There was a time in the not too distant past when the only type of financial justification required for an internal Information Technology (I.T.) project was that the end-user wanted it and they would take the allocated charge back. Today, the approval of a major systems project usually entails the development of a complete business analysis backed up with detailed numbers. A further complicating factor in this change is that increasingly it is the project manager who is expected to prepare the business case without any help from Finance. In a world where only a small percentage of project managers have enough data to properly control costs on their current projects, proficiency in the complexity of business case analysis is probably not a skill at the top of the average project manager’s list.

The intent of this five-part article is to highlight some tips and techniques for constructing a good business case.

The planning process at most companies operates on a three-tiered basis. At the highest level of abstraction is the long-range strategic plan that defines the company’s line of business and the perceived critical success factors for that particular industry. Upon completion of the strategic plan most companies develop a set of specific measurable business objectives that are incorporated into what is usually referred to as the annual business plan. This document is operational in nature as opposed to strategic or tactical and will usually have specific cost and revenue goals. The third tier of the planning hierarchy, and the one that we will be concerned with in this article is the development of the tactical component or the individual business case.

The Business Plan and the Project Manager: Or Why You Should Care

The first issue a project manager usually confronts in the preparation of a business case is exactly where it should fall in the life cycle of the project. A case could easily be made that it is impossible to detailed costs and schedules prior to the completion of the requirements analysis. Unfortunately, that appears to rarely be the process used in the real world. Because of such things as annual budgets, revenue goals and cost reduction targets even the best company will refer to its strategic plan; quantify a specific deliverable in terms of acceptable cost and then someone (almost never the project manager) makes a determination that the project can be done in a certain amount of time, will cost a predetermined amount of money and will result in a predetermined savings to the company, and this has been done before the first project meeting, let alone the construction of a WBS (Work Breakdown Structure) and a detailed analysis. This often leaves the project manager feeling that failure has been assured before the project even starts.

In response to this persistent business reality, Arthur Anderson’s system development methodology, (Method One), incorporates the development of the business plan as an ongoing project management activity that begins prior to and then continues in parallel with, the development of the project itself. The methodology rather succinctly articulates “The business case is important for gaining initial approval to begin the system development effort; it provides guidance during the effort as to which features or designs contribute most to the business objectives; and it serves as a continuous benchmark for decisions along the way.”

This increased emphasis on the use of mainstream business tools within an I.T. environment points up a shift in perspective on exactly what skills and responsibilities the average project manager ought to possess. Dr. David Frame in his book “The New Project Management: Tools for an age of rapid change, corporate reengineering and other business realities” makes a very convincing case that in order to prosper in the current business environment a project manager needs to have all the skills one would usually expect to find in the organization’s general manager.

No matter how much a project manager might wish to the contrary, management will always need to have some idea what possible projects are in the pipeline and what their costs and potential savings will be before a detailed analysis is done, and like it or not ultimately they’re going to be the ones held responsible for meeting the high level targets someone pulled out of the air. What this means is that it is absolutely critical for the project manager to be involved with the business case process from its inception.

The goal of this article is to offer some basic tools to ensure that the I.T. project manager knows as much about the business case preparation process to ensure that the committed deliverables are at least theoretically obtainable.

Rule of Thumb : The business case should not be viewed merely as a way to initially justify the project. Its real purpose is to be the final authority behind those decisions that are made at 2:00 A.M. when you’re too tired to know or care — you just have to instinctively head in the right direction and the business case will point the way.

In part 2 of this article we unpack key the components of a Business Case.

Written by Klaus Wohlfarth

Rules of Thumb Source: Donna Fitzgerald (Donna Fitgerald internet presentation)