Rarely do my sister and me share the weekday hour-long commuter train ride from downtown Toronto to our homes north of the city.
Aside from the fact that we typically travel at different times, even if we happen to be on the same double-decker train she resides in the lofty top part of the locomotive with her raucous “train pals.” I, on the other hand, prefer solitude in the lower berth. I care neither for the reverie up top or the relentless sway that’s much more evident up high, which churns whatever happens to have made it down into my stomach.
On a day in late June, we two had a prior arrangement to meet and my sister mercifully agreed to hang with me on the ground-floor section.
“How was your day?” I inquired, as we settled for our journey.
“Don’t ask,” she replied, in fact meaning, “thanks for asking.”
She then related a tale of IT angst, specifically to do with an application-integration project happening at her work. Seems the effort was going off the rails in terms of not producing the expected results and running extremely late in completion. My sister and I never talk shop, since she is anything but computer literate, although her job as someone who administers banking processes means she is heavily dependent upon IT. So it was particularly interesting to hear her experience, since most of my time is spent understanding the perspectives of IT vendors or IS practitioners.
Working for a mid-sized financial institution, she is currently part of a committee made up of senior management and operational staffs who are overseeing the conversion of her company’s banking and mortgage systems to a more “open” model. In layman terms that means consolidation of disparate financial applications and greater interoperability between her company’s banking and mortgage systems.
My sister had been involved in a series of meetings between her committee and a systems integrator (SI) who was performing the conversion project. Apparently both sides walked away that day frustrated and unhappy. She explained that the systems conversion project, which began in January, was to have been completed in six months, but here in month five it had already been twice delayed – from late July to mid-October, and probably further beyond that.
The meeting that day saw the committee lay out a list of demands regarding how they’d like to see the new system function, while the SI company doing the work seemed more bent on explaining why from a technical perspective these demands simply could not be met.
I asked her to explain what had gone so wrong with the project. It became quickly apparent the experience of her company was probably a blueprint for how not to engage in an IT service contract. Right from the start there were questionable decisions.
Her company’s IT experts had short-listed about six SIs – all relatively small and regional shops – who were then separately interviewed by the committee, which really wasn’t a committee at all, but rather a collection of representatives from various business departments looking out for their respective interests.
It certainly would have been wise to include at least one large SI, even if the price for service might have been too rich, to at least use the large player as a measuring stick for the others. The committee should have determined a comprehensive criterion prior to meeting with the short-listed group, which would have served everyone’s collective needs as well as individual department concerns and provided clearer direction and guidelines for the chosen SI.
The key selection criterion, aside from price, was someone who could do the job, according to my sister. What was sought was an SI with a ready set of developed applications, which could then be used to easily convert the legacy set of banking and mortgage systems in place.
What the company didn’t apparently do was hold the SI to the flame by insisting on an outline of measurable stages and a hard date for overall project completion, enforced by stringent penalties if the SI didn’t live up to the deal. It also seemed apparent that the chosen contractor did a poor job of scoping out the project, especially from the perspective of what was needed on the business side.
“They (the SI) never came around and asked us what we needed in order to do our jobs,” my sister lamented, saying the contractors simply went ahead with the conversion project, without clearly understanding the needs of those who use the banking and mortgage systems. She explained that in hindsight, the committee should have insisted the SI spend time with each department to understand what they did with the current banking and mortgage systems, then learn what the new system needed to do for those individuals who would be working with it each day.
The application conversion, which should have created greater efficiency and allowed users to do their work more easily and quicker has, according to my sister, actually created more work. She estimates in some cases it takes nearly twice as long to input changes or add new records to her company’s banking systems, since there isn’t the level of interoperability that was expected and data for certain records must be re-entered in various fields.
My sister admitted the committee is as much, if not more, to blame for the current circumstance. “We were enthusiastic and wanted this to work,” she said, explaining they were a highly inexperienced group, who may have proceeded too quickly.
However, after hearing her story, one has to seriously question whether the committee had much decision-making authority in the first place. It seems the SI that won the bid was the one most strongly recommended by an in-house IT systems manager. In fact, my sister wonders why the systems manager has so vigorously defended the SI every step of the way and seems far less understanding of user concerns.
Ironically, despite an IT project that looks doomed to fail or at the very least result in a highly dissatisfied customer, both parties will push onward.
“We’re all in too deep now to get out of it,” my sister explained. “We’ve got to keep going.”
It was the best train story I’ve heard in quite a while. It wasn’t exactly Murder on the Orient Express, but a fascinating lesson in the “don’ts” of IT contracting. I absolutely must make a point of traveling with her more often.
McLean is research manager, network support and integration services, for IDC Canada Ltd. in Toronto.
