Abstract: Existing project chartering in your company is built to protect against the risk of failure big projects have, and also to “weed out” shadow IT projects. BPM projects are not big, and at the business case level they can look a lot like a shadow IT project, so existing chartering requirements are stacked against their approval. We need to change that so that the agility promised by BPM can be achieved at scale. I’m proposing five Charters for BPM Governance. These will be freely available under an open-source, Creative Commons license. Prior to release, they will be discussed over a series of seven blog posts. This is the first.

We're in the midst of major management change. Traditional application-centric projects are by their nature big bang, pervasive, invasive projects that, if for no other reason than their obscene cost, have a formal, top-down governance model. Now, your company’s governance may or may not be effective in practice, but the model is mature, and no doubt it provides visibility all the way to the top of the organization.

Let me ask you two questions:

1. What would you have to go through to charter twenty $500,000 projects in your organization?
2. What do you have to go through to charter one $10,000,000 project in your organization?
   

Both cost the same, but I’ll wager that #1 is 10 to 15 times more difficult.

We simply are not set up to govern BPM.

Avoiding Big Disasters

Strategic IT projects of the past have all shared risk characteristics that we’ve come to accept as normal:

• Costly
• Lengthy
  
• Unmet expectations upon delivery
  

Over the years, we’ve built up biases that “this is the way it is,” and we’ve built up competencies for managing around these risks. Governance models. We think our managerial dog is wagging its tail, but in reality the dog of our legacy IT systems is wagging the tail of institutional governance. We’ve built our institutions to deal with the monolithic mainframes - both the hardware and software kind. And in so doing, we've built them to solely deal with those mainframes!

By the way, this isn’t limited to custom applications developed many years ago. Who hasn’t heard of SAP implementations, IBM projects and Oracle projects that have gone horribly wrong? In fact, isn’t late, over-budget, and off-target the norm with these things?

Avoiding Little Disasters

BPM projects are fundamentally different from typical high cost, long term development projects. Because BPM embraces at its core the notion of many relatively small, timely quick-win projects, it’s easy to contemplate anarchy; a thousand "shadow IT" BPM process applications running amok, creating the next Lotus Notes or Microsoft Access/Excel chaos. About once a week someone pulls me aside and whispers about how they aren’t convinced about BPM’s ability to scale; they “can’t imagine letting users loose with yet another Access, Excel or Notes.” And they're right: who needs that headache? Won’t BPM become a bunch of random point solutions, some of which deliver value, many of which don't and none of which fit in to a cohesive whole that can be effectively maintained and migrated to meet your company’s objectives.

Avoiding Any Disaster

And so here's the conundrum facing today’s IT management: we know big top-down silo'd applications, like ERP, are this century's mainframes, but at least we know how to govern those projects. We also know that BPM offers the hope to break that paradigm, with targeted application development, pragmatic designs, and rapid deployment. But we have no mechanism to cope with that at scale.

I’m not talking about the project management. I'm talking about the program of several BPM projects. Every aspect of today’s global organization fights this. Examples include:

• A project’s procurement costs are expensive
• IT hardware provisioning is expensive and slow
• Allocation of business change management resources is built on an old model of massive user training over a long period of rollout.

In response to protecting ourselves against potential disasters, we’ve built governance mechanisms that are put in place to limit the risk. Things like:

• It’s hard to charter a project
• It’s costly to get a developer allocated
  
• Heck, it’s impossible to even get time on a procurement officer’s calendar
  

It's funny. We work with companies all the time who have several hundred people assigned to massive projects which will take quarters, if not years, to deliver. Yet, it's almost more difficult to locate three people who can work for 4 months on a BPM project that results in a deployed process application.

I've concluded is that this isn't for lack of want or resource, it's for lack of governance. A lack of a structured way to scale such a seemingly ad hoc request.

Another example I hear about all the time is that getting 10 people for a given project is just as difficult as getting 2 people for a project. And, a corollary is that it is more than twice as difficult to get two people for two projects than it is to get four people for one project. Again, my conclusion is that this is because of institutional bias against small, seemingly ad hoc projects. This is probably well-founded, in that in the past this resulted in many "shadow IT applications" which carried more than double the maintenance costs. So some institutional friction against multiple projects is something that the organisms have built an immunity against.

Of course, BPM changes this. The whole point of the technology is that it can support multiple, discrete process applications in a new, scalable way. And you want many of these projects going on, seemingly unconnected form one another, because you will be getting reuse of services (about 50% on average) even if the business process is very different. Also the linkages between the network of seemingly discrete projects are pretty high.

In fact, that difference is the point of the battle: BPM is a post-millennial, post-application way of thinking, one that assumes the existence of technology and is not agnostic to it. The difference between BPM and traditional technologies is that the technology is embedded so closely into the the business that the lines between what is IT and what is business get blurred. This means the power shifts more and more to the business people running the processes, and away from the ERP bigots and integration specialists who dictate what can and can't be done by the business.

To Get New Outcomes Requires New Thinking

But to “do” BPM at scale, you need to think about governance very differently from, say, an SAP implementation. Probably the biggest reason you’re thinking about BPM is because you want some new outcome.

To get that new outcome, we need a new model.

We need this new model because the chartering processes that have been built to avoid the disaster of traditional projects have inherently stymied your ability to not do a traditional project!
Ironic, isn’t it?

BPM Basics

Enter BPM, where each project is small - two or three full time people - and the time duration to deployment is so short - 90 to 120 days is reality - and you just don’t match up with the cost of chartering. I mean you may, literally, spend as much time chartering the project as the project duration itself.

A BPM program is fundamentally different. I should say "if done well, then a BPM program is different." BPM is a program, not a project. It’s a bunch of projects, maybe hundreds but certainly dozens of projects. All meant to align with a few - maybe 2 or 3 - top level goals. All of which add value to the business every 90 days or so. It’s an entirely new beast of internal application development because it is the antithesis of almost every centralized IT application ever built.

BPM is built on many of the pragmatic principles of “shadow IT” application development:

• 80% better than today is good enough, we’ll get the rest with version 2
• High degree of involvement of the business in the application development
  
• Small team, low investment, fast return
  
• Small, seemingly random, chunks that form a network of managed processes; built literally from the bottom-up

But with the qualities required for scale:

• Centralized, shared infrastructure
• Deployed and maintained using top-down IT best practices and procedures
  
• Secure, highly-available, hardened applications
  

An Open Invitation To Participate

In this series of posts I’ll be putting forth five Charters for BPM Governance. These will be straw man proposals; I don’t know how these mechanisms should work. I only know for sure that existing governance mechanisms are not working, and it is at the core of what is preventing the agility that is the promise of BPM from being fulfilled at scale in virtually every company of any size, around the world.

I will be open-sourcing these Charters. I want the BPM community as a whole, regardless of tooling and partners, to have a dialog and contribute to these Charters. They are not vendor or tool-specific. They will be freely available for use and modification under a Creative Commons license. They will be developed on a wiki so that we can all participate in their evolution.

Finally, I don’t expect any company will adopt these Charters intact. That’s OK. They are meant to be the codified “best efforts” for how to think about establishing BPM governance in your company. You, your management, your procurement group will need to adapt them to fit into your existing culture. But now we’ll at least have something we can point to, start with, so that we can begin changing our internal governance mechanisms and bring them into line with the agile efforts every business today must adopt in order to survive.

Next - The Five Charters of BPM Governance