[mmonihan]

Having built a field management system in the construction industry[1], I can confirm, it's a tough market. And, most of it comes down to getting in front of people. A lot of my time is spent going to trade shows and pitching, just like Tracy did, when I'm not coding.

There's a stigma that this industry is full of people who resist technology, but I really don't think that's the case. People in this industry resist change because change is risky. There's too much money at stake, and delays associated with new technology can ruin an entire job. Paper processes are usually terrible, but you're never going to have to battle wi-fi connectivity to flip through your spec, or experience your pencil throwing a 500 when you fill out a safety analysis. It takes a while for anyone in the field to get comfortable with the pros and cons of a new process versus a paper process that's worked for years.

It's changing incredibly quickly, though. There's a lot of new products getting funded, and a big opportunity to integrate between them.

[1] http://safety.voyager.vc/

[prions]

Exactly- risk aversion is the driving force. When I was a civil engineer, paper was king. It's wasteful printing 5x copies of one 1000+ page spec, but it's reliable.

I did write a shop drawing automation program when I worked at the office. There was resistance to it at first, but getting the right people on board and demonstrating the improvements helped a lot to get it all the way to the executives of the company. During my push to get my software adopted I learned a lot similar to your perspective; many professionals don't dislike new technology, but they're unwilling to put their name beside it unless it's proven to work.

A lot of young engineers like myself want to walk in on the first day and start shaking things up. But working in a slower, more risk averse field has made me a better software engineer by tempering some of those impulses to adopt the latest and greatest tech. Taking a pragmatic and proven route will nearly always get you reliable and predictable results.

[dsfyu404ed]

>A lot of young engineers like myself want to walk in on the first day and start shaking things up. But working in a slower, more risk averse field has made me a better software engineer by tempering some of those impulses to adopt the latest and greatest tech. Taking a pragmatic and proven route will nearly always get you reliable and predictable results.

x2

[6stringmerc]

Nice to see your perspective, this is gold! I've worked in the B2B and risk management side of Construction and I'd like to chime in - as a verification - of the market in Construction. It's a multi-billion dollar per month industry in every major City. Property and development and investment are where big money plays. REITs and up.

Two things Construction cares about: Safety & Shrink.

Safety in the human cost of skilled labor - and settling workplace claims of deaths on the job / innocent bystanders / loss of property (on and on and on) - is a giant consideration. Claims are more expensive than, well, anything because they're unpredictable. Can technology help? Yeah, but looking at a tablet ain't gonna do it, unless it's like 30 cameras on the job site...which leads to...

Shrink. That's what it was called in the Big Box store. Losses due to theft. It could be something small, or something kind of big. Or maybe somebody on the job site tipped off a local relative with a good crew who have the brass ones to haul off a couple generators if they're not lifted up on a crane over the weekend...again, there's a nice middle ground of disruption for technology, but it has to be grounded in real world learning.

Sketching out a few ideas on a white board will probably not be anywhere close to the 3 years I consulted with Field Safety Managers, Claims Managers, Managing Directors who speak at Conferences to this day...I was the guy who could write it down, put it in images, because Construction people have their own world.

I'll never forget one story a highly accomplished team leader said on a conference call about Safety: "Last week at the new XXXX auto plant, installing a 4 ton brace that was freshly painted, the crew was so worried about scratching the paint that one got jammed between the brace and the wall and lost his life. Priorities are our concern."

TL;DR: Nobody makes a good brisket in a microwave.

[Mtinie]

I agree with your thesis and would like to anecdotally expand on your second point. It's been my experience that people in the construction industries -- and I say this as someone who comes from a multi-generational family of builders -- tend to be on the leading edge of technology adoption.

For example:

- Quick adoption of pagers, cell phones (originally the physically installed "car phones", later, Motorola's "brick"), Sprint's "Direct Connect", to now using iPhone or Android-based devices for on-site visual status updates.

- GPS and RFID vehicle, inventory and tool tracking.

- Computer-assisted design (CAD) and manufacturing (CAM).

Not to mention all sorts of back-office software and tools.

All of these things need to be vetted in light of risk mitigation, as you stated. Most builders I know have been burned multiple times in the past when tools and processes fail, so they tend to hesitate before jumping to the "next-greatest-thing-ever".

[JusticeJuice]

> People in this industry resist change because change is risky

I'm researching a similar field, where risk of change is the biggest barrier to improvement. What have you been doing to combat this / how do you reduce the risk? What makes a user willing to take the jump?

[mmonihan]

Early on, it's meant spending months on implementation, hand-holding the first few users so they can become evangelists within the company. It's not a lot of work, it's just over a long period of time.

I track usage metrics every day and routinely message power users to ask what may be keeping others from adopting, asking non-users if they've been trained, and asking execs if they have evangelized from the top down.

So, you have to hit everyone over a long period of time.

[rhizome]

Paper processes are usually terrible, but you're never going to have to battle wi-fi connectivity...

I noticed this point made in the article as well. Are cellular tablets simply out of the question?

[mmonihan]

The company I work with gives everyone a verizon cell hotspot and an android tablet. These work fine in city areas where this company does a lot of utility work.

But, when you do an install of electric wire towers on a mountain, you might not have cell connectivity. Most apps get by this by saving data locally, and then transmitting on the next connection.

[rhizome]

Well of course remote work is going to have its own challenges, but I don't get the feeling that that's what's going on here. So, besides corner cases, is there any reason not to consider cellular tablets in the construction world?

[Mtinie]

Job sites, especially those in the throes of major structural construction, are a horrible place if you are seeking consistent wifi or cellular coverage.

Generally: The thick concrete walls, exposed rebar, and intentional and unintentional geometric structural elements combine to form a giant Faraday-esque electromagnetic exclusion zone. Even with wifi repeaters on each floor you aren't assured a connection.

I worked for LATISTA as a product designer and spent a significant amount of time on-site speaking with users about this exact problem. It's getting better, especially with the larger construction management / development firms, but it's not a solved problem (unless your firm spends a significant amount on portable IT infrastructure).

[rhizome]

Thank you.

[mmonihan]

I guess my point is that there are some crews where all their work is remote and subject to spotty cell service. It all depends on the kind of work the company is doing. So, for some companies, it's not a corner case at all, it's a factor in the primary use case.

[rubidium]

These aren't corner cases. It's everyday experience of any field worker. Basements, shielded building, unreliable cellular, remote locations, etc...

[jaredhansen]

s/wifi/cellular/

Doesn't change much.

[rhizome]

Are you saying that cellular and wifi networks are equal in reliability, range, and ease of administration? That's the criteria I'm using.

[andrewflnr]

They don't have to be "equal" in any sense. All that matters is whether they meet some (probably ill-defined) threshold of reliability. In at least some circumstances, neither does, even if cellular gets closer.