Phil Gilbert gave the keynote for Day 2 of the OMG BPM ThinkTank 2008 conference.  Using a combination of facts and humor, Phil made a great case for community governance intellectual property, to be developed in the near future (fall 2008?).  The key benefits were to reduce friction/drag on the overall process of chartering projects and resolving resource conflicts.  For example:  How does the integration team decide whether to allocate someone to the $500k BPM project or the $100M legacy system replacement project?  It is too easy for IT teams to simply freeze up and only tackle these huge projects and not address any of the smaller quick-benefit solutions.  On the budgeting/approval side:  chartering 1 big project has the same overhead as chartering 20 smaller projects.  To reduce the drag, one can allocate an investment to a BPM capable team, with an expected return.  Then that team can, in turn, charter projects in an expedited way.  As Phil points out, the incentives have now been flipped, such that the incentive is to ACT, rather than to veto or stall, because the goal is an outcome, not a budgetary one, but a results-oriented outcome.

This is pretty neat stuff if we can take it from philosophy to actionable framework.  In fact, it occurs to me that a good governance framework can help with several of the “effects” that act as barriers to BPM adoption (the sophomore effect, for example, and potentially the bus brake effect).

Good Q&A session afterward as well, ranging from governance to BPM and SOA playing nice together.  Phil did a great job of tying it back to these governance issues.  Looking forward to seeing the next level of detail on this… I’m not sure if its the yellow brick road but it does seem like it has some promise.  Look to phil’s blog for more details and for upcoming updates.

Round Table sessions at the conference didn’t go as expected due to the turnout.  At our new, combined table, we discarded the prescribed topics and chose our own:  talking about the barriers to successful BPM adoption.  Our table, by chance, was comprised entirely of vendors and consultants (a vendor fest).

In no particular order:

1. The Sophomore Effect. Most companies are successful with their first BPM project.  They tend to focus on something fairly attainable and have good alignment and staffing for the first project.  They get an unmitigated success, but as soon as it goes live, the team that was supposed to get all the learning about BPM and form the core of a Center of Excellence is reassigned to everyday work within the organization.  That might be back to their business units or to other applications or support functions in IT.  As a result, when the second BPM project comes along, the staff has to be re-incarnated.  Often the actors are all new, or mostly new, and you don’t get the benefit of expertise gleaned from the first project.
2. The Bowflex Coat Rack Effect.  BPM is not a pill.  Its exercise.  But companies are always looking for the quick fix.  If you want to be successful with BPM, you have to work at it, you have to have discipline, to really reap the rewards over time.  After all the biggest ROI %’s don’t come from the 1.0 release of each process, but from the point-releases - the 1.1 and 1.2 releases for example, or the 2.0 release.
3. The Used-Car Effect (or, my preference: The Little Red Wagon Effect). Often a company can’t come up with the budget to buy new software (Capex) but they have maintenance dollars that can be appropriated for other purposes.  This can end up being more expensive in the long-run, but in the short term it lets the company get going at a lower price entry point. The used car analogy is that you keep investing in keeping the used car running rather than buying a new one.  The little red wagon analogy is simply the “if it ain’t broke don’t fix it” theory.
4. The Bus Brake Effect. In many companies, the BPM project can be halted by almost anyone that is involved in the project.  We called this the Bus Brake Effect because everyone on a city bus can be stopped by each person pulling the brake cable at each interesection.  Making progress quickly depends on everyone on the bus withholding their right to pull the cable.  In the BPM world, this means convincing all the different parties to participate - the Compliance group, Governance, Security, Integration teams, the Line Manager in the Business, the Champion, and other Business stakeholders.  Its quite a list of people that can raise exceptions to your deployment progress, or essentially veto progress if they don’t agree to staff their responsibilities to your process.
5. The Sharepoint Effect. This is almost the opposite of the Bus Brake Effect.  Where the bus brake effect concerns too many vetos and not enough yes-votes, the Sharepoint Effect represents the unbridled proliferation of ungoverned, adhoc processes using unmanageable technology.  Sharepoint becomes a substitute for process, or a substitute for the Excel-based or Access-based processes of the past.  However, there’s no way to find the appropriate Sharepoint site for the appropriate process or process task.  The general consensus was that Sharepoint does more harm than good.  UPDATE:  Now the real worry in many big IT groups is that BPM will be another Sharepoint - leading to unrestrained anarchy of adoption by business users.  See below for solutions, but I don’t believe this is the danger that IT departments worry it will be, because of the nature of BPM installations and deployments.
6. The AA Effect. Ok this wasn’t part of our Round Table but probably should have been.  For BPM adoption, the first step is to admit you have a process problem (in some circles, we call these “problems” opportunities).  If you can’t do that, then you’re not receptive to really making the changes your business needs.

Ok, so we’ve listed the effects that act as barriers or resistance to BPM adoption.  What can we do about them?

1. The Sophomore Effect and the Bowflex effect really require similar treatment to avoid.  Preventative measures are key.  Education helps managers avoid this, but more importantly, plan for more work than the first roll-out, and staff that additional work with the same team, BEFORE the rollout.  By having the staffing plan extend to work for a 1.1 release, or extend to work on the next process immediately following, the time for people to “return to the day-to-day busines” is reduced.  The temptation is reduced as well.  And the longer these people are focused on process improvement, the less likely they are to be re-allocated. The third tactic pays off in the long run, but is not preventative - and that is to make sure you measure the process, so that you have real measurable results to communicate to the executive team and justify getting your crack team together to deliver additional results.
2. See above.
3. The Used Car Effect - the coping mechanism here is, if you can’t beat them, join them.  Sell software in ways that these corporations are prepared to buy - as a subscription, for example, or SaaS.  It may be more expensive for the customers in the long run to rent rather than buy, but in the short term they have predictable, smaller, expenses, and it becomes an ongoing budget item to plan for.  I think this is a tough one to fight head on with a customer.  If they have a certain way of funding projects, usually the best bet is to play ball with their predilections.
4. The bus brake effect - the best advice we have here is to “paint the matrix green”.  Which is a fancy way of saying, make a matrix of all the people you need to support your project or contribute to your project, and then make sure you get each of them to truly agree to do so.  You have to watch out for those who say yes, but do “no”.  But fundamentally you have to build consensus in your process/project.  Still, this is a tough one to conquer.  Lots of moving parts are required to make BPM projects a success, so I feel it is particularly susceptible to this kind of failure.
5. The Sharepoint Effect requires the company to take control of its own destiny - vendors can’t do this for them.  One of the better ideas was to have governance around creating Sharepoint portals - that you can set one up if you implement and stand up a real process associated with that portal.  But with respect to BPM, IT can manage the assets that run the processes, and the process for putting those assets into production, and still give the business the flexibility and room to breathe to create the right kind of process assets to be promoted…
6. The AA Effect.  Well, since this is just my own personal addition to the list, I’ll just tackle this one with my own opinion.  If you don’t believe you have a process problem, or you don’t believe there is much room for improvement (a gentler way of saying the same thing - because implicitly if you think you don’t have any problems, that you also have no opportunities to improve!), try doing a kaizen event, or a business process discovery session.  Establish measures for your process and see if you still feel that there aren’t opportunities for improvement.  The good news is, figuring out whether or not you have a process opportunity/problem does not require buying a lot of software and making a big infrastructure investment - it just requires bringing in an expert or consultant for a short period of time to do some discovery and size the opportunities for you…

Now, the real story is this.  All of the solutions just require one thing from an organization and its vendors:  Leadership.  I don’t mean, necessarily, upper management or “champion” when I say leadership.  I just mean leadership in its most basic form.  Someone on your team, or someone outside your team, will have to lead, to create consensus, to see these effects before they fully stop your progress and plan the path around them or through them.  Not to mention, you need an aspirational view of what you can achieve in your organization with business process improvement - and that, too, requires leadership.

Lance and I are going to be at OMG ThinkTank in October (October 6-7, 2008), and then again at OMG Think Tank in Europe (November 11-12, 2008).  Lance is hosting a Round Table on Managing Complexity, and I’ll be hosting a Round Table on how process execution is being impacted by ERP/SOA/Web2.0. This year Think Tank is going to have much more of a business focus around BPM, which is welcomed news! Not that the technical side hasn’t been very well represented — and with great content.  Nearly all of the BPM events hosted each year have technology as the center of gravity. Looking forward to seeing how this goes over. The round table sessions are without a doubt the best part of Think Tank. A round table is where you usually have about 6-10 true industry experts and/or very active BPM practioners from mainstream companies sit around a table and provide their experiences based on the topic of the RT.

Last year at the conclusion of the event, everyone agreed Think Tank should expand this vehicle as it was chock full of some great insights and collaboration. Most of the time the topic left the table and was picked up at breaks and after session get-togethers to continue the discussion. The purpose of the leader of the RT is to bring some very good knowledge and experience on the topic, but to primarily facilitate discussion; it is not a platform to monologue the content.

If you have the chance I would highly recommend considering going to Think Tank this year in either Chicago or Amsterdam. You can check out the previous year’s event here.

Last year, OMG made some significant advances in specifications in BPM-related spaces. We now have a BPMN 1.1 spec, a beta of the BPDM (Business Process Definition Metamodel) spec for data representation of BPMN models, and two interesting business-oriented models, the BMM (Business Motivation Model), and the BPMM (Business Process Maturity Model).  We have a mix of both technical and business-oriented specifications for defining business process and improving business process.

OMG is now making public its OMG Expert Certification in BPM program (OCEB), and also published the list of 25 experts who helped put the certification exam together. BP3 Played a role in both the business and the technical aspects of the fundamental exam, and we are now writing questions for the Intermediate exams. This is probably a good time to thank OMG and specifically Jon Siegel for doing such a good job organizing this effort.

BP3 got involved with the OCEB effort (OMG Certified Expert in BPM) first, because BPM is our area of primary interest as professionals. But second, certifications prior to this one tended to be software-vendor-specific, the OCEB offered the opportunity to have a more comprehensive and collaborative examination of what it means to be fundamentally qualified as a BPM professional. We also have an interest in both perspectives of BPM - business and technical - and as a team we bring both types of expertise to the table, which we thought would be a healthy perspective to lend to the working group. In talking with Janelle Hill from Gartner last year she advised that the pool of professionals truly qualified and experienced with BPM is woefully thin, to expect that trend to worsen, and that by 2011 the industry will be in dire straights unless additional professionals come into the fold and earn their stripes. This comment certainly resonated with what we know is the current state of the union. I think OMG is doing a good thing here and I hope we see more practioners enter the fray. It’s good for all of us!