To program or not to program?

As a project director, your aim is always to save, create and ensure. Save money and time, create efficiency and ensure quality. When you work on initiatives at the scale we do here at RPS–projects worth millions or even billions of dollars–a strategy that we use to ensure these value levers (save, create and ensure) are pulling in the right direction is the elevation of individual projects to a nationalised or state-based program of work.

Examples include our work on major programs spanning multiple sites, such as our work with Defence on PFAS investigation and remediation , the Navy Capability Infrastructure Sub Program or the Advancing Clean Energy Schools (ACES) program in Queensland.

Treating individual projects as a collective can deliver benefits across all three value levers:

Save  

• Costs are reduced through economies of scale

• Cashflow can be balanced across multiple projects

• Approvals can be streamlined across multiple projects saving significant time and effort

• Efficiencies are generated for the client by reducing their workload through the engagement of external program and project managers with specialist skills.

Create

• Opportunities to balance and share resources across multiple projects

• Better project outcomes through leveraging opportunities and relationships with other related projects

• Ability to generate data insights from across a program to assist with analytics and decision-making.

Ensure

• Consistent and efficient reporting for better overall insight into status and risk.

• Rigorous safety and environmental management implemented across many small projects.

While combining projects into a program can generate a lot of value, this approach should only be applied under the right circumstances. If done incorrectly, or for the wrong reasons, elevating to a program level can erode our ability to achieve some of the very benefits it is intended to generate.

Here are some of the questions and considerations that we use to evaluate whether to tackle projects individually or collectively in a program management structure.

Test the relationship: what is common, what is unique?

The Standard for Program Management—Second Edition defines a program as ‘a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually’. The likelihood that benefits will be realised is dependent on the strength of the relationship between the individual parts.

• Are there common stakeholders and sponsors?

• Is one project reliant on the delivery of another?

• Are the projects to be delivered at common sites/locations?

• Will combining the design/construction of elements lead to cost savings through integration of functions or economies of scale?

• Do projects have a common funding source or the same resource pool?

• Will each initiative progress through the same approvals process?

If the answer to more than one of these questions is ‘yes’, then consideration should be given to combining the projects into a program. If the answers are mostly ‘no’ then combining into a program may create additional work for no real benefit.

In structure lies strength

Once the decision is made to elevate individual projects to be delivered as a program, another series of questions need to be asked. What structures and mechanisms can be placed around the program to ensure all our levers are working throughout the program lifecycle?

Here are four of the key areas that my team considers when tackling this question for our clients.

Program design and authority

• At what level of the delivery team should the Program Management Office (PMO) function reside?

• Should this stay within the client’s organisation, be contracted to the external client-side project manager (if the same company is appointed across all projects), or be contracted to an independent program manager?

• What role should the PMO ultimately play? Is it a support and guidance mechanism or is it a direction and control body? The answer may be directed by the client and nature of the work. For example, a controlling/directing PMO will have more accountability for individual project outcomes than a PMO that is in more of a guiding role.

Resourcing

• What resourcing is required for the program’s management, and what are the roles and responsibilities of the PMO versus the project management teams?

• How can we ensure roles, responsibilities and capabilities are clearly defined so that the PMO and project teams do not work at cross-purposes and erode our save, create and ensure value levers?

Support systems

• What tools do we need to support the implementation of disciplined program and project controls? A well-delivered program relies on accurate tracking and reporting of each individual project, performance across key measures such as schedule, cost, risk and safety, coordinated and collated at the program level. RPS’ own software tool, myProjects, is being successfully used for this purpose on several programs.

• How can we ensure we have adequate insight across programs that may incorporate projects across many sites or jurisdictions?

Delivery strategies

• How should the works be designed and constructed?

• Can economies of scale and value-for-money be realised by combining design and construction under a single firm/bulk procurement or are project elements too disparate in terms of size, location, type or timeframe?

While there is certainly no ‘one size fits all’ solution to program delivery and management, when we evaluate and ask the right questions at the beginning, combining individual initiatives in a program can offer real benefits for those looking to save money and time, create opportunities and ensure quality.