"What you don't know hurts you" the role of Governance & Control
Intro
In my final article of this series, I would like to share some observations on the role of effective governance in project or programme success. The term “Governance” carries negative overtones of big brother and bureaucracy which are seen as an anathema to modern ideas of Agile and flexible delivery. Consequently, it is not an area of project delivery that many people understand or focus on, however I would like to present a case that supports how effective governance can act as the glue that brings strong leadership, good planning, and great people together into successful project delivery.
What is governance?
At its simplest level Project Governance is a framework that defines the authority and accountabilities to control the outputs, outcomes, and benefits from a project, programme or portfolio. Governance is the mechanism whereby project sponsors exercise control over the deployment and realisation of benefits. It’s a two-way street, where decisions flow down from the sponsors through the project structure, and information flows up to allow decisions to be made in a timely manner so that the plan can be delivered on time.
So much for definitions, the trick however is to be clear at what level decisions need to be taken, and what level of information is required to support them. Micromanaging delivery from the top can be as detrimental to success as having a free for all with no controls at all. Therefore developing the right balance of project control v accountability and freedom to operate is crucial.
How to control the project and when
So effective governance is all about balancing the need to control v freedom to operate. This balance changes during the lifecycle of a project, therefore governance. Is not a static mechanism but one that evolves. I have found the best way to reflect this in projects is to formally recognise the different stages of a project and reflect them in the design and approach of the governance framework.
Project Stages
Although the definitions can vary, all projects or programmes go through the same basic lifecycle from Initiation, to planning, then execution & monitoring, and finally closure. Each of these stages has defined outcomes that need to be approved before the project moves onto the next stage. These are important control points or gates that need to be strictly enforced. Many times I have seen projects go from the idea stage, straight into execution in the mistaken belief that this will deliver speed. However often these initiatives flounder due to unclear scope or a badly developed plan. Delays in the execution stage are a big problem because project teams are fully mobilised with a high burn rate and re-work or re-planning is wasteful and expensive. It is always better to complete initiation and planning before execution, because it reduces the risks during execution and also allows project sponsors to endorse the desired outcomes, agree the scope and commit to the plan with its resource requirements before the heavy lifting starts.
A well-defined and governed project, therefore, recognises these gates and has formal documents as control points for each one:
1. Project Initiation:
This is the start of the project, and the goal of this phase is to define the project at a broad level. Ideally, the potential project sponsor should draw up a simple Mandate to start this phase outlining the idea behind the initiative and what basic information exists including things like broad objectives, assumptions, and known constraints. Based on the mandate, work is undertaken to develop more detail around the scope and deliverables, high-level planning (Roadmap), and a simplified business case. These elements go into a project Brief that the sponsors should use to approve the potential of the project and the resources to go into detailed planning.
2. Planning:
This stage is often overlooked. Keen project managers can bung in so much information in the project brief that they feel prepared and ready to go straight into execution. Whilst I’m all for detail, too much investment during initiation can be wasteful because at this stage it is still likely that the project might not get approval. In this case, the effort would have been wasted. In my experience, it’s better to focus initiation on developing the scope, deliverables, and high-level business case, and leave the detailed planning for after the sponsors have conditionally approved the viability of the project. The control document for this stage is called a PID or PDD and should contain a more comprehensive overall plan and a detailed schedule for the first execution phase. To do this a lot more detail will need to be developed around the scope, delivery approach (including the project organisation and use of third parties), constraints, dependencies, and risks. This in turn will allow a more comprehensive business case to be developed.
The PID is probably the most important document the project will develop and should be used by the project board to approve the project and allow execution to commence. The challenge is to get the project board to read and understand it (see my article on strong leadership), and I have seen many projects produce these documents, put them in a drawer, and use some glossy presentation as the formal gate control. This approach can come back to bite you as project risks, dependencies and scope start to be challenged during delivery. It’s painful, but successful projects need to educate their boards on the details in the PID and the document needs to be kept current and alive during delivery. It is after all the contract between the project and the sponsoring board and will need to be referred to throughout the life of the project especially if there are disputes.
3. Execution:
Another important part of the PID is defining the control environment for the project during execution. This includes defining decision levels and tolerances, the stages of execution, risk, and issue management, and the quality plan including assurance. This in turn helps define the project organisation including where the work gets done, by whom, and how it is controlled. The management of this framework on a day-to-day basis sets the tone for the project, operationalises the control and empowerment balance, which is important to overall success.
Controlling delivery
Once the project is in execution the Project Manager must take control of day-to-day actions and manage the project. Key decisions include: populating the project organisation with the right people, allocating work, monitoring progress, ensuring the quality of delivery, and keeping on top of the plan and budget/resources. The PM also has to keep the sponsors in the loop on the progress and escalate exceptions and decisions when required. Practically this is done through the dreaded highlight reporting process and also holding regular checkpoint meetings.
Checkpoint meetings can take many forms. I have seen the whole range from daily 30 min stand-ups, through to monthly 6-hour torture sessions and in some cases both at the same time! There is no right or wrong approach and in fact, the frequency and composition of these meetings should change as the needs of the project evolve. What is important is that the approach is clearly defined in the PID, with associated decision rights and that a rhythm is established. The checkpoint, stages, and plan become the drumbeat of the project that acts as an anchor for everything else.
What should you discuss at a checkpoint? As a minimum, each checkpoint should cover the basics which include:
- An update on progress
- A forward look at the overall schedule for the project or workstream in question
- A look at the budget and resources burn rate
- Quality and scope updates, plus and issues or emerging risks.
- The meeting should end with an agreement on actions the next steps on the project (the priorities) until the next checkpoint.
It’s important to allocate more time looking forward than a post-mortem of past misdeeds. Whilst lessons learned are crucial, it’s better to anticipate and therefore avoid mistakes rather than go over them in gory detail.
Checkpoint frequency and whether there are multiple and different meetings in a project is largely determined by the complexity and size of the project organisation. What is important is that these meetings cover the point mentioned but do not overlap with each other. There is nothing worse than a workstream checkpoint making a decision, only to have to debated and reviewed somewhere else. This breeds frustration, project politics, and delays in execution. This is why it is crucial to define the decision rights for each of these meetings and to have a formal escalation process with the project if it is required.
By their nature project managers tend to be on the control freak spectrum, therefore care needs to be taken to ensure there is an effective balance between the need for communication and control against too much management interference in the work. In addition, there is always a tendency to invite everyone to these meetings. Alignment across workstreams and the project is important but having 20 plus people in a meeting with only 2 talking is not very efficient. Alignment and communication should be managed in a different way.
How Checkpoints should work
Checkpoint meetings are the drumbeat of the project and define the overall tone of how it works. Therefore getting the organisation and management right is important. Too many times I have seen these meetings turn into car crashes because the basics are not followed. All checkpoints should have:
A defined agenda – before the meeting starts with time for preparation.
Prepared participants with balanced input from the team.
Great time management to get through the agenda and finish on time.
Focussed discussions to remain on topic and not veer off onto today's favourite topic.
Clear actions including review of previous ones and agreement on the ones developed during the meeting.
Things to avoid:
The Adhoc assembly of team members without agendas. These “meetings” lack any sort of structural framework and can therefore easily runs off course with time being wasted. Checkpoint meetings are designed to understand status, so without an agenda, it’s difficult for team members to gather the data that might be required.
Failure to provide the required information wastes time and runs the risk that another meeting might have to be called building frustration.
The marathon slog. Long meetings with people taking turns to drone on about their favourite topic might not be hell, but it seems like it. Poor time management coupled with a failure to control the agenda allows the project gas bags to flourish. These meetings are often not productive and in fact might require more meetings to be scheduled to cover the actual requirements. The impact on morale can’t be underestimated especially as many team members are probably under severe time pressure. When the laptops come out in the meeting and you see people answering eMails when they should be contributing, you know you have a problem.
The Alpha personalities and project wallflowers. Project managers need to manage different personalities on the team. In my article on people, I stressed the importance of team composition, but it can be in the checkpoint meetings where these issues become most problematic. Aggressive personalities tend to dominate project meetings, with the result that their views can skew the opinion of the project manager about what is important. It is vital that a balanced view is obtained from all participants on big issues and it is up to the PM to make sure this happens. This often requires the PM to be both the leader and facilitator to help the group toward its goals by managing the process of the meeting.
Conversely, it is also important that membership of the meeting mandates contribution. The PM should ensure that he or she receives a balanced view on important topics. Whilst facilitation helps, if people do not contribute or attend the meeting because of its status only, they should not be invited.
The hanging action item. Not everything can be resolved at the meeting. Sometimes these action items are only verbalised, which often results in them not being resolved and therefore resurfacing in subsequent meetings. Actions should be accurately logged, and responsibility allocated. They should then be followed up and reviewed at the next meeting. All too often I have seen vague actions allocated to people, which are allowed to fester. Long lists of actions develop which are then “time out” rather than resolved. I once saw an action that sat on the log for two years! This behaviour dilutes the importance of assigning actions and can disguise issues on critical path items. Failure to keep on top of actions can lead to a culture where It becomes easier for team members to dodge their responsibilities by complaining that they didn’t know about the action item, they didn’t understand it, or they didn’t have time to complete it. When action items aren’t completed in a timely manner, project progress is impacted.
4. Closure
So you have taken the project through its lifecycle, by controlling each stage. You have become an expert in man-management and run your checkpoint and stage meetings like clockwork. The project board is eating out of your hand and cheers you every time you make an update. This probably means that you might actually have arrived at the point where the project has delivered. Congratulations because you are one of the 37% who actually gets this far. Tempting as it may to hold a massive party and book a holiday on a beach somewhere, your work is not yet done. Closure needs to be completed and it is also where control and governance play a very important role. It is also in my experience the phase of the project that is usually executed the worst and the one that has a lasting impact even after everyone has moved on.
What should you do in closure?
Closure is a critical governance step where you actually hand over the project and ongoing responsibility to the sponsor. If you do this successfully then you can focus on completing the knowledge assets, disbanding the team, winding down the project drumbeat, and closing out the budget. My article on people covered the importance of managing your organisation, so in this one, I will focus on the governance and control aspects of this stage.
You need to be able to prove what you said you were going to do. This is where the contract or PID comes back into play. The PID is the contract with the board and you need to demonstrate to them that you have met its conditions. This means that the deliverables articulated in the scope have actually happened and that the investment case was achieved. At this stage, it's often difficult to point to benefits as they are often only fully realised after the project or programme is finished. This means that particular attention needs to be invested in the benefits realisation plan. This is where there are governance challenges because you may have to assign responsibility for benefit reporting to another organisation and agree with the project board on how they will monitor its delivery. Most organisations are risk-averse so getting them to accept the responsibility can be hard. If this can’t be achieved, then the project can’t close resulting in additional costs to support the temporary project organisation. IT projects also provide additional challenges as the new capabilities will have to be accepted into business-as-usual support as well. The benefits realisation plan and handover to support processes can’t be left to the last minute. They need to be planned and aligned with stakeholders during the execution stage.
Typical problems I have encountered during Closure are:
The wandering scope. Often project boards tend to focus on scope when the project is coming to an end. Questions are raised along the lines of “this is not what I expected” to “I thought we were going to get this and where is it” This can be minimised if the scope is clearly articulated in the PID and kept alive with the board during execution.
The other common scope problem is the last-minute request. Project Boards like the fact that project teams do stuff and are sometimes reluctant to let them disband. Therefore when closure comes up, they can ask for new things to be delivered. A rigorous change control process and governance are very important to make sure any requests are properly impacted and reflected in project timing and budget or rejected if they are unfeasible.
Disappearing cash benefits. Projects enable outcomes that include savings . Programmes have a wider scope and are outcome focussed. In both cases, however, cash savings mean cutting budgets in the business as usual functions. These budgets are usually built incrementally over time and are not zero-based, therefore savings in one area tend to be adsorbed in cost inflation somewhere else. This can result in a lower reduction in functional budgets which undermines the credibility of the project that claimed it was going to save them. A rigorous benefit realisation plan is necessary to identify the costs saving areas and to track them adopting a zero-base budget approach. Functions can bank these savings and invest them elsewhere, but this needs to be acknowledged and go through the normal resource allocation process.
Quality is relative. Again the PID should have a clearly stated quality and acceptance criteria for the project deliverables. Failure to do so can result in questions been raised about the usability, functionality, and stability of what the project has delivered. This is particularly a problem when deploying new IT systems. I have seen many IT projects delay their closure because the “reliability” of the IT systems did not meet sometimes ill-defined BAU quality criteria. This inevitably leads to a post-closure stabilisation workstream to manage these systems until they reach a level that is acceptable to the BAU support organisation. Whilst this will allow the project to close, it adds to overall costs and also contributes to legacy reputation issues for the project team.
And finally
Don’t forget lessons learned. Time should be set aside in the project throughout all its stages to document lessons learned. These need to be brought together and discussed with the project board and business as usual organisations before closure can be completed. Then you can put them in your memory bank and apply them to the next project – assuming you are up for it after this one!
Conclusion
Over four articles I have attempted to articulate 20+ years of experience in delivering Transformation initiatives. I expanded on my four golden rules for success which were:
1. Make sure you have strong leadership in the business that is committed to the change, willing to make tough decisions, and prepared to stick with the journey.
2. Ensure you have experienced people working on the programme who are motivated in its success.
3. Have a great plan before you start - based on reality and realistic in its ambition.
4. Operate effective governance that keeps connected with all parts of the programme and leadership but allows empowerment in decision-making and flexibility in execution. Focus on risk identification and management rather than micro-management of the plan.
These articles were not intended to be the definitive guide to delivering projects, but a reflection on some of the areas that projects needs to focus on to improve their chances of success. If you found these articles thought-provoking and wish to learn more about the underlying methodology that drives Strategy into Action, please watch this space.