Chicken Run Case Study Report About Ibm

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

John Wei, Maureen Field, Venkat Alladi, and Wendi Rhoad
Published on April 15, 2004

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.


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

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.

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 4 shows one of our customized workflows.

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.


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

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.

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.

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.


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.


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

[Return To Selected Articles]

March/April 1992 - By Andrew W. Singer

Is IBM’s ‘Open Door’ still ajar?

Certain management practices have an important effect on morale, efficiency, productivity, and on corporate ethical standards as well. International Business Machine Corporation’s Open Door program is arguably such a practice.

Initiated back in the 1920s by the legendary Thomas Watson Sr., the Open Door is essentially a way of dealing with employee grievances. When workers can’t get satisfaction from their immediate managers—a machinist doesn’t think he is being treated fairly, for example—they can take the problem up the organizational ladder, to the chairman of the company, if necessary.

Most of the Open Door complaints that reached Thomas Watson Jr. when he was IBM’s chairman from 1956 to 1971 could probably have been resolved at a lower management level. “But I listened anyway,” he recalls in his autobiography. “I learned an awful lot about the problems of the working man, and I gained a visceral sense about IBM that enabled me to hear a complaint and say, ‘Something’s wrong here.’”

 But recently critics have questioned whether the door really is as open as it was in the past—whether the current chairman and CEO, John F. Akers, is as prepared to “listen” as some of his predecessors. For its part, IBM asserts the Open Door program is alive and well.

‘A sham’

Two employee lawsuits against the company—one in Michigan, the other in New Jersey—have focused attention on the Open Door. Until now, the giant computer maker has been reticent about explaining the actual workings of the Open Door, at least for publication; it regards this as proprietary information.

“The Open Door is a sham,” declares Noel A. Gage, partner in the Southfield, Michigan, law firm of Gage, Beach & Ager, who represented an IBM employee, Joseph Martin, in a race discrimination lawsuit against the company.

 “The IBM Open Door is the fox watching the chicken coop,” echoes Nancy Erika Smith, partner in Smith, Mullin & Kiernan, a law firm in West Orange, New Jersey. Smith challenged the integrity of the Open Door process while representing a former employee of the company, Richard Rathemacher, in an age discrimination action, a suit she won. “I have at least 100 people who have contacted me” about grievances brought initially under the Open Door, says Smith. “The IBM Open Door is really a joke.”

Both cases attracted an unusual amount of attention because they included testimony from Akers. The IBM chairman was questioned, among other things, about the Open Door.

A formal process since the 1950s

In the Open Door process, if a complaint cannot be resolved by immediate management, then “it will be investigated by someone not in the organizational line,” an objective individual who will listen to both sides of the issue, explains Andrew McCormick, an IBM spokesperson.

It has been a formal program at the company since the 1950s. “The Open Door is part of IBM’s culture,” says McCormick. Although the majority of cases are addressed at the local level, a percentage does reach the chairman’s office. McCormick declined to specify the number.

According to IBM’s employees manual:

    “Should you have a problem which you believe the company can help solve, discuss it with your immediate manager, your manager’s manager, your personnel manager, or your branch or site manager. You will find that a frank talk with your manager is usually the easiest way to deal with the problem.

    “If the matter is not resolved or is of such a nature that you prefer not to discuss it with your location management, you should go to the senior management in your business unit.

    “Finally, if you feel that you still have not received a satisfactory answer, you may cover the matter with the chairman by mail, or personally if the chairman finds it appropriate to the resolution.”

A rubber stamp?

In a company with more than 300,000 employees, 200,000 of them in the United States, it is presumptuous, of course, to extrapolate from just two lawsuits. It is understood that within a company of IBM’s size there will always be grievances that are not happily resolved. Still, the cases cited above do shed some light on how the Open Door works in practice.

While Open Door grievances do indeed reach the Chairman’s office, John Akers’ involvement in such matters appears to be slight, even though his name appears on letters that are sent to complainants that explain the resolution of their cases. Attorney Smith puts it more bluntly:

‘‘He rubber stamps what someone else does.”

Ethikos asked IBM spokesperson McCormick if Akers ever meets personally with Open Door complainants who petition his office. “It could happen,” answers McCormick, “if he decided that [a matter] bears further investigation.”

Does the chairman, in fact, ever meet personally with complainants? “I don’t know.” As with any other business issues, the chairman must rely on his staff, McCormick says. “But if it appears to be something with which he disagrees, he will look at it further.”

The Martin case

Joseph Martin, an IBM salesperson in the Detroit area, brought a race discrimination suit against the company in the late 1980s, charging that he was given an unfair job evaluation and passed over for promotion because of his race. (IBM denied the charges, saying Martin had performance problems that resulted from substance abuse.) In 1986 he filed an Open Door grievance. About a year later, convinced that he had suffered retribution for filing his first complaint, Martin filed a second Open Door, this time to the Office of the Chairman.

In a letter addressed to Chairman Akers, Martin wrote:

    “....Mr. Akers, in my brief tenure with the IBM Corporation, I have learned that it is not the IBM way to white-wash an issue. Every ounce of training and experience I have received as an IBM employee has taught me to deal with the issue head on and in a forthright manner. It is because of this background that I am convinced that the investigation of my concerns was not handled in a forthright and objective manner. In short, the investigation was a farce.”

In a deposition taken from Chairman Akers at IBM world headquarters in Armonk, New York, July 27, 1990, Martin’s attorney, Noel Gage, tried to show that the Chairman’s response to his client’s Open Door grievance was to “put a rubber stamp to a form letter.”

    GAGE: Take a look at paragraph 12 of the sworn affidavit by Margaret Dadakis [an assistant in the Chairman’s office], please, and it states in part, does it not, sir, that Mr. Akers’ only involvement was his review of the summary and signing the letters prepared for his signature. Do you see that?

    AKERS: I do.

    GAGE: Was she telling the truth when she signed this document under oath?

    AKERS: I expect she thought she was.

Gage asks Akers to read from the Dadakis affidavit, which describes the process for handling Open Door grievances that reach the Chairman’s office:

    “Upon completion of the investigation, the investigator’s findings and recommendations are briefly summarized in a typical one-page analysis by the administrative assistant. A summary is often prepared and typically takes the form of a four by six-inch slip. In some instances, the administrative assistant’s analysis and summary is then reviewed by the executive assistant, the individual responsible for the supervision of all of the administrative assistants in the chairman’s office. The administrative assistant provides the CEO with a final draft of a letter to the complaining employee, which is prepared for the CEO’s signature.

    “If the summary is sufficient and the recommendation appears reasonable, the CEO signs the recommended letter, which is then sent to the employee; in almost all cases, the CEO does not review either the one-page analysis or the investigative report. In the normal course of business, in my experience, when Mr. Akers had a question regarding an Open Door, he typically would not review the investigative report, but would request that the administrative assistant supervising the Open Door give him a brief oral report. I specifically remember that Mr. Akers did not request such a report on Martin’s Open Door.

    GAGE: Now, my question to you is, sir, is Miss Dadakis’ sworn testimony correct wherein she says in almost all cases you don’t review either the one-page analysis or the investigative report?

    AKERS: She doesn’t really know how I do it because she’s not present when I do it.

    GAGE: I am asking you whether or not she’s told the truth.

    AKERS: I think she thinks she has.

    GAGE: And has she?

    AKERS: Well, as I just said to you, I review the summary in all cases. In some cases I review more than the summary and in some cases I have an oral discussion of the case.

    GAGE: Is it true, sir, that in almost all cases you do not review either the one-page analysis or the investigative report, yes or no?

    AKERS: In almost all cases I do not review beyond the summary.

    GAGE: Thank you.

‘A pretend circumstance’

It would be useful to know how many Open Door grievances are filed a year, and how many actually do reach the chairman’s office, but as indicated, IBM does not share this information. Whatever the number, attorney Gage is convinced that the chairman’s involvement is perfunctory. “It’s a pretend circumstance on his part,” he says in an interview. “He signs his name, or he has someone sign it for him. The implementation as promised is a sham.”

Asked about this, John Boudreaux, an IBM spokesperson, says, “I think a reference has been made by some that the chairman personally does the investigation. The policy does not say that. The chairman has the prerogative of the investigation.” Nor would it be feasible in a company the size of IBM for the chairman to involve himself in every grievance that reaches his office.

Do individuals in the company think that the chairman personally looks into their cases? “It’s hard to say what the individual expectation is,” answers IBM’s McCormick.

Could a situation arise that misleads employees like Martin into thinking that the chairman himself will examine their cases? “We can’t speak for a consensus of employees,” says Boudreaux. But employees are mistaken if they think that the chairman is personally involved in every complaint.

Do complainants, in fact, get back a form letter from the chairman? “They get back a letter with the chairman’s decision on the complaint,” answers Boudreaux.

Lincoln Electric’s open door

IBM’s isn’t the only “open door” policy in corporate America, although it is one of the oldest and best known. Lincoln Electric Company, a Cleveland-based manufacturer of arc-welding equipment—and, like IBM, a company with a reputation for good employee relations—has had an open door program for many years.

When Ethikos visited the company in 1988, President Donald F. Hastings indicated that he met personally with six to eight employees a week to discuss their grievances. Lincoln has about 2,500 employees overall.

Does Hastings still meet with that many? He admitted that he had cut the number down. “The load did get too heavy.... You have to have some sort of filtering system.”

Lincoln Electric now has a vice president of human relations who handles initial calls. Nonetheless, Hastings still meets personally with 10 to 12 open door complainants a month.

“I spoke with two people yesterday,” he says in a recent interview. “One was quite emotional.” Hastings spent about half an hour with that individual. “When they get me, I’m glad, so they know we have a system here.”

IBM’s workforce is more than one hundred times larger than Lincoln Electric’s. A question arises: If even Lincoln Electric’s president found his open door workload too heavy, what is one to make of a leviathan like IBM? Could IBM simply be too large to run an open door program that involves the chairman?

Asked about this, Hastings speculates that if a company were to run an open door process “with more than we have here”—2,500 employees—“you’d have to have a pretty good system.”

Still, “I would think that if IBM is professing this policy, that some people do [in fact] get through to Akers. And if they don’t, I would recommend he let a few get through.” The effect on the company can be quite profound when the word gets out that some employees have really seen the chairman.

That was affirmed by Thomas Watson Jr.:

    “Many employees did not want to take a complaint all the way to me, but the very existence of the Open Door was a morale builder. It made them feel free to approach a personnel manager or the man running the plant when they had a problem. As IBM grew, we tried to take more and more Open Door cases at the division-chief level, with only charges of serious mismanagement that might reflect unfavorably on IBM coming to my office. But even so my office handled two or three hundred cases each year, with each case typically taking several days to resolve. The bulk of this work fell to my administrative assistants, who were chosen among our most promising managers.... Periodically I’d see complainants myself, so that word would get around that the head man was indeed available.”

The issue of retaliation

With an Open Door program it is important that employees feel that they will not suffer retaliation for using the process. This is the case with any organizational grievance procedure, of course, including ombudsman offices. Yet here too plaintiffs’ attorneys raised questions.

“The so-called confidentiality of the Open Door is fairly non-existent,” asserts Smith. “IBM has its own personality. Either you’re an IBMer or you’re not, and once you file an Open Door it follows you around the rest of your career.” It is virtually impossible to secure advancement within the company after filing an Open Door grievance, she charges.

Asked about this, McCormick refers to an IBM document stating that management must be alert to the possibility of retaliation in such cases. “We’re sensitive to that concern,” although employees have to recognize that an Open Door action is not an anonymous complaint. “But we do restrict knowledge of it to those people who have a need to know.”

 Is there follow-up to ensure that retaliation doesn’t occur? “There’s follow-up in the sense that if a decision is made, and action taken, there is follow-up to see that the action was taken.”

 There is no formal mechanism to see that retaliation isn’t occurring, but McCormick adds that if an employee feels that bringing an Open Door results in retaliation, he or she can always bring another Open Door.

 “It’s not our experience that retaliation does occur.”

 Retaliation against employees for using the open door? “That’s felt from time to time here,” acknowledges Lincoln Electric’s Hastings, which is why “we’re careful not to let any retaliation take place. We monitor their performance-merit pay for three years” after a grievance has been brought to ensure that no negative pattern has emerged.

‘The Open Door is working’

 Overall, IBM’s Boudreaux insists the Open Door is functioning as advertised. “The Open Door is working. It’s an effective communication channel and policy.”

The company, he notes, has a high reputation for treating its employees well, and IBM is regularly included in magazine surveys of “best companies to work for,” published by Working Woman, Black Enterprise and Hispanic Magazine, among others. The number of employee lawsuits brought against the concern is low, Boudreaux notes, adding that until the Rathemacher case, IBM had never lost a discrimination lawsuit. (The Martin case was settled out of court.)

It might be anticipated, in the company’s defense, that as Big Blue restructures and deals with its present financial woes—1991 was the first year ever the firm lost money—its human resources policies, including its no-layoffs practice, will be subject to closer scrutiny. Critics will be looking for the first faltering in the company’s treatment of employees.

And perhaps the company simply has gotten too big to have an Open Door policy that runs up to the chairman of the company. But if that is the case, IBM ought to say so: To pronounce that what worked in the time of Watsons Sr. and Jr. is no longer viable today.

One would hope, however, that that is not the case—that the computer maker will preserve and sustain what, in Thomas Watson Jr.’s words, is a “most unusual method for shortening the distance between the sales man or factory man and top management.”

Andrew Singer is Co-Editor of ethikos.
Reprinted from the March/April 1992 issue of ethikos.
© 2005 Ethikos, Inc. All rights reserved.

[Return To Selected Articles]

Categories: 1

0 Replies to “Chicken Run Case Study Report About Ibm”

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *