How are you capturing data?

When executed well, self-perform work returns higher margins, but it also carries significant risk. Tracking labor, equipment and productivity on site is a key to success.

Historically experienced project managers have had a 'sense' of how their projects are performing. Unfortunately there are less and less experienced project managers in our industry. In addition, commercial projects continue to increase in size and complexity. More than ever, it's important to capture data on site and do so in a way that information can be served up to project teams. Best in class software should quickly show teams how things are going (by the numbers at least), highlight where they need to take action, and give them a way to take that action.

Paper and Excel

Why are paper and excel still the leading tool for self-perform contractors to capture their full spectrum of data on site. One significant reason is flexibility. Exceptions and variations exist on even the best run projects and can only be managed by flexible tools.

Experience has taught us, once a technology tool isn't able to handle a variance, adoption drops making paper and excel the default tools.

Point Solution Tools

There is value in using best in class tools if they serve your outcome. Also many articles have been written about the challenges of siloed data from point solutions.

Over a decade ago construction technology tools started flooding the market. Every year there were literally thousands of new apps addressing very discrete items. This makes sense from a technology perspective. Once something complex is segmented into very small pieces, the requirement for variance decreases. This gave contech apps the opportunity to achieve adoption.

However, does adoption equal success? Adoption is obviously part of a technology succeeding but success for contractors is ultimately about outcomes. The question to ask should be, is data from point solutions able to help your teams achieve the outcome you are looking for?

Domains and Connected Tools

There is value in using best in class tools if they serve your outcome. Lots of people have probably heard the argument for inter-operability of technologies which can facilitate using point solutions. That makes sense and also I would suggest there are probably some data sets, or 'domains' that are so interconnected they should be considered in one tool.

For Riskcast, as we considered our vision of real-time job cost reporting and forecasting, our domain was evident. We are the labor, equipment and production tracking experts.

How do you look for domains? Software companies may not even talk about themselves in that way. We didn't, it was a customer that brought this to our attention several years ago. So how do you know when to consider a domain vs. point solution vs. platform? It's about your goals.

Knowing what tools/systems can be connected in the future is important. Knowing what matters first is more important. At a recent event our partners shared their tech stacks and the philosophy behind them. Each had very clear visions of what they were trying to accomplish and how they were getting there. Two stuck out to me, I've shared them repeatedly and I think it adds context to this discussion.

In one case, a multi-discipline GC was building the foundation of their tech stack from a project management perspective and chose a PM system first and then added tools that supported their workflows from there. Domains became evident. Document management, file sharing, labor & production tracking, payroll, resource planning etc.

In the other example, a national Trade Contractor had constructed their tech stack with two pillars, Projects and People. They saw both as key to their success and thereby selected a PM System and HR platform (incl. of payroll). Other domains and point solutions were added to support their approach. Domains included labor & production tracking and resource planning.

Note: Key functions like safety were managed in point solutions since their need was very discrete and specific to safety. Metrics were tied back and are used in visualization tools like PowerBI.

In both these examples, the contractor had staffing to 'pull' together data. If less of that exists at your company, domains matter even more because there isn't anyone to pull together data. Asking yourself what data you want to see 'together' is a way to think about domains.

Closing Thought

From an outside perspective it might be asked, why can't one tool do 'all the things.' The answer is, it depends on the outcomes contractors are looking for. Buying software that almost gets your outcomes isn't an option for many core processes. You can't get payroll mostly right. And forecasting is valuable when it's accurate.

Captured data should tell a story, one that everyone looking at can understand. Done well, technology should be in the background, facilitating decision making, communicating those decisions and enabling action.

Disclaimer: Unlike working with engineering, product or business (left brain stuff), when I am writing (right brain stuff), I try not to start with the end in mind but instead work from a target idea. Along the way, there are often many connected tangential and parallel threads on which to pull. To compose a concise article is a challenge. Each finished article leaves countless others unexplored. Your time is valuable, I hope I've inspired you with threads of your own to pull.