Apr 14, 2014
You know how it goes. Something is so obvious to you that you think it’s obvious and well known to everybody else. But then you meet people that have no clue. You try to explain the topic to them but they don’t seem to get it and keep enforcing their own agenda.
The topic in this case is trying to control all the variables of a project at once: scope, resources, time, and quality.
The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be.
No one can control all 4 variables. When you change one you inadvertently cause another to change in response. Note that lowering quality to any less than excellent has unforeseen impact on the other 3 variables that may not become obvious until your project slows to a crawl just before the deadline.
It was documented more than a decade ago but I still see a lot of people playing God trying to control all four variables at once.
Recently, I have been involved in a project where a stakeholder presented a specific fixed scope to be developed by a particular number of developers with a fixed deadline and it had to be done with high quality by covering the code with lots of tests. Since it was an attempt to rewrite a legacy system of very low quality, quality had to be high this time. I didn’t see many tests being written under this pressure, so it seems it’s gonna end up as a rewrite of the same quality problems but on a cooler framework this time.
If common sense doesn’t work for you, I hope math will help you.
Let’s assume that
Q stands for quality,
S stands for scope,
R stands for resources, and
T stands for time. We can come up with several formulas for project constraints:
T = Q × S ÷ R Q = R × T ÷ S S = T × R ÷ Q R = S × Q ÷ T
As you can see, each variable depends on the other three. If even after seeing the math behind project constrains you still think you can control all of them, well, you picked the wrong industry. Maybe you should been a magician and you probably would be successful in that area, but project management and software development are not for you.
Controlling all the variables is just impossible. It’s either wishful thinking or an attempt to play God.
You can enforce scope, quality and resources, but then you can’t enforce a deadline. Given that developers actually work on the project and don’t waste time, it will be done when it will be done. If you try to speed things up a bit here, again, you have to give up something else. Unfortunately, quality is the one usually sacrificed.
Or you can enforce quality and resources with a fixed deadline, but then you can’t enforce a scope. In this case you should prioritize features so that what you care about most gets done first.
Resources is a bit tricky, since according to Brook’s Law, throwing more people on a late project makes it later. So, I wouldn’t recommend adding more people just because you wish to keep the same scope to be done with high quality and with the same deadline. It doesn’t work.
And sacrificing quality is not a good idea too. Low quality brings unpredictability to your project because it negatively affects all other variables in the equation.
So, it makes the most sense to either give up on deadlines or scope.
Yes, you’re not God and your attempts to control everything will undoubtedly fail. But it’s not that bad. You can develop a successful project by first realizing that you don’t control everything in this life, and second, focusing on what matters the most for your project for it to become a success. You have to give up just a single variable of the equation; the other three are still under your control.