Saturday, November 24, 2007

Technology meltdown (again) causes blog outages

Hey Readers!

Well, for the second time this year my traveling laptop refused to boot up. It's not such a bad problem when we're home at the Broadsword office, but it always happens when we're on the road, far away from discs, files, and backups. We love the Sony Vaio's here (light and fast) but after the third meltdown I'm looking for something new. They really don't hold up well on the road (sorry Sony).

I'm typing now on Patty's Apple MacBook and giving some thought to making the switch over to the dark side (or the white side, to be more precise). As a Windows user since the beginning (and DOS before that) I'm loathe to admit that a Mac might meet my needs, but with MS Office, MindJet's MindManager, and some of the other tools I use also available on the Mac, it might just work. I'm getting to the age where playing with drivers and hardware is just downright boring. I just want it to work!

Fortunately, we've been practicing pretty good Configuration Management here at the 'sword, so restoring files shouldn't be a problem, although emails could be a problem unless I go to another Outlook-capable system. I'll be executing a product-selection DAR soon enough on a new machine and software (if it's a Mac). I need to ad "durability" to my scoring criteria.

So, I'll start with a Requirements Development exercise, execute a DAR, and finally SAM using IPM/PP/PMC to help drive the process.

In the end though, the decision will be made by accounting :)

If anyone has successfully transitioned from Windows to Mac in an engineering work environment I'd be interested in hearing from you.

See you all when I'm back up and running!

Wednesday, November 21, 2007

Some crazy holiday blogging!

Hey readers,

Right now we're blazing down the highway (I-80) through Ohio on our way to our annual Thanksgiving event with my four siblings. As usual, I'm thinking about PROCESS and answering a few blog questions.

We're in a massive RV - 32 feet long, the boys are in the back playing "World of Warcraft," the wife is at the wheel, and I'm the Internet junkie, managing a wireless web inside the RV all through a Blackberry 7250. Slow but effective for all three laptops.

Here in the US we're about to celebrate Thanksgiving, and it's an appropriate time to say THANK YOU to all of you readers and posters who have made "Ask The CMMI Appraiser" successful this year. With over 1000 hits a week it's way more than I ever thought it would be and I've met 100's of people since I started a year ago.

For all of you in the US, have a great Thanksgiving. If you're outside the US, here comes an extra day for you to get ahead of us! Don't worry though, we'll be catching up on Friday.

Keep the questions coming!

Tuesday, November 20, 2007

So what is the difference between Agile and Waterfall anyway?

Could you tell us what the difference between Agile and Waterfall?

Sure, Agile guys are super laid back, and waterfall folks are really uptight :) No, that's not true, I know lot's of uptight agile guys too!

There are many differences between Agile methods (XP, SCRUM, Crystal, etc) and traditional "waterfall" methods, and a whole book could (and should) be written about it, but there are a few things that stand out for me (these are not all inclusive by the way).

- In an Agile environment, budget and time are fixed around Releases and Iterations, and scope (within each Release) is negotiable.

- In a waterfall environment, scope is fixed and both budget and schedule are negotiable (no one wants to negotiate these, but they do).

- In an Agile environment, a complete lifecycle is executed incrementally and iteratively against a subset of requirements during each iteration, enabling both the business customer and the development staff to learn along the way. These small sets are delivered to customer in useable chunks.

- In a waterfall environment, the requirements are fixed at the beginning, extensive planning is done, and all changes are managed through a formal change control process. The entire set of requirements is completed, the code is designed, built, and tested, and then delivered.

Finally . . .

- In an Agile environment, they pride themselves on focusing more on development and less on documentation (for better or worse)

- In a waterfall environment, most everything is written down, many times (for better or worse)

Both of the last items are problematic, but that seems to be the behavior.

How do I get smart FAST about PPQA?

I've been assigned the PPQA process area at my company and I don't know much about it. How do I get smart FAST about the practices?

How to get smart fast? OK, first get some #8 AWG/3 wire and and a plasma welder .. . .

I would start by simply reading the PPQA PA making sure to read the informative material (in other words, the whole chapter). Remember that PPQA has multiple purposes - one focuses on "are we using the process?" and "is the process appropriate?" The other is, "what insight can we gain by understanding these two things?" Is the process useable? Is it helping people? How can we make it better?There are numerous books on the CMMI that could help you - one that I like because of its organic approach is Mike West's "Real Process Improvement with the CMMI."

Good luck! And don't hurt yourself!

Monday, November 19, 2007

How many CMMI Experts do we need to achieve CMMI Level Three?

Dear Jeff,

We are suggesting that the IT shop of a company should move from level 1 to level 3. They have all of the documents available to give the benefits of implementing CMMi, however, they did not take into account the resources required to move up the maturity level. My question is: how do we size the number of CMMi experts our client will need to transform its IT activities from level 1 to 3 (say for 800 people). I would appreciate any thoughts that you might have on this.

Wow, you have ALL the documents in place? Doesn't that make them Level Three already? I'm kidding of course.

There are two ways of looking at your situation. My preference is to say "no additional resources are required" to achieve CMMI Maturity Level Three.

How is this possible? It's because the CMMI isn't something you can "do" to a client. It's something only they can do to themselves. It isn't about documents, it's about culture. I have had appraisals where all of the documents were in place, but it was obvious the company was not performing any of the behaviors from the model, and they were not successful at achieving CMMI Level Two or Three.

If an external firm does this to a client, they will leave at the conclusion of the engagement with all of the knowledge of how to develop and sustain the process. Part of Level Three is knowing how to design, deploy, and sustain a process. This might be good for business and billing rates, but it's not the best thing for the client organization.

Here at the 'sword we normally recommend to have one person onsite part time helping to guide the client organization towards managing this themselves - but any more than one tends to muddy the waters and the organization starts to depend on us too much and won't change themselves.

Now, once in awhile we come across a client that wants to hire an outside firm to do this for them. This is not something we do, but if they insist on a recommendation of needed resources, we have learned that to kick off and sustain an effort to move from CMMI Maturity Level One to ML3 takes about 3% of the overall engineering staff, plus another 1.5% to perform "PPQA" responsibilities. Given that you've said your client has 800 practitioners, that would account for about 24 people plus 12 for QA. How many of those are client personnel would depend on their skills and availability.

I would implore you to consider alternate ways to accomplish this goal that involve the client taking on as much of the load as possible. Your chances of success (and theirs) are far greater if you do!

Sunday, November 11, 2007

CMMI Accelerator Products

Hey Readers!

I don't usually self-blog but it's a slow Sunday and we here at the 'sword have some exciting news. For several years we've been focused entirely on consulting and training, and it's been going great. We've been growing fast, and bringing on new talent, so a few months ago we all got together to do some "strategic planning."

When discussing the many clients we have helped this year (thanks to all of you!) we realized that there were some companies out there that may want to "roll their own" when it comes to CMMI. Hey, this is great and is the same thing I did when I ran my first CMMI program (seems like decades ago).

Our sales person, Jill, kept asking what were the things all companies needed to do for CMMI that might be mundane, tedious work, and would our own internal collection of templates, tools, work products, procedures, and processes be of any use if we were to "productize" them in order to save these guys a few thousand hours? What a great idea!

So, we're announcing the release of our brand new "CMMI Acccelerator Boxed Set," an appraisal proven set of work products that will shave about one-thousand hours off of your program if you're just starting up.

For more info about the CMMI Accelerator click over to

Thanks for listening!

Wednesday, November 7, 2007

Can we just ignore Product Integration?

We have made solid progress on a very neat integrated process tool including process models, deliverable templates covering the full lifecycle from the point where one gets the contract to go-live. I am not clear in my mind how to deal with product integration. If I was a large system integrator, I would expect it would be all about taking the big software components and making them work together. In our case, I feel we have no significant product integration, because our method is always integrating the new item with the old as part of our normal lifecycle. Therefore, I would like to say that product integration is not relevant to us, but suspect that is not possible?

Well, let's start at the end first. You're correct, Product Integration cannot be "out of scope" for purposes of a CMMI Appraisal. In other words, if your goal is to achieve CMMI ML3 performance, then PI is a "must have." The only process area that can be out of scope is Supplier Agreement Management (SAM) and ONLY of you truly don't use suppliers.

That said, it's interesting that so many people overlook what they are already doing when it comes to "developing processes." I have not seen your system, but based on your description it sounds as if it manages the sequence, creates the environment, and has established procedures and criteria (or else it would not work!). If it also validates program-program interfaces, and perhaps even creates some documentation, even better. Didn't I just list more than half of the practices within Product Integration?

Sometimes the "stuff" we do everyday is, by definition, the process. You may need to round it out with some process definitions, guidelines for tailoring, training, and policies, but in the end, it sounds like a "PI Process" to me. With all of the bad tool implementations out there it's refreshing to see an example where a tool actually helped.

I recently conducted an appraisal where the client had a similar system to manage the entire lifecycle. Their system also created the executable package, the documentation, and installed it on the client site (they had a dedicated, long-term client). After digging into it for a couple of days we determined that it (with a few documents) did meet the spirit of Product Integration.

These types of innovative solutions are too few and far between in our business. Documents do not make a process - and the mentality that it takes a million documents to succeed at CMMI is just wrong. Congratulations on a great start.

How much of our company has to be ML 2 for us to say the whole company is ML 2?

Can you tell me what percent of your company needs to be recognized as certified Level 2 in order to state that your entire company is Level 2?

Contrary to popular belief, an entire company rarely achieves CMMI ML2 (or any other level for that matter). There is a concept in the SCAMPI Appraisal Method called an "organizational unit" that defines the target organization within a company that is to be appraised. When the appraisal is complete, you may say that your company has reached ML2, but in reality perhaps only a single organization in your company has reached that goal. That information is displayed on the SEI's appraisal results page, although I would argue that most people aren't aware of the concept when they look at.

The definition of the Organization Unit, or OU in Lead Appraiser speak, is something you discuss, and agree upon, with your Lead Appraiser. It needs to be credible (such as an entire location (Dayton, OH), a product line (mainframe payroll systems), a type of technology (all web development), or a management tree (everyone reporting to the Director of Engineering. . .). Inside of your OU, you and the Lead Appraiser will select a group of projects (3 or more) that is a representative sampling of the OU. Again, this is something you and LA agree on in advance.

A poor example is one where the OU is "all projects with the charge code 145387.

When it's all over (and if you're successful) if you're like most companies you will say [company name] is CMMI ML2. Some are more specific, and name the OU, but it my experience, most do not (right or wrong).

When you enter Baltimore-Washington airport there is a huge banner across the road that says "Lockheed-Martin - CMMI Level Five." I can assure you that, while they have achieved ML5 within some organizations, the "entire company" has not.

One exception I can think of is a company whose sole business is writing software in a single location. Perhaps then the company is ML5.

So, there are two ways to slice it. First, the organizational unit is agreed upon, and then a set of representative projects is selected. Make sense?

Thursday, November 1, 2007

How do we avoid bulky processes when using the CMMI?

We are in the process of defining our process artifacts after a CMMI Gap Analysis . Due the lack of experience in CMMI I am finding the definitions we are creating are too bulky and that worries me lot when I think of the implementations . Suppose we define all that is required , how can we best take extracts and publish it in a QMS system for others to practice?

Remember this:


Sometimes, "lack of experience" is exactly the RIGHT thing needed to be successful! I like the way you're thinking - don't stop doing that!

Usable and useful processes are a pre-requisite for any company to be successful, and too many go down the road of "over-interpreting" the CMMI so that you end up with heavy, burdensome processes that are not useful. Remember, your engineers are not there to "follow the CMMI," they are there to build creative solutions to business problems using technology.

One common mistake is trying to implement a process that includes all of the "typical work products" and "subpractices" within each specific practice. This was never the intention of the model. These are only examples, and are not "required" components of the CMMI.

What you need to do is internalize the meaning of the practices and goals in each process area and piece together a puzzle that shares work products and procedures across many process areas - in other words INTEGRATE don't REPLICATE.

Once you've identified all of the processes and work products conduct a CONSOLIDATE exercise where you consider the data in each work product and determine ways to reduce and eliminate documents by combing similar data, the ELIMINATE redundant and useless data.