Pop quiz, hotshot. There’s a bomb on a bus. Once the bus goes 50 miles an hour, the bomb is armed. If it drops below 50, it blows up. What do you do? What do you do?
It’s an age old argument: Should the emphasis be on delivering on time, or delivering on quality.
BPM projects are still IT projects. The problems are the same, just with a BPM twist…
There is no right or wrong here. It depends on the type of customer, the type of project, your relationship with the customer, your ability to persuade…
If the customer says: “I don’t want it perfect, I need it on Wednesday. I need to present it to the CEO” – you have room to manoeuvre on “under the bonnet” features, and can concentrate on finishing the GUI and end-user features.
If the customer says: “Technical review is on Wednesday” – you need to complete the technical parts. GUI and end-user features can probably be postponed.
If the customer says: “I need it completed on Wednesday” – Well… basically you’re screwed.
Now I know most of you are jumping up and down and yelling “Wrong!! Wrong!!” It’s all to do with project management, managing customer expectations, managing risks… and I agree.
But every once in a while you get a project that you know from the beginning that it’s going to be an uphill battle. The customer wants to manage the project by themselves, new project manager, shoddy requirement gathering, indecisive managers. Fun, fun, fun…
How do you explain to an IT manager that has spent the last decade managing IT projects using the Waterfall methodology, that the best approach in BPM projects is the Agile methodology. BPM projects are not a “build, bang and deliver” kind of project. Even after Go-Live the process will continue to change. Do a phased approach.
How do you explain to the business team that BPM software is… software.
Whatever comes with the product out-of-the box can be implemented quickly. Customization takes time. Additional features take time.
And no.. BPM software doesn’t make coffee or play music… so stop asking for nice-to-have features that are not needed.
So you find yourself between a rock and a hard place. The deadline is set.
You are either going to deliver on time with missing features, or deliver on time with an unchecked process.
Pop quiz, hotshot. There’s a bomb on a bus. Once the bus goes 50 miles an hour, the bomb is armed. If it drops below 50, it blows up. What do you do? What do you do?
And don’t tell me to shoot the hostage…
Adam Deane 
OMG, I think that you have talked to every customer that I’ve ever had! 🙂
Waterfall to Agile is one of the single biggest contributors to BPM project success, but it’s truly an uphill battle for many more traditional organizations. The management will love the promise of Agile, but will find it hard to get away from the lengthy requirements writing, massive testing cycles and all the rest that they are accustomed to.
I think that sometimes you do have to shoot the hostage.
By: Sandy Kemsley on 15/12/2010
at 1:50 pm
Great blog. Love the perspective. Perhaps before you get on the bus take a hard look at the other passengers and ask “where are you going and which route are you taking?” That’s the standard rules for a Nightbus in London
Perhaps this image will clarify matters? “Follow process or hit the deadline?” http://bit.ly/huxs7A
By: Ian Gotts on 16/12/2010
at 6:01 pm
[…] A great blog by Adam Deane on Delivery Focused BPM. […]
By: Ian Gotts : Making you think on 16/12/2010
at 6:23 pm
[…] A great blog by Adam Deane on Delivery Focused BPM. […]
By: There’s a bomb on a bus. Once the bus goes 50 miles an hour, the bomb is armed. If it drops below 50, it blows up. What do you do? #bpm « Ian Gotts : Making you think on 16/12/2010
at 6:26 pm
Well, fundamentally, you do as you’re told…you can only advise, and if they don’t take your advice that’s ultimately up to them and they have to deal with the consequences. I’m a big fan of agile, but at the end of the day they are the customer and they set the rules…
TPN
By: The Process Ninja on 16/12/2010
at 11:10 pm