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.

        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)
<< 映画評:★★★ 「ヴィヴィアン... プロジェクト&プログラム・アナ... >>