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.
