The Cost/Time/Content Triangle
The Cost/Time/Content Triangle is a simple way of representing the rather complex (not to say confusing) interaction between the three key components of any IT project - Cost, Time and Scope. It provides a mechanism for visualising the effect of changes in any parameter and provides managers with a tool for quickly assessing the impact (and hence the risk) of changes to any one component on the others.
The Cost/Time/Content Triangle is a graphical triangle whose three sides each represent a measure for an element of the project. By setting an appropriate scale for each side we can define the limits for the three key elements of any project. This is probably easier followed with an example, so let's consider a simple project that, based on the defined scope (the 'Content' element) has been estimated as comprising 4 key parts totaling 20 weeks of work as follows:
-
Main Data Screens 12 Weeks (55% of the Content)
-
System Admin Functions 3 Weeks (15% of the Content)
-
Standard Reports 4 Weeks (25% of the Content)
-
User Definable Configuration 1 Weeks ( 5% of the Content)
The percentages refer to the contribution each part makes to the whole project. Having got the Content, and Time elements we can calculate the Cost using our standard formula which, in this example is very simplistic and based on a standard Development Cost of $25 per man-hour + 25%, giving us a total cost of $25k:
20 * 40 hrs = 800hrs @ $25 = $20,000 + 25% = $25,000
(Note: this is the estimated internal cost of undertaking the project, not the price we intend to charge to the customer; that is a wholly different algorithm ![Smile [:)]](/emoticons/emotion-1.gif)
)
We can now construct our initial Cost/Time/Content Triangle - using these values to generate the scales. The objective is to get a balance so we want to get our initial estimate centered in the triangle. As you will recall from your Geometry classes you find the center of a triangle by drawing a line from each vertex to the mid-point of the opposing side. Where the three lines intersect is the center. Where each baseline intersects the opposite side of the triangle we set the appropriate estimated value; i.e. Cost = £25k, Time = 20 Weeks and Scope = 100% as shown at Figure 1.
Scope is, of course, the main driving force behind any project and in overall, will largely dictate both the project time scale, and the cost. After all, the more you have to do, the longer it will take, and the more it will cost! However, not all elements of a project scope will have equal weight, and invariably the actual scope consists of two parts, the 'Must Be Done list' and the 'WIBNIF (Wouldn't It Be Nice If…) list". The key to assessing scope is to determine what percentage of the project each element will account for.
Note that, thus far, our Content and Time scales are directly related (10% of the content = 10% of the time) which is what we would expect since our time estimate is based directly on the content. Cost is also directly related to content at this point because it too is derived solely from the content estimate and all we have considered to date is the "must-do" components. In fact, there were (as there always are) a couple WIBNIFs that we estimated as follows:
Moreover our internal assessment is that both the "User Definable Configuration" and the "Standard Reports" are really WIBNIFs too (the basic project could be done as "Phase 1" with just Screens and Admin functions) . So our project scope could drop as low as 70% of the base estimate, or go as high as 120%. These are, therefore the limits for our "Content" scale, which we define as a linear scale. Similarly our time, based on this content, could be as short as 14 weeks, and go out to as much as 25 weeks and we should add an appropriate time scale that covers this range, with some additional margin at each end (we'll see why later). Draw lines from the Content and Time vertices to each point on the relevant scale - this gives us the CTC Triangle shown in Figure 2:
To complete the triangle we need to add the Cost scale. To get this we need to calculate the cost of the project given various alternate elapsed time scales – remember that we have based the estimate on the defined scope. Changing the scope will give us a different cost for a given time scale. Table 1 shows how this works:
and using this as the basis for our time scale we get the final triangle (Figure 3):
All of our estimates relate to the original estimated scope and a time scale of 20 weeks, so now we can assess the impact of changes by simply reading off the appropriate scale. To ascertain the cost of doing the project in only 15 weeks, we do the following:
-
Draw a line from the Cost/Content vertex to the 15 Week point on the Time axis
-
Draw a line from the Time/Content vertex, through the intersection between our new line and the 100% Scope line and extend it to the cost axis to get the revised cost
The value is about £30K, which equates to £2k per week and is equivalent to 24 weeks at the standard rate - doing things quicker always costs more!
Similarly, we can estimate the reduction in cost if the project can be spread over a longer period. For example if we took 24 weeks for the project it cost only £22.5k. Although this equates to reducing our weekly rate to about $940, we still only have 20 weeks worth of work to do and (hopefully) would be able to employ our developer gainfully elsewhere to make up the difference.
Now what about those WIBNIFs? If there are no other changes in the original scope, but our client also wants the Report Generator (estimated at 3 weeks work – or an extra 15% on the original scope) we can immediately see our options:
-
To preserve the original cost, the project will have to take 6 weeks longer, reducing our cost to $960 per week, but gaining an additional 3 weeks of time in which to carry out the extra work
-
To deliver on the original time scale, the cost will have to go up to just over $31,000. Not only is this increasing the amount of work to fit in, but it is also increasing our risk of failure
-
Propose a compromise. Increase the project time line by 4 weeks, and the cost to $28,000. This gives the a cost for the report generator of $3000 but gains us an extra week over estimate in which to do the additional work
In precisely the same way we can rapidly asses the effect of scope changes. If the decision is made that User configuration is not required after all, but that an Ad-Hoc Query screen is, the net result is to change the scope by +5%, the estimate can now be revised as either:
The triangle is really useful when you need, as in the example above, to cope with changes in scope (of the upward variety) at short notice and need to be sure that you can not only cover the costs, but can explain to the client why it is going to cost so much more. However, as you will no doubt have realized by now, the key to the triangle is the initial setting of the scales. This is only as good as the information which you use to generate your estimates, and the relationship which you determine between cost and time.
Typically the cost relationship is not as simple as shown in this example – if we really wanted to increase the scope by 15% and deliver in the original time scale our poor developer would be working over 60 hours per week for five months (not a good scenario!). The reality is that we would need additional resources and that will change the cost relationship. Adding a developer is not simply a question of increasing the hourly billing rate, it also increases the fixed costs; each developer needs equipment, Employment, Administration and Management Overhead costs all increase too. Similarly if the workload falls below 40 hours a week it is not always possible to re-deploy the resource without losing income.
The reality is that the relationship between cost and time is typically a stepped relation, rather than linear. In fact, getting this relationship right is one of the hardest parts of any project estimate, but once you have it, the CTC becomes a powerful tool for assessing risk and managing change.