Someone had to do it, and I’m glad it was Theo Priestley, and not I!

Theo’s written up a summary of the Forrester-initiated BPM Jam on Twitter (thanks Connie!), and did a pretty good job of it.

Key points from his summary, where the idea that education needs to standardize (a la ABPMP), but also needs a more mature, comprehensive approach (a la Lombardi University). I missed this part of the discussion so I’m not sure how people felt about the OMG OCEB examination – of course, since that is a cert only, not a full educational curriculum, that may be why it was overlooked.

Another key point was the idea that a business architect requires 20 yrs of experience with Six Sigma, Lean, TQM under the belt.  As Theo put it:

I disagree somewhat on that point, whilst those methods are ‘nice to haves’ they shouldn’t be prerequisites of a Biz Arch and certainly not as steeped in the skills that they can’t accept outside influences. I’ve seen this among a lot of Master Black Belts and I don’t think they have what it takes to be a Biz Arch on this alone. Needs to be cross-skilled and understand architecture on a wider scale outside of process alone.

I think the key point Theo makes is that if you have adopted the religion of Six Sigma, or Lean or <fill-in-your-favorite-improvement-methodology>, you may be too inflexible to solve BPM problems in the most effective way.  A simple example I’ve seen of this is the Lean and Six Sigma ideal of ignoring technology while improving the process.  As with most doctrines, there is a kernel of a good idea there, but too often it is taken too far – to the point where many six sigma and Lean practitioners seem to be saying that technology can’t inform process improvement approaches – which any software engineer can disprove.  The real point of course is to not let technology slow down the process improvement, which is a very different thing altogether, and something I very much agree with.

Ok, its no secret that I love coffee and cafes with wireless.  But as I’ve said before, I think having an office is important.

But recently two authors have made the case much more eloquently than I have.  James Reinhart’s post, “Why your start-up needs to get out of Starbucks and into an office right now” makes a great case for why working at the local coffee house can be undermining your start-up.

He points out the main deficiencies:

• 75% productivity (this might be generous)
• Lack of space for whiteboards, etc.  The virtual tools don’t replace real stuff yet.
• Boundaries between work and play dissolve in an unhealthy way.
• It doesn’t save much money (office space is cheap).

I’d add to this:

• If you have to take professional calls, the coffee house, and the busy street outside, are *not* appropriate places to do so.  Neither is home, with the dog barking in the background.
• You can often sublet space cheaper than the market rate from another company that isn’t able to fully utilize their space yet.

So he’s given us the cost-benefit justifications… and that’s where the “Locker Room Theory” comes in, which captures the essence of how I feel about having an office.

Today, many people believe in the distributed model – many executive teams are spread all over the country (or globe) and connect only virtually.  Many start-ups believe in the model.  But David Dufresne’s reaction:

I’m sorry, but I don’t buy that at all. As far as I am concerned, business is all about people. Building a winning tech company is mostly about people and having a strong team dedicated to a strategy and executing it together. Being a hockey fan, I will use a hockey team as the analogy for a portfolio company. Being on the road is like being on the ice. That’s where you score goals. That’s where you win that big contract. That’s where you build momentum; grow a sales pipeline, forge partnerships, hurt your opponent, drop the gloves if needed, etc.

But, when players are not on the ice, they are in the locker room. The locker room is where it’s hot and where it stinks of hard work and empty cups of coffee. It’s where you regroup in between periods, look your teammates in the eyes, listen to your coach and team captain, get ice for that bloody bruise, adjust your strategy and tactics. It’s also where you celebrate after a game. Open that case of cold beers every Friday at 4PM. Get back to the whiteboard to figure out what went wrong on that goal against or sale lost to a competitor.

I think this is great insight, and if you don’t mind a hockey analogy, it works well.  In our business (business process management consulting), we can’t avoid being a distributed team.  But we do our best to make it feel closer (investing in videoconferencing, for example), and we very much believe in our investment in a headquarters so that when we are together, we can *really* be together and hash things out.

When people ask me why BP3 has office space, I don’t have trouble explaining why.

“I know how eggs are sucked.” – Theo Priestley, in reference to a vendor giving a 90-minute overview of BPM to someone who has been an expert in the space for years.

I personally prefer the “Teach me to suck eggs” formulation, but this one works quite well also. Theo’s blog is definitely refreshing in its candor!

Fascinating notes were taken at a talk Tim Cook gave earlier today, in which he explicitly laid out the fact that Apple benefited from its narrow product focus, a $40B company whose entire product portfolio could fit on a single table.

So given that focus, why invest in custom silicon?

“We felt that we had the best knowledge of what we wanted the silicon to do,” he said.

By designing its own silicon, he said, Apple can create chips that are best-suited for the company’s products, allowing them to run cooler and more power efficient.

“Apple has, for years, been in the silicon design business,” he said. “When we were on the PowerPC architecture, Apple always personally crafted the northbridge and southbridge chipset, and so it’s not new to us.”

In other words, even when it appears that they are straying from their focus, Apple’s management team has identified an opportunity to use their laser-focus to their advantage, upstream and downstream of the core product the consumer is buying.  (In my way of thinking, silicon is downstream, and retail would be “upstream” of the product itself)

Coincident to this talk, there was new data out showing that the iPhone’s unit shipments *and* market share grew more than any of its rivals in the smart phone space (and honestly, the research firms are being generous when they apply the “smart” label to some of the phones included).

And meanwhile, they’re getting some good news from their major US partner: AT&T.  A recent report from PCWorld shows that AT&T has dramatically improved the reliability and speed of its network.  Not that I can feel these improvements from a particular square block in downtown San Francisco (and the AT&T network gets its lowest scores in San Francisco!), but I’ll take the study at its word that on the whole these improvements are real.

Oh, and, happy birthday, Steve.

Theo Priestly on BPM Redux wrote about ArisAlign and its lack of “buzz”.  I’ve had similar feelings about Aris’ user experience, and the feeling that some of the enthusiasm espoused is a little forced – sort of trying to hard with the “I (heart) ArisBPM” pins, etc.

But the post reminded me of a theme that has been on my mind a lot over the last year: Design Matters in BPM. As if there was any doubt, I see more and more evidence that in the Second Decade of BPM, design will matter.  Not just a little bit.  I believe design will dictate whether BPM achieves ubiquity in the business. Design will dictate which tools will benefit from that ubiquity.

Apple serves as a good example of how much design matters in an industry that appeared to be commoditized (personal computing, cell phones).  Some might argue that BPM software isn’t commoditized yet, and therefore the focus might be on features/functions rather than “design”.  But I think the key elements of BPMS are, by enterprise software standards, fairly commoditized:  there are many players in the space, customers have a difficult time discerning the differences from a feature/function point of view, and ASP (Average Selling Price) is likely declining for most BPM vendors.  There are also a couple of open-source BPM software offerings on the make.

Combine the above with a trend toward putting BPM suites “in the cloud” and offering them in a SaaS model, and it really starts to look more like a utility.  But what takes it to the next level?  Here are some areas of BPM and my thoughts about how well they’ll differentiate vendors…

• Execution.  I think everyone agrees execution is nearly commoditized.  There are *real* differences at the execution level, but the market doesn’t recognize these differences in a way that channels dollars to the best execution engines.
  
• Simulation. Many of the vendors offer this.
• More modeling constructs? Already, vendors barely provide a fraction of the BPMN modeling capabilities defined in BPMN 2.0 (or even 1.0).  So, there’s an opportunity here, but fast-following will be pretty easy.
• Process Discovery? This holds some promise for differentiation in the short-to-medium term, in my view (there are only a few vendors who even claim this ability).
• Optimization? This has potential, but the current solutions simply don’t achieve it.  They work really well on small data sets and don’t (yet) let you efficiently do “optimization” on enterprise production data.  There’s a significant software investment to make here, and opportunity for differentiation.  Pair optimization with process discovery and you’ve got something really interesting…
  
• Modeling tools?  This is heading toward commodity rapidly.  Absent the advent of SaaS software I would have predicted an open source modeling tool would gain pre-eminence and get embedded in a lot of commercial products.
  
• SaaS / Cloud offering? There are already numerous choices and prices are heading toward standard increments.
  
• Community / Collaboration?  Outside of BPM, these are already fairly commoditized from a feature/function point of view.  Wikis, chats, Instant Messaging, Videochats, Communities – these features will not provide differentiation on their own.  In fact, vendors may rely on Wave or similar technologies to incorporate collaboration without making some of the IT investments that early adopters have had to make.
  
• “Dynamic” BPM or “Case Management”.  Call me crazy, but I remember CASE tools being all the rage in the mid-90′s.  I think unstructured, dynamic, and case management style processes are important, but I don’t think the technology required will offer differentiation to vendors for long from a feature/function point of view.  What they offer is a “better fit” to these use cases, but they’re not solving a problem that couldn’t be solved before.  (Note: Better fit matters, its why you should use BPM tooling to solve process problems rather than just slinging some Java or PHP code or hoisting a SOA stack into place)  To the extent that these “case management” tools are better, its a result of better design to suit the problem, not a case of out-featuring the other guys…
  

The opportunity for BPM vendors will be to produce differentiation based on the design of their products and offerings, by producing designs that engage the users, that elicit effective and efficient usage.  Collaboration, Unstructured BPM, Process Discovery, and Optimization all offer the biggest opportunities for differentiation by product design, in my opinion.

In closing, I should clarify that product design is not just skin deep.  Some make this mistake when they look at Apple Products and see only the outer shell.  Good product design goes much deeper than the UI, than the outer shell of the product.

Sandy Kemsley has a few good updates on these topics.

In the first, she releases a review on IBM’s BlueWorks online community for BPM.  Some of the interesting tidbits:

• IBM BlueWorks uses Flash.  Interestingly, Lombardi started with a flash interface (and it was a very slick prototype) and scrapped it for GWT/Ajax.  Why?  Because Flash was just not stable enough to support what they wanted to do (even in the early stages), and they could see that they were going to run out of “room to run” with Flash, whereas in GWT they felt the sky was the limit in terms of layout and functionality over time.  Quote from her blog: “The process designer is Flash-based, and it only took me about 5 minutes to crash it; luckily, it saved as I worked, so I didn’t lose any work.”
• She gives pretty good marks to the content they included, which might form the basis or significant contribution to a CoE.

Speaking of BPMN modelers in the cloud… Sandy followed up with a good post about why locating your hosting services in different locales matters (a lot) to customers.  Although I can point anecdotally to data points (companies) that don’t have an issue with the location of servers (unless it affects performance), I can also attest that quite a few customers in other geographies *do* have an issue with hosting location.

Hopefully as these services mature they can offer more options for their customers.  Certainly IBM has the global reach to put its cloud / community offerings in as many geographies as it needs to to be sufficient for its customers.

Great article from Jeff Jarvis advising companies with nonphysical goods to stop selling scarcity and start selling value. It is a principle that can be applied to a great many businesses, not just the “Web 2.0″ world, but as he points out, education and consulting as well.

His advise to advertising businesses: sell the outcome, don’t sell the scarcity of your space!In the Content world, he points out that content just isn’t scarce any more.  The existence of this blog is actually just one more data point to that effect!  Information is not scarce either – with Google at our fingertips. He goes on:

Thus we have performers and consultants. There is still value in unique performance. We will continue to buy tickets to concerts by stars (but we won’t pay for the Muzak covers of their songs on elevators). We will buy books. We will pay to sit in a movie theater with popcorn. The new competition in the case of media and performance isn’t that someone will make a good-enough version of what we do but that there is more call for the public’s attention.

Quality is a scarcity. But it is a real scarcity.

The challenge is, there has to be recognition that:

• You (your company, your product, your content, etc.) represent quality, and
• Your level of quality is discernably and valuably differentiated from other sources of similar product, content, expertise, etc.

In BPM, we’re suffering a scarcity of BPM-related skills.  We already have a general shortage of technical skills in the world, but on top of that, having the technical skills combined with the understanding of business and process improvement – we’re talking about a real scarcity for the right talent and skills.  But as I’ve argued previously, BPM isn’t hard because it is rocket science – each component task we do in BPM isn’t hard – its hard because knowing the right combination of tasks is a subjective, judgmental activity that depends on experience.

But the *real* scarcity isn’t the BPM bonafides.  The real scarcity is quality BPM skills and personnel.  Because what we’re selling isn’t truly our hours of labor.  What we’re truly selling is the outcome: a successful BPM deployment; a successful BPM program; or a successful transfer of skills and methods to a COE. My shorthand for this is that our customers are buying success.

One of the popular sessions at bpmCamp was a session on offshoring, from which we have a few notes preserved.  Steve Lang from Ford moderated the discussion, which by all accounts was a lively one.

Several of the teams in attendance pointed out that they already have distributed teams, geographically, within the United States.  So the teams are accustomed to conference calls, IM chats, etc.  The teams are largely effective at handing off work remotely as well.

The challenge of a lack of timezone overlap hurt some off-shoring efforts.  Also, a reliance on “hand-offs” (ie, throwing a spec over the wall and expecting to get back a finished deliverable) was not working well for BPM deliverables.  There was a big challenge around how to structure teams and deliverables to get maximum “yield” out of the combined onshore-offshore teams.  One participant pointed out that the problem of hand-offs not working was between roles in the same geography – not just between geographies.  And everyone had problems with attrition undercutting their efforts to onboard staff.  Interestingly there wasn’t much discussion of different locations for the offshore work – not sure if this is because almost all of these projects were considering off-shoring in India or if the geographic differences weren’t that interesting to get mentioned.

Some of the suggested ways to address the challenges:

• Extensive use of webcams, IM, and screen-sharing
• Don’t settle for “newbies” in the offshore team – press for the most experienced people you can get
• Don’t try to fix the scope for your BPM project – BPM scope needs to be flexible to do it right
• Use a tool (e.g. Rally) to improve tracking and transparency in an Agile project
• Eliminate barriers to communication (e.g. going through “proper channels”). People on the project should have access to communicate with anyone else on the project without asking permission. (Emphasis on collaboration)
• Increase time overlap for the onshore and offshore teams.
• Have onshore or offshore members visit opposite location to build relationships and come up to speed.

I’ll make another recommendation: use an offshore team that actually does this stuff for a living in their local geography.  There are many issues working against you when you offshore BPM work -but don’t let a lack of appreciation and experience with BPM be one of them. BPM projects are quite a bit different than the typical IT project, and the collaboration required between business and IT requires more nuance and communication than the typical project.

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.

BP3 is now registered on Google Maps.  Not a bad interface for registering the map location and business summary.  And its always good to be “on the map”!

Lance Gibbs gave a well-attended talk on moving from Plan-Driven to Value-Driven delivery at bpmCamp 2010 @ Stanford.  There are some great slides in this presentation, and the approach dovetails well with Lance’s ability to get people focused on what matters most to their project success.

It starts with realizing that requirements are estimated, and resources and time are fixed, which is inverted from the typical plan-driven approach.  There’s also a focus on “should” rather than “could.” In particular, slide 4 jumps out at me, as it spells out what you should value, for example:  working software over comprehensive documentation.  Amen!

The presentation is embedded here:

Had lots of feedback in favor of adding Disqus commenting system (here and in other blogs), specifically around threading, identity, and sharing.  For example, you can login using your Twitter id or openID etc.

So we finally bit the bullet and installed it.  Hope it helps keep the discussion going in our blog and makes it easy for everyone to post their opinions!

Great article by Keith Swenson explaining why large and complex organizations are difficult to model using “scientific management”.

I think Keith makes a couple of great points that are worth letting soak in:

• Complex systems are unpredictable
• Organizations that “Learn” can adapt when the environment becomes less predictable.
• If you divide your organization between brains and brawn, you are failing to reach your organization’s full potential.
• Learn from *near* mistakes – not just the *actual* mistakes.

Of his takeaways for BPM- my favorite is transparency:  people involved in the process need to understand the part they play and the context of the process if they are to help the organization learn and improve upon it.

Worth the read and there’s a good comment-stream as well.

On a tangent relating this to political science…

For very complex organizations, it may well be worth applying some theories from political science and international relations to your thought process. One of the most useful political science theories is “Realism” – the notion that nations act in their own best self-interest, in a rational and calculating way.  My first exposure to this was in Dr. Krasner’s course on International Politics.  Usually deviations from what appears to be self-interest can be explained by imperfect information or miscalculation – but in general realism probably most closely describes how most states will act at critical moments of international relations.  In large, complex organizations, it helps to assume that departments, teams, and divisions will apply a healthy dose of Realism to the way they behave.  Part of how you deal with overly complex systems is by having useful abstractions that give you a shortcut to understanding, not ALL of the minutiae of cause and effect, but rather the SUM TOTAL of these effects.  It is much like the difference between micro and macro economics. Realism does not deny the other effects, but it argues that they are secondary effects rather than the primary correlating explanation.

Interesting article in the MIT Sloan Review on “Where Process-Improvement Projects Go Wrong“.  It compares process improvement projects to the behavior of a metal spring, by dividing into three phases:

1. Stretching – at the beginning, a small team is motivated to succeed, and has support of executives.  A six sigma or process improvement coach helps them navigate some of the harder issues to make sure they stay on target and achieve early success, which causes additional initiatives to be kicked off.
2. Yielding – As the process improvement coach is removed, teams begin to revert back to prior behavior, or lose the ability to get the team objectively past some of the harder sticking points.  Executive attention, and perhaps some of the best team members, has moved to other projects.  Performance starts to retreat, though not necessarily to pre-improvement levels.
3. Failing – the vicious cycle begins “With the improvement expert long gone and no additional training in Six Sigma or other improvement strategies provided by the aerospace company, team members became increasingly discouraged by their failure to build on earlier success. They eventually stopped caring about the improvement project, partly because it wasn’t tied to their performance reviews.”

Well, I feel motivated, how about you? Luckily we are not springs, we’re people, and we can be a bit more creative about avoiding this inglorious “failing” phase than the author imagines.

The article author proposes 4 lessons learned from the many companies they studied for this report:

1. Keep the improvement expert around longer – or share this expert among more than one team to spread the cost – but the recommended term was 2 years, augmented by training managers to pick up these responsibilities.
2. Performance appraisals tied to improvement.
3. Keep teams small (less than 10).
4. Executives need to directly participate in the projects, not just receive reports from someone who has incentive to focus on only the good news.

This isn’t bad advice, it is good advice to start.  But it is insufficient and unlikely to cause organizations to suddenly get higher success rates with process improvement.

What did they miss?  Well, they missed BPM, is what they missed.  One of the reasons BPM is a “killer app” for process improvement is that when you discover the most effective changes to make for your process, you can put them into software, not just into a book of Standard Operating Procedures that your team will quickly forget about.  And your improvements aren’t just things that people on the team learn and practice, nor just things that they pass on to others on adjacent teams – they are things that get encoded into your process.  The software gives you:

• Some resistance to the “yielding” phenomenon described in the study results.
• Accurate measurement over time – no dependence on manual measurement techniques that may degrade as team members lose interest in the stop watch and other manual measurement techniques.
• The ability to “bake in” an improvement and move on to the next thing, rather than get stuck in a high-cost maintenance of the first improvement.
• A “control” baked into the software.  (Six Sigma has standard approach called DMAIC – define, measure, analyze, improve, control… and BPM software directly addresses D, M, and C, and supports the A and I activities…)  So often the “failing” phase is because the organization loses focus.  Software doesn’t lose focus – it just keeps running.

Too often, the proponents of Lean and Six Sigma ignore technology because they view it as an impediment, failing to understand that there is more to technology than MiniTab or SAS/SPSS or Excel.  And if technology allows you to do something at lower cost, such as a process improvement project, or maintaining an improvement over time, then it shouldn’t be dismissed out of hand.  But it is easy to understand why they sometimes see tech as an impediment – deploying software takes time – and during the initial phases of improvement the improvement guys just want to move fast.  My take is – don’t let the tech get in the way, but don’t pretend it can’t dramatically improve the efficiency of your business – in fact, technology, and specifically BPM software, is likely the key to locking in the gains you seek to establish a “new normal” that is a more efficient and effective process.

Or was that the other way around?

Prashant Gadgil gave a presentation at bpmCamp 2010 @ Stanford on this topic – because often business process problems are described as a process but require a full-fledged web application to properly address – or vice versa.  His talk focused on helping differentiate between the two – or to know when you are stepping outside the sweet spot of what a BPMS usually offers you.  Still, if you have a process, you don’t want to lose sight of it as you build out your web application’s functionality!

There was more ground covered in discussion but I don’t have notes from this session, so the slides will have to suffice! Prashant was generous enough to allow us to publish via slideshare (and they are also available to bpmCamp participants via the bpmCamp wiki site).

More to come from bpmCamp notes in the coming week…

I’m a big fan of Google.  And of the products that Google produces that I use (Gmail, Google Apps, Gtalk, Google search itself).  But lately some of the products from Google are reminding me more and more of Microsoft, which has me concerned:

1. Me-too product releases
2. VERY corporate-appropriate names for the products being released
3. Failure to embrace the world outside the ‘plex

Maybe I should explain what I mean in more detail…

Me-Too Product Releases

You might say everything Google has ever done is “me-too” – its not as if Search didn’t exist before Google came along.  Or email.  Or even web email.  Or instant messaging.  Or document editing in a web browser… the list goes on and on.

But the difference in (most of) these cases is that the field had become a bit moribund and was lacking innovation – leaving itself open to a new entrant.  Search seemed like a dead-end.  Web email was stagnant and sites like Yahoo! mail and Hotmail left a lot to be desired.  If there wasn’t a technological edge that Google could gain, then Google was able to exploit an economic edge (more storage for the “free” price, or free document editing on Google Apps instead of paying for MS Word).

But the space of real-time broadcasting and status updates and social graphs is hardly a field of stagnation.  Facebook and Twitter are robust companies at the top of their game for their respective niches.  Foursquare is up-and-coming (and several other firms like it). The problem here is that Google can’t out-innovate these companies in their core competency.  The fast-follow works better if you wait for the arteriosclerosis to set in with these firms – either due to the weight of technical debt they’ve taken on (client side apps, instant messaging), or due to the organizational heft and indecision (Yahoo?) or due to painting themselves into a corner with respect to revenue models (e.g. Microsoft).  The new firms have none of these problems.  They’re nimble, decisive, and have emerging revenue models with little to lose and much to disrupt. VERY corporate-appropriate names for the products being released

Corporate-Appropriate Names

Remember when Microsoft had a lock on this approach to naming applications? Now Google is doing it.  Latitude, Gmail, Gtalk, Buzz, Docs, Apps, etc.  And when they do come up with a “funky” name, it really doesn’t resonate (Orkut?).  Meanwhile, companies with lighthearted names are eating their lunch – Facebook, Foursquare, Yelp, Gowalla.

It just makes me wonder if the suits have taken over important naming-functions at the firm.  Sometimes the name of something affects how people perceive it – even internally.  And unfortunately, even when Google tries to be more whimsical these days, it comes off like they’re trying too hard.

Remember when Google was coming up with whimsical names like… “Google” ?

Failure to Embrace the World Outside the ‘Plex

Search gives Google an advantage in “embracing” the outside world in most of their applications – most noticeably in Google Maps (now there’s a product name with all the creativity of paint drying).  I’m not sure why Google didn’t just buy Twitter and get it over with. But, if Google’s not going to buy Twitter, another straightforward thing to do is embrace it by integrating Twitter functionality into Gmail – not copying Twitter, but leveraging Twitter’s API.  Show how integrating Twitter functionality into your email client could make both more useful.  Show how integrating search into the experience can also make them more powerful.

And then figure out how to slip Google’s own “real-time-update” infrastructure into the mix – perhaps by granting twitter users their identical @names on Google’s infrastructure – essentially adopting the useful conventions of the leading platform.  Don’t make people rebuild their social graph, let them port it over while retaining a separate identity from their email address (one of the beauties of Twitter, for example, is that it is (somewhat) resistant to spam because you only see messages from people you follow).

Well, Google has a lot of smart people – I’m sure they’ll figure out the strategy, but I was disappointed that they didn’t just improve my life by making it easier for me to Tweet (Twitter?) and Facebook.  I’m not the only one who thinks they might have missed the target.  The Business Insider describes Buzz as “Late, Boring, and Lame“.  And Twitter was not full of supportive comments today, e.g.:

cdixon : Prediction: Google’s Twitter killer will be lame. A few billion dollars later they buy Twitter.

cdixon : Besides being just generally bad at social, Google products seem to be suffering from a strategy tax a la MSFT.

I think Google should drop the product launches.  Apple is really good at them, and each product launch creates almost as much negative buzz in the aftermath as positive buzz (where’s my videocamera on the iPad!? who named it “iPad”? ).  If you do a mediocre or “okay” job with the product launches, its even worse.  I suggest they go back to releasing product the Googley way:  by putting it out there and letting people discover it.

Starbucks may be doing a lot right these days – they’re stock is up more than 100% from its lows, almost 200%.  But recently they rolled out a change at “my” Starbucks that is a step backwards.  I go to one of the highest volume-per-square-foot Starbucks in Austin, TX.  One of the reasons I go there, despite the fact that it is so busy, is that the staff is by far the most efficient in Austin – for the last 12 years they’ve been cranking through the line faster than any other store in the city, and remember all the regulars’ names and drinks along the way.

In fact, it wasn’t unusual for me to get to the cash register and my drink would be there waiting already made.  I always wondered what happens if I change my order!  But they knew I was a regular and what that meant.  And I got faster service for being that regular – something I might expect to get at a neighborhood cafe, but not at a big national chain.  The baristas there are my friends – I’ve seen them get married and have kids (and, they’ve noticed when I got married, and when I stopped on the way to the hospital after our kids were born, to get coffee after a long night).

But the other day, the wheels came off.

What happened?

It seemed like a little thing – and I’m sure the folks in HQ thought they knew what they were doing – rolling something out to this location that they do at lots of the high volume locations.  They started printing stickers for the cups instead of writing on them with a marker or grease pen.

Its the kind of automation that seems to make sense.  It might even make overall throughput slightly better, or error rate slightly lower.  But my observations follow:

1. They don’t ask my name anymore when I order.  I just order.  The new employees aren’t learning my name.  They aren’t my friends, and aren’t becoming so.  They also don’t know my drink, which is even worse.
2. My drink doesn’t get started until after I pay.  Sometimes the person making drinks is literally idle because the cashier has gotten behind.  The barista behind the espresso machine no longer jumps the line by making regulars’ drinks in advance.
3. I spend an extra 5 minutes in the store on average.  It is no longer a quick stop for me on the way to work – its an expensive distraction from getting started with my day.

So, I’m looking at buying an espresso machine for the office.  So, I bought a Nespresso machine for our office.  I won’t have to wait in line, and they won’t have to learn my name or my drink.  Or collect my money when I’m in Austin.

Besides just ranting about Starbucks, this is a bit of a cautionary tale – sometimes an “obvious” technology improvement or automation can actually slow things down because it robs the people involved in the process of the independent volition to make a difference – or to delight the customer.  The trick is to introduce tech that enhances that individual ability to execute rather than stifling it.  This is critical for BPM projects especially.  We can’t forget that for all too many of our processes, “delighting the customer” is still a goal.

Congratulations to Bryan Menell for landing an interview with Fast Company about Austin’s startup ecosystem, as well as the background contributors to Austin being a great place to start a company.

I’ll boil it down to what I think matters most:

1. Great quality of life.
2. Abundant educated workforce
3. Abundant housing
4. Access to funding
5. Great ecosystem to support entrepreneurs (especially first-timers) and startups

Great quality of life is in the eye of the beholder- some like Austin for the weather (and some hate it), some like Austin for the music (and some hate the noise), some like it because it is “Weird” (and some hate the weirdness), some like the abundant water recreation (and some people prefer dry land).  Some people even like UT sports events!  (And some really really don’t)  Almost everyone likes the food in Austin.

The point is, there’s something for everyone, and usually more than one something. I think the quality of life in Austin retains people who otherwise might move: when they get laid off, when they pursue another job opportunity, etc.  In fact many people return to Austin after flirting with the Bay Area or Boston.

Bryan’s list of startups only scratched the surface.  What I find interesting about Austin is the diversity of businesses that have been started: furniture,  groceries, consumer websites, enterprise software, chips, food and beverage firms, ad firms, music venues, ticket sales, music promoters, manufacturing, biotech, batteries, green building.  And I’m still just scratching the surface still.  I think you get this diversity in Austin because of the background support for entrepreneurship, and the willingness of the workforce in Austin to bet on startups and work in them. Well that, and because you can work at a startup and then play with your band at the Saxon Pub.

The first go-round on Process Debt got quite a few reads and private emails and comments that motivated me to keep thinking about his topic and how to further clarify process debt so that we can use this concept to help manage our process development efforts.  It also motivated me to run a small session at bpmCamp on Creating and Retiring Process Debt.

We had a good discussion during the presentation and lots of examples from recent history to draw on in this room.  A couple of folks from the same company were in the room and as a result they tell me that they now have a common, useful vocabulary for describing trade-off process decisions which are made *all* the time in BPM groups.

Presentation embedded here, but also some rough notes below for those who prefer reading text…

(Incidentally, I used a tool called “Prezi” for this which I find pretty useful for organizing thoughts about a topic that requires a lot of context or gets past a certain number of slides… Something about the spatial relationship of the elements helps maintain context in the discussion.)

First, let’s agree that there is such a thing as Technical Debt, as defined by smarter folks than I. But also, that we can repackage it just a bit to more closely align with Process terminology and concerns.

Why we incur Technical Debt (borrowing heavily from McConnell):

1. Time to market – we want to get our process built quickly so that we can start to reap the ROI quickly – and time is money.  If a process can save you $1M per month, each month of additional development effectively costs you $1M.  Time to market matters.
2. Preservation of budget (for startups, preservation of capital)- We have a limited budget, and we want to make sure we spend it on the things that give us the most leverage for getting ROI.  These are likely the same things that will help justify budget for additional improvements going forward.
3. Delaying development expense.  As a system nears end of life, it takes a very high degree of return to justify anything but expedient fixes -because when a system is retired, its technical debt no longer matters and isn’t paid within that system – it is being paid by whatever is replacing it.

What are the types of Technical Debt that we can be concerned with:

1. Unintentional Debt – debt incurred due to poor technical choices, but not with forethought.
2. Intentional Debt – debt incurred for strategic reasons, with explicit trade-offs.
   1. Short-term debt:  sacrifices made to get a specific release out by a certain date.
   2. Long-term debt:  typically architectural decisions (assuming only one database platform, for example) that can be good trade-offs measured in years.

And then we have “Product Design” debt – which I believe can occur in process projects where functionality is added over time until the originally simple screens have become cumbersome and unwieldy.  This isn’t quite the same as Process Debt – but process projects can become afflicted with it.

Finally, we have Process Debt itself.  I think we can follow on the Technical Debt framework and build on it:

1. Unintentional debt
   1. Process Shift – this happens when performance of the process degrades over time.
   2. Requirements Shift – this happens when the external realities change but your process fails to adjust adequately.
   3. Squeezing the balloon – the local process gets optimized at the (greater) expense of other parts of the organization (or customers or vendors)
2. Intentional debt
   1. Short-term trade-offs to get a release out – scope removed, etc.
   2. Experiments to find out which possible solution is the right one
   3. Manual work-arounds in place of system integration (SOA team can’t give you your webservice in time? will a manual work around work for the first few weeks or months?)
   4. Sub-optimal integrations (batch instead of real-time, etc. )
   5. Assumptions around geography or localization or product line support.

Tracking Debt:

1. Enter tasks into work tracking or defect tracking software to track both the items that need to be worked on and the effort required to retire the debt incurred.
2. Measure the process for squeeze-the-balloon effects (can be difficult if the other parts of the balloon are not measured).
3. Teach the team not to take short-cuts that “aren’t worth entering compensating tasks in the software tracking tool” – if they’re not worth it then the short cuts aren’t worth it either.
4. Another suggestion (from James Shore) is to measure Source Lines of Code (SLOC) as an approximation for technical debt. It isn’t an exact measure, but since lines of code will affect cost of maintenance, it is a reasonable proxy.

The starting point is that you have to have a system for tracking your work and work backlog – and from there you can mature the way you think about Process Debt based on what works for your organization.

As of February 1, BP3 is in new offices.  We’ve moved just a short distance from our old office on Balcones Drive in Austin, to our new office at Plaza 7000, at the intersection of Far West Blvd and MoPac Expressway.

We’re really happy to have the extra space, and our new co-working arrangement with Red Velvet Events.

Today, I unwrapped a little present for the new office that makes it feel like home to me, and that’s an espresso machine:

First latte at bp3 headquarters

Its a Nespresso Citiz, and yes, I’m expecting to be wide awake at the office from now on, and a little less cash will be going to Starbucks this year.