Anyone in a service business should have a notion of what a customer is worth to you.  The concept of a lifetime value of the customer has been around a long time and Wikipedia is a good reference: Customer Lifetime Value.  But the basics are pretty simple:  take your typical contract value, your typical retention rate, and then run the math to figure out how many times the average customer renews…

I think the main thing that becomes clear, is that customers have a lot more value than the value of the initial contract would suggest.  If you’re retention (renewal) rate is 90%, the value is close to 9x the inital contract.  Of course, for longer term relationships, you also have to factor in some discounted value of future dollars to present value.  Good article here by Tom Karlo that breaks this down (with an actual formula) using a website customer example, but it is important to keep these ideas in mind for any business, because repeat customers are the lifeblood of successful businesses.

Eric Ries’ presentation on “The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products” has three processes depicted for “product” development.  I put product in quotes because I think you can accurately substitute “service” or “process” and the presentation still applies very well to the situation if you assume that some technology or other development activity is required to support your service or process.

Here’s the presentation, but allow me to call your attention in particular to slides 20, 21, and 22.  In slide 20, you see the traditional waterfall strategy, which Eric explains is appropriate when you know the problem well, and the solution is also well known and understood.

In slide 21, we see an Agile approach, where the problem is known, but the solution is not well-known and understood.  In fact, a decent number of agile projects get into trouble because the problem is not well-understood and they get caught in what feels like “churn”.

In slide 22, we see the introduction of the Customer Development Process to the mix, and the situation is one where the problem is not known, and the solution is also unknown.  So part of the journey is to discover the right problem to solve, as well as the solution that solves it.

I think a lot of BPM projects would do well to adopt this third method (or an adaptation of it) as well.  At a high level we may know that there is a problem (opportunity), but we may not understand what that problem is at a detailed level that would allow us to design a good solution.  So we have to do some level of customer development (in our case these may be users) to understand the problem adequately, and then use an iterative approach to get the proposed solutions improved and adapted as quickly as possible.  At the very least, when taking on a BPM project, one has to keep an open-mind to improvements that haven’t been thought of, and to new problem-identification that may happen over the course of the project.

A blurb about the slideshow is available on O’Reilly here.

Also, a more in-depth presentation was done previously on the Customer Development Methodology:

This version goes into a lot more detail on how to build the startup around this methodology, and makes a stronger case for why you need to iterate between business plan and hypotheses before funding, rather than proposing a business plan, getting funding, and *then* testing the market… its a good read!

All too often I see conclusions based on observable data, where the conclusion does not necessarily follow the data presented.  This doesn’t mean that the conclusion is wrong on the face of it, but that it can’t be made based on the facts presented thus far.  Sometimes the conclusion is presented as causal when it is only correlated, sometimes it is extrapolating from a really small sample to describe the whole population (over generalizing).

I recently read Theo Priestley’s post on why Six Sigma doesn’t work in the real world.  In it, he relates a LinkedIn posting from someone attempting to do six sigma analysis on a call center process.  From reading the LinkedIn posting, it is clear that the person posting is not experienced in Six Sigma or other  related process improvement technologies that would be helpful to the cause.  This person is trying to figure out how to get a bell curve from a formula related to rate of defects in the call center process, where a defect is defined as a call response being over 60 seconds.  Theo extrapolates from this that it is an example of why Six Sigma doesn’t work in the real world, and why black belts are not needed (all that is really needed, he says, is a pragmatic approach).  And he quotes a response he advocates:

“…at the end of the day if you produce a bell curve telling me the USL and LSL for my call centre, along with the number of defects per million and a sigma value of 1.727, is this really a useful measure? More to the point, what can I – as a business person – do with it?”

Well, look. The response (quoted) asks the right question – is this a really useful measure, and what can I, as a business person, do with it?  In other words, are you wasting our time trying to figure this out in the first place?

But here’s the rub.  A good Six Sigma practitioner would not need to post to linkedIn (hardly the font of six sigma knowledge in the first place) to ask how to plot a bell curve to show USL and LSL.  So the poster hardly represents the “failure of Six Sigma in the real world”.  And a good six sigma practitioner could tell the respondent quite nicely:

If we can plot the response times of your call center, we can understand whether the process is “in control” or not – by which we mean, is it predictable and does it vary in a “normal” way from the median behavior.  If it *is* in control, then we can endeavor to improve the process by decreasing overall response time if too great a percentage of responses are exceeding your 60s window.  However, if your process is *not* under control, then this means that there are one or more special cause conditions causing the process to be more volatile. Therefore your first effort has to be on stabilization before you effectively focus on ratcheting down the long-term variation (i.e. drop the average of the process down as a whole).

Not that Six Sigma is the only tool available.  Lean has several tools that are well suited for call-center style efficiencies, and so does 5s (the Japanese concepts of organizing the workplace to keep things consistent and orderly in order to keep the process consistent as well) and keep in mind just like BPM, Six Sigma is continuously evolving with new tools and techniques and while the statistics is certainly an important part it’s not the alpha-omega that many who haven’t learned Six Sigma believe it to be; certainly not the Six Sigma of the 1980′s.

My problem with the post:  using one example of someone struggling with the concept of Six Sigma, to challenge the whole notion of using Six Sigma – a bit like challenging the concept of a 100-meter dash after watching me run it, instead of Carl Lewis – at least look at how experts apply the techniques!  Six Sigma is not a religion (or at least it doesn’t have to be!)- it is simply a set of tools that can be used to pragmatically improve your process by focusing on unemotional data rather than exposition based on anecdotes.  Not all the tools are even statistical, which was a surprise to me when I first studied material at the green belt level -but even those tools are very practical process improvement tools.  The biggest problem with Six Sigma in the past has been the C in the DMAIC moniker (Define, Measure, Analyze, Improve, Control).  BPM really helps address C by putting the controls in software (call center software can help with this as well), and it helps with the M by helping measure the process even when no Six Sigma blackbelts are paying attention.  This makes it a lot easier for them to drop in, interpret the data, and devise new improvements based on the data, rather than spending so much time collecting hand measurements.

Here’s a great post by Jason Cohen (of Smart Bear software) that illustrates that humans are terrible at making gut decisions that can be disproved with statistics, and how to help yourself avoid sample size errors at least when dealing with A/B tests (as in, which is better, A or B?).  Better yet, it has a cute video of Hammy the Hamster to assist.  It cuts to the point about how much data you need to get a reasonable sample size to draw conclusions, and I think it makes clear why data sets of less than 10 are just generally problematic.  Um, also, there are formulas involved, so if you don’t put much faith in mathematics, Mr. Cohen’s article may not be much comfort to you, but I promise the math required to evaluate your sample size will be easy to do!

In my view, the real problem with applying Six Sigma is usually people.  Turns out it takes skill and  judgment to apply Six Sigma tools in a way that helps the business answer questions the business cares about.  This isn’t that much different than the kind of challenge one confronts getting a business to adopt BPM, or a software package.  Let’s not condemn a whole professional practice with proven successes just because we have one example of someone who doesn’t understand how to apply it (or even 10 examples of such people).

Sometimes it is hard to convey the amount of experience your team has.  Sometimes it is hard to convey the positive impact you’ve made on a company you used to work for.  Sometimes it is hard to convey how much you’ve positively impacted the customer base. But at Driven 2009, Lombardi actually gave me a great way to communicate this to the folks who were there.

All in all, Lombardi walked through 18 different customer stories by my count.  These were really compelling stories of customer success, achieved value, and really deep references for Lombardi.  By the time they were done discussing the 18 customers, I realized individuals from the BP3 team had played key roles in the success of no fewer than 16 of them (often as employees or partners of Lombardi).   Peter noticed this as well.  It isn’t just pride that causes me to say that we have the most experienced team in the business.  And the quality of that experience is second-to-none.  You can’t trivially recreate the experience of being the first person to segment a Teamworks workload between user-traffic (UI) and background processing (of events, web services, and batches).  You can’t trivially recreate the experience of helping an insurance company develop common global processes that accommodate local variation across nine European countries, or helping a global manufacturer apply six sigma techniques to their process prioritization and improvement efforts.  You can’t trivially recreate the experience of starting the Lombardi On Demand Assistance program, nor being the anchor man on the team.  You can’t trivially recreate the experience of being the chief architect and advocate of BPM within your organization for over 4 years.  These are great guys to work with, and I’m barely scratching the surface.

I also found it interesting that in Gartner’s Magic Quadrant, their assessment was that Lombardi customers, in general, are more mature in their thinking about process and BPM.  They don’t typically look at it as a small part of a big project, they look at it as a program, a discipline, as a way they’ll be doing business going forward.  This is actually a *significant* difference in outlook as compared to the typical BPM customer cited by others in the industry.  We take some pride at BP3 in that we helped shape the attitudes of Lombardi and our customers in the early years at Lombardi, from 2003-2007, to get customers to really think bigger and longer term, and to get Lombardi realizing the benefits of broader adoption and deeper adoption within the customer base as something more than just additional license sales.

We are equally gratified and proud to be part of creating new stories in the BPM space, helping customers achieve significant success.  We’re not resting on our laurels, on our past achievements, we’re right now working on critical-path projects for customers anyone would be proud to list as references.  And we are very thankful for their belief in us, and in our ability to help them achieve their business objectives.

Note from the editor:  Peter has been working with BP3 for the last year and prior to that was a key member of his IBM Global Services team on document management software projects.  Here’s Peter’s inaugural post to our blog, following his first BPM conference – we thought it would be a good idea to share the perspective of someone who hasn’t attended so many of these conferences already… hopefully his first, and not his last, contribution to the blog! – scott.

After the conclusion of Lombardi’s Partner Conference, my first BPM-related conference, time has come to write a blog post. Rod Favaron’s keynote got me really excited about being in the BPM space, because I learned that Business Process Management was not only a job, but also a way of life. Lombardi’s goal was very apparent, they want to become the name-brand for the BPM space, the Coke of BPM if you will. Lombardi laid out the roadmap to achieve this goal; you need a platform for communication (Blueprint), a platform for execution (Teamworks 7), and the sufficient know-how (a strong network of partners).

There is a certain level of talent gap to this latter component of the roadmap, which seems to be restricting the extensive growth of a BPM market. A market that is tailored for our current dire economic times, where companies are looking to improve their business processes, to reduce enterprise costs, and to improve enterprise workforce effectiveness. By being part of BP3, the most experienced Lombardi Teamworks implementations team, I am thrilled to get a chance and fill in this talent gap.

My confidence in BP3′s team was reassured, while Jim Rudden of Lombardi was giving us a number of client success stories, and I noticed Scott quietly nodding and acknowledging that someone from the BP3 team has been part of each story Jim mentioned.

At the end of the two day conference, I walked away knowing that there is a stellar BPM market, in which BP3 can be a key player.

- Peter

I’m often asked why I do what I do by friends who are not in the traveling consultant business.  Been thinking about these types of things a lot lately, as you might have noticed in a previous post.  There are a lot of reasons of course, but there are only a few that really matter:

1. I love what I do.  Yeah, there are days when it is “work” and days when it is fun, but when I have quiet moments on the weekend, I am grateful to get to do this for a living.  (definition:  “this” in my mind, is building what we believe can be the best BPM practice in the business, and building it from scratch, and all that entails).
2. I like being able to provide for my family.  There are other careers I would love, most of them don’t pay as well.  Some of them might, if I jump ship.  But I’m glad that what I’m doing allows me to provide for my family.
3. I love the people I work with.  At each of the last three roles I’ve had at companies, I’ve essentially been able to assemble my team.  In one case I did my recruiting internally, rebuilding a team around the company’s flagship product, responsible for more than $40MM in maintenance revenue every year.  In the next case, we were building up the services practice at Lombardi, where the # of people in technical field services grew (conservatively) 10x in my 4 years there.  I have a lot of good, positive feelings about those people that I helped bring on board.  The same is true at BP3 – we have the kind of team you want to succeed for.  For them as much as for yourself.
4. Mom and Dad are proud.  Admit it, that matters :)

A couple of recent experiences, and a few recent articles I’ve read, rubbed me the wrong way on this question of why we go to work.  Admittedly, that isn’t the question being asked, but it should have been!

Problem #1: How Employers Approach “Why we go to Work”

Employers are far too focused on compensation as both a way to create satisfaction and as a source of employee dissatisfaction.  First, I read this article by Joel Spolsky on Inc.com.  The title is appropriately attention-getting: “Why I Never Let Employees Negotiate a Raise“.  I figured that this one would be interesting, right off the bat, and it was.  But I don’t like the outcome.  He starts with the provocative scenario:

What would happen if you got to work one day, went into the kitchen, and saw a list of your employees’ salaries taped to the fridge? Would you freak out? Would you expect to find half of your staff weeping and the other half waiting with pitchforks outside your office door?

I think for one thing, the employees would be rightly pissed off about the invasion of privacy!  Salary information is not just private to the employer, but to the employee.  Joel asserts that keeping salaries secret is a way to avoid paying people fairly.  He might even be right, though no data or studies are cited to back up the assertion, because that interpretation probably fits how some of us feel about it from anecdotal data – we all know someone who was paid pretty out of line with their peers (high or low) somewhere we worked.

But Mr. Spolsky’s next statement is, I think, the foundation of my disagreement with his approach to compensation:

When my partner and I started Fog Creek Software, we knew that we wanted to create a pay scale that was objective and transparent.

Aspirationally, this doesn’t sound so bad.  My objections? First, if the goal was fairness, why not say “fair”, rather than “objective and transparent” ?  Notice, the word fair didn’t occur here an the assumption is that if it is objective and transparent it will also be fair (but I can name several examples in life that are transparent and objective – and not fair)… Second, the statement presumes that a pay scale can be objective and transparent – that is the basic assumption going in.  I’ll concede that there is precisely one objective part of compensation: the dollar amount.  And you can make that dollar amount transparent.

But the process of selecting the right salary, and the transparency of that process, has limits.  The basic idea is to take your experience + skills + scope of your job, sounds pretty objective.  But then there’s the question of which experience should count – does someone’s .NET programming experience count toward their Java programming salary?  The article proposes that objective skills are pretty easy to arrive at, from newbie to “consistent successes” – but these are subjective judgments that they are making about their employees skillsets – not *objective* assessments, and as such they can never be fully transparent.

Ultimately, I’m not a believer in putting a number on someone and assigning salary based on that.  I think a respectful conversation between the employer and employee (or prospective employee) generally will lead to mutually agreeable answers that are less likely to be looked at badly in the future (by either party).  Make sure that if the discrepancies in pay between employees are ever exposed, that you can confidently defend those differences.  If you can, then there’s no reason to fear questions on the subject.  In one important aspect I agree with Mr. Spolksy:  you should *assume* that salary data will get shared at some point, and so you should not do anything you can’t stand behind 100%.

Problem #2:  How Employees Approach “Why we go to Work”

People (in this case, we can probably just say “Employees”) often approach this question without really thinking about it.  They’re chasing the next rung on the ladder, the next reward, the next bonus, the next project, the next external confirmation of success.  But they haven’t defined, for themselves, what success looks and feels like.  As a result, there’s often an over-focus on compensation.  But Maslow’s hierarchy would tell us that after a certain point, when our income covers our physical needs and safety, that it has diminishing returns (because its utility toward achieving love/belonging, esteem, and self-actualization is less than its utility for achieving basic needs).

At South-by-SouthWest (SXSW) this year, Tony Hsieh gave a great presentation about customer service and culture at Zappos.  Particularly relevant to this subject, skip ahead to the slides in the 40′s, and especially slide 44, where he displays the 3 types of happiness:

1. Rock star – chasing the next high
2. Flow – engagement, time flies
3. Meaning / Higher Purpose – being part of something bigger than yourself

The point is that having a larger purpose is a more sustainable form of happiness than chasing the next high.  In general when I talk to people about joining our team (or, in previous lives, my other organizations), I first made sure that there was cultural alignment about what matters to the employee and what matters to me, and what matters to our team.  If someone doesn’t already start out believing that customer success matters, I’m going to have an uphill battle teaching that to them, and it might be easier to let them figure that out on someone else’s dime.  If someone doesn’t get excited about building the best BPM shop in the world, or being part of a great team – it just isn’t a fit.  When someone is consistently focused on compensation trumping all other concerns, I generally recommend they either stay where they are or go contract, and accept that risk/reward proposition.  Or if they’re too focused on being paid “fairly” they may prefer a system like Fog Creek’s.  I would expect Contractors won’t get the psychological rewards of building up a company, but they can more easily maintain a laser focus on their own personal bottom line.  Just beware slide 44 from the Zappos presentation!

Meanwhile, we’re going to get back to building a BPM business we can be proud of.

During Day 1 of the conference, Lombardi confirmed their belief in something that I’ve believed for many years- that the key things holding back BPM adoption are Leadership and Talent.  Lombardi’s take on leadership was that executive leadership (C-level) is required to really foster BPM adoption in a broad way at an organization.  I think there was general agreement in the room that it is a lot easier when that is the case.  However, I wouldn’t let the rest of the organization off the hook so easily.  Obviously, as an outsider – as a vendor, or consulting firm- the people in the room need to focus on getting executive support for BPM, and even leadership of BPM initiatives.  But for insiders, within the organization, if your executives aren’t leading, and aren’t supporting, you have some work to do.  Leadership doesn’t always come from the top at organizations – it often comes from where the need is, which is a polite way of saying, it comes from people who are dealing with real problems (where the sh*t hits the fan).

Often these leaders at lower levels of the organization need help – the data and tools (ammunition) to make their case to executives, the methods and tools to manage and measure their BPM projects, and a sounding board for their efforts.  And this is just why BP3 is in this space – we think Leadership is the critical element, and we think our job is to augment those leaders with expert advice, support, tools, and assistance.

The second term Lombardi focused on was “talent”.  Of course, we’re really talking about “people who are expert enough in BPM to implement BPM.”  It isn’t truly talent (as in, the “born with it” kind) – its the combination of skill, experience, knowledge, and wisdom.  And when you’re sitting in a room full of BPM practitioners, one of the things you do is take stock of your own team and what your role in the ecosystem of partners should be.

At BP3, we’re the most experienced team on the planet for Lombardi Teamworks BPM implementations.  We have quite literally brought together some of the best and brightest in the BPM universe into one team.  And I think we can be a keystone in the strategy of helping companies develop their own BPM teams:

• A customer putting together their BPM Center of Excellence (CoE)
• A consulting firm putting together their BPM practice, or needing help in a region outside their normal operating geography
• A software company adding BPM to their portfolio, needing to augment their skills or team
• A solutions company selling a solution based on BPM software, needing more weight or heft or reach behind their deployment team.

I was encouraged to see the quality and variety of partners in attendance as it tells me we have the seeds in place for really growing the number of BPM practitioners available to the marketplace.

Update: In Day 2, Lombardi came back to the theme of the talent gap – specifically a very good chart showing the ramp of BPM projects relative to the ramp of talent to work in and on those projects, and how often customers (or partners) will hit the wall as the talent gap reaches a certain level of pain – causing delays in projects, or higher costs, or just stress for a team stretched too thin.  The more aggressive your BPM roll-out plan, the more acute the pain from this talent gap will be.  Recognizing that this can happen, of course, you can plan around it by establishing relationships with partners to help fill those staffing gaps or help accelerate knowledge acquisition in BPM.  See the above bullet list – if your firm is engaged in building a BPM competency, and your plans are aggressive, you’re going to need help from outside experts to bridge the gap – or else you’re going to have to accept a longer pipeline for delivery.

There was also an extensive discussion of Lombardi University – Lombardi’s new approach to education and certifying individuals and partners.  That’s going to take a separate post to comment on, however.

Day 1 of the Lombardi Driven Partner Conference covered a lot of ground.  Lombardi’s CEO, Rod Favaron, gave a good general update on the state of things  BPM and Lombardi.  Some clear themes emerged from the presentation and subsequent Q&A:

1. Lombardi’s confidence in its ability to capture market share, and confidence the BPM Market is growing (27% estimated CAGR by analysts from 2005 to 2011!).
2. Growth of the Blueprint footprint in terms of users and geography.
3. Market awareness thanks to great billing from Gartner’s latest Magic Quadrant, and increased focus on BPM thanks to a tough economy.
4. Businesses are picking up Lombardi because of the business pressures they face- global processes with local variation (perhaps due to regulation); changing Service Level Agreements; increasing volume of process work despite no increase in revenue (due to economic circumstances).
5. Dramatically increased focus on Partner enablement (as evidenced by the gathering itself!)

The rest of the day was full of great content for partners:  customer stories, competitive positioning, partner enablement programs, etc.  Plenty of fodder for a few more posts once we’ve had time to let the data sink in and synthesize it with the other data we have.  I was impressed by the quality and variety of partners – and by how many of them we know from prior lives at other companies.  We were definitely in good company.  Looking forward to more product-focused sessions tomorrow…  More to come!

Today and tomorrow we’re attending Lombardi’s Partner Conference, an adjunct to the virtual Driven 2009 conference. So far we’re getting some interesting data and impressions and we’ll be sharing our thoughts as the week progresses.

Thanks to an intrepid WordPress plugin developer, we now have Google Translate machine translation embedded in our blog.  You’ll find it along the right-hand column, and while I can’t test it in too many languages, I did get a kick out of practicing my meagre Spanish skills.  I’ll have to ask our own Peter Olah how the Hungarian translation holds up to scrutiny (it *is* machine translation after all).

I’ve been trolling on Twitter recently – meaning, I’ve started following a few people, just to see if anything interesting crops up.  I haven’t really felt the urge to post to twitter, but I thought I’d see what kind of wisdom arrives in 160-character tidbits.  One thing I immediately don’t like – all the links are reduced by tinyurl to very small URLs – but this also has the effect of making it harder to tell if someone is sending you a malicious link of some sort (even by accident).  Twitter accounts can be hacked after all.

So yesterday I had my first real “hit” on twitter – meaning, the first time I saw something that was really of interest and value that I would want to turn around and share.  It was a link to one of Steve Blank’s articles on “SuperMac” – relating his experiences as Chief Marketing Officer (or VP of Marketing) of a graphics board company that focused on the Mac market.  Honestly, who cares about the graphics market of 20-30 years ago, right?!  But the lessons are not technical lessons, they’re more about understanding the customer and leading your team.

In  “Strategy versus Relentless Tactical Execution”, Steve makes a fantastic case for why execution matters, and also points out one of the most common mistakes college grads make when interviewing:

Just as an aside, over my career I must have interviewed scores of business school graduates (some from the very fine universities where I now teach) who would say, “I want to do strategy.”  Well yes, I understand that, but this is a startup, what else do you want to do?  “I just want to do strategy.”  Those were very short interviews.  The “strategy” of learning who SuperMac’s customers were, what solutions they needed and what our repositioning would be was a three month effort.

The tactical execution took three years.

Note, if you want to do “strategy” (which is a fine endeavor) and nothing else, you have just defined your career as one in large corporation or in a consulting firm.  Stay out of startups.  Tactics mean tenacious and relentless execution measured in years.

On the technical side of the house, the analogy is “Design” instead of “Strategy”, and tactical execution in the technical world largely consists of coding.  I did at least a hundred college technical interview screens each year for 5 years+ at Trilogy when I graduated from college.  And one of the things I learned was that when a college grad started selling me on their design and architecture skills, versus their coding skills, it was a huge red flag.  Of course, when I was a college graduate, I could have easily made the same mistake, assuming that my knowledge of software design and architecture made me desireable to a company, and up to that point, assuming that almost anyone much older than me didn’t know as much about software as I did (in the general population, that was probably true, but not within the specific software company population!).  To succeed as a software engineer or technical consultant, you have to have the personality that will allow you to focus on the relentless execution of the plan.  As you gain experience, your voice in the plan (the strategy, the design) will increase.

In his next article on SuperMac, “Building the Killer Team – Mission, Intent, and Values”, Steve further pounds the table on some principles of leadership that I think are critical:

1. Titles are not your job.  Your job is defined in terms of what you are expected to accomplish for the company and how you further the goals of the company.  Some of Steve’s examples of people in his group defining their job in terms of their narrowly-written title are pretty amusing.
2. You have to give your team a mission- something bigger than “set up the trade booths.”  The mission for his marketing team was pretty specific – growing sales by a specific amount, at a specific margin.  But it could have easily been written a little bit more high level, with some bullet points for the specific year’s financial targets.  Given that mission, the team members and leaders can make better decisions about how to get from here to there – and about prioritizing the mess of work that might be in front of them!
3. Accountability.  Steve describes a world where deadlines in his marketing department were not met. Consistently not met.  And no one was surprised- there was always an excuse.  Finally, he tells them no more excuses for missing commitments – that you can ask for help or work it out ahead of time, but no more showing up on due date with hat in hand full of excuses.  I think this is not as frequently a problem in consulting organizations:  our customers are going to demand a certain level of accountability from us.  But I have seen that this is often a problem in Marketing organizations – precisely because there usually isn’t a customer picking up the phone when they miss.  As a result, it takes more internal discipline and willpower to create that sense of accountability.

Look for more in this space on staffing thoughts.  Because I think part of what Steve gets at is the motivation behind working – the “why” in Why we go to Work.  At this stage in the growth of BP3, we think about the why’s a lot.

Thanks again to Sandy Kelmsey’s blog, once again I found my way to a surprisingly relevant article, this one about keeping business rules out of your use cases, by James Taylor.  In it, he includes a 65-slide presentation that he and Scott Sehlhorst put together on keeping Business Processes, Requirements, and Rules separated.  I haven’t had the pleasure of meeting Mr. Taylor but I’ve known Scott Sehlhorst for well over 10 years.  He keeps a pretty frequently updated blog that covers a number of subjects, but with certain subtopics that have a lot of posts (requirements, business process).

Here’s the slideshow:

Slide 14 is what did it for me:

• Business Process:  What the business does.
• Requirements:  How the system must support What the business does.
• Rules:  Control behavior of What the business does.

This is a really concise way of explaining why you want to separate these things, without even going into the details of what goes wrong when you don’t.  But, for those who need more proof, there are another 51 slides!

Bruce previously had a good post on the 5 things to like most about BPMN 2.  Now he’s back with the 5 things that were left out that might be the most disappointing.  Perhaps disheartening, but not completely surprising, given how difficult it is to pull these kind of specs together.  Hopefully they’ll keep at the revisions on BPMN and react to the feedback once BPMN 2.0 is approved.

Derek posted recently about the Elephant in the Room, by which he means the big issues that are slowing down BPM adoption, and that are not, quite frankly, technology issues.  I’d like to quote one passage from his post:

Organizations are struggling to drive wider adoption of process management? The average number of Processes under Management in a typical BPM site is probably 5 or less; I think we would all agree that more than 10 is unusual. While there may be some cases of organization with over 20 or even 50, the reality is that there is little widespread adoption inside your average large organization (although some are starting to grapple with that problem). Why is that? Because the effort required to standardize the processes and deal with all the data and artifacts is just too great. Yet at the same time, the number of spreadsheets used to coordinate work in those same organizations is numbered in the thousands (or at least hundreds).

Now this is an interesting point.  As he goes on to say, each spreadsheet represents an opportunity to improve the organization and its processes and performance (and financial results)!   However, I’d call attention to his assertion that the reason the adoption isn’t greater is because the effort required to standardize process and deal with all the data and artifacts is just too great.  I believe that the *key* element is that the organizational will-power required is too great.  In other words, to get from 5 processes to 100, the issue isn’t absolute effort – those first 100 processes will aboslutely produce return on the implementation costs and effort – the issue is organizational will-power:  the energy and focus to organize and push and prod people to follow these standardized processes so that the company can reap the benefits of process improvement.

The effort required to implement is also an issue, but I think it is more of an issue in terms of displacing the thousands of spreadsheets that tackle “process” issues beyond the first 100 or so.  In other words, if we can make it easier to organize the process, data, and artifacts, then more of these spreadsheets will look like attractive process targets!

Derek makes some other good arguments that we have anecdotal evidence to support, around case handling, and value-chain optimization vs. inside-the-corporation optimizing.  He also gives some advice like “Deal with the Politics First” that I think is easier for an outsider to do – because it is, in a sense, an efficiency argument – if you deal with that first, and the politics can’t be aligned with BPM success, then you can move on to projects/accounts where the politics can be aligned or are aligned.  If you wait on it, you may implement the first of many projects and then get stymied by politics and lose all of the momentum and skill-transfer progress.

His last point is that there just aren’t enough good people with the right skills and knowledge and experience to deliver BPM projects and successes.  Our experience matches his.  It will take time to get the right skills into the market, and in the meantime, companies will have to lean on consultants to get the job done, but they also need to invest in their own teams – and establish partnerships that will leverage the outside expertise they are paying for to ramp up the internal teams.

Dennis Byron published this article back in March, but I missed it.  Part 2 of 2, the focus was on the CFO’s requirements.

From our perspective, the key passage is right here:

As mentioned above, through your CFO’s (or CEO’s) intervention, your company’s partners may affect your BPM-enabling technology choice. In addition, CFOs may be interested in the partners of your BPM suppliers. Often the association of a BPM software supplier with a big-name consulting firm such as Bearing Point, Patni or Accenture will provide CFOs peace of mind even if you actually use the services of smaller BPM consultancies.

For example, a professional services supplier such as bp3 has a close but non-exclusive relationship with Lombardi Software, and you might want to look for such product-complementary partners once you have finalized a choice of technology supplier.

(Our emphasis on BP3, above)

I happen to agree with this point, and clearly our customers do as well.  Often as our customers are choosing a software vendor, partnerships with big consulting or outsourcing firms are part of the evaluation criteria.  Equally often, they are interested in BP3 (or companies like ours) doing a piece of the work or being responsible for the core BPM delivery.  Customers want to know that they aren’t “locked in” to a single consulting provider, and they also generally want access to boutique firms that are really experts in the area, in addition to the big, generalist, firms.

I went back and read part 1 as well, and its a good read, with broad mention of vendors in the space and their pedigree- and proof that there is still no shortage of software vendors to the BPM space!  Which, I think, just proves that business process touches everything.  I suspect we’ll see a whole wave of BPM software in OEM deals and arrangements going forward, to put BPM closer to the many problems that other software already (mostly) addresses. I thought it was interesting how many of the software vendors mentioned were previously service providers.  For service companies entertaining becoming software companies, I’d recommend reading a previous post on this subject (you can skim by reading the first two paragraphs and the last three paragraphs if your time is limited).

Jim Sinur of Gartner poses this question in a blog post the other day.

Actually, he phrased it as “Is XPDL 2.1 on the Edge of Becoming a Dominant Process Standard”.  I think the answer is a “no (not yet).”

(this may just be because my definition of where the edge is, or what dominant means, is different than Mr. Sinur’s, or it may be because we disagree on some of the background material – either way, here’s my take)

Some arguments in favor of XPDL are cited by Mr. Sinur, and by others (Keith Swensen in a previous post as well), and by WfMC.  The primary argument in favor is the portability of the activity models.  And, a pretty inclusive vendor list that supports XPDL.

I’m not against XPDL at all.  I won’t even mind if it becomes the dominant process standard. But here are the arguments working against it for now:

1. First, keep in mind that these portable activity models are stripped of their execution attributes/elements – those elements are not, according to Mr. Sinur, part of the portability of XPDL 2.1.
2. Second, the processes that are ported are also devoid of the implementation of human activities (and typically, system activities), which are presumed to be implemented outside the BPMN model.  (See John Reynolds thoughtful post on this subject here)
3. When I look at the “implementations” of XPDL on the list above, I found a few problems with it:  the references aren’t dated (and may, therefore be out of date or obsolete), and several of the implementations are for tiny pieces of the software or companies being mentioned, and don’t represent full support of XPDL.
4. According to Gartner, the two leading BPM vendors are Pega and Lombardi.  I looked through that list and I couldn’t find either of them on the XPDL bandwagon.  If the two leading vendors in the space don’t find it necessary to support the standard, then I’m doubting that it becomes the dominant standard.

All that said, XPDL could still become the preferred format for model exchange if BPMN 2.0 doesn’t fit the bill.  Or Gartner could ratchet up the pressure on the vendors that haven’t supported XPDL so far to begin doing so – by weighting that support higher on evaluation criteria for the next Magic Quadrant (though that is quite a ways off, it probably gives these vendors no excuses if they haven’t delivered it by then).  Currently the vendors not on the XPDL list seem to be waiting on the BPMN 2.0 to be released.  If that spec doesn’t live up to the billing, I can imagine vendors supporting XPDL for model interchange as a backup plan.  But I don’t see those vendors investing in two solutions for interchange if they don’t have to.  And I can’t see calling a format a “dominant” format if the leading vendors aren’t fully supporting it.

I think the portability of XPDL, and the compliance tests they’ve put together, are a big step forward for the BPM community.  But that conclusion is regardless of whether XPDL in fact, dominates over BPMN, or vice versa.  Either way, the BPM community wins.  Because I’m sure some of the enterprising XPDL vendors will come up with a mapping from BPMN2 to XPDL 2.1… (These XML formats do lend themselves to being translated after all…)

There’s a really thought-provoking blog on startups, Lessons Learned by Eric Ries, and in a recent post he details his thoughts about “the Launch”.  His advice in a nutshell:  Don’t Launch.

It sounds so counter-intuitive when so much of the hype and mystique around startups is about The Launch.  Much like The IPO, or The Liquidation Event, it seems inextricably tied to the process of starting up:

1. Draw business plan/product idea on paper napkin
2. Get angel funding
3. Build out slide deck and prototype for investors
4. Get Series A Funding
5. Launch
6. Build virtuous hype cycle
7. Go public

Or something like that…(YMMV)  However, Eric points out that most people conflate the announcing of a new product/service with the making of that product or service available to the public.  It turns out, he is advocating to do the latter – make your product or service available – without the marketing launch.

He makes compelling arguments:  that the launch is a tactic, rather than a strategy.  He points out that there are pitfalls to a launch, as well as rewards (for example, mis-positioning, and setting expectations unrealistically high).

What Eric does a really good job pointing out is that your time and energy in your startup is much better spent on improving your product and service offering, on iterating it, and building up your operational capability, revenue stream, pipeline.  In other words, focus on the basics of running a business.  Don’t focus on the Launch. Put into process terms:  the Launch is a step (tactic) that cannot ensure success in the process of building a successful startup.  It turns out that you need to focus on all the more process-oriented aspects of your business:

• Product Design & Development
• Service Design & Delivery
• Sales
• Operations, etc.

Some would say this is focusing on substance over flash – and isn’t that pretty appropriate for a process-focused professional? After all, when the process is the star of the show, there’s a little less glamor, but the bottom line results speak for themselves, and those results are generally sustainable over a longer period of time- launching isn’t something you can do well in a repeatable fashion for your product- its a one-and-done moment in time.  And as a result, as Eric points out, the risks associated with this single tactical action can be negative, but the positive side is a temporary boost if all goes well.

Pretty cool interview with Scott Monty, who runs the social media efforts at Ford.  Not so much relevant to BPM, but it came up on my radar and I thought it was interesting!

Scott

Keith has updated the community with a Model Portability Landmark:  WfMC’s announcement of a BPMN Model portability test.

This is a great step forward, and Keith does a great job summing up the results.  Unfortunately, from my perspective, the portability standard uses XPDL, rather than the as-yet-to-be-approved BPMN 2.0.  I have nothing against XPDL, I just wish some of the vendors I work with supported it!  Without that support, I’m tempted to rain on the parade of this announcement of portability.  For example, missing from this list on WfMC’s website are Lombardi, Savvion, Appian, Intalio, Pega.  Well, Pega and Lombardi (arguably market leaders based on Analyst reports) were recently placed prominently in Gartner’s Magic Quadrant for BPM, and they don’t support XPDL.

However, there is a silver lining for those of us who don’t use products that support XPDL.  Whether BPMN portability can be accomplished or not is not longer a theory.  It is a fact.  It can be done, and it has been done.  Now the question is whether the BPMN-2.0 supporters will get to the altar of portability sooner than later… one can hope!

Impressive sounding title to this article on BPM.com by Terry Schurter.

Terry gives a good background to bring new arrivals to the BPM market up-to-speed, and then dives into dividing the commercial BPM market into 4 segments:

1) Executable BPM software:
Software that is executable, meaning it moves data (in one of a number of forms) from interaction to interaction (between any combination of systems and people).

2) Non-Executable BPM software:
Software that is used to plan, manage, architect, analyze and visualize “processes.”

3) Technical Consulting services:
Services that design, manage, implement and maintain executable BPM software and/or other software to achieve a similar result.

4) Process Consulting services:
Services that help organizations address problems from a “process” perspective; deal with the change requirements associated with “business” changes, and lead improvement initiatives.

Hard to argue with this part.  BP3, for example, provides services to the latter two categories, because we feel there is a gap in offerings in the BPM space that address both technical consulting and process consulting adequately, with appropriate experts in both (there are services companies that are experts in one and novices in the other).

However, I found the overall tone of the article to be a bit negative- perhaps to counteract vendor “hype” which he refers to at several points in the article.  For example, he posits that BPM does not address human processes well.  But of course, when making such a statement, one has to follow with “as compared to what?” – because the bar that any software should be judged against is not an abstract concept of perfection, but rather that of its peers.  If, for example, BPM executable software suites represent human processes 50% to 100% (picking arbitrary range here) better than existing application integration software, that may well be “good enough” for now. In another part of the article, he points out that executable BPM vendors don’t address more dynamic/ad-hoc processes.  I would agree that they don’t address these well -but in my experience the factor holding us back from addressing these processes is the creativity of the process author (consultant, in many cases), rather than the underlying technology.  Technical consultants want to see order out of a chaotic process and try to fit the square peg in a round hole.  Process consultants don’t understand how they can parameterize the underlying software to make it more dynamic and responsive to the individual user’s personal process.  Both types of personalities need to be experts in their software of choice, and creative with their application thereof.

At one point in the article, Mr. Schurter mentions that BPM vendors have been frustrated by the space not “popping” as they hope or expect.  But I didn’t feel like he directly addressed why.  My personal opinion:  First, any software that is focused on real ROI, and delivering it, is training customers to not buy all at once, but to buy piecemeal and prove the value.  Second, BPM requires an intersection of skillsets that are hard to come by in one person’s body.  So what’s the good news?  I don’t believe there will be a popping of a BPM bubble either.  In several other spaces, the market grew faster than the vendors’ ability to mature and provide quality software to a bigger and broader set of audience needs.  The vendors ossified around narrower technology offerings faster, and sold them like hot-cakes. But when it came time to extend and branch out, it wasn’t in their DNA, and the growth stopped or stalled dramatically.  I believe BPM’s growth rate has afforded vendors the time to invest in new features, and mature their platforms, considerably.  The growth rate is also giving the market time to provide the skilled practitioners needed to deliver these solutions.

Mr. Schurter also offers several lessons learned:

1.  The Need for Individual Process Orchestration

2.  Workflow Queues are Extremely Limited

3.  The need to “Capture” Reality

4.  Unstructured or Free-forming Processes

Its hard to argue with these on the face of it, but I found myself looking for more prescriptive solutions rather than just acknowlegment of the problems (lessons).  The part I wanted to learn from the article was how he suggests to address these issues.  For example in discussing alternates to workflow queues, he says the “means by which this is accomplished is highly variable”, but I was looking for examples:  RSS feeds?  simpler integration to email?  How does one provide the work to the right people without introducing new work?  How do you measure without interfering? For Capturing Reality and Free-forming processes, Terry rightly points out there are vendors scratching the surface of these ideas now.  But Unstructured processes isn’t really a technical problem (as I pointed out earlier) – it is much more a problem of creativity of representation.

Maybe to sum it up, the state of the union for BPM in 2009 has as many questions as answers.  My take, however:  the ROI from BPM projects is real, and companies are going to keep investing in BPM as a result.  Nothing in 2008, or early returns from 2009, convinces me otherwise.