Project Requirements Process R140

R140 - Estimate Costs and Benefits per Option

DEFINITION

For each option, prepare initial estimates of costs and benefits, sufficient to give an understanding of the likely costs and to allow comparisons to be made between options.

SUMMARY

Many details of the preferred business solution will have become clear during the preceding requirements processes.  In this process, a complete balanced view of the anticipated costs and benefits is formulated.  This might include non-financial aspects.

A benefit model is formulated for each major option that is under consideration.  This will assist the project sponsor and key decision makers to decide which direction to take and to confirm that the project is a worthwhile undertaking.  The results also provide a model against which future deviations or proposed changes can be assessed and a target measure for the overall success of the project.

In addition to the package software costs and required hardware cost, the cost for implementing the package has to be considered in the calculation. This will include the cost of internal client organisation resources (both within and external to the project team), external consulting fees (consultant, vendor, other), and all other costs attributable to the project.  Benefits included will be all benefits of the project over a defined period of operation.  The Benefit Model would also highlight non-financial benefits and define performance measures by which they can be assessed such that progress and eventual live operation can be gauged.

Many of the details will necessarily be estimates at this time.  The detail of the model will be refined as future decisions are taken and details become clearer.   The model will be maintained throughout the project.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

• Review/confirm business needs and anticipated benefits (L020)
• System Vision (R070)

Prerequisites (Finish-Finish):

• Constraints (R040)
• Organisational Impact (R090)
• Detailed Requirements (R100)
• Feeder Review (R110)
• Gap Analysis - existing system versus requirements (R120)
• Establish Architectural Options (R130)

Dependent procedures (Finish-Finish):

• Collate and agree final report (R150)

RECEIVABLES

• Business Needs and Anticipated Benefits
• Constraints (technical, organisational and financial)
• System Vision
• Detailed Requirements
• Feeder Review
• Gap Analysis
• Architectural Options

DELIVERABLES

• Benefit Model (updated) - published as part of the Definition of Requirements (DoR)

TOOLS

• Consultant’s “Benefits Realisation” Core Guide
• example implementation plans
• sample proposals

DETAILED DESCRIPTION OF TASKS

Objectives of the Benefit Model

The business needs and anticipated benefits are normally first established in the project’s launch (see Process L020).  These will have identified an initial view of the overall benefits expected from the project.

Now that the requirements have been considered in detail and possible solutions have been identified and detailed, it is possible to construct a substantial model of the anticipated costs and benefits.  This model may have several uses, for example:

• to confirm that the project is a worthwhile undertaking,
• to assist initial decisions to be taken regarding the available business and technical options that have been identified,
• to present a balanced view of the overall benefits of the proposed solution that can be used to communicate the project’s aims to the management of the client organisation and other relevant parties,
• to provide a model that can be used to measure deviations from the original planned benefits
• to provide a model against which proposed changes can be measured to ensure that they are worthwhile,
• to provide a means to measure the overall success of the project
• to provide a standard by which actual achievements, costs and benefits can be measured throughout the subsequent operational life of the system.

Format of the Benefit Model

Application Implementation and Intergation Processes do not prescribe a specific approach to identifying costs and benefits.  Typically the approach will need to comply with the normal policy and style of the client organisation.  For example, the organisation is likely to have pre-defined attitudes to such things as:

• the period over which to view the costs and benefits,
• the costing of internal staff resources,
• the approach to accounting for inflation,
• the need to achieve a specific internal rate of return,
• the treatment of intangible or non-financial benefits.

The model should address the full costs of implementing the solution and the operational costs of the system.  It should contrast this to the existing facilities and business processes to establish a net benefit of introducing the system.

It is recommended that the client organisation take a balanced view of all types of cost, benefit, risk and quality issue.  A balanced view will inevitably include traditional tangible financial costs and benefits.  It would also, however, examine the intangible factors such as staff morale, customer satisfaction, and quality.

Some organisations might translate these factors into assumed costs or financial benefits.  Various techniques can be used to make this translation, for example, by asking the responsible managers how much they would be willing to pay to achieve the intangible benefit.  Alternatively, these factors might be recognised and quantified - but not in financial terms.

For the Benefit Model to be used to assess deviations, changes and the project’s overall success, these intangible factors should be quantifiable.  For example, customer satisfaction could be measured and quantified by survey questionnaires without attempting to relate this to an actual financial cost or benefit.

Assessing project costs

During the course of the project several systems environments will have to be set up, the most common being:

• the development system,
• the integration and the test system,
• the productive environment,
• possibly different roll-out environments at different sites.

Each of these system environments will have different user groups and thus will induce different package and possibly different systems cost.

The cost for the implementation project should normally include the following factors:

• cost for the application package modules
• cost for hardware, network, systems software, databases, network management, PCs, printers and other system utilities
• cost for installing and maintaining the different system environments
• cost of internal client resources such as personnel, accommodation, services, utilities, telephone, etc
• external consulting fees and expenses (Consultants, vendor, other)
• training cost for end users, operations personnel and project team members
• any internal allocated charges for use of equipment, eg use of central computer facility.

The client organisation can decide on the level of external consulting support by supplying internal resources to perform parts of the work.  Typically, minimum client organisation participation would be about 25% of total estimated effort to specify user requirements; maximum participation, if the client organisation can run most of the work themselves and Consultant will do project management and QA activities, about 75%.  As a general rule of thumb, external consulting costs for a simple implementation project range in the region of 1½ to 3 times the software cost.

Depending on the specific client needs:

• the need to implement custom functionality within the package,
• implementing interfaces to surrounding or legacy systems,
• Business Process Re-engineering / Improvement and
• Change Management activities

can make the project substantially larger.

Producing the model

The project sponsor and other relevant managers within the client organisation should define and agree the approach to assessing costs and benefits, based upon their normal practices and the practices recommended by Consultant.

The data for the model will normally be based upon the detailed requirement investigations conducted to date.  It may also be necessary to investigate further the detailed costs and benefits, for example to establish the rates to be used for internal and external staff resources.  Any assumptions should be agreed with the project’s sponsor and stated in the assessment.

The results, conclusions and recommendations will be discussed and agreed informally with the project sponsor before being published and agreed formally as part of the Definition of Requirements (DoR) - see Process R150.

It is important that the calculation of the costs and benefits and the preparation of the Benefit Model are not seen as a warranty of specific costs or savings.  As with all aspects of the requirements and selection work, the project team should be viewed as workers, facilitators, and advisers - the needs, evidence and conclusions must be those agreed, accepted by the project sponsor and the other relevant representatives of the client organisation.  It should also be clear in the wording that the figures can only be considered as initial estimates pending the choice of specific components of the solution and the subsequent detailing of the implementation approach.