Making a business case for mobility

Making a business case for mobility

Mary Ann Stewart, P.E.
Manager, Data Acquisition
UtiliCorp United
20 W. 9 th Street
Kansas City, MO 64105
Telephone: (816) 467-3289
Fax: (816) 467-9289
Email: mstewart@utilicorp.com

I’ve been speaking to you for the past four years about UtiliCorp’s AM/FM system. We’ve moved through a huge data conversion and applications development project to smaller applications for internal departments to a field data acquisition project. I’ve been candid about our failures and issues as well as our successes, believing lessons learned is often the most useful part of a presentation. By the lessons learned measuring stick this should be the most useful presentation to date.

We’ve tried many approaches to selling mobility in our organization. From the beginning the AM/FM staff has wanted to develop a mobile application for use by designers and other field staff. We have encountered overt, covert, and confusing logjams to developing mobility for our designers and field staff. We appear to still be nowhere near having mobility sold to potential sponsors.

This presentation is an exploration of the use of structured project management tools, the business case in particular, for developing and selling the concept of mobile technology to an organization. I’ll also present the results of interviews with successful mobile proponents and draw some comparisons in an effort to develop successful business case strategies. What’s a Business Case?

Before studying project management as a formal discipline, I thought of business cases as strictly cost-benefit analyses. You listed out everything imaginable with a financial or functional impact on your project and tried to make the case for funding the project.

A business case means many things to many organizations, but here I’m talking about the business case as a product packaged for an intended audience, designed to justify expenditures but also to perform some intangibles like triggering sponsor interest and involvement, getting buy-in. The business case is a balancing act. It must show sound research into the business needs and recommended technology, as well as discussing feasibility, timelines, risk, results. A business case must also be inspirational--well written, passionate about the technology, and succinct. A business case should be so convincing that it causes a project champion to emerge and carry the project flag for you. On a more mundane level, it should provide the information needed for management to make a go/no go decision about your project.

The following are some topics you need to address in a business case for mobile AM/FM capability for your organization.

Business Value: What business processes would a mobility project affect and by how much? Are there associated broken processes that your project could fix? At this point, it would be good to assess the possibility of integrating AM/FM mobility with like-minded mobility projects such as dispatch, meter reading, outage management, marketing applications. Does this association help or hinder your project? This may depend on technology, but also consider your project’s interface with other business process and overall business strategy.

What business requirements will the product satisfy? Document known business requirements. How have competitors responded to similar products? How pervasive is this capability among competitors? What competitive advantage will the product provide? Consider a wide range of possibilities from reduced building costs due to better designs to improved customer service when working outages. How many users are likely for the product?

Technology Questions: How mature is the product? Address issues of technology and business stability, ease of integration with existing hardware, software, networks. Is the product scalable, able to run on multiple platforms, open?

Technology issues for mobility projects are not as cut and dried as the spec sheets. Recent increase in mobile software solutions is very encouraging for the industry as a whole but makes responsible product evaluation much more time consuming and raises complex design and integration issues. As one successful early adopter to mobility put it, “Five years ago, decisions were easy. There was only one kind of mobile software that would work with our AM/FM system.” Wireless technology, seemingly an obvious desired capability for a mobile application, is also an extremely complex and rapidly changing field. The result in our organization is a perception by our mobile dispatch staff that AM/FM bandwidth issues would swamp their already stressed systems. Even if we don’t much care whether we’re wireless, we appear to be a huge problem for them if we want to integrate AM/FM with dispatch.

Operations Questions: What are the training requirements for rolling out a mobile product? Will the product function just like the desktop AM/FM product? Will the users be the same as the desktop users? Are there functions to be developed—field data collection leaps to mind—that are appropriate for the mobile application and do not currently exist in the office application? What are the internal support issues for the mobile product? What external support is available for the product? If there are to be field applications targeted for thousands of users rather than the current hundred or so, what training and support issues are raised by change in scale? Cost/Benefit Questions: What are the costs for acquisition, implementation and support of the product? What benefits can be shown? Cost reduction could include reduced headcount, reduced overhead cost, better materials management. Improved processes could include improved business response, improved management of facilities, increased employee productivity and morale, improved supplier relations, better organizational awareness of facilities issues. Increased revenue could include increased customer retention, growth of customer base, competitive advantage. What is the opportunity cost of not pursuing the project?

Risk Questions: What technical, personnel, organizational, schedule risks should be considered? What is the mitigation plan for these risks? Project risks could include the traditional project management issues of scope creep, cost overrun, time overrun, people issues. Technology risks could include performance, installation, deployment, support, infrastructure integration, interoperability, standards, communications, training. Remember that IT projects are considered to be the highest risk due to technology change and scope creep. Plan accordingly. Recommendations: Support a go, no go, or need to collect more information decision. By now the potential project sponsors should be nodding their heads along with you. There may be questions to be answered and issues to be resolved, but the weight of the decision is resting on your recommendation. You are the expert. Be convincing. If you’ve not yet convinced yourself, use the business case process to figure out the solution.

Evaluating Software for Mobility
To some extent, you should evaluate software for mobility the same way you should evaluate any other potential software implementation. A lot of this is common sense. Know your business requirements and check functionality against them. Explore fine points to the extent possible in advance of making a selection. Keep your mind open to new products and developments but don’t strive to be bleeding edge with your technology. Know your vendor suppliers and assess them for ease of business relationship and long term stability in the marketplace.

What’s unique about evaluating software for a mobile AM/FM implementation? I would contend that the range of business applications for the software may be more diverse than for a more traditional software application. Mobility may duplicate office AM/FM used for design, provide field data acquisition capabilities, push out view only map books to the field, incorporate GPS locations with data capture, provide data correction and update capabilities, provide data for working outages. If you’re trying to incorporate some or all of this functionality, bear in mind that the mobility software may have to change to accommodate changes in any of the office technology and change will likely be constant.

One approach to software analysis is Kepner-Tregoe Decision Analysis. Decision Analysis is particularly good when it is unclear which is the correct choice from a number of alternatives. The analysis process assists you in clarifying purpose, evaluating alternatives, assessing risks and benefits, and ultimately making a decision. The methodology provides a common language and approach that removes decision making from the realm of personal preference. It provides organized ways of applying critical skills to an issue.

The basic format for a Decision Analysis table is to first list your Must requirements and evaluate each product as Go or No Go with respect to the musts. A No Go evaluation will immediately eliminate a product from the running. Remaining products will also be evaluated against your Want requirements and given weighted scores. You can use these ratings to determine the most appropriate products.

We had a constantly changing array of Musts and Wants to feed into the evaluation process. This was not helpful for getting on with Decision Analysis but did serve to highlight the issue of the volatility of mobility project champions and issues. We did have good team consensus around using the Decision Analysis process for software evaluation.

Some Good Experiences with Deploying Mobility
I’ve had the opportunity to interview AM/FM leadership associated with early adoption of mobility at gas and electric utilities. Some distinctive patterns have emerged respective to the business needs of each utility type. We have discussed the possibility of unique qualities associated with early adoption of mobility vs. more recent adoption but to date we can only speculate on what these differences might be.

In one of the successful early mobility electric utility sites, improved customer service drove the needs for the application. Planners were able to successfully present a business case with this slant to their management. Next in importance was keeping the facilities database current, another issue of great concern to management. Continuous support from senior management was considered one of the critical success factors at this site. There was little shift in staffing or business drivers associated with the project. This continuity allowed the technical staff to be very focused on the project and to “just do it.” They were also able to resist the temptation to go big, instead remaining small and hands on with building the application.

The early mobility gas utility site emphasized regulatory compliance and safety as most critical issues. They were able to obtain early buy in for mobility implementation from upper management based on these business needs. It was possible to quantify savings in costs of printing paper maps (with a good sized town paying for its annual software lease in the cost savings from one set of maps). Mobility issues were somewhat unique due to the clear business need for field staff to have access to the data. As with the electric site, very simple technology solutions (for example, nightly downloads and uploads by wireless LAN) proved very satisfactory for the field staff and were easy to support.

Given all the above, is mobility a hard sell at business case time? Yes, because no matter how important mobility is to upper management, so are many other projects. Increasingly, IT projects must compete for funding with other projects and be subjected to formal competitive evaluation processes. Projected cost savings remain a touchy issue, especially as more businesses are asking project sponsors to commit to these savings in advance in their budgets. Some successful implementations did not attempt to quantify savings in timeliness of maps in trucks, data integrity, FTE reduction due to automation, or labor saved in not duplicating processes. Yet in other proposed mobility projects, it was possible to show savings from quicker billing that more than offset the technology costs.

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.