The term strong PMO is traditionally used to describe a model where the project or programme management office is deeply embedded in an organisation and acts as the central guiding authority on how programmes and their projects are to be managed. Pcubed's Stefan Bertschi suggests using the term to propose an organisational concept of strong PMO equally suitable for managing smaller projects that require a higher level of assurance.
While the concept of the strong PMO had been created as a programme management office supporting joint, cross-organisational management teams for a capital project within built infrastructure, it is scalable to be applied at any project level.
The differences seem subtle; while its strength lies in protecting assets early, the concept is equally applicable to a large multi-year programme of change or a smaller IT project. To come to full effect, it is more likely to attract projects of a novel nature with complex risk profiles, e.g., those driven by restrictions, an unfamiliar and ambitious scope, the scale of the scheme, a larger number of interfaces, or political and public attention.
What Makes a Strong PMO?
This proposed "project-to-programme management office" receives its strength through effective planning and controls closely embedded in the organisational structure. The core roles of the management office are:
- Head of PMO;
- Risk lead;
- Change control lead;
- Governance/reporting lead;
- Quality assurance lead; and
- Planning lead.
These are recognised as standard components of project management. Special focus is put on the following functions:
- Document management. An agreed hierarchy of documents adhering to standards such as building information modelling (BIM), remnant of the capital project origin of this concept;
- Configuration management. This is needed to track and protect the status of interlinked assets in or between projects and programmes, or of a multi-faceted IT deployment;
- Stakeholder management. The management of interface, likely driven by a strong need for governance across contractors and suppliers, diverse audiences and complex dependencies; and
- Communication management. Considering varied audiences, communication by government offices or simply managing complex change in an organisation.
The centre of this concept is in planning, control and the use of distinct stages in a project. Ultimately, planners link into the PMO controlling functions, to ensure that scheduling, governance and change is under full guidance at all times and the protocols adopted. The approach to integrated control functions, ultimately making it a strong PMO, is threefold:
- Contractual integration of contractors and subcontracts, or simply suppliers, by defined requirements and key performance indicators (KPI), with systems focus and spot audits of plans and controls;
- Configuration states required by critical stages; e.g. a limited prototype or pilot is used to de-risk, test, refine, measure progress and ensure maturity;
- A stage assurance team ensures quality products at gates, with all PMO controls in place; e.g. comparing contractor plans with a baseline programme plan or comparing a supplier's delivered software feature against specification.
What does this mean? In order to integrate controls in the project or programme structure, a conventional PMO is proposed (the roles mentioned previously).
A classical PMO will support potentially distributed teams; develop, deploy and embed project or programme management processes, standards and tools; and ensure that the latter are consistently and rigorously applied across the project or programme.
This concept is then fortified with focus on functions of higher importance; plus additional integration and configuration features are added too.
Finally, the concept is strengthened further by proposing the use of a new specific stage assurance team, running in parallel to the PMO and situated in approved stages. While this team of two controls "plan, measure, recover" through the cycle of getting through each gate, the stage manager is always at the most critical point of this three-tick-cycle, while the stage controller is one tick ahead or one behind, depending on how far through the stage we are.
The extra cost of the additional resources is justified by the interface and stakeholder-driven complexity of the project or programme in question, likely requiring strong controls and tailored status reporting for continued stakeholder engagement. This concept as proposed ensures that a holistic project or programme view is in place and appropriate controls are fully integrated and aligned between the PMO and the design and build contractors in a capital project or suppliers in an IT project.
The other important aspect is the appropriate staging of the project, ultimately related to the focus on planning structure, enabling effective scheduling and resourcing, and milestone and baseline reporting. A traditional stage gate approach will be used to enforce project assurance, with gates having agreed criteria, to be satisfied before moving on to the next stage, and to ensure a successful integration of governance covering all stakeholders.
The need for stages is expressed in the simple truth that nobody has managed "to eat the elephant whole." While it is necessary to break even simple projects into manageable parts, a staged approach simplifies the all-important scheduling of any project.
The stage assurance team is in place to monitor and control the PMO and potentially any other managing or delivering stakeholder. As an example, it will ensure integrated planning starts by creating a work breakdown structure with meaningful criteria (asset class in infrastructure or hardware and software in IT delivery projects), followed by estimating and scheduling the work in such a way that the design and build contractor or IT supplier is fully integrated.
A clear hierarchy of plans will provide the baseline on which financial tracking and change control are based and offer a communication tool to demonstrate progress and communicate this across third-party delivery teams.
Governance is closely linked to scheduling and will include regular steering group meetings and tailored project management processes, emphasising the scalability of a strong PMO.
What Else Is Needed?
Clearly stated client requirements, as well as agreed deliverables and milestones, are crucial and will require selective use of configuration states (to reduce risk, ensure maturity and integration between projects or even work streams) and tight change controls as well as quality standards.
Freezing and pinning down the state of a configuration is a straightforward way of assessing its status and measuring readiness during a time range (prototype) or any given point in time (pilot series). This puts the configuration state rather close to a timebox as it is known in agile methodologies.
Fixing time and cost comes naturally when turning the project triangle on its head; and for agile project management this is prominently exercised in DSDM Atern.
Bringing agility to a strong PMO comes with its own challenges, especially if there is little maturity and a lack of trust in substituting documentation for collaboration (i.e. the favourable "people over process" principle). Under such circumstances measurement is key, not just through configuration management, but by defining a radical baseline through agreed document hierarchy with an almost fixed or frozen scope.
The intervening stages of design and passing into build will be carefully monitored by the PMO, while it is being monitored by the stage assurance team. The strong PMO with all three constraints constrained may have lost the valued reader. However, while these lines were written, this concept is applied to an IT delivery project of moderate-to-medium complexity with little time left, restricted resources and an immovable launch date. Needless to say, a notably down-scaled version of the strong PMO is being used.
Whether this appears sensible or not, it becomes obvious why the right KPIs are the key to success; integrating control plans and document schedules will be the decisive factor.
For example, having delivered 86 per cent of the solution may seem on schedule, but is contra-indicated if there is a 10 percent failure rate of designs against solution requirements.
In addition, project governance will have to outline clearly the exception process where a project or work package exceeds the slippage tolerances.
Performance is measured by a combined product view and focus on how the PMO is delivering. This is achieved by starting with high-level product objectives, such as functionality or availability, which encompass benefits of a fully functioning solution. To include project health, KPIs are mapped against core project attributes: scope, quality, time and cost.
Additionally, softer KPIs should be included, for example, stakeholder engagement. When planning stages through requirements and broken down product descriptions, estimating techniques are used to get to an adequate forecast and realistic scheduling. Selective configuration states are used in later stages to refine forecasting along the way and to keep close control of delivery. Since this method always starts with the final outcomes, benefits are managed simultaneously.
Having discussed systems and concepts, let us examine what personnel is required to make up a strong PMO.
Needless to say, they must have good analytical competency, the ability to work with other organisations or at least the confidence to hold two-way communication with stakeholders; in case the "P" stands for programme, they need a strategic grasp of how the various projects support the overall programme goal; and they have to be able to maintain clear governance at all levels and across interfaces and organisations.
Depending on complexity, extended capability is needed to assess and control impact of risks and changes (through configuration management and change control). The critical stage assurance team competency is the ability to challenge project managers and to think in terms of end-states. The planning and control personnel will need to deliver the necessary policies (including approval standard, responsibilities and accountability) and tools (including requirements gathering, templates and standards) in order to set the function up and to run and maintain it for the duration of the project or programme.
This is a reminder that "strong PMO" in this context does not refer to an embedded authority on how to run projects within an organisation, but the actual organisation of running any programme or parts of it.
A strong control strategy for the PMO is crucial to assure the required holistic view across all areas, spanning from organisation, planning and integration to control, measurement and reporting. Given the origin of the concept but minding the alleged scalability, this strong PMO critically has to ensure that all stakeholders are bought-in and committed. The larger the variety of stakeholders and external interfaces, the greater the need to cater for different groups with different expectations and communication requirements that have to be appraised at all times.
The classical concept of change management comes to mind. For these reasons, the proposed concept of a strong PMO, introducing an encompassing stage assurance team, furnishes increased visibility of performance and reporting, both internally and externally, which is required during the whole life, whether it is the life of a programme, capital project or IT project.
Thanks go to Lawrence Rowland who co-developed elements of the "strong PMO," though opinions expressed are the author's own. Thanks go to the British Computer Society who have kindly published this article in ITNOW. The Magazine for the IT Professional 56 (2). Summer 2014 (Special edition project management): pages 12-14. Permission for reuse in Pcubed Insight has been granted by Oxford University Press.