More on REQM and Categories
Thanks for the comment to my previous entry on REQM and PA Categories, Narayan. My apologies for taking so long to respond. I’ve had a lot to do lately, so I haven’t been as diligent about following the blog as I should. Then there’s the problem that getting my ideas sorted out and written down takes a lot of effort. I'm responding in a new entry, rather than a comment, to take advantage of the increased editing capability I have in this mode.
Among other things, the points you've made show how difficult it can be to neatly categorize many CMMI components. REQM's SPs can be particularly difficult. Before going further, let me say that I agree with the coupling you’ve made between SP 1.1 and 1.2. It’s an important one, and I’ve been teaching people about it for years.
I lean toward Engineering for SP 1.1 for a couple of reasons. First, it’s the one REQM practice that I could see fitting smoothly into RD. It seems to me that the existing RD SP 3.5 could become 3.6, with REQM SP 1.1 sliding right into the vacated space. I don’t really think that would be a good idea. I’m only saying that it *could* fit there without being conspicuous. For this reason, if no other, considering it to be an Engineering SP seems arguable.
A second reason I like the Engineering connection better than Project Management is that the work described by the other five PAs in that category will be "wrong" if SP 1.1 isn’t covered somewhere in an organization’s development practices. The implications in RD, TS, PI, VER, and VAL should be obvious to anyone who has even a modicum of practical development experience. Bad things ripple through all of Engineering if developers and requirements providers understand requirements differently. Since the Engineering PAs describe a development organization’s core work—that around which everything else in the model revolves--the effects of confusion in Engineering ripple into every aspect of project work. This would, of course, include the work described by the Project Management PAs.
You stated in your comment, “Thus, if SP1.2 belongs to project management, so should SP1.1 also belong to project management!” I respectfully agree—and disagree. Among other things, the richness of model component interactions leaves me reluctant to be so definite when talking about their purpose, intent, placement, etc. It is for this reason that I make such frequent use of the subjunctive case in discussions of this sort.
As you point out, REQM SP 1.1 has a strong relationship with SP 1.2. The commitment of project personnel certainly won’t mean much if they're committing to the wrong thing (but what they've been told). But to what are project personnel committing? To project management concerns like schedule, budget, and resources? Yes, certainly--but secondarily. First and foremost, they commit to requirements, per the SP statement:
“Obtain commitment to the requirements from the project participants.” [emphasis added]
Then, as stated in the note attached to REQM SP 1.2:
“this specific practice ensures that project participants commit to the current, approved requirements and the resulting changes in project plans, activities, and work products.” [emphasis added]
So, SP 1.2 content indicates pretty clearly that commitment is both to requirements [primarily] and to project parameters [secondarily]. Based on this material, I could have argued its Engineering nature in my original entry, but it “feels” more like Project Management to me because of the “people” aspects of making commitments. It has very much the same feel as PP SP 3.3 [“Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.”] in that regard.
SP 1.1’s strongest and most immediate ties would seem to be to the other Engineering PAs. It is also linked to SP 1.2, as you stated. The Project Management links--particularly (and most directly) to PP--seem to be more indirect, through GP 2.2 in Engineering. The elaborations for all these PAs (except PI) state:
“This plan for performing the <PA Name> process can be part of (or referenced by) the project plan as described in the Project Planning process area.”
I don't know why PI’s elaboration is different, since the wording seems to fit it just as well as it does the other four PAs. In any event, the [re]planning expectation established by GP 2.2 in RD, TS, PI, VAL, and VER is a major contributor to PP’s activities and outcomes. If anything changes in Engineering, PP changes. Changes in PP cascade to the other Project Management PAs.
The line of thought I've laid out here is an across-the-boundaries way of looking at model content. In my experience, a thorough understanding of the intent, significance, and impact of most CMMI components is not possible if boundaries are not crossed. Because of their proximity, relationships between SPs within a single PA will be more obvious than those between SPs in different PAs, but “more obvious” doesn’t necessarily mean “more important” or “more useful.” REQM has a very rich set of relationships both inside and outside of Engineering, so alternatives for “out of the box” (or “out of the PA”) thinking and exploration abound.
It happens that this particular richness has led me to spend quite a bit of time discussing and working with REQM in the CMMI User Workshop (UW) I’ve developed and teach. I’d like to do that here, too, but addressing all those relationships in a blog entry would require more time than I can afford to spend. I can say, however, that REQM’s relationships both inside and outside of Engineering are explored in great detail, and workshop participants consistently express amazement at REQM’s far-reaching impact.
As I stated in my original entry, I believe I could successfully argue for assigning REQM to Project Management, Engineering, or Support. In fact, I've been pointing out the arguments supporting each placement for years, when teaching Intro, Intermediate, Instructor Training, and my own material. REQM’s assignment to Engineering has been fine with me. Putting it in Project Management, as has been done in ACQ and SVC (and probably DEV in V 1.3) is also OK. I'd be happy with Support. Its category assignment really doesn’t matter much to me, as long as its components remain in the model and continue to reside at ML 2.
The material in this comment does a fair amount of hair splitting, which is an inherently intellectual exercise. I hope, though, that exploring model relationships can provide practical value through more complete understanding of component interactions. I’m a fan of navel contemplation only if it results in a useful outcome.
Thanks again for an interesting and thought-provoking comment.