Preamble

With the thinning of the herd of Pure Play BPM software vendors, and with the energies of firms like Oracle and IBM behind BPM, I think two predictions we can reasonably make are:

1. BPM software will be pervasive (or pervasively available).  IBM, Oracle, Pega, Progress, Software AG – they’re all going to move a lot of BPM software.  And of course it looks like open source offerings are going to be more prevalent as well.
2. BPM software is going to get better – either because the big stack vendors invest in the new products they’ve acquired, or because the remaining pure play vendors continue to innovate at a faster pace and grow, or because open source solutions will lift the bar for the minimum requirements that all the BPM software suites have to match.

Why Pure Play BPM Consulting?

But the other prediction we can make, is that there is a growing need for specialty BPM consulting firms – or, dare we say it, “pure play” BPM firms.  These BPM consulting firms are all about BPM – and not about being all things to all people. Nearly all of the points I’ll make about BPM pure play service firms likely apply to pure play services firms in other market segments.  The advantages:

• They really “get it” with BPM – and they’re willing to explain it to customers, they even evangelize to people who might never be customers.
• They’re really invested in understanding the BPM space – which pays dividends over time. Their staff don’t go from BPM project to integration project to database architecture project – they’re transitioning from BPM project to BPM project. It takes time and patience to develop a deep practice in BPM, and it takes time to develop a deep bench in any services business.
• The right methodology and tactics to get BPM projects successfully deployed. And after all, success is what we’re after…
• Really deep expertise on at least one BPM software suite – every product suite has its own strengths and weaknesses and you want staff that knows what those are before they start your project.
• Process improvement staff, that understands how to marry improvement methodology to BPM Software.
• They are “high touch” - high quality, long-term relationships with customers are more important than chasing the next shiny deal, because they’re not selling software…
• Experience, quality, focus, and vision. Not volume.
  

Pure Play BPM consulting firms also fill the void left by pure play BPM software companies being purchased by the Big Software companies of our day – previously these pure play firms had staff focused on BPM alone, but now that they’re part of a bigger machine, focus will be diluted within a much much bigger team.

It’s hard to imagine the big guys matching this focus – not that they can’t afford to, but just because they have so many customers, and so many products, and so many people, that they’ll always depend on specialists (pure plays, if you will) to augment their teams of business and technology generalists.  These general purpose consulting, outsourcing, and off-shoring firms just don’t bring the BPM-specific focus to the table.  As such, customers will continue to need pure play service providers to bring that depth of experience and focus to the table.

Requirements Risk

The BPM Pure Play consulting firms know that you can’t throw requirements over the wall to 50 guys offshore to build the software to meet those requirements.  That’s very old-school separation of responsibilities, but it is based on a lack of trust between the parties – requirements have to be thoroughly specified before anyone can start working – and all the work has to be exactingly matching the requirements or it isn’t accepted.  Keep in mind that the biggest risk to any project is that the requirements are wrong; any methodology that puts off finding out the bad news is going to increase risk.

As my friend and colleague John Reynolds pointed out in the comments on my previous post, so much of this is about Trust.  The pure play firms understand how to build that trust with the business by building the solution in the same room, and doing frequent playbacks of the results of their labor.  Iterations and Accountability are the watch-words of these engagements. It doesn’t take 50 people to get the process right, it takes just a few of the right people in the room, and they have to be brave enough to hear the feedback of the business on a daily or weekly basis, and then course-adjust.

Prioritizing

Another issue: the big firms don’t know what they are not.  They’re trying to provide any service their customer needs. Pure play BPM services firms don’t need to increase their own footprint on the project by capturing non-BPM work, because the universe of BPM consulting work is already so much bigger than their ability to capture that business.  Sure, an increased budget will be good for the bottom line of any services company.  But a pure play services firm can be relied upon to turn down work that isn’t in their sweet spot – or at least to advise you that you are asking the firm to take on work that isn’t their strong suit.  Pure play services firms (not just in the BPM ecosystem) can afford to turn down work because they know what they are, and more importantly, what they are not.

Where did we get these crazy ideas?

These aren’t revolutionary ideas – they’re well known and understood and tested in industry as best practice (and not just for BPM projects).  But the general firms just can’t adjust from a world of 100+ person projects to a world of smaller, independently motivated teams engaging in highly value-added projects that act independently – it just isn’t part of their business model.

The BPM Pure Play service firms are the tips of the spears in a sense – the vanguard of experts that increase your odds as a customer of punching through the inertia and hitting the target of success we’re all aiming for.  The BPM ecosystem needs that ability to cut through the noise and focus on what matters most.

Giff Constable’s article addresses this age-old divide from the point of view of a software vendor.  In fact, I’ve previously written on this topic from another perspective, advising services companies to reconsider getting into the software business unless they can:

• Attract outside investment.  This acts as a proof point that your product effort has merit outside the four walls of your office.
• Separate the financial risks and incentives (form a new corporate entity).  This protects your successful consulting business from being stripped bare by the software development effort (and later, the software sales effort). And…
• Enter a market that doesn’t already have a good software solution.  In such a market, the product has time to mature through iterations and customers feedback (assuming you are mostly bootstrapping it)
• (alternately, get behind an open source project, which is a good strategy for reducing the cost of your complements)

Giff puts forward some really good advice, but it is all from the software perspective.  I’ll give my reactions to each bit of advice here, as well as my take from a “services perspective”:

“Keep it separate” – this is great advice, and mirrors my advice to services companies who want to build software products – keep it separate.  Giff doesn’t go into great detail about why, but if you keep it separate it leaves your financials a lot simpler, and makes it more clear how much capital your start-up has required to get lift-off. In fact, if you do form a services arm within your firm, you should look at the profit they generate as investment capital and reward them with equity accordingly.  Instead, product companies often resent their services counterparts and treat them as second-class members of the company.

“Focus” – If you get pulled into consulting work this will detract from your ability to deliver product.  I agree.  You need to have “someone else” deliver the consulting – this can be an employee of your separate Consulting LLC, or it can be an existing firm, or an independent contractor.  But if possible, best to avoid it being your development team.  And I mean that, sincerely, as a services guy – we want those product guys focused on making the product better.

“It is hard to turn down money” – Giff’s argument here is that the consulting revenue is tempting, but misleading – leading your firm away from its product software roots and into the world of becoming a consulting firm.  If you don’t find really good help, Giff’s imagery will be correct – subcontracting only works if you have really GOOD subcontractors.  Probably better to let them work directly for the client and get a royalty or finder’s fee.  But I disagree that if you take on consulting work that you also have to pick up a sales staff and project managers-  just stick to a small number of experienced industry veterans who can sell themselves based on their own credibility, and who can execute projects with little oversight.

“Conflicting Team Goals” – If you didn’t turn down that work (because you needed the cash) then you’ve hired people… now what?  Giff writes:

When you start talking about the glorious future of the business (i.e. the product), these hires start to question, “wait a minute, am I irrelevant to this future?”  That doesn’t help morale.

Great insight actually – this is exactly what can happen if you don’t understand how to lead a services team.  If there is an obvious services business alongside the product that you are building, then it should be obvious what the role of that services team will be in the future:  to enable partners and the channel to be successful using the product- a small number of experts to grease the wheels.  The next point he makes is a good one:

Further, you have a problem in your incentive structure.  Your business is structured like a product company, with a focus on equity, but you now have a business unit which should be structured like a services company, i.e. focused on cash flow.

Consulting doesn’t have to be cash-incentive based if you are willing to share software-company-equity with them.  The problem is that the software guys often don’t want to do this.  There are certainly consultants out there who would prefer cash over equity – put those guys on a contract, don’t hire them.

Giff’s final point on this one is that you have acquired a morale problem: your products folks are now stuck working with clients and hate it, and the client staff is jealous of the product team.  To the first part, keep your product team focused on product.  To the second part, client staff are “jealous” of product staff at software companies because software companies constantly make it clear who they care about most: the product guys – jealousy derives from being undervalued.

Distraction to Death – yes, if you keep the consulting in-house, inevitably a fire-drill will distract your product team unless you firewall things appropriately.  And, as Giff says, “Client services work is difficult.”  I think most folks on the product side of the house fail to understand just how difficult client services work is.  Often difficulty is judged by the complexity of the code.  But in fact the difficulty is in managing human expectations, emotions, and politics. And rarely does anyone take into account the sacrifices services teams make to travel to client sites and leave behind friends and family.

The wrong investors – Giff’s point here is that VCs and experienced Angel investors will typically not want to invest in companies with substantial services revenue.  “They want a scalable business, not one that requires an hour of work to get an hour of pay.”  This is a bit of a pet peeve of mine, that services businesses are considered to be “not scalable.”  There are multi-billion dollar businesses that would argue that services revenue is pretty scalable… and profitable.  But to Giff’s point- it is true that services companies get an hour of pay for an hour of work (or close to it).  Unfortunately for software companies, they often get much less than an hour of pay for an hour of work (lose money)…

There’s a dirty little secret in software – very few software companies are profitable on their software business.  I believe that most enterprise software companies now make most of their money on services rather than software.  Sadly, those services folks are not looked at as investors in the business, but as a drain on the business (in fact, Giff’s article makes that point: a drain on focus, morale, and priorities).

The real issue is that if you’re running a services business “right” – you don’t need outside investment.  The company organically funds its own growth.  From another post on Giff’s blog:

“the running joke [on raising VC] is that as a first-timer, if you don’t have a prototype don’t bother, then if you don’t have traction, don’t bother, then if you don’t have revenue don’t bother, and once you do have revenue – why bother?  ” — adityac, in comments of my last post

Exactly the issue with a good services company.  So investors can’t get good terms from services companies, and the services companies would be crazy to take the terms investors would want (to make their investment worthwhile).  As a result, services companies make for pretty unattractive investments unless the investor is looking for more mundane returns.  Services companies also won’t “pop” the way a service like Twitter can pop – because you *are* constrained by the number of work-hours you can deliver, and the number of skilled consultants you can bring into your firm.

Giff concludes with this:

So a consulting business can’t create a product?
That is indeed my argument: a consulting business has the wrong structure, processes, priorities and people involved to pull off a great new product.  However, a consulting business can be fertile ground for good *ideas*, because you are exposed to lots of client pain points.  If you want to be effective at creating that idea (or whatever it pivots into) and bringing it to market , you are better off spinning out a new company with a small, dedicated, product-experienced team right at the start.

Which matches well with my thoughts on the subject – in fact, at BP3 we’ve been exposed to quite a few good ideas for product.  But I’ll add another angle to this – it isn’t just about giving your product the best chance it can have of getting to market successfully – it is also about protecting your services business from being gutted by loss-leading spending on the product side of the house. I’ve seen more than one successful, profitable services company fold because they raided the cash cow to build and market a product – unsuccessfully.  And in the few cases where they raised outside capital from VC’s, the dilution to the services team was extreme. Better to keep these two organizations separate and let the investors have a bigger stake in a separate firm.

Really good, thoughtful post by Giff, and after reading it a second time, I’m even more impressed at the insights. At BP3, we’ve often been pressed by outsiders and our own team members to consider making product development investments – but so far we’re focusing on building the scale we need in our services business.  If we do something product-oriented we want to make sure it plays to our strengths and can be carved out as its own entity. Mostly, I like to think we’re mature enough to recognize that we aren’t ready for the distraction of splitting our focus on building a great services company focused on business process.

A friend of mine recently asked me about going to work for a software vendor, we’ll call ACME. Well, specifically, what I thought of their prospects in the market, rather than what it is like to work there (after all, I don’t work there, and have never worked there). He was asking me because I’m familiar with the market space that company competes in. I thought a story/fable/parable might be a good way of addressing the question, because I don’t think my answer is really unique to his company/market/situation.

As a card carrying member of more than one corporate alumni group i’ll offer my opinion by way of comparison, by referring back to my travelogue from a previous employer. This story is from the second epoch, primarily, stretching from the time my employer at the time, we’ll call it WidgetWorks, actually had a paying customer, to the time the product actually got good (version 3… isn’t it always version 3?). WidgetWorks was going from small niche vendor to the big gorilla vendor on the block (biggest fish in a small pond). But at the time, it was only slightly larger than rivals in terms of revenue, but a greater percentage of revenues were coming from software licensing and being reinvested in software development than its rivals.