From Pilot to Program
- June 12, 2008
- 0 Comments
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:
- 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…
- 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.
- 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.