Abstract: The second of seven posts discussing BPM governance. Nothing quite like BPM has been attempted before. Today we are held hostage to the very systems that allowed us to scale to this level. We need to balance the decentralized productivity that today's technology empowers while still embracing the centralized scale that yesterday's technology enabled. BPM is a top-down targeted set of small bottom-up implementations. A vertical integration of in-process performance metrics across a horizontally integrated implementation. To do this, BPM is more closely connected to business users than any technology development in history. A new model for governing these projects is needed. Five Charters for BPM Governance are being proposed and will be open-sourced under a Creative Commons license. This post introduces them and briefly describes the purpose of each one. Future posts will discuss each of the five in more detail.

BPM Is Different

BPM is just different. In the past, projects with IT software dependencies were funded as a single line item and had a single, defined set of requirements in the form of "speeds and feeds," the functions required by the application. When you deployed the application, and trained the users over some period of time on a static, unchanging application, you were pretty much done.

BPM intends to break this cycle by altering the core assumptions underlying it.

• A "network" of bottom-up process application implementations
• Directed, top-down strategy driving the implementation roadmap
  
• A primary mental model of time-boxed deliverables vs. feature-based deliverables
• Many iterations (versions) of each process application
• Ability to adopt these iterations in the business (changing application plus an increasing user community)
• High re-use of process application components
• Constant business-user involvement in the development process
• Constant business-user involvement in the deployment process

The Elements of New Governance

We simply don’t have governance models that we can rely on to:

1. Establish how this new type of platform is shared; who can play in the BPM sandbox
2. Provide visibility into the metrics the BPM projects are supposed to attain, and their success; provide structured guidance on the alignment of a given project to the program's chartered goals; alignment of bottom-up process projects
   
3. Provide a scalable mechanism to generate and gain approval on business cases for BPM projects; define financial and other requirements for entry of a project into the program
   
4. Provide a defined way that BPM projects get on the interface roadmap for access to core systems; define interface maturity requirements that align with BPM project requirements
   
5. Define the way shared BPM infrastructure will be maintained and how that cost will be allocated to the various processes under management
   

And so this issue of governance is key. A new governance model for BPM is needed. This model needs to embrace how the program of BPM works, it needs to reflect the differences between BPM programs, projects and processes. It needs to ensure structure, while embracing the decentralized implementation at the core of BPM’s appeal. It needs to create “BPM enterprise zones” inside your company, stimulating improvements at the edge of every process, while always feeding into the top level goals your processes serve.

Governance. What the heck is it?
The first problem with "governance" is that the word has been diluted. It's blather. 99 people out of a hundred will, when asked about governance, start going down some buzzword bingo list of words and phrases and say absolutely nothing. Everyone who hears this mumbo jumbo will dutifully nod their heads at such important concepts and then walk to the next meeting and, of course, do nothing different.

But in fact, BPM governance is the most important aspect of any BPM program done at scale. Governance is not unique to BPM or any other aspect of technology. Governance - the institutions and mechanisms by which you oversee the development, implementation and growth of a given body - is required for human progress.

The first thing we need to do when we drill down on governance is that we have to make it real. Tangible. Governance is not some abstract notion, although it contains abstract notions. For example, the US Constitution is a concrete (if sometimes inscrutable) governing document. So while we need overall visions for BPM (a Declaration of Independence, if you will), there needs to be an actionable set of governing rules that can be communicated and followed. These rules help determine:

• What projects are included in the BPM initiative
• Who is going to run these projects
• How projects are to be approved
• How labors will be shared
  
• How projects will be measured
• How projects fit into the overarching BPM goals
• How your competency will be achieved company-wide

The Five Charters of BPM Governance

1. Charter for BPM Platform Sharing
2. Charter for BPM Democracy
3. Charter for BPM Project Budgeting & Transparency
4. Charter for BPM "Conflict Situations"
5. Charter for BPM Platform Investment

Over the course of the next five blog posts, I'll discuss each of these. Subsequently, I'll be making these Charters available under a Creative Commons license. I'll also be establishing a web site where the community can alter and improve upon the skeleton documents I'll set up. I don't have any pre-conceived notions of how all this should be implemented. I only know that we need to implement this framework, and the more quickly we do it the better. Companies around the world are struggling in moving from BPM projects toward scalable BPM programs. But there's few signposts along the way, and even fewer companies who have actually achieved the vision, at scale.

A Brief Description of the Five Charters

Charter for BPM Platform Sharing

Too often today the people or small team who did the first BPM project are now the "keepers of the flame" so to speak. These people become gatekeepers; whether they wish to be or not isn't the point, they are gated by their own organizational influence and limited resources. Further, in companies of any size, these teams generally aren't the teams that have the most visibility into the business. By the very nature that these teams bit off on a fairly leading edge technology, or at a minimum they were first-users of a new technology, they probably are not in the best situation to capitalize on their successes to build a scalable organization.

How the BPM platform is shared among projects, and how the roadmap of projects is determined, needs to be bigger than the individual(s) who has had a success or two. It needs to be institutionalized.

Further, because the roadmap of BPM is fundamentally top-down, but the implementation very bottom-up, new steering committees of cross-functional business leaders need to be created, independent of the bottom-up skills that might be located in, say, a Center of Excellence. In fact, a CoE should be one of the tactical results of having a Charter for BPM Platform Sharing, and only one. A CoE is a tactical implementation mechanism, not a strategic body. This Charter lays out the principles for sharing the platform, and the bodies responsible for ensuring strategic alignment of the BPM projects, and the roadmap for BPM.

Charter for BPM Democracy

Everyone's a part of BPM if you do it at scale. And guess what, BPM is not BPMS. Like any enterprise technology, the "orchestration engine" has only a relatively minor part to play in the life of all the business users. To do BPM at scale, you need to bring your company's culture along. This requires a commitment to improving communication about process improvement, process inefficiency, change management and many other non-tool things. To create this culture, you need a commitment to open dialog- free speech and non-government-owned TV! - throughout your organization.

BPM is a programmatic approach to making every white collar worker in your company twice as productive. It is much bigger than orchestration of tasks. Communication, cross-process understanding and a culture of process-centric innovation are the tactics of BPM, along with the automation of process. Defining that mission is the work of the Charter for BPM Democracy.

Charter for BPM Project Budgeting & Transparency

Budgeting for BPM projects is quite different than normal software projects. It needs to cover a time period of multiple releases, for example. Budgeting also requires non-cash items, like the contribution of key people from the business on to the process projects.

Project chartering also requires new transparency into the in-process measures that give you the forward visibility that you want. This forward visibility - understanding every process like a sales pipeline - that gives you the most agility, even more than the real-time changes that can be made to the tooling.

This Charter makes clear those requirements and provides for a forum for understanding metrics across business silo's.

Charter for BPM "Conflict Situations"

BPM doesn't live in a greenfield silo divorced from the 40 years of propagated systems that is your company. How do these co-exist? How does BPM "drive" your SOA initiatives (or does it at all)? How do you align BPM roadmaps that deal in weeks with system renewal and consolidation efforts that legitimately deal in quarters and years? We need to establish a mental model of how these efforts align with one another. This Charter documents the requirements for aligning roadmaps and providing specific mechanisms for the timely and cost-effective achievement of all technology roadmaps: BPM, renewal and consolidation.

Charter for BPM Platform Investment

Is BPM a shared service? Do you allocate the costs based on the number of process applications you think you will build over three years? Or just this year? And how do you allocate the maintenance of the platform across multiple process applications. By number of users? A fixed fee for each? What about license costs?

And how do we maintain our infrastructure? What about upgrades? And what happens if an upgrade to the infrastructure affects one of the existing BPM process applications? Who pays?

This Charter provides a framework for maintaining the infrastructure, knowing that up-to-date infrastructure is the best thing you can do to keep technology evergreen, but also provides a framework for how the cost will be fairly shared.

Next - A detailed discussion of the Charter for BPM Platform Sharing

A Note on My Inspiration for the Five Charters
In his book, The Bottom Billion: Why The Poorest Countries Are Failing And What Can Be Done About It , Paul Collier, a Professor of Economics at Oxford, lays out the five governing documents he believes are required to set up an effective government. They are:

1. Charter for natural resource revenues
2. Charter for democracy: free speech, TV, radio
3. Charter for budget transparency: top down, bottom up, peer review - ex ante, ex post
4. Charter for post-conflict situations; standards for after rollout?
5. Charter for investment

I read these after I saw Dr. Collier speak at TED in the Spring. I had been thinking about BPM governance for some time, and most specifically since last December, but the specifics of what were needed hadn't crystallized until I saw Collier speak, and then read the book.

For those of you interested in the state of our world and the potential for the emergence from poverty of many of the world's people, read this book. It's the most insightful new book I've read about the world we live in since The Pentagon's New Map.

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