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.  URL:  http://www.brsolutions.com/bbs

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?  What's missing?  Isn't there a better way?!

The answer is simply that business leads are not being properly engaged at the onset in sketching out key elements of a winning business solution.  Business Analysts are not asking the right questions in the right way of the right people at the right time.

Correcting the omission must take into account the realities of business life.  Business managers and business leads are notoriously busy.  They are also understandably hesitant about participating in requirements sessions inevitably slanted toward IT.  They dislike being asked questions that have implications they can't appreciate or that are phrased in unfamiliar terms (ITspeak).

Business managers and business leads need to be engaged in the right kind of conversation, asked the right kinds of question, and hear only real-world vocabulary.  The conversation must be fast-paced, pinpoint, and natural.  The effort must use the minimum amount of their time possible and produce compact documentation that can easily be reviewed by busy sponsors to spot holes.  The approach must absolutely uncover any blind alleys or showstoppers.  And the results obviously need to serve as a foundation for developing requirements.  What kind of technique could make all that work?

Enter the Policy Charter

One day in the mid-1990s, we^[1] were called into a senior manager's office for a hastily arranged meeting.  The manager needed help deciding whether to proceed on a very large reengineering initiative.

There were piles of documents all over her desk (and on the floor).  Gladys knew this manager pretty well — she was capable, highly respected, and normally calm, confident, and collected.  That day, though, she was clearly perturbed.

As we talked about the proposed business initiative and the major software development it entailed, the manager grew ever more agitated.  Before long she got right to the heart of the matter:  "I have great people working for me.  They've worked very hard these past several months and produced a ton of documentation.  I've gone through it carefully.  I've talked in depth with the team.  Still, for the life of me I don't know whether or not we should do this.  Do we have a winning business solution or not?  I know we need to do something, but I'm still not seeing the big picture."  She paused for a moment and then added, "And if I'm still missing it, I'm pretty sure the team is too."

A ton of documentation.  Winning business solution or not?  Still not seeing the big picture.  We'd heard similar complaints from senior managers confronting large projects many times before.  This sponsor's team had produced use cases, data models, technical architectures, migration issues, support requirements, problem areas, 'open' issues, and still more — hundreds of pages.  Yet nowhere did it provide what she really needed.

What exactly was missing?  The documentation implied a new way of doing business.  Yet nowhere in the documentation was there any concise, direct representation of the business thinking behind that new way of doing business.  Perhaps the thinking was somewhere in all that documentation, but if so it was everywhere.

Previously the team had done high-level cost/benefit analysis.  Everyone was fairly satisfied on that score, so ROI wasn't the issue.  The effort would clearly pay-off if the business problem were fixed properly.

There's the rub:  fixed properly.  Specifically what the sponsor wanted to see were the key elements of the business strategy that the proposed design embodied.  She wanted to see the underlying motivation laid out — the why of it all.  She simply wanted to know whether the business problem really was being addressed properly.

Why hadn't their requirements approach given her that answer?  The answer hadn't come from the business side because there was too much 'systems' in the approach.  And it hadn't come from the IT side because there was too much 'business' in the question.

In response, Gladys came up with an innovative technique, the Policy Charter, first published in 1998.^[2]  The Policy Charter ended up having significant influence, not the least of which was on the Business Motivation Model, now the standard for organizing business strategy.^[3]

Why It's Called a Policy Charter A key element in well-developed business strategy is business policies.  You can think of business policies as business rules in the making.  Not just any business rules, but core business rules that are make-or-break for the business success of the strategy.  The name Policy Charter emphasizes the special role of these business policies.  The content is laid out in a format that highlights that role. It doesn't really matter too much, though, what you call the artifact or how you format it.  What's important is what it holds — a strategy for the business solution. Just one thing:  Don't call it a business process or lay it out as a flow.  A business process model is something altogether different from a business strategy.

Gladys convinced the manager to commit the business leads to several days of facilitated sessions to develop a Policy Charter.  The effort was a big success.  At the end of the sessions the business leads commented that the discussion was exactly the one they had wanted all along.

The key elements of the strategy for the business solution were laid out in a few pages.  An even shorter summary was created for higher-level executives.  The sponsor got great feedback from the executives, not to mention solid buy-in.  As events later proved, they had indeed carved out a winning business solution.

I have to confess something here.  It fell to me to develop material to conduct a half-day orientation session for the participants.  The material needed to cover business goals, business risks, business tactics, and business policies, and to show how to structure them in coherent fashion.  I wasn't sure I could get those ideas across.

I needn't have worried.  The participants were all highly-experienced business leads.  They knew intuitively all about business goals, business risks, business tactics, and business policies.  They had no trouble whatsoever applying those ideas free and clear of any IT and project concerns.  They just needed some structure.  No more than half an hour into the session, they began telling me how it fit together (and to please hurry up). 

Since that first experience we've helped create Policy Charters to front-end many scores of initiatives of all shapes and sizes in many different industries and countries.  Properly organized the technique always works like a charm.

References

[1]  Gladys S.W. Lam, Co-Founder and Principal of Business Rule Solutions, LLC, and I.

[2]  Gladys S.W. Lam, "Business Knowledge — Packaged in a Policy Charter:  Policy Charter as a Deliverable," DataToKnowledge Newsletter, Vol. 26, No. 3 (May/June 1998).  URL: http://www.BRCommunity.com/a1998/a385.html  

[3]  Business Rules Group, The Business Motivation Model ~ Business Governance in a Volatile World ( 1.4 ed.), May 2010.  Originally published as Organizing Business Plans ~ The Standard Model for Business Rule Motivation, Nov. 2000.  Available from http://www.BusinessRulesGroup.org.  Now a standard of the Object Management Group (OMG).The Business Motivation Model — Business Governance in a Volatile World (BMM), v1.1.  Object Management Group (May 2010).  Available at http://www.omg.org/spec/BMM/1.1/   

# # #