Business Case - Business Process Improvement

A major component of any consulting job is the development of a clear understanding of the payback for the investment a client will be making. Regardless of what a client 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 consulting engagements 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 and 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 is 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 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 organisation 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, such as SAP, Oracle or Microsoft Dynamics.  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 organisational 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 a consulting engagement perspective, a business case has several critical objectives:

• It is a vehicle to document and gain agreement within the client’s organisation on the value of the business benefits associated with change, including changes such as business process re engineering, information technology implementation, organisation 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 client 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 clients view 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 organisation 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 organisation who implement change and achieve identified benefits. Therefore, identified benefits need to be agreed to, and achieved by, the organisation.  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 organisation 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 mobilises the organisation.  It is the process which defines the expected impact of an implementation or change, and establishes the measures which the organisation 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 measureable.  Business cases often contain stated benefits that are either unquantified 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 organisation’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.

Mobilisation Plan

The “Program Repository” is a significant program management support tool which serves as an “umbrella” document that houses all project planning materials (i.e. contains phase-by-phase descriptions of all activities undertaken during the BPI program). It takes the form of a "live" planning binder to which additional, more-detailed sections (e.g., Mobilisation, Migration and Implementation Plans) are added with each new phase of the BPI initiative.

The “Program Repository” provides a comprehensive account of all decisions relating both to the “what” and the “how” of the BPI initiative. It thus integrates the “technical” aspects of BPI (e.g. assessment and design deliverables) with the “relationship” aspects of achieving stakeholder commitment (e.g. partnership with the organisation, and employee-involvement strategies).

The “Program Repository” begins with the Mobilisation Plan, which relates primarily to the Envision, Focus and Design High Level phases, and is normally developed with the organisation as a result of a CEO and/or leadership team “arousing” process.  While additional planning details are added to the “Program Book” as the BPI program moves through its successive phases, there are two fundamental “shifts in emphasis” during the BPI program.

The first shift occurs while Design High-Level activities are being completed, when the organisation is beginning its migration towards adopting the new way of doing business.  At this point, the Mobilisation Plan is reassessed and updated (based on all current information) and the Migration Plan is developed.  Later, as the organisation completes Build activities, its focus shifts towards implementation activities.  At this point, the Migration Plan is revisited and revised, and Implementation Plans are developed.  As part of day-to-day project management, the three major plans are supplemented through the use of one or more project management techniques (e.g., Plateau Planning, Work Packages).

The diagram above illustrates how the BPI initiative begins with a Mobilisation Plan that is “fleshed out” in more detail as it evolves into the Migration and Implementation Plans.  This process of evolution  reflects the natural movement of major organizational change from an initial idea to concrete reality.

Description

• The Mobilisation Plan is the first section of the “Program Book”.  It contains a high-level outline of all phases, the anticipated milestones of the project, and an initial detailed description of the activities conducted in the early stages of the project.  The Mobilisation Plan also incorporates an initial employee involvement strategy (or “Change Leadership Model”) agreed by the CEO and the leadership team.

Organisation Value

• A comprehensive Mobilisation Plan  assures the organisation that all important steps are being addressed.  It enables the organisation to gain consensus and share ownership of the overall project scope, the upcoming phases’ objectives and subsequent activities.
• The decision on an initial employee involvement strategy, or change leadership model, prepares the leadership team for the challenges of guiding employees through a major change.
• Omission of the Mobilisation Plan presents a significant liability to the organisation. Without this plan there is a serious risk that the project will not be completed on-time or within budget, or will not be completed at all.  If expectations are not clearly aligned within the organisation, both will fail.

Approach

1. Review/validate the content of preceding proposals and/or discussions with the client.
1. In some cases, project planning activities (or a subset of these activities) have been conducted as part of the proposal process.  Where a formal proposal process has not occurred, discussions will precede the development of the Mobilisation Plan.
2. Discuss with the CEO and the leadership team alternative approaches and strategies for involving people and leading them through the change process.
1. Visits to/from other organisations to discuss their experiences with large-scale change, and the negative and positive consequences of different degrees of employee involvement, are often highly beneficial.
3. Facilitate consensus of the leadership team regarding the most appropriate strategy for employee and stakeholder participation.  This step has a direct impact on how the BPI initiative will be,and alerts the leadership team to the necessity of team cohesion and consistent communication.
4. Create a draft project plan.
1. For the entire project (end-to-end), elements include:
1. project scope and overall objectives
2. preliminary timeline showing all project phase.
2. For the first phase (or immediate next phase) elements include:
1. activity descriptions, duration and milestones
2. specific resources required to complete activities\
3. dependencies (or required predecessor tasks) associated with each activity.
5. Review plan with team members to ensure feasibility and obtain commitment.
6. Review plan with the CEO and/or the leadership team, revise if required, and obtain sign-off to proceed.

Guidelines

Problems/Solutions

• Keep the project plan simple and crisp.  An overly-complicated plan may cause confusion and frustration for the project team and client organisation.  It should be user-friendly and easy to communicate.
• If the organisation is unfamiliar with collaborative or participative employee involvement strategies, provide additional coaching and support on the implications of such strategies upon project plans.  As required, adopt different strategies for different parts of the organization.
• Participative strategies, providing they are well-managed, have the highest likelihood of embedding change in the long term.
• Use realistic time and resource estimates so that the project plan is a management tool rather than a “straight-jacket”.

Tactics/Helpful Hints

• Start by identifying outputs on the timeline; then identify tasks and required resources.
• Identify integration points with other related processes, departments or on-going projects and build relationships into the project plan.
• Work as closely as possible with the organisation sponsor in establishing the project plan.
• Use project plans from previous engagements in similar industries and/or companies of similar size.  These are valuable sources for information, standards, etc. during the course of project plan development.
• The Mobilisation Plan provides an invaluable opportunity to build a robust relationship with the CEO and the leadership team.  It provides the framework and a mechanism for controlling how resources are deployed, and for accurately gauging and reporting on project progress to the client.

Resources/Timing

• The Organisation Project Manager must spend significant time in developing the project plan to assure that it satisfies contractual requirements, includes all necessary steps, and deploys project staff effectively.
• The Project Manager needs expertise in managing BPI engagements of organisations of similar size and industry.  It is critical that the manager have expertise in the methodology to such an extent that he/she clearly understands all of the intended outputs, requisite inputs and their interdependencies.

Work Packages

Description

• Work Packages are detailed, project-workstep descriptions for small, separable groupings of activities within the BPI programme.  They serve as “turn-key” terms of reference describing work that may be assigned to a project workteam.  Work Packages are often used in place of Design Charters to specify activities of a subteam undertaking the implementation of Quick Wins.

When to use

• Work Packages can be created whenever a grouping of logical, interdependent work tasks is identified as “ready for assignment” to a workteam.  The actual date of assignment to a team may not be immediate and will depend on the timing of other interdependent activities.

Approach

An ongoing “laundry list” of suggestions for potential Work Packages is compiled over the course of the program.  The suggestions are reviewed at regular intervals and developed into detailed Work Packages, as appropriate:

• On an on-going basis, obtain suggestions from project team members and technical specialists for separable groupings of change/ implementation activities,
• For each logical grouping of activities, develop a separate Work Package that outlines:
• Objectives—specific goals.
• Outputs—expected results.
• Dependencies—other Work Packages whose results are interdependent.
• Worksteps—activities required to complete the Work Package.
• Resource Requirements—the skills and estimated time requirement of resources.
• Schedule—the estimated elapsed time frame for completion of the Work Package.
• Implementation Issues—Potential hurdles or risks associated with completion of the Work Package.
• Review the Work Package with appropriate decision-makers.  Modify as required.
• Include the Work Package in the appropriate section of the “Program Book” (i.e. as a supplement/ enhancement  to a Mobilisation Plan, Migration Plan or Implementation Plan).
• Identify the Work Package manager who will be held accountable for its successful completion (or a future candidate if the Work Package is to be commissioned at a later date).

Guidelines

Problems/Solutions

• Projects have a high risk of failure as they enter implementation.  Reduce this risk by developing and allocating Work Packages as early as possible.

Tactics/Helpful Hints

• Work Packages can be developed as soon as logical groupings of change activities are identified.  They may be assigned immediately to an accountable work package manager, or retained in a database and then commissioned at some later date.  By "stock-piling" Work Packages on an on-going basis, the organisation has them ready to draw down and commission without losing time.
• Create a single Work Package that governs the management/coordination of all other Work Packages (e.g. management all Quick Win implementation activities).
• The development of Work Packages usually requires several iterations with team members and management to ensure completeness (i.e. to avoid gaps and duplicated tasks) and the proper timing of dependent activities.  Accordingly, it is advantageous to assign the initial development of a Work Package to a single individual as soon as it is identified as a logical grouping of activities.
• Organisations may insist that detailed Work Packages be developed prior to presentation of the Committed Project Results and Budgets in order to ensure that all anticipated costs have been included in the total implementation cost estimates.
• Technology-related Work Packages often span a migration period of twelve months or longer.  There are, however, significant changes that can proceed without major technology alteration; the benefits of these should be derived as soon as possible.  Accordingly, non-technology dependent work packages should be commissioned early.

Examples / Templates

Example #1 illustrates a “laundry list” of potential sub-projects (from which work packages would be created) for a series of human resources-related processes (e.g., pay/benefits, staffing process, etc.).

Projects that must be completed to implement redesigned processes include:

1. Develop generic job specifications
1. With first page summary for posting purposes.
2. Standard clauses for posting
2. Develop staffing toolkit
1. Update/harmonise guidelines, document best practices, do’s and don’ts --         Develop checklist for process
2. Provide format for documenting selection justifications
3. Provide letter of offer templates
3. Establish CV database
1. Determine criteria for inclusion
2. Set up mechanism to ensure scanning of all recall/priority candidates
4. Develop classification toolkit
1. Document classification guidelines, checklist for process
5. Equip HR with an automated telephone answering service
1. Determine appropriate information and messages to be communicated
6. Develop comprehensive orientation package for new employees
1. Harmonise benefits/orientation package between two company locations
7. Develop salary administration toolkit
1. Harmonise compensation guidelines and document
2. Document checklist for process
3. Provide template
8. Develop termination toolkit
1. Document guidelines, checklist for process
9. Negotiate changes to collective agreements
1. eliminate pay exceptions
2. reduce differences in benefit coverage, coverage codes
3. convince unions to handle the administration associated with “bumping”
10. Negotiate changes with insurance carriers
11. Communicate changes to employees, line managers and unions
12. Train line managers in new process, new system, roles and responsibilities.
13. Develop workforce adjustment strategy for HR-transactions staff
14. Classify/staff positions within HR-transactions group
15. Train HR staff
16. Develop and implement support technology.

Example #2 outlines the migration Work Packages used in redesigning the “core process” of a small agency (200 employees) that distributes funds for research grants: Making Grant Decisions and Delivering Payments. It includes a Gantt Chart highlighting all migration activities as well as two sample Work Packages

Work Package 2:    

Redesign application forms & supporting information package

Objectives

To produce a simplified application form and information package that will minimize the amount of information required from the applicant, and the amount of time applied by both the applicant and Agency staff.

Deliverables

• Mandatory core application information requirements, standard across all programs.
• Mandatory program-specific application information requirements and support materials.
• Applicant "self-test" checklist to support self-screening of eligibility.
• Sample completed application form for clients to consult in completing their applications.
• "Did you remember" checklist for applicants in reviewing their application for completeness.
• Standard memorandum "to the applicant" describing the use of the "self-test" and the "did you remember" checklists, the policies regarding late submission of applications, return of supplementary documentation, tapes, etc., the Agency’s services for providing assistance to applicants and the Agency’s mechanisms for responding to successful and unsuccessful applicants.
• Question/answer sheets for common inquiries.

Dependencies

This work package can be initiated immediately.  Completion will require full approval of new policies (Work Package #1).

The deliverables must be provided to managers of the technology work packages.

Major Worksteps

1. Develop strawman of minimum mandatory application information requirements, both standard and program-specific.  Identify which information fields, if any, will not be directly accessible by computer for any staff member to change.
2. Review strawman with representatives of the Agency’s finance section and auditor.
3. Review strawman with representatives of each program.
4. Revise and present to management for approval.
5. Design one standard "fill in the blanks" form follow-up letter for notifying early applicants of incomplete information.
6. Design self-test checklist to determine applicant eligibility, by program
7. Prepare sample completed application forms.
8. Design "did you remember" checklist for applicant to review completeness of information
9. Prepare standard memorandum "to the applicant" on application policies and protocols for inclusion in all application information packages.
10. Communicate revised application forms and information package to all staff.
11. Communicate reasons for revised tools to clients, and request feedback.

Resources

• Work package manager (WPM); approx. 0.5 days per week for 4 weeks.
• Application Design and Analysis Team (ADAT); 2 people for approximately 3 days per week over 4 weeks.
• Program representatives
• Finance section representatives
• Representative(s) from auditor.

Schedule

• Elapsed time:  4 weeks.

Implementation Issues

It is expected that there will be periodic revisions to the grant application forms and information package as programs and eligibility criteria change with the needs of the research community.  The outputs of this work package, therefore, must be positioned to reflect the minimum mandatory information given today's programs.  The gains derived from this work package are large.  Work packages for redefining programs and eligibility criteria can run in parallel, but should not hold up completion of WP#2.

Re-education of clients will be critical to success in using the revised tools produced in this work package.