The other day an old friend dropped me an email.  He wanted to talk.  The next day we got on the phone and and we spent some time catching up.  This is someone I’d been trying to hire for years, and he tells me he is leaving his current job and looking for his next job…

Him:  So before I go looking for another job, I want to find out more about what you guys are up to down there?

Me:  We’re putting the band back together.

Him:  Oh yeah?

Me:  (listing the people we’ve hired or put on contract)

Him: Wow, sounds like it!

Me:  You still got that trumpet?

Okay, I didn’t really say that last line.  When I mentioned the conversation to Lance, he quoted another famous line from Blues Brothers:  “We’re on a mission from God.” (picture deadpan delivery here).

So yeah.  We’re putting the band back together.  We’re finding people we’ve worked with over the last 5+ years that we really found rewarding to work with, but for various reasons moved on to other things or took a different path.  We have a new value proposition to offer them, some additional independence, and a chance to get onto really exciting wave building in BPM.  And we *are* on a mission from God (so to speak): spreading the BPM gospel is the mission and we’re dedicated to the cause, because we see the ROI.

On a related note… At Lombardi’s Driven 2008 we heard a lot of talk about “unicorns” and “heroes”.  There seemed to be a concern that BPM deployments relied too much upon these mythical “unicorns” that could understand the business processes (and the business people themselves), convert them into BPM Models that the business could understand AND that could be implemented in software, and then could implement those models in software of your choice… and then they could help you with systems engineering, architecture, database work, J2EE, Java, XSL, XML, Javascript, AJAX, etc.

And we heard about Heroes.  Those guys that can run a project, sling some code, mentor the team they’re working with, and deliver the project successfully. The implicit negative was that all this might happen in the absence of any adult supervision or structure.

The outcome of these two “problem statements” - not enough unicorns, not enough heroes, therefore, difficult to scale - was a hypothesis that the way to combat this problem was to refine the roles that people on BPM deployments play so that perhaps more people can participate in the process of building out processes.

We don’t fault anyone for embarking on this strategy.  It makes a certain amount of sense (especially when you’re trying to get quite large, and manage that growth).  However, its not what BP3 is about.  We’re putting the band back together.  We’re hiring those heroes, those unicorns.  Those people that have the capability, accountability, and discipline to do it all.  And we are hiring people that have the potential to be “heroes” or “unicorns”.  We believe we know how to foster the right kinds of experiences and growth opportunities.  We believe we can create the right culture, that leads to the development of these all-around players.  Partly we believe this because we’ve done it before, at more than one company.

And we believe when people pay for our services, they want the best, and they want experience.  Which is what they get - the most experienced team in the BPM business. We’re not interested in scale for scale’s sake.  We want organic growth and quality growth.  We’re putting the band back together.

Well, Lombardi’s Driven 2008 conferences is over.  We’ll be posting a few thoughts over the next few days, but we wanted to take a step back to digest what we saw, heard, and discussed.  While I fully expected great content and great networking and discussions, I hadn’t anticipated those discussions lasting quite so late into the night.  So we’ll be posting our observations a little delayed from the actual events!

Greg Harley is joining BP3 on Monday.  He’s had a long and some might say, glorious, career in the software business.  More recently, Greg has been doing some identity management work for Beacon, here in Austin.  Prior to that, Greg worked for more than 2 years at Lombardi, and was the anchor man on the LODA team at Lombardi.  Although I didn’t personally have the pleasure of hiring him at Lombardi, I did have the pleasure of having him on my team for over a year.  Greg is one of the best. And not just because of his outrageous Australian accent (Australian accent + too many years in Texas). Every team needs a Greg Harley on it.

Greg is unafraid of new technical challenges, and pioneered work at Lombardi that included making Teamworks compatible with single-sign-on technologies (all sorts of them, actually).  But he also understands the business of BPM:  ROI, Business Process, and Managing the process.  He joins us as the Senior Architect on our team, where he’ll be helping us develop our technical talent and team, and where he will likely shepherd some of our interesting technical assets into finished product.

Previously, Greg held technical and leadership positions at Vignette, Vector, and IBM.

Greg, welcome to the team, we sure are glad to have you-

Fahad Osmani, a colleague and friend over at Lombardi, wrote a good post today on the Lombardi Blog.  I put a comment over there but it is a moderated blog so it may take a while to show up.  The basic premise of the post is right here:

“But now, with a single successful process under your belt – what comes next?

This is where the challenges begin from an overall enterprise perspective. Word of the Pilot spreads. And unless there is a clear plan for scaling to this new demand (and there usually isn’t), this is where it becomes difficult to replicate your initial successes. And as a result, the overall enterprise BPM initiative can stall before it gets off the ground.”

I think Fahad captured the challenge exactly right, and goes on to suggest some good tactics for the implementation team to adopt to prepare themselves as best they can for the onslaught of demand.  All of a sudden pent-up demand for BPM software implementations will be released, and solutions that were previously planned for other technologies will seek to migrate to the BPM platform  for its additional business benefits.  But at BP3 we look at the solution to this problem through a different (complementary) lens:  that is, through the lens of business value rather than solving the technical/staffing hurdles.  So I would focus on the following as key issues:

1. Business Value decisions: How to decide which projects to work on. What is the compass for making this decision? And how do you communicate both the method and the decision to the people with demand? Too many times these “ROI” discussions are not fact-based, but gut-based. But there’s no reason to settle for that…
2. Policy/Governance decisions: Will you allow business units to staff their own projects and leverage the infrastructure already acquired? (or will you allow them to establish their own infrastructure?) Without doubt there will be some projects with sufficient ROI to proceed, but without sufficient skilled staffing to get it done in a given period of time.
3. How will you staff the ongoing projects? centralized team of experts, or decentralized team with some centralized standards and governance?

BP3 is in prime position to help with the first task:  establishing a method for picking projects, and helping you execute and explain the method to your company, users, business sponsors.  This is what some of the early stages of our BPM framework are for, for example.  And it helps to not just give projects a thumbs up or  down, but to explain what the criteria are and why the criteria are important to the business and why the project did or did not meet the criteria.  Sounds like a mouthful, but part of what you want to accomplish is a change in culture or a reinforcement of a culture that focuses on return on investment and fact-based decisioning and accountability.  Communicating the method behind the madness is a big part of that.

The second part is important too.  Governance over whether you allow various business groups to fund their own BPM projects with their own $$ is an interesting call to make.  If you allow it, you can devolve into a balkanized set of processes and priorities, and you run the risk of squeezing the balloon in one group, creating more work for another, and no netting the company a net-improvement in cost.  However, having people spend their OWN money on projects tends to have higher rate of return than when they spend someone else’s money on projects (basic human nature being what it is, people are more selective when it is their own budget).

Staffing is also crucial.  That central team can provide gravitas and competency that might be lacking in a broader roll-out with decentralized staffing.  However, we’ve all worked with companies with a centralized “integration” team (replace the word “integration” with the buzzword of your choice!), which turns out to be a team that is understaffed and oversubscribed to projects.  I’ve never met a DBA group, a SOA group, a doc management group, etc. that seemed to have lots of spare bandwidth.  Inevitably, in the effort to shrink hard-cost commitments, these centralized groups get starved for resources, except in the most exceptional of circumstances.  But the competency issue is important - if disparate teams will have access to the process development environment, there has to be some quality control and center of gravity, and some baseline of skills.  A good compromise is to share infrastructure, have a small team (even as small as one person) responsible for coordinating between development groups, and leverage expert consultants to augment the decentralized internal teams (or staff the decentralized teams).  When those business-sponsored projects wrap up, the consultants can go away and the process moves into maintenance mode.

We’re one week away from Lombardi’s Driven 2008. We’re looking forward to it for more than one reason this year. Of course we’re excited to see what Lombardi has cooking in the R&D labs, and we’re looking forward to reconnecting with old friends from Lombardi and our customer base, but we’re also looking forward to having our own team together in one place for the first time, so that we can all talk and look each other in the eye for a change!

One of the challenges of a professional services company is the distributed nature of the work. Even if everyone lives in one place, we’re likely to travel a lot. And if we live in different places, its even harder to stay connected. When I was building out the professional services technical team at Lombardi, we decided early on that we needed to hire people where our customers lived, rather than hiring them all in Austin. There is real value in being closer to customers, but also in being able to access a more diverse talent pool. I believe in this strategy of following the customer, and it served us well when I was at Lombardi, at a time when everyone else was just focused on lowest-cost-resource.

One thing we realized is that if you’re spending serious money on a BPM project, and you’re going to change core business processes, saving a few dollars by going with the cheapest available talent halfway around the world was not worth the risk of having a major project blow up. Spending the extra $ on the right kind of talent and experience is well worth it to reduce risk of failure, and likely to increase the overall ROI of the project… Its that old penny-wise pound-foolish saying, I think… At BP3, we’ve continued along those lines.  We’re going to build a team of really great practitioners and focus on quality over quantity, on depth over breadth, and we think the fruits of that strategy will bear over time.

We’ve updated our service offering. No, we’re not actually doing different things out there in the field, but we’re working toward explaining it better. We’ll continue to explain in a series of blog posts and updates to our content. We previously unveiled parts of our approach in Lance’s post about defining BPM, and in a previous post of mine about working on this framework on our whiteboard at the office.

It starts with the chart below:

The themes (or pillars) of our framework are Visibility, Control, and Performance. Horizontal bands give you the rough timeline, as well as high-level phase or activity description. The right hand columns inform us on the expected benefits and outputs from that phase. At the bottom of the chart, you can see the overall outcomes of the program. For Visibility: Increased Capability. For Control: Increased Repeatability and Reproducibility. And for Performance: A Breakthrough Benefit (rather than incremental).

To take an example… Across all three themes, if you are just getting started, you spend the first 1-2 weeks doing Process Definition. In the Visibility theme this means Value Stream Analysis. In the Control theme it means prioritization and selection. And in the Performance theme it means Process Charter. The benefit is a $ benefit identified and cost-avoidance of taking on projects that don’t have cost-benefit, and the key output is root and contributing cause identification.

Once we figure out which theme we either are focused on or should focus on, and we figure out how far down the pillar we’ve already traveled, we can give you a pretty good idea of what the typical ROI of that next step is, and we can give you a pretty good idea of what the typical ROI of that step is when you don’t execute the previous steps vs. when you do execute those previous steps.

Check out the revised services page here, where you’ll also find links to further detail on each of the three themes above.

Expect to hear more from us on the subject on this space. But by all means, feel free to reach out to us directly for more information. We’d love to hear from you.

Last year, OMG made some significant advances in specifications in BPM-related spaces. We now have a BPMN 1.1 spec, a beta of the BPDM (Business Process Definition Metamodel) spec for data representation of BPMN models, and two interesting business-oriented models, the BMM (Business Motivation Model), and the BPMM (Business Process Maturity Model).  We have a mix of both technical and business-oriented specifications for defining business process and improving business process.

OMG is now making public its OMG Expert Certification in BPM program (OCEB), and also published the list of 25 experts who helped put the certification exam together. BP3 Played a role in both the business and the technical aspects of the fundamental exam, and we are now writing questions for the Intermediate exams. This is probably a good time to thank OMG and specifically Jon Siegel for doing such a good job organizing this effort.

BP3 got involved with the OCEB effort (OMG Certified Expert in BPM) first, because BPM is our area of primary interest as professionals. But second, certifications prior to this one tended to be software-vendor-specific, the OCEB offered the opportunity to have a more comprehensive and collaborative examination of what it means to be fundamentally qualified as a BPM professional. We also have an interest in both perspectives of BPM - business and technical - and as a team we bring both types of expertise to the table, which we thought would be a healthy perspective to lend to the working group. In talking with Janelle Hill from Gartner last year she advised that the pool of professionals truly qualified and experienced with BPM is woefully thin, to expect that trend to worsen, and that by 2011 the industry will be in dire straights unless additional professionals come into the fold and earn their stripes. This comment certainly resonated with what we know is the current state of the union. I think OMG is doing a good thing here and I hope we see more practioners enter the fray. It’s good for all of us!