Blog

Part I: THE QUESTIONS

Defining successful delivery of software is easy. The act of creating it is not.

Successful software, in an abstract sense, is simply any software that satisfies the client’s business requirements. More specifically, you might define successful delivery of software like this: software that’s released on time, under budget, feature-complete and as stable and bug-free as possible.

Unfortunately, despite all the methodologies and tools commonly used to achieve these goals today, most of today’s software projects simply don’t measure up. According to several recent studies, only 32% of projects are considered successful as measured by these yardsticks. Worse, the trend is getting worse, not better, because that 32% is also a 3% drop since 1997.

What does that say about the project manager, business analysts, developers, and testers? Would you have confidence in an IT partner that only succeeded 32% of the time? Last time we checked, 32% was a failing grade.

Common-sense approaches intended to yield a better result – “drive quality from the start of the software development lifecycle, and minimize the number of builds and total project cost” — are certainly a good place to start.

But as a practical matter, moving from that abstract concept to a specific implementation is much easier said than done.

Let’s say you take the above advice and try to drive quality from the start – i.e., focus on the requirements phase. How exactly do you make that happen, and get it right? In our quarter-century of experience, as much as 40% of a project team’s time, even today, is wasted on requirements definitions that don’t lead anywhere useful.

What we see instead bears out industry studies – that well over half of the defects found in up-and-running production software ultimately stem from poor requirements definitions.

So what’s the solution? Small-team, rapid-development approaches such as Agile and SCRUM are gaining popularity, but are they really leading to better software delivery as we defined it at the beginning of this blog entry?

And if quality assurance best practices can help, why aren’t they seeing wider support and implementation?

Check back with us next week for Part II, in which we’ll move from these common problems to some of the best available solutions!