Using Agile Strategy to Improve VDC Coordination
I have been looking at how to apply agile strategies in construction for a long time. Over the last year, I have gotten to work with a great number of software companies and have witnessed the effectiveness of the agile development cycle. I can imagine how those companies would operate if they used our conventional construction strategies and, except for maybe a modified pull planning process, I think they would quickly sink, and even pull planning would not be as effective as the agile strategy they employ. I thought in applying it I would start with what I know best and that’s Virtual Design and Construction (VDC). I have visited a good number of VDC departments over the last year. I had discussions on the subject of an agile strategy with a lot of gifted VDC managers and designers. My takeaway was that most of the VDC departments had similar problems to the one I used to manage. In general, the biggest Issues came down to time and the ability to stay on schedule, and that is a problem agile strategy is made to address.
As a good first goal, I want to address what I see as the Big Three problems that lead to missed schedule, rework and mistakes.
The Big Three could be expanded, but I think they represent the major categories well. They are:
Missing Information — This can be any information that is critical to the VDC process — Specs, RFI’s, submittals, information from other stakeholders or trades.
Changes and Revision — Changes or revisions to the coordination either initiated by owners, other trades, field conditions, or mistakes and omissions.
Shell Issues — The Architectural and structure design teams are often not active within the coordination phase. They may be in production or critical to the client, so they are considered static components to be worked around. This workaround can heavily impact schedule, and at times not even be possible.
The big three have a lot of parallels to software and hardware development so I think drawing from those tools and processes we are likely able to make some real improvements. I am going to refer to this modified process as Agile VDC (AVDC). The critical push of AVDC is maintaining schedule while resolving the big three. It also provides a way to capture and measure the big three for any given job.
AVDC in its simplest form adds two items into the conventional VDC process: a backlog and sprint style issue resolution cycle. I would note at this point that to do AVDC you must capture and track issues that occur throughout coordination. There are several pieces of software targeted at doing that, both in the software development and the construction space. I am partial to Revizto but have also used Trello, Jira, Airtable even Excel. The point is simply to generate, categorize, and track coordination issues. If you are not doing that, then you may find just adding that to your coordination SOP will vastly improve your outcomes.
In its simplest form, the AVDC cycle works as follows: The Lead Project Coordinator (LPC) works the critical path and builds a backlog of issues. That backlog is prioritized then handed off to a team led by a Secondary Project Coordinator (SPC) for resolution in a short, high-intensity session called a sprint. This is similar to a Scrum for those familiar with that process.
Drilling down a little, the Lead Project Coordinator (LPC) is tasked with critical path coordination as required by the project schedule. The LPC, however, is no longer responsible for any of the big three items if that item is going to cause a schedule impact that leads to a missed due date. Any big three issues that do affect schedule goals go in the backlog. Once in backlog, the issue will either result in a schedule change and go back to the LPC for resolution or go to a Sprint. LPCs are no longer responsible for the correction of issues outside of the critical path including revisions and even mistakes. All revisions and mistakes that would cause schedule deviation will be put in a backlog. This means that the LPC will meet deadlines but may do so with a backlog left over.
So why is that better than just doing issues as they arise?
Backlogs are measurable, detailed, and represent the issues that need to be resolved to finish an area. The issues left in the backlog at the various due dates should have clear schedule impacts and be deserving of discussion. In addition, the LPC has reached the end of the area or task they are not guessing at what is left to be done. They are simply completing what can be done before addressing problems. Many problems work themselves out as work progresses, and the LPC may trim their own backlog as they get further down the line and understand more about the project. So, providing a way to reach the end of a task is critical.
There are three ways to resolve backlog issues. The first is through a change to the schedule. The backlog’s primary purpose is to maintain a schedule, so if the schedule is changed to accommodate extra work, the issues can come off the backlog. The second is resolution outside VDC. This is most relevant to information issues. The PM or other team members should be reviewing backlog issues to resolve them for the team. Once resolved, those issues can be moved back to the LPC and primary coordination team. The last option is to go to the sprint.
In a sprint, a selected team intensely focuses on eliminating the backlog. For an AVDC sprint, a Secondary Project Coordinator (SPC) is selected and assigned to lead the sprint team. That team will meet on a set schedule and for a fixed period to focus entirely on resolving the backlog. The SPC should either be an LPC from a different project or an experienced coordinator who is very effective at resolving issues. If the other projects are using AVDC the LPCs will be fresh and likely ready for a change of pace, especially if the sprint is the priority — and they need to be. Being on a sprint means no outside project interrupts your sprint team and they are 100% focused on the backlog. This is easier said than done and I would suggest that in the beginning, you assign a senior PM to run interference for the group. It is also important to involve people outside VDC in the sprint if the issues require either PM or engineer involvement.
In a perfect world, projects would run conventionally with the backlog for eight days and sprint for two days. The sprints would begin with a short meeting between the LPC on the project and the SPC selected for the sprint. They would prioritize the backlog and then the SPC would get his team started. The team doing the sprint should be a separate group from the day-to-day team on the job. The lack of familiarity with the job will be offset by several other benefits, which I will discuss in future articles. The two days would be focused only on backlog issues and would end with an assessment of the remaining backlog and the scheduling of the next sprint.
Using AVCD to build in a cycle of conventional work and issues resolution has proven successful in many other fields and it seems likely to me that it will significantly improve the VDC process in our industry. This article is not intended to be instructions for making your backlog or running your sprints. I intend to put out other articles and videos on the process as I am able. I consider this article the MVP (minimum viable product) for the idea of AVDC and hope to get your feedback online, at Dork-A-Thon, MCAA Tech Convention and at other convention during the year.
