Determining the System Scope

Once you know why you are implementing a system, you have a basis for deciding what functionality reasonably falls within the scope of the system (and what doesn't). As with design criteria, the functions within a system's scope should directly support a specified goal.

Say, for example, that improving the efficiency of the sales order process is a project goal. The printing of invoices directly supports that goal and clearly falls within the scope of the proposed system. The production of a product catalog, on the other hand, does not, and therefore lies outside the scope of the system. This remains the case even when the catalog is produced by the same people and shares a certain amount of data with the order-taking system.

Sometimes, when there's a lot of overlap in data or functionality between core and "extraneous" goals, it makes sense to redefine the goals of the system. In the preceding example, the system might become a "Sales Support" system rather than an "Order Taking" system, and "Produce Product Catalogs" would become one of the project's goals.

But this can also be a dangerous process. You don't want to be using the desired scope of the system to define the goals. That's very much a case of putting the cart before the horse. I know from experience how tempting it can be to expand a system's scope to include easy or interesting functions. I also know from experience how embarrassing it is when you don't have a good answer for a user who asks, "Why would I want to do that?"

Old versions of the Norton Utilitiesan indispensable piece of software in the days of MS-DOSprovided a great example of this. The program used to report, on exit, how long it had been running. Having spent years considering the matter, the only explanation I've found for why it did this is "because they could."

Not good enough, I'm afraid. The rule is that if a function doesn't directly support a goal, then it's outside the scope of the system. Like most rules, this one can be broken, but you should do so only after careful consideration, if you're sure that there's a legitimate use for the function. Timing how long a piece of software is loaded may be cool, but it's hardly useful.

There are situations in which the function has clear value to the users and that value clearly outweighs the cost of implementation. The product catalog goal described previously might be a good example of this.

But even in fairly clear-cut situations like this, where you might expand the goals of the system, it's probably safer to include these extra functions under the general scope category "Added Value Functionality." This makes it clear that the functionality is not strictly necessary and it can easily be dropped from the system at a later date if you discover that its implementation is going to cost more than expected, or if you simply run out of time and money.

The second situation in which you might need to include functionality that doesn't directly support a system goal is when the client insists on including it. It might seem perfectly obvious to you that producing an employee phone list has nothing whatsoever to do with processing orders, but if the client wants it, they want it. You can point out that the functionality doesn't support any of the specified goals, but your job is to satisfy your client's requirements, not define them.

Cost-Benefit Analysis

As a final step in this phase of the design process, you might find it worthwhile to perform a cost-benefit analysis on the scoped functionality. This is particularly true if the proposed system has several components. The relative cost-benefit ratios of the various components will help you determine the order in which the components should be implemented. And if you're considering expanding the scope to include "Added Value" functionality, a cost-benefit analysis can serve as a reality check on the system.

All else being equal, components with the highest benefit per cost should be implemented first. This strategy provides the best "bang for the buck" and allows the system to start paying for itself as early as possible. This is particularly true for projects that will take considerable time to complete. If you can deliver the core functionality quickly, you have a sound basis for evaluating future development, and you reduce the risk of changes in the business environment making the system unusable later.

If the system can start paying for itself relatively early in the development process, you might also find it possible to fund some of those "fun and interesting but not strictly necessary" functions that you had to weed out while defining the system's scope. Of course, the reverse occasionally happens as well. Clients might find that the initial functionality adequately meets their goals and delay the development of future components indefinitely.

Performing a formal cost-benefit analysis is, of course, subject to the rule about the cost of making a mistake outweighing the cost of researching the answer. Cost-benefit analyses aren't difficult, but they can be time-consuming, and it's obviously not sensible to spend two days analyzing a system that will take one day to write. In many situations, an informal analysis (otherwise known as gut feel) is more than sufficient.

There are many ways of performing cost-benefit analyses, although the principle is simple. The estimated benefit of a function divided by the estimated cost of the function will give you a numeric value. The higher this value, the higher the relative value of the component when compared to other components.

Where cost-benefit analysis gets tricky is in determining common units of measurement. All costs must be measured in the same units, and all benefits must be measured in the same units, although the two units need not be the same. You can, for example, compare costs in time against value in dollars. The resulting ratio is used for comparison with other values calculated using the same units, so the result is perfectly valid.

Estimated cost can usually be measured in either hours or dollars, and it's normally straightforward to convert between these two in a business environment. Because both of these terms are somewhat loaded, however, it might be better to express costs in some derived value, like "units of work." This avoids the possibility of confusing a cost-benefit analysis with either a price quotation or an implementation schedule.

Assigning common units of measurement to benefits can be more problematic. You might estimate, for example, that automating a given work process will increase efficiency by 20 percent and reduce errors by 50 percent. The 20-percent improvement in efficiency can be translated into hours saved, and from there, if necessary, into dollars. But it might not be so easy to assign a value to the improved accuracy. It might be possible to estimate the cost (in either time or dollars) of finding and fixing mistakes, but that doesn't allow for other intangible, but very real, benefits, such as the good will gained by getting a customer's order correct.

In these situations, you can use multiple benefit estimates. For example, you might estimate benefits in terms of "Dollars Saved," "Dollars Earned," and "Intangible Benefits." You then calculate three ratios, one for each value. This can make comparison a little complexyou and your client might find it difficult to determine whether a function with the values 3/6/2 should have higher priority than one with values of 6/2/3. In this case, you can normalize the values in some way to derive a single cost-benefit estimate.

You might decide to add the values for each benefit category together if they're all of relatively equal importance. Admittedly, you're adding apples and oranges, but at this point it's acceptable to think of them simply as fruit. Sometimes an average value seems more appropriate.

If, as is most often the case, the categories are not of equal importance to the organization, you can assign a relative value to each category, and multiply each category by that importance factor. For example, given the benefit categories cited earlier, you might decide that "Dollars Saved" is not terribly important but "Intangible Benefits" is and that "Dollars Earned" is twice as important as "Intangible Benefits." So you would assign a modifier of 1 to "Dollars Saved," 2 to "Intangible Benefits," and 4 to "Dollars Earned." The resulting figures are shown in Table 10-1.

Table 10-1. A Sample Weighted Benefit Analysis

	Dollars Earned (mod: 4)	Dollars Saved (mod: 1)	Intangible Benefits (mod: 2)	Total	Weighted Total	Average	Weighted Average
Function 1	3	6	2	11	22	3.6	7.3
Function 2	6	2	3	11	32	3.6	10.6

It's often easier to assign benefit estimates in relative, rather than absolute, terms. For example, it's often difficult to assign Function X intangible benefits of 3. But it's usually possible to say that Function X is likely to have twice the intangible benefits of Function Y and that Function Y and Function Z are likely to have the same intangible benefits.

Cost-benefit analyses can be useful tools for capturing the proposed benefits of a system. They provide a simple way to compare the relative values of various components, which can be useful in scoping and scheduling projects. But they are only tools, based on best-guess estimates, and you must not mistake them for absolute values. Even though Function X has a benefit ratio of 12 and Function Y has a ratio of 2, it might still be appropriate (or technically necessary) to implement Function Y first.

The results of a cost-benefit analysis have to be reviewed in conjunction with other factors, such as system dependencies. They must also be reviewed as your understanding of the system improves. Re-evaluate your estimates prior to commencing work on each component. You might find that your experience with the actual costs and benefits of the previous components will alter your estimates for future components.