Where are projects going wrong?
For all the fancy new tools, portfolios of best practices and strict testing regimens, delays and failures still plague corporate software development projects.
It’s possible that as many as 70% of all projects are significantly delayed or canceled, says Dave Locke, program director for worldwide technical marketing at Rational Software, a unit of IBM.
Among the reasons why projects fail: mismanagement, scope creep and communication breakdowns. Another big problem, according to Locke, is poorly defined software specifications.
Typically, the technology department creates a specifications document based on requirements received from the business side. A software specification meshes what the user wants with what’s possible technically and, just as important, feasible financially.
If the specifications are too complex, the project schedule “becomes untenable and may even be longer than the useful life of the system,” says Ellen Shepard, chief operating officer at software consultancy Agility Investment Technologies. And the more complex the system, she adds, the harder it will be to maintain and enhance down the road.
But a specification that’s not well thought out, says Shepard, “will almost always lead to an unmet user expectation”—a situation that can be fixed only with additional time and money.
Part of the problem stems from the business side providing too much detail—to the point of dictating how to solve a problem rather than simply stating the desired outcome. Conversely, it’s still common to find that employees are too busy—or too impatient—to bother with a software project. And, of course, the translation from business goal to technology spec may introduce errors.
According to some, the answer may be a standard procedure for creating specifications. “If companies are using the right methodology, I think it’s not an issue at all,” says Susan Hutt, a vice president in PeopleSoft’s Global Services practice.
To help you get started on solidifying your own process, Baseline has outlined the seven key steps for keeping requirements in check.
