The Path Less Taken
A lot has been written about the tough time organizations have developing software on time, within budget and to user requirements. The spotty record has been similar for all organizations, whether commercial or government and regardless of size.
For more than a dozen years, an often-cited source on development prowess has been the Chaos Report. When first released in 1994 by The Standish Group of Boston, the report found that organizations viewed fewer than 17 percent of projects as successful, meaning they completed them on schedule, at the expected cost and to full spec. The remainder were either outright failures (canceled) or challenged (came in late, were over budget and/or delivered fewer functions than planned).
Fast-forward to the present, and the good news is that, according to the group’s latest research, 35 percent of projects are successful, and outright failures are on the decline, down from 31 percent to 19 percent. The bad news is that the still-high rate of failures and challenged projects indicates significant room for improvement.
With this checkered past in mind, let’s examine two key components of software development projects: development methodologies and project management.
Methodology: A Philosophical Continuum
Predictive and adaptive approaches, with a wide range of variation on either theme, dominate software development.
The predictive approach derives from engineering disciplines and emphasizes planning before building. Typically, this approach separates design and construction and, from that perspective, is similar to how the engineering and construction disciplines work for building a structure such as a bridge. The theory holds that, with a good design, the coding phase leads to a predictable construction activity.
To continue the engineering analogy, highly skilled resources (architects) create the designs, and less-skilled resources (construction workers) build to the detailed plans. For a bridge or office tower, the cost of design runs about 10 percent of the project; the rest goes to construction. For software, the amount spent during design generally runs much higher — at least 50 percent of the total cost. For building projects, design changes can be minimized, and the construction plan remains highly predictable. But for software, capturing requirements and developing a fixed design can prove elusive; the history of software development suggests that changes to requirements are made throughout a project — and therefore, to some degree, requirements are unpredictable.
Predictive approaches emphasize the processes of developing software and documentation. Traditional waterfall methodologies, for instance, implement the predictive approach.
fact:
65% Software development projects that fail or are challenged (overbudget, late or failing to meet users' needs)
SOURCE: The Standish Group
The adaptive approach, by comparison, takes the view that an organization must anticipate changes in requirements and accommodate those changes throughout design and development. When using this approach, an organization applies iterative development; it produces multiple working versions of a system and revises them frequently to elicit user requirements until completion of the desired application.
Adaptive approaches focus on people over process and demand a much different relationship with the customer or user. The customer is more closely tied to the developers, prioritizing requirements and checking progress and features at every iteration. In effect, the developers and customers work together to adapt the system based on what they see in each iteration. When this process works, customers report greater business value.
The adaptive approach is also referred to as agile development, and organizations ascribe a number of methodologies to it, including extreme programming (XP), context-driven testing, lean development, rational unified process, dynamic systems development method (DSDM) and feature-driven development (FDD). These all share the adaptive philosophy, but each has its own practices, terminology and tactics.
One final differentiator: Organizations measure predictive projects’ success by how well they meet their plans, schedule and budget. They track adaptive projects using a more subjective measure — the business value delivered.
The Role of Project Management
Most simply defined, software project management allows an organization to plan, monitor and control an application’s or application suite’s development. In this context, project planning identifies the scope of a project, estimates the work involved and sets the project schedule.
The purpose of project monitoring and control is to keep the team and an agency’s leaders up to date on a project’s progress and to create a mechanism for taking corrective action should development deviate from the plan. According to much of the research into why software development fails or projects stumble, the culprit most often cited is flawed project management.
Software project management is a separate but related component of the development process, as contrasted with the development methodology. The methodology specifies what will be developed and how an organization will complete development; project management focuses on achieving the planned activities (incorporating both the what and the how).
It is sufficient to view project management as critical to the successful completion of a software development project under either the predictive or the adaptive approach. Although project management processes and tools may differ, the objective remains the same.
The Triumphant Trio
Recent research by The Standish Group shows decided improvement in IT project management, with software development success rates trending upward. It attributes a project’s potential to succeed primarily to three metrics: project size, project duration and team size.
Combined, these three factors translate into the axiom that short timeframes, with delivery of software components early and often, increase a project’s success rate. Creating software in an iterative process — through designing, prototyping, developing, testing and deploying small components — engages users early and confers ownership. There is a greater probability that each ensuing component will meet users’ expectations.
