vive la difference?


August 1991


PM NETwork believes that difference in opinions is like conflict in project management. It can lead to clarification of concepts and better understanding of our profession. Bill Duncan provides a different opinion from that presented in William Roetzheim's article, Managing Software Projects: Unique Problems and Requirements (May 1991).

We welcome other opinions on these or any article published in the PM NETwork. They may be published as Letters to the Editor or as articles. So, shake hands and come out stating your case… and smiling!

The purpose of “Concerns of Project Managers” is to share expert knowledge and opinions on topics of general and continuing interest to PM NETwork readers. The opinions expressed in these columns are those of the respective author. They are in no way to be construed as official positions of PMI on an issue or endorsements, either positive or negative, of any product or service mentioned herein.

William R. Duncan, Duncan Associates

In the May PM NETwork, William Roetzheim describes some “unique problems and requirements” of software development projects versus construction projects. But is software development really so different? And whether it is or isn't, should the average PMI member care? Yes, for two very important reasons:

  • PMI's efforts to build professionalism in project management are grounded in the assumption that there is a common body of knowledge applicable to most projects inmost cultures most of the time. If there is a major category of projects (software development) that is unique, then this assumption is false and our efforts in this area are misguided.
  • Many of Roetzheim's arguments have been used by others to justify delays and overruns on software projects. With software in most everything we buy or use from automobiles and VCRs to HVAC and airplane guidance systems, both our lives and our livelihoods are affected by performance in this area.

So, back to the question at hand… are software development projects really so different from construction projects? Let's review the arguments one by one as they are presented in the article.

1. “Non-software project planning emphasizes the dependency definition and scheduling steps.” This assertion is true if we compare the entire software development process (from concept to implementation) with only the implementation phase of a construction project—the actual erection of the structure. But such a comparison is not fair, we must either compare the software development process with the real estate development process, or we must compare programming with construction.

When the comparison is done fairly the different emphases disappear. Simply substitute “implementation phase” for “non-software project” in the phrase above, and you have a true statement. Roetzheim himself points out the need to emphasize scheduling during the implementation phase (see item 6 below).

2. “A relatively significant (perhaps 30 percent) amount of the project work involves deciding what to do!” This statement is true of well-managed software development projects, but it is also true of real estate development and thus not unique to software. The solution presented to this “unique” problem-developing a new “task decomposition” after completing a major deliverable—is nothing more than a call to use a phased development process with a revised Work Breakdown Structure and up dated cost and schedule estimates at the completion of each major phase.

Ironically Roetzheim's approach is exactly that described in the Framework section of the PMBOK document—and the PMBOK document has been criticized for being too construction-oriented!

3. “Completion of tasks is difficult to measure.” This point is illustrated by comparing the pouring of a building foundation to coding a software module. But the comparison is unfair. Comparing screen layout for a computer program (easy to measure) with installation of cooling pipes in a nuclear power plant (hard to measure because it is necessary to x-ray the pipes for structural defects after installation), it would appear that completion of software tasks is easier to measure.

The real issue is not the nature of the task but the nature of the task definition. Most software developers define tasks in terms of responsibility assignments (“do all required coding for module X”) rather than in terms of measurable completion criteria (“Code module X until all defined unit tests are run successfully”).

Defining tasks in terms of measurable completion criteria also provides better feedback into the estimating process. The software project manager can now tell whether coding or testing was underestimated, whether modules completed as estimated cause more or fewer testing problems, and soon.

Further, the implication that “hidden defects” are a problem unique to software development is spurious. Remember the Tacoma Narrows Bridge? The Kansas City Hyatt?

Even small construction projects are susceptible. When my house was built, one of the carpenters put a nail into the pipe feeding the showerhead while installing shelves in the bathroom closet. But the nail was a tight fit, and it was four months before it rusted out and water began leaking. To paraphrase “even a [plumbing fixture] which is marked complete can (and often does) still require additional work to correct hidden defects…”

4. “I can literally meet the exact same set of requirements with software whose cost and complexity vary by a factor of ten.” This could be true of construction as well. If my requirements are “I want a 10,000 square foot office facility,” costs could easily vary by a factor of ten. Will it be first class space or economy? Urban site or greenfield? High rise or low rise? Even something as simple and straightforward as a four-bedroom, single-family home could have significant cost variations based on options such as kitchen cabinets, bathroom and lighting fixtures, or choice of heating unit.

The problem is poorly defined requirements. And it is not unique to software development.

5. “Software dependencies are always of the partial-finish-to-start variety.” See item 3 above regarding comments on completion criteria. Some construction projects are even scheduled this way on purpose it's called “fast tracking” and is recognized as a riskier approach.

6. “Very few software dependencies are rigid requirements. ” Yet two paragraphs later, Roetzheim contends that “the unique characteristics of the problem being solved often drive the sequence in which tasks should be completed.” Sorry, but you can't have it both ways.

The lack of rigid dependency requirements is common to the concept and design phases of all projects, from software development through electronics and aerospace to real estate development. The more rigid dependencies do not appear until the implementation or construction phase-and when they do appear, they appear in all kinds of projects.

7. “Software dependencies… originate within the people doing the work and the problem being solved.” This is simply a recognition of the need to calculate a resource constrained scheduled. Any construction manager worth a weekly paycheck knows that scheduling a project based solely on task dependencies is pure folly. Again, there is a very real problem to be solved, but it is not one unique to software development.

8. “Estimating resource requirements…is much more difficult Because] costs are non-linear.” The assertion that construction costs are strictly linear is simply false. Material costs may be reasonably linear over a broad range of facility sizes, but total project costs are not. The total cost (concept, design, implementation) per square foot for a 1,000,000 square foot building is significantly more than the total cost per square foot for a 10,000 square foot building.

There is even a substantial body of literature around the difficulty of estimating costs on construction megaprojects (implementation only) and—surprise, surprise—the issues identified (changing requirements, integration difficulties, communications, overhead) are exactly those which cause problems on large software. projects.

9. “Software project managers have very limited long-term historical information to assist them in preparing resource estimates.” This is a self-inflicted pain. Historical cost and schedule performance data are routinely discarded because “every project is different .”

One commercial software developer I worked with had extensive historical data showing that more than 90 percent of their actuals were between 190 percent and 220 percent of their estimates. Rather than responding to the statistical probability that the next actual would be twice the estimate, they explained every variance in terms of a “unique” one-time occurrence.

10. “Risk analysis is significantly more important [because] every software project is doing something new and different.” Well, every construction project is doing something new and different as well. Good architects will use the same plans to meet the same requirements whether they are designing software or buildings. Good implementers will use the same techniques to solve the same problems whether they are writing code or installing wiring.

Once again, a note of irony the types of risk identified and the concept of doing risk analysis on a task-by-task basis is straight out of the “construction-oriented” PMBOK.

11. “A detailed and accurate schedule…is only possible with continuous revisions to the initial schedule.” No argument here. But also nothing unique about software development. Construction project managers routinely update their schedules at least weekly and often daily. A large construction project will even have two or three full-time professional schedulers who do nothing but update the schedule.

12. “‘There are additional (although more debatable) differences during…tracking and control. Specifically, technical awareness is more important,…quality control is most important,… [and] the software project manager must manage the customer.” This may be true if we compare software development to residential home construction, but what if we compare it to the design and construction of a nuclear power plant?

I've been involved in managing software development projects for nearly twenty years. I've been involved in managing non-software development projects for nearly eight. The differences are more imagined than real. Software developers can learn to deliver every project on time, within budget, and without compromising quality by adapting generally accepted project management practices from other industries.

William R. Duncan, in addition to heading his own consulting company, has been a very active PMI member and is Co-chair of PMI's Standards Committee and, therefore, has more than a casual interest in the subject discussed here.