Software project management and the balance between management discipline and creative freedom



The Software Capability Maturity Model (CMM), and to a lesser degree the integrated CMM (CMMI), have their roots in the software projects that were undertaken during the 1970s and 1980s. Since the sponsor for the Software CMM was the U.S. Department of Defense, the projects researched as sources of best practices tended to be large, complex projects, and the principles captured within the Software CMM seemed primarily to be applicable to the same type of project. Consequently, over the last decade numerous smaller companies have looked at the Software CMM and decided that it simply did not apply to their types of software projects, or to their circumstances.

During the last few years some alternative software management paradigms have been receiving increasing visibility. Examples of these alternatives include “Adaptive Software Development” and “Extreme Programming.” The premise behind adaptive and extreme software development is that the rate of change occurring on many software projects—especially software companies working on Internet-based or Web-based products—is so fast that the “command and control” philosophy embedded within the CMM and CMMI (CMM/I) are inappropriate. Consequently, the alternative approach is adaptive and/or extreme development. Put simply, in this paradigm rapidly changing circumstances are viewed as an opportunity and something that can be used advantageously, and this approach is considered by many of its proponents to be the opposite of the CMM/I approach.

It is relatively easy to see how the CMM/I is applicable to large, complex software projects. However, small projects and small companies frequently have difficulty seeing how the CMM/I frameworks apply to their circumstances. The criteria often used to assert whether or not the CMM/I is applicable to a given project include: project duration, number of team members, requirements completeness, requirements stability, project dollar value or funding level, and product size.

At one end of the software development project spectrum are the projects that were more common during the 1970s and 1980s. These were often multiyear projects sometimes involving hundreds of developers. These projects often had extensively documented requirements, involved tens or hundreds of millions of dollars (US), and built—or attempted to build—very large, complex systems sometimes involving millions of lines of code.

At the other end of the software project development spectrum are today's dot-com companies, Internet start-ups, Web start-ups, incubator companies, first-round venture funding software startups, and similar organizations that commonly assert that the software development they do, and the projects they undertake, are “completely” different from traditional, large software projects. Many of these companies, for example, limit project durations to six months—and sometimes as little as three months. A project team might consist of one person, part time. Requirements may be virtually unknown.

The polarity of these two ends of the software development spectrum can be readily understood in terms of their primary values or philosophy on how to achieve success. The “old view” is that success is achieved via: order, structure, rules, control, and repeatability. The “new view” is that success is achieved via: flexibility, variability, freedom, innovation, and creativity.

It is from the world of smaller, younger, and more agile organizations that many of the concepts of adaptive, emergent, and extreme principles were developed. Although primarily intended for high-agility organizations and projects, the principles of adaptive or extreme development are arguably applicable to any software development project. Similarly, although the CMM/I is primarily intended to promote organizational stability and predictability, the principles of the CMM/I are also, arguably, applicable to any software development project.

This paper examines the principles behind the CMM/I and then looks at the basic tenets behind adaptive and extreme programming. The applicability of the CMM/I and extreme programming to a variety of environments is examined, particularly from the perspective of where these frameworks provide value, and where they fundamentally conflict, at least potentially, with either themselves or with the project or organizational environment. The paper concludes with a discussion of how to achieve an appropriate mix of both management discipline and creative freedom.

Capability Maturity Models

The two primary principles behind the Software CMM and the CMMI are (1) command and (2) control (Highsmith, 2000). The CMM/I frameworks essentially require that you implement and perform certain processes that help ensure efficient and effective command and control. These process areas are grouped into four levels, numbered 2 through 5. Level 1 has no associated process areas and is considered indicative of an organization with informal or uncontrolled processes. Generally, Level 2 of the Software CMM focuses on project management activities; Level 3 focuses on organization-level activities such as process improvement and training, and also includes engineering-level activities. Level 4 includes significantly increased reliance on statistical techniques, and Level 5 focuses on ongoing process improvement.

The process areas covered by the Software CMM are:

Level 1

(No process areas)

Level 2

Requirements Management

Software Project Planning

Software Project Tracking and Oversight

Software Subcontract Management

Software Quality Assurance

Software Configuration Management

Level 3

Organization Process Focus

Organization Process Definition

Training Program

Integrated Software Management

Software Product Engineering

Intergroup Coordination

Peer Reviews

Level 4

Quantitative Process Management

Software Quality Management

Level 5

Defect Prevention

Technology Change Management

Process Change Management

Each process area is represented by one or more goals, and each goal is associated with several practices. In the Software CMM, if you comply with all the goals within all the process areas within a level (and the same is true for all lower levels) then you are considered compliant at that level. Practically speaking, one of the easier ways to demonstrate goal compliance is to demonstrate comprehensive compliance with all associated key practices, although this is not a requirement. At a minimum, throughout all the process areas, it is important that each:

•   Is supported by an organizational policy

•   Has been assigned to a responsible group

•   Is provided adequate resources and funding

•   Provides for any required training or orientations

•   Is measured to determine status

•   Is monitored and controlled by management

•   Is monitored by quality assurance.

The CMMI has a two-dimensional architecture and seems to take a more aggressive posture with regard to requiring compliance with both specific practices (unique to a process area) and generic practices (applicable across all process areas). The overall impression of both the CMMI and the Software CMM is that there are lots of rules, or requirements, that you need to comply with if you are going to assert you are, for example, a Level 2 organization. In the Software CMM there are over 100 applicable practices within Level 2. The CMMI adds additional process areas and, due in part to its architecture, seems also to have a significant number of explicit and implicit requirements.

The specific process areas (SPAs) in the staged representation of the CMMI are:

Level 2

Requirements Management

Project Planning

Project Monitoring and Control

Supplier Agreement Management

Measurement and Analysis

Process and Product Quality Assurance

Configuration Management

Level 3

Requirements Development

Technical Solution

Product Integration



Organizational Process Focus

Organizational Process Definition

Organizational Training

Integrated Project Management

Risk Management

Decision Analysis and Resolution

Level 4

Organizational Process Performance

Quantitative Project Management

Level 5

Organizational Innovation and Deployment

Causal Analysis and Resolution

In addition to the SPAs shown above, the generic goals and their associated generic practices are also used to determine compliance at or above a maturity level. The generic goal (GG) and generic practices (GP) associated with CMMI Level 2 compliance are:

•   GG2: The process is institutionalized as a managed process

•   GP2.1: Establish an organizational policy for planning and performing the <SPA> process

•   GP2.2: Establish and maintain plans for performing the <SPA> process

•   GP2.3: Provide adequate resources for performing the process, developing the work products, and providing the services for the <SPA> process

•   GP2.4: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the <SPA> process

•   GP2.5: Train the people performing or supporting the <SPA> process as needed

•   GP2.6: Place designated work products of the <SPA> process under appropriate levels of CM

•   GP2.7: Identify and involve the relevant stakeholders of the <SPA> process as planned

•   GP2.8: Monitor and control the <SPA> process against the plan for performing the process and take appropriate corrective action

•   GP2.9: Objectively evaluate adherence of the <SPA> process against its process description, standards, and procedures, and address noncompliance

•   GP2.10: Review the activities, status, and results of the <SPA> process with higher-level management and resolve issues

The generic goal and generic practices for CMMI Level 3 compliance are:

•   GG3: The process is institutionalized as a defined process

•   GP3.1: Establish and maintain the description of a defined <SPA> process

•   GP3.2: Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization's processes and process assets.

Given the preceding, the impression persists that the principles behind these frameworks include the implementation of rather extensive command and control via compliance with rules, and that compliance with an ever-increasing number of rules equates to higher process maturity and improved organizational performance.

Adaptive or Extreme Programming

The premise behind adaptive and emergent software development is that the traditional approach to software development is to attempt to establish orderly processes and then optimize those processes. Optimization techniques include techniques that resolve sometimes highly complicated problems by, for example, breaking those problems into smaller pieces and then improving the efficiency or effectiveness of high-impact pieces. This works extremely well in areas like manufacturing, assembly-line processing, etc. However, at a minimum this requires a relatively high correlation between cause and effect. This, in turn, requires a relatively stable environment so that the same types of causes are highly likely to yield the same types of effects.

If the environment, tools, objectives, or anything else about a software development project are subject to a rapid level of change, then cause and effect begin to breakdown. If change is the rule, rather than the exception, then adaptation to change becomes the prevailing success factor. For examples of how best to do this, proponents of adaptive techniques advocate that we need look no farther than to nature itself.

Systems in nature can be scattered along a spectrum from “orderly” to “chaotic.” Highsmith asserts that biologists report that the greatest advances in evolution occur at the edge of chaos (Highsmith, 2000). This is the area, existing between chaos and order, where something truly new and different can (and does) emerge. The idea is not just “survival of the fittest” but is instead—and much more importantly—“arrival of the fittest” (Highsmith, 2000). This arrival of the fittest is the emergent component of some adaptive environments and is potentially a key source of what is sometimes referred to as “disruptive technology.”

In the high-technology industry, disruptive technology is a new technology that is highly successful due to the fact that it represents either a new or radically different solution to a given problem. These technologies often originate from smaller, newer companies that are attempting to gain market-share against older, established companies. Arguably, these disruptive technologies tend to appear from highly adaptive companies that are using emergent techniques to unseat older, established companies that are trying to maintain their market dominance though the imposition of order and control. The dot-com bubble that occurred at the turn of the century was likely due, in part, to the perception that many of the start-ups might be introducing disruptive technology.

Adaptive programming concepts laid the foundation for the development of the principles of extreme programming, or XP. XP is more commonly found in smaller organizations (e.g., 20 people or less), or on smaller projects (e.g., five people or less) of relatively short duration (e.g., six months or less). Additionally, these are typically pure software projects versus hardware/software projects requiring systems engineering. The proponents of XP assert that there has been a fundamental sea change in the nature of software and programming projects and that new techniques are therefore needed. Indeed, Tom DeMarco, in the forward to Planning Extreme Programming (Beck, 2001) states, “Extreme Programming is the most important movement in our field today. I predict that it will be as essential to the present generation as the S.E.I. and its Capability Maturity Model were to the last.”

Some of the primary principles and techniques that support XP include (Beck, 2000):

1. Plan unit testing before development

2. Unit test throughout development

3. Have programmers work in teams of two (sharing one screen)

4. Involve the customer extensively throughout development

5. Perform regular refactoring—reduce complexity

6. Seek and provide rapid feedback

7. Integrate and test the entire system several times a day

8. Start projects with an extremely simple design and evolve when required

9. Put a minimalist system into production as rapidly as possible—evolve when required

10. Have programmers do everything, constantly (analysis, design, test, integrate, etc.)

The basic philosophy is, take whatever we've learned about good practices for building software systems, and then push those practices to extremes. Citing examples used in Beck (2000):

•   “If code reviews are good, we'll review code all the time”

•   “If testing is good, we'll test all the time”

•   “If design is good, we'll make it part of everybody's daily business”

•   “If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality”

•   “If architecture is important, everybody will work defining and refining the architecture all the time”

•   “If integration testing is important, then we'll integrate and test several times a day”

•   “If short iterations are good, we'll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years.”

To generalize, some of the more important characteristics of XP include taking smaller steps, verifying tangible progress, avoiding single points of failure, ensuring teamwork, and relying much less on documentation, and more on the people performing the software development.

Balancing Between Discipline and Freedom

The notion that the CMM/I is somehow incompatible with adaptive and extreme environments is primarily based on the premise that the requirements of the CMM/I are overly restrictive and will not allow for the rapid adjustment to new and changing circumstances. However, generally speaking, the degree to which the CMM/I restricts a process is primarily of function of how the CMM/I is implemented. If an organization elects to design and deploy a very flexible CMM/I-compliant process, this is certainly achievable. The CMM/I does not explicitly require rigidity, though many organizations have elected (probably not intentionally) to approach it that way.

Ironically, there are elements of the CMM/I framework that become even more important in the context of projects that are living on the edge of chaos or are using XP. Requirements management, for example, becomes increasingly vital if there is any intention of maintaining some type of influence over, and an internally consistent approach to, product features and their relative importance. The CMMI/I looks for documented requirements, but there is nothing that says the documentation has to be exhaustive and difficult to maintain. Instead, it is simply considered risky for requirements to be undocumented and existing only in the minds of various developmental and organizational personnel.

Similarly, configuration management becomes increasingly important in direct proportion to the rapidity with which updated versions are created and distributed. Likewise, ensuring access control and preventing inadvertent simultaneous updating of the same software item becomes even more important on XP projects when you have an environment where anyone can change anything at anytime.

Project planning and project management still remain key to project success, even though the planning documents in XP environments are likely to be far more sparse. The management function is also more likely to depend extensively on close proximity, tight teamwork, and leadership skills, but none of this is contradictory to the CMM/I. Similarly, quality assurance may look decidedly different, but there is still an advantage to having someone help the project manager by ensuring that nothing is being accidentally overlooked. Overall, the primary motivations behind the CMM/I—effective and efficient management and engineering processes—remain equally important for projects that are working in adaptive or XP environments.

Process areas at higher levels of the CMM/I also remain important, or become even more important, on projects working under highly changing circumstances. These process areas include, for example, risk management, training, and even organizational process focus and process change management. About the only place where there is a potential inappropriateness is with Level 4 requirements and the notion of attempting statistical process control and variance analysis. In highly volatile environments it is increasingly likely that each new project will be substantially different, at least in some critical way, from prior projects. Consequently, historical data in these environments may actually be a very poor predictor of future performance. Similarly, distinguishing between common cause variances and special cause variances in highly adaptive or XP environments becomes very difficult, especially when special cause variances become a weekly or even daily occurrence.

From the other perspective, it is also true the CMM/I projects and environments can benefit from leveraging some of the principles and techniques applied in typical XP environments. For example, the principle of developing tests before writing code can be highly beneficial in nearly any software development. One major advantage to this approach is that it better ensures that requirements are testable. If the programmer is preparing to write code for what amounts to an untestable requirement, this is revealed prior to coding versus after coding is complete.

The notion of regularly refactoring code and systematically simplifying the design on an ongoing basis is applicable to any environment, and becomes progressively more important as the code and overall system becomes progressively larger. Hence, this XP method is clearly vital in traditional large-project CMM/I environments.

As another example of CMM/I projects and environments benefiting from XP principles and methods, even very large projects can benefit from the technique of putting a minimalist system into production as soon as possible, and then evolving that system by adding additional features and increasing functionality. Properly done, you'll always have a functioning system—though clearly an incomplete one. Even if the customer context prevents deploying the developing system into a production environment, projects can at least deploy their functioning minimalist system into a test environment. This supports yet another XP method that states that testing should occur throughout product development.

To summarize, even XP projects working in adaptive environments will find that there is value in having some discipline, some element of “command and control.” The notion of “control” versus “freedom,” and “discipline” versus “innovation,” and even “chaos” verses “order” is potentially the wrong mental model. The seemingly opposite approaches of CMM/I and XP are actually quite compatible. Indeed, to generalize, each is strong precisely in those areas where the other tends to be weak. Therefore, to better ensure success nearly any software development project needs to find a balance between these seeming opposites—one that leverages the best characteristics of both control and innovation. Fortunately, a marriage between CMM/I principles and adaptive techniques makes for an excellent combined and balanced approach that preserves both management discipline and creative freedom.


SEI. 1993. The Capability Maturity Model for Software, Version 1.1. Software Engineering Institute. Carnegie Mellon University.

SEI. 2002. CMMI-SE/SW/IPPD/SS. Capability Maturity Model—Integrated for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Selection. Software Engineering Institute. Carnegie Mellon University.

Highsmith, James A. 2000. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing.

Beck, Kent. 2000. Extreme Programming Explained. Addison-Wesley.

Beck, Kent, & Fowler, Martin. 2001. Planning Extreme Programming. Addison-Wesley.

Jeffries, Ron, Anderson, Ann, & Hendrickson, Chet. 2001. Extreme Programming Installed. Addison-Wesley.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA



Related Content

  • PMI Sponsored Research

    Digital Transformations of Traditional PBOs and Modern PNWs member content open

    By Braun, Timo | Ekstedt, Eskil | Lundin, Rolf A. | Sydow, Jörg Digitalization is a phenomenon occurring across sectors and nations, affecting technical processes, organizational forms, and managerial practices. Project management, which is often used as an…

  • PM Network

    Banish Distractions member content open

    By Husted, Chad If I have learned anything in my 20-plus years of project management, it's that there is always room to grow and improve my skills. Yet, some of the best lessons I've learned about being an…

  • PM Network

    Standing out from the Start member content open

    By Scott, Lindsay Project management recruitment professional Lindsay Scott provides career guidance.

  • PM Network

    Ready, Set, Stretch member content open

    By Bishel, Ashley A strategic skill set can guarantee a static career. But for project professionals eager to be recognized, get promoted or take on more ambitious and complex projects, an expansive skill set is a…

  • PM Network

    Exit Strategy member content open

    Uncertainty looms for project professionals in the United Kingdom. But there's hope amid the Brexit chaos: Salaries are up—especially for those who change jobs.