EditAttachPrintable
r1 - 2013-05-07 - 21:54:01 - Main.jduckmantonYou are here: TWiki >  Deployment Web > DeploymentFieldGuidanceAndCustomerExperience > DeploymentAcceleratingAdoption

Accelerating adoption of software tools & practices

Authors: JohnDuckmanton
Build basis: CLM and SSE

Deploying a new software engineering process and /or tooling to a large user community are often both a significant technological challenge and an organizational change that requires an appropriate level of planning, resourcing, coordination, collaboration, and governance in order to be successful. In this paper, we look at some of the key factors that influence the rate of adoption and some measures that can be taken to accelerate the rate of change.

The rate of adoption

Figure One below shows a typical change curve for the adoption of new technology as the organization moves from its current productivity level of towards the desired target (shown as a blue line). Initially there is a dip in productivity as resources divert effort to implementing and adapting to new the tools and working practices (point A). Then gradually as the new practices are more widely adopted, and people become more proficient in the new tools productivity begins to trend towards the desired target levels (point B).


Figure One: Adoption change curve

Factors influencing the rate of adoption

Of course the level and duration of the initial productivity dip, the rate of adoption, and the extent to which productivity increases towards the desired level are influenced by a number of factors. These are shown in Figure Two below. These factors can have a significant positive impact on the rate of adoption, helping you to realize the expected benefits from the new solution earlier. Equally they can have a negative impact. Therefore, in planning any technology adoption they require careful consideration.


Figure Two: Factors influencing the rate of adoption

Delivered solution

These factors relate directly to the technical solution being adopted.

Solution complexity

The complexity of the solution to be adopted has a significant influence on the rate at which it can be embedded into the organization. Complexity has a number of dimensions. For example:

  • The number of new tools, practices (or both) to be adopted
  • The interdependency between elements of the solution
  • The amount of new knowledge to be communicated and absorbed.

Solution variability

Solution variability means how uniformly the solution can be applied throughout the target organization. There will generally be a number of variants of the solution, tailored to meet the particular needs of a particular stakeholder group. However, the higher the variability, the longer it will take to a) understand the variability, b) adapt the solution to take account of the variability and c) deploy and enable people on each variant.

Available skilled resources

A key factor influencing the rate of adoption is correctly resourcing the change initiative. Understanding the requirements and developing an optimal solution needs time & effort from domain, process and tool SMEs. Supporting the roll-out of the solution is critical. You will likely need a number of trainers and mentors who really understand the solution well, and are available to work directly with practitioners to mentor them and assist them to adopt the solution. It takes time & effort for these people to develop the new skills and capabilities required to be effective.

Training and enablement

It doesn’t matter how much more efficient and productive the new solution is – on paper, if the practitioners aren’t trained in the correct use of the solution, it will be a long time before those benefits are realized. Worse still, some practitioners may choose not use it at all and keep doing things the old way. It is important to build effective training, develop knowledgeable trainers and ensure that the practitioners receive the training and support that they need to be successful.

Feedback & adaptation rate

It is very difficult to define a solution that will be 100% effective from day one, or which will not require improvement whilst the solution is being deployed. Therefore it is vital that the deployment team is able to continuously gather feedback on the adopted solution and make changes as the solution is deployed further. Failure to do this will build up ‘technical debt’ that will need to be addressed later (perhaps when no more budget is available), and will also impact the adoption as practitioners may feel that the solution is not ‘fit-for-purpose’.

Target community

The target community is the end-users of the solution that must learn to use the new tools and practices effectively in order for any benefits to be achieved.

Size of the target community

Obviously the more practitioners the solution needs to be deployed to, the longer the adoption will take. The “It takes 9 months for a woman to have a baby… throwing another 9 women at the problem won’t make the baby happen any faster.” Adage applies, in that teams of practitioners can only absorb a certain amount of change.

Geographical distribution

Geographically dispersed teams will likely have a negative impact on the rate of adoption, since this places additional logistical and resource constraints on the adoption team. For example, your team may have to work across multiple locations and time zones, or need to be supplemented with local resources.

Organizational distribution

If you have teams from multiple organizations that all needs to adopt the solution, this may place a number of constraints on the adoption rate.

  • Commercial: You may be working with business partners or subcontractors, which may introduce additional commercial constraints.
  • Political: If you need to introduce the change into multiple organizations or business units.
  • Resources: You may need additional resources that will need to be trained.
  • Culture: You may have to overcome language or cultural barriers. ---++++!! Attitude to change

Clearly teams that are eager to adopt the new solution will do so more willingly than teams that are more reserved or reticent. Effective communication of the rationale and benefits is vital, as is listening to - and responding to - concerns and insecurities presented by the practitioners. There are a number of steps that you can take ensure a positive outcome. For example:

  • Choosing the right mix of people to be ‘champions’ or Subject Matter Experts
  • Choosing the right teams to be ‘early adopters’
  • Recognizing and rewarding participation and successful adoption.

Change impact

The following factors relate to the effectiveness of the change management approach used to embed the new solution.

Leadership effectiveness

Leadership is "organizing a group of people to achieve a common goal" (Locke et al, 1991). Change will happen more smoothly with effective leadership. When the vision, goals and benefits are effectively communicated and understood, and the adoption is correctly planned and managed, people will naturally align the work that they do towards achieving these goals. Achieving executive level support for the change initiative within the target organization is therefore critical.

Communication

Resistance to change often arises from uncertainly about the future. People will ask: how will the change affect me? Will I still have a job? How will my job change? When will the change happen? Why are we doing this? And so on. It is important that these questions are answered in order to achieve buy in from the practitioners.

Timing of change introduction

Obviously there is an imperative to adopt the new solution as quickly as possible in order to realize the benefits. However, there are often practical reasons that will dictate when (or even whether) it makes sense for the team to move to the new solution:

  • Projects nearing completion
  • Critical points in a team’s lifecycle (for example, a team that is just about to release a major new product)
  • Projects that will not benefit from using the new tools & practices.

Risk & impact of change

If the impact of the change and the risk of failure are small, then a team will, likely as not, be able to absorb the change without impacting their plans significantly. If however, the risk or impact is large, then the change will need to be assessed, planned in, budgeted for, and appropriately resourced. This will take more time to achieve.

Adoption best practices

When undertaking any large-scale adoption of new technology, be it new processes or working practices, new tools, or both there are a number of best practices that are essential to the success of the adoption:

1. Incremental adoption

An organization can only effectively support a given size of change effort. Also, practitioners can only cope with a certain level of change; beyond this level the productivity dip we discussed earlier becomes unacceptably large. To respond to this, a best practice is to introduce the new capability incrementally in a number of phases. When doing this it is important to consider a number of factors:

  • Carefully identifying the right capability to include in each increment, ensuring that practices and associated tooling are delivered together
  • The priority of each increment to the end-users
  • The implications of not having all the expected new capability at once. Often this may lead to temporary workarounds or duplication of effort. This needs careful communication in order not to impact on morale and expectations.

2. Establish a high-performing team

The most important factor in ensuring the success of the adoption is to establish a high-performing core team. Below are some of the attributes that should be present in members of the core team:

  • Effective leadership
  • Shared vision
  • Professional outlook
  • Highly skilled and knowledgeable
  • Open and collaborative
  • Enthusiastic
  • Good communicators
  • High level of trust

The article Establishing a software/systems engineering ecosystem center of excellence provides additional insight into the organization and establishment of a Center of Excellence.

3. Effective communications

Frequent, good quality communication to all the practitioners and stakeholders is essential. It is important to communicate:

  • Why the change is happening, and what the benefits are
  • An initial roadmap of the change journey
  • How the change will impact individual practitioners
  • How the change will be managed.

4. Establish a knowledge base

Providing a knowledge base helps practitioners to help themselves, and to learn from the experiences of others, speeding up the adoption rate, and reducing the support burden on the adoption teams.

  • Process Information
  • Tool Feature Guides
  • Training Materials
  • Hints & Tips
  • Frequently Asked Questions (FAQs)
  • Forums
  • Support and Help Contacts

5. Provide effective technical support

Introducing a major technological change will always encounter problems and issues. It is important to ensure that a mechanism exists to address these issues quickly and that practitioners know:

  • How to get help when the solution isn’t working (for example the tool isn’t correctly configured). For example, clear helpdesk procedures
  • How to get help to understand how to use the solution effectively in a given situation.

6. Effective change management

The new solution will need to continually evolve as it matures and as the needs of the business change. A robust and effective change management process is needed to facilitate this change.

  • If the new practice, process or tools are not working as effectively as they should, what is the change management process
  • How to raise new ideas for improvement.

Summary

This paper has examined some of the factors that can influence initial deployment and ongoing adoption of new software tooling and working practices, and suggested six best practices to help ensure the success of the adoption.

Related topics:
Implementation planning and deployment roadmap
Establishing a software/systems engineering ecosystem center of excellence

External links:

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r6 | r4 < r3 < r2 < r1 | More topic actions...
 
This site is powered by the TWiki collaboration platformCopyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.