Preventing the Squeeze
I don’t know how many application development projects I’ve been involved in during my career--in numerous organizations, industries and roles. The specifics of the projects have varied considerably, but there has been one recurring theme to almost all of them: the later in the project we go, the more timelines get squeezed.
The story goes pretty much like this--the delivery date is publicly committed to early in project planning (or even earlier) and when problems in execution occur and schedules start to slip, the date can’t move. There may be changes to functionality and perhaps some additional resources added, but milestones continue to slip--and by the time we reach the “code complete” milestone, there are some fairly significant delays.
That leaves the testing function to recover the entire schedule deficit, while still undertaking a comprehensive set of test cycles that ensure the product is customer ready. There is probably some effort to overlap testing and development with the vague notion that testing prior to the completion of development is going to save time later, and there may be additional testers supplied with an expectation that testing is a function that can benefit from as many additional resources as can be made available.
Sound familiar? Of course, it happens everywhere and with predictable results. In this article,
Please log in or sign up below to read the rest of the article.