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.

Creating a Document Control Plan for Your Project

Most of the projects I’ve run in recent years have involved just a few documents and all control of those documents can be handled through the use of the following:

• A version table at the beginning of the document
• A standardized file naming structure
• A document status section on the status report
• Formal signoff sheets for delivery team and customer

However, if your project is extremely large, looks like a large program rather than a project, or has a government agency or institution as it’s customer, it may be prudent and even necessary to use a formal document control plan to outline the process you – the project manager – will use to manage the various documents that will be created, reviewed, and approved during the course of the engagement. Only do this if it’s beneficial for the project and for both teams as I certainly don’t believe in doing extra work just for the sake of doing extra work. But a solid document control plan can be beneficial in the right situation.

I don’t have one of my own, so I’m including Carl Pritchard’s description of a document control plan as laid out in his book “The Project Management Communications Toolkit.” If it’s something your project needs, then I think you’ll find this information very useful.

The Document Control Plan

Purpose

The document control plan is an outline or guide on how physical or virtual documents will be managed throughout the life of the project. It provides a road map for tracking documents and for adding, archiving, and removing new documentation from the process.

Application

The document control plan is used whenever sufficient documentation exists to warrant a specific process for the control, sequencing, and maintenance of documentation through multiple channels. It is initiated to ensure that those involved with the project share an understanding of how information in the project will be managed and who will have access to which documentation at which point in time. It is used during the project as both affirmation of the process and as the means to educate others on the process application.

Content

A document control plan may consist of little more than an index of available documentation and its intended locations, or, in more ornate applications, it may consist of a matrix of documents and their owners, locations, update schedules, circulation lists, archival locations, and destruction dates. Some of the common issues with document control are evident. Depending on how the document is crafted, it may be necessary to update the document control document any time a document is updated. Such would be the case with the “Location” column, for example, because each document is called out in its most current version. By contrast, if a wildcard location is called out (in, say, an “Archive” column), then the document control plan may go for a more extended period without an update. Similarly, if team and organizational titles are identified, rather than names, the need for frequent updates may be lessened significantly.

Approaches

The document control plan can be approached in a variety of ways, including straight narrative or the tabular format shown here. There are normally extensive cross-references to other documentation and to storage repositories within the organization. Document control frequently incorporates the protocols for version control of documentation as well. This may be as simple as incrementally renaming files as new iterations are created (e.g., Document01, Document02, Document03) or may involve protocols that address authorship, ownership, or the responsible party for the latest iterations (e.g., Document01.Bob03, Document01.Bob03-Martin01). The rationale for and description of the approach(es) should be clearly delineated in the narrative associated with the document control plan.

Considerations

While project managers may be tempted to arbitrarily set the archive and destruction dates for aging documents, the legal aspects of document maintenance need to be considered. Project organizations have legal responsibilities to their clients and to their governments and regulators to maintain certain documents. The laws regarding document retention vary from region to region and agency to agency. Before establishing (and implementing) document destruction protocols, legal counsel should be sought.

A Template for Formal Project Acceptance

This article describes the Formal Acceptance Document. This is just one example – I have other templates to provide at a later date – but I will go into some of the specifics concerning the document and provide some template text for the document itself. This is primarily for acceptance of a deployed system or project, but could also be modified to provide signoff for a specific deliverable document during the project such as a test plan or business requirements document.

Formal Acceptance Document

Purpose

The formal acceptance document captures the concurrence of the customer, sponsor, and other stakeholders that the project has been completed and meets its objectives. The most common form of formal acceptance document is the customer acceptance document, acknowledging that the project has been developed as the customer originally requested.

Application

Formal acceptance is used as the legal acknowledgment that the project deliverables have been delivered as intended. It is used to certify the project as complete and to release the project organization from any future obligations. Because of the important and heavily contractual nature of the document, it is normally developed early in the project and reviewed with the customer. It is then preserved and used during the phase or project closeout processes.

Content

A formal acceptance document may be presented as a form or a letter. It will provide detail on the date of origin of the project, the project name, and the degree (if not total) of acceptance. In that the document requires a customer signature and is normally initiated by the project organization, it must be designed to ultimately cycle back to the project organization after being signed. It may reflect any interim or milestone acceptance documents that have been exchanged, but should serve as the ultimate determinant that the customer accepts the deliverables as generated.

{Customer}

This letter is to certify that all deliverables under project [name/number] have been delivered in accordance with the contract/agreement dated [date]. Interim approvals for these deliverables were accepted and signed on [dates]. This serves as affirmation that the latest and final deliverables under the project agreement have been conveyed, and we seek your concurrence.

If there are any outstanding issues or concerns that have not been addressed please alert [name] of our organization as soon as possible. We have appreciated serving you in this effort and look forward to our ongoing relationship. Please sign two copies of this letter, keeping one for your records and returning the other to us via the enclosed self-addressed, stamped envelope.

[Signature]

X______________________ (Signature of Customer)

Date___________________

Approaches

Note that the customer acceptance letter does not go into a great deal of detail about the nature of the relationship, the type of work that was being performed, the level of effort, or the specifics of the project. In a formal acceptance document, the key is to reference a primary documentation source (like the contract) and to garner the customer signature. Some customers may perceive any supplements to the formal acceptance document as contractual addenda or as their approval or acceptance of certain behaviors or performance aspects that were not specified within the contract or project agreement.

As to the choice of a letter or form for formal acceptance, the letter creates more of a sense of professional warmth, whereas forms may be perceived as cold or pragmatic. Both serve the same function, but the nature of the relationship or corporate protocols may drive the use of one versus the other.

Considerations

Because the formal acceptance document requires a commitment on the part of the customer, and because that commitment releases the project organization from further obligations (except for those outlined in the contract), some customers may use the issuance of the formal acceptance document as an opportunity to extract last-minute concessions from the project organization. It is important to note that the acceptance document reflects the project as contracted, and although organizations may choose to accede to the customer’s late requests, any major shifts in project approach or delivery may need to be acknowledged as either contract addenda or within the body of the formal acceptance document.

Closing Out the Project – Part 1

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?

In Part 1, 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 training 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.

Next

In Part 2 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?

Five Factors that Can Derail Your Project

Have you ever been running a project and you thought you had everything under control? Everything seems to be running smoothly and the customer is happy…everybody is happy….and then the wheels start to fall off. If you haven’t been there…that’s great. If you have, then you know what I mean.

Not everything is within the project manager’s control when running an engagement. The PM has their hand in most everything and can speak up to affect the outcome on most things not directly within their control, but as far as having total control over everything…not possible. However, they are still responsible.

So here I would like to discuss five factors that I’ve singled out as issues that are not directly within a PM’s control, but they can watch for them and hopefully take evasive action in time to save their project should these things begin to occur.

Starting too Soon

I’ve discussed this one before. The SOW is in hand, the schedule is drafted and the project is kicking off. What may start to become apparent is that either there are not enough requirements in place or well enough defined to really start the project, or the customer doesn’t yet fully understand the solution and how they will use it. The requirements issue may jump out at you quickly – especially during kickoff discussions. The understanding of the solution and how to use it – that one is going to take some discernment and help from your delivery team to recognize.

Watch for the signs because the deeper you get into the engagement the more apparent this is going to be and when you go to implement that final working solution, the customer is going to think you’re talking a different language if the gap in understanding has continued to widen throughout the implementation.

If you recognize it early, push to shelve the project until the customer has had more training, or reviewed requirements further, or discussed the intended solution at greater depths with their end users and business process SMEs. It’s a tough sell, but it will make everyone happier in the long run.

Revolving Resources

This is a scary situation to be in because it can be so damaging to both your reputation as the PM and to the reputation of the delivery organization. And it doesn’t really matter which side has the revolving resources. If it’s your team, then you’re constantly losing experience with the customer and this particular implementation…and that’s bad. If it’s the customer’s team, then you’re constantly losing your allies and having to start over with individuals on where things stand and bringing them up to speed. It’s a frustrating place to be in and that’s why it’s critical to run through the project team functions – on both sides – during kickoff and ensure that you have buy-in from the powers that be that there is the proper commitment to keep the key resources engaged throughout the project.

Indecisive Customer

An indecisive customer is as bad as an ill-prepared customer. If you’re running a phased project and they keep moving implementation phases around, that can affect many things on your project over the course of the engagement. It can affect when you on-board particular expertise and with resources tight, it can throw off your entire resource planning process.

If the customer continually changes their mind on requirements, tasks, deliverables and milestones, the overall affect to your project schedule can be monumental. The risks to track will mount, and the change orders will mount as well. In the end, customers who have paid for a lot of change orders are not usually the happiest customers – even if they are the primary reason for the many change orders.

Manage the customer well and keep their expectations…and their changes in check if at all possible. Set the understanding up front during kickoff that the project schedule is important and should be changed as little as possible – otherwise it is of no use.

Vague budget

Managing the budget to keep both your executive management happy and the customer happy is one of the key responsibilities of the project manager, in my opinion. Losing control of the budget is never a good thing and can easily lead to a project being canceled…which can be a career-killer if it’s the right..or wrong project.

As bad as that is, having a project that lacks a budget or has a vague budget isn’t much better. Trying to manage a budget that doesn’t really exist or is a moving target can lead to great dissatisfaction for the project manager and the customer.

I was leading a large federal project with a ‘vague’ buget of $1.2 million for the implementation. Some processes were taking longer than anticipated – mostly because the customer data was far more detailed and of a larger volume than previously understood through the exploration phase. I was also of the understanding that the budget could be increased to cover this issue. That was not the case and there was a lot of corrective action that had to be taken – even though the customer was well aware of the issues and the budget concerns.

Having a good understanding of the budget you’re managing is critical and gives the project manager much more control in keeping the project in check and keeping customer confidence high.

Flexible Project Plan

Some of what is applicable here was already covered as part of ‘Indecisive Customer’ above. However, there are more concerns with this one and it bears more discussion here.

It is critical at the time of kickoff to review the project plan in draft and discuss milestones. Get the customer’s verbal agreement at that time as to the general milestones and anticipated implementation date. And, within the first 2-3 weeks of the project, finalize this project plan in greater detail and obtain a formal customer signoff, if necessary, to ensure that everyone is on the same page with dates, expectations, etc.

A moving target project plan is nobody’s friend. You never want to be known as the ‘flexible’ project manager. If dates, tasks, and milestones are constantly shifting, then your ability to hold delivery team members and customer team members accountable to dates and tasks falls apart and you’re still left with the target on your forehead.