Happy Endings - Project Management

I don't know about you, but I like happy endings. When I'm closing in on the last chapter or two of the novel I'm reading, I want things to work out. I want the guy to get the girl, I want the bad guy to get caught, and I want the revenge to be sweet. I feel the same way about my project endings. Especially the revenge part…all those stakeholders who thought the project would never be successful. Ha! We fooled them. Oh…um…back to project closeout.

We started off our study of project management by stating that a project is considered successful when it meets or exceeds the stakeholders' expectations. This means that the deliverables have been completed, the requirements met, and the budget and schedule followed closely throughout the project. It also means that you've applied good project management techniques and communicated with the stakeholders throughout the process.

Everything we've talked about up until this point will help you meet or exceed customer expectations at the end of your project. As we've stated many times, project planning and communication are the two biggest allies you have in your camp. When you fight the daily project management battles with a good plan as your foundation and you have the ability to communicate honestly and can resolve conflict, you can conquer the world. (Okay, maybe not the world, but certainly your next project!)

Details

The Closing process is often hurried through at best or skipped altogether. Closing has several purposes that will help you on your next project. Here you'll get formal project approval of the product or service of the project, close out the contracts, pay the vendors, and close out the financial records for this project. You'll file away the project documentation for future reference and take some lessons learned from this project with you to the next project. You'll also take one last look back and examine the work of the project and make sure everything is complete.

project approval

Verification and formal acceptance of the product or service of the project.

Remember the checklist we started with in Chapter, "Building the Foundation"? Table below shows an updated version of that checklist, with some new items added that we've learned about throughout the course of this book. Use this checklist to help you manage your next project through the project life-cycle phases.

Table Project process check list


This checklist shows the primary documents you're responsible for creating and the processes you'll follow throughout the project life cycle. All the Executing, Controlling, and Closing processes have now been added to the list. You can use this checklist template when starting your next project as a reminder of the important documents and activities you'll need to complete as you manage the project. You should periodically review this list throughout the project to make certain that you've covered all the bases. It also serves as a good reminder or reference for what's to come, so you should review the checklist as you approach the end of each life-cycle phase to remind yourself of what needs to happen during the next process. File this checklist in the front of the project notebook, and use it as an informal measure of your progress throughout the project by checking off each process as you complete it.

You can see from the list that we have several things left to complete in the Closing process. The first item we'll talk about is closing the accounts and finalizing the contracts. We'll deal with the remaining items throughout this chapter.

Closing the Accounts

When the project is completed, you'll want to make sure that the accounts for the project are closed so that no more spending is charged against the project budget. Your accounting staff or finance manager usually does this. We talked about the unique account identifiers or codes associated with the WBS elements back in Chapter , "Breaking Down the Project Activities." These codes associate the accounts with the project budget and were used by the accounting office to track expenditures. When the finance manager closes the accounts, the codes are closed out also, and no additional charges will be approved against the project's code of accounts.

Tip:Stop runaway charging and over-budget conditions by closing the project accounts when the work of the project is completed.

If you're working on a small project, you're probably the only one approving orders and invoices, so you'll know when to stop charging items against the project budget. But large projects may have several approvers, or your finance manager may be the one who has managed the budget throughout the project. Make certain that you formally communicate to them that the project is over and the books should be closed out so no more spending goes against your project.

Finalizing the Contracts

During the Closing process, contracts are finalized and closed out. When projects are completed under contract or you've used contract help to do the work of the project, you'll want to verify that the work of the contract was completed accurately and satisfactorily according to the terms of the contract prior to closing them out. Review the contract and the statement of work, and compare them against the project outcome to make certain that all the requirements have been fulfilled. This should be a fairly easy step because you would have monitored the work of the project and requested that the vendor make corrections when needed during the Controlling phase. Now you'll make one more pass through the SOW and make certain that none of the requirements have been missed.

One of the most important activities you'll fulfill during this process is the formal notification to the seller that the contract is complete and the product or service is satisfactory and accepted. This notification should be put in writing. If the product or service doesn't meet your expectations, inform the vendor that there are outstanding issues they need to resolve before you can issue a final acceptance notice. This usually happens in the Controlling process as you monitor and measure the project outcomes and at that time notify the vendor of problems. Sometimes, though, you don't have the final product until the Closing phase. If that's the case and the product isn't acceptable, let the vendor know as soon as possible.

Be aware that some contracts have specific conditions or terms that you must meet in order to close out the contract. Review the contract, or ask your procurement department to make you aware of these conditions, so that you can fulfill the requirements of closeout and don't hold up the project.

Breaking Up Is Hard to Do

As the project comes to a close, you'll release team members back to their functional duties or to assignments on other projects. This will likely happen slowly and may even begin in the Controlling phase as tasks are completed and approved.

This process involves good communication on your part. You'll want to keep the functional managers informed prior to the release of team members so that they have a chance to prepare for their return. If the team members are being released to another project, let the project manager know the dates the team members will be released. This gives the other managers time to plan activities and schedule due dates for activities for the new work. Start informing the managers about four to six weeks prior to the team members' release, and keep them posted as you approach the date for their return.

Warning:Watch for signs of project slowdown toward the end of the project. Team members may not want to move on to new assignments and will try to extend the fun on the current project by making up problems or delaying final due dates.

Team members may begin to drag their feet as the end of the project approaches. Keep an eye out for this situation, especially with teams in the performing stage. They've formed friendships, are committed to the goals of the project, and are generally having a great deal of fun doing the work of the project. As the end approaches, they know that the camaraderie and the synergy they've created as a team are coming to an end. This may cause them to slow down their work in order to prolong the project and postpone their reassignment. Communicate openly with the team during this time, and let them know how valuable their work has been on this project. Assure them that their new assignments are important to the organization and that they'll have many opportunities to form relationships with their new team members. Remind them that they'll have a chance now to educate others in the organization on how good teams function and that they'll have the ability to help form great teams in other parts of the organization because of their experience on this team.

Prior to sending team members on their way, you should write up performance reviews and hold one-on-one meetings with each team member to discuss their performance on the project. These reviews will be given to their functional managers or to their new project managers and will become part of their over-all performance rating for the year.

Training and Warranty Period

Have you ever brought home a new gadget or appliance you couldn't wait to try out? It hums along fine the first day or two and then quits, right when you need it most. "Thank goodness for the warranty," you think. Project warranties work the same way.

Some projects, particularly those in the information technology arena, require that some of the primary team members remain assigned to the team, or at a minimum are available for assistance, for a specified length of time after the project is completed and turned over to the customer. This time period is called the warranty period. (Some vendors offer warranty periods on their work as well.) It's inevitable that problems will creep up on newly written programs or newly installed hardware. The idea is, as the user works with the new programs or hardware, they can report problems to the team and have them addressed immediately during the warranty period. This is not a time for the team to work on additional features or enhancements. The warranty period is for bug fixes only, and once the warranty period expires, problems are prioritized and handled according to the organizational policies designed to handle day-to-day problems.

warranty period

A period of time when the stakeholders can notify the team of problems and have them corrected immediately.

Note:If you don't establish a warranty period and the customer finds problems, it can be frustrating for them to have to wait for these problems to make it to the top of the priority list before being addressed. The warranty period gives them a buffer period when problems can be addressed as soon as they occur.

Some projects require training upon completion. If this is the case, the training activity is included as part of the overall project plan. Once training is completed, the product is turned over to the customer. Again, you might choose to institute a warranty period to answer training questions and issues as they come up.

Implementing the Project

At the end of the warranty period, it's time to turn the product of the project over to the customer. You'll want to make sure that all the processes are complete and the proper information is turned over to the customer. Table below shows a sample checklist that you can use at the end of the project to make certain that the product is ready to be delivered and the customer receives all the information they need regarding the product. As the project manager, you should verify that these items are complete and correct prior to delivering the product to the customer.

Table Implementation checklist



All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Project Management Topics