Executing the Project Plan

Executing the project plan is the third of five process groups in project management, following initiation and planning, and preceding monitoring and controlling, and closing. It is the phase where the project team does the actual work defined in the project management plan. If the planning phase is like drawing a map, execution is the journey itself.

To understand execution, you need to know the key parts of the project management plan. The scope baseline defines exactly what the project will deliver and what it will not. The schedule baseline sets the timeline, often shown as a Gantt chart or a network diagram. The cost baseline is the approved budget. During execution, the project manager coordinates people and resources to turn those baselines into a completed product, service, or result.

A critical concept in execution is the work performance data. This is raw information coming from the team — number of tasks completed, hours worked, materials used. The project manager collects this data to compare it against the baselines. If the team is behind schedule, the manager can take corrective action.

Team leadership is central to execution. The project manager motivates the team, resolves conflicts, and ensures everyone knows their responsibilities. This is done through a responsibility assignment matrix, often called a RACI chart, which stands for Responsible, Accountable, Consulted, and Informed. A RACI chart clarifies who does the work, who signs off, who needs to be asked, and who just needs a heads-up.

Communication during execution is constant. The project manager holds kick-off meetings to formalise the start of work, daily stand-up meetings for quick status updates, and status review meetings with stakeholders to report progress. A communication management plan, created during planning, defines who gets what information, how often, and through what channel. For example, the sponsor might receive a monthly dashboard, while the team gets a weekly email with task assignments.

Another major execution activity is managing stakeholder expectations. Stakeholders are anyone with an interest in the project — customers, executives, end-users, regulators. The project manager proactively engages them, addresses concerns, and keeps them informed. Failure to manage stakeholders often leads to scope creep — unauthorised changes that grow the project beyond its original boundaries.

Quality assurance also happens in execution. Quality assurance, or QA, is the process of auditing the work to ensure it meets the quality standards defined in the plan. This is different from quality control, which happens during monitoring and controlling and focuses on inspecting the final product. QA is about preventing defects; QC is about catching them.

Finally, execution is where change requests arise. A change request is a formal proposal to modify the project's scope, schedule, cost, or quality. The project manager logs these in a change log and takes them through the change control process, which includes evaluation, approval, and implementation. If the change is approved, the baselines are updated and the team adjusts their work.

Execution is not a passive phase. The project manager must actively lead, communicate, and manage. Without strong execution, even a well-planned project will fail.

Sarah is a project manager at a small IT consultancy that has been hired to deploy a new customer relationship management (CRM) system for a retail client. The planning phase is complete: the scope baseline lists 150 features, the schedule says 12 weeks, and the budget is approved at £180,000. Now execution begins.

Step one: Sarah conducts a kick-off meeting with the development team, the client's IT lead, and a representative from the sales team who will use the system. She hands out the RACI chart so everyone knows who is responsible for writing code, who is accountable for testing, and who needs to be consulted on data migration. The team agrees on a daily stand-up meeting at 9:30 AM via video call.

Step two: During the first two weeks, the developers build the user login and dashboard modules. Sarah collects work performance data — tasks completed, hours coded, bugs found. She enters this into the project management software. By week three, the client requests a change: they want the dashboard to show a new metric called "customer lifetime value" that was not in the original scope. Sarah logs this as a formal change request. She assesses the impact: two extra developer days and a £3,000 cost increase. She presents this to the change control board — a group that includes the client's director and her own project sponsor. They approve it, and Sarah updates the baselines.

Step three: Sarah notices the team is running one week behind schedule because the login module took longer than expected. She facilitates a problem-solving session. The team identifies that the integration with the client's existing inventory system is causing delays. Sarah assigns a senior developer to work exclusively on that integration for three days. She communicates the new timeline to the stakeholders at the weekly status meeting.

Step four: Halfway through, the sales team lead tells Sarah the new system is hard to navigate. Sarah treats this as a stakeholder concern. She organises a demonstration for the sales team and collects feedback. Most issues are minor — button placement, label changes — so she implements them without a formal change request because they are within the approved scope. One request, however, is significant: the sales team wants a mobile app. That would require a new change request and budget approval.

Step five: In the final two weeks, the QA team audits the development process. They verify that all 157 features (150 original plus 7 approved changes) are built to the client's quality standards. Sarah prepares a handover document and schedules the training sessions for end-users. Execution closes when the system goes live and the client signs the acceptance form.