The Process Ninja

Lessons from a Process Project Failure

Recently I worked on a process project that I consider to be a failure. In the eyes of the company involved, however, it will probably be viewed as a great success.

Success or failure can be bizarrely subjective sometimes - mostly due to complete ignorance of what a process project should achieve.

 

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 be.  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.

Lesson 1

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, beureaucratic 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 2

Realise the cost of beureaucracy 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 3

Treat staff with respect and allow them to utilise their experience. Managers need to swallow their ego's.

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 4

Involve stakeholders from start to finish. Make them part of the project. Sit with them, involve them, 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 consultantion with customers.

Lesson 5

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 forcussed 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 6

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 an 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 7

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 experise, 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.

- TPN

Have You Met Holocentric?

I've recently become acquainted with Australian based BPM software vendors Holocentric. If you haven't heard of them you should have. I've had some basic training in the system and I have to say I'm fairly impressed with the depth of the product.

There are two main parts to the Holocentric product - one is the modeller which is where you build your processes. Like all good BPM products it provides the ability to set properties for objects, link and re-use process data to create a holistic approach to BPM. The second part is Modelpedia which is essentially a collaboration tool for discussion around the published models. I'm not an expert in the system (but I will be soon!) but I am already getting fairly excited about the possibilities of using it. For those out there stuck using tools like visio it is a quantum leap to use a tool like Holocentric.

If you are keen to find out more there are some very informative videos on their website.

I've met Holocentric and I like it - maybe you will too...

- TPN

Process Amnesia or (That's the way we do It because that's the way we do it)

"Sorry Sir, that's our process". How many times have you heard this said? And how many times have you thought "Well, your process is DUMB!" And how many times would you be right about that? A lot.

What I call process amnesia is when an organisation puts a process in place which over time becomes "the norm" or "just the way we do things". The danger in this is that over time organisations forget why they put the process in place in the first place and just blindly follow it. It remains unchallenged and starts to cripple the organisation. It's like having termites eat the wood that holds up your house.

I experienced an organisation's process amnesia only yesterday. Having realised that my train ticket was faulty I went to the counter at the train station to have it checked. Yes it was faulty they said. Could I have it replaced then, said I. No said they, but if I could bring my receipt in they would replace it. In the meatime they suggested I write a number 19 in a circle on the back of the ticket as this was apparently the secret code which would allow me to bypass the station guards never mind the fact that legally it was a receipt for taxation purposes. Luckily I did have my receipt so I brought the ticket back the next day. I took my receipt and ticket to the counter and was passed an A4 sized form (double sided no less) to which I had to complete and give back to them. So I filled in the form and handed back all the details. At the end of much filling in of forms, stapling and abstract fussying around I was handed a "General Purpose Ticket" - a piece of paper. "What's this for?" I said. "Oh you have to keep that until your new ticket arrives" she explained. "Can't I just have a new ticket now?" I asked. "Oh no" she said, "We have to send all this paperwork off to the audit department in the city who will check the ticket, process the form and send the new ticket back to us within 14 days. If you don't want to do that you can keep your faulty ticket and if you write a number 19 on the back..."

So now I have a piece of paper and a wait of up to 14 days to receive a new ticket. Somewhere back in the deep, dark mists of time there was a reason for this process, but it has been unchallenged for so long it costs cityrail, time and money and enless customer frustration. In any other retail business in the land you'd take your product back with your receipt and get a replacement. Not here.

Cityrail has forgotten why this process exists and until they overcome their process amnesia the customer and the organisation will continue to suffer. 

- TPN

UML Must Die

One of the few things in this world that causes me to break into a cold sweat is UML.

UML stands for "Unified Modelling Language" and by the mere fact that it mentions the word "language" you can understand that is is a tool deeply loved by those up to their armpits in RAM, ROM and other technical pleasures. Like most things evil in the world of process it crawled out of an engineering environment - this time a software one.

Quite simply UML needs to crawl back up the cavity it came from. I'm sure there are software engineers out there that worship it, but when it comes to process it needs to die a quick death. The reason for this is quite simple - no-one understands it. No, not me, not the enterprise architects, not the BA's and above all else the business certainly do not understand it. And if we fail with the business's understanding of THEIR OWN PROCESS, we simply fail altogether.

If you want to create cohesive, understandable processes that will give the business confidence in your ability; keep it simple, keep it clear, keep it concise and keep well clear of UML.

- TPN