The Lean Product Development Toolkit is the basis of all Lean and Agile Project Management today. It includes the habit of working in Single Piece Flow (one project at a time), working in a One Room (or Obeya) Environment, to have one Chief Engineer responsible for the entire project, to engage in Concurrent Engineering and to use the typical A3 Problem Solving method for continuous improvement.
Having One Chief Engineer responsible for any project may sound too obvious. How can that be called a typical lean and agile tool? Of course we want to have one single person in charge! A ship has one captain, a company has one CEO and a project has one project leader, isn’t that always the case?
Well, often this happens NOT to be how things are organized. We find many people to have something to say about a project, about different choices and decisions, about allocation of team members, financial resources or priorities in general. Project teams are often composed of many different specialists who tend to find themselves the last authority for quality control on their specialism: Investors, designers, developers, constructors, architects, editors, marketeers, accountants, scientists, politicians, teachers and trainers, legal specialists, process specialists… They all tend to decide whether a product or service, or contribution to a project is OK or not. And ultimately, how they spend their time too.
Most project organizations today are part of what Mintzberg called ‘professional bureaucracies’, which for coordination rely on the standardization of specialists’ skills, hiring duly trained ‘Professionals’ and then giving them considerable control over their work. Where control over their own work means that these professionals work relatively independently of their colleagues, but closely with the clients that they serve. This has led to company cultures where hardly anyone has anything to say about anyone else. Often even the specialists’ managers don’t know exactly what their specialists actually do and how they spend their time. So, a specialist may be allocated to a project team for a couple of hours per week, and then feel completely free how to devote her time. She may be assigned to other projects as well, or want the back-up and approval of respected colleagues or political seniors, or need time for a holiday break just at the projects core weeks… And no one can do anything about it, unless it’s really urgent and the project manager is able to mobilize hierarchical forces to get the time and attention she wants.
For Lean and Agile Project Management to work well, it helps a lot to bring the specialists together under the responsibility of one project leader, or product owner: The Chief Engineer. So, the specialists are moved to another line of authority. But just for the duration of the project. When the project is finished, the specialists will move to another project, with yet another project leader. The Chief Engineer assumes the role of the senior authority to decide on the quality level of all contributions. Specialists still may consult with others, but ultimately it’s the Chief Engineer who decides to spend more time on one issue or on another, whether ideas or products get a go or not. It’s they who are responsible for the deadlines and the budget and it’s they who get the means to handle that responsibility.
So, to introduce the Chief Engineer can be quite a cultural change for a project organization. Specialists will have to give up their individual autonomy, Chief Engineers must assume a lot of responsibility. For both this comes with a lot more accountability too. There are no more excuses when either one fails. At least, one can’t blame other colleagues, authorities or obligations anymore. Yet the rewards are very valuable: Teams are much better at getting things done and their results to get better from one project to the next: Which is a great inspiration to most.
For the organization, often a ‘professional bureaucracy’, The One Engineer principle means that it’s necessary to design a pipeline for projects, to be ticked of in ‘Single Piece Flow’: preferably one project at a time for every team. And it needs to develop a way to prioritize and allocate resources. In other words, it must make conscious decisions about all this, rather than picking up everything that comes on its’ way. It helps a lot to design visual kanban boards for upcoming projects and visual resource planning boards, in order for all to see what will be happening next.
For the individual specialist, this means that she will be working in a much more balanced and focused way. On one thing at a time. She will start learning from other trades and specialisms, stop running from meeting to meeting, and become more responsible for her own work too. Chief Engineers are invited to learn a lot about all specialisms and to listen carefully to the opinions of their specialists. If they don’t, they fail. But they don’t need to be blocked by the official agreement of others -out of their team-.
Having One Chief Engineer leads to shorter projects and faster feedback loops: Learning curves tend to be steep. Team members and chief engineers learn quickly from each other. User Stories, playing Planning Poker and the rest of the Lean and Agile Project Management Tools help a lot for this. As does the Waypoint administration, of course.