Mind the Gap
Wednesday, December 13, 2006
Ken Frazier is serving as interim Director of DoIT and campus Chief Information Officer. Frazier is also Director of UW's General Library System. The “mind the gap” sign, one of the most ubiquitous public messages in the London Underground, warns commuters to avoid the deadly misstep of falling into the gap between the train and the subway platform. The “Fit/Gap analysis” process used in implementing PeopleSoft systems ought to feature a similar warning about customizing administrative software. Falling into this
gap will cost the UW millions of dollars over the life of the software. It doesn't have to be that way. We can avoid customizing these systems most of the time if we have the will and leadership to adapt business processes and change University policies when necessary.
No one can deny the benefits to the University of purchasing administrative systems and software. Buying products already proven in the marketplace frees us from the expense of designing and building our own software and then maintaining it over time. We can obtain favorable pricing in a competitive environment, take advantage of vendor support and learn from the experiences of other users of the same systems.
While that's all certainly true, danger lurks.
To maximize our investment in off-the-shelf software, we conduct Fit/Gap analyses that compare the functions of the software we're buying with the University's business processes. Where a gap exists, we must either change our processes or customize the software to the way we do business.
Fit/Gap analysis has its pitfalls:
- The tendency is to customize to fit existing policies and practices. For a variety of reasons, people are unwilling to change the way they work, preferring to modify the new software to match how they already do business.
- Native software, the new kid on the block, has a weak constituency. Almost no one will step forward to advocate for it, even when it makes technical and economic sense.
- In a Fit/Gap analysis, the focus is on functionality and business processes. Cost considerations are secondary.
How do we avoid these pitfalls, make sure we buy the right software and implement it for a reasonable cost? We can start by infusing the Fit/Gap process with some ruthless questioning. If the analysis leads us to customize, then:
- How much will it cost? It almost certainly will be cheaper to modify our business processes instead.
- Of all the things we need to do, should we spend our money on customizing this software? An objective look at our spending priorities might give software customization a low ranking.
- Who will pay to customize and where will the money come from?
- How do we benefit from customizing? What downsides do we avoid?
There's really nothing wrong with the Fit/Gap process that can't be fixed by eliminating customization as one of its outcomes. If software we are considering won't work at UW without customization, then perhaps we shouldn't buy it. At a minimum, we should insist that any proposed customization is demonstrably worth the cost of supporting it over time.
We should resolve to run the software “as is” for a year with no customization. Admittedly, changing the way we operate to match the software is both troublesome and annoying. But, coping with that trouble and annoyance for a year of transition could save the University many millions of dollars.