In this post I am going to pick up where we left off on the topic of measurement (Measurable benefit in BPM. Where is it? Part I). So let’s just dive in. Notwithstanding the reasons for not capturing baseline measurements in a process to begin to understand its current capability, here is the punchline if it isn’t done. When it comes to turning dials and flipping switches with the aspirations of making things better in a business process, without understanding the range of said dials, or the effect of flipping certain switches, you cannot possibly understand what will actually provide the highest yield and what won’t in process improvement. Take Dr. Bruce Banner for instance, he turned a knob too. He didn’t know the real range and things didn’t work out so well (i.e. overdose of gamma radiation and voila! a hulking, destruction toting beast emerged). I have seen this with process improvements many times. A “new” process is put in place and all of a sudden people either (a) don’t see any real difference or, (b) things actually get worse.

What are the basic metrics needed? There are five, with a “really nice to have” sixth metric. With these few metrics you can learn a great deal about a process, and don’t sweat how accurate or precise they are up front. That is something through additional work you figure out but getting even rough numbers up front are enough to get some real progress going. With emphasis- having these with a 95% or better confidence level is not a pre-condition to move on. Here is the definition of the 6:

1) Cycle Time - what is the mean or median total time for an activity, or step in a process to be executed? could be data entry, call handle time, etc.

2) Lead Time - What is the total mean or median time, defined by the process owner or company, that is required to meet the customer demand? The term backlog comes to mind, and the motivation for companies having SLA’s for their vendors (or customers). This is the fundamental measurement of your commitment to deliver to a customer (or the commitment you expect as a customer).

3) Throughput Time - What is the total mean or median time from the absolute beginning to the absolute end of a process. The summation of Cycle Times. Key metric to use for the notion of continuous improvement.

4) “Nice to Have” Takt Time- The time the customer expects a given process output to be delivered to them.

5) Work In Progress (WIP) - This is the volume of transactions or widgets in a process. An invoice, A report, a car, whatever it is your process is built to deliver.

6) Number of Operators - Number of process consumers participating in the process to create and deliver the good or service. Claim Specialists, HR Specialists, etc.

With these few metrics you can start to get a picture of how the process performs. There are other metrics like good versus bad process outputs (such as number of defects, think bad invoices, bad orders, etc) but up front these will really get things moving along. For instance, you will see as you look horizontally what steps quite possibly should be left alone versus the one or two that you need to remediate to promote flow. Processes which execute faster have few defects by and large. So how do I start getting these?

Value Stream Mapping is almost always the defacto starting point to then bridge metrics against processes and their activities. Let’s look at an example, this does not use standard Lean notation. This VSM was made with Lombardi’s Blueprint product. What is important is not the iconography but rather being able to see the big picture and relative detail in one view.

Here you can see the value stream representing the core end-to-end process with a target of completing the process in 72 hours. It shows the highest level (1) and goes to the next level down. This is the equivalent of using sticky notes. I could add meta information behind the scenes describing problems in each of these process areas, but what it doesn’t tell me is where am I going to get the biggest bang in terms of improvement. Now let’s look at the same image with the basic metrics assigned:

Now, with the metrics associated I can get a much better understanding of where to focus. If the target is to deliver the tickets to the customer in 72 hours, but we can see that our Throughput Time is 162 hours, where do we need to focus? Conventional thinking is we should improve each area and that the sum total of improvements will make everything better. However, that is not in fact how it works. We will just waste scarce resources doing that. If we drop the listing process from 2 hrs to 1 hr it is equivalent of a rock in the Grand Canyon. We need to get yield! So look at the Order Fullfillment, if we drop it from CT 120 hrs/LT 40 hrs to something similar to the others, we just created a ton of velocity. With these metrics attached, and with the process decomposition we were able to channel those scarce resources to the weakest link in the chain- Order Fullfillment. As a result, if we carve off 100 cumulative hours and reduce the lead time coming in to this process area we are much closer, if not dead-on, to hitting the takt time of 72 hours.

Could we have improved those other areas? Sure and it’s most likely without these basic metrics we would have tackeled them (possibly at a great expense). Being intellectually incurious about basic data is a key driver behind failing to move the needle in the business; just flat missing the mark because project selection was poorly executed.

Again, its not critical to be dead-on accurate up front, there are techniques to help shore up what measurement variation is really doing to the overall management of the process. The point is understanding that processes have multiple dimensions to it. The picture is just one important part of it. You need the metrics to help focus in on what will make a meaningful difference, and the obvious ROI.

Hope this helps, if you have questions or feedback, please leave a comment or catch me at lgibbs@bp-3.com

I find it ironic that it’s often the IT department that pushes for and obtains a BPM solution. Again, it’s the IT department that spawns the first BPM evangelists in the enterprise and sets out to internalize and deploy BPM solutions; all with the hope that their business counterparts will “get it” and run with the benefits of process management and become true participants and later owners of the solutions. Yet, all too often, it’s the IT department that then slides into their familiar role as software developers and begins writing software instead of managing processes. They may deploy one or two quick process solutions and then comes the project or program that begins to derail the vision; the process centric vision that is.

The project starts, you know, the one that’s larger than it should be, a seemingly invisible scope boundary, involves business units that don’t even know their included; yeah, that one. The group meetings start with good intentions, the process is kept in the middle for a while. But then, the conversations about how the interface looks, how fast will it run, what kind of system integrations are “we” going to pull off, begin. And suddenly, everyone loses focus of the business process. Suddenly, the “IT guys/gals” are writing software and the business analysts are trying to keep up with the requirements. The group meetings including the business sponsors give way to technical meetings with whiteboard discussions about how the BPM tool will be bent, prodded and tapped into to accomplish the “tricks” at hand. At the end of the day (month, year) you’re left with perhaps a slick solution; but where’s the process? Is there a useful process artifact for which the business sponsors can consume? Is the business unit ready to assume ownership and ongoing evaluation of the business process solution delivered? What about real process metrics, no, not the custom reports that were glued together on top of the custom database wired into the solution; but the real process metrics that could/should be gleaned from an adequate process model? These are the things that get lost when the process discipline and process centric visions are abandoned.

What to do?

If I had all the answers I suppose I’d write a book instead of this blog, but I do think we can start with the Project Manager role. This role is usually rooted in or reports to the IT department. As such, they’re often more focused on time lines, budget, and meeting requirements. Understandably so, but if this role were also responsible for an effective transition of ownership to the business sponsors/process owners, perhaps we could take some measures to keep the process centric view intact.

From the start of the project, the business sponsors should be accountable for delivering a series of statements regarding the metrics they wish to obtain from the proposed solution. In addition, they should be required to agree upon the manner in which the solution will be deemed a success or failure; this often tied to the metrics acquired. The Project Manager should keep this “project contract” or “decree” if you will in focus at each meeting. When scope is concerned, if the item in question does not lend itself in support of the metrics and measurement for success, then it should not be considered (at least for the first release, table suggestions and “sugar coating” for subsequent releases) . After all, an important goal of BPM is to deliver timely solutions with an opportunity for rapid change; that too must not be lost in the vision.

Many project teams are conducting routine “play backs” with their sponsors, but all too often these merely include screen shots or execution of interface screens and/or reports. Again, the process should run front and center. The process owners should know exactly what their process looks like before it’s delivered. They should be acutely aware of the swim lanes that exist, the roles associated with each, the activity steps defined. These are the things process owners manage, not an interface screen.

Upon delivery, the Project Manager should conduct routine meetings with the process owners and hold them accountable for the metrics they stated were necessary. The same measurements for success should be evaluated again and again. The Project Manager must evaluate his/her own success against the process owner’s ability to own the process, to understand the process, to measure the process, and ultimately to be empowered to improve upon the process.

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’ve been a going concern at BP3 since May 2007.  But it doesn’t seem that long ago that I was part of a much larger organization.  I almost forgot how fast a small team can achieve alignment.  In larger organizations, you accept that you have to say the same thing many times before it sinks in as “policy” rather than opinion.  You spend a lot of time bringing people along with your way of thinking, giving them an opportunity to reflect back to you, provide input into the process.

Sometimes it is great to be part of a small team.  A single email rallies the troops to action.  Everyone is on board with the goals, and providing valuable inputs toward those goals.  One of the things I felt was most important at my last stop was setting out an operating philosophy for our team, and a “compass”.  The compass tells you where “North” is so that you can make decisions in relation to how close they keep the compass aligned with North.  When a company makes every decision as a one-off exception, and hopes that the team will infer the philosophy from those collective decisions, the company is taking a huge bet that won’t pay off.  Spell out the philosophy.  Give them a thumb-rule or compass for making tough decisions. Give them visibility to how you apply the philosophy and compass to your own decisions.  And then watch your team apply the philosophy and compass to their own, providing some coaching along the way.  It isn’t that different from teaching, when you get right down to it.  I’ve seen some pretty senior leaders (in multiple organizations) exhibit some excellent crisis management skills, or customer management skills, and yet fail to communicate the principles behind their behavior to their team.  As a result, those decisions keep going back to those leaders to make, instead of being made closer to where the action is.  This creates bottlenecks in the organization, and it can inhibit growth of the organization in terms of size…

You can’t leave a healthy culture behind unless you invest in this kind of team and grass-roots self-reliance.  One of the Navy Seals sayings is to “equip the man” rather than to “man the equipment” and I think that’s a guiding principle for running teams of any size. We’re working to impart our organizational philosophy to our team, as well as other tools, such as six sigma, process mapping, value stream, etc.  These are alignment-aiding tools that our team can put to work to guide their own efforts without needing to check in with “management”.  Further, I think this philosophy can be pushed to process implementations.  Don’t look at the process as equipment to be manned by operators.  Look at it as a tool to equip your process operators to do their job more efficiently and more effectively.  The change in perspective can open our eyes to great process improvement opportunities that we’ll otherwise miss.

After watching the market gyrate a bit over the last weeks, months… year?… and as a business owner, I get a lot of questions from friends about how the economy is affecting our business, or our customers.  I’d be lying if I said there was no effect.  Clearly, some of our customers are making tough business decisions, altering forecasts, and making plans to deal with a tougher financial environment.

But I’ve noticed something else.  The pace of process innovation and change hasn’t slowed.  If anything, it has increased.  This is entirely appropriate-  process improvement can save a company a lot of money, and typically it is money that goes straight to the bottom line (much like an improvement in pricing performance will go straight to the bottom line).

We see customers focusing on process innovation for the following ends:

1. Making a location-specific process global (applying best-of-breed across the enterprise)
2. Making a global process location-independent (no longer dependent on a single call-center location)
3. Extracting savings from commodity processes
4. Measuring performance of BPO (Business Process Outsourcing) contracts against SLAs through BPM.
5. Making it possible to utilize BPO companies in combination with internal staff on a single process
6. Improving on differentiated processes
7. Measuring adherence or increasing adherence to Risk Management processes

We’re seeing less focus on refactoring processes for growth, and more focus on refactoring for savings.  What’s the difference?  When you are building a process for growth, the concern is that the process that handles 1000 calls a day won’t handle 10,000.  That you need a process to help you scale that 10x growth curve, and to help people who are new to the process cope with the process.  Often this means taking a process suited for experts and making it accessible to new employees.  When you’re refactoring for cost, you’re looking for the defects.  In a call-center process that’s eliminating the need for call-backs, dropped calls, calls that finish without conclusion.  So you look for root causes and look for preventative measures, quality control on data entry, etc.  You look for elimination of non-value-adding steps in the process, and for eliminating bottle necks that cause one area or another to be overstaffed.

Not every company is making these investments, and the companies we work with are already narrowed to a select group that are already pursuing process excellence via BPM - but it feels as though most companies are not panicking and they are focused on these tried-and-true ways to improve their bottom line.

One of the reasons we offer bite-sized packages to customers (and prospective customers) is because there is an element of “you have to see it to believe it” with process improvement.  I’ve seen a few of our relationships go from a 1-hour session to a 2 day working session to a 4 week study to a 3 month roll-out.  Each piece a palatable risk-reward investment to move down the path toward process improvement, rather than signing up for a boil-the-ocean endeavor.

Now that the day is over, I’m happy to see the market ended up for the day.  But regardless of the market ups and downs, we see real value and real need for process improvement all around us.  And consistent investment in those activities will yield results in good times and bad.

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.

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.

In a previous post, I discussed hiring “heroes” and putting the band back together. This seems like a good time to revisit that thread, but this time, let’s focus on what it means to have an experienced team.

Businesses are always advertising “experience”. I think we could all agree that years of experience is also not the only interesting metric to look at. But just for argument’s sake, let’s address it. I want to spend a moment debunking some of this:

1. You’ll see a local company advertising that they’ve been in business since 1950, for example. But then they don’t tell you that someone new bought the business two years ago and all the staff turned over. So, really, its a 2-yo business that is trying to leverage a 50+ year history.
2. Consulting firms will often tell you how many “total” years of experience they have. “50 years of experience in software” - but of course if they have 50 people that’s an average of 1 year of experience per person… which sounds a bit less exciting. If its two people, that’s a bit more interesting, isn’t it?
3. Companies will assign their “general” software experience to a “specific” software category, and conflate the two. For example, after doing 10 years of software deployments, and 3 years of BPM deployments, someone might say they have 13 years of process-oriented software deployments under their belt. Not an outright lie, but it sure is misleading, isn’t it?

I think the only meaningful measure of experience in consulting is the median level of experience. That measure will tell you that if you get a resource from this organization, half the time you will get this much experience, or more. Of course it would be nice to have a full distribution graph but we can’t really expect companies to provide that level of detail on a regular basis :)

At BP3, we think we have the most experienced BPM deployment team in the business. Our median software industry experience is 16 years, and our most experienced technologists don’t shy away from writing code, either. Our median BPM deployment experience is 4 years (and climbing). You work with BP3, you’re working with people who know how to develop BPM solutions, who have done it before, and have the scars and smarts to show for it.

But is years of experience really the measure to focus on? Well, it certainly tells an important part of the story, but the other part is to answer the question of what kind of experience? in a meaningful way.

The answer to that is pretty straightforward for BP3. We have, on our staff, the guy who authored Lombardi’s deployment methodology, created the Lombardi On Demand Assistance (LODA) program, and created the Business Process Analysis function at Lombardi (previously “Transformational Services”), and expanded training offerings to include method training. We also have the guy who ran all of the technical delivery functions in Lombardi professional services for 4 years, and hired most of that team. We have the primary driver of Aflac’s award-winning BPM deployments on our team. We also have the former leader of LODA at Lombardi for the last 2 years. Each of us has had critical experience helping customers get BPM software deployed, and helping customers realize ROI from their BPM initiatives.

In addition, we’ve each had compelling, high impact roles prior to our work in the BPM space. We have a lot of relevant experience about how to focus on high-impact changes to business processes, and a lot of relevant experience about how to translate process into a solution represented by software.

If you need help with your BPM initiative, give us a shout.