This week I have been focused on developing support models for two different projects so felt it worthwhile discussing how to develop a support model that really does support the customer or end user.
Support model or no support model
I have found that on some of the projects I have worked on, the support model is completely forgotten. The development work is done, put into production and the expectation is that it (the system, change, process) will support itself and the business. Well who really cares about the business. This is not a good outcome in my mind.
For other projects the support model has been considered and well documented with every group or person in the chain who needs to be involved in the provision of support fully understanding the requirement from them. There is usually a well documented support model, complete with process flow diagrams where groups can clearly see the hand off points of items, and timing (if relevant) of pieces of the support puzzle are also clearly spelt out. This leads to a great outcome for the business. They know exactly what sort of support they will receive and how long it will take for that support to be provided.
With technical teams this process works really well, because there is a clearly defined path of who does what, in what order, where information flows, and how the loop is closed back to the initiator (usually the customer).
Technical teams are more likely to have tracking and monitoring tools in order to capture support requests, so that they can follow a workflow and be escalated as necessary. If you teams don’t have this, it might be something that you consider setting up in another form.
Best fit for the business
I find that business teams prefer a little different approach. Yes, they also like to see where the linkages are between them and others in the support process. Business teams though, often deal more directly with the front end customers and so their perspective is different. They need to understand more about what their customer will see, know, be given and how they (the customer) have gotten to them.
I currently have a project where there are several front end support teams that the customer can come through to gain assistance. My main aim in this situation is to have each of the teams skilled up to the same level (or as close as possible to that), so that the customer receives the same experience no matter which group they call. This also means up-skilling the team members to be confident in their ability to provide support to the end customer. This can involve process understanding, as well as additional system change knowledge.
Defining and documenting your support model
I have found that the best way of getting each group to understand their part in the support process is to have key members of each team in a room so that we can walk through the support model with everyone understanding the hand off points and responsibilities, whilst allowing them to clarify points and ask for any additional information that they need to feel comfortable with their role in the support process.
It is then important to document this information in some form. I have sometimes used a formal report style format and other times used a Power Point presentation with diagrams. You will know your audience and the level of detail that is required.
Create a draft document and have it reviewed by everyone. Ensure that all of the hand off points and teams that need to be involved in support, see and participate in agreeing and signing off the model. They have a part to play in the provision of support, and need to be fully aware of the expectations on them to deliver support to the business and it’s customers.
Support model definition and handover are an important and necessary part of finalizing a project successfully.
If the change goes in and the business is supported, then you have achieved the change that you were aiming for.