Recently, a business project sponsor confided to me her frustration with the project team she had put together to kick off a project.  Basically, her complaint boiled down to this.  Despite many months of work, she still felt like she was missing the big picture.  And if she was still missing it, she confided, she was pretty sure the team was still missing it too.

The irony was that the team had produced a 'big' picture -- a very big picture indeed!  They had produced documentation covering features, workflows, data models, technical architectures, migration issues, support requirements, problem areas, 'open' issues, and still more -- hundreds and hundreds of pages of it.  But in all those pages, there was no answer to what the sponsor really wanted to know -- the why of it all.

As we discussed this more, it became clear what the sponsor wanted was a focused statement of what the new capabilities would mean to the business.  What business tactics (courses of action) and policies (core business rules) would be supported, and why these would be best for meeting their objectives.  In other words, she wanted to see the underlying motivation laid out -- not for the new system per se -- but rather for a new way of doing business.  She had not been able to get that from the business side because there was too much 'systems' in it.  And she had not been able to get it from the IT side because there was too much 'business' in it.

I made the mistake of calling this "the business case."  She quickly corrected me.  They had done high-level cost/benefit analysis previously, and had satisfied themselves on that score long since.  She did not mean that.

She wanted proof that the business implications had been examined and resolved before they went into actual design and development.  That meant answering two fundamental questions:  one looking 'down' from objectives, and the other looking 'up' at them.

• Looking 'down' -- What are the optimum tactics and policies, and how would the associated risks and conflicts would be resolved.
• Looking 'up' -- What is the business motivation for each of these tactics and policies, and why are they appropriate.

Actually, these are two sides of the very same coin.  They require what my associate, Gladys S. W. Lam, and I call a Policy Charter, which I have come to believe is a key element of the business rule approach.  In our experience, a Policy Charter does not need to be all that large -- just a small-sized picture of the big picture.

# # #