A short time ago we were at a meeting of IT executives. A major new CIO survey had been released, and, once again, one of the top ten concerns of CIOs is the impact poor requirements have on delivering software on time and on budget. So in the Q&A session, the question was posed: Since the requirements problem has been a top concern of CIOs for at least the last ten years, why hasn’t anyone done anything about it?

The answer was summed up succinctly by one of the CIO panelists: “Requirements are the elephant in the room that no one wants to talk about.” Poor requirements specification accounts for about 80% of all software development rework, and rework itself is typically half of the cost of software development overall. So it is a big elephant indeed, especially as budgets get tight in tougher economic times.

Why Is This?

After all, proven, reliable, technology-backed solutions are out there that guarantee correct implementation of requirements into applications with few defects and very low rework costs (we should know; we’ve been doing it for years!). What keeps the requirements problem on the CIO top-ten issues list? We think there are two factors.

How to Improve

First, improving requirements cannot be done by simply buying another tool and some training classes. It also requires changes to roles, responsibilities, and skills, especially in the QA and testing organization. Many IT organizations are simply unwilling or unable to make these changes. Managers are willing to take risks with new technology but unwilling to do so when it comes to changes in how the organization does its work.

Second, the financial rewards for delivering higher-quality software at less cost are difficult to recognize. Suppose the annual software development budget for an IT organization is $2 million. They implement proven requirements validation and testing solutions and remove $500,000 in testing and rework costs (a typical result). How does that “profit” benefit the IT organization? Better salaries? Probably not. More likely, it translates into additional projects or goes to mitigate our chronic tendency to under-estimate software development costs in the first place.

There is, however, an overriding incentive to recognize the elephant: customer satisfaction. When applications and releases are routinely delivered on time and with few, if any, functional defects, the business customer is spared a tremendous amount of frustration and anxiety, not to mention cost. The trust between the business customer and IT goes up substantially. In these times of budget austerity and limited investment, this can be critical to the success of the CIO and the business as a whole. So pack up the elephant gun and let’s go on a safari!

Imagine you are an architect (the house kind, not the IT kind). A client comes to you and says, “I need a four-bedroom, three-bathroom house with living room, dining room and a big kitchen with all of the latest equipment. It should be large enough to meet all of my lifestyle needs. Now, tell me how much it will cost.” Could you give an answer? Would you give an answer? Probably not, because there is not enough information.

Yet how many times in IT software development does the business sponsor challenge us with the same type of question: “We want a system that does such-and-such, but tell me the total cost before you start.” We have brought a lot of this on ourselves by being notoriously poor at estimating the effort to build software and then delivering on that estimate. Some 60% of all projects are substantially over their original estimates, so you can’t blame business for wanting to somehow get a fence around its IT expenditures.

Two Costs, Not One

In reality, there are two costs to worry about: the cost to define the software and the cost to build and implement the resulting application. Allowing separate estimates for each activity can control cost risks and improve accuracy of estimates. But the trick is to be very clear about the exit criteria for each of these efforts, especially the define phase. Define means completely specify the expected behavior of the system: all business rules, every GUI, all user navigation, each electronic interface. The user should know exactly what the system will look like. Build and implement covers the technical software design, construction and testing of the software as well as the transition into production.

Traditionally, too much define work gets merged into the software build and implement activities, which not only makes it hard to segregate costs, but also drives up the cost by adding expensive definition rework. So being sure that the define phase meets its goals is critical. Reliable completion criteria for define phase specifications are

• Developers can build the system without requiring additional analysis and feedback from the business and functional analysts
• Detailed functional test cases can be designed from the specifications
• User manuals and training materials can be drafted from the defined specifications

Reduce Total Cost

Since the majority of defects come from poor or incomplete requirements, a strong define phase virtually eliminates the opportunity for requirements defects to be introduced into code. Total software defects and associated rework costs plummet. Properly executed, this project structure can reduce total costs by 20–30% and add predictability to schedules. Cost risks are better managed. Further, it still allows for agile or iterative software construction and implementation.

Critical Logic has been holding a series of Webinars entitled “Accelerating IT Performance.” Based on the feedback, two major issues seem to be on most senior IT managers’ minds:

• “We seem to have a lot of challenges getting IT projects delivered successfully; is everyone else having problems?” and

• “What can I do about it?”

This edition of Critical Knowledge examines the first of these questions. Future editions will address the second.

Is Everyone Having These Problems? Yes!

We’ve been working and talking with senior IT professionals about project challenges for over two decades and their litany of problems never seems to change: missed deadlines, blown budgets, failure to deliver business value, and lack of quality.

We wondered if this is just the nature of who we talked to, or is it a global complaint?

To get an objective insight into the question, we looked at the various literature on the subject and found that the best seemed to be the bi-annual Standish Group’s Chaos reports. They’ve been looking at these issues since 1994, and their latest study (based on over 15,000 projects) shows that not only is there a problem, but people know it’s there, and know it’s big. How big? Twenty percent of IT projects completely fail or are cancelled, half are challenged (late, over budget, missed objectives) and only 35% are completely successful!

Why?

Saying there’s a problem begs the other half of the question: Why? Here again, our anecdotal evidence seems to be supported by what the studies are saying: lack of user/executive involvement and unclear/poorly communicated business objectives … But the single biggest factor is poor requirements (Forrester Group - 2006).*

We think that most IT execs would agree that given the first two causes, it’s not suprising that it’s so hard to get requirements right - and the code written from them.

Upcoming editions will look at what people are doing about it. Experience the difference of getting it Right from the Start™. Visit critical-logic.com or email moreinfo@critical-logic.com for more information.