What does a project manager actually do when executing the project?

The question "What does a project manager actually do when executing the project?" often gets answered with vague statements about keeping work on track, but the execution phase involves far more specific, observable responsibilities. During project execution, the project manager and the project management team direct the performance of planned activities and manage the various technical and organizational interfaces within the project. That sentence may sound abstract, yet it covers a range of concrete actions: producing deliverables, coordinating people, securing resources, capturing performance data, handling change requests, managing risks, and documenting lessons. This article walks through those responsibilities in detail, drawing on established project management frameworks and practical realities.

Project Manager Execution Duties: Key Topics Summary

What Does a Project Manager Actually Do When Executing the Project? The Core Process

In the PMBOK framework, project execution corresponds to the Executing Process Group, where the primary process is Direct and Manage Project Work. This process turns the project management plan into actual outputs, and it is where the project manager spends a large portion of their time. The project manager does not simply monitor progress from a distance. Execution means actively guiding the team, making decisions, allocating resources, and removing obstacles that block work. The planned activities themselves come from the project management plan, but the act of directing those activities requires constant adjustment to real conditions.

Think of a construction project where the plan calls for concrete pouring on a specific date. The project manager has to ensure the crew is available, the concrete supplier delivers on time, the forms are inspected, and the weather does not create a safety problem. If the supplier is late, the project manager does not just record the delay. They call another supplier, resequence the work, or negotiate a partial delivery. That is the direct management work that defines execution.

The source activities listed for this process are not sequential steps. They overlap continuously. A project manager may be reviewing a deliverable draft, then immediately shift to a team conflict about resource allocation, then respond to a change request from a stakeholder. This multitasking is not a failure of structure. It reflects the nature of execution, where technical and organizational interfaces constantly interact. The technical interface might be a software module depending on an API that another team is building. The organizational interface might be a functional manager who controls a shared testing resource. The project manager has to manage both types of interfaces at once.

What this really means in practice is that a project manager spends less time writing plans and more time resolving the gap between plan assumptions and real conditions. Plans assume resources will be available, requirements will remain stable, and communication will flow naturally. Execution proves otherwise. The project manager's job is to close that gap without losing sight of the project's objectives.

Creating Project Deliverables and Performing Planned Work

One of the most visible responsibilities during execution is creating project deliverables. Deliverables are the outputs from processes performed to accomplish the project work planned and scheduled in the project management plan. They can be tangible, such as a building, a report, or a software application, or they can be intangible, such as a training program or a set of documented procedures. The project manager does not usually create every deliverable personally, but they remain accountable for ensuring that the work gets done to the required standard.

In a software project, creating deliverables might involve writing code, designing user interfaces, producing test cases, and writing user documentation. Each of those outputs requires coordination. The developer writing the code may need clarification on a requirement. The tester may need access to a test environment. The technical writer may need a stable version of the product to document. The project manager facilitates those handoffs. They do not just assign tasks and walk away. They track progress, remove blockers, and verify that each deliverable meets the acceptance criteria defined in the project scope.

A common pitfall here is treating deliverables as the only measure of progress. A deliverable may be completed on paper but still fail to satisfy the underlying requirement. For example, a document may be submitted by the deadline but contain incomplete analysis. The project manager has to look beyond the binary status of "done" and assess whether the deliverable actually serves its intended purpose. That is why work performance information about the completion status of deliverables is collected as part of project execution and feeds into performance reporting and the Monitoring and Controlling Process Group.

Another nuance is that deliverables are produced through processes, not just individual effort. A deliverable may require design review, quality inspection, user testing, and final approval before it is accepted. The project manager ensures those processes happen in the right order and without unnecessary delay. If the quality inspection is skipped because the team is behind schedule, the deliverable may pass into the next phase and create rework later. That rework is often far more expensive than the delay it was meant to avoid.

Staffing, Training, and Managing the Project Team

During execution, the project manager must staff, train, and manage the team members assigned to the project. This does not mean the project manager always has formal hiring authority. In many organizations, team members are assigned by functional managers or resource owners. The project manager still has to assess whether the assigned people have the right skills, and if not, arrange for training or coaching. Managing the project team during execution includes setting expectations, resolving conflicts, providing feedback, and maintaining motivation.

Team management in execution is not a one-time activity. It changes as the project moves through different phases. Early in execution, the project manager may focus on onboarding and setting up collaboration norms. Later, the focus may shift to performance issues or knowledge transfer between team members. In a long project, team fatigue becomes a real factor. A project manager who ignores the human side of execution will eventually face lower productivity, higher turnover, or silent disengagement.

A realistic scenario helps illustrate this. Suppose a developer is assigned to a project but has never worked with the specific database technology the project uses. The project manager could simply expect the developer to figure it out, but that often leads to delays and quality problems. A better approach is to arrange a short internal training session with a senior engineer or to pair the developer with a more experienced colleague. That training is part of execution work, not just a planning artifact. The project manager has to make it happen in real time.

Business value-oriented project management adds another layer here. Practitioners applying that perspective often treat employee-created tools and open-source software as formal products rather than informal side work. They also mandate cross-functional teams as a core success factor during execution. This means the project manager does not just accept whatever team structure the organization provides. They actively work to ensure the team includes the right mix of skills and perspectives to deliver value without handoff delays.

Conflict resolution is another part of managing the team. Execution creates pressure. Deadlines tighten, requirements shift, and people disagree about the best technical approach. The project manager has to intervene before conflicts affect the work. Ignoring a conflict between a designer and a developer may seem polite, but it can fester and disrupt the entire team. Effective execution requires addressing disagreements directly, fairly, and with a focus on the project's objectives rather than personal preferences.

What Team Management Looks Like When Executing the Project

The daily reality of managing a team during execution includes checking in with people, identifying blockers, and adjusting assignments. It also means recognizing when someone is overloaded and redistributing work before quality suffers. A project manager who only tracks tasks and never talks to team members will miss early warning signs of trouble. The best execution happens when the project manager understands both the work and the people doing it.

Training and coaching often get deprioritized during execution because they feel like overhead. That is a mistake. A small investment in a targeted training session can prevent weeks of rework. The project manager has to make that case to stakeholders and protect the time for learning. This is not about being nice. It is about protecting the project's schedule and quality.

Key Insights on Team Management

Staffing requires skill verification

When functional managers assign team members, the project manager still needs to verify that each person has the required competencies and should arrange targeted training or coaching to close any gaps before work begins.

Managing covers motivation and feedback

Ongoing team management during execution requires setting clear expectations, addressing conflicts early, providing constructive feedback, and actively sustaining motivation so that the group remains productive.

Leadership focus shifts over time

During the early stages of execution, the project manager focuses on onboarding and establishing collaboration norms; as the work progresses, attention shifts to resolving performance issues and facilitating knowledge transfer among team members.

Neglecting human factors carries costs

Ignoring the human side of execution tends to produce lower productivity, higher turnover, or quiet disengagement; proactive measures such as running internal training sessions or pairing a developer with a senior colleague can prevent these issues from turning into delays and quality problems.

Obtaining, Managing, and Using Resources

Execution also requires the project manager to obtain, manage, and use resources including materials, tools, equipment, and facilities. People are one type of resource, but they are not the only one. A project can stall because a server is not provisioned, a piece of lab equipment is not calibrated, or a meeting room is not available for a critical workshop. Managing resources during execution means securing these items at the right time and ensuring they remain usable throughout the project.

Physical resources often get less attention than human resources in project management training, but they cause just as many execution delays. Consider a pharmaceutical project that requires a specialized clean room for a pilot batch. The plan may assume the clean room is available in week six. When week six arrives and another project is using the facility, the project manager has to negotiate access, adjust the schedule, or find an alternative. None of that is glamorous work, but it is exactly the kind of execution responsibility that keeps a project moving.

Tools and equipment also need maintenance and availability management. A construction project manager does not just order a crane and forget about it. They confirm delivery, ensure the operator is certified, and monitor daily usage. If the crane breaks down, the project manager coordinates repairs and communicates the impact to the schedule. In a software project, the equivalent might be a build server or a test environment. When the test environment goes down, testing stops. The project manager has to escalate the issue and get it resolved, not just wait for it to fix itself.

Facilities are another resource category. A training project may require a large room with specific audiovisual equipment. A manufacturing project may require floor space for a new production line. The project manager coordinates these physical spaces, often in competition with other projects or ongoing operations. Managing these interfaces is part of the technical and organizational complexity of execution.

Implementing Planned Methods and Standards

During execution, the project manager must implement the planned methods and standards. These methods and standards were defined during planning, often in the project management plan or subsidiary plans. Execution is where they are actually applied to the work. This includes coding standards in a software project, safety protocols in a construction project, and documentation standards in a regulatory project. The project manager ensures that the team follows these standards consistently.

A common misconception is that standards slow things down. In reality, good standards reduce rework and make handoffs smoother. If every developer follows the same coding style, code reviews take less time. If every site worker follows the same safety procedure, accidents decrease. The project manager's job during execution is to enforce these standards without becoming rigid. There will be cases where a standard needs to be adapted because the project context changed. That adaptation should be deliberate, not accidental drift.

Implementation of methods also includes the specific processes for how work is approved, how documents are versioned, and how quality checks are performed. A project may have a defined change control process, but it only matters if people actually use it. The project manager models the right behavior. When a stakeholder asks for a quick scope addition, the project manager routes it through the change control process instead of simply telling the team to do it. That consistency protects the project from uncontrolled scope creep.

Pitfalls arise when methods are treated as documentation exercises rather than practical tools. A team may have a risk register that no one updates, or a quality checklist that people sign without actually checking. The project manager has to make these artifacts useful. If the risk register is just a form, it will be ignored. If risk reviews are tied to real decisions about response actions, people will engage. Execution is where the value of planning artifacts is either confirmed or lost.

Key Insights on Standards Execution

Executing what planning defined

The execution phase translates the methods and standards defined during planning, usually documented in the project management plan or subsidiary plans, into the team's actual work.

Standards vary by industry

Software teams rely on coding standards, construction teams follow safety protocols, and regulatory projects depend on rigorous documentation standards.

Manager enforces compliance

During execution, the project manager holds the team accountable for applying the defined standards consistently across all deliverables.

Strong standards reduce rework

Consistent standards reduce handoff friction and rework, for example code reviews move faster when developers share a common style and accident rates fall when all site workers follow the same safety procedure.

Broader processes also standardized

Standardization during execution also governs approval workflows, document version control, quality check procedures, and the routing of change requests through change control.

Establishing and Managing Project Communication Channels

Execution cannot succeed without effective communication. The project manager must establish and manage project communication channels, both external and internal to the project team. Managing project communication channels includes deciding who needs what information, how often, and in what format. It also means monitoring whether those channels actually work as intended.

Internal communication happens within the project team. It includes daily standups, status updates, issue logs, and informal conversations. The project manager ensures that team members share information that affects each other's work. A developer who changes an API specification must tell the tester and the technical writer. A procurement specialist who learns about a supplier delay must inform the scheduler. When these internal channels break down, work gets duplicated, deadlines slip, and quality suffers.

External communication happens with stakeholders outside the immediate team. This could be a project sponsor, a functional manager, a customer, or a regulatory body. The project manager tailors the message for each audience. The sponsor may need high-level progress and key risks. The customer may need confirmation that a milestone has been met. The regulator may need proof of compliance. Sending the same detailed status report to everyone is not communication management. It is information dumping.

A practical example helps. Suppose a project is behind schedule on a critical deliverable. The project manager does not wait until the monthly steering committee meeting to raise the issue. They inform the sponsor immediately, explain the cause, and propose a recovery plan. They also tell the team what is expected of them in the coming week. Keeping the sponsor informed prevents surprise and builds trust. Letting the team know the recovery plan reduces uncertainty and helps them focus.

One common failure during execution is overcommunication without structure. Endless email threads and status meetings can create noise that hides important signals. The project manager has to design communication channels that are concise and purposeful. If a daily standup turns into a 45-minute discussion, it stops being useful. The project manager may need to coach the team on what belongs in the standup and what should be handled offline.

How Communication Channels Shift When Executing the Project

Communication needs change as execution progresses. Early in execution, the team may need frequent clarification on requirements. Later, the focus shifts to resolving integration issues. Near the end, communication may center on acceptance testing and handover. The project manager adjusts the channels accordingly. A weekly status meeting may be more than enough in the middle of execution, but daily check-ins might be necessary during a critical integration phase.

External communication also becomes more intense when issues arise. A supplier delay may require a formal notification to the customer. A safety incident may require immediate reporting to a regulator. The project manager has to know which channels are required by contract, by regulation, or by organizational policy, and use them correctly. Failure to communicate through the right channel can be just as damaging as not communicating at all.

Generating Work Performance Data for Forecasting

During execution, the project manager and the team generate project data such as cost, schedule, technical and quality progress, and status to facilitate forecasting. This work performance data is not just a reporting afterthought. It is the raw material that allows the project manager and stakeholders to understand where the project actually stands. Without reliable data, forecasting becomes guesswork.

Work performance data includes things like actual start and finish dates, actual costs, hours spent, defects found, and milestones achieved. In a software project, it might be the number of user stories completed, the number of open defects, and the actual effort logged against a task. In a construction project, it might be the cubic meters of concrete poured, the number of inspections passed, and the actual cost of materials delivered. Each piece of data seems small, but together they create a picture of performance.

The project manager has to ensure this data is collected consistently and accurately. That often means setting up simple tracking mechanisms that do not burden the team. If team members have to spend hours entering data into multiple systems, they will cut corners or delay entry. The data will become stale and useless. A better approach is to integrate data collection into the work itself. For example, a developer updates task status when code is merged. A site supervisor logs daily progress in a mobile app. The data flows naturally from execution.

This data feeds into performance reporting and the Monitoring and Controlling Process Group. The project manager uses it to compare actual performance against baselines. If actual cost is trending 10 percent over budget, the forecast will show a cost overrun unless corrective action is taken. If actual progress is slower than planned, the forecast will show a schedule slip. Execution data makes those early warnings possible.

A common pitfall is treating data collection as a compliance activity rather than a decision tool. The team fills out timesheets because they have to, but no one uses the data to make decisions. That wastes time and creates cynicism. The project manager should close the loop by using the data in team reviews and forecasting discussions. When people see that their data leads to real adjustments, they take it more seriously.

Core Insights: Performance Data Enables Forecasts

Work data is raw material

Actual performance records such as start and finish dates, actual costs, hours logged, defects identified, and milestones reached provide project managers and stakeholders with an evidence-based view of project health, replacing assumptions with verifiable facts.

Metrics vary by project type

The indicators that matter change with the project domain; software teams commonly monitor completed user stories, open defects, and logged effort, whereas construction teams track concrete volumes poured, inspections passed, and material costs delivered.

Low-burden tracking ensures accuracy

Project managers should establish a small set of consistent, low-friction data collection routines that fit naturally into daily work, because requiring updates across multiple systems encourages shortcuts, missing entries, and late reporting.

Issuing Change Requests and Adapting Approved Changes

During execution, the project manager must issue change requests and adapt approved changes into the project's scope, plans, and environment. Change is inevitable. Requirements evolve, stakeholders identify new needs, risks materialize, and technical constraints force adjustments. The project manager has to manage that change deliberately rather than letting it happen informally.

Issuing a change request means formally documenting a proposed change to the project baseline. The project manager may initiate the change request themselves, or a team member or stakeholder may raise it. Once issued, the change request goes through the integrated change control process, which is part of the Monitoring and Controlling Process Group. But the project manager's responsibility during execution includes preparing the request, understanding its impact, and ensuring that approved changes are actually integrated into the work.

This is where many projects go off track. A stakeholder asks for a small addition. The team says yes to be helpful. No change request is issued. The scope creeps. Later, the schedule slips and the budget overruns. The project manager has to enforce the discipline of formal change requests even for small changes. That does not mean being bureaucratic. It means making the cost and schedule impact visible before the change is accepted.

Once a change is approved, the project manager must adapt the project scope, plans, and environment. Updated requirements have to be communicated to the team. The schedule may need to be rebaselined. The risk register may need new entries. Approved changes also affect documents like the work breakdown structure, the quality management plan, and the procurement plan. The project manager ensures those updates happen, not just that the change is recorded in a log.

Adapting approved changes also means changing the project environment when necessary. A new software tool may need to be installed. A new vendor may need to be onboarded. A new work area may need to be set up. These environmental changes are easy to overlook, but they can delay execution if not handled promptly. The project manager looks beyond the immediate scope change to understand what else must shift.

Handling Change and Risk When Executing the Project

Change and risk are closely linked during execution. A change request often arises because a risk has materialized or because a stakeholder wants to avoid a future risk. The project manager has to assess both dimensions. Implementing a change may reduce one risk but introduce another. For example, switching to a new supplier may solve a delivery problem but create quality uncertainty. The project manager evaluates that trade-off and documents it in the change request.

Change requests should not be seen as failures of planning. They are a normal part of execution. No plan can anticipate every condition. The discipline of issuing and adapting changes keeps the project aligned with its objectives even as the environment shifts. A project that refuses to change becomes irrelevant. A project that changes without control becomes chaotic. The project manager's job is to find the balance.

Managing Risks and Implementing Risk Response Activities

Execution is when risks stop being hypothetical and start affecting real work. The project manager must manage risks and implement risk response activities throughout the execution phase. This includes monitoring known risks, identifying new risks, and putting planned responses into action. A risk response plan that sits in a document is worthless. Execution is where it gets tested.

Suppose a project identified the risk that a key supplier may fail to deliver a critical component. The planned response might be to qualify a backup supplier. During execution, the project manager watches for early warning signs from the primary supplier. If those signs appear, the project manager activates the backup supplier. That activation is a risk response activity. It may involve issuing a purchase order, conducting a quality audit, and updating the schedule. All of that happens during execution, not during planning.

Risk management during execution also includes implementing contingency plans when triggers occur. A trigger is a defined event that indicates a risk has occurred or is about to occur. The project manager has to recognize the trigger and act quickly. Delays in responding to risks often make them worse. A small supply chain disruption can become a full production stoppage if the project manager waits too long to react.

New risks also emerge during execution. A technical approach may turn out to be less stable than expected. A team member may leave the project. A regulatory requirement may change. The project manager has to identify these new risks, assess their impact, and develop responses in real time. This is not the same as the initial risk planning. It is more reactive, but it still follows a structured thought process. The project manager asks: What is the risk, how likely is it, what is the impact, and what can we do about it?

A common pitfall is treating risk management as a periodic review activity rather than a continuous execution discipline. Risks change weekly, sometimes daily. A risk register that is only reviewed at monthly meetings will be out of date. The project manager should encourage the team to raise risks as they see them, not wait for a formal review. That requires psychological safety. Team members must feel comfortable reporting bad news without fear of blame. Otherwise, risks get hidden until they become issues.

Key Lessons on Executing Risk Responses

Risks become real during execution

Execution is the point at which risks become concrete and begin to affect real work, requiring the project manager to actively manage known risks while monitoring for new ones throughout the phase.

Plans require proactive implementation

A risk response plan remains theoretical until it is executed, so the project manager must activate planned actions such as qualifying backup suppliers, issuing purchase orders, and conducting quality audits as soon as early warning signs appear.

Contingency triggers demand rapid action

Contingency plans must be implemented as soon as trigger conditions are met, because any delay in response can allow a minor supply chain disruption to escalate into a complete production stoppage.

Managing Sellers and Suppliers During Project Execution

Many projects depend on external sellers and suppliers. During execution, the project manager must manage sellers and suppliers to ensure they meet their contractual obligations. This includes monitoring delivery schedules, reviewing quality, handling invoices, and resolving disputes. The project manager may not be the procurement officer, but they remain responsible for the supplier's performance as it affects the project.

Managing sellers starts with clear contracts and statements of work. But execution is where the relationship is tested. A supplier may promise a delivery date in the contract and then miss it. The project manager has to hold the supplier accountable while also maintaining a workable relationship. That requires a mix of firmness and diplomacy. If the supplier is a sole source, the project manager may have limited leverage. In that case, they may need to adjust the project schedule or find a partial workaround.

Supplier management also includes verifying that what was delivered is actually what was ordered. A vendor may deliver materials that fail inspection. The project manager coordinates the rejection, the rework, and the schedule impact. A software vendor may deliver a module that does not meet the acceptance criteria. The project manager documents the nonconformance and manages the remediation. These activities are part of execution, not procurement planning.

Invoices and payments are another execution responsibility. The project manager may need to approve supplier invoices based on actual progress. If a supplier invoices for 50 percent of the contract value but has only completed 20 percent of the work, the project manager should flag the discrepancy. Paying too early reduces leverage. Paying too late damages the relationship. The project manager has to manage cash flow against performance.

One subtle point is that supplier management is not just about enforcement. Good supplier relationships can help the project in times of trouble. A supplier who feels fairly treated may prioritize the project when a shortage occurs. A supplier who feels micromanaged may become uncooperative. The project manager has to balance oversight with respect. That is a skill that cannot be fully captured in a process document.

Collecting Lessons Learned and Implementing Process Improvement

During execution, the project manager must collect and document lessons learned and implement approved process improvement activities. Lessons learned are not something to be left until the end of the project. They are captured continuously as the work happens. A team may discover a better way to run a meeting, a faster way to test a component, or a risk that should have been identified earlier. The project manager records those insights and uses them to improve the current project, not just future ones.

Implementing approved process improvement activities means actually changing how the team works based on those lessons. If the team discovers that code reviews are taking too long because of unclear standards, the project manager may update the standards and adjust the review checklist. If the team finds that daily standups are not surfacing blockers, the project manager may change the format to focus on impediments. These are small but real improvements that compound over the life of the project.

A common mistake is collecting lessons learned only when things go wrong. Positive lessons are just as valuable. If a particular technique sped up integration testing, the team should record why it worked and how to replicate it. The project manager can then institutionalize that practice in the current project or share it with other projects. Lessons learned are not just a post-mortem exercise. They are a living part of execution.

Documenting lessons learned also requires a usable format. If the lessons are buried in a shared drive and never discussed, they have no impact. The project manager should review lessons at regular team meetings and connect them to process changes. A lesson that leads to a visible improvement reinforces the habit of sharing. A lesson that disappears into a repository teaches the team that sharing is pointless.

How Application Area Shapes Project Execution

The Direct and Manage Project Execution process is also directly affected by the project application area. Project application area influences execution more than many people realize. A software project executes differently from a construction project, a pharmaceutical project, or an event planning project. The principles are the same, but the specific activities, constraints, and risks vary widely.

In a software project, execution often follows iterative cycles. Work is broken into small increments, and deliverables are produced continuously. The project manager facilitates sprint planning, daily coordination, and sprint reviews. Risk management focuses on technical debt, integration failures, and changing user needs. In a construction project, execution is more sequential and heavily regulated. The project manager coordinates site logistics, safety inspections, and material deliveries. Change requests often involve formal contract modifications.

In a pharmaceutical project, execution includes rigorous documentation and compliance activities. Every step may need to be validated and traceable. The project manager has to balance speed with regulatory requirements. In an event planning project, execution is compressed into a short window, and there is little room for error. The project manager coordinates vendors, volunteers, and logistics under intense time pressure. The application area changes the tools, the vocabulary, and the specific risks, but the core execution responsibilities remain.

Understanding the application area helps the project manager anticipate where execution problems are likely to occur. In regulated industries, documentation gaps often cause delays. In technology projects, integration issues are a frequent source of risk. In physical construction, weather and site conditions create uncertainty. The project manager who understands these patterns can plan responses and manage expectations more effectively.

Execution is also affected by organizational culture and maturity. Some organizations have strong project management discipline and clear escalation paths. Others operate in constant firefighting mode. The project manager has to adapt their approach to the environment while still maintaining the core disciplines of directing work, managing resources, communicating, and controlling change. That adaptability is part of what makes execution difficult to teach and even harder to master.

When execution is working well, it looks almost invisible. Deliverables appear, team members know what to do, and stakeholders receive the information they need. When execution fails, the signs are obvious: missed deadlines, frustrated team members, scope creep, budget overruns, and constant surprises. The project manager's real contribution is not in producing a single deliverable. It is in maintaining the system of direction, coordination, and control that allows all the other work to happen. That is what a project manager actually does when executing the project.