The same can be said when approaching a CM implementation. While it can be argued that if you miss the approach of a CM implementation by 1%, that no one will be hurt. This is generally true 99.9% of the time. However, there are cases that if SCM is not approached correctly, then poor configuration identification or an unidentified change may cause:

• A pacemaker for the heart to work incorrectly that could lead to serious implications.
• An air traffic control system to miss a plane or two that could lead to tragic consequences.

Also, like unnecessary circling, when there are limited CM resources, expending effort needlessly can lead to an exhausted and frustrated CM staff. Therefore determining a good CM approach can reduce wasted effort and ensure focus on the appropriate tasks. Now that I hope to have your attention, let us ‘land' to earth and discuss what we can do as CM professional to improve our chances of effective CM.

In the CM professional's everyday life, we are continuously wrestling with where to best place our resources and where to apply the most CM rigor. Typically this is due to the fact that we are resource-strapped, but still believe it is important to provide as appropriate a level of CM rigor that is possible. Or we are in the process of maturing CM within the organization and ergo establishing the need of more comprehensive CM to our management. With this in mind, it is important to consider the way CM is approached so that resources are best applied. In considering an approach, it is important to analyze the task or implementation ahead of us. The outcome of the analysis may help you establish a CM approach. The analysis focuses on the following areas:

• Target Level - this involves identifying the target audience of a CM Implementation or task and then preparing an implementation plan to that level. Target levels include the organization, application, or project.
• Application Criticality and Risk - this involves determining the criticality of the application being developed relative to what it is used for and the ramifications of the application not operating as expected. The higher the criticality, the more the CM rigor is needed.
• Development Methodology - this involves reviewing the high-level categories of development methodologies and determining if they have an impact on how and when CM should be applied.

Let us expand on these items more fully below.

Target level refers to the level within a workplace in which CM may be implemented and performed. Generally, the 3 levels include the: organization level, the application level, and the project level. It is important to determine the target level before beginning a CM implementation effort since it will improve your chances of successful implementation and deployment. To identify the target levels, consider the following:

• Identify the life of the output of the task/implementation, a.k.a., deliverable(s). Or consider what the task is focused on. Ways to identify this are:
• Is the deliverable expected to live the duration of an organization or an application?
• Is the task focused on a project release, an application, or organization?
• With the results of the bullet item above, who in the organization level, application level, or project level is the primary beneficiary of the task or deliverable and who may help the SCM professional best ensure adoption of the deliverable or completion of the task?

For example, let us say the CM implementation involves establishing a CM Policy. First, identify if the CM Policy is to live throughout the life of the organization, an application, or a project. Then identify whom the CM professional needs to work with to get this accomplished. If the CM Policy is only for an application, then the CM professional should work with the owner of application (a.k.a., Product Manager), then the CM implementation should be conducted at the application or product level. However, if the CM policy needs to live the duration of an organization, then the CM professional needs to work with senior management to ensure adoption of the CM Policy within the entire organization.

Below is a summary of when you might target the organization, application, and project ‘levels' based on the life or usage of the deliverable and primary beneficiary.

The identification of the target-level will help maximize the time spent on the task and increase the chances of success. This should be one area of focus when approaching a CM implementation.

Will the criticality of the application under development play a role in the CM rigor being applied? I suggest that it may. While, IMHO, all applications should have a standard level of CM rigor, the level of CM rigor applied will vary depending on the risk of the application, the level of maturity of the organization, and the resources available. Aren't we usually short of resources?. And a way to collect this information is to perform a type of risk assessment.

The risk assessment approach may be used to determine the criticality of the application being developed relative to the usage of the product and the ramifications of the product not operating as expected. This will help you consider the rigor of the CM processes and technologies needed (high risk then high CM rigor).

A key question to ask is, "What is the ramification if the most important function of the application does not function as expected?" This includes identifying the more important functions, or features, of your application and then identifying the worse case scenario if this function were to work improperly.

Let us consider some examples:

• If a word processor application does not function as expected, what is the worse case scenario to the users? Quite possibly, you could lose your file. The worse case scenario from this may be a loss of productivity.
• If an online trading application does not function as expected, what is the worse case scenario to the users? Quite possibly a significant trade for stocks or mutual funds does not occur. The worse-case scenario from this may that the company that owned the stock or mutual fund lost an opportunity to have a significant purchase, the person who made the trade losses a potential gain, and the person who made the trade could sue the company that owns the online trading system.
• If a heart pacemaker application does not function as expected, what is the worse case scenario to the users? Quite possibly the user can die. This is the worse case scenario, and there are a number of applications, comprised of both software and hardware, that have life-threatening ramifications, particularly in the medical/biotech and aeronautic/aerospace fields.

With this in mind, it is important to assess the risk of the application(s) in question because this may help you (and ergo your management) decide on the level of CM rigor applied on the application and their respective projects (e.g., just version control or version control and change control, or version control, change control, and audit, etc.). Hopefully, if a potentially critical application is being developed, industry standards are also applied for added rigor, as appropriate.

Below is an example table to illustrate the application criticality as it relates to the usage and the ramifications of the application not operating as expected.

If risk assessment is performed, and one application is part of a critical system for the space shuttle and the other is the toothbrush that the space shuttle astronauts will use, which would you apply the most rigor if you have an allocation of resources that cannot fit over both of these applications? You can not say both. This way, when a CM professional has a certain amount of resources, they can most appropriately apply a level of CM rigor that is appropriate for the criticality of the application in question. This does not imply that no CM should occur on lower criticality applications, but that in most of our lives, we have to ultimately prioritize, and make trade-offs, when attempting to build and perform the CM practice.

Does the development methodology being used on a project have an impact on the CM implementation approach? Before we answer this, for awareness and consistency let us look at some of the high-level development methodology categories. Please understand that there is great debate on the definitions and applicability of each of these methods and this is just one perspective. They include:

• Waterfall - A methodology that describes linear/sequential development where the overall lifecycle is composed of several phases that lead to the delivery of one release. Each phase of development proceeds in a particular order and it is implied that once you have completed a phase, there is no turning back. While more commonly associated with larger projects, it has its basis in smaller linear incremental projects. An example of a waterfall method is Summit-D.
• Incremental - A methodology that focuses on developing a small manageable set of functionality and externally releasing it to the public upon completion. It can be associated with waterfall (short time span linear project), but is more commonly associated with iterative (see below). Examples of incremental methods may be evolutionary and RAD.
• Iterative - a methodology where the overall lifecycle is composed of several continuous iterations where a small set of functionality is developed per iteration and internally released for review and modification. Additional iterations are built upon prior iterations until the functionality is adequate for external release to the public. In modern iterative methods, the recommended length of one iteration is between one and six weeks. Sometimes, iterative and incremental are combined to be referred to as ‘iterative and incremental development (IID)'. Some examples of this method may be Agile, XP, Scrum, RUP, and Spiral.

In all of the above methodologies, it appears that identification and control are important. While I have seen it argued that some of the iterative methodologies such as Agile and XP do away with process control, the reality is that identification and control of requirements and control over design and coding changes is core to the fast-paced iterative nature.

It is with this in mind, that I advocate before any development project occurs, irrespective of the development methodology, that a CM system, including both tools and processes, is implemented. I have witnessed unknown requirements during the time of release, loss of code, and schedule slippage when an iterative, increment, or waterfall method is being used when no CM system is in place. I have seen this particularly from those who claimed to be following an iterative methodology like Scrum, Agile, or XP who think they can begin the project without any CM infrastructure. Effectively, it becomes almost impossible to manage change without a level of CM rigor that focuses on identification and control.

The question then becomes, are there specific areas of a CM system that should be focused on more than others per the methodology used on a development project? Let us examine this:

Using the waterfall methodology, consider having a change control infrastructure for processes and tools in place prior to the requirements gathering phase, and then have the version control infrastructure in place prior to the coding phase. You can take a phased approach at having elements of CM in place throughout the project lifecycle as and when they are needed.

Using the iterative or incremental methodology, due to the short development cycles and because coding occurs within weeks or days of the project being started, then consider having a change control infrastructure (processes and tools) and the version control infrastructure in place prior to the coding phase.

Ultimately, it is important to understand that a CM system or parts of a CM system, change control infrastructure and/or version control infrastructure, take time to establish and are an infrastructure-building project in-and-of-itself. Therefore, this infrastructure should be in place at the appropriate times irrespective of the development methodology. If you have a developer or project manager telling you that their methodology does not need CM, then they mostly likely do not understand the methodology in question.

Since most CM professionals have numerous challenges, considering the way you approach CM may be beneficial. As suggested, focusing on which target level CM should be implemented, understanding the critical nature of the application, and understanding the development methodology used may provide some insight in approaching CM. Consider the following key points:

• Identifying the target level helps you increase the chances for a successful implementation because you can identify the personnel (at the organization, application, or project level) that can be most helpful to the implementation and adoption of CM.
• Identifying the critical nature of an application by applying risk assessment helps you perform better resource management as it relates to applying CM rigor (more rigor to more critical applications).
• Identifying the development methodology helps you know when elements of CM needs to be in place and this can help you best apply CM resources during particular times.

As you wrestle with where to best place your resources and where to apply the most CM rigor, I hope that these areas may help in considering your CM approach.

• "Software Development: Iterative & Evolutionary", Jan 09, 2004, by Craig Larman. Provided courtesy of Addison Wesley Professional
• "Managing the development of large software systems", Proceedings from IEEE WESCON, IEEE Press & Proceedings of the Ninth International Conference on Software Engineering, IEEE Press, August 1970, by Winston W. Royce
• "Agile Change Management - from first principles to best practices", August 2003, by Brad Appleton, Steve Berczuk, Steve Konieczka -- http://www.cmcrossroads.com/newsletter/articles/agileaug03.html
• "The Spiral Model as a Tool for Evolutionary Acquisition", CrossTalk: The Journal of Defense Software Engineering, May 2001, by Dr. Barry Boehm, University of Southern California, Center for Software Engineering and Wilfred J. Hansen, Software Engineering Institute
• Many CM professionals who converse on "CM Crossroads" (http://www.cmcrossroads.com/ ) and "CMTalk" (part of CM Today - http://www.cmtoday.com/ ) who stimulate critical thinking.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment