We use cookies to provide you with a better experience. By continuing to browse the site you are agreeing to our use of cookies in accordance with our Cookie Policy.
February in Wisconsin, as I’ve written in the past, can be excruciatingly long. The holidays have come and gone, your new-year-new-me attitude has faded, and March madness feels like a lifetime away. The month of February has always gotten to me. It’s mathematically the shortest month of the year. It is even the shortest during these anomalous leap years —such as we will experience this year — but it just seems to last forever.
Science tells us that time is relative. I’m not going to do a deep dive into why this is true, but do yourself a favor and check out some YouTube videos on this topic.
In reflecting on time during a project, do you ever wonder why some stages of the project feel as if they go faster than others? Why do specs always seem to take forever? The master planning phase seems to fly by. The relationship is comparable to studying for a test versus taking a test. When studying, time seems to crawl and when taking the test, time feels like its flying.
Most projects are built on a precise schedule. The idea that certain things feel as if they go faster than others doesn’t really sit well with a sophisticated construction manager.
I wanted to share with you some ideas our project teams are working on that might help you with planning time on your project. We are trying to pull plan all our tasks in master planning, design, BIM and then construction phases of a project.
Pull planning was developed by the Lean Construction Institute (LCI) as a part of the Laster Planner System and has been highly successful in the construction world as construction management teams live and breathe a lean culture that demands every single task be planned. The culture of consistency and reduction of waste has transformed project delivery methods that have demanded new thinking by design teams.
Since 2010, HGA Architects and Engineers have been doing “pull schedules” on projects — or at least we thought we were. What I was really doing was letting others know my work plan by using Post-its. There was little pull from a deliverable and the default reasoning was, “This is the way we’ve always done it.”
Fast forward to the past five years, where the industry has been demanding actual pull planning on projects during design. We’ve gone from a team of engineers who say, “This is when we can get our design done,” to a team that now understands a meaningful transaction between a task owner and a task customer.
LCI has promoted these methods to create behaviors on a project that are habitual in nature and reliable in outcomes. It’s a beautiful dance to watch when two people are negotiating what it is the customer needs to continue his work as the task owner ponders the duration to complete said task. The customer is the person receiving the product/output from your task.
The Uncomfort Zone
As an engineer, this is such a practical and attractive concept. Plan the work and work the plan — it’s in our DNA to work like this. If this is the case, why are so many engineers skeptical of the pull schedule concept? I have three theories on this; I will add the caveat that I am being presumptuous and stereotyping engineers. You don’t need to e-mail me; I’m sure you’re not a typical engineer.
The first theory of why engineers don’t like pull schedules is because of the idea of giving only some of the information to their teammates. Pull planning inherently causes you to parcel out work and that is scary for an engineer. We have to trust that our teammates aren’t going to misuse the information. This might be tough for someone who was burned in the past, giving conceptual ideas to other disciplines.
The second theory — pull planning forces you to commit to your teammates, in public, on paper. Oh, and typically you’re committing to something after just recently learning when you’re going to be informed. There’s a hastiness to the way pull planning can happen and sometimes it forces teammates to commit to things on the spot. It is something typical engineers hate. A social pressure decision will cause them to not like pull planning.
The history of design changes is at the crux of the third theory. In pull planning, we know that for everything to work out as planned, you need everyone to complete their tasks as promised. When looking at the engineering tasks on a project, the architectural design team is usually the predecessor for information. Understanding the design process is critical to understanding why pull planning is a concern for the engineering community.
Architects are some of the most brilliant artists the world has ever seen. Their canvas is a building they get to show off every day to potentially millions of people. How or why would we ever want to rush that?
There are possibly other reasons why engineers might not like pull planning, but these are the three prevalent in my experiences. The good news for us is that they are all resolvable. The bad news is it is going to take some work and buy-in.
Solutions for Skeptics
For theory No. 1, the engineer is nervous about giving the team information that could potentially change. I’ve learned it is constructive to have an active dialogue with the team. When we were struggling to get a team member to break down the task, our Lean Coach (who was leading the pull schedule population) asked this person five different questions about the task until he finally got the person to explain the minimum amount of information to complete a task and move on.
This is great, but it also came with anxiety for the engineer. I believe the key to reducing this anxiety is explaining to your team how or why things might change. If the MEP team is committing to space in the mechanical room, you’re going to want to tell the rest of the group why this space could potentially change.
The solution for No. 1 is to have dialogue and explain your risks to the team. If verbal communication still doesn’t make you feel comfortable, then send your team the list of risks associated with the pull schedule.
In the case of theory No. 2, there is nothing written in pull planning law that says you have to sign off on everything on the spot. This is where the comment of putting extra work comes into play. When preparing for a pull schedule session, we tell our teams to start to plan out their work. It will definitely help with the number of on-the-spot commitments you will have to make as an engineer.
When doing the plumbing design for an office building, you should know everything you need to design the storm system. So, before a pull planning session, you know you’re going to be asked when you can have the storm mains sized and elevated for your civil teammate. Anticipating this, you should plan out how long this will take.
You also should do your homework on what you need to finish the storm design. It would probably be superstructure laid out, roof design complete, general footing layout and the known location of where civil wants you to take the storm main. With this information, you will be able to tell the team the storm main and the invert.
So, to resolve theory No. 2, we can be more confident with some prep work. Next time you’re at a pull schedule session, you can pick out the people who didn’t do any homework, as they’re probably the ones sweating over every decision.
Theory No. 3 gets the easiest solution. You’re nervous about design changes affecting your ability to commit to the pull schedule when you really should be embracing the team’s ability to also commit to you. If everything has been pulled from the end deliverable, we can easily show the design team how the change will affect our ability to deliver on the new changes.
For example, if the storm system took three days to design and the architect redesigns the whole roof system, you can share with them that once it’s done, it will take three days for you to get the civil team a new design. The solution to theory No. 3 is to use the pull schedule to your benefit.
Time is the most valuable thing we have. I truly believe pull planning has brought a level of rigor to planning on our projects that will allow us to maximize our time. As engineers, pull planning should be embraced. A process in which the goal is to create reliable promises amongst teammates, eliminate waste and further define deliverables aligns very well with the engineering community.
Pull planning and the idea of building construction becoming leaner is not a fad and is going to be a common practice on your projects. This February, if you find yourself in my shoes waiting for March, I suggest you take some time to learn about pull planning and how it can improve your project.