Tom Shepherd writes about the pride of the knowledge worker:

I had this point hammered home almost immediately as I was immersed into product and user research. See, as “automate and improve” types, we are often taught to believe that every worker involved in a business process needs to be told what to do and is limited to doing that work assigned by their manager or team lead. Extrapolating that point, one might assume that measurement of productivity is necessary to enforce good working habits. In some rare cases, this is true, but almost to an individual, what I’ve witnessed are people who are conscientious and truly care about their jobs and their performance. They take pride in their accomplishments, and they are competitive with their colleagues.

I must have missed this “automate and improve” class that teaches you to believe workers have to be micromanaged.  I subscribe to the view that the process should remove the mundane and enable the great.  I’m glad Tom is experiencing this first hand as well.  As a consultant and BPM practitioner, I see this all the time in the field.  People care about their work and they want to do it well.

This philosophy has impacts even on seemingly small elements of business process:  do you assign work based on skill levels and some notion of “fairness”?  Are you overly concerned about cherry picking?  Or do you just let users pull the work down as fast as they can work it and reward the most productive and constructive members of the team?

I try to remind our customers and partners that a BPM solution doesn’t replace good management of people.  You still have to decide who to keep and who to let go – who to coach and who to reward.  And software does not excuse you from these responsibilities. Look – people matter.  You have to nurture your human resources or you pay the price in the long run.

I recently met with a customer who achieved a 300% increase in productivity with the solution we helped them build.  To give credit where it is due – they designed the process. The process improvement team had the insight (without our help) that more of the work being performed was fungible than others in the business believed.  They needed BPM software and some experts like our own at BP3 to  show HOW to implement the process to realize their vision – but it was their own key insights that led to the project we helped them with.  Now that they’ve implemented the process, they’re in the position of letting their best team members handle the work.

It would be tempting to think that we automated most of the work.  But actually, we automated the mundane-  notifying the experts when something went wrong with their book of business, rather than making them responsible for constantly monitor for completeness.  It wasn’t so much that we automated more – it is that we automated the right parts, and transformed something transactional and case-management-oriented into something process-driven (They previously had what could best be described as case management work – with a set of cases assigned to each person. ).

Of course, before we all embarked on the process, we were told this couldn’t be done – that the work wasn’t fungible.  And ACM proponents would have told us this knowledge work isn’t suitable to BPM.  But it was clear to us that it makes more sense to have software do the parts that are the same every time.  What’s LEFT after we boiled down the process, is the case management activity real people need to perform. But what they were doing before was case management and process management… manually.  And the users weren’t clear which was which.

Ironically, there was more assembly-line thinking in the old approach than the new approach.

This article from Todd Barr, of Alfresco, made me think again about how open-source software might impact BPM. The point of the article is that VMWare is rumored to be acquiring SUSE Linux from Novell – and that this is evidence of the march of open source into commercial software companies.

I agree.

I think the key issue is one of complements and substitutes.  If you are selling software, you want the complements to your product(s) to be cheaper or free, because those complements *increase* the value of your product.  If you’re selling peanut-butter, you sure would like the price of bread to go down… even to zero.  A better treatment of this subject than Chris Dixon’s blog post about Twitter and Twitter Apps cannot be found.

The only question in BPM is… what are the substitutes… and what are the complements? It depends entirely upon what your primary business is built around.  If you’ve built your business around selling BPM software, then the complements are templates, databases, application servers, development tools, web services… all the other enterprise applications on the market.

If you’re selling one of those other applications or stack elements – then you want BPM to be cheap or free (a complement), because it enhances the value of your offering.

The next few years in BPM are going to be interesting.

Jacob Ukelson posed this question the other day:

So where does all this leave us? I think that in 2011 we’ll start seeing business user backlash to BPMS – they will want more participant control over process, faster start up time, better end-user usability.  That will lead them to ACM (or to continue using email+excel).  It also probably means that the BPMS growth rate will slow.

Having been in BPM, and remembering how many times a break-out year was predicted… I prefer not to make these kinds of predictions.  BPM has been a steady grower, however, which may actually be more appropriate for enterprise technology- giving technology time to catch up to some of the hype (although, admittedly, the hype always seems to lead!).

Regarding BPMS growth rate slowing – I don’t think any slowing of growth rate will be caused by ACM, nor by a “backlash” as Jacob calls it.

I see the trends Jacob is pointing too, but these are trends that play out over many years or even decades, not 12-18 months.  I often agree with Jacob – and 2011 may well be a “break-out” year for ACM – but I disagree with some of the arguments he proposes to make his case:

“1. BPMN is becoming more complex because it is primarily a tool for IT professionals.”

BPMN is not becoming more complex.  The standard (BPMN2.0) is out. BPMN is unlikely to now change for some time.  Whether BPMN is primarily a tool for IT professionals or not, this hasn’t suddenly changed.  If ACM is successful, it will not be because of BPMN.  It will be because of ACM’s unique, value adding, capabilities.  If those capabilities are subsumed by existing software packages that have market presence, then it will be difficult to determine what is ACM separate from what is BPM.

“2. IT departments like the centralized control most BPMS give them.”  Actually, many IT departments push back against BPM, and against the methods that make BPM most likely to succeed.  In many cases it requires cultural change in IT departments to be successful.  This accounts for some of the slow-and-steady growth I referred to (not that 20% CAGR is bad).  On the other hand, in many cases the business is championing BPM – somehow I can’t accept that this is a bad thing.  Naturally IT can feel threatened in some cases when business takes the lead with respect to software, but it isn’t always that way.

“Paraphrasing Phil Gilbert – it enables 1 Java programmer to control the productivity of 250 business users, and makes those business users completely dependent on IT.”  I don’t agree with this paraphrasing.  Phil Gilbert was, if I read correctly, arguing that Java programmers are highly leveraged, not highly controlling.  The implication of intent to control isn’t really accurate or appropriate.  It is simply an implication, on Phil’s part, of a limitation to agility because this 1 Java programmer is overloaded.

“This is reminiscent of the mainframe era in the 60, 70, and 80’s – which generated the client-server backlash of the 80’s, 90’s, and 00s.”  I normally think of backlashes as things that happen faster than over 3 decades.  Also, I recall IT departments being pretty high on client-server and MS Office roll-outs… and *not* fighting them.

“4. IT, the CIO and most vendors hated that trend and tried to fight it. The more they fought it, the more people found ways to get around IT and use the systems that gave them back control.”   I don’t remember this at all.  We had different experiences with this (and, admittedly, both experiences probably happened, depending on which companies you were working with at the time).

Having said that, I think that products that address the “other 75%” of process work will find an audience.  I just don’t think that they’re competitive with BPM products – in fact, they’re highly complementary.  Just as email and Excel spreadsheets aren’t competitive with BPM…

Topics at bpmCamp are taking shape based on feedback from attendees and prospective attendees.

A few highlights:

• A look inside the black box that is Websphere Lombardi Edition (v7) and Teamworks v6.
• Fronting Teamworks with FLEX – who says good process can’t be pretty?  Greg Harley, a BP3 and Lombardi Alumn, and currently product architect at IBM, shows off some techniques for getting the most out of your BPM platform.
• Using Ajax to spruce up more common Coach interfaces in Lombardi BPM.
• Agile Development with BPM: Revisiting Value-based delivery
• How to dig your way out of process debt.  Revisiting the process debt topic, how do we address debt and pay it down?

bpmCamp is only 3 weeks away – time is short (register here!) – and we still have room for registrants.  If you can’t make it, make sure someone on your team *does* make it to bpmCamp.  I can guarantee that they’ll take home some really interesting learning and experience.

IBM Lombardi folks – you’re invited.  Come on down.

“Successful Failure” has been used to coin the events which unfolded for the Apollo 13 mission. The failure was that the mission did not meet its original objective to land on the moon and return but rather met a more urgent objective which was to successfully deliver home the astronauts who were caught up in a series of unexpected and violently changing situations.

During the course of BPM delivery, and if a company is open-minded enough they can actually benefit from a failure. Now to be clear, I am not suggesting that every endeavor should automatically be assumed to fail or for that matter even the planning for failure is not something anyone would really want to do. Risk mitigation, yes of course but what I am referring too is a willingness to change a plan if the business value interests aren’t completely aligned with that initial plan. Things happen on a project and sometimes even a perceived negative situation can be capitalized on and may actually yield a better overall outcome than that original improvement roadmap. For example, when you are finding yourself looking at a process and subsequent solution requirements and they have stagnated. Stagnation of solution requirements is extremely common. Perhaps those requirements were developed months and months ago (or even longer), or similarly developed in isolation of the true voice of customer/voice of business. If you approach this purely from a plan-driven approach your failure scenario is high pure and simple. And achieving that failure may be the best thing to happen on that project because it opens the door to re-adjust and go after the more immediate business-value aspects of the solution; the here and now, not the how it was. As a result, you likely just saved a ton of capital by avoiding the ongoing support for a solution that was at best dead on arrival, and at worst just added to the overall process problems.

In a Lean-Agile delivery approach the notion of “failing fast” and being business-value driven over plan-driven are extremely important in these scenarios. Business-value driven simply means that during delivery you are willing to put the true needs of the business first, those solution requirements that will actually move the performance needle and not generating assets just because they may have been written down in a plan once upon a time. In essence, separating the wheat from the chaff.

For Apollo 13, as much as solutions were needed to the various problems, solutions had to be identified quickly in the face of the many unknowns that the mission was faced with. To do so the team needed to “fail-fast”, meaning that the capability to perform quick failure assessments and prevent re-occurrence is equal to the value of identifying a solution. Simply stated, do everything you can to get the real problems you are going to face identified up front. For companies new to BPM and its Agile software delivery tenets no matter how rock solid you believe your plan to be the teams will be undoubtedly faced with unexpected challenges. Getting too far ahead of the risk aversion curve by trying to engineer for every possible corner case everyday is fruitless, expensive, and ultimately useless. Reason being is that in doing so you will create more mass in the project than what can literally be propelled off the ground; more mass requires more energy and will ultimately result in inertia. The last thing anyone would want to have on their delivery project is a vast, never ending source of mitigations and controls based on theory or even meta-theory. An organization needs to have courage to move into and stay in a delivery mode versus discussing what delivery may or may not mean for a project academically.

What is required in delivery is proportionality and pragmatism in order to achieve the mission objective. In Lean-Agile, which happens to be the method of choice for us at BP3 in delivering BPM solutions, there are just a few simple staple items all of which are based on delivering business value as soon as possible. When we talk about what is value we talk in terms of a working solution over the documentation of a solution, collaboration over negotiation, flexibility being valued over rigidity as examples. The reason we value this is because it brings everyone closer to seeing a successful outcome by bringing risk and unknowns forward to deal with immediately.

In Lean, something which is considered Value-Added must pass three discrete tests:

1. The customer would be willing to pay for it
2. Done right the first time
3. Physically transforms the output; increasing its value

If you took the same philosophy to dealing with failures which occur on projects today then its pretty evident that there is a tremendous value in being able to identify and resolve issues quickly.

Value-Added Failure

1. The mission/project/program would be willing to pay to prevent or remediate issue
2. Identified and resolved early
3. The outcome increases efficiency, effectiveness, and business value of the ultimate solution

Again, in order to truly realize the value of putting your undiscovered troubles behind you quickly you have to begin by acting, doing something that provides the opportunity of discovery versus avoiding the journey all together. So if your going to have a failure, set yourselves up to do it quick and unequivocally.

Adam Deane’s recent post about Keith Swenson’s blog was quite interesting to me.

Keith has been blogging on BPM for the last 4 years.
The first couple of years were mainly around notations, standards and development.
The next year had an emphasis on BPM best practices.
His last year of blogging concentrates on ACM – Adaptive Content Management.

Personally, I found the articles on BPM best practices – the most interesting to read.
Clever observations and recommendations. They were also articulated very nicely.

I’m not a notation kind of guy, so the debate around standards and acronyms wasn’t exactly my cup of tea (XPDL,BPAF, BPDM, Wf-XML, BPMNEL, WYDIWYE and … IJKLMN)

I’m not a notation guy either… but I found myself sucked into some of these debates anyway! Sometimes you just can’t help it.  People often criticize the notation, when the real problem is the specific implementation of the notation that they’re working with. (This same thing applies to people criticizing a space, like BPM, when the real complaint is with specific tools).

Of course, the part that really jumped out at me was almost buried at the bottom:

And I must admit that his latest obsession with ACM has got me a bit baffled.
I haven’t a problem with the ACM concept, but I do have a worry about the approach.

I agree with Adam that Keith’s most interesting work (to me) was regarding BPM best practices.  I find the discussions on ACM too theoretical – with nothing practical to separate ACM from BPM in a meaningful sense (only in a theoretical and etymological approach).

I’m reminded of The Graduate:

I want to say one word to you. Just one word… Plastics.

BPM is apparently going mainstream.  And now we’re seeing analysts (Connie Moore) and the industry note that there’s a career in BPM:

All of this background points out one major trend: A new career field is emerging for business process professionals, fueled by the growth of business transformation, business improvement, and business optimization projects.

What do the individuals in this new field need most? Process architecture skills, process analysis skills, process modeling skills, change management skills, Lean and Six Sigma skills — the list goes on. More than anything, the skills gap or skills shortage keeps BPM projects from scaling throughout the organization.

This comes as no surprise to me – as it seems, looking back, that most of my career has been focused on process technology of one sort or another (initially, supporting sales processes for complex products, and later, actually working for a BPM vendor… and now, working with our own practice realizing business processes in production software).

Those of us at BP3 have already made a career out of BPM as business process professionals.  It looks as though most of us on our team fit most closely to the “Prodigy” cohort, as defined by Connie.  An appropriate place to start for a boutique consulting firm – though we have our Gurus and Change Agents.

Connie Moore has specific advice for picking up the necessary skills.  She advocates “two in a box” for training new process professionals.  This is something I’ve advocated for a long time.  BPM is more craft than anything else – you learn from others, and give it your own spin based on what you bring to the table.

Connie also advocates employees attending training, and leveraging external resources.  Couldn’t agree more (hello, bpmCamp!)

Jacob Ukelson has run a blog post espousing BPM for “business process management” and ACM for “best practice management” (reporting from the BPM2010 conference):

One participant (I didn’t get his name) summarized the conversation by the intriguing statement”So BPM is for processes, ACM is for best practices” – from earlier comments he made it was clear he was a management consultant.

I think his statement is a good way of looking at ACM – especially if you come from a management consulting background. According to wikipedia “A best practice is a technique, method, process, activity, incentive, or reward which conventional wisdom regards as more effective at delivering a particular outcome than any other technique, method, process, etc. when applied to a particular condition or circumstance.” also “A given best practice is only applicable to particular condition or circumstance and may have to be modified or adapted for similar circumstances. In addition, a “best” practice can evolve to become better as improvements are discovered”.

Now, referring back to a previous post on this blog, it is no wonder that Jacob and I agree so often:

… If BPM is focused on optimizing the aggregate of many process instances, Case Management is focused on optimizing the outcome of an individual run of a process by providing better information and tools to the case worker.  To take the medical example – case management would philosophically try to help improve the outcome for a single patient.  BPM would philosophically try to improve the overall outcome of health care provided by the facility across all patients.

(Note, I used the word process but could have just as easily substituted the word “case” or “issue” or “patient”).

So, I once again find myself in violent agreement with Mr. Ukelson.

We’d like to extend our thanks to our colleagues at IBM and specifically the folks in the BPM group, who have agreed to sponsor bpmCamp 2010 @ Austin.  Running a small, break-even event like bpmCamp requires everyone to contribute a little bit, and we really appreciate IBM’s willingness to contribute by sponsoring Thursday night’s dinner, which has been a great time for networking, following up on the day’s topics, and arguing about the next day’s agenda.

Dinner also happens to be at the Austin landmark restaurant, Lambert’s Downtown Barbecue.  Those from Austin will be familiar with it, and those visiting will have a chance to try some Austin-style BBQ (and other dining selections of course).

Sandy has great coverage (as usual) of the BPM2010 conference:

• Research on Business Process Design – several presentations on informal process design and machine-assisted process design.
• Research on People and Processes
• BPM and Social Software Workshop
• Research on BPM in Practice – how novices model, and IT requirements of BPM in practice (room for improvement apparently ; )
• Research on BPM in Education – professionalizing BPM with a BoK for BPM. Sandy includes a call to action for building this process BoK.  And another session on building a BPM and SOA education community.
• A real call to action on process knowledge.  Very interesting effort Sandy and others are undertaking.  We at bp3 will have to take a closer look as well.
• And of course, the wrap-up notes.

Thanks again for tracking this conference for those of us who couldn’t be there, Sandy!

Keith Swenson says BPM makes the workplace more stressful:

It is really quite simple: in the workplace there is a mix of routine work and knowledge work.  Routine work is repeatable and predictable in pattern.  Knowledge work, however, is different every time and makes us think hard about what to do for this particular situation.  Routine work can more easily be automated with a BPMS.  Therefor, the mixture of work is shifting toward having less routine work, and more knowledge work.  Automate work never results people becoming idle.  Business being always competitive, people are expected to keep busy with whatever most needs to be done, and that is increasingly knowledge work.

I like the straw man Keith presents (you should read it all).  But it isn’t BPM making work more stressful – it is competition that does that.  Capitalism and competition.  BPM is just one of the tools we use to address that competition.  We don’t blame the nail gun for making construction more stressful – we blame the competitive pressures that cause the need for speed to be so great.

I really like Phil’s talks on “the big picture”.  Of course, given his investment in process, his talks on BPM are particularly compelling stuff (even if you disagree with him).

In his latest blog post, which is, essentially, an excerpt from his presentation at the BPM2010 Conference, Phil really drives home the point about how leveraged the IT resources at our major corporations are.  That for every true software developer, there are 5 people supporting their work (maintenance, deployment, requirements, management).  For those six people, 240 people are in “the business”.

He could have added an additional dimension: outsourcing.  By outsourcing, the # of IT employees relative to business employees has been reduced even further. 

And both of these trends have a cost:  reduced agility.

One answer would be to have more software developers – therefore increasing the throughput of the current 6:240 ratio.  Another answer is to provide better software to the 6 IT folks.  Phil argues that BPM is, essentially, just better tooling for these same 6 people.  An argument could be made that BPM extends its reach a bit further, allowing 7, 8, 9, or 10 people to get more directly engaged.  But the point remains – a shockingly small number of people are the bottleneck to business agility.

So the other answer is to address this larger community of “the business”.  Addressing the 240.  Increasing the scale from 240 to 480.  This is the challenge that Phil is calling on BPM to address:

So the next great challenge is before us: how do we turn the notion of scale on its ear? How do we gain the involvement of the 240 real business people so that without training they can contribute their knowledge of how things work, their requests for how things should work into the explicit, unambiguous conversations required for automation? And, by doing so, how can we increase the velocity of communication for everyone, so that requirements can be more exact, more quickly and communicated more effectively, so that the scale of software can be enhanced even further.

Good stuff.  Nick Malik elaborates from his perspective in a followup post.  But rather than dig into that, we can jump straight to Phil’s response to Nick:

And then once you are on the cloud, the technologies of Social are, in essence, free. I think if Social is your value prop you will lose inside the enterprise. People have no time for abstract notions of “community” at work, any more than they have time for abstract notions of “process.” But if the value prop is unleashed via the cloud, then Social becomes possible. And Social then can become, in essence, your Center of Excellence. This is the ultimate democratization: a Social network that enables the communication that is your Center of Excellence.

This will never happen with someone buying a “Center of Excellence in the Cloud” package. It will happen because they use a set of tooling that solves personal or small group problems… and that technology has as a secondary value prop the ability to communicate via the new Social.

Which then, finally, leads to this: my Center of Excellence isn’t defined by expertise but, rather, by the velocity of communication that speeds through it. Expertise is so highly distributed and, for most interesting breakthroughs, so specialized, that the main hurdle to breakthrough isn’t knowing everything, but rather, knowing where the pointer to any one thing is. A Center of Excellence should not contain experts with answers but, rather, should be a vehicle through which I can pretty easily get to any answer. It is about communication. And the faster and more robust that communication can be, the quicker the person or artifact with the answer can be identified and reached, then the better the CoE is.

I would argue, it isn’t knowing everything- it is knowing how to get to the answer.  This concept is familiar to me, as the son of a librarian, who could seemingly find any bit of information or research paper the son desired to find.  As computing resources evolved, the key improvement in “finding the answer” was search.  The difference with “the new Social” as Phil calls it is, not only can I use search to find answers, I can use my network of experts to find answers.  Phil calls this dis-intermediating the experts, but I would instead say that it is removing the official distinction between experts and non-experts.  Whoever has the answer can be the expert.  True experts will still be immensely valuable in “the new social” as they’ll be even more leveraged than they ever were in the old systems, and access to these experts are not likely to be as limited by governance and chains of command and project charters.

That’s probably a good thing.

Phil leaves us with one last thought:

By the way… we may be closer than you think on some of this stuff :-)

I think I mentioned before that I suspected Phil might be priming the pump with his talk at BPM2010, while working on the answers back at the lab :)

We’re looking forward to seeing the outcome.

Answer:  They don’t.

But this question was recently posed on ebizQ.  I frequently respond to ebizQ questions regarding BPM, but when I read this one, I read the first couple of responses and decided not to comment.  BPM “projects” that employ BPM software fail for the same reasons all IT projects can fail, nothing unique to talk about.  But my real issue was the phrasing of the question: “why do so many BPM projects fail?”.  Ask the same question but without the prejudgment:

“Why do BPM projects fail?”

And then the discussion is a bit more interesting. But saying “so many” we have to ask “as compared to what?”

Connie Moore wrote a long response that reflects my point of view on this subject (an excerpt):

Before delving into why BPM projects fail, we should first ask “who says they fail?” I think the “failed BPM project” canard is an artifact of the old business process reengineering (BPR) days when big bang reengineering projects really did fail by collapsing under their own weight. But I’ve worked in BPM–and workflow before that–for many years now, and to be honest, I haven’t seen that many BPM projects utterly fail. In fact, I can probably count the failures on one hand. Instead, BPM clearly involves a journey, and sometimes BPM projects and even BPM programs stall out because the organization hasn’t matured its understanding of BPM and/or in its in-house capabilities to deliver business process change across the organization. Companies sometimes take a long time—too long—to move through the maturity phases so they get from implementing individual projects that provide good but limited productivity/efficiency gains to instead tackling true transformational initiatives that go to the heart of business performance.

This mirrors my experience.  The only BPM projects that I’ve seen fail failed in exactly the way Connie refers to – collapsing under their own weight because they were run as classing BPR projects.

Some of the comments seem to be caught up in whether “BPM” has succeeded or failed, not whether a “project” (the subject of the original question) succeeded or failed, as does this comment from Thomas Olbrich:

First off, I think that BPM has not delivered. This automatically begs the question of ‘delivered what?’. Well, what are we talking about here? It’s BPM, Business Process Management, the management of business processes.

Fair point that many people have or had bigger aspirations for BPM than what it has, to this point, delivered.  But that kind of judgment of failure is very much in the eyes of the beholder.  If we judge by other yardsticks, BPM could be judged a success. But let me just say, that success is no excuse for getting complacent. We should be striving for more with BPM – not less.

Thomas goes further:

So, after this rant-de-force, who is prepared to tell me that
• Our processes are managed better today with the availability of BPM?
• Our enterprises have really become more agile, more flexible?
• Our processes have become more application independent and quicker and easier to adopt to customer requirements?
• Standards like BPEL and BPMN have facilitated the transfer of business requirements into IT?
• That the quality of processes and process management has improved?

Yes, there are ways to adress these issues and to achieve these goal, but as long as we insist on this make-believe approach of ‘easy BPM at the push of a button and the purchase of a BPM system’, I fear we’ll never get there. Managing processes is a complex business and anyone reducing it to projects needs to be very lucky indeed. BPM is an intellectual challenge and not a technical one. Have we got the right people with the right attitude to make it work?

If anybody can convince me that things are indeed better than they seem to me, I’ll bow my head in shame and apologize (from a safe distance).

Well, I don’t anticipate that I would convince Thomas, but I do believe that processes managed by BPM are, by and large, managed better than they were before.  That enterprises who embrace BPM are more agile and flexible than those that do not.  That BPM-implemented processes are indeed more application independent and quicker and easier to adapt/adopt customer requirements.

However, I agree with Thomas that we have got to drop the idea of push-button BPM – or that managing processes is easy if only we have the right silver bullet.  It isn’t easy.

Connie’s last thought sums it up quite well:

But let’s say that an organization’s BPM initiative suffers from certain problems, such as not delivering as much business value as expected, or taking too long to complete a project, or providing limited value because it was just an isolated pocket of the organization. These are some of the common problems I’ve heard, but I believe it’s not so much failure as it is getting stuck in the business process improvement/transformation maturity life-cycle and needing a kick start to get going again. Also, failure is in the eyes of the beholder so one project team’s success may look like failure to a very senior exec who had much greater expectations than were delivered.

Very very true.  If BPM is a journey, failure is giving up and going back home.

On this blog, we typically discuss leadership in the context of BPM projects, initiatives, and programs.  Because BPM efforts typically cut across departmental and organizational boundaries, they also typically require an extra measure of leadership to convince people to something when they don’t report in through the chain of command.

A recent article on TechCrunch by Vivek Wadhwa points out that leadership is often lacking in Silicon Valley firms as well.  This isn’t the popular refrain about startups (outside of the startup community itself) – mostly the popular coverage of startups is about swashbuckling risk-takers who conquer new ideas and disrupt industries. And then there are the stories about the unique management approaches of startups (queue the last 8 years of articles about Google).

But the picture Vivek paints is one of managers who aren’t prepared for the responsibility they have on multiple fronts.  This is essentially an argument about the Peter Principle writ large: because most managers in Silicon Valley startups don’t receive any management training, they’re unlikely to be good managers.  Worse, they’re unlikely to be good leaders.  They’re getting promoted into these positions because there isn’t anyone else to do it.

Vivek advocates for explicit management training.  But it is easy to get caught up in the idea that you have to get a Masters degree to learn something new.  I think the real point of management or leadership training is to get potential leaders OUT of the day-to-day grind, and IN to a setting that facilitates free thought.  When listening to leadership and management training material that has real context for a leader’s current management situation, the recipients are more likely to assimilate that knowledge into the way they think and operate. Vivek reports on research at Duke University:

The conclusion of the researchers wasn’t surprising: many high-tech companies are young, so their systems and procedures for grooming leaders aren’t well developed or firmly established.

Maybe this is why so many tech companies suffer from morale problems, missed deadlines, customer-support disasters, and high turnover. And this may be one of the reasons why so many tech startups who succeed in selling their vision and raising millions in financing are just a flash in the pan.

But lest readers in bigger firms take comfort in this, there is a lesson to learn here about how we approach developing leaders within larger organizations as well.  The first thing I’d say, for BPM leads, is read this previous post on our blog.  Secondly, realize that you can foster leadership development on your team without a formal, executive-sponsored, program. It isn’t as easy, of course, because you have to take responsibility for it at a more local, personal level.  But on the other hand, your star pupil can’t be rejected from your own leadership program, but might not be included in the corporate program.

Vivek appears to recommend several kinds of educational opportunities (MBAs, Executive MBA’s, and more creative programs).  We recommend something a bit simpler for many of our BPM colleagues – attend a small conference (like bpmCamp), and take time to invest in sharpening the saw.

Interesting to see Xerox getting coverage for moving into BPM/O and initiating an advertising campaign around it:

Xerox has decided to rebrand itself through a major ad campaign that will roll-out next week and carry over through 2011 as a business process management and document management company rather than one that just provides copiers.

Apparently as a result of the ACS acquisition, Xerox now earns half its revenue from business services management.  This all sounds more like BPO than BPM to me, though they are related.  It is interesting that the notion of BPM is starting to get coverage in places I didn’t expect to see it.  I just saw the first of these ads yesterday, with Marriott.

Quick updates on bpmCamp 2010 @ Austin:

1. Early bird registration ends Friday at midnight – $150 early bird, $200 regular registration price.

2. I’ve updated the home page of the bpmCamp wiki to show what some of the topics and descriptions were at our last bpmCamp @ Stanford.  This should give you a good idea of the kinds of quality topics we can discuss at bpmCamp.

3.  We’re in final strokes to line up a sponsor for Thursday night’s dinner at Lamberts, an excellent Austin eatery.

Phil gave the keynote at BPM 2010 yesterday, and Keith Swenson had the early coverage ready before EOD yesterday.  In this talk, it sounds like Phil has continued his main themes (since I can remember) of making BPM more and more accessible to the business.  As he often put it in the past, the IT folks are a small minority of the total population in a business (2%?), and “we want to focus on the other 98% of the people in the business”.

Every year this theme gets some tuning, based on technology and cultural developments.  This year the stats were updated a bit:

For every one 1 java programmer developing applications, there are 5 IT people supporting the technology infrastructure, to support the work of 240 business people.  Tools to date have all focused on the 6 people.

And the suggested general direction is evolving to include the idea of “following” elements of the business.  I’ve used the follow feature in Blueprint, and love it – sometimes simple features are compelling.  But I’d like to see “follow” functionality throughout the IBM Lombardi BPM solution – within the Lombardi Edition authoring environment, as well as in the run-time environment.

It sounds like Phil also took some shots at the standards effort behind BPMN.  This isn’t new – Phil has long been a proponent of having a standard, and having a standard storage for the notation.  But he’s also expressed his frustration in the past that the folks working on the standard were getting bogged down, taking too long, and getting too far into the weeds.  Fair criticisms that I think Keith and Bruce Silver and others would echo (including myself).  I’m glad to have BPMN, but I hope the standards folks take some time off and let it bake.

The central argument (quoting directly from Keith’s blog):

Citing an IBM study of customers, 2.5% of the processes are complex,  22.5% are somewhat complex (less than 200 steps),  75% are not complex at all.  This last category is done today by excel over email..  At Banco Espirito Santo the complex processes impact zero people,  moderately complex effects 2000 people, and the non complex effect 8000 people.  This organization has moved forward to allow business users to be “100% empowered to automate the non-complex processes”.  If your business is based on people (and there are very few companies today that are not) where is the value being delivered by your BPM?   Everyone is way too focused on the really complex processes.  IT was clear he felt that is what lead BPMN standards astray, and this research crowd should be mindful not to fall in the same trap.

BPM is a cultural issue, not a technical one.

(Neil Ward-Dutton focuses on the same part of Keith’s summary, with an emphasis on the cultural).

Keith comments that Phil stopped short of prescribing a solution to empowering business users to increase the support for business work… but I think he’s priming the pump.  He’s giving us a sense of what we’re missing today.  But if I know Phil, he has people working on it right now.

The future is focusing on the “B” in BPM – not the “N” in BPMN – and the vendors that can offer the most compelling solutions are going to reap substantial rewards.

TechCrunch and Vivek Wadhwa have a controversial article up about Age-ism in high-tech in the US.  TechCrunch is no stranger to controversy, having also just caused a bit of a stir around systemic gender bias in the venture-funded tech startup business.

Vivek makes a few key points. Paraphrasing, High Tech companies prefer younger workers because:

1. They are cheaper (salary, benefits, insurance, etc).
2. They have fewer competing interests (lower percentage are married with kids)
3. They are perceived to be easier to mold (into culture fit)
4. They are perceived to be “more current” on whatever the latest technologies are
5. They can be trained up on new tech more cost-effectively than older workers

I’ve certainly seen this logic play out, but more in the 90′s than today.  I see a lot of pressure from small companies to hire someone who already knows the technology in question, not someone who still has a lot to learn.  I see a lot of companies hiring someone with an existing track record.  Hiring a college recruit is a multi-year, long-term investment – which a lot of startups aren’t ready to make.  But perhaps things are a bit different in the Valley than in Austin.  Perhaps there, the pressures are more like the pressure to offshore: get the cheapest labor inputs you can get.  Certainly, one way to do that without the pain of offshoring, is to hire less experienced (or less costly) talent. In fact, in another article, it was predicted that labor (or jobs) will migrate to less expensive parts of the US (this seems logical, over time, if other parts of the country prepare people with the right skills).

My observations about experienced hires (I won’t say older) in the same order as above:

1. Usually (but not always) much shorter ramp-up time from day 0 to first fully independently productive day.
2. The competing interests are also balancing interests – keeping more experienced team members balanced emotionally, more so than some less experienced hires.  They have other positive things going on in their lives which allow them to pursue work with confidence, rather than fear of failure.
3. Whether easier to mold or not, it is easier to judge what an experienced hire’s real work values are – and to find people who already align with your values, rather than trying to mold (some might say brainwash) less experienced hires.
4. Often more experienced hires are actually more current on the new tech than students, because it takes quite some time for educational institutions to switch gears.  I remember distinctly Stanford University rolling out its C++ computer science classes (intro classes), just as Java was about to hit the scene.  It was several years before Stanford switched the curriculum to start with Java, though they did start offering a class in Java right away.  It was many years before we could hire people with Java skills learned in college that were more than trivial.
5. This last point is true, if you assume ramp-up time is equal, and that the less experienced worker is cheaper than the more experienced hire. However, as I pointed out in my comment on TechCrunch, I have come to believe that learning itself is a skill, which can be practiced and improved over time.

We run a services business at BP3, so it isn’t apples to apples comparison with the TechCrunch article, but there are a few more things that we note about our firm when we talk to candidates.  First, our business requires a lot of travel for nearly everyone on our team.  That is easier to accommodate when you’re single (it may even be a benefit) than when you have a family.  And while it may be true that younger or less-experienced people are more likely to be single, it really has to do with family vs. no family.  Because our firm is run by people with families, we take our commitment to make our job sustainable for our families *very* seriously.  Second, if we’re going to pay for experience, we want that experience to be relevant to our specific business – that of BPM.  I’ve had conversations with people who have previously made considerable salaries, and are interested in switching to focus on BPM – but they don’t know the BPM space yet, or the specific technologies we use to support BPM.  I tell those folks that they can’t expect to switch into BPM and not have a hit to salary in the short-term.  But I believe that is true for any career change -when you switch specialties, your compensation takes a (hopefully short term) hit.  If it is a good long-term change,  compensation will catch up to and surpass the old compensation at some point, but more importantly, the career change will breathe new life into working.

I couldn’t make it to BPM 2010 this year, but luckily for us, Sandy Kemsley did.  I expect her blog to once again be the definitive place to go to for interesting news from the conference.  If you want to get all her BPM2010 updates, just link to the bpm2010 category here.

I think Paul Vincent’s blog on CEP is where it’s at – my favorite place to keep tabs on this interesting space.  It isn’t BPM, but it is related to BPM, and vice versa.  Not only are the markets complementary, sometimes the concepts in one space directly make sense in the other.  A side note: often when having trouble designing a process, I think about the important business (or even system) events that might occur – I may not know the actions that happen inbetween, but the events become useful markers around which to design a process.

A recent post from Paul caught my attention: “Do Events Have Duration“.

This might seem an odd question, but there are 2 schools of thought here:

• An event is a point in time.
• An event is an activity that can take a period of time.

Taking the latter view, we can say things like:

Earthquake MMM took place from date-time D1 to date-time D2
Fraudulant act on account NNN took place from date-time D3 to date-time D4
Flight QQ123 was delayed in the period date-time D3 to date-time D4, when it completed disembarkation time T1 late
World War 2, an historical event, took place from 1 September 1939 to 2 September 1945.

Lest this make your head hurt, Paul makes a compelling argument that events should be considered moments in time, and an “event” like World War II is really more of a “state” of being in World War II with a start and an end and many other events in between.

I think the principle of Occam’s razor applies here: the simplest explanation is usually best.

Another side note: my favorite comment on his blog post is one that almost sounds like a snippet from a Star Trek script: “…’temporal semantics of event processing’. In short — events always have durations, but in many cases, the time granularity that we are interested in a certain application is large enough so that we can approximate the duration to a time point (note that a ‘second’ is also an interval and not a point, since time is not discrete).”  I was waiting for something about reconfiguring the deflector shield…