Specification Design

Often an organization will find that its needs cannot be easily met by a standard, "off-the-shelf" software system, even with extensive customization. In other cases, such a system may exist but it may be extremely expensive, with only a fraction of its capabilities actually needed.

There are thousands of appropriate vendors who can economically produce good-quality software. The best option is to produce a shortlist of qualified firms, then provide them with specific information on what you need, and ask for a quote.

This is where a major difficulty appears: vendors will need a good description of the system so they can provide you with a quote. A firm that promises a fixed price for an undefined product always falls in the "too good to be true" category: it can only do one of the following things:

• Ask a very high price to cover the expected "feature creep" that always occurs with undefined software. Seriously inflated profit margins (or what some vendors calls "risk provision" - usually in the 80-100% range) will compensate for unclear requirements
• Offer a low price and then supply software that only marginally achieves its promised goals, and does so with inferior performance. The company will then make up on lost profit by asking for various "unforeseen extensions" and will use other tactics to finally arrive at a large profit

Both options have major drawbacks, and only one benefit: you are not required to invest money upfront in planning; instead, you will pay several times more over the course of the project. What’s even worse, even if the total bill at the end of the project is still satisfactory, the originally promised deadlines for delivery, and the promised quality will rarely be there.

The key to solving these issues is to have an independent and competent third-party produce a solution specification for your project. This has the following immediate benefits:

• Vendors can quote a price loaded with a low "risk factor" (figures between 10% and 25% are common) because they will have to stick to a written and signed document, not to an unclear promise
• Vendors can usually provide an excellent estimation of the time needed to complete their work when the work is clearly specified
• The solution specification can become an inseparable part of your contract with the vendor, thus eliminating a great many possibilities for misunderstanding and even legal liability on both sides
• Upon delivery, it is relatively easy to make sure the vendor has delivered exactly what was agreed upon; this is almost impossible to do with any suitable precision when the deliverables have not been well described beforehand

Delera Systems consultants have helped numerous clients with the specification writing process. Like the previous phase (requirements gathering), writing a good specification also involves a great deal of communication with the client. At any given moment there are hundreds of decisions and tradeoffs to be made: quality vs. speed of implementation, ease of subsequent support vs. overall project budget.

Many customers are tempted to produce a brief form of specification themselves. This approach typically works only with very large organizations that have highly paid MIS departments, staffed not only with system administration personnel but also with high-level system architects with years of experience creating software. Having your own architect-level staff is without doubt an excellent asset, but few organizations can afford it.

Another approach is to hire a medium or large software vendor to do the consulting work for you - basically produce a specification for a discounted price, and then implement the real system. This method only shifts the planning costs to a later stage of the game: in one way or another, IT vendors will recover these costs. It is important to note, though, that operating margins of smaller consulting services firms are invariably lower than those of larger corporations.