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

Featured
10692 Views
3 Comments
4 Likes

What’s Really Needed to Align Business and IT Part 1: Creating True Business SolutionsSo 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.

Excerpted with permission from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October, 2011, 304 pp, http://www.brsolutions.com/bbs

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

 

Like this article:
  4 members liked this article
Featured
10692 Views
3 Comments
4 Likes

COMMENTS

ajmarkos posted on Monday, March 5, 2012 8:55 AM
Ronald:

Very good article, but you are espousing a fundamental upheaval in BA practices: becoming more strategic and business oriented. Lets get specific and look at the popular system behavioral modeling tedhniques to get a feel for the extent of problem (being too small-picture oriented and solution oriented).

UML Use Cases steer the BA to focus on a computer solution. Even if they are created with the intent of documenting what needs to be done vs how it should be done, they still strongly steer a BA into limiting the scope of analysis to what will ultimately be encased in the ultimate solution.

BPMN: This technique steers a BA to jump immediately into looking at "the system in the small": the detail-level processing logic that can be expressed sequentially. There is no emphasis at all on looking at the bigger picture, which, especially for business systems, is almost always very non-sequential.

Tony
larimar posted on Tuesday, March 6, 2012 8:41 PM
Hi Ronald,

Very good article, lots to discuss. A couple of thoughts:

1) Where is the business justification for implementing the idea? What is the problem that the idea is solving? The idea sounded like a neat feature, but if the solution can't be tied to addressing specific business requirements that have been identified and validated then there's no reason to implement it. In your narrative I didn't get a feeling the most fundamental question was answered: "why do we need to do implement this?" This has to happen before any resources are spent on analyzing an idea in depth, much less spending more time and money building a solution. It seems like the project was based on a scope defined by the solution, not the problem. A good BA should take a step back whenever they are dropped into a project that has an answer already with no defined problem or opportunity. It's their job to validate the need and then look at all possible solution alternatives, not just the first idea that may have been the genesis for the project.

2) As a wise mentor told me and I now fully advocate to all my clients, there is no such thing as an 'IT project'. There are only projects that are sponsored by a business unit and are tasked with solving a defined problem or capitalizing upon a defined opportunity. IT resources may get involved after all the potential solution options have been evaluated and the need for IT systems is established. This is why I advocate for BAs to live outside of IT departments, since they often become predisposed to thinking of only IT solutions when gathering, documenting and analyzing requirements. Budgets for these projects should also be controlled by the business unit, with transfers made to the IT department for resources used in the project (i.e. a true IT service model). This structure dramatically reduces the risk that money is spent on building bridges to nowhere but look really cool.
undrkvabrtha posted on Tuesday, March 6, 2012 8:48 PM
UML is a bit limited in its dexterity when a BA tries to understand why a certain process works a certain way.

BPMN is a great common format in which to exchange ideas if one is part of a BPD / A team / area.

However, when it comes to understanding why something happens the way it does, and figuring out what improvements can be made, there is no substitute for stakeholder interviewing (especially where commercial or other legislation is involved).

Also, unless we're talking about 'new' (Novou?) BAs i.e. those who call themselves such or are assigned such a position in an ICT environment (in Oz, ICT is considered a more complete phrase rather than IT), Business Analysis is actually a BUSINESS thing, NOT an ICT thingie.

The original BAs were chartered accountants, and their tools were usually Excel sheets detailing the 'health' of the organisation - and their role, of course, was to analyse the cash flow, expenses, production capabilities etc for the process / organisation.

Today, doing the same thing in an ICT environment does NOT change the fundamentals of Business Analysis.

That's why the BABoK clearly describes knowledge areas within a BUSINESS environment, and NOT an ICT environment.

(I'm not shouting, but simply emphasising on the pre-existence of these methods / processes / analytical approaches)

Cheers,
Undercover Brother
Only registered users may post comments.




Latest Articles

Domain Expertise and the Business Analyst: How Vital Is It?
Sep 15, 2019
3 Comments
The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains tha...

Copyright 2006-2019 by Modern Analyst Media LLC