Dave Brakoniecki writes about Technical Debt:

The fundamental metaphor underlying technical debt is easily understood in technology circles but nearly incomprehensible outside of them. Unless you understand in detail the technical trade-off you have no appreciation for how you are ‘borrowing’ which makes it a trust issue between the business and IT teams. If this trust exists, then you don’t need the metaphor to make the problem explicit. If the trust doesn’t exist, then the metaphor won’t help you.

A counterpoint to this – I recently saw a talk by HomeAway’s CEO, Brian Sharples (at Capital Factory).  I also had a chance to talk to one of their lead developers (a friend of mine from way back).  When I asked my friend how it was going these days, he said (paraphrased) “we’re paying down a ton of technical debt right now… and when I look back, and ask if we should have done anything different, the answer is no.  I think we made the right call.”  Interesting. Thanks to Eric Ries, I knew what he meant by Technical Debt.  I also knew what he meant about paying it down (HomeAway has been acquiring companies, and paying it down in this context means they are consolidating these companies onto common software systems instead of maintaining fragmented systems… )

In their terminology, technical debt is a cost that has to be paid in the future.  It can be estimated in terms of work effort.  But consider a variable interest rate – you have the same problem. You estimate costs, but you don’t know for sure what the future cost will be.

Finally, I actually heard the CEO refer in his talk to paying down technical debt.  He had the same meaning the developers had.  What this told me is that he’s invested in the whole company, not just the “business part” of the company.  Those techies are his people too, not just an IT arm to be offshored later.  And they explicitly understood they were postponing a cost (integration) into the future, a future in which they could afford to pay it down (IPO money helps with that).

Dave goes on to say:

The reason the metaphor doesn’t hold is that the unit of borrowing can’t be quantified. Technical debt is an attempt to use the well-understood concept of financial debt to explain a software development problem but everyone (business and technical) understands what happens when you borrow money and the cost of that decision. It’s explicit.

If you borrow $1, well then the amount you owe is $1. People have mortgages and credit cards and use them to make decisions to borrow money so both everyone in an organization can be reasonably expected to understand the basic concepts of financial debt.

The same is not true of technical debt. The unit of measurement is entirely a trust issue between people. Most technical debt conversations are really the engineers saying to the business stakeholders: If you make me do it this way and in this timeframe, it will cost you more in terms of effort to support per month.

But, unlike the financial debt, the interest may not materialize. On your mortgage, you know exactly how much interest you will pay. It’s not a random number.

Getting a handle on the cost (future cost) of technical debt is hard, but it can be done.    You usually have an ongoing cost that you can think of as interest (the cost of maintaining two systems, for example, or supporting two databases when you only need one).  When you remove one of the two systems, it may have a lot of accumulated debt-  which is now all retired debt.  Presumably its functionality was either no longer needed, or replaced by implementing (and paying for) another system.

As to quantifying – this all comes down to estimation and convention.  A proxy is just lines of code (each line of code incurs some maintenance cost, in theory).  Another proxy is to put work estimates against it and cost those.

One might expect me to come down against metaphors – I’m not a fan of using them as proof in arguments or debates.  They’re better used to explain yourself or your thinking, than they are as “proof”.  But in this case, technical debt is a decent short-hand for work-effort we need to plan for in the future.  It avoids people thinking they’re avoiding cost when they take shortcuts – they’re really just spreading that cost out over a longer period of time (for perhaps a much higher overall cost).  Similarly, it assigns cost to gold-plating the software implementation (more lines of code = more debt).

Pretty interesting perspectives on the concept… for more about applying this concept to processes, check out these posts.

Jason Cohen, a local Austin startup hero, paints a bleak picture for consulting in “The unfortunate math behind consulting companies.”  The basic thesis is that it is really hard to ramp up from a single-person consultancy to a bigger company that makes money.  He’s right. It *is* hard.  But it is also harder to be an individual consultant than he lets on:

• Most independent consultants have a hard time relaxing when they’re “off”.  They get enough time on the bench or on vacation to live a good life, but when they’re on the bench they’re worried about when the next project starts. It makes it hard to truly enjoy time off.
• Lack of camaraderie.  There’s no team as an independent.  At first that is liberating, but later on it is frustrating for those of us that are more social.
• Lack of vision.  Being an independent consultant does lack a certain vision.  What are the goals? What are we building toward?  What gets me excited about getting up in the morning to do this work?  You know, besides paying the bills?
• Not to mention, your income is clearly a function of hours worked * billable rate.  Not everyone likes that.
• You have to do it all: sales, contracts, insurance, delivery of the project, project management, QA, etc.

Most happy independents that I know offload at least a couple of these things:

• Having a spouse with insurance.
• Having another company produce most of their leads/business, while they just focus on delivery.
• Paying other independent consultancies to do things like accounting, benefits, and other bits that aren’t in the sweet spot.

So this leads to the question:  should you hire?  Should you try to grow your consulting firm to a bigger practice?  Jason writes:

Consulting can be a great way to fund a startup or make a bunch of cash. It’s easy to start; Just pick an hourly rate and jump in.

But someday soon you’ll notice there’s only so many billable hours in the day, and you’ll be tempted to expand. Maybe hire an employee for $30 per hour and re-bill them at $60. Easy money, right?

Unfortunately the math doesn’t work that way.

Jason is right. It isn’t that easy.  But it isn’t quite as bad as he makes it out to be either.  First, let me lay out some of the ground rules you can use as assumptions if you’re building a consulting company.

1. Base your budgeting on 2000 hours in a year.  It is a nice swag (2 weeks off), and it also makes the math easy!
2. Expect 80% billable as your realistic maximum, though some of your people will do better than this.
3. A good rule of thumb is that your minimum billable rate is 2x the hourly cost.  At 80% billable this is better than break even.  But at 50% billable you’re losing money. This isn’t a good billable rate, but it is the minimum billable rate. Because you do have costs: Medical benefits, 401k contributions, office space, vacation, downtime, sales & marketing, etc.  But there’s no reason to settle for the minimum rate.
4. If you are using a contractor (1099) in the US, you shouldn’t expect to markup their rate by more than 50% (ie, 33% margin for you at most).

So, even with all that, Jason paints a pretty bleak picture for your prospects of making money as a consultancy.  The primary issue is scaling the size of your business so that you can (a) reduce risk, and (b) make more profit.  If you talk to friends at startup software companies, they’ll spend lots of time discouraging you about the scalability of consulting companies (something investors and software folks are pretty convinced of).  Here are my thoughts about how to address scale, risk, profit:

Start with a co-founder.  If you don’t have one, find one who is also a specialist in the same area, or who has a tightly complementary specialty.  Make sure that you have enough skills overlap that you can cover for each other in a bind, but that you also have some different skills to augment each other in unique ways.  Starting as a company of two partners is easier than being the sole founder with one employee.  (Who wants to be your first employee, anyway?).  It allows you to reduce your risk – and if you charge correctly you can be break-even if one of you is billing.  And you’ll have more flexibility to chase leads, take vacations, etc. – without company revenue declining to Zero while that is happening.

If you’re going to grow, you’re going to forgo profits.  The independent consultants I talk to don’t want to admit that, but it is true.  At BP3, Lance Gibbs and I certainly could have had a more profitable first 3 years of operation if we just ran a two-man shop.  But we saw an opportunity to grow a bigger business.  We hired great people – and held on to the team through lean times in 2008 and 2009 – taking lower salaries ourselves and paying people when they were on the bench for long periods of time.  That scrappiness and determination got us into a great position to grow our team in 2010 and 2011 – from a bigger base.  But remember – every time you hire, you’re investing profits – reducing your cash flow for 60-90 days (or longer if training is required).  A good way to think about it is that people you hire in 2011 will add materially to your business in 2012 – it makes you plan conservatively around what you can afford.   Now that we’re a little bigger, it is easier for us to hire when we come across the right person – we don’t have to work as hard to time each hire just right.

This also means that it is better to not grow, than to hire the wrong people.  If you take this approach, when you can’t find enough talent to grow, you’ll be more profitable.  When you can find those people, you’ll grow the business at a little lower margin, and with a little tighter cash flow – but with your future baseline performance at a higher level.

Those early hires are really important.  See the previous point.  Early hires in a consulting firm set the tone: culture, discipline, follow-through, work-ethic, reputation, skill.  Don’t hire someone on reputation alone – better to hire someone whose reputation hasn’t caught up to their real performance than to hire someone whose reputation exceeds their real capability. If you hire the right people at the beginning, it actually gets easier to attract the right talent later on.

Forecast next year’s revenue based on your current staffing.  Don’t fall into the trap of building a consulting-based business plan that depends on hiring people in the same year that they contribute to your bottom line.  I’ve seen a lot of these “plans” before: “we’ll hire 3 people in Q1, 4 people in Q2, 6 people in Q3…”  To which my response is typically “which 3 people? which 4? which 6?”  If you don’t know who they are, take that out of your plan.  A better way to write it would be:

Based on our forecast we can afford to hire 3 people in Q1, 4 people in Q2, 6 people in Q3.

Point being: there’s a difference between what you can afford, and what you can actually execute.  Given how important each person is to the growth of your company, are you going to hire the best 3 people you can find in Q1, or will you only hire 2 if you can only find 2 you’re excited about?  Intellectually we all know what the right answer is but it is important to actually act on that knowledge.

Get Financing.  You may not think you’ll need it – but as soon as you can, get it.  When you’re a small consulting company, usually one customer has an outsized influence on your cash flow.  Having a line of credit or a loan can give you some cushion against the vagaries of their accounts payable.  Word of warning: it is very difficult to get a traditional bank to do this until you have 3 years of history as a business.  Second, you’ll be referred to operations that do receivables factoring, but I would recommend steering clear of those companies because their contracts are horribly one-sided and may make it difficult to get traditional financing later on. If you and your partner have the capital for it, it may make sense to put some money into a corporate savings account – to be tapped only in certain situations that all the partners agree upon.

Have a sharp focus.  You have to know how to say no to work that isn’t in your sweet spot.  Saying yes to all the opportunities that come your way will cause the following problems:

• You won’t build the necessary depth in your chosen area of expertise, or any particular area at all.
• Your win rate will be a lot lower – because you’ll be competing with people who specialize in each area, whereas you are essentially presenting yourself as a generalist.
• You can’t effectively partner with other people or companies because you always feel like you could be competing with them for business.  Ask yourself what kind of work you would refer to the partner firm, and what kind of work the partner would reasonably refer or sub to you.  If you can’t answer that question, one or both of you is lacking focus.
• You won’t build a reputation in your niche.  Reputation in the age of twitter and blogs is really powerful.  Lack of one is similarly powerful in its absence.  Start blogging, get on twitter, and learn your niche and who the experts are.  Those experts are rarely wanting for work.

Back to Jason’s Post:

Jason terms it “unfortunate” math for consulting… but the real problem is that consulting is an EQ business, rather than an IQ business.  It requires more emotional maturity and awareness, and the smartest guy in the room is not necessarily the best consultant.  Ideally you’re both high IQ and high EQ.  But don’t forget which one will get you further in consulting – EQ.  If you don’t have a high EQ, partner with someone who does!  There’s no one “right answer” to how to succeed as a consultant.  But there are definitely higher or lower risk plays on the business.

Jason points out in his post a series of problems a small consulting firm will face.  There are remedies to the problems Jason points out, and he offers a few himself.  But as you ramp up your team, in my experience when the firm is ~5 people is the hardest phase in growth.  At that stage you need everyone billing as much as possible, you can’t afford to pay for overhead (a non-billable person working for your company), and somebody (hello, founder) has to work a lot of extra hours to get things like invoicing, sales, and recruiting done – because customers don’t pay you to do that work with billable time, you don’t want to pay someone else to do it for you, and it has to be done right.

As you head north of 10 people, the math starts to work more in your favor.  You can hire non-billable help with administrative or sales work, or one of the knowledgeable billable people on your team can explicitly spend less time billing.  Another thing I’ve often heard from bigger companies is that getting past 15 people is a tough barrier – that you run out of “people you know” to hire, and have to get your operations in much better order than you required as a smaller company. I agree that somewhere between 10 and 20 people, the nature of your firm changes and you need to change with it.  I’m sure that is true at many inflection points further on as well.  If you just look at this as another interesting business problem to solve, you’re in good shape.  If someone tells you there’s a glass ceiling to how big your services business can get, just ask them if they know how big IBM’s professional services business is.

Jason’s thought on running the business at smaller sizes:

• None of these new tasks are fun or creative. It’s drudgery, and it’s on you. Congrats, you’re a business owner.

Well, don’t go down the path of building a business unless you enjoy being a business owner and running or building your business.  If you enjoy doing this sort of thing, it won’t feel like drudgery – it will feel empowering and gratifying*.  If you don’t enjoy this sort of thing… partner with someone who does, or get a job!

His other recommendations are in bold, my comments in regular typeface:

Recommendation: Charge more.  Well, this one is a bit obvious.  If you have too much demand for your services, you generally need to raise your rates or hire more people (increase supply).  Figure out which one you can do.  The basic issue is, pricing is incredibly important in consulting businesses.  Mimiran is a great resource for better pricing techniques.  But regardless, you have to understand that your consulting value is worth more than the hourly wage you put in.  You have uniquely differentiating value.  You’re likely committing to provide your customer with an outcome or else lose your “job” (contract) – which is something their own team may not be putting at risk.  An hour is not what you are truly charging for, you’re charging for the output you produce, and dividing it by the # of hours. There is a difference.

Recommendation: Bill more hours.  Generally consultants bill more than what Jason was describing in his post. While this is true, so long as you bill by the hour, I’d phrase this differently:  provide more value.  That might mean billing more hours.  Or it might mean that you will either raise your rate or the demand for your services by providing “better outcomes”.  Focus on the value.

Recommendation: Build a product.  I’d be very careful with this one.  Most consulting companies don’t make the transition.  The product you’re going to build has to be something that will get a lot of your attention and TLC – and likely something that earns money for you right away.  What you don’t want to do is take a profitable consulting company, plow the profits into a product that isn’t profitable (most products aren’t), and then find yourself with a less valuable enterprise overall.  Make sure the product is truly something you want to invest in, and make sure you understand how it will yield revenue.

Recommendation: Use subcontractors instead of employees.  This is lower risk, but lower reward – and I don’t just mean financially.  This choice comes down to what you want to be when you grow up. Is this a business or a body shop? There’s a difference.  If you’re building a business, you use contractors as a minority of your business or to augment specific skill sets or deal with variability of demand.  But if you’re building a business, it is your team, your employees, that will really build it with you.  You need to hire those people – contracting them won’t cut it.

Concluding Thoughts…

Jason’s conclusion:

It’s always hard. Most consulting companies don’t make much profit, and it’s one in a thousand that has the discipline to launch a successful product during off-hours. If you’re going to make it happen, you yourself need to be serious, disciplined, and relentless.

The idea that small consulting companies don’t make much profit doesn’t ring true.  A well-run consulting business is a good business.    Of course, for many consulting companies their margins may look lower because they do certain things:

• Provide generous benefits, from vacation to medical insurance, to 401k or profit sharing.
• Pay generous salaries & bonuses.
• Buy the latest and greatest hardware gadgets and software tools.
• Keep overhead (non-billable head count) low.

These tend to reduce margins in the short run, but retain top contributors in the long run.  Usually a tradeoff worth making.  But the biggest question for the independent consultant moving toward a small consulting firm:  What’s next?

Is the goal to build a big consulting firm?  To make some money?  To solve a particular problem in your industry or specialty?  To have a boutique firm of good friends and rock star specialists?

It really is up to you.  But the answers will help dictate what makes sense as you build your business…  For BP3 it is to be the best business process firm we can be – which is compatible, for now, with being a growth business.

*  Author’s note:  One of the things I enjoy about building the business, as a consultant, is the opportunity to practice our craft (BPM) internally.  As we get bigger, there are real payoffs to improving processes. And we have time to actually think about our business and improve it.

** Another note: Perhaps the title should just be “Consulting Math” since we didn’t discuss Software Math… but I think the prevailing public opinions about consulting businesses largely come from people with a software background – primarily that they don’t make much money and can’t scale, and are inherently riskier.  But, most people don’t mention the fact that these days, most software companies are probably less profitable than consulting companies.  There are really significant exceptions (e.g. Google, Microsoft) which is what people focus on.  But in enterprise software most of the money is in consulting these days.

Adam Deane strikes gold again with this post on a “Request for Answers”:

There is a difference in the amount of work needed in “simple process”, and a “simple process, but by the way we want it also to integrate into an old legacy system, run through a thousand steps, and automatically make coffee”
The difference usually results in a quick deployment where everyone is happy, or a project the drags on for ever, a vendor looking to run away, costs spiralling and everyone feeling that they have been screwed by the other side.

But the best part are the 20 questions he’d ask back to the customer… I’ll just list the first five to give you a taste of how spot-on they are:

1. What is the business problem that we are trying to solve?
2. What impact does this have? Who does this impact?
3. Why do we want to resolve this now?
4. How critical is this process to the organisation?
5. What would be considered a project success?

 

 

Our very own Flournoy Henry recently contributed to a new IBM Redbook: “Scaling BPM Adoption from Project to Program with IBM Business Process Manager” :

Your first Business Process Management (BPM) project is a crucial first step on your BPM journey. It is important to begin this journey with a philosophy of change that will enable you to avoid common pitfalls that lead to failed BPM projects, and ultimately, poor BPM adoption. This IBM® Redbooks® publication describes the methodology and best practices that lead to a successful project and how to use that success to scale to enterprise-wide BPM adoption.

The intended audience for this book includes all people who participate in the discovery, planning, delivery, deployment, and continuous improvement activities for a business process. These roles include process owners, process participants and subject matter experts (SMEs) from the operational business as well as technologists responsible for delivery including BPM analysts, BPM solution architects, BPM administrators, and BPM developers.

PDF and HTML versions are available (I recommend PDF version, it is just easier to read because some of the sections are short but flow well together).

This is just part of our (and Flournoy’s) commitment to give back to the BPM community we are a part of.  But it wouldn’t be possible without some of the folks at IBM organizing and bringing a group of experts together to do it.  Congrats to Flournoy, Lisa, Ines, Fahad, Wim, Jonas, and Duan for producing this (RedBooks are team effort).  Hopefully we’ll be able to participate in more Redbooks in the BPM space in the future.

There’s an argument that says the world is too complex for humans to understand.  Further, that by thinking we understand cause-and-effect, we’re doomed to act in ways that have unforeseen (usually negative) consequences.  It is a really interesting debate, and informative on the more than two sides represented.

Personally, I found myself rejecting this notion as useful.  Not that the notion of complexity isn’t useful – but letting it paralyze you is not useful.  When it comes to running your business, simplicity is more powerful than complexity.  A combination of relatively simple interactions has more power than a complex single interaction.  Simple interactions are more replicable, more scalable. I would focus more on enabling “emergence” than disabling decision-making by leaders.

Simplicity and abstraction go hand-in-hand.  The iPad has a significant amount of complexity baked in – from the hardware, to the software, to the production processes that lead to its creation, to the design processes that lead to its conception.  But to me, it is just a glossy glass enclosure that responds to my touch.

Does my touch cause the apps to do what they do?  Actually, it doesn’t matter whether touch is causal or not – it is, at minimum, so highly correlated between action and reaction that it feels like causation.

And that’s what we should be striving for in our businesses – that our actions would achieve the results we’re looking for – will feel like causation – though there may be a complex choreography and it may not be driven top-down.

There was a truly fantastic quote in the original HBR article:

“If you want to build a ship, don’t drum up people together to collect wood and
don’t assign them tasks and work, but rather teach them to long for the endless
immensity of the sea.”

- Antoine de Saint-Exupéry

Sometimes simple is best.

Actually, my least favorite seat on a certain model of plane that flies in and out of Austin is 27E.  Some planes manage to pack the lavatory, the kitchen, the divider wall right behind you (no reclining!), and engine noise all in one truly fantastically bad seat.

Jason Cohen asks the question: why?  Why not spend time either improving the worst case experiences for your customers – or better yet, eliminating them entirely?  Would it be such a bad idea for the airlines to eliminate a few of these bad seats?  To put more insulation in? To offer some freebie or consolation prize for the bad seat?

Eliminating these worst-case experiences doesn’t mean radically changing your business. It just means saying no to customers or projects that aren’t a good fit:

Bill impressed them and they were ready to begin, but Bill decided this was too far outside his experience and so told them, while it would be interesting and fun for him, and he was confident in his abilities, he isn’t comfortable accepting this job, because he wants no chance that they’ll have a bad experience.

Of course this only won the customer over still more. Bill won’t do this particular gig, but I guarantee that when something else comes up in six months, he’ll automatically be offered the job. As for me, I’m going to continue connecting customers with Bill because there is no seat 32B with Bill.

Saying “No” requires that you know yourself- or your firm – well enough to know what you’re not going to do.  Buried in the example is the fact hat Jason’s startup is referring this consulting business to a consultant – rather than doing it in-house.  Another example of knowing when something is outside the suite spot.

Now I need to go think about how to eliminate seat 32B for our customers at BP3!  Looking at this from a BPM/process perspective, however, I’ve often see customers look at this the wrong way – focusing on all the exceptions before they have the average case nailed down tight.  What Jason has described here isn’t handling every exception, it is recognizing a bad situation and either avoiding it (saying no), or figuring out how to make it not feel like seat 32B. A precursor to this is actually getting the average case nailed down and sorted out.

Jacob Ukelson recently said:

There was an interesting discussion on ebizQ around the question “What does enterprise tech have to learn from Steve Jobs’ success?” What made it even more interesting for me is that even though the question was asked of the process community, not one person answered “better process management” and certainly not “leveraging a BPMS”. So does that mean that even the process community doesn’t see any way to link outsize success to better process management? – or is this just a quirk related to Apple?

Two thoughts:  first, I think it is a good thing that BPM/BPMS advocates weren’t attempting to take credit for success we didn’t cause.  This doesn’t mean Apple doesn’t have good processes or differentiating process, but with all modesty, I think we have more to learn from Apple than vice versa when it comes to how to run a business process.  It isn’t enough to point at Apple’s success and declare victory for our (or someone else’s) interpretation of how they run their business – we have to tease out the correlated or causal elements and then show that they can be applied intentionally elsewhere.  Instead we should be pointing to those who are succeeding as an example to emulate, not a proof point of our approach – they’re only a proof point if they’re following our lead, rather than the other way around.

Second, I’ve actually made a connection between Apple and BPM several times over the years. I linked to the thread of articles in my ebizQ comment but I don’t blame anyone for not reading them all!

In particular, this one gets the most page views: http://www.bp-3.com/blogs/2009/01/apple-and-business-process-management/

Jacob is wrong in saying that process isn’t what makes Apple great, but he may have a point that process is “table stakes” in the areas we usually think of it (supply chain management, manufacturing, etc.).  Apple’s differentiated processes are their processes for product design and user interface, not to mention their go-to-market decisioning process.  All the great designs in the world wouldn’t be enough if they didn’t have the supply chain process prowess to back them up. But, similarly, all the process prowess in the world isn’t enough if you don’t have the ability to design (see Dell, HP).

Moreover, Apple doesn’t just excel at process where it is obvious.  They’ve innovated with manufacturing process (aluminum casings, glass casings, etc.) that have also differentiated their profit margins and product designs.  These are process improvements – but they’re also process improvements where it really matters.

Jacob goes on to say:

It is clear that companies need to manage processes well, but that isn’t what makes a company great. I am sure Apple had some really good processes, but today those are table stakes. The real battlefield is in the realm of knowledge workers – design, user experience, innovation, customer understanding – and most of today’s process thinking and tools don’t help much there.  That is why I don’t think ignoring process as a success factor is a quirk related to Apple, it reflects what is really important for a company to be successful in today’s world. Process won’t make your company great – design, user experience, customer understanding and innovation will.

Design, by the way, is a process… So is developing a good user experience. The companies that are good at this have process around it – just ask Genentech or Frog Design, to name two. It isn’t “automation” the way most people think when you say “process” but it is a process nonetheless.  But if your focus on process doesn’t include user experience (voice of the customer) – you may find yourself non-differentiated on measures other than price.

I wouldn’t draw too many conclusions from the ebizQ crowd being momentarily focused on product design, etc.  I’m sure that there’s good process behind those efforts at Apple, and it looks to me like we just take it for granted.

Joannes Vermorel, of Lokad, has guest-posted on A Smart Bear blog on the topic of email.  Specifically, why your company should have a single email address.  But to the BPM consultant, it reads like an email process manifesto for your company.

It is a fascinating read on (email) process, thought that wasn’t necessarily the intent.  Some of the highlights:

1. The dangers of building too much process too soon – before the true requirements emerge.  Spinning off too many email addresses complicates your organization’s ability to respond correctly.
2. The problem with exposing your internal processes and organizations to your customers and partners, by having many different contact email addresses for your company.  Your customers and partners don’t care about your internal structure, they just want one contact point that works.
3. How to deal with inbound email flow – routing emails to the people most appropriate to respond.
4. The benefits of shared information within your team.  Everyone knows about the communications happening, and can see the history and context.

Along the way, we learn from Joannes that not advertising a public email is bad.

What are the benefits to moving to a single email account?

• Improved responsiveness
• Smarter replies (better quality)
• Peer reviews of email communication
• Better Morale
• Resilience to turnover

That’s a pretty good benefit from a process change.  Joannes sums it up:

Finally, I believe that the single email approach remains valid no matter if you happen to be two guys in a garage or MegaCorp Inc, but I digress. Are you still exposing a number of emails not equal to one? What are you waiting for?

I think the biggest point to take away – is keeping it simple for customers, and not foisting your own company’s complexity upon them.  That sounds like a great principle of process improvement to me.

John Reynolds wrote a post recently about Interdependent tasks, and the resulting complexity. John takes a simple example, the vacation approval process, and then points out what makes the difference between a cute model and a real implementation:

Sam can’t really (in good conscience) make a Decision about any Vacation Request in isolation.  Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests.  To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

And further:

Examples like these are what makes implementing “real world” processes hard.  Processes seldom execute in a vacuum, and work done within one instance often influences other instances.  Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

He’s right, of course.  This is why a demonstration of a BPM solution can look easy, but the actual implementation actually takes real work and thought.

John purposely held back from suggesting a clever BPMN modeling solution or other trick of the trade to give us something to think about. I’ll give you my thoughts on how to approach the problem.   But in a general sense, this falls back into a general process pattern:

• a process model that does a decent job of representing one process “instance”.
• another process that manages the set of all processes
• yet another process that is the maintenance and improvement of the process definition and the management of process instances collectively.

What John is describing is a variation on the second level of process.  It already goes without saying that we need to manage a set of vacation requests collectively.  The extra wrinkle is that at a step in the approval process, the process should present context to the user, that likely includes:

• All pending and approved vacation requests for other team members
• Possibly other pending and approved vacation requests for people on other teams
• Remaining vacation days for this person
• Remaining days in the year in which to use those days
• Time since last vacation

All of this information gives the Approver context in which to make the decision.  The individual process’ execution flow hasn’t gotten more complicated. But the implementation details of that Approve step got more interesting.  Luckily, the information above will be pretty easy to provide if your BPMS had reasonable tracking and introspection capabilities.  So if we simply invest some trust in our user, and supply them with the information they need to make a decision, we’ll get really good outcomes with minimum implementation headaches.

Sometimes the really interesting bits in a process implementation aren’t in the BPMN.  As John points out, we shouldn’t assume that every detail should be captured in a BPMN model.

Anatoly recently did a podcast with ebizQ’s Peter Schoof.  The transcript was posted on Anatoly’s blog, and well worth reading, but something he said in the pre-amble really caught my attention:

My activities in BPMN got me a reputation of an expert in process modeling. Let it be so; yet I believe it’s rather the basics of the craft than its top and personally I’m more interested in issues arising at BPM and performance consulting intersection and business process BPMS implementation methodology. It’s a common story: the public is more attracted to what an expert considers almost trivial while what he treats as an achievement may come unnoticed. As an example, the most popular posts at this blog are those tagged “FAQ”.

I added the emphasis in the second sentence, and included the whole paragraph for context.  One of the most difficult things to explain to novices and newcomers to BPM is that although the basics sound easy in black and white, a lot of judgment and experience comes to bear in making subjectively good decisions about how to leverage BPM techniques.  Rightly, this is not what people want to hear.  They want to hear that it is a science, an engineering discipline, if not a mathematical formula.  But it is not so.

I’ve often said what makes the difference between the average BPM practitioner and a really good one is that the best practitioners have a sense for how all the individual simple things will come together into a cohesive outcome – each individual action being pretty easy, but the combination of actions, and knowing which action to execute when, and under what circumstances-  that is the secret sauce of BPM.

What Anatoly’s blog largely provides is an insight into how he thinks through these basics – the subtleties that are like lego bricks – individually sort of simple (2×4, 2×2, etc. ) but in combination quite interesting business problems can be addressed. And it is the basics you need to master first.

Update: In the interest of clarity I’ve updated the second-to-last paragraph of this post.

Anyone following the #BPM hashtag on twitter has probably been amused at times because we also get a fair number of posts about BPM the XM/Sirius station as well.

But in this case, Emily Burns of Pega has decided music offers a metaphor for BPM vs. Case Management:

Recently I was describing to someone the difference between BPM and Case Management, and found that music lends itself very nicely as a metaphor—specifically, the contrast between solo and ensemble works and the contrast between Classical and jazz.

I couldn’t disagree more.  Any use of an analogy like this, especially when it is loaded to make one party sound better than the other, is easy to pick apart.  In particular she states that “the closest musical metaphor to traditional BPM is the performance of a solo piece; a piece of music written to be performed by an individual person.”  I’m not sure what kind of BPM Emily Burns has been familiar with, but I have yet to see a BPM project for one person.  or built around one process-actor (or even multiple process actors all playing out the same role in the process).  BPM projects are cross-functional and typically cross-departmental.

The core of her argument is on more common footing with the idea that case management accommodates improvisation whereas BPM does not.  But I’d hardly equate case management with a jazz ensemble.  Nor BPM with classical music.  Music is art.  Office work may not be routine, but it isn’t typically what I’d call art.

Comparisons and analogies around Case Management and BPM always trip up if one is willing to dig into specifics.  Often, the people making the comparisons do so with an implicit (unstated) assumption that all the interactions between process participants has to be modeled in a tool to be effective (or coordinated in a tool at runtime to be effective).  This just isn’t the case – normal human interaction takes place outside of tooling – whether you are a BPM advocate or a Case Management advocate.  There’s no need to model the conversation in the hall, the conversation over the cube wall, the agreements made between coworkers over lunch.

What it boils down to is simple – most case management approaches really focus on improving the outcome of a single case, largely ignoring the consequences at volume.  Case Management approaches seem more appropriate to work “processes” (cases) that can not be well-designed a priori.  BPM approaches, on the other hand, tend to focus on optimizing aggregate outcomes rather than a single outcome.  BPM approaches seem more appropriate to work “processes” (cases) that can be largely designed in advance (a priori).

The analogies may be comforting, they may help explain an opinion or a point of view, but let’s not mistake them for proof. (Or in particular, proof that one approach is better than the other)

Mike Gammage on Sourcing Shangri-La:

To avoid continually tripping up, to be able to implement Management 2.0 thinking, the enterprise needs a cortex, a way of pulling it all together:  an integrated management platform.  And its language has to be end-to-end business process because that can be universally understood across the enterprise. So it’s a BPM platform.

In the BPM platform, business process becomes the key by which we describe what the enterprise does, and how it all fits together – and how we analyse what the impact of change will be.

But it goes way beyond this. The BPM platform integrates process with real-time metrics, risks and controls, compliance and quality management – all within one governance framework. It deploys process to every desktop and mobile device as a personalized intelligent operations manual.  It also provides the collaborative framework that enables a culture of continuous improvement.

Worth reading the whole thing.  I’m still digesting it.  Well, partly I’m still getting over the use of “2.0″ on yet another word.  But Mike makes good points about balancing the need for autonomy and innovation with the need for predictability or compliance.  In fact, a similar discussion broke out on ebizQ recently, with Ian Gotts and Theo Priestley representing two ends of the spectrum quite well.  As I noted in my own comment: “you want innovation, but not in *every* aspect of your business.”

Adam Deane on Business Users and Programmers:

But the best differentiator pitch that I’ve heard being used is the “business user oriented” vs “programmer oriented”.
The claim is that business users can use the tool. I think it’s a great differentiator.  Although it usually doesn’t have much truth to it – it’s still a great market positioning pitch.

You see.. (and I’m trying to hide my sarcasm here..) BPM tools that use programming are bad for you.

If you need to open Visual Studio to build a workflow – it means you need skilled programmers, which means high salaries, and they need to write code, which means you need a tester, a team leader and a project manager (more salaries).

Every time the customer wants to change the business process you need the programmers to recode, recompile, retest (long deployment, or no changes – you can pick). Sophisticated code means that you need to rely on the IT team which means that you are tied in with that programmer/team. If the programmer leaves – no one will dare to change their code (who wants to be responsible for code that someone else wrote.)

“If you need to open Visual Studio to build a workflow” – then you’re doing it wrong.  A good bpm tool doesn’t require you to build your workflow in C++/C# or the like.

Of course if you’re opening visual studio to do an integration – have at it.  To build something custom that will plug into your BPM solution – have at it.  BPM should make certain things easier than traditional development tools (and a “workflow” sounds like one of those things to me).  It doesn’t mean that you won’t still need traditional development tools for a BPM deployment, but you shouldn’t have to write your process flow in assembly language any more than you should have to write it in C++.

Incidentally, I don’t agree that “business can do everything” is a good pitch, though I do agree with Adam that it is horribly oversold.  The business and IT have to work together to make BPM successful (or, arguably, nearly any long-term IT or business investment).  Vendors oversell this all the time, which accounts for Adam’s sarcasm.  But, conversely, companies purchase tools that bring too much complexity to the simple stuff, or tools that start simple but don’t scale with complexity.  What do I mean?  I mean that as you add more process intelligence to your tooling, complexity should increase at a linear (or less) rate.  If you experience complexity increasing at a greater than linear rate, you’ll hit a point where the system can’t be maintained – the interconnectedness and interdependency of the system is too complex for someone to properly understand, modify, and maintain.

That’s why it is important for the “workflow” to be simple.  Because it can be.

Gary Comerford of Process Cafe recently noted that improving process is not always in the company’s best interest, as in cases where penalties and fees may be extracted from uneducated customers and users.  Despite the following process issues for a train system, the organization may not feel that it is economically advisable to address them:

1) They are notoriously unreliable in their timings. Trains are late more often than should be expected
2) There are delays for many, many unknown reasons. Leaves on the line and ‘The wrong type of snow’ are two examples
3) The ticketing system is completely nonsensical and misleading.

Gary points out that the organization is not incented to address problem area #3.  That indeed, much of their revenues derive from the ticketing system’s shortcomings:

So let’s examine this: The process of a rail company calls for multiple, confusing fares which the customer has to decipher and understand. The penalty for buying and using an incorrect fare is a spot fine or the requirement to purchase a higher priced ticket to continue ones journey.

Can you see how improving this process would help the customer but not the company? They would end up with passengers buying the right fares, penalty fares being reduced and higher-priced ticket repurchases being eliminated. The end result would be a reduction in rail-fare income and associated profit. Of course the rail companies are not going to go for this.

I think this is a classic case of penny-wise, pound-foolish.  Of course it looks like the train system is making more money.  And initial measurements of revenue will tell them that revenues increased when they implemented the new penalties and schemes.  Based on this information they’ll proceed forward blind to the reality – that they are undermining the very foundation of their business – the goodwill of their customers.

When revenues eventually begin to decline, they’ll blame in on changing ridership patterns, changing economic conditions, etc.  They’ll never think to blame it on the fact that people would prefer not to use their service because it is a hassle.  When they need public-funded improvements in the rail line or station, they may be surprised when voters or elected officials fail to support them, further undermining their ability to serve customers well.   A difficult system also leaves people feeling that it is okay to cheat the system, because the system doesn’t seem to be fundamentally fair.

That said, I would differentiate between changes in the process that provide better customer service, and changes in the process that “make things easier for the consumer.”  Mortgage companies in the US made things easier for the consumer in the last decade- it turned out to be horrible for both the consumer and the business, in the long run.

Gartner’s Business Process Maturity Model is not for the faint of heart.  I’ve heard a couple of talks on the subject and read a couple of papers, and never found it terribly useful or informative to our action plans with customers.  Apparently Anatoly Belychook agrees based on this blog post:

Phase 0. Functional management. Organization has yet to realize that its performance as a whole depends not only on how certain functions are performed, but also on how well these functions coordinate with each other, i.e. the quality of business processes interconnecting them.

Phase 1. Business processes awareness. The organization explores itself through the prism of business processes. End-to-end business processes are discovered and process owners are appointed. Everyone draw process diagrams. Gaps and bottlenecks are identified and eliminated, without investments into processes automation (BPMS).

Phase 2. Automated execution and control of business processes. The organization learns to manage business processes in a continuous loop model – execute – analyze and seeks to improve their effectiveness, mostly on a separate processes basis.

Phase 3. Execution and control of end-to end business processes. Process boundaries are expanded under the control of BPMS, inter-process communications are worked out and end-to-end processes are established connecting the company to its customers/partners and/or their business processes.

Phase 4. Explicit and automatic link between business goals and business processes. With the help of simulation and dynamic business rules, business goals changes trigger automatic rebuilding the network of business processes.

Phase 5. Adaptive business structure. The ability to quickly react to changing business environment, anticipate these changes and create opportunities through deeper integration into various markets and partner ecosystems.

I would offer a simpler set of maturity levels, which is what I proposed at Lombardi when I was still employed there:

0. Process Ignorance: No organized process per se
1. Process Awareness: Documented processes
2. Process Discipline: Processes both documented and consistently adhered to
3. Process Proficiency:  Processes implemented in software
4. Process Excellence: Ongoing investment in process improvement is cultural in the organization.

As Anatoly says, in Gartner’s 5 phases, phase 0, 4, and 5 aren’t really interesting for discussion in today’s business climate.  But he points out a key trap in pursuing process maturity the way Gartner envisions it:

The key words are “for all processes.” Trying to evenly raise the maturity of all processes is a recipe for disaster. In accordance with Pareto’s law, 20% of processes are responsible for 80% of the company’s performance. Wouldn’t it be wiser to focus on these 20%?

Sure the BPM-3 grants much more control over the processes than BPM-1. But it’s much more expensive as well! Complete BPMS implementation of an end-to-end business process is a custom IT development, apart from other considerations. And cheap custom IT development just doesn’t happen.

This isn’t just true for BPM – it is true for QA, for CMM, for all kinds of organizational and technical efforts.  Failure to apply the Pareto principle is to fall into the sins of either waste or overproduction (depending on how you look at it).  When we tackle even one process for an improvement and/or implementation effort, we try to focus in on the most important 20% – the changes that will really move the needle in terms of process performance, rather than expending our work equally across each stage of the process.

It is just hard to see how this news, courtesy of Steve Blank, could possibly be bad news:

Today, the National Science Foundation (NSF) – the $6.8-billion U.S. government agency that supports research in all the non-medical fields of science and engineering – is changing the startup landscape for scientists and engineers. The NSF has announced the Innovation Corps – a program to take the most promising research projects in American university laboratories and turn them into startups. It will train them with a process that embraces experimentation, learning, and discovery.

The NSF will fund 100 science and engineering research projects every year. Each team accepted into the program will receive $50,000.

I feel sure that some will nay-say.  But Steve Blank has documented on his blog how the government has fostered a startup ecosystem before in his Secret History of Silicon Valley series, and this has some of the same feel to it – but with the added impetus of a better way to wrap scientists and researchers brains around the concepts of startup formation.

As a process guy, I’m really impressed with how much the process of “starting up” has been improved upon in just the last decade – and Steve Blank and Eric Ries and others in the Lean Startup movement are behind much of it (too many contributors to name in one post – because it really is a collection of ideas from many people and companies). I’ll continue to follow along as it informs our own growth as a “startup” consulting firm, but also because there are interesting cross-pollination opportunities with the process improvement work we do.

Congrats to Steve Blank, the NSF, and everyone else who was part of making this I-Corps program come true.

XKCD often hits the target squarely, and they’ve done so again with this little gem that everyone in the BPM / BPMN space can appreciate:

Sure, maybe there were only 3-4 BPM standards going to 5 when BPMN was introduced… but now there’s BPMN 2… and one gets the feeling that there will be more!

But Gosling has a fantastic repartee that even more closely nails it:

Tell me the BPMN 2 specification doesn’t feel like that…!

There were several reports about BPM spending going into next year, mostly based on the Gartner report to that effect.  Much of the commentary around this report seemed to be to treat it with cynicism:

“I think this is the 10th anniversary of Gartner predicting hockey-stick growth in BPM. Sure to happen some day…” – Sandy Kemsley

Of course, part of the problem is that, if a market has CAGR (compounded annual growth rate) of 15% or more, EVERY year is going to look like the bend in the hockey stick when you plot it out on a linear graph.  And it appears that that is what we’re seeing in the BPM market today.

There are other interesting signs of a change afoot.  Lately, when I tell people what I do for a living in social settings, sometimes people actually know what BPM is.  Or they do when I start to explain it.  More surprising: sometimes they’re actually interested in it.  A few years ago I’d get looks like I was doing something incomprehensible or foreign.  So when gartner says “Spending on business process management (BPM) projects will increase significantly in 2011” I believe them.  Gartner considers 5% increase significant (54% of respondents) and 10% even more significant (20% of respondents).  That actually doesn’t sound like predicting hockey stick growth to me, but maybe the compounded charts into the future make it look that way.

I can relate to this somewhat just looking at the historical growth rate at BP3. We’re already having our best year yet in 2011, and setting up for an even better 2012 with the hiring we’re doing.  To anyone in the BPM services or product market, it anecdotally feels like a hockey stick growth curve.

Appian’s take:

The hockey stick growth that BPM analysts continue to predict year after year is achievable. But it will not come from the minority of people already focused on process. Neither will it come from incremental updates to old BPM paradigms or from the resolution of debates over BPMN minutiae, for examples. Exponential BPM growth will come through the majority and its rapid adoption of Mobile, Social and Cloud technology.

Well, no one was really talking about “exponential” growth were they? I think they were talking about 15% compounded growth, at most.  And while mobile and social may provide an exponential growth (for a time) in usage, they’re not likely to provide exponential growth in revenue, which is what Gartner is attempting to estimate.  Most users’ expectations is that these social apps are free.

(Appian goes on to mention that they’re hiring.  So are we!)

David Brakoniecki comments on the ACM discussion on LinkedIn:

Over on Linkedin, there is a spirited debate over several aspects of the Adaptive Case Management (ACM) movement going on.  The whole thread makes is worthwhile a read if you are trying to understand what exactly ACM is trying accomplish, how the community is organized and who some of big players are.

I commented on his blog but thought I’d repost here:

I saw this thread-  too bad it descended into something – how shall we say it-  not very professional.  I like the definition of DCM – it makes that particular definition much more apparent.  And I agree with you – almost every BPMS out there is also DCM.  I’m sure there are/were a few exceptions, but the surviving BPMS’ all have good rule systems to leverage (or can leverage external rules).

Now we’re just left with the muddy ACM definition.  I found it particularly amusing to see that people who have previously argued that BPM can’t succeed because we can’t agree on the definition, then turn around and argue that no definition of ACM is needed!

And I also find myself agreeing that I don’t see the technology issues with case management.  The differences that are communicated are at a really high level, unsubstantiated by an actual software artifact or code snippet or API (to give a few examples).  Philosophically the difference between basketball and “soccer” is quite large, but to a kid with a ball, it turns out he could play either one.  Actually, a kid could probably play either of these sports with any decent ball if he/she was motivated…

I’d recommend reading David’s summary more than the original thread, or at least stop reading the thread when it leaves off the constructive and starts to get a bit heated.

Shared with permission of Gary Samuelson, original post here.

The image is getting across the finish line in less-than-optimal conditions. As first-timer BPM projects go, let’s think of engine smoke and a hopeful driver.

I need to remind myself on this point: not everything lands in one piece when focused on winning. Vision is just about everything in this race. Parts wear out, pieces come unglued, bad stuff happens. There will be lots of failures along the way. As BPM does it most certainly will test your infrastructure – weakness points itself out by design and discoveries as painfully obvious as a flat tire and engine smoke… these will show themselves. There’s no avoiding weakness on a BPM project, or any project that touches so many different parts of the business and IT. It’s better to understand limitations both going into and during the race. These can be fixed. The end-goal however cannot be un-done. We either win or lose – never forget the vision. Winning may not be graceful but there’s always a thousand reasons and rationalities for losing. Stay focused, save the apologies, and stow the complaints. We’re in this race until it’s over.

Ironically the race is between “us” on big, enterprise BPM projects. We only need to cross the finish line to win!