Five dimensions of software project health
08.02.2025 PermalinkA software project is usually a complex endeavor spanning several months or years, requiring expensive expenditure of human labour. Many aspects are unique: the customer, the product, the composition of specialists, the challenges, chances and risks and so forth.
So it's no wonder that each project follows its own path, makes its own rules, distributes responsibilities in different ways. Many projects may officially adhere to a documented process framework like Scrum or whatever a company has decided to use. But at the operational level, they have to work in their own style.
So how can one judge if a project team is on its way to success or headed into trouble, if adherence to a process framwork (or lack thereof) is no useful indicator?
In order to examine for when a project team needs to review the way it works, I found much benefit in the following five dimensions:
Product Quality
If the product released by the team is in poor shape then something needs to change. Poor quality can manifest itself in frequent occurrence of bugs, change requests that point to fundamental traits, users complaining that their work is hampered, low performance on reasonably sized inputs or high effort to implement seemingly simple changes. The cause of poor quality may be time pressure, a low level of expertise or morale, a lack of understanding about user needs or simply skipping standard quality assurance steps like reviews or tests.
Stakeholder Satisfaction
The outcome of a software project usually affects different groups of people. For example there is the paying sponsor, subject matter experts, one or more user groups, possibly a work council, IT operations and last but not least the development team. Each group sees the project from its own angle, each individual has its own perception. The likelihood that something is actually broken is high when one or more stakeholder representatives express their concern.
Transparency
The management overseeing the project will have a hard time trusting the project team when its work is kind of opaque. Good project management will bring light to actual progress, budget consumption, spotted risks and problems, next milestones, task assignments and so forth. If the management feels a lack of transparency then the project team should change its habits.
Predictability
The more uncertainty there is the harder predictions are, especially those concerning the future. Uncertainty in the very early days of a project is usually high, therefore one important first task is some exploration to reduce choices and risks. However, at some point in time the project team will have to provide estimates about effort and attainable milestones. Going forward, if the team repeatedly misses milestones that were set based on its own estimates something needs to change. The project may have dependencies which it can't control, ever changing requirements, or the methods for the collection of numbers about the past and creating estimates for the future might need improvement. In any case the project management must adapt its modus operandi to regain their stakeholders trust.
Efficiency
Finally, even if all people affected by the product feel satisfied, the project team is able to live up to its promises, the management feels like it has enough insight and control and the product meets its requirements, there's a chance that time and budget are wasted for no good reason. Consequently, questioning habits, tools and technologies should be part of a well-formed closer look at how the product is developed from requirements to release.
In conclusion
A regular retrospective, as it is recommended in Scrum projects, is a good occasion to think about how the team is doing in light of the five dimensions explained above.
If it ain't broken then don't fix it. If the team is successful according to the five dimensions, then congratulate them and let them do their work, because it simply doesn't matter if the way they work complies to a given process framework.