During a project’s life, it will probably undergo a lot of up and downs. The value to be created from project completion often keeps the project afloat, but what happens after the project owners approve its release and leave the room? Projects often need to be updated after the original project owners leave
the scene. The better the transition plan, the easier it is to avoid flatlining a project’s value because no one knew how to update its content. In situations where the transition plan was not sufficient or non-existent, all project value could be lost.
Does this apply to all projects? I would say it applies to some more than others but rarely does it not apply to a project at all. Obviously projects that need a solid transition plan would include process modeling and documentation. These projects are bound to change as new processes are introduced and new information is needed to be documented. Less obvious projects may include software development projects. Some may say that after the new functionality is implemented – there is little that needs to be transitioned. What about the models and requirements that were defined for the project? Surely this will not be the last time that this software will be updated and there is a chance that the functionality may call for different process steps than previously defined, after it is fully implemented. Not updating this documentation could leave new team members confused and could slow down the next system update.
So what is a part of a good transition plan? Considering that everyone learns differently, I would say multiple transition formats can mitigate the risk of losing value after completion due to lack of understanding how to keep it a “living” document. Here are methods I have used:
- Instructions: Probably the most used form of transition documentation, which is simply just writing out the steps that will need to be taken in order to update or create documentation.
- Examples: Provide completed documents that mimic exactly what will need to be filled out for new processes later. Using the exact form will allow future users to see what information should look like in any new forms that were created.
- Form Explanations: In conjunction with examples, a document that textually describes how to fill out a form could provide additional clarification or act as a quick reminder in the future. This could simply be done by mapping a field on the form to a description of the field.
- Training: Host a training course on how to fill out or update forms or models. This will allow those who will be in charge of these processes in the future to see how it is done. It will also allow time for any questions to be answered.
- Recorded Training: Taking training to a whole new level. This is a simple task that could significantly improve the value created from a training session. If the presentation and question/answer session can be recorded, then it can act as a future reference for newcomers and can considerably reduce the risk of losing the information. The easiest way to do this would be to use a conference client (Webex, Gotomeeting, etc.) and just have it record the screen and conversation in the background.
- Pre-Release Practice: Before the project owners leave the project, they could allow those who will be taking over after release to contribute to the project. This would include having them participate in filling out forms and updating models beside the project owners. Similar to on-the-job training, it would allow for the future users to get experience and ask questions from those more familiar with the processes before they are required to do it on their own.
- Transition Model: Develop a model specifically associated to when or how documentation should be used, which I often refer to as an action plan. Recently, I used this on a project to determine which UAT tests should be run based on what changed in the system. Decisions that resulted in change were tied to test scripts that should be run.
These are just some examples of what I have used on my previous projects. The key takeaway from this is to at least have a transition plan for aspects of current projects that will need to be updated in time. Not having a plan could prove to be detrimental, or even fatal, to the project after it is in production.
