Five Key Steps to Closing Down the Project

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

A lot of text and attention is given to how to start projects, and how to run projects. But process of properly closing down a project is overlooked. Why? Well, since I can say from experience that I’ve been guilty of this in the past, here are my reasons, at least:

• Implementation and transition to support happened so moving on seems reasonable
• Have 4-5 other projects I’m also managing
• Just received a new, hot project and I’m preparing for kickoff
• Problem-free implementation means no worries, right?

Look at that list…none of them are good excuses for just basically dropping the ball – and the customer – post-deployment. Things still need to happen, proper hand-offs may still need to be taken care of, information needs to be transitioned. It will happen anyway through frantic phone calls and emails, so why not take care of it in an organized fashion? Because we say we’re too busy…but that needs to change.

Here are my list of five key activities that should happen to ensure proper closure of the project you’ve just finished. Your list may differ and I’d love to hear from you if it does. Feel free to comment and share with our readers here on PMTips.

My list:

• Make sure all pertinent documents and deliverables have been signed off by the customer. You don’t want this coming back to you after the project is over – especially if there are any question marks our payments outstanding.
• Get a final signoff on implementation/solution acceptance. You may have the best relationship in the world with your customer, but don’t skip this step.
• Conduct a lessons learned session with the customer and your team. The information you glean from this type of session can be invaluable to you as a project manager going forward, to your customer as they go forth with the implemented solution, and to your tech support as they provide the ongoing support for the solution with the customer.
• Hold a proper handoff to tech support. Make sure they have all necessary information in order to properly support the client post-deployment.
• Keep in touch with the customer post-deployment. You may have a 30 or 60-day agreement to remain available to the customer and for your team to remain available before the formal transition to tech support. But don’t just drop them at that point, keep checking back. It’s good for your reputation with the customer and for your company’s reputation.

Implementation Preparation

As the delivery team plans for deployment, or implementation – depending on what you prefer to call it, there is much preparation that must occur. How you prepare for your particular project depends on several things including the following:

• Customer requirements
• Type of system being implemented
• Policies and processes of your organization
• Logistics of customer, delivery organization, and implementation site

Personally, the type of implementation prep that I go through with my team is dictated heavily by the needs of the specific implementation and what was planned for and laid out as part of the statement of work and the kickoff sessions with the customer.

In his book “Project Management Nation,” Jason Charvat discusses his vision of typical implementation planning and preparation. While I don’t specifically endorse this process and understand that your specific situation usually dictates how implementation is handled, I believe that this is helpful and useful information.

Implementation Checklist

The project manager must be sure that the implementation follows the implementation tasks and activities as stated in the project schedule. This forms the basis against which the implementation will be done. Generally, the tasks would be to:

• Load or install the new system
• Perform a system test
• Convert to the new system
• Verify that an application works with other applications in the system
• Perform an integration test
• Perform an acceptance test

The Implementation Plan

The implementation plan, which was developed by the project manager during the design phase, should, at this stage, be approved and communicated to all project stakeholders. A successful project can be ruined by a poor implementation plan. A working implementation schedule should be developed and maintained for all parties to use and agree upon. As the project changes, the project manager must pay close attention to the schedule and update it to reflect the latest changes to the implementation date. This schedule should then be communicated to all project stakeholders.

It is important to publish an initial implementation schedule for each site early in the project. Many members of the deployment project team will reach a point where they cannot until they know the time, sequence, or date of the implementation. Experience has shown that developing a draft implementation schedule early in the project life, rather than later, resolves many problems. The project manager should remember that the implementation plan could be put on hold if the software development is late for whatever reason. However, if the implementation plan cannot be moved and there is no slack in the schedule, the project manager should immediately escalate this risk to the necessary stakeholders.

Meetings Leading up to Implementation

The implementation plan must be discussed and agreed upon by both the user management and IT support staff in order to ensure that both parties plan their work schedules to match the project schedule. For the majority of IT projects, implementation will most likely occur after hours or over weekends, during a series of working hours per day, or on public holidays.

The Onsite Visit Progress Report

Here’s a template that may or may not be applicable to your project situation.  I’ve only had to use it a couple of times because, in general, the regular status report will usually suffice.  The topic: The Onsite Visit Progress Report.

This type of document is not really meant for routine customer onsite visits.  I would never use it for an onsite visit to kickoff a particular phase of the project.  You could, but I believe it would be overkill as that is just routine activities and is covered both by the project schedule and the project status report.

However, if you must go onsite to the customer for some corrective-type action, then it is entirely possible that a communication mechanism such as this document may be your best way to get down in writing what you plan to do, what you actually accomplished and problems that were encountered.  This will help justify what work you performed, the hours expended, etc. as you get further down the road and need to justify budget overages to your executive management and/or your customer.

For me, it was very helpful to use when I had to take a team onsite in the middle of a the development phase to break through some barriers we were experiencing due to some requirements confusion.  It was helpful for our team to have the purposes and outcome documented, and it was very helpful for the customer and for my management to see the progress in a separate document from the regular formal status report.

PROJECT ONSITE PROGRESS REPORT

[Save file name as: client name ONSITE PROGRESS yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

TRIP OBJECTIVE

Provide a brief description of the onsite objectives. (1 or 2 sentences)

PROGRESS

Provide the progress notes from the onsite visit.

PLANNED

Provide a list of the planned activities for the next visit or to be performed remotely that have been taken away from this onsite visit along with expected completion times (List of action items to be addressed).

ISSUES

Provide information on issues encountered during onsite visit along with items to be addressed by vendor and client.

Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work performed.

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.

Kicking Off a Small Internal Project

Fundamental project management is basically the same across all projects, but how much formal project management practice goes into it does depend a lot on things such as overall timeframe, budget, internal vs. external project, and project criticality and visibility. Let’s face it, these all play a role in how much effort is allowed to go into a project…budget being a huge player.

For small, internal projects that aren’t very visible, aren’t very critical and don’t involve an external revenue generating customer, the circumstances for managing the project and the effort that goes into it are going to be fairly small. For the purposes of this article, I’d like to use Michael Thomsett’s description of how a project manager might kickoff an internal project as described in the Project Announcement Meeting section of his book “The Little Black Book of Project Management.”

I do not necessarily agree with or endorse the information set forth in this article, but I do find the information helpful and it is undoubtedly useful information given the right situation. In a future article I will submit my own viewpoint on the processes for getting a small internal project underway.

The Project Announcement Meeting

Getting your project off to a healthy, well-defined start depends on your approach: how you lead, how you seek definition, and the initial organization of the team, schedule, and budget. But it’s also necessary to communicate your purpose and approach to your team. Thus, a project announcement meeting is essential.

Do you really need an announcement meeting? It may be possible to set the tone and define your purpose without gathering people together; but a preliminary meeting can save a lot of time and effort later, and can help avoid misunderstandings about authority levels and the nature of the assignment.

Example: An accounting manager was assigned the project of setting priorities for automation. The task included interviewing the heads of each department and recommending routines that should be given priority. But the department managers were not advised of the project. The accountant found these managers to be defensive and suspicious; they weren’t sure whose idea the project was, the accountant’s or top management’s. A great deal of effort went into explanation, and the project proved difficult to complete.

This project could have been executed more efficiently if an initial meeting had been called. The accountant and each department manager should have been invited, as well as the executive who made the assignment.

If an announcement meeting is not called at the time a project is assigned to you, recommend calling one. The executive should briefly explain the purpose and objective of the task and clearly identify you as the project manager. Once everyone understands what you’ll be doing, it will be easier for you to organize your project team and contact the resources you’ll need. Most of all, a brief meeting will help avoid your having to explain what you’re doing and why, or having to deal tactfully with other managers who have not been informed about your project.

Support your recommendation for the announcement meeting with these points:

• Announcing a new project defines it for everyone involved, and clarifies the intended purpose. If the meeting is not held, definition will be a problem each time you have to contact a resource.
• The meeting helps ensure success, because everyone gets the message at the same time and from the same authoritative source. Your ability to lead the project team is aided when the project is launched from the top.
• A demonstration of executive support for the project manager helps the team to achieve its goals. However, it’s important to let others in on the decision when they or employees reporting to them will also be affected, either as a team member or as a resource for the team.

If you have identified your project team by the time the announcement meeting takes place, each member should be invited along with individual managers or supervisors of their departments. Introducing the project to everyone—team members and their supervisors—makes your job of working with other departments much easier.

There’s a significant difference between trying to achieve a project task that conflicts with departmental goals and working with other managers to resolve problems. Inviting the managers to the initial project meeting makes them feel included in the process. That sets a positive tone and helps you to function as project manager. The alternative is having to continually struggle with a manager who was left out of the decision-making process at the beginning.