Monday, October 29, 2007

How can CMMI work for small projects?

We are currently CMMI Level 2 for our deliverable products to customers. However, we tend to work on many very small internal projects (1 person, less than one month delivery) to support testing of products. As we gear up for Level 3, the thought of having a gazillion artifacts to cover 18 process areas seems like overkill for these projects. Is there some point where an organization can say a project is too small for CMMI compliance, as long as there is some minimal process in place for this micro project (requirements, test, estimated schedule, ...)?

This is an excellent (and common!) question.

Let’s start with the concept of “tailoring.” Tailoring is introduced in ML3 within the OPD and IPM process areas. The net on tailoring is that each project should adapt the process (or “tailor it”) for their own specific situation.

As CMMI is an “organizational” model, leaving projects out of scope can be problematic. At the same time, regardless of the model you use, do you really want individual engineers working in an ad-hoc way? What if they come up with something that is really cool and can be used by the rest of the company? What if their one-person project has a high risk profile?

So, the answer is not in having them create a “gazillion” artifacts (technical term) but having them tailor the process so it makes sense for their project. How about 1/2 a gazillion?

A couple of other points:

There is nothing in the model that requires us to use a gazillion documents, and I hope you were not guided in that direction by an LA or other CMMI consultant. You owe it to your practitioners to evaluate the impact on them and reduce, consolidate, and lighten the documentation to a reasonable amount of weight. Have you considered alternatives such as digital cameras, white board cameras, cards, databases, et al to reduce the load? Sometimes a single work product can (and should) satisfy multiple practices in the model.

Just to clarify, there are 18 PA’s in ML3, but not all of them require projects to create work products. OPD and OPF, for instance, are organizational, not project focused. So are parts of IPM. Is SAM applicable? That may be another that does not require much documentation. Same applies for parts of MA, VAL, and VER (SG1 in each one).

And of course, many of the GP’s don’t require project artifacts either.

Best of luck to you!

www.broadswordsolutions.com

6 comments:

Anonymous said...

Jeff, I presume that your talk about tailoring means that small projects will (probably) require different procedures than large projects, and that the small projects should therefore choose "small" procedures that better match the work scope of those small projects.

But, with a mostly fixed number of SPs and GPs that must be satisfied, there's also a fixed number of artifacts. You probably didn't mean that tailoring means one can get rid of half (or a comparatively significant number) of the artifacts produced by following the procedures, right?

In my opinion the fixed, minimum number of artifacts scales somewhat with the size of a project. For example, a huge project will probably have more plans and issues useful as artifacts than a small project. Was this what you meant?

In addition, for small projects, probably the artifacts are also more "shallow" than for huge projects. For example, your planning and resource allocation documentation will probably have a much smaller scope on small projects than on large projets. However, they're basically the same artifact regardless of the size of the artifact.

Anonymous said...

ole,

Thanks for the post. Why does each SP/GP need to map to a single artifact? I worked with one small company where there ENTIRE set of work products was one document (with appropriate sections of course) on projects that were less than 3 people.

Also, tailoring (in the CMMI) means to "select from the set of standard processes." Why couldn't you have a set of lite processes for small projects?

Anonymous said...

We probably agree. One document can easily make up for several artifacts, of course, but you would still trace those individual artifact requirements to that document. Also, small projects would probably use light-weight processes.

But, presumably the light-weight processes would nonetheless have to comply with the mandatory and recommended practices. Although the effort required to produce each artifact would be smaller on smaller projects, I can't imagine you can just leave them out.

Anonymous said...

Ole,

I think we're in agreement also. You're correct - they cannot just ignore or not perform a process, but it could be a lighter process that requires minimal documentation. Jeff

Anonymous said...

In reference to your article titled “CMMI for Dummies” at
http://blog.blazingangles.net/whatsthis/2007/09/cmmi-for-dummies.html
you state,
“Thirdly, tailoring does not mean you eliminate or modify parts of a process as you see fit. Tailoring means selecting those procedures, guidelines, templates, tools, and other process assets that are the best way to follow the process on your project. It does not mean omitting procedures or modifying procedures at will, because that's reverting to level 2 or level 1. Procedures describe how to follow a process, and tailoring means finding the procedures with the best fit for your project. Following the process is mandatory, and your freedom lies in determining how to follow the process within the limits of the tailoring guidelines provided by your company.”

I believe your guidance in this area goes beyond what CMMI states, and appears to be too restrictive. The CMMI glossary defines process tailoring as:
“Making, altering, or adapting a process description for a particular end. For example, a project tailors its defined process from the organization’s set of standard processes to meet the objectives, constraints, and environment of the project.”

It defines a process description as:
“A documented expression of a set of activities performed to achieve a given purpose. A process description provides an operational definition of the major components of a process. The description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior, or other characteristics of a process. It also may include procedures for determining whether these provisions have been satisfied. Process descriptions can be found at the activity, project, or organizational level.”

Note, that process tailoring is the altering of a process description, and a process description does not necessarily include a procedure. However, it does include the *major* components of a process. Hence, in contrast to your guidance, tailoring may eliminate or modify parts of the process, including the major components, so long as the policies, goals, and practices are met. It is not limited to procedures, guidelines, templates, tools, and other process assets. Additionally, it doesn’t prohibit one from “omitting procedures or modifying procedures at will”. A project may modify a procedure or eliminate the procedure and/or substitute their own. Elsewhere in the CMMI standard it states, "Projects tailor the organization’s set of standard processes to create their defined processes."

On the other hand, I believe your guidance should be a “best practice”. If the process is written correctly, projects should seldom need to modify a process. But I don’t believe we can make that an absolute.

For example, I know of one organization that wrote their processes in such detail, they were equivalent to training manuals, written in some cases to the level of “use your mouse to click on the…”. Although their processes satisfied CMMI, you can image that a lot of projects found it necessary to alter the processes. By the way, the organization had at least 3 different CMMI assessors within 5 years, and none identified this as a problem. Sorry to say, it should come as no surprise that the organization is still struggling with projects buying-in to CMMI.

Anonymous said...

Anonymous,

I think you're referring to Ole's article, not mine (although I think he drew from my blog as a source). That said, I agree with most of what he said.

I tend to look at the CMMI as guidelines to achieve greatness, not as minimum requirements to pass an appraisal. As an appraiser I don't look for companies to implement MY vision of CMMI - I look for them to implement what makes sense for their business - quite a different thing.

This is what I believe: the CMMI is a set of guidelines that help lead us to certain conclusions that are customized for a specific situation. Those guidelines have led me to the things I discuss in my blog. Others may have different needs for their process and the guidelines might lead them to another conclusion.

I disagree with your statement that if the process is well written it would require little tailoring. What's a "well written" process? One thing the model DOES tell us is that each project is unique and the process needs to be tailored for each situation - so a single "well written" process won't cut it. Perhaps you're better at it than I am, but I have never seen one process work.

My work around Process Selection (what I call Encapsulated Process Objects) is based on experience with people who interpret the model literally and end up with a rats-nest of modifications that cannot be evaluated or re-used. Letting your org modify processes at will ends up with them not using processes at all.