Investment in upgrading, or the aquisition of a major, Application Software Suite

Application Software Investment - Business Case

Overview:

A major component of any Investment in upgrading, or the acquisition of a major, Application Software Suite is the development of a clear understanding of the payback on the the investment.  Regardless of what an Organisation is focused on - re-engineering business processes, implementing a new application system or restructuring an organisation - cost will be involved.  The question that is being asked more and more often is “What will be the return for this expenditure, or investment?”.

In the past, many organisations were sold on the basis of managing the cost component of a project.  If companies did address the benefit side of a project, it was often based on an intuitive understanding of the benefit which might be achieved based on a given change.  From a cost perspective, methodologies became key enablers of “project cost containment”.  In fact, the development of methodological approaches to re-engineering, upgrading or replacing information systems development was often driven by the need to have a defined, manageable process for implementing change and managing the cost side of a project.  As methodologies matured over time, many began to focus on the benefit component of change.  Methodologies often included the implementation of business performance measures which are used to communicate the impact of the change to the organisation.  However, what was still missing was a clear understanding of, and agreement on, the goals and objectives associated with the defined changes.  A business case is the technique which develops this understanding.

This ability to deal with projects from an investment rather than a cost containment perspective becomes even more significant as the scope, potential impact on the organisation, and the cost of projects increase.  For example, consider a re-engineering process which is focused on streamlining a company’s warehouse management processes.  The scope is reasonable limited, the project is typically short in duration, and the cost to the company for external consulting support and internal resource commitment are limited.  From a benefits perspective, the company might typically look to a reduction in cost, but as the project was limited in scope, the expectation would likely be modest.  In effect, the business “risk” is relatively low, therefore the need for a clear cost benefit is reduced.  Now take the same company, and consider the impact if the objective was to re-engineer the customer value chain, including re-engineering customer facing processes, implementing sales force automation technology, and establishing customer “partnerships”.  The time required to design and implement the changes is significantly greater, the required commitment of resources is much higher, and the potential impact on the business goes beyond simple cost reduction, and begins to drive improvements in revenue growth and asset management.  In this example, the business “risk” becomes much higher, therefore the need for a clear cost benefit is significantly greater.

Consider another example.  In the 1970’s and 1980’s, many companies implemented integrated application software such as MRP II systems.  These systems were typically site specific, and impacted business functions associated with the planning, scheduling, production and shipment of products.  The impact on the organization was reasonably high, and the cost could easily be in the millions of dollars.  However, even with this level of expenditure, business cases were often ignored, or developed at a high level, with a focus on subjective, non-quantified benefits.  Compare this scenario to the situation today for a company that is planning to implement an integrated enterprise wide system.  Not only is the scope much broader, often touching all components of a company’s value chain, but the costs can easily be $20-30 million or higher, depending on the geographic and organizational scope of the implementation.  Suddenly, there is a much greater need for a clear understanding of what the return on this level of expenditure will be.

From an external consulting engagement perspective, a business case has several critical objectives:

• It is a vehicle to document and gain agreement within the organization on the value of the business benefits associated with change, including changes such as business process re-engineering, information technology implementation, organization alignment and restructuring and business rationalization (products, facilities, etc.).
• The business case is used to establish achievable targets for business performance improvement associated with the change.
• It is the technique used to develop the perspective of the project as an investment, rather than a cost, by relating the implementation requirements to quantified business benefits.
• It is an approach which provides the organisation with a clear payback/return on investment profile.
• The business case establishes the business performance baselines and goals which are used to evaluate and drive any change.

There are several critical points within these objectives.  First and foremost, developing a business case impacts how the organisation views and deal with change.  Rather than looking at projects as a necessary cost of doing business, or something that is the latest rage or trend, companies begin to view and evaluate projects in terms of what they will specifically return to the organization for the money spent/resources committed.  Second, once this payback is understood, performance measures can become true drivers for change. Clear goals and expectations can be shared and communicated to the individuals within the organization who will be responsible for implementing change and achieving the performance improvements.

Third, it is people within an organization who implement change and achieve identified benefits. Therefore, identified benefits need to be agreed to, and achieved by, the organization.  Note that the purpose of a business case is not to set “stretch” goals which individuals have little hope of achieving.  Rather, the business case is focused on setting realistic goals which people in the organization agree with and which they are measured against.  Viewed from this perspective, the development of a business case can be seen as a process which engages and mobilizes the organization.  It is the process which defines the expected impact of an implementation or change, and establishes the measures which the organization will use to monitor and measure success.

Finally, as achievement of benefits will be measured and monitored.  it is important to ensure that the business case contains quantifiable benefits.  This is not to suggest that all benefits contained in a business case must be quantifiable and measurable.  Business cases often contain stated benefits that are either unqualified or intangible.  The table below suggests typical benefits which could be components of a business case:

The challenge in developing a business case therefore is not to identify only those benefits which can be quantified and measured, and which will result in a bottom line impact on the organization’s P&L or balance sheet.  Rather it is to identify and document the benefits people believe will be achieved, regardless of whether they are quantified or unquantified, tangible or intangible, while at the same time keeping the focus on those results which will yield true improvements in business performance improvement.

Inputs & Outputs:

The business case process typically parallels an analysis process, be it Business Process Re-engineering, Software Selection and Implementation or Enterprise Technology Planning and Design.  Each of these methodologies/project approaches has a specific perspective on what project work looks like.  It is up to the individual who is designing the specific project plan to determine where, when and by whom the necessary business case development work will be done.

As an example, the following chart outlines business case development activities and their relationship to a high level Business Process Re-engineering project methodology.

The financial baseline development is the financial equivalent of developing an operational or systems understanding of the current environment.  The opportunity quantification is the translation of improvements in operations based on re-engineering and/or systems implementation into expected financial performance figures.  Finally, the business case development itself takes the investment documented in the implementation plan, the financial benefits documented in the previous steps, applies timing and risk assessment factors, and presents the implementation project in agreed on financial terms.

There are several critical interface/integration points throughout the project.  The financial baseline is typically very broad, as it is important that the team understand the financial performance of the company from a holistic perspective.  The financial baseline also provides the team with a focused understanding of where the areas of high potential dollar benefits are.  The second step, Opportunity Quantification” is dependent on input from the “As-Is”, To-Be” and Opportunity Identification steps.  Opportunity Quantification ensures there is clear agreement on the identified opportunities, the assumptions around the impact of achieving the opportunity, and agreement on the calculation of the financial benefit.  Once these three areas are clear, the development of business benefits becomes a reasonably straight forward mathematical calculation, starting with the financial baseline and applying the agreed on calculation.  In addition, the assumptions provide the basis for identifying when the benefits will be realized.

The final step, business case development, requires input from the implementation planning activity.  Implementation planning delivers the cost component of the business case by identifying the resource requirements and the expected timing of the respective requirements.  As noted above, the specific format of the business case will often be dictated by the client specific requirements for project authorization and approval documentation.

Business Case Development

As noted above, the development of a business case typically parallels  traditional analysis and definition activities.  As such, the business case development is part of an analysis as opposed to a stand-alone effort.  However, when developing a business case, the following are typical  activities which need to be integrated with process and/or technology definition work.

Activities & Tasks:

• Identify/confirm the required financial justification required by the Organisation (for the specific type of investment anticipated)
• Review Organisation’s justification requirements with client project sponsor and others as required (i.e., financial organization)
• Identify key client decision makers who will be involved in final approval of results delivery or implementation project
• Review previous project justification documentation
• Develop straw-model business case framework (ROI, IRR, payback, etc.)
• Develop straw-model executive review and authorization process, including timing, sequence of communication, individuals involved, etc.
• Review/validate business case approach with client management team (i.e., Executive Steering Committee)
• Develop/confirm Organisation’s financial baseline
• Gather necessary financial baseline information, including expense ledgers, performance reports, balance sheets and other available reports as required
• Develop summarized financial information baseline as required
• Develop financial profile consistent with the agreed on business case framework (for example, if ROI is to be used, the team can develop a current ROI model as well as a “proforma” future ROI to indicate the magnitude of change which would be required)
• Review and validate current financial baseline with appropriate client personnel and executive management team members
• ¸Develop and review required business opportunity charts with project team members
• Develop opportunity chart, highlighting information required, standard documentation format, types of calculations, etc.
• Review opportunity charts with project team and gain agreement on use of charts within the overall project work plan and the due date for completed charts, by project work stream/sub-team
• ¸Develop opportunity charts
• Complete opportunity charts during the course of key analysis and definition tasks; information includes such items as:
• Opportunity description
• Analysis findings which support the validity of the opportunity
• Calculation used to derive the opportunity
• Assumptions around the opportunity and/or calculation
• Measurement which would be used to evaluate the achievement of the benefit over time
• Confidence level
• Validate opportunity information with appropriate Organisation’s personnel
• Review and validate opportunity information with client individuals who will be accountable for delivering the defined benefit(s)
• Consolidate opportunities identified by the team consistent with the defined business case format
• Consolidate opportunities as required
• Review and validate with team members
• Pre-present business case information with decision maker(s)/Executive Steering Committee
• Plan and schedule one-on-one review sessions with appropriate decision maker(s) and/or Executive Steering Committee
• Conduct pre-present sessions
• Update and re-validate opportunities and business case with appropriate client personnel as required
• Develop and present final business case to client decision maker(s)/Executive Steering Committee
• Develop final business case documentation
• Present to client as planned

Deliverables:

• Agreed on financial justification documentation
• Financial baseline
• Validated opportunity charts
• Validated business case

Suggestions:

• A critical success factor is to ensure that the business case is developed consistent with the Organisation’s required justification  process, including the required justification methodology, information granularity, presentation format, etc.
• Develop and confirm the financial baseline very early in the project.  It provides the team insight into the potential magnitude of opportunities based on current financial information, which in turn directs analysis activities.  It also helps identify additional financial information gathering which will be required.
• Lay out the opportunity charts early in the process.  This will allow the project team to begin filling them in as they go through the analysis, rather than waiting until the end of the analysis to try to recreate the required information.
• Pre-present business case information in individual sessions with decision makers and/or Executive Steering Committee members.  If any changes are recommended/suggested, be sure to reconfirm with necessary individuals prior to the final presentation
• The final presentation of the business case should be a group confirmation of the benefit associated with subsequent implementation efforts.
• An effective business case development typically requires that one team member have accountability for it’s development.  This individual also develops the financial baseline and the opportunity chart format, and assist team members in completing and validating opportunity charts with client personnel.