This article is the fourth in a five part series around successfully delivering step changes in value through a comprehensive view of project / portfolio best practices and organizational change management. To access the other articles in this series, click here.
Governance. A powerful word and theme which immediately instigates thought and discussion. It can sound scary or intimidating. Done well, project governance could be likened to going to the doctor. You can do all the right things, eat well and exercise regularly, but getting an informed, educated and independent perspective can diagnose either minor or major conditions which can improve things tremendously.
It’s all about Risk.
If the other dimensions (People, Process, Technology and Culture) always worked as intended, then there would be no need for governance processes at all. But the world is imperfect, projects are uncertain, and people are human. Governance must start with a discussion around business, project and operational risk.
Are you clear about your organization’s risk appetite? It’s easy to say that you could come up with a framework that works in all circumstances, but having seen many portfolios of thousands of projects, I can certainly tell you that there may be very good reasons for doing things differently - but never a good reason for doing things foolishly. Rushing through study phases can sometimes be appropriate - expensive and risky, but appropriate. The important thing is to accurately communicate the risk of doing the next phase of the project given the level of scope / cost / schedule / economic definition when the decision is being made.
Effective governance should not be about shaming teams into compliance, but teaching project teams on how to ensure the project stays aligned with the company’s values and strategic objectives. Governance should always be a means of demonstrating and reinforcing the culture you want to see.
Decisive Action or Paralysis: The Role of Individual Accountability, Authority, Independent Review & Committee Consensus
The most consistent complaint I hear from Project Managers (in any industry) is not about their teams, their contractors or suppliers, but about their decision-makers. Project sponsors, steering committees, review boards, investment committees, boards of directors, etc. each asking for different things, and with different priorities and perspectives. This is very typical, but doesn’t always have to be painful.
Some advice for project managers:
At the start of each phase, get clear, documented expectations from every individual involved in project governance (functional reviewers, business leaders, customers, stakeholders, operators, sponsors, authorities, etc.) about what they want to see, which processes they expect to be followed, which deliverables they expect, and the level of detail they require.
If something changes through the phase, re-engage with those stakeholders as soon as possible, so they are not surprised by anything when you come to ask for a decision.
Go into any meeting with decision makers with a clear list of the decisions that need to be made today. If they can’t decide, be clear about what information they need to decide. Never be afraid to recommend stopping the project altogether!
Some advice for decision-makers:
Your project manager is not a clairvoyant. If you expect to see something or need a piece of information to make the decision, be clear and say it.
Empower your project manager to be accountable for project delivery, and give them the right level of authority to do this. This is a common root cause of many project delays.
A word about steering committees / consensus-based decision making. It sounds great and inclusive, but this is a convenient way for many decision-makers to pass the buck, and avoid making tough decisions. Use a committee to get broad input and perspective from others, but be clear on the actual means of decision making. Either nominating one accountable person to make decisions (incorporating the input of all), or be clear about a more democratic approach (quorums, voting rights, thresholds, etc.).
Here’s one thing that’s helpful for everyone to remember:
Nobody is an expert in everything.
This is especially true of the person or people making a decision about your project. A wise decision maker listens carefully, speaks respectfully, encourages different opinions, but still acts decisively.
Project Stage Gates - “Doing the Right Projects”
Many organizations involved in capital projects employ a phased / gated (or waterfall) project methodology, as it’s particularly costly and risky to modify the project scope during the execution phase. Certain projects (e.g. software / product development, business change programs, etc.) lend themselves to other methods, such as Agile / Scrum approaches, which utilize a number of iterative “sprints” to deliver projects progressively. This article will focus on the former.
Governance in early phases is really about identifying and stopping bad projects as quickly as possible. Studies have confirmed that >30% or organizational value is lost due to selecting and implementing the wrong projects - so encourage and reward your teams for the value they save by quickly stopping projects which don’t align with the company’s objectives.
Project Proposal / Portfolio Entry
The first gate is surprisingly overlooked by many organizations. This gate is about defining the high-level intent of the project, and classifying it across several dimensions to confirm it’s objectives are broadly aligned with the organization’s strategy, the risk is within acceptable ranges, and the outcomes are likely to be technically and commercially viable. This step is important as it officially joins the portfolio, so it can be continually monitored through it’s lifecycle and included in financial planning processes.
Project Appraisal / Study Phases
These phases go by many names: Pre-FEED, FEED, Detailed Design, Feasibility, Selection, Definition, etc. , but the purpose is clear:
Have you demonstrated that you are clear on the requirements that must be delivered, and have incorporated them into the recommendation?
Have you demonstrated that of all the options that could be studied, there is at least one option that is technically and commercially viable, and aligned with the organization’s strategic objectives?
Have you demonstrated that you have effectively converged on the preferred / selected option using the right combination of informed functional and domain expertise, market conditions, internal / external stakeholders, and have incorporated appropriate considerations for the outstanding levels of risk and uncertainty?
Where does this project rank (cost, schedule, technical, etc.) versus other / similar projects? (i.e. benchmarking)
Before proceeding to any study phase, have the scope, cost and schedule of each phase been sufficiently defined to approve the required level of investment?
Execution Readiness Assessment & Mid-Execution Governance - “Doing Projects Right”
Before spending millions or billions of dollars on a capital investment, it’s important to ensure that all the right planning has been done and the team is ready to execute the project. For major capital projects, this can be quite exhaustive and detailed, but the themes are broadly consistent across all types of projects. It’s helpful to assess these across the five dimensions:
People - Is the team in place? Are there enough resources? Are they qualified? Do they understand their role, responsibilities, accountabilities, authorities (e.g. RACI / RAPID)? Are there plans in place to mitigate and respond to turnover?
Process - Are the project’s processes and procedures sufficiently documented and communicated? Are processes streamlined and correctly fit the contracting / execution strategy?
Technology - Are the project’s systems in place? Is the team trained in their use? Are there any conflicting or duplicate data sets? How are contractors / suppliers providing data?
Governance - How will performance be assessed? How will reports be issued, assessed, and acted upon. How will issues / performance be communicated to decision makers? How will risks / controls be assessed, and contingency be managed?
Culture - Does the entire team feel engaged and confident that the project’s objectives can be met on-time and on-budget? Does the team feel it is safe to speak up and raise concerns and objections? Is there clear evidence of strong 2-way communication at all levels?
The full range of project controls processes, when well applied, can really help a project team keep the project on track throughout execution. Throughout major multi-year projects, it is useful to have regular independent reviews of project performance. To provide an fresh perspective, confirm the accuracy of reports, and highlight opportunities to the project team.
There are so many lessons and best practices that we will explore in other articles. But today, I would like to share a few key points that should really inform governance through Execution:
Baselines are critical to performance management, but they are so frequently overlooked. Execution readiness should include an assessment, validation, and storage of the official project baselines (in all categories: schedule, quantities, cost, etc.).
Projects are certainly subject to significant change, and re-baselining should be treated very seriously, and be scrutinized heavily.
Symptoms of Poor Progress Measurement
Arbitrary Weighting Factors - when weighting factors are arbitrarily assigned to work packages, any semblance of cost performance analysis is destroyed. Earned value principles are very effective when applied correctly.
“Magic Matching & the Infinite S-Curve” - If weekly / monthly progress matches a little too closely with the baseline, take a closer look at how this is being calculated. A bit of deviation is expected, particularly when progress is based on detailed quantities. A typical result of this is for s-curves to match the baseline until the project reports about 90% complete, then the next month 91%, then 91.1%, then 91.2%… when the same level of activity is occurring. This does not mean that performance has fallen off in the last few months. This means that progress was never measured correctly since the beginning of the project.
“Baseline Drift” - When creating portfolio-wide reporting standards for large companies, I created a hidden function which stored the reported baseline every month. At mid-execution performance reviews, I would show the team all of the baselines they have reported since the project began. Barring any approved re-baseline, there should only be one curve showing, but you would be amazed at how the baseline kept changing, to present a more positive situation. This should be treated very seriously, as it’s effectively falsifying critical performance data.
“Miraculous Recovery” - If progress starts falling below the baseline, but the team continues to hold the project end date - the forecast progress curve grows more and more vertical. To achieve this, although the team was earning 2% per month, they now must earn 10% per month to make the end date. This is highly unlikely, and should be scrutinized.
Contingency / Management Reserve / Unallocated Provision, etc.
The subject of contingency is hotly debated in project controls circles, and I could write many paragraphs on best practices related to this, But there are only a few things I would urge from a governance perspective:
Auto-Balancing: Contingency should be representative of an allowance to complete the project given the outstanding level of risk and uncertainty which remains. Just because one work package spent less than it’s budget, this does not make the rest of the project inherently more risky. So “give-backs” to contingency should be discouraged, or even prohibited. It should never be treated as a “balancing account” to artificially hold the project forecast fixed.
Ongoing Contingency Assessment - a healthy project, with a clear view of the outstanding risk and uncertainty should have little trouble in continuously reviewing and assessing the amount of contingency needed to complete the project. To do otherwise is lazy and inaccurate, and will likely result in negative effects to overall cash management across the portfolio.
Project Reporting Effectiveness
Communication Hierarchy - Track the time from when someone first knew about a problem to when a decision-maker found out about it. You would be amazed how often projects started reporting problems at 80% complete, and upon forensic review, we found the real deviation when the project was 20% complete.
Reporting Culture - What kind of cultural considerations / executive behaviors are influencing the way teams report on projects. Are they incentivized to hide the truth until they can’t hide it anymore? If someone reports an underrun, will Finance take their budget away?
Reports Too Long / Too Short - What is the right amount of reporting needed across the project team and to decision-makers / other stakeholders? Many people consider a monthly report as a “management tool”. This is incorrect. Management tools include your schedule, cost reports, risk registers, etc. Monthly reports are “communication tools”, that should tell the story of what has happened, what it means, what the team is doing about it, how well our efforts are working, and what the report audience needs to know, or needs to do. Anything more detailed should just be an automatic summary or filter from one of your real management tools.
Project governance is a broad topic, and there are a variety of opinions out there about what good governance looks like. But having seen many good and bad examples, I can assure you there are some commonalities which separate them. The most important element of good governance is the right project and organizational culture. Establish a clear distinction of roles, but be clear that everyone is on the same team, and interested in the best outcome for the organization.
At ProjectAI we have significant experience in designing, implementing and conducting project governance processes across large enterprise capital and IT portfolios. Please contact us to learn more!
We’d love to hear from you! What are your thoughts on project governance? Do you find that it hurts more often than helps? How do you think it could be better? Leave your comments below.