The Project Leader Studio™
The Last Planner System®
-- Roles, Reliability, and Reform
Reframe Your Role for Lean Project Delivery
I received this email today. As I prepared a reply, I decided to share it with readers of this weblog. I started answering with the mechanics of delivering projects on a lean basis, but then it occurred to me that one needs to see their role differently to deliver projects with far less waste, higher schedule and cost reliability, and so much safer.
Hi Hal,
Please help me understand:
Our role in construction projects is either general contractor or
construction manager (CM). We plan our projects using master CPM schedules
and two-week look-ahead schedules for site activities. Typically we do not
self-perform any work. How do you apply the Last Planner® and the "pull principle" in such an environment?
Bosko
Great question. As CM you are responsible for the completion of your promises to the customer. Sub contracting doesn't shift that responsibility. You are still responsible. But how do you carry out that responsibility?
Normally, a CM hires numerous Subs to perform specialty roles. These Subs interact with each other to produce the finished spaces. Each Sub naturally acts in their own interests seeking to optimize their use of their labor, equipment, and materials. This local optimization of resources leads to an overall reduction in the productivity, risk to schedule performance, and higher costs. The CM needs an approach for bringing the interests of the specialists into alignment with the promises to the customer.
The approach has three steps:
- Backward schedule just that work that adds value for the client. Produce this reverse phase schedule in conversation with the primary Subs on your project.
- On a six-week look-ahead basis prepare the work, wherewithal, and the circumstances for completing the work on the reverse phase schedule so that each task can be started and completed without interruption. Continue to review and make-ready the work adding a new week from the schedule each week.
- Have crew leaders (last planners) have public planning conversations where they promise the completion of only the work that has been prepared (ready). The weekly work plan (WWP) is the sum of the promised tasks. Use the WWP to guide what is done on a daily basis. Also use it to measure how you are performing and to learn from planning failures.
Your aim is to have tasks completed as promised. As CM you have a project manager and site superintendent for the project. Their roles shift from controlling (after-the-fact monitoring) and motivating (carrot and stick) to engaged planning, preparing, and navigating with those people performing the work. The essence of the your work as CM is to see that performers are in a position to be successful with their efforts.
Lean projects require more conversation, more engagement, and more teamwork. Your role is to be the leader that brings all that about.
Add Headlights to Your Project
The focus of the system and practices is to make work ready
Awhile back, I spent three days working with a program management team who had ~80 projects to complete in the next three years. The scope is big; budgets are tight; they're planning a shotgun start on 4-10 projects; and staffing is not in place. Oh, I forgot to mention these projects will be performed throughout the US. Historically, this group and most other companies would hole-up to do detailed planning that would be base-lined at a task level. This would allow a central control of the project. The good news is this group of people have concluded the usual approach simply would not work. In no time the central plan would be out of sync with the reality of the field. This program requires a massively distributed project planning and execution system. The key challenge is to know that project managers everywhere are planning reliably. They have settled on a lean approach to project delivery using the Last Planner® System.
So, what's so special about this approach? To start, the focus of the system and practices is to make work ready -- that as tasks are coming up to be performed all constraints to performing the task are resolved prior to the start of the task, e.g., availability of competent staff, materials, tools, specifications, authorizations, etc. The intent is to get the task in a condition that it is ready to start and finish...in lean parlance once the performer starts work the work continues until it is finished avoiding the usual wastes of demobilization and re-mobilization, waiting, and hand-offs. Earlier I wrote about should-can-will planning. This step is the "can" activity.
The next difference is organizing recurring planning conversations with those people -- last planners -- who will assign the work to performers. In this conversation the last planners make promises to complete tasks on specific days. Planning-as-promising results in dramatically increased reliability of task completion. I have seen overall project reliability jump from under 50% tasks completed as planned to over 75% tasks completed as planned just by conducting these weekly planning conversations with the last planners.
Finally, task completions are tracked just like Microsoft now recommends (see entry on 8/26/02) rather than tracking hours applied to tasks. Simple 'yes' or 'no' records are kept. Whenever a 'no' is recorded a reason for that variance is also identified. Accumulated reasons for variance can be studied and addressed so that over the life of the project some of the more prevalent causes of the variances are eliminated.
Now, back to the 80-project environment...instead of operating under the illusion that a complete master schedule gives the program manager control over the projects, the program manager in this lean environment is monitoring the quality or effectiveness of the planning system through the results that are recorded on a week-to-week basis. This offers the opportunity for the program manager to offer assistance to those project managers whose planning reliability is low or not improving. One colleague describes the process as adding headlights to the project where the usual project only has taillights: after-the-fact end-of-month reporting.
Planning is Practice for Planner-Doers
I'm in the process of writing a paper with Greg Howell titled Projects, Planning, and Promising. In the paper we are setting out to show what isn't covered today in the accepted practice of project management while offering a new definition of what needs to be covered and how that might occur. In the course of a conversation with two project managers using the Last Planner System™ this past week, I made the claim that while planning is temporal -- it has an often-short shelf-life -- the exercise of planning is a make-ready activity for the planner-doers.
Planning is a practice session that gets planner-doers ready for later on being in action. One go through a planning session is ill preparation. It is like hitting one golf ball and thinking you are ready for the game. The more often one is in planning conversations, the more practice one gets, and therefore the more ready one is to act in the future that is surely to be different (in some way) from the planning scenario. Yet, when the planners are also the doers, then these people will be prepared to plan again on-the-fly.
Unfortunately, the current practice separates planning from execution. A few smart and experienced people do the planning. Once the plan is accepted by the customer and management, then it is baselined (frozen) and published to the team. By that time the shelf-life may have expired leaving the doers in the situation that they can't be guided by the plan, yet they will be measured and controlled to it. For them it is a double whammy. They missed the practice session so they are not prepared for dealing with the unanticipated and they must still perform to the baselined plan.
What could they be doing? Planning could be connected tightly to execution. Planning cycles could be short -- one-week intervals rather than the usual 90-180 day planning intervals. Finally, they could be learning as they go, adjusting their plan as their competence increases and the future unfolds.
So What Do Dependence and Variability Have to Do with Projects?
In the usual practices of project management establishing precedence relationships is a key step in creating a network plan for the project. Along with that the planner often establishes early and late start dates and a finish date. But these dates have nothing to do with what will be done when the time comes for the task. Why? One reason is due to the variation of task completion throughout the project. We can count on each task taking a different effort and duration than was originally planned. Let's consider an example:
The engineering specification expected to take 20 hours and due on the 15th of the month actually took 30 hours and was completed on the 20th. Further, the task was planned for one person, but that person needed others' help. To the extent that other work couldn't begin 'til the spec was ready (a usual case for a spec), the project accumulates delay. Further, there is less engineering hours available than were originally planned due to the variance in effort of the engineer and the help provided by others. While it is true that some tasks take less effort than estimated, our project experience tells us that we rarely benefit from early completions. So we have a project that will require more hours and more duration than originally planned.
What can be done? First, one must identify the situations that are likely to vary from the planning estimates. Then, buffer other tasks from that variability and work to reduce the variability. How? For recurring tasks one can study the flow of work, reduce the waste, minimize ambiguity, and appropriately staff the task with necessary skills. Is this enough? No, because we have variability popping up all over. The solution then must be systemic and organizational.
Project Reliability Soars when Work Is Ready
Reliability is produced when an individual promises to complete a task
Ok, so if that makes so much sense, then why don't we systematically and organizationally address the issue of making work ready? One reason is that we act like announcing what must be done vis-a-vis a master schedule is enough for responsible people to successfully perform their tasks. That is all too often insufficient. Sure, all good projects have an always up-to-date master schedule representing what 'should' be done, but what about what 'can' be done? By 'can' I mean tasks that are in a ready state: the wherewithal has been addressed for both starting and completing the task. While this might appear to be sufficient, it still lacks one essential element: someone says it 'will' be done by a specific time. Only when an individual commits or promises to complete a task do we have a scheduled item that we can rely on. Within the lean project community we refer to this as should-can-will planning.
Are we done? Not quite yet. We don't want to leave reliability to chance on projects, therefore someone must take responsibility for seeing that the work that should be done is in a ready state so that it can be done and elicit promises from project participants so that it will be done. We call that role the project manager.
Partnering, Promising, and Project Management
Trust and communication have been the primary issues in every one of over a hundred partnering meetings I have facilitated. The meetings themselves were designed to align objectives, establish lines of communication for resolving disputes, and to develop personal cooperative relationships. The underlying premise was that all project participants could get more out of the project by cooperating than by fighting. This would be accomplished by better relationships, communication within the organization, and more rapid dispute resolution. In many cases the resulting project organization was able to work more effectively than expected and many believed the project was well served by the effort. Even so, most people moved from being wary at their first partnering session to cynicism by the third. Why was this?
I think the answer comes in two equally important parts. First, the participants assumed that the underlying approach to project management was effective and its performance was not related to the problem. As a result, nothing was changed in the way the work itself was managed. Second, participants shared a belief that trust could be built by aligning objectives and improving communications. Let me take them one at a time.
Trust develops when people make and keep commitments. But promising to "communicate" isn't as effective as promising and delivering the submittal documents on a date certain. But people on projects, even with partnering sessions, are reluctant to make specific promises for performance when they lack confidence in their ability to deliver when they know other people are unlikely to deliver the needed prerequisites. So people promise to "try" and they say delivery will be "hopefully" on time. Project performance spirals down as delays compound.
Great project plans don't stand a chance on a project without leadership.
I now believe that project management itself, particularly the separation of planning and execution, is the root cause of the problem. No specific commitment to action is necessary in current project management because action is triggered by the project plan. Senior managers make contingent promises to deliver, but people at the operating level rarely make firm promises. How can their commitments be solid if the can’t say "NO!" when the conditions for doing the job are not at hand? The very idea of allowing people to say "no" rather than to accept a deficient assignment is hard to accept in an industry built on "Can Do."
So we need to reform project management. Our project management system must enable people to work ready so those responsible can make specific promises. And we need to develop the ability to make and secure reliable promises. Project performance spirals up as the system and behavior develop together. Like love and marriage, horse and carriage, you can't have one without the other. Ah but if you do...
Never on the Rails
Projects need great leaders who put the people before the plan. Great leadership can compensate for poorly conceived projects. But great project plans don't stand a chance on a project without leadership.
This paper was compiled from the following weblog postings appearing in Reforming Project Management, authored by Hal Macomber.
The Project Leader Studio™ is one of the leadership programs offered by Lean Project Consulting, Inc. We also conduct programs for executives who are leading a lean transformation of their company's project delivery organization. Write us to learn more about the Lean Company Leadership (Shusa) Program.
© 2004 Lean Project Consulting, Inc. The Last Planner System is a registered trademark of the Lean Construction Institute. Greg Howell and Hal Macomber