On Messing With the Quality Variable

Interesting quote from my colleague Obie after my comment that software development projects have five variables (time/duration, budget/price, scope, people/rates and quality) and that we should be able to respond to change in all of them, on this post:

(…) Letting quality slip has never, ever produced good results in my experience. I’ve been in situations where the client was explicitly demanding it, but it was still a bad idea and has all sorts of negative repercussions on the team.

Some might argue over the exact definition of those variables and how they play together. I write specifically in the context of consultancies, in what I may have some experience in.

In this context, budget/price equals time/duration of the project times people/rates including the management overhead. It’s a simple and easy equation which has traditionally left the scope and quality variables out, up for discussion. And those discussions can go on and on until the last pointy hair is yanked in despair.

To us and most people in the Agile world, quality is not even really a variable - we like to think it’s a constant, and hopefully fixed way up high close to 100%. To clients, not necessarily so - while some definitely know the importance of a good QA, some might be willing to take the risk and compromise the quality of the product in order to gain some market advantage by reducing the duration of the project, or to save some money on the short term.

As long as everyone understands what playing with that variable causes to the sustainability and risk of a project, and there is a justifiable reason to do so that the whole team can buy into, I don’t see a problem. But, you see, that’s only a theory of mine - I’ve never actually seen that compromise being made with a reason I could believe myself.

PS: I need some feedback on this! If you know - or even better, was involved in - a project where that happened, please get in touch.