The further into the future you look when performing your analysis, the more important it is to convert your estimates of benefits over costs into today’s dollars. Unfortunately, the further you look, the less confident you can be of your estimates. For example, you may expect to reap benefits for years from a new computer system, but changing technology may make your new system obsolete after only one year. Thus, the following two key factors influence the results of a cost-benefit analysis:
How far into the future you look to identify benefits
The assumptions on which you base your analysis
Although you may not want to go out and design a cost-benefit analysis by yourself, you definitely want to see whether your project already has one and, if it does, what the specific results of that analysis were.
The excess of a project’s expected benefits over its estimated costs in today’s dollars is its net present value (NPV). The net present value is based on the following two premises:
Inflation: The purchasing power of a dollar will be less one year from now than it is today. If the rate of inflation is 3 percent for the next 12 months, $1 today will be worth $0.97 one year from today. In other words, 12 months from now, you’ll pay $1 to buy what you paid $0.97 for today.
Lost return on investment: If you spend money to perform the project being considered, you’ll forego the future income you could earn by investing it conservatively today. For example, if you put $1 in a bank and receive simple interest at the rate of 3 percent compounded annually, 12 months from today you’ll have $1.03 (assuming zero-percent inflation).
To address these considerations when determining the NPV, you specify the following numbers:
Discount rate: The factor that reflects the future value of $1 in today’s dollars, considering the effects of both inflation and lost return on investment
Allowable payback period: The length of time for anticipated benefits and estimated costs
In addition to determining the NPV for different discount rates and payback periods, figure the project’s internal rate of return (the value of discount rate that would yield an NPV of zero) for each payback period.
Conducting a feasibility study
A feasibility study, also called a proof-of-concept or POC, is conducted to determine whether a proposed project can be carried out successfully, whether the results the project provides can be used, and whether the project seems to be a reasonable approach to the problem it’s designed to address.
Following are five important areas you should consider when trying to determine a project’s feasibility:
Technical: Does the organization have access to the technical resources (such as people, equipment, facilities, raw materials, and information) at the times they’re needed to successfully perform the project tasks? (See Chapter 8 for information on human resources and Chapter 9 for information on equipment, facilities, raw materials, and information.)
Financial: Can the organization provide the funds in the amounts and at the times they’re needed to perform the project tasks? (See Chapter 9 for information on project funds.)
Legal: Can the organization satisfy any legal requirements or limitations that may affect the performance of the project work or implementation of its results?
Operational: Can the results produced by the project satisfy the organizational needs the project is designed to address?
Schedule: Can the work of the project be completed in the time allotted? (See Chapter 7 for information on developing the project schedule.)
The information generated from a cost-benefit study can be used to support the analyses of the feasibility study. For example, the estimates of cost developed in the cost-benefit analysis can be fed into the analysis of the project’s financial feasibility.Beware of assumptions that you or others may make (sometimes without realizing it) when assessing your project’s potential value, cost, and feasibility. For example, just because your requests for overtime have been turned down in the past doesn’t guarantee they’ll be turned down this time. Have people write down all assumptions they make when analyzing or planning a project in an assumptions log (see the next section for details).
Generating documents during the development of the project charter
Three documents are generated at the completion of the development of the project charter:
The project charter itself: A list of the information typically included in the project charter is included at the beginning of this section.
An initial version of a stakeholder register: A register of people or groups that are needed to support, affected by, or interested in your project. A stakeholder can be classified as a driver (someone who has some say in defining the results your project is to produce), a supporter (a stakeholder who helps you perform the project), or an observer (someone who is interested in your project, but is neither a driver nor a supporter). (See Chapter 4 for more information on project stakeholders.)
An assumptions list: A list of statements about project information that people consider to be true, even though they have not been proven to be. The assumptions you make about project information that’s important but about which you’re uncertain can dramatically affect every aspect of your project planning, tracking, and analysis. Equally as problematic is the information you believe to be true but is actually based on someone else’s assumption or on a faulty source. Therefore, it’s critical to begin to maintain a list of project information you know to be assumed in the early stages of the development of project materials and to continually add to and delete from it as necessary throughout the project.
When developing elements of the project plan, be sure to reflect the information developed in the early stages of the project’s development. As examples, the project charter should be considered when drafting a project’s scope statement (see Chapter 5), and the project stakeholder register and assumptions list should evolve from the corresponding documents begun when developing the project charter.Deciding Which Projects to Move to the Second Phase of Their Life Cycle
The decision whether or not to allow a proposed project to proceed to the next phase of its life cycle is the last step of the first stage of the project’s life cycle (starting the project). The last step of one phase that leads to the first step of another phase is called a phase gate.
To maintain control over the progress of a project, it’s essential to assess how a project has progressed as measured by its key performance indicators (KPIs) and only to allow those projects that have met or exceeded their performance targets to proceed to the next phase.