Determining the Business Impact

Building the Business Case for Groupware

Learning Objectives

After reading this chapter, one should be able to:

· Define an initiative and how it addresses business strategy

· Identify the key stakeholders that are needed to develop a Groupware business case

· Define the importance of analyzing and documenting the current state of business process

· Determine how to qualify tangible and intangible risks and benefits

· Determine criteria and weightings for evaluation of options

· Determine how to properly utilize research results to prepare a business case

Introduction

When tasked with a Groupware project, many teams may tend to directly begin the project before taking the time to develop and structure a detailed business case. This common approach is misguided, as a carefully researched and well prepared business case sets the tone for successful procurement and implementation for a Groupware application. One of the main differences between a business case for Groupware and one developed for an ERP application such as Oracle is the inclusion of a return on investment (ROI) analysis. A case for an ERP system will put the most weight on the financial criteria. Conversely, a case for Groupware places more weight on business process analysis and collaboration benefits. A solid business case lays the foundation for a successful Groupware application. To demonstrate the importance of a business case resulting in a successful project, the following key statistics have been identified from a 2008 survey by CIO.com (Assay, 2008) of 800 IT Managers:

· 62 percent of IT projects failed to meet their schedules

· 49 percent suffered budget overruns

· 47 percent had higher-than-expected maintenance costs

· 41 percent failed to deliver the expected business value or return on investment (ROI)

· 25 percent were cancelled before completion

These figures illustrate the lack of stability that plagues many project initiatives and how a structured business case can help alleviate this instability. In addition, the business itself should own the business case, not the IT organization. In an application initiative, there are three primary stakeholders, all of whom must be thoroughly involved in the development. In Denise Ganly's article for Gartner she outlines the following three stakeholder groups (Ganly, 2009):

· Business process owners – These are the business managers most directly affected by the initiative. One or more of these managers needs to be the driving force behind the initiative and will act as its sponsor. Primary responsibilities include defining business requirements, active participation in defining the solution, and most importantly being the advocate for communication among all involved parties.

· Financial representatives – These are members of the finance group who are responsible for budgeting the initiative. They also provide business executives with clearly defined lines of responsibility and accountability.

· IT organization – These individuals provide the necessary information for making IT decisions. They also ensure a proper balance of roles and responsibilities among the three stakeholder groups. The IT organization’s primary goal is to provide value to the business customer by offering services that lead to competitive advantage, promoting a drive towards continuous improvement, and maximizing investments in technology to improve productivity.

One of the first steps when building a business case is to identify the stakeholders based on the groups identified above. Classification of the size of the project is a good place to begin; does the initiative stand to impact a single department or the whole company? If it is a company- wide initiative, then the business process owner and executive sponsor would most likely be the CEO or COO. If the project is targeted toward a specific department, then a Manager or Assistant Manager would probably be sufficient as the executive sponsor. Once the stakeholders are identified, the selection process can begin for the application initiative team. The individuals chosen for the application initiative team must continue through the selection, implementation and post implementation phases to provide continuity to the project. This continuity provides the organization/department with a deeper understanding of the overall achievement of the project and how the defined objectives will be met.

A typical business case should contain the following sections:

1. Business Case Preparation

a. Situational (current state) assessment and problem statement

b. Project description

c. Solution description

d. Implementation timeline

e. Critical assumptions, constraints, and risk assessment

f. Conclusion and recommendations

2. Cost Benefit Analysis

a. Rules for quantifying costs and benefits

b. Project costs

c. Overview of benefits

d. Identification of benefits

e. Quantifying the benefits

f. Cost and benefit conclusion

One of the main goals of every business case is to clearly illustrate how the initiative will change or improve a current business process. This is especially critical for Groupware initiatives as often times the changes or benefits associated with these projects are intangible and difficult to quantify. The main objective of a Groupware application is not just about cutting lead or production times, rather they are tools that can change internal processes and help employees collaborate. As a result, it is important to distinguish the potential business impact that the Groupware will provide throughout the business case. This concept will be discussed later in this chapter.

When preparing a business case, an organization should undertake a series of tasks in four stages: Initiation, Business Impact, Option Evaluation, and Documentation and Review (see Figure 1). One key point is that building a business case should always be an iterative process. Therefore, research findings and lessons learned should be utilized to continually revisit these stages and update the business case development accordingly.

Figure 1. Business Case Process

Initiation Stage

There are four main items in the initiation stage. This may be the smallest stage in the business case development, but it helps set the foundation for the case. The main objective in this stage is to define the following:

· Business case

· Major stakeholders

· Audience

· Those responsible for writing the business case

Define the Initiative and How It Addresses the Business Strategy

The business case initiative must be defined as clearly as possible and illustrate how the Groupware system will fit into the overall culture of the organization. This is important as the new application must drive business value; otherwise the case for changing the standard business process will not be strong enough to garner approval. The initiative should have clearly defined goals and proposed solutions.

Identify Stakeholders and Business Case Audience and Form the Business Case Team

These three tasks can be discussed in tandem because they have a similar purpose; to establish the target audience of the business case and who will complete the preparation. The business case team should involve the business process owners, financial representatives and IT organization. This phase will also help identify the executive sponsor and any other key stakeholders.

In all business cases, choosing the team is very important but it is especially important for a Groupware application initiative. As Groupware is not for all companies, the project team should include a mixture of members who understand the software and how it will impact the organization and improve business processes. Also, as Groupware generally provides initial intangible improvements, it is often difficult to provide an estimated ROI to the stakeholders. Therefore the number of financial representatives required may be low. It is also important to ensure that some members demonstrate collaboration and facilitation skills, as these will play an important role in building the business case. Team members will not only develop the business plan for collaboration software, they will also need to use it, and this will help build a deeper understanding of the process.

The next step in the process involves stakeholder identification. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. The project team must identify the stakeholders, determine their requirements and expectations and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project. Roles must be developed in this stage as well, and all stakeholders should understand their purpose on the case. If stakeholders do not know the roles they will play, then this could lead to internal issues and miscommunication. All in all it comes down to a very simple concept; the business must own the project.

Determining the Business Impact

In this stage of the Business Case development process the focus is accurately accounting for the overall impact of the proposed initiative to the organization's core business processes. A major function of the business case is to justify the expenditure, or need, for the initiative in the first place. In order to effectively quantify the benefits you need a clear view of where you currently are, where you'll be after the initiative, what the benefits are and, of equal importance, what the risks are to undergo implementing the initiative. In Denise Ganly's article for Gartner (Ganly, 2009) she outlines a 3 step approach for undergoing this stage: 1) Document the current state. 2) Determine the future state and 3) Quantify the benefits and risks.

Documenting the Current State

The goal for this step is to determine the current state of any and all business processes that will be affected by the initiative and identify the existing applications, if any, that support them. Of note this also includes gathering documentation on the current IT strategy and architecture as well as evaluating the initiative in the scope of other in-progress projects or planned initiatives (if they should exist). Remember, the focus of this stage is to objectively measure the business impact of the imitative to the overall organizations goals. A macro view of the company is more helpful at this stage than the opposite.

In many cases you may find that this information is non-existent or out of date requiring you to devote significant effort to establishing the information you need; but without this information you can not get an accurate baseline to measure improvements against. One of the more important areas of focus should be constructing or updating process maps.

In the business world process mapping is similar to what you see in the software world. The goal is to identify, for each business process, the step-by-step function of how you get from the start to the finish. For example, in an accounts receivable office the primary function is to bill, or invoice, for services or goods rendered by the organization and to make sure that those invoices are then paid in a timely manner. The process map for this function would track step by step how this is currently accomplished (Figure 2). In addition to a simple map it should include information on how many people complete each step, how much time it takes per step and overall, what applications they currently use, what other departments are utilized during this process, etc.

It is a fine line between dedicating the time for a proper analysis and wasting time on too much detail. It is easy when you begin this stage to explore more and more processes as you delve deeper into the affected department(s) but it is important to remember that documenting the current state is only one small part of the overall business case development process. Ganly (Ganly, 2009) recommends you restrict your efforts to, "processes that drive competitive advantage, support regulatory or compliance needs, or provide unique functionality" and that you "should not spend more than 15% of the estimated effort for the project in completing this task."

In addition to process mapping it is also extremely important to gather traditional accounting metrics. What metrics you use are highly dependent upon the processes you're trying to improve. We will discuss this more in a moment but it's safe to say the biggest of them all will almost always be Return On Investment (ROI) also known as Rate of Return (ROR). ROI is simply defined as the ratio of money gained or lost on an investment relative to the amount of money invested (http://en.wikipedia.org/wiki/Rate_of_return). Simply put, what does the organization gain in dollars in return for the money spent deploying and maintaining the initiative? It is important to pick the metrics at this stage because you will use the same criteria to show improvements when you move into determining the future state.

Determining the Future State

Now that you have clear process maps and you have selected and computed your accounting metrics you have effectively established your current baseline. The next step is documenting the proposed future state. This is the state envisioned at the start of the business case process and consists of not only the new process but also any new applications to facilitate these processes.

You want to develop your future state to the same extent as you developed the current state. This includes process mapping to the same level. Also evaluate your future state using the same accounting metrics you selected for your baseline. Most importantly talk to the people directly affected so that you can get their input on what you have planned. They'll best be in position to tell you how feasible a change is or how accurate they think your numbers are.

As you move forward and develop the metrics it is important to keep up with documentation and create an audit trail. This is important so that you can demonstrate to key stakeholders the rationale behind how you came to a certain conclusion. This not only makes it easier for those outside your team to understand but also allows you to easily update your metrics should new information arise.

Quantifying Benefits and Risks

Now that you have a well developed picture of the current state and a clear idea in mind for the future state you can begin to do the comparison analysis. Looking at the gaps between the current and future states give you a good start on identifying the benefits of your initiative. The benefits of any initiative can be hard to measure but especially so with groupware projects that are largely new and just becoming mainstream. Even so there are still three basic categories you should divide their benefits into: Strategic Business, Hard Financial and Soft Financial.