Quality and Deadlines

by Krishna on July 7, 2009

In my previous post on software quality, I said that it was wrong to argue that quality lowers cost without talking about transition costs. There is also another dimension that we must consider, which is the calendar time taken for deliverables. In the long run, higher quality results in more deliverables or less development time or both. But in the short run, you will see deadline overruns and you have to be prepared for that.stadium

Regardless of what is actually more important, time overruns are usually treated as a bigger problem than cost overruns. Missing deadlines is an immediate problem. It is in your face. It is very objective. In contrast, cost overruns require greater analysis and deviations can be smoothed over or explained away unless the variations are very large. So, meeting deadlines is usually treated as the most important objective for a team.

When you meet an immovable object, you have to give way. If deadlines cannot be changed or compromised, then something else will have to be gone instead. This should be best accomplished by reducing the feature set for the deadline release, but sometimes, at the individual level, quality takes a step back. Sometimes, the reduced quality may be imperceptible, but over time, it adds up to a poorer system that is less maintainable and less extensible.

If you want to fix this, it is necessary to change the emphasis from “meet the deadline” to “meet the quality standards”. First improve quality, and only then examine productivity issues. If you try to improve productivity first, quality may decrease and also reduce net productivity as the team is pulled into fixing quality problems.

But as I started saying, when you try to improve quality, you will initially see a reduction in productivity as the quality activities take more time. There might be refactoring that takes time away from new development. So here is where the project manager has to show leadership by avoiding compromises on quality while the clock keeps ticking. She may have to buy more time for the team to improve quality. It may be tough sometimes with external deadlines looming, but that is what is required for quality improvement.


Pradeep Bhanot July 9, 2009 at 6:00 am

Krishna, right from the outset the project manager has to have a set of levers that can be pulled to meet customer needs. A project often supports a business case, which as to state whether it is a feature oriented or time oriented deliverable. If it is a feature oriented deliverable, time has to have some elasticity. If it is a time sensitive deliverable, then the feature set has to be granular enough to be open to being trimmed. Quality should never be a lever, but I have seen situations where a release deadline has to be met to meet a contractual obligation, where products have shipped with no severity 1 or severity 2 issues and documented severity 3 issues. This makes the software fit for use, even though it has known, temporary minor issues.

If you are interested in other issues around project management, I blog about it here: http://community.ca.com/blogs/ppm/

Krishna July 9, 2009 at 3:56 pm

Pradeep, that is very true. What I have seen in practice is that project managers sometimes do not use those levers even when they could. This is especially true of those new to project management. They are unsure about themselves and think that nothing is negotiable.

By the way, you have a nice blog.

Lucas A. Hansen August 31, 2009 at 3:45 am

Thanks for the thoughts. It was a great kickoff for approaching the issues regarding deadlines vs. quality deliverables.

Krishna August 31, 2009 at 2:38 pm

Thanks for your comment, Lucas.

Comments on this entry are closed.

{ 1 trackback }

Previous post:

Next post: