The Business Case Document

I’m trying to get on a roll providing our readers with some hopefully meaningful samples and templates of documents that may be needed on their projects.  These are templates that I created a few years ago – basically from information I think I probably found somewhere else…(isn’t that always the case?).

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.

A Discussion on Project Management Methodologies

I like what Jason Charvat has presented in terms of Project Management methodologies in his book “Project Management Methodologies – Selecting, Implementing, and Supporting Methodologies and Processes for Projects.” He basically goes by the same premise that I do – there can really be no standard methodology to be utilitized to fit most or all projects – hybrid methodology must exist. Your methodology must fit what you do, who your customers are, and what your capabilities are.

Project Methodology Overview

Key decision makers must often determine whether a universalized project life-cycle methodology is sufficient for all their projects. The answer to that question is an unequivocal no! Very few people are capable of creating a state of-the-art, concisely defined, phenomenally small, highly prescriptive, measurement-intensive, fast, and cost-efficient methodology allowing project managers greater performance improvement (consisting of an expertly designed/optimized family of policies, procedures, plans, specifications, forms, logs, and metrics). Every company has its own process flow diagram. This flow originated from a methodology created to ease implementations of new technologies or new project ideas. These process flow diagrams have many different stages, all similar in nature.

Even dynamic project-based organizations such as Accenture, KPMG, Deloitte Touche, RCG Information Technology, Bechtel, and Keane are far more than a collection of individual projects. If that were all they were, they wouldn’t be multimillion-dollar organizations. They all use various arsenals of project methodologies for each solution they undertake. Companies are becoming very much like small film studios. Each project is a “movie” all by itself and has its own “director” and “script.” The movie needs project funding to begin and is short lived; project teams are also short lived, and, amazingly, in this brave new model, they follow a unique project methodology, because if they don’t, no one will invest in a “movie” or project. Therefore, projects need to be innovative, they need process, and they need to adhere to the “script” or methodology. Each movie script is different from the next; this is where we focus our efforts throughout the book.

By simply assessing those project methodologies that exist today, we see that a universal project approach simply won’t work. The main reasons that a single “be-all-and-end-all” methodology won’t work from industry to industry are differences in:

• Life cycle
• Market sector
• Product
• Size
• Technology
• Situation

For instance, a nuclear plant or space shuttle project has very specific heavyweight life-cycle components (e.g., work breakdown structure, activities, tasks, task durations, priorities, skill sets, and economics) compared to a small construction project. In other words, they use different phases and activities on their projects (i.e., communications and navigation equipment, operating systems, and a variety of technologies).

In addition, the life cycles for construction projects (e.g., bridge building), compared to information systems projects (e.g., three-tier architectures), may be vastly different from one another. This means much tweaking is needed if you have to accommodate every kind of project. Hence, different methodologies are needed. Therefore, we have a catch-22 situation—various technologies and industries make it very challenging to design a one-size-fits-all project life cycle. It does not seem likely that an individual project manager or executive can actually design a highly operational, functional project methodology that meets the needs of every single project—irrespective of its technology or industry. Hence, some creative genius is needed to bridge this gap. A project life cycle is, therefore, a collection of project phases. Project phases vary by project or industry, but some general phases include:

• Concept
• Development
• Implementation
• Support

Remember that products also have life cycles. Many companies have project managers or executives who are unwilling to follow systematic project methodologies all of the time. Instead, they tend to rely on standard business activities to get them through the project. They are simply trying to keep up with all this talk of project methodologies and associated processes and techniques. Questions such as “Why are there so many methodologies?” and “Which one do we use?” often arise. Over the years, even those involved in managing projects have observed that projects have common characteristics that can be formalized into a structural process, which allows them to manage projects more effectively.

Each phase can typically be brought to closure in some logical way before the next project phase begins; and each phase results in discrete milestones or deliverables, which provide the starting point for the next phase. Project methodologies should be structured to take advantage of the natural phases that occur as work progresses. The phases should be defined in terms of schedule and specific accomplishments. Define how you will know when you have finished each phase and what you will have to show for it.

Cost and schedule estimates, plans, requirements, and specifications should be updated and evaluated at the end of each phase, sometimes before deciding whether to continue with the project. At times, you may want to hold off or cancel the project. Large projects are usually structured to have major program reviews at the conclusion of significant project phases. These decision points in the life of a project are called major milestones. The figure below shows how project phases are somehow linked to one another. This is the basis of how project phases, once incorporated, form a typical project development methodology.

Figure: Depiction of general project methodology phases.

Milestone decisions are made after conducting a major program review in which the project manager presents the approved statement of requirements, acquisition strategy, design progress, test results, updated cost and schedule estimates, and risk assessments, together with a request for authorization to proceed to the next phase. The early project phases tend to shape the direction for all further efforts on the project. They provide requirement definitions, evaluation of alternative approaches, assessment of maturity of technologies, review of cost, schedule and staffing estimates, and development of specifications.

A relatively short-term or technically straightforward project may have only a few basic milestones or deliverables following a (1) proposal, (2) feasibility study, or (3) business case. Nevertheless, the project manager should report to clients and executives at intervals to keep them up-to-date on project progress, thus ensuring project direction.

On small projects, if no formal agreements are written, the project manager should deal with clients and executives in an informal, yet somewhat structured and logical, manner. This means managing expectations and making clear agreements about what will be produced and when. You simply cannot do this on the fly.

On long-term projects, you may find project phases take place over many months or even years, and, in this case, it is vital to provide interim deliverables to give the clients and executives a sense that work is being accomplished, to provide an opportunity for feedback, and to capture project successes in documented form. This is exactly why a project methodology works. How else are you going to do this?

It is wise that the project processes be built around the specific project methodology. Particular care should be given to defining the work to be accomplished in each phase. This should include definition of the deliverables to be produced, identifying testing and demonstrations to be completed, preparing updates of cost and schedule estimates, reassessing risks, and conducting formal technical and management reviews.

Five Current Priorities of IT Industry Leaders

Mr. Peter Schroer is the founder, chairman and president of Aras, which provides product lifecycle management solutions. During the past two decades, Mr. Schroer has had manufacturing and engineering business roles at IBM, Thermo Fisher Scientific and Data General.

Here, Mr. Schroer outlines 5 top priorities for IT industry leaders and decision makers for a recent issue of eWeek.

Focus IT Projects on High-Value Business Goals

Priorities have transformed overnight, bringing a new urgency to cost-cutting measures and initiatives that will drive the business forward in the face of economic uncertainty. IT leaders must look hard at alignment and corporate goals and think out of the box to accelerate projects that will help the company compete and even take advantage of the downturn.

Challenge the “Big Box” System Fallacy

Today, IT has to challenge the viability and logic of the “suite will do everything” mentality. The business can’t afford that answer, and cannot wait two, three or four years for capabilities that the company needs now. IT executives in senior management must find new alternatives that are cost-effective and quick to deploy, or the CEO and board will find someone else who can deliver.

Leverage SOA to Cut Costs

One of the best ways to cut project costs and deliver results more quickly is to stop trying to rip and replace all of the old systems each time a new one comes along. Major replacements are long and expensive. With a smart SOA (service-oriented architecture) approach, companies can do more with less. Vendors have tried to frame the SOA concept in their terms to sell IT new packages; however, SOA is really vendor-neutral. It comes down to using XML and SOAP messaging to interface between wrap around systems to expose and exchange information in new ways that provide more flexibility than was previously possible.

Expand the Use of Enterprise Open Source

Several years ago, open source meant Linux. Not anymore. These days, there are one or more high-quality open-source solutions in every software category. “Enterprise open source” typically means that a solution is sufficiently robust to complete directly with conventional proprietary offerings on functionality and capabilities, and that there is a company standing behind the solution to provide enterprise-class support and value-added services. The real business benefits of the open source come from the licensing format that removes the up-front capital expense for licenses and enables companies to prove out solutions before committing.

Renegotiate the Big Contracts

When push comes to shove, everyone has to share the pain. When IT executives take a hard look at expenses to find savings, there are usually three to five line items in the budget that jump off the page. These are the major provider agreements that have been entered into in the past and now jeopardize corporate profitability. To achieve real savings, IT will need to renegotiate contracts of magnitude.

Project support unit to conduct training in project management

As reported at SKNVibes.

Roadtown, Tortola - The Ministry of Finance’s Project Support Service Unit (PSSU) will conduct a series of training workshops on the Basics of Project Planning and Management beginning on July 22.

The training, to be held at the PSSU conference room located on the third floor of RFG Building at Road Town round-about at 10 a.m., will introduce participants to the basic need-to-know concepts of managing projects.  Participants will be exposed to standard forms and tools developed for use throughout the public service.  The topics to be covered during the training will include an introduction to the PSSU; What is Project Management? and Project Planning and Management.

During the training session participants will also be introduced to the revised British Virgin Islands Government Project Management Guidelines and will be shown how to utilise the document to achieve optimum results when managing projects.

According to the unit the principal purpose of the guidelines is to support the efforts of ministries or departments to more effectively plan, implement and monitor capital investment projects in a manner consistent with stated objectives, and within the limits of financial and other resource constraints.
Manager of PSSU Ms. Shaina Smith told the Department of Information and Public Relations in a GIS Radio Report interview that project management allows the Ministry of Finance and the Government on a whole to “achieve value for money”.

“By planning projects out we are able to properly assign a cost, as well as a schedule, so that we will know how much time it would take and how much money it will cost and this can help us make informed decisions,” she said.

Ms. Smith added, “In keeping with Government’s desire to achieve a more targeted and results-oriented expenditure programme, the guidelines seek to achieve value for money by more consistently realising project objectives with optimal results.”

… read more..