One of the main advantages of using BPM tools over in-house custom development is the speed of development, and more importantly – the speed of implementing changes.
That said, I have never managed to go-live with a new customer implementation in less than 3 months.
The ability to shorten the time from design to go-live is an important element in BPM projects. It reduces project risk, reduces implementation costs, reduces frustrations.
Over the years BPM software has become easier to use, quicker to develop with.
The practices and methodologies we use are clearer, better defined, but still the overall project time hasn’t changed much.
The hazards are well known, the warnings clear and visible, but we do not always manage to find a way around them.
I can spot problems a mile away. I can foresee problems just by the customer’s attitude, resources, budget, IT maturity…
My experience should enable me to shorten project time, but it doesn’t.
Yes, projects have less problems, management is happier, customers are happier… but I still cannot find a way to shorten project time.
In all my years of implementing BPM solutions, managing BPM projects and BPM programmes I have never been able to go-live with a new customer implementation in less than 3 months.
Even with small implementations that take a couple of weeks to build, never manage to go-live quicker.
The reasons vary:
- The infrastructure is not ready yet
- The customer adds a “must have” change request after development has completed
- The project manager suddenly gets cold feet and delays the go-live for “additional testing”
- Someone realises that the design doesn’t really solve the business pain
- The 3rd party vendor isn’t ready for integration yet
- Resource problems, annual leave, personal days, someone leaves the company, maternity leave
- A higher management level suddenly decides that they need to be involved… bless them…
Phase twos are faster, but new customer implementations have more hurdles.
It usually comes down to project management and managing customer expectations.
But you don’t always have control over them.
These are some of the haste hurdles that I try to avoid:
- Never let a customer implement the first project by themselves.
The pursuit to cut costs and the simplicity of a presale demo sometimes leads customers to believe they can implement their processes by themselves, without someone holding their hand, leading them.
Business processes are always more complex than they seem. A BPM tool is more sophisticated than a few days training can provide.
If you are not holding the customer’s hand throughout their first implementation, you will be managing a crisis later on. - Always do a soft go-live.
Grandstanding, defining D-days are always counter-productive. They raise expectations and tensions. A soft go-live, by going live with a small group, then a bigger one, then everyone – has less pushback - Phase 1B
There will always be change requests, and requirements that will cause delays. Using the terminology of “Phase 1B” (unlike Phase 2) is always easier for the customer to accept. It enables to deploy, go live, start using the system, while you develop the changes - Enthusiasm is great. The customer’s desire to move forward quickly is great. You need to have your feet firmly on the ground
Do it once. Do it properly. - Direct pressure on the customer to go-live is usually counter-productive
Coach, persuade, influence, entice… use your charm and diplomatic skills… but the decision must come from the customer.
One of the main advantages of using BPM tools over in-house custom development is the speed of development, and more importantly – speed of implementing changes.
“More speed, Less haste” – Beep Beep
Excellent insight that matches with my experience. There is a human element that makes all BPM efforts require a certain amount of “buy-in” time that no amount of technology or accelerators can change. Great post for setting realistic expectations.
By: Chris Taylor on 17/08/2011
at 8:49 pm