This document looks at the issues that can arise and suggests solutions when a testing
project becomes constrained by deadlines. While this is true of most testing projects, there
are some with farther reaching consequences than others, especially if the deadline is
immovable. I hope to impart a few key points along with a few tips and techniques on what to do when
you find yourself in this situation. This list is not exhaustive and the ideas presented here
may need to be adapted to your own specific project. However, when the chips are down and
you need to bring in some semblance of software that is tested, these ideas may be a good
starting point. This paper is intended for testing managers, but the points and tips contained within it will be
of use to anyone involved in planning for a deadline-fixed project.
In an ideal world all IT projects would be carefully planned well ahead of time with adequate resources (time, people, money etc.) made available.
The more typical story is that a project starts off with the best of intentions, finds itself in difficulty some ways down the track and then sees panic set in when the real size and scope is finally unearthed. Then its all hands to the pump, long days and nights, and it falls gasping over the line (after the line has been moved a number of times).
Curiously enough, I have found that testing projects or the testing phase of a larger IT project seem to suffer most from under-estimation both in scope and the resources required—the "oh did we actually need to budget for testing?" syndrome. As a general rule of thumb we usually recommend allowing between 30%-60% of the development budget for testing, more if the risks are greater.
Deadlines are fact of life, not just in IT. Without them no project could ever be properly controlled and the art of good project management would quickly disappear. However some deadlines cannot be moved and if you find yourself with one of these and in trouble, what can you do?
Let’s look first at the different types of deadline…
The most challenging deadline is, of course, one that cannot be moved due to an absolute or a force of nature eg. Y2K. Fortunately there are precious few of these.
Next is the project that is being forced by law or legislation eg. new tax laws, industry compliance legislation etc.—an ever-increasing occurrence in our continually changing governmental and financial systems.
Then there are those that are brought about by changing business initiatives and requirements eg. to make best use of a business opportunity, reduce costs, increase efficiencies etc.
Following these are those projects that the sponsors are just dead keen to get out of the way within a certain timeframe eg. to ensure no more money than is absolutely necessary is spent on silly things like software. This is where many projects sit.
Then there are those that really need to be completed within a certain timeframe however there will not be any major impact if they slip by a week or two on the grounds that earlier implementation could cause problems. Most sensible managers would rather have it late than compromised.
Lastly are those projects that are non-critical or ones where the sponsors and project managers are so laid back that the project can be completed just about when everyone feels like it. And believe it or not, I have seen a few of these.
Whatever the reason for your deadline, there are techniques that can be deployed to give your testing project the best possible chance of success. In a few cases, there may be genuine reasons to say no way on earth can this be done on time and if all other aspects are non-negotiable, then there is a strong case to take a walk. However, there are probably more walks taken than really necessary and although in most cases, you will never get to the ideal, you may be able to get closer to it than you might think.
So let’s take a ride…
What Are We Aiming For?
So what constitutes a quality delivery? A project delivered on time, on budget, to expectations, beyond expectations, low level of defects outstanding when you go-live, low level of apres-implemente defects, software that does what its supposed to do and doesn’t do what its not supposed to do, test team still breathing, test