The following checklist will help you to quickly get to grips with the status of any project, covering all the main themes.
In this blog post we’re going to share some of the fundamentals that we look for when we’re appraising projects. We’ve presented these ideas in a really simple mnemonic style using the word “PROJECTS” to make it easy for you to remember and fast for you to use.
For example, if you find yourself in a meeting with a project team and you want to ask some searching project health check questions then just remember PROJECTS. If you’re a small business owner and you want to use a project health check to ensure that you or your team have got all the bases covered, then just remember PROJECTS. Finally, if you’re a project manager or working on a project then make sure you can give clear answers to any questions that might arise from people running a project health check by remembering PROJECTS.
PROJECTS stands for:
1. Plan
The first thing that we always look for in a project health check is a plan. Without a plan there’s a serious risk that people will ‘make it up as they go along’. There is a huge amount of evidence to show that when this kind of behaviour occurs that deadlines are more likely to be missed, budgets tend to overrun, and whatever is being delivered is less likely to be fit for purpose.
Even if a project is using an ‘agile’ approach there should still be some sort of plan, perhaps describing phases, the number of anticipated iterations, which resources will be working on the project and when. Agile is not an excuse for a lack of planning.
2. RAID
RAID stands for Stands for Risks, Assumptions, Issues and Dependencies.
- Risks are things that could go wrong, but haven’t gone wrong yet.
- Issues are things that have gone wrong, and probably need sorting out.
- Assumptions are things that we assume will be true in the future, for example that we will have all the people we need to deliver a project. Assumptions are most often made when plans are being drawn up.
- Dependencies are a bit more specific than assumptions. They describe particular tasks that need to be completed to ensure the success of something else.
When we run a project health check we expect that a good project manager should have a clear and up-to-date RAID log. In each case, the log should describe the item, its impact, and explain what is being done to manage it.
3. Objectives
Confusion over why a project is being run is a surprisingly common project health check finding. In the rush to deliver the project objectives are sometimes never clearly defined.
Don’t assume that it’s only project stakeholders who get confused. Even within project teams confusion can exist.
When everyone is clear on the reasons why a project is being run they can all ‘pull in the same direction’. When a project health check uncovers this kind of issue it can be incredibly beneficial.
4. Justification
Projects are like little businesses. They have costs. They should deliver a quantifiable benefit. As long as the benefit is greater than the cost then there is a justifiable (profitable) reason for running the project. This is sometimes called the project business case.
This step in the project health check says that if the project business case no longer stacks up then the project should be stopped because it means that money is being thrown away.
Sometimes it’s hard to precisely calculate project benefits. When this is the case estimates should be used and we would expect to find a risk listed in the RAID log.
5. Executive
One of the most often cited reasons for the failure of larger projects is a lack of support from senior managers.
Sometimes called the executive, or sponsor, there should be someone who is ultimately responsible for securing funding for a project, ensuring continued focus on objectives, and that the project remains justified.
The executive should champion the efforts of the project team, but also hold the project team to account.
When we run a project health check we, regardless of size, we always ask who the executive is, and find out how engaged they are.
6. Control
One of my favourite business quotes is from Peter Drucker, who says, “What gets measured gets managed.”
Projects should always have some sort of reporting mechanism, and our project health check searches for this. Even if you’re a one-man-band small business then try to spend a bit of time stepping back from the detail and looking at the bigger picture.
In larger projects ask about reports and progress meetings. Project teams should always be accountable to someone. Things can and do go wrong when project teams are allowed to ‘mark their own homework’.
7. Team
Projects often involve bringing people with different skills together. Key project health check questions here include checking whether the project team have access to the number of people they need, and people with the skills needed to complete the job.
It can also be useful to investigate levels of motivation and leadership of the project team.
8. Scope
Scope defines what a project will, and won’t do.
Say the project was originally supposed to deliver X, but it ended up delivering X + Y, or even Y + Z. We call this scope creep.
When scope is clearly defined and well understood the project has a far better chance of delivering on time, budget and to specification. Where scope is poorly defined expect to find missed milestones, budget overspend and upset people. This is a key project health check test.
