Track project health
Custom software is rarely shipped without turbulence mid-flight. The best teams identify risks, escalate them, and pivot course before they become an issue. Project health reports (PHRs) document the project status keeping the managing director, the squad lead, and Devbridge management informed on the latest status. PHRs are tracked in Jira and allow both the MD and the SL to align on the project state.
The Jira Kanban board shows projects that are in flight as well as complete, with statuses of green, yellow, and red.
The PHR facilitates a conversation inside the team on an ongoing basis; if alignment cannot be reached there, it escalates to the weekly sync meeting between the squad lead and the managing director.
Be transparent and take ownership. Even if there are obstacles, remember that the future of that account depends not only on the software that ships but also on individual behavior when encountering failure. Be part of the solution. Do not prolong the problem. From tracking time to the PowerUp app to the sprint reports, all these tools build trust and alignment.
Green keeps rolling
This is the ideal state. These projects are flying smooth. They do not have any active risks, are on budget, and have a scope-completed percentage that is greater than or equal to the budget-spent percentage.
Amber and red need attention
These projects require active steps to be taken to right the course. Amber indicates a level of uncertainty and risk. Red indicates failure to deliver on time, conflict, escalations, performance issues, and the like.
To address issues and get green, take the following actions:
- The team first creates a risk under the project and assigns it to a team member.
- The assigned team member then sets the risk’s status as “identified.”
- Once the team member is working on the risk, its status changes to “addressing.”
- When the risk is minimized to the point that no action is needed, its status is set to “closed.”
Sprint-based reports
Teams produce sprint reports that are delivered to the client during the demo at the end of a sprint. The objective of these reports is to communicate the state of the project, any potential risks, necessary countermeasures, and any other dependencies that should be addressed.
When discussing these reports with the client, compare them to the reports from the past three sprints. Identify scope changes. Determine whether there is consistency in the estimation and commitment to sprint stories, and whether the backlog has decreased or continued to grow. The release burn-up chart should indicate scope change over time; a smart team detects patterns and communicates potential risks to the timeline and funding. This is also an opportunity to review the alignment of work completed with spend to date. Hopefully, this review indicates a positive trend with the release finished on time and under budget.
If the release burn up is not trending in the right way based on the desired go-to-market date—if stories aren’t closing or if the velocity is lower than expected—then this is an opportunity to figure out why and right the course.
A report is only part of the story that can be interpreted incorrectly without context. Make sure to present and facilitate a conversation around the captured metrics.
