Individual Activity Estimations

Estimating the individual activities started by listing the types of activities in the project to avoid missing crucial activities. The team classified the TradeMe activities into three categories:

• Structural coding activities

• Nonstructural coding activities

• Noncoding activities

When building the list of activities, the design team expanded each list to include the individual activities and the duration estimation for each activity. The team also indicated the designated role responsible for each activity according to the customer’s process or their own experience.

Overall Project Estimation

The design team asked a group of 20 people to estimate the TradeMe project as a whole. The only input provided was the static architecture of TradeMe and the system’s operational concept. The design team used the broadband estimation technique and came up with duration of 10.5 months and average staffing of 7.1 people. This equated to a total cost of 74.6 man-months.

Behavioral Dependencies

When building the first set of dependencies, the design team examined the use cases and the call chains supporting them. For each call chain, they listed all the components in the chain (often in the architecture hierarchy order, such as Resources first and Clients last) and then added the dependencies. For example, when they examined the Add Tradesman use case (see Figure 5-18), the design team observed that the Membership Manager calls the Regulation Engine, so they added the Regulation Engine as a predecessor to the Membership Manager.

Distilling dependencies from the use cases required multiple passes, because each call chain potentially revealed different dependencies. The design team even discovered some missing dependencies in the call chains. For example, based solely on the call chains of Chapter 5, the Regulation Engine required only the Regulation Access service. Upon further analysis, the design team decided that Regulation Engine depended on Projects Access and Contractors Access as well.

Nonbehavioral Dependencies

TradeMe also contained dependencies that could not be traced directly to the required behavior of the system or its operational concept. These involved coding and noncoding activities alike. Such dependencies originated mostly with the company’s development process and TradeMe’s planning assumptions. For example, the new system had to carry forward the legacy data from the old system. Data migration necessitated that the new Resources (the databases) complete first, so the data migration activity depended on the Resources. Similarly, the completion of the Managers required the Regression Test Harness. In addition, at the time of the project’s design, the plan still had to account for a few remaining front-end activities. Finally, the company had its own release procedures and internal dependencies, which were incorporated as dependencies between the concluding activities.

Overriding Some Dependencies

In TradeMe, a core operational concept was the use of a message bus. It was crucial to choose the right message bus technology and align the detailed design and coding activities of messages and contracts with the message bus. The call chain–derived dependencies showed that the project could defer the Message Bus activity until it was needed by the Clients and the Managers. However, that ran the risk that the message bus chosen by the development team might invalidate prior decisions about design or implementation. The team decided it was safer to address the Message Bus activity first in the project.

Similar logic applied to security. While the call chain analysis indicated that only the Clients and the Managers needed to take explicit security actions, security was so important that the project had to assure Security completed before all business logic activities. This ensured all activities had security support if they needed it and avoided security becoming an after-thought or a late-stage add-on.

Sanity Checks

With the initial network laid out, the design team performed the following sanity checks:

1. Verified the TradeMe project had a single start activity and a single end activity.

2. Verified that every activity in the project resided on a path ending somewhere on the critical path(s).

3. Verified that the initial risk measurement yielded a relatively low risk number.

4. Calculated the duration of the project without any resource assignment. This came to 7.8 months and later would serve as important check of the normal solution.

Network Diagram

Assigning resources to the various activities affected the project network. In several places, the network included dependencies on the resources in addition to the logical dependencies between the activities. After consolidating the inherited dependencies, the network diagram looked like Figure 13-1.

Figure 13-1 contains a couple of collapsed dependencies (indicated by two activity numbers per arrow) that simplified the diagram without affecting its nature. The most notable aspect of this network diagram is that it contains two critical paths.

Planned Progress

Figure 13-2 captures the planned earned value of the first normal solution. The duration of this solution stood at 7.8 months, indicating that the staffing assignments had not extended the critical path. The chart in Figure 13-2 has the general shape of a shallow S curve but is not ideal. The project starts reasonably well, but the second half of the project is not very shallow. The steep planned earned value curve was also reflected in the somewhat elevated risk values. Both the activity risk and criticality risk were 0.7.

Planned Staffing Distribution

Figure 13-3 shows the staffing distribution chart of the first normal solution. As with the planned earned value chart, the distribution in Figure 13-3 is problematic. The distinct peak at the center of the project indicates waste and implies an unrealistic expectation of staffing elasticity (see Chapter 7 and Figure 7-10).

Cost and Efficiency

Based on the staffing distribution, the project total cost came to 59 man-months: 32 man-months of direct cost and 27 man-months of indirect cost. The higher direct cost compared to the indirect cost indicated that this solution likely was very much to the left side of the time–cost curve, where the indirect cost is still low.

The calculated project efficiency was 32%. Since the upper practical limit is 25%, such high efficiency was questionable. Taken together, the direct cost higher than the indirect cost, the conspicuous peak in the staffing distribution chart, and the high efficiency strongly indicated overly aggressive assumptions about staffing elasticity. The solution expected that across all the parallel network paths, resources would always be available at the right time to maintain progress. The rather steep planned earned value chart visualized this expectation. In short, this first attempt at the normal solution assumed a very efficient team, likely one too efficient to be practical.

Results Summary

Table 13-5 summaries the project metrics of this first normal solution.

Adding Enabling Activities

For each Manager service, the design team added the following activities, which enabled the compression:

1. A contract design activity that decoupled the Clients from the Manager. The various contract design activities could perhaps have started after the SDP review, but it was deemed better to postpone them until after the infrastructure was complete. Estimated work per contract: 5 days.

2. A Manager simulator that provided a good-enough implementation of the Manager’s contract. The simulators had to enable full development of the Clients, which now depended on the simulators, not the actual Managers. The simulators had no dependencies on lower-level services such as ResourceAccess or Engines. The simulators needed only the Manager contracts to simulate and the Message Bus. The contracts themselves depended on the infrastructure, which included the Message Bus. Estimated work per simulator: 15 days.

3. A dedicated activity that integrated and retested the Clients against the Managers. The integration activity depended on the completion of the actual Manager and its Clients. The system testing activity now required not just the Clients but also all the Manager integrations to be completed. Estimated work per integration activity: 5 days.

Figure 13-4 shows a simplified network diagram capturing the compression-related activities in red. In the compressed network, the Managers were only near-critical and were developed on a similar timeline to the normal solution. The most important change (which allowed the compression in the first place) was that the Clients now completed a month sooner. However, the reduction in the duration of the project was less than a month because of the additional integration activities following the Managers.

Assigning Resources

The rest of the steps for the compressed solution were virtually identical to those for the normal solution. However, the design team discovered they could reduce the staff by two developers throughout the project by using the architect for one development activity and by pushing the schedule out one week. The company judged trading the slight delay for the reduced staff as acceptable given its challenge in securing more developers. The duration of the compressed solution came in at 7.1 months, a 3-week (9%) acceleration compared with the normal solution (7.8 months). The new resources did consume more of the floats, and the new risk number for the project was 0.74.

Planned Progress

Figure 13-5 shows the planned earned value for the compressed solution. The curve now tapers somewhat at the end of the project, better than that in the normal solution.

Planned Staffing Distribution

Figure 13-6 shows the staffing distribution of the compressed solution. The staffing distribution looks solid for the most part. The initial ramp-up from 3 to 12 people is a bit challenging, but doable. Peak staffing of 12 is the same as the normal solution. Average staffing is at 8.2, compared with 7.5 of the normal solution.

Cost and Efficiency

The cost of the compressed solution came in at 58.5 man-months, slightly less than the normal solution’s cost of 59 man-months. Direct cost was 36.7 man-months compared with the normal solution’s direct cost of 32 man-months. Although this project design solution was faster and at lower cost, the real difference from the normal solution was the expected project efficiency—37%. If the normal solution’s efficiency of 32% required a highly efficient team, the compressed solution demanded nothing less than a team of heroes. Combined with the elevated risk of 0.74, this compressed solution was a disappointment waiting to happen.

Results Summary

Table 13-6 summarizes the metrics of the compressed solution. The compressed solution made an already challenging project (see Figure 13-1) more challenging and created an unrealistically high efficiency expectation. Its major downside, however, was the integration—not the increase in execution complexity. The multiple, parallel integrations occurring near the end of the project offered no leeway. If any of them went awry, the team had no time for repairs. The increase in both the execution complexity and the integration risk in exchange for less than a month of compression was not a good trade.

Even so, this compression attempt was not a waste of time—it proved the compressed solution would be an exercise in futility. The compressed solution also helped the design team to better understand the project and provided another point on the time–cost curve.

Design by Layers and Risk

As discussed in Chapter 12, design by layers yields riskier projects. The design team found that with TradeMe, the risk of the design-by-layers solution was 0.76, up from the 0.7 of the original normal solution (which used design by dependencies). The risk went even higher to 0.79 when ignoring the high-float support activities.

Staffing Distribution

Figure 13-8 shows the planned staffing distribution for the design-by-layers solution. The overall shape of the staffing distribution chart was satisfactory. The project needed only 4 developers, and staffing peaked at 11 people.

Results Summary

Table 13-7 shows the project metrics for designing TradeMe by layers.

Duration, Planned Progress, and Risk

The subcritical solution extended the project to 11.1 months. The planned earned value curve (shown in Figure 13-9) was almost a straight line whose linear regression trend line had an R² of 0.98.

The subcritical nature of the solution was also reflected by its risk index of 0.84. If the company had to pursue this option, the design team recommended decompressing the project by at least a month. Decompression pushed the schedule into the 12-month range, 50% or more longer than the design-by-layers solution.

Cost and Efficiency

The total cost of the subcritical solution was 74.1 man-months, with a direct cost of 30.4 man-months, and the expected efficiency was more reasonable at 25%. The staffing distribution chart (not shown) was missing the hump in the center, as is typical for subcritical solutions (see Chapter 7).

Results Summary

Table 13-8 shows the project metrics for the subcritical solution.

The subcritical time and cost metrics (11.1 months and 74.1 man-months) compared favorably to those for the overall estimation (10.5 months and 74.6 man-months), differing by about 5% in duration and less than 1% in cost. This correlation suggested that the subcritical solution numbers were the likely option for the project. The more realistic 25% efficiency also gave credence to the subcritical solution.

Risk Decompression

The design-by-layers solution had elevated risk and critical pulses, which the design team mitigated by using risk decompression. Since the appropriate amount of decompression was unknown, the design team tried decompressing by 1 week, 2 weeks, 4 weeks, 6 weeks, and 8 weeks, and observed the risk behavior. Table 13-9 shows the risk values of the three design options and the five decompression points.

Figure 13-10 plots these options and decompression points against the timeline. The criticality risk behaved as expected, and the risk dropped with decompression along some logistic function. The activity risk also dropped with decompression, but a gap appeared between the two curves because the activity risk model did not respond well to an uneven distribution of the floats. The calculations that produced the values in Table 13-9 addressed this issue by adjusting the float outliers as described in Chapter 11—that is, by replacing the outliers with the average of the floats plus one standard deviation of the floats. In this case, the adjustment was simply insufficient. A float adjustment at half a standard deviation aligned the curves perfectly. However, the design team chose to just use the criticality risk curve, which did not require any adjustments. The team observed that decompression beyond D4 was excessive because the risk curve was leveling out.

With the values in Table 13-9, the design team found a polynomial correlation model for the risk curve with R² of 0.96:

Risk=0.09t3−2.28t2+19.19t−52.40

where t is measured in months.

Using the risk model, maximum risk was at 7.4 months, with a risk value of 0.78. This point was between the deign-by-dependencies solution’s 7.8 months and the compressed solution’s 7.1 months (see Figure 13-11). The design team removed the compressed solution from consideration because it was past the point of maximum risk. Even the design-by-dependencies solution was borderline risk-wise: At 7.8 months, the risk was already 0.75, the maximum recommended value. The design-by-layers solution was at a comfortable 0.68 risk. The point of minimum risk was at 9.7 months with a risk value of 0.25.

Table 13-10 captures the risk value of these points, and Figure 13-11 visualizes them along the risk model curve.

Recalculating Cost

Recommending D3 required the design team to provide the total cost at that point. While the direct cost was known from the prior formula, the indirect cost was unknown across the decompression range. The design team modeled the indirect cost for the three known solutions, obtaining a simple straight line described by the following formula:

Indirect Cost=7.27t−30.01

The design team added the direct and indirect cost equations together to come up with the formula for the total cost in the system:

Total Cost=2.98t2−50.42t+244.53+7.27t−30.01=2.98t2−43.5t+214.52

Using this formula, the total cost at D3 was 67.6 man-months.