A PMaaS engagement should not begin with a project manager and a to-do list. It should begin with the delivery problem you need to solve. Knowing how to structure PMaaS means turning that problem into clear authority, practical governance, visible reporting and accountable execution.
That matters when a transformation is stalled, a regulatory deadline is approaching, a technology rollout is growing in complexity, or internal leaders are carrying more delivery risk than their roles can reasonably absorb. The right structure gives the project manager enough access and authority to move work forward, while keeping decisions where they belong - with your executive team.
Start with the delivery outcome, not the resource
The first question is not, “What level of project manager do we need?” It is, “What must be true six or 12 months from now for this work to be considered successful?”
Be specific. A core system implementation may need to meet a fixed compliance date without disrupting operations. A community housing provider may need to bring order to a portfolio of asset, tenant and technology initiatives. A growing retailer may need to launch a new platform while protecting trading performance. These are different delivery environments, and they require different operating models.
Define the outcome in business terms: the capability being introduced, the deadline that cannot move, the risk that must be reduced, the customer or operational impact, and the executive accountable for the result. This becomes the anchor for the PMaaS scope.
A weak brief asks a project manager to “support the team”. A strong brief identifies the programme or project boundaries, the decisions to be made, the stakeholders who matter and the measures that will show whether delivery is on track. The distinction is significant. Support can become open-ended. Accountable delivery has a clear purpose.
Match the PMaaS structure to complexity
Not every initiative needs the same level of leadership. A contained project with a known solution, limited dependencies and an engaged sponsor may need a Project Manager focused on planning, coordination, risk management and delivery discipline.
A more complex initiative may require a Mid-Level Project Manager to manage multiple workstreams, vendors, operational impacts and competing stakeholder priorities. Where the work spans a major transformation, recovery programme, high-risk compliance change or several interconnected projects, a Senior Project Manager can provide stronger governance, executive engagement and strategic control.
The right choice depends on more than project budget or team size. Consider the level of ambiguity, the number of decision-makers, the consequence of delay, the maturity of your internal governance and the amount of change expected from staff or customers.
A common mistake is to structure the engagement around administration when the real constraint is decision-making. If the project is stalled because no one is resolving scope trade-offs, challenging assumptions or escalating risks early, a more senior delivery lead may be needed. Conversely, assigning senior oversight to a simple, stable project can add unnecessary layers. The structure should fit the risk, not the title.
Give the delivery lead clear authority
An embedded project manager needs a defined mandate from day one. They should know what they can decide, what they can recommend and what must be escalated. Without this, delivery slows down as routine matters are pushed upwards and critical risks remain unresolved while teams wait for direction.
Set this out in a practical responsibility model. The project sponsor owns the business outcome and provides decisions when trade-offs arise. The project manager owns the delivery plan, cadence, coordination, risk management and reporting. Workstream leads own their assigned outputs. Executives and subject matter experts contribute decisions, expertise and approvals at agreed points.
This does not need to become a complex document. It does need to be understood. In particular, agree who can approve scope changes, commit internal resources, sign off key deliverables and accept residual risk. These are the points where otherwise well-planned projects lose momentum.
The PMaaS lead should also have direct access to the sponsor. A weekly or fortnightly sponsor check-in is usually more valuable than a monthly meeting that is crowded with status updates. The purpose is to make decisions, remove barriers and test whether the work remains aligned to the organisation’s priorities.
Build governance that helps work move
Governance should create control without burying the team in meetings. The best structure is proportionate: enough discipline to expose risks and drive decisions, without duplicating conversations or producing reports nobody uses.
For most significant initiatives, establish a delivery rhythm that includes a working team meeting, a project or programme steering forum and a sponsor escalation path. The working team addresses dependencies, actions and near-term issues. The steering forum considers major decisions, budget or scope movements, strategic risks and benefits. The escalation path is for matters that cannot wait for the next scheduled meeting.
Each forum needs a clear purpose, standing attendees and decision rights. If a steering committee is only receiving updates, it is not governing the work. It should be actively deciding on the few issues that could materially affect outcome, timing, risk or stakeholder confidence.
Reporting should serve the same aim. A concise report that shows milestones, decisions required, top risks, budget position and overall delivery confidence is more useful than a lengthy document full of activity. Senior leaders need an accurate picture quickly. Teams need enough detail to act. Those are different audiences, and the reporting format should reflect that.
Structure the first 30 days around certainty
The early phase of PMaaS should reduce uncertainty quickly. Before accelerating delivery, the project manager needs to establish the real state of the work. Plans often look complete until someone tests ownership, dependencies, assumptions and resourcing against reality.
The first 30 days should focus on confirming scope, reviewing the delivery plan, mapping stakeholders, assessing risks and dependencies, and setting the governance cadence. It is also the right time to identify decisions that have been deferred, suppliers or internal teams that are not aligned, and milestones based on optimistic assumptions.
This is especially important in a recovery situation. Teams under pressure often respond by adding more meetings and more reporting. A better response is to find the few blockers that are preventing progress, establish ownership and make the necessary decisions visible to the right people.
A sound mobilisation phase produces a baseline: what has been agreed, what is in motion, what is at risk, what needs a decision and what the next critical milestones are. From there, the delivery lead can manage change rather than simply react to it.
Treat change management as part of delivery
A project can meet its technical milestones and still fail to deliver the intended business benefit. This happens when the people expected to use, operate or support the new capability have not been prepared for the change.
PMaaS should therefore include change impacts from the start. Identify who will be affected, what will be different for them, where resistance may emerge and which leaders need to reinforce the change. For a new technology platform, that may involve process owners, frontline teams, customer support and data owners. For a compliance initiative, it may include operational leaders who need to embed new controls into day-to-day work.
The depth of change activity depends on the initiative. A contained internal process change may only need targeted communications and manager briefings. A business-wide transformation may require detailed readiness planning, training coordination, communications and adoption measures. The key is not to leave this work until the final weeks before go-live.
Measure performance beyond the traffic lights
Red, amber and green reporting is useful, but it is not enough on its own. A project can remain green for months because the underlying measures are vague or because risks have not been tested honestly.
Use delivery indicators that show whether the work is truly under control: milestone predictability, decision turnaround times, unresolved dependency age, risk exposure, stakeholder readiness and benefit progress. The measures should reflect what is most likely to derail the initiative.
For example, in a multi-vendor technology implementation, dependency management may be the leading indicator. In a regulatory programme, approval timing and evidence quality may matter most. In a construction or social infrastructure project, approvals, site access and procurement lead times may be critical. Good PMaaS structures surface these signals early enough for leaders to act.
Review the structure as the work changes
PMaaS should not be treated as static. A project may need intense senior leadership during discovery, recovery or a critical delivery phase, then a different level of support once governance is established and delivery is predictable. Equally, a contained project can become more complex when new requirements, stakeholder concerns or external dependencies emerge.
Review the engagement at meaningful points: after mobilisation, before major delivery gates, when scope changes materially and as the project moves into implementation or transition. Ask whether the governance is still helping, whether decision rights remain clear and whether the current level of delivery leadership matches the risk.
At JJPH, this is how we approach embedded delivery: establish control quickly, create a practical operating rhythm and take ownership of the work that needs to move. The goal is not more project management theatre. It is a delivery structure that gives leaders confidence, teams direction and important work a genuine path to completion.
The strongest PMaaS model is the one your organisation can feel working: decisions arrive faster, risks appear earlier, teams know what matters next and the sponsor is no longer left guessing whether the project is truly on track.
