Dear general contractors, stop building construction management software.
During the web boom of the early 2000s, companies like Aconex, QA Software (Team Binder) and Procore launched onto the scene with new document management systems to significantly improve the way a construction document was being shared during a construction project’s lifecycle.
Leighton Contractors (now CPB), under then CEO Wal King, decided not to use Aconex and Incite was born as an in-house reactive effort.
After many years of Leighton’s own efforts, Aconex acquired Incite in 2015.
From the perspective of ongoing support, maintenance and improvement this is an extreme example that highlights the long-term cost benefit of sticking to your core competencies, and collaborating instead of trying to do everything yourself.
Dear construction companies, in particular, general contractors.
Stop building your own software.
Please, stop it now.
You don’t have to do it anymore.
It’s killing the productivity of your delivery teams on site.
Focus your thoughts and resources around building the best tunnels, roads, bridges, skyscrapers and other cool things that map to your core competencies.
Say no and do less, but better.
Disclaimer: this is not about putting down internal IT teams, and this story relates to delivery phase software tools, specifically for construction teams, and not tools for operations teams such as estimating, architecture and design (including BIM).
This is a story about what happens when a General Contractor goes from problem identification to the implementation of an in-house software solution, and why it rarely works.
First, meet Bill from Future Constructions Pty Ltd.
Bill is a Senior Project Manager at Future Constructions Pty Ltd, who are responsible for delivering critical new infrastructure such as roads, buildings, bridges and tunnels.
The story often starts when someone like Bill (a bright spark), who from within an organisation, identifies an opportunity to improve a business process using new technology.
So since Bill works for a construction company and has done for a long time, he should know what people in the field want to use and how they will use it, right?
The construction of tangible and static assets follows a completely different philosophy to the development of fluid and continuously evolving systems. They come from two different worlds.
What people like Bill don’t realise is that solving a problem is less to do with any single person’s knowledge and experience in their particular domain (such as construction), and more to do with becoming an objective and empathic former of habits.
1. The Source: A Reaction to Legacy Systems
Rewind a second, Hartley! Maybe these construction companies needed to build their own IT teams to develop their own systems because nothing was available 20 years ago?
That’s true, they did.
And as the quality of global consumer software products has increased, so too have the expectations our people on-site hold for the tools that they are asked use at work. These expectations can be both conscious and subconscious.
Due to the gap between legacy systems and continuously improving consumer software products, the best engineers and foremen are defining processes and storing information by sourcing their own tools.
Some of the most frequent concerns I have heard again and again from senior engineering managers is that their biggest concern is ‘giving people another tool to use’.
In stark contrast, I have personally observed numerous occasions of people increasing the number of notches on their tool belt with on-site workarounds in an attempt to see personal productivity gains.
Instead of worrying about another tool to use, budget owners need to stop and ask:
How often do the tools that we currently provide get used relative to how much they could and should be used?
The image above highlights some of the serial offenders.
Products like Dropbox, Evernote and Excel win because they are faster and friendlier than the typical legacy systems offered.
Possibly the funniest and most ingenious solution I have seen is from one Site Engineer who went to the effort of coding his own tricks in Excel’s VBA just to streamline his Sub-Contractor day dockets:
The point here is not to condemn these Engineers and Foremen for creating work on-site arounds because they are the bright sparks trying to do better.
The point is that the tools being provided are not meeting expectations and rarely get traction.
2. The Reaction: In-House Solutions
Based on two years of investigation, which started at site level with people on the ground and then progressed through operations, I have found that 60% of Tier 1, 2 and 3 General Contractors are currently pursuing ‘internal’ software projects for delivery phase tools.
The following five steps describe what usually happens after people like Bill have identified the opportunity to improve, and one of these projects is started:
- Within Bill’s company — Future Constructions, more people are sucked into an official or unofficial committee that forms around the new project (which is sometimes even an ‘extra’ on top of their current role).
- The majority of the upfront work to conceptualise the solution is done inside of the office by people like Bill who haven’t done this type of work before, instead of out there in the world with the people who will have to live with it.
- A scope is defined and the system is built by using current internal resources, or more commonly, an external software development contractor. Similar to construction work, rigid commercial structures are used to engage the external software development contractor, which means that the ‘internal’ product has a commercial end point.
- The external software development contractor charges a bomb and then proceeds to make even more money when everything changes over the next 2–3 years. If an internal team was used, then by this time multiple full-time resources are being consumed by a product that isn’t liked and isn’t getting used.
- The final problem, which is most severe because it is hidden, is that once the in-house solution is implemented, people don’t know if it is or isn’t ‘working’. Without adoption and usage metrics to measure success, Bill and his team are blind to their return on investment, and usually rely on what people say, instead of making decisions based on what people do.
The takeaway here is that being able to build a road that people want to drive on and take pictures of, does not mean that you can economically build construction project management software that people want to use and tell their friends about.
Coming from a former Engineer now working on building software full-time, getting it right is hard.
3. The Consequences: Competitive Disadvantages
After having consumed the brain power of people like Bill, who should of been thinking about delivery higher quality infrastructure safer and faster, Future Constructions is left with a system that has cost a load of money to build, taken even longer to ship, and hasn’t changed habits. By this stage it is also likely to already be running on outdated technology.
Speaking with the global CIO at one of the world’s top 10 General Contractors confirmed that not only do in-house solutions rarely work, but off-the-shelf products that are not tailored to the construction industry belong in the same bucket. This includes Share Point and Docusign.
We have found adoption and the subsequent derivation of value to be low when systems are not tailored to construction applications.
~ Global CIO, top 10 General Contractor based on ACV
One common misconception is: ‘this is our IP, we should keep it in-house’
In fact, when screening against core competencies, your true IP is the deep understanding your people have of complex construction methodologies, the ideas from your people when the design on the piece of paper doesn’t work and the habits that exist to keep people safe.
Unfortunately, when systems don’t change or align with people’s daily habits, you lose your true IP, as this information is transferred and therefore stored in uncontrolled tribal communication channels.
If you are really worried about your IP, it’s probably sitting in emails and spreadsheets that will never be found, a free Dropbox account, or someone’s personal Evernote.
Linking back to core competencies, and with a forward looking conclusion, the main reason you should stop building your own software is because you will not be able to keep up with the competition.
If you continue to build your own delivery phase software tools then based on the failed projects of others, you will likely be spending a lot of money and even more time on something that people don’t want to use.
If you collaborate and work together with companies and people that create and use the latest technologies as their core competency, greater adoption will allow you to get more work done with less people.
Fools learn from experience. I prefer to learn from the experience of others.
~ Otto von Bismarck
Key Takeaway: General Contractors build static assets such as roads, bridges, tunnels and buildings. Building software requires a different philosophy and as a result, when General Contractors endeavour to build their own software, an expensive and time consuming project usually results in the creation of a product that no one wants to use.