Achieving a balance between policy and process

Have you ever wondered where business rules come from?  Who thinks these things up?  We say "the business" but it is a small core of leaders, thinkers, and analysts in any self-contained unit of the business that is empowered to create business rules.  This group goes by various names, but in the business teams that I work with, it is often called the "policy" group.  These are the folks that consider the specific business needs of a unique slice of customers and create "programs" designed to meet their needs, increase revenue, increase loyalty, and remove disincentives for ongoing business.

This notion of policy specific to a customer segment is a key element in the ability of Microsoft to respond flexibly to the needs of customers.  Microsoft does not make money by building the newest innovations every year.  (As the slip in Vista ship shows, unfortunately).  We make money by delivering all of the basic needs and a broad swath of the "cool stuff" in a way that makes sense for both the customer and for Microsoft.  This flexibility is a major competitive practice.

One thing to consider: this flexibility is part of the culture and part of the business structure, and not an explicit business rule.  That means that some IT initiatives may come along that could, if not handled well, reduce costs or increase performance but may also have the  unintended consequence of reducing this precious and highly valuable flexibility.

So we go the other way.  We protect the flexibility, at the cost of increased expenses and potentially reducing the performance of business systems.  (I'm not talking about MS Products like SQL Server here.  I'm talking about internal financial, sales, marketing, management, and fulfillment systems).  This protection is automatic and part of the culture.

In a way, this translates into policy like this:

Policy maker: I think it would be cool if we put feature X in our order entry system.

IT person: We've never done that before on our order entry system.  That means we would need to create a new user interface and a bunch of new rules.

Policy maker: So what?  Do it.

There is no structural mechanism that responds: "No.  We won't adopt this requirement because, for this one requirement, we are creating a new application.  If we drop this requirement, we could leverage an existing application.  This is the straw that breaks the camel's back.  Stop here."

There should be.  Policy and Process need to work together, hand in hand, with each willing to give and take to the other.  If Policy always wins, it is easy to create rules, but after a while, the IT systems fill up with overlapping and badly connected systems.  If Process always wins, then it is hard to create rules, and sales will suffer.

Somewhere in the middle is the right answer.  Both Policy and Process need to work together, sometimes giving, sometimes standing their ground, always cognizent of the value of the other. 

Making this happen in practice needs to be part of the organizational structure... embedded in the culture.  This is why every business capability (like "accept an order") needs an owner, so that there is someone for the business policy teams to negotiate with.  Someone who can give and take, compromise and stand ground.

Yin and Yang.  Policy and Process.