Contents


A Case Study: Using IBM Rational Unified Process as the Methodology Framework

Comments

This article is divided into five parts. First, a brief introduction, then we discuss our development effort, followed by our deployment effort, lessons learned, and our conclusions.

This case study is a real story with real-world experiences about how our team successfully developed and deployed an iterative methodology using RUP® as a framework. This was done as a joint effort between Ford and Ford FinancialFord Credit. Ford Financial Credit is a fully owned subsidiary of Ford and the largest provider of automotive financing. We provide vehicle financing for over 11,000 dealers in 40 countries, and we have financed more than 50 million vehicles since 1959. We are also known as Ford Financial. in the media frequently as Ford Credit. We have a large IT staff of over 700 people.

What Was Our Motivation?

We had difficulty sharing project deliverables across projects. Every team had its own set of templates and its own methodology. When people moved from one team to another, they had to learn a new method. We also had difficulty with our common teams, known asour service teams. Those are the teams, outside the application team, that provide goods products and services to projects. Examples of service teams includesuch as the DAs, DBAs, frameworks team, and build team. Every application team that came to one of these service teamsthem had a different set of deliverables, so they didn't have a common framework to work through.

We also had late involvement of these service teams, and that caused problems. People came to the build team right before they needed to go to production instead of contacting them at the right time.

In addition, our framework architects were being overburdened by process questions. The framework architect's job is to design and maintain our design patterns; instead they were being asked how to organize a project, what process should be used, and how many iterations the project should have. That's not their job.

Projects were also feeling another pain: late identification of project risks. We had one project that had to connect to data warehousing and retrieve information for reporting purposes. They left this to the last minute and found out that the performance was not fast enough. This had a big impact on the project.

Most importantly, this endeavor to have a common process was a pull effort, not a push. We weren't pushing this methodology on our organization. We were asked to implement a common software development process.

Why Did We Choose RUP?

We had some expertise in RUP in our organization. We also knew that RUP was meant to be customized. Some individuals on the frameworks team, who said that they knew a lot about RUP, drafted a one-page summary of RUP, which obviously was a little too much tailoring.

We also knew that there existed knowledgeable resources, both within and outside the company. We knew that RUP provided a rich set of terms that were clearly defined and well understood throughout the industry, and that this was a real advantage. This industry-leading position of RUP gave us credibility with our management and from those outside. RUP is highly customizable, and we knew that that's what we had to do.

How Did We Set Out on Our Path?

First we piloted RUP on six projects, covering four different business areas. We then promoted RUP awareness through presentations at community forums. Some of these had a standing room only crowd, which gave us a lot of encouragement. We identified subject matter experts (SMEs) throughout the company. We then undertook two projects: one to develop a customized version of RUP and one to deploy what was developed. The result of our journey is what we call Unified Solution Delivery Methodology, Unified SDM, or USDM. It's based on RUP, but is customized for Ford with specific organizational and project needs. For instance, we had to include our internal controls considerations and our data and record retention policies. In addition, we had to include roles defined by what is known as Ford's job families.

Unified SDM is pragmatic enough to deliver real value, even for fast paced projects, and it is flexible enough that we could use it to satisfy many of our project needs.

Development

We structured the development effort as a project (see Figure 1).

Figure 1: The Development Project

We had a goal, and that was to create a robust and pragmatic object-oriented development process tailored for Ford's needs. We also had objectives: to customize RUP, to develop training, and to define a support organization. We had a timeline of six months, and we also had three resources: three methodologists to work on this project.

The steps we took are outlined in Figure 2.

Figure 2: The Steps in the Development Project

Through our RUP Pilot, those six projects that we piloted, we determined the Unified SDM entry criteria. At Ford Credit it was going to be all projects that used object technology. For us, that's J2EE. We prepared the artifacts by first looking at the RUP artifacts, and then deciding which ones we needed and which we didn't. We then added Ford processes to the methodology. At Ford we have many of our own artifacts and our own required processes.

We documented the service teams' roles and responsibilities and at what point these various teams should become involved in a project. We also defined the phase exit criteria by identifying what it meant to enter and to exit the Inception, Elaboration, Construction, and Transition phases. In addition, we created simplified workflows. We took the workflows that existed in RUP, and used some as they were, and simplified others significantly.

We refined the glossary and assembled a recommended reading list. We created training materials. In addition, we collected artifact examples and defined our support organization. Most importantly, we created a Web site. This all resulted in Unified SDM.

We incorporated the service teams (organizations outside the application team that provide services and products to the application team) by creating a sense of ownership and involving the service teams as SMEs in our project. Then we identified the service team process entry points -- when they should get involved in the project. This was important and added a lot of value. Next we mapped the service team responsibilities to the appropriate disciplines or workflows. We developed a good relationship with the service team management, and that was very important for us.

Every project has challenges. We encountered organizational complexity as well as the chicken and an egg problem. We had to run the train while we were trying to improve it, and we also had skeptical pilot team participants. Some managers of the pilot teams that we worked with during our RUP Pilot were reluctant. Managers wanted to see every last detail in the project plan for the next six months, or they weren't satisfied. They wanted to know everything up front. We had to convince them that that's not how you run these types of projects.

We had conflicting ideas among some of our SMEs. Whenever you have a few experts in the room, you always have lots of opinions, and that was definitely our case. We also had difficulty coordinating the effort between Ford and Ford Credit (for example, when and where we should meet).

We also have different project management methodologies at Ford and Ford Credit. This created a few problems for us because those at Ford, even though they were the sponsors of our project, didn't understand our project management methodology. They didn't understand what was involved, what it meant to be a project sponsor, and what their responsibilities were.

To summarize, in Unified SDM we have about 20 artifacts. We also have well-defined service team touch points. We have simplified workflows. We have a well-defined support organization, including coaching services, which we find extremely important. Our entire process is depicted on a comprehensive Web site.

As we customized RUP one of the key artifacts we brought in was the project charter, which replaced the Vision document within RUP. We created a System Architecture Document. We took the RUP document called Software Architecture Document, made significant changes to it to meet the needs of Ford and Ford Credit, and changed its name. We also created a useful artifact called the Risk-Use Case Mapping that is used to rank or prioritize the risks against the use cases.

Figure 3 shows some of the key artifacts.

Figure 3: Core Artifacts

Figure 4 shows one of our customized workflows.

Figure 4: RequriementsWorkflow

We took RUP's workflows, reviewed them with our subject matter experts, and then filled in some additional activities that we felt were needed. Overall we simplified the RUP workflow diagrams.

We then had to make the organization aware of Unified SDM, and we did this through the comprehensive Web site. We made presentations to both senior and mid-level management. We conducted USDM awareness presentations, and presented at local Object Oriented interest forums. This helped to make the organization aware of this new methodology that we were about to deploy.

Deployment

After we developed Unified SDM, we needed to deploy it. This effort was also structured as a project as shown in Figure 5.

Figure 5: The Deployment Project

Our goal was to implement the Unified SDM Support Center with all the necessary support and coaching services so that Unified SDM would be easily understood and used in the organization.

Our objectives were to establish the support center procedures, to produce and deliver appropriate training materials, and to define metrics to go along with the program. We had three methodologists, and it took us five months to complete.

The deployment steps are shown in Figure 6.

Figure 6: The Deployment Project

Deployment Deliverables

We instituted a change control process. We defined a coaching certification process and coaching procedures. We also developed training materials for our service teams, as we wanted them to know what our process was all about and when and how they should get involved. We then defined and signed off on service team agreements. (One of these agreements was with the frameworks team, whom we knew wanted to be involved up front). Most importantly, we delivered and deployed coaching services to qualified projects.

Our support organization has two arms as shown in Figure 7.

Figure 7: The Support Organization

One arm researches the industry, and develops and maintains the products of the process. They are the continuous improvement part of the support team. The other arm assists application teams. We have coaches to provide training, which we feel is really important and has led to the success of the process.

We also created a flow chart of how the change control process works. We wanted to involve the right people, leverage existing tools to track and log our suggestions, and establish a change control board. The change control board consists of a methodologist, project coaches, the SMEs from the service teams, and management. This group decides whether suggestions will be accepted or rejected.

Coaching

As we mentioned, one of the key features of our process is coaching. Good coaching helps to smooth the paradigm shift. Most people at Ford were used to getting all the requirements, signing off on them, doing analysis and design, coding, and delivering something that is integrated together at the end of the project. We had some people in the organization who were Cobol programmers and didn't know anything about object-oriented programming. There was a big learning curve to overcome, which the coaches helped to eliminate.

We wanted to ensure consistency across the organization for this process. We wanted to make sure that teams applied the methodology in the same way and were not taking their own slant on it. Through coaching, we obtained instant feedback on the process. We wanted to work pro-actively rather than reactively. We wanted to get involved in projects at the beginning, not when they're in trouble. Our coaches showed the teams how to execute the process, and even helped them create the UML diagrams if the team needed help doing them.

In the past we had just handed the teams a bunch of binders and said go do it. It didn't work. We also hired consultants. They sold us a big process that produced a complicated work plan. It contained many tasks, and the task names were different than teams had been used to seeing. This time we decided we needed hands-on coaching to help teams apply the methodology, and so far we have been successful.

The essentials for a project coach are that we want them to be able to relate to the project teams by being patient and consistent. They need solid methodology experience. They need to be fluent in RUP. They need to be experts in iterative development. They need hands-on technical experience that gives them some credibility. They have to be proficient in OOAD with UML and have project management know-how.

Our coaches get involved with projects through our collaboration with the service teams. The service teams tell us when projects are starting out and when a coach is needed. As an alternative, we have a request button on our Web site so that projects can request a coach. Coaches also become involved in projects through management communication. However, we think coaches becoming involved in the project management and the prioritization process up front should replace the hit or miss process of getting coaches onto projects. We're in the early stages of getting involved from the very beginning and becoming part of the prioritization and project management process. Ford Credit also has project management coaches. When the project management coach gets involved, we want our Unified SDM coaches to also get involved in the project.

How Do We Measure the Success of Our Coaching Services?

Project team perception was one way that we measured success. We had surveys that we conducted at the end of Elaboration and Construction. Another way we knew we were successful was when we recognized that our service teams were getting engaged earlier in the process.

Another way we knew we were successful was that there was a reduced need for coaching after the Elaboration phase. The teams were on a roll, they knew what to do, and they just went and did it. Our coaches were able to phase out at the end of Elaboration. We have had projects that finished on time and were flawlessly launched.

Where Do We Stand with Unified SDM Today?

USDM has been adopted by over 18 projects since May of 2002. We have increased the support staff due to the coaching demand, have hired another coach, and continue to have strong management support. We have also identified the need for training for requirements development. We are starting to train some of the business people so that, when they get on a project, they know how to do use cases. We want to train them up front and make them aware that it's their responsibility to lead the effort in defining requirements. We have also implemented many change requests, even though we have a log of many more to come.

What Are Some of Our Planned Enhancements?

We plan to have a standard Configuration Management Plan, which all Ford Credit projects will use. We feel that this will add a lot of value to projects. Everyone will be doing things the same way. They will have the same build structure and same directory structure, and that's going to be a real advantage for us. We also have a standard Reference Implementation model so that all of our projects start from the same architectural framework. We are looking at adding processes for outsourced efforts. We have plans to incorporate Six Sigma concepts. We have a new use case-based project plan. We also have a project staffing aide and a defect management process that will soon be incorporated into Unified SDM.

Lessons Learned

One of the things we feel that we did right is that we waited until the project management process was thoroughly institutionalized before we developed and tackled the software development process. Our project managers know what it is like to manage a project. We actually used this project management process to manage our development and deployment projects. We secured management support at all levels. The mid-management levels are very important, as they are the ones closest to the projects. We separated the development from the deployment effort. We involved SMEs from service organizations early on. We hired qualified coaches, which have been real assets. We kept things simple and supplied just-in-time training.

Mistakes Made

Like a lot of projects, we committed to dates before we had secured the appropriate resources. We waited to educate the business community until we were in a project setting. We should have given them a little up front notification. We spent too much time customizing the artifacts. We overemphasized reusing some of our existing artifacts and templates, but we almost always reverted back to RUP and made some modifications to the RUP artifacts. We spent too much time discussing our entry criteria. We had a lot of disagreement, especially with the folks at Ford. During our effort to develop this methodology, we also accepted project resources with the wrong skill set and we underestimated some of our project deliverables, especially the development of the Web site.

Conclusions

RUP is a great way to start. It's a good framework with all the tools and necessary information for an organization such as Ford. The framework was easily customizable to meet our needs. The great thing that we discovered was that integration is key. RUP is a package solution. If you bring it into your organization, you still have to do some work. You cannot just give it to a project team and tell them to use it. At Ford Credit we have our own project management process and other processes that we had to integrate. Customization is important. Most importantly, coaching was the essential ingredient for us to institutionalize a process such as RUP.

The next conclusion we drew was to keep it simple. We have project management, Six Sigma, service teams with their own processes, and RUP. We tried to be very straightforward, showing clear touch points between these processes, which resulted in fewer artifacts and limited paperwork.

In the final analysis we feel it is important to enjoy your success with the teams you are supporting by getting valuable feedback, and then incorporating it into your process.

Web site Demo -- Key Features

One of the key features of Unified SDM is the Development Case, an important artifact that we use to configure the process for a project. We have identified three different project types: new projects, which are new applications; enhancements, which consist of some scope changes for a release; and maintenance, which are bug fixes and intermediate releases.

Using the Use Case Model, we identify which use cases are done for which iterations. Then we do the initial planning, where we time box the iterations. That's how we start every project. We understand the scope of the project and then create a customized Development Case, with the understanding of what the timelines look like and how the iterations are defined. Then we develop our work plan (schedule).

Based on the type of project, we suggest which artifacts should be used. This is a collaborative team effort. As coaches, we sit with the team and discuss the needs of the project. In addition, at the end of each iteration and phase we determine if the artifacts used provided value. If the artifact did not provide value, we stop using it.

Another feature of Unified SDM is customization of the workflows for the different project types, as you might not do all the activities in a new project. For enhancement or maintenance work, you may only need certain activities; therefore, you reuse existing artifacts. For example, in the enhancement path activity, "design user interface," we might review the existing GUI to identify user interactions to see how the enhancements can be integrated into this flow. For all the workflows or disciplines, we identified key things to follow for enhancement projects.

The next key feature of the process is a Web enabled Service Team Touch Points page. We have one for Ford and one for Ford Credit because we each have different service needs. Again, service teams are organizations outside a project that provide common resources. Examples of Service Teams are the DA/DBAs, the reuse team, the framework architects, the build team, and production management. When application teams use the Service Team Touch Points Web site, they understand when in the process a service team should be contacted. They then go to the Service Team link, and approach the service team either to re-establish a contact or request a new service.

Another key feature of Unified SDM is the use of coaches for process improvement. Coaches have been a great help because they consistently and continuously give feedback on what artifacts are working, what processes are working, and what is not being used effectively. We log suggested improvements from the coaches as change requests. The change control board then says yes or no for these change requests. If the answer is yes, we then implement the change.

In addition, we keep a coaching request log. When a coach is assigned to a project, we log some metrics, such as how long the coach is estimated to be involved in the project and what the resource allocation of the coach is to that project. We plan to use this information for doing measurements. We are trying to build statistical data that will allow us to perform trend analysis. We hope to use this information to improve our process. We also get process improvement ideas from our users. They use a simple Web site feedback form to submit suggested improvements. These suggestions are then brought to the change control board.

For training we have several presentations that we give to teams as they start a project. We do not have a printed process guide. Previously, development processes at Ford included large binders, sometimes several volumes. This time we decided to publish everything on a Web site and provide downloadable pages. It's a cost-cutting measure, but the advantage is that we have something that is updated every couple of months. People are in touch with the Web site, and they get the updates as needed. We think it is an effective way of communicating the process and the knowledge within it.

Another feature of the USDM process is the Coaches' Web site. This Web site houses information for our coaches, including a documented coaching process. The process lists what coaches do when they engage in projects. It starts with what they do in Inception, as well as the other three phases. This is a guideline that our coaches follow to promote consistency in coaching. We also have a coaching certification program that we put new coaches through to make sure they understand Ford and Ford Credit organizational-specific processes so that they can consistently coach our application teams.

Our Unified SDM Web site is very similar to the RUP process tool, but is much simpler to use. RUP has many more features in it, which we use as a supplementary tool mainly for our coaches. All of our artifacts and templates are stored on the Unified SDM Web site.

Q & A

When you developed the Web site, did you use WorkBench or any other Rational tools?

The only tool that we used was the RUP process tool. We did not use WorkBench or any other tool. We developed our own Web site; RUP is not underneath it. We, as process methodologists, have RUP on our desktop, but teams do not have access to it.

Are you going to include legacy, non-OO development, in the future?

At the present time, we don't have that in our plan. The organization, Ford, also has another SDM flavor called Classic SDM, which we are using for our mainframe and waterfall type development. That's the plan now although we have thought about making some changes to Unified SDM so that we could use our RUP based process for both, but politically, that's not an option right now. At the present time, we're just using Unified SDM for development projects using Object technology.

After applying RUP, did you see an improvement in the time and quality?

We definitely did see improvements in quality. The projects were on time but even better customers were satisfied. Business customers were involved all along. They were able to test much earlier in elaboration, which resulted in less pain later in the project.

What sort of metrics did you use to define success of the methodology?

We have an ongoing effort to define a measurement model that proves the value and captures some other key metrics. The basic feedback that we have at the present time is from our customers, from our service teams, and from sessions that we conduct with management. In addition, , at the end of a project we have a lessons learned session where we get immediate responses. We have an evaluation form that our group submits to the project manager and project team members, and they provide feedback on the process and on the coaching effort.

What's been your biggest challenge to date?

This process is very simple and a lot of people want to use it, but we don't have a large enough support staff. Because it's becoming mainstream at Ford Credit, a very big organization, we don't have enough support services to provide to all those who need help. The second point is we have just looked at OO based projects, projects that use J2EE platform, and projects that use component architectures. If you're working in a big organization, all the data is stored in mainframes so it is a big challenge for us to extend this process to legacy-type projects.

How did you separate deployment from development and what do we mean by that?

The first thing we did was to develop the methodology. We took six months to develop it, and then we took another five months to deploy it to the organization. Our Web site was available at the conclusion of the development project, and then during the deployment project we set up the coaching services. We determined what the coaching procedures would be, trained our service teams, and developed agreements with our service teams.

What kind of iteration timing do the projects you coach use?

That depends on the project, but we try to keep those iterations to between two to six weeks at the maximum, and it also depends on what's involved on the project. The coaches sit down with the team to try to help determine that.


Downloadable resources


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=4474
ArticleTitle=A Case Study: Using IBM Rational Unified Process as the Methodology Framework
publish-date=04152004