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…

Don’t Forget the Indirect Actors

As a consultant in the technical space, I’m often not involved in the gathering of requirements and creation of the functional specifications of a Business Process Mapping (BPM) project. I usually get brought into the project whilst the Business Analysts are finalising these documents ready for me to design a solution. More often than not, I usually receive a document that covers the direct actors involved in the process. These are the people that will receive a task item to action. If I’m lucky it will also address the key systems involved directly with the process.

• Example: Person A will submit a request; Person B will approve a request; Person C will deliver the request; System A will store the request; System B will provide a report for the request;

This is important for the day to day usage of the process. It is what I refer to as the Workflow Process. This does not cover the Business Process. The Workflow Process is only a part of the Business Process. It describes exactly the example explained above: the direct actors within the process. If you went and implemented this solution with K2 BlackPearl/BlackPoint you would be implementing a fairly basic workflow process – but it would not cover all the needs of the business. This might be all the client wants and/or needs as to do more, would cost more money, time and resources. So what more do we need to ensure that we map the business process successfully? We need to define the Indirect Actors within the business. These are the people that don’t get assigned tasks, but will be required at some point to get involved.

• Example: Person A submits a request; Person B will approve a request; Person C will deliver the request; System A fails to store the request; Person D monitors the process through a Management Console and resolves the issue by manually uploading the request; Person D progresses the workflow; System B will provide a report for the request;

Hopefully you can start to see, by this very primitive example, the importance of defining the indirect actor here. Hopefully it was simple enough to spot, if you didn’t get it the first read, go again. Person D is not involved in the process at all. In this example, they are monitoring the K2 Workspace and getting involved manually in the process.
Defining this type of use case is critical to ensuring the business needs for the process are covered. It will go a long way to ensuring that the business users are comfortable with the solution being designed and delivered. If we don’t map this solution out properly, if it’s not defined in the functional specifications and is left up to the Technical Expert to come up with a something on their own, it would be even more dangerous than not defining it at all. That last part might be confusing at first, but if you think about it further, it makes perfect sense. If we are here to design a Business Process, then it requires that the business define the process. Not the solution, but the process – how they wish to interact with the system; how they expect the system to react to situations; if we rely on technical people to dictate or mandate a solution that does not fit the business expectations, then you will have a potentially failed process. If, for example, we didn’t define what would happened if the request in our little example. The request failed to get stored correctly and went into error. The technical expert decides that this is a likely scenario, and needs to be handled. They decide that the solution is to:

• Retry the upload three times; if still in error - email a notification to Person D to resolve;

What a nice and tidy solution. Pats on the back all round.
Not quite. We’ve now found ourselves in the dangerous position of prescribing a solution that the business did not request. We’re sending an email to a person that isn’t expecting a notification. We are retrying an upload to a system we don’t control potentially three times. We are forcing the business to accept something they didn’t ask for.
Notifications are nice, but not everyone is so receptive to them. If Person D in our example was a Group, maybe the local Help Desk at a large company, emails would be like spam to these people. They may receive hundreds a day. Sending an email to a group of people in this field is akin to giving a dollar to a millionaire. Bit of a waste of money. Retrying to upload a document to a system we don’t control could also cause us issues we might not see. There may be a perfectly legitimate reason that the Business Analyst did not suggest a retry at this point.
To design a Business Process we need to identify these indirect actors. We need to understand where a process might require some form of exception handling – be it manual or automated – and we need to ensure that the business is directly involved in determining the way they wish to handle it. Our job is not to prescribe the solution that they need, but to ensure that there is a business strategy to cover their workflow process.
To that end, our responsibility is to escalate these types of things back to the Business Analyst, to provide options for them to go back to the business with, and to clearly outline in the functional specifications. It’s usually in this area that I see a lot of workflow processes fall short of business expectations. Anyone can build a workflow, what we as Technical Experts need to do is ensure that all the actors, direct or otherwise, are accounted in our solution, and that the business is aware and accepting of it.
The types of indirect actors I generally keep an eye out for are your: Front Desk; Help Desk; Managers (usually those that like to get reports out of processes: completed in a month; started in a month etc); System Administrators; Personal Assistants; SharePoint; SQL Reporting Services; Log Files;
These types of interactions usually raise red flags for me, and I generally start the process of harassing the BA Team to get me more information around those particular things. Indirect Actors, don’t forget them. Make sure you have them defined. Don’t underestimate their importance just to get a process out the door, because chances are pretty good that they’ll find their way back you sooner rather than later. K2 or any other workflow tool won’t be able to save you. There’s no magic involved. There are lots of solutions available to you. K2 gives you quite a number of different ways to solve the majority of issues you may come across; but the only way to ensure that you map out a robust solution is with a clearly defined Business Process – which encompasses the business’ way.