Friday, August 14, 2020
Lean pull planning programs empower teams to break down silos and collaborate for improved project outcomes. Using pull planning, teams optimize workflows, maximize resources, and completely eliminate non-value-added activities; these are wins that often aren't realized using traditional push planning approaches.
Remember back to the last time your team produced a project plan; you may have had a few intense meetings, sent a few emails, and asked your project scheduler to create a draft schedule. The scheduler probably worked diligently with the project management and engineering teams to define their optimal sequence of activities. Or perhaps, a project engineer wrote a schedule for the project based on what they knew and sent it out for execution.
The result; a long and complicated Gantt chart. It probably illustrated a target start date, target end date, and hundreds of activities sequenced within that window. After being sent out for review, it may have undergone some updates that led to final approval. The driving force behind this schedule was the early stakeholder activities (project management for the General Contractor and engineering). Does this story sound familiar? And how did that turn out? Most likely, multiple revisions were made to the schedule and even the revisions were wrong. Meetings were held weekly to update and status the schedule, and everyone in the meeting knew the schedule was wrong, but they had to go through the process. After the meeting, the superintendents would get together in the field and coordinate how they were really going to build the project and the project got built. Maybe a better approach would be to have the superintendents that are building the project, work together up front and develop the schedule.
Push Planning
Traditional push planning approaches are commonly employed by project teams. Push planning entails the forward sequencing of activities from a defined start date. A single kickoff activity, or group of activities, leads to the identification and sequencing of additional successor activities. The plan is developed in a forward motion. The result is a plan that is pushed through the project phases to completion; in this approach, the activities of early groups drive the activities of later groups.
Push planning, while commonly leveraged, has one distinct drawback; plans are driven forward by the sequencing of activities by early project stakeholders. Using complex CPM scheduling tools, project schedulers spend hours, days, or even weeks, preparing a complete schedule that painstakingly details all logical relationships, lag periods, start dates, and end dates. But this schedule is produced in a vacuum, devoid of the critical input and interface of the end-users and responsible supervisors. The result is a plan that isn't bought into, and sometimes isn't even supported, by parties that come to the table later in the project. Accountability is fleeting when construction tasks are dictated by engineering deliverable sequencing rather than the optimal path of execution.
Push planning is common because it is quick. Plans can be produced from templated schedules and buy-in is rapid as each sub-team is responsible for providing input only for their own work scope. Push plans can be produced like puzzle pieces and fit together, or so it would seem.
The problem is that these puzzle pieces often don't fit at all, especially as the project progresses. The scheduler, a single entity, must try to compile these distinct plans, recognize conflicts, adjust and level resources, and ensure plan achievability. Sound logical? It's not; and it's not the scheduler's fault. The reason that push-planning programs alone don't produce desired results is that 90% of the team knowledge isn't being tapped into while the plan is being created. Rather than engaging supervisors across the value stream to develop an integrated plan to accomplish their work, we are slowly building up parameters that restrict the ways they can accomplish their work. The distinction is marked.
How is Pull Planning Different?
When creating Pull Plans, the complicated scheduling software is replaced by the people who will build the project huddled around in a room to generate the plan. A Kanban is a whiteboard with project phases delineated as columns (using marker lines or tape). Column phases may represent hours, days, weeks, or months. Teams create sticky notes that denote tasks, or more precisely - conditions of satisfaction (CoS). Those sticky notes are affixed to the whiteboard and sequenced to produce a flow that optimizes the order of execution. Sticky notes are used for ease of movement and re-sequencing where needed.
Pull planning takes an opposite approach to push planning; teams identify the target end date and place the final project activity on the Kanban board. Working backward, teams identify predecessor activities and sequence them to reduce the total project duration while streamlining workflows across stakeholder groups. Identifying handoffs between team members is key to ensuring validation of stakeholder commitments and achievability of the overall plan duration.
Therefore, pull planning is driven by the needs of the end-user, while push planning is driven by the activities of the first user.
Breaking Down Walls
Silos are common on projects. Team members often fail to communicate effectively, share information and innovations, or even have adversarial relationships. Silos are detrimental to project success; eliminating them requires a shift in the way we plan and execute activities.
In push planning, the scheduler becomes the single point of contact, reaching out to gather information from multiple stakeholder groups. The scheduler becomes the gatekeeper of the plan; the result is often a lack of team engagement, buy-in, and ownership over activity durations, sequencing, or commitments. Essentially, push planning reinforces existing silos.
If you are working on a project that is leveraging push planning, ask any construction superintendent if they are working to the project schedule. You will be surprised how many times you will get a chuckle or an eye roll as a result. A lack of engagement in the development of the plan yields a lack of plan ownership, regardless of the stakeholder in question.
Effective pull planning programs are messy, integrative, and dynamic. Key stakeholders (that are responsible to meet the conditions of satisfaction) are brought into planning sessions. They participate directly in the development of the plan. They share ideas, offer alternatives, and make commitments. They are active rather than passive participants; they own the process.
Commitments are Key
Commitments are a key facet of pull planning programs. Stakeholders work collaboratively, committing to start dates, end dates, and total task durations. Those commitments are made in person, and individual and team performance is tracked based on adherence to those commitments. Reports are produced to determine the percentage of promises complete for each stakeholder. Those that can't or don't meet their performance targets are highlighted in project reports.
Common Misconceptions
Pull planning is often misunderstood as phased backward pass scheduling. Many industry stakeholders incorrectly assume that a phased schedule that is produced in a backward pass motion is a pull plan. This assumption is fundamentally incorrect. Effective pull planning requires the collaboration and engagement of end-users. If your scheduler is simply starting with the final activity and working backward to sequence tasks, you aren't effectively using pull planning.
We will continue to explore pull planning in future articles. Stay Tuned.
Ted Smith
Comments