Drive Business Value with the Three A’s of ArcGIS
Years ago, I worked at a power company for one of the most interesting people I can remember. Bob was brilliant, articulate—and paranoid. He didn’t trust anyone. He believed that many of the folks working for him were goofing off all the time. (Not me, of course!) He would even sneak around the city in the middle of the night to try to catch night shift crews in the act of not working.
Bob had a number of operations groups working for him. I ran one of those groups. He was also in charge of an administrative group that performed a variety of functions such as checking police detail invoices, preparing dispatcher reports, and filing circuit maps. Bob hated this group. He couldn’t understand why it even existed.
One day, Bob had had enough. He decided to simply blow up the department. All his managers—myself included—warned him that this was a risky move. We believed that if the group failed to exist, something bad was sure to happen. A critical report or regulation filing would go missing. We could get into trouble. Surely, this department was doing valuable work for the company.
He didn’t care. According to Bob, we’d find out soon enough whether we needed this department. Then—and only then—would he reinstate the group. Bob pulled the trigger. He gave the manager an early retirement package, fired a couple of supervisors, and reassigned all the clerical staff to open positions elsewhere in the organization.
A funny thing happened: nothing.
WWBD (what would Bob do)?
There were no complaints of people not getting reports; there were no increased fees and no fines. Bob was right. The department did not add any business value to the company. The department had simply added complexity to operations. Some of the work was a carry-over from the time before computers and GIS. Long ago, some unknown person had created tasks that were needed at the time. That legacy continued for years until no one actually knew why the tasks were being performed.
I always think back to Bob whenever I run into situations that seem too complex. I wonder what Bob would do if he were in charge. Once in a while, a request for proposal for a GIS project will come across my desk with requirements that are exceedingly complex. Often, the only way to meet the requirements is to customize the software.
Overly customized software built on top of commercial software is a nightmare to maintain, troubleshoot, and upgrade. CIOs will demand that all software be commercial off-the-shelf solutions; however, many times, the complex requirements make that impossible.
As good, obedient vendors and consultants, we work hard to meet the customer’s requirements. We all know that the risk of problems, performance issues, and downtime increases with every line of custom code. But, unlike Bob, we don’t recommend that the customer blow up the requirements into something simple.
Simple Scales, Complexity Fails—Easy to Remember, Hard to Do
I was recently at a project review meeting where we were discussing the workflow for a mobile GIS solution for about 500 fieldworkers. It seemed to me that the workflow was complicated; it involved replication, uploading data, adding redline layers, and synchronizing changes. So I asked a simple question: What are the fieldworkers going to do with the system?
Everyone was quiet until one of the developers piped up saying, “We don’t know.” Then another project member said that he recalled that there were more than 90 use cases for the mobile GIS. Having run electric operations, I couldn’t imagine more than a handful of necessary functions.
Finally, after probing the requirements, the project member stated that the customer wanted the mobile workers to have every function that the office editors had—just in case. Further, the system administrators wanted all the editing functionality turned off for the fieldworkers except the ability to create field markups, or redlines. The end result was that the customer was going to get a heavy client for each fieldworker with nearly one hundred functions with a complete replica of the GIS in the field, yet no ability to edit it. I couldn’t imagine the training needed. The back-end processing would be onerous and expensive.
If he were around, Bob would have blown up the system. (By the way, the requirements were written six years ago, before the advent of the cloud or smartphones or tablets.)
Clarity in Simplicity
While there are many valid reasons to add functionality to GIS or any automation system, we have learned lessons from IT leaders including Steve Jobs of Apple and Scott Morehouse of Esri: keeping things simple and focused is best. Simplicity drives productivity, lowers training costs, reduces costly mistakes, and improves morale. Instead of customization, utilities can simply configure the ArcGIS platform and give fieldworkers only what they need.
The ArcGIS platform is the epitome of simplifying. It masters three powerful yet simple things—the three A’s:
Access—the ability to easily use authoritative information from any device, anywhere, anytime
Awareness—the ability to get information from internal and external sources with no heavy lifting
Analytics—the ability to make sense out of disparate data, such as when customers are unhappy and have had a bunch of power failures or high bills
Throughout the next several weeks, I’ll devote a separate post to each of these A’s. Check back here on Esri Insider to catch each post.
By leveraging the three A’s of the ArcGIS platform, companies can blow up complexity and insist on simplicity. Bob would be proud.