Interesting and stimulating remarks, Randy. I think of CM as its own discipline, not as a
hodge-podge of folks who come and go with various skills, as in a CMM Level 1
organization. If your goal is to think of CM as a CMM Level 2 operation, some of these
question clear up right away: it makes just as much sense to plan for role-based
competent, complex activities in CM itself as it does to rely on trained proffesionals in
software development generally. I agree that trained CM folk are scarce, but so are
I think we should be thinking of CM as a Production Management discipline in the context
of software engineering, not as a field which contributes quixotically, with unexpected
brilliance, relying on the individual genius of a small coven of geeks, (no matter how
charming it is to be a member of such a small group in a developing specialty ;o) ). There
are roles for people in all the quantum states of your competence spectrum, and indeed,
I'd argue that an organization would do well to have the whole spectrum, with the
more-experienced strengthening their professional standing by training the less-experienced.
So I would say that CM Processes that fall apart like a house of cards when key people
leave is a signal of the failure of CMM Level 1 organizations. The cure is to achieve
Level 2, not to clamp expectations at that achievable by untrained staff. Use good Process
Improvement techniques, and role-based tasking rather than relying on individual
brilliance for day-to-day success. The brilliance should be put to work planning,
training, and Process Improvement, not saving the company's bacon every day.
> You're all making really good points. Let me try to add a little, if I may,
> to the decisions involved here.
> <jumping onto soapbox>
> Much of what we're describing here is highly dependent on the skill-sets of
> the people in the roles of Configuration Manager. The way I look at it, you
> have a spectrum that looks something like this:
> At one end: CM people being able to handle
> semantic analysis of code to sequence
> atomic changes associated with features.
> Somewhere in the middle: CM people help organize
> the repository, structure releases, but are not
> involved in looking at the code.
> At the other end: CM people essentially push the
> "check-in" and "freeze" buttons and inform other people
> that stuff is ready.
> You need to take a good hard look at your processes and the underlying
> methodologies involved in deploying your software products (yes, if you have
> CM involved, you're in a product mode, because evolution is implicit). Who
> runs the CM group? Is it product management (my feeling is that that's the
> most appropriate place, most often), development, quality assurance (that's
> also a good place, because that's often under product management also),
> quality control, operations, etc.? What skill sets do you require of your CM
> people to perform their roles to the expectations of your organization? Are
> you likely to be able to sustain the required skill sets should changes
> occur in your organizations (growth, reorganizations)?
> <General back-patting coming, beware :-) > It's fine and great when we're
> all able to effectively manage our changes because we are, or have been, or
> have close access to heroic developers, or really understand the process of
> building software. But, and it's a bit but, what happens when it's time to
> move on? Can the organization continue to maintain the processes and
> procedures we've created and executed so effectively, if we move onto
> something else?
> <jumping off soapbox>
> I've seen many companies set up CM infrastructures that worked for a while,
> and were highly dependent on specific individuals being in the jobs. When
> those people left, the whole CM process fell apart like a house of cards.
> We, in CM (Change Management, Configuration Management - take your pick), of
> all people, should be able to avoid doing this. It's our calling in life,
> isn't it?
> Just some thoughts.
> Hoping they help,