If you cannot execute the work you planned and handle changes without losing control, your project will spiral into chaos, missed deadlines, and blown budgets. For PMP candidates, understanding how to direct and manage project work – and how to formally process changes – is the difference between a project that finishes smoothly and one that fails. This chapter gives you the practical framework to keep the project on track while adapting to reality.
Jump to a section
A simple way to picture Executing Project Work and Managing Changes
A Master Builder is the person responsible for turning a set of architectural blueprints into a finished house. They don't just hand the plans to a crew and hope for the best. Every morning, they walk the site, check that the foundation matches the drawings, and solve problems as they arise. When the homeowner sees a different window in a catalogue and asks to swap it, the Master Builder doesn't just say yes. They check the schedule, the budget, and whether the wall can support the new window. They submit a formal change request to the architect, get approval, and then update the plans for the electricians and plumbers. The whole job is about coordinating the crew, managing materials, and keeping the project on track despite unexpected rain, late deliveries, or last-minute requests. The Master Builder's job is executing the work and managing changes without letting the house collapse.
Later, when the house is finished, the Master Builder walks through every room with the homeowner, makes sure everything works, and hands over the keys along with a folder of warranties and maintenance instructions. That is project closure – a proper hand-off so the homeowner can live in the house without calling the builder every week. This analogy maps precisely to executing project work: you are the Master Builder, your project plan is the blueprint, and every change request – from a new window to a different wall colour – must be evaluated, approved, and documented before you touch a single nail.
Executing project work is the phase where you actually do what you planned. In project management, planning is essential, but a plan is useless unless you carry it out. The PMP exam calls this the 'Executing Process Group'. It is the phase where the team builds the product, delivers the service, or produces the result the project exists to create.
Imagine you are organising a community festival. Your plan says you need permits, a stage, vendors, and volunteers. Executing the work means you go to city hall for the permits, hire the stage crew, contact vendors, and assign volunteers to their shifts. While you do this, things inevitably change. A vendor cancels. The weather forecast predicts rain. A volunteer cannot make it. These are changes you must manage.
Managing changes is the formal process of handling deviations from the plan. It is not about preventing change – change is normal. It is about controlling change so that every adjustment is evaluated for its impact on time, cost, quality, and scope. In PMP terms, you use an 'Integrated Change Control' process. This means every change request – whether from a stakeholder, a team member, or a new regulation – must be logged, assessed, and either approved or rejected by the right people.
A Change Request is a formal proposal to modify any document, deliverable, or baseline. A baseline is the approved version of a plan – the schedule, budget, or scope statement – that you measure progress against. Once a baseline is set, any change to it must go through approval.
To execute work effectively, you need to manage the 'Project Team' – the people doing the work – and 'Stakeholder Engagement' – keeping everyone informed and involved. You also produce 'Work Performance Data', which is raw data about how the project is going, like 'the team completed 40% of the coding this week'. This data feeds into monitoring and controlling.
When changes come in, you assess them using a 'Change Control Board' (CCB) – a group of stakeholders authorised to approve or reject changes. Not every change needs the CCB. Minor changes that do not affect baselines can be approved by the project manager. But any change that affects scope, schedule, cost, quality, or key resources must go through the full process.
The key document here is the 'Change Log', which records every change request and its status – submitted, under review, approved, or rejected. This log creates an audit trail so you can show why decisions were made.
Why does this matter? Without a formal change management process, you get 'scope creep' – uncontrolled changes that gradually expand the project beyond its original goals. Scope creep is one of the biggest reasons projects fail. The PMP exam tests your ability to spot when a change needs formal approval versus when you can handle it informally.
Finally, closing the project is the formal ending. You obtain 'Final Acceptance' from the customer or sponsor, you release resources, and you archive documents. This step is often rushed, but it is essential for learning lessons and closing contracts. The PMP exam will test you on the difference between 'Close Project or Phase' and 'Close Procurements'.
Receive and Log the Change Request
Any stakeholder, team member, or sponsor can submit a change request. The first step is to log it in the change log with a unique ID, date, description, and submitter. This ensures no request is lost and provides an audit trail.
Assess the Impact of the Change
The project manager or a designated team member evaluates how the change affects the project baselines – scope, schedule, cost, quality, and risk. This analysis is documented and presented to the decision-making body.
Submit the Change Request to the Change Control Board (CCB)
If the change impacts baselines, the project manager presents the impact analysis to the CCB. The CCB reviews the information and makes a decision: approve, reject, defer, or request more information.
Update the Project Management Plan and Baselines
If the change is approved, the project manager updates the relevant baselines (e.g., schedule baseline, cost baseline) and the project management plan. The change log is updated to reflect the approval and implementation status.
Communicate the Decision and Implement the Change
The project manager communicates the CCB's decision to all relevant stakeholders. The team then implements the approved change according to the updated plan. The change log is updated again once implementation is complete.
Close the Project or Phase
After final deliverables are accepted, the project manager obtains formal sign-off from the customer or sponsor, releases the team, archives project documents, and closes contracts. This step ensures all project work is complete and documented.
A real IT professional, say a project manager at a mid-sized software company, lives this process daily. Consider Priya, a project manager leading a team building a mobile banking app. The project plan is approved, and the team starts executing: developers write code, designers create screens, and testers write test cases. Priya's job is to facilitate the work, remove obstacles, and ensure everyone knows what to do.
One Tuesday, the product owner asks Priya, 'Can we add a fingerprint login feature? Users are requesting it.' Priya does not say yes immediately. She asks the team to estimate the effort: two extra weeks of development. The original schedule has no buffer. Priya logs this as a 'Change Request' in the change log. She assesses the impact: scope increases, schedule extends by two weeks, cost rises for extra developer hours, and quality may suffer if the team rushes. She presents the analysis to the Change Control Board, which includes the product owner, a senior architect, and the sponsor. The CCB approves the change, and Priya updates the project management plan and the scope baseline. The team then starts work on the fingerprint feature.
Another day, a developer realises they can use a more efficient code library that saves two days of work. This is a change that does not affect the scope, schedule, or cost baseline – it just makes execution faster. Priya approves this change informally, as it does not require CCB approval. She notes it in the change log for transparency.
During the project, a key test engineer resigns. This is a resource change. Priya works with HR to find a replacement, but she also updates the stakeholder register and the resource management plan. She communicates the change to the team and reassigns tasks temporarily. All of this is part of managing changes to the project environment.
At the end of the project, Priya organises a 'Project Closure' meeting. She walks the product owner through every feature on the app, gets formal sign-off on the final deliverable, and archives the project documents, including the change log, lessons learned, and the final project report. She also releases the team to new projects and closes the contract with the external testing vendor. This closure ensures the company can learn from the project and access the documents if needed later.
The PMP exam tests this area heavily, because executing work and managing changes are at the heart of project management. You will see 15-20 questions on these topics, often in scenario-based formats. The exam loves to test your ability to identify when a change requires formal integrated change control versus when it does not.
Common question types:
Scenario: A stakeholder requests a small change. What do you do first? (Answer: Assess the impact of the change, then follow the change control process.)
Scenario: The team wants to improve a process mid-project. Do you need a change request? (Answer: Only if it affects baselines. If not, approve informally.)
Straight definition: What is the purpose of the change log? (Answer: To track all change requests and their status.)
Process question: Which process includes the CCB? (Answer: Perform Integrated Change Control.)
Traps the PMP exam sets:
Trap 1: The question says 'implement the change immediately' but you must check if it impacts the baseline first. The correct answer is always 'analyse impact' before taking action.
Trap 2: The question involves a 'corrective action' – remember that corrective actions are changes to bring performance back in line with the plan. They still require a change request if they affect baselines.
Trap 3: Confusing 'monitoring and controlling' with 'executing'. Executing is about doing the work; monitoring and controlling is about tracking. The exam will ask which process group a specific activity belongs to.
Trap 4: Scope creep vs. approved change. Scope creep is unapproved change. If the team adds a feature without a change request, that is scope creep. The exam will test if you recognise that scope creep is a risk, not a benefit.
Key concepts to memorise:
Integrated Change Control: The process of reviewing all change requests, approving changes, and managing changes to deliverables, documents, and baselines.
Change Control Board (CCB): The formally chartered group responsible for approving or rejecting changes.
Change Log: A document containing all change requests and their status.
Corrective Action: An intentional activity that realigns the performance of the project work with the project management plan.
Preventive Action: An intentional activity that ensures the future performance of the project work is aligned with the project management plan.
Defect Repair: An intentional activity to modify a nonconforming product or product component.
The exam will also test closing. Know the difference between 'Close Project or Phase' (finalises all activities across all process groups) and 'Close Procurements' (finalises each contract). You close procurements before or at the same time as the project or phase closure.
Finally, remember that all changes must go through the change control process, even if the change request comes from the project sponsor. The sponsor has authority, but the process still applies. This is a classic exam trap.
Executing project work is the process of directing the team to produce the deliverables defined in the project management plan.
Every change request must be assessed for its impact on scope, schedule, cost, quality, and risk before approval.
The Change Control Board (CCB) is a formally authorised group that approves or rejects changes affecting baselines.
The change log is a formal record of every change request and its current status throughout the project lifecycle.
Scope creep is unapproved change that accumulates without control and is a primary cause of project failure.
Project closure requires final acceptance from the customer, release of resources, archiving of documents, and contract closeout.
Integrated change control applies to all change requests – from stakeholders, team members, or sponsors – without exception.
Corrective and preventive actions and defect repairs are all types of change requests that must be tracked.
The project manager can approve changes that do not impact baselines, but baseline-affecting changes need the CCB.
Executing and monitoring and controlling occur in parallel, not sequentially.
These come up on the exam all the time. Here's how to tell them apart.
Corrective Action
Reactive – responds to a performance deviation that has already occurred.
Brings project performance back in line with the plan.
Example: Reassigning work to catch up after a delay.
Is a type of change request that may require CCB approval if baselines are affected.
Preventive Action
Proactive – prevents a potential future deviation.
Ensures future performance remains aligned with the plan.
Example: Training the team to avoid a known quality issue.
Is also a type of change request that may require CCB approval if baselines are affected.
Change Log
Tracks all formal change requests and their status.
Used to manage scope changes and baseline updates.
Approved changes update the project baselines.
Created during the executing process group.
Issue Log
Tracks problems, obstacles, and concerns that arise during the project.
Used to manage risks and issues that need resolution.
Resolving issues may or may not require a change request.
Updated throughout the project lifecycle.
Close Project or Phase
Finalises all project activities across all process groups.
Produces final acceptance and lessons learned.
Archives all project documents and releases resources.
Can occur at the end of a phase or the entire project.
Close Procurements
Finalises each contract with a vendor or supplier.
Confirms that all deliverables from the vendor are accepted.
Closes the contract financially and administratively.
Usually occurs before or simultaneous with project closure.
Work Performance Data
Raw data from executing work – e.g., hours spent, tasks completed.
Unprocessed and not yet analysed.
Collected during the executing process group.
Example: 'Team completed 5 of 10 user stories this week.'
Work Performance Information
Analysed data that provides context – e.g., variance from baseline.
Processed and ready for decision-making.
Produced during monitoring and controlling process group.
Example: 'Team is 10% behind schedule due to unexpected bug fixes.'
Mistake
If a change is small, you don't need to document it at all.
Correct
Every change, even minor ones, should be documented in the change log for transparency and auditability.
Beginners think documentation is unnecessary overhead, but the PMP exam requires documentation for traceability and to prevent scope creep from accumulating.
Mistake
The project manager can approve any change without involving others.
Correct
The project manager can only approve changes that do not affect baselines (scope, schedule, cost). Changes affecting baselines require the Change Control Board approval.
New project managers often overestimate their authority, but the PMP emphasises governance and stakeholder representation in decisions.
Mistake
Executing and monitoring happen in separate phases – first you do the work, then you check it.
Correct
Executing and monitoring happen simultaneously. The team executes work while the project manager monitors progress and verifies performance in real time.
Linear thinking leads beginners to imagine waterfall phases, but real projects and the PMP process groups overlap and iterate constantly.
Mistake
Scope creep is inevitable and should be accepted as normal.
Correct
Scope creep is uncontrolled change that must be avoided. All changes should go through formal integrated change control to protect the project's baselines.
Beginners confuse being flexible with being uncontrolled. The PMP test expects you to protect the project's integrity through formal processes.
Mistake
Closing the project is just a paperwork step you can skip if the customer is happy.
Correct
Project closure is a formal process that includes obtaining final acceptance, releasing resources, archiving documents, and closing contracts. Skipping it creates risk for future projects and audits.
Practical experience often rushes closure, but the PMP exam values it as a critical process for accountability and learning.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A change request is a formal proposal to modify a documented plan or deliverable. A defect repair is a specific type of change that fixes a non-conforming product. Both go through integrated change control.
Yes, but only if the change does not affect any baseline – scope, schedule, or cost. If it impacts baselines, the CCB must approve it.
That is scope creep. The project manager should document the change, assess the impact, and retroactively submit a change request. The team should not implement unapproved changes.
No. Closing a phase ends one phase of a project (e.g., planning) and may transition to the next. Closing a project ends the entire project. Both use the Close Project or Phase process.
Yes, if the corrective action affects a baseline (scope, schedule, cost, quality). Small corrective actions that do not affect baselines can be done without a change request but should be documented.
You need final project reports, lessons learned, project archives, formally signed acceptance from the customer, and documentation of closed contracts. All change logs should be archived too.
You've finished Executing Project Work and Managing Changes. Continue through the PMP study guide to build a complete picture of the exam.
Done with this chapter?