Deconstructing BPM journey (1) and (2)

To read my previous posts on starting the BPM journey you could be mistaken in thinking any old fool could do this and what is the big deal about it all. Unfortunately the reality is that these type of improvemnet projects have a glorious history of failure or catastrophic under delivery. We recently ran an internal workshop of the core stakeholders of our own improvement project and the following points are straight from that forum - warts and all.

• these things take time and it needs to take time, you will not see all the options and complexities in the first pass
• look for the key influencers in the various pools of employees and look for high levels of involvement with these individuals
• the level of involvement of these indviduals will signify the level of takeup and enthusiasm later
• some people are habitual sniffers and just sit around the edge waiting for things to be proven for them
• without the support at least one of senior management and the business management the project will fail
• maintain credibility through the project - come clean about missed targets, changed objectives, challenges faced and not yet overcome etc
• you can only force people to turn up - they must be personally interested and motivated in improving the process (particularly if it is cross functional) to be able to achieve a quality outcome - if they don't give to the project then they will not achieve all the benefits possible to them
• people always underestimate the amount of time they will have to commit to the project - it is not a one meeting wonder session
• Visio is a reasonable one-dimensional tool and easy to use but the challenge is to cover all the interconnected layers of people, process and applications in a digestable and manageable ways - there are modelling tools available that do this better - we have now selected one to move forward with
• be prepared to be flexible and don't be surprised if things change around on you
• face reality as it is not as you would like to be
• communicate regularly and at appropriate times
• have the resources as available as possible when they are required for the project - if everything goes into stasis waiting for resources then the project is going to suffer in credibility
• do iterative boardroom prototype workshops with clear thinking stakeholders - more than once
• don't just follow the "happy path", question hard around where things go wrong, exceptions occur etc
• There are complicators and simplifiers - always hunt out the simplification - and be aware - it's amazing how complicated cultural issues can be
• think about the level of tolerance to compliance requirements that you may be happy to live with in line with your capacity just to "do business" - for some processes there may be zero tolerance, others may be less rigid
• you can't abdicate your process improvement to third parties - all good athletes have coaches and mentors but they have to run the race themselves - don't try to outsource the project, only the business can do it for itself
• think about setting up a "process office" so that as people come in and out of the project they are situated appropriately within the team for their involvement
• be organised and be seen to be so - if that is a problem for you then you are probably the wrong person to be managing this project
• "fight" for this internal project as hard as you would fight for a customer project
• An interesting point - when you get properly involved stakeholders workshopping around the table it is quite likely that technologies and BPM application/solutions etc don't get discussed
• Name the project other than the technology platform - problems are invariably people rather than application system issues but the project will be tarnished unfairly if it is named the same as any technology component being implemented.