What’s Really Needed to Align Business and IT Part 1: Creating True Business Solutions

So many IT projects ultimately end in failure and are simply written off. Same old story, time and time again. Why is it so hard? Why can’t we figure out beforehand whether some solution will actually work once we roll it out? Most project management approaches and many IT methodologies include steps for building business cases and provide guidelines for project planning and estimating. What’s missing? In the first of a two-part series, Ron profiles the problem using a typical case study. Then he identifies the answer: Developing a business strategy and business solution before jumping into system design.

Before relating the following cautionary tale about scrap and rework in system development, let me tell you how the story came out. What approach did the organization normally use for figuring out business solutions before jumping into designing a system? None. What group or role in the organization was responsible for making sure it happened? Nobody. Sound vaguely familiar?

An All-Too-Common Story: Case Study

The organization is in auto insurance. Their existing business process went like this: When an insured gets into an accident, the insured calls the claim center by telephone, reports the damage, then takes the vehicle to a claim center. The claim center gives an estimate for repairs and provides a claim form. The claimant takes the claim form to a repair shop to have the car repaired.

The company had conducted an in-depth study of claims. The study indicated that over 80% of claimants were honest and, surprisingly, most repair shops too. A large majority of claims were fender-benders and glass breakage with no bodily injury (i.e., ‘simple’).

So someone came up with a bright idea. For simple claims from honest claimants, the claimant could just phone-in the claim, then take the car directly to a selected list of (honest) repair shops. Claimants would like that – one less step (no need to bring the car to a claim center for an estimate). The claim centers would like it too – less volume.

An IT project was initiated to implement the idea. A competent analyst was assigned. First she interviewed telephone operators at the claims centers to find out what they needed. Easy. Claimants usually go to a repair shop close to home or to work. So a key feature for the new system would be for an operator to key-in a claimant’s home or work address and access all certified repair shops nearby.

The analyst then interviewed managers of the repair shops. Easy too. They simply needed access to claimants’ policies to determine coverage.

Six months later an impressive new system had been built, complete with a colorful map of the city. Point to any location (or key-in any address) and the system identified all certified repair shops within an x-mile radius. Slick. Lots of bells and whistles.

The IT project team proudly demoed the new system to a group of high-level managers. Fifteen minutes into the demo, a senior director asks: “Are there any legal implications for our organization if we suggest repair shops over the phone?” Blank stares. The IT analyst didn’t know the answer, nor did any other team member.

That afternoon the senior director phoned us and said, “I don’t know what went wrong. A system has been built but I have no idea whether we should roll it out. We have no sense of what business issues it might create. Can you help?” Gladys responded, “If you can get the right people in the room, I can facilitate a session to find out.” He asked, “Who do you need?” Gladys replied, “Someone with significant experience from legal, the director of the telephone claim centers, a manager representing the repair shops, and a seasoned adjudicator who understands the needs of claimants thoroughly.”

When a senior director wants something done, things happen. Monday morning Gladys was in a room with six managers including the four people she had requested. Here’s some of what she discovered within just a few hours.

From the director of the telephone claim centers: “Did you know that an average one-minute increase in talk time on every call means adding six additional operators to the staff? Our call volume is so high our operators have no spare time for additional conversation. Suppose an operator suggests ABC repair shop and the claimant responds, ‘My sister went there once and they did a terrible job. What other ones do you have?’ The operator must spend time going through alternatives.”

From the representative from legal: “We absolutely cannot suggest a repair shop over the phone. We could have legal issues from both claimants and repair shops. Claimants might hold us liable if they feel the repair shop doesn’t treat them well or fails to repair the damage properly. Repair shops will have issues if they feel we suggest competitors more often.”

Gladys spent several days brainstorming a viable business solution with the group. In the end the group decided on a public, self-help internet system rather than the internal system originally developed.

She led the group through a thorough assessment of business risks. The new business solution would require beefed-up security and extra information about repair shops. Since some claimants might not have access to the web or feel comfortable using it, an automated phone service would allow them to search for near-by repair shops by punching phone buttons. People who dislike automated phone dialogs could still call a claim center, but the response would be limited to a request for a list of all repair shops sent automatically by the mailroom.

The bottom line: The best business solution turned out to be very different from the system built originally. That system basically had to be scrapped.

Lessons Learned

This case study and innumerable ones like it demonstrate that:

1. Business Analysts should think and talk in terms of creating business solutions, not building software systems.

2. Blind alleys and showstoppers can be found early on.

3. Creating viable business solutions involves identifying business risks and ways to address those risks – in other words, business strategy.

4. Most IT approaches are fundamentally deficient in that regard. It’s simply not what they’re about.

5. If you have the right people in the room, and conduct the conversation in the right way, it doesn’t take that long to work out a viable strategy for the business solution.

What’s the worst case? You might find out there’s no viable strategy for the business solution at the present time. (We’ve never seen that happen.) Still, wouldn’t it be better to know?! As they say, hope is not a strategy. And given the costs of IT, hope can also prove very expensive.

~~~~~~~~~~~~~~~
In Part two of this two-part series, Ron talks about a better approach for creating business solutions based on strategy in the form of a Policy Charter.

Author: Ronald G. Ross 

Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of BRCommunity.com and as Chair of the Business Rules Forum Conference. He is the author of nine professional books, including his latest, Building Business Solutions: Business Analysis with Business Rules with Gladys S.W. Lam (2011, http://www.brsolutions.com/bbs), and the authoritative Business Rule Concepts, now in its third edition (2009, http://www.brsolutions.com/b_concepts.php). Mr. Ross speaks and gives popular public seminars across the globe. His blog: http://www.ronross.info/blog/ . Twitter: Ronald_G_Ross