Friday, February 16, 2007

Is there a minimum waiting period between a SCAMPI C and a SCAMPI A Appraisal?

Dear Appraiser:

Is there a minimum amount of time that has to elapse from the end of the gap analysis or SCAMPI C until the initiation of the SCAMPI A? In other words, for processes not in place during the gap analysis how long do we to have them in place before starting the SCAMPI A Appraisal?

As the SEI likes to say to almost any question, it depends.

There is no rule or guideline within the CMMI that prescribes a waiting period. You could do it the next day if the results of your SCAMPI C are strong enough. However, if you've decided to conduct a SCAMPI C first, I'm thinking that maybe you don't think that's likely to be the case.

So given that, you'll need to give your processes and projects using them enough "bake time" to sensibly adopt the process and to see the results of running several projects through the "cycle." Depending on your typical project size and duration, this could take some time - say a minimum of six months to a maximum of twenty-four or more.

Like they say, it depends.

What if some core processes are performed outside of our organization? Can we still achieve CMMI Level 3?

Dear Appraiser:

Imaging following situation:

The SDLC begins in a software house at the point of "Low-level Design" and ends with "Unit & Package Tests".

Other parts of the SDLC (Business Req Analysis, High-level Design and System Integration, System Test, UAT) are done direct by concern internal customer of this software house.

Is it sensible & achievable - at this situation (the above mentioned "not active processes" are described, but recently not lived) - the software house can get CMMI Level 3 certification ?

Oh, you want sensible AND achievable? Picky picky picky..... :)

On the face of it (and not knowing much about your company) I can see where you might think you have a problem. After all, the CMMI requires you to be performing ALL of the Process Areas in a Maturity Level (and all of the levels below it) in order to be appraised , and the only exception allowable is to leave Supplier Agreement Management being out of scope (this is by no means a “given” by the way, but it does happen).

So I would start with a question. “Do you really have a problem?”

Let’s take Requirements Development (a ML 3 PA) as an example. You’ve implied that your customer supplies you with requirements in a way that allows you do jump right to low-level design. Is that always true? Do they supply you with true requirements, or simply with their needs? Do you spend any time “fleshing” out the requirements so that it’s clear what they mean? Do you ever “derive” requirements from your customer’s needs (derived requirements could be based on technical, regulatory, legal, process, organizational, or any other source that your customer had not considered)? Do you break requirements into “component requirements” or “sub requirements so that they can be allocated to designs?

If you do any of those things you are performing parts of requirements development. You may not ALWAYS be performing ALL of Requirements Development practices, but you are probably are performing the right amount for your business environment.
You’ve also indicated that there are other process areas outside of your scope. It’s possible that some of these things could treated as “Supplier” activities if they are done on behalf of your company, or some of them could be jointly appraised with your business partner for level 3, or for some of them you may even be performing more of the process than you think.

It may be "sensible" to include your customers as part of the appraisal of they can come to understand the value of what you're trying to do. In the end, they will benefit as much as you will from the effort.

Either way, I would recommend you connect with a CMMI Lead Appraiser as soon as possible to visit your site, speak with your stakeholders, and give you some specific recommendations for moving forward.

Best of luck to you!

Thursday, February 15, 2007

We want to be Agile and need to achieve CMMI Level 3 ASAP! How shouldwe begin?

Dear Appraiser:

We just set up a body of our new SW development company. The design of the processes is currently the task concerning us.

We would like to be agile and also to achieve the maturity CMMI Level 3 ASAP.
What would you recommend? How should we begin?

Let me start by saying that, contrary to popular belief, CMMI and Agile go together like "peas and carrots." Since your writing from outside the USA, that's my own way of saying that they are just meant to go together.

Remember, while "Agile" describes "how" you build software, the CMMI only describes "what" needs to be done. There is no reason to think the two ideas are in conflict.

The good news is that it sounds like you've set up a new organization; so at least some of the baggage that goes along with trying to shift the culture will be minimized.

I would first start by downloading a copy of the CMMI for Development from and become familiar with the various process areas associated with Maturity Levels Two and Three. I would also recommend that you complete a CMMI training course conducted by an SEI partner in your area. The biggest problem we face as appraisers is working with an organization that misinterprets the CMMI model because of lack of training and/experience. The course alone won't solve all of that, but it will sure help get you started.

The next step is to take a look at the processes you already have (you have them, even if they're not written down) and conduct an inventory and compare that to the model. Some will be there, some will be missing, and some will just not be "aligned" with the model (e.g.; you may practice an "alternative" that looks and feels different than the practice in the model).

Remember, in the CMMI the Specific and Generic Goals ("SGs" and "GGs") are REQUIRED, and the Specific and Generic Practices ("SPs" and "GPs") are EXPECTED. Everything else is just information and suggestions.

Next, I would recommend you spend some time learning about how Agile and CMMI can work together. One place to start is to download "Agile CMMI" from our website at It's located on our "Resources" page and will give you some insight into interpretation and philosophical issues related to both. There are several other excellent articles on the web available for download. One I recommend you search for is by Steven Baker and is titled "An Agile Organization's Journey to CMMI Level Three."

Getting to Level Three "ASAP" may prove problematic for you. It can be quite a bit of work (depending on your current state) just to reach Level Two and I would recommend you strongly consider taking a measured and deliberate approach that starts with achieving Level 2 and then gradually moving to Level 3. The Agile CMMI download has some sample work plans you can look at for ideas. That said, it's entirely possible you are further along than you think.

Once you believe you are "close" to filling in any process gaps, you might consider having a lead appraiser come in to conduct an "informal" appraisal - just as a check and to identify any gaps that may need to be filled.

He or she will be able to determine how soon a formal SCAMPI Appraisal can be performed.

Best of luck to you!

Monday, February 12, 2007

What in the world is an SEPG?

Dear Appraiser,

Could you help me understand the concept of a Software Engineering Process Group (SEPG)

If I had a nickel for every . . . .

Every SEPG I have come in contact with has had a different approach and mission. Some of the flavors include:

- "working" SEPG's that actually develop and deploy process as a type of internal consulting team.

- "oversight" SEPG's that oversee the process architecture, approve it, manage changes, and prioritize it (sort of a process CCB)

- "deliberative" SEPG's that debate the process approach and develop strategy for a process architecture and deployment

- "virtual" SEPG's that are made up of representatives from throughout the organization that dedicate a certain amount of time to the effort and are responsible for deploying and training everyone else in the organization

. . . . and everything in-between.

My favorite is the "virtual" SEPG because it helps the entire organization feel ownership of the process, thereby bypassing the most difficult and hard to achieve step - acceptance. The real difficulty here is getting people to dedicate their time and to make them accountable. You're trading one challenge for another but the latter challenge is, in my humble opinion, easier to manage. Don't underestimate the difficulty in enterprise acceptance - it's by far (an order of magnitude) the most difficult to conquer and the primary reason why the failure rate is so high. Approach and themission of your SEPG (or whatever you call it) is very important to the success of your effort.

In terms of it being "required?" The model doesn't dictate anyrequirement for an SEPG. You can look to OPF, OPD, and OPP forguidance on the "mission" but, that said, there are more than 100ways to skin the cat, name the cat, and cook the cat and in the endthese are only guidelines.

OPF and OPD give you PARTIAL guidance in the responsibilities of the SEPG, but there is a lot more to deploying a successful process than is presented in those two process areas. An SEPG encompasses parts of ALL of the PA's (starting to sound like a project?).

One more thing, there is a concept in the Theory of Evolution called "Punctualized Equilibrium" that describes the evolutionary pattern of "sudden spikes" and plateau's within a species. Your SEPG will follow the same type of pattern - in the beginning it will probably have more oversight, more hands-on "design" work, and later on will probably want to focus more on "operational" types of issues. This may require you to re-structure your SEPG - maybe even change up some people. Either way, it's important that you plan for that up front.

Sunday, February 11, 2007

The Business Customer says using a process adds cost to our project. How much does it really add?

Dear Appraiser:

Our business customer is constantly saying that any new process is going to add overhead and cost to our projects. They want to quantify it before agreeing to go forward. Help!

The answer is "9" :). No, just kidding.

How would they know?

I am working with a customer right now that used to say that. They complained that the new process IT was about to deploy would add 10% cost in overhead AND that it would slow IT down. The strawman they would use was "if the system costs $100 it only makes sense that if you "add" process in, now the same system would cost them $110. Only a neophyte could claim differently right?

Now that sounds like a pretty good argument eh? So, contrary my advice (which happens more than you might think) the CIO ordered a study to determine how large the overhead was to implement the new process. They dedicated a team for two weeks and they worked round-the-clock to document their findings. You know what they found? Nothing. Zip. Nada. They were not able to attach an overhead cost to the process because they were not able to determine what the actual cost to develop software was to begin with.

Sure, they knew what was budgeted, and they knew if the project had to "go back to the well" for more (it happens often), but what they didn't know were things like how much re-work ocurred, how many defects caused the developers time and energy, and even whether or not the system met the requirements of the business community. Heck, they weren't even sure what features the system contained in it when it was delivered.

You see, the perception of speed and cost are typically only that ... perceptions. If I can call a developer on the phone and get a change "slipstreamed" into the software, isn't that better, more efficient, faster, and easier than going through that pesky change control process? If I keep a design on my laptop isn't that easier than logging on to a control system and checking it out? Maybe once. But try to scale that up to even 5 developers and you're facing an entirely different situtation. How do we know projects are on time? Because the project manager with the best communicating skills (or the loudest) is always the one who is on time . . . or at least says they are.

This type of "black-box" software engineering is just bad for everyone. When no one knows what is actually happening inside the project they all make assumptions - and most of them are wrong.

When someone complains about overhead, what they're often saying is that you've asked them to change the way they do things, and their first reaction is to push back in whatever way they can.

Sure, you can over-engineer your process and make it worse, but let's assume for now that you have done an excellent job and it really is more efficient now.

How can the CMMI help you with this? You can start by positioning CMMI ML 2 as a "foundation" for managing projects across all relevant stakeholders and for information sharing and measurement of project performance as it is progressing though its project lifecycle. It will help provide that visibility into the black-box. In a way, it will give you a set of process tools and "levers" to begin getting an answer to that question "how do you know?"

A lot of good reasons to do this are listed in subsequent posts, but when you start to hear this common tune, it pays to start with the question: "how do you know?" and work from there. Chances are pretty good no one knows and that some of them are reacting to the change in a normal and understandable way.

Then again, how would you know?

Our customer doesn't care about process and says it's just overhead. How do I respond to that?

Dear Appraiser:

Our customer expects to have the application and nothing more. I mean, he doesn't care if we have a process, if we are CMMI compliant, if there is documentation, if there are minutes of the meetings, how things are done, etc. He cares only for having the application as soon as possible in his environment, and he is only paying for that. Everything else is overhead. Then, not only I am having a hard time convincing the development team to use process, but management keeps telling me that all the additional stuff (aka CMMI evidence) is something that the customer doesn't care at all... Oh boy. I'm having some difficult times down here. Guess I have to think more about these problems. BTW, I live in Buenos Aires, Argentina.

Believe it or not, we have the same problems here in the US! It's all too common a problem. In a way, your customer (and management) has set up the perfect scenario for you to make your argument. It's starts like this: Your customer should not care about the documentation - it's right that he only cares for the code. That is the "end product" he's paying for.

But he should consider what life would be like with:

- fewer defects
- software that more likely meets their needs
- a smaller support/maintenance organization
- projects being on time more often
- projects being on budget more often
- the ability to manage multiple releases at the same time easily
- the ability to revert back to any release when needed
- less mistakes during deployment (like the wrong code going into production)
- the ability to re-use code for future projects (saving up to 50% of effort)
- the ability to reuse architecture designs in the future (again saving up to 50%)
- the ability to use resources across a wider array of projects, making more people available
- the ability to not be held hostage by "bob" who is the "only guy" who can make it happen
- the ability to more quickly deliver projects (more Agile!)
- there's a lot more .. . .

And the best example is the debacle of Y2K. If the organization's who had to spend millions of dollars fixing that problem had done MINIMAL design and requirements documentation then COBOL programmers would not have to be paid $180/hour to fix it, and IBM (and dozens of other firms) would not be billions of dollars richer for the effort.

Is it overhead? I don't think it is, but the real question is "how do you know?" What is your true cost for developing software if you consider re-work, defects, mistakes, misunderstandings in requirements, endless test cycles, production fixes, et al. The honest answer is, they don't know.

I call it "underhead." It's as good a name as any, because the whole discussion is moot and a waste of time when you don't have accurate data.

Our XP developers say CMMI is not compatible with XP and Agile Methods. What do you think?

Dear Appraiser:

The other day I was browsing Amazon and I found the page of the book you are writing called Agile CMMI: . I am very interested in this topic since my organization has projects which follow a formal Unified Process and they are CMMI compliant, but other projects use Scrum + XP, and are definitely not CMMI compliant. I am in charge of the SEPG in the company, and I have difficult times when I try to instill some CMMI artifact in the agile projects. They are all the time bragging about "Hey, check out the Agile Manifesto. It says Working Software over Comprehensive Documentation". Then, I'm speechless. I have no arguments to use except for "Yeah ok. But CMMI requires it". And that ends the discussion, and we cannot agree at all. I know I should try to show the business value of every piece of documentation that is used, but hey, I've never read of Configuration Audits in any XP book!!!

That's funny! The Agile Manifesto (which I believe was written on a napkin in "pumpkin patch" colored crayon) was based on Deming's "Theory of Profound Knowledge" which is the same foundation that CMMI was based on. Tell them to think about that one for awhile....

It's a topic that would take more than a few posts to answer but perhaps I can point you towards some information. I gave a talk at the SEPG conference last year on this subject. You can download it off of our site for free at off of our resources page. It was the foundation for the upcoming book.

Bottom line - many developers who say they're "agile" are sometimes just "lazy." I did NOT SAY all. I've worked with several that are truly Agile (My friends at DTE Energy being one). Yes, the Manifesto does say that about documentation, but it doesn't say "no documentation" at all. It stresses the right amount . . . which is all I stress as a CMMI Appraiser. Unfortunately, that is often interpreted by developers as "none."

Believe me, Agile is VERY compatible with the CMMI. You may have to get creative with your artifacts as the SEPG leader, and there will more than likely be "alternative practices." . . . one size doesn't fit all.

One interesting approach is to get them, as the "agile experts" to develop their own versions of the processes and work products. I'll bet you a dollar right now that they come up with something FAR more complicated than what you're trying to implement. Why? Engineers like to be very prescriptive! It can be amusing to watch the horrible things they do to themselves in the name of process. J ust be sure to step in and help before they get too out of control.

My friend and colleague, author Ron Jeffries, one of the original signers of the "Agile Manifesto," and I were on a panel discussion together the other day at an IT software developer event. The promoters of the event advertised it as a "smackdown" with Agile vs. CMMI. The place was packed with people from both camps anxious to see the blood fly. Guess what? We agreed on almost every question the moderator asked! It was fascinating to hear how the issues were more about interpretation and perception, not about conflict. You'd think the audience might have been dissapointed - but they stayed after for HOURS asking more questions and commenting on how valuable the discussion was.

Can't we all just get along? :)

How is "Fully Implemented" determined in a SCAMPI Appraisal?

Dear Appraiser:

I was told by the Lead Appraiser that gave us the CMMI Intro Course, that the SCAMPI v1.2 MDD defines a practice as fully/largely implemented only if there is "a Direct Artifact and a Direct Affirmation" (both are a MUST). No Indirect Artifacts required whatsoever. He only mentioned they could be used for the purpose of clarifying some direct artifact. Could you explain your phrase to me?

A couple of thoughts for you. Section 2.4.2 of the MDD clearly indicates that there is only a "Direct Artifact, an "Indirect Artifact," and an "Affirmation." No "direct affirmation" is ever mentioned in the MDD. Further, the statement in the MDD that defines "Fully Implemented" reads: "One or more Direct artifacts are present and judged to be adequate; at least one indirect artifact and/or affirmation exists to confirm the implementation and; no weakness are noted." It then goes on to say regarding "Largely Implemented": ""One or more Direct artifacts are present and judged to be adequate; at least one indirect artifact and/or affirmation exists to confirm the implementation and; one or more weakness are noted."

So, a simple analysis of those two statements can result in the following equation: FI = (DA + (IA or Affirmation) + No Weakness). Similarly, LI = (DA + (IA or Affirmation) + 1 or more weakness). Simple.

By the way, there is a formula within the MDD that identifies a minimum amount of affirmations that are required. It's more than a one-liner though :)

Saturday, February 10, 2007

Can we just jump right to Maturity Level Three?

Dear Appraiser:

We've been preparing for a long time. we have standard processes and think we're ready to go right to Maturity Level Three, skipping over Maturity Level Two. Is this allowed?

Sure, you can do anything you want. Oh, you also want to be successful? Why didn't you say that before?

Allowed? Yes. Practical? Maybe. Recommended? Not often.

When it comes to "Maturity Levels" the formal answer from the SEI is that you "should not skip levels." This has multiple contexts. First, you should not skip appraisal levels and second, you should not skip implementing the processes in ML Two. I'll address just the appraisal question here.

One reason it may not be practical is that, while some of the ML 3 processes areas are "built" upon the ML 2 PA's, some of the ML2 processes "stand-alone" and are foundational to the model (e.g.; Configuration Management, Measurement & Analysis). You'll have a lot of trouble being successful with ML3 without them.

I've worked with some clients that felt strongly that they were ready to jump directly to ML3 and I've advised them to AT LEAST conduct a less-formal appraisal (SCAMPI Class-B) on ML 2 prior to the formal appraisal to reduce their risk. Some have taken that advice and some have decided to conduct a ML2 Class-A just to be sure.

I don't usually recommend skipping appraisals because ML 2 is a very large effort and a huge accomplishment in it's own rite. In my humble opinion, the "jump" for ML 1 to ML2 is much larger than from ML2 to ML3 (it's a major culture change). Conducting ML2 first and then letting it "bake" for a while is a good thing for your organization and almost always results in a far higher degree of applied maturity in the end.

We need to get to "Level 2" fast! How long will it take us?

Dear Appraiser,

My boss just told me we need to get CMMI Level 2 certified ASAP. We don't have any processes now. How long does it take?

Excellent question! I get this one more than any other, so let's take a minute to set the stage. First, there is no "certification" (at least not now ... stay tuned though) as such. The SEI has avoided that term for what appears to be legal reasons. Certification implies so much, and they seem keen on not assuming the risks that go along with it. More appropriate language might be that you are "performing at Maturity Level Two" or that you have "achieved Maturity Level Two."

Second, you've indicated that "we don't have any processes now." Are you sure? If you're successfuly building software or systems, and you plan, design, code, test, and deploy them then you must have a process. It may not be written down, and it may not be "world-class" but it's still a process. One can't open a door without a process (1: get up, 2: walk towards door, 3: reach left hand out; .... et al). What is it?

Note: Beware the "consultant" that tells you that you don't have a process. He's or she is selling. That said, you're process may not be "appropriate" for CMMI.

Third, how long it takes depends on a number of factors. Of your existing processes, how many of them are close to being "code compliant" with the CMMI Model? How well aligned are your processes with the CMMI (1:1 aligment is not important though). How large is your organization? How committed is your management team? Is there a budget for this effort? Are there resources assigned that have authority?

There are many other factors to consider as well. The best advice I can give is to go back to basics and start with the sponsor. Make sure you have ROCK SOLID support for your effort from as high a level in the organization as possible. You'll need it when the going gets tough. And it will!

I've seen all kinds of different examples of duration. One client I worked with had already been working towards CMMI for two years when I was called, so they obviously were closer than the one that just called me and literally didn't know how to start. The first client wanted to conduct a Maturity Level Three appraisal right out of the gate. Talking them down from that ledge was a real challenge. Because of the risk involved I convinced them to do a Level Two appraisal first, and if successful, we would do a Level Three a couple of months. This worked for them and they were eventually successful at both.

I've heard the phrase "18-24 months" thrown around in various SEI classes but I wouldn't put much faith in those numbers - could be less, could be more. It just depends.

A good way to start might be to contact an authorized lead appraiser in your area (list is available on the SEI's site) and have him/her come in for a consultation and informal assessment. That will give you a baseline to work with, a "taste" of what an appraisal is like, and a gap analysis. The rest, as they say, is up to you.!

Wednesday, February 7, 2007

What is this SCAMPI thing and how many should I order?

Dear Appraiser,

What is this SCAMPI thing and how many should I order?

Yum! Just thinking about SCAMPI makes me hungry - especially when the shrimp are big and fat and .... hey wait a minute! We're talking about software here, not dinner at Buca di Beppos.

SCAMPI is a TLM for "Standard CMMI Appraisal Method for Process Improvement." It's the companion appraisal method to the Capability Maturity Model Integration, or CMMI. Think of it as a "User Acceptance Test" for your company's processes.

When an IT or engineering organization adopts a process for developing software, it's often difficult to gauge how effective the process is, and how well it has been adopted across the entire company. Enter SCAMPI - a method now at Version 1.2 that follows a structured pattern to evaluate the process and institutionalization that has been deployed in your company. It has some similarities with the ISO9001 Audit, but it is deeper in the technology space and more detailed.

There are three classes of SCAMPI - Class-A, -B, and -C with "A" being the most ridgid and C being the most flexible and informal. Have you heard of company reaching "CMMI Level 4?" Well, if they did, they executed AT LEAST one SCAMPI A, probably more than that.

A SCAMPI "A" is the only class of the method that results in a "maturity" or "capability" rating (like Level "2"). Running a Class-B appraisal is perfectly good, it just doesn't result in a rating.

It's a team-based event which is led by an external "SCAMPI Lead Appraiser" that has been authorized by the Software Engineering Institute (SEI) to perform SCAMPI Appraisals.

To learn more you can go to


Tuesday, February 6, 2007

We are SW-CMM Level Three. How do we go to CMMI?

Dear Appraiser:

We were CMM L3 before we were acquired by another company. I came to know that our certificate no longer holds good and we have to go for CMMI certification. Where do we start from?

If your organization (“we”) has already achieved CMM Level Three I assume you still have at least some established processes and some type of QA activity to help keep you focused on sustaining it. If your management has changed, due to the acquisition, you may need to start with asking for, and receiving, their commitment and sponsorship. Then you will need to become educated on the differences between CMM and CMMI. This information is readily available on the SEI’s website. Transitioning from CMM to CMMI will take some work but your team should be familiar with the Process Area’s as they are different but similar enough that they should be able to understand them pretty quickly.

You probably should consider having some key people attend the training (at the SEI, or through a partner) so they have an appreciation for the scope of the model. Then you might want to engage, on strictly an advisory basis, someone who has deep knowledge of not only the CMMI model itself, but also someone who can guide you in the deployment of “reasonable and useful” processes that will not overburden your organization. Remember, this is something best done by you and your team – not an external agency – but some advice from the right outside source can really save you some time and money.

When you think you’re team is performing at a satisfactory level, you may want to consider having a Lead Appraiser conduct a SCAMPI C or SCAMPI B appraisal to determine your level of performance vis-à-vis the CMMI model. This will reveal any gaps you may need to address. Finally, if a SCAMPI A is your goal (you mentioned “certification” – the SEI doesn’t use that term, but I assume a SCAMPI A is what you are referring to) then a Lead Appraiser could conduct that for you at a time that is in alignment with your team’s performance and your business goals.

Could you share a format for waiver purposes?

Dear Appraiser:

I was looking for a format that would help when waiver situations arise in Tailoring (IPM) and Training (OT).

By waiver, I’ll make the assumption you’re referring to a waiver in the execution of part of the process or the completion of a work product.

So let me stir up the dust and say that the entire premise of “waiver” as part of a process architecture just doesn’t compute for me. Why? Let’s start with the CMMI itself – the IPM PA guides us to “Establish the Project’s Defined Process” based on tailoring of the defined process. This tailoring has guidelines. It further guides us on the maintenance of that tailored process throughout the life of the project.

In other words, we plan for, and expect, variability in the process and work products.

Just based on this alone, doesn’t the CMMI imply that a “waiver” is not the exception, but merely the normal course of business – i.e.; we never follow the standard process “as is” but must tailor it for our particular situation? This by definition isn’t a waiver (unless you’re going to grant a waiver to not tailor the process – and why do that?) This doesn’t mean, by the way, that just anything can be tailored any way we want. There must be guidelines and process wrapped around the tailoring that guide us.

Putting aside the CMMI for a moment, how about the real-world SW Engineering environment? The real-world intrudes forcefully on our plans to run our neatly designed process “assembly line” and forces us to tailor our process for each unique situation – to not do so would make it virtually impossible to be successful. Deming would roll over in his grave if we tried to foolishly insist that the process was so linear that we didn’t need to tailor it. In his “Theory of Profound Knowledge” he clearly expresses his belief that engineering is empirical by nature so to behave as if it’s linear is just counterproductive.

So, given that basic premise, your process must be designed to allow (and manage) tailoring as the norm, not the exception. It is the default position and, if designed well, will result in a lighter, more management process that still embodies the spirit of the CMMI. This is an important philosophical difference that will affect your overall process architecture, PPQA, CM, PP, and oversight processes.

Of course, some work products just can’t be tailored out (think workplan or requirements). Since that’s the case, no waiver is ever required for those either.

What does this mean in practical terms? A project’s collection of work products needs to be defined and committed to up-front, and that group should be reviewed and committed to as a package. This “additive” method, as opposed to the “subtractive” method that waivers represent, ensures that appropriate work products are not being “tailored out.” It also embodies a sense of empowerment for the project teams, eliminating a major hurdle when it comes to acceptance and adoption down the road.

Friday, February 2, 2007

What other kinds of reviews should we conduct on our process?

Dear Appraiser:

Besides the basic CMMI PA Compliance Reviews are there other techniques (review types) use to measure or ensure that processes are being adopted?

While I’m not sure what “CMMI PA Compliance Reviews” means exactly, there are many different techniques to plan for, deploy, and gauge adoption of process within your organization. Of these, the SPs associated with PPQA are only the most obvious.

The PPQA PA describes a couple of different options that address “functional” and “physical” audits of both the process and the work products, and there is also the concept of the “configuration audit” inside of the CM PA. For each of these, there are multiple interpretations and deployment methods you could explore to gauge adoption beyond just “compliance.”

Another category you may consider is monitoring the plan for adoption. It’s not possible for your entire community to adopt a process instantly, so planning for adoption is a wise choice. That schedule will depend on many factors, including organizational size, complexity, and culture, and the cyclomatic complexity of your process. Ultimately, you should probably consider multiple releases and iterations, where components of your process are rolled out to parts of your organization in a cyclical manner (sort of a cycle within a cycle).

You also may consider tying “project performance” metrics to “process performance” metrics. By this I mean, tag the segment of the population that you have deployed your process to, and determine how the project metrics (e.g.; defects, estimates, task metrics) are influenced by the process components that have been deployed (including training). I think you’ll find a very interesting correlation here that will help guide you in the further development, and deployment, of your process.

Don’t forget that process deployment occurs in two “meta-phases” – design and deployment being the first, and “Pointilized Equilibrium” being the second. This category combines “maintenance and support” with subtle spikes in increased functionality within the process over time. This is important because it changes your planning for resources. Not only will the metrics be different, but it will require (another) change in your process culture.

Best of luck to you.

Could you explain what the new concept of "Constellations" is in CMMI v1.2

Dear Appraiser:

Can someone clarify this new concept from v 1.2?"CMMi for development" and "CMMi for development + IPPD" are different constellations?"CMMI for acquisition" and "CMMI for Services" are also considered constellations?

The concept of “Constellation” makes a lot of sense if you consider that the CMMI v1.2 consists of a “core” set of processes and data that is then “extended” with a set of processes and informative data that address a functional sector, in this example “Development.” In previous versions, each “discipline” (Software Engineering, Systems Engineering et al) was almost a “one-off” and made it difficult to easily create new models based on services, acquisition, and other yet to be considered scenarios. This new architecture is more “open” in that it is designed to allow for the creation of new models based on the core.

IPPD is an “Addition” and, again, it is an architectural improvement to the model in that other “additions” (yet to be imagined or implemented) can easily be added to the model using this standard “interface.” In the case of Development + IPPD, it is the CMMI “core” plus the Development-specific processes and/or informative data that make up the constellation, with the addition of IPPD “on top.”

In engineering terms, the “core” set is like a common code-base, and the inclusion of additional customer-specific code would then create an instantiation of the code known as a “constellation.” In this same context, IPPD would be a “bolt on” with all of the requisite interfaces and standards pre-defined. Conceptually this is similar to the “good software architecture” many of us have been practicing and preaching for years. While it’s not “object oriented,” it is starting to show some of those attributes.

In systemic terms, and in the context managing new releases and maintenance, this new architecture is an important improvement for the model because now the business and systems communities can suggest, recommend, develop, or request that new constellations be developed for their unique businesses that cannot easily be “shoehorned” into an existing constellation. How about “CMMI for Small Companies?” “CMMI for Embedded Systems?” “CMMI for Agile Organizations?”

Just to clarify, three constellations have been identified thus far (Development, Acquisition, and Services).

What is an SEPG and how do we use it for CMMI?

Dear Appraiser:

I want some information in regard to SEPG's (Software Engineering Process Group). Basically we are lookingat two aspects: Typical structure of SEPG with their responsibilities, and b) Compliance with CMMI Level 5 requirements. We are not sure if it is a requirement of CMMI to have a formal SEPG in the organization. Looking forward to some guidance.

Every SEPG I have come in contact with has had a different approach and mission. Some of the flavors include:

"working" SEPG's that actually develop and deploy process as a type of internal consulting team.
"oversight" SEPG's that oversee the process architecure, approveit, manage changes, and prioritize it (sort of a process CCB)

"deliberative" SEPG's that debate the process approach and develop strategy for a process architecure and deployment

"virtual" SEPG's that are made up of representatives from throughout the organization that dedicate a certain amount of time to the effort and are responsible for deploying and training everyone else in the organization

.. . . and everything in-between.

My favorite is the "virtual" SEPG because it helps the entire organization feel ownership of the process, thereby bypassing the most difficult and hard to achieve step - acceptance. The real difficulty here is getting people to dedicate their time and to make them accountable. You're trading one challenge for another but the latter challenge is, in my humble opinion, easier to manage. Don't underestimate the difficulty in enterprise acceptance - it's by far (an order of magnitude) the most difficult to conquer and the primary reason why the failure rate is so high. Approach and the mission of your SEPG (or whatever you call it) is very important to the success of your effort.

In terms of it being "required?" The model doesn't dictate any requirement for an SEPG. You can look to OPF, OPD, and OPP for guidance on the "mission" but, that said, there are more than 100 ways to skin the cat, name the cat, and cook the cat and in the end these are only guidelines.