Understanding what the deliverables and outcomes of project execution actually are is essential for anyone overseeing the Directing and Managing Project Work process. In PMBOK terms, project execution sits inside the Executing process group and represents the point where the project management plan is put into action. Plans have been approved, resources are being applied, and the project team is performing the activities that were described during planning. Execution is not a passive phase; it generates a structured set of outputs that feed directly into monitoring, controlling, and eventual closing activities.
The source notes for this article identify four primary outputs of project execution: deliverables, work performance information, change requests, and updates to both the project management plan and project documents. Each of these outputs has a distinct role. Some are tangible and immediately visible, such as a completed prototype or a tested software module. Others are informational or procedural, such as cost performance data or a request to adjust baseline dates.
A common misunderstanding is that execution only produces the product or service the project was chartered to create. That is part of the story. But execution also produces the information needed to understand whether the project is on track, the formal requests that allow the plan to change, and the administrative records that maintain consistency as work unfolds. Without these outputs, the project manager would be flying blind. Execution, in other words, is not just about doing the work. It is about producing the evidence of work and the signals that guide future decisions.
Some of these outputs are easy to overlook because they are not physical. A change request is a document or a record in a system. Work performance information is often a set of numbers in a dashboard. Project document updates might be a few lines added to a risk register. Yet these invisible outputs are just as important as the main deliverable. They create the feedback loop that keeps a project controllable.
Project Execution Deliverables and Outcomes: Key Topics Summary
| Key Concept | Summary |
|---|---|
| Execution Outputs | Outputs generated during project execution form the operational baseline for monitoring, controlling, and closing, ensuring that downstream decisions rely on current execution evidence. |
| Deliverables | A deliverable may take the form of a tangible asset, software module, status report, training session, proof of concept, or formally approved decision, each of which must meet acceptance criteria before handoff. |
| Work Performance Information | Execution generates performance data that is converted into actionable information for schedule, cost, quality, and risk analysis, enabling timely corrective action and informed stakeholder reporting. |
| Change Requests | Formal change requests originating during execution, including corrective actions, preventive actions, and defect repairs, are routed through integrated change control to maintain scope, cost, and schedule integrity. |
| Plan Updates | Execution results in controlled updates to the project management plan and project documents, ensuring that baselines, logs, and registers reflect actual work and remain administratively consistent. |
| Process Integration | The Direct and Manage Project Work process integrates human resources, equipment, materials, and stakeholder inputs while defining the performance data to be captured and the communication channels to be used. |
| PRINCE2 Mapping | Under PRINCE2, the Managing Product Delivery process requires teams to create specialist products and report progress to the Project Manager, aligning work package execution with stage boundaries and quality checks. |
| Adaptive Execution | In adaptive environments, execution and validation occur within short iterations, enabling continuous feedback loops that adjust priorities, refine backlog items, and align delivery with evolving business value. |
Defining the Deliverables and Outcomes of Project Execution
When execution operates effectively, it produces project execution outputs that serve as formal inputs to control processes. These outputs are not optional byproducts. They are the evidence that execution occurred and that the project is moving according to intent. The Direct and Manage Project Work process coordinates people, equipment, and materials, but it also determines what gets recorded and how that record gets used downstream.
The term "deliverable and outcomes of project execution" can be understood at two levels. At the immediate level, execution delivers completed work items and reports about progress. At a broader level, execution yields a clearer picture of project health and the adjustments needed to keep the project viable. Both levels matter because they connect to different stakeholder concerns. A sponsor may care about the finished deliverable, while the project manager and control board care about the performance information.
Key Deliverables and Outcomes of Project Execution
The source definition of a deliverable is precise. An approved deliverable is any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project. This definition is intentionally broad. A deliverable can be a physical component, a software feature, a report, a training session, a proof of concept, or a formally documented decision. The phrase "unique and verifiable" distinguishes project outputs from ongoing operational outputs. It means the deliverable can be checked against acceptance criteria or quality requirements.
Verification matters because a deliverable cannot simply be declared complete by the person who built it. It must be examined by someone other than the producer or measured against an agreed standard. In project execution, the team produces the deliverable, but formal sign-off typically occurs through the Validate Scope process or through quality control. Execution creates the item. Validation confirms that the item meets requirements. This distinction avoids the dangerous situation where the project team marks work as done without an independent check.
The outcome side of project execution can be confusing because the same work can produce both immediate outputs and longer term effects. For instance, a project to implement a new procurement system produces the configured software as a deliverable. The outcome might be faster purchase approvals, but that benefit materializes after the project closes and the software is used. During execution, the discussion usually focuses on the deliverable itself, along with performance information that tells whether the work is progressing acceptably. Longer term business outcomes are typically measured after transition and benefits realization.
Execution outputs do not sit in isolation. Deliverables move to quality control and scope validation. Work performance information feeds the Monitor and Control Project Work process. Change requests go to the Perform Integrated Change Control process. Project document updates maintain the repository used by team members and stakeholders. This flow is one of the reasons execution is described as a central hub: it generates the raw material for nearly every controlling activity.
In a PRINCE2 environment, similar concepts appear through the Managing Product Delivery process, where the team produces specialist products and passes them to the Project Manager through checkpoint and highlight reports. Agile environments, by contrast, often collapse execution and validation into short iterations so that the deliverable and its acceptance happen almost simultaneously. The vocabulary changes, but the intent remains the same: produce something verifiable and generate the information needed to steer the project.
How Execution Outputs Feed Other Processes
The connection between execution outputs and later processes is often underappreciated. A deliverable that moves to quality control without adequate documentation can trigger rework. Work performance information that is too vague can make variance analysis meaningless. A change request that lacks detail can stall in the change control board. Project document updates that are delayed can create inconsistencies between what the team believes and what the official records show. In each case, the quality of the execution output directly affects the quality of the control decision.
This feedback loop works in both directions. Controlling processes may produce change requests that send work back to execution. For example, if quality control identifies a defect, the defect repair request goes through integrated change control and then returns to execution for implementation. The execution phase then produces an updated deliverable and updated performance information. This iterative pattern is natural and expected. Treating execution as a one-way production line ignores the reality that projects constantly adjust based on what they learn.
Key Insights on Execution Outputs
- Two levels of execution results
- Execution produces tangible outputs, including completed work and progress reports, alongside broader insights into project health and the corrective actions required to address distinct stakeholder concerns.
- Defining an approved deliverable
- An approved deliverable is a unique, verifiable product, result, or capability that marks the completion of a phase or project and can take the form of physical components, software features, reports, training sessions, or documented decisions.
- Sign-off and reporting mechanisms
- Formal acceptance of deliverables is achieved through processes such as Validate Scope or quality control, and PRINCE2 operationalizes this through the Managing Product Delivery process, which uses checkpoint and highlight reports to transfer specialist products to the Project Manager.
Deliverables as the Primary Output of Project Execution
The source definition states that an approved deliverable is any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project. The word "approved" is important because it signals that the deliverable has passed some form of verification. The same deliverable may go through several approval gates at different levels, from a technical review to a formal product acceptance.
Deliverables exist at multiple levels within a project. A large construction project may have a foundation inspection report as a phase deliverable, while the entire building is the project deliverable. A software project may have a sprint increment as a deliverable, while the final deployed system is the project deliverable. The level of formality and the verification method vary according to the deliverable's importance and the project's governance rules. A small internal report may need only a supervisor's review, while a safety-critical component may require formal testing and regulatory sign-off.
One common pitfall is confusing activities with deliverables. Holding three stakeholder meetings is an activity. The meeting minutes and updated stakeholder register are deliverables. Completing a design workshop is an activity. The approved design document is a deliverable. This distinction matters because project progress is measured against deliverables, not against hours worked or meetings attended. A team can be very busy and still produce no verifiable outputs. Project managers who focus on deliverables keep the project oriented toward results.
Approved Deliverables in Project Execution
The execution process does not finalize acceptance in every case. It produces candidate deliverables that then go through quality control and scope validation. The term "approved deliverable" in the source indicates that some deliverables may be approved as part of execution when a process or phase closes, but the formal acceptance typically occurs in the Validate Scope process. In practice, project managers often use "signed off" and "accepted" interchangeably. The formal PMBOK distinction matters for governance and audit trails, especially when payment milestones are tied to deliverable acceptance.
Deliverables can take many forms. Tangible products include hardware, prototypes, reports, and physical components. Intangible capabilities include a trained team, an installed software function, or a new operational procedure. Results include a proof-of-concept outcome, a decision record, or a demonstrated performance level. The source emphasizes "capability to perform a service" because service-based projects often produce operational capability rather than a physical object. For example, a project to set up an IT service desk may produce an onboarding runbook and a functioning ticketing system as deliverables.
In Agile environments, deliverables are often working increments of the product at the end of each sprint. The definition of done provides the verification standard. This is a slightly different rhythm but the same underlying principle: something unique and verifiable is created each iteration, and the team cannot claim completion without satisfying the defined quality criteria. The main difference is that Agile teams often accept the deliverable incrementally with the product owner rather than waiting for a separate validation gate at the end of the project.
Types of Deliverables Produced During Execution
A deliverable can be a document that captures a decision, a component that becomes part of the final product, or a service capability that the organization can use after transition. In a process improvement project, the deliverable might be a redesigned workflow and a set of standard operating procedures. In a marketing project, the deliverable could be a campaign plan and a set of creative assets. The common thread is that each deliverable is unique to the project and can be verified against an agreed standard.
Some deliverables are intermediate, meaning they are used by later project activities but do not go to the customer. Examples include technical specifications, test plans, and procurement documents. Other deliverables are final, meaning they are handed to the customer or operational team at project closure. Both types must be tracked during execution. Losing sight of intermediate deliverables is dangerous because later work depends on them. A missed test plan can delay the entire testing phase.
Work Performance Information Generated During Project Execution
After project activities begin, the execution process routinely collects and organizes work performance information from various performance results. The source lists three primary types: deliverable status, schedule progress, and costs incurred. This information is not a single report but a collection of data points that, when analyzed, tell the project manager whether the project is on track, ahead, or behind.
Work performance information is often confused with raw work performance data. In PMBOK, raw observations are data, while analyzed and contextualized information is the output of the execution process as described here. For example, the number of hours a developer worked is data. The comparison of those hours against the planned hours for a particular activity, expressed as a variance, is information. Execution may produce both, but the formal process output is the information that can support decisions.
Tracking Deliverables and Outcomes of Project Execution Through Work Performance Information
The deliverable status component tells the project manager how much of each deliverable is complete, in progress, or not started, and whether completed portions have passed quality checks. This is more than a simple percentage. It includes the current state of verification and any known issues affecting completion. A deliverable that is 80 percent physically complete but has failed a critical test is not truly 80 percent complete in a meaningful sense. The status information must reflect both physical progress and quality status.
Schedule progress data compares planned start and finish dates to actual performance. It includes milestones reached, activities in progress, and activities that are delayed. This information feeds schedule variance analysis and helps the project manager decide whether corrective action is needed. If a critical path activity is slipping, the schedule progress report will surface it before the delay becomes unmanageable. Cost incurred data works similarly. It shows actual expenditures against the cost baseline and provides the basis for cost variance and earned value calculations.
Cost information is not just about money spent. It also includes committed costs, such as purchase orders issued but not yet invoiced, and accruals. This broader view prevents the project manager from being surprised by a large invoice that arrives after the reporting period closes. Work performance information therefore supports forecasting as much as it supports reporting. It is backward-looking in the sense that it records what happened, but forward-looking in the sense that it enables predictions about the remaining work.
In Agile environments, work performance information often appears as burndown charts, velocity, and cumulative flow diagrams. These tools visualize progress in a way that is easy for the team and stakeholders to understand. The same underlying principles apply: the team is collecting data about completed work, remaining work, and impediments, then turning that data into information that supports adaptation. The terminology may differ, but the purpose is identical.
One practical difficulty is that teams often collect too much data and fail to convert it into useful information. A project manager can drown in raw timesheets and status updates without ever seeing a clear picture of project health. The solution is to define in advance what information will be collected, how it will be summarized, and who will receive it. This is the purpose of the communications management plan, which itself may be updated during execution as reporting needs change.
Core Insights on Execution Performance Data
- Three primary information types
- During execution, work performance information consolidates deliverable status, schedule progress, and actual costs to give project teams a reliable basis for monitoring delivery outcomes.
- Data versus information distinction
- Raw observations represent data, whereas analyzed and contextualized outputs become information that directly informs project decisions and corrective actions.
- Deliverable status tracking
- This component tracks the degree of completion for each deliverable, records whether acceptance criteria have been met, and highlights open issues that may delay final acceptance.
- Schedule progress comparison
- By comparing planned start and finish dates with actual performance, schedule progress data reveals variances that show whether work is on track, ahead of plan, or slipping behind.
Change Requests Produced During Project Execution
When issues are found while project work is being performed, the project team issues change requests that may modify project policies or procedures, project scope, project cost or budget, project schedule, or project quality. Change requests are among the most important execution outputs because they are the formal mechanism for adapting the project to new realities. Without them, the project would either remain frozen in an outdated plan or change informally without control.
Change requests can be direct or indirect, externally or internally initiated, and optional or legally or contractually mandated. A direct change request might come from a stakeholder asking for a specific feature. An indirect change request might arise when a risk event occurs and the team realizes that a planned approach is no longer feasible. An externally initiated change could be driven by a new regulation or a supplier change. An internally initiated change could come from the project team identifying a better technical solution. Optional changes are those that could be accepted or rejected without legal consequence, while mandated changes must be implemented to remain compliant.
Change Request Types Impacting Deliverables and Outcomes of Project Execution
Corrective action is a documented direction for executing the project work to bring expected future performance in line with the project management plan. It addresses a deviation that has already occurred or is currently occurring. For example, if the schedule is slipping by three weeks, corrective action might involve adding resources, resequencing activities, or reducing scope in a later phase. The trigger for corrective action is a variance, and the objective is to restore alignment with the plan.
Preventive action is different. It is a documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks. Preventive action is forward-looking and risk-based. It does not require that a problem has already occurred. If a supplier shows early signs of financial instability, preventive action might involve qualifying a backup supplier before the primary supplier fails. Preventive action often gets less attention than corrective action because it addresses possibilities rather than actual problems. But it can be more valuable because it prevents the problem from materializing.
Defect repair is a formally documented identification of a defect in a project component with a recommendation to either repair the defect or completely replace the component. Defect repair requests are usually triggered by quality control activities. A software module that fails a test case generates a defect repair request to fix the code. A physical component that cracks during stress testing generates a defect repair request to replace or reinforce the component. The key distinction is that defect repair focuses on a specific, identified fault, whereas corrective action focuses on performance deviations from plan.
Updates are changes to formally controlled documentation, plans, or other project artifacts to reflect modified or additional ideas or content. This is a broad category. It can include updating a requirements specification after new details emerge, revising a test plan to cover an additional scenario, or changing a risk response strategy based on new information. Updates may accompany other change request types or stand alone when the change is administrative and does not affect project baselines.
Many teams treat change requests only as scope changes. That is a mistake. Corrective action, preventive action, and defect repair are all change requests. If a project manager implements a corrective action without submitting a change request, the project may be adjusting in an uncontrolled way. The formal change control process is designed to evaluate the impact of any change, whether it is driven by a scope request, a performance deviation, or a quality defect. Execution generates the request; integrated change control authorizes it.
Project Management Plan Updates in Project Execution
As execution generates new information and approved changes, the project management plan must be updated through project management plan updates to keep the plan aligned with reality. The source lists several elements that may be updated, including the requirements management plan, schedule management plan, cost management plan, quality management plan, human resource plan, communications management plan, risk management plan, procurement management plan, and project baselines.
These updates do not happen automatically. They occur after a change request is approved or after a formal review determines that the plan no longer reflects how the project will be managed. For example, if the project team discovers that a particular requirement is far more complex than originally thought, the requirements management plan may need to be updated to reflect a more rigorous traceability approach or a change in how requirements will be prioritized.
Project Management Plan Updates in Project Execution
The requirements management plan can be updated when new stakeholders are identified, when the requirements process is modified, or when traceability structures change. The schedule management plan and cost management plan may be updated when the project adopts new estimating techniques, changes control thresholds, or revises reporting formats. The quality management plan may change when defect trends reveal the need for additional quality control activities or revised quality metrics.
The human resource plan may be updated during execution as roles and responsibilities evolve, as new training needs emerge, or as the team structure changes. The communications management plan often changes when stakeholders are added or removed, when reporting frequency is adjusted, or when communication tools are replaced. The risk management plan may be updated as the risk appetite shifts, as new risk categories are identified, or as the approach to risk responses changes based on execution experience.
The procurement management plan may need updates if the project decides to source additional goods or services, if contract types are renegotiated, or if supplier management procedures change. Project baselines, including the scope baseline, schedule baseline, and cost baseline, can only be updated through formal integrated change control. Execution does not change baselines directly. Instead, execution produces change requests that, when approved, lead to baseline revisions. This separation is important because it prevents the team from unilaterally moving targets to make performance look better.
Project management plan updates are outputs of Direct and Manage Project Work because the team implements the approved changes and updates the plan documents. But the actual decision to approve the change belongs to the Perform Integrated Change Control process. This distinction can be subtle in practice, especially on small projects where the project manager may have authority to approve certain changes. Even then, the update should be recorded and communicated as a formal plan change, not an informal adjustment.
Some plan updates are administrative and do not require baseline changes. For example, updating a stakeholder list in the communications management plan may be a simple documentation update. Other updates affect how the project is managed and should be handled through the project's change control procedure. The project manager must know which updates are within their authority and which require escalation.
Key Insights on Plan Alignment
- Updates follow approved changes
- The project management plan is revised only when a change request has been formally approved or when a structured review determines that the plan no longer reflects the agreed approach for managing the project.
- Multiple subsidiary plans affected
- Updates may span the full set of subsidiary plans, including requirements, schedule, cost, quality, human resource, communications, risk, and procurement management plans, together with their associated project baselines.
- Real-world triggers drive revisions
- Concrete conditions such as newly identified requirement complexity, the adoption of new estimating techniques, evolving role definitions, shifts in risk appetite, or changes in stakeholder composition each prompt targeted revisions to the relevant management plan.
Project Document Updates in Project Execution
Execution also produces project document updates that keep the project's supporting records current and reliable. The source lists requirements documents, project logs, the risk register, and the stakeholder register as examples. These documents are not part of the project management plan, but they are essential for managing the project day to day. When they are neglected, the project can develop a split personality: the official plan says one thing while the team's working documents say another.
Project Document Updates in Project Execution
Requirements documents may be updated as execution reveals more detail. A vague requirement such as "fast response time" might be refined to a specific latency threshold after technical work clarifies what is achievable. This is not necessarily a scope change. It is an increase in clarity. Requirements documents can also be updated when new requirements are approved through change control or when existing requirements are decomposed into smaller, testable components.
Project logs include the issue log, assumption log, and decision log. Execution records issues as they arise, assumptions as they are validated or invalidated, and decisions as they are made. This documentation is critical for traceability. If a decision made during execution is later questioned, the decision log provides the reasoning and the date. If an assumption turns out to be false, the assumption log shows when it was identified and what impact it had. These logs are not bureaucratic overhead; they are the project's memory.
The risk register is updated continuously during execution. New risks are identified as work reveals unknowns. Existing risks are updated with their probability and impact values as conditions change. Risk responses are marked as implemented, effective, or ineffective. Triggers that have occurred are documented. A risk register that is not updated during execution quickly becomes useless. It becomes a snapshot from planning rather than a living document that guides current decisions.
The stakeholder register may also need updates. New stakeholders can emerge as the project enters new phases or as external conditions change. Existing stakeholders may shift in their level of influence or interest. Contact information changes. The project manager may need to add notes about stakeholder engagement preferences or concerns raised during execution. Keeping this register current supports the communications management plan and helps prevent misunderstandings.
One frequent mistake is updating the project management plan but ignoring the supporting documents. The plan may be revised to say that a new quality control step is required, but if the issue log and risk register are not updated to reflect the underlying problem, the team loses the context for why the change was made. Document updates should be part of the execution workflow, not an afterthought. A simple practice is to update the relevant document immediately after any significant execution event, such as a defect discovered, a decision made, or a new stakeholder identified.
Integrating Execution Outputs into Project Control
The real value of execution outputs appears when they are integrated into project control and governance. The project manager must move deliverables to validation, route work performance information to monitoring processes, submit change requests to integrated change control, and record plan and document updates in the project management information system. This integration is what turns execution from a production activity into a managed process.
Deliverables that are not passed to quality control and scope validation may be considered complete by the team but not by the organization. Work performance information that is not analyzed against baselines is just raw data. Change requests that are not processed through the change control board create uncontrolled change. Plan and document updates that are not communicated to stakeholders create confusion. In each case, the lack of integration undermines the project's control structure.
How to Use Execution Outputs for Project Control
The execution outputs create a feedback loop. Deliverables inform scope validation, which may result in change requests. Work performance information informs variance analysis, which may trigger corrective action. Change requests feed integrated change control, which may lead to plan updates. Plan and document updates then alter the guidance for future execution. This loop is the engine of project management. It allows the project to adapt without losing control.
Project managers should define the expected quality of each execution output in advance. A deliverable should have clear acceptance criteria. Work performance information should have a defined format and frequency. Change requests should have a template that captures the description, rationale, impact, and recommendation. Plan and document updates should follow a version control procedure. When these standards are clear, the integration becomes smoother and the risk of miscommunication drops.
From a Business Value-Oriented Project Management perspective, execution treats employee-created tools and open-source software as formal products, which means they should be captured, documented, and considered in deliverable tracking just like any other output. Cross-functional teams are also emphasized as a core success factor during execution. This perspective reinforces the idea that execution outputs are not limited to customer-facing deliverables. Anything the team creates that adds value or supports the project should be recognized and managed.
The quality of execution outputs also affects the organization's ability to learn from the project. Lessons learned are often derived from the same information captured in project logs, risk registers, and change requests. When those records are incomplete, the organization loses valuable knowledge. A defect that was repaired but not documented may reappear in a future project because the root cause was never recorded. Execution outputs therefore serve both immediate control and long term organizational improvement.
Key Insights on Execution Integration
- Integration enables managed execution
- Execution outputs deliver measurable value only when they are systematically routed into validation, monitoring, change control, and document management processes.
- Four control pathways for outputs
- To preserve control, project managers route deliverables to validation, work performance data to monitoring, change requests to change control, and plan updates to the project management information system.
- Unintegrated outputs create governance risk
- Deliverables that bypass validation may gain internal team acceptance yet face organizational rejection, and unprocessed change requests lead to uncontrolled change and stakeholder confusion.
- Performance data drives corrective action
- Work performance information enables variance analysis against baselines, which in turn can trigger corrective actions that keep the project aligned with its objectives.
- Employee tools are formal deliverables
- From a business value perspective, employee-created tools and open-source software are formal deliverables that must be captured, documented, and tracked like any other project output.
Common Pitfalls in Managing Execution Deliverables and Outcomes
Several common execution pitfalls can reduce the value of the deliverables and outcomes produced during project execution. The first is treating scope creep as inevitable. When stakeholders request informal changes and the team implements them without going through change control, the project scope, schedule, and budget drift. The resulting documentation becomes inaccurate, and the project manager loses the ability to report true progress. Execution must produce change requests, not hidden changes.
Another pitfall is false progress reporting. A team may report a deliverable as 90 percent complete for weeks because the remaining 10 percent is more difficult than expected. Work performance information that is not honest creates a false sense of control. The project manager should verify status claims against objective criteria, such as test results, inspections, or completed deliverables, rather than relying on subjective estimates.
Delayed document updates are also common. Project managers sometimes defer updating the risk register or issue log until a convenient time, but that time rarely comes. The result is that the documents lag behind reality. A risk that should have been added during execution is only captured after it has already affected the project. This undermines the value of the risk management process and leaves the team without a current picture of project threats.
Finally, execution outputs can be produced but not used. A change request may be written and then buried in a file. Work performance information may be generated but never analyzed. Deliverables may be completed but never formally validated. The value of an output lies in its use, not its existence. The project manager must create a habit of moving each output to the next step in the process. Execution is not the end of the line. It is the beginning of a control cycle that continues until the project closes.
The deliverables and outcomes of project execution are not just a list of items to check off. They are the connective tissue between doing the work and managing the work. A project that produces a brilliant deliverable but no work performance information is uncontrolled. A project that produces meticulous change requests but never updates its plan is disconnected. The best execution practices treat every output as part of a single integrated flow, where each piece informs the next and keeps the project moving toward its intended result.
