Colin Tuebner wrapped up with a session on BPM and change management. The presentation is based on a set of interviews with those customers using BPM a while and doing a good job at managing process change. The theme is “Organizations use different patterns for controlling change; choose yours and don’t let change manage you.” The important thing is to be explicit about controlling change, regardless of the details of your approach. Business people are less formal about this kind of thing so IT needs to help.
There is a balancing act for business and IT between empowerment of business users to change processes, control of those processes and governance is the fulcrum. Tackling change management is crucial because:
- Continuous importment is the primary value of BPM
- Organizational silos can cause disagreements across a process
- Lack of a business mandate could mean no-one funds change
- No CoE may mean there is no-one to manage the change
So who is responsible for identifying change, who makes them, how do business and IT together and who tests? No one answer came out of the interviews, although they did get some good best practices. Given the number of stakeholders it is critical to have a defined process.
Change is a mixture of larger changes that are less frequent and smaller, more frequent ones and the degree of change tends to increase over time. The continuous change tends to be every few weeks, though it can even be daily – while new process versions tend to change every 2-6 months and have a more involved project to make the change. Interestingly almost all the cases had technology tightly integrated into their business – “partner” or “trusted supplier” types – the “solid utility” mindset was not common.
One interesting observation is that joint ownership – business and IT – tended to impede fast changes. Investment bank and software company had strong business or IT ownership and rapid change – those with more pairing tended to talk more about changes and make fewer of them.
Best Practices:
- Always plan for version 2 of a process when you roll out version 1 – plan for a big change
- You need to iterate through both the overall execute-monitor-analyze-design cycle and within each cycle (design iterations for example or new versions of the dashboards).
- Make sure business people have a test environment, especially one suitable for the continuous change – a mirror of the production environment. One customer did a champion/challenger approach with 5% of the staff running a new and as yet undeployed version of the process.
- All of the customer examples had a tight and good relationship between business and IT folks.
- Financial Services Company best practices:
- Let business drive change
- Get everyone on board with change management practices
- Make testing changes a priority and allow ample time for testing – they use the standard development/test/production progression
- Software Company:
- Increase goals over time, start small
- Use Agile concepts to manage change – rapid iterations, small projects (don’t let projects go more than 3-6 months)
- Use detailed user story or scenario-based design to help employees define their future role and so reduce resistance
- Investment Bank (overnight changes with an offshore team and bigger weekly changes):
- IT owns change because they are better at paying attention to detail (especially with busy business people like brokers)
- Rapid, iterative change cycles
- Flexibility on timelines – pushing change out rapidly
- Separate out the small things that business can change (and bound this change) but let IT do the majority of more serious changes
There is a range from conservative to aggressive in several dimensions:
- Tiger teams to Full Bore Agile;
- Business sets priorities to Business makes changes;
- Business-IT teams to completely new roles;
- IT to shared change management;
- External rules to shared QA;
Pick a starting point that works for you.
