Making a business case for mobility
Lessons Learned from Our Mobility Effort
Research technology likes to pose grand problems, those that are fundamentally difficult and
worthy of great effort and creativity to solve. I could describe our mobility experiences in the form
of grand mistakes, those with far reaching consequences which should be studied so as to not
repeat.
Our first grand mobility error was to pull back from an early implementation option. The vendor
for our large scale translation/conversion effort offered their view/query mobile software and data
conversion package as part of our contract. We evaluated the product extensively and
determined that it would not be a good choice for growing into our long term design, outage
management, field data collection needs. It also required the vendor to perform data translation
for each data refresh, resulting in ongoing costs for the vendor to be connected to our data base.
These would be perfectly good reasons for rejecting software in an ideal world, but by doing so
we missed a golden opportunity for making a low profile entry into mobility for our end users. We
could have put our maps in the field at very little cost and begun to engage our end users in a
dialog with this technology. As it is, we are still waiting for that first pilot project.
The second grand mistake was to attempt to incorporate field data collection for electric
distribution systems into a mobility product. The field data collection effort was a significant piece
of a large business need—we were planning to buy a utility without maps. It seemed reasonable
to further the mobility effort by developing methodology for field data collection. However, we had
to attempt a pilot on a low budget and we believed there was not time to perform the thorough
software evaluation advised above. Vendors providing data collection services had a difficult time
understanding our requirements and in developing processes to get the data into our AM/FM
system. I discovered that understanding the business requirements for field data collection was
even more daunting than resolving our technical issues. The result? Partially complete, partially
correct data collection; unsatisfactory results from tiny software development efforts.
Management was convinced that GPS technology will never work for us. Conclusion? The
technology market remains bleeding edge for merging field data collection with design software.
We went out on a limb to solve problems creatively, but the purchase of the utility with no maps
didn’t happen and as a result our problem solving was perceived as unnecessary and thus stupid
blundering.
Three strikes and you’re out? In 2001 I once again tried to join mobility with a large business
need. Data quality issues in our AM/FM system were causing problems for our recently deployed
home-grown outage management system. The problems were deemed serious enough to
develop, fund and staff a data correction project. I recommended developing mobile map book
capability merged with field data collection software for use in making field based data corrections. Software alternatives at various levels of sophistication and expense were presented
to our management oversight group in a large meeting. A more office-based manual approach to
data correction was voted in and my data correction ideas in general fell into great disfavor. We
definitely still don’t know how to make a business case for mobility.
Comparison of Success Factors
The following chart is an attempt to determine broad categories of business case success factors.
It tends to be based on our experiences (less successful) versus those of more successful
interviewees.
