IT project sniff test: how to tell the health of a project
The Deming cycle–Plan, Do, Check, and Act/Adjust–is only four steps, but in many organization’s we’re lucky if we have both “Plan” and “Do.” Especially in project management, we may select a project and begin running it but not check back to see whether the project’s going well. The PMBOK calls this checking the “Monitoring & Controlling” phase of a project.
So, to that end, here are a few simple ways that you can check in on the health of a project.
When was the last project update?
Hopefully you have some mechanism to record project status updates. This could be a weekly message from the project manager or even a report-out in a standing meeting. When was the last time you heard an update?
The UNIX maxim “no news is good news” does not apply to project management. Lack of update can indicate that a project manager or the project team does not have time to work on the project, or they’re stuck and are quietly trying to get unstuck before anyone notices.
Can you tell when the project is done?
Is there a mechanism to validate when the project is done? This could be a charter, for example. However, you must ask the project team to know for sure: sometimes people pay lip service to a charter while acting under a different scope. If the answer is, “we know we’re done when we see it,” that’s a sign the project will never end–or that you’ll get stuck doing work that’s very low marginal benefit for the cost.
Is there a project sponsor?
Does the project have someone who’s actively championing it? The project sponsor should have a high rank in the organization; they are not the project manager, but they’re the person who will “go to bat” for the project as it has issues. If a project isn’t important enough to have a project sponsor, it’s probably not important enough to be done right now.
Are the project’s zones of control in balance?
Roles are a combination of accountability, responsibilities, and authorities. Projects have to invent roles all the time, as they are by definition covering uncharted territory. If a role is out-of-balance, then people may be responsible for doing something that they have no authority to do: designing a network without having any authority to see the network budget, for example. When zones of control are out-of-balance, project team members will feel panicked, or possibly resigned to the fact that they have no control over their destiny.
Is someone checking with users/beneficiaries of the project?
Is there some process or mechanism to check with the users or beneficiaries who will receive whatever the project is creating? This process can help ground the project and ensure that the outcomes will really be helpful.
Ideally, there are regular milestones in the project that can be reviewed to ensure that the project is still on track.
Are appropriate–and only appropriate–project management processes being used?
Project management includes many processes such as risk management, quality management, and stakeholder management. Depending on a project, you may need very different processes. A project involving many vendors, for example, will need robust procurement management. A project where team members are new to the technology may require HR management, for example to create a defined training process.
People who have less experience with project management, however, may do too much project management, or they may hyper-focus on one area. For example, many people hyper-focus on project task and schedule management and try to understand dependencies and time estimates. That’s great, but if you don’t have good project scope management then you can throw your project schedule out the window: tasks are predicated on an understanding of scope.
In higher education, many times project risk management is one of the biggest “bangs for your buck.” When you canvass your project team, you can learn about all kinds of risks that may impact your project. The process helps you learn about “unknown unknowns”–and one unknown unknown, such as a potential leadership change or budget crisis can derail the entire project.
Using the wrong processes, too many processes, or focusing too much on one process at the expense of others can waste the project team’s time and lead to a false sense of control.
What is the project’s current end date vs. its original target? How many times has it slipped?
The more times a project end date has slipped, the more likely that the project is being managed “as things come up.” That’s not necessarily a bad thing, depending on how important time is to the project, and there can be valid reasons for a project end date change such as an authorized scope change. But slipping end dates are a sign that the project may not be under control.