Concepts: Implementing a Process in an Organization

Topics

• Introduction
• The Effect of Implementing a Process
• A Step-by-Step Procedure to Implement Process
• Process Implementation Approaches
• Treating Process Implementation as a Project

Introduction

In many circumstances, the Rational Unified Process can be used in whole or in part directly "out-of-the-box." However, the process may be configured to better fit the needs of a given organization.

Configuring the Rational Unified Process means adapting and modifying the process product to the needs and constraints of the adopting organization.

Implementing the Rational Unified Process in a software-development organization means changing the organization’s practice so it routinely and successfully uses the Rational Unified Process in part or in whole.

The result of configuring the Rational Unified Process is captured in a development case. The development case can be a web site with hyperlinks to the relevant sections of the Rational Unified Process online.

To implement a new development process and supporting tools in a software-development organization is a long-term task, that could span over several software-development projects. In some cases, a development organization could be of a size large enough to have an internal organization to develop, implement and maintain the process and tools to support all projects in the development organization.

The Effect of Implementing a Process

Process changes are difficult and it may take a long time to see their true effects. It is relatively easy and fast to adopt a new tool: install it, read the users’ guide, go through an example, and maybe attend a training course. The transition can last from a few hours to a couple of weeks. However, changing the software-development process often means affecting the fundamental beliefs and values of the individuals involved, changing the way they perceive their work, and how they perceive its value. It is a cultural change, and almost political or philosophical in nature.

A process change affects the individuals and the organization more deeply than changing technology or tools. It must be carefully planned and managed. The adopting organization must identify the opportunity and the benefits, convey them clearly to the interested parties, raise their level of awareness, and then gradually change from the current practice to a new practice. Ivar Jacobson describes this as "reengineering your software engineering process".

The following areas must be addressed when implementing a process:

• The people, their competence, skills, motivation, and attitude. Everyone needs to be adequately trained and motivated.
• The supporting tools. New tools will inevitably replace old ones, and will require customization and integration with the others.
• The software-development lifecycle model, its dependent organizational structure, underlying activities and practices together with the artifacts that are produced.
• The actual description of the software-development process.

There are other areas, in addition to the ones above, which affect the way people work. For example, the physical working environment, organizational culture, organizational politics, and the reward structure. Some if these will be touched upon, but not dealt with in detail here.

In addition to people inside the affected software-development organization, you must take into consideration the people outside that organization:

• Managers, who are responsible for the performance of the software-development organization. They must understand why the process is being changed, and why new tools are being procured. It is important that they understand how (and if) progress is being made. Any process improvement project must have executive support. Management needs to understand that there is a return on the investment being made in changing the process, and also that expectations need to be carefully managed.
• Customers may need to be informed that the organizational process has changed as it could effect how they and when their input will be addressed.
• Other parts of the software-development organization. Sometimes changes in one part of the organization may lead to resistance and skepticism from other parts of the organization. The reason is often that the other parts do not understand the reasons for the changes. Even if they do not have a direct influence, this may cause political problems.

Involve people

To succeed with the process-implementation project, it is important to involve people in the process-implementation effort as early as possible. They are an important source of information when assessing the current state of the software-development organization. Secondly, everyone needs to understand the current state of the organization, and to understanding its problems and how and where it could be improved. Building up this understanding is one of the keys to success for any "change project."

Start early and let the entire organization know what is going on. There is always a potential risk that people outside the affected part of the organization do not support the effort. One way of reducing this risk is to keep them informed. This is important and enough time needs to be allocated for it.

The right people need to participate in the first part of the change project, as they will be the ones that will pass the message on to the rest of the organization. Choose people that have good communication skills and influence in the organization. Some of these people will play important roles as mentors when the process is implemented in the rest of the organization. 

A Step-by-Step Procedure to Implement Process

Implementing a new process in a software-development organization can be described in six steps.

The steps to implement a new software-development process.

Step 1: Assess the current state

You need to understand the current state of the software-development organization in terms of its people, process, and supporting tools. You should also identify problems and potential areas for improvement, as well as collect information on outside issues such as competitors, and trends in the market. When this step is complete, you should know:

• What is the current state of the software-development organization.
• What kind of people there are, their level of competence, skills, and motivation.
• What tools are currently used in the organization.
• What is the current software-engineering process, and how it is described.

The reasons for assessing the current state is because you want to:

• Use it as to create a plan for getting from the current state of the organization to your goal.
• Identify which areas need to be improved first. You may not want to introduce the entire process and all of the tools at once. Instead, you may want to do it in increments, starting with the areas which have the greatest need and the best potential for improvement.
• Explain to the sponsors why you need to change process, tools, and people.
• Create motivation and a common understanding among the people in the organization that are directly or indirectly affected.

Step 2: Set (or revise) goals

The second step is to set up goals for the process, people and tools, noting where you want to be when the process implementation project is complete. The reasons why you need to set up goals is that

• Goals serve as an important input when planning the implementation of the process.
• Goals combined with the result of step 1 (a description of the current state), will be used to motivate the sponsors and to create an understanding and motivation among the people in the organization.

The result should be a list of measurable goals, expressed so that they can be comprehended and internalized by project members. The goals can serve as a vision of the future state for the organization.

Step 3: Identify risks

To succeed in implementing a new process, you need to control the many different risks involved. We recommend that you perform a risk analysis, where you identify potential risks, try to understand their impact, and then rank them. You should also plan when you will mitigate the risks and in what order.

Switching from a linear process to an iterative process is not a risk-free undertaking. Software development organization using an iterative approach for the first time may fall into several traps, such as:

• The first iteration is too ambitious, unable to focus only on the most important risks.
• Not completing the iterations, thinking you have mitigated a risk without having tested what you built.
• Not all stakeholders buying into or understanding the iterative approach, and expecting progress of the project as if it were waterfall.
• Planning feature by feature instead of planning the complete project from the start (at a high level) and being prepared to change the plan along the way.
• Too much rework between the iterations, meaning that you do things in an earlier iteration that you will have to redo later.
• Uncontrolled requirements changes, thinking that it does not matter much if they change since there are several iterations to fix this.

Other process-related risks:

• Too much training too early, which means it will take more time before you start produce real work and also you may forget what you learnt once you actually need it
• Staffing up the project too quickly, with too many people involved in the inception phase, makes it difficult for the group to understand responsibilities and runs the risk of leaving some people without tasks.
• Insufficient tool support, or inadequate skills to properly use them.
• Producing unnecessary artifacts, by not evaluating whether or not they add true value.

Step 4: Plan process implementation 

Develop a plan for implementing the process and the tools in the organization. This plan should describe how to efficiently move from the current state of the organization to the goal state.

Define a sequence of milestones for the process-implementation project (see Treating Process Implementation as a Project). Define the goals of each phase, what should have been achieved, what risks should have been reduced.

When you define the content and goals of the first iterations keep the following guidelines in mind:

• Keep the final goal in mind.
• Reduce major risks early.
• Focus on major problem areas early.
• Select some areas where you can make some easy gains early.

The following are some typical factors and how they can affect the plans (see also Guideline: Process Discriminants):

• Problems in the current development process. Focus on the areas of the development process, where the organization has problems today. Focus on areas where you can expect some easy results, where people can see the benefits early. Make sure that the first iterations focus on some area where you know you will address and solve one the major problems in today's organization.
• The need for change in the current organization. If there are a lot of problems in the organization – with the tools, or with the way people work – the frustration level in the organization will be high. In this case, you can be more aggressive and employ the new process and tools, or parts of them, in real projects.
• The capacity for change in the current organization. If they are either unaccustomed to change or currently overwhelmed by it, the goals of the first few iterations should be modest. In this case, the primary objective should be to build credibility and confidence in the process, with more intrusive changes reserved for later iterations when they can be more easily accommodated. See also Concepts: Managing Organizational Change.
• The size of the organization. If the organization, which will use the process and tools in the end, is large, you want to be sure that the development case and the tools are stable enough to be used by many developers. In this case you should be more careful and implement the process and supporting tools during several iterations in one (or a couple of) software-development project(s).   
• The risks involved. If they are small, you can be more aggressive and start using the process and tools in new projects faster. If the risks are big you need to be more careful, and use pilot projects to verify the process and the tools.
• The attitude among people in the organization. Communicate the problems in today's organization, and its way of working. If there is an understanding of the today's problems among the people, then it will be easier to accept and understand the need for change. Involve the people outside the immediately affected part of the organization.

Do not try to do everything at once. Instead, divide the implementation into a number of increments, and in each one implement a portion of the new process, together with the supporting tools. Typically, you should focus on one of the areas where you believe the change will have the most impact. If the software-development organization is weak in test you may start by introducing the Test workflow of the Rational Unified Process, together with tools to automate testing. However, if the organization is weak on capturing or managing requirements, you would start by introducing the requirements workflow, together with supporting tools.

You implement the process and tools in iterations of software-development projects; pilot projects or real projects. The purpose is then to verify the process and the tools, in as real environment as possible. Consider the following when you select software-development projects and iterations (see Process Implementation Approaches, for examples):

• If the goal is to implement the process and tools in one single software-development project, you may decide to implement the process and tools in that one project, and then monitor and improve the process as the project goes along.
• If the goal is to implement the process and tools in a large organization, many projects, you should consider to implement and verify the process and tools in iterations in several phases. In that case you should choose a relatively short project, where you can apply the process and tools during the whole lifecycle of a software project.
• Pilot projects. If the Rational Unified Process represents a significant departure from your current software engineering process; or if you need to get a better handle on the risks and advantages of introducing the new process; or if you are in a new organization that has little or no process in place, you should consider trying out your development case (or a simplified development case) on a "mini-project" or "pilot project" before applying it to your major, mission-critical development project.

The use of a new process, new tools and possibly technology in a software project makes the project's schedule more volatile. Be sure to allocate time and resources to implement the process, train people, and so on, during the iteration in the software-development project were you start using the process and tools. 

Step 5: Execute process implementation

The most time consuming step in implementing a process is to execute it according to the plan defined in step 4. This includes the following: 

• Develop a new, or update an existing, development case. See Activity: Assess Current Organization, and Activity: Develop Development Case.
• Develop guidelines to support the development. See Activity: Develop Business-Modeling Guidelines, Activity: Develop Use-Case Modeling Guidelines, Activity: Develop Design Guidelines, Activity: Develop User-Interface Guidelines, Activity: Develop Programming Guidelines, and Activity: Develop Test Guidelines.
• Acquire and adapt tools to support and automate the process.
• Train members of the development team to use the new process and tools.
• Apply the process and tools in a software-development project.

In executing the process-implementation plan, there is one common effect that has to be guarded against: over-reliance on the mentor. In the beginning of a process-implementation effort, there are many benefits of having an external experienced process mentor, on-site, full-time. However, if the team relies too much on the mentor, they will never make the necessary commitment required to make the process a success. Periodic follow-up by the mentor is required, but over-reliance should be avoided. We recommend that you plan for someone within the organization to take over the role of the process mentor.

Step 6: Evaluate process implementation

When you have implemented the process and tools in a software-development project, real or pilot, you need to evaluate the effort. Did you achieve the goals you established? Evaluate the people, the process and the tools to understand which areas you should focus on when you start again from step 1.

Process Implementation Approaches

There are different approaches for implementing a process. We will give examples of two approaches:

• the "typical" approach, and
• the "fast" approach, and 

The typical approach (illustrated in the figure) is to first implement the process in a "pilot project". In an initial step you configure the process and describe it in a development case. You use the process on the pilot project. Experience from the pilot project is fed back into the development case. The process is then considered "tested" or verified, and can be rolled out to a broader audience. What you use as a pilot project could be:

• A complete software-development project that is considered low risk from a technical and financial perspective.
• The first complete iteration of a "real" software-development project, with the caveat that the main focus is on learning and improving the process, not on developing software.

This is often the most effective way to introduce the process and tools.

The "typical" approach to implementing process and tools.

The "fast" approach (illustrated in the figure below) is to use the process and tools directly in real projects without verifying that they work in a pilot project. This approach introduces a greater risk of failure, but there can be good reasons for taking those risks. For example, if the current process is very similar to the Rational Unified Process, and if the tools are already used in the organization, it may be relatively easy and low-risk to implement the new process and tools.

Another case is when the organization is suffering from such severe problems that any change is perceived as an improvement. This also assumes that the potential for improvement is greater than the problems the organization will inevitably will encounter.

The "fast" approach to implementing process and tools.

Treating Process Implementation as a Project

Implementing a software-development process in an organization is a complex task and should be done in a controlled manner. We recommend treating it as a project (external to or sub-project of your software development project) and set up milestones, allocate resources, and manage it as you would for any project.

The process-implementation project is divided into a number of phases, where all six steps are performed in each phase until the project is ready and the process and tools are deployed and successfully used by the entire organization (see the figure below).

A process-implementation project can be divided into phases.

The following table gives a rough idea of how a project can be planned with four phases.

The four phases of a process-implementation project.