(a totally fictitious and unbiased tale of star-crossed analysts, a process, a handful of decisions and determinations, a bumper crop of business rules, and a system use case)

The two analysts had ten years combined employment for Uff Da Health Insurance (UDHI)^[1] but had never worked together before.  Ollie, a Business System Analyst, thrived within the privileged confines of IT.  He was smart, decisive, and a meticulous documenter.  He was unusually skilled at creating requirements and system use cases with little or no input from the Business and then convincing the Business it's what they had asked for all along.  Fellow BSAs had grown accustomed to Oliver's motto:  "I like to build the solution and then let the Business respond to it."

Jenn, a Business Rule Analyst from the wrong side of the tracks (the Business), was equally intelligent as well as innovative and eager to prove that the Business was perfectly capable of documenting their own needs with the powerful combination of process, decisioning, and business rules.

The Business and IT, while frequently squared off in a dance of civil hostility, were united in their ambivalence to Jenn's theory that IT should design their solution around well-documented business rules.  IT felt imminently more qualified to tell the Business…well…their business.  And frankly, the Business had gotten pretty comfortable with that arrangement.

Enter the Big Honking Automation Project (or BHAP <be-hap>).  Everybody wanted a piece of this puppy.  The ROI associated with the successful automation of a 100% manual process was mouth-wateringly significant.  Problem was, while no one argued the value of it, there were several other high-profile projects already in the works — most of them attached to state and federal mandates (the tedious Have-to-Do's).  Both Business and IT resources were haggard and twitchy, strung out on ill-gotten carbs and epic government-authored edicts.

Ollie's manager requested he meet with Jenn and get educated about business rules.  She played the dreaded "Look at it as an opportunity" card.  Ollie grimaced.  Everyone knew 'opportunity' was really code for getting something unpleasant foisted on you.  Nevertheless, Ollie and Jenn met one sunny day in late August to discuss BHAP.

Ollie took charge immediately, "In a nutshell, I don't have much time to dedicate to this project — 21.67 days to be exact.  I am currently involved in 7314 other projects that require my time and attention."

'This does not sound promising,' Jenn thought irritably but bit back a snarky reply.  "We're all pretty busy these days, Ollie.  Why don't you let the Business take a stab at helping you out with some of our own deliverables?"

Ollie looked skeptical.  "Business deliverables, huh?  Such as?"

"Well, first we'll put together a current state process and then a future state process, if it's different," Jenn explained.  "Once that's done we'll experiment with some decisioning and then develop a fact model, a glossary, and business rules.  Let me show you a few samples of work we've done."

For the next half hour, Jenn walked Ollie through a portfolio of work her team had produced for other projects.  Ollie was interested despite himself.  He had to admit Jenn's offer was an attractive one.  If she could produce what she said she could, writing the tedious system use case would be a breeze.  But letting the Business fend for itself?  He risked becoming the laughing stock of IT if Jenn couldn't deliver.

On the other hand, Ollie was starting to feel the pressure of those 7000+ projects vying for his attention.  Jenn seemed pretty capable and she had numbers to back her up (e.g., IT cost vs. Business cost, dollar savings from re-use of terms/definitions and business rules, good PR from other project managers).  He decided to give the Business a shot.  He would watch their progress closely and make sure to step in when they got into trouble.  He tried not to get his hopes up that this 'opportunity' might actually be legitimate.

"Okay," he said.  "Let's give this a try.  I'd like to start writing system requirements in mid-November, which means I need the system use case done by then.  How about you have your stuff done by the third week in October.  That will give me a couple weeks to develop the use case with your SMEs, write up the system requirements, and then we'll hand it all over to the developers in early December."

Jenn took a few minutes to think through the timeline.  "Done.  What kind of communication would you like from the Business over the next couple months?"

They spent another few minutes developing a communication plan, exchanged a few pleasantries, and parted company.

Jenn didn't waste any time once she'd landed the gig.  She pulled her SMEs together and they went to work creating a current state process.  The goal of BHAP in a nutshell:  automate Coordination of Benefits.

• When Coordination of Benefits (COB) was required for a health care claim (meaning another insurance company had already adjudicated health care services as the primary payer and UDHI would be adjudicating those services as the secondary payer), health care providers submitted the health care claim to UDHI with a paper copy of the primary payer's explanation of benefits (EOB).
  
  
• EOBs were not standardized, and therefore every insurance company had their own particular flavor.  An Examiner then had to interpret the EOB, perform some calculations in order to pass half a dozen critical pieces of information to the claims adjudication system, and only then could the system properly coordinate benefits and finalize the health care claim.
  
  
• Due to some intelligent legislation, health care providers were going to be required to submit all health care claims data electronically… including primary payer information.  Yahoo!  Once data was received in a standard, electronic format there would be nothing to prevent a system from interrogating the proper fields on the electronic health care claim, performing the same calculations as an Examiner, and passing the required information into the claims adjudication system.

Though there was existing documentation galore, with clues about what the current COB process might look like, it turned out no one used it because it was hard to follow and didn't produce consistent results.  The wheels spun for hours while the Business tried to hash through "what is."  Everyone was frustrated.  Jenn made an executive decision, "We're going to treat this as if it's an entirely new process to the company.  Forget what your manuals tell you.  We're trashing them.  Forget what you know about the systems.  We're creating the process as you envision it should be.  Don't think about what the systems require now or what they'll do with it later.  Just think about how you'd instruct a new Examiner — equipped with only a pencil, paper, and calculator — to accomplish this task.  No systems — just process!"

Banishing the system monkey gave the group the freedom to quite literally think outside the activity box.  The process was created with relative ease, and it didn't cover reams of 11x17 paper, littered with hundreds of mind-boggling, eye-crossing diamonds and boxes.  Nope … this was one 8½x11 sheet of paper with only four simple boxes.  And, ironically enough, the process that "should be" (fully automated) was actually the process that "already was" (manually executed).  The SMEs just hadn't been able to see it through the mess of outdated documentation.

Still, the SMEs scratched their heads and furrowed their brows.  They seemed concerned.  "Tell us our process isn't really this simple," they seemed to be thinking, and of course it wasn't.  Three of the four boxes represented one major decision each.  And within the scope of each major decision were one-to-many smaller decisions (sub-decisions), and each sub-decision was comprised of one-to-many business rules.  The fourth box represented a major determination … but more on that later.  The group had only scratched the surface of the work to be done but had created an all-important foundation for the project.  Jenn asked the Business to hang in there a little longer.

With the four major decisions/determination captured they moved on to creating sub-decisions.  For instance, one of the major decisions required that the COB information submitted on the health care claim be valid.  This major decision encompassed two sub-decisions: 

• Was the COB information complete — was everything that was needed to coordinate benefits present and accounted for?
• Was the COB information compatible — did the provider submit apples-to-apples or apples-to-oranges? 

These two sub-decisions were further fleshed out by a half-dozen business rules or so each (e.g., B may be considered compatible to A only if B is X, Y, or Z).

The path laid out during this exercise could not have been happier had it been paved with yellow bricks and lined with singing munchkin tour guides.  Follow it and you'd have yourself a health care claim with automated COB.  Better yet, it was so fantastically obvious to see where the health care claim might veer off the happy path ("Houston, we've got a problem at Sub-Decision 2") that the Business was able to designate all the detours before testing ("Copy that; please send the claim back to the submitting health care provider advising that the COB data be corrected.").

With sub-decisions in place the only thing left for the Business to hash out was six sub-determinations included under the major determination and their related business rules.  Much like finally getting to paint (the fun part) after hours of sanding and taping (the grunt work), the determinations would be the reward for a health care claim successfully put through its ten grueling sub-decision paces. 

Unlike the sub-decisions, which were more or less tests — the claim is or isn't, the claim did or didn't — the sub-determinations for this project began with the assumption that the health care claim both was and did.  By the time the claim would hit the sub-determinations, an Examiner (current state) or system (future state) would be assured that data pulled through the sub-decisions passed muster and therefore the six COB fields required by the claims adjudication system could be accurately calculated or otherwise determined (e.g., mapped to a decision table).  And that's just what the business rules captured under the sub-determinations did — provided guidance about how to calculate or otherwise populate those fields.

The Business deliverables were done:  process, business rules, fact model, and glossary.  The major and sub-decisions/determinations were gathered together in an Excel spreadsheet and affectionately referred to as the project playbook.

Figure 1.  The Project Playbook  

Jenn let Ollie know he could proceed with drafting the system use case.  She'd been sending him regular updates while the Business developed their goods, but besides a few questions now and again, he'd been mostly silent.  7314 projects in the hopper will do that to you.

Ollie prepared to author the system use case.  He scheduled three meetings with Jenn and the SMEs over a relatively short period of time.  As Ollie and the SMEs got busy building the use case, he became aware in short order that, not only did this group have a completely unified understanding of their business process and rules, he was not actually creating the use case, he was scribing it — verbatim — from the project playbook.

The use case development and sign-off happened quickly and painlessly.  After the final session, Ollie and Jenn shook hands.  "This was great, Jenn," he said.  "You guys did a superb job on the project.  I have to admit I wasn't totally confident this arrangement would have such a happy ending.  Sorry for doubting you."

Jenn — satisfied that this time around that the Business had built its own solution and let IT respond to it — stated simply, "Success means never having to say you're sorry."

Author's notes:

[1]  For those who don't have Norwegian ties and need a definition of "uff da," this fabulous catchall phrase can mean just about anything you want it to.  From Wikipedia:  "Uff da" is often used in the Upper Midwest as a term for sensory overload.  It can be used as an expression of surprise, astonishment, exhaustion, relief and sometimes dismay.  The term has been heard among men when a particularly attractive woman enters a room, or depending on the tone of voice, when a particularly unattractive woman enters the room.  Gotta love it, yah, you betcha!

[2]  If this story were true, I would say there might actually have been two BSAs on the project, and while both truly were pulled like taffy between many projects, they were totally and wonderfully supportive of letting the business run the show.

[3]  I might also be compelled to disclose that three BAs with business modeling experience shared the duties of producing process, business rules, fact model, glossary, project playbook, and embracing new approaches.

[4]  Certainly I might add that busy Business Analysts filled the role of the SMEs and had a scary amount of knowledge about the business and its systems in their heads (and in their gargantuan manuals).  I would go on to acknowledge, perhaps, that projects constantly compete over their time and expertise (and sanity, I expect).  Hats off to them.

# # #