Creating an Enterprise Software Business Case

Buying, implementing, and operating enterprise systems can easily run into millions of dollars, which does not even include the “soft costs” and organizational disruption that often occurs during implementation.

A strong business case helps ensure that you select, buy, and implement the best system for your particular needs. The best business cases go beyond financial projections, to describe opportunities and facilitate conversation around the organization’s strategic goals and objectives.

Many organizations do not adequately link business requirements and expected outcomes to their enterprise software purchase. A good business case can help establish this link and create a solid foundation for achieving enterprise software success.

The business case for enterprise software typically includes six components:

• Problem definition
• Value proposition
• Recommended solutions and alternatives
• Financial analysis
• Timeline
• Risk factors

Problem definition. Although enterprise software is a capital expenditure similar to other large investments, it has an intangible aspect that often causes confusion. As a result, many organizations implement software without clearly, and realistically, defining the business problem.

To overcome this obstacle, the Association for Operations Management (APICS) suggests you quantify the business pain as a “need to change.” Look across your organization to prioritize specific areas of inefficiency you want the new system to address. Examples might include slow reporting of financial or inventory information, redundant or inefficient processes, and so on.

Although the reasons for considering a new system are unique to each organization, it is always important to understand and enumerate the pain points. These organizational pains ultimately dictate the roadmap for selecting, buying, implementing, and measuring results from the new system.

Benefits and value proposition. Having determined the business requirements, the next step is formulating the value proposition. The value proposition should directly address the business challenges determined earlier. A Gartner presentation on this topic suggests considering the value proposition from the perspective of multiple roles in the organization: Executives, LOB Heads and Managers, Partners, Customers, Project Management, and End Users.

For each of these roles, examine the business challenges to the expected benefits you hope the software to deliver. By working this way through all relevant departments in the organization, you can assemble a comprehensive and clear list of challenges and solutions on which to base the value proposition.

Search for potential benefits in areas such as:

• People
• Process
• Technology
• Management
• Infrastructure

Most importantly, create a value proposition that makes practical, business sense to people across the organization.

Recommended solutions and alternatives. Once the organization gains consensus on the business pains and desired reasons for implementing a new system, it’s time to evaluate solutions and vendors.

When examining potential solutions, consider issues such as:

• Ability of the proposed software to address the specific challenges defined in the problem statement.
• Fit with the vendor’s target market; for example, a small process services company should not buy a product aimed at large discrete manufacturers.

Researching solutions is a time-consuming process in which the customer can easily fall prey to underhanded or manipulative sales practices from vendors. Although most enterprise software vendors are honest, an element of buyer beware should prevail. For more on this, see my ZDNet blog post, "Seven common lies told by enterprise software sales people."

Given the need to ensure a good match between company needs and vendor capabilities, I suggest getting assistance from a qualified external consultant or analyst. When selecting a consultant to help with vendor selection, find someone independent who will work for your interests. Avoid consultants who are primarily funnels for business to software vendors.

Financial analysis. Finances are the heart of a typical business case. The financial section should clearly state all assumptions on which you have predicated the desired return on investment. It is also important to include a sensitivity analysis, to help ensure that the financial assumptions behind that ROI model are realistic.

When developing financial projects, be aware that overall project costs go far beyond the software license fee. Be sure your financial plan considers all these items:

• Software license fee
• Software maintenance and support
• Implementation consulting
• Internal resources that must be applied to the project
• Change management
• Training and documentation
• Hardware and other infrastructure

Timeline. Despite the importance of accurate scheduling, statistics tell us that most projects run late and over-budget. This fact underscores the need for matching business case goals to practical steps required to achieve desired outcomes. Late projects can have a strong negative impact on your intended ROI, which again reinforces the need for careful planning.

Risk factors. Complexity is the primary driver behind most project risks. This complexity arises because enterprise software deployments typically involve multiple departments and business processes across the organization. Consequently, the software must meet a diverse range of business needs and satisfy many different voices.

Off-the-shelf software may not perform all possible functions that the organization demands, so you may be tempted to write custom code. Most organizations should avoid custom code of this type because it substantially increases project risk and cost.

Other common sources of project risk include inadequate change management and failure to define requirements properly at the project start.

ALTERNATE VIEWS

Although conventional wisdom generally dictates the importance of a full business case, some observers suggest caution. In response to this question that I posed to the Focus.com community, “Why is a business case necessary before implementing CRM or ERP?”, several commenters described common pitfalls associated with the standard business case.

One commenter, social CRM consultant Wim Rampen, explains that some organizations use a detailed business case to justify bad decisions:

Business cases (and even business plans) are mostly written to justify the choices already made and to ensure that there is budget, which will always succeed.

These days you’ll likely need to make 5 to 10 year projections, apart from all the risk-assessments and alike, which of course is absurd. So what happens is that people put in the wildest of expectations/projections and a good list of assumptions on which the projections were based. In the end you have written a full PhD-thesis. Something really nobody likes to read, and does not have to read, because the decision was already made in the first place. And people really don’t start doing all the work if the result is highly uncertain.

Worst thing: I have never seen any CxO or senior manager evaluate the business case after let’s say a year, or two years. Let alone after the 5 or 10 years. Within the next annual budgeting round, the costs will be seen as fixed/planned costs and people will start dumbing down their expectations because of numerous externalities that were not in the business case. But nobody notices, because the DMU has moved on to another job ;)

A business case helps expose the true costs, benefits, value, and risks associated with large IT investments. Developing the plan can force your organization to gain greater insight, understanding, and alignment among stakeholders, which is perhaps the most critical ingredient for achieving project success.