Capability Maturity Model Integration (CMMI) in less than 1000 words

Essentials elements of CMMI-based process-improvement

This article and series addresses the CMMI model for systems and software engineering. There are additional CMM that address other disciplines. Understanding the essential concepts presented here enables a more than cursory familiarity and gives you a basis for informed discussion and further inquiry. Unless otherwise noted, this series article and series will reference the staged representation (organization maturity) of the model rather than the continuous representation (process area capability).

What is the CMMI?

CMMI is a descriptive model that integrates (showing dependencies and work-product flows) twenty-two process areas common to both systems and software development.

CMMI is also a prescriptive model that provides goals and best practices for software-process capability and software organization maturity.

CMMI is widely accepted and used by IT organizations worldwide and there is a wealth of data, analysis, and reportage that documents its effectiveness and potential benefits in terms of improved product quality and ROI from CMM-based software process improvement.

Essential CMMI Terminology

A process area is a set of goals and practices for one development area (E.g., Project Planning or Requirement Management). There are 22 process areas in CMMI.

Specific goals (47) are objectives that characterize what is needed to satisfy the purpose of one process area.

Specific practices (192) support specific goals.

Generic goals (4) —common to all process areas— to institutionalize process at a given level of maturity

Generic Practices (10) implement common features to ensure that any process area will be effective, repeatable, and lasting.

Maturity Levels & Process Areas

Process areas are sequenced and staged at one of four maturity levels and for a foundation for process areas at higher maturity levels. Sequenced and staged deployment creates opportunity for practice and work-product synergy and leveraging between process areas.

1 — Initial Level (ad hoc process)

 In a level-1 organization, project-process is ad hoc and frequently chaotic. Project success and work excellence depend on the competence and heroics of people in the organization and cannot be repeated unless the same competent and experienced individuals are assigned to the next project.

2 — Managed Level Process Areas

A level-2 organization ensures that work and work products are planned, documented, performed, monitored, and controlled at the project level.

  • Requirements Management manages a project’s specific product requirements and verifies consistency between requirements, work plans, and work products.
  • Project Planning establishes and maintains work plans to identify activities and work products.
  • Project Monitoring and Control tracks work plan progress and signals significant deviations for management action.
  • Supplier Agreement and Management manages formal agreements for acquisition of products and services from suppliers external to the project
  • Measurement and Analysis develops and maintains measurement capabilities that support project and product MIS.
  • Process and Product Quality Assurance assures adherence of project process and associated work products to applicable process descriptions, standards and procedures.
  • Configuration Management establishes and maintains the integrity of work products using configuration identification, control, status accounting, and audits.

3 — Defined Level Process Areas

A level-3 organization establishes and maintains standard processes and work products, which are improved over time. Project standards, work activities, and work-product descriptions, are tailored from organizational process assets. As a result, the processes performed are consistent, measurable, comparable, and reusable across projects and across the organization.

  • Requirements Development models customer and product requirements in detail sufficient to mutual understanding and development of technical solutions.
  • Technical Solution designs and builds solutions for requirements—as products, product components, and product related processes.
  • Product Integration assembles the product from new and baseline components, ensures (by testing) that the product, functions properly, and delivers the product.
  • Verification (typically by inspection) assures that work products meet specified requirements.
  • Validation (user and acceptance testing) demonstrates that a product or product component fulfills its intended use in its intended environment.
  • Organizational Process Focus establishes and maintains sets of standard processes and process assets, and identifies, plans, and implements process improvement activities.
  • Organizational Process Definition establishes and maintains a reusable set of standard-process assets.
  • Organizational Training develops learning assets and cultivates skills and knowledge that enable satisfaction of organization and project requirements.
  • Integrated Project Management establishes and manages projects, project dependencies, and the involvement of the relevant stakeholders—according to a defined process.
  • Risk Management identifies potential problems before they occur, plans activities to track risks and contingent activities, as needed, that mitigate adverse impacts.

4 ­­— Quantitatively Managed Level Process Areas

A level-4 organization manages standard process and projects using statistical and other quantitative techniques. Quantitative objectives for product quality, service quality, and process performance are established and used as criteria for management throughout the project life cycle.

  • Organizational Process Performance establishes and maintains a quantitative understanding of standard process capability and performance across projects, and provides performance data, baselines, and models to quantitatively manage the organization’s projects.
  • Quantitative Project Management employs statistical process control to quantitatively manage the project’s defined process and achieve the project’s established quality and performance objectives.

5 ­­— Optimizing Level Process Areas

A level-5 organization continually improves standard processes based on an understanding of the common causes of variation inherent in processes.

  • Organizational Innovation and Deployment selects and deploys incremental and innovative improvements that measurably improve the organization’s processes and technologies and support the organization’s quality and process performance objectives as derived from the organization’s business objectives.
  • Causal Analysis and Resolution identifies causes of defects and other problems and takes action to prevent them from occurring in the future.

In Summary CMMI prescribes

  • Best practices for continuous improvement of process area capability and organization maturity
  • The staged representation of CMMI prescribes a sequence for process area deployment that affords optimal leveraging of process and work-product assets between process areas.
  • Process-area capability and organization maturity co-evolve in ways that complement both.

Capability Maturity Model Integration (CMMI) and Me

A brief history

After getting a degree in English Literature and writing in 1968, I joined the exploding information revolution, training as programmer analyst.

My IT career spanned computer and OS evolution from early third-generation mainframes through virtual machines—from flat indexed files through hierarchical and relational database—through numerous generations of Moore’s law chip evolution in minicomputers, microcomputers, tablets, and smart phones—from LAN through WAN and VPN—from Arpanet to the Internet and web-based applications. I designed, led, and managed development of online data based information systems for organizations as diverse as Harvard University, AT&T, the Federal Reserve Bank, and Merrill Lynch. I also did groundbreaking work at those institutions in methodology, CASE, and software process.

At Merrill Lynch (ML) in the decades on either side of the millennium, my career intersected with the Software Engineering Institute’s Capability Maturity Model for Software. CMM-based software process improvement became my full-time job for the remainder of my corporate IT career. I had formal SEI training as an Assessment Team member and participated in a number of weeks-long projects and gap analyses to assess organizational process maturity in numerous ML/IT departments. I became an SEI-certified CMM Trainer and presented numerous overviews and formal classes. At my corporate home base, the Jacksonville Solution Center, I was a leader in that department’s rapid evolution to CMM Level 5, the model’s highest organizational maturity rating. We had quantitative project, process, and quality management, and a program for continuous process improvement in all process areas addressed by CMM-SW. Along the way, I also received formal training as a Six Sigma Black Belt, which enabled me to develop the quantitative analysis and management practices necessary for CMM levels 4 and 5.

The CMM was evolving, even as we worked to apply it. The base CMM had been applied to numerous disciplines, in models for systems engineering, software engineering, software acquisition, workforce practices, and integrated product and process development. A comprehensive model, aptly named CMM Integration (CMMI), was released and is now the de facto standard.

After my departure from ML, I “discovered” another discipline that benefits from CMM integration. I’ve had a second career in digital media production, operating a “boutique” studio. I quickly realized that CMM processes were applicable to studio work. Although there are obvious differences between system/software engineering and media production, there is some overlap in project planning and management, requirements development & management, product integration, verification, and validation. I have informally adapted specific practices to plan and manage media projects, to continuously improve my process for making, editing, and distributing digital media, and to manage an ever-growing archive of digital media and reusable project assets.

My IT career left me with two lasting legacies that are relatively independent of galloping information technology: a systems/process analysis skill set and understanding of CMMI—as a model—and its specific practices for software engineering. I can still analyze requirements and develop a structured model of an application (or business process) and I continue to experiment with, reflect upon, and write about the CMMI’s profound utility and application in a growing array of disciplines—including media production.

I plan to explore the model over a series of articles in this blog and maybe a book. I write to consolidate, enhance, and share my own experience and knowledge. I don’t presume to write for experienced CMMI “experts”. I write for IT executives, managers, analysts, designers, and engineers who may want or need to learn more about the subject and may enjoy “readily digestible” forays into discrete aspects of the model’s daunting complexity. I also write for managers and practitioners in other disciplines who may be curious to see what a capability maturity model might offer to their work.

If you are interested, I invite you to “follow” this blog and join me on this journey of exploration and discovery.

Why Do (Software) Projects Fail?

Seven ways a project (plan) can fail and foredoom a project

Image by Gerd Altmann from Pixabay

The primary goal of a project plan is to deliver the best tradeoff between reality and commitments—to satisfy as much of its requirements as possible while making and keeping realistic commitments given real constraints of time and money.

What’s a failed project? One that doesn’t meet its commitments for—

  • Products or services that perform as specified by the customer
  • On time
  • Within budget

This article specifically addresses software projects but the points made apply to any kind of work plan.

Why do projects fail?

Many—perhaps most—software projects that fail do not fail in software development.

Many projects fail before software development actually begins.

They fail because their plans are defective. In that sense, they are planned failures.

Failure in planning is planning to fail

Seven Ways a Project (Plan) Can Fail

  1. The project isn’t sufficiently estimated and scheduled
  2. The plan does not sufficiently address project risks and mitigation.
  3. The plan does not sufficiently address project resource requirements
  4. The plan does not sufficiently address timely acquisition of knowledge and skills
  5. The plan does not sufficiently address stakeholder involvement
  6. The plan proceeds without strong commitments by all stakeholders
  7. The plan is not maintained throughout the project life cycle

The keyword here, in case you didn’t notice, is sufficiently.

The project isn’t sufficiently scoped, estimated and scheduled

Project scope is the framework for the plan. The goal is to identify all stakeholders (see below), the business goals that will be addressed, the conceptual product architecture and the work to be performed.

The work plan is typically developed as a hierarchical work breakdown structure (WBS) that shows the tasks to be performed in each area of software engineering and support. It is (or should be) based upon the envisioned product architecture.

Mistakes often made here (in no particular order):

  • Inadequately detailed planning

You don’t want to wait until the end of the current phase (or cycle) to find out how well your estimates are tracking against actual results. Once you have sufficient size and complexity data from a phase, you should plan the next phase at the lowest practical level of detail—tied to specific work-product components (requirements, designs, code, test plans et al). Unfortunately, you can only do this by phase (or cycle for spiral or agile lifecycles).

This leads to the next possible mistake.

  • Prematurely detailed planning

Work plan details depend on and correspond to available product metadata.

You can’t plan detailed work for software product requirements analysis without actual requirements. With requirements in hand, you can scope the features and functions (however named) that will reviewed, clarified and modeled by the initial analysis phase of the project. You won’t have the analysis work products you need to do a detail plan for product design until analysis produces them.

As the saying goes, you don’t know what you don’t know.

Detailed planning is only indicated for the next phase or cycle of the project. Anything more is speculation not planning.

This is one reason project planning must be reiterated at project milestones to use newly developed work product metadata—specifically size and complexity. Until you can quantify how much work will be performed and its level of complexity, you can’t plan detail tasks to do the work.

  • Failure to develop estimates for work product size and complexity

Size matters!

This is one of the most common defects seen in software project planning. Aside from lines of code—and that only rarely—very little work product sizing is estimated. Every software work product in every phase—regardless of methodology—offers some basis for sizing and assessment of complexity. Work product size and complexity drive—or should drive estimates for work effort.

  • Confusion of work effort and work duration

Many projects estimate effort in terms of calendar time—days, weeks, or months.

Effort measures how much human effort it will take to do the work. Duration is how long the work will take.

It takes longer then one week for one full-time resource to expend forty hours of effort on a task.

Effort should be estimated; duration should be derived.

Effort should be estimated based upon size and complexity. Balancing effort with resource availability should yield the correct duration.

  • Failure to use objective models for effort estimation

As mentioned previously, work size and complexity should be the principle parameters for estimating effort. An estimating model should use historical or industrial data for comparable work whenever possible.

The plan does not sufficiently address project risks and mitigation.

Nothing is without risk. Project risks can include hurricane season, timely availability of resources, volatile and changing business requirements, and timely completion of related projects, among other thing. Virtually every aspect and section of the project plan may pose risks that require monitoring and mitigation.

Risks should be itemized, quantified, and prioritized for their potential impact, probability of occurrence, and timing. Work to monitor the risk and mitigate the impact should be planned and resources allocated on a contingency basis. If you don’t do this, you increase the risk that your project will be late and or over-budget.

The plan does not sufficiently address project resource requirements

You can’t develop a realistic project schedule without knowing two things: work effort estimates and available resources to do the work.

This process can founder on the myth that resources are available full time to do the work. Therefore, a forty-hour estimate for effort becomes one week on the schedule. Resources are never available full time. There are myriad ongoing overhead tasks and events—time and status reporting, production system problems, staff meetings, employee events et al—that interrupt time on task. For lack of anywhere else to report the time, team members report it against assigned project tasks and slippage ensues.

A realistic plan devises an algorithm for computing realistic availability metrics. Depending on the organization, real availability is likely to be in the 60-80% range.

The plan should also identify specific non-routine equipment and software resources along with the effort and time required to assimilate and integrate them into ongoing project work.

The plan does not sufficiently address timely acquisition of knowledge and skills

Typically, a project team is assigned because proven individual and team skill sets are a good match for a project. In the ever evolving and rapidly changing IT landscape that will not always be a given. Minimally, project planning should assess skill needs and skilled-resource availability and plan time and resources for closing any gaps.

The plan does not sufficiently address stakeholder involvement

Project stakeholders may include customers, users, other business and IT organizations, other systems, other projects, vendors, and the project team.

Strong stakeholder commitments are critical to project success.

The plan should document:

  • Stakeholders and specific commitments
  • Specific roles and responsibilities, tied in to specific scheduled events in the plan
  • Time, effort, and resources needed to ensure timely stakeholder involvement

The plan proceeds without strong commitments by all stakeholders

Without formally documented organizational commitments, authorized by appropriate levels of management, a project can flounder and founder through no fault of the project team.

The plan is not maintained throughout the project lifecycle

Project planning is too often regarded as a preliminary front-end to the project lifecycle. A dynamic instrument, the plan changes on a daily and weekly basis based upon actual work performed and actual events—planned or unplanned. That assumes ongoing monitoring and timely feedback on every critical component that has been cited in this post.

If you estimate it, you need to track it and revise your estimates as needed based upon actual results.

The planning process should be reiterated at prescribed milestones in the project lifecycle, at completion of phases in a traditional waterfall lifecycle, or thread-completion in a multi-threaded waterfall cycle, or completion of a cycle in a spiral or agile lifecycle. At each point, there is new and expanded software product metadata and verification data that will enable a greater level of detail in the next phase or cycle of development.

There is much overlap between project planning and project monitoring & control and project management encompasses both processes throughout the life cycle of the project.

A shorthand way of saying all this is that a project can fail because there is no appropriate planning process. An appropriate planning process anticipates and satisfies all the potential causes of failure cited above.


Revolutions However Known

Systems, Process, and the English Major

In 1968, armed with a seemingly “useless” English degree, I was swept up and away into communication, computer, and information revolutions that since have rocked the world, and are still rocking it at full throttle. In “the Revolution (however known), I served as foot soldier, as mercenary, and led troops into battle as a program director, project manager, and team leader. This is how it happened.

By 1968, demand had spiked for people who could program and manage computer systems and telecom networks, information technology (IT) industries so new that there wasn’t yet an education infrastructure to supply them with trained workers. IT organizations had to grow their own first generation of programmer analysts.

Supply and demand intersected this story at a Bell telephone company that trained this “English major” (EM) first as a network manager and then as a computer programmer analyst. The EM learned a new language—assembly code—a cryptic 2nd generation language for programming third generation computers. Those huge amazing machines could do (or seem to do) multiple things at the same time. They read and wrote large volumes of data on magnetic tape drives as big as refrigerators and disk drives the size of washing machines. He wrote his first programs on cardboard punched cards—one card per instruction.

Within five years–the English major thought things had come nearly full circle. Now he typed code on a TV-like display terminal, writing in a 3rd generation “procedural” language—COBOL—that was essentially structured English. Another computer program translated “high level” Cobol into the “assembly code” he’d first learned to write so that the computer could execute it. That was a programming language revolution—from machine code to English—and a system/IT revolution—software compiled translation from English into machine code. These were early fruits of “the Revolution” that was changing—everything.

Over the next seven years, the English Major surfed the revolutionary waves across various emerging technologies—timeshare networks (computer time not condos), parallel programming with multi-tasking, and minicomputers. He ended the 70s with a sabbatical year and an extended meditation retreat to an ashram in India. “On the cushion,” he experienced new insights—that “everything is a verb”—a process; that every system is an attempt to control some process; that every process (or system) is actually a sub-process—and that includes computer programming, himself, and his mind. In fact, his mind seemed to have a lot in common with software.

That sabbatical was excellent priming for two simultaneous appointments—one full time as a lead analyst at Harvard University’s Office of Information Technology and one part-time as course designer and instructor at a post-graduate systems training school.

Mornings, he would try to teach liberal arts graduates (EM newbies) to think like computers in structured, logical, and relational terms.

The rest of the day, across the river at Harvard, he researched and prototyped new fruits of the Revolution: microcomputer systems, relational databases, structured development methodologies, 4th generation—non-procedural—programming languages, and expert systems—a step toward AI. He worked on a “virtual machine” in a networked system environment that extended off campus into something called The Advanced Research Projects Agency Network (ARPANET) that turned out to be a precursor to our Internet.

At night, as he planned the next morning’s lectures, the EM would reflect and ruminate upon the explosive progress of the new technologies that were inundating the culture—and his own mind. He saw human software process lagging far behind technology. He tried to render all this in relevant terms and concepts he could use to teach. One student observed, “You’re not just teaching us to program computers; you’re teaching us how to think—about everything!” He saw the graphs of revolutionary change accelerating, converging and veering toward the vertical and told his students (in 1983) that he could almost imagine how things might change until some time in the 90s. Beyond that, in the new millennium, he said, “It’ll be science-fiction.” He was right about that and here we are “in that future”—supercomputers, pocket computers, smart phones, and the World Wide Web.

Bursting with ideas, the English Major set out as a systems samurai consultant for ten years to apply some of what he’d learned at Harvard and in teaching. He used his 4th generation programming and relational database expertise to lead RAD (rapid application development) projects. The projects included systems that assisted AT&T through divestiture of its Bell-system companies; a metadata-driven COBOL code generator; a computer-assisted budgeting process for a Federal Reserve Bank; and a system for translating and migrating 4th generation programming code between Unix and IBM VM operating environments. The unifying theme in his work was visualizing software development as a process and automating or at least computer-assisting that process.

Software process and software process improvement was his sole focus in the final decade of the English Major’s IT career. He let technology—the “what” of IT—rocket past and beyond him while he focused on the “how.” He hadn’t given up on computer-generated software but realized its ultimate fulfillment lay with rapidly evolving AI.

Meanwhile, he saw an IT industry beset and burdened with development and support of an ever-growing inventory of human-programmed systems. He became intrigued with software process as a means to “program the programmers and software managers.”  

The English Major became an expert in the Software Engineering Institute’s Capability Maturity Model (CMMI) and the Six Sigma Black Belt process for quantitative process-improvement. He spearheaded one IT department within his global-financial-services employer in its rapid evolution to CMM Level 5, the highest capability maturity rating—the first American group in the finance sector to earn that distinction. His “reward” was the disbandment of that elite department and his own early retirement—and that’s a story for another post.

Dispirited and unwilling to return to corporate IT trench warfare, the English Major pursued a second career in writing and video production, where he still employs some “software” process best practices to improve productivity and quality assurance in digital media management and production. A process is a process. Making a movie—even developing a screenplay— share much common process with developing a software product—they are all Intellectual Properties (IP)—and they all benefit from some of the same best practices.

He’s never stopped thinking and journaling about systems and process, not the technology so much as the social science, psychology, and philosophy—and the diverse opportunities and potential benefits of “process thinking” both inside and outside the IT industry. He still reflects and ruminates on systems and process at night, and still dreams about adventures and misadventures in his IT career.

Now, the English Major has embarked on a third career—“coming home” to write about what he’s learned—as a blogger, copywriter, and author. He intends to focus on the human side of the software process more than the technology. The English Major plans to keep it simple and hopes to entertain, inform, and even inspire readers within and outside IT.