The Best Project Tools Preserve Understanding, Not Calculations

One of the things that has always frustrated me about construction projects is how much useful thinking disappears when the project finishes.

Over the years I've developed a lot of models to help me understand different problems. Some have been relatively straightforward spreadsheets, while others have become fairly complicated models looking at earthworks, commercial performance, change or different delivery scenarios. Some have taken weeks or even months to develop and, in a few cases, have become quite important to the way the project understands a particular issue.

The problem is what happens afterwards.

Projects are temporary by nature. They finish, teams disperse and people move on to something else. The person who developed the model may leave the business or simply no longer be around when somebody needs to change it. Eventually something breaks, the source data changes, or nobody is quite confident enough to touch it. A model which might have contained a considerable amount of useful thinking gradually becomes another spreadsheet sitting on a shared drive.

Then another project encounters a similar problem and somebody starts building another one.

I've seen this happen enough times that I've started to think differently about what was actually valuable in those models in the first place. For a long time I probably thought the value was the model itself. Looking back, I don't think it was.

An earthworks model is a good example. The formulas calculating quantities, haul distances or costs aren't necessarily the clever part. The difficult bit is understanding how the earthworks operation actually works. Where is the material coming from? Where can it go? What did the estimate assume would happen? What constraints exist on site? What happens to the overall operation when one of those assumptions turns out to be wrong?

By the time you've built a useful model, you've usually had to work through quite a lot of those questions. The spreadsheet is really just where that understanding ends up being captured.

I've found much the same with commercial models. Knowing that an operation is losing money isn't particularly difficult; the monthly accounts will eventually tell you that. What interests me is understanding why it is losing money and, preferably, understanding it early enough that somebody can still do something about it.

That might mean looking at output against the estimate, the resources being used, changes in methodology, plant utilisation, programme constraints or something happening elsewhere on the project which is affecting the operation. Normally it isn't one number that gives you the answer. You have to bring several pieces of information together before the picture starts to make sense.

That is probably why I've always been more interested in models than reports. A report generally gives you an answer based on the information available when it was produced. A good model gives you somewhere to investigate. You can change an assumption, test a different scenario, follow something that doesn't look right and gradually understand what is actually happening.

Once I started looking at models in that way, the problem of them disappearing at the end of projects bothered me more.

Construction is actually very good at solving difficult problems. What I don't think we're always particularly good at is retaining the thinking that went into solving them. A project can spend months developing a way of analysing something, only for the next project to start again with a blank spreadsheet because the knowledge remained with the individuals involved rather than becoming something the wider business could reuse.

Sending somebody the old spreadsheet doesn't necessarily solve that either. Unless they understand why it was built, what assumptions sit behind it and what the person developing it was trying to understand, you've really preserved the file rather than the knowledge.

That doesn't mean everything needs to become software. I still build spreadsheets and probably always will. For a one-off problem, a spreadsheet may be exactly the right answer and there is no point turning every useful calculation into an application.

It becomes more interesting when the same problem keeps appearing.

If several projects are trying to understand the same thing, there is an opportunity to take what was learned from the original model and turn it into something reusable. The information can be structured consistently, the logic can be made visible and, importantly, the system doesn't have to stop developing just because the first project has finished with it.

The next project will almost certainly find something the first one didn't. Different people will use it differently, assumptions will be challenged and weaknesses will become apparent. Instead of that being a reason to build another model, it becomes a reason to improve the existing system. Over time you're not just carrying a tool from one project to another — you're carrying the accumulated learning from the projects that have used it.

A lot of what I've been developing through Neartime Reporting has come about in exactly that way. The XER Inspector is a recent example. It didn't start because I decided there was a market for another piece of planning software. It started because I had a practical problem on a live project. We had Compensation Events that needed programme input, limited planning resource available to support them and contractual timescales that weren't going to wait until somebody had time.

My first instinct in that situation is normally to find some way of analysing the problem myself. In the past that would probably have meant another fairly complicated spreadsheet. This time I started thinking about whether the underlying problem was actually specific to this project.

It clearly wasn't.

Projects everywhere have specialist resources that become bottlenecks. Commercial people need to understand programme information without pretending to be planners. Planners should be spending their time on the things that genuinely require planning expertise rather than necessarily doing every piece of initial investigation themselves.

That doesn't mean building something which replaces the planner. It means capturing enough of the underlying logic to allow somebody else to do more of the investigation before the planner becomes involved.

The same thinking sits behind some of the other systems I've been developing. They have generally started with something that irritated me on a project, followed by me trying to understand why it was happening and then wondering whether the solution could be made useful somewhere else.

I think that's a more interesting opportunity for construction technology than simply digitising existing processes. Putting a spreadsheet into a browser doesn't automatically make it better. The important question is what understanding went into creating that spreadsheet in the first place, and whether that understanding can be retained and improved rather than disappearing when the project team moves on.

There will always be project-specific models because projects will always have project-specific problems. I don't think that should change.

But when we find ourselves solving the same problem repeatedly, we should probably be asking whether the valuable part of the previous solution was ever the spreadsheet at all.

More often than not, I suspect it was the thinking behind it.

 Back to Insights