Post Go-Live Strategy

What happens after you have completed the application lifecycle of a Business Process and implemented the solution?

You’ve launched the workflow and the organisation have signed off and gone live with your masterpiece.  It’s a work of art.  You couldn’t be happier.  The Business Analysis Team was switched on; your key users were involved throughout the lifecycle; the stakeholders are counting how much money they’ll save with this magnificent piece of work you have created.

What’s your next move?  Is it to go on to the next project?  Have you thought about your post Go-Live strategy?  If you’re not following me yet, then we’re probably not as good as we were looking in the above paragraph.  If you are following me and you think you’re still moving on to the next project straight after, then we’re still not looking as good as we were in the above paragraph. 

If you’re next move was to implement any of the following: 

• a “Continuous Improvement Register”– something that will enable users to add “nice to haves”, “should haves”, “must haves” for your process;
• a support strategy – known issues list of what typically might go wrong with your process and how to quickly resolve it; which will be maintained by the support team;
• a maintenance strategy – a way for the owner of the application to see both the Continuous Improvement and Known Issues list that will enable them to see how they can ensure that the business adapts to the process, and that the process can adapt to the business.

These things are critical to the overall success of the application.  You’ve just put all your blood, sweat and tears into a Business Process, the last thing you’d want to see is that in six months’ time, the business has outgrown your process.  They are critical strategies; there should be no doubt about it.  Yet it doesn’t seem to be obvious to everyone in the projects that I’m involved in.  It seems to follow me around, this constant discussion and/or battle that these things should also be part of the application lifecycle planning and budget.

This goes beyond just your usual: Quick Reference Guides; user training; and handover notes or walk throughs.   Businesses change how they do things constantly.  With every change in personnel, or systems or the policies that organisations put in place, your Business Process Model needs to change with it.  The only way it can do that is to constantly capture these changes.  Encourage users and support teams to capture (or capture it for them) these and then react to the change.

Even a great process will still have a limited shelf life.  It might be three months, it might be a year, it might be longer, but it will eventually become out-dated.  If it doesn’t, you’re either not looking, or the users have worked out ways to “get around” the limitations of your once perfect process.  All of a sudden, those pretty pennies that the stakeholders thought they had saved have now turned into pieces of paper with “IOU” written on them. 

Application Lifecycle: gather requirements; specify functionality; design solution; build solution; accept solution; implement solution; strategy to support solution; strategy to maintain solution;

Let’s stop the battle, let’s all just agree with me on this, that the process isn’t complete after Go-Live.  The process grows (more integration with systems, more automation, more data capture, more reporting capabilities) and shrinks (less approval steps, less human validation steps, less bottle necks) with the business.  Let’s start planning in our projects that this is a key element that needs time and budget.  It’s not tacked on to the existing budget; it’s carefully and strategically placed as part of the budget.   Whilst you, the K2 Expert, won’t have to be there to support or to necessarily maintain the process, the strategy for both should be part of your responsibilities. 

The planning of these strategies occurs at the design and doesn’t stop… ever.  So start asking the questions: how do we support it; how do we maintain it; how do we ensure its longevity?  If these are taken seriously at the start of the project, then your Business Process Model will remain as perfect as it was when you first released it into the wild, otherwise... I’m all talked out about otherwise…