Вы находитесь на странице: 1из 14

Appendix A: Financial Metrics

Financial metrics represent one of the core techniques used to evaluate the business value of a proj-
ect proposal. Organizations use various forms of these metrics and three are illustrated here. The
role of financial measures is to evaluate a life cycle view of benefits and costs related to a particular
project proposal. In this view, the goal is to assess the relative measure of benefits versus the associ-
ated costs over some expected useful life.
The three classic financial measures demonstrated here are payback (PB), net present value
(NPV), and internal rate of return (IRR). Each of these has inherent advantages and disadvan-
tages in their constructs and these should be understood before making decisions based on any
one of them.
Step one in the financial measurement process is to estimate the net benefits and costs of the
project proposal over some useful life cycle. In many cases, this is done for five years given the
inaccuracy of estimates longer than this. As an example, Table A.1 shows the estimated cost-
benefit values for the five-year life cycle:
An interpretation of the forecast data shown indicates that the initial project would cost
$50,000 and would be installed one year later at which point positive returns would occur over the
next four years. During its expected lifetime (years 1–4), the project would generate net business
benefits (benefits minus cost) as shown. Summing the total list of values shows that the project
would generate $55,000 in net benefits over the period. A basic financial question related to this
set of data is “Is this considered a good financial project?” The answer to this depends on how we
look at the data using the basic financial measures. Let us explain the three classic measures before
going further.
PB method is the simplest and often used financial measure. This calculation simply looks at
the cash flow estimates and defines the time required to recoup the initial investment. The goal in
using this measure would be to favor projects that pay back their investment the quickest.
NPV is the calculated present value of the benefit stream. This measure is sensitive to the time
value of money, and the analysis is based on some hurdle rate, that is, it has to be measured positive
compared to a required value of 15%. This would favor any projects that returned values greater
than this amount.
IRR represents the rate of return calculated for the estimated benefit stream. This is analogous
to investing money and getting some measured percentage return from that investment. This is
the most difficult financial calculation, but the one that has the best comparative value across the
project portfolio.

578  ◾  Appendix A: Financial Metrics

Table A.1  Cost-Benefit Estimate

0 −$50,000

1 $15,000

2 $30,000

3 $10,000

4 $50,000

Total $55,000

A.1 Calculation Interpretation
PB—This represents the time required to pay back the initial investment. In this example case,
we can visually examine the data and see that it would take slightly over two years to recoup the
initial investment.
NPV—this value is calculated by the formula (1 + i)n, where i is the interest (hurdle) rate and
n is the number of years in the future. In the NPV calculation, each year value would be translated
back to the current time using the formula above, and then all values are added together for the
NPV value.
IRR—this uses the same concept as the NPV, except that the value of i is unknown; therefore,
it is necessary to repeat the calculation until a value of NPV is zero. Hence, IRR is the value of i
where the NPV is zero.

A.1.1 Timing Issues Related to Estimates

In the use of these measures there is some timing issue to consider. That is, do we assume in the
estimate that all of the costs are incurred at the beginning of the year, middle of the year, or spread
equally through the year? For these examples, we will follow the end-of-period Excel assumptions,
but for a particular analysis, the timing question should be reviewed to make sure that the calcu-
lated values properly reflect the estimates used.

A.2 Sample Calculations
The ABC company is considering investing in three projects. The projects are expected to cost the
company $500,000 and the future cash inflows for the three projects being considered. Table A.2
shows the cost-benefit estimates.
Note that all three projects have the same total benefit stream; however, timing of these ben-
efits is different for each. We will see the impact this has on the calculated financial measures that
each produce.
One more important item regarding Excel’s NPV function is that if we include the initial
project cost or the initial investment into the Excel NPV function, we get incorrect results that are
indicated in the worksheet below as NPV (Incorrect). This is an idiosyncrasy of the Excel’s NPV
function that must be understood.
Appendix A: Financial Metrics  ◾  579

Table A.2  Portfolio Cost-Benefit Estimates

Project X Project Y Project Z

1 $50,000 1 $325,000 1 $130,000

2 $150,000 2 $175,000 2 $130,000

3 $300,000 3 $75,000 3 $130,000

4 $100,000 4 $50,000 4 $130,000

5 $50,000 5 $25,000 5 $130,000

Total $650,000 Total $650,000 Total $650,000

A.2.1 Manipulating the Data

For this calculation assume the company wants to not undertake projects that return less than
10%. Each of the projects will show estimated net benefit flows for five years. The worksheets
below illustrate the calculations with Excel and a flow diagram. Follow the arrows from the Excel
Table A.3 to the various calculation sections.
Figure A.1 Illustrates the process of moving the future values back to time zero using the NPV
formula. Note how the $5,836.66 value is derived in the Excel calculations shown in Table A.3.
Calculations for Projects Y (Table A.4) and Project Z (Table A.5) are similar to those shown
for Project X in Table A.3.

A.3 Project Summary Comparison

From the various financial options calculated in the previous tables, we can compare the financial
parameter values for the three projects.
Note that project Y is the best financial option in all three parameters. The PB method is
very simple to calculate but often favors short projects with quick returns and penalizes excellent
longer-term projects where large benefits do not start until years 3 and beyond. However, in this
case it leads to the same result. In this example, all three methods favor project Y. This would not
be the case if the flows were changed to show benefits later in the stream (Table A.6).
There are many different reasons for a company to select a project that has benefits other
than financial and therefore would not be reflected in the measurement techniques discussed

+ve (Returns)

1 2 3 4 5
Convert all future values to present

NPV = $5836.66

Figure A.1  Arrow flow diagram.

580  ◾  Appendix A: Financial Metrics

Table A.3  Project X Financial Calculations

Table A.4  Project Y Financial Calculations

Table A.5  Project Z Financial Calculations

Appendix A: Financial Metrics  ◾  581

Table A.6  Project Summary Comparison

Project NPV IRR PB

X −$5,836.66 0.10 3

Y $46,104.96 0.16 2

Z −$7,197.72 0.10 4

above. Let’s assume that the following additional criteria need to be assessed along with the basic
financial measures:

◾◾ Strategic fit
◾◾ Availability of resources
◾◾ Likelihood of success
◾◾ Increases revenue
◾◾ Process efficiency impact.

This example adds some additional assessment criteria to the evaluation and assigns weights to
each of these. Note in Table A.7 that some of the evaluation attributes shown are more pure

Table A.7  Multi-Criteria Project Assessment

Project X Project Y Project Z

Criteria Criteria Criteria

Rating Rating Rating

Weight 1 = Low, 1 = Low, 1 = Low,

Criteria (%) 5 = High Weighted 5 = High Weighted 5 = High Weighted

Strategic fit 20 4 0.8 3 0.6 5 1

Availability 10 3 0.3 4 0.4 4 0.4


Probability 5 4 0.2 3 0.15 5 0.25

of success

Revenue 10 2 0.2 4 0.4 2 0.2


Operation 10 4 0.4 2 0.2 4 0.4


IRR 40 1 0.3 4 0.8 1 0.2

PB 5 3 0.15 4 0.2 2 0.1

Score 2.65 3.55 2.75

Ranking 3 1 l2
582  ◾  Appendix A: Financial Metrics

financial, while others are qualitative assessments translated into an integer score. Let us see what
summary values emerge from this type analysis.
As we can see from the weighted average shown above, Project Y is still rated the best option
based on the highest weighted score of 3.55. The weights assigned for each category are somewhat
arbitrary, and it is often wise to perform this type analysis using other weightings to see if the
answer is sensitive to some particular weight value.

Discussion Questions
1. What other evaluation criteria might be added to Table A.7?
2. What might be the value in selecting one of the other projects?
3. Do you see any flaws in the manner in which weights are assigned to the various criteria?
4. Is there a situation where PB might be the best financial metric?
Appendix B: Templates

One of the operational irritants of project management is the creation of formalized documents.
As a result of this many projects shun the documentation process and produce only the bare mini-
mum. For those external stakeholders dealing with such projects the lack of professional looking
documentation can make the management process appear amateurish, whether that is a valid
assessment or not. Use of templates can be a great asset in making the overall project look more
professional and save a significant amount of time in the process. Throughout the book, various
project management artifacts have been described as to their role, but not so much in detail as to
what they might look like in format. If one were to undertake developing a format for all of the
required documents, there would be significant wasted time spent in that activity.
A more efficient approach to document production is to have ready access to standard samples
that can be extracted and edited quickly (see Appendix C for more on this). A search of the
Internet will yield a wide array of online sources where tested template formats can be found.
Some of these have moderate costs and some are free. This appendix will summarize a few such
sites that are worthy of reviewing.
A sample listing of documentation template types would include the following:

◾◾ Project plan
◾◾ Change request
◾◾ Scope management plan
◾◾ Scope change register
◾◾ Work Breakdown Structure (WBS)
◾◾ Change tracking
◾◾ Requirements definition
◾◾ Estimating worksheet
◾◾ Standard development network plan
◾◾ Life cycle development activity list
◾◾ Issue register
◾◾ Project status reporting
◾◾ Project standards

The locations listed here are well-known sources for various project management information,
including methodologies, articles, training, and templates.

584  ◾  Appendix B: Templates

B.1  Web Sources

TenStep is a free site offering technical source material in project management. One of the unique
aspects of this site is its partnership with Cordin8, which is a repository and distribution utility.
These two sources offers an inexpensive approach to implementing a tested methodology along
with the Cordin8 tool for information sharing and collaboration. Both of these options offer a
good potential for improving project selection, delivery, and collaboration processes. Their URLs
are www.tenstep.com and www.cordin8.com.
Method123 is an online reference for project management. This site sponsors an excellent
methodology and templates for various project management functions. Their URL is www.
Gantthead.com is a good online source for various project management articles, training, webi-
nars, and tools related to current project management. Their URL is www.gantthead.com.
IAPPM. The International Association of Project and Program Management (IAPPM), formed
in 2003 through volunteers, is established as a global organization providing knowledge and use-
ful content to PMs and program managers. This UK organization provides links to various project
management topics. IAPPM is dedicated to helping individuals achieving success in the global
project community.
Matt H. Evans. This site contains an extensive listing of spreadsheets that collectively have
potential value in various aspects of project management. The URL for this list is: http://www.
There are several interesting items referenced here, but one in particular should be looked at.
The title of this is “Project management templates.” This offers a suite of tools that at least trigger
ideas on various areas of the life cycle.
In addition to these named sites there are various other Internet sources offering both free and
for sale templates.

B.2  Governmental WebSites

The State of Texas Department of Information Resources sponsors a large set of templates. Further
details can be found at www.dir.state.tx.us.
The State of Michigan hosts a very mature website dedicated to project management (www.
michigan.gov/dit). Use the search option to browse through their library of methodology and
The Government of Tasmania sponsors a mature project management website dedicated to
various aspects of project management. This site includes a knowledge base, various resources
including templates, and services. Further details can be found at http://www.egovernment.tas.

B.3  Texts
Several commercial texts publish project management templates. One notable example can be
found at:
Garton, C. and E. McCulloch, 2007. Fundamentals of Project Management. Lewisville, TX:
MC Press.
In addition, an Internet search will uncover many more.
Appendix C: Project
Data Repository

C.1  Repository Design

This appendix describes a conceptual project document architecture that is envisioned to be a
central information repository template for the project team and other stakeholders. The value of
such a repository comes from having easy access to technical and status documentation regard-
ing the project and its work products. These data groups have broad communication value to the
various stakeholder groups involved. They also have value for management activities related to
team collaboration, decision-making, and information sharing. Organizations that successfully
accomplish appropriate levels of information sharing report significant improvements in opera-
tional efficiency and improved decision-making. In addition to this, the cross-communications
value produced through the lessons learned process is greatly enhanced by having ready access to
previous project’s archival data.
An appropriate enterprise project documentation repository strategy consists of the following
basic content parts:

1. Technical artifacts produced by the project (physical design and related items dealing with
the technical work of the project).
2. Operational status metrics (raw performance data collected for the project).
3. Stakeholder communications.
4. Project formal status reports (complete history).
5. KA miscellaneous artifacts (filed by KA).
6. Product/process validation artifacts (test plans, testing results, etc.).
7. Project initiation repository (original vision, project Charter, business case, etc.).
8. Operational documentation (User-related documentation).
9. Configuration management libraries (formal product repository filed by WBS with ver-
sion control references—this would be drawings, computer source code, or other formal
10. Communication repository (meeting minutes, team communications, and external
11. Lessons learned repository.
12. Reusable standard project management templates.
13. Scope Control (Integrated Change Control repository).

586  ◾  Appendix C: Project Data Repository

14. Risk Management (including Risk Register—this may be an isolated data base).
15. Issues log—daily problem tracking.
Note: Items 9–15 may be separated and managed with centralized enterprise level data

Each of these repository subsets has value in executing and managing the overall work flow of the
project. Note that several of these repository groups contain data that might need to be shared
with external stakeholders. If the various data structures were standardized this could be an auto-
mated link. For example, data related to enterprise PPM, central accounting, human relations,
corporate policies, and others would be managed by their respective custodians, but shared with
external entities as needed. Appropriate access security is required to handle that type access.
Some of the repository data shown here is so focused on one aspect of the project that it would
be more effective to isolate it into its own domain. For example, change control processing or the
issues log both would seem unique in their role and might have custom access software that works
well. There would be no need in the short term at least to redo mature subsets of this data. The
key idea to focus on with regard to a project repository is to make access to the data both easy
and secure. The design goal is to view this as “The one place to look for the truth”: daily status,
latest information, current drawing, etc. Whatever item of information desired, this would be the
structure to look at for that.
Ideally, all of the data groupings described above would need to be logically interrelated; how-
ever, practically speaking, that level of integration is probably not a reasonable tactical goal for
most organizations. The core discussion here is to describe a subset of those items that are most
critical to serve basic project information needs. In modern terms, this repository should be viewed
as automated. If that is not practical, a similar manual filing structure should be organized as
indicated. Migration from manual files to automation should proceed in a priority order based
on value to the team. Step one of that approach should be to develop an overall repository design
structure and work toward full automation. Modern document management software is making
this process much more feasible than in the past when more customization was required.
In operation, value of a structured repository will be recognized through information sharing
and improved decision-making. Additional value will be recognized in supporting audit require-
ments and other requests for project data. One of the common complaints of project team mem-
bers is the time wasted looking for various project documentation. One other aspect often not
recognized is using an out-of-date document or artifact. The project repository is intended to be
the one place to retrieve data and one could view this as a “Google-type” database for all project
artifacts. In order to achieve these goals, both the storage and the retrieval technical aspects of the
repository need to be considered in the design. The view shown here is more logical and less tech-
nical. Access to the data store will require appropriate security access control through a common
portal or collaboration tool that simplifies the access process.
Computer-based storage and retrieval of text and graphics documents has been one of the
most recent advances in automation, but relatively recent technology developments in document
management software has made this topic one that can be effectively dealt with. Basically, large
volumes of documents can now be stored cost effectively, and retrieval speed for such documents
is impressive. Based on this current state of technology the structure described here represents
nothing more than an internal project to improve the overall working of projects. A manager
once described this environment as a project digital workbook. Rather than having to pass physical
documents around, they can be retrieved electronically with more accuracy and timeliness than
previous paper approaches.
Appendix C: Project Data Repository  ◾  587

C.2  Data Contents

A brief comment about each of the defined document subgroups is included below.

1. Technical artifacts. This segment of the repository contains many of the technical objects
needed by team members to execute their daily work. For example, items related to the WBS
and WBS Dictionary would be cataloged here. In addition, any logical or physical design
notes would be stored under their respective WBS codes.
2. Operational metrics. This subgroup is designed to store all project performance metrics, both
planned and actual. Data required to report project status externally would be extracted
from this source for both internal and external status information; however, other opera-
tional KPIs used for internal analysis of performance would also be stored in this area.
3. Stakeholder communications. This subgroup would contain a repository of various stake-
holder data organized by stakeholder. For example, the stakeholder communications plan
and analysis would fit this category.
4. Project formal status reports. This repository would contain all formal status reports issued.
5. KA artifacts (filed by KA). Each of the project KAs produces various documents related to
that area. For example, the management plans for each KA would fit this classification.
Later, more detailed documents will be created. These groupings would contain operational
items for these areas. Note: QC and QA documentation might be separated from this group
given the testing and process audit characteristics of these documents (see below).
6. Product/process validation artifacts. This section would contain various operational quality
artifacts such as test plans, testing results, user acceptance reports, quality audits, and so on.
7. Project initiation. Many historical artifacts are created during the early initiation phase of
the project. Items such as the original business case, vision statements, preliminary scope
statement, and the official Charter authorizing the project should be saved here for future
reference and possibly reuse on another project.
8. Operational documentation. In many cases, there is the need for documentation regarding
operational instructions for the deliverables. For example, future maintenance support per-
sonnel will need this information related to their work. All documents in this category
should be kept under version control and available to authorized personnel.
9. Configuration management. Many projects require that certain items fall into a category
where their version of the item has to be controlled. Design drawings (CAD) and computer
code are well-known examples of this.
10. Communications repository. This repository is used for general communications documents
not in the formal periodic status category.
11. Lessons learned. The value found in this process has been recognized in recent times and all
projects should be tasked with completing their lessons learned for each phase. This should
be an enterprise level system, but is first created as a project level effort and then evolves
12. Reusable standard project management templates. The concept of reuse has been recognized
for quite some time in various industries and project types. Over the past few years one of
the strategies to make the project management process more time efficient is to use templates
for various required items (i.e., project plans, status reports, WBSs, etc.). This also should be
an enterprise level effort and shared by all projects.
13. Scope Control. This repository will focus on the change control process. This process could
be either viewed as internal to the project structure or managed at a central level. The data
588  ◾  Appendix C: Project Data Repository

organizational option for change control will answer how this process would be designed
and how the physical repository would be created. However, the formal capture, tracking,
and management of scope change requests represent the most important formal configura-
tion management and tracking goals for the project and the organization. Failure to properly
manage this aspect of the process can create severe cost and schedule problems.
Risk Management. This management area represents the least mature management process
for most organizations. Assuming that the process is recognized as being part of formal proj-
ect management, there is a need to identify and track risk elements in the same basic manner
that scope is handled. That is, to identify risk elements, decide how to handle that element,
and then monitor the process. A more detailed discussion on risk management processes is
included in Chapter 22 and will supply further thoughts on this data group. Much of this
operational data would reside in a formal Risk Register database.
Issue log. Project issues are essentially unplanned items that arise daily in the course of the life
cycle. These items need to be tracked and resolved in a timely manner, which means that the
role of this repository is to ensure that the item does in fact get resolved and not elevate into
some higher-level problem. As an example, an item of hardware needed by the project team
breaks and needs to be fixed. It is anticipated that this is a normal maintenance activity, but
someone must monitor its status. As an alternative example, a decision is needed on a par-
ticular question. The issues log would identify the issue, criticality, and person responsible.

Each of repository subgroups outlined above represents important data artifacts for the project.
Mature organizations seeking to improve their project environment will support the evolution
of this concept, but tactically the PM should follow these guidelines in implementing whatever
physical form is available—manual files, crude project file systems, enterprise formal systems, and
the like.

C.3  Implementation Strategy

A data repository architecture with the breadth and complexity outlined here typically evolves
over time through several steps. The initial development phase often is triggered by the recogni-
tion that a defined data group has value. From that starting point data are collected and stored,
usually in a crude form such as a spreadsheet file, or a manual paper file. Similar repository groups
often migrate in fragmented fashion horizontally across the organization. Finally, at some critical
decision point high-level recognition and support will surface for formalizing and centralizing the
data store in order to improve the overall operational value of the data.
Each of the repository groups outlined here often follows such an evolutionary path, but ideally
this subject should be looked at in total and a formal solution sponsored by higher organizational
levels. It is important to recognize the value of these repositories as part of the standard project
work process and to identify an official owner charged with evolution and implementation of each
data group. Leaving this to the project often means that it is not a high enough work priority given
the goal of the project. This is yet another example where high-level management support can add
value to the project. This is a project in its own right! As these data groups become operational,
there needs to be a mechanism for the overall implementation to be recognized and dealt with.
Standardization of issues such as master data schema and date element definitions is needed for
all subgroups. One development hazard is to allow stovepipe, isolated developments, that later do
not fit together. Likewise, data element ownership needs formal recognition (e.g., where does the
Appendix C: Project Data Repository  ◾  589

data come from, who owns it, and who can access it). Philosophically, a standard design is needed
before implementation occurs.
Step two in the evolution is the organizational push to embed the data into the operational
culture. This is typically accomplished by using these data items for formal status reporting and
operational management actions. Storage and publication of approved metrics fits into this theme
as well. The major support facility for this is a retrieval strategy that opens up the data store to
users with little pre-training requirement—in other words, an intuitive usage approach.
Step three in the evolution involves using the data store for analytical purposes to improve
understanding of the project activities—that is, source of errors, productivity variables, resource
issues, resource management across the organization, and the like. Data mining utilities and
search capabilities represent two types of tools to aid in ad hoc exploration through the data.
These capabilities support efforts to improve performance and understand the processes better
than traditional tools or ad hoc judgment provide.
Step four represents data reusability across projects. The management templates will support
quick methods of producing high-quality documents efficiently. Much of the project management
process requires formatting and boilerplate wording. All of this can be supplied from the template
library and other structures defined in the repository. Once the entire structure matures, the
repository will provide the opportunity to bring significant changes to the traditional documenta-
tion and associated development paradigms.
As with all procedural changes to the organizational culture this process requires high-level
management support and an understanding of the value of stored data. Historically, this has not
been the case and project documentation methods have been characterized as being similar to the
cobbler’s children with no shoes. Process improvement can only come through a strategic focus
on the topic.