カテゴリ:English articles( 6 )

Calculating real values of activities - an introduction to the risk-based project value

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

e0058447_618787.jpg
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.
e0058447_611585.jpg

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.

Therefore,

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

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.

References:

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

Please also listen to my podcast from PMI (Project Management Institute) series, which is available from below URL.
https://www.pmiwdc.org/pm-pov/2016/04/advances-in-pm-part-2
by Tomoichi_Sato | 2016-06-10 06:53 | English articles | Comments(0)

Sunk cost principle and DIPP criteria for project portfolio management

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

e0058447_9415260.jpg


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

e0058447_942143.jpg


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.

e0058447_942311.jpg


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.




"Introduction to the basic of scheduling, and DRAG as the metrics for project delays" (2016-02-13)

"Drag Cost - The true cost that takes into account delivery schedule effects" (2016-03-20)
by Tomoichi_Sato | 2016-05-03 23:37 | English articles | Comments(0)

Drag Cost - The true cost that takes into account delivery schedule effects

"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 in my blog. 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.
e0058447_15345039.jpg

        Duration   Execution  DRAG   DRAG   Overall
                cost          cost   cost
---------------------------------------------------------------------------------
1. Basic design  20 days  ¥1.0 M  20 days   ¥4.0 M  ¥5.0 M
2.1 Hardware    35 days  ¥4.0 M  10 days   ¥2.0 M  ¥6.0 M
2.2 Installation   5 days   ¥0.3 M   5 days   ¥1.0 M  ¥1.3 M
3.1 Detail design 10 days  ¥1.2 M   0 days     ¥0 M  ¥1.2 M
3.2 Software   20 days  ¥6.0 M   0 days     ¥0 M  ¥6.0 M
4. System test  15 days  ¥2.5 M  15 days   ¥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 Mr. 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.


[Related articles]
"Introduction to the basic of scheduling, and DRAG as the metrics for project delays” (2016-02-13)

[Website by Steven Devaux]
"Total Project Control"
by Tomoichi_Sato | 2016-03-20 15:58 | English articles | Comments(0)

Introduction to the basic of scheduling, and DRAG as the metrics for project delays

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)
e0058447_23443368.jpg


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)
e0058447_2349663.jpg


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)
e0058447_2350514.jpg


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)
e0058447_23543164.jpg

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.
by Tomoichi_Sato | 2016-02-13 23:56 | English articles | Comments(0)

Push vs. Pull - Comparison of Toyota and Nissan Production Systems

Manufacturing Innovation Forum ("MIF-Ken") is a small study group of consultants in Tokyo. Most of members, including myself, are Registered Management Consultant for Small and Medium Enterprizes who are interested in production systems. We usually conduct plant visit tours twice every year.

Several years ago, our MIF-Ken had a three day journey to Kyushu, a western part of Japan, to see car manufacturing plants of Toyota and Nissan. I was not able to join it, unfortunately, but reports by visiting members were very interesting. The two rival companies have many similarities in facilities and work ways of their plants, although terminologies are quite different from each other. Such similarities are not surprising, because the they manufacture the same category of complex, yet voluminous, machinery product: cars. They both implement "Pull type" production systems. Toyota calles it "Just in Time (JIT)", and Nissan calls it "Synchronization (Douki)". However, we learned there was a fundamental difference between the pull type manufacturing of the two car giants.

"Pull type" manufacturing is usually understood as the way of production that replenishes goods or products which are just consumed. In other words, only needed items of needed quantities shall be supplied at needed timings. "Push type" manufacturing is a conventional way of production of "Make-to-Stock (MTS)". It requires the demand forecast, production planning and pushing out products to the market. To the contrary, "Pull type" is a way of production of "Make-to-Order (MTO)" that is triggered by consumption (pulling out) of parts or products by downstream consumers. Famous "Kanban" system of Toyota is a typical tool to implement this idea to the entire production processes which starts from the product shipping to the raw material supply, and even to suppliers. Other Japanese carmakers do have somehow similar work processes, yet under different names.

Therefore, in order to implement the Pull type manufacturing, you have to allocate minimum quantities of product inventories and work-in-process (WIP) in every stock points and let every work center replenish items in quantities just as much as consumed. No production planning thus is required. In fact, many consultants of "JIT Production" advise such stories to part manufacutrers in Japan.

However, you will later face one difficult problem when you try its plant-wide full implmentation. Stances of Toyota and Nissan to resolve this problem are - according to my colleagues report - very opposit. What is the problem?

It is regarding "Naiji" (advance notice of purchase, or the blanket order). If you wish to make perfect Pull type production system, you have to let suppliers deliver their parts of needed quantities at needed timings. However, suppliers are not like "Doraemon", a cartoon hero who can pull out any items he wants from his magic pocket. In order to cope with daily Kanban orders in a short time, they need preparation in advance. Naiji, an advanced information of parts purchase for coming months, is an inevitable element of Pull type production system. Car makers usually issue Naijis of every items they plan to buy in 3, 2, and 1 month prior to the actual orders.

This Naiji is nothing but the forecast of parts demand. Lead time of the car delivery from factory to dealer is minimum 10 days in Japan. Delivery to the end user will take nearly one month from the final order confirmation because paperwork with authorities takes time. Anyway, it is far shorter than 3 months. Therefore, demand forecast is necessary to provide Naijis to suppliers.

Such demand forecasts are, of course, associated with errors. Car makers revise forecasts every month until the actual month comes. Still, final order confirmation by the end user is just several days before "line-off" (shipment). Gaps between the forecast and actual demands cannot be avoided. In other words, risks of stock surplus or shortage will arise. The main difference between Toyota and Nissan lies in the policy to deal with this issue - directions to hedge such risks seem opposite.

Nissan tries to adjust the gap on the production side. Since stock inventory is always kept minimum, it is difficult to absorb demand fluctuations by part or sub-assy stocks. So, they make every effort to conduct Pull type replenishment and request suppliers to follow them. Lead time to suppliers are forced to be shorter, because longer lead time means larger errors in forecast. In fact, we heard from one supplier that Nissan allowed only 72 hours to them although they needed 96 hours to manufacture. In spite of these efforts, considerable gaps between Naiji forecasts and actuals are still headache for them.

Toyota way is very different from Nissan. Toyota allocates some buffer stocks intentionally. Basic process of automotive plant is (1) body shop -> (2) paint shop -> (3) final assembly line. They seem to have the buffer between the paint shop and the final assembly line, though they never disclose it to visitors. They have some other buffer stock points beside this. When firm orders are given, buffer stocks of part/sub-assy are dispatched in accordance with the sequence schedule. It is like BTO (Buid to Order) production system by Dell Computer.

"Nissan Production Way is Kanban system, and Toyota Production System is BTO" - this was the conclusion by my colleagues. Nissan Way is based on the concept of synchronized production to the firm demand. Nissan's Master Production Schedule (MPS) is just a monthly forecast or a rough indication. It is not a target that leads people. To the contrary, once stepping in Toyota plant, you will see "Production Plan of This Month" shown on the announcement board, with each car model and target quantity.

Then, how and where can Toyota fit the demand gap? They match demand and supply roughly on monthly plans, and precise gap closure is done through controls using Kanban system. Therefore, Production Plan is very important for Toyota.

Professor M. Kuroiwa of Kyushu Institute of Technology, a Toyota Fellow who long served as manager of the carmaker, has once summarized this policy as "Pushing with Naiji and Pulling with Kanban". Very brief but perfect explanation. We see that Toyota never hopes to do "100% make-to-order" like Nissan desires. Push type production comprises one part of their system. They even request selling side to off-take products when necessary. It is aiming at ensure "Heijunka" (production leveling) which is a core of Toyota Production System. I learned this from a Toyota CTO in face to face a few years ago.

In Nissan Production Way, risks of demand gap will be borne by production side. In Toyota Production System, sell side takes the risk. We can regard Nissan as a perfect Pull type producer, whereas Toyota is combining Push + Pull type production. Pushing along with the plan, and pulling for the adjustment/control - this is the way of Toyota.

There would be some arguments, discussing which is the better way. But I think the sales sections knows demand variations and trends better than production sections, as they are closer to the market needs. Therefore, isn't it reasonable that more responsibilities should be on the side who is more sensitive to market needs?

P.S. If you would like to read academic research on this subject, please refer to Takahiro Tomino: "Nissan Production Way and Make-to-Stock: A Comaprison with Toyota", Tokyo University Manufacturing Management Research Center (2010, in Japanese) . Professor Tomino concludes in the paper that Nissan shows strong tendency toward "market-in", while Toyota has attitude of "product-out" that enables sales side to cope with stable production plans.


by Tomoichi_Sato | 2014-02-28 23:43 | English articles | Comments(0)

Book review: Handbook of Emergency Response (edited by A. B. Badiru and L. Racz)

From this year I would start writing English contents in this site, from time to time, to those readers who are interested in the planning and management technologies.


My first article is a review of an interesting book:

Handbook of Emergency Response: A Human Factors and Systems Engineering Approach"
Edited by A. B. Badiru and L. Racz, CRC Press, 08/2013. (ISBN=13:978-1-4665-1457-7).
Handbook of Emergency Response: A Human Factors and Systems Engineering Approach (Industrial Innovation Series)

I happen to know this book by an e-mail from Mr. Stephen A. Devaux, the author of Chapter 21. Mr. Devaux is a well-known project management consultant/researcher and has been creating various innovative ideas. But, why emergency response? The emergency rescue for disasters is an important mission, of course. However, it may not be relevant to project planning or scheduling. No one can plan or schedule disasters beforehand. It seems just a matter of quick response by police, firefighters or military, and should be covered by their routine work -- that was my first impression as an ordinary citizen.

I have learned from this book that my understanding was not correct, or, at least, insufficient. Disasters have wide varieties in time and special spans. Each emergency situation is different from others. It requires a good, precise response plan in quite a short timeframe of an early phase. Adequate and sufficient resources/tools/technologies need to be mobilized. In fact, emergency response is a project of very compressed form. And, true costs of this type of project are not money -- human lives. Therefore, Chapter 21 by Mr. Devaux is titled “Time is a Murderer – the cost of critical path drag in emergency response”.

“Critical path drag” and “drag cost” are metrics proposed by Mr. Devaux in recent years. A critical path is the longest path connecting from the start node to the end node of a project network diagram. It governs the overall project duration. The critical path drag indicates how many days each activity contributes to its entire project length, with taking the parallel activities into consideration.

Suppose an activity in the critical path has 10 days duration. If this activity can be removed, overall project duration normally becomes 10 days shorter. However, if parallel activities exists with the critical path, it does not always happen. If the parallel path has total float of 3 days, it means removal of the critical activity of 10 days turns the parallel activity chain into a new critical path, and thus gives us only 3 day reduction instead of 10. When we wish to shorten project duration, value of the critical path drag is a good guidance for us to judge which activity to tackle -- the ones with larger drags.

Mr. Devaux combined this drag metrics to the cost. It is the drag cost. It is calculated by the critical path drag multiplied by cost of project delay per each day. For instance, if an activity's drag is 3 days and project is constrained with delay penalty at $1,000 per day, then its drag cost would be $3,000.

Cases for emergency response are, however, a little more complicated. There is no simple 'delay penalty'. Instead, we have to consider incremental increase in damage to people or property for every additional hour. He introduces "Damage Control Time Chart" that can illustrate profile of damage along time (p.511). Using this chart together with activity network diagram, Mr. Devaux explains how to obtain drag cost for each activity. Using this technique, he demonstrates in a case study showing a proper planning could reduce rescue time and save 237 lives out of 909 mortalities in 16 hour crisis.

As we see here, logical and quantitative approaches have great values in the emergency response practices. This book is a comprehensive collection of methods and technologies with such approaches. Chapter 5 explains optimization in evacuation route planning wit OR techniques. Chapter 7 deals with optimization of helicopter mission. Chapter 17 (written by the editor themselves) describes the coordinated project systems approach to emergency response. This book also covers wide aspects of human factors that play very important roles in the emergency situations.

In Japan we experienced a big earthquake and consecutive tsunami, and even nuclear plant failure on March 11, 2011. We saw too many tragedies in the area, but some part of them could have been prevented or reduced if quick and proper plans/actions taken in the earliest timing. There were lessons from another big earthquake in Western part of Japan back in 1995, telling us that good coordination among public services is vital in the emergency response. Unfortunately, it seems that lesson has not yet been fully implemented in our country. What we lack here is a structured, systematic approach in governmental planning and operation. Yes, it is the operations research (OR) itself.

I recommend this book to those readers who are interested in the emergency response. This is not a handy guidebook but a compilation of papers by researchers and practitioners, still we can learn a lot about the systems approach.


by Tomoichi_Sato | 2014-01-11 11:13 | English articles | Comments(0)