Question put to Michael Ballé in his Gemba Coach column:
Management wants us to start lean in product development, but refuses to consider the difference in roles between our current project manager and a chief engineer – how important is that?
Project Manager and Chief Engineer are job titles covering different roles in different organizations. Before commenting on whether management in the questioner’s company should switch titles, we should know how they select their project managers, how much authority the project managers have, and what they are accountable for. Some companies do an outstanding job of product development under project managers; others don’t.
In some companies, as Ballé puts it, the Project Manager is just a “caretaker of the process,” producing slides full of Gantt charts, milestones, and percentages of task completion for corporate presentations, while team members work off lists of action items that are out of sync with the presentations. Organizations like the Project Management Institute promote project management as a profession, rather than a skill. Their Project Management Body of Knowledge (PMBOK) presents it as primarily a technical subject, with formal procedures and terms like “Work Breakdown Structure,” “Precedence Diagram,” or “Scope Change Control.” Purportedly applicable to any project, it’s dry reading and does not contribute much to actual projects beyond administration, which is not where problems occur.
In other companies, the project managers are engineers with technical insights who have been given the responsibility to turn these insights into new products, but are pressured by upper management to commit to unrealistic deadlines. This is the project game, where project managers are permanently in position of working desperately hard to catch up and atone for being late. Those who survive this treatment, once promoted, impose it on their successors, perpetuating it in the company culture.
The effectiveness of a project manager also depends on control of resources. A project manager who has none, and must farm out all the work to functional departments, is, strictly speaking, only a project coordinator and lucky if he or she can get all participants to produce slides in a consistent format. The position is even weaker when the participants are spread through multiple remote locations. At the opposite extreme, the project manager has a task force of members that have been detached from their departments for the duration of the project, are collocated in a project office, and do much of the project work in a dedicated war room or obeya. In the middle, you have projects with a core team of dedicated members, supported by experts with specialized knowledge who pitch in as needed.
For product development in the US, the coordinator model is largely discredited. It is perceived as slow, bureaucratic and resulting in mediocre products delivered behind schedule and over budget, while the task force model is perceived as leading to the rapid development of boldly innovative products. And dedicated, collocated teams with technically savvy leadership have given us the F117 stealth fighter from Lockheed Skunk Works under Ben Rich in 1981, the Apple Macintosh under Steve Jobs in 1984, the 1996 Ford Taurus under Dick Landgraff, the Google search engine in 1998, and many other products.
U.S. Air Force F-117A ‘Nighthawk’
Steve Jobs with original Macs
1997 Ford Taurus
One product, the Data General Eclipse MV/8000 computer in 1980, is now mostly remembered for being the subject of an influential book called The Soul of a New Machine, by journalist Tracy Kidder, to whom the project manager granted unlimited access to the development team from start to finish.
But the task force approach doesn’t always excel as expected, for several reasons:
Fit with the business. The dedicated teams may develop products that misfire in the market, or that the rest of the company struggles to manufacture and support. 30 years on, Macs are a commercial success, but they weren’t for the first 15 years, nearly bankrupted Apple and cost Steve Jobs 12 years in the wilderness. The 1996 Taurus, retrospectively, is considered a design misfire. Its dramatic looks may make it a work of art, but it didn’t sell as well as the preceding Taurus models or its competitors. It was beaten by “boring” cars like the Toyota Camry and the Honda Accord. In addition, the manufacturing representatives on the design team were unable to get some manufacturability issues addressed. For example, the cars sculptured body and doors parts were difficult to stamp.
Human resources. People enjoy working with others who have complementary skills towards a common goal. Organizing to do so, however, may require them to move, disrupting their spouses’ careers and children’s education. Joining such a team may also make them report to a leader who does not understand their professional specialties.
Transitions. With the launch of the product, the team’s work is done and it disbands. For members who have worked side-by-side and bonded for years, it can be a traumatic event, comparable in psychological impact to a divorce. But companies that use this approach rarely prepare for these transitions.
Generally speaking, we can expect the task force approach to be best for work that is closest to R&D, like finding a molecule with the potential to fight a disease agent, developing glass that can be used for a smartphone screen, or inventing a new search algorithm. It doesn’t work as well downstream from R&D, where the challenge is to turn discoveries and proof-of-concept prototypes into products that can be made and sold, and where there are many more stakeholders.
The title of Chief Engineer also needs some examination, because it is used as translation of the Japanese word Shusa (主査), which contains no reference to Engineering. It literally means Chief Investigator, and designates police chiefs as well as research chairs in labs. That the person responsible for developing a product should be called “investigator” is strange, but it does sound like the title of Principal Investigator that is used at NASA for R&D team leaders who are themselves hands-on researchers. The bottom line is that we shouldn’t use terms like Project Manager or Chief Engineer as if they had a precise, context-independent meaning.
To explain the difference between a project manager and a shusa/chief engineer, Ballé quotes Eiji Toyoda saying “The Shusa [chief engineer] is product president and company’s president’s role is to help Shusa.” For more specifics, he links to the definition of chief engineer in the LEI’s Lean Lexicon:
The term used at Toyota for the program manager with total responsibility for the development of a product line; previously known by the Japanese term shusa.
The chief engineer leads a small, dedicated team that creates the product concept, develops the business case, leads the technical design of the product, manages the development process, coordinates with production engineering and sales/marketing, and takes the product into production.
Chief engineers typically have strong technical skills that enable them to effectively lead and coordinate the technical work of engineers, designers, and other developers assigned to their projects. Their most important responsibility is to integrate the work of the development team around a coherent and compelling vision for the product.
However, chief engineers do not directly supervise most of the developers who work on their products. Most members of the development team report to managers within their own functional units (in Toyota’s case, body engineering, drive train engineering, test engineering, purchasing, and so forth). The organizational structure sets up a natural tension between the project leader (who wants to realize his product vision) and the functional units (who understand intimately what is possible).
This creative tension becomes a source of innovation as the project leaders continually push the organization into new territory according to market needs, even as the functional units try to keep the project leaders true to the organization’s technological capabilities. Also called an Entrepreneur System Designer or Deployment Leader.
The first paragraph describes a task force approach, but the third one contradicts it when it says “Most members of the development team report to managers within their own functional units.” In the coordinator approach, the “tension between the project leader and the functional units” is precisely what causes delays and compromises designs. So what is it that makes Toyota’s approach work? Perhaps that the Shusa/Chief Engineers actually are engineers, as stated in the second paragraph, as opposed to professional project managers, or product planners with no technical background, as used to be the case at GM.
In product development, the specifics of each project should drive the way it is organized, not the other way around. Product development in pharmaceuticals, electronic hardware, and software have different timelines, different resource requirements, and different technical and social challenges. There is one-size-fits-all approach, and the title given to the person in charge does not matter. A project manager by any other name, succeeds or fails the same.
Jun 12 2016
Project Manager Versus Chief Engineer: What’s The Difference?
Question put to Michael Ballé in his Gemba Coach column:
Project Manager and Chief Engineer are job titles covering different roles in different organizations. Before commenting on whether management in the questioner’s company should switch titles, we should know how they select their project managers, how much authority the project managers have, and what they are accountable for. Some companies do an outstanding job of product development under project managers; others don’t.
In some companies, as Ballé puts it, the Project Manager is just a “caretaker of the process,” producing slides full of Gantt charts, milestones, and percentages of task completion for corporate presentations, while team members work off lists of action items that are out of sync with the presentations. Organizations like the Project Management Institute promote project management as a profession, rather than a skill. Their Project Management Body of Knowledge (PMBOK) presents it as primarily a technical subject, with formal procedures and terms like “Work Breakdown Structure,” “Precedence Diagram,” or “Scope Change Control.” Purportedly applicable to any project, it’s dry reading and does not contribute much to actual projects beyond administration, which is not where problems occur.
In other companies, the project managers are engineers with technical insights who have been given the responsibility to turn these insights into new products, but are pressured by upper management to commit to unrealistic deadlines. This is the project game, where project managers are permanently in position of working desperately hard to catch up and atone for being late. Those who survive this treatment, once promoted, impose it on their successors, perpetuating it in the company culture.
The effectiveness of a project manager also depends on control of resources. A project manager who has none, and must farm out all the work to functional departments, is, strictly speaking, only a project coordinator and lucky if he or she can get all participants to produce slides in a consistent format. The position is even weaker when the participants are spread through multiple remote locations. At the opposite extreme, the project manager has a task force of members that have been detached from their departments for the duration of the project, are collocated in a project office, and do much of the project work in a dedicated war room or obeya. In the middle, you have projects with a core team of dedicated members, supported by experts with specialized knowledge who pitch in as needed.
For product development in the US, the coordinator model is largely discredited. It is perceived as slow, bureaucratic and resulting in mediocre products delivered behind schedule and over budget, while the task force model is perceived as leading to the rapid development of boldly innovative products. And dedicated, collocated teams with technically savvy leadership have given us the F117 stealth fighter from Lockheed Skunk Works under Ben Rich in 1981, the Apple Macintosh under Steve Jobs in 1984, the 1996 Ford Taurus under Dick Landgraff, the Google search engine in 1998, and many other products.
One product, the Data General Eclipse MV/8000 computer in 1980, is now mostly remembered for being the subject of an influential book called The Soul of a New Machine, by journalist Tracy Kidder, to whom the project manager granted unlimited access to the development team from start to finish.
But the task force approach doesn’t always excel as expected, for several reasons:
Generally speaking, we can expect the task force approach to be best for work that is closest to R&D, like finding a molecule with the potential to fight a disease agent, developing glass that can be used for a smartphone screen, or inventing a new search algorithm. It doesn’t work as well downstream from R&D, where the challenge is to turn discoveries and proof-of-concept prototypes into products that can be made and sold, and where there are many more stakeholders.
The title of Chief Engineer also needs some examination, because it is used as translation of the Japanese word Shusa (主査), which contains no reference to Engineering. It literally means Chief Investigator, and designates police chiefs as well as research chairs in labs. That the person responsible for developing a product should be called “investigator” is strange, but it does sound like the title of Principal Investigator that is used at NASA for R&D team leaders who are themselves hands-on researchers. The bottom line is that we shouldn’t use terms like Project Manager or Chief Engineer as if they had a precise, context-independent meaning.
To explain the difference between a project manager and a shusa/chief engineer, Ballé quotes Eiji Toyoda saying “The Shusa [chief engineer] is product president and company’s president’s role is to help Shusa.” For more specifics, he links to the definition of chief engineer in the LEI’s Lean Lexicon:
The first paragraph describes a task force approach, but the third one contradicts it when it says “Most members of the development team report to managers within their own functional units.” In the coordinator approach, the “tension between the project leader and the functional units” is precisely what causes delays and compromises designs. So what is it that makes Toyota’s approach work? Perhaps that the Shusa/Chief Engineers actually are engineers, as stated in the second paragraph, as opposed to professional project managers, or product planners with no technical background, as used to be the case at GM.
In product development, the specifics of each project should drive the way it is organized, not the other way around. Product development in pharmaceuticals, electronic hardware, and software have different timelines, different resource requirements, and different technical and social challenges. There is one-size-fits-all approach, and the title given to the person in charge does not matter. A project manager by any other name, succeeds or fails the same.
#shusa, #chiefengineer, #projectmanager, #productdevelopment
Share this:
Like this:
Related
By Michel Baudin • Management • 0 • Tags: Apple, Chief Engineer, GM, Project management, Project Manager, Shusa, Toyota