Software Best Practices

Voices on Software Development Best Practices
Welcome to Software Best Practices Sign in | Join | Help
in Search

10x Software Development

Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell's thoughts about how to move toward the "10" side of that 10:1 ratio.
Add to Technorati Favorites

Steve McConnell on Facebook

Why Requirements Weren't More Prominent in Construx's Classic Mistakes Survey

A reader of our 2008 Classic Mistakes White Paper made the following observation:

I work in the Aerospace/Defense industry and have read your article called Software Development's Classic Mistakes 2008 dated July 2008. I am most interested in questioning the results of your most damaging classic mistakes overall that is tabulated in Table 8. I have read that up to 70% of project failures can be attributed to incomplete and poorly communicated requirements. Furthermore, the root cause of more than 50% of all errors identified in projects are introduced during the requirements analysis phase.

Could you please shed some light as to why the results of your study don't cite mistakes that are attributed to requirements? Is this embedded in one or more of the tasks or is this a non-issue?

The reader is correct that multiple industry studies have found that requirements problems are the most common source of project challenges, so I can see why our results might seem anomalous.

The fact is that people who took our survey were given the chance to rate requirements as severe classic mistakes, and they just didn't. We included several classic mistakes in our study related to requirements:

  • Feature creep
  • Shortchanged upstream activities
  • Lack of user involvement
  • Unclear project vision
  • Requirements gold plating

Of these requirements-related mistakes, feature creep made the overall top 10 list (at #7). It was also the 6th most commonly reported mistake. None of the other requirements-related mistakes made the top 10 list for frequency, and none of them including feature creep made the top 10 list for severity.

Based on our consulting experience I am not that surprised to see non-requirements mistakes percolate to the top of the classic mistakes list. Some of the other studies I've seen didn't offer the option to choose some of the problems we listed in our survey, which means their survey respondents didn't have the chance to rank them higher than requirements problems.

Some studies I've seen survey only project managers, which could give a one-sided view of which mistakes are most common. And many of the surveys I've seen focus only on business systems projects (most notably, the Standish Group survey), whereas our data set was for a broader set of projects.

We've also found in many cases that requirements problems are symptoms of other issues, such as overly optimistic schedules (leading to shortchanging requirements), unrealistic expectations (same issue), short-changed QA (don't detect requirements problems until late), etc.

We don't have a classic mistake called simply "bad requirements" or anything comparable to that. Maybe we should add that.

Classic Mistakes Update

We're updating our Classic mistakes survey in 2010. Help update these results, and take the survey!

Related Articles

Comments

 

Vince Panuccio said:

Very insightful. It's good to see a different survey.

January 5, 2010 1:23 AM
 

Andy said:

For us, requirements issues are low percentage of the problem. We would include Feature Creep and Shortchanged upstream activities, but not as important as other areas, and the other 3 related to reqs not at all.

And I would vote against "Bad Requirements". Too vague.

January 11, 2010 11:25 AM
 

Jeff Smith said:

Requirements challenges may be more correlated with large phased-commitment and contract-based industries. It would be interesting to see the numbers across industries, company size and ages, and government/public services. The need around budget/contract challenges, safety, compliance needs, or simply very large complex projects. Limits in choosing adaptable approaches or in obtaining easy feedback may move the burden onto requirements.

Of course, the percentages may easily have changed with the evolving technology world. With smaller projects, cheaper hardware and bandwidth, improved tools and methods, and broader competition, perhaps the dependence on perfect requirements has shifted. Certainly there are more players, many of whom are also working with totally different models. Google and Boeing play a much different game. And I would offer finally, that some who did requirements poorly, may just not be here any longer to respond.

January 30, 2010 11:05 PM

About Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he writes books and articles, teaches classes, and oversees Construx’s software development practices. Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His first two books won Software Development magazine's Jolt Excellence award for best programming books of their years.

Steve has worked in the desktop software industry since 1984 and has expertise in rapid development methodologies, project estimation, software construction practices, and third-party contract management. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds. Steve was Editor in Chief of IEEE Software magazine from 1998-2002.

Steve is on the Panel of Experts that advises the Software Engineering Body of Knowledge (SWEBOK) project and was Chair of the IEEE Computer Society’s Professional Practices Committee. Steve earned a Bachelor’s degree from Whitman College and a Master’s degree in software engineering from Seattle University. Read more about Steve at www.stevemcconnell.com.

This Blog

Syndication

Seminars           www.Construx.com           Consulting