Guess the Project Cost

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.

Learn More and Stay in Touch:

• To learn about Critical Logic, independent validation and verification, and the Logic Based Development Process, click here
• We welcome your questions and comments. Contact us at: http://www.critical-logic.com