This is the next in a series of posts focused on process work - particularly process work being carried out in projects. It links in closely to my eBook ‘The Perfect Process Project’, version 2 of which has been released. If, after reading these posts, you want to purchase a copy of the book please feel free to click over to the appropriate page and do the business.If you are already a subscriber to The Process Cafe you will receive these update automatically in your RSS reader or inbox. If you don’t already subscribe you might wish to do so by clicking the RSS icon on the right of this post.
This post is going to focus on not doing the wrong things in a process project.
- Buying a tool to solve a problem
- Sorting out the organisation before the process is defined
- Getting stuck on methodology and dogma
I've often said on this blog 'If all you have is a hammer then every problem is a nail'. By that I mean it is very easy to focus your attention on solving an issue using tools you already have. However stepping back and looking at things in a different light can reveal things which are not, necessarily 'nails' in this case. The mere fact that you are focused on the tools could be clouding your judgment and thinking.
It's the same with process projects. A lot of organisations decide that they need to have the latest EA/BPA/BPMS system installed and then use that to solve their problem. They focus on the capabilities of the tool and end up distorting what they really need in the service of the tool.
Sorting out the organisation before the process is defined
I worked with an organisation a few years ago when they were looking at completely overhauling their European IT function. They approached me and told me they wanted me to define the processes by which this function would operate. I told them I would be happy to define these processes and then let them know what the appropriate organisation needed to be to support those processes. "It's all right, Gary. We've already defined the organisation" they said. "But how can you define who is going to do things before you've defined what they are going to do?" I asked. "We know, basically, what we want the organisation to be so we'll go with that" they replied. I knew from that point onwards that my work would be devalued and useless, as indeed it turned out to be. We were always spending time playing catch-up after that.
The point is that if you are defining how a department or a function works, one of the end results of this work is an organisation structure. Defining the organisation structure prior to defining the process is tantamount to saying "We don't care whether we are doing this right". Don't do it!
Getting stuck on methodology and dogma
Luckily I have never been stuck in this situation, but I think that this is a case which happens more often than people care to imagine. It happens like this:
A project is started and the project spends a lot of time planning and organising. As part of the planning and organising they decide that the process definition should follow a methodology. It could be BPMN, or UML, or - if this part of an Enterprise Architecure initiative - TOGAF, or IDEF, or any of the myriad of other methodologies that exist. Fundamentally the use of a methodology to manage your processes is a good thing, but oftentimes the methodology becomes an end in itself rather than an enabler. The analysts stick slavishly to the methodology even when it might not be the best thing to do. I believe that sometimes sticking to a methodology or a particular dogma can be detrimental to the project in the long term.
Summary
This is the last of the specific articles on the Unseen side of Process Projects (although there will be a summary post next week). I think it has covered a number of the 'softer' type of problems that can plague processes. Nevertheless these are exactly the types of problems that can cause a process project (or indeed a project in general) to suffer.
I would be interested in your views and comments on any of the items in the series. (for earlier posts in this series please click here). Please feel free to add a comment into the field below.
Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
