I'm on my third startup and I've discovered three differentiators between winners and losers: focus, sustained execution & culture. The same can be said about any new initiative, I guess. Lots of companies have gone "six sigma" yet few are really great at it. Saying "everyone is a green belt" does not a culture make.

The same is true for BPM.

So what is "culture"? How do you instantiate it? Can you do this in a repeatable, sustainable way, or is it simply the result of random evangelism by high priests. In a nutshell: how do you develop, scale and then maintain a culture?

I've been struggling with that question ever since it became apparent that culture is the single biggest impediment to moving from a "BPM project to program." There's little doubt that BPM is simply one milestone on the longer arc which is the movement of technology into the business, as business people regain control of their information. But it's a big milestone. There is as much cultural change required to do BPM at scale as there was to move to desktop computing at scale. This isn't an IT choice of, say, "BPMS vs. Ruby-on-rails."

It is BPM vs. business-as-usual.

I'm reminded of the time when the COO of a "top 10" law firm told me that "lawyers will never be typists." That was in 1990. Of course, by 2000, every lawyer was "a typist." Cultures changed, as did the economics of law firms. Firms either led or followed the move to desktop computing, but in the end everyone adapted. And the leaders thrived.

The same is now true for BPM.

Business economics are changing, and BPM can be either a catalyst or a response; an offensive weapon or a defensive one. You can lead or you can follow.

But in order to lead you must accelerate the culture required to adapt and adopt. Today's business culture, from top to bottom, is resistant to much of what BPM preaches. We pretend to champion:

• Incremental, continuous improvement   
• Structured change
• Re-use

Instead, despite our rhetoric, the actions of people in company after company show that:

• We prefer to "boil the ocean" and fix everything at once (often taking the subtle form of: "automating a bad process just means you still have a bad process")
• We really prefer doing things our own way and letting others do things their own way
• And we truly believe our way is better, as opposed to some common way

We are BPM hypocrites.

In yesterday's New York Times, David Brooks wrote an insightful column about dignity (and the loss thereof) in the public sphere. He wrote about how as a young man George Washington, who would become the US's first president, wrote down "110 Rules of Civility & Decent Behavior," and then applied those rules to his own daily life. Brooks calls these rules "the dignity code."

"[A]s the biographer Richard Brookhiser has noted, these rules, which Washington derived from a 16th-century guidebook, were not just etiquette tips. They were designed to improve inner morals by shaping the outward man. Washington took them very seriously. He worked hard to follow them. Throughout his life, he remained acutely conscious of his own rectitude.

In so doing, he turned himself into a new kind of hero. He wasn’t primarily a military hero or a political hero. As the historian Gordon Wood has written, 'Washington became a great man and was acclaimed as a classical hero because of the way he conducted himself during times of temptation.'"

I love that idea, that "inner morals" might be "shaped by the outward man." Of course, religious and other ritualistic frameworks have existed for this same reason for centuries.

Brooks touched on this same topic last week in The Conversation, a New York Times online weekly discussion he has with Gail Collins. They were chatting about whether hypocrisy in public figures is a relevant issue. He wrote:

"I suppose it all comes down to whether you believe good character is constructed through culture and artifice, as I do, or whether you think people are naturally good and that social conventions are warping and destructive."

Character as a result of "artifice." Does BPM have an artifice, a dignity code that we can look to in times of stress?

We will all, at times, be hypocrites... we won't always do the "BPM-appropriate" thing, but we need to try. We need those rules of BPM Etiquette and Decent Behavior, so that we can objectively assess our progress.  Without them, it is simply too easy to avoid "walking the talk." We will continue to give lip service to "agility" and "continuous improvement" and "change as fast as the business" but we won't. Not really.

We need a BPM dignity code.

Last week I met with the senior leadership of several of the top Indian systems integrators and outsourcers. The week not only confirmed my suspicion that these firms are becoming the strategic partners of the Global 2000, replacing the stack vendors and SAP in that role, but also shed new light on why this move might have even greater implications to the businesses they serve than even they realize.

To put it bluntly, a great outsourcer may be better at quickly improving your business than you are. Why is this? Because, these companies are quickly achieving the cultural maturity required for BPM that eludes even the most progressive companies in the world.

Companies have realized that moving from a few successful BPM projects to a scalable BPM program is difficult. Where the 80/20 of BPM projects is 80% go smoothly, the 80% of programs face difficulty. McKinsey has recent research on why this is and it argues persuasively that cultural factors are the single biggest contributor. It is hard to change a corporate culture, and business improvement programs require change to occur at every level, on every desktop.

If change is so hard, then why is it moving faster at outsourcers than at beleaguered companies? I think it is because process is their product.

Previously I've written about how outsourcing has, in the past, led to even worse process, giving the illusion of business improvement due to labor arbitrage-induced savings. But two strategic trends are forcing process improvement today... even on India. First, labor costs are normalizing with the West. They're still lower than the US and Western Europe, but not by as much as they were. And second, even lower cost countries are now competing for the BPO wallet. So the top integrators and outsourcers must achieve qualtiative process outcomes that the lowest cost providers can't achieve.

That is: the Indian outsourcing firms must drive real performance improvement into the processes they run in order to compete, achieving both efficiency and effectiveness; and they are committing to those outcomes contractually in order to win business.

In my meetings in India, I was told that the typical outsourcing deal now requires significant cost reduction every year, for increased volumes of work. Further, these deals typically are moving more and more to process outcomes (SLA's, KPI's) being measured every year, and substantial improvements in those metrics over the life of the contract. And finally, they tell me that in years one and two, much of the savings is in labor arbitrage, but that in the out years (most deals are in the 5 year range), substantive, non-linear changes are required, which force qualitative process improvements be found by the outsourcer in order to make a profit.

In a nutshell, they have to do BPM in order to do BPO. And because the process is their product they have to instill a culture of BPM in order to stay in business! Very few end user organizations have this compelling of an event. Most companies still view their product as Widget X; for the outsourcers, Widget X is the process!

This acquisition of culture is key to the strategic influence the outsourcers can gain. This isn't just about labor arbitrage, but about the willingness of the outsourcers to deliver better outcomes across the board. Instilling this culture, through acquisition or organic growth is key to scaling business improvement in general, and process improvement specifically. Could outsourcing be the fastest way to go? It may or may not be, for you. But it is true that this is the x factor that is driving business (and IT) strategy today, making the culture-carriers, the BPO's and integrators, the strategic partners for the Global 2000.

So this leads me to the final questions: today, you may think of your SI as a means to bring cost reduction and consistency to your IT processes, and your BPO partner as bringing the same to your business processes. But what if you could simply augment your business people in order to graft the culture of change? Is this a new value prop for the Indian companies? Does it accelerate your business outcomes while preserving other aspects of your company's culture in better ways than simply outsourcing everyone?

More and more companies are beginning to understand that business is change and when that's the case, process becomes your product. The Indian outsourcers could be the Toyota of white collar process understanding, and they could hold the key for business improvement ideas, like Toyota's lean production methods.

I've written previously about BPM Governance and you'll see some more on this from Lombardi later this Spring. The parallels between work being done to understand and implement BPM Governance and the work being done to understand and implement governance in emerging countries is strong. Both represent big changes because in both cases, entire populations (employees in one case, citizens in another) need to understand their "new democracy." BPM isn't "top-down," and it's not "middle-out" or "bottom-up." It is simply, and complexly, democratic.

Therefore it was with interest that I received a pre-release copy of a book from Chris Anderson, the curator of TED. It's a book by Jacqueline Novogratz, founder and CEO of the Acumen Fund, and in the book she tells many stories about her personal journey into social entrepreneurship, and we learn another bit or two about how people behave, which helps us understand how they can and will govern. As we look to BPM as a way to manage business in an interconnected world, these first-hand stories are invaluable.
Whether or not you see the parallels as I do, this book tells some interesting stories, and is both thought-provoking and insightful without yelling. Not a small thing.

   

Here's a video of Jacqueline talking about her book The Blue Sweater: Bridging the Gap Between Rich and Poor in an Interconnected World, as recently posted on McKinsey Quarterly's web site.

And here's a link to the book on Amazon.

This appeared originally as an Op-Ed on CIO.com.

Blue collar workers aren't killing Detroit, white collar workers are. And since the entire service economy is built on white collar work, what happened in Detroit over the past thirty years and happened to banks in the last 10, will happen to everything else in the next three.

In fact, everything in the American economy is driven by service economy workers (“white collar workers”). But the model upon which this economy is built is broken. It is based on the unscalable heroics of artisan workers, who largely work outside the limelight. In the worst cases, they work outside any light at all. To prevent another industry meltdown, business leaders need a set of white-collar principles based on the bedrock of visibility.

As Congress deliberates over a historic bailout of the Big 3 car manufacturers everyone has become an expert on what needs to change. According to one opinion in the Wall Street Journal the problems start with the big, bad unions and stop only if you can "gut" them. According to the Beltway folks, we’re in this mess because the car manufacturers didn't produce enough hybrids or, in the vernacular, they "didn't build the cars America wanted."

Neither of these gets it right.

One of the three (Ford) is in demonstrably better shape than the other two, and it's no mystery why. Two years ago, when he took the reins of Ford, Alan Mulally identified two things that needed to change: parts costs have to go down, and engineering productivity must go up.

Get it? The white collar workers who design the cars have to move from artisan to engineer, and they need to work together across all the company's platforms to use common parts.

While cutting healthcare benefits and union concessions might help conserve another month or two of cash, neither would address the causal differences between old school manufacturers and those from a new school focused on white collar efficiency and cross-process visibility.

But this type of change doesn't come on the cheap. It requires imagination and determination. Imagination to re-think the details of what we do and how it’s measured. Determination to take on the entrenched interests inside our companies and drive change right down to the desktop of every white collar worker. So far, these failures haven't only resulted in the Big 3 crisis, and all the related manufacturing meltdowns over the last 30 years, they’ve also caused the mess on Wall Street.

In Michael Lewis' terrific article on portfolio.com, “The End Of Wall Street's Boom,” he highlights the two key drivers of the banking meltdown. First was the huge, unseen risk of leverage in the new financial products that were being developed. Second, in the article's money quote, John Gutfreund , the former Solomon CEO, reflected on the role of CEOs across all of today's megabanks. He said "I didn't understand all the product lines, and they don't either." Lewis writes "the Wall Street C.E.O. [has] no real ability to keep track of the frantic innovation occurring inside his firm."

CEOs and everyone below them must have a common understanding and visibility into the processes needed to establish new efficiencies. As an example, it’s rumored that Toyota’s engineers spend more than half their time “doing engineering.” In Detroit, it’s half that. And as Lewis points out, few people anywhere knew that a single mortgage was leveraged up to 10x through the various CDOs and credit swaps.

In both of these seemingly diverse industries, decisions about parts, risks and returns are made in the vacuum of virtually unchecked darkness. In companies today there's no direct linkage between the tasks your people are doing and the goals of the organization.

This isn’t a lack of automation, it’s a lack of visibility. Regardless of industry, the world’s largest companies are houses of cards, built on darkness and risk.

This should scare the hell out of us.

Ironically, the off-shoring, which was the first response to the symptoms of the artisan-economy-on-steroids, served to increase risk and darkness even as it hid behind the allure of cost savings.

Because the growth in the service workforce was not easily scalable (costs went up in a linear fashion as heads were added), CEOs found it easier to fire local workers and hire distant ones who were paid a fraction of their U.S. counterparts. These executives took the easy way out, often-times they actually added headcount to an already-unwieldy process and boasted about their “savings.”

So now our U.S. companies are in increased peril: white collar tasks are more opaque than ever, while customer and product risks are on the rise.

Today, leading edge companies across the manufacturing and services spectrum are working on new ways to reduce risk, and increase visibility. The technical bits are fairly easy, but the cultural change needed inside the white collar parts of the organization are massive.

There needs to be a revolution in implementation of processes that bring greater visibility and less risk to all aspects of our businesses. It is no longer acceptable that senior management remain ignorant of the goings-on at even the deepest depths of the organization.

Technology can play a key role in providing this linkage and visibility. But before this can help, we need leadership at the top that doesn't fail to imagine and is determined to make their people work differently. This isn’t about taking on the popular bogeymen of the past. It’s about fundamentally changing our culture and our capabilities.

The old manufacturing and service economies can be saved, but they both need to be rebuilt upon the bedrock of visibility.

We need a new service-enabled economy that lowers business risks, lowers business costs and increases the number of local jobs.

But it requires imagination and determination from the very top of the tree. It requires driving change throughout the upper, middle and bottom of the white collar parts of your organization.

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