Scaling the scope of CMMI
Eric Willeke
your plans, Hillel.
Scenario: A small custom software provider works for a variety of
regulatory environments including FDA, DOD, and none. Contracts range
from two week prototyping efforts for eCommerce sites to multi-year
regulated embedded projects to high-availability medical information
system.
Questions: Does the CMMI model support the entire breadth of process
needs for this company and its projects? Does the CMMI model allow for
situations where the correct level of process is "Sign a short
statement of work and put the customer and a developer in the room
until it's done"? If so, what sort of approach to process definition
allows this company to maintain both agility AND CMMI-level maturity?
Assumptions:
I'll go ahead and recognize a couple of the assumptions I included in
the scenario - feel free to challenge the validity of these or bring up
more that I may not have recognized.
Assumption - The company's CMMI implementation isn't so light yet
complete that it IS the most appropriate for every project.
Assumption - A conscious choice not to utilize the company's process on
a given project violates the intent of measuring organizational
maturity.
Hillel Glazer
I'll challenge your 2nd assumption which (in my own words) sounds like
you're saying that a company must use its process assets on all
projects or risk not managing development "in a mature fashion".
That's not the case. Not all projects fit a company's set of
processes. I would further argue that a company as yours shouldn't try
to conduct all its projects using all of its formal processes. In
particular, a project that might take 1 developer 1 week might not be
well-suited to all practices in all processes, whereas that same
company might also be in the market of multi-month, multi-developer
projects for which formal process management would be very appropo.
This isn't to say that *no* processes are needed in the smaller
projects, just that a particular company's processes may not be suited
for smaller projects. It's also not to say that a process architecture
*can't* be designed to handle projects of smaller and larger sizes, but
the question to come up will be whether the investment in creating such
a scalable process set will be returned through implementation of those
processes.
I guess the answer to that lies in what the company sees are its
"typical" project size as well as in whether not using a formal process
will negatively impact the risks on the project or the relationship
with prospects/clients for such work.
In all of the process policies my clients write, I coach them to
include some sort of threshold value to determine whether the formality
of the processes are required. Keep in mind: the purpose of formal
processes are to reduce the risk of not delivering what the customer
wants, when they want it and at the price they're willing to pay.
The "triple constraints" (as many call it) must be what balances
against the extent of process formality. So, in some cases you might
not use "all" the processes or at least not use all practices of all
processes. Some might even call this "tailoring" from the
"organization's set of standard processes".
Eric Willeke
questions to explore the threshold concept further.
I really like the idea of thresholds that are predefined within the
process to allow exits from the process. What form do these thresholds
normally take? Are they specific situations related to the project
environment, scope, cost, duration or other measurable characteristics,
or is it permitted to state them subjectively in such a way that the
experience of the individual project manager can be used to determine
the appropriate level of process to apply?
What decision evidence will an appraiser need to see in order to be
'ok' with these projects existing outside of the standard process
environment? Does this evidence change as an organization moves to
higher maturity ratings?
Does the "non-process" on the other side of the threshold need to be
fully specified in advance, or is there room for a highly situational
ad hoc approach? Is it appropriate to have a mix across the various
process areas? For instance, use standard organizational processes for
ISM and SAM, etc but have non-defined approaches for PMC, RD, and REQM?
Hillel Glazer
and in whatever combination appropriate to the organization and/or the
project.
I suppose one could argue that the threshold always reduces to a
question of risk in some way.
So, for example, is "size" always a good threshold? What constitutes
size? Number of developers? Number of feature/functions? Should a
1-person e-commerce project that might take 4 months require formal
processes but not the 4-person 1 month project? And so on.
Whatever threshold makes sense is up to you and your organization as
appropriate for your business rules and reflected in your policy. CMMI
doesn't specify . How/whether it is consistent with expectations of
CMMI shows up in how well your policy achieves your process improvement
goals.
Keep in mind, CMMI is about process management for process improvement.
If your projects "opt out" of following a process then that
option/decision ought to be weighed against whether doing so is
good/bad for the company's improvement aspirations.
If the only reason an organization pursues use of the CMMI (framework
for process improvement) is so they can say they're "doing" CMMI, then
the "opt-out" option might be a little hard for them to wrap their
brains around -- they might find it too convenient to opt most of their
project out and still (somehow) claim to be using CMMI.
The challenge is to design elegant processes that work in any size
project or organization with the same benefit of process improvement.
In an appraisal, and for ratings purposes, projects that opt-out would
not be in the scope of either the appraisal or the rating. Part of the
appraisal process includes the identification of the "organizational
unit" being appraised. The rating applies to the "OU", not to the
entire organization. Projects picked for appraisal/ratings represent
the OU, not the entire company, unless it can be shown that the OU
*does* represent the entire company.
You can begin to see how design of processes becomes very important so
that you're not having too many projects opting out of the processes --
to the point at which drawing a line around the OU becomes terribly
convolulted.
Projects that opt out of the process don't need to have any process
associated with them. On the other hand, why lose valuable data? Even
opted-out projects might provide useful process or programmatic
feedback.
One of the advantages at Maturity Level 3 are the creation of defined
process assets that are tailored to each project. If an OU is
operating at that maturity, they ought as well to be capable of picking
how they will implement a practice for a given project and still gain
the benefits of doing so even if at a less "formalized" production
effort.
Susan Carter
I am currently working with SEP on their CMMI gap analysis. Tim
Shoemaker from SEP gave me this site and your name as a contact person.
I agree with you on the tailoring for their projects that falls
outside of their formal standardizations. We are now capturing what
those projects are and how manyfall under FDA, FAA and "other". There
will possibly have to be a segment of projects that are at the
discretion of the Relation/Program manager.
My concern is related more to obtaining the appropriate resource for
CMMI training and the actual audit. My understanding is CMMI was
written as a "guidance" document. I think with this particular company
needs professionals who embrace the more agile CMMI approach. Your
suggestions as to a firm who has this approach is greatly appreciated.
I am familiar with SCAMPI A, B and C assessments but would like to have
a dialogue about which method is best and your opinion on direct and
indirect artifacts needed for certification. I want to assist in
finding a good auditor and trainer for this organization.
I would also like to talk with you about obtaining certification to
become a CMMI auditor/trainer myself. I am very familiar with the
process areas/history/efficiencies of CMMI. Thanks!
Hillel Glazer
Thanks for writing!
I'm sorry it's taken me so long to reply, however, we're in the process of moving and our new location is without Internet access. This also means that my main PC is not yet online -- which is where I normally check this account from automatically.
Right now I am "scamming" bandwidth from a neighbor's unsecured wireless access point!
To continue the discussion, please contact me at my usual email address which Tim or Eric can get for you, or via my Web Site: www.entinex.com.
I will write to you from there.
Cheers!
-->> Hillel
--
Visit http://www.agilecmmi.com