Project Go – No-Go Decisions – Part 4

In this segment, we’ll look at the non-financial criteria for selecting projects to proceed with. Basically, here we’re looking at weighted factor scoring to identify whether a project should move forward. The info in this article comes mainly from Gary Heerkens’ book “Project Management.”

Using Non-Financial Criteria for Project Selection

Financial models express costs and benefits in dollars and cents. As mentioned earlier, estimating certain kinds of benefits in financial terms can be quite difficult or uncomfortable. In other situations, accurate data may be obtainable, but only by conducting expensive tests, studies, or surveys. Whenever the process of getting good financial data is difficult, expensive, or time-consuming, using a weighted factor scoring model (decision matrix) may be a reasonable option for selecting the best alternative solution.

The figure below shows a decision matrix constructed to determine the preferred model of automobile. We’ve identified six attributes that are meaningful to us: cost, comfort, style, handling, reliability, and resale. We then weight each attribute by assessing a relative importance to it. The weights must total 1.

To use a decision matrix, you need to establish a scale for rating each alternative for each attribute. (The example shown uses a five-point rating scale.) You must define the scale so that everyone has a common understanding of what each rating number—0, 1, 2, 3, 4, 5—represents. Once you’ve established the relative weighting and the rating scale, it’s merely a question of filling in the blanks to determine the best alternative. In our example, using six weighted attributes and a five-point scale, the Lincoln Town Car was determined to be the best alternative.

Use of a weighted factor scoring model offers several advantages:

• It allows for using multiple criteria, including financial data. The attributes you select could include any combination of the four financial metrics presented in this chapter.
• It is easy to construct and to interpret.
• It allows for management input. Management can determine the appropriate attributes and the relative weighting. In fact, involving management in constructing the matrix may streamline the project approval process.
• It is well suited to what-if studies and sensitivity analysis. Trade-offs between criteria are readily observable.

There are also some disadvantages:

• The process relies almost entirely upon subjective measure, thus opening it up to questions of bias, halo effects, and reliance on opinion or judgment.
• The result obtained is only a measure of relative attractiveness. There is no absolute verification that any of the alternatives identified is a justifiable investment from a business perspective.
• All attributes are assumed to be independent; there are no allowances made for interdependencies between or among factors.

Project Go – No-Go Decisions – Part 3

Part 3 of this segment comes primarily from Gary Heerkens’ book entitled “Project Management.” Here we are examining the use of financial criteria in determining the best project solution.

Using Financial Criteria for Project Selection

Companies that use project selection and justification methods often rely on financial calculations as a comparative tool and as a basic hurdle for management approval. Basic financial evaluation models—variously known as financial analysis, business case, project financials, or cost/benefit analysis—often include some combination of these four basic metrics: net present value, internal rate of return, payback period, and cash hole. Let’s take a look at each of these metrics in more detail.

• Net present value (NPV). Calculating a project’s NPV answers the question: How much money will this project make (or save)? It’s a calculation in dollars of the present value of all future cash flows expected from a project. It’s roughly analogous to the concept of profit.
• Internal rate of return (IRR). Calculating the IRR answers the question: How rapidly will the money be returned? It’s a calculation of the percentage rate at which the project will return wealth. It’s roughly analogous to the effective yield of a savings account.
• Payback period. Calculating this metric (also known as time to money or breakeven point) answers the question: When will the original investment (the amount spent on the project) be recovered through benefits? It’s typically expressed in months or years.
• Cash hole. Calculating the cash hole (also known as the maximum exposure) answers the question: What’s the most we’ll have invested at any given point in time? It’s expressed in terms of dollars.

Performing a Financial Analysis (or Cost vs. Benefit Analysis)

Each of the four financial metrics identified previously can be determined by performing a financial analysis. Although you may not be intimately involved in performing a complete financial analysis, as a savvy project manager you should understand how it’s done and the terminology involved. The basic financial analysis process is not as difficult as many think. It consists of four basic steps.

Step 1: Identify the Sources of Cash Flows (Inflows and Outflows)

Executing a project causes money to flow out and in. Cash inflows are any financial benefits that can be claimed as a result of executing your project: e.g., an increase in revenue from sales, a reduction in production or operating costs, material savings, and waste reduction. Cash outflows are any expenditures or losses due to the project or its downstream effects. The most obvious cash outflow is the cost of the project itself. However, an increase in operating costs due to the project would also be a cash outflow.

Step 2: Estimate the Magnitude of Specific Cash Flows

In some cases, it will be fairly straightforward to estimate cash flows. In other cases, it may be very difficult. For example, consider how confident you would feel in placing a specific dollar value on these benefits:

• Increased output due to enhanced employee satisfaction
• Improvement in vendor delivery reliability
• Improvement in workforce safety
• Increase in user comfort or convenience
• Reduction in potential legal action against your organization

In estimating some of these types of cash flows, it can be very useful to rely on historical data or benchmark data.

Step 3: Chart the Cash Flows

After you’ve estimated the magnitude of all cash flows, you can chart all cash outflows and inflows year by year throughout the useful life of the project.

Step 4: Calculate the Net Cash Flow Using an Agreed-upon Discount Rate

Because the value of a dollar in the future is less than the value of a dollar today, the value of future cash flows must discounted. In simple terms, it is what the investor (your company) could expect to receive from any other investment that is consistent with its risk tolerance. An NPV greater than zero indicates that your project is expected to provide a financial return that exceeds the organization’s investment expectations, so your project is likely to be approved (if there’s enough cash to fund it).

In Part 4, we’ll further discuss the project decision process by examining the non-financial criteria for project selection.

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.

A Discussion on Project Success

How do we define project success? For me, the analysis is usually broken down into these four categories:

• Customer satisfaction
• End product usability
• Budget management
• Schedule management

Gary Heerkens’s brief case book entitled “Project Management” takes a cut at the definition of success. I’ve included a slightly modified version of this section below.

Defining Project Success

The definition of project success is obviously critical. After all, that’s how you’ll be judged as a project manager. Unfortunately, there are almost as many definitions of project success as there are project management professionals. To add to the confusion, every organization has its own view of what matters in project outcomes.

So, instead of trying to focus on one definition, I’d like to offer a framework of thought on success. I’ve found it valuable in the many discussions I’ve had over the years. If you consider the various ways that projects could be deemed successful, you come to realize that project success exists on four levels, each with a unique perspective and set of metrics. And despite the specific values used to quantify success or failure, the principle remains constant. Following are the four levels of success that I use:

Level I—Meeting Project Targets

Did the project meet the original targets of cost, schedule, quality, and functionality? Although it’s certainly admirable to beat these targets, my concept of success is tied to whether the project manager did what was expected. In other words, maximum success is zero variance between project targets and results. There are at least two reasons why I embrace this interpretation. First, it supports the organization’s need for certainty. Second, I believe that project managers who chronically beat targets are suspect, at best.

Level II—Project Efficiency

How well was the project managed? This is a metric for the process. If the project meets its targets, but the customer groups, project team, or others were adversely affected by the project experience, the project will probably not be perceived as successful. Project efficiency can be evaluated through the use of criteria such as the following:

• The degree of disruption to the client’s operation
• How effectively resources were applied
• The amount of growth and development of project team members
• How effectively conflict was managed
• The cost of the project management function

Level III—Customer or User Utility

To what extent did the project fulfill its mission of solving a problem, exploiting an opportunity, or otherwise satisfying a need? If the project did not satisfy the true need, the project may be perceived as a failure.

Here are some questions to help assess Level III success:

• Was the original problem actually solved?
• Was there a verifiable increase in sales, income, or profit?
• Did we save as much money as expected?
• Is the customer actually using the product as intended?

Level IV—Organizational Improvement

Did the organization learn from the project? Is that knowledge going to improve the chances that future projects will succeed at each of the three levels described above? High-performing organizations will learn from their failures—and their successes—and use that knowledge to improve their success rate in over time. This level assumes a long-term perspective and measures organizational learning and a resultant increase in project successes. The primary tools for organizational improvement are the maintenance of accurate historical records and the widespread use of lessons learned.

Feedback

What is your definition of project success? What is your organization’s definition…or your PMO’s definition? Some organizations focus on customer satisfaction. Others focus mainly on budget or schedule. I’d really like to hear your feedback and thoughts.

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