During a lean project delivery workshop I attended a few weeks ago I became aware of a fundamental misunderstanding of the Last Planner System (LPS) by many users of it in our industry. What brought this to my attention was a question or rather an assertion by one of the workshop participants.  The workshop dealt with exploring different approaches to takt time planning and execution on projects. I don’t remember the specifics leading up to the assertion but it had something to do with the duration of the lookahead window for make-ready planning which in the particular approach to takt time planning that was under discussion was not 6-weeks. This prompted one of the attendees to point out the “fact” that this approach was different in one respect to LPS because the lookahead time horizon was different from the “LPS Standard” of 6-weeks. This caught my attention because for me it aptly illustrated a fundamental misunderstanding of LPS.

For many users LPS is a tool that must be used in exactly the same dogmatic mechanistic way on every project. If not, then “you are not doing it correctly.” This mistaken approach belies a deep understanding of LPS. For me, LPS is more of a conceptual approach to how we plan and execute our projects rather than the “10-steps for project success.” It is about understanding the conceptual underpinnings behind the various “steps” and adapting them to the particular context of the specific project. Above all for me, LPS provides a framework on the project to have the right conversations at the right time with the right people. Producing the physical artifacts of LPS, such as milestone, phase and weekly work plans, is not the objective. The objective is these critical conversations – the artifacts serve only to document them.

Back to Basics

A good place to begin the review of the conceptual underpinnings of LPS is the Current Process Benchmark for the Last Planner System documented by Glenn Ballard and Iris Tommelein of Project Production System Laboratory (P2SL). LPS was not conceived of in its totality all at one time. Rather, it evolved as a series of countermeasures to problems being observed on projects. The fundamental problem that kick started the development was the observation that most project teams had the ability to fully complete only a portion of the tasks during the week in which they had been planned for completion — the well-known “54%.” The “Weekly Work Plan,” which explicitly documented what tasks were planned for execution in the week, was developed as an aid to understanding this problem.

Make-ready Planning

This observation, then, provoked the question as to why teams were not able to fully complete what they had planned for completion. It turned out that the vast majority of the failures was caused by work not being ready for execution — missing information, materials, equipment, labor, owner decisions etc. and the cascading effect of this throughout a serial chain of tasks. This led to the “Make-ready Planning” activity of LPS in which activities in a “lookahead window” were to be explicitly made ready for execution. Through trial and error it came to be understood that a 6-week lookahead window makes sense on most projects.  This was based on two criteria: (1) most constraints (issues jeopardizing successful completion of the activity as planned) could be resolved within 6-weeks; and (2) the project team could clearly “see” 6-weeks into the future on the project. Does this mean that on every project the lookahead window has to be 6-weeks in order to be considered consistent with LPS? Several years ago I worked on a hydro-electric project in northern Ontario in the depths of a 40-degree below winter. Because of the remote location and difficulty in getting material and equipment to the site, we established an 8-week lookahead window. To make this work, the team had to be more focused on stabilizing the planned work 8 weeks out into the future rather than 6 weeks. In other circumstances maybe a 5-week or 4-week window makes sense. The bottom line is that the “right” length depends on the circumstances of the project.  Keeping in mind the objectives of make-ready planning, a project team will discover what works best on their specific project.

I will discuss other conceptual aspects of the Last Planner System in future articles.