Enterprise Software

10 things you should do near the end of a project

When a project is winding up, some project managers skip a few important final steps. Here are several details you shouldn't overlook when you reach the end of your next project.

When a project is winding up, some project managers skip a few important final steps. Here are several details you shouldn't overlook when you reach the end of your next project.


Depending on the size of your organization, you may treat project management as a casual practice or you may have an involved PMO. In either case, you probably go through the typical inception, elaboration, and construction phases of a project. But when it comes to the end of a project, many project managers come up just short of the finish line. Failure to handle the final steps can add confusion to an initiative and may lead to customer dissatisfaction, unhappy staff, and a project dragging on longer than necessary.

Here are a few things you should be thinking about when you get to the end of your next project. Some of these items are purely administrative, but many of them will help get you one step closer to ensuring that your project is successful.

Note: This information is also available as a PDF download.

#1: Finalize testing

Testing can be a drain on people, and many of us don't like to do it -- especially when it takes a few rounds. I have seen complex projects that were four to six months long have a day or two scheduled for testing. Not scheduling an adequate amount of testing usually ends up with problems occurring during the first few weeks of an implementation. Don't take a shortcut here and minimize the importance of testing; otherwise, you'll take on the additional risk of having a painful rollout.

#2: Finalize training

Users? Who cares about users? Well, many projects are done for their benefit, so make sure you have all your testing materials completed and delivered. Failure to do so will most likely manifest itself in the form of angry phone calls from irate users in the middle of the night.

#3: Validate deliverables

You've checked all your boxes and cleaned out your inbox, and you really think you're done. But what does your customer think? Schedule time with customers to review all the deliverables and ensure they have been met. In some cases, there may be a few outstanding issues still unresolved when you get to your scheduled end date. Early on in your project, you should have made an agreement that determines how this will affect your end date if this situation occurs.

#4: Get project signoff

After you've agreed that all the deliverables have been met, request a formal signoff on the project documentation. Doing so helps ensure that everybody is in agreement on the state of the project. Since this signoff usually signals the formal end of the project, be careful not to make your customers feel pressured into signing. If they do this without understanding what it means, you will likely end up with an unsatisfied customer if an issue arises at a later date.

#5: Release the team

Now that the project is done, where is your team going? Depending on the organization, they may be sent back to a development pool or into the business. Or maybe they need to go drum up some work for themselves within the company. No matter what it is, make sure you spend time with them and set a clear end date for when you no longer need their services. Also don't forget that you probably need to complete any performance review documents that need to be added to their file.

#6: Analyze actual vs. planned

Resources. Did you really get away with only one developer/tester for 10 weeks or did you need to scramble and get more people? What about the amount of time you scheduled for your business partners? Understanding how well you hit these targets will help you better allocate resources for your next project and set more realistic expectations when it comes to a project's duration. Budget. How much was the project going to cost? Did you come in on budget, under budget, over budget? Sitting down to understand the answers to these basic questions should give you some insight into a critical area of any project.

#7: Archive documentation

During any project, we seem to create huge amounts of documentation. It can range from scope documents and project plans to contracts and meeting minutes. Whatever it is, when you are done you should have someplace to keep it based on the retention policy of your company. You'll be glad you did when your phone rings two years from now and somebody asks you to explain the rationale behind a choice you made during the course of the project.

#8: Ensure contract closure

It's not unusual for a project to have its own budget. You also may have contracts for hardware, software, or professional services. When you're done, make sure that you verify that all the terms of your contracts have been met, request final invoices from vendors and submit them to AP, and close out any associated financial accounts, if necessary.

#9: Conduct a postmortem meeting

What types of risks did you identify and mitigate? What went really well that you want to ensure you do again next time? Have a meeting with all the project stakeholders and relevant participants to provide them with a forum to express any lessons learned.

#10: Perform a self assessment

So it's finally over. After all the hard work has been completed, you've made sure that all the i's have been dotted and all the t's crossed. Now what do you do? It's important to get some feedback on your performance from the people you interacted with during the project. If you have the opportunity to send out a 360-degree feedback survey to as many individuals as possible, I would recommend it. It will help you assess how you're progressing and will give you some great direction in deciding which personal growth opportunities you should focus on.

This list won't be the same for everybody and will depend on your organization and how it implements projects. But if you can do them, it will always make the transition to the next project smoother.

13 comments
BALTHOR
BALTHOR

Correct credit is most important.Do not let anybody steal your credit.Run down with the boss each person's assigned function.Let the boss know what you did.

pavppz1
pavppz1

Reward good performance of people involved. www.computer-answers.com

mike.mcgarrity
mike.mcgarrity

This list and comments are great! I agree that testing QA/DR needs to be built in up front, in place from the start for any systems projects. This provides the foundation for your training materials and "go live" scripts and frames your time for the implementation window. I would add an 11th item to the list, no big ROI for this one in a solid way but it sure adds to keeping our project environment/people healthy. #11.Hold a celebration and recognition meeting, this can be part of your lessons learned. Make up certificates of recognition for all your project contributors, identify the specific contribution of the individual on the certificate, have the project sponsor sign them. Thank the resource owners. All the best! Mike

rishikumar
rishikumar

Excellent and its is very useful to me. With the above check list, it will be easier to come out of a project very sucessfully. Thanks to the author

BALTHOR
BALTHOR

You might not think it's new---but---come to Papa!

Scott.Rolf
Scott.Rolf

I think a few important ones were missed: * Hand-off Production system to support team (define training and workflow) * Verify any budget variance with management * Document Contact information for vendor (sales & support) * Verify backups (and their size, growth) are as expected * Add any critical systems\services to the automated monitoring\alerting system (Openview, Nagios, etc.) * Document baseline performance for future comparison * Identify support team workflow (Who gets called, and in what order, when things don't go well.) * Modify following years operational budget to include support, service or maintenance fees. * Get user feedback and start a knowledge base of issues

Bill Stronge
Bill Stronge

My post highlights some of the normal things many of us should be thinking about when we get near the end of a project. But there are lots of other things that need to get done as well. What about you? What do you think is important to cover when you get near the end of your projects?

CultOfTech
CultOfTech

This post definitely deserves kudos... for its high-lit the most often overlooked (and obviously most under-rated) aspect of Project Management - celebrating closure & according recognitions due. Please note, there IS a tendency to try & bucket these events as part of the actual Project Closure phase; quite obviously, a more formal performance appraisal process would come under this. However, the REAL deal - setting up a REAL party, arranging for & giving out the certificates/trophies of recognition/merit is best handled once the ink has dried upon the formal closure documentation. .. of course, there's always the counter-point that a lot of organizations may just be so darned busy, the moment the project team is disbanded, all resources disappear into other projects/initiatives!! So it MAY make sense to include the aforementioned events as part of the formal Closure process. Bottom-line: everyone loves to celebrate collectively!! ;-)

Laurie.Harmon
Laurie.Harmon

Many software projects require building Disaster Recovery (DR)into the design if possible. If the app is Tier 1 and critical to the business, DR & BC plans should be written, tested prior to going live. Business Continuity plans should also be written and exercised with the business. Of couse these things should be worked into the plan long before ending the project.

Laurie.Harmon
Laurie.Harmon

Many software projects require building Disaster Recovery (DR)into the design if possible. If the app is Tier 1 and critical to the business, DR & BC plans should be written, tested prior to going live. Business Continuity plans should also be written and exercised with the business. Of couse these things should be worked into the plan long before ending the project.

alan.radlett
alan.radlett

Sounds like Scott has actually been there and done it. Certainly prepare a hand-over pack for the support group whether its a system, network or even a new facility. They need to know all the wrinkles of the project deliverable to be able to hit the support ground running.

thomas.ratliff
thomas.ratliff

Schedule that post-project review 6-12 months after completion. This is more than the quick feedback loop, (e.g. "how did we do?") it intends to measure the expected return against actual. Assessing the output / deliverables of a project after they have been in place for a period of time identifies new priorities for any outscoped components and gives a more accurate picture of the success.

CultOfTech
CultOfTech

While I definitely agree with most of what is in this post, I'd like to point out that "testing" and "training" essentially form part of the very execution (if I may use PMI terms..) of the project itself. So to include these two as part of your 10 things you should do near the end of the project makes me wonder - are you referring to the closure (again PMI speak) phase? IMHO, including testing and training as PART of the main project SOW is only fair to the client... would you like to get a product/service that is neither tested to be up-to-spec, or not be aware how to use it?