One day in the mid-1990s, Gladys Lam and I were called into a senior manager's office for a hastily arranged meeting.  We were consulting to the company and the manager needed help deciding whether to proceed on a very large reengineering initiative.  When we entered the manager's office, we noticed piles of documents all over her desk.  Gladys knew this manager fairly well from previous assignments — the manager was capable, highly respected, and normally calm, confident, and collected.  But on that particular day she was obviously perturbed.

We began to talk about the proposed business initiative and the related software development it would entail.  The manager grew more and more agitated as the minutes went by.  Eventually she came out with this:

"You know, I have really great people working for me.  They've all worked really hard on this.  They've produced a ton of documentation and I've looked through all of it very carefully.  I've talked with them in depth.  Yet for the life of me I still don't know if we should take it on.  Do we really have a winning business solution?  I'm at a loss to know.  The project will require major resources and I know we need to do something.  But I'm still not seeing the big picture."

Do we really have a winning business solution?  Still not seeing the big picture.  We had heard similar complaints from senior managers confronting large projects many times before.  And so many projects ultimately end in failure and are simply written off.  You know that story.

What's the problem?!  Why is this so hard?  Why can't we figure out beforehand whether some operational business solution we want to build will actually work once we roll it out?  Why can't we be more confident upfront about launching into business solutions?  Most project management and software development methodologies talk about building business cases and provide guidelines for project planning and estimating.  Why aren't they working for the big-picture question?

In a nutshell, the real problem is that the business leads are not being properly engaged at the start in sketching out the key elements of a winning business solution.  What form should that take?  Business leads are notoriously busy.  They are also understandably hesitant about participating in requirements sessions inevitably slanted toward IT.  They are always asked questions with implications they have no real means to understand.

You need to engage them in the right kind of dialog and ask exactly the right kinds of question.  You need fast-paced, pinpoint discussions that feel natural for them.  The effort has to take a minimal amount of their time, and produce compact documentation that can easily be reviewed by busy sponsors to find any holes.  It absolutely must uncover any showstoppers.  Lastly, it obviously needs to be something that embodies a major step forward in terms of upfront IT requirements.  What kind of deliverable can make all that work?

In response, Gladys came up with an innovative and powerful solution, the Policy Charter.  That was back in 1997.  The Policy Charter ended up having significant influence, not the least of which was on the Business Motivation Model, the standard for structured strategy.^[1]  But let me stick to how Policy Charters came about in the first place.

The Solution

Gladys tells me that when she was still a little girl, her grandfather taught her to always think through risks.  When you want to take on something big, he said, think of every risk you can and how you would handle it.  Only when you have decided you can live with any remaining risks should you actually do whatever it is.  All remaining risks you can think of must be acceptable ones.  Her grandfather was very proud of his Chinese heritage.  Much later she would connect his thinking about risks with a book he once mentioned — Sun Tzu's The Art of War.

So Gladys knew right off that risk would be at the heart of any solution.  But there are risks everywhere you look.  There are business risks, project risks, IT risks … the list goes on.  Which kinds of risks should we be considering?  What else do you need?

Our focus on business rules naturally got us thinking about business policies.  We also had been using the Zachman Framework to organize our new methodology.  The Framework helped in at least two specific ways:

• The Framework starts off with scope in row 1.  As a project manager, scope is another of Gladys's hot buttons, right up there with time management.
  
  
• Column 6 of the Framework talks about motivation and strategy — why you do what you do.  The generic model John gives for column 6 is:  ends-means-ends.  That suggested inherent structure for strategy — barebones, pinpointed structure.

Where Zachman helped the most, however, was in distinguishing architectural requirements from project justification and project management concerns.  He focuses squarely on architectural requirements for the complex thing you want to build.  So it's not about project risks or IT risks, it's about business risks.  In other words, what operational business risks will you face in running the to-be business?  How will you address those risks each and every day?  What ends will you constantly be trying to achieve?  What means will you employ to achieve them?

Now we had all the pieces — risks, business policies, means and ends.  They simply needed to be structured.  The result was the Policy Charter,^[2] a central piece of Proteus, our methodology for business analysis and business rules.

Finally a Better Way

Gladys immediately proposed a Policy Charter for the manager's business initiative.  She convinced the manager to commit the business leads to several days of facilitated sessions to develop the business strategy.

The effort was a huge success.  At the end, the participants said this discussion was exactly the kind they had been wanting all along.  It yielded key elements of the business solution in just under ten pages.  For higher-level executives we created a three-page summary.  The manager got great feedback, not to mention broad buy-in.  As events later proved, they had indeed sketched out a winning business solution.

I have to make a confession here.  It fell to me to develop some training material for the effort, a half-day upfront workshop on business goals, risks, tactics, and business policies, and how to structure them in coherent fashion.  I wouldn't admit it at the time, but I was nervous about giving the training.  I just wasn't sure I could get the ideas across.

Think about that.  I was worried that highly-experienced business leads wouldn't 'get' thinking about business goals, risks, tactics, and business policies, free and clear of IT and project concerns!  It turns out it was some of the easiest 'training' I've ever done.  After about half an hour, they were telling me how it all fit together.

Since that first experience, we've helped create Policy Charters to front-end scores of projects of all sizes and in many different industries.  It always works great.  What business people need is simply some structure to organize their thinking about the elements of strategy.  Once they've got that, they're off and running.

Gob-Smacked

Let me share another experience we had a year or two later in the U.K.  A large pharmaceutical company wanted to integrate four lines of business that had previously been stove-pipe.  At the same time they wanted to open a new channel for their offerings via the web.  Very complicated stuff, with delicate business trade-offs to consider.  They called us in to conduct some facilitated Policy Charter sessions.

On Monday morning, the room filled quickly with more and more people — about triple the number we had expected.  As the morning progressed we found out why.  The various business managers from the four lines of business had brought their operational staff because they had become accustomed to IT requirements sessions asking questions only the operational staff could answer.

Here's what happened.  At the end of the first day's session, the managers told their operational staff not to come back the next day.  The managers caught on very quickly what the discussion was about and that they themselves needed to participate.

Still, there were one or two tense moments.  The worst was when we came in the next morning and saw the walls bleeding red.  Let me explain.

During Policy Charter sessions, we like to use different colored Post-It notes on the walls for each component of strategy — that is, for each goal, tactic, risk, and business policy.  (Sometimes we wallpaper just about the whole room!)  We use red or pink for the risks so they will really stand out.  But when you come into the room and see nothing but a sea of red, it can startle you.

Gladys quickly went to the project manager to assess the damage.  To her surprise he said not to worry.  The feedback from the managers was very positive.  He said this was the first time they'd actually talked through the risks face-to-face.  He could already see they were saying many of the same things, just using different words.  Sure enough he was right.  By the middle of the second day, the sea of red had shrunk considerably.

The group went on to do some outstanding thinking.  Originally the sessions had been planned for three days.  They were so pleased with the progress, however, that at the end of the third day they asked us to return the next day for more.  Whenever did you hear of business managers asking for more time to spend in requirements sessions?!

We were not involved in the effort after the Policy Charter sessions, but we learned that two years later the manager received a world-wide award for the project.  They determined that the project had saved the company some £80 million.

About a month after the sessions, Gladys received an e-mail from one of their managers.  In the very first line she came across the words 'gob-smacked'.  Gob-smacked?!  What's that?!  Had something horrible happened?  What were we to blame for?  In a panic she called me to find out what it meant.  I didn't know either.  After a flurry of e-mails another Brit finally assured us it was highly complementary.  Loosely I think you could translate it as having been blown away by the sessions.  Very good stuff!

References

[1]  In the late 1990s, the Business Rules Group (BRG) initiated a multi-year effort to create a standard for structured strategy, which came to be called "The Business Motivation Model:  Business Governance in a Volatile World."  The standard was first released in 2000.  See www.BusinessRulesGroup.org for a readable (free) copy.  The standard was released in UML through the Object Management Group (OMG) in 2007.  For the OMG version, see:  http://www.omg.org/technology/documents/br_pm_spec_catalog.htm

[2]  Gladys S.W. Lam, "Business Knowledge — Packaged in a Policy Charter," Business Rules Journal, Vol. 1, No. 5 (May 1998), URL: http://www.BRCommunity.com/a1998/a385.html

# # #