Delivers Process Improvement Frameworks with Proven Business Results

Entinex is a proud partner of the CMMI Institute. We have been using CMMI and its predecessors to help elevate performance for over 16 years and have seen the value of the models to deliver measurable business results for our clients. We look forward to working with the CMMI Institute to extend the reach of the CMMI frameworks to enable individuals and organizations to reach their goals.

Our Founder, CEO, and Performance Jedi, Hillel Glazer continues to be the pathfinder for bringing CMMI, lean and agile practices together. He furthers his involvement by playing a critical role in helping the CMMI Institute formulate its strategies and carry out several important projects, including providing important input to the success of their SEPG conferences and foundational material for CMMI’s product suite in the agile market.

(Also, see this article on CMMI in SD Times.)

November 20, 2013 09:00 AM Eastern Standard Time
PITTSBURGH–The CMMI Institute announced today its strategy to extend the reach of the CMMI model to enable businesses of every size in every industry to elevate performance and to provide tools that equip CMMI practitioners to begin and to grow their journey with CMMI.

The CMMI Institute, established by Carnegie Mellon University, is home to the Capability Maturity Model Integration (CMMI), a gold standard of excellence in software and systems development. The Institute will continue to help this market to solve business problems while advancing the use of the model to new industry sectors around the world.

CMMI is used by some of the world’s most admired and innovative organizations, including Samsung, Accenture, Proctor & Gamble, and Siemens. CMMI adoption has been a powerful differentiator for businesses and a catalyst for economic growth in regions that invest in its broad adoption.

“To compete in the global market, leaders must build organizations that can consistently deliver quality and value in products and services,” said Kirk Botula, CEO of CMMI Institute. “The CMMI Institute enables organizations committed to excellence to achieve measurable results in the facets of their business that matter most to their goals. CMMI provides a framework of practices that can help organizations to identify and address key challenges to improve performance and the bottom line. We all know work is not the way it is supposed to be—CMMI helps make it better.”

The CMMI model was developed at Carnegie Mellon’s Software Engineering Institute (SEI) through collaboration of government, industry, and academia to help the Department of Defense and its contractors like Raytheon, Northrup Grumman, Lockheed Martin, and Boeing improve their software engineering capabilities. Widely trusted as a mark of reliability, many organizations require CMMI adoption as a pre-requisite for bidding on contracts.

Thousands of companies across multiple industry sectors in 94 countries have adopted its practices to elevate performance and have been appraised for capability and maturity using CMMI methods. The CMMI product suite includes product development, service delivery, procurement, and staff management—making it a worthwhile investment for any business. Carnegie Mellon University founded the CMMI Institute in order extend the benefits of CMMI beyond software and systems engineering to any product or service company regardless of size or industry.

KK Raman, Partner Business Excellence, KPMG India says, "Carnegie Mellon is a pioneer in developing best practices and transitioning them to industry, and this is reflected in the global adoption of the CMMI. KPMG is one of the premier organizations around the world with over a decade long partnership with CMU. We help use the CMMI Institute product suite—frameworks, training, certifications, and appraisal methods—to achieve organizational goals by enhancing processes."

Extending the Benefits of CMMI

The global adoption of CMMI is supported through a vast network of partners who guide organizations in the successful adoption of the CMMI models. As part of today’s news, CMMI Institute is advancing the practice of CMMI with an online self-assessment tool as well as new professional credentials for practitioners.

• CMMI Self-Assessment Tool: A new online tool that allows organizations to begin their journey of elevating performance as well as to diagnose their existing implementation by assessing the current state of their organization. By answering a brief set of questions, users will gain critical insights that provide an analysis of an organization’s strengths and weaknesses as well as solutions to improve the capability of their organization.
• CMMI Associate and CMMI Professional Certification: The CMMI Institute will be offering certifications to help individuals translate their experience with CMMI into professional development opportunities. CMMI Associate and CMMI Professional Certifications will provide confirmation of an individual’s knowledge of basic and advanced concepts in CMMI and demonstrate to current and prospective employers they are dedicated to excellence and have valuable skills to help elevate organizational performance.

"As a professional who uses CMMI daily in my work, I am committed to advancing my understanding of the models and to helping my clients and my organization position themselves to successfully meet their goals. The practitioner credentials will not only provide a clear path for my growth, it will also help me to communicate and validate my skills to my clients as well as my organization," said Capri Dye of Hubbert Systems Consulting, Inc.

The CMMI Self-Assessment Tool and Practitioner Certifications will be available in early 2014.

About CMMI Institute

The CMMI Institute, a subsidiary of Carnegie Mellon University, is dedicated to elevating organizational performance through best-in-class solutions to real-world challenges. The Institute is the home of the Capability Maturity Model Integration (CMMI) for Development, Services, and Acquisition; and the People Capability Maturity Model which are process improvement models that create high-performance, high-maturity cultures. The models are used in thousands of organizations worldwide to deliver business results that serve as differentiators in the global market.

About Entinex

Entinex, Inc. is an aerospace engineering firm bringing the same skills and critical thinking used every day in aerospace to solve complex business problems. The creative, technical, and audacious characteristics of aerospace are leveraged to create elegant, inspiring, and break-through solutions to real business challenges to companies throughout the world in many fields and industries. The company’s approaches see through hairy, complex business problems with x-ray-vision-like clarity and accuracy and designs, explains and implements solutions with amazingly powerful yet easy-to-apply simplicity.

Call for papers to the Cutter IT Journal for which I’m the edition’s guest editor.

Topic: Agile and CMMI: Why Isn’t this Conversation Dead Yet?

Proposals/abstracts due 17 August 2012, so act quickly!

See Cutter’s blog and web site for more information, including specific areas of interest, editorial guidelines and how to submit your proposal/abstract.

(If you reference CMMI experience, please ensure that your experience with CMMI is from using v1.2 or later.)

This morning, SEI Partners and Sponsored Individuals received the letter, below, from Dr. Paul Nielsen, Director & CEO of SEI.

THIS IS A GOOD THING.
Watch the video for my explanation why it is.

******
To All Partners and Sponsored Individuals:

The following important announcement is sent on behalf of Dr. Paul Nielsen, Director and CEO.

Carnegie Mellon University (CMU), the Software Engineering Institute (SEI) and the U.S. Department of Defense (DoD) have mutually decided to move the CMMI (Capability Maturity Model Integration) and the PCMM (People Capability Maturity Model ) out of the SEI and into an independent business unit of CMU. We believe this new unit may also be a natural transition path for other SEI developed technologies, methods and practices as they mature.

The SEI is a Federally Funded Research & Development Center (FFRDC) established in 1984 to provide technical leadership and innovation through research and development to advance the practice of software engineering and technology in support of DoD needs. DoD acknowledges the significant contributions that CMMI has made to Defense programs and the software engineering community, in general. Recognizing the maturity of CMMI and PCMM, SEI and DoD have agreed that the maturity of these technologies make this an appropriate time for the SEI, as a science and technology based FFRDC, to concentrate on newer research.

Carnegie Mellon University is excited about establishing this new business unit to serve the global software engineering community even better–to make adoption, evolution and maintenance of the models more flexible for government and commercial organizations, to be more creative with our partners and other organizations in creating business relationships, and to face the market more proactively.

As we plan and implement this transition, one key objective is to cause as little disruption to our licensees and partners as possible; therefore, we expect the transition to be seamless, with continuity among key participants. You can expect:

• A renewed, single-minded commitment to the product
• A transition that underscores the central role of our licensees and partners
• Continuing investments to expand the scope and evolution of the models

We intend to transition these technologies and evolve the business model in conjunction with our partners and the Partner Advisory Board. Current details of the transition can be found at http://www.sei.cmu.edu/partners/CMMI-Transition-2012.

Additionally, we will be hosting interactive webcasts on 25 May at 9:00-10:00am EDT and 30 May at 5:00-6:00pm EDT. To register for the webcasts Friday, May 25: https://www1.gotomeeting.com/register/649898953 or Register Here and Wednesday, May 30: https://www1.gotomeeting.com/register/690424856 or Register Here. Look for more face to face information sessions at SEPG-EU.

Best regards,
Paul

For more than the last 10 years I’ve been thinking a lot about CMMI.  Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation.  I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks.  And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle.  I wish I were.  And, this is what’s both frightening and sad.  I’m merely talking about the relationship between capacity and demand.  For that matter, I’m not even worried much about demand, which is another matter.  I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work.  Throughput, for instance.  According to others, it’s the wherewithal to do the work.  Either way, too many operations don’t know what their capacity is. 

What does it actually take to get work done?  And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees].  This is an "out-of-tolerance" condition.  It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends.  Furthermore, it is risky to do so.  One client said he couldn’t be away from the office for 5 minutes before product would stop shipping.  Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation! 

What’s worse is the extra time he and his team put in is entirely unaccounted-for.  His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out.  The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation.  But a better equation to work with is work worked-on = work completed.  The key mistakes is the assumption that started = in-work.  That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months.  Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility.  And, to put it plainly, by "programmatic" I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want. 

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation.  In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize.  Over time, they’ve found that their Build*Capitalize approach is tough to Sustain.  Try that they might, whether it’s CMMI or something else, they’re looking to "fix" the equation on the "Sustain" side.  The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the "Sustain", it’s that their approach to Capitalizing on what they Built is no longer Sustainable.  What needs to change is on the Build side.  Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose "build" is broken is putting the cart before the horse.  While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the "build" side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side.  If CMMI is to be truly about improving the processes of the operation in a "sustaining" sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity.  Because unless it knows its capacity, it doesn’t really know what’s going on.

For more than the last 10 years I’ve been thinking a lot about CMMI. Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation. I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks. And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle. I wish I were. And, this is what’s both frightening and sad. I’m merely talking about the relationship between capacity and demand. For that matter, I’m not even worried much about demand, which is another matter. I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work. Throughput, for instance. According to others, it’s the wherewithal to do the work. Either way, too many operations don’t know what their capacity is.

What does it actually take to get work done? And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees]. This is an “out-of-tolerance” condition. It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends. Furthermore, it is risky to do so. One client said he couldn’t be away from the office for 5 minutes before product would stop shipping. Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation!

What’s worse is the extra time he and his team put in is entirely unaccounted-for. His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out. The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation. But a better equation to work with is work worked-on = work completed. The key mistakes is the assumption that started = in-work. That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months. Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility. And, to put it plainly, by “programmatic” I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want.

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation. In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize. Over time, they’ve found that their Build*Capitalize approach is tough to Sustain. Try that they might, whether it’s CMMI or something else, they’re looking to “fix” the equation on the “Sustain” side. The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the “Sustain”, it’s that their approach to Capitalizing on what they Built is no longer Sustainable. What needs to change is on the Build side. Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose “build” is broken is putting the cart before the horse. While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the “build” side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side. If CMMI is to be truly about improving the processes of the operation in a “sustaining” sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity. Because unless it knows its capacity, it doesn’t really know what’s going on.

This is probably the most important blog entry I’ve ever posted.

The video is the longest video I’ve ever posted on the blog, and for that reason, I’ll keep the text content to a minimum. 

Here’s why you should watch the video:  CMMI may be entirely wrong for you, and you may not know it!

The video explains an epically crucial reality about CMMI that many agile (and other) teams are not aware of, leading them unknowingly down a path of self-defeat and damage.  All of which could be avoided with this one super-critical piece of knowledge.

You’ll thank me later.

Backstory:

The lure of seemingly limitless opportunities can be quite strong, obviously.  And, especially in tough economic times, succumbing to that lure can cause even the best of businesses to act unwisely.  Such is the lure of CMMI ratings.

Well, anything that’s very alluring can cause unwise behavior, I suppose.  Whether it’s as apparently harmless as indulging in a luscious dessert, spending money on unnecessary luxuries, or any of equally limitless opportunities to make bad choices, doing what we want instead of doing what’s right shows up even when working with CMMI.

This blog is full of examples of such bad CMMI choices, but there’s one bad choice I haven’t mentioned much about.  That’s the choice to even try to use CMMI.

When working with a knowledgeable, concerned, trustworthy CMMI consultant, an organization should be steered away from CMMI when their circumstance doesn’t align well with model-based improvement using CMMI.  In some cases, it may be a matter of steering towards the right CMMI constellation (e.g., for Development, or, for Services).  However, just as whether or not CMMI is right for an organization ought to be discovered before too much energy is put into it, so should the decision about a particular maturity level within the constellation.

No CMMI constellation should be attempted if/when the organization doesn’t control the work that it does.  Namely, that the work it does is controlled by another organization, such as a customer.  Or, put the other way, CMMI should only be used if/when the processes used by the people doing the work are controlled by the same organization using CMMI to improve them.

At Maturity Level 2 (ML2), almost any type of work can use the practices in that level to improve its performance and to demonstrate that the practices are in place.  However, at Maturity Level 3 (ML3), you have to be doing the type of work in the particular constellation in order to be able to use the practices in it.  If you’re not doing that type of work, the practices will be irrelevant.  Attempting to use the practices when there’s no such work being done will only cause the practices to get in the way and add nothing but frustration.

In particular, if you’re not doing work that involves structured engineering analysis, CMMI for Development at ML3 will be truly unwieldy.

Adding practices for work you’re not doing is an example of the bad behavior many organization exhibit when they’re chasing a level rating rather than hot on the trail of performance improvements.  It’s these sorts of behaviors that are somehow rationalized as being beneficial when, in fact, they are unequivocally, diametrically, and everything but beneficial.  They are a colossal waste of time and money and detrimental to morale and productivity.

You really need carve out about 11 minutes to watch the video.

I’m speaking @ the Lean Software and Systems Conference 2011.

The program is amazing!

I highly encourage attendance.

There’s an entire day in cooperation with the SEI with 3 unique tracks on it including a track on CMMI and Multi-Modal Processes (which I’m chairing).

Take a look at my talk… it’s from my upcoming book: High Performance Operations.

Register quickly and make your hotel reservations! Block rooms are nearly gone!

Apple, Inc. learned the hard way what happens when engineering isn’t complete.  In particular, when verification and/or validation aren’t performed thoroughly.

Verification is ensuring that what you’re up to meets requirements.  “ON PAPER.”  BEFORE you commit to making the product.  It’s that part where you do some analysis to figure out whether what you think will work, will actually do what you expect it to do.  Such as, walking through an algorithm or an equation by hand to make sure the logic is right or that the math is right.  Or, stepping through some code to see what’s going on before you assume that it is behaving.  Just because something you built passes tests, doesn’t mean it is verified.  All passing tests means is just that: you passed tests.  Passing tests assumes the tests are correct.  If you’re going to rely on tests, then the tests need to be verified if you’re not going to verify the requirements or the design, etc.  Another problem with tests is that too many organizations only test at the end.  Verification looks a lot more like incremental testing.  Hey wait!  Where’ve we seen that sort of stuff before?

Had Apple’s verification efforts been more robust, they would have caught the algorithm error that incorrectly displays the signal strength (a.k.a., “number of bars”) on the iPhone4.  This is why peer review is so central to most verification steps.  The purpose of peer review, and of verification, is to catch defective thinking.  OK, that’s a bit crude and rude… it’s not that people’s thinking is defective, per se, but that thinking alone didn’t catch everything, which is why we like to have other people looking at our thinking.  Even Albert Einstein submitted his work for peer review.

Validation is ensuring the product will work as intended when placed in the users’ environments.  In other words, it’s as simple as asking, “when real users use our product, how will they use it, and will our product work like we/they expect it to work?”  Sometimes this is not something that can be done on paper, and you need some sort of “real” product, so you build a prototype.  Just as often it’s not something that can be done “for real” because you don’t get an opportunity (yet) to take your product into orbit before it has to go into orbit to work.  Sometimes you only get one shot, and so you do what you can to best approximate the real working environment.  But neither of these extreme conditions can be used by Apple as excuses for not validating whether or not the phone will work as expected while being held by the user to make calls.

Had Apple’s validation been operating on all bars, they likely would have caught this while in the lab.  When sitting in its sterile, padded vice, in some small anechoic chamber, after taking great care to ensure there are no unintended signals and nothing metallic touching the case, someone might’ve noticed, “gee, do you think our users might actually make calls this way?”  And, instead of responding, “that’s not what we’re testing here”, someone might’ve stepped up and said, “hey, does our test plan have anything in it where we’re running this test while someone’s actually using the phone?”

Again, testing isn’t enough.  Why not!?  After all, isn’t putting it in a lab with or without someone holding the phone a test?   True…  However, I go back to the same issue we saw when using testing as the primary means of performing verification… Testing is too often at the end.  Validating at the end is too late.  You need to validate along the way.  In fact, it’s entirely possible that Apple *did* do validation “tests” of the case separately from the complete system, and, in *those* tests — where the case/antenna were mere components being tested in the lab — performed fine, and, then only when the unit was assembled and tested as a complete system would the issue have been found.  In such a scenario we learn that component (elsewhere known as “unit testing”) is not enough.  We also need system testing (in the lab) and user testing (in real life).  Back we go to iterative and incremental…

So you see… we have a lot we can apply from ordinary engineering, from agile, and from performance improvement.  Not only does this… uh… validate(?) that “agile” and “CMMI” can work together but that for some situations, others can learn from applying both.

In full disclosure, as a new owner of an iPhone 4, I am very pleased with the device.  I can really see why people love it and become devotees of Apple’s products.  Honestly, it kicks the snot out of my prior “smart” phone in every measurable and qualitative way.  And, just so I’m not leaving anything out, the two devices are pretty much equally balanced in functionality (web, email, social, wifi, etc.)  – even with the strange behaviors that are promised to be fixed.  For a few years, this iPhone will rule the market and I’ll be happy to use it.

Besides embarrassing, this will be an expensive couple of engineering oversights for Apple to fix.  And, they were entirely avoidable for an up-front investment in engineering at an infinitesimal fraction of the cost/time it will take to fix.  For even less than one day of their engineering and deployment team’s salary, AgileCMMI can make this never happen again.

Apple, look me up.  I’m easy to find.

In this quote, CAPT Kirk wants Dr. Bones McCoy to do something he feels he’s not-qualified to do because he doesn’t know how to treat the species.

I’m using it to explain that organizations looking for a lead appraiser to work with them towards an appraisal and/or to perform an appraisal ought to think of what we do as they would think of a doctor, not a laborer or vendor.

Do you really want the lowest price doctor?

For that matter, is the highest price doctor necessarily the best in town?

When reaching out and interviewing for a lead appraiser or CMMI consultant, you:

• Want the person who is the right person for the job.
• Want someone who is qualified (definitely not under-, but preferably not over- either).
• Not the lowest bid.

Seriously, whoever you hire for this effort has in their power the ability to make or break your future.  They literally have the health and well-being of your organization in their hands.  They can put you in the dump just as easily as they can take you to the next level.

They should see themselves that way as well.

Unfortunately I’ve got too many sad stories of appraisers/consultants who definitely see that they can make or break you, but they don’t feel like they personally own the responsibility for what happens to you when they’re done.

If it costs too much?  So what?
If you get no value?  Not their problem.
Didn’t see any benefit?  Didn’t learn anything?  Things take longer and cost more and you’re not seeing internal efficiencies improve?
YOU must be doing something wrong, not them.

In an AgileCMMI approach, your CMMI consultant and/or lead appraiser would see themselves as and act like a coach, and would put lean processes and business value ahead of anything else.  And, an AgileCMMI approach would know that when the processes work, they add value; when they add value people like them and use them; when people like and use them, the next “level” is a big no-brainer-nothing.  You get it in your sleep.

Let me know if you want help finding the right lead appraiser or consultant.

Your people with prior CMM/CMMI experience are probably worse than worthless, they’ll probably cause you to fail.

Why?

Because what they (or you) think they (or you) know is probably wrong and the advice you’re getting, the expectations being generated are entirely off base.

It all goes back to the many ways in which CMMI can be done poorly and the few, simple, but hard work ways in which it can be done correctly.

Every time I meet with a new prospect I’m confronted with reams of inaccurate assumptions and assertions about what it will take to implement CMMI and how am I expected to “do all that” and still claim to be “agile”.

My simple answer: I’m not going to do all that.  And, you shouldn’t be doing it either.

Seriously, you’ve got to wonder about executives who will force their company into doing stupid things for the sake of a rating instead of doing their homework to learn about CMMI before they head out on an implementation journey.

A recent client didn’t know any better.  They hired a consultant and an appraiser to evaluate their work against CMMI and to help them prepare for a SCAMPI appraisal.  Unfortunately, they got as far as the appraisal only to realize they weren’t going to get the target Maturity Level.  (I won’t get into some of the inappropriate behavior of the firm they hired.)

However, when this client was confronted with:

1. Do something stupid, or
2. Find a better way to do something smart.

They took option B and found a consultant and an appraiser who understood their context and found how to both be on a disciplined improvement path while also remaining true to their own business.

Fortunately for them, this client had a strong engineering backbone and knew what they did worked and were confident in their processes.  Many companies have a while before they can claim that much.

Next week:

Picking a Lead Appraiser:  “Dammit, Jim!  I’m a doctor not a bricklayer.”