Project Systems: Distinguishing Fact from Fantasy
From SystemsWiki
A common mental model relative to software reliability is ... "Yes, we could design highly reliable software. The problem is we can't afford it. It will take too long and cost too much. Our most important priority is to get the product to market. If we don't get our product to market quickly, we won't make sales and profit; and, after all, profit is what counts the most."
Based on each of our own personal experiences, this really does make sense. In every personal project we've ever undertaken, we've discovered that making a higher quality product requires more care and therefore more time. The problem is that extending our personal experience to an organizational level is often not valid. In fact, it is quite common that the system-level consequences of our actions are extremely counter intuitive.
What if designing reliable software is actually less expensive at an organizational level than designing lower quality software? What if, as asserted by Putnam & Myers (1991), "When productivity improves, errors seem to decline, or, as others put it, when more emphasis is put on quality, productivity increases."?
If producing higher quality software does result in higher overall organizational productivity, this would change the entire approach our organizations take in producing software. As a consequence, what would be the effect if we were to consider an alternative mental model?
Such a model might be: "Yes, we design highly reliable software because we can't afford to not do so. It takes too long and it costs too much to correct defects once they're in the product. If our engineers aren't fixing problems in response to customer problems, they can be creating new products and features. After all, our most important priority is to make sales and maintain customer satisfaction to produce the highest possible profits."
The end result desired based on both of these world views is the same. How we endeavor to accomplish this result, and our success in doing so, depends on our mental model of the software development process.
Contents |
Systems Thinking and Software Project Management
The system of interactions in a software development project is a complex web which we must understand to avoid the unintended and counter intuitive consequences that cause project overruns and even project failure.
The frightening reality is that many software development projects get caught in what's known as the "Impossible Region." Causal Loop Diagrams of the complex web of effects of such things as, for example, overtime and rapid staffing effects on project quality, schedule and cost show that projects are not just "problems to be solved," but "messes" in the truest sense of the word. We greatly underestimate the magnitude of the unintended consequences of such interactions.
Work Remaining
Fig. 1 indicates that the work remaining with regard to the current project schedule will tend to add to schedule pressure. This schedule pressure will then add to overtime which will subtract from the work remaining with regard to the current project schedule. This structure represents a Balancing Loop (B1) where overtime is used to compensate for the work remaining.
Morale & Fatigue
The structure in Fig. 2 points out a couple unintended consequences of increasing overtime to compensate for the work remaining situation.
While overtime is intended to compensate for the work remaining it has a couple additional influences. Overtime, if employed for too long, begins to subtract from morale, which will subsequently add less to productivity. Productivity subtracts from overtime, though if productivity is declining it will subtract less from overtime essentially increasing the overtime required. This structure represents a viscous Reinforcing Loop (R2) moving the situation opposite to the direction desired.
At the same time as overtime subtracts from morale it is adding to fatigue. Since fatigue subtracts from productivity it essentially further increases the overtime required. What we have is another viscous Reinforcing Loop (R3) moving the situation opposite to the direction desired.
If these unintended consequences weren't enough of an annoyance, the following structure points out a couple additional unintended consequences.
Undiscovered Rework
While morale and fatigue are influencing productivity declines, morale and fatigue also have the nasty habit of influencing quality to decline. Yes, morale adds to quality though with morale declining it tends to add less to quality making it even easier for fatigue to subtract from quality. The decline in quality is often not immediately realized but enters into the structure as undiscovered rework. This undiscovered rework is work that needs to be done, we just don't know about it yet as it's undiscovered. As undiscovered rework increases it will tend to influence us to find more of the rework thus increasing the known rework. Known rework just serves to increase the amount of work remaining which adds to schedule pressure, and subsequently increasing the need for overtime. Here we are again, with two viscous Reinforcing Loops (R4) & (R5), taking us in exactly the direction we don't want to go.
Quality
A short time ago we addressed the manner in which decreases in morale and increases in fatigue tend to cause quality to decline. The following structure, Fig. 4, alludes to another influence resulting from a decline in quality.
As quality declines, and once the decline is realized, there will be an increased focus placed on quality. This is represented in Fig. 4 as as quality pressure. As quality pressure increases it will tend to add to quality. Thus we finally have a Balancing Loop (B6) which moves something in a desired direction.
Fatigue
Yet, don't get too comfortable for the following structure in Fig. 5 provides an insight into an unintended consequence of quality pressure which isn't quite so beneficial.
Once a decline in quality is realized there is an increased emphasis on quality, i.e. quality pressure. This increase in quality pressure will serve to improve quality as shown in Fig. 4. Yet, an increase in quality pressure also serves to subtract from productivity because there is more of an emphasis on getting it right than getting it done. So this decline in productivity serves to promote more overtime which increases fatigue and decreases morale. The end result being a tendency for quality to decline. Thus we have two more viscous Reinforcing Loops (R7) & (R8), which simply indicate that the more quality pressure applied the more will be needed. Doesn't seem to make much sense does it? Welcome to the dysfunctional reality of organizational life!
Elaboration of Understanding
When we merge the structures in Fig. 2, 3, 4, and 5 with Fig. 1 we end up with Fig. 6. The current elaboration of the understanding.
Before you let yourself become overwhelmed by the complexity of this diagram you had best fasten your seat belt as we're only about half way there.
Cost Pressure
Overtime has this real nasty habit of costing more than regular time so there are some implications of increasing Overtime.
As depicted in Fig. 7 an increase in overtime brings with it an increase in overtime cost. As overtime cost increases there is an increased emphasis on cost which shows up as cost pressure. The cost pressure is interpreted by the management of project in such a way that it shows up as additional schedule pressure. This increased schedule pressure then leads to even more overtime. Here we have but one more viscous Reinforcing Loop, (R9), in which actions influence the overall effect to be just the opposite of what is desired.
Burnout & Hiring
Overtime and overtime cost have a couple more influences as depicted in Fig. 8.
Prolonged overtime has a tendency to lead to burnout which means hiring must occur to replace or augment resources. Yet hiring only serves to increase cost pressure also, creating another viscous Reinforcing Loop (R10).
Also, in an attempt to minimize overtime costs additional resources are hired. And, because of the time delays involved, hiring only serves to increase cost pressure. We therefore have another viscous Reinforcing Loop (R11) driving cost pressure to increase schedule pressure leading to more overtime. Does it sound like things are going down hill fast?
Percent New Staff
Now, as Fredrick Brooks stated in "The Mythical Man Month" (1986) more than 20 years ago, "Adding additional resources to a late software project only makes it later," has a very solid foundation. What follows in Fig. 9 is another unintended consequences of hiring.
Hiring serves to increase the percent new staff which tends to increase attrition rate which simply serves to require more hiring. You guessed it, another viscous Reinforcing Loop (R12).
Supervisor Strain
As the percent new staff increases it tends to produce supervisor strain. As supervisor strain increases it influences a decline in productivity and an increase in overtime, and we're back to the same part of the model presented in Figure 8. Yes, another influence which is part of two viscous Reinforcing Loops (R13) & (R14). Are you beginning to feel there is no hope in sight?
Average Skill level
Percent of new staff has another influence, described in Fig. 11, which is just as miserable.
As percent new staff increases it decreases the average skill level of the resource pool. This has a tendency to decrease quality which creates two new viscous Reinforcing Loops (R15) & (R16). The reduction in the average skill level also has a direct impact on productivity, but yet another viscous Reinforcing Loop (R17). All this would itself be bad enough, though this feeds right into the viscous Reinforcing Loops described in Fig. 3 and Fig. 5.
Nightmare
Now when we combine the implications developed in Fig. 7 thru 11 with Fig. 6 we have a nightmare even I'm not happy looking at.
Schedule Pressure
Schedule pressure has a couple additional influences that should be mentioned.
Schedule pressure serves to increase overtime thus reducing the work remaining and finally decreasing the schedule pressure, this is the Balancing Loop (B1) from Fig. 1. This Balancing Loop (B1) is supported by a virtuous Reinforcing Loop (R18) as schedule pressure tends to increase productivity. This increase in productivity then tends to decrease overtime decreasing the work remaining. This decrease in work remaining then promotes less schedule pressure.
Schedule pressure also has an effect on quality.
Schedule pressure serves to influence quality to decline. This decline in quality results in an increase in quality pressure which serves to decrease productivity resulting in an increase in overtime. The increase in overtime then serves to reduce the work remaining. This is a Balancing Loop (B19) such that an increase in schedule pressure tends to reduce schedule pressure. The decrease in quality due to the increase in schedule pressure serves to increase the undiscovered rework thus increasing known rework and the work remaining. The increase in work remaining influences an increase in schedule pressure. This is yet another viscous Reinforcing Loop (R20) where an increase in schedule pressure tends to influence additional schedule pressure.
Project Complexity
Now, combining the structures in Figure 13 and 14 with Figure 12 we have:
If this is reality, is it any wonder we have such difficulty getting projects done on time and within budget?
Reality Revisited
Our standard approaches for managing and controlling projects (including reviews, work breakdown structures with earned value-based tracking, and PERT/CPM and Gantt scheduling) are not adequate to understand, and guide us to prevent problems caused by these dynamics. Using them is like driving by looking in the rearview mirror.
For example, projects often get a bad start due to underestimating the effort and the time required. Project underestimates often end up causing seemingly never-ending difficulty and would cause Mr. Rogers to ask, "Can you say Death Spiral?" Underestimates can put projects in what might be called the "Dead Meat" region where they are subjected to large and simultaneous quality, schedule, and cost pressures.
This region is larger than one might think because the effort required on a project increases as the cube of the code size and the inverse fourth power of the development time (see "Measures for Excellence" by Putnam and Myers, 1992). Seemingly minor underestimates in code size and/or duration-required can cause a major underestimate in the effort required.
While managers have little control over projects, they do have great influence in avoiding the unintended and counter intuitive consequences that cause projects to falter. Systems thinking can help managers, engineers and programmers understand the dynamics of project system, their part in the system, and the varieties of policy feedback that cause project performance problems.
Such a systems perspective sheds light on what doesn't work, and on what does work, in managing software projects. For example, demanding excessive overtime and hiring personnel too rapidly definitely don't work because they have an adverse impact on quality and productivity -- and ultimately on project schedule and cost.
Among the things that work are to:
- Do excellent planning including product specs, project plans and test plans before starting development,
- Guard band schedule beyond the minimum development time because, for example, a 15% schedule guard band saves ~50% in required manpower,
- Identify independent, parallel development opportunities, because two decoupled sub-projects take about one quarter the manpower of one large project of the same size,
- Test as soon as possible to avoid the effect of defects on downstream code, and
- Before the project starts, identify optional functions that can be worked on later, or dropped, if the project gets in trouble.
References
Special thanks to Bob Powell, Ph.D., MBA, for contributing the conceptual foundation for this article. Bob is a consultant in continuous improvement and learning organizations based in Colorado Springs.
- [prjsys.msys] MapSys Diagrams
- Brooks, Frederick P. (1986) The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional
- Putnam, Lawrence H. & Meyers, Ware (1991) Measures For Excellence: Reliable Software On Time, Within Budget. Prentice Hall
| Systems Thinking World Discussions Systems Thinking World Q&A * Gene Bellinger |
