![]() | ||
![]() |
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.
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:
Since adoption covers a broad spectrum of issues, it needs to be properly and skillfully addressed. Adoption needs to be treated as a project. It requires resources in terms of time and people and it encompasses many activities that need to be done within a certain time frame. Section 4.0 and Section 5.0 give a feel for the activities and responsibilities in adopting a CM solution.
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:
While these issues are not directly CM tool ones, since they impact the CM tool and because there generally is no simple and instantaneous solution, these become risks for the adoption of the CM tool. As a result., risk management needs to be done in order to eliminate, resolve or reduce the effect of these.
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.
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.
The key events in this phase are:
The key events in this phase are:
Key events in this phase are:
Key events in this phase are:
The key events in this phase are:
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.
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.
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.
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.
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:
In summary, the customer's Adoption Team and the vendor's Adoption Team need to work as a "closely knit" team to enable adoption.
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:
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.