Time to say goodbye

Setting up a project in an efficient way is not an easy task. It involves sharing the vision of the project, and ensuring that everyone is aligned and has a common understanding of how the project will be managed. It is now seen as good practice to have a kick off workshop, not only for an hour but for a day, with teambuilding and vision refinements, not only once but depending on the project duration at regular intervals.

But how things look at the end of the project? Is everyone aware of how long they will be involved in the project? What are the tasks when the project is coming to an end? When is the last working day? What will happen with the project deliverables after project closing? Who is going to ensure operational startup, when and how?

The following often occur:

Ops and Support became involved too late or not in an efficient way due to time constrains or other reasons. They have therefore not been enabled to take over tasks and responsibility.
The transfer to operational mode is not proceeding because the project team is still receiving new requests and trying to handle these.
People are happy to be contacted and needed, because there might be a certain kind of uncertainty in terms of how things are going and how much longer we will be involved in the project. Every change brings a certain kind of insecurity.
Most often, knowledge transfer and handover do not take place, but resentment due to unclear responsibilities takes over.
Sometimes the project manager simply says there is no more work and there is no information flow any longer. Project members feel dropped, not appreciated and a degree of frustration sinks in.
Something similar might also happen if project members are assigned to a new project and expectations are not aligned between the project members, and the former and new project managers.
And, last but not least, a completely different aspect: people get frustrated because of all the experiences gained from a project, as they realise that the new project is making exactly the same mistakes right at the beginning.

Based on these insights, I would like to give you 6 suggestions regarding what can be done to reduce or avoid the previously mentioned situations.

Get operations and support involved as soon as possible. With this I do not mean just invite them to the team meeting, but also ask them what their expectations about the project are and what they need in order to take over responsibility at the end of the project. Ask them for document reviews and involve them as testers. Create informal documentation of all issues and decisions taken as the basis for further reference and a handbook.
Give the transition phase a name, and define, plan and communicate this phase. Just like the development needing to be planned in advance, the transition also needs to be planned in advance. Official communication that this phase will now start and what the achievements of this phase will be help all the involved people and provide some kind of orientation.
Redefine roles, responsibilities and meetings in the team and communicate the results. With the new phase and activities, responsibilities will change. Maybe a business analyst will no longer be responsible for just requirements but also for training, and the support provided by a support team or a test manager will no longer be needed. Some tasks will be taken on by operations and no longer performed by the project team itself. Therefore, a new definition of roles and responsibilities in the team is crucial, as well as communication of the new assignments. Team meetings or defect meetings may no longer be required. Therefore, meetings to discuss existing production issues, progress within training sessions or performance and usage statistics are more relevant. From my perspective, it is better to discontinue previous meeting series and setup new meetings with new agenda and participants instead of reusing old ones, as this ensures an official shift.
Establish contact with the team members and their superiors. Sometimes team members are 'lured away' to switch to another project. This is obviously not always the case but as a project manager I recommend discussing with the superiors by when the team member will leave the current project and to what extent the person will work in the new project or can take on new tasks outside the current project. This agreement should be made between the superior, project manager(s) and team member in order to ensure that they all have the same view of the situation.
No project without any learning elements. Invite all the team members to a lessons learned meeting. Ensure that the meeting will either be split into separate ones if there are too many people involved for a common retro to be held, or get someone to help you conduct the lessons learned workshop. The workshop could be organised as a "world café". Good practice is to make the project stages visible by putting cards on the wall for each month and each event during the project duration, making collages or writing a story/poem. As a source of information, you can use the monthly status reports or your project diary. You will be amazed about what things took place (and you about which you have already forgotten) and what you and the team achieved. One important point for me is that at the end of the meeting every single participant has the possibility to write down his/her own lessons learned and take these notes with them into the next project. Maybe you can prepare some cards beforehand and hand them out as a template that they can fill in. You can also ask your team members either for feedback about your performance or if they want you to provide them with feedback about themselves. In order to ensure you are prepared for these activities, it is helpful to write a project diary and note some keywords each week regarding what happened, what was good, what was bad, what was learned and also, using your private project diary, what happened to all the team members, so that you can see their development along the way.
"Goodbye and thank you for the fish". Project managers often forget to allocate some budget for celebrating project success or having a small give away as a "Thank you" to the project members. Regardless of whether or not you have any budget for this, it is a good habit to invite your team members in advance to a project closing meeting. The purpose of this meeting is to officially hand over all responsibilities to the operations team and relieve the project team of their responsibilities. That is also opportunity to reflect on the past months and perform a project review. Summarise the findings from your lessons learned meeting and share the impressions of that. This is the moment to say thank you. Maybe with some personal words for each member, a card with some keywords about what was special about the person during the project duration, photos, etc... There are many possibilities to show recognition without needing expensive gifts or events.

As a conclusion, in my opinion a successful project closure must be prepared already at the beginning of the development phase. Documents should be updated with each sprint or iteration and each learning and insight should be documented in a way that allows it to be handed over to support and operations to enable them to solve issues by themselves. Writing some kind of project diary for the whole project might also help at the end of the project to remember what happened, what was done to solve issues and if these were successful. Just as the project has a planning phase at the beginning, it should also have a transition phase when it is coming to an end. Here I dare to make the statement that transparency provides certainty. Talk about what's going on and what the plans are, and involve all the team members and stakeholders, as you (hopefully) did at the beginning of the project.

By Sabrina Lange