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.
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.
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.
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.
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:
4.2 The Necessities
In order to safely proceed with the change to the CM
tool, the following necessary items must exist.
5.0 The Adoption Strategy
A typical adoption strategy for changing over
to a new CM tool consists of five phases:
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.
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.
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.
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.
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.
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.
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:
And the list goes on.
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.
FIGURE 2. Adoption is a partnership.
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 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.
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:
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.
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.
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.
Copyright - Continuus
Software Corporation