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.

One of the things we observe too often in our engagements is quality being adversely impacted by seemingly reasonable project management decisions. We are not talking about the obvious quality-killers of tasks with impossible time frames or inadequate resources (dollars or people) for the amount of effort required. Rather, there are decisions that a PM makes during the project that sound good at the time but have serious impact on the testing and delivery phases. Let’s look at three examples:

Switch to iterative. Sometime during design and coding, the PM decides to deliver code to the test team in several iterations rather than as a single release. Makes sense to the developers, but it adds a major burden to the testing. Now for each iteration, not only must the new functionality be tested, but functionality delivered in previous iterations must be thoroughly regressed. Before switching the delivery strategy, the PM needs to understand and account for the impact on regression testing.

Assumptions. Every project estimate and plan comes with assumptions. Assumptions are to be managed, not assumed. We see too many cases where test schedules are based on important assumptions about specifications, test environments, or test data. The PM fails to ensure these assumptions hold true, then is surprised when the test effort is delayed because the need has not been fulfilled. In our proposals, we are relabeling assumptions as dependencies to ensure they get the attention they deserve.

The Project vs. MS Project. Just because MS Project says a task is done does not make it so. Is the work truly complete? Has the user of the task’s deliverables accepted them, without being under pressure to “meet the date?” The reality is that there is no free lunch; you always get caught by taking shortcuts, and it usually is when testing commences that the pain begins. Shortcuts in requirements definition become excessive defects. Shortcuts in test coverage translate into long nights during implementation, when the bugs surface.

Any time the project tasks are restructured in mid-project for the purpose of shaving time or effort, be very careful what the impact is on the testing effort. You may be adding to the testing burden or extending the rework costs by lowering the likely quality of the delivered application. Nobody wins in that case.