The article cites the tremendous improvements in efficiency that appear to be enabled by LiDAR surveying technology: a 10x improvement in the number of scans that can be completed in a day, 80% reduction in required field time, a half-million data points per second at speeds of 45-50 mph for ground-mobile units, and even more staggering numbers for airborne systems. However, despite these impressive performance numbers, transportation infrastructure projects have been resistant to widespread adoption of the technology.
Ted had an informative discussion with a state surveyor from the Florida Department of Transportation (FDOT). The perspectives expressed by the FDOT surveyor were tremendously valuable and drove Ted to consider a much broader view of the customer’s ecosystem. I will get to Ted’s recommendations in a moment, but first a sidebar.
Any time someone mentions ‘disruptive technology’ I immediately re-register the numerous wisdom nuggets that come from Clayton Christensen’s seminal book The Innovator’s Dilemma and its more instructional sequel The Innovator’s Solution. Of particular relevance here is Christensen’s mantra to focus on the circumstance and the job to be done rather than the customer. What exactly is the job to be done? Are you helping the customer do their job better? Are you factoring the entirety of the job? Are you asking the customer to change their job?
The last of these questions is a doozy. In many cases, and quite often it seems where LiDAR technology is involved, the customer is being asked to change their job in significant ways. From personal experience, this is a huge challenge, especially with governmental organizations. As Pip Coburn’s The Change Function articulates, those customers will only act when the pain of adoption is less than the level of their crisis. Companies with emerging technology products, no matter how stellar their performance metrics, must focus relentlessly on minimizing the pain of adoption while being leery of circumstances where the customer’s sense of urgency is limited.
- Stop the “Point Cloud Drive-bys!!” – The DOT isn’t prepared to deal with demo point clouds dropped into their laps. They need deliverables ready to insert into existing processes and workflows. Half-finished projects—even if delivered for free—aren’t helping anyone.
- Agree on a QA/QC Procedure -- Agree on the implementation of appropriate principles and make sure the DOT can evaluate LiDAR data independently.
- Identify the Model Extraction Process First – Once you know how the topography model will be extracted, placing requirements on the point cloud data becomes much easier.
- As a provider, define your respective responsibilities in the process – Understanding every aspect of mobile LiDAR technology may not be necessary for dataset customers so long as there is a QA/QC procedure in place. The customer cannot be expected to diagnose and repair errors or artifacts. Rather, they should simply be able to know see that something is not quite right with the data and alert the provider so they can remedy the problem.
Of these, #3 seems to focus on technical performance only. It may well be a useful thing to do, but I am not sure it is getting to the crux of the adoption issues. The rest of the recommendations (#1, #2 and #4) are spot on in my opinion because they demonstrate understanding of the customer’s circumstance, job and pain of adoption.
What would help at least as much, though, is to delve further into the customer’s ecosystem. For agencies like FDOT, this ecosystem is complex and entrenched. A couple examples drawn from the article should illustrate the challenge. First, FDOT pricing policies would apparently need to be modified to address the fact that they currently correlate value delivered with the amount of field time expended. This lines up with traditional surveying methods, but is 180 degrees out of phase with LiDAR methods where field time reduction is a purported benefit. Changing procurement pricing policies = pain of adoption! Working with the FDOT customers to develop an alternate pricing structure or standard will be tough sledding but is a necessary piece to reducing the pain of adoption. Is there an associated role for NSPS or ACSM?
Along these same lines, back-office processing time and IT infrastructure demands grow dramatically with the introduction of LiDAR data sets. To the extent these are borne by the customer, project budgeting benchmarks would need to be updated to reflect these additional labor and capital expenditures. Again, more pain of adoption. The article’s recommendations drive a turnkey solution mindset, and that should help. However, the customer’s ecosystem is complex and many circumstances and jobs are involved. From this perspective, LiDAR vendors that offer robust off-site data hosting, as one example, may have a real competitive advantage.
The article closes by encouraging vendors and consultants to serve as customer partners. Solution providers are asked to “do what we can to tighten up our performance wherever possible.” Amen. More than this, though, LiDAR solution providers would be well served to factor into their activities ways to really reach across and help the customer. In particular, find creative means to remove internal barriers to adoption that have little to do with the LiDAR technology itself and everything to do to with easing changes to the customer’s ecosystem. The customer’s job is truly made easier only when the entirety of their job is addressed.