Tradeoffs in Time and Costs

So far we've only considered the time involved in projects. However, project managers also have to control the costs of a project.

There's another reason for tracking costs as well as time. Here's a scenario that illustrates this.

Suppose you're working on a project to put a new catalogue system on-line for a fledgling company. You've gone through all the work of Gantt-ing and PERT-ing the project and have determined that it will take 30 weeks and cost $10,000. Then the owner of the company says that his new business is booming. Customers are calling and faxing requests for products. The people in the catalog-sales department are falling behind using the paper-based catalog which is always out of date. Of course he's angry that "your" project is going to take so long. So you go back to the PM program and try shortening the times of the tasks on the critical path. One way to do this is to hire additional, more experienced programmers, buy the software needed rather than code it in-house. This is called crashing the system and it costs money. At some point there will be a cutoff point--the point where all the critical tasks are the shortest they can be. There will also be a break-even point. You can sink a lot of money into speeding up the project, but the return on the investment won't pay off. To help in deciding where the break-even point is use the following formula:

             crash cost - original cost
Crash rate = -------------------------------
             original time  -  crash time

Suppose you can shave 10 weeks off the project at an additional cost of $10,000. The crash rate would be 10000/10 = 1000.

If the owner of the business claims that he's losing $2,000 a week in sales for lack of an on-line catalog system, you can figure that he'll make the extra $2000 every week that he's on-line. In other words, he'll be able to payoff the additional cost in five weeks and earn an additional $10,000 in the next five weeks.

Aren't text book case-studies wonderful? The numbers are always given as whole numbers, and it looks like nothing can go wrong. Everyone comes up a winner. But, in real life, the numbers are often ambiguous. For example, how does the owner know that he's losing $2,000 a week? Are there other methods he could use to speed up the current system so that he'd cut his losses, such as hiring temporaries. The point is that crashing a system often leads to a crashed system in the worst sense of the term. If you can avoid it, do so.

Press ESC or click the on-screen Back button to return to the previous document.