In 2005 two major organizations were rationalizing their financial systems (having, through mergers, acquisitions and other events ended up with multiple systems). Both of these projects cost over $10 million — not an insubstantial investment.

In both cases the decision was made to minimize the scope of the project so as to minimize the workload, cost and risks. They decided to "take the best existing practice" and make that the new standard for the whole organization.

Neither project had a realistic business case. One decided to forgo a formal business case and just focus on realizing the identified savings (mainly software licence and consolidation workload savings). The other did follow the business case process but closer scrutiny of the numbers showed that 25 percent of the "benefits" were invalid.

Both organizations, after their project's completion, wished they had not minimized the scope and had "done the job properly".

They found they were still stuck with the same inefficient processes they had before, but had now spent millions of dollars reinforcing them into the business. The opportunities to reduce the time to do processes, to reduce accounts outstanding and other savings had been forgone and, as the new systems were designed to the old paradigm, were too expensive to be gained after the systems' implementation.

A driving force for minimizing the scope is the desire to reduce the project's costs and risks. This is a very narrow way of thinking as the true focus should be on the net value and its achievability.

Systems are automated processes. If you simplify your processes you can often eliminate 50 percent of the process steps. This translates, in our experience, a 20 percent reduction in the overall project implementation costs. So, had these organizations simplified and rationalized their financial processes beforehand, the overall cost of their projects may have actually gone down while the value of the benefits would have increased exponentially. So, minimizing the scope up front is often a false economy and can cause projects to fail.

This led us to define the need for two types of scope — problem and solution scope.

In our example, the starting point should be to take into consideration all financial processes and related systems to define how you want to manage your finances in the future — in process terms. This is your problem scope. It allows you to take a broad perspective to see where the most value is.

The simplification of these processes should be driven by the organization's improvement targets — eg a two-day end of month, halving the accounts receivable amount, halving the accounts payable processing workload.

So then, the project team works with the organization to define the new financial processes and where the systems can add the most value. Just because you have defined the whole end-to-end financial process flows it does not necessitate that you have to implement every idea and improvement.

Done properly, the process simplification step will also identify where the most benefits are, the dependencies involved and the scale of the workload. This allows you select the areas where you want to move forward — your solution scope.

(Obviously, over time, a series of solutions scopes can cover all of the problem scope solution, delivering all of the potential benefits.) Now the solution scope can be used to develop and install a solution within the context of the overall problem scope solution (allowing the necessary hooks and allowances to be made for future needs — increasing future benefits' value).

The decision as to which elements go into the solution scope will be determined by the organization's needs and imperatives - fast savings, system decommissioning needs, problem operational areas, and so on.

Also, why elements are not in the defined solution scope will now be known.

Project manager take away

When looking at your project's scope ask yourself whether you have a problem scope or just a solution scope and the necessary consideration of the bigger picture has been forgone.

The objective of the scope definition is to both control the workload (and associated cost and risks) and maximize the available value. The wrong scope can cut off significant value too soon without knowing that this is what is being done.

In one of the financial systems rationalizations above we quickly computed that a 10 percent increase in project cost would at least have doubled the potential benefits. This additional $20m in benefits was missed. An expensive scope decision.

To read part two of Jed's first column, Why Projects Fail: Part Two, Poor Business Requirements, click here

Jed Simms is CIO magazine's weekly project management columnist. Simms, founder of projects and benefits delivery research firm Capability Management, is also the developer of specialized project management and project governance Web site www.project-sponsor.com