Impact Estimation Tables Understanding Complex Technology Quantitatively

I mpact Estimation (IE) tables allow you to analyze any technical or organizational idea in relation to requirements and costs. It is a method I have developed over the last 20 years, and it works! To give one example, shortly after we taught the idea to a manufacturing group, they declared it was worth a million dollars. Using IE for the first time, they presented a bid for project money to management and got the full budget they requested—$1 million more than they had expected! Aims of IE IE can be used for a wide variety of purposes [1]. Its most important uses include • Comparing alternative design ideas. • Estimating the state of the overall design architecture. • Planning and controlling evolutionary project delivery steps. • Analyzing risk. I use IE tables when evaluating projects to help answer my " Twelve Tough Questions. " • Why is the improvement not quantified? • What is the degree of the risk or uncertainty and why? • Are you sure? If not, why not? • Where did you get that information? How can I check it out? • How does your idea measurably affect my goals? • Did we forget anything critical to survival? • How do you know it works that way? Did it before? • Have we got a complete solution? Are all objectives satisfied? • Are we planning to do the " profitable things " first? • Who is responsible for failure or success? • How can we be sure the plan is working during the project—early? • Is it " no cure, no pay " in a contract? Why not? The basic IE idea is simple: Estimate quantitatively how much your design ideas impact all critical requirements. As simple as this is, software engineers do not normally do it. We judge too narrowly. We only treat the costs, e.g., development costs and operational costs, quantitatively. The qualities, e.g., usability, system availability, and system flexibility, tend to be handled subjectively. There are two important underlying issues here. First, we need to express our requirements in a quantitative manner. Second, we need to gather objective data about our technologies. We can make a start by making use of practical experience data. How to Quantify and Document the Relationship Between Requirements and Design First, I will show how to express the relationships between the system requirements and your new design ideas …