We’re struggling with “tailoring” and “tailoring guidelines.” We think we understand the concepts, but we can’t seem to find the value. What are we missing?
[Note: Jeff addressed much of this in “Just the FAQs #06: What can we learn about process architecture from Justin Bieber?” It’s a terrific article, and if you haven’t watched the YouTube video that he included at the end, stop reading and watch it – it’s a hoot!]
PAT: I actively participate in many of the CMMI‐related Yahoo and LinkedIn forums. I’ve noticed that in many of the exchanges, participants tend to talk past, rather than to, one another, as illustrated in the following fictitious exchange:
A: Our lead appraiser said that we don’t have to perform some of the CMMI practices and we can still get our maturity level.
B: Well THAT’s not right – unless, of course, you are performing alternative practices instead.
A: Nope, he said we are not expected to have alternative practices in place either.
B: Your lead appraiser is dead wrong and should have his certification revoked!
This seemingly meaningful conversation goes back and forth for some time until…
A: Yeah, well, we are going for ML2 and he says that none of the ML3, ML4, or ML5 practices have to be performed – in fact, he won’t even be looking at them during our appraisal.
B: Oh, uh, well, never mind…
The point is that context is important!
Keeping that in mind, consider that “tailoring” can be performed at various levels of process decomposition, and you really have to understand the context in which tailoring is being discussed in order to have a meaningful dialogue. As I see it, there are four layers of tailoring:
First, there’s MEGA‐“T” tailoring – essentially, selecting a life cycle. Whether you are consciously aware of it or not, once you’ve chosen a given development life cycle, a whole lot of rituals associated with all of the other life cycles approved for use have just been tailored out. One could think of this as “tailoring with an ax.”
Next, there is CAPITAL‐“T”, or phase‐level tailoring. In very small projects, for example, the tailoring guidelines may allow the Requirements and Design phases to be combined into a single “Desirements” phase. Similarly, verification and validation activities might also be conducted in an integrated manner.
One could think of this as “tailoring with a knife.” Then there is small‐“t” tailoring – selecting among various methods within a given phase ‐ combining High Level Design and Low Level Design specs, for example, or selecting either formal inspection, desk‐check review, or buddy review for verifying a given document. This is probably what most people think about when they hear the word, “tailoring.” One might think of this as “tailoring with scissors.”
Finally, there is micro‐“t” tailoring – adjustments that are made much closer to the bottom of the food chain. For example, your formal inspection process may indicate that the work product to be inspected must be pre‐published at least 3.17 days in advance of the inspection meeting, thereby giving the participants adequate time to prepare. However, a tailoring guideline may indicate that the item can be pre‐published with less lead time provided each participant explicitly agrees that the truncated review period still provides them adequate preparation time. One might think of this as “tailoring with a needle.”
Until you establish the proper context for a given tailoring discussion, people may be doing a lot of talking, but very little communicating.
. . . . .
OK, now that I’ve (successfully?) argued that context is important to conduct a meaningful conversation about tailoring, let me set the context for what I see as one of the primary stumbling blocks with respect to deriving maximum value from the “tailoring guidelines” implemented by many/most organizations – the source of which is found in the last bit of the CMMI Glossary’s definition: “Tailoring guidelines describe what can and cannot be modified and identify components that are candidates for modification.”
Having conducted a ton of appraisals targeting ML3 or higher, I’ve noticed a couple of recurring themes when it comes to tailoring guidelines – both of which appear to align much too closely to this portion of the Glossary definition.
One of the recurring themes I see is sets of tailoring guidelines that indicate which process elements are mandatory, which are strongly encouraged, and which can be tailored out. These are clearly delineated by CMMI process area to ensure full credit is given to all GP3.1 practices when conducting an appraisal. This aligns much too closely with that bit in the Glossary that indicates “tailoring guidelines describe what can and cannot be modified.”
The other recurring theme I see is use of an Excel spreadsheet that lists every conceivable arrow in the organization’s process quiver. It includes every policy, life cycle description, process document, methodology, workflow, procedure, work instruction, guideline, template, form, checklist, metric, bathroom stall number, etc. that can be selected. The project manager is expected to meticulously mark those elements that the she intends to use. This theme aligns much too closely with that bit in the Glossary that indicates, “Tailoring guidelines… identify components that are candidates for modification.” Well, it’s more “inclusion” than “modification,” but the point still stands – explicit decisions are made regarding the project’s means of conducting its business – its “defined process.”
(Note: organizations having trouble conjuring up uses of formal decision making are likely to use DAR to make the tailoring decisions on each project – thereby bagging an appraisal twofer!)
Having a list of mandatory, suggested, and optional process elements provides some modest value, as does using the 1000+ row Excel checklist to make explicit project decisions regarding process element inclusion. But, like you, I believe there is more value to be had from the concept of tailoring.
Let me try to make the point by relying on everyone’s my favorite analogy – marathon running! Most long distance runners are concerned about the “Five H’s” – hills, heat, humidity, height (altitude), and head winds. Two of the five, hills and height, are attributes of the course and can be considered well in advance. The other three, heat, humidity, and head winds, are race day attributes – and, weather forecasts notwithstanding, you really won’t know what you’re up against until the day of the race.
Magazines like “Runner’s World” have lots of articles dedicated to such topics:
- Heat and How to Handle It
- Don’t Sweat Running in Humidity
- Running Against the Wind
These articles, written by very experienced marathoners, share secrets, hints, and tips about adjustments you may want to consider due to race‐day conditions. The author’s objective is to arm you with information based on their tried‐and‐true experience, but the decision to follow their advice or not is entirely up to you. After all, what works for them might not work for you.
So why not apply this same value‐added concept to process tailoring? In addition to following the standard script for establishing bland and boring tailoring guidelines (the one you know will pass the appraisal), why not write your own “articles” filled with tailoring guidance. Organizations that adopt such a “tips and hints” approach typically find it much more valuable than those that only follow the more mechanistic approaches above. Your project retrospectives, lesson learned sessions, or, my favorite, project post mortems (yet another project has died; let’s examine the corpse and see what we can find) will evolve from generating a repeatable list of what did and didn’t go well on the project, to lively discussions that also explore the question, “If we knew then what we know now, what might we have done differently?”
Like the “Runner’s World” articles, tailoring guidance is intended to provide experiential insight for future projects’ consideration. Codifying the secrets, hints, and tips of how to tailor project activities to overcome the inevitable hills, heat, humidity, height, and head winds will arm the next project team with advice that should make it easier for them to go the distance, and hopefully that’s the value that you were looking for.
Like this post? Please forward to your nearest engineering or software professional!
Like this post? Please forward to your nearest engineering or software professional!
© Copyright 2015: Process Assessment, Consulting & Training and Broadsword Solutions
“Just the FAQs” is written/edited by Pat O’Toole and Jeff Dalton. Please contact the authors at PACT.otoole@att.net and jeff@broadswordsolutions.com to suggest enhancements to their answers, or to provide an alternative response to the question posed. New questions are also welcomed!
No comments:
Post a Comment