The Case For Results-Based Software Management

Consider the old way of thinking about project management: You develop a detailed plan of activities, track that plan's execution, and adjust for variances between planned performance and actual performance. Traditionally, you assess a plan's quality by scrutinizing its level of detail. There's little uncertainty about the steps or the eventual outcome in the construction industry, for example, where the laws of physics, properties of materials, and maturity of building codes and practices are established engineering disciplines. Success simply depends on resource management and proper execution of the plan.

But in the software-development industry, these traditional methods cause a huge percentage of software-development projects to founder. True, a sequential, activity-based construction approach may be better than nothing, but the success rate for software projects following this approach (typically called the waterfall model) is about one in 10.

It's tempting to compare software construction to the building of a house. After all, both projects involve requirements management, design (blueprints), scheduling, specialty teams (comparable to roofers, carpenters, plumbers, etc.), and inspections.

But decades of software projects have shown us that traditional modes of construction are very different from the diverse ways in which software is designed and delivered to the customer. One reason for such a low success rate is that traditional project-management approaches do not account for the level of creativity often required to complete software projects that are initiated with significant levels of uncertainty regarding:

Why so much uncertainty? One reason is that software is "soft"; it's easily changed. What software is required to do, and how it does that, usually changes over time as our understanding of the problem, the solution, and the planning evolve. For this reason, it's counterproductive to require five-digit precision in the design when the development team has only one-digit precision in understanding of the problem.

What we've learned is that software management is better described in terms of "software economics" than "software construction" or "software engineering." Day-to-day decisions in software management are about value judgments, cost tradeoffs, human factors, macroeconomic trends, technology trends, market strength, and timing. They are rarely concerned with mathematics, materials, physics, or established engineering tenets.

So what we need is a modern way of thinking about software-quality management that accommodates our industry's 30 years of lessons learned and patterns of successful projects. Today's modern software-management approaches steer software projects through the minefield of "uncertainties" rather than tracking against a precise long-term plan. Delivering innovation on schedule and on budget requires iterative life cycles, constant risk management, objective oversight, and a "steering" style of leadership that demands creativity throughout the team, however large or small.

The Waterfall Approach
The traditional "waterfall" approach to project management is a sequential, activity-based paradigm--i.e., do requirements activities, then design activities, then coding activities, then unit testing, integration activities, and finally system acceptance. I've identified 10 classic principles of this approach:

To continue the building analogy, these principles align with traditional construction approaches. Don't do any blueprints until you've got every detail discussed and approved with the owner; don't build anything until the owner has totally approved the blueprints; pneumatic nail guns are better than hammers for the bulk of construction; buy standard plumbing fixtures, toilets, appliance, and electrical fixtures and they will install and integrate with no issue; require city building inspectors at each major milestone to ensure compatibility with established codes. Nothing wrong with that--unless you're building software.

The Results-Based Approach
By contrast, iterative development techniques, industry best practices, and economic motivations drive software-development companies to take a more results-based approach. Develop the business case, vision, and prototype the solution; elaborate this into a basic architecture; create usable, iterative releases; and then finalize into field-ready code.

Here are my top 10 principles of results-based software development:

Build the architecture first. An early focus on the architecture results in a solid foundation for 20% of the stuff (requirements, components, user interactions, project risks, etc.) that drives the overall success of the project. Understand the architecturally important things and stabilize them before worrying about the complete breadth and depth of all the artifacts, and you'll see far less scrap and rework over the course of the project.

Confront risks early. Resolving the critical issues first results in more predictable production with fewer surprises to impact your budget and schedule.

Use component-based development methods. The complexity of any software effort is mostly a function of the number of human-generated elements. Reduce this complexity by using existing architectural frameworks (like .Net and Java 2 Enterprise Edition) and their rich libraries of pre-built components.

Establish a change-management environment. Along with the advantages of iterative development comes the need to carefully manage changes to artifacts over the course of the project.

Use tools that automate the process. This enables teams to spend more time designing and writing the software, less time on overhead tasks.

Design software with rigorous, model-based notation. An engineering notation for design enables complexity control, objective assessment, and automated analyses.

Use automated metrics for quality and progress assessment. Progress and quality indicators are derived directly from the evolving artifacts for more meaningful insight into trends and correlation with requirements.

Maintain working versions of the software. Because the integration of software components occurs early, then continues throughout the project, it's important to maintain demonstrable working code. Intermediate results are objective and tangible, so integration issues emerge quickly and are more readily solved.

Plan releases with evolving levels of detail. Each project increment and demonstration should reflect current levels of detail for both requirements and architecture, since these things evolve in balance. What's more, the level of precision in the software evolves along with the level of understanding of the project team.

Establish a scalable, configurable process. No single process is suitable for all software-development projects. To be pragmatic, a process framework needs to be configurable for a broad spectrum of applications. This ensures economy of scale and best return on investment.

The Mark Of Success
The most discriminating characteristic of a successful software-development process is a well-defined separation between "research-and-development" activities and "production" activities. When software projects do not succeed, the primary reason is usually a failure to crisply define and execute these two stages, with proper balance and appropriate emphasis. This is true for both traditional (waterfall) and iterative processes. Most unsuccessful projects exhibit one of these characteristics:

By contrast, successful projects tend to have very well-defined project milestones in which there's a noticeable transition from a research attitude to a production attitude. Earlier phases focus on achieving functionality; later phases revolve around achieving a product that can be shipped to a customer.

Software management is hard work. Technical breakthroughs, process breakthroughs, and new tools will make it easier, but management discipline will continue to be the crux of software-project success. New technological advances will be accompanied by new opportunities for software applications, new complexities, new modes of automation, and new customers with different priorities. Accommodating these changes will perturb many of our ingrained software-management values and priorities. However, striking a balance among requirements, designs, and plans will remain the underlying objective of future software-management endeavors, just as it is today.

Walker Royce is a VP of Rational Software Corp., where he serves as general manager of the strategic services organization. For the past seven years, he has managed large software engineering projects, consulted with a broad spectrum of Rational's worldwide customer base, and developed a software-management approach that exploits an iterative life cycle, industry best practices, and architecture-first priorities. He's the author of Software Project Management, A Unified Framework (Addison Wesley Longman, 1998) and a principal contributor to the management philosophy inherent in Rational's Unified Process. Before joining Rational, Royce spent 16 years in software project development, software technology development, and software management roles at TRW Electronics & Defense.

Walker Royce is the VP of Rational Software