Understanding Project Health and Its Importance For a Successful Product
![]()
The SK Project Management Team
Red… Yellow… Green are more than just colors on the color wheel or signals to stop, slow down, or go on a traffic light. In the Project Management world, these colors signify if a project is progressing well or NOT! In most organizations, red indicates a project is on fire. Yellow, means that there’s something going on that requires more attention. AND, green… all things are manageable and nothing to be alarmed about. Let’s just keep it real… Project Health is not rocket science, but it does play a critical role in assessing if a project is likely to succeed. Let’s continue to keep this simple by following three basic rules of assessing project health.
Related: Agile Development: Defined, Explored Applied
Rule # 1 – Use Risk Management
First, let’s define risk so we are all speaking the same language. A risk is any unwanted event or situation that could lead to the failure of your project or a significant impact to the project constraints. There are different types of risks, and most can be controlled by implementing a risk management framework. This framework is an approach in which risks are identified, analyzed, and mitigated. Risk management is an action plan that consists of various steps to ensure the removal of risk or minimize the impact of uncontrollable risks. It is an essential part of project management and when done effectively leads to more successful projects. If your organization has yet to introduce a risk management framework, I highly recommend you do it as soon as possible. Otherwise, risks could easily escalate to a crisis if not properly monitored and controlled.
Rule # 2 – Communication is the Key
Another meeting? No way! Meeting aimlessly is not the ideal way to fix a problem when the project success is in jeopardy, BUT communicating often and as frequently as necessary is paramount to getting the project back in good health. It is often a misconception that communication is a distraction from action. I beg to differ! Communication is the glue to action, and without it, people tend to work in silos. Then, efficiency and productivity wavers causing redundancy and waste with no clear path of completion or understanding of ownership. The project can become chaotic with everyone doing their own thing. Even if a project is in GREEN (good standing), it’s still necessary to have a pulse on the project health. Some things may seem low priority to one and significant to another. Communication keeps everyone aligned on the goals, risks, issues, and next steps.
Rule # 3 – Know Your Escalation Path
There’s nothing worse than to be advised of an emergency during “the emergency.” This causes unnecessary panic, lack of preparation and disorients the person(s) of the purpose or goal at hand. Throughout the project, individuals involved in the escalation path should be aware/notified of the project health. The details of any risks or issues will increase as the need-to-know increases. Basically, if you are not a person that cannot resolve the project issue or assist with mitigating the risk then it is likely you do not need to know any details. If you are likely to be called on to assist, you should have enough knowledge of the issue or risk in real-time to start triage. The escalation path should only be used if it significantly impacts the project constraints. Constraints can involve the triple threat: time, costs, scope or any of the others (stakeholders, resources, quality, communication, procurement, risk).
It’s important to know when and how to use the escalation path in your organization. For example, let’s say the project has a new milestone that must be met that was unknown at project initiation. This is a “LOW” risk, but it should be monitored closely. If it looks like the risk is going to increase in severity then it should be managed by the project manager and lead who should notify those designated in the escalation path of the potential of this risk. We all have our responsibilities and we cannot be everywhere, every time a problem occurs. Therefore, the escalation path is an opportunity to inform, collaborate, and resolve with a key decision maker or project owner(s) or sponsor(s). They should not be bogged down with small crises that should remain at the project team level unless absolutely necessary.
Conclusion
Here at stable|kernel one of our company imperatives is We Build This Company Together. Transparency in what is going on around the company is a solid way to embody this imperative. We keep everyone updated on the status of each project weekly. In addition, this an opportunity to celebrate our wins and be mindful of any shortcomings. The primary goal is to provide our partners and clients with the highest quality product built from a team that believes in solution-oriented development.
