Executing in PM²: Delivering the Solution and Making It Adoptable

Eleventh article in the “Learning PM² Through a Project” series

The Executing Phase is when the project produces planned deliverables and performs the activities needed for the solution to be transferred and used.

It is not the same as technical development alone.

Executing answers: “Are we delivering the agreed results and preparing the organisation to use them?”

The Two Results of the Phase

Every project must manage two connected results:

The PCT produces the solution; the BIG prepares business change. The PM coordinates delivery; the BM focuses on adoption and benefits. If either side is missing, the project may complete an output without producing an outcome.

Delivery: Producing What Was Planned

During Executing, the Project Core Team performs the work defined in the Project Work Plan. Depending on the project, this may include development, configuration, integration, testing, service procurement, data migration, technical documentation and release preparation.

The Project Manager must:

• coordinate activities, resources and dependencies;
• compare actual progress with the baseline;
• manage risks, issues, changes and decisions;
• keep plans, logs and reports current;
• ensure quality and deliverables integration;
• manage escalations and decisions beyond the PM’s authority.

In Smart Bookings, the PCT delivers class configuration, booking, cancellation, waiting lists and notifications on web and mobile. The PM coordinates backend, app, testing and pilot integration.

Deliverables Acceptance: “Finished” Is Not Enough

A deliverable is not complete merely because the team believes it is finished. It must be verified against agreed acceptance criteria.

Manage Deliverables Acceptance requires the project to:

• identify what must be accepted;
• define criteria and required evidence;
• organise review, testing and sign-off;
• record non-conformities and corrective actions;
• retain the acceptance decision.

Acceptance protects both business and provider: it shows that the result was assessed against known criteria rather than later impressions.

Managing Non-Conformities and Rework

If a deliverable does not meet the criteria, it should not be accepted “with reservations” without a clear decision.

The project should record the non-conformity, assess severity and impact, assign actions, plan the next verification and communicate the decision to relevant roles.

In Smart Bookings, if a notification of an available place arrives too late to meet requirements, the issue may prevent acceptance. The PCT corrects it; the PM replans; users or designated roles repeat verification.

Transition: Moving from Delivery to Operations

Transition organises the movement of the solution towards operations, support and maintenance.

It may include:

• data migration or preparation;
• environment configuration;
• operational and technical documentation;
• support, monitoring and ownership arrangements;
• handover to operations;
• release and rollback procedures;
• readiness checks.

The Transition Plan, prepared during Planning and updated in Executing, prevents delivery to the business from being an informal and fragile handover.

For Annotatio, transition includes infrastructure availability, notification-error handling, support instructions and clear ownership after release.

Business Implementation: Enabling Adoption

Business Implementation is the work required for the organisation to change behaviours, processes and competences in order to use the new result.

It may include:

• process updates;
• training;
• communications;
• pilots and feedback collection;
• user and support material;
• change-resistance management;
• early adoption measurement;
• corrective actions for user experience.

The Business Manager leads these activities with the BIG.

In Smart Bookings, a gym must know how to configure a class, manage absences and waiting lists, and support a customer. Releasing a feature without preparing these activities produces available software, not adopted change.

Monitor & Control During Executing

Executing concentrates much of the work, but control remains continuous:

1. observe status, quality, cost and risk;
2. compare them with baselines and objectives;
3. decide corrective, preventive or change actions;
4. update logs, plans and reports;
5. escalate decisions through governance.

A delay is not automatically failure. It becomes a governance problem when it is ignored, hidden or addressed by informally changing the baseline.

Preparing RfC – Ready for Closing

The RfC Gate does not only check whether “the team has finished development”. It checks whether the project can responsibly enter Closing.

Key questions are:

• are planned deliverables complete and accepted?
• are non-conformities, issues and residual actions closed or explicitly managed?
• are transition and handover complete to the agreed level?
• have Business Implementation, training and initial support been performed?
• are documents, logs and reports current?
• are there post-project actions to assign to operations?

A project may have a production release and still not be RfC-ready.

Practical Case: The Release Is Online but the Project Cannot Close

Smart Bookings is available in the app. However:

• two pilot gyms have not been trained;
• support has no procedure for failed notifications;
• a critical waiting-list defect remains open;
• user sign-off has not been collected.

The release occurred, but closure is not ready. The PM, BM, PCT and BIG must complete or formally manage these items before proposing RfC.

Do Not Confuse

Test What You Remember

1. What are the two results that Executing must manage?
2. Why is a completed deliverable not automatically accepted?
3. What does transition prepare?
4. Who leads Business Implementation?
5. What does RfC check?

Answers

1. Delivery and Business Implementation.
2. Because it must be verified against agreed acceptance criteria.
3. Handover to operations, support and maintenance.
4. The Business Manager, with the BIG.
5. That the project is ready to enter Closing with deliverables, transition and residual actions managed.

Flashcards

Q: Who normally produces deliverables?
A: The Project Core Team.

Q: Who leads Business Implementation?
A: The Business Manager.

Q: What makes a deliverable acceptable?
A: Verification and sign-off against agreed criteria.

Q: What does the Transition Plan prepare?
A: Handover and integration of the solution into operations.

Q: What does RfC authorise?
A: Entry into the Closing Phase.

Exam-Style Question

Which situation most clearly prevents a transition to RfC?

A. The team has updated the Project Work Plan with actual progress.
B. All deliverables are accepted and residual actions are assigned to operations.
C. The software is released, but a critical deliverable is not accepted and transition is incomplete.
D. The PSC has received the Project Status Report.

Correct answer: C. A technical release does not compensate for missing acceptance and transition required for responsible closure.

In the Next Article

In the next article, we will address Closing in PM²: the Project-End Report, Lessons Learned, recommendations and the difference between project closure and product life.

Essential Sources

• European Commission, PM² Project Management Methodology Guide v3.1.
• European Commission, PM² Project Management Methodology – Highlights, 2025 Edition.