Using a cross-functional team at Ford to select a corporate PM system

In manufacturing circles, Ford Motor Company is well known as a champion of employee involvement. Its unique blend of “participative management” has paid off handsomely on the factory floor, but has it worked in Ford's complex and far-flung engineering community?

Since the late 1970s, Ford's systems community developed and implemented several planning, scheduling and tracking systems. Although the applications met the needs of specific users, it became apparent as Ford moved through the 1980s that a common project management system was a must, especially if Ford intended to significantly reduce its product development time and compete with the Japanese.

In this case, the issue was not whether to develop or buy. (The project management software industry has been mature, especially on mainframes, for several years. ) The quandary was what to buy, especially since several divisions had already implemented their own packages.

According to Hans Kuschnerus, Manager of Engineering Information Systems for the North American Automotive Operations, the problem of “which way do we go with project management” reached a critical mass in early 1988. Said Kuschnerus, “On their own, users from several divisions started developing and/or implementing project management packages. Some were quite substantial in both cost and scope. The closer we looked, the more users we found. Either we acted quickly to unite them or lose them for years to their own pursuits.”

But how could Kuschnerus and his staff unite the users without discouraging them? Without overwhelming them with interminable requirements analyses? Without plunging them in the middle of a complex computer infrastructure analysis and detail?

“As we discussed the problem,” said Kuschnerus, “it became clearer that we should apply our Corporate participative management model to the situation.”

In March 1988 the Ford Corporate Mainframe Project Management Tool Selection Committee (PM Committee) was born, “With the PM Committee,” said John Mio, Manager of the Component Development Systems, “we really stretched to give the users a voice in the system selection process,” Ground rules were established up front which proved critical to the eventual success of the effort:

1. In the critical organizations, including Corporate Systems, upper management agreed to accept the recommendation of the PM Committee as long as it backed up the selection with facts.

2. The PM Committee agreed to operate as a Cross-Functions] Team (CFT), an emerging subset of the participative management model. One of the attractive facets of CFTs is that team members are encouraged to contribute and hone their best skills. PM Committee members would routinely accept responsibility for tasks “outside their formal job description” but “within their skill set” in order to get the job done.

3. An aggressive schedule was adopted to maintain user enthusiasm. Software selection had to be completed by October 5, 1988. A project management plan was developed, complete with critical path, to guide the PM Committee. “To show commitment to project management, we took a large dose of our own prescription,” stated Mio.

4. The software recommendation would be by team consensus -each member had to buy in.

5. Ann-Marie Krul, a supervisor within Mio's activity, was assigned to the role of team leader. She applied the systems “glue” that held the committee together,

By May 1st, Krul formulated a wide-ranging game plan for guiding the PM Committee to its ultimate purpose of recommending a mainframe Corporate project management software package. The plan featured two parallel phases: a Technical Benchmark Test of the candidate package and a Business Requirement Analysis for determining the best long-term fit between Ford and the software vendor.

“An important Corporate strategy is forming strong partnerships with our suppliers,” said Krul. “As with most software decisions, we knew the downstream costs would far outweigh the initial purchase price. At Ford, we feel the supplier must be considered a team member,”

At this point in many software selection efforts, the users are relegated to the roles of observers. But not at Ford. “Both Hans and John felt strongly that we had to keep the users waist deep in the process, even if it meant that we risked not touching a few systems’ bases,” said Krul.

Thus, the PM Committee designed the Technical Benchmark Test on their own, Each team member contributed a key test requirement. This meant not only what the software had to do, but the data it had to use. Said Jack Han-non, a PM Committee member, “We knew we would only feel comfortable with software that modeled our current environment across several divisions and also showed a capability to model future needs.”

Key components of the project management benchmark included:

• Systems Functionality
• Resource Management
• Multiple Project Scheduling
• Graphic/Management Reporting
• User Friendliness
• System Interface Potential at Ford
• Mainframe/Mini/Micro Interfaces

This strategy certainly stretched the software vendors. They were allotted three weeks to load their software in a Ford environment, create databases from several Ford user scenarios (these databases contained many hundreds of activities, in one case many thousands), and then produce, in a one-week fire test, a variety of complex plots and reports. All under the watchful eye of ten to twenty users.

A first hurdle was selecting the candidate vendors. Not only are there many rnainframe project management packages on the market, but the users had marked favorites. One vendor, in particular, was already entrenched in a few divisions,

“Luckily for us,” said Krul, “a local project management consulting firm had just completed an exhaustive evaluation of about 100 project management packages for a team member. This report had the objectivity we needed to gain buy-in from our users. We reviewed the report and selected four candidates with consensus of the team,”

In July 1988, the Benchmark Test begin with four vendors. To support their efforts, the PM Committee selected a project management consultant to observe, document, and evaluate the benchmark proceedings. “We felt we needed an objective record of the tests to help the users make their recommendation and show management how serious we were about project management,” said John Mio.

With considerable effort, the Benchmark Tests were conducted according to the original project management plan. The plan served to coordinate the activities of both the vendor and user teams. Briefings, meetings, debriefings, presentations, and management reports occurred repeatedly during the two-month benchmark. “We couldn't have pulled it off without our own project management plan,” said Krul. “By the end, we were driven by the schedule. We had to be.”

The activity reached a peak in late September/early October for the team. The target milestone was a two-day off-site team conference that the PM Committee scheduled for October 4 and 5 in order to arrive at a final recommendation. As the benchmark tests concluded, the consulting firm had to stretch to prepare its report, and then delivered a 400 page document evaluating the performance of each package. The vendors submitted lengthy responses to the Business Requirements Survey, and these were reviewed by the Committee in panel discussions. And, most importantly, the Committee had to prepare itself to analyze and make sense of the voluminous data and impressions of the six-month effort.

‘The conference was the toughest test of our participative management process,” said Krul. “We worked so hard to get user buy-in, but we felt if we failed to reach a consensus decision at the off-site, the team would more or less self destruct. As you can imagine, during the benchmark, users forrned strong preferences for certain packages, not to mention the solid bonds that existed before the benchmark began.”

With this in mind, the Committee brought in an internal consultant to facilitate the conference. The consultant met with the Committee beforehand and established a process for making the final decision. Each package would be measured first against a list of musts and wants determined by the users. using must/want criteria, two packages would be eliminated. Then final selection would be made through a risk analysis process (again, determined by the users).

“The off-site was both emotional and rewarding,” said John Mio. “Each participating division (six) had a main spokesperson, but at times the debate was heated with all representatives chiming in.”

“We were bound by our commitment to decide together, Only that commitment allowed the divisional team to make real sacrifices,” said Krul. “We knew it would be tough for them to go back to their management and say, ‘We've got a new Corporate standard so we're going to have to switch from our current system,’ but the commitment to the PM Committee held fast. We made a consensus decision.”

On October 5, the PM Committee recommended PROJECT/2, from Project Software and Development, Inc., as Ford's Corporate project management software. Since then, the team remains intact to face the daunting challenge of implementation. As of this date, significant progress has been made. The system is operational on the rnainframe, and pilot efforts are in process.

Hans Kuschnerus, the Manager of Engineering Information Systems,
Continued on page 59

Continued from page 36
wrapped up the effort by stating: “In line with our participative management goals, we made a real team decision. Considerable work remains, but I am confident that the selection process forged a strong cross-functional team that will persist in introducing the common project management disciplines so crucial to furthering our competitive position in bringing products to market in less time.”

Charles Fleetham is manager of the Project Management Consulting Group for Management Technologies, Inc., in Troy, Michigan. He is responsible for developing and implementing project management systems and has ten years experience in both military and commercial manufacturing environments. He is a graduate of Michigan State University.

August 1990