Sometimes it seems like projects do not want to be closed. As hard as project managers push for project closure, still project closure proves illusive. Why? I have a theory.
Problems on projects are caused by people. It is not technology or equipment or the weather. It is people. Same with closing projects. Did you ever notice that the only one interested in closing the project is the Project Manager? Look at the other stakeholders:
- The customer wants to keep the project open to get an extra feature.
- The users are afraid that if they sign off on user acceptance testing that the project team will abandon them.
- The team members are OK with the project as it gives them some security of knowing that they have something to do tomorrow. Something familiar rather than go to another project.
So you as project manager are left with resistance from everyone to closing the project.
So how to solve this? As with many other things in project management, the answer is in building upon trust. Hopefully around the end of the project, you were able to already build rapport with the stakeholders. You already have the credibility the expert power with the client, the team, and the other stakeholders. If you do, you can use this relationship to reach out to the stakeholders and address their worries and concerns about signing off on the project.
Here are some ideas to communicate:
- Remind client and users that you are still there to support them with things they might need even after the project is complete. They can still call, get support, and ask for guidance. I am not saying give them out of scope support. Instead, make sure you include provisions for support after the project is complete. It can be in the contract or purchased separately.
- Focus on the positive aspects already covered by the project and the need to close the project to get the benefits sought form the project. If the project keeps getting delayed, the deliverables cannot be used fully.
- The longer the project stays in development, the more the risk of project failure. Projects are never safe from failure until they are closed and transitioned to operation.
- Focus on the core functions, not the minor or secondary ones. Remind client and stakeholders to focus on key functions and launch product even if some minor features are not ready. This way we can get benefits from project and not wait for secondary items.
- Create a “punch list.” This is a bulleted list of things that need to be fixed on the project. Then, categorize the items into “Must fix before launch” and “can be fixed post launch” items. This will keep stakeholders focused on launching even if some minor features are not ready.
- The “punch list” cannot keep getting longer. Especially the “must fix before launch one.”Keep reminding the client that one can keep adding to the list indefinitely and work cannot be completed that way.
- Remind client and stakeholders that there can be a later version of the product. But for this specific version, we need to launch with what we have. Nothing is ever perfect and there is always room for improvement. But if we keep improving indefinitely, nothing would ever be launched.
- Negotiate with stakeholders. Do not take everything they ask for and do it. Work with them on identifying out of scope items and unnecessary items.
- Ask the client to work with you fairly. Ask them to put themselves in your shoes and ask them how they feel about a never ending addition requests from the client.
- And finally remember that the shortcuts you took in documentation, planning, and communication will come to haunt you at project closing. So proactively prepare for closing from the beginning of the project, by proactively dealing with possible objections and issues that might come up at closing.
What techniques do you use during closing to help you close a project?