| Implementing a software development process in a large organization with a hundred or more people is a complex task and needs to be done in a controlled manner. We recommend treating it as a program with clear business objectives, well-defined milestones, and dedicated staffing resources, and the program should be managed according to defined objectives and milestones. When looking at your organization's problems, you may feel the strong desire to fix everything at once, especially since many of these problems occur simultaneously . Organizations, just like individuals, can accommodate only a limited amount of change, and different organizations are better prepared for change than others. To understand the organizational capacity for change, we recommend that you interview people in the organization to understand their attitudes and willingness to change. The process improvement program consists of a combination of the following types of projects: -
Process and tool enhancement projects (PTEPs), which aim to produce new baselined versions of processes and supporting tool environments used for internal deployments. They provide the right infrastructure to facilitate the introduction of the process and tools. -
Pilot projects, which are software development projects with the added objective to investigate the organization's ability to adopt a certain process and tool environment and verify that the process and tool environment is sound. -
Software development projects, which use the processes and supporting tool environments. Following, we walk through each of the project types; and in the sections A Typical Program for Moderate Change, A Typical Program for Major Change, and An Aggressive Program for Major Change, we discuss different outlines of RUP adoption programs based on your ability to accommodate change, time constraints, willingness to take risks, and many other factors. Process and Tool Enhancement Projects (PTEP) A process and tool enhancement project aims to produce the next generation of the process and supporting tool environments ( ideally accompanied with some reusable assets), tailored for the specific needs of the adopting organization. Just as a RUP project is divided, we divide the PTEP into four phases, in which each phase has the same name and business objectives as a software development project using the RUP (see Table 11.2). Table 11.2. Four Phases of a Process and Tool Enhancement Project. A PTEP consists of four phases, with very similar objectives to a normal software development project using the RUP . | Phases | Objectives | Description and Outcome of Each Phase | | Inception | Understand the scope and objectives of the next generation of the process and tool environment. | -
Assess the organization and decide what areas of improvements will provide the biggest return on investment. Should you, for example, focus on Requirements Management, Analysis & Design, or Configuration Management? -
Develop the business case. Get buy-in on the business case from all stakeholders, and get a go or no-go decision from the sponsors. -
Produce a high-level plan and budget for your project. Produce a detailed plan for the next phase and identify resources. | | Elaboration | Prove the feasibility of the next generation of the process and tool environment within the context of your organization. | -
Produce a detailed plan and prioritize the implementation of the customized process content, training material, and tool environment. Provide skeletal content for the most important/ controversial customizations. -
If you will develop RUP Plug-Ins, develop the plug-in without the content (see the section Develop RUP Plug-Ins, in Chapter 10). -
Define and execute pilot projects to verify the ability of your organization to successfully adopt the outlined process and tool environment. -
For major customizations, the Elaboration phase may need to be divided into several iterations, in which major risks associated with the customization are addressed in the first iteration. -
Plan next phase. | | Construction | Create project-consumable "beta" version of the next generation of the process and tool environment. | -
Produce a complete version of the customized process (including any RUP Plug-Ins you may develop), supporting tool environment, and training material. The material should be of "beta" quality, meaning that you may still have to do some fine-tuning before it is released for organizationwide adoption. -
If the customizations have been extensive , try them out in practice through one or several pilot projects, or parts of pilot projects. This will provide you with the feedback necessary to improve customizations as necessary. -
Identify risks and issues with the process, training material, and supporting tools. -
Produce a training plan for the organization. Most training should be done just before the knowledge is needed, but some key people, such as mentors, trainers , project managers, and team leads, may need training outside the context of a project. -
For major customizations, the Construction phase may need to be divided into several iterations, in which top risks are mitigated first. -
Plan next phase. | | Transition | Fine-tune the next generation of the process and tool environment, prepare for organizationwide deployment, and plan future improvement projects as necessary. | -
Assess potential issues associated with the process and tool environment by deploying changes done to the process, the training material, and the tool environment during Construction in one or several pilot projects, or parts of pilot projects. Note that you do not necessarily need to start new pilot projects; you may instead deploy changes in a pilot project that was initiated during the Elaboration or Construction phases. -
Prepare the organization for deployment of the new process and tool environment by training mentors, trainers, project managers, and team leads. Document how projects are supposed to deploy the new process and tool environment, including how to acquire and deploy the process and tool environment, how to get mentoring and training assistance, and how to provide feedback on the environment. -
Identify the need for additional projects to improve the process and tool environment. | Pilot Projects Pilot projects are software development projects with the added objective to examine and provide feedback on the new process and tool environment, including supporting material such as training material. Here are the things to consider when setting up a pilot project: -
Purpose and timing. A pilot project should mitigate your highest risk items in your process and tool enhancement project. For most organizations, the biggest challenges are related to adopting core RUP best practices such as iterative development, requirements management, Configuration Management, and Change Management, and the tools supporting these best practices. These risks need to be mitigated during the Elaboration phase of PTEP, which means that you need to run pilot projects in this phase. If you are doing major customizations to the RUP, you typically want to try these out. This is done by pilot projects during the Construction and Transition phases of PTEP. -
Team size. Most pilot projects work best if you have six to eight people on the project team. This is enough people to introduce some elements of complexity, but not enough to risk failure. Sometimes you may want to have more people, maybe because the main risk you are trying to mitigatethe main uncertaintyis whether the process or tool environment works for larger projects. -
Length and time constraints. You want fast feedback on the process and tool environment. Often, you do not have to run a complete pilot project to obtain the feedback you are looking for. In most cases, you want to go through at least one Construction iteration of the pilot project to obtain the feedback you are looking for, because by that time you will have deployed all tools and tried out most aspects of the process. In other cases, it may be sufficient to go through only one iteration of a project as a pilot project. The ideal length of a pilot project is typically two to six months, which is long enough to allow for some complexity and short enough to allow you to move on and put your experience to work on other projects. Furthermore, you don't want the time constraints to be too tight. You need to be able to take enough time for the project to learn to apply the process and tools appropriately. -
Staffing profile. Choose for your pilot those people who have an interest in learning something new and who have the ability and the opportunity to act as mentors on future projects. Having pilot team members act as internal mentors on other projects is the fastest way of transferring knowledge. Also, make sure that the project manager and the architect are qualified and work together as a team because these are the two most important roles. -
Importance and complexity. A pilot project should build real software that has a reasonably important business purpose. If the application isn't important or complex enough, people will say, "Well, building that application doesn't prove anything. Over here, we're building real software, and we still don't think you can do that with the RUP." In most cases you don't want your project to be so critical and complex that you run a risk of compromising your business in the face of failure. That won't prove anything, and you won't be any better off after the pilot than you were before. You will know only that the first time you used the RUP, under suboptimal conditions, it did not save a doomed project. There are, however, a number of cases in which you actually want to choose a very high-profile, critical project. This is typically the case when you have nothing to lose, or you must force a rapid improvement of the process and tool environment to ensure business success. The advantage in choosing a critical project is that these projects will likely employ the most talented people, the strongest management support, and the deepest pockets to pay for necessary training, mentoring, and tool support. Software Development Projects Deploying the RUP in software development projects was described in the earlier section Adopting the RUP in a Project. Here again are the five steps discussed in that section: -
Assess. Assess what issues your team has been facing in the past and what issues are of the highest priority to address for the future. -
Plan. Plan the rollout activities, such as customization of the process, training and mentoring, and purchase of required tools. -
Configure and customize. Do necessary configuration and customization of the process, tool environments, and training material. -
Execute. Deploy the process and tools in your project, train and mentor project members, and run your project. -
Evaluate. Evaluate how the project went, and compare it to your expectations. Identify opportunities for future improvements. Note that when you deploy the RUP in a project within an organizationwide RUP adoption program, a lot of the work within the three first steps (Assess, Plan, and Configure and Customize) may already be done for the individual project by the overall program. For example, the program may have already identified that the organization needs to enhance the RUP by providing increased guidance on building safety-critical systems. It may have facilitated a lot of the planning by describing how to roll out the process and the tools, and the program may have done the necessary configuration and customization. A supporting infrastructure in terms of mentoring and training services may also have been put in place, facilitating the Execution stage within the individual project. The fact that the process and tool enhancement project typically reduces the amount of work associated with assessing, planning, and configuring and customizing the RUP articulates one important aspect of the program: to increase the likelihood of success while reducing overall costs associated with individual projects, improving their process and tool environment.  |
