Maximizing Project Value: Defining, Managing, and Measuring for Optimal Return

by Jeff Berman

Overview

"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."

Product Details

ISBN-13:	9780814473825
Publisher:	AMACOM
Publication date:	12/14/2006
Edition description:	New Edition
Pages:	208
Product dimensions:	6.00(w) x 9.00(h) x 0.80(d)
Age Range:	17 Years

About the Author

Jeff Berman is Vice President of PM tec, Inc., a leading project management consulting firm. For more than 20 years, Jeff has helped Fortune 500 companies including Gillette, Johnson Johnson, FMC, CertainTeed, and Cytec deliver measurable value from project investments. He holds an M.B.A. and a B.S. in Industrial Engineering from Northeastern University. His keynote speaking events have included: Project Management Institute, American Production Inventory Control Society, New England Summit of Project Management, Mid Atlantic Project Summit, as well as many Fortune 500 client conferences. Jeff lives in Phoenix with his wife and daughter. He can be contacted at [e-mail] or www.pmtec.com.

Read an Excerpt

MAXIMIZING PROJECT VALUE

DEFINING, MANAGING, AND MEASURING FOR OPTIMAL RETURN

---

By Jeff Berman

AMACOM

Copyright © 2007 Jeff Berman
All right reserved.
ISBN: 978-0-8144-7382-5

---

Chapter One

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.

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.

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, you should describe the project leader, project sponsor, and project category (see Figure 1-4). The project leader is typically a project manager who will be responsible for managing the daily activities and implementation of the project during the project life cycle implementation. The project sponsor is typically a senior level manager who will oversee the project implementation and be responsible for ensuring that business risks are mitigated and the project will be successful.

The project category is where the project belongs within the organization of project portfolios. Many organizations have unique and specific project categories related to their business. Examples of projects within an IT organization may include application systems (such as human resources, accounting, enterprise resource planning [ERP], and supply chain); data and information (e.g., data warehouse, reporting, development); infrastructure (e.g., desktop, hardware, networking, telecommunications); operations and services (e.g., manufacturing, training, knowledge management, Internet). Another example may be projects within a state agency; projects of the Department of Transportation might include research, highway design, construction, and maintenance. Within each one of these categories you may have more granular level categories: for construction, for instance, you might have highways, roads, and bridges.

The point is that categories need to make sense to the organization and that they should be defined at the corporate or enterprise level so that every project that is initiated is classified into one of the already predefined categories. In the end, the organization will be able to review a portfolio of projects and be able to properly assess which projects and how many of what type to approve for funding and resources.

Project Scope

The third and perhaps most critical component of the PID is the "Project Scope" (see Figure 1-5). The Scope is the basis for putting together all of the details required for the detailed business case document and provides a way for executives or readers of the PID to get their hands around the project by sensing how big it really is. Within the Scope section of the PID the following items should be discussed:

Project location

Project business units or organizational departments

Stakeholder departments

Project milestones

Project approvers

The project location describes the location(s) where the project will be implemented. Typically this can include manufacturing plants, facilities, regions and/or countries. Project business units are defined as strategic operating units of the business, or a unit of the business that has its own profit & loss statement. A stakeholder is someone or a group of people that will be affected by or that can have an impact on the project, either positively or negatively.

Stakeholder departments are the departments or organizational units to which key stakeholders belong and which will be affected by this project (e.g., accounting, manufacturing, construction). Stakeholder units can also include external customers, neighborhoods/communities, or government agencies. Identifying a stakeholder group or unit is key to the overall scope of the project because they may have an impact on the project one way or the other by increasing or mitigating the overall project risk and the probability of success. If, for instance, a stakeholder group identified includes the accounting department and we know that accounting never wants to change their way of doing things, this may jeopardize getting your project approved unless you have a clear and well-thought-out plan to mitigate the risk invoked by this group.

(Continues...)

---

Excerpted from MAXIMIZING PROJECT VALUE by Jeff Berman Copyright © 2007 by Jeff Berman. Excerpted by permission of AMACOM. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Table of Contents

"Acknowledgments

Introduction: Beyond "on Time and on Budget"

The Speed2ValueTM Project Approach

Chapter 1 Defining the Project Business Case and Getting Buy-In from Top Management

Business Case Process Life Cycle

Step 1: Determining the Need for a Project

Step 2: Initiating the Project

Step 3: Making the Business Case

Business Case "Influencers and Supporters"

Seven Principles for Developing a Winning Business Case

Step 4: Project Selection Techniques

Step 5: The Business Case Approval Process

Chapter 2 Executing a Project with a Business Value Mind Set

Defining Project Value Drivers

Project Key Performance Indicators

Chapter 3 Achieving Project Value Through Stakeholder Management

Change Management

Stakeholder Management

Stakeholder Management as a Process

Stakeholder Communication

Chapter 4 Creating Organizational Alignment and Accountability

The Impact of Change

Accountability

Rewards and Incentives

Chapter 5 Establishing an Ongoing Project Performance Tracking Process

Reporting Mechanisms

Metrics Visibility

Correction Management

Chapter 6 Conclusion

Appendix A Project Business Case Exercises

Exercise A-1 Project Initiation Document

Exercise A-2 Initial Assessment

Exercise A-3 Risk Factors and Ratings

Exercise A-4 Resource Requirements

Exercise A-5 Total Project Cost Estimate

Exercise A-6 Financial Return

Appendix B Stakeholder Management Exercises

Exercise B-1 Sharing Your Experience with Change

Exercise B-2 Identifying Stakeholders

Exercise B-3 Assessing Stakeholders

Exercise B-4 Developing a Stakeholder Communication Plan

Exercise B-5 Establishing Stakeholder Accountability

Key Terms

Index"