In-Depth

Successful Project Management: Think Iteratively, Code Early

Is the way most enterprises develop software fundamentally flawed?

• By Stephen Swoyer
• 09/27/2005

A growing number of project managers and programming enthusiasts argue that the way most enterprises develop their software is backwards. Earlier this month, management consultancy Cutter Consortium published a new study that supports one of their key claims, particularly with respect to the core tenets of “agile” project management and software development practices.

Cutter’s study is based on a sample of 232 completed software projects from around the world. It includes a near-equal distribution of short-duration (one to nine months) and long-duration (10 months and over) projects. While some conclusions might surprise you, one probably won’t: short-duration projects are much more likely to be successful than their long-duration cousins.

Cutter measured success according to five metrics: customer satisfaction, the ability to meet budget targets, the ability to meet schedule targets, product quality, and staff productivity.

More to the point, says Cutter senior consultant Khaled El Emam, the research reveals that smaller software projects that unfold as part of a phased, iterative cycle tend to be much more successful than their monolithic cousins. Agile methodologies differ—there’s Scrum for project management, Feature-Driven Development (FDD) and eXtreme Programming (XP) for software development, and countless other variants—but most emphasize rapid, test-driven application development that incorporates advanced features and functionality over time, in successive application builds.

Isn’t it a no-brainer that a smaller, less complex project will have a better chance of success than a large, ambitious one? Not according to El Emam.

“One could argue that large projects are more likely to be cancelled because mistakes can be very expensive, making it difficult for management to continue its support of a project. Many software projects lack an effective problem escalation mechanism, so mistakes can remain hidden for some time,” he writes. “But one could also argue that the significant sunk investment in large projects makes these initiatives harder to stop; it is easier to cancel a small project. My analysis lll didn’t yield a statistically significant difference between large and small projects’ cancellation probabilities. Therefore, project size does not seem to be related to project cancellation.”

False Assumptions

The typical software development project has a fairly high mortality rate in spite of the best efforts of programmers, project managers, and (in some cases) line-of-business customers alike. That may be because some of the most time-honored of project management assumptions are, in fact, false.

Consider the gestation of a software project at a large, Fortune 500 company, in this case, at XYZ Corp., a pseudonym for the prominent network services company on which this account is based. XYZ has its own variation on the classic waterfall model, which we'll call the software development process. Like classic waterfall, SDP describes a multi-stage process for producing software: Define, discover, design, develop, and deploy. Simply by virtue of its structure and process-centric pacing, SDP, like most waterfall-based project models, places a much greater emphasis on planning and documentation than on nuts-and-bolts programming.

A typical project scenario might involve a request from one of XYZ's business units for changes in an application that powers a customer billing system. This request is forwarded to XYZ's requirements analysis and design team, which has one job: Coming up with best-guess estimates for project costs. In this case, the RAD team computes costs based on a custom metric (let's call it level of effort—LOE) that's supposed to translate into projected hours of developer time. If the LOE estimate is low enough, the RAD team passes the request on to IT, which must come up with a lower estimate of its own.

If the cost of the project can be justified, the developer team finally sits down with the line-of-business customer. It's at this point the team and customer hash out the application's requirements in the form of a contract. Once the requirements are finalized and the contract set, XYZ's developers typically won't interact with the line-of-business customer again until the application is finished and ready for testing.

By the time the developer team starts coding, several weeks or months have passed, and it's possible the customer's requirements will have changed, too. Unfortunately, there's not much anyone can do. Making changes to the plan—even minor changes—means generating more documents, attending more meetings, and haggling once more over projected developer person-hours or project delivery dates. This sometimes results in software that does little to solve business problems, even if it does satisfy the application requirements set forth in the contract. It also leads to "cover your backside" thinking among developers and business representatives alike.

Agile disciplines such as XP or FDD turn this process on its head. Agile programming teams – and most agile disciplines are team-based exercises – start coding almost immediately, in some cases directly after meeting with line-of-business customers. Customer input is essential at all stages of the development process, and agile approaches try to get working code into the hands of users as frequently as possible.

“You write code for a week. You show the code to real users. They say, 'That's not what we meant at all.' Since you've only worked on it for a week, you can still change direction without losing too much,” explains author and XP enthusiast Roy Miller, author of Managing Software for Growth.

Forget (Some of) What You Know

Cutter’s El Emam doesn’t explicitly endorse agile programming, but his research does validate one of its core assumptions: namely, that of phased, iterative software development. Agile designs typically start simple and evolve greater complexity over time. El Emam recommends a similar approach.

At the same time, project managers need to revisit some of their own most time-honored best practices, he advises. Consider that most cherished project management rule of thumb – namely, the more coders you have working on a project, the more likely your project will be a success (i.e., finish on time and on budget). El Emam says there’s no evidence to support such an assumption.

Ditto for another cherished project management best practice—throwing more people at the problem. In fact, longer-duration projects (those of greater than nine months) tend to have more developers working on them, while medium- and short-duration projects are likely to have between three and 10 developers, according to El Emam. Needless to say, longer-duration projects have a significantly higher failure rate than their short-term cousins. The upshot is that peak project staffing has no relation to ultimate project success. In other words, he says, the number of developers working on a project is not a critical predictor of project success.

Instead, El Emam notes, one of the strongest predictors of project success is the duration of a project. To the extent that smaller projects are typically of a shorter duration, he says, they are also more likely to be successful.

“[D]uration is a much better indicator of project size than are staffing levels. Smaller projects are more likely to meet budget and schedule commitments than are larger ones. Smaller projects are also more likely to be more productive. There is no difference between smaller and larger projects in terms of customer satisfaction and quality,” he writes.

So what are project managers to do? Start with the basics, he suggests. Get your application architecture down first, and then flesh out your software project with features, functions, and other requests over time. Once the first major release of an application is in the hands of users, considering augmenting it with three-month-project build iterations. It’s in this respect that you can evolve the complexity—i.e., features and functionality—of the application.