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.

I've long felt that one could argue for REQM's assignment to Project Management, Engineering, or Support because of the diversity among its SP's:

  - SP 1.1 (Develop an understanding with the requirements providers on the meaning of the requirements.) seems to be closely related to--and might even be included in--RD.  This SP argues for the Engineering placement.

  - SP 1.2 (Obtain commitment to the requirements from the project participants.) seems to lean more toward Project Management.

  - SP 1.3 (Manage changes to the requirements as they evolve during the project.) clearly ties to CM, particularly to SG 2.

  - SP 1.4 (Maintain bidirectional traceability among the requirements and work products.) has an obvious Engineering flavor to it, but it also smacks of the same sort of administrative work that's provided by the ML 2 Support PAs.

  - SP 1.5 (Identify inconsistencies between the project plans and work products and the requirements.) leans pretty clearly in the Project Management direction for me, as with SP 1.2.

All the practices relate to requirements in some way, so for me it makes sense to put them in close proximity within a single PA.  The criticality of requirements as the root cause of many ML 1 problems further argues for some explicit, special attention.

REQM interacts significantly with many of the Project Management, Engineering, and Support PAs.  Addressing all of those interactions would require far too much time and space for discussion here, but they constitute one of the model threads that's well worth taking the time to investigate further on one's own.

Awareness of REQM's interaction with the work described by so many PAs can be of great help when implementing CMMI-based process improvement.

I've been teaching CMMI independently and as an SEI visiting scientist for a lot of years now, chalking up some 250 officially sanctioned CMMI training courses along the way.  All told, I've taught a few thousand participants, ranging from beginners to old hands.  See my bio if you'd like to check out my background and experience for credibility purposes.

Quite a few people--including those who have quite a bit of CMMI background and experience--have told me that I provide insights into model content and implementation that they haven't heard from anyone else.  They’ve also said that I explain things in a more understandable way than they've encountered elsewhere.

I've frequently been asked to put what I know into writing, most recently by people who have attended the five-day CMMI® User Workshop I've developed and offer through my company (without SEI endorsement).  Setting up a blog seems like a good way to start, though I must confess that I'm new to the blog scene.

So, welcome to my blog.  I hope you'll find material here that will be instructive and useful.