Strategic Weakness: SCM Implementation Risks

This article will explore the common motivations behind SCM implementations, the likely weaknesses that will affect the implementation process, and some suggestions for addressing those weaknesses.

Why Implement SCM?

An SCM implementation costs a great deal of time and money. Why, then, would a company choose to implement SCM? Where do the ideas and the motivating forces come from?

SCM implementations are driven from five sources: Upper management, middle management, a client or customer, development organization, or some (external) third party.

SCM is sometimes implemented before, during, or after a crisis. An SCM crisis is some trouble or failure that directly relates to SCM, or which would have been prevented or ameliorated by SCM practices. For example, a customer reports that a bug fixed in an earlier release has reappeared in the latest release - costing the customer time, money, or performance.

SCM Implementation Scenarios

Combining the dimensions of originator and crisis gives the following matrix. I have labeled the boxes in the table with scenarios for SCM implementations, discussed below: 

Note: Mid-crisis origination is not applicable to low-level or third party sources. These sources usually lack the authority to respond directly in a crisis.

Note also that the crisis in question is not required to affect the current project or company - some organizations can learn from the mistakes of others. This is rare.

Strategic Objective

A strategic objective is essential to some corporate goal. Examples are a contract that explicitly contains an SCM requirement, or that requires the organization be certified CMM level 3 (which indirectly requires SCM). SCM may also be considered strategically essential if an ongoing implementation program or executive mandate affects the program.

Customers, upper, or middle management drive strategic objective scenarios. They usually occur independent of a crisis, but are sometimes initiated in mid-project because of a crisis elsewhere in the organization (see prophylaxis).

Unification

Unification scenarios happen when different levels of SCM implementation, or different SCM systems, are present in the organization and an effort to convert to a single SCM mechanism exists. This scenario sometimes also qualifies as a strategic objective, such as reducing the corporate-wide total cost of ownership for SCM.

Unification scenarios occur without a crisis, and are normally caused by upper management, or an external change agent, such as a software engineering process group (SEPG) or best practices council.

Crisis Response

An SCM failure has occurred. Typically, this involves an embarrassing loss of face high in the management hierarchy caused by the reappearance of a defect, the failure of an audit, or the inability to identify or reproduce a configuration. This scenario is typically accompanied by much wailing and gnashing of teeth, usually focused on "never letting this happen again!" Crisis response implementation scenarios are driven by customers, upper, or middle management.

Prophylaxis

A prophylactic SCM implementation is demanded to prevent what happened to project X after a crisis occurs. The original crisis may be within the same organization, or may have occurred at a previous employer of some manager. One crisis that I know of caused the manager to change employers. Ouch! Prophylaxis scenarios are driven by customers, upper management, and occasionally by external consultants. They occur after a crisis, although the crisis may have been elsewhere.

Best Practice

Best practice implementations occur because some authoritative voice. Either a veteran manager or an external agent identifies SCM as an industry-wide good idea. In this case, the reputation of the authority is the primary driver (as opposed to a strategic objective, which highlights the business case.

Before a crisis, middle management or external agents drive best practice implementations. After a crisis, especially a total process failure, third parties may recommend a bundle of several best practices, including SCM.

Key Learning

Key learning scenarios occur after a crisis has affected the project. Generally, if the crisis was dealt with internally, the overall impact was low, or if the crisis was resolved at a middle management level, a key learning can occur. High impact crises generally produce crisis response behavior. Middle management or external agents typically initiate key learning scenarios.

Grassroots Campaign

The bottom levels of the organization initiate grassroots scenarios. Normally, an experienced developer or line manager recognizes the need for SCM because of daily headaches or knowledge of industry best practices. An unsuccessful grassroots campaign is frequently a precursor to an SCM crisis. These scenarios usually occur without a crisis. 

SCM Scenario Risks

The following table summarizes the individual discussions below. Boxes are marked high if one or more risks for that scenario fall into the corresponding category (e.g., the risk "limited buy-in" falls into the "commitment" category, so any scenario with that risk will have "high" indicated under commitment).

Scenario Risk Levels by Category

Notes: (*) Indicates a category with multiple "High" risks. Empty boxes are "Low" risk categories.

Some scenarios may be converted to other scenarios. A best practice scenario, for example, will sometimes convert to a strategic objective. This is indicated in the text below. The usual conversions are shown in this diagram:

Scenario Risk Details

Each scenario is listed here in alphabetical order along with the risks or vulnerabilities that attend. Find the scenario that best describes your implementation to map out the minefield you face.

Best Practice Risks

Best practice implementations initially suffer from risks associated with the perception of SCM as an external concept. This creates the following risks:

·         Limited buy-in (at all levels)

·         Low priority in project plans

·         Management by influence

·         “Not invented here" resistance

·         Commitment to the scope of the implementation needed

·         Integration of SCM with existing systems

·         Budget or resource availability problems

·         Ownership issues

·         Correct analysis of SCM plan/procedures to be implemented

Obtaining buy-in from project middle management can mitigate risks 2 and 3. Buy-in to the full implementation, especially at the upper levels of management, will be the most dangerous risk.

Once middle or upper management support is found, it may be possible to convert the implementation scenario to strategic objective or prophylaxis. Doing so will mitigate risk 4.

Risks 5 through 9 derive from a thorough understanding of SCM and what it entails. Best practice implementations are particularly vulnerable to perceptions that SCM will be easy because it is simple. This misunderstanding can lead to underestimation when the implementation project is planned out.

Crisis Response Risks

A crisis response scenario is fraught with peril at all sides. These include, but are not limited to the following:

·         Budget or resource availability problems

·         Commitment to the scope of the implementation needed

·         Successful understanding of the nature and scope of the problem

·         Correct analysis of SCM plan/procedures to be implemented

·         Slapdash implementation

·         Falling victim to the silver bullet anti-pattern

·         Integration of SCM with existing systems

·         Schedule constraints

There is no right sequence to risk mitigation in this scenario; the risks are generally independent of each other. The best handling of this scenario is to perform the minimum amount of work possible, then convert to a different scenario such as prophylaxis or key learning.

Grassroots Campaign Risks

A grassroots campaign, like a crisis response, features a huge number of risks but less schedule pressure:

·         Top-tier support

·         Budget or resource availability problems

·         Ownership issues

·         Integration/Interoperability with existing systems

·         Vulnerability to the developer-driven SCM anti-pattern

·         Understanding the scope of the problem

·         Correct analysis of SCM plan/procedures to be implemented

·         Inadequate implement ratio

The primary vulnerabilities of this scenario boil down to buy-in at the top and SCM experience. Obtaining upper management support is the key to this entire chain of risks. The budget (2) and ownership (3) issues can be dealt with after support is obtained. Beyond these risks, the availability of experienced SCM personnel becomes crucial. Risks 4-8 depend on understanding of SCM issues.

Key Learning Risks

A key learning scenario is one that suffers from a few debilitating risks involving commitment to the key learning process from upper and middle management. If these risks are overcome, the key learning scenario will convert to a prophylaxis scenario.

·         Limited commitment to the key learning process

·         Low buy-in from upper management

·         Low priority in project planning

·         Management by influence

Risk 2 is the most important. In fact, support from upper management is critical in nearly all scenarios. It is not necessary to overcome risk 1 if risk 2 can be overcome directly. Once support is obtained, priority and authority should be forthcoming. At this point, the scenario becomes a prophylaxis scenario.

Prophylaxis Risks

A prophylaxis scenario stands a good chance of success, since the post-crisis nature can give everyone a motivating vision even if the crisis was not local. The risks in this scenario are mostly risks of commission rather than omission; doing things wrong instead of not doing them:

·         Successful understanding of the nature and scope of the problem

·         Falling victim to the silver bullet anti-pattern

·         Commitment to the scope of the implementation needed

·         Budget or resource availability problems

·         Ownership issues

·         Correct analysis of SCM plan/procedures to be implemented

·         Slapdash implementation

·         Integration of SCM with existing systems

·         Schedule constraints

Understanding and committing to the scope of the implementation needed (risks 1 and 3) are the keys to this puzzle. In most cases, having an experienced SCM advisor will help mitigate these risks.

Strategic Objective Risks

Strategic objective scenarios generally offer some of the best and worst possible circumstances. Because these scenarios have the attention of upper management, the level of involvement and support is generally high. However, some scenarios include the utter conviction that a small-scope, short schedule implementation is important. This will be disastrous if attempted. Overall risks include:

·         Low horizontal buy-in: support from only on manager

·         Short schedule fixation: MBO or this quarter scheduling

·         Low commitment: SCM is a stepping stone to another goal

·         Commitment to the scope of the implementation needed

·         Integration of SCM with existing systems

The risks here are not a series of risks so much as a menu. Depending on the particular details of the implementation, select the risks that apply.

In the case where, "We have to implement SCM so that we can get certified" or "So that we can go ahead and do this other thing," risks 1 and 3 are likely. In cases where "I've been given responsibility to get SCM going across the enterprise," risks 2 and 4 are likely. In almost all cases, top-level managers fail to understand the impact SCM systems have on other enterprise and development level systems. Risk 5 is possible in all cases. See my January article on solution selling for hints on "creating a vision".

Unification Risks

Unification scenarios are probably the worst possible scenarios in terms of conflict, resentment and resistance. Generally, groups that have successfully adopted another tool will be highly resentful of the need to convert from their existing, successful tool to the new one, while groups that have no tool generally have no motivation to use one now. The exception is those lucky few groups that have suffered an SCM crisis lately, and for which this qualifies as a best practice or prophylaxis implementation scenario.

Risks for unification scenarios include:

·         Low commitment from all involved parties

·         Resistance and/or partisanship from the development organization

·         Management by influence

·         Budget or resource availability problems

·         Ownership issues

·         Successful understanding of the nature and scope of the problem

·         Commitment to the scope of the implementation needed

·         Correct analysis of SCM plan/procedures to be implemented

·         Slapdash implementation

·         Integration of SCM with existing systems

·         Schedule constraints

·         Data migration efforts can become resource sinkholes

After encountering this scenario just once, I had all the experience I ever wanted to have. The especially unpleasant part of unification scenarios are that they break down into a whole series of smaller, more concentrated unification scenarios: one for each team or group in the enterprise. Think of it as an unhappy fractal, where each lower level contains the same quantity of misery as previous levels.

There are not very many good ways to get through this scenario. For groups that have no SCM system in place, the best thing is a crisis that lets you switch from the previous scenario to a mid-crisis or post-crisis scenario. For teams with an existing SCM system, addressing risk 1 is the key to overcoming risk 2.

The only way to deal with the resistance, and in some cases outright sabotage, from below is with a great deal of middle and upper management support. Because of the high impact to the enterprise, unification scenarios are sometimes also qualified as strategic objectives. If this can be arranged, it can help increase the level of commitment at the upper and middle management levels.

Risks 4 and 12 are pretty much in direct opposition to each other. If you are fortunate, you can set the implementation parameters in such a way that your data migration takes the minimum possible amount of data to the new systems, and leaves your legacy system in place for a year or two for reference purposes. Sadly, this means leaving hope for a rollback in the minds of the heavy resisters, which doesn't help risk 2.

Risks 6 through 10 are all focused on the understanding of the actual SCM domain, and how it should work across the enterprise. Happily, solving this problem once is usually sufficient: recall that the objective is for all groups to use the same system.

Conclusion

You will notice that the same risks are repeated over and over throughout the scenarios. There are some risks that are truly unique to a particular scenario, but most are repeated. One of the nice implications of this is that implementing SCM is a repeatable process. It is possible to become an expert by doing implementations repeatedly.

SCM vendors make a deliberate effort to provide this expertise in the form of their professional services departments. There are third party specialists out there (disclaimer: I am one) who provide this expertise as well. Don't be afraid to ask for help from online resource like CM Crossroads or the CM Wiki, or from a specialist. Don't be afraid to budget for help. It's worth it.