Gartner published an article about the lack of skills needed to implement Business Processes, as well as 11 steps to take to determine whether you should source your BPM projects internally or externally.

As an early colleague of mine used to like to say:  “The Genius of the And” (if I remember right, one of the principles from “Built To Last”).  Even if you have the internal skills to staff a BPM project, you’re likely to want to bring in a vendor-specific expert or an outside expert on process improvement for fresh perspective.  And if you’re a company that prefers to outsource these projects, you are going to benefit from seeding that external team with a well-informed person inside your own org, someone with a lot of institutional knowledge but also the confidence to buck conventional wisdom.  In other words, a little of both internal and external is probably the best of both worlds…

Regardless of what you decide, don’t lose sight of the importance of the partnership between business and IT on these projects.

Good article on SearchCIO.com last week. The first paragraph points out the challenges:  lack of internal resources, and internal politics.  The second paragraph brings up another: complexity.  Of course the article goes on to point out that the challenges are worth it, because the rewards are significant and measurable.

The points are a bit obvious:  BPM is “new” in IT circles, relative to other technologies in use.  It also is a bit “different” in that it isn’t just a new programming language (in fact, it *isn’t* a new programming language), but if done right, it requires a different way of doing things, in that some of the traditional boundaries between the business and the folks who write code for a living are broken down.  It also tends to require a little more agility from the integration specialists and database specialists than traditional application development efforts. The approach is closer to an Agile development approach than a traditional software development approach (although I’m not big on the particular religions of software development methodologies, Agile is at least a close proximity to the implementation style you want to adopt).

Finally, BPM isn’t something the kids are learning in college.  Hiring someone fresh out of school (graduate or undergraduate) isn’t how you jump-start your BPM expertise, as you might have previously jump-started your Java expertise or Ruby or Rails expertise.  With BPM, you might or might not use those technologies, but the skills and knowledge you need to have a handle on include:

• BPMN
• Process Mapping
• ROI
• Measurability
• Prioritization
• Abstraction
• Staging / Incremental Improvement
• Technical prowess for web services, thin or thick user interfaces, Java API’s, XML, Databases

The complexity of deploying BPM often comes from the cross-department, cross-functional nature of the projects.  The typical analogy is that the process is the elephant and each group within the process is like the blind man feeling their part of the elephant and trying to guess what the whole process looks like.  We have to get these constituents into the room and complete the picture.

The lack of internal staff with these skills or experiences is most likely because these kinds of cross-department and cross-function projects are rarely embarked on.  Most of the members of your IT and Business teams may not have worked on such a project (and their previous experience may have made them gun-shy).  That’s the time to pull in some outside experience- and if you can get both generalized experience with BPM projects, and specific-vendor experience, from the same outside firm, then so much the better.  You’ll be better served by firms that aren’t interested in backing up the bus and unloading a whole bunch of consultants, if you’re goal is to have a core competency in Business Process roll-outs, or BPM.  Instead, you’ll want to find firms that will augment your team, will reduce your risk, and will be available for the long-term, on your terms, to assist your process efforts.  In our experience, most companies start with one project, and then expand to two or three parallel projects in the next iteration.  So, even as internal staff are getting ramped up, the need to leverage outside expertise across those projects (risk mitigation) actually increases at that point, even while the percentage of outside help relative to internal resources actually declines as the internal expertise builds up.

If your organization is one that outsources non-core competencies, and BPM is not a core competency, then you can also work with a firm who will staff up as you need more work done, and stand down as your work winds down.  At BP3 we’re interested in business continuity contracts where we maintain a long-term relationship with our customers and help them through high- and low- tides both with initial development as well as ongoing maintenance and support.  Doubtless we’re not the only ones interested in providing this kind of white-glove service.

We just had our first internal videoconference between HQ and our Atlanta office.  Well, that’s how we like to refer to Flournoy when we’re not calling him BP3-East.  We made the decision to invest in Videoconferencing equipment because it is really important to have high fidelity communications both internally and with our customers.

When I was at Lombardi we built a distributed geographic technical team based on the belief that high-value, high-touch interactions with customers were crucial to building lasting customer relationships.  That’s a really hard thing to do right when you are starting from a base of 2 or 3 staff members, and don’t have the national network of people to draw on.

At BP3 we’re going to attack this in two ways.  First, we’ll hire geographically again, I have no doubt.  We have a better national network to tap into this time around, and some of our colleagues from Austin have moved to other cities, and might be able to help us find the right people.  Second, we’re going to invest in videoconferencing equipment.  We think it will enhance the quality of our offsite work with customers, and likely it will somewhat reduce the need for travel expenses.  It also sends a powerful message to our team that we’re interested in their quality of life and their ability to do good work remotely.

Videoconferencing still isn’t cheap (can’t wait til its under $1000/seat), but I was pleasantly surprised at how affordable it is compared to what it cost 10 years ago, for a better product.  And with the cost of travel increasing, videoconferencing looks more and more affordable by comparison.  Oh, sure, you can go the <insert favorite IM chat client> route, but the fidelity of such video connections is generally terrible, and certainly not good enough to show someone at a remote location what you’re drawing on your whiteboard.  We went with a Lifesize system.  Its high-def, the quality is fantastic (720p), and with remote control, the person on the other end can zoom into our whiteboard to see what you’re drawing.  Voice is included in the video/audio stream, so there’s no need to place a separate voice call.  And there’s no per-call charges because it all goes over IP (over your network).

We’ve been pleasantly surprised at how many of our customers have videoconferencing setups as well.  Often these are underutilized assets, but there’s no reason for that to be the case on our projects!

I want to thank good friend Megan Lueders for giving us a demo of the system and getting us to take this seriously.

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.

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.