r6 - 2013-05-11 - 16:50:37 - StevenBeardYou are here: TWiki >  Deployment Web > DeploymentFieldGuidanceAndCustomerExperience > ImplementationPlanningAndDeploymentRoadmap

new.png Implementation planning and deployment roadmap

Authors: JohnDuckmanton
Build basis: CLM and SSE

Adopting new software or systems engineering tools and practices on a large scale is a significant technological and organizational challenge that requires an appropriate level of coordination, collaboration, and governance in order to be successful.

In this article we will take a look at four best practices to ensure successful deployment and user adoption:

  • Address all aspects of the solution
  • Build the right team
  • Deploy capabilities not tools
  • Tackle larger deployments incrementally

Address all aspects of the solution

Deploying software into the enterprise is more complicated than just provisioning hardware and installing your software on it. There are many aspects that need careful consideration and planning in order to ensure that the software works correctly, performs as expected, integrates effectively with other systems, supports your business processes, and that the users know how to use it effectively.

At IBM Rational we have developed a proven framework to help to address all aspects of deployment of new tools and/or working practices. This framework is called the IBM Rational Development Environment Architecture (DEA).

The DEA addresses:

  • The processes or working practices to be adopted or incorporated into the tools (method)
  • The tools to be deployed and their integrations to other systems
  • Enablement in methods and tools
  • The infrastructure required to support methods, tools and enablement
  • Organization (to use and support methods, tools, enablement and infrastructure)
  • The plan for adoption of the above elements

Across all of these areas are cross-cutting concerns such as the functionality to be provided and constraints placed on the solution such as capacity, performance, availability etc.


A key element of any development environment is the method that is followed, whether formally or informally, by practitioners. A method defines project roles, tasks, work products, and processes. It is also underpinned by guidelines, standards, templates, and examples that can be applied on a project.


Development tooling automates aspects of the method being followed. For example, we may use a tool for storing and managing requirements on the project, or use a tool for visually modeling our architectures and designs, or use particular tools for testing our software, and so on.


Enablement (training and mentoring) of practitioners in the use of the development environment contributes to its successful adoption. Therefore, an aspect of a development environment is the definition and creation of training and mentoring materials that can be applied. The enablement itself is focused on the use of the method and tools within the environment.


Method, tools, and enablement are supported by some infrastructure (hardware and software). For example, we may want to Web-enable the method, and then deploy it on the company intranet, which would require a Web server and some hardware on which to run it. Development tools are often run on practitioner workstations with an appropriate specification (in terms of CPU, memory, and disk). Training materials may be made available via several mechanisms, over and above classroom training -- for example, Web-based training that would require the presence of a Web server and associated hardware.


The right organization is critical to support the use of a development environment. This may include providing specialists in certain aspects of the environment (such as method experts, tool specialists, trainers, and mentors), personnel to administer and support the environment, and personnel to augment the existing set of skills available through the company Help Desk. In addition to the environment itself, which requires people, there is clearly a need to create (develop) the development environment, which also requires people (including the development environment architect).


Adoption addresses the process of putting all of the above elements in place in an organized way and ensuring that the benefits expected from the development environment are actually being achieved. This is more than simply acquiring the relevant hardware and software, installing and configuring the environment, and training and mentoring end users. Adoption is equally concerned with the migration of existing assets (such as work products residing in a now-legacy toolset) and the collection of measurements that allow the development environment to be assessed against desired results. It is important to recognize that this adoption represents a change in the organization and needs to be managed as such.

Cross-cutting elements

There are, of course, elements that cut across the areas described above, and they represent functionality, qualities, or constraints. The functionality provided by a development environment represents a particular software engineering discipline, such as testing. A quality represents a property exhibited by the development environment, such as the ability for the development environment to scale to support different numbers of concurrent users. A constraint represents a restriction on the options available for implementing the development environment, such as the need to accommodate a particular operating system.

For more information on the IBM Rational Development Environment refer to the paper The rise of the Development Environment Architect on IBM Developer Works.

Build the right team

Adopting new software or systems engineering tools and practices on a large scale is a significant technological and organizational challenge that requires an appropriate level of coordination, collaboration, and governance in order to be successful. It will also impact, directly and indirectly, a large number of people within the organization. Let’s examine some of the key user groups who will be instrumental in the success of the adoption effort:

Executive Sponsorship

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.

Solution Deployment Team

Key to the success of any large-scale deployment is the deployment team itself. Typically this will be comprised of personnel in the following roles:

  • Project Management – Personnel focused on planning & organization, day-to-day management, and status reporting for the deployment.

  • Solution Architecture – One or more personnel focused on defining the overall solution technical architecture and providing architectural governance during the deployment

  • Domain & Product Subject Matter Experts – personnel with specialist knowledge in one of more of the domains affected, for example Requirements Management, or specialists in particular aspects of the tooling solution. It is important to focus early on in the deployment in identifying and growing these skills early.

  • Trainers, Coaches and Mentors – Internal personnel or external consultants with the skills and experience required to build the expertise of the SMEs initially, and support training & mentoring activities during the adoption.

  • External Consultants – For example experts from the tool vendor organizations, management or process consultants.

IT Support Teams

A large-scale tools deployment will require on-going collaboration with a number of other IT Support Teams such as IT Infrastructure Support, Database Support, Network Support, Helpdesk Support, Application Support; for example, to procure and provision the required hardware and networking infrastructure to host the solution, and to provide appropriate support for that infrastructure throughout the deployment. It is important to understand the support required and engage with these groups as early as possible.


It is important to the success of the deployment to understand who all the stakeholders are and their needs and expectations. You must continually ensure that the stakeholder needs are being addressed and that they are kept informed of progress throughout the adoption.

For more information refer to the article Establishing a software/systems engineering ecosystem center of excellence.

Deploy capabilities not tools

Organizations adopting IBM Rational products are typically not just looking to install new tools, but are looking to them to provide one or more capabilities such as Requirements Management, Source Control, Performance Testing etc. Sometimes the organization may already have the capability and is looking to better tools or practices to help them to increase their effectiveness.

Many of the IBM Rational tools support more than one capability. Therefore it is important when deploying a new solution to understand what capabilities you are looking to deploy. Doing this will help you to keep focused on the short-term goals of the deployment, the scope of any tool configuration, the impact on any existing methods or practices, and the associated enablement needs. It will also help you to ensure that you deliver something of value to the stakeholders. Where you are deploying the solution to a large number of users, a capability-based deployment can also provide a means to organize incremental delivery of functionality in discrete manageable chucks (See below).

Tackle larger deployments incrementally

Deploying a new tooling solution can be a significant change effort within an organization. Therefore, you must bear in mind that an organization can only effectively support a given size of change effort. There are many underlying reasons for this but below are just a few:

  • The time lag between initial purchase and realization of the benefit may be too large leading to loss of management focus.

  • The disruptive impact of the transition to new tools and working practices will become too great and will impact on core business activities

  • The organization will have a limited capacity to enable and support new users

In addition, practitioners can only cope with a certain level of change; beyond this point productivity and enthusiasm levels begin to suffer significantly. To avoid 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 value and priority of each increment to the stakeholders

  • 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.

The diagram below illustrates a typical incremental deployment in a series of ‘waves’ each comprising a number of phases:

  1. Assessment & planning – where the activities to be performed in the current wave are identified and planned
  2. Solution build – the infrastructure is established, tools installed and configured and supporting materials such as training and mentoring materials created.
  3. Pilot and/or early adoption – the solution is trialed with a small number of users in order to validate the technical solution and the readiness of the deployment team and gain feedback.
  4. Large-scale deployment & embedding – the capability is gradually rolled-out to the entire user community

When planning your adoption roadmap, there are many factors that can influence the adoption approach and the pace of the adoption effort. These are summarized below:

It is important to consider each of these factors to determine if it applies to your adoption, what impact it may have, and the steps you can take to minimize that impact. For an analysis of these factors and some practical measures that can be taken to minimize them refer to the article Accelerating adoption of software tools & practices.

Related topics: None

External links:

Additional contributors: PeterEeles (Development Environment Architecture)

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r10 | r8 < r7 < r6 < r5 | More topic actions...
This site is powered by the TWiki collaboration platformCopyright © by the 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.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project