. --.- -i

CHBIS DEBMODY AND PHIL RAGSDALE

Assessing options and costsvensus benefits of a mobile wonk

management solution

THIS FIRST IN A SERIES OF ARTICLES

ON A VABIETY OF REAL.WOBLD

UTILITY EXPEHIENCES DETAILS HOW

A METBOPOLITAN UTILITYAND ITS

CONSULTANTS WOBKED TOGETHER

TOARBIVEATAN OPTIMUM

WOBK MOBILIZATION SOLUTION,

he pace of change in information technology (IT) over the past

four years has been nothing short of breathtaking. A dynamicinnovation cycle has produced quantum leaps in mobile comput-ing, system virtualization, data integration, and public dataservices such as Google and Bing maps, all of which present water

utilities with advanced options for improving customer care and drivingoperational efficiencies. At the same time, utilities face higher maintenance

costs for aging infrastructure, employee retirement and the accompanying loss

of talent, demands for greater fiscal accountabiliry and rising customer expec-

tations. ITithin this context, how can an IT manager help chart a directionthat respects the forces at play and addresses the related challenges?

This article, the first in a series, shares the practical experience andinsights gained by Denver Water of Denver, Colo., and The ConfluenceGroup of Boulder, Colo., as they worked side by side to address these chal-lenges. The series will look at several topics, including Il project cost-ben-efit analysis, enterprise mobility buy-versus.build, data integration, projectmethodologies, and adaptation to business change. The authors' goal is tohighlight what has worked (and not worked) by using real-world examples

and retrospective insights.

DERMOOY & RAGSDALEAUGUST 2012 | JOURNALAWWA . 104:8 |

WOBK MOBITIZATION PROJECT

PROVIDED A STARTING POINT

Of the projects tackled by Denver'Water and The Confluence Groupover the past several years, nonehad greater benefit potential thanthe mobilization of work for Den-ver'Water field personnel. Everyone

"knows" the benefits from suchprojects can include increased vis-ibility into utility workers' perfor-mance of tasks, reduced paper-work, improved data capture andquality, faster emergency response,

and better customer service. Giventhat funds for large IT projectsare becoming increasingly scarce,

however, "knowing" mobilizationbrings benefits may not be suffi-cient. 'sfater utilities may need todefine and justify the benefits thataccrue with mobile solutions.

How does a utility go aboutproving these benefits? Just as

important, how does the justifica-tion inform the mobile product orplatform choices and project execu-tion? This article addresses these

two questions through a reviewof Denver 'Water's journey to fullenterprise mobility.

Existing mobile applications had

become costly and outmoded. Likemany utilities, Denver'Water starteddown the road to field mobilizationsome years ago with the incrementaladoption of various mobile woqkmanagement solutions. IndePen-dently, each system performed com-petently. As a whole, however, thepatchwork of solutions provedcostly to maintain because each

application reflected the idiosyncra-sies of the department for which itwas implemented, the vendors whosupplied the solutions, and the sys-

tems with which the mobile applica-tions integrated. Compoundingthese legacy challenges, a new breed

of smartphones and tablets in theconsumer market had amplifieduser expectations for operabilitybeyond what had been historicallypossible. The mobile computinginvestments from previous yearswere showing their age. By 20L0

and 20"1L, when field personnelfrom customer service and transmis-sion and distribution were sched-uled for mobile workforce automa-tion projects, the shortcomings ofthe system had become even moreapparent, and it was clear that theutility was at a crossroads.

The new mobile system shouldsolve Gurrent problems and providespecific features. The initial mis-sion was to mobilize business pro-cesses, including replacing metersets and automated meter-readingdevices, isolating leaks, locatingDenver Itrater assets for the public(locates), and performing preven-tive maintenance. At the time the

data included multiple years' worthof water consumption and work his-

tory at customer addresses, physicalequipment characteristics, and pipenetwork details. Unleashing thesedata from the back-office systemsthat managed them would improveresponse times for the work, reduce

the number of situations requiringthat a utility truck respond, andenable more-comprehensive cus-tomer care delivery. From the back-office point of view, the users wantedto reduce the completion time onwork orders but also have fieldupdates transmitted directly back tothe'WMMS or CIS applications thatoriginated the work requests. For

Now the question pneviously posed-"What could we

do better?"-tniggered an immediate response:

"We need to reduce complexity, not increase it."

mobilization effort was launched,users were forced to manage theorigination of work either in thework and maintenance manage-ment system (WMMS) or throughthe customer information system(CIS) with paper printouts takeninto the field at the beginning ofthe day by each field technician.This mode of work execution waslabor-intensive and required sig-nificant back-office and call-centersupport to manage the constantradio and cell phone calls from thefield technicians. The process wasalso prone to error because at theend of each day equipment change-outs, meter reads, and daily workdiaries had to be transcribed intothe systems originating the work.

\7ith a mobilization solution, the

business users sought the ability toroute work real-time to individualsin the field with the aid of globalpositioning systems, dynamicallyadjust workloads, and provide fieldtechnicians with a rich system inter-face to serve up enterprise data. Such

Denver'Water, these benefits, even

in anecdotal form, were enough tosubstantiate initial funding for themobilization project.

SOTUTION AND COST ANALYSISGTARIFIED PROJECT DIRECTION

Vithin the IT department, work onfinding a solution began with a

review of the options. Three optionswere available: Denver'Water coulddouble down on the legacy vendorapplication as a platform for futuremobile applications, go to marketwith a request for proposals for othersolution vendors, or chart a newcouise with some fresh thinking onenterprise mobility by creating itsown application. An informal surveyof solution providers in the market-place revealed similarity in cost and

technical approach between the eist-ing legacy mobile solution and othervendors. Furthermore, because the

legacy mobile solution was already inproduction, switching to an analo-gous technology was not compelling,so that option was eliminated.

I04:8 . J0URNALAWWA I AuGUST20l2 43DERMODY & BAGSDALE I

Analysis ofthe legacy option helped

clarify desired improvements, bene-

lits. til7ith rwo options remaining,the team began asking some basic

but essential questions. "'S?'hat dowe really know about implementingnew solutions with our older legacy

tion had to be better executed. Theteam needed to know, "If we had todo it all over, how could we achievebetter results? "

On the cost-of-ownership side,the program breakdown shaped upwell (Figure 1). As expected, a sig-

As shown in Figure 2, the pro-jected cost of data integration wouldbe extremely high compared withother expenses. Typically, the cost ofdata integration would be expectedto total less than 25%" of the projectbudget without software and main-tenance. At34"/o the data integrationline item was quite high, and theteam needed an explanation as towhy. The integration architects andproject manager looked deeper intothe activities and deliverables fromthe bygone mobile projects that hadprovided the budget baseline andquickly identified waste. Despite thefact that all of the software packages

involved in the legacy mobile solu-tion had strong integration capabili-ties, competing data definitionsamong the utility's WMMS, CIS, andmobile applications for data attri-butes on work orders, assets, andlocations required project and busi-ness team members to spend longhours reaching an agreement oncommon definitions. For example,consider what was involved in arriv-ing at a consensus on a work orderpriority field across four major Den-ver 'W'ater departments with hun-dreds of users. Field service person-

nel might use "10" to designate anemergency order, whereas the correc-tive maintenance group might use

"4" or t'A." Now compound thissingle problem by hundreds of fields,from pipe material types to valvesizes to meter types.

Although achieving consensus onthe meaning of Denver.Water datawas a great success, it was only the

first step. The flow of data fromthe call center through the V/MMSoi CIS to the mobile applicationrequired up to 10 integration steps,

each with its own level of datamapping and "mediation" or trans-formation. Figure 3 highlightsthese inefficiencies in the integra-tion architecture.

As for the ongoing project and the

34o/o estimated cost for data integra-tion, the cost estimate underscored a

need for even more advanced inte-gration tooling and greater interde-

As additionaltrouble spots were identified, the wish list

of improvements expanded, and the option of Denver Water

developing its own solution looked more and more promising.

mobile application?" "Do we have

a sense of the total cost of projectexecution and ownership??' On thebasis of previous successful projectswith the legacy mobile application,team members were confident thatthey had good insights and couldpredict future costs by extrapolatingfrom old costs. However, theywanted a bit more from the analy-sis. If Denver 'Water opted to buildon the legacy technologS that deci-sion could not be based on a simpleassessment of cost; the implementa-

nificant amount of spending wouldgo directly to the legacy system ven-dor for additional software licensesand maintenance fees. Because soft-ware and maintenance representedrelatively fixed costs and were notsubject to drastic improvement, thisview did not help inform how theproject could be better imple-mented. When the software andmaintenance component was takenout of the equation, however, thecost distribution proved more illu-minating (Figure 2).

FIGURE 1 Mobile work management program costs

I Software and maintenance

I Mobile application developmentI Data integrationI lnternal supportI Proiect overhead

44 AUGUST 2OI2 I JOURNALAWWA. l()4:8 I DERMODY&RAGSDALE

partmental collaboration because

the data relationships were muchmore complex than what had been

encountered in previous projects.From a pure cost standpoint, how-ever, the team knew enough aboutthe problem to avoid compoundingit. The project team estimated thatnearly 50Y" of the data integrationexpense in the legacy mobile solu-tion was attributable to labor-inten-sive analysis stemming from thearchitecture itself. Now the questionpreviously posed-"I7hat could we

do better? "-triggered an immediateresponse: "'We need to reduce com-plexity, not increase it."

Although the first opportunity forimprovement took some digging,others appeared with considerablyless effort. For example, deploymentcosts constituted a significantexpense, with each new release ofthe legacy vendor mobile applica-tions requiring a recall of all fieldcomputers as well as a manualupdate. The process was inefficientand prone to error, representing a

major impediment to systemimprovements for the business. Theteam also considered the effort ittook to configure the mobile appli-cation and identified some key defi-ciencies; the legacy applicationrequired a specialized skill set, find-ing qualified staff was increasinglyexpensive, and long-term in-housesupport skills did not align easilywith core IT competencies.

A wish list of improvements de-manded a different option. As addi-tional trouble spots were identified,the wish list of improvementsexpanded, and the option of Denver'Water developing its own solutionlooked more and more promising.The team took the list a bit furtherby reflecting it in the architecturaltenets of the second option, i.e., the

custom mobile application. These

tenets grew over time, but the starterset stressed low integration complex-ity, easy over-the-air deployments,and common technical skills to buildand maintain the platform. If theteam members executed the second

option according to these tenets andmet the end user's needs, they couldconfidently respond that yes, theyhad done better.

Of course, compared with buyingan off-the-shelf product, building a

custom application is a riskier prop-osition for a variety of reasons thatwere not lost on the team. Foremostwas the factthat fully reproducing a

feature-rich legacy applicationwould be prohibitively costln andDenver \Mater's mobilization solu-tion might end up with less requiredfunctionality and more dissatisfiedusers. To address this risk, the teamchanged the rules of engagementbetween the business and IT; thedelivery approach explored newdevelopment methodologies thatdeeply integrated the business and ITteams (to be discussed at length in asubsequent article). There were otherrisks as well, and some of theserelated to how the system wouldfunction; therefore, before commit-ting to new development, the projectteam completed technology proofsof concept to satisfy any concerns.

Testing the waters with the proofsof concept also provided additionalconfidence when it came to building

a cost model for the effort. Even so,

the joint project team took a slightlydifferent approach with the costanalysis for the custom application.Instead of a historical data analysis,the team asked the developers andproject manager if they could buildthe solution for the same price as thelegacy option. Informed by experi-ence, they answered "yes." Thedevelopers and project managerwere then asked if the build pricecould be the same as the legacyoption without the associated soft-ware and maintenance costs. Here,too, the answer was "yes." Buoyed

by this confidence, the project team

committed to a pilot for the applica-tion that would integrate with workorders from the VMMS to performinfrastructure field locates across the

Denver'Water service area.Although the pilot was somewhat

limited in scope, it was quite success-

ful, and more than 18 months afterthe production date, the users con-tinue to be satisfied with the applica-

tion. The bigger hurdle after thepilot, however, was the mobilizationof more than 80 different fieldworktypes coming from the CIS applica-tion. This next phase of the program

FIGURE 2 Mobile work management project labor costs

I Mobile application developmentI Data integrationI lnternal supportI Proiect overhead

DERM0DY&RAGSDALE | 104:8. J0URNALAWWA I AUGUST2012 45

was significantly broader in scope

and complexity (and therefore moreexpensive). These myriad businessprocesses spanned work performedby at least three distinct depart-ments: customer service, meter shop,and meter inspectors. The projectedoutlay, although still less than ifDenver'Water had proceeded withthe legacy solution, faced increasingfiscal scrutiny by the Denver Boardof !7ater Commissioners and theexecutive team. As a result, projectteam members were directed toquantify the benefits of the applica-tion and produce a payback calcula-tion for the outlay.

TEAM OUA]IITIFIED PROJECT

BENEFITS AND PAYBACK PERIOD

For any IT shop, assessing busi-ness benefits from a technology proj-ect,presents a challenge that cannotreasonably be undertaken withoutthe business playing an active role.In this instance, the cost-benefitanalysis was derived by able hands

in IT in conjunction with intenseparticipation by the business stake-holders. As in any analysis, the firststep was to break the process intomanageable pieces. What were thebenefit areas, and which of these hadquantifiable benefits? The work of

fication of at least one benefit areathat was highly quantifiable was suf-ficient to start investigating at a

deeper level.At this stage, the project team

more fully immersed itself into theend-to-end business processes to be

Although the pilot was somewhat limited in scope,

it was quite successful, and more than 1 I months

afterthe production date, the users continue

to be satisfied with the application.

the project team on Denver'W'ater'slegacy and new locates mobilizationshelped define a starter set of benefitareas (Table 1). There were otherareas of benefit as we1l, rangingfrom reducing customer call backsand number of trips required byeach field activity to having betteraccess to the information needed toperform the work; however, identi-

mobilized. Business process focus isa discipline in itself and can pro-duce positive results for any utility.Artificial barriers to efficient opera-tions-for instance, system or orga-nizational boundaries-can fre-quently be identified through thistype of analysis. In the case dis-cussed in this article, the projectteam documented the process flow,

FIGURE 3 lnefficiencies in integration architecture

E Appllcation services$ lntegration services

Mediation and business logicAlntegration queuing

Call center/operations

supportWork originating

systems

Analysis and design to translate between applicationrepresentations of work orders presented the largestshare of lntegration spending.

Cl9-customer inlomation system, E9B-entetprise service bus, WMMS-work and malntenance management system

46 AUGUST 2OI2 I JOUBNALAWWA. I()4:8 I DERMODY&RAGSDALE

highlighting areas in which manuallabor would be reduced with themobile application.

Conservative averages were used

to arrive at the incremental laborsavings from automation. Forinstance, if a field technician needed

(on average) 7 minutes per fieldactivity to record notes on a fieldstop and less than 1 minute to enter

the identical data into a mobileapplication, the pro;'ect team used a

net benefit figure of 4 minutes per

stop. lfhen the average number offield activities per user per day was

known to typically be greater than24, the analysts used 20 instead.When all the numbers were in, the

benefits were again trimmed, underthe assumption that in the first year,

only half of the benefits would be

realized because of the potential forslow adoption of the system by the

field technicians.Certainly, benefit assessment is an

imprecise science. However, a firstattempt should be conservativebecause many projects, even with a

fraction of the benefits quantified,will prove justifiable. Should the eas-

ily understood benefits not justifythe project, another round of analy-sis would be called for. Fortunatelyfor this benefit analysis effort, noadditional benefit areas needed to be

examined. .lfhen

the conservative,quantifiable benefits were droppedinto a five-year financial model,results showed a benefit of $3.2 mil-lion (Table 2). With a high level ofconfidence in the development costnumbers for the customer servicefield mobilization, the team was ableto then calculate the payback periodif all the detailed benefits were real-

ized. The resulting calculations are

shown in Table 3.New questions arose over the

course of the analysis. In most anal-yses, completion of one round ofanalysis typically spawns a series ofadditional questions. The team'sfindings sparked a host of new con-siderations. For instance, how wouldlabor savings be converted into harddollars for a salaried workforce?\7ould efficiency lead to layoffs orreductions in force?'I7ith so many ofthe benefits difficult to quantify,what would the total possible upsidebe for the organization?

The director in charge of the cus-

tomer service field group and theother senior management personnel

making up the Denver'Water execu-

tive team did not have to have all the

answers to these questions. Still, itwas clear that even with the conser-

vative numbers as a basis, the projectshould be continued for the cus-

tomer service field group. As theproject team launched developmentof this next phase, its due diligence

on the cost-benefit analysis reaped

unforeseen positive outcomes. Theteam was able to align its work moreprecisely to minimize cost and max-imize benefits as the thousands ofsystem requirements were analyzed

and ultimately satisfied by the finalproduct. Here again, the team'sexperience led to significant lessons

learned, which will be addressed ina subsequent article.

c0NGrusr0NFor team members, Denver

'Water's workforce mobilizationjourney pioneered new ways ofthinking about how best to leverageIT solutions with business stakehold-ers. Not only did they figure outhow to more fluidly accommodatecommon industry and organiza-tional pressures to spark innovationand change, they also learned tochallenge old assumptions.

This current retrospective provides

an opportunity to enumerate some

of the many lessons learned over the

course of the prol'ect.. Let cost analysis drive IT deci-

sion-making, even for legacy appli-cations. It is tempting to reinvest inold technologies for a variety of

TABLE 1 Potential benefit areas with customer service field automation

ExamplesAbility to

Quantlfy BenefltsBeneflt Area

Reduction ofmanual work

Reduction inradio calls

On-screenvisibility intofield workerlocation andstatus

Efficiency gain by avoiding printing and distributing up to 800daily paper field activities

Cost avoidance by removing need to write daily logs by fieldtechnicians

Cost avoidance by removing need to transcribe handwrittenlogs from the field technicians into the customerinformation system application

Time saved by making and answering calls related to fieldworkby providing better water network and customer data to thefield technician

Improved emergency response by routing high-priority workto the nearest available field resource

Improved missed appointment ratesReduced driving time for field resources, resulting in improved

efficiencies, reduced costs, and greener operation

Cost avoidanceSupport of greeq initiatives

Cost avoidance

Cost avoidanceRisk mitigationImproved eustomer serviceSupport of green initiatives

High

DERM0DY & RAGSDALE | 104:8 . J0URNALAWWA I AUGUST 2012 47

TABLE 2 0uantifiable benefits over five years for CS field automation

(ost Savlngs Area

Increased efficiency in CC field activity

Increased efficienry in CC followup

Reduction in CC overhead

Reduction in CS field daily log

Reduction in CS field activity documentation

Reduction in CS field review of daily logs

Inoeased efficiency in CS field monthly reporting

Reduction in CC and CS field printing costs

CS underutilization of field technicians addressed

Reduction in CS administrative staff field activity

20olo vehicle route optimization

.Total beneffts over ffve years

ROI Measure

Cost of capital

Net present value

Intemal rate of return

Payback period

Discounted payback period

reasons, but costs should continu-ally be rationalized.

. Always ask the question, "!7hatcould we have done better?" Evenmore important, allow what hasbeen learned to inform all aspects offuture efforts.

o When looking for benefits, takethe easy path first; steer clear of ana-lyzing fuzzy benefits unless justifica-

tion is not readily evident.. Carve out risk areas around proj-

ects, and ad&ess them early. Whetherthese areas are orgarizational or func-tional in nature, test mitigation strate-

gies with proofs of concept.o Share the costs and benefits of

the project with the delivery team.Describing a desired outcome inquantifiable terms presents a rallyingpoint for the group.

The next article in this series willlook more deeply into how IT proj-ect execution methodologies candrive better outcomes for both the

48 AUGUST z0r2 I JoURNALAWWA . 104:8 |

business and IT. The authors empha-size some highlights and lowlightsfrom their experience with waterfall,rational unified process, agile, andscrum methodologies. Lessonslearned from their experience withcost-benefit analysis will also fea-ture prominentlS and they willattempt to answer the question,"How can a project methodologysructurally reinforce the benefitobjectives for a technology project?"

ABOUT THE AUTHORS

Chis Dermody ,Denuer (Colo.)Water's cbiefinformation offi-cer is responsible

for informationtechnology (IT)strategy and exe-

cution, including neou IT solutiond eu e lop ment, lT infr a stru ctur e,

operations, end user support, and

DERM(]DY & RAGSDALE

Amount Saved-lzto,53t

26,318

1,516

395,227

7,78s,678

s6,823

2,674

68,405

225,844

899,921

204,260

3,277,a97

Amount

7.Oo/o

$2,494,s32

30.70/o

3.41 years

3.55 years

app lication support. B efore comingto Denuer Watef be spent 19 yearsas a technology leader in tbeh ealtb care industry. D ermodyhas a computer science degree

from Brandon U niuersityin Brandon, Man., Canada. PhilRagsdale (to whom correspondenceshould be addressed) is the founderand cbief executiue officer of TheConfluence Group, POB 1182,Boulder, CO 80306-1. 1. 82;p h il.r a g s dal e@ co nfl u e n c e gr o up. com.

TABLE 3 Project payback period for customer service field automation

http//dxdotorg/10. 5 9 QJ iawwa.2012.104.01.03