Some key practices used to implement a new development environment, consisting of the Rational Unified Process together with tools, are:

• Assess the Project and the Organization
• Implement Process and Tools Incrementally
• Manage and Plan
• Use Mentors
• Distribute Process Ownership
• Think 'Return-On-Investment'
• Keep People Informed and Involved
• Educate People

Assess the Project and the Organization

Assess the current state of the project and the organization to better understand what parts of the environment you should improve. You will also better understand how to implement the environment. 

The following pages explain how to assess the state of a project and its surrounding organization:

• Role: Process Engineer
• Task: Tailor the Development Process for the Project
•  Work Product: Development Organization Assessment
•  Guideline: Assessment Workshop
•  Role: Tool Specialist

Implement Process and Tools Incrementally

Implement the environment, process, and tools incrementally so people on the projects won't be overwhelmed by many new factors all at once. By implementing the environment incrementally, it's possible to focus on a subset of the environment, which increases the probability of success. 

Introduce the environment one piece at a time. The result of the development organization assessment helps decide which parts of the process and which tools you should start to introduce. Normally, focus on those areas where the development organization has its biggest problems. 

Incrementally implementing the environment might mean that in a first, or inception, iteration, you focus on introducing the Requirements discipline together with the Requirements tools. In the second iteration, the focus is on introducing the Analysis & Design discipline together with its modeling tools. In subsequent iterations, more and more parts of the environment are introduced.

See Concept: Implementing a Process in a Project for details. 

Manage and Plan

Manage and plan the environment tasks just as you would with all other tasks in the software development project. 

Implementing a new process and new tools on a project is a complex task. Changing the way people work can jeopardize the success of a project. Experience shows that when compared to the development tasks, the environment tasks are sometimes overlooked by the project manager. 

The environment tasks must be managed and planned like all other tasks in a software development project. Therefore, it's important that the project manager has a good understanding of the new process and tools. Sometimes it's difficult for the project manager to allocate the necessary time to learn about both a new process and potentially several new tools. In that case, the project manager needs support from someone who knows both how to implement the environment and who has previously been involved in doing so. Even if the project manager has the right set of skills and experience, we recommend that you involve "environment-implementation expertise", as it greatly increases the chances for the project to succeed.

See the Project Managementdiscipline for details on how to manage and plan a software development project, including the environment tasks. Also see Concept: Implementing a Process in a Project. 

Use Mentors

Use mentors to introduce a new process in a project. Experience shows that using mentors is crucial if you want the implementation of a new process to succeed. If you don't have mentors, there's a clear risk that the people on the project will fall back into their old habits. The mentor acts as a driver of change. 

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. See Concept: Mentoring for more details on what a mentor is and what a mentor does.

Distribute Process Ownership

Distribute the ownership for the process among the people on the project because they're more likely to adopt and learn the new process faster. The resulting development case is better when the "real experts", those people on the project, develop it themselves. If you distribute the ownership for the process, it will also reduce the likelihood of the project becoming too heavily dependent on outside consultants. 

As soon as possible appoint people on the project to be responsible for each core process discipline. This person has primary responsibility for configuring that part of the process and the corresponding part of the development case. For example, being responsible for a core process discipline like requirements, means you're responsible for that part of the development case. Each person needs to be responsible for one or several core process disciplines, and is someone who knows the area well and who can mentor other developers.  

A process engineer acts as mentor to the people on the project who own the different parts of the process and assists them when they configure the process. 

Think 'Return-On-Investment'

Think 'return-on-investment' when you configure the process: focus on those things that will pay back more than the investment. 

Experience shows that some projects tend to spend too much time and resources developing extensive guidelines, an extensive development case, and additional process-related material. There are three major problems with this:

• People do not read extensive descriptions. 
• Doing everything right from the beginning is very difficult. It's better to do something less extensive, try it out, and then adjust it. 
• It removes the focus from mentoring. People with process knowledge need to have mentoring, not writing extensive descriptions, assigned as their primary task. 

When developing guidelines, you need to keep in mind the return-on-investment. Try to reuse existing guidelines. For example, a cost-efficient alternative to developing a complete use-case modeling guideline is to let a good example of an existing use-case description serve as the Use-Case Modeling Guidelines.  

In practice, you can't measure the investment and the pay-back, then compare the two. As a process engineer, the most important thing to always keep in mind is that whatever you do, it must have a substantial pay back for the developers.

Keep People Informed and Involved

Keep people informed about the new process and tools, and have them involved in the work because the greatest threat to any change in an organization is peoples' attitudes towards the change. Introducing a new process and tools in any organization means that people have to change the way they work. People have a natural resistance toward change. There's always the risk of falling into a negative spiral, where people's negative attitudes lead to poorer results which then lead to even more negative attitudes.

The following lists some actions you can take that 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. See Distribute Process Ownership.
• Explain why the change needs to be done. 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 can't expect a completely frozen design at an early milestone. They would also be affected when projects change the way they capture requirements. 

Educate People

Educate people about the new process and the new tools because they need to understand both the new process and how to use the new tools. 

There are several ways to educate people, including the following methods that have been used:

• Standard training courses
• "Boot-camps" consisting of one to five weeks of concentrated, hands-on training. Not many organizations can afford boot-camps, however, they have proven to be efficient if there are many new factors for the people in the project. 
• Mentoring works when you have a mentor who reviews results, leads workshops, and answers questions. Done well, mentoring can be a very efficient way to transfer knowledge.
• "Kick-start" workshops are an efficient way to get the people up-to-speed in a day when introducing a new part of the environment. In this type of workshop, people work using their real project material and following the new parts of the development case 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 using new sections of the development case together with templates, guidelines, and tools. The kick-start workshop is also a way to verify the development case, templates, guidelines, and tools.