By Trish Sutter

While I was working for a Japanese automaker, I was assigned to the TIGER project. The project name stood for Team Integrity Generates Earnings Recovery. I know that it makes little sense in English, but management liked TIGER because a tiger is an aggressive predator, and they intended to be aggressive with their approach to this project.
TechRepublic member Trish Sutter is currently working as a systems manager for a tier-one automotive supplier in Michigan. She is an experienced technical project manager on platforms that vary from IBM’s OS/390 Systems across a WAN to a Windows-based client/server across a LAN.
Her background is in automotive business database development. She has developed OLTP and OLAP systems that are currently in use both nationally and internationally. In this article, she shares advice on how she created a sense of ownership among end users in an effort to help a major IT project succeed.
TIGER takes shape
The objective of TIGER was to cut $2,000 from of the cost of all North American vehicles. I was given a very short deadline for project implementation. After just one month, we were required to issue a report to the president of the North American operations on the success or failure of this initiative.

I was to report the average cost savings per vehicle from concept through production. I needed a mechanism to collect and report data from design engineering and manufacturing operations that were geographically dispersed. This was a good-size automaker, so the technical infrastructure to support any application was already in place via an international WAN. In-house technical expertise allowed for the system architecture to be put in place well within the given time frame. Rapid application development tools enabled a software system to be quickly prototyped and put into a production environment as well.

Executive management was the stakeholder. Design engineering and manufacturing were the users. The real challenge that existed with this project was communication management—in part because of the diverse culture within the company.

The corporate culture
This was a Japanese company with a corporate culture that was very different from that of U.S. companies. Among all automakers, generally speaking, engineering rules. However, in this Japanese company, multiple communication chimneys existed for every department in design engineering and manufacturing. These departments were very protective of their data and they considered it a proprietary asset.

The corporate culture also allowed the company’s policy of giving departments nearly unlimited freedom to develop their own systems, the theory being that they didn’t want to restrict creativity. Very little was systematized. Cost estimates were manually gathered and reported only on a pre-selected cost model. TIGER required a major change in the way these departments were doing business.

Project planning
I had the support of upper management, which gave me the clout I needed to get everybody on board. I could have just “swung that big club” on design engineering, but the ramifications of playing it heavy-handed could have reduced TIGER’s chances for lasting success.

Previous similar projects had failed or been phased out of existence for just that reason. At the same time, I didn’t have the luxury of a lot of time or resources to gather, integrate, and customize every department’s requirements.

Fortunately, the automotive design process naturally led to the division of the project into three main phases:

  • Engineering estimates
  • Purchasing quotes
  • Actual manufacturing costs

Management’s time constraints on the project were forcing a rapidly prototyped implementation with no up-front analysis. Typical of most large projects, I had conflicting priorities I had to juggle. If I did as management wanted, I was setting up my project for ultimate failure.

Project execution
Keeping in mind that previous similar projects had failed because engineering had not been consulted, I went to bat for engineering. Here are the key steps that I took:

  1. I worked hard to convince upper management that I needed engineering’s input in this project.
  2. I gathered a committee of representatives from each of the engineering departments.
  3. I included key administrative personnel and Japanese staff. The inclusion of this staff helped greatly with communications.
  4. I kept management informed of the committee’s progress through weekly status reports.

With input from the committee, we very rapidly prototyped and placed into production an application to gather and report the TIGER progress of engineering. This application also changed the way engineering did business by systematizing their “creative” business processes.

A smart way to sell TIGER
I partnered with a Japanese staff member, and we developed a training presentation for the rollout of Phase I of TIGER. The target audience was approximately 100 engineering staff members. The training presentation was also our opportunity to really “sell” them TIGER and create a sense of ownership among the target audience. My plan included:

  • Scheduling flexible training sessions. We scheduled approximately 16 training sessions over two months to ensure that all of the engineering and support staff could attend.
  • Providing an incentive to attend training. To help increase attendance, I made sure employees would get “credit” for taking the class. The company had a mandatory annual continuing education requirement; this class satisfied that requirement.
  • Encouraging enthusiasm and synergy. Besides explaining the objectives of TIGER and training the engineers how to use it, we also set specific departmental goals and gave engineering a pep rally.
  • Inviting feedback. We started the quality assurance process by strongly encouraging feedback. At first, usage of TIGER was limited to part releases having cost changes associated with them. After we received feedback from engineering, most requests were quickly implemented. Ten months of prior part cost releases were back-loaded into the system from the mainframe database.

Take a proactive approach when complaints begin
Phase II and III were developed and implemented in a similar fashion but with more up-front analysis. System requirements were gathered from the purchasing department and manufacturing finance department. Each phase was widely publicized throughout the company.

Management loved the reporting and within two months had made it mandatory for all engineering part releases. Other departments jumped on board and became users. The cost department—which had never had a system for tracking actual costs—cautiously came on board. Downstream data departments and systems also loved the automation and systematized data flow.

Once TIGER usage became mandatory, engineering began to balk. Complaints from the worst of the engineering critics began to flow. I had seen the fate of other projects that the critics did not like. Remember, in auto companies, engineering rules.

If engineering complained loud enough and long enough, as they had in the past, TIGER would eventually be phased out. I continued to keep the lines of communication open with management. I tracked complaints. I made sure that, the majority of the time, management heard those issues from me first. When I presented concerns to management, I was always prepared with a recommended solution and a scheduled implementation.

Turning enemies into allies
I kept close communications with engineering. I followed standard quality-assurance practices of encouraging feedback. With management’s blessings, I formed a new TIGER improvement committee. Like the first committee, a representative from each engineering department and each support department was invited to participate. Except this time, the worst critics were invited first.

Engineering really did assume ownership of TIGER. They proposed solutions and negotiated among themselves for what they really needed out of TIGER. The system’s worst critics became its biggest advocates.

Lessons learned
This project could very easily have suffered the same fate as its long-forgotten predecessors. While following standard quality assurance practices was a factor in the success of this project, the key to the success was communication with both management and the engineering end-users.

At every step of the project, management understood what was happening, why it was happening, and what was going to happen next. My communications program was also dedicated to the end users taking ownership of TIGER.

We in the computer technology profession are trained in communicating with our machines. We have all of our B.S.s, M.S.s, PH.D.s, CCNPs, and MCSEs. It is taken for granted that we will be able to communicate everything sufficiently to our users and stakeholders. Too many times, good IT projects end up in the never, never land of unused systems because the users have not bought into it or do not understand how to use it. That is a lot of effort to be throwing away just because of communication issues. As an IT project manager, you must plan the communications that are necessary for the project’s success.

Summary
This project succeeded. We reduced the cost of each vehicle by $2,000. Plus, I’m proud to say, I was project manager for a system that is still in use and still benefits the company today.
In the auto manufacturing biz, engineers are kings. What kind of political landmines have you avoided to ensure success? Post a comment or, if you prefer, please send us an e-mail.