Introducing the RUP into an organization

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

DJ de Villiers (devilliers@wxs.nl), Mentor, Empulsys

24 Nov 2003

This Rational Edge article discusses the ins and outs of introducing process in your development effort

When an organization is considering a new process or tool introduction, there are a number of issues to consider: Which combination of process and tools is best? What is the most suitable implementation approach? Is the organization fully committed to the success of this project? What is the organization's capacity for change? This article examines these issues based on personal experience with introducing the Rational Unified Process® (RUP®) and Rational Suite® in both small and large organizations.¹

Implementation Approaches

An organization may take any one of several approaches to implement the RUP, depending on the project situation:

• Typical approach
• Distributed approach
• Fast approach
• Careful approach
• Organizational development environment approach

We will discuss each one below. Please refer to the Sidebar for definitions of terms.

Typical Approach

In the typical approach, the process and tools are first introduced through a three-to-four-month pilot project consisting of ten to fifteen people. Before the project starts, the RUP is configured in a project-specific Development Case, and tools are selected. After the pilot project, the Organizational Development Environment (ODE) is prepared. During this stage, the new process and tools are evaluated by the Software Engineering Process Authority (SEPA).2 The Development Case and Guidelines developed during the pilot project are refined for the organization, and the pilot project team members prepare to serve as mentors for other projects (see Figure 1).

Figure 1: Typical Approach for Implementation

As its name implies, this is the most commonly used approach. It has its plusses and minuses (see Table 1), but it is especially applicable when the organization is skeptical about process change. Since there is a risk that the delivery date of the pilot project may be delayed, it is wise to select an urgent project for the pilot, keeping in mind the potential effects of a possible delay.

Distributed Approach

In the distributed approach, multiple pilot projects are targeted for the initial introduction of process and tools (see Figure 2). Because a larger "surface" of the organization is involved, process and tools can be applied to different domains or environments. The environment preparation phase will take longer because multiple evaluations, Development Cases, and Guidelines need to be harmonized. As in the typical approach, pilot project team members are used as mentors on future projects, and because more mentors are available, more projects can be started.

Figure 2: Distributed Approach for Implementation

This approach is applicable when the organization wishes to test process and tools under different scenarios (for example, mainframe versus Java skills or in-house versus contractual projects). Due to the increased effort and complexity, this approach is more expensive than the typical approach (see Table 2).

Fast Approach

In the fast approach, process and tools are introduced into projects without first verifying their effectiveness or building up experience with them (see Figure 3). It's important to relay the experiences of these projects to the SEPA in order to prevent the "ivory tower" syndrome.⁴ This approach carries a greater risk of failure because the organization does not have time to make mistakes, correct them, and then adapt to the changes.

Figure 3: Fast Approach for Implementation

This approach is effective when the current process is very similar to the RUP or the organization is already using some of the tools, which lowers the learning curve. This approach is also appropriate when the problems are so great that any change will be considered an improvement. (See Table 3.)

Careful Approach

In this approach, the Development Case created by the initial pilot project is successively refined in multiple, sequential pilot projects (see Figure 4). Tools can be introduced incrementally in each project. Use of the new process and tools then spreads like an oil spill, as smaller projects enjoy progressively larger successes. The final preparation of the environment will be shorter, because the Development Case and Guidelines will not require much refinement. When using this approach, it is very important to ensure small successes rapidly (quick wins) in order to prove value and progress. Otherwise, the organization may lose sight of the goal, and the transition may eventually fail.

Figure 4: Careful Approach for Implementation

The careful approach is usually applicable when the organization's capacity for change is low or there are many changes to be made. In these cases, it is necessary to carefully plan and execute change in small increments. (See Table 4.)

Organizational Development Environment Approach

Organizations that are setting up an organizational development environment can run that project in parallel with the pilot project(s) described in the other approaches. Usually, this approach is combined with the typical approach, as shown in Figure 5. The SEPA's role is to coach and support the pilot project, while the pilot project provides feedback to the SEPA about the application of process and tools.

Figure 5: Organizational Development Environment Approach for Implementation

This approach can be used to relieve pressure on the pilot project, or when there is no development organization already in place. Combining this approach with multiple pilot projects significantly increases the managerial complexity of the project. (See Table 5.)

Back to top

The Pilot Project

The goal of a pilot project is not only to deliver a product, but also to apply new process, technology, or tools. Important requirements include:

• Manageable Technical Risk. A pilot project should not involve too much technical risk, although risk is difficult to avoid when you are introducing a combination of new process, tools, and technology.
• High Priority. The project should have a high enough priority to ensure necessary management commitment and sufficient resources. A mission-critical project would certainly meet this criterion but also carry a high cost of failure (financial risk).
• Committed Resources. Many pilot projects fail when their resources are reassigned to other projects or their budgets are cut. Managers should commit sufficient resources for the duration of the project.
• Realistic Schedule. The project schedule must not be so constrained that the team must forgo the adoption of process and tools in order to meet it. Usually, the project manager is given some extra time to complete the project (ten to twenty-five percent of the original schedule).

If the pilot project has been started before a process introduction, it is important to position the project within the applicable RUP lifecycle phase. If the project is in Inception or early Elaboration, there is usually enough time to introduce process and tools without jeopardizing the delivery date. Waiting to introduce a new process or new tools at a later stage will destabilize the project, as the project team's focus will shift to accommodating the changes. This may lead to delayed delivery of the project, and in some cases could even lead to project termination if the team becomes swamped in complexity. A neat project startup provides the opportunity to set realistic expectations, ensure user availability, and form the project team. If the project has already been started, then these issues need to be addressed immediately.

Generally, process and tools are introduced during Inception and Elaboration, as shown by the focus areas in Table 6. Inception focuses mostly on requirements management and project management. The goal of Inception in a pilot project is to get buy-in from the sponsors (of the organizational change rather than the product). In Elaboration, focus shifts to design and configuration and change management. Testing tools are introduced in Elaboration but will not be used widely until later. The major goal of Elaboration in a pilot project is to eliminate the risks associated with the new process and tools. During Construction, no new tools are introduced, and the project team focuses on developing the product and improving productivity. Stability, efficiency, and the product are the goals of Construction in the pilot project. During Transition, the team collaborates more with the SEPA, and focus shifts to evaluating the usage of process and tools in the project.

Back to top

Training and Mentoring

Training is a key to success, and all project team members should complete the RUP Fundamentals (two-day) training before the start of the project. Further training may be required on specific disciplines, depending on the team's skills and experience. For example, the designers may require UML training, or the users may require training in use cases and requirements management. If in-depth training focuses on the same domain as the pilot project, then the project team can prepare by working on a mini-project similar to the pilot, without fear of failure or wasting time. An important by-product of training is team building, which can occur only if the team is trained together.

Tool-specific training takes place just before the tool is to be used. In a project environment, this tool training is usually done in a workshop; it covers only functionality that is relevant to the project and focuses on the project artifacts.

Mentoring is necessary when introducing new technology or techniques to a project team. During a typical course the examples merely illustrate the application of theoretical concepts. Afterward, most people struggle to apply these new concepts directly to real-world problems. A mentor can discuss their questions and doubts, guide them toward answers, and review artifacts. Although mentoring cannot fully replace in-depth training, it is an effective way of balancing learning with practical experience without compromising quality or deadlines.

Back to top

The Challenges of Big Implementation Plan

Introducing the RUP into an organization involves the following sequence of activities (see Figure 6):

1. Set goals and expectations.
2. Plan your delivery.
3. Instantiate the RUP.⁵
4. Train the project team.
5. Mentor the project team.
6. Evaluate progress.

These activities are discussed below. They may also be performed in iterations, as described by Philippe Kruchten⁷.

Figure 6: Introducing the RUP into an Organization

Activity 1: Set Goals and Expectations

Goal: Determine the scope and goals of the new process and tools introduction, and set the expectations of key stakeholders and the Rational team.

The Vision⁷ produced by this activity will be used as the measure during Activity 6: Evaluate progress. Goal setting is performed in a meeting between the sponsors and the Rational TEM (see Sidebar), who should agree upon the following:

• Business drivers for change (including stakeholders)
• Scope (organization or project level; which process and tools)
• Responsibility assignment (including driving the organizational change)
• Implementation approach (typical, distributed, careful, and so on)
• Priority of improvement areas⁸
• Project organization
• Pilot project(s)
• Commitment by both parties
• Training requirements

Activity 2: Plan Your Delivery

Goal: Establish a delivery schedule that satisfies dependencies between the items and activities defined in Activity 1: Set Goals and Expectations, and available resources.

This is accomplished in a meeting between the Rational TEM and the Project Manager. Required tasks are:

• Identify key stakeholders.
• Schedule installation.
• Schedule training.
• Schedule mentoring.

Activity 3: Instantiate the RUP

Goal: Produce a project-specific or organization-specific Development Case.

Exact timing of the steps in this activity depends on the selected implementation approach. This activity is typically carried out in parallel with others and consists of the following steps:

1. Train key stakeholders. The organization obtains a clear understanding of the RUP. Key stakeholders attend the RUP Fundamentals training (two days), and the Process Engineer attends the Implementing RUP training (two days).
2. Assess the organization. Assess the software development organization in terms of its current process, tools, roles, competencies, attitudes, market, technical trends, problems, and improvement areas. This assessment is performed by the Process Engineer(s) under the guidance of a Rational Software Engineering Specialist. The scope of the assessment depends on the chosen implementation approach and schedule pressure. This step might be initiated earlier to help set goals and expectations (see Activity 1: Set Goals and Expectations above).
3. Write the Development Case. The project-specific (or organization-specific) configuration of the RUP is captured in a Development Case. This artifact describes the combination of roles, artifacts, activities, and level of ceremony and formality to be used by the project (or organization). It is in the form of either a Word document or an HTML shell provided by the RUP.

Activity 4: Train the Project Team

Goal: Train the project team on both the standard RUP and the project-specific (or organization-specific) customizations defined in the Development Case (see Activity 3: Instantiate the RUP).

The team attends the RUP Fundamentals training (two days) and a kick-off session in which the Development Case is presented.¹⁰

Activity 5: Mentor the Project Team

Goal: Mentor the pilot project team regarding the use of the standard RUP and the specifics of the Development Case.

The mentoring is performed by a Rational Software Engineering Specialist, who answers questions, participates in and steers discussions, and reviews artifacts produced by the project team. If the organization also wishes to set up an ODE, the Process Engineer receives mentoring if necessary.

Activity 6: Evaluate Progress

Goal: Conduct an assessment of progress made by the project team (or organization) in adopting the RUP and determine next steps for further deployment of process and tools.

The evaluation is performed by a Rational Software Engineering Specialist(s), usually by interviewing key stakeholders. The next steps are based on the evaluation report and are determined during a discussion between the Rational TEM and the sponsors.

Back to top

Success and Failure Factors

Based on our experience, we have compiled lists of the top reasons for both success and failure when instituting a new process and tools in an organization. Organizational change cannot be forcibly imposed; its introduction must be managed. How the change will be effected depends on many factors, such as skills, attitudes and motivation, existing process and tools, and organizational structure and culture. These process discriminants¹¹ will determine the particular configuration of the RUP to be used by the project or organization as well as the most suitable implementation approach.

Top Reasons for Failure

1. Failure to introduce process and tools incrementally. A big-bang introduction forces change onto people and can destabilize the project if resistance is too great. People can lose motivation, which hampers them from dealing effectively with the complexity of having to learn and apply everything at once. Typically, someone eventually decides to rectify the situation, most often by reversing the original decision rather than reassessing the situation and determining the best way out.
2. Lack of management support. It is a well-known fact that organizational change has to be effected at all levels in an organization, starting with management. The pilot project should have visibility at the management level, and part of the organization's commitment to success is a management team that is willing to participate in implementing new process and tools.
3. Lack of buy-in from sponsors and stakeholders. When sponsors or stakeholders are not aware that progress is being made, they tend to become less motivated about a project. Having agents of change at all levels of the organization is important, and these people must be kept informed and involved. Be especially mindful of this when using the Careful Approach described above.
4. Unwillingness/incapacity for organizational change. When the organization is not committed to success, or it has chosen the wrong implementation approach, people lose motivation. If the organizational change is not managed well, or political forces become more important than the process and tools, then the project has very little chance of success. This usually goes hand-in-hand with lack of management support; management provides a poor example for the team.
5. Vision and change drivers are unclear. When the business drivers behind the change are not clear, it is difficult to convince people of the value of steps that must be taken to effect that change. People must know why the organization must change (drivers) and where the change is leading (vision) in order to build a strong foundation for the implementation.

Strategies for Success

1. Assess the project and the organization. Assess the organization to prioritize improvements and determine the best implementation approach. Assess the project to understand its unique characteristics and drivers so that the process is applied in the most beneficial and effective manner.
2. Implement process and tools incrementally. Take small steps, making a few improvements at a time, and book successes (quick wins) before starting on the next improvements. In this way, the project team will not become overwhelmed, and sponsors can be convinced that you are making progress. Do an organizational assessment to determine which improvements to tackle first. Be sure to steer each step toward the vision; stepping in a random direction is no better than not stepping at all.
3. Manage and plan. Environment activities should be managed and planned along with software engineering activities (Environment is one of the RUP disciplines). Often, project managers overlook environment activities, regarding them as secondary or overhead. In reality, these activities are just as complex and crucial as requirements analysis, design, or testing. Process management is as essential a part of any project as project management.
4. Use mentors. Mentors act as agents of change at the project level. Even with extensive training, people tend to fall back to their familiar way of working after some time. Mentoring is especially crucial in the first weeks of the project, until the team is accustomed to the new way of working.
5. Distribute process ownership. The people using the process are the "real experts." Their experiences and feedback should be captured and shared. Not following this advice may lead to the "ivory tower" syndrome; that is, there may be a clear, sometimes hostile, divide between the process academics and those who actually apply the process.
6. Be pragmatic. Don't make the process too heavyweight. Too much documentation and ceremony can swamp a project. Use the most appropriate form for an artifact; even a rough sketch on a whiteboard can be an artifact. A Development Case should not be a completely rewritten process, but should contain only deviations from the standard RUP. Finally, keep in mind that you cannot always do things right the first time, so it is better to just do it than get stuck trying to do it perfectly.
7. Communicate. People don't like change, but by showing them proof of progress and setting realistic expectations, you can convince them that the change is a good thing. Identify key people (agents of change) at all levels in the organization, and be sure to keep them and the stakeholders informed and involved.
8. Train people. Training can be an especially effective tool for managing organizational change. Training on tools and techniques can be done through courses, workshops, boot camps,¹³ and kick-starts¹⁴. It is very important to mentor the application of the tools and techniques after training to ensure effective usage.

Back to top

RUP Talk

Here is some of the terminology you'll encounter if you decide to implement the RUP.

Account Manager: The Rational employee who is commercially responsible for a given Rational Software customer.

Development Case: A document or Web site describing the particular RUP customizations to be used by a customer project or organization.

Guidelines: Documents produced before a project begins that capture decisions regarding existing standards or strategies. Guidelines are typically updated during the project, based on the team's experiences. Examples: Use Case Modeling Guidelines and Design Guidelines.

Organizational Development Environment (ODE): Organizational standards regarding process, tools, and techniques that all projects should use consistently.

Pilot Project: A "proof of concept" project for new process and tools. Organizations typically run pilot projects before full deployment in order to minimize the risk of failure.

Process Engineer: The person (or group) responsible for configuring the RUP by writing and maintaining the Development Case. The Process Engineer works closely with the Software Engineering Process Authority but does not necessarily belong to it.

Project Manager: The person (or group) responsible for planning, staffing, and monitoring the project implementation. The "project" could be either the pilot project or the full project to set up an Organizational Development Environment.

Rational Unified Process (RUP): An iterative, architecture-centric software engineering process developed by Rational Software. RUP is a Web-based description of roles, artifacts, and activities that enable the application of software engineering best practices.

Software Engineering Process Authority (SEPA):¹² The person or group who owns the process and is responsible for providing process guidance and support to projects. A more formal SEPA, such as a staff department, would define process standards and perform project reviews.

Software Engineering Specialist: The Rational consultant with expertise in a particular field of software engineering. These consultants typically provide training and coaching as needed, determined by the Technical Engagement Manager.

Technical Engagement Manager (TEM): The Rational employee technically responsible for the successful implementation of the RUP and Rational Suite within a customer organization.

Back to top

Conclusion

In this article, we have seen what needs to be taken into account when introducing new process and tools into an organization. A suitable implementation approach should be chosen based on how many resources and how much time are available for implementation. In the typical approach, a pilot project precedes broader deployment. Multiple pilot projects may be implemented, either sequentially or in parallel, to apply the process and tools in a broader context.

The implementation plan involves identifying and meeting with stakeholders to set the goals and expectations for the implementation; scheduling installation, training, and mentoring; configuring the RUP based on project-specific or organization-specific process discriminants; training and mentoring the pilot project team; and performing a follow-up evaluation.

Factors that often lead to failure include trying to change everything at once, lack of management support, and not keeping stakeholders informed. Ways of ensuring success are to employ pragmatism, common process ownership, training and mentoring, and effective communication.

The duration and effort estimates in this article reflect a typical project and organization. Use them as guidelines for planning your own implementation, but be sure to monitor progress and adjust your plan as necessary.

A final message: If you let people know that you enjoy what you are doing, then they will want to participate!

Back to top

Acknowledgments

I would like to thank Gary Pollice, John Smith, Cindy VanEpps, Eric Lopes Cardozo, Catherine Southwood, and Marlene Ellin for their patience and help with this article.

Back to top

References

1. Alistair Cockburn, Surviving Object-Oriented Projects: A Manager's Guide. Addison-Wesley, 1997.

2. Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed. Addison- Wesley, 2000.

3. Walker Royce, Software Project Management, A Unified Framework. Addison-Wesley, 1998.

Back to top

Notes

¹ Note that the average figures in this article are based on experiences with large financial organizations. Smaller companies, or companies doing contractual software development, may have slightly different average figures.
² If there is not yet a formal SEPA, then a representative group can fulfill this role.
³ This point warrants further explanation. Many pilot projects conclude and leave the organization asking, "So what's next?" At this point, it can be very difficult to involve other parts of the organization in the environment. Instead, the environment stage should be planned by all involved parties during the pilot. This ensures that the momentum built up during the pilot will be maintained; otherwise, the environment stage may take months to get up to speed.
⁴ The "ivory tower" syndrome can occur when the group that defines standards and guidelines is detached from projects. It leads to excessive documentation that is not practically applicable to projects.
⁵ Note: This activity is typically carried out in parallel with the other activities.
⁶ The Rational Unified Process: An Introduction, 2nd ed., pg. 253.
⁷ This is a document containing a description of the problem, the boundary conditions of the solution, and a list of what will be done to solve the problem. The purpose of the Vision is to achieve concurrence among the stakeholders.
⁸ These are categories of improvements such as requirements, communication, or project planning.
⁹ Examples of such items and activities are meetings, courses, workshops, reviews, and presentations.
¹⁰ Depending on the selected implementation approach, the project team may actually create the Development Case during this workshop. In this case, the Write Development Case activity in Activity 3 would instead occur during Activity 4.
¹¹ For an in-depth description of process discriminants and their effect on process, see Software Project Management by Walker Royce, pg. 209.
¹² Also known as Software Engineering Process Group.
¹³ A short period of intensive training followed by an evaluation.
¹⁴ A way to combine training, team building, and a project kick-off by taking the team to a remote location for a few days, away from the office. These few days are spent learning, working, and having some fun.

Click here to download a PDF of this article. (182 K)

Editor's Note: This article was first published in The Rational Edge.

About the author

		DJ de Villiers is a freelance consultant in The Netherlands, helping teams and organizations adopt the Rational Unified Process (RUP.). Formerly, as a Rational technical representative for financial and government accounts, he supported customers using RUP and Rational Suite. Before joining Rational, he architected and developed banking software and also served as a South African Artillery officer, liaising on artillery command and control and fire control projects. He holds a BS in military science from the University of Stellenbosch, South Africa. His e-mail address is devilliers@wxs.nl.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top