 |
Develop and validate an adoption strategy including goals, plans for deploying the improvements, and training and mentoring. |
Disciplines: Software Capability Improvement |
|
Purpose
The purpose of this task is to formulate the strategy for the adoption of process within an organization or
specific project.
|
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Main Description
Steps
Set or revise goals
Set goals for the process, people, and tools, describing where is it you want to be when the process implementation
project is complete. Gain agreement on a reasonable and achievable set of objectives for the adoption project.
This is important because:
-
Goals serve as important input when planning the process implementation.
-
Goals and the description of the organization's current state are used to motivate your sponsors, and to create
understanding and motivation among the people in the organization.
The result is a list of measurable goals, expressed so project members can comprehend and internalize them. These goals
serve as a vision for the organization's future state.
|
Identify adoption risks and constraints
Identify risks associated with implementing the process and tool improvements Listed below are several examples of
risks:
-
"The pilot project involves many technical risks."
-
"There are too many new things for the people to learn."
-
"It is not clear how tool A and tool B will work together."
-
"It is not clear how to use tool A in a distributed development organization."
Identify constraints:
-
What are the barriers to adoption?
-
What has hindered adoption efforts in the past?
|
Determine roll-out strategy
Decide when you what to launch the process and tool improvements to a wider audience of software development
projects. You may want to run one or two pilot projects before you launch to the entire organization. For more
information about alternative implementation approaches, see Guideline: Selecting a Capability Improvement Roll-Out Strategy.
Decide how to facilitate the launch of process and tools. There are a number of things you can do to facilitate
software development projects in implementing the process and tools, such as:
-
Developing ready-to-use templates and examples that all projects can use.
-
Developing training programs.
-
Developing process implementation guidelines that provide guidance to those people who will be responsible for
implementing both the process and tools.
-
Preparing mentors who will support the projects.
Decide whether you are going to develop an organization-wide development environment that each software
development project can use with the necessary adaptations.
In most situations, we recommend you wait until several software development projects have used the process and tools
before you take this step. At that point, it will be easier to identify those parts of the process and tools that are
reusable and those that will benefit from being owned, and maintained, by a separate organization.
If you decide to develop an organization-wide environment, you must initiate a project to develop the organization's
development environment.
If you decide to initiate a project that develops the organization-wide development environment, it must be made clear
that this project team will work very closely with the software development project teams. It must also be understood
that the team who develops the organization-wide development environment is a service organization measured by the
success of the software development projects it supports.
|
Plan process customization guidelines
You may need to develop user guidelines to help individual projects implement the processes and tools. These guidelines
contain advice and guidance on how to plan the implementation of process and tools in an individual software development
project based on its particular needs. |
Select pilot projects
Define a sequence of software development projects, or iterations. Decide whether to run any pilot projects. For each
software development project, define the goals you want to reach, what you want to achieve, what risks you want to
reduce, and what parts of the process and specifically which tools you want to implement.
See Guideline: Selecting Pilot Projects for requirements and considerations for
appropriate pilot projects.
|
Establish measurements
Adoption cannot be deemed successful without metrics in place to evaluate actual performance. These metrics should
consist of the following attributes:
-
Automated where possible and non-intrusive to work processes
-
Should contribute to evaluation of effectiveness
-
Should support business and technical objectives
-
Phased in over a period of time
Develop a Measurement Plan in order to plan how to monitor capability improvements with performance data. Define
the measurements strategy and plan to track delivery, capability attainment, and achievement of results and success
criteria of benefit to the organization.
Answer the question: "If we succeed, how will we know it?"
|
Plan mentoring
Experience shows that having a mentor help with implementing a process is a key success factor. Therefore, we recommend
that each software development project has a process mentor to help them start using the process. It is impossible
to give exact figures, but, as a general suggestion, we recommend you plan for at least a 50% full-time equivalence
during the first few of iterations in the project until the project comes up to speed.
The projects also need help setting up the tools, so plan to allocate resources for tool mentoring and tools support.
Mentoring works best when you have a mentor who reviews results, leads workshops (when needed), and answers questions.
Done well, mentoring can be a very efficient way to transfer knowledge. Ensure that mentors should be experienced
practitioners not purely process-focused.
The project needs both the resources and the budget for mentoring on the project. The occurrence of some mentoring
activities need to be planned, such as leading workshops. It's important that the process mentor understands the
significance of being a change driver and makes sure that the work progresses. It's also important that the mentor
becomes dispensable and that there is an end to it, therefore, the mentor needs to transfer both knowledge and
responsibilities to members of the project.
|
Identify training needs
Education is necessary for successful capability improvement adoption. People need to understand the new processes and
how to use the new tools. Study the current competency levels among the organization's people documented in Artifact: Development Organization Assessment.
Next, look at the parts of the process you plan to implement, and what tools will be introduced in each project.
Identify those areas where the organization's people need to raise their levels of competency and to what extent this
must be done.
Decide what training is needed for each project. A change of process and tools affects the entire organization,
therefore, in addition to mentoring we recommend you train people outside of the projects to give them an understanding
of what the change means.
There are several ways to educate people to support successful adoption:
-
Standard training courses to introduce the new process and tools
-
"Boot-camps" consisting of concentrated, hands-on training. Not many organizations can afford boot-camps. However,
they have proven to be efficient if there are many new elements to learn.
-
"Kick-start" workshops are an efficient way to get the people up-to-speed in a day when introducing a new
improvement. In this type of workshop, people work using their real project material and following the new parts of
the process using the new templates, guidelines, and tools. Typically, a process engineer and a tool specialist
would be responsible for this workshop. Do not spend a lot of time developing training material for a kick-start
workshop. The main purpose is to give hands-on experience with templates, guidelines, and tools. The kick-start
workshop is also a way to verify the process assets and tool configurations.
-
Lunch 'n Learn sessions for quick topics
|
Communicate goals and expectations
One common mistake in process and tool adoption is failing to communicate expectations clearly to the effected
stakeholders. Depending on your organizational culture, use whatever medium is appropriate to communicate the goals and
expectations to the stakeholders. This might be through briefing sessions, workshops, training sessions, presentations,
team meetings, teleconferences and so forth.
It is important to communicate and manage organizational changes introduced as part of the improvement program.
See Concept: Managing Organizational Change.
|
Prepare environment for deployment
-
Detail the specification for infrastructure support for the process and tool improvements.
-
Add learning tasks to the overall project plan.
-
Develop learning assets.
|
|
Key Considerations
The greatest threat to any change in an organization is peoples' attitudes towards the change. The following actions
may help prevent negative attitudes from forming among people in the organization:
-
Set realistic expectations. Do not oversell the new process or the new tools.
-
Involve key people in the change work. Let them be part of the pilot project and give them responsibility for parts
of the process.
-
Explain why the change is needed. What problems does the organization have that need to be solved? What changes in
technology require a new process and new tools?How will you benefit from using these new tools and process?
-
Inform all people in the organization about what is happening. For example, keep all departments informed about
what is going on. This information doesn't have to be in very great detail; the important thing is that they
receive some information.
-
Remember stakeholders such as customers or sponsors. For example, if you change from a more waterfall-like
development approach to an iterative development approach, the stakeholders must understand how an iterative
development project is managed and how progress is measured. In an iterative development project, for example, they
cannot expect a completely frozen design at an early milestone. They would also be affected when projects change
the way they capture requirements.
|
More Information
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|