I thought I’d share a few of my thoughts from two days at SXSW-interactive…

1. Austinites don’t really know escalator protocol.  We stand on both sides of the escalator, annoying the folks from both coasts who know that you stand to the right to let the impatient blow by you on the left.  The Austin Convention Center has some very long escalators, and the traffic jams have been beauteous.
2. People will not take the time to go to another floor to find shorter food and beverage lines.  Try the 4th floor first thing in the morning – its a morgue because everyone stops at the first “Starbucks served here” sign they see – which happens to be on the first floor.
3. Unlike my experiences at every other conference I’ve ever been to, SXSW (at the Austin Convention Center at least) had power supplies everywhere.  I swear I saw one above the urinal in the Men’s bathroom.  No, not really.  But they were almost everywhere else.
4. Do not screw up a bay-area coffee snob’s coffee order.  They will not be amused.  (I love coffee, but I don’t qualify as a snob because I actually like Starbucks just fine.  If you think people who like Starbucks coffee are coffee snobs, trust me, this is a finely layered cake and Starbucks is now where near the top of the coffee snob cake).
5. People who blog about comic strips can expect to see 1000 comments in a couple of days.  There aren’t 1000 comments in the whole BP3 blog yet.  Apparently BPM is only mainstream in the eyes of Gartner and Forrester – it is not mainstream in the eyes of comic-strip readers, or anyone else you could call “mainstream”.
6. Nearly every blogging-related panelist seemed to have started blogging when computers were built with vacuum tubes.  I jest, it was only 1997 or 1998… which amounts to the same thing as far as blogging goes.  Would have been good to hear from a successful blogger who started more recently…
7. A classic quote (missed the name for attribution): “In 2002, I thought [cynically], ‘hasn’t everyone who wanted to start a blog already started one? I mean, there are literally thousands of them.” Needless to say, as he pointed out, he vastly under-estimated the number of people who wanted to start their own blogs.
8. Fun quotes: “If you think Twitter is a good substitute for a blog you weren’t a good blogger to begin with”… “Huffpo could just be tweets”… “New generation of blogging sees it as furthering your existing self.  Whereas before, it was unearthing the self you were afraid to expose” (paraphrased)…
9. Do design and platform matter? The panel says, largely: no.  “Design is 5% important. Craigslist is popular and its the worst designed site on the web.”
10. There need to be about 10 more food trailers outside to satisfy the hunger of 15,000 attendees.  Seriously.  It turns out that Austin is not just ground-zero for Migas and Breakfast Tacos, but also for the food-in-an-airstream-trailer – even good food.
11. Going to Moonshine for a 1:30pm lunch was a good call. But it was a 45-minute wait.  Food trailer was also nearly a 45 minute wait. Guess which one was better?
12. There was a running joke about how to get a million page views on a blog post, but I won’t repeat it here.
13. Top ten lists were also cited as a key driver of traffic.  Why? No one knows for sure, but it works.  Check Digg, Reddit… etc… it always seems to work.   (I wonder if a top-29 list will work?? hmmmmmmmm let’s find out).
14. Apparently it is hard to make $50k/year blogging.  I’m not sure what “hard” means in the context of blogging, but everyone nodded their head (we know hard isn’t hard like mining coal, but does “hard” mean you need to be lucky or does “hard” mean it takes many many hours of investment without much assurance of return on that investment? or something else?)
15. A Google product manager talked about link quality like it was a moral good and not just something you worry about because you want your page rank to be good and you want Google search to drive traffic.  Kind of losing sight of the fact that getting paid for linking isn’t really amoral, it just inconveniences Google’s search quality – and then Google will punish you for having paid links that aren’t marked as such with no-follow (they literally used the term payola).  The example given was that you should turn down that $1000/month someone is offering you to link to their site.  The guy next to me said (sarcastically) “yeah, that’s a problem I have.”  Right.
16. Saw a panel about “unsexy” but profitable businesses.  Great representation from local firm, uShip, among others.  If Business Process Management (BPM) consulting doesn’t qualify for unsexy, someone explain to me the looks of desperate un-interest I can generate by telling people at SXSWi what I do for a living (BPM Consulting).  Hopefully this means we’re destined for profits as well.
17. There are too many stock photo sites in the world. But that’s good, because next time I need one they won’t be too expensive (I saw 4, at least, on the exhibit floor).  There are a LOT of tools for building websites (I saw 4, at least, on the exhibit floor). Couldn’t help but wonder if they were all partnered up with stock photo sites…
18. There are too many sessions! I can’t possibly see everything I’m interested in.  But I’m glad there are so many sessions because the small sessions are the real gems.
19. The Chevy Volt actually looked kinda cool.   Kinda.
20. There’s an under-served interest in well-designed physical products at the exhibit.  DAS keyboards and blue lounge where the two that I saw, and they looked great and had good attendance the two times I looked.  Everything else was a bit too virtual.
21. The AT&T U-verse store was, unsurprisingly, unable to tell me if they serve our neighborhood yet. On the other hand, AT&T the wireless carrier seemed to hold up pretty well the first two days of SXSW.
22. @paulcarr with British accent:  “The internet is a major distraction.  I recommend you all stop using it.” In the context of this audience, that was high humor.
23. It turns out, hashtags have to be shorter than 140 characters to be useful on Twitter.  Please take note of this, SXSW organizers…
24. Apparently: “if you’re goal isn’t to make money, you’re not actually in business”.  I like the way that panelist thinks.  If I remember right, that was also @paulcarr, of Techcrunch.
25. Sushi goes quite well with Tres Leches, thankyouverymuchialwaysthoughtso.  And this is why I love Austin.
26. Pedi-cabs in Austin cost more during SXSW than any other time of the year.  Why does Austin have so many pedi-cabs?  I don’t remember them being here when I first moved to Austin, but they’re everywhere downtown now.
27. Bijoy is everywhere.
28. SXSWi men’s fashion can be summed up as converse sneakers with tshirt and jeans and a sport coat.  Fedora optional.
29. No matter how many people are here, you can still bump into your friends, and make new friends. Good seeing everyone yesterday.  If you see me looking lost today, say hi and distract me from finding the next panel room.

I’m looking forward to the rest of the conference, its quite an experience.  Really impressed with the Austin representation.

In “Pick one and own it“, Jason Cohen advocates for picking just one advantage over your competition to sell, and really owning it.

Its a valuable debating technique to learn, regardless:  when confronted with an argument, instead of switching to a different argument, stick to the one at hand, and finish it out.  When you switch gears you’re often conceding ground, without arriving at consensus. It also prevents you from being intellectually lazy if you can’t just switch subjects when the discussion isn’t going your way or the way you expected.

It is also a good way to build your brand if you can focus on just a few key advantages, taking each one to logical conclusion, instead of overwhelming the message with 100 advantages that are difficult to prove or show.

The summary of an MIT Enterprise Forum’s gathering of 3 economists seemed to be optimistic, but with major caveats and concerns.  With three bubbles in our rear view mirror (dot.com, oil, and banking/real-estate), the concern has turned to a potential fourth bubble: cash (when there’s too much of it, inflation can eat away at it too quickly).

Here in Austin, a major new shopping center has opened (phase 2 of the Domain), and the tallest building in Austin is nearly complete (the Austonian, apparently the largest residential tower in Texas).  Meanwhile, Facebook is opening an office and hiring 200 people in Austin.  And co-working facilities seem to be doing well, while providing a good support network for small businesses. So perhaps the better-than-average local economy is influencing my optimistic outlook.

Meanwhile, the Senate has passed a $15B jobs bill. I don’t know if anything in the bill will affect our business directly, but we make our decisions without regard to tax effects (generally that seems like putting the cart before the horse), and from what we can see the environment is still favorable for BPM software and deployments – businesses are investing in process improvement, and BPM.  And big software companies are investing in BPM software (witness the acquisition activity of December and January).  Its a good time to be focused on BPM.

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.

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.

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…

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.

At bpmCamp we had a great session on BPM Requirements led by Zelda Durden.  Often the answer to the question “How much is enough?” is “I know it when I see it” – but we wanted to go deeper, and Zelda offered to help shape the discussion. How can we tee things up so that we know how much is enough as part of our requirements process?

She broke things up into two phases for consideration:

1. Exploring – no budget approved yet, no Project Manager either.
   1. Strategy – what needs to be improved from 50,000 feet, and what are the business priorities and goals.
   2. People – who and how much commitment from the business?
   3. Process- scope, SIPOC
   4. System – What is the current system?  Current state of the process?
   5. Discussion:
      • getting people commitments is difficult at this stage
      • using this information to help prioritize projects – along with ROI and other tools
      • scope management is difficult once users see what is possible.
2. Discovery – a real project is on the books, with budget.
   1. Strategy – Critical Success Factors (CSFs), ROI calculations if necessary, alignment with corporate objectives
   2. People – current skill set of process users versus new required skill set?  Change management: figure out the influential people and engage with them.
   3. Process – full process audit/investigation.
   4. System – plan for legacy systems, determine the extent of Teamworks (BPMS) in the solution.
3. Development Starts

First playback drives a lot of requirements changes.  Not planning for that level of change is just kidding yourself.

• Iterative development – iterations range from 3 weeks to quarterly – which keeps the lifespan of requirements to some reasonable level.
• Initial “onboarding” of process focussed on keeping it very simple (no integrations, or as few as possible) – get the process right first.
• Best process information comes from the end users – have to get in front of them and get feedback.
• Blueprint could be used for initial process modeling / analysis – but has the disadvantage of forcing you to consider licensing issues (unless you have a site license, etc. )
• Some people don’t get flowcharts: figure out the tools that work to communicate with them.  Draw on the whiteboard, for example.
• Teamworks as a process document repository (even for processes that are never intended to be TW apps).  While this isn’t the primary use of Teamworks, there was general support for this idea.
• “BPM Document” like a mini-BRD
• BRD still developed for interfaces / web services, etc
• Plan to develop process for project selection/kickoff

There was much more discussion than what we’ve captured here – but that is the nature of these things – you get into the conversation and you forget to take notes!  A few related thoughts come to mind for me, which I’ll share here.  Our CEO, Lance Gibbs, has some great common sense yardsticks that he often communicates to people on BPM projects who aren’t familiar with how to think of requirements:

• Does it affect ROI?
• Does it impact business objectives?
• Does it impact customer service?
• Does it impact throughput?
• Does it impact quality in a measurable way?

You can think of similar questions.  If a requirement doesn’t address any of these concerns, it should probably go in a secondary bucket to “come back to later” after you’ve first dealt with requirements that DO affect these criteria.

We applied a similar approach to documentation:

• Does it reduce work?
• Does it reduce waste?
• Does it reduce risk?
• Is it required for regulatory or other legal reasons?

It turns out we as an industry turn out a lot of doc that does none of these things.

More to come from bpmCamp 2010 @ Stanford…

bpmCamp's patio

Last week Stanford hosted the first “bpmCamp” for Lombardi Teamworks and Blueprint practitioners.  By all accounts the event was a success – sold out at 40 participants – and with some truly great interactive sessions and discussion that is hard to have at a bigger forum.  Our Stanford hosts did a wonderful job hosting, including all of the little details like name badges and maps, but also helping organize logistics around lodging, transportation, parking, and providing an excellent facility in which to have our meetings.  Encina Commons is one of the older buildings at Stanford – sandstone and arches and wide covered patios, surrounded by lots of green – a perfect atmosphere for sharing.  We were lucky to get a reprieve from the rain for 2 days so that we could really enjoy the surroundings (and make the occasional trip for espresso).  Thank you to Lombardi, and Apex (and bp3) for sponsoring the dinner on Thursday night at Pampas – an all-you-can-eat Brazilian feast.

The lawn outside Encina Commons / bpmCamp

And thanks most of all to everyone who came and led a session, contributed their opinions, reached out to their colleagues and made new friends and contacts.  What a great experience.

We’ll follow-up with a series of blog posts based on bpmCamp to share some of the content with a chance to step back and editorialize a bit. The biggest takeaway that I had was that the community needed an event like this to step out of the daily grind of delivering processes and process improvement – to see what others are doing, to see the forest for the trees.  Sessions ranged in size from 5 people to 40, and discussions were often lively…

bpmCamp in Session

Meanwhile, we’ll start with a short session from Friday morning, when we had a cameo appearance from Phil Gilbert, giving his impressions of the acquisition and the plans for Lombardi products for the next 6 months.  There’s a clear focus on proving that they can deliver and innovate “even faster” after the acquisition, as Phil put it.  And they have set themselves some very high, but relevant goals.  In particular, making it as easy to install Teamworks on Websphere as it is to install Teamworks on JBoss today (cur

Phil Gilbert holds forth @ bpmCamp

rently JBoss is your option if you want an embedded appserver), and making upgrades to Teamworks 7 a truly good experience.  The goal is to bring the ease of use of Teamworks to IBM’s customers, and to leverage key IBM technologies but expose them in ways that let you cut through the noise and focus on delivery. It was a motivating message for our bpmCamp crowd because clearly Phil’s attention is still on the BPM game, and this prioritization will keep Teamworks relevant for the audience.  Knowing the developers that IBM/Lombardi are putting on this project and upgrade paths, I also know that this is a crack team of some of the best engineers at Lombardi, which says something about the commitment from the executive team.

Someone in the audience noted afterward that this was a more tactical set of goals than they expected to hear from Phil- who usually talks in terms such as “the Second Decade of BPM“… but if the focus on the tactical reveals that they believe the tactical may BE the strategic right now, I think its a welcome shift-  because truly, what’s holding people back from BPM is not the knowledge that it has value – the press and blogs are full of information on that score – but rather, its the “getting started” effort required that slows things down.  The easier a software company can make the transition from “business problem conceived” to “BPM project underway” the more likely it is that BPM software is applied to that problem instead of sticky notes and a change order on an ERP system scheduled for 2 years out.

There were so many more great sessions to report on, so there will be more posts here about the sessions.  One thing anyone reading this can do for me that will help – is let us know if you’d be interested in attending a future bpmCamp, and if you would travel to attend, or if not, where you’re located so we can judge where we have critical mass for another event.

Thanks again to everyone who participated, and watch this space for more information!

Also, lest you think that BPM was the only educational opportunity at Stanford last week, I stopped by the Cantor Museum for Visual Arts and took a few photos of Rodin sculptures – the collection is the second largest in the world and nearly every piece was on display:

the infamous "Gates of Hell"

Lest there be any doubt that BPM skills are in demand, Tom Baeyens has pointed out that SimplyHired stats claims the average jBPM salary in CA is US$114,000.  Not bad.  Lombardi BPM shows similar numbers.  It supports what we’ve been saying all along – BPM skills are in demand, and it should be a great career for the next decade (or two, or more).  Its just hard to see “process” going away as an important concept in business. So what the SimplyHired stats tell us is that the technical side of BPM is in demand – regardless of the tool set, there is a mismatch between supply and demand right now that is going to take time to fill – and knowing the technical side of the coin is only half of it – the other half being the business process side of things.  I can tell you from experience that not all great technical people have an interest in business process, and not all of them can make the adjustment to focusing on the process over the technology.

In the meantime, your best bet to get up to speed is to get a job that will let you learn on the job, attend training, etc.  There really aren’t any formal education programs at universities that are widely recognized (although there are a small number of universities that have a small number of opportunities to learn about business processes).  There are classes you can take from the software vendors or the likes of Bruce Silver, and there are certification programs-  but no sense paying for certification until you know what you’re doing.  Once you get started, then try to take advantage of the many resources on the net, and resources like bpmCamp.

I’m excited about the topics taking shape for bpmCamp this week, and I’m going to send out a few teasers before the event starts on Thursday morning.  We’ll do our best to capture as much as we can and share insights with readers of this blog as bpmCamp happens, so keep an eye on this space or bookmark the bpmCamp tag.

Some of the sessions we’re looking forward to:

1. Phil Gilbert is going to stop in to discuss the acquisition by IBM and take questions from customers.
2. We’ll have a few members of the Lombardi product team in attendance to give us some insights into Teamworks 7’s operations, and upgrading to Teamworks 7.
3. We’ll talk about what “Fixed Effort” means as a way to focus on delivering value.
4. A case study discussion of an application of Agile to a project.

There are 20 other topics on the potential list, more to come tomorrow…

MWD Advisors has a post up regarding Running IT as a Business. As they put it, the main objections to this idea seem to be “daft” – that they depend on assuming that IT will run this business in the worst-possible “order-taker” fashion.

As MWD points out, there’s no requirement that IT run their business badly!  However, I will say I can identify with the skepticism that IT can be run like a business, because although “running X like a business” doesn’t have to be interpreted in the most simplistic order-taking terms, I’d be dishonest if I said I hadn’t seen just that happen.  All too often that over-simplification is what the company executives seem to think they want.

So, I think what we have here is a difference between what it should mean to run IT more like a business, and the reality of what people have confronted in their work life.  I think everyone would agree that when IT takes too myopic a view of their role in the success of the business, it is detrimental to everyone.  And if IT provides more business value… that’s good for everyone.

Where IT and Business meet is something that we have had a lot of experience with at BP3 because we’re involved in BPM projects.  You can’t do BPM projects without bridging the gap between IT and Business, and in our experience, the closer aligned IT can get with the business, the better.

I couldn’t agree more with Fabrice Grinda’s post on Why you Need a Partner.  Perhaps I’m biased, since BP3 started with two co-founders.  But I also have a lot of friends who own their own business.  And I’ve worked for people who own their own business.  And it just is true that very few people can be good at everything they need to be good at to run these businesses well.  If their business makes enough money, they can hire the help they need to run their business.  But early in a company’s life, it is really useful to have people on your team who ACT like owners (whether or not they are).

Finding the right partner can be problematic – but my recommendation is to try.  Find someone who is different, but make sure that you appreciate and value the differences, rather than finding them annoying.  And make sure the reverse is also true.  This should be someone you would want to partner with no matter what the startup idea was – not just because this person makes sense for this one idea.

And if the partnership isn’t working, exit stage left and try again- but don’t make each other miserable.  Life is too short to get stuck in an unhealthy business relationship.  Make sure you have a fair separation agreement in place from the moment you form your business.

bpmCamp 2010 @ Stanford has sold out!  The waiting list is open, however, and we’ll evaluate additional attendees on a first-come-first-serve basis if we get any cancellations.

We’re looking forward to seeing 40 participants from at least 11 companies, plus independent practitioners.  Topics of discussion will likely include:

• Teamworks 7 and upgrading
• Scaling Teamworks 7
• “Process Debt” and BPM programs – creating and removing process debt
• Delivery Challenges: Moving to BPM Software Delivery (Value Driven) from a Waterfall experience base (Plan Driven)
• BPM Requirements Analysis – How much is enough?
• UI frameworks with Teamworks
• Teamworks and Rules
• Teamworks and Systems of Record
• A/B testing and BPM
• Myriad additional technical and project and process-improvement topics

We’ll continue to revise the agenda topics and schedule as we approach the first day of the conference – and we’ll continue to accommodate new ideas even during the conference.  Look for more on the conference as it approaches, and afterward we’ll share some of our impressions and nuggets of wisdom that we’re able to glean.

Man. Steve Blank writes some great stuff.  Makes me wish I had gone to epiphany back in the 90’s!  He explains that if you’re going to go work for someone, make sure they have big plans, plans to grow the enterprise – because that growth is what you will benefit as a member of the team.

I thought his IMVU example was pretty interesting.  He mentions Will Harvey and Eric Ries (of Lean Startup fame) as being cofounders who wanted to swing for the fences and turned down buyout offers.  So, being me, I click on the link for Will Harvey – and I see he is at “Finale | Fireworks” along with Chris Hondl.  What a blast from the past.  Will was the TA of a Motorola 68040 assembly language class when I was in college (Stanford CS 110 if I recall) and Chris was the star student in the class.  We had a “robot simulation” game where we programmed the strategy for a robot to interact in a maze.  Mine was one of the four finalists, but Chris’ was a class above the rest in terms of the elegance of design and economy of action. Chris went to work with Will at Sandcastle, and most of us in class were fairly in awe of Will for his chops as the writer of music software for the Mac.

There are times when you realize it is a small world.

At bp3, we’re building a business process company, just like the tag line says, making no little plans.

Good article by John Reynolds on the age-old question:  is Programming Hard?  We’ve often argued that BPM suites make implementing processes easier by giving the business and technical participants in process implementation a common language for discussing the process.  It doesn’t mean that BPMN is ideal for either party, it just means that it helps bridge the gap in communications between them.

Another key concept is to understand the fundamental entities that the process is interacting with, and to model their lifecycles and attributes, from a business perspective. Modeling both can lead to a fuller understanding of the process problem.

John sums up the point pretty well:

That’s the key to making “business” programming easier… Build more tools that help programmers and their clients “make their maps” and build more software engines that “follow those maps”.  This isn’t a new idea – software modeling tools have been around for decades, but they’ve often lost their way and focused on modeling the software engineering aspects rather than the business requirement aspects of the problem.

That’s the key – because these tools have to be built by software engineers, they often turn introspective and lose sight of the end goal of being more inclusive – because by facilitating communication and consensus on requirements, we’re facilitating “easier” software development…

The first day (or two) of 2010.  While some say that this marks the beginning of the Second Decade of BPM, others are proclaiming the Death of BPM.  For those of us at BP3, we remain optimistic about this “second decade” of BPM, and we’re optimistic about what BPM can do for companies across a broad spectrum of sizes and industries, as you can see from our blog and our comments on other blogs and sites.

2009 was a tough year for the economy, and for many of our friends and colleagues across a number of industries.  We entered 2009 with a lot of uncertainty, but also with some very good customer relationships, and some very good opportunities in front of us. And finally, we can see real signs in the statistics that our economy is mending slowly.

I’m happy to say that despite these challenges 2009 was our best year yet – growing by 60% and adding a couple of skilled and dedicated members to our staff in the process. 2009 was full of interesting announcements in BPM – not least of which was IBM’s acquisition of Lombardi in December.

We had some great customer successes in 2009 and forged some new relationships that we’re really excited about continuing in 2010.  And we’ve assembled a team we’re very proud of, and grateful for.

We also placed in Gartner’s “Who’s Who in BPM Services” report,  which reinforces our hard work and thought leadership in the BPM space and puts us on a short list of services providers.  More to come on this announcement in another blog entry.

And we stayed so busy in 2009 we barely had time to come up for air.

As happy as we are with how 2009 turned out, we’re looking forward to 2010 even more:

• We have bpmCamp at Stanford to look forward to – a chance to reconnect with colleagues who implement BPM solutions for all kinds of different processes.
• We have some really interesting ideas to pursue this year in terms of running large BPM programs, and managing key concepts for BPM initiatives.
• We’re looking to grow our business again in 2010.  Although growth in and of itself is not necessarily the goal, we see opportunities to grow in a healthy, organic way based on the business opportunities for 2010 – and we can still see a real shortage of BPM skills and experience in the market place.  BP3 is going go to be a go-to vendor to get both – and we’re going to be a great place to work if you have both skills and experience.
• We’re moving our HQ to new offices in Austin in 2010.  It will be a better working environment and a place we’ll be proud to call home, while still respecting our lean cost structure.

Of course, mostly we’re hoping to do well by our customers in 2010, and in so doing, do well by our team.  Happy New Year to all of you!  May 2010 bring in the next decade with health, happiness, and success.