(This post contains affiliate links. Read my full disclosure.)
Projects ideally sit within a governance framework that is bigger than the project team. It’s actually easier to work in an environment where there is governance in place because it gives you boundaries. And, like toddlers, people respond well when they know how far they can go.
But what does governance on projects actually look like? Here are 7 factors that make up good governance. How many of these do you have on your project?
In this article:
1. You have a sponsor
A good governance model requires every project to have a project sponsor and while you read about sponsorship all the time on blogs like these in reality I still come across people who don’t know who their sponsor is.
A sponsor should be appointed during the very early days of the project. He or she is responsible for the business case. When the project is approved they are the people responsible for finding the resources and setting the vision for the team.
They also are the main risk-taker and decision-maker on the project so it’s important to have them around.
2. You have a plan
Every project requires a plan and that’s more than a Gantt chart. The project management plan is the responsibility of the project manager, although everyone in the team will end up having input to it.
It’s made up of lots of sub-plans that cover how you are going to manage project quality, risk, change, resources, and so on, so it’s the foundations for the governance and structure for the work.
If you have worked on projects before then it’s highly likely that you can copy and paste from previous documents so don’t get too hung up on the idea that a fully-fledged plan is going to be days worth of work for your tiny project.
We recommend: Project Management Plan Template
3. You have clear reporting
Clearly defined reporting is an important governance element because it’s reports that tell the steering group what is going on. As the key decision-making group, they need enough information to be able to make the right decisions without being bogged down in the detail.
Doing this part of governance is most likely in your project manager job description: it’s such an important part of the role.
You’ll probably end up with a number of different types of reports going to different audiences: project reports, budget reports, briefings to senior managers, and others that you do on an ad hoc basis.
We recommend: Project Status Report Template
A common structure and templates for your reports make the governance element easier because it aids comparison between projects. Again, reuse documents that you have already produced to streamline the effort and ask around to see if your PMO or colleagues have templates that you can use.
4. Your stakeholders are engaged
Let’s recap: stakeholders are anyone affected by, participating in, or impacted by the project.
Engaged stakeholders – how does that fit into governance? Well, without having stakeholders who are participative you might miss issues. Engaged stakeholders are willing to raise problems and they do the actions that are assigned to them, whether they are the Chief Exec or a frontline staff member.
The more engaged the stakeholder community, the easier it is to do the work on the project – trust me, that’s experience speaking on that one! The stakeholders can be your eyes and ears: they listen out for what’s troubling end users, they report back on potential problems before they happen, they bring their subject matter expertise to thorny issues and they support you and the project team.
Knowing you’ve got a great group out there identifying risks and making sure that your end result is fit for purpose is a great way to boost the informal aspects of governance on the project.
5. You manage lessons learned
I mean really manage them – not just capture them in a post-implementation document and then file them away where no other project managers can find them.
Lessons learned feed into governance because it shows you have a culture of continuous improvement. How frustrating is it to make a mistake and then have someone say: “Oh yes, that happened to me last time!”
Why didn’t they just warn you first and save the company a pile of money and you from some headaches?
Embedded lessons learned can be a large change to the culture if you don’t do it already but sharing lessons between projects is a good way to improve the culture of delivery and project governance overall.
If your company doesn’t do lessons learned in a structured, corporate way, look at what you can do to build it into your project team meetings so that at least within your team you are sharing your successes and ‘could do betters’.
We recommend: Lessons Learned Meeting Minutes Template
6. You have clear roles and responsibilities
This takes us back to the toddler analogy. Knowing what you are responsible for and what your colleagues are responsible for doesn’t mean that you end up all being jobsworthy.
You can still pitch in and help get the work done when necessary, but day-to-day you aren’t treading on each other’s toes because you don’t know where the boundaries are.
At best, poorly defined roles and responsibilities on the project team results in miscommunication and duplicating effort because you don’t know who to talk to and you might end up doing a task that someone else believes is their job.
At worst, unclear responsibilities mean that no one really gets on with anything, and the project stalls as no one knows who is supposed to be doing what.
This is very easy to fix and to put in place if you don’t have it set up already. Set up a Terms of Reference for the project or include a section on roles and responsibilities for the team members in the Project Charter or Initiation Document. You could also write it into your resource management plan if you felt it fits better there.
It doesn’t really matter where it goes, or whether it’s in writing at all. The point is that people know their roles and who to ask for other things.
We recommend: Stakeholder Roles and Responsibilities Template
7. Projects are stopped when they need to be stopped
Projects that serve no purpose are soul-destroying places. You know that there isn’t any point in delivering what you are going to deliver, but because no one has the courage to stop the project you all lumber on towards the finish line.
What a waste of time and resources.
Projects should be stopped when they can no longer be justified. That’s the point of gate reviews (or stage reviews, or whatever you call them in your company).
You and your sponsor review the project’s progress and what it can now realistically achieve against the stated benefits in the business case and make the decision: is it worth carrying on?
If it isn’t, the project sponsor will make the call to close the work down.
Read next: A Guide to Project Closure
Your next steps
These 7 factors will help you build a good governance structure on your projects. If you don’t identify with them, ask yourself if there is anything you can do to start bringing these practices into your project.
Here are some actions to get started:
- Book project board meetings (or steering group meetings if you use that term)
- Book one-to-one conversations with your project sponsor
- Talk to the PMO about a standard project reporting template
- Book a lessons learned meeting
- Revisit your roles and responsibilities, or create a document that sets them out if you don’t already have one for the team.
I’ve rounded up a list of my recommended project governance books.
An older version of this article first appeared on the 2080 blog in 2016.
Pin for later reading