BPM projects should take weeks, not months.
I’m constantly amazed every time I hear about BPM projects that take nearly a year to go-live. Or even better – two years to design!
I don’t understand what the value is in these kind of projects.
Business processes change. The business requirements change. The business goals and emphasis change. Its the nature of the beast. This is how business works.
BPM projects need to be agile. They need to adapt to the changing business needs.
Process design is good. Taking your time to understand the business pain is good.
Taking time to understand the current process and how it should be is excellent!
Some of the best value you can get from a BPM programme/initiative is even before a software solution is brought in. Sitting down and discovering the process enables you to implement changes. Some problems are easy to solve once discovered.
Process discovery and design is important, but it shouldn’t take you years…
BPM software is a tool to design, implement and monitor business processes.
Its not an end. Its a means to an end.
If it takes you months to build a single process – you’re doing something wrong.
You’re building an application. Therefore it’s an IT project – you probably could have built it faster and better using the conventional software programming tools. It doesn’t matter if it’s because the tool is too-shallow or too-complex, or just requires lots of customisation. It doesn’t matter is it’s the developers fault. Going that extra mile. Trying to build some special functionality that the software doesn’t have out-of-the-box.
You’re building a software platform that is supposed to solve the business pain – visibility, governance, control.
It’s not rocket science. You are not building Nasa’s next spaceshuttle.
BPM projects should take weeks, not months.
But seldom have I seen a BPM project that takes weeks. It might take weeks to build the main workflow, but the song and dance around the rest of the project takes months.
Server is not ready for installation, new integration feature required, new “must have” functionality required, additional reports, forgotten rule exception.. the list goes on.
Yep, it’s a project management issue: Problems managing requirement gathering, or managing customer expectations, or managing change creep.
And then you’ve got the customers that are afraid to jump into the water. Afraid to Go-Live.
You need to drag them kicking and shouting to the water. They’ll protest, they’ll threaten, they will give the best excuses in the world. They need to be pushed into the water. Once they’re wet, they change their song. Suddenly they are our biggest sponsor, they are totally committed. What was all the yelling and screaming about?… What yelling?
BPM projects should take weeks, not months.
It doesn’t matter why the project is taking so long: the BPM software, project management, or the customer – the end result brings little added value.
Dilbert’s Wally has a famous saying: “I’m not lazy. I’m useless. There is a big difference“
Adam Deane 
I second that thoughts.
While working on such BPM projects I observed that the projects start with the spirit of BPM projects – weekly milestones, regular playbacks to business users and the project is scheduled to go-live within a month or two.
A twist to this rosy story comes in when project managers or process analysts could not manage customers’ expectations – they see legitimate business requirements or features need; they agree to such requirements although such requirements are bit tangential to the objectives of the project or cannot be addressed by using OOB features of the underlying platform or may cause significant schedule variance.
And that’s when, the project that was started as BPM project becomes typical application development project.
Having said that, I feel that project managers / process anlysts play a very important role in keeping BPM project as it is. May be it’s the time to identify and monitor the KPIs which would help staying on this side of the fence!
Thanks!
By: Neo Patel on 06/04/2011
at 8:24 pm
And I disagree. First, let’s look at the “business requirements change” argument. If that’s the case, then via a rules engine or case management you’re going to want to build as much of that into the BPM app as possible so it doesn’t have to be re-visited down the road, or at least minimally. That takes time. Years? No, but months maybe. Depends upon the scope of the BPM app. If department then yes, we should be able to do it in weeks. If a large vertical like in a big corporation like mortgage lending or insurance underwriting where there’s a lot of hand offs, probably a lot of content attachments associated with multiple workflow steps along the way then yes, months.
Infrastructure is a logistical problem, usually an organizational bureaucracy one as well. That one I won’t address. It’s the company’s problem, not the BPM solution’s.
Developers, complexity and unnecessary “doodads?” That’s a project management and technical leadership problem. Again, not specific to BPM. Rather an organizational an IT issue.
Recalcitrant users? Again an organization problem. The user base wasn’t properly engaged in the requirements elicitation or specification phases and so the buy-in wasn’t there. Any good PM and/or technical lead worth their salt will know the “how” doesn’t mean doodly without doing a good and timely job of defining the “what.”
All of the above said though, I can and have seen robust BPM applications stood up in months with hundreds or thousands of users and many tens or hundreds of thousands of workflow transactions firing on a daily basis and it was always, without question, a function of all of the above already being in place, with a good client and a good delivery team.
Your suppositions against BPM project delays aren’t endemic to BPM, they’re part and parcel of IT projects. BPM projects should take as long as necessary commensurate to the task at hand. Overruns are an organizational issue. The client, the vendor, the users, the technical team, their relationships and their mutual understandings; or lack thereof.
By: Patrick Lujan on 06/04/2011
at 8:49 pm
[…] on running BPM projects & governance thereof). While BPM initiatives still continue to toy back & forth between “the fast, iterative , singles-and-doubles approach” and “ambitious, long-drawn, […]
By: The new role of IT – from Cost Center to Business Platform Provider « The Eclectic Zone on 07/04/2011
at 3:42 am
Yes Adam, and you did prompt me to write a post now! 🙂
IT has to realize its role as a Platform Provider, as against a Development shop. The need for IT to focus on control over the underlying wires and toying with the platforms makes it less configuration & modeling driven and more customization & development driven. We’ve been trying to tame this through the Governance and CoE approaches, and through positioning “seasoned” BPM practitioners in those bosses’ seats. However, unless the platforms engineering and development aspects are decoupled, we would continue to face that challenge.
Here’s the post! It’s titled – The new role of IT – from Cost Center to Business Platform Provider http://wp.me/pN8i1-7c
Enjoy reading…!
By: Ashish Bhagwat on 07/04/2011
at 4:11 am
I’ll make this short and sweet:
Having a workforce that is unaware of its current processes is unable to contribute to change. Hence the shocking figure of 40% of project time spent on process discovery. (Btw: I wrote something on the issue here: http://bit.ly/e6MNyB)
Add to this the general attitude that planning, organising and running process projects is easy, because the process models always look easy and you have the cause of some of the ‘song and dance’ issues Adam mentions.
Finally, the separation of process project and process operations does the rest: The larger (and longer running) the project, the more kudos to the project manager. Unfortunately, someone seems to have forgotten that only operational processes deliver results, never the projects themselves.
Thomas
By: Thomas J. Olbrich on 07/04/2011
at 10:58 am
This article raises good points for BPM project that are summarised by you sentence “You’re building an application. Therefore it’s an IT project”
But NOT ALL BPM projects are about building a workflow application. Many are getting end users to understand the end to end process and use the current systems ( eg SAP Oracle) and manual procedures consistently.
These projects can be very fast and drive a huge ROU and don’t get bogged down in ziT politics
By: Ian Gotts on 11/04/2011
at 5:48 pm
Hi Ian,
I agree that not all BPM projects are about building a workflow application. Some of the best BPM value comes from the discovery.
As I said:
Cheers,
Adam
By: Adam Deane on 15/04/2011
at 12:08 pm