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 tell you captain, if you look in the maps of the worlds, I warrant you shall find in the comparisons between Macedon and Monmouth, that the situations, look you, is both alike. There is a river in Macedon, and there is also moreover a river at Monmouth."

- Fluellen, in Shakespeare's Henry V, explaining that his hometown Monmouth, Wales, is very similar indeed to the classical kingdom of Macedonia

Last night I had a dream that Fluellen said: "Pegasystems has training. Oracle has a BPMS. And IBM has Blueworks. I warrant you shall find in comparison of these situations with Lombardi, look you, is all alike."

The Welsh do make me laugh, and I did, I woke up laughing.

Normally, I use this blog to talk about industry issues and try to not so much flog Lombardi-specific products as deal with universal issues. But not today. Today is the culmination of hundreds of man years of effort and understanding here at Lombardi. Today marks the end of what I call "the first decade of BPM" and sets the industry on what I think is going to be an all-new course, or more accurately, a much broader and valuable course. And so out of pride, but also because I think that the BPM industry shifted today, I want to write about Lombardi.

Today Lombardi announced major advances in all three areas that determine success or failure in BPM:

• The need to communicate - you have to make business improvement personal
• The need to automate - you have to drive productivity and re-use
• The need for talent - you need to be able to assess risk, plan, and lead

Forget about simplistic approaches to driving transformational change based solely on whether your BPMS (or "BPP" or "PAAS") has a given feature. The so-called "Business Process Platform" as a sole-sourced technological salvation is a hoax. It's a solipsistic approach by technologists to once again say "if I have a better tool, I won't be as big a fool." Go on, stare at your image in the water and try to pawn all this off on simply another development tool or architecture. Instead, you need to take to heart what Toby Redshaw, CIO of Aviva, said a couple of weeks ago (paraphrasing here): If you're in IT and not doing BPM, three years from now you won't have a job.

He wasn't talking about a tool. He was talking about change and changing everything: how we relate IT to the business, how we use tools, and how we manage, nay, lead, change in our businesses through the use of BPM tools and methods.

Today Lombardi re-defined what a BPM platform needs to be; three specific vehicles:

Blueprint (Spring '09): The place your people should go for business improvement conversations. Using a unique approach of combining structured process (BPA) tooling with Facebook-style social networking and wiki documentation, Blueprint helps guide personal conversations about "how I think I can do my job better" into the scalable discovery of practical business improvements. Blueprint puts BPM on every desktop. Some of our customers have made this commitment and are in the process of training thousands of users. Yes, thousands. Want to knock down some walls in your company? Put Blueprint on every desktop and lead people (by example) to make suggestions about their jobs, their tasks, their activities. Even if you're not ready for the automation part of BPM, Blueprint will help you discover your processes, and then improve them. BPM isn't just about "modeling" and "BPMN" or "rules." It's about changing a culture, about embedding technology into the fabric of how we do things. We can learn from social media how to do this. This isn't your daddy's enterprise software, because it isn't 1983 anymore (or 1977, or 1896).

Teamworks 7: What's new about BPM-style process application development? It's the model, stupid. And so why is all the management of models and their internal assets built on top of traditional, decades-old-school-text-based source control systems? Using models, the application development goes faster, but then when you save a version of the model and try to manage it (both at design-time and at run-time), our competitors use traditional notions, or incomplete representations of the model (they might, for example, restore the rule that existed at some point in time, but not the UI's or the integrations).

Teamworks 7 answers this question with a completely new way to manage process models for their entire life - from the beginning of time. We looked at every use case along the entire process application life-cycle and we solved every problem that BPM-style development threw at us. Let's take a simple example. BPM demands iterative development. So what happens at the end of every sprint in agile? You know what happens: you tell people to "stop development for 24 hours" to stabilize the system, to make sure it's going to work. With Teamworks 7 you simply create a snapshot of the working version, then you keep developing, and when it's time for the Playback, with one click you go Back In Time to the Playback version (while all the other developers are still working on the tip), and you play it back. Zero lost productivity, entire model-universe reversion. One click. Back In Time is the biggest advance in iterative/agile development tooling since the method was developed. And you can quote me.

But that's just the beginning of Teamworks 7's repository model management. Dependency management is a problem that is solved, finally, with Teamworks 7. This is the best way to manage dependencies in any SOA development environment. Ever.  Because of this, Teamworks 7 also enables re-use to an extent never before realized. Re-use is the lynchpin of the BPM value prop. And the barrier to real-world re-use of technology assets isn't knowing they exist, it's knowing you won't get screwed by upgrades to those processes/services if they change. With Teamworks 7, you won't get screwed from service or rule re-use. Ever. And yes, you can quote me on that.

Lombardi University: OK, so you have people talking to one another. And you have a platform that truly enables the end-to-end business process application life-cycle. Now what? "How do I sell BPM to the business?" "Where do I find qualified people?" "What skills do I need?" "My infrastructure is maintained in a different group, and they are difficult to deal with!" Although BPM is (relatively) new, it isn't about all-new skills, and it's not about building an empire or creating an "other" part of the organization to deal with BPM. This is about adding the unique aspects of BPM-style development and management to each of your peoples' CV's. Sure, all vendors do staff-augmentation with experts, but there's also skills-augmentation. And frankly, this is what we are hearing our customers and partners want. "I have good people who can (build apps) (lead projects) (maintain infrastructure) but this is a bit different. Teach my people. Help me (or my partner) become self-sufficient in a scalable way."

With Lombardi University, there is now a roles-based way to augment your peoples' and your partners' skills. Roles-based is the key. This isn't simply education on the speeds and feeds of a tool.

And with Lombardi University certification, you can also measure the attainment of those skills and your own maturity as an organization. Have you deployed five process applications? How many people can you rely on to maintain that infrastructure? How do you assess the risk you are assuming? How do you talk about a 1, 2 or 3 year roadmap of skills development? With Lombardi University, there is now a way to do just that.

And not only that, I've talked with CIOs around the world and their #1 talent concern is this: how should I lead my BPM initiative? Who should do that? What does that person look like? Well now, for the first time, there's BPM Executive Leadership courses. We're launching two at the outset. These courses don't teach modeling and products, they teach how BPM is different from other programs - and how it is the same - and gives concrete guidance on how to lead your BPM effort, so that it doesn't become an "other" - that it is mainstreamed into the programatic fiber of your company.

By the way, we can't do all this by ourselves. So we've embraced technology from Saba to help you manage your talent development programs, they're the leader in career development software (in fact, your HR group might use Saba... if so, we can mash it all up and you can manage your BPM careers along with the rest of your career development efforts).

We've also engaged outside faculty. Industry experts like Bruce Silver will be delivering courses available through our catalog. Some of them use Lombardi tooling, some don't. The issue is education, not brainwashing. If you succeed with our help, we'll do fine. Derek Miers and his BPM Focus group will be teaching Lombardi University courses. Same with Dr. John Alden, 30 years with Accenture, co-founder of Terraquest. And Andrew Spanyi, author of probably my favorite BPM book, BPM is a Team Sport. This isn't altruism that we're practicing here, it's about your success. If we assist in that, we'll figure the money bits out. So Lombardi University is attracting the best BPM faculty in the world (if you want to be a part of our Extended Faculty, let me know).

Together, these 3 pillars - communication, automation and leadership - combine to form the basis for the platform for BPM's second decade. Lombardi is that platform. You don't have to do it all at once. Like all journeys, BPM is something best tackled one step at a time. Ping us for more information. I promise that if you do, you won't confuse us with Pegasystems, Oracle or IBM, or any other Monmouth of BPM...

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

I'm at the TED Conference in my annual attempt to escape the confines of making and selling software. It's a box, not a process, sometimes. And this year's lineup has pretty much exceeded expectations. Heavy emphasis on physics; I mean, when Amy Tan says "ambiguity is the cosmological constant" of her book writing process, you know that science is on the ascendant. Here at TED, anyway.

This is the third day. Day one was 6 hours of content. Day two began at 9am and the content portion ended at 8:15pm with Karen Armstrong revealing her "TED Wish" that leaders, maybe 1,000 leaders, of the three major monotheistic faiths would establish and proliferate a single governing document, a Charter of Compassion, for how the scriptures of faith should be interpreted. A mental model for reading scripture, if you will, based on looking for the Golden Rule in each passage. Not a bad wish.

Today we just went from 9,000 feet deep (still 4,000 feet above the deepest parts of the ocean floor) to the top of the oldest redwoods in the world. And there was unexpected life in both places. We also heard from Paul Stamets who believes, and attempted to show, that mushrooms have the power to save humanity. At a minimum we saw how fire ants could be eradicated with mycelium. It was pretty good, but not as good as seeing Stephen Hawking speak to us Wednesday, and hear him say that, in his opinion, there probably isn't life (as we know it) in the Milky Way galaxy. Rare earth, indeed.

Well, I come here to keep the entirety of the world - not simply my software world - in perspective, yet this year I find myself drawn further into the web of "process" - Lombardi-style. Amy Tan considered this phenomenon when she said that while writing about a given subject she often stumbles, serendipitously, into chance encounters with the topics she's writing about. She said she's come to the conclusion that "when I am aware of chance encounters being connected, then chance encounters connected to work I'm doing tend to happen more often.... so now I just look for them."

And so I see process everywhere. Today a track on the creative process. Yesterday a disorienting, disturbing talk on the process that led to Abu Ghraib. Today I met a gentleman who "works with companies on their mythology." He helps them rediscover who they are, so they can get on with becoming who they want to be. I call that BPM, he calls it mythology (no wise cracks from BPM cynics, please). Today Brian Cox, one of the scientists at the CERN big particle accelerator said that once the accelerator comes online (the final pieces were put in place, literally, today!) then the story of the process of creation might actually become known. We may know more about who we are, and may be in a better position to figure out who we can be.

The other aspect of all this that's been interesting is the number of people who talk about the closer we get to actual creative process, the closer we get to simplicity. Complexity is the result of time and scale, but the heart of any great scalable system is simplicity. And I find in this, again, an important connection to our world at Lombardi. Brian Cox showed us the very few elements that existed at the beginning, during the 1/billionth second of the big bang.

At Lombardi, we believe process is the story. It is the structured book through which what you do and what you want to be is communicated. How we behave and to what we aspire form the lynchpins of culture. A company's relationship with its customers. How it behaves amongst its employees, between one another. These behaviors are instantiated in processes, whether formal or informal.

At many companies, their mythology, their culture, has become stale. Inert. It's not known, it's not understood or it's inaccessible. We find this is often the case because the means of transference have become so convoluted that any semblance of narrative is lost. When process is not explicit, which is simply another way of saying the process is informal then, oddly, communication becomes formal. And this is exactly the wrong way to go. Folklore, the stories of culture, these memes survive in large part due to their informality.

Ironically, then, the result of informal process is formal communication ("knowledge is power" syndrome). The result of formal process is more informal communication ("transparency" and "open-door policy").

This formal communication results in left-brain actions on the part of the people in the process. Silos. Hidden factories. Leading to unproductive work. Low quality. More exceptions. And finally, lost market share.

Transparency results in innovation - positive change based on trust. "Good fences make good neighbors". If you look at the history of this phrase, it wasn't to say that "excluding others is a good thing," it originally meant that explicit relationships enhanced trust and understanding, and therefore increased empathy and compassion.

To me, BPM is the means by which you document, communicate and then instantiate your actions and aspirations. If your processes are the mechanisms that transfer your culture - internally, externally and into the future - then BPM is the means to make your culture great.

BPM can help you create that possibility.

In his recent post, Neil Ward-Dutton talks about how WebMethods customers are doing traditional application development under the guise of Business Process Management. Folks, automating a business process is NOT business process management! Sandy Kemsley says "these customers are coming from the traditional EAI-type usage of webMethods." Yep. And, in summary, Neil says:

"Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the work—is it business people, IT people or both?

"Unfortunately, getting to the bottom of things is not as simple as saying 'I need a human-centric BPMS" or "I need an integration-centric BPMS'."

Neil, you've hit the nail on the head! And, indirectly, you raised the key difference between what used to be called "the pure-play vendors" (like my company, Lombardi) and the "stack vendors" (IBM, BEA, Tibco, WebMethods). I prefer to use the terms "new-BPM" and "old-AppDev" to describe the vendors, but however you slice it, the new-BPM tooling is directly targeted at enabling new levels of participation of business people alongside IT people in the solution scoping and development processes.

As you point out, that difference has nothing to do with "human-centric," "document-centric," or "integration-centric" but whether the user is approaching use of the BPMS as a new developer tool (with, for example, the semantics of BPEL), or as a way to change the way business and IT interact during solution development. This developer-centric vs. business-centric approach is the key difference in deciding what tools you will be successful with.

Our experience is that if a company uses a BPM tool in the same old way (IT application development owning all aspects of the project and the business expected to deliver a set of detailed requirements at the outset of the project) then the project will fail exactly as often as any traditional waterfall application development effort. Which is fairly often.

But if the customer wants to move to a new model for those processes owned by the business, with the business contributing people full-time to the solution development effort, then the new BPMS tools are effective at increasing success rates, lowering costs, and delivering better solutions. The new BPMS tooling by the focused BPM vendors is better at this, far better, than any of the tooling the stack vendors provide. The old-AppDev vendors provide tools for their target market... and that is not business people with moderate technical skills. In contrast, the new-BPM vendors are focused on providing tools for a new solution development model, one that promises increased participation by the business, while retaining full-control for IT.

Technorati Tags: BPM, WebMethods

I was hiking today up above Portland, Oregon at the Multnomah Falls. Spectacular. Except my damn knees. I started thinking about how I hear people say "gee, I wish I was <fill in younger age here> again" and I have to say I really don't want to go back to most of my younger ages but it sure would be nice to have younger knees. I saw 18 year olds running down the 600 foot drop of a trail. I want their knees. Well like Rummy said "you don't go to battle with the army you want, you go with the army you have."

Oddly, this got me to thinking about business process management and about how almost everyone (except Lombardi, of course) has got it wrong. Most people think business process management is about Process. Wrong. Business process management is about people. Specifically, it is about making people more productive. People of diverse skills. People put in positions they might not be quite ready for. People retiring from their jobs. People starting their careers. Dear reader, if you are in a company with more than, say, 1,000 people, I wonder how many of those people do you think are perfectly suited to their jobs right now? How many have the perfect levels of skills, abilities, training and wisdom to do their jobs at peak efficiency right now? How many in your workgroup fit this description? I'm guessing you have people with different levels, some achieving the perfect blend you need, and some not.

Look, the point isn't that your organization needs help. In fact, the point is that your organization looks a lot like everyone else in this respect! Business process management should be thought of as a way to help teams work better. The team you have is the team you have, in many respects. You can't take the perfect team into the battle of competition tomorrow! You have to get a lot of the job done with the team you have. You might top-grade over time, and you might also lose some of your best people to promotions and their own career changes. The fact is, the people in your business have very different combinations of "perfection" at any given point in time. And in this globalized world, the question senior management asks is "how can I be most effective with what I have?" (A recent NY Times article quoted HP CEO Mark Hurd: "C.E.O.’s work on three things: strategy, operating models and people." Which, loosely translated I think means: what strategies can we pull off given our people, processes and customers?")

If workflow is the means by which we define behaviors, then the real advance of business process management is that it is the means by which we normalize how we measure behaviors and correlate those behaviors with the business results we achieve. Let me say it again: business process management is about how we measure people and correlate their activities with the business results they achieve.

In fact, practiced purely, I'd argue that it has nothing to do with how something gets done, only how well it gets done! It is today's evolutionary state of the most advanced de-centralized management capability. And by the way, if you don't get a grip on this issue - how to decentralize control of behavior while retaining insight into results - you will be run over by the people and technologies of the 21st century. Wiki's, blogs, SaaS word processors, SaaS spreadsheets, IM, Facebook (or Open Social) computing platforms... this all means you will have less control over the specific workflows, and more creativity than you ever thought possible. Your BPM initiative better be figuring out how you can deal with this... because these are becoming parts of the best processes in the world.

BPM helps you get a handle on the chaos that is real life, makes it explicit, and helps you manage around it. It does this by making the work explicit, linking that work to the reasons you are doing the work, and providing insight into the results. We call this trace-ability and it's key to doing business in the 21st century. It allows you to take the army you've got, and make them as effective as possible in executing against the strategy you've set.

As for me, there's direct traceability from the hike to my aching knees... time to take an Advil.

Technorati Tags: 21st Century Process, BPM

Only in the tech world could we be in June passionately arguing about "top down" and "bottom up" and not be in a convertible drving up PCH to Zuma with a cooler full of Pacificas and limes in the trunk. Well, to return to the summers of your youth and live the dream of BPM, now's the time to download this 8-track podcast., set aside Danielle Steele and for the next 22 minutes listen to ebizQ's Gian Tratta interview me about why and how to implement top-down BPM strategy.

"Our view is that business process management is a business function and it is something that should be pervasive to your organization. If you're really going to start viewing your company through the prism of process, this requires top-down commitment."

I know that's pretty steamy but if you can handle it, there's more where that came from. Enjoy...

Technorati Tags: Blueprint, Gian Trotta, ebizQ