Don Willerton
This article is the first in a three-part series exploring how you can keep a better handle on your software development project to ensure it doesn’t spin out of control or face cancellation before the product’s release. Because software development involves varying levels of uncertainty, that doubt precludes the use of traditional project management assumptions, processes, and tools. Of interest is the fact that recent developments are leading to different and better ways of managing software development projects.
Software Demands
Software projects are in a world of hurt.
Consider the following daunting statistics: (1)
• The majority of the 300,000 software development projects currently in progress in the U.S. will take longer, cost more than planned, and result in “out of spec” products that fail to meet user requirements. Many of them will be never be finished at all.
• More than half of the large projects (those involving more than a million lines of code) will be cancelled before a new type of software is ready for rollout.
So, what’s the reason behind all the difficulties? As natural as it might seem to pin the blame on technology or the rapid change of technology, that’s not what the studies say. Rather, a Defense Science Board report attributes project failures to “counterproductive management.”(2) In contrast, another study comparing a successful project to an unsuccessful one pointed out that “internal management” was responsible for 60 percent of the cost improvement and 70 percent of the schedule improvement, as well as the overall success of the project. (3)
If both of those assessments are correct, internal management is the key to success or failure when it comes to developing software that survives beyond the idea and ultimately finds itself in the hands of users. Why, then, are software projects so hard to manage? Here is one of the main reasons:
The traditional project management processes, the tools supporting those processes and the ways of measuring and managing progress are almost useless for software development. Yet, the content of almost every “project management” course offering is dominated by traditional project management methods.
The bottom line is this: in learning how to manage projects, most software project managers are actually taught what will make them fail!
A Quick Look at Traditional PM Assumptions
A traditional project management class will make you familiar with these steps and outputs:
• Work breakdown structure,
• Work precedence network,
• PERT/CPM diagrams,
• GANTT charts,
• FTE loading profiles, and
• The overall role of the Project Plan.
Performing some of the typical classroom examples will underscore the objective of project management: to control the project to match the Project Plan. Defining the Project Plan, then, becomes the most important activity of the process, and it, by definition, is done completely before any technical work of the project is done. This reveals the assumption that almost everything about the project’s activities is known and understood before the project is begun.
Consider some of the foundational assumptions that support the use of the Critical Path Method (CPM).(4) The CPM is used to quantify the key activities of any particular project whose durations directly affect the project finish date. The assumptions of CPM reflect the fundamental assumptions of the overall traditional project management philosophy.
With each assumption, imagine the reaction of the typical software project manager:
1 A project can be subdivided into a set of predictable, independent activities.
Predictable? Independent? My requirements may not only significantly change during a project, but I have to actually do some of the project before I can know some of them! I have to discover or invent information in one activity that directly affects other activities in terms of content, duration, and cost!
2. The precedence relationships of project activities can be completely represented by a noncyclical network graph.
Noncyclical? That means no DO LOOPS! But some activities are based on iteration, sometimes being repeated several times, before we can go on. I need a network graph that allows not only loops, but IF statements, to cover the things that I’ve learned don’t have to be done.
3. Activity times may be estimated and are independent of each other.
Estimated? I’m using a fluctuating workforce, a range of technical competence, new workstations, an object-oriented language that most of us are not familiar with, and I don’t even have consistent documentation for our new supercomputer! How about if you just shoot me now?
4. The variance in the length of the project is assumed to be equal to the sum of the variances of activities on the critical path.
An overall delay is the sum of the critical path delays? I have many critical issues and players that influence my project on a daily basis. Any statistical feeling of whether I’m ahead or behind of schedule doesn’t guide my decisions.
5. The duration of an activity is linearly (and inversely) related to the cost of resources applied to the activity.
In theory, this means that if I have double the number of people on an activity, the activity will be done in half the time. I can remember Fred Brooks explaining that adding more people to a software project will eventually have a negative effect, so maybe this works for widget-making, but not for me.(5)
Why Is Developing Software So Hard?
Software development is a process filled with uncertainties. The progress of a software development project may rely on information being discovered or created in the process of performing the project. With projects with high uncertainties, the ideas of estimating, planning, sequencing, and progress seem out of sync with reality.
In The Project Survival Guide, Steve McConnell put it this way(1):
“If you want to understand what software development is all about, you need to understand that the project team has to think through and make all the decisions in one stage before it can know enough about the next stage even to estimate the work involved in it.”
One can guess at a few of the things that will happen if you use traditional management methods for projects with high uncertainty:
• Customers and sponsors may have false expectations in start dates, end dates, activity and project durations. These expectations can carry over into cost and specifications. It’s the usual “being held to a schedule that was created before the project was defined!”
• Traditional project management will not account for “rework”&emdash;the work that will have to be done over because of bugs, changes in requirements, or design changes. McConnell says that rework may account for 80 percent of all of the work of the project!
• The project team will spend useless effort on traditional overhead activities, like reporting, documentation, audits, evaluations, and administrative reviews, with no value added. Upper management and stakeholders have little confidence in project status reports that have phrases like “well, we think that we’ll try this for a while …” and, yet, it may be exactly the right thing to do!
• Software project managers will face big dilemmas with customers and sponsors who don’t recognize or aren’t familiar with the difficulties of projects that involve high levels of uncertainty, exploration, invention, or discovery. It may be especially difficult when the only thing they do understand is a GANTT chart.
The Wild Side: Nontraditional Project Management
Because none of these difficulties are surprising to those in the software business, some software thinkers, researchers and practitioners have developed different, nontraditional approaches to project management. Many of these approaches specifically address the differing levels of uncertainty in projects, as well as prescribing good practices that raise the determinacy of project performance, better requirements matching, lower project cost, faster development times, higher quality, and other factors.
Coming in the next installment, we’ll look specifically at some of the new approaches in “Adjusting for Reality: Mitigating Uncertainty in Projects.”
References:
(1) S. McConnell, Software Project Survival Guide (Microsoft Press, Redmond, WA, 1998).
(2) N. Brown, “Industrial-Strength Management Strategies,” IEEE Software 13, (no. 4) 94-103 (1996). Also, at http://www.spmn.com/whatsnew.html#evm
(3) K. Cooper, “The Four Failures: Systemic Sources of Project Problems” (Paper for Pugh-Roberts, Boston, MA, 1998).
(4) J. D. Wiest and F. K. Levy, A Management Guide To PERT/CPM (American Management Association, New York, 1977).
(5) F. P. Brooks, Jr., The Mythical Man-Month (Addision &endash;Wesley, Reading, MA, 1975).