I've always wondered what the core objectives of CMMI training are and how they truly benefit an organization? ~E. Fiscient
Hi E!
Hi E!
Hi Appraiser,
I'm really afraid of failing my company's appraisal. We've been working so hard on it! What are some things to avoid if we're looking to pass our appraisal? ~Ima Frade
Dear Ima,
Helping you out of your predicament here is Darian Poinsetta, the president and CEO of Broadsword Solutions and a certified lead appraiser. He's giving me a little break for blog writing today. With years of experience helping companies align with CMMI maturity levels, Darian has witnessed firsthand the pitfalls that can take down even the most well-meaning organizations.
1. Misaligned Processes:
A common way organizations set themselves up for failure is by having processes that aren’t aligned with the company's goals. It’s crucial to remember: if your processes aren’t driving your company toward its objectives, they’re essentially useless. Each process should serve the broader purpose of advancing your company’s mission. This is why understanding CMMI Process Areas is essential to aligning your processes correctly.
2. Lack of Senior Leadership Engagement:
Without the active engagement of senior leadership, an appraisal is doomed to struggle. Leaders provide the resources, funding, and training necessary to implement and sustain processes. Their support is vital for any organization aspiring to pass an appraisal, and without it, the path forward becomes significantly more challenging. Senior leadership involvement is integral, and our CMMI Leadership Training can help guide your team through the process.
3. Insufficient Time for Process Adoption:
Lastly, organizations often falter by not allowing their teams enough time to adapt to and utilize new processes. Rushed implementations can result in confusion and inefficiencies. It’s essential to give employees ample time to integrate processes into their daily routines, understand how they work, and identify improvements over time. Process Adoption is a long-term commitment, and understanding its importance can make all the difference.
By steering clear of these pitfalls, organizations can greatly enhance their chances of success and ensure their processes meaningfully contribute to achieving company goals.
Many Agile teams studying the Requirements Development and Management (RDM) practices in CMMI ask the same question:
“How is any of this agile?”
It’s true—the model doesn’t prescribe specific techniques, and the language can feel dated or overly formal to Agile teams deep in their day-to-day work. But that doesn't mean it’s not compatible. In fact, with the right translation, the CMMI can significantly strengthen how your team approaches requirements—without abandoning Agile values.
To borrow a line from Gloria Estefan: "The words get in the way."
CMMI’s terminology—think “product and product component requirements”—might work in a classroom or a textbook, but on an Agile team board? Not so much. In practice, I drop the jargon and meet teams where they are.
Instead of rigid terms, I talk about stuff:
The stuff customers say they want (even though it will change).
The stuff we build to try to satisfy them (which also changes).
The stuff we validate, to make sure it's useful—and fundable.
The challenge is aligning that “stuff” with CMMI RDM practices in a way that feels natural, not forced.
To help Agile teams ground their requirements in real, actionable practices, I often recommend a three-tiered architecture plus a cascading “definition of done” that supports clarity, traceability, and better delivery.
Let’s break it down:
The backlog captures customer needs in priority order. In CMMI-speak, this aligns with eliciting and developing customer requirements.
Here’s where estimation often comes into play—especially when customers ask questions like “We’re not sure what we want, but how much will it cost?”
For this, Agile teams can use:
Wideband Delphi: A collaborative, experience-based estimation method similar to Agile practices, but focused on effort, not story points.
It's a great middle ground for government or large corporate customers still struggling with the concept of relative sizing.
Epics represent high-level, user-focused narratives—each potentially encompassing multiple user stories.
While often dismissed as just “big stories,” epics are critical for validation. They help teams and stakeholders clarify scenarios before diving into detailed development. They also uncover defects and assumptions early.
Estimation at this tier shifts toward relative sizing, using tools like:
The Fibonacci Game or the Team Estimation Game
(still collaborative, but faster and more intuitive than formal effort estimates)
User stories are the most familiar Agile artifact: focused narratives with clear tasks, completed within a sprint.
CMMI's RMN is especially useful here—it can help uncover hidden or missed requirements that aren't typically found in the backlog.
By the time a story reaches this tier, it’s been validated and refined from initial need → epic → story → task. This clarity makes Planning Poker a natural fit for estimation.
To bring it all together, I recommend teams define a set of tier-specific validation questions. These help ensure that each requirement, whether a backlog item, epic, or story, meets a minimum threshold of clarity and feasibility.
Some examples:
Is there a clear narrative for the Epic or User Story?
Is the source reliable and validated?
Can all stakeholders understand the request?
Are test cases defined?
Does functionality meet funding and performance requirements?
Have we done this before? Do we have the data?
Is there significant risk we need to manage?
This creates a “gate” at each level of granularity—backlog, epic, story—helping teams spot ambiguity or risk beforedevelopment begins.
Teams can also implement a lightweight Confidence Matrix:
Mark each validation question as strong or weak.
Tally up a Confidence Score per story.
Use it as a multiplier or input for risk-based estimation.
Over time, teams can even experiment with weighted scoring for more precision.
These are just a few ways to apply CMMI Requirements Development in an Agile context. When teams use CMMI not as a constraint but as a lens for improvement, it helps them level up—starting from the stuff they’re already doing.
So don’t think of RDM as old-school bureaucracy. Think of it as a toolkit to help you:
Clarify what you’re building.
Estimate with more confidence.
Deliver high-quality stories that matter.
Get your requirements architecture in place first—and then go deeper into CMMI. There’s plenty more gold to mine.
Onward!
Dear Appraiser,
Sometimes I look at a new process and think, Really? This DAR (Decision Analysis and Resolution) thing just feels…silly. Aren’t we the experts here? Why do I need a bunch of overhead to make a decision I’m perfectly capable of making myself? ~Dan A Resulo
Back in the early '90s, I was leading a team tasked with building a point-of-sale system for a major department store. It was a high-stakes, high-visibility project—and yeah, we were feeling pretty "RAD" back then.
My team was responsible for selecting a code library to handle basic retail functions. So, we did what most competent engineers would: we gathered names of known vendors, reached out for information, and asked what we thought were the right questions—platform compatibility, core functionality, cost, viability, etc.
Eventually, we narrowed it down to three solid candidates—all text-based, Linux-compatible systems—and one flashy new option: a Windows-based GUI with a touchscreen.
Yes, a touchscreen.
Cue the nerd excitement. Suddenly, the office was buzzing with words like "innovative", "sexy", and "groundbreaking". Text-based systems were yesterday’s news. Even our CEO declared that the new graphical interface would be the “soul” of the new system.
Our CIO, however, saw through the glitter. He found the touchscreen option functionally lacking and more expensive—and added a new column to our decision matrix: Pizzazz.
You can guess what happened next.
The momentum behind the shiny new thing was unstoppable. Despite clear drawbacks, the touchscreen system was chosen. And predictably, it failed. The library didn’t even work. The project went over budget, missed deadlines, and turned into a full-blown disaster.
But from that painful experience, something good emerged: The 3 D’s.
I’ve since made the 3 D’s a cornerstone of my approach to project and product decision-making. You may have heard them in one of my CMMI classes. They stand for:
Use a structured, fact-based approach involving the right stakeholders. It doesn’t need to be a 100-page document, but it does need to be systematic. Had we followed even a simple, deliberate process, we could have slowed the hype and made a smarter decision.
Make decisions that last. Not forever, but through reorgs, leadership changes, or the next tech trend. Durable decisions are adaptable—not just “solid” or “robust”—and they anticipate change rather than resist it.
Every decision has political implications. Who’s involved, how you communicate, and how you justify your choice all matter. A defendable decision earns support—and helps neutralize those who’ll second-guess you the moment things go sideways.
Start by identifying key decision points—the ones that carry real impact. Then follow a deliberate path: define criteria, involve the right people, gather data, and come to a resolution. Simple, right? Not always. But effective? Absolutely.
So the next time you’re tempted to skip the process and just “make the call,” remember: one flashy touchscreen can derail your whole project. Take a beat, remember the 3 D’s—and save yourself the pain.
Dear Appraiser,
Our CMMI Consultant tells me that all CMMI Practices have to be used on every project with full rigor- regardless of size. That doesn't sound right.
What gives? ~Harley Fullblast
It's important to adjust your Process knobs to the right levels
Dear Mr. Fullblast,
Okay, I’ll admit it — Justin Bieber’s “Baby” sounds amazing on my iPhone.
Wait, did I just say that out loud?
Yes, I did. And honestly? It sounds really good. Now, don’t get the wrong idea — Bieber is definitely not my usual go-to artist. In fact, the only reason I even own a copy is because my 12-year-old niece gifted it to me on iTunes. (Still not sure what I did to deserve that.) But here we are… and I have to say, it sounds fantastic.
Not because it’s my favorite genre, and not even because of the singer. It sounds great because a sound engineer carefully adjusted all the right knobs. The mix is balanced. Nothing is maxed out unnecessarily. Some elements are subtle, others are prominent — all placed with purpose.
Compare that to an old live Pink Floyd recording I have — captured on a handheld cassette recorder in the '70s at Madison Square Garden. Nostalgic? Sure. Sonic quality? Absolutely awful. I don’t remember much from that night, but I know this: those knobs were not in the right places.
Here’s where this analogy gets fun. The CMMI is a lot like that sound engineer’s mixing board. Only instead of a dozen sliders, we’ve got over 350 “knobs” at Maturity Level 3 — each representing a process area, a practice, or a tool. And like sound engineering, the magic is in how you tailor those settings for each unique situation.
Not every project, team, or organization needs the same mix. Cranking every knob to “11” doesn’t guarantee success — it just creates noise, waste, and frustration. Instead, the art lies in adjusting the process to fit the need. Some practices will be more critical than others, depending on your goals.
That’s right — some practices are more important than others.
Too often, when an appraisal flags a practice as “partially met,” the knee-jerk response is to reverse-engineer the checklist, bulk up the documentation, and crank up the visibility. Problem solved, right?
Not always.
Sometimes, that perceived weakness exists because of how other “knobs” have been configured. Tweak one area too aggressively, and you might throw everything else out of balance. I call this the Whack-a-Mole approach to process improvement — and it's as chaotic as it sounds.
You may have heard some consultants say that Maturity Level 3 is all about strict uniformity:
“Everyone doing everything the same way, every time.”
“More than 54.7% of sample artifacts must be fully deployed!”
“Every practice must receive equal emphasis.”
I disagree. Strongly.
That’s not what the model teaches. In fact, the CMMI training materials and the “Foundations of Capability” class make it clear: Defined Process does not mean a single, one-size-fits-all process. It means creating a flexible framework that supports multiple approaches — tailored to fit context, constraints, and objectives.
Or, to borrow from one of my niece’s favorite movies:
“Defined… You keep using that word. I do not think it means what you think it means.”
A smart process architecture isn’t rigid — it’s deliberate. Whether you’re choosing Planning Poker vs. COCOMO, Fagan Inspections vs. informal reviews, or daily standups vs. all-hands meetings, the tools are only as effective as the context they’re applied in.
Where and how you set the knobs determines the quality of your outcome.
It’s the difference between an average project… and a great one.
Want to see what it looks like when the real pros set the knobs just right? Check out this behind-the-scenes video of how audio engineers work their magic on pop vocals: https://www.youtube.com/watch?v=RmT6MDOD3uc
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.
Dear Appraiser,
Our Process Team ("SEPG") was created as part of our CMMI ML3 effort [PCM 1.1], and we've built and deployed processes required for CMMI. But the question of HR training, Business Development processes, and IT. Those teams don't seem to have much process, and they are very resistant to being part of our program. How should we proceed? ~Hung yup B HR.
Dear Hung,
Let me tell you a sad, all-too-familiar story.
A brave little Process Team is born. It’s full of hope. Energy. PowerPoint decks. They work day and night, fueled by caffeine and blind optimism. And finally, after 12 grueling months… they pass the appraisal.
🎉 Cue the confetti, the pizza party, the obligatory “We Did It!” email. 🎉
Then what happens?
Poof.
The team vanishes into the corporate abyss like a rogue Post-it note under a desk. Why? Because the “process” wasn’t about improving the company — it was about surviving the audit. And once that badge is earned, it’s off to the next fire drill.
But here’s the plot twist:
CMMI isn’t your process.
It’s not even A process. It’s just a model. A suggestion. Kind of like a recipe you “loosely follow” but end up adding sriracha to anyway.
Meanwhile, other departments — like BD and HR — are off doing their own thing. You suggest, “Hey, let’s align our training processes!” and they look at you like you’ve just asked them to share a toothbrush.
“Oversight? Collaboration? Standardization? In this economy?”
But here’s the kicker: if Engineering has one training process and HR has another, you’re creating a game of “Which Form Do I Fill Out Now?” Multiply that chaos across every team, and congrats — your company is now powered by confusion and duplicated effort.
It doesn’t have to be this way.
What we need is a mindset shift:
❌ “Let’s Get That CMMI Level 3!”
✅ “Let’s Make Our Company Suck Less!”
Because frameworks like CMMI, CMMC, ISO, NIST, PMBOK, SAFe, and their acronym-istic friends are tools, not goals. They’re cheat sheets for good behavior. But they only work if everyone’s reading from the same playbook.
So should you extend your SEPG to other departments?
HELL YES, YOU SHOULD.
Process isn’t just for the engineers. It’s for anyone who does work. That's another word for process....WORK!. And who wants to stop reinventing the wheel… while it’s already rolling downhill… on fire.
So stop worshiping the audit gods.
Start building something that actually works.
And maybe — just maybe — get HR to return your process improvement meeting invites.
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.
Dear Appraiser,
My boss told me to "go out and get us CMMI ML3. I just learned that there is a ML2 but just found a webpage to to we should skip it and go right to ML3 to save money. Can we do that? What gives? ~Leveled in Levitown.
What is CMMI Anyway?
Dear Leveled,
STOP WHAT YOUR DOING AND STEP BACK FROM YOUR COMPUTER!
Why Starting with CMMI Maturity Level 2 is Crucial for Success
Of course, you can jump ahead and aim for higher levels of maturity. But honestly, I wish more people (and companies) wouldn’t skip over the basics. Maturity Level 2 (ML2) is all about building a solid foundation for your performance. It’s not about the flashy, advanced stuff—not yet, anyway. And that’s by design.
Having appraised hundreds of organizations, I've seen many companies who reached Level 3 (ML3) later on and wished they had focused on Level 2 first. Why? Because they didn’t have basic processes in place from the start, and the journey to ML3 was a much tougher climb than it needed to be.
It’s one thing to pinpoint the root cause of a problem (CAR). But it's an entirely different challenge to pilot a solution, prove that it works, and implement that fixed process across the entire organization. It’s one thing to choose a solid estimating method, but it’s another entirely to get everyone on board and doing it consistently.
See where I’m going with this? Maturity Level 3 is next-level—and not just in terms of complexity, but in the level of discipline required. It’s great stuff for sure, but you need to have a solid foundation in place first.
Think of it this way: imagine you hire a personal trainer and say, “I want to compete in the Olympics next year, but I’ve never trained before.” Sure, there are a few once-in-a-lifetime athletes who could make that leap, but let’s be honest—you probably aren't one of them!
Starting with Level 2 is like laying the groundwork for long-term health. It's more manageable, more productive, and ultimately more sustainable than skipping straight to Level 3. And don’t even get me started on Maturity Level 5—let’s save that for when your processes are truly optimized!
So, before you rush to comply with ML3 or beyond, remember: tackling the fundamentals at Level 2 will make your journey to higher maturity levels far smoother and more effective in the long run.
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.
Dear Appraiser,
We want to have an appraisal for CMMI Development, and we heard that we could offer three projects to the appraiser to look at. We really want to limit it so we don't have to implement CMMI and don't have to be in compliance on all of our projects. Is it true we can limit it to three? ~ CMMI newbie
CMMI Newbie,
Short answer is ....maybe! But, no.
The Evolution of the CMMI Appraisal: From Negotiation to Randomized Samples
In the early days of CMMI, specifically with v1.2 and earlier, the process for determining the scope of an appraisal was more of a negotiation. The Appraiser and the Sponsor of the appraised organization would sit down and agree on the scope, aiming to ensure that the organization would get the maximum benefit from adopting CMMI. If it made sense to include only one project in the appraisal, that was the route they would take. However, over time, CMMI started becoming a gatekeeper for federal contracts, which led to a shift in how these negotiations were viewed. Instead of focusing on value, many organizations began using this process as a way to avoid fully adopting CMMI. So, even though your company might have 100 projects in play, all you had to do was select one, right?
Well, it didn't take long for the Software Engineering Institute (SEI) to notice this trend. They began wrestling with the question, “How many projects are enough?” Their answer? Three. That was the new minimum requirement unless there were extenuating circumstances that could be justified. As a result, most appraisals began featuring a "standard" scope of three projects.
Fast forward to today, and I still get calls from companies saying, “We’ve picked our three projects.” A complete policy fail.
With the introduction of CMMI V2.0, the game changed once again. This time, the CMMI Institute moved away from letting companies pick their own projects and instead introduced the Randomly Generated Sample (RGS). Here’s how it works: the organization sends in a list of their active projects, and the Institute randomly selects a sample of projects to be appraised. But there’s a twist: rather than a single project being evaluated for all Capability Areas, each project is assigned a selection of individual Capability Areas. For example, one project might focus on Planning, Risk, and Monitoring, while another is evaluated for Requirements, Validation and Verification and Peer Reviews, and so on. No one project is expected to cover all practice areas, except for the overarching organizational ones.
To be honest, I’m not a huge fan of the partial samples—but, it is what it is.
Another major change with CMMI V2.0 was the timing. With earlier versions, you could pick your three projects far in advance and know about what to expect before your appraisal. With the RGS process, you won’t know which projects have been selected for evaluation until 60 days or less before your scheduled appraisal. That means the entire preparation process is compressed and, dare I say it, assumes you are actually performing at the maturity level you are seeking! OH NOOOOO!
Ironically, my experience with the RGS has been that, in some cases, fewer than three projects are actually selected. Go figure! It seems that in their effort to make the process more comprehensive and random, the nature of the sample doesn’t always result in the old "three-project" minimum.
At the end of the day, whether you’re used to navigating the old-school "negotiated" approach or the more structured, randomized sample of V3, one thing is clear: CMMI appraisals have evolved—and they continue to shift as the landscape of federal contracts and organizational processes change.
What do you think? Has your company had to comply any of these shifts firsthand?
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.
We just had the annual Lead Appraiser workshop in Florida, and our friends from ISACA made a major announcement!
CMMI V3.1 is in the works! What is the most exciting part about CMMI V3.1?
AI. That's right. Artificial Intelligence will now have an esteemed place within the model.
Details are sketchy at the moment, but we know that it's on, and the working group of 100+ volunteers, led by IBM, has been hard at work putting content together.
While Appraisals with AI content will not be available for some time, it's on the way!
What you SHOULDN'T do if you want to succeed with your Appraisal!
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.
This is a brand new version of Ask The CMMI Appraiser! To see my old CMMI blog go to Ask the CMMI Appraiser V2.0 here.
As I've been doing since 2010, I'll be taking your questions about CMMI and answering them here as soon as I can, along with a healthy dash of wit and sarcasm.
I'm been a Lead Appraiser since 2005, and a CMMI Instructor since 2006. I've delivered more than 300 CMMI-based Appraisals, 100 Agile Performance Appraisals, and taught CMMI to well over 2,500 students. So I've learned a few things along the way.
I'll be talking about straight up CMMI, no cap, implementation, and CMMI and Agile, along with any rumors I hear from our friends at ISACA!
I'll also be posting videos of interviews and snippets from my CMMI-TV channel!
Feel free to leave me a question here or email me at AskMe@broadswordsolutions.com.