Project Management One Point Lecture

Lectures on concepts, terms and methods of the project management

Project scheduling

Introduction to the basic of scheduling, and DRAG as the metrics for project delays (2016/02/15)

Why do our time schedules always become longer? In order to make the final delivery date earlier, which part of the schedule should we tackle ? - These are common questions we face in the schedule planning.

There are some basic principles in the scheduling we'd better learn. Plus, there is a metrics that tells us specifically which part to tackle for shorter schedule. Let me explain in this article.

Suppose we have to deliver a system product. This work is comprised of just six (6) activities to be done.

1. Basic design (estimated duration = 20 days)
2.1 Hardware purchase (estimated duration = 35 days)
- preceding activity: Basic design
2.2 Hardware Installation (estimated duration = 5 days)
- preceding activity: Hardware purchase
3.1 Detail design (estimated duration = 10 days)
- preceding activity: Basic design
3.2 Software development (estimated duration = 20 days)
- preceding activity: Detail design
4. System test (estimated duration = 15 days)
- preceding activity: H/W Installation, S/W development

Now, how many days will it take to accomplish this work? It may help us to create a network chart that depicts activities and their relationships. There are a few styles to draw such network diagrams. We here choose the Precedence Diagram which uses boxes for activities and arrows for preceding relations.

(Fig. 1 Precedence diagram of the activity network)

Within each box we write down activity name in the center and necessary duration at the bottom. There are also four small spaces in each box at top-left, bottom-left, top-right and bottom-right. We have to fill in following dates.

top-left: Early Start (ES)
top-right: Early Finish (EF)
bottom-left: Latest Start (LS)
bottom-right: Latest Finish (LF)

These four dates represents “earliest possible start date”, “earliest possible finish date”, “latest possible start date” and “latest possible finish date”. Please remember these terms as they are the four basic parameters used in the scheduling.

If you are smart enough, you may be able to calculate the entire duration after looking at the Fig. 1 just for a few seconds. However, I would like to explain calculation procedure step by step here. Even for very smart persons, it would be not easy to calculate duration of a network containing 100 or more activities.

We start with the first activity “Basic design”. Its ES (earliest start date) is the day 0. Its EF (earliest finish date) is day 20. Then, ES of the following activity “Hardware purchase” should be day 20. And its EF = 20 + 35 = 55. In this manner, we calculate ES and EF of all the activities in the order of precedence. This procedure is called “Forward scheduling”.

By the way, the last activity “System test” has two preceding activities: H/W Installation and S/W development. They have different EF dates (60 and 50). Then which number should we take as the ES value of “System test”? ? Needless to say, the system testing cannot start unless the both preceding activities finish. Therefore, we have to take the later date (greater value) of EF as the ES of the next activity. In this case, it is 60.

Rule 1: If there are more than one preceding activities, their largest (latest) ES date becomes ES date of the following activity.

Here we can fill out ES and EF of all the activities. Please see Fig. 2. It tells us that System test will complete in day 75 at earliest. This is the delivery date of this work. However, we have to go on further.

(Fig. 2 Earliest start and earliest finish dates)

Next, we calculate the LF (latest finish) and LS (latest start) date of the final activity, System test. Its LS date is 75. Subtracting the activity duration from EF date gives ES date (75 - 15 = 60). This number should be LF dates for the two preceding activities, H/W Installation and S/W development. In this manner, we can fill in LF and LS of all the activities. It is called “Backward Scheduling”.

Basic design activity has two following activities; H/W purchase and Detail design. LS of H/W purchase is day 20, and LS of Detail design is day 30. This case means H/W purchase has to start at latest on day 20. Therefore, Basic design should finish at latest day day 20.

Rule 2: If there are more than one following activities, their least (earliest) LS date becomes LF date of the preceding activity.

Now, four spaces of all the boxes are filled in. So, let’s pick up activities whose ES equals to LS. It means its earliest possible start date is exactly the date it should start at latest. We call an array of such activities as “Critical Path”. In Fig. 3, the critical path is marked in red.

(Fig. 3 Schedule dates and the critical path)

If ES is less than LS for an activity, it means that the activity have a certain slack in starting date. For instance, Detail design is possible to start on day 20, but it is okay to start even on day 30. This slack is called “Float” in the scheduling theory.

Rule 3: Difference between LS and ES shows schedule float of the activity starting date.

Critical path is a series of those activities whose float days equal to 0. Furthermore, duration of the entire work equals to the length of the critical path. Unless we can make the critical path shorter, we cannot deliver work earlier. In other words, even if we work harder to attain shorter duration of an activity with positive float days, such effort does not contribute to earlier delivery date at all. Therefore, managers has to recognize there the critical path resides and concentrate his/her control efforts to it.

The most unique characteristic of schedule control is the fact that there is a clear distinction between “important” and “non-important” activity. This is quite a different situation from the cost control. Cost control is based on the logic of addition. When we can save $1 for an activity, total cost would be saved by $1. In the schedule control, however, making shorter duration for an activity with positive float does not contribute to earlier delivery of the work.

Up to this point is a basic explanation of the critical path method (CPM). Now, we face a question about the "important activity” - how much is it important? A metrics called DRAG is needed to answer this question.

DRAG is a measurement that shows how many days an activity pushes down the entire delivery date. For instance, DRAG of an activity is zero if that activity has float. In the above example, DRAG = 0 for Detail design and S/W development. On the other hand, for an activity on the critical path that has no parallel activity (like Basic design and System test), its duration becomes DRAG value. This is because existence of such an activity pushes down the final delivery date by its duration. Clearly, the shorter the activity’s duration becomes, the earlier the final delivery date comes.

Some consideration is needed for an activity that is on the critical path but has parallel activities running with. H/W purchase and Installation are these kinds. There is a parallel path: Detail design and S/W development, which has 10 days float. If we shorten H/W purchase by 5 days, then final delivery date becomes 5 days earlier. If we shorten by 10 days, delivery date is 10 days earlier, respectively. However, if we shorten H/W purchase by more than 11 days, then the other path becomes now a new critical path and no effects on final delivery date any more. 10 days are the limit. Therefore, DRAG of H/W purchase is 10 days.

H/W installation has only 5 days duration. It is shorter than float of the parallel path, 10 days. Thus, if we can shorten its duration by 1 to 5 days, then delivery date becomes earlier by the same days. DRAG = 5 days for H/W installation.

Let me summarize the rule with DRAG.
(1) For activities with float days: DRAG = 0
(2) For activities on the critical path with no parallel activities running: DRAG = duration of the activity
(3) For activities on the critical path with parallel activities running: DRAG = float of the parallel activity
(4) Nevetheless, in case its duration is shorter than the parallel activity’s float: DRAG = duration of the activity

Fig. 4 shows this results.

(Fig. 4 DRAG values)

Is there any benefit if we know DRAG values? Yes, there is. DRAG indicates how many days the activity pushes down the final delivery date. If you wish to attain earlier delivery date, then you should tackle activities with larger DRG values. Priority is very clear.

DRAG value also measures how the entire work is out of parallelism. If you would like to make the entire schedule shorter, then you had better break down your work into pieces that can be run in parallel. This parallelism principle applies to any kinds of work, even applicable to construction of pyramid or calculation process in the computer. DRAG clearly shows which activity is out of parallelism.

The above example is made up of only 6 activities, so you may easily find out which one to tackle without computation of DRAG. However, you cannot do it easily with 60 or 600 activities. (As to my business field, engineering projects, 600 activities are not a big number)

Of course, there are certain limitations for the critical path method or DRAG. You can criticize that, say, they are no more than static analyses, or, it is difficult to estimate activity duration precisely by one value, or no resource constraints are considered. But here is one point to keep in our mind. The scheduling is a practice to build approximation models based on various assumptions. Modeling always accompanies with simplification. Still, simplification enables us to see structure of time schedule. “Models are all wrong, but they are useful.” Simple tools are powerful as far as we are know its usage in a simple manner. Scheduling is the same. What matters is how and when to use models and methods.

DRAG metrics was first developed and proposed by Steven Devaux in his textbook “Total Project Control: A Practitioner's Guide to Managing Projects as Investments” (1999, 2nd Edition 2015). It will be more useful when applied together with costs. However, this article is already long. So, I would like to write it in next occasion.

→to the home page

Drag Cost - The true cost that takes into account delivery schedule effects (2016/03/20)

"Liquidated damages" is a legal term used in the contracts. It represents potential compensation by the contractor for damages caused by delays in delivery or poor product performance. The contractor is obliged to pay penalty costs stipulated in the liquidated damages clause, in case it fails to satisfy mandatory contractual requirements.

Liquidated damages cost on the schedule delay is often calculated on pay-per-day basis; delayed days multiplied by, for example, thousand dollars or million dollars per day. In addition, a ceiling amount for the penalty is usually defined, say, up to 8% of the contract price. Although the liquidated damages are a stringent term, it clarifies the formula and boundary with schedule risks. Therefore, contractors may regard the term better than unlimited liability. To my observation, American and European companies will never sign agreements that requires unbounded compensation for schedule delays.

Penalty cost for schedule delays is usally clear with the contracted projects in this manner. Then, how about the internal projects that are initiated by the company itself? New product development project is an example. Consider a case that its target date of market-in was the end of December. However, the first lot was actually shipped in next February. Sales and marketing people might complain, but there were no real damages -- is this correct?

The answer is NO. Let's suppose the product life length in the market will be 5 years. Expected revenues will be 100 million Japanese Yens per year (I use "\1 M” notation for 1 million Yens hereinafter for simplification). Profit margin will be at 20% or \20 M. It means revenues in total will be \500 M and profits will be \100 M in five years. This will be the expected income up to December 2021, if shipped in December 2016. However, it may be too optimistic to expect the same income for 5 years in case market-in date is delayed to February 2017. The life length of a new product is not determined by physical persistency but by competition with others. Therefore, we should think the duration of sales become shorter if market-in date delays. It means profit will decrease by 20 x (2/12) = \3.3 M.

In other words, profit decreases \3,300,000/40 = \830,000 per day if delayed (20 working days per month assumed). About \10,000 is lost per hour. \140 loss per hour, or \2 loss per second. Saying “oh!” costs \2. If you drop a 1 Yen coin onto the ground, you should not bend your body to pick it up. Because it may take more than 0.5 second, and costs you more than \1. This is the “time is money” sense for the new product development projects.

Okay. Then, suppose my project is a contracted type without any liquidated damages terms. My time won't be a cost? Even if delivery delays, we just make apologies to my customer, perhaps together with our sales guy. How about this?

A good try, but NEVER count on such ideas. Now, this is the very important point. In the contractor's business such as the systems integrators, number of project managers governs the company's capability of work. A project manager needs to be engaged from the very beginning to the end of the project. Missing chances of getting new contract because no PM is available at that moment - this often happens in real business situations. PM is the bottleneck resource for contractors.

Suppose PM is 5 times valuable than normal engineers in your company. It does not mean PM wages are 5 times higher, but PM is a scarce resource from the company's viewpoint. Let's assume annual wage of average engineers is \5 M per year. Then, value of PM availability is \25 M per year. A year has roughly 250 working days. So, its value is \100,000 per day or \3.5 per second. Loss of PM availability caused by delays will cost more than the previous new product development project case.

Time is money in any projects. Based on this principle, I would like to remind the readers of DRAG. It is the metrics I explained in the previous English article. It evaluates impact of an activity duration to the entire project duration. An activity having DRAG of 10 days can be regarded that it pushes final project delivery date by 10 days. Basically, DRAG = 0 for an activity which is not on the critical path. DRAG of a critical path activity normally has plus value, depending on its duration and existence of parallel activity paths.

DRAG Cost is defined as DRAG days multiplied by the penalty cost per day for project delivery delays. It is a monetary value. For instance, DRAG Cost of an activity having DRAG of 8 days equals to \1.6 M when penalty cost is \200,000 per day of delay. DRAG Cost represents cost effects of each activity's duration in the project.

Each activity, of course, needs cost to execute itself. Suppose execution costs are given in the below table for the Fig. 1, then summation of execution costs and DRAG Costs are as shown in the right end column.

WBS No. Activity Duration
Execution cost DRAG (days) DRAG cost Overall cost


Basic design


\1.0 M


\4.0 M

\5.0 M




\4.0 M


\2.0 M

\6.0 M




\0.3 M


\1.0 M

\1.3 M


Detail design


\1.2 M


\0 M

\1.2 M




\6.0 M


\0 M

\6.0 M


System test


\2.5 M


\3.0 M

\5.5 M

When we compare execution costs only, "3.2 software" seems to be the most costly activity. However, calculation result shows "2.1 Hardware" and "3.2 software" both have the highest costs of \6 M and next is "4. System test" of \5.5 M, when we take into the DRAG Cost. It means we should tackle activities in this order when maximizing the project profit.

Business trends nowadays make many people simply think "tackling for profit means trying cost down". However, the DRAG Cost provides us another approach. Duration of "2.1 Hardware" may not be easy to shorten, as it relies on vendors. Case of "3.2 software", DRAG=0. It has no effects on the project delivery even if we can shorten it.

Therefore, we should tackle "4. System test" activity. Can we make it shorter with assigning double number of people? Of course, double resources does not reduce duration by half. There will be learning curve with people, and more communication time may be required as members increase. Let's say duration will be cut off by about 30%. Then, its dration becomes 10 days instead of 15 days. Execution cost will increase, because double resources are assigned for 2/3 duration. Hence, execution cost will be 4/3 times larger, which is \3.33 M in total. Meanwhile, delivery date becomes 5 days earlier. DRAG Cost will decrease by \1.0 M. In total, we will gain \0.17 M. If this is not sufficient, then the next target may be "1. Basic design".

This approach is also applicable to cases with multiple sources for hardware procurement with different conditions. For example,
 A company: delivery = 35 days, price = \4.0 M
 B company: delivery = 25 days, price = \5.0 M
We can calculate total costs as: A company = \6.0 M, and B company = \5.0 M. In this case, we should buy from B company although its price is a bit higher.

Concepts of DRAG and DRAG Cost were proposed by Steven Devaux, an US-based project management consultant in late 90's. He calls summation of the execution cost and DRAG Cost as "True cost" of the activity. Traditional project management theory could not resolve trade-off between time and cost. Time is time, and cost is cost. They have been two separate worlds, until the day he established his new methodology. Hence, DRAG concepts are very valuable.

We have to elaborate this method more in order to apply to real problems. Creating an appropriate tool is very important contribution to the management. It will bring out a big diffenrence, it is like going out to the sea with having GPS equipment. I believe more people should learn the DRAG Cost approach.

[Website of Mr. Steven Devaux]
"Total Project Control"

→to the home page

Sunk cost principle and DIPP criteria for project portfolio management (2016-05-05)

Among various concepts and principles for the management theory, “sunk cost” principle looks easy to learn, but is the most difficult to apply in practices. The sunk cost means the money we have already spent for a subject matter. Because it was already spent, our decision making should not be affected by it. The principle of sunk cost tells us to decide based on future prospectives of the matter. However, our way of thinking often reflects past history, and it is hard to make right decisions.

Let’s take an example. Suppose a woman bought ticket for a concert at \8,000 (roughly $70). It is a good price. However, she cannot find her ticket in her handbag when she arrives the concert theater. She might have lost it or just left it home. She confirms with the box office that seats are still available at the same price. She has money to buy it. The concert is held only that night. Then, what should she do? She should buy another ticket to enter, or just return home?

If she believes the concert is worth \8,000, then she should buy another ticket. She might have lost or forgot her original ticket. Whichever it was, the money she paid for the ticket never comes back. It is the “sunk cost”. The question is, now, simply to compare the concert value and price of \8,000, as seats are available and she can pay that amount. And for her, concert value would be greater (that’s why she bought one ticket before).

Nevertheless, people often wonder on this problem because they transform the question into “is this concert worth \16,000?”. This example problem was originally raised by the Nobel Prize Economist Daniel Kahneman (2012). He explains: “if the lady’s income this month is just \8,000 less that the normal month, then does she buy the ticket? Most people may answer “yes”. However, if the same problem is presented in a different fashion of “lost ticket she once bought”, then many reply wrong answer. This is because they put the lost \8,000 on the cost accounts. (D. Kahneman: “Thinking, Fast and Slow” chapter 34)

Similar problems arise during the course of much larger projects. I dare not mention its proper name, but a huge national dam construction project in northern part of Kanto region has been a political issue for several years. The underlying cause of this dispute is a fact that the central bureaucracy does not have any criteria or mechanism to terminate projects once they were commenced. One more complicating factor is a way of thinking “we’ve already spend so much amount of money, so we cannot stop the project to make it in vain”. Oh yeah, it’s natural to consider that way, unless we learn the principle of sunk cost. According to the economics, it is not relevant to our decisions no matter how much money has been spent. We have to make up our mind, just based on comparison between “amount of money to spend till the end" and “value of the dam when completed”.

It is very difficult to decide whether to continue or stop projects regardless of their sizes. Reality is that efforts and faces of project members are at stake.

“Amount of money to spend till the end” of a project is called cost ETC (estimate to complete) in the PM theory. “How many days till the end” is called time ETC. Cost ETC refers to the cost from now till completion regardless of the amount already spent. Total cost of a project when completed is called “cost EAC (Estimate at Completion)”.

Decisions about project commencement, continuation and termination are the problems in the project portfolio management domain. The most important factor is normally the economic evaluation, except for non-profit projects such as academic researches. There are various criteria for economic evaluation like NPV/IRR of DCF method, or payout period. However, there is a common limitation with them: they are all comparison between the total investment cost and the total profits. They are applicable for planning phase decisions, but not appropriate for judgement of ongoing projects because they do not take into account of the sunk cost principle.

In order to conquer these limitations, DIPP was proposed as a metric for portfolio management. DIPP stands for Devaux's Index of Project Performance, originally conceived by Mr. Stephen Devaux as well as DRAG and drag cost which I explained in previous articles.

Definition of DIPP is quite simple:
 DIPP = EMV / Cost ETC

Where, EMV represents Expected Monetary Value which is anticipated profits of the project. Its division by Cost ETC gives DIPP calculation. For example, suppose there are four projects ongoing. Some of them are in planning phase and some in execution phase, as shown in the below table.

Very simple. Now, there comes another new proposal for Project E.

It seems to be a good idea to include Project E into our portfolio because it has higher profitability - unless it has any impacts to others. However, there is often a limitation of available man-power resources. Pursuit of Project E may affect other project schedule. If we have proper scheduling tools, we can evaluate it. The simulation result shows following impacts to the other projects.

Please be aware that EMV of each project decreases due to delay of the finish date. If we are too greedy and put priority to Project E, it will end up with depleted DIPP of the overall portfolio from 2.9 to 2.2. It may not be a good decision.

Of course, this is just a desktop calculation. We all know that other factors, such as gut feelings, prides or customer relations, etc. coming into the equation. However, it would bring out a significant difference for corporate performance in the long run, whether the management makes decisions with knowing this equation or without knowing it. Please also be aware that normal DCF method cannot evaluate such portfolio impact problems due to lacking of the sunk cost calculation.

DIPP increase as a project proceeds. This is because the Cost ETC, denominator of the equation, becomes smaller as the project reaches to its goal. When we have to prioritize budgets or resources among projects having different progresses or phases, it is rational to select the one which has the largest DIPP (normally the closest to the goal).

I have explained methods developed by Mr. S. Devaux in three article series. They were proposed in the US and have put in practices in military industries to some extent. I first learned them at the conference Project World in Boston in 2003. In that conference, many other new ideas or techniques were presented. I could feel enthusiasm by the people gathering in the PM field in the States.

12 years have passed since then. DRAG, DIPP or any other new idea has not been introduced to Japan. Discussions about PM in our country are still bound within PMBOK Guide(R) knowledge areas or just reports of in-house trial & errors. I believe we should have more sensible antenna for new evolution in PM theories in the world.

→to the home page

Calculating real values of activities - an introduction to the risk-based project value (2016-06-12)

“A Guide to the Project Management Body of Knowledge” (PMBOK Guide)(R) by Project Management Institute (PMI) has been introduced to Japan and widely accepted by the IT industry in recent 10 years. As it became well known, technique of Earned Value Management System (EVMS) has also been widely tried put in practice. EVMS is a very useful tool that can monitor and control cost and progress of a project at the same time. In Japan, the concept of “Earned Value” (EV) has corresponding word “Dekidata” (出来高). This word and concept can be tracked back even to 18c Edo-era in Japanese construction industry. However, we could not develop any management system using EV, which is a bit pity for us.

By the way, introduction of the EVMS seems to have made many practitioners to hold a misperception that it is applicable and powerful to control any types or situations of project. No, it is not. The EVMS should be used carefully with appropriate premises and methods. It is not an omnipotent tool.

The weak point of the EVMS may be clearly understood when we try putting it to the research and development (R&D) type of projects for new products. Let us consider very simple example: suppose there are two people starting a garage company. One is an engineer and the other is a salesman. The engineer has made a brilliant new idea. With this idea, he thinks he can make a very unique product having new features from parts and materials costing only $2,000 amount. The salesman says to the engineer that he can easily find a customer to buy the product at a price of $10,000 if it is really manufactured and be functional.

However, the engineer thinks success probability of making the product would be fifty-fifty, as it is the first attempt for his new invention. On the other hand, the salesman is 90% confident that he could find a customer. It is a very simple new product development project with only two activities: development activity and sale activity. Initial cost of the development activity requires $2,000. Sales activity would cost only some phone calls and transportation, therefore negligible small.

Now, here is a question. Suppose their project have just successfully completed the first activity, development. The engineer has fabricated the new product and it’s functional. Then, what is the current project progress in percentages? How do you think?

Conventional EVMS tells us that the project progress percentage should be measured by current EV divided by total EV (which equals to the total budget of the project). In this case, current EV is $2,000, and the total budget is also $2,000. Therefore, progress becomes 100% even though they have completed the first activity! Do you concur to this calculation?

Clearly, this calculation does not match perceptions by practitioners. You cannot manage projects properly, with measurements which is not acceptable to people. Some may argue that a cause of this problem is in the assumption of zero cost in the second activity for sales. Then, let’s assume sales may cost $10. Progress calculation now becomes 2,000 / 2,010 = 99.5%. When we round up after the decimal point, it is still 100%. It does not resolve this issue. You can see challenges when we apply the EVMS progress calculation automatically to new product development projects.

What is the root cause of this issue? It comes from the assumption widely used in EVMS that “budgeted cost of an activity is regarded as its value”. It means that low cost activities are low value activities, in other words. In general, costs of intellectual activities such as design or concept development are relatively small because it just human salaries. To the contrary, manufacturing or implementation activities normally cost higher as they require material and outsourcing expenses. Physical labors are high value than intellectual world. EVMS has evolved in procurement projects in the US DoD. Cost-based progress measurement seems to have been base of their way of thinking.

If the cost-based progress calculation is not acceptable, then how about this? “This is a collaborative project with two persons, so, we say 50% progress at the completion of the first half.” However, this is not a theoretical resolution, rather a political compromise. What do we say if development needs 2 persons or sales takes 5 guys? Progress measurement system depending on political voice power may not be useful in the fair management. Then, what should we do?

I give the answer first. We can calculate progress with "risk-based value” of the project activity. In this case, it tells us the current progress = 81.8%. New product development projects are collaborative endeavors undertaken to attain unique outcome, which are always associated with risks of failure. In fact, any project is associate with risks. In such cases, theory of the risk-based value analysis of projects are applicable and useful. Let me describe it in the below sections.

The above contradiction with the EVMS comes from assumption that value of an activity is its budgeted cost. It gives us 100% completion in the middle of a project. In order to avoid this, we have to weigh the real value of an activity in the project. Then, what is the “real value”?

Let us simplify this project. How about making it into a single activity project of “make-and-sales”? It requires initial cost of $2,000. Risk probability of failure of this project equals to 55%, because 100% - 50%×90% = 100% - 45%=55%. If this project successfully completes, then it will bring out monetary value of $8,000 as a profit.

However, at the beginning of the project, revenue of $10,000 is not assured. Its expected value is calculated as just $4,500, because 10,000 x 45% = 4,500. On the other hand, it is sure they have to expend $2,000 as an initial cost for parts and materials. Therefore, the expected monetary value of the project is just $4,500 - $2,000 = $2,500 at the starting point. Success of “make-and-sales” activity will increase and realizes their project value from $2,500 to $8,000. It will contribute value to the project by $5,500 (= $8,000 - $2,500).

Let me put this in other way. Value contribution of an activity can be expressed as an increase of the expected monetary value of the project; the difference of values before the activity’s starting point and after its successful completion. Expected monetary value of a project is determined by costs and incomes (cash flows) of its consisting activities, and risk probability of failure associated with the activities.

Then, what would be with the project with two activities: development and sales as in the original example. Let us calculate. Expected monetary value of the project (we call it “risk-based project value", or RPV in short, hereinafter) is as follows:

After completion of “sales” activity: $10,000 - $2,000 = $8,000.
After completion of “development” activity: $10,000 x 90% - $2,000 = $7,000.
Before starting of “development” activity: $10,000 x 90% x 50% - $2,000 = $4,500 - $2,000 = $4,500.


Value contribution of “sales” activity = $8,000 - $7,000 = $1,000.
Value contribution of “development” activity = $7,000 - $2,500 = $4,500.

Total contributions of the two activities are $5,500 in total, which corresponds to the value contribution of the “make-and-sales” activity in the simplified case.

Now, we are ready to measure the progress. They have just completed the development and are about to start the sales. Progress can be obtained as attained (“earned") contributed value divided by total value contributions, like the EVMS tells us. It is,
$4,500 / $5,500 = 81.8%.

OK? Real value of an activity is represented by an increase of the project’s expected value before and after of the activity execution. The value depends on risk probabilities of failure with project activities. Please see the above example. Value contribution of development is greater than that of sales. This difference comes from the fact that the development has higher risks, or in other words, more difficult. The more the work difficult, the more it brings value when successfully completed. The theory of risk-based project value proves why our common-sense insights are true.

What if the risk probability of sale in the above case is zero? You can immediately see the value contribution by the sales equals to zero. Activities with no risks are zero values to contribute to the project, even if they are necessary to complete.

Practical projects have activities far more than two, and there are parallels projects. Even with these cases, calculation of the RPV and value contribution of activities are possible. Please see my academic papers in the references.

And, please see the above case once more. Conventional management theory has usually treated as development as the “cost center” activity and regarded the sale as “profit center” one. This is one background of the phenomenon that sales sections have more influential power in companies. However, if we compare real value contributions of the two activities in the above case, development has greater value. It is clear which is more important in the viewpoint of management.

The theory of risk-based project value enables evaluation of components in value-chain in a enterprise or calculation of added-values in a supply chain. This was made possible because we included concept of “risk probability” into cash flow analysis. I hope the readers understand how this theory can be a powerful tool for us.


(1) Sato, T. (2014): “Risk-based project value ? the definition and applications to decision making”, Procedia - Social and Behavioral Sciences. Vol. 119, pp.152-161.
(2) Sato, T. (2009): “Risk-based Project Value Analysis: General Definition and Application to Progress Control”, Journal of Japan Industrial Management Association Vol. 60, No. 3E.

→to the home page

(c) Tomoichi Sato