Enter data. Enter data. Enter data. Build.

Do project planning processes really need to be so inefficient?

Let's all imagine we’re a foreman about to deliver our daily briefing to the crew. We’ll set out what needs to be done and which crews will work where. This unremarkable scenario plays out hundreds of thousands of times every day on projects around the world.

But how do we know what our crew should be working on? Well, we know that for most projects, there are intricate and complicated schedules that plan out everything in great detail. Surely we just read off that? Well, not exactly. An engineer soon explains that the master schedule is “high level” and because it's managed by planners “doesn’t really represent what happens each day”. They explain that actually, each engineer keeps a 4 week lookahead spreadsheet for their area of the job and that any other engineers working in the area will share their spreadsheets.

Ok, so we just need to open each of the spreadsheets, work out which work is for us and that will tell us what needs to happen today? Well, not exactly. Our engineer would then explain that while the lookahead is “close” it only gets updated each week or so and in between the team holds daily meetings where the next day’s work is planned. So that's the answer! Information from the master schedule is passed to 4 week lookaheads which is in turn coordinated daily before ending up as a to-do list for each crew.

So, what software is seamlessly connecting these things so that my daily to-do list actually keeps the job moving where it should? Or, if I fall a day behind how that progress update ends up back in the master schedule?

The Real Story

Now, anyone in construction knows that there is absolutely no magical software doing this. In reality, only the slightest amount of information is transferred between these levels of plans. What is transferred is at best a “CTRL+C, CTRL+V” job and at worst is a load of manual data entry.

Recording progress is even worse. Planners patrol the site each month like some sort of crime scene detective, looking for signs of progress  to be scratched into their A3 plan. Before heading back to the office for an afternoon of entering dates into their computer they drop in with the engineers to inquire about the correct completion dates of work that finished weeks ago and, if the engineer can remember why it finished late.

The real story is that our tools and processes turn our engineers and planners into data entry robots and our plans into confusing webs of out of date documents.

An Evolving Vision

When we launched the first version of Aphex back in late 2018, we sort of assumed that this problem was outside of our core value proposition, involving lots of different software and probably not ours to solve. We needed to focus on our core idea of helping engineers build their lookahead plans.

However, thanks to the assistance, feedback and just a little pressure from our awesome users we were quickly convinced this issue needed to be solved… and by us.

Here’s the story (so far) of our journey to understanding the part Aphex should play in connecting the different versions and levels of plans across a project and an insight into our obsession with the future of construction planning.

The First Import

Understanding that many teams adopting Aphex would already have some form of plan in any number of formats like spreadsheets or gantt tools, we started with a simple import function to allow teams to move that data into Aphex. We chose CSV as the medium because it was universal and was the easiest for our users to interact with and if needed correct formatting discrepancies.

After rollout we noticed our users trying to import data… a lot of it. Mostly planners who were not only sick of using spreadsheets to consolidate detailed short-term plans but also those that realised Aphex’s simple, clear outputs were a far more efficient way of sharing plans and tracking progress than legacy systems like P6. The efforts that teams would go to in order to get ideas from the master schedule down to the teams on site highlighted a very real issue for construction teams: the interoperability between tools for construction planning from master schedule down to daily plans was borderline dysfunctional.

Over the coming months, as we studied what was happening, we noticed that as projects grew in size the volume of data being imported grew significantly. Before we knew it, larger, complex projects were importing upwards of 30,000 tasks. Yes, all in a single lookahead. This imported complexity threw up loads of new problems and questions for both us and the teams eager to close the gap between their master schedule and their site. We received a bunch of feedback from planners wanting complex filters, additional import functionality, and to use Aphex to update their master schedule. At the same time, we noticed that the more data that was imported, the harder it was for our core engineer users to actually go about making their plans.

Importing to Address the Disconnect

Our conclusion to what we were seeing was a real demand for a solution to the disconnect between master schedule planning and lookahead planning. And so we took on the challenge. Our first step in connecting the master schedule to the lookahead was to enable richer data to be imported. Metadata such as WBS, calendar, relationships and unique identifiers - not only made it easier to compare the two plans, but eliminated a large amount of data entry for engineers. To facilitate this we developed a more complex XML import function that created WBS trees and other assets alongside the tasks.

With the potential to import a project’s entire master schedule into a focused lookahead we believed teams would need the ability to control the volume of data being imported by time and their own custom filter. Once we saw users using user defined fields (UDF) to filter their plans we figured we should allow them to use the same thing to import ever richer data in order to save the end user time. So we next developed the capacity to use this same UDF mechanism to import, create and assign other attributes to work in the lookahead: owners of work, subcontractors and locations. This also meant accountability of work could now also exist in the master schedule. All in all, we wanted to create the ability for specific information in the master schedule to be passed to the lookahead without teams needing to hack around software or manually edit a CSV file.

Refining the Workflow into a Routine

Once we incorporated this top-down import approach into our onboarding and training it became the preferred approach for a significant number of projects, especially the larger and more complex. Projects were importing data from their master schedule on a monthly or quarterly cycle to give guidance and structure to the engineering teams. Observing this, we started analysing the experience of the engineer that received these plans to get on with. One obvious conclusion was that engineers know and recognise their plans, and the sudden appearance of a load of new tasks following an import could be a confronting sight, and displeasing experience at the next login.

We studied the example of agile project management and the use of a backlog as a tool to set the expectation of medium term workflow without overloading the focused sprint. This seemed to hold a lot of parallels to the relationship between a master schedule and the lookahead. Similar to a backlog, the master schedule can be changed and reprioritised independently of the immediately work in progress. At the same time, tasks in the lookahead or sprint can drive or be linked to those in the backlog.

We spent time investigating this relationship and designing solutions with the ultimate goal of making the importing and distributing of tasks a meaningful and powerful workflow as a bridge between lookahead and master schedule.

Today, our importing and distributing workflow combines all these concepts. Teams can bring in relevant information from their master schedule in less than a minute. Imported tasks are segregated from the live plan until they have been distributed out to the user that is ultimately responsible. The backlog acts as a staging place where users can review and organise their work before bringing it into their plan.

Once work is merged into the plan, it can be adjusted, rescheduled or broken down into subtasks with the powerful knowledge that Aphex tracks all the changes against the original master schedule dates.

This approach will to help you improve productivity on your project. 

What's next?

In addition to monitoring and refining this workflow, our focus is now also shifting to the flow of information in the reverse direction. What is the best way to get data from a lookahead back into a master schedule? Is it feasible to do this automatically or do planners need to review and input everything? How and where should a review of changes be undertaken prior to reentry?.. (Just a few of the thoughts that keep us up at night 😂)

If you have ideas about this or share the same trouble sleeping, we’d love to hear from you! Any input will play a part in making project teams faster and more in control of their plans and project data

Happy Importing!

‍George

‍