7 lessons from a process project failure
Add bookmark
|
Success or failure can be bizarrely subjective sometimes - mostly due to complete ignorance of what a process project should achieve. I recently worked on a process project that I consider to be a failure but in the eyes of the company involved, it will probably be viewed as a great success. Here's what I deemed to be the reasons for its failure and what lessons can be learned: Failure #1: Too expensive While the particular company had oodles of money to spend the eventual cost of the project was approximately 10 times what it should have been. This was due to the fact that the company was mentally locked-in to old ways of thinking and could not see past developing new systems in the manner of which they had previously done it - hardcoded, costly and slow. |
Is your process project about to be done in by one of these ticking time bombs?
|
)
Lesson:
Don't be locked into old ways of doing things. Utilise new software solutions to provide agile systems that are flexible today and tomorrow.
Failure #2: Too slow
6 months after inception the project had not even started to be developed.
Actually it hadn't even been resourced. Old, bureaucratic management processes with no agility meant that projects had to follow a stuffy development cycle with 150 rounds of sign offs to get anything done. As a result nothing got done. What could have been done in 3 weeks took 3 months.
Lesson:
Realise the cost of bureaucracy and unleash staff by empowering them to make decisions. Embrace "freedom within boundaries".
Failure #3: Not Utilising Staff Experience
Whilst some highly experienced and capable resources had been engaged to work on the project it was clear from day one that they would neither be allowed to use their experience or their initiative. Staff were treated like junior BA's and PA's. Management paid lip service to their suggestions. 6 months on, all the staff had left.
Lesson:
Treat staff with respect and allow them to utilise their experience. Managers need to swallow their egos.
[eventPDF]
Failure #4: Not Involving Stakeholders
Throughout the project stakeholders were treated like lepers - not to be spoken to or touched in any way. As a result they became disengaged and skeptical of the direction of the project. "buy-in" was disintegrated.
Lesson:
Involve stakeholders from start to finish. Make them part of the project. Sit with them, involve them, and communicate with them. A few workshops and a slap on the back is not enough.
Failure #5: Forgetting the Customer
No matter how many times I tried to bring up the customer experience, the concept fell on deaf ears. Customers were not advised or consulted. If the stakeholders were treated like lepers then customers were treated like they had bubonic plague. There was to be no consultation with customers.
Lesson:
Customers are an organisation's reason for being. If we fail to take into account the customer experience we simply fail. Customers must be involved no matter how afraid we might be of what they will say. The implications of what they will say will never be worse than the danger of us not communicating with them.
Failure #6: Technology Defining Process
It was clear from the start that the project was dangerously focused on (old) technology being pushed at the business. Rather than look ahead to find new and innovative solutions the project was trapped in the mire of inflexible legacy systems that were limiting the company's ability to do business.
Lesson:
Technology is a tool for achieving business success - nothing more. Technology should not be pushed to the business - the business should define what it wants, and receive the technology it needs. Customer > Business Strategy > Process > Technology. It's that simple.
Failure #7: Shyster Consultants
When things started to go wrong (i.e. all the staff left) the panic button was hit and in came a highly paid consultant. Rather than delivering tangible project benefits the consultant swanned around telling other staff what they should be doing (in meaningless management speak riddles) and re-hashing previous work into a number of new and equally useless PowerPoint presentations.
Lesson:
If you are going to spend money on consultants, ensure they have a history of being able to deliver, rather than just talk and create PowerPoint presentations. Focus on them demonstrating expertise, not legalese.
Whilst this is not an exhaustive list of reasons for process project failure, this is a REAL list of reasons for process failure based, sadly, upon my own experience.
It doesn't have to be this way - and I, for one, will not be putting up with it again.
You shouldn't have to either.
First published on www.theprocessninja.com. Reprinted with permission.
