9 Questions to Look at When Closing a Project Successfully

When you've reached the end and deployed the solution, then it's time to make sure everything has been completed, all paperwork is done, and no stones are left unturned. It's best to do that with some sort of checklist and I propose using a list similar to this:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?
• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?
• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

For start, we'll discuss the first three items above:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?

Have all the project objectives been achieved?

This should be fairly easy to evaluate. Look at the project schedule and review all milestones and deliverables. Have they been met? At this point, we're not considering timeliness or budget, we're just concerned with did we hand the customer what we said we would. Did we supply a Functional Design Document, did we provide weekly status reports, was completed successfully and signed off, was user acceptance testing (UAT) fully completed including re-review of all issues and did we get official signoff, etc.

Though it definitely shouldn't be the first time during the engagement that you do this - it's also a very good time to go back to your kickoff session notes and see that all points discussed during that meeting have been addressed. Make sure at this point that the customer knows you're concerned that you fully covered everything for the project - they'll appreciate it and it definitely helps with customer satisfaction levels and can increase the chances of repeat business from this customer.

Is the client satisfied with the overall project?

You may think you can simply answer this yes or no based on your knowledge of how things went on the project and the communications you had with the customer along the way - but that is not always the case. On some projects, you can end up being very surprised by the customer's on viewpoint of their satisfaction levels.

I've had customers on projects that went extremely smoothly later state that they weren't happy about how I handled something or weren't pleased with one of my team members or how we delivered 'x' deliverable. And I've had other projects were I was certain the customer was just about ready to ask that I leave the project only to find out that they were very happy with me and with the team and how things were going. They were just demanding and somewhat needed. But we were meeting their needs and they were happy. It's amazing how off your perception can sometimes be concerning your perception of the customer's satisfaction level and what their satisfaction level truly is.

Have the necessary post-project support agreements been established?

Usually you'll move from deployment into a post-deployment with some sort of pre-defined plan to both hand-off overall support to your tech support group but also you'll agree to make your original delivery team available for a 30 or 60-day window to do immediate fixes should problems arise in the functionality of the delivered solution. That's something that just needs to be worked out with the customer and something that was likely planned for both by Sales with the customer during the sales process and discussed between you and the customer during kickoff.

Just make sure that whatever the plan is, you act on it. If it's to keep your team available for 60 days should problems arise, then make sure that every team member knows that and that each of their managers know that as well. It can have an affect on their next assignments, but it must be addressed in advance of deployment.

We'll further discuss these items in terms of the project closeout checklist/review...

• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?

The key to closing a project successfully is to plan in closure from the beginning.

So what should you be planning during the early stages of the project to give yourself the best possible chance of a successful close? Think about support What plans are you going to put in place for supporting the deliverables of your project? For example, if you are delivering a new software system, what is your approach for support for users going forward? Add the support tasks to Seavus Project Viewer or whatever scheduling tool you are using, as part of a final project phase called 'Closure'. Consider:

• What support function will pick up the ongoing maintenance and queries?
• What user guides or manuals produced as part of the project will be handed over to the support function?
• What other project activities will you be doing throughout the life of the project that would create useful information for the support function?

Involve the support people early Once you have identified who will be the recipient of the deliverables, start involving them in the project. It is a lot easier to pick up the support for something you know a little bit about - and the support team will be much more willing to accept the handover if they have been involved throughout the project. Consider:

• How will you involve the support team?
• What role will they play in the project?
• What time commitment do you need from the support people between now and the time that the project is officially handed over?

Organise your documentation A lot of your project paperwork will be handed to the support team, so make sure you have plans to keep it up to date and organised. Plan in regular review sessions. Put in place a good configuration management system so you always have access to the latest documents. This will mean that you can easily find the latest, most recent copies of documents at the point that you need to package these up for the support team. Consider:

• How will you organise and archive your project documents?
• Are there any other text-based project artefacts like a wiki that would be useful to handover to support?
• How will you identify what documents would be useful for the support team? Will you tag wiki entries with 'support' or 'handover' to make them easier to find later on?

What does 'closed' look like? Start thinking about what 'closed' looks like early in the project. There are some straightforward things that equal 'closed' such as making sure all tasks are completed, all issues are resolved, all risks have been mitigated or accepted and closed. But what else, specific to your project, will mean that the project is closed? Consider:

• When will you issue a final project communication about project closure?
• Who will the final project communication come from?
• How will you help the project team transition to new projects?
• What will you do if you can't close all actions, risks and issues? Who will pick up anything outstanding?

Finally, consider how long the closure phase will last. Don't underestimate the amount of work required to wrap up a project adequately and hand it over to support. Admittedly, the work will tail off, so you can start picking up other projects during the closure phase.

We started the process of covering some critical questions to ensure all of the project 'i's are dotted and 't's are crossed. The list can be much longer, but I'm choosing to cover 9 basic questions to look at when closing your project. We've covered the first three - now we'll cover items four through six:

What were the major concerns with the project?

No matter how perfectly a project goes, there are always concerns. You may have been able to mitigate whatever issues came up, but they still happened whether they knocked your project off course or not.

What we want to do here is document what those major issues or risks were. They key questions to ask during this process would be:

• Was the concern anticipated in advance (meaning was it something your team or customer foresaw as an issue or risk and thus you were already looking out for it)?
• Did the concern end up affecting the project adversely in terms of time, money, resources, or progress?
• Did it affect customer satisfaction and if so, in what way?
• How did you react to the concern and was your action the appropriate one in hindsight?

What are the key lessons learned from the IT project?

For this activity, it's most beneficial to sit down with the customer post-deployment and formally discuss and document lessons learned. This is somewhat similar to reviewing the major concerns in the previous question, though this one is best done face-to-face - or by phone - with the customer as their insight will be invaluable...and is critical feedback to have. As I've stated before, your customer may have been unhappy with things and you had no idea - and now will be your opportunity to find some of those things out and understand how to better react in the future.

What would you do differently?

Knowing what went right and what went wrong, how the project turned out and how your customer feels about it, now you can look at what you would do differently in the future. There may even be other opportunities with this customer and having a plan for a different course of action on specific issues that arose on the engagement can be an invaluable piece of information going forward.

Re-review the issues and risks faced on the project and asked yourself and your team - did we react appropriately and, if not, what should we have done differently. Chances are, the issues will show up again in another project and you'll be ahead of the game. If we don't learn from our mistakes, we are destined to repeat them.

We'll further discuss these items in terms of the project closeout checklist/review...

• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

So far, we looked at the things you should plan in advance - basically, when the project starts - to help you close the project. What happens if you didn't do any of that, and you are now approaching the close of a project and you are just starting to think about closure activities? Don't despair, you can still close your project adequately. Let's assume you are working on a project with the duration of a year and you are two months away from finishing. What do you need to do? First, get the project team together for a session about everything that is outstanding. During the meeting, set the scene and explain the objectives. These could be:

• To recap the scope for the project
• To establish what 'closed' looks like - essentially, success criteria for closure
• To establish what tasks are required to close the project that are not on the existing plan
• To establish the timeframe for closure.

As the project manager, you may already have an idea about acceptable timeframes for closure, so make sure to mention these. Explain any other constraints as well. Work through the objectives, gathering input on every point from the project team. You will hopefully end up with a lot of information about what is still outstanding and what specific closure activities are required before the project can be adequately handed over to support. Document all the output in iMindQ, on flip chart paper or in any other way that makes logical sense to you and the team.

Who is going to do it? Once you have a list of things to do, these need to be mapped against existing responsibilities and tasks, other project commitments and the resource profile of the team generally. Consider holidays, planned training and so on. Essentially, plan this closure phase exactly as you did the rest of the project, and resource it in the same way too. What are the support agreements? Talk to the people who will be providing the support ongoing - involve them in your planning meeting if you can.

What do they need from your project team to be able to accept the deliverables into support? Who will manage the financial information? If your project involves a third party, such as a software vendor, it is likely that there will be ongoing costs. These could be licences, maintenance fees, subscriptions, escrow agreements or other ongoing contractual obligations. Someone (not you) needs to pick these up and be responsible for them on an ongoing basis. Once you have found out who will be doing this, schedule some time to sit with them and do a full financial handover. Explain what has been agreed, what still needs to be agreed and anything else they need to know like whether the maintenance fees increase with inflation, for example.

How long will it take to close? If you didn't factor in the work required to close the project when you did your initial planning, you might be surprised at how long this handover and closure phase is going to take. Negotiate an extension to the project if necessary. You can probably run the closure phase with a skeleton staff, so this will make it cheaper. If you don't complete a proper shut down and handover, the deliverables will end up costing more in the long run, and you'll never be able to make a smooth exit from the project. Explain to your project sponsor that the clean and professional way to ensure a good transition to support is to invest the time now. This will also help embed the change and make the project deliverables 'sticky'.

Do you feel the solution was cost effective?

Here's your chance to analyze the solution in words in financial terms. And we're not really talking about budget here, but that's a big part of it. In hindsight, did the engagement:

• Utilize the best level of resource skills and thus use resources in the most cost effective-way possible.
• Should Phase A really have been implemented first as the customer required, or would it have been a more sound business decision, in your opinion, to implement Phase B first?
• Is the final solution meeting the customer's needs in the most cost effective manner possible? Would certain enhancements or different requirements have resulted in a more cost effective solution?

The list could be long, but I think you get the picture. Ask yourself the tough questions and imagine this isn't for the customer to see. In fact, imagine you ARE the customer on this one but also have your additional insight.

I'm not saying you can't involve the customer on this one - you certainly can - or you can perform it separately with your team and then with the customer and compare results.

When would it be applicable to enhance or update the delivered solution?

You've probably had an eye to the future all along and you've probably already discussed some key points along the way with the customer - especially if the project was a successful one and the customer satisfaction seems high. That's what a good project manager does.

Think about ways you can provide new and future services to this customer and certainly keep in contact with them post-implementation on future product capabilities that you feel they will want or can benefit from.

What is your executive leaderships view of the project outcome?

This one is important to your career. No question about it. How does your leadership feel about the project? This likely will come more from leadership's discussions with the customer than from your discussions with the leadership. And it should.

If it was a visible, critical project, you know that they've been in communication with the client along the way and if anything has gone wrong, they've heard about it. They're not as likely to hear about the successes, but if you think the project has gone well, encourage your CEO or other leadership to follow-up with the client and discuss the outcome with them.

Summary

We've covered what I consider to be nine key questions to review once your project has been implemented. Most are for you and your team, some should also include the customer. But be sure to perform some sort of post-implementation checklist like this. You'll benefit from it as a project manager, your team will benefit from it in learning what went right and what went wrong, and your organization will benefit from it - especially if you can share the successes and the lessons learned with others in the organization.

If you have other key points or questions to add, please comment.