Executive Summary

In large organizations, a steering committee often oversees development projects. Even with small projects, usually someone in a management position who isn't directly involved in the project has oversight or budget responsibilities. If someone is overseeing your project, it's a good idea to include an Executive Summary aimed directly at that person.

These individuals are generally not terribly interested in the details of the system. They have a few specific questions they want answered, and the more efficiently you answer them, the better. Management is usually looking for answers to questions like the following:

• What problems does the proposed system address?
• Is this the best and most cost-effective solution?
• What other solutions have been considered?
• How long will it take to implement the system?
• How much will it cost?
• What are the risks?

Answering the first question should be simple if you've defined the system's goals and scope. You only need to restate them here. I like to be as explicit as possible about listing anything that might have been considered for inclusion in the system but was rejected. I find it's good insurance against finger-pointing later.

If you're an outside consultant, you might not be able to address the second and third questions regarding other solutions. If you do have access to this information, however, it's useful to include a brief description of other solutions that might have been considered and the reasons for their rejection. Management finds it reassuring to think that due consideration has been given to alternatives.

But do keep your answers to the second and third questions brief. If you've done an extensive evaluation of off-the-shelf applications and rejected them in favor of a custom solution, you'll probably have detailed information comparing cost, functionality, support, and so on. This isn't the place for it; put it in an appendix. As a matter of fact, the entire Executive Summary shouldn't be more than a few pages long.

Answering questions about time and cost can be tricky, and it's almost always scary. But answering questions becomes more manageable if you consider what you're asking management to buy into. If you're developing a simple system, you probably have a good idea of the answers, based on the defined scope. With large, complex systems, you won't yet know how long or how much, but that's OK. You'll know what the next step is, and that's all you need approval for at this point.

If you can realistically say something like, "It is not yet possible to estimate the actual time or cost for full implementation, but we expect it to be in the range of x to y. The next phase, however, will require only z to complete, and will result in…", then you should be fine. Just be sure that whatever follows the "result in…" is tangible and intrinsically valuable to the organization. In my experience, people are very hesitant to commit funds to "additional research."

I've also found that adequately addressing the final question, regarding risks, is one of the most effective ways of establishing your credibility. Spend time thinking about what could go wrong. Are there technical issues that haven't been resolved? Are things likely to take longer than expected? Where? Why? Be paranoid.

Now go back and be realistic. How likely are these things to happen? Yes, it's possible that your entire development team will be incapacitated by the plague or that the office will be destroyed by an airplane crash. But it's not very likely. What is likely is that sometime during the project something will go wrong, and management will want to know that you've thought about likely issues and have contingency plans. You needn't list everything, perhaps only the top two or three concerns in a few paragraphs, but it is important that the risk issues be addressed.

If you're an outside consultant, I recommend that you not skirt the issue of your competence. Obviously, the first question anybody considering hiring you will ask is whether you can do the job. The Executive Summary probably isn't the best place to talk about your credentials, but you should address the risk of nonperformance. The details of risk negotiation are up to you; I won't presume to make recommendations. It's just been my experience that directly addressing the issue helps establish your credibility as a businessperson.