Big software development projects are complex and challenging, especially when the scope is large and the timeline is fixed. In such projects, the trade-off between quality, scope, and time is the most critical. Fixing the time and scope while maintaining a high level of code quality is daunting, even if you have an almost infinite amount of money. In this article, we will discuss how fixing time and scope can impact the completion of a big non-lean software project and its associated risks.
The Triple Constraint in project management
When the Triple Constraint is applied to software projects, "quality" is most of the time used as "code quality", and "cost" is simply the budget available. In my experience, huge organizations that don't care much about spending money do care about getting the payoff as early as possible. In those cases, "time" becomes the currency, and it's fixed.
When I talk about "lean software projects", I refer to projects based on avoiding waste by delivering small tasks directly to the customer but not offering all features on the first delivery to get early feedback and iterate. In such projects, when time and scope are non-negotiable, code quality is also non-negotiable, and money is unlimited, the focus shifts from time/scope/code quality to time/scope/customer satisfaction. The user satisfaction with the software becomes the risk, as everything else is fixed; something has to give.
I've seen many executives trying to add impossible "constraints" like those to teams, hoping they would improve but offering absolutely no infrastructure for continuous improvement. Spoiler alert: it doesn't work.
Fixing time and scope in non-lean software projects where code quality is also fixed is risky. The more we fix the time, scope, and code quality, the more challenging it becomes to deliver a satisfactory product to the users. Product quality issues will inevitably leak into the completed software and will be noticed by the user at some point, which may take longer and is hardly perceivable by the product managers before launch. In such cases, the project's failure will be almost non-recoverable, and the cost of fixing the issues will be much higher.
Forget about the "pseudo-Agile" ideas of "fail fast, fail often":
It’s not worth waiting to learn from a failure that can’t be recovered from.
Another main risk of fixing time, scope, and code quality is the pressure it puts on the development team. The team is forced to work within a fixed timeline and a set of requirements, which is very challenging. Besides product quality, the pressure will compromise other aspects, such as security, as the team may cut corners to meet the deadline and the required scope. Moreover, this can lead to technical debt, requiring additional time and resources to fix later.
Another risk in fixing time, scope and code quality is the lack of flexibility. In such projects, requirements or timeline changes midway won't be easily accommodated, and any change will significantly impact the project’s outcome. This lack of flexibility can lead to a situation where there are more shortcuts, and the delivered product does not meet the users’ expectations, resulting in even more dissatisfaction.
In conclusion, fixing time, scope, and code quality in non-lean software projects can be risky. While it may seem straightforward, it can lead to serious unintended compromises on product quality and a lack of flexibility, resulting in unsatisfactory project completion. It is essential to consider the risks associated with fixing time, scope, and code quality and balance those dimensions to deliver a satisfactory product to the users. A Lean approach to projects solves most of these issues. That is: avoid waste by delivering small tasks directly to the customer but not offering all features on the first delivery to get early feedback and iterate.
Ultimately, the success of a software project is determined by the users’ satisfaction, and this should be the development team’s primary focus.
That is if they really care about that at all…
Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.
Top comments (0)