I love reading case studies.
Case studies are ever so positive.
We came We saw. We conquered.
The customer loved the solution. The customer reaped huge ROI.
The project was delivered under time, under budget.
The customer gave his consent for you to marry his daughter,
and everyone lived happily ever after.
So instead… I’ve decided to write a few anti-casestudies
Unfabulous projects that I’ve seen over the years. I think it’s more interesting…
Case Study 1: Bypassing the IT
It all started out nicely.
The customer had seen the solution, was impressed, and was looking to close the deal quickly. Their business team was a powerful department, with their own budget.
All that was needed was a tick in the box from the IT department.
I knew the customer had a hidden agenda. I just didn’t know what it was…
I managed to find out that they already had a BPMS solution from another vendor, but they found it complex, clunky, and could only be used by the IT team.
It took ages to get IT to deliver anything on the existing platform.
They wanted to be able create very simple approval processes by themselves.
… They were looking for a way to bypass the IT.
The budget was there. The people were engaged.
The first presentation to the business team and management had gone down well. “Wows” and “Ooohs” from all the participants.
The second presentation to the IT department started off nicely.
The techies asked the common technical questions and were happy with the answers.
Suddenly, the IT manager starting asking annoying questions. Then he erupted.
Why wasn’t he told about this meeting earlier. Why was he being bypassed?
Why the heck are we buying another BPM solution?!? he demanded to know.
We already have 7 different BPM solutions from 7 different BPM vendors already installed in the company. Yes.. some of them were not being used, and some of them were not being used properly, but the answer to that is not to buy another vendor solution.
At that point an internal discussion kicked off between the business and IT.
Business and IT yelling at each other. Blaming each other. Yelling. Screaming.
The police were called in… (ok, I’m exaggerating here…)
• Prepare for the worst.
• Some things are out of your hands
• Internal politics analysis is part of your job
Case Study 2: Building an App
It sounded like a simple project. Employee time recording.
There wasn’t a real need for process, but they loved the web-based wizard platform.
Months later (and two project managers later..) we got it to go-live.
Over time, over budget. I was told you could buy a small house with the money lost.
• Never agree to do a fixed price project in BPM. (BPM projects are agile)
• Never build a non-BPM solution using a BPMS platform
• Keep away from product customisation
• You need a bad project to learn from. It’s expensive, but a necessary learning fee.
• Never believe the IT manager when he says “Could you stay a little longer, we have already ordered pizzas…”
Case Study 3: Bringing Real Value
It sounded like an important project.
One of the European governments had passed a law forcing elected government ministers to provide more transparency on the process of their decision making.
The process design was grandiose. Two hundred steps long.
It would take a couple of years to run the process from end-to-end. Impressive.
That said, the process had only two actors (the minister and his parliament assistant).
I learnt the fun bit later.
It turns out that the minister doesn’t know how to use a computer,
so basically the whole workflow was built for the parliament assistant to send tasks to himself.
I am “sure” they are using it. And I am sure it bring them “great” value.
It’s nice to know that our taxes are put to good use…
• All governments around the world think and work the same way.
• Unlike the private sector – the public sector has a different agenda when implementing a BPM programme (self preservation).
• Government – Always expect the worst and you won’t be disappointed.
Case Studies: They say wise men learn from mistakes of others, a fool from his own