Lisa J Douglas

 A SUBJECT PROJECT HEALTH METRIC

Background. Project teams at Mile Two, a software consultancy, work in highly collaborative groups. Researchers, designers, software engineers, as well as project leads and QA all share work from day one. Teams engage in common collaboration sessions several times a week and contribute artifacts and expertise to a project. Frequent reflection is essential, as it can be difficult to understand changes to team performance in the moment and at a larger organizational scale, especially when teams are expected to adapt to unique evolving pressures and opportunities.

Standard, quantitative project metrics (velocity, burn rate) do not include all of the factors relevant to project success. A team’s ability to promptly recognize, understand, and respond to changes to their project and their team performance impact that success. This proficiency is essential when teams are adapting to dynamic pressures, conflicts, and opportunities. However, project teams can struggle to notice or reflect on the changes that impact progress. In response to these needs, I led a team to develop a lightweight, subjective project health measurement tool to help teams to regularly measure, reflect, and act on five defined dimensions of project health.

Goals and dimensions. Our goals for the tool include 1) improved organizational communication about project status, 2) quicker identification of risk, and 3) quantification and comparison of measures over time.  

The five dimensions of the project health measurement tool currently are:

Team dynamics is the measure of the team’s pro-social behavior and interactions between team members. 

Research and design artifact fidelity is a measure of the level of understanding, comprehensiveness, and detail for artifacts that reflect the team’s understanding of the users’ cognitive work and the work domain. Intentionally increasing fidelity at a deliberate pace is critical to success.

Software fidelity is a measure of the scope and maturation of code. For our teams, code is, among other things, an artifact to elicit feedback. As such, they aim for lower fidelity early in a project. High quality code takes time, and committing too early is typically a time sink.

Project resilience is a measure of the ability of teams to adapt to change and cope with complexity. This considers how the team addresses surprises, responses to dynamic workload demands, and methods of coping with complexity. 

Customer satisfaction measures the team’s perception of how well they are meeting the customer’s expectations. 

Results. Project and tech leads regularly use our tool to find alignment and discover areas of discrepancy, which indicate opportunities for discussion with the team and others. The tool aims to promote transparent communication within the team as a system, rather than assign blame for certain actions. Overall, our organization is successful in bringing together multiple perspectives on a project team to collaboratively measure their progress in project work and the evolution of this tool positively indicates value and records the growth of our project teams. From our early findings, we are addressing areas for improvement to mitigate potential sources of bias in under or over-reporting, increase contextual understanding, and iterate on our visualizations to support the goals of our project health tool. This process has also been shared at several conferences.