Task: Plan Adoption
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
RolesPrimary Performer: Additional Performers:
InputsMandatory:
  • None
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