Confessions of a real champion
After 20 years in the automotive industry, I now have adequate experience to look back and see that many of the problems of product design, development, and manufacturing in the ’70s are similar to today's problems. However, the big difference lies in the way companies approach solutions to these problems.
Project Management: Part 1
In 1991, as Valeo Engine Cooling's sales director for North America, I was accompanied by our general manager and branch vice president to a meeting with the executives at our No. 1 customer. We knew the purpose of the meeting was to inform us that the latest contract was awarded to our Japanese competitors, which would be a first entry for them at this customer. Yet, rather than the traditional “you just weren't as competitive” speech, we were politely, but firmly, told that our company was not capable of managing multiple projects and that the car manufacturers' platform groups were losing faith in our abilities.
As our customer ran down a checklist of recent problems, including late sample deliveries, incorrect drawings, product validation test failure, constant changeover in manpower, launch difficulties, and many others, I knew they were right. Having worked in engineering, both at a car manufacturer and supplier, and now in sales, I constantly saw how even the simplest of projects often became confused and complicated due to the company's complexity or lack of communication with the various functional departments involved. It wasn't that the product was a new invention that caused problems, it was more likely that many of the operational managers and workers, both at the supplier and customer, all experienced difficulty obtaining information. In the past, my belief was that the main cause of these types of problems lay in the large bureaucratic organizations of the automotive manufacturers. But here I was, listening to the automotive manufacturers describing these same symptoms to us, the supplier.
Further, with the automotive manufacturers' trend for outsourcing the complete product design and development, I knew we had to simplify our organization or we would become so overwhelmed that our current systems would continue to break down and result in the loss of more business to the competitors.
At about this same time, Valeo embarked upon its own strategy to achieve customer satisfaction throughout its 80 facilities in 15 countries around the world. Focusing on the five-core strategy of involvement of Personnel, Production Systems, Supplier Integration, Constant Innovation, and Total Quality, corporate guidelines were issued that explained the policies and requirements for each of these cores. As I read the Constant Innovation Charter, it was clear that Valeo wanted to create a universal program management system. Up to this point, all divisions and branches could manage however they wanted. Since the late ’80s, we had been evolving in our division from the traditional “Salesman” approach…pick up the customer blueprints and drop them off in Manufacturing, to the “Sales Engineer” approach…once business is obtained, send in the engineer to develop the design Sales has sold, to “Multi-Function Interface”…two or three people interfacing with various customer departments to input and collect information for all projects.
At this time, the theory of these various approaches to managing a program sounded logical to management, and could be referred to as “program management.” In retrospect, however, I can say that none of these approaches addressed our basic problem…that of communication and discipline. Instead, they were just window-dressing to cover the traditional “over-the-wall” or “smokestack” activity everyone was comfortable with. Their success, or failure, was more related to the mixtures of personalities and political climate at any given time.
The direction of our Constant Innovation Charter was to manage all programs in a structured development process, utilizing cross-functional teams with a specific team leader or program manager. This required that program development schedules would be clearly broken down into the various functional tasks that would support the customer milestone dates. Furthermore, a systematic review with upper management at key points during the program would be a requirement. As I studied this document, I became convinced that this methodology would put Valeo on the right track to consistently managing the projects, not only in areas of timing, but also cost and quality. The means needed were not complex or new ideas but rather more of an organized approach of the disorganized methods that many people were using. At that time, I felt Valeo would be operating with higher efficiency and customer satisfaction would be on the rise in about six months to a year.
Project Management: Part 2
It is easy for people or companies to talk about change and commitments to new ways of doing business but oftentimes the good intentions get lost in the day-to-day activities. The good news was that Valeo's management was putting a high level of commitment toward its focus on the five-core strategy. Among other things, the company created an auditing function that would measure progress toward implementing the new policies. The auditing function reported directly to the president, which helped management in all divisions understand that this was going to be more than slogans to hang on the walls of the offices and factories.
To support the program management function, our division made some specific changes to its organization. First, it was decided that we needed to organize program management as a specific activity, not just a job various people performed part-time. Thus, we created fulltime program managers with the clear responsibility for a program's cost, quality, and delivery. This responsibility included leading cross-function teams and being the primary interface with the customer. The full-time program manager approach is very important to success because it eliminates the conflict that occurs if you piggyback program management on functional work with one individual.
Generally, the piggybacking approach resulted in continued tradeoffs, and since we were trying to implement a program management system that was not yet well defined, the results suffered in both areas. Further, it was decided that upper management's involvement was required. This responsibility was eventually assigned to me, so the Sales Department became the Sales and Program Management Department. Other options considered included creating a separate department, combining program management with engineering, or combining program management with some other department.
However, in our industry, Sales is responsible to the Customer Purchasing Department. It is at this interface that we see a broad spectrum of information constantly being exchanged. By combining sales with program management, we theorized that the best opportunity for efficient communication with all aspects of programs would occur. The concept of a separate program management department may be a possibility in the future but was decided against based upon the appearance of more bureaucracy.
It is also important to realize that support and guidance for program management was required at the director level in order to provide support and get recognition of the program management activity. The program manager was to be responsible for the program cost, quality, and delivery, but would have no authority over the functional departments. By having director involvement to negotiate functional responsiveness, we were able to ensure functional recognition of this program management activity.
Initially, we identified six program managers. Some were drafted from the Engineering Department and others from the Sales Department. Armed with these forces as well as a corporate charter that outlined the responsibility and required results of program management, we were ready to enter the new way of doing business.
It did not take long to realize that we did not know how to implement the mechanics of something with which we had no experience. We needed to obtain some professional program management help or the process would take too long. Initially, we felt some two-day training seminars by Dr. Harold Kerzner would put us on the right track. After attending a Kerzner seminar with the program managers, I came to two conclusions: (1) the program management training needed to be provided to more than just program managers, and (2) Dr. Kerzner's approach was a good overview but we needed specific tools for our specific company.
Relative to Point 1 above, we moved forward by enrolling people from all functional areas in the seminar. This not only helped them understand that program management was going to be a reality, but also how they fit into this activity. Relative to Point 2, we decided to hire a consulting company to assist us in setting up our specific program management operating structure.
Once we contracted with a program management consultant, we decided to focus on two pilot programs to lead the development of our program management technologies and procedures. Using the consultant on a part-time basis, the two pilot programs worked through the details of what program management would do and how our people would do it. Through this detail focus, which lasted about one year, we constructed a single program management process that would be applied to all programs. Several fundamentals that came out of our pilot programs were:
- Cross-functional teams need to be empowered with the responsibility and authority to manage the programs.
- Functional department heads must give their team representatives guidance and support so that they can be effective team members.
- Functional team members must focus on achieving their functional tasks on time.
- All functional areas must participate in identifying their required tasks in order to achieve a successful program.
- The program manager must focus on program tasks, i.e., schedule status, meeting quality levels, cost tracking, and delivery.
- Software is mandatory in tracking and reporting the constantly changing tasks, schedules, and targets. But, software is not the silver bullet in implementing program management…it's only a tool to be used for calculation and reporting.
- The program manager must be recognized by upper management and team members as the responsible person for program success.
The way I would summarize the lessons learned is that program management is everyone's responsibility, not just the program manager's. This is akin to the notion that quality is everyone's responsibility, not just the quality manager's.
After the completion of the pilot programs, I envisioned each program manager spending 30 percent of his or her time at the customer, 20 percent leading and interfacing with the product development teams, 40 percent managing the project by reviewing progress on tasks, costs, quality, and 10 percent inputting data into the computer software. This assumption was unrealistic. The problem was the software—not that the software was bad, rather that, like many software packages, you need to develop a higher level of expertise to achieve efficient usage. Also, software can be input many ways and each person can interpret input and output several ways. The result was that the program managers were spending approximately 50 percent of their time working on the computer trying to make inputs and consolidate results.
To address the software issue and get the program managers back to managing their programs, I instituted the concept of a “program specialist.” This person would provide computer services to the program managers. The specialist would maintain our generic work breakdown structure, set up specific work breakdown structures for each program manager, and provide progress tracking and reports. Not only did this allow the program manager more time to focus on managing the program but also allowed for standard input and output of data on all programs.
Beyond reorganization, it was important to imbed the program management methodology across all functional areas so that all team members participated in reporting the progress of these program tasks. Although there were many ways considered to accomplish this, we developed a simple process using a “four-week window.” Through our software, we were able to sort all tasks by individual across all programs.
Our four-week window showed the active tasks that each person had previously signed up to complete during the current four-week period along with the scheduled start and finish dates of these tasks. A hard copy of this information was provided to each person and each person was required to simply mark up the current status in achieving these tasks. The mark-up was given back to the project specialist, who input the updated data to show progress vs. schedule. This then became the basis for the program manager to know where each person was relative to where their tasks should have been and where they needed to go.
There are many other ways scheduling progress can be compiled, such as having functional managers provide input rather than team members or using electronic data input to automate and update schedules. The four-week-window approach was selected based on the recognition that the functional manager's inputting progress would counteract empowering the team members. Further, input via EDI is a popular idea but, in reality, it has a couple of drawbacks: all employees don't have computers; and having all employees input their progress revisits the same problem the program manager's had with EDI.
Project Management: Part 3
Although the four-week window was a simple process, its initial effectiveness left a lot to be desired. The problem was that even though it was simple, people needed to be trained and we needed the support from functional managers to ensure that team members would respond. To address this issue, we formulated a one-day seminar for both managers and subordinates that presented how the program management system was structured, a self-evaluation of our current performance, the benefits and operations of the four-week window, and an open discussion of areas for improvement. After this seminar, the response rate improved but we were struggling at approximately the 70 percent level.
To place further attention on the response rates, we compiled a “scorecard” that identifies the percent of on-time responses by team and by individual. These scorecards are provided to the functional managers to assist in identifying individuals who many need further training in understanding the program management system.
Although we were able to address our responsiveness problems on the four-week window report in our division, when the program involves other divisions or branches, responses remain low. The reasons for this may be associated to our branches and divisions being autonomous business units and each having its own level of development in program management. The less sophisticated in the development of program management procedures, the less responsive they generally were.
As my organization increased the number of programs to which we applied the program management methodology, I found it was becoming more and more difficult to manage the information. Even though all program managers were following the same procedures, finding pertinent information on a specific program was often difficult.
Part of the problem was based on the fact that our program managers frequently interface with the customer. Thus, the manager was frequently out of the office or conducting cross-functional team meetings in one or another of our facilities and therefore not available.
To resolve this issue, I explained my concern to the program managers and asked them what solutions they could provide. The result of their brainstorming and analysis was to create what we called a “projects book” for each program. The concept was that critical program documents would be placed in the book and the book would reside in my office. It was the responsibility of each program manager to maintain the book with the current information and revisions to previous documents. The key to this approach was that for each program, the critical documents could be referenced quickly, without waiting for a program manager to return or riffling through the program files. The project book did not contain the complete history of the program nor was it meant to replace the program manager's own filing system. Presently, our project book contains 46 documents that I feel can give me confidence that a program is progressing in all areas. These documents range from a copy of our quotation, listing of functional team members, budgets and quality plans, to the signed copies of our management's “phase transition” approval. Although, at times, not all project books are fully up to date, I feel the books have provided a solution to the original problem of overseeing the 25 to 30 programs we are managing.
For me, training the program managers and organizing procedures will not make a working program management system. Program management is everyone's responsibility! All functional areas need to be actively involved. In line with our corporate charter, management visibility is required.
Two management committees were created. The first, the Project Validation Committee, is made up of functional managers and is chaired by the director of program management. The second, the Project Management Committee, consists of the division president and the division directors. The Project Validation Committee is responsible for validating the progress of the programs and helping resolve problems that the team or program manager may have. The Project Management Committee is responsible for setting corporate strategy and addressing problems that cannot be resolved by the Project Validation Committee.
For several months we struggled to develop an effective Project Validation Committee report format. First we tried having each program manager report a status on his or her projects. With the high number of programs and the desire to solve each problem, these committee meetings lasted all day and never succeeded in reviewing all projects. Additionally, we found that the manufacturing plants only cared about products they would produce, not ones that the other plants would produce. Thus, we were wasting a lot of resources with little benefit.
We broke the Project Validation Committee into three separate committees, one for each of our manufacturing locations. Additionally, we structured the meeting to focus only on the identified problems of each program and a general “open issue list” that focuses on cross-functional issues which are not program-specific.
The program manager attends a Project Validation Committee meeting only if a problem is so complex or urgent that the information cannot be communicated via the standard report that I present to the committee. The standard report focuses on two areas: (1) timing charts for customer deliveries, and (2) a one-page status report using red, green, and yellow indicators for the subjects of economics, technology, quality, and timing.
This has improved the effectiveness of the Project Validation Committee and helps ensure program information is being passed horizontally and vertically throughout the organization.
Project Validation Committee meetings are held monthly. Another assignment of this committee is to approve the programs “phase transition.” Our program development process is based on a five-phase approach concept, design, adaptation, tooling, production. The Project Validation Committee must agree that all tasks in each phase have been completed prior to entering the next phase. For these transition meetings, the program manager and application engineer are required to present their project and documentation that verifies the program is ready to pass on to the next phase.
Today, our phase transition meetings are working better than a year ago. An important problem we overcame was that phase transitions were constantly rescheduled to a later date because the program manager did not want to conduct the phase transition until all work was completed. Regrettably, we were missing the point! If the work was not completed, this was the very reason the phase transition meeting was needed. When the Project Validation Committee was informed that the tasks were not up to date, then the functional managers had to take actions to resolve the problem. By delaying phase transitions, we were guaranteeing that customer milestones would be missed later in the program. I think our organization now understands this problem. We now have organized a firm phase transition meeting schedule. Program managers are not allowed to revise the meeting date unless the customer has changed the milestones. We then conduct the meeting and focus on the problem.
Project Management: Part 4
As program management activity spread from our two pilot programs to others, we started to evaluate and measure progress vs. budgets and time lines. We discovered weaknesses in our system in that we were allowing too much creativity in work breakdown structures by the program managers. This resulted in our inability to easily summarize information from multiple programs. Tasks were not identified in a consistent manner and some critical tasks were not being included. So, although we could look at individual programs, we could not take advantage of total resource or cost analysis.
To address this weakness, we decided to reengineer the generic work breakdown structure. This time we placed the emphasis not only on ensuring that correct tasks were included but also on identifying time durations and standard costs for each task. This, coupled with a fixed code for each task, allows consolidation of information across multi-projects. With this capability, we can provide forecasts of resources for the various departments and, by the same method, make comparisons of our progress vs. budgets and schedules.
Since the output we were searching for was to benefit the functional managers, it was important to have them involved in the reengineering process. Through a series of meetings with all departments, a more extensive and detailed generic work breakdown structure was created. Helpful in creating this new work breakdown structure were our experiences (good and bad) in working with the work breakdown structure from the existing programs. We now have a work breakdown structure that is set up for the most complex of programs. When the program manager begins a new program, this generic work breakdown structure is used as the starting point for a specific work breakdown structure.
The program manager then simplifies the program based upon the number of subcomponents in the specific program. The fewer components, the more tasks that can be eliminated from the generic. Upon completion of this customizing, the program manager is required to review the work breakdown structure with each functional manager for confirmation of the tasks, duration time, and standard costs. This results in a uniform approach to all programs by all program managers.
After almost four years since the start of our program management implementation, I view the experience as successful, although it did grow more slowly than I had originally hoped. The responsibilities of the program manager have been established and are recognized throughout our organization. The functional manager and department members have accepted the concept of matrix reporting and actually view program management as adding value to the process. Our customer relationships have improved dramatically. We are now identified as a source for all new programs and have even replaced some competition. Our program management activity has demonstrated our capability to handle multiple projects and meet customer expectations. Many customers now require program management for new programs.
The job of implementing program management at Valeo is not finished. Now that we've progressed to the point where we are having measurable success, it becomes apparent that more can be done. From the corporate level, yearly audits of our division's progress on the complete five-core strategies helps us to keep improvement plans high on the priority list. Training of employees (especially new hires), simplifying reporting, keeping reports relevant, and improvements on change management will be our next goals…But I eagerly look forward to the continual improvements of our program management process.
William T. Borowski is the director of sales and program management at Valeo Engine Cooling, a Division of Valeo S.A. He has a B.S. in electrical engineering from Lawrence Institute of Technology and is a member of the Great Lakes PMI Chapter.
PM Network • August 1995