Maximizing Project Value

Defining, Managing, and Measuring for Optimal Return

Jeff Berman

• Publisher: AMACOM
• Year: 2006
• ISBN:
  9780814429785
• Topic: Business
• Subtopic: Bookkeeping & Budgets
• Index: Business

What good is a project that's on time...on budget...and ends up providing your organization with no bottom-line results whatsoever? Whether it falls short of expectations, fails to ultimately be embraced by the people in the company meant to be using it, or simply lands with a thud in the marketplace, a project that doesn't truly deliver value is worthless at best. It's great to be on time and under budget, but to achieve positive results, project managers have to embrace an all-new philosophy of what it is they do for their organizations. Maximizing Project Value shows you how to put the emphasis on value when managing a project, from the project's initial inception, all the way through its completion, and even farther down the road to determine whether it's of continuous worth to the company. This valuable guide offers a step-by-step plan you can use to establish the value of a project, identify value drivers and key performance metrics and then track and report them, organize a team for accountability, and much more. You'll get the tools and information you need to: * Generate accurate value estimates in the proposal stage. * Create a clear plan that identifies measurable and ongoing value. * Establish buy-in from key players in your organization. * Develop and use a process for managing the people responsible for implementing the plan. * Adapt your project to meet changing business objectives. Far too many projects lose sight of their original purpose due to shifting resources, changing organizational objectives, and other unexpected developments. Maximizing Project Value provides a clear, immediately usable blueprint for ensuring the kind of project success that truly provides value to your organization.

CHAPTER 1


DEFINING THE PROJECT BUSINESS CASE AND GETTING BUY-IN FROM TOP MANAGEMENT

The first step in the Project Speed2Value™ Road Map is to develop a project business case. In doing so, you as project manager will begin to lay the foundation for achieving project success by obtaining buy-in from top management and getting your project approved. This means getting the powers at large to give you the required funding, resources, and time to execute the project. Sound simple? It is not by a long shot. With chief executives mandating tighter control over spending, financial support for projects comes at a premium. Resources are limited at best, and there is not enough time to do all things necessary to keep the business running smoothly. If you are like the rest of us, I am sure you have put in your fair share of working more than eight hours in a day, weekends, and holidays on occasion. Am I right?

With that said, I am sure that you are not the only one in your company with limited time or a good idea for a project. It is a given that every proposed project out there is in competition for the same resources, limited funding, and time to be spent for implementation. Therefore, it is up to you to justify that your project is better than the rest of the proposed projects so that you are one of the few winners for getting the limited resources, funding, and time commitments from the powers that be.

The key to getting your project approved is your ability to prove that your project, among all others, will deliver business value to the company. This means that you must be able to articulate “how” your project will deliver one or more of the main business drivers: cost reduction, business growth, maintaining operations (e.g., regulatory compliance), and increasing speed and efficiency. Keep in mind that these business drivers are why projects are executed. These are the drivers that keep your company profitable and keep your company competitive, and you must demonstrate how one or more of these business drivers can be achieved by your project in order for it to get approved. This is the premise for putting together what is called a project business case.

In simple terms, a project business case is a project justification document that outlines a project proposal and plan for authorized funding, resources, and implementation. It is a plan for execution and more importantly a plan for achieving project business value. The objective of a project business case is to justify:

• What benefit and cost the project brings to the business

• Why the project is important and should be funded

• Where the project needs to be implemented

• When the project can be implemented

• Who is required to implement the project

• How the project can be implemented with success

A business case is typically mandated by organizational policies and management preferences. The key is that the business case is used to approve a project as well as to serve as a baseline for determining project success. Think of the business case as your first benchmark for your plan of action as well as a measure for success. If all goes right and your project is approved, you will be on your way toward laying the foundation for building a project success plan of action.

Like a blueprint for building a house, a business case is the blueprint for achieving project success. Would you want your house built without a plan? If you are going to invest hundreds of thousands of dollars, I’m sure you would want to know what the plan is:

What type of house is it (3 bedrooms or 4)?

Why does it cost so much?

Where is it going to be located (facing north or south)?

When will it be built?

Who is building it (are they reputable)?

How will the house serve me and my family for the future to come?

Wouldn’t you agree that you would have to know the answers to these questions before deciding whether to spend your hard-earned money on building the house? It’s the same with the business case for a project, but instead of it being your hard-earned money, it is your company’s. Instead of you and your family living in the house for the future to come, it is your company and all of its employees who will be affected by the project you are proposing. As such, the business case is the blueprint for success; it is the plan for a project that will best serve company employees and help make your company more profitable and better off by its implementation. It is therefore up to you to articulate the case why your project will serve the company best and how you plan to make it happen.

A business case can look different from organization to organization; however, the key components remain the same. All of the basic questions must be answered (who, what, when, where, why, and how). I frequently get asked, “Do all projects require a business case?” The quick answer is yes, although some business cases are more formal than others. For instance, a small project, such as deploying six new laptops for the marketing group, may only require a purchase order and an e-mail committing resources from the Information Technology department.

However, the thought process for approving the small project is the same as for approving a larger project. Who needs the laptops (everyone or just a few people in the department)? What types of laptops are required (as you know there are many to choose from)? When do the laptops need to be purchased and to be in the hands of the marketing people? Where will the laptops be used? Why are laptops even needed? Why can’t they use desktop computers like everyone else? How will the laptops be deployed? I am sure you get the picture. The point is that no matter how small the project, the thought process is the same as long as funding, resources, and time are involved. More than likely this will be the case most of the time.

Most projects, however, require a more formal type of business case, because they require more funding, resources, and time to implement. By formal, I mean a well-documented report that clearly articulates the answers to all of the questions (who, what, when, where, why, and how). A good rule of thumb is that the larger the proposed project, the more time is required for formalizing a business case.

Information Technology projects are the most common projects requiring business cases. These may include projects related to networking, application systems, system integration, reporting, technical infrastructure, or software development. Other types of projects may include research & development (e.g., new products or pharmaceuticals); implementing new processes (e.g., reengineering the work flow of the supply chain); organizational restructuring (e.g., a merger of two companies or departments); construction, design, and engineering (e.g., highways, facilities, housing); and many, many more. Basically, projects ranging from thousands to many millions of dollars require a business case as long as they are competing for the same business constraints (time, money, and resources). The bottom line is that the business case can serve as the formalized document for getting your project approved as well as a baseline for measuring project success.

BUSINESS CASE PROCESS LIFE CYCLE

Most people don’t think much of a project business case, let alone think that there is actually a process that a project business case goes through in order for it to get approved and succeed in delivering measurable business benefits. Getting a project approved takes effort, thought, and finesse. A project business case is a way to help achieve the goal of getting your project approved. It follows it’s own sequence of steps or phases before it is approved. This is what I call the business case life cycle, or sequence of steps (see Figure 1-1).

STEP 1: DETERMINING THE NEED FOR A PROJECT

The first step of the business case life cycle is determining the need for a project. Needs for a project can be driven by a market need, such as a new product that will fill a certain void in the marketplace or a new elementary school to be located in a new master plan community. There may also be a business need, like a new software application that will help in productivity or efficiency of the workforce or a new restaurant to be built to service a community. Regulatory or legal need is also a driver, such as compliance with a financial filing or the advocacy of a product to be used on humans (e.g., drugs and medical devices).

Of course, the need for a project may derive from a simple stakeholder request, whether it is a customer change to a product or a taxpayer requesting the widening of a highway to help handle traffic due to population growth. Last but not least, a need for a project may be driven by a technological advancement, such as new manufacturing equipment or computer and phone networks to enhance communication. The bottom line is that the need for a project may come from many different places and at different times from different people or organizations, or even just from an idea that you developed. Without the need for a project, there is no reason to pursue getting resources, time allocation, or money.

FIGURE 1-1. Business case life cycle: need for a project.

STEP 2: INITIATING THE PROJECT

Once the need is determined and it is deemed an idea to pursue, the project should then be initiated. This is the second step of the business case life cycle. Sometimes a project initiation comes from you just asking your boss for the verbal approval to pursue a project in terms of developing a business case. Other times, a formal request is required to be filed so that a committee or council can approve the need for a detailed analysis or formal business case. For the larger and more formal type projects, this initiation is what I call the Project Initiation Document, or PID (see Figure 1-2). This is a document that begins the business case development process by formally documenting the project objectives and description; leadership and organization; and overall project scope.

Objectives and Description

The first component of the PID is the “Objectives and Description” section. Basically, this is the “what” and “why” you want to obtain funding and resources (see Figure 1-3). Within the objectives and description section is the unique project identifier. Typically this is the project identification number or project code most likely assigned by the accounting department or cost accounting system. This number can be randomly assigned, or in some cases is a “smart” number whereby the codes within the number are defined to mean different things, like department or cost center.

For example, in the project code “00301CAP,” “003” might stand for public works department, “01” for January, and “CAP” for capital project. The idea is that many companies may have many different unique identifiers or project codes particular to their organization. The only rule of thumb is that the project number be unique for the purposes of being tracked and accounted for once it is approved.

The second part of the “Objectives and Description” section of the PID is the project description itself. Typically this is a short text description of the project such as, “Deer Valley Elementary School Building” or “SAP Software Implementation.” The key is that it is short and sweet and gets to the core of what the project is about. Think of the project description as something that would describe the project in a nutshell to someone with little knowledge about the details of your business.

FIGURE 1-2. Project Initiation Document (PID).

FIGURE 1-3. Project initiation: Objectives and Description.

Next describe your business objective or what your overall mission of the project is going to be. Typically this would include cost reduction, revenue growth, maintaining operations, and achieving speed or efficiency. The business objective is critical to establishing the foundation for why it is important that funding and resources are to be obtained for this project.

Leadership and Organization

The second component of the PID is “Leadership and Organization,” or who will be involved with leading the project. Within this section, yo...