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.