Useful strategy documents - part 4.
Finally I have reached my latest post in the useful strategy document series.
Now I would like to talk about the
- going live procedures
- handover/takeover criterias
- acceptance/goal criterias
Why are they so important? Because they could be the most important documents near the going live milestone. It's very important for both side, for the solution provider as well as for the customer too.
Usually what happens on a project? At the first phase of a project lots of people sit together to plan the whole project, the resources, the timeline, the milestones etc. Once the project team decide when will be the Going Live Date (GLD) then ones modify again the whole project plan to ensure that all design, all implementation, all develop, all test step will be finished until that point. So we plan everything but we usually create plan only from one viewpoint, from the first step viewpoint. What I mention is to create new viewpoints and create plans for these viewpoint then merge all plans into the final project plan.
Usually what happens on a project? At the first phase of a project lots of people sit together to plan the whole project, the resources, the timeline, the milestones etc. Once the project team decide when will be the Going Live Date (GLD) then ones modify again the whole project plan to ensure that all design, all implementation, all develop, all test step will be finished until that point. So we plan everything but we usually create plan only from one viewpoint, from the first step viewpoint. What I mention is to create new viewpoints and create plans for these viewpoint then merge all plans into the final project plan.
What are these viewpoints?
- What steps should be done near GLD, how will the project's outcome go into production?
- How will done the takeover, when the solution providers team member give all maintance responsibilites to the customer team members.
- Who and how will accepted the outcome.
So let's go through them
This document is what never has a final version. You will make an initial version and continuously develop it during the project as the whole architecture, system requirements, design etc are changing, evolving.
What I mean on this document? This document should contain all necessary technical, functional, business etc steps and procedures what the team should on the going live day(s).
It's quite good practice to create a diagram to represent all necessary step, all stakeholders, all branches. Usually I use the MS Visio cross function flow diagram and it's pencils. Rows are the stakeholders, the participants, I use boxes for the procedure steps, and arrow lines for representing the flow, the connections between the steps.
If you don't plan these then at the takeover time there will be gaps between the teams, there will steps that nobody want to perform because they thought it will be done by the other side. So I strongly mentioned to discuss and document the whole takeover technical procedures and criterias much earlier than the GLD.
I have already talked about it in the previous post, so let me copy paste a part from it to here with some extra general notes.
What I mean on this document? This document should contain all necessary technical, functional, business etc steps and procedures what the team should on the going live day(s).
It's quite good practice to create a diagram to represent all necessary step, all stakeholders, all branches. Usually I use the MS Visio cross function flow diagram and it's pencils. Rows are the stakeholders, the participants, I use boxes for the procedure steps, and arrow lines for representing the flow, the connections between the steps.
Handover/takeover criterias
What are these criterias and why are they so important for me? We already decided all necessary business steps, all acceptance criterias, but we didn't plan the deep technical step during the takeover. What technical steps should be done, what steps should be done by the project's maintenance team, what the customer's team. When will be transfered all maintenance responsibilites to the customer side.If you don't plan these then at the takeover time there will be gaps between the teams, there will steps that nobody want to perform because they thought it will be done by the other side. So I strongly mentioned to discuss and document the whole takeover technical procedures and criterias much earlier than the GLD.
Acceptance/goal criterias
I have already talked about it in the previous post, so let me copy paste a part from it to here with some extra general notes.
Elementary necessary information for a successful going live. If you didn't know how will the customer/key users accept the project's output, you couldn't prepare for. If you didn't know how will the measurement done, what the customer will measure during the acceptance process, what key users viewpoints should be exactly satisfied then you will never know that you have already reached the goal or not.
If these criterias wasn't well defined at earlier phase of the project then probably you will never reach acceptance for the whole project outcome, only for a part for it and it means that a neverending story could begin. Don't you have a dejavu feeling? Going forward to reach new acceptances for other parts of project's outcomes in a continously changing project space, where the requirements begin to change, the customer key users begin to use the parts, with many, many bugs and continously growing dissatisfaction. A Nightmare, isn't it?
If these criterias already available and accepted by the key users then you should reflect them in the going live documents too. You have to draw up how the going live steps will ensure that all acceptance and goal criterias will be satisfied, fulfilled.
There is a big common set between the these criterias and the TOGAF critical success factors. Of you have already has CSFs than you should just rethink that are there any other special acceptance criterias that the project should satisfy during the implemention phases.
If these criterias wasn't well defined at earlier phase of the project then probably you will never reach acceptance for the whole project outcome, only for a part for it and it means that a neverending story could begin. Don't you have a dejavu feeling? Going forward to reach new acceptances for other parts of project's outcomes in a continously changing project space, where the requirements begin to change, the customer key users begin to use the parts, with many, many bugs and continously growing dissatisfaction. A Nightmare, isn't it?
If these criterias already available and accepted by the key users then you should reflect them in the going live documents too. You have to draw up how the going live steps will ensure that all acceptance and goal criterias will be satisfied, fulfilled.
There is a big common set between the these criterias and the TOGAF critical success factors. Of you have already has CSFs than you should just rethink that are there any other special acceptance criterias that the project should satisfy during the implemention phases.
Nincsenek megjegyzések:
Megjegyzés küldése