The Five Dimensions of a Software Project, Part 2

In the first article in this series I described five dimensions of a software project: features, quality, schedule, staff, and cost. Each of these dimensions can be a project constraint, a driver, or a degree of freedom. A way to classify each dimension into one of the three categories is to think of the amount of flexibility the project leader has with respect to that dimension. A constraint gives the project leader virtually no flexibility, a driver has low flexibility, and a degree of freedom provides wider latitude to balance that dimension against the other four.

Flexibility Diagrams

A graphical way to depict the degree of flexibility is with a Kiviat diagram, also called a radar chart or a spider chart (Figure 1). In a Kiviat diagram, you show the five dimensions around a circle and draw a separate axis for each dimension coming out from a common origin point in the center. All the axes are the same length and they are normalized to the same scale. Each axis represents how much flexibility the project manager has in the corresponding dimension, so I call these pictures “flexibility diagrams.” I use a relative scale from zero to ten for flexibility. Zero is not shown at the exact center of the origin just for convenience in drawing the plot.

Figure 1. Flexibility diagram for a corporate information system.

Plotting a point at zero indicates that the dimension for that axis is a constraint with no flexibility. If you plot a point fairly low on the axis, between zero and two or thereabouts, that represents a driver. It shows that the project manager has a small amount of flexibility in that dimension. Any dimension plotted at a higher level on its axis represents a degree of freedom having more latitude for adjustment. If you connect the five points for the five dimensions that you plotted, you get an irregularly shaped pentagon that visualizes one profile of the project’s characteristics.

Figure 1 shows the flexibility diagram for an information system my team once developed. This project was constrained to a fixed staff size, so the value plotted on the staff axis is zero. The project was aiming for a desired, but not critical, delivery date, so the point on the schedule axis also has a low value. The project had varying amounts of flexibility around the features that would be incorporated into the initial release, the product quality, and the latitude for cost overruns. Therefore, the values for these degrees of freedom are plotted higher on their axes.

Note that this is not a high-resolution or quantitative tool. We’re not going to calculate the area of the pentagon or anything like that. But the size of the pentagon does provide a rough indication of how much flexibility the project manager has to work with. If the pentagon is small, that means that you have numerous constraints or drivers, which will make it more difficult for the project manager to steer a path to success.

Different types of projects will lead to flexibility diagrams having very different shapes. Figure 2 illustrates a flexibility diagram for a hypothetical project for which quality is a driver and the schedule shows the greatest latitude. This is what you might see for a product intended for use in a higher-risk environment. Note that this diagram does not show any constraints; none of the axes are plotted at the zero value. That’s fine. In contrast, the profile for a commercial software product in a highly competitive environment might look like Figure 3, in which a specified feature set must be included (a constraint), the schedule is constrained to a specified ship date, and the quality is just whatever it turns out to be.

Figure 2. Flexibility diagram for a quality driven application.

Figure 3. Flexibility diagram for a competitive commercial application.

The shapes of the pentagons in these examples visually indicate the important aspects of each project. If you push the point on one of the axes inward to reduce the amount of latitude the project leader has in one dimension, you’ll generally have to adjust the other dimensions to compensate. You can use this sort of analysis to make management aware of the tradeoffs and decisions they must make to meet a project’s key objectives, and to negotiate realistically achievable commitments on each project.

Flexibility Table

You can also document your project priorities in the form of a flexibility table, as illustrated in Figure 4. This example is simplified just to give you a flavor of how this works. For each project constraint, state the limits the project manager must work within. For each success driver, described the goal you’re intending to achieve. For each degree of freedom, describe the tolerance or latitude that the project manager has available.

Figure 4. Sample flexibility table

The table in Figure 4 is for the project whose flexibility diagram appears in Figure 1. Recall that staff was a constraint. We had just five full-time team members available for the duration of this project. Schedule was a driver. We wanted to have the first release delivered within four to five months, but there was no fixed delivery date. The other three dimensions had more flexibility. Because the project was essential, the project manager could overrun the initial budget by a reasonable margin before anyone would get upset. We did have a core set of high priority features that we needed to have delivered in the first release, but other than that, we could defer some requirements if necessary.

Note that each of the five dimensions takes on only one characteristic. For example, schedule is either a constraint, a driver, or a degree of freedom, not two of these or all three. You wouldn’t have entries for the same dimension in more than one column in a flexibility table.

Applying the Five Dimensions

The point of this analysis is to help the project manager make decisions as to how to respond to changing conditions or realities on the project. You can use the five-dimension model to renegotiate when the world changes. Suppose staff is constrained as it is in Figure 1. If new requirements come along that simply must be included, the only parameters that can change are quality, cost, or schedule. Nothing is free. Ask management which dimensions to adjust to accommodate this request. The specific answer is less important than the discussion that is triggered when project managers react to unexpected changes in any of these five dimensions. Customers and managers have to understand the impact of such changes on the other project dimensions so they can make the right decisions.

One characteristic of a healthy software engineering culture is that project expectations and commitments are established through negotiation. To avoid unpleasant surprises late in a project’s life cycle, the stakeholders all have to understand and agree on their objectives and priorities. Not everyone might be happy with the outcome of the negotiations, but people can commit to realistic schedules and deliverables only if all the parameters are discussed honestly. A group with a culture in which people are afraid to say no or to discuss problem areas openly will always fall short of expectations. Tools like the flexibility diagram can facilitate these frank, and often difficult, negotiations.

Don’t forget to leave your comments below.