Downloaded from http://www.continuus.com/developers/developersACEE.html
Telelogic AB

SearchMapContact UsHome PageAbout ContinuusCareersProductsServicesCustomers OnlyROIClient ListsPartnersEuropeNews

Adopting An Automated Configuration Management Solution

Susan A. Dart, President, Dart Technology Strategies, Inc.
Conference: STC'94 (Software Technology Center), 12 April, 1994, Utah


This paper describes the aspects of CM adoption and why adopting an automated CM solution tends to be more complex than expected. It presents all the elements of an automated CM solution and highlights a proven adoption strategy that has been implemented successfully at many large companies. Following that, a discussion indicates why companies generally need adoption services support from their tool vendor and how together, the customer and vendor address the adoption needs. The paper concludes by giving 16 key lessons learned from many adoption experiences that capture the essence of successful change to a new CM tool.

* 1.0 Introduction

* 2.0 Understanding Adoption

* 3.0 Why Adopting A CM Solution Tends To Be Complex

* 4.0 Elements Of An Automated CM Solution
4.1 The Preparation Work
4.2 The Necessities

* 5.0 The Adoption Strategy
5.1 Preparation and Planning Phase
5.2 Organizational Process Definition Phase
5.3 Pilot Projects Implementation Phase
5.4 Roll-out Phase
5.5 Process Improvement Phase

* 6.0 Why A Customer Needs Adoption Services

* 7.0 How A Vendor and Customer Support Adoption
7.1 The Adoption Team For the Vendor and For the Customer

* 8.0 Lessons Learned About Adoption Experiences

* 9.0 Conclusion

* 10.0 References

Go to beginning of article.


1.0 Introduction

Making a major change in a company, such as changing over to a new automated configuration management (CM) tool, is both a significant opportunity and a major responsibility. It is an opportunity since it enables a company to address its CM problems and do process improvement for better management over its data and its development and maintenance activities - this enables the company to leverage its business practices and strategies.

At the same time, changing over is a major responsibility because of its ramifications and the resources required to make the change. Many tricky technical, political, organizational, cultural, organizational, process-oriented, risk-related, and personnel issues need to be addressed in making the change and people need to be committed to the change.

Any change in a company is complex, especially when it concerns CM because CM affects a company's corporate data repository and all of its development, testing, quality assurance, and release management processes. The change needs to be well-managed. To be well-managed means an adoption strategy is implemented to ensure successful, effective and optimal use of the CM tool.

But an adoption strategy in itself is not enough to ensure successful adoption - an understanding of all the ramifications and dependencies of the change is needed along with the proper in-house adoption support. This means that risk management becomes a major part of the adoption effort and that an Adoption Team is set up. An Adoption Team, made up of key members of the user groups and/or the CM team, ensures that the adoption strategy is properly enabled and risk management is addressed.

This paper describes the aspects of CM adoption and why adopting an automated CM solution tends to be more complex than expected. It presents all the elements of an automated CM solution and highlights a proven adoption strategy that has been implemented successfully at many large companies. Following that, a discussion indicates why companies generally need adoption services support from their tool vendor and how together, the customer and vendor address the adoption needs. The paper concludes by giving 16 key lessons learned from many adoption experiences that capture the essence of successful change to a new CM tool.

Return to Table of Contents.


2.0 Understanding Adoption

The term "adoption" refers to implementing technology transition, i.e., doing all the work necessary to ensure successful, optimal and effective use of the CM tool. Its scope is broad as given below and it encompasses all aspects of making the change to the new tool. At the end of adoption, the tool will be in routine use on the specified projects; it will be part of standard practice. To do adoption involves some serious, full-time work, as indicated in the subsequent sections of this paper.

There are books and papers that discuss technology transition in general such as references 1 through 10. This paper brings together the many elements of the CM solution. Based on these elements, a cohesive approach to making a change to a new CM tool is presented. This approach is based on many adoption experiences by Continuus in large companies.

In itself, adoption is not "rocket science". Yet, most companies do not succeed in transitioning to a new CM tool. The main reasons for not succeeding can be traced back to not doing adoption or to not understanding the many facets of adoption. Rarely is the tool itself the sole reason that it was not successfully used in a company - most companies do a thorough evaluation of a tool which determines, to a high degree of confidence, that it suits the minimum capabilities for the company.

In theory, adoption is straightforward. In practice, it is difficult because it brings together all the complexities that companies face in making a change - a change that has wide-ranging ramifications in the company. The complexities fall into the following categories:

Return to Beginning of Chapter. || Return to Table of Contents.


3.0 Why Adopting A CM Solution Tends To Be Complex

Most companies these days are seeking a new CM tool since they have reached a pain level with their existing CM solution that is unacceptable. This solution, or lack thereof, is affecting the quality of their products and hindering them from easily expanding their product line. Companies want a new tool that will greatly improve their existing way of doing business. They do a thorough evaluation of the CM products that exist and then choose one. In most instances, a company has a large list of requirements for the CM tool.

Typical kinds of requirements are identified in several papers such as those given in references 11 through 15. There are many requirements for CM tools and they span the spectrum from version control of any kind of object, build support, configuration item management, team support for parallel development, integration with third-party tools, change management, query capabilities, metrics capture, and customizable process enactment. To automate these capabilities requires a sophisticated CM tool that focuses on a complete CM solution, rather than on a partial one.

There are other factors, apart from the capabilities of the CM tool, that add complexity to the CM solution. These factors end up being the major risks that companies face and these impact the ease of changing over to the CM tool. They include:

Return to Beginning of Chapter. || Return to Table of Contents.


4.0 Elements Of An Automated CM Solution

The key elements involved in addressing a CM solution are shown in Figure 1. The elements outside the circle indicate the kind of preparatory and planning work that needs to be addressed. Inside the circle, are elements that are the products of doing that work and are mandatory in order to begin the change over to the new tool.

FIGURE 1. Elements of a configuration management solution.

4.1 The Preparation Work

As part of doing the necessary preparation and planning for adopting a CM solution, many issues need to be addressed. A brief description is given of each. They are:

Process: understanding the current CM processes, policies and procedures and defining new improved processes for automation.

Culture: recognizing the kind of culture that exists and how best to invoke change in such.

Roles: clarifying and supporting the various user roles and their responsibilities so that these can be automated; the roles include developers, testers, documenters, QA people, build managers and planners, release managers, CM manager, and project managers.

Risk Management: identifying risks that affect the adoption effort and defining strategies to eliminate, reduce or resolve them as early as possible.

Environment: understanding the working environment which includes the network architecture, the host development and target build platforms, the tool sets, and the operating systems; the CM tool will need to be compatible with these and work efficiently in this environment.

Application: choosing what objects will be put under CM and where they will reside; this includes source code, executable images, tools, command scripts, documentation, tests, and project management information.

Requirements: defining the CM functionality that needs to be supported; this generally involves a combination of manual and automated capabilities.

Management: making brave decisions about what resources to apply to the change, ways of altering the schedule, when to cut-over the project groups to the new CM tool, who to assign to do the adoption work, and how to resolve risks.

Planning: making sure that all the above issues are addressed with appropriate plans developed, implemented, monitored and measured.

4.2 The Necessities

In order to safely proceed with the change to the CM tool, the following necessary items must exist.

The Adoption Plan: this plan is the defining document for the change over to the tool; it includes details about the adoption strategy, the key people involved and affected by the change, the master schedule for roll-out of the tool, training and support issues, network and hardware capacity planning, list of risks and success criteria, and lessons learned for process improvement activities.

The Adoption Team: this team leads, guides, nurtures, monitors and implements the complete adoption strategy; it is the focal point for ensuring that all the elements of the CM solution are appropriately addressed and that the necessary preparation for each user is done before cutting over to the tool and that they will have any needed support in the early stages.

The Risk Management Plan: this plan describes in detail all the risks that potentially can impact the change over to the new tool; strategies for managing these risks and how they are implemented is detailed.

The Process Model: this is a description of the CM processes which includes the software flow throughout the company; it incorporates the development/maintenance phases, through the integration testing, system testing, QA testing, and release management phases.

The CM Tool: this is the automated capability that implements the CM process model and user requirements.

Return to Beginning of Chapter. || Return to Table of Contents.


5.0 The Adoption Strategy

A typical adoption strategy for changing over to a new CM tool consists of five phases:

  1. Preparation and Planning Phase
  2. Organizational Process Definition Phase
  3. Pilot Projects Implementation Phase
  4. Roll-out Phase
  5. Process Improvement Phase.
For each of the phases, the purpose of each is described below along with its key events. This five phase adoption strategy takes place after an evaluation of candidate tools has been done and a particular tool is chosen by the company. Some companies choose to mandate the tool as The Corporate CM Tool; others decide to have just one group, e.g., the CM group, cut over to the new tool - it really depends on the sophistication level of the tool, that is, how much automated and integrated functionality it actually implements.

5.1 Preparation and Planning Phase

The purpose of the Preparation and Planning Phase is to do the necessary preparation for the adoption activities; this is the most important phase and companies generally omit this phase which results in painful, long, and generally unsuccessful adoption of the new tool.

The key events in this phase are:

By the end of this phase, the Adoption Team has started its work, they have been trained on the tool and on adoption processes, the first version of the Adoption Plan is written and an adoption strategy is agreed upon, there is consensus between the vendor and the customer about each other's roles and responsibilities, there is total commitment from the levels of management, and a risk management plan exists.

5.2 Organizational Process Definition Phase

The purpose of the Organizational Process Definition Phase is to garner an understanding of the CM processes so that they can be automated as much as possible and to understand the role of the tool in relation to the CM processes.

The key events in this phase are:

Return to Beginning of Chapter. || Return to Table of Contents.

5.3 Pilot Projects Implementation Phase

The purpose of this phase is to implement the pilot projects in order to test out the process model and migration of the corporate data into the CM repository, to validate the functioning of the CM tool, to examine the learning curve for the various kinds of users, and, to prototype the risky issues.

Key events in this phase are:

5.4 Roll-out Phase

The purpose of this phase is to actually cut over each user group to the new tool. Typically, this is done in an incremental fashion since the right window of opportunity for cut-over in each group is different. If the right preparation has been done in the earlier phases, this phase becomes fairly easy and straightforward.

Key events in this phase are:

5.5 Process Improvement Phase

The purpose of this phase is learn lessons from the above adoption experience. This is needed so that the company can improve its processes and so that the company can leverage from all the benefits of having automated CM support.

The key events in this phase are:

At the end of this phase, the company is able to make process improvements and has retained the knowledge of how to do adoption, ways of tackling various risks, how to leverage from the benefits of having a productive CM solution, and has evaluated its success criteria that it originally developed for the whole adoption effort.

The company will continue to grow and the lessons learned will greatly benefit it as its business strategies and product lines evolve and as new people are hired.

Return to Beginning of Chapter. || Return to Table of Contents.


6.0 Why A Customer Needs Adoption Services

Buyers of a CM tool generally need adoption services because their company is afraid of change. Even though they know they need to improve, change is fearful. It is fearful because:

By seeking expert advice and support, the change can be made less fearful because of the support from the experts and learning from the vendor's adoption experiences. Very few, if any, vendors provide adoption services for their tools - this includes any CASE tool as well as CCM tools. Continuus is unique in its provision of adoption services for our CM customers.

The customer benefits from such services because the vendor knows the optimal way of implementing and using their tool and how to bring it into an organization. The vendor has a vested interest in making sure that the tool does not become "shelfware" i.e., sits on the shelf and is not used - the vendor wants to get repeat business from the customer and want successful customers as site references. With adoption services, the customers feel they are fully supported in making the change.

The vendor also wins by providing adoption services. This is because as part of guiding and nurturing the adoption process, expectations between the customer and vendor are firmly set which avoids potential misunderstandings. The vendor can now take a more pro-active approach in meeting the needs of the customer rather that just reacting to situations. Also, from all the experiences with the customers, the vendor can make many process improvements by building on its adoption expertise and finding optimal ways of doing adoption.

Return to Beginning of Chapter. || Return to Table of Contents.


7.0 How A Vendor and Customer Support Adoption

In providing adoption services, the relationship between vendor and customer has to become a partnership.
Figure 2 indicates the typical kinds of responsibilities between these parties.

The vendor can take responsibility for tool training, maintenance and support of the tool, customizations and integrations of the tool, and documenting and guiding the adoption effort.

The customer must take responsibility for management sponsorship, designating Adoption Team members, empowering them and enabling them to perform the adoption activities, developing and implementing resistance strategies, doing pilot projects to enable risk resolution, and testing and validating that the CM tool does exactly what it's supposed to do with all the data.

FIGURE 2. Adoption is a partnership.

Together the vendor and customer can develop collaborative training and educational seminars and the adoption strategy, and garner process descriptions and consensus on those, resolve risks, and implement customizations.

While a customer would ideally like the vendor to micro-manage the adoption effort, it is impossible for the vendor to do that since the vendor has no control over events at the customer's site; nor is the vendor at the site 100% of the time to see all events, and the vendor has very little power to directly cause change. This is why the customer's Adoption Team is crucial.

7.1 The Adoption Team For the Vendor and For the Customer

Both the customer and the vendor have Adoption Teams. The vendor's Adoption Team generally consists of an adoption expert who leads the adoption strategy and an implementation consultant who is an expert on the implementation details of the tool.

The purpose of the vendor's Adoption Team is to educate the customer about adoption, to analyze the customer's situation and recommend a suitable adoption strategy, document all the appropriate adoption documents, lead and guide the adoption activities for the customer and ensure that the vendor fulfils its responsibilities to the customer.

The purpose of the customer's Adoption Team is to be the focal point for carrying out the adoption effort. It is the team's responsibility to co-ordinate, prepare, lead, monitor, do, support and aggressively encourage the transition to the new CM tool. This team is crucial to the success in adopting the tool. Each member of the Team needs to be assigned the time and power to carry out the adoption activities.

The customer's Adoption Team generally consists of the following people:

The Leader and Champions generally devote their energies full-time to adoption - this optimizes the pace of change. The Sponsor mostly monitors progress of the Team and of the adoption effort and jumps in to assist when needed. User group representatives are generally not available full-time to participate in the adoption activities, but at a minimum, they need to be present at key meetings for the Adoption Team and should review all of the adoption documents.

In summary, the customer's Adoption Team and the vendor's Adoption Team need to work as a "closely knit" team to enable adoption.

Return to Beginning of Chapter. || Return to Table of Contents.


8.0 Lessons Learned About Adoption Experiences

Each adoption experience brings a wealth of lessons learned. The lessons range from ones concerning the adoption process itself, to ones about the CM tool, the company and the people. Those lessons listed below are indicative of each adoption effort. Some of the more important ones are:
  1. Adoption must be managed as a project - this means that all the elements of project management are needed along with resources in terms of time, money, and people.
  2. Schedules need to be adjusted to account for supporting adoption activities. Similarly, the reward system i.e., salaries, bonuses, etc. should enable people to focus on adoption activities.
  3. The customer's Adoption Team has the most crucial role and biggest responsibility for leading the change over to the new CM tool.
  4. For the customer's Adoption Team, competent, technically knowledgeable and well-respected people should be chosen to participate on the team; they must have the skill set to suit the adoption activities
  5. Consensus building, group conflict resolution and the ability to run productive meetings are vital skills for the customer's Adoption Team.
  6. Roles and responsibilities must be defined for the key players in the adoption effort.
  7. The definition of CM processes is vital to understanding how the new tool will function to meet the CM requirements.
  8. All levels of users and management must be educated about the tool and the adoption process.
  9. The pilot projects should be carefully selected so that they address the high risk topics as well as people, process, and data issues.
  10. A focal point during adoption must be on management sponsorship at all times, otherwise the whole effort could easily be cancelled.
  11. Resistance to change must be overcome creatively through means such as education, successes and involvement.
  12. Users need to be properly prepared when changing over to the new tool; this means that they have been trained, the right kinds of documentation exist, such as manuals for migration path, new methodology, new usage model, new processes, new policies, etc.; also, that any necessary data migration, customizations and integrations have been done.
  13. The timing of training is crucial - it should be done just before users cut over to the new tool, and any data migration to the tool should have already been done.
  14. Expectations and responsibilities between the vendor and the customer must be clearly agreed upon.
  15. Breadth of participation in all adoption activities by all affected users must be ensured in order to maintain the adoption momentum.
  16. The adoption strategy should be implemented in a timely fashion so that the enthusiasm for the change is maintained and users see the benefits of the change as soon as possible. There are many other lessons learned but these seem to be the most important these days given the maturity levels of large companies.

Return to Beginning of Chapter. || Return to Table of Contents.


9.0 Conclusion

Changing to a new CM tool is a major change, especially if the tool is a sophisticated one that automates all levels of CM. This is because CM addresses enterprise-wide data management and process management in the company. These topics are tricky ones in any company and have state-of-the-art solutions.

This paper presented an overview of all the elements in addressing an automated CM solution. It highlighted an adoption strategy based on experiences from a vendor (Continuus) at many large companies making the change to an automated CM tool. While an adoption strategy is necessary to initiate a change, it in itself is not enough to ensure a successful change. What is further needed is an understanding of why adopting a CM solution is complex and this entails understanding the risks confronting the company. The complexity issues and typical risks have been identified in this paper.

In order to make adoption as painfree as possible, the vital elements are the following:

  1. An Adoption Plan - this is the strategy and defining document that encompasses all issues regarding adoption and is the repository of success criteria and lessons learned
  2. An Adoption Team - this is an organizational team the leads, guides, supports and monitors the implementation of the adoption strategy
  3. A Risk Management Plan - this identifies all the risks and how they will be resolved
  4. A Process Model - this describes the CM process and hence, the role of the CM tool
  5. A good CM tool - this automates all the required CM functionality
  6. A good CM vendor - these people form a partnership with the Customer, have the expertise to implement a CM solution, and care about the Customer's solution.
The elements above are intended to make adoption as pain-free as possible. But behind these elements a well-functioning Adoption Team must exist and most importantly, strong management support at all levels for the change must be evident.

Any change involves risk but so does standing still and not changing. The high technology arena is constantly changing and at a fast rate. In order to remain competitive, to be productive and profitable, companies need to change but change in a manner that is planned, well-understood, monitored and supported at all levels.

Return to Beginning of Chapter. || Return to Table of Contents.


10.0 References

References 1 through 11 focus on technology transition in companies. The remaining references address to requirements for, and functionality in, CM tools.
  1. P.S. Alder and A. Shenhar "Adapting Your Technological Base: The Organizational Challenge", Sloan Management Review, 32(1), pp 25-37.
  2. B. Bochenski "Managing It All: Good Management Boosts C/S Success", Software Magazine Client/Server Computing Special Edition, Nov. 1993, p. 98.
  3. B. Bouldin, "Agents of Change: Managing the Introduction of Automated Tools", Englewood Cliffs, N.J., Yourdon Press.
  4. D. R. Conner and R. W. Patterson "Building Commitment to Organization Change", Training and Development Journal pp. 18-30, April 1982.
  5. R.G. Fichman and C. Kemerer "Adoption of Software Engineering Innovations: The Case of Object Orientation", Sloan Management Review, Winter 1993 pp. 7-22.
  6. P. Fowler and L. Levine "Foundations for Systematic Software Technology Transition", Software Engineering Institute Technical Review 1992, pp. 1-32.
  7. D. Leonard-Barton "Implementation as Mutual Adaptation of Technology and Organization", Research Policy 17(5), Oct. 1988, pp. 102-110.
  8. E. Roger "Diffusion of Innovations", The Free Press, New York, 1983.
  9. S. Bonsack, D. Hahn, P. Marion "An Experience in Introducing a New SCM Tool", Proceedings of the 4th SCM Workshop, May 1993. ACM SIGSOFT, IEEE Computer Society, pp.29-32.
  10. E. May "Rules of the Road for SCM", Proceedings of the 4th SCM Workshop, May 1993. ACM SIGSOFT, IEEE Computer Society, pp.182-184.
  11. M. Cagan and A. Wright, "Requirements for a Modern Software Configuration Management System", Continuus, January 1992, 17pp.
  12. S. Dart, "Concepts in CM Systems", Proceedings of Third International Conference on SCM, Trondheim Norway, June 12-14, 1991, 18pp.
  13. S. Dart, "Past, Present and Future of CM Systems", Proceedings of IFIP World Congress, Madrid, Spain, Sept. 1992. 8pp. Also printed as Technical Report Software Engineering Institute CMU/SEI-92-TR-8.
  14. P. Ingram, C. Burrows, and I. Wesley, "Configuration Management Tools: A Detailed Evaluation", Ovum Ltd, UK. 1993.
  15. D. Whitgift "SCM Methods and Tools", J. Wiley and Sons, England 1992.
Return to Table of Contents.



Copyright - Continuus Software Corporation About ContinuusCareersProductsServicesCustomers OnlyROIClient ListsPartnersEuropeNews
1