Administrative Closure

Once the project work is done, you may be tempted to quickly move on to a new assignment. But you still have important work to finalize your project. Administrative closure involves gathering and centralizing project documents, obtaining sign-offs, and communicating the finish of the project.

Some administrative work is tedious , but without it you have no point of reference for any future questions that may arise regarding why this project was authorized and what it accomplished.

Administrative closure also provides a reference source that can be used to improve the success of future projects. There is no reason for another project to make the same mistakes or recreate a useful tool or template that is already available.

We are going to take a closer look at several aspects of administrative closure: project archive, formal acceptance, comprehensive review (often know as lessons learned), turnover , and release of team members .

Project Archive

You have created a lot of documentation over the course of your project, and it was organized to fit your needs for overseeing the project work. One of the benefits of all this project documentation is that it can be used to help you or other project managers on future projects. Your planning documents can be a reference for cost and time estimates or used as templates for planning similar projects. But that can only happen if you create a project archive.

There are a variety of ways to create a project archive. Some organizations have a room dedicated to the storage of project binders for completed projects, and this area may even be set up like a mini-library where project documentation may be checked out. Your PMO may maintain a centralized project archive. If you have a project library or a centrally maintained archive, you should check what the guidelines are for documentation and how to organize it.

Even if your organization has no formal rule regarding project archives, you should create a project binder. Not only will the binder be a good reference tool on future projects, it will facilitate answering any questions you receive about your project's history. Even though you may be tempted to just empty your project files and shove all that paper in a binder, put some thought and effort into organizing the data so that it can be easily retrieved.

Electronic archives are also becoming more popular. Your organization may have a secure file server where it stores project documentation.

One of the documents that will eventually be placed in the project archive is the final acceptance and sign-off for your project.

Formal Acceptance

By this time, you should be very familiar with the importance of doing reviews with stakeholders to get sign-off on major deliverables or milestones to move from one phase to the next . If you have followed this process throughout the project, formal acceptance of the project itself should be easy.

After completion of the final project deliverable , you should bring the stakeholders together for one last formal review of the project. The purpose of this review is to officially declare the project work complete by obtaining stakeholder acceptance and sign-off on the project

Depending on the policies of your organization, there may be a specific format or template for formal project sign-off. Make sure you are aware of all the signatures you need to obtain. On some projects, you may need just the signatures of the sponsor and the client; for other projects you may need a signature from every work group impacted by the project. The formal approval document with all required signatures is your paper trail of project acceptance and should be included in your permanent project archive.

You can clear up any unanswered questions or issues regarding the project. You want everyone to walk away from this review with the agreement that the project is complete and has met the requirements.

Although you should have already communicated to the stakeholders changes to the project plan, some of the players may not remember all of these changes. You should cover any changes to requirements or scope to make sure everyone is on the same page regarding expectations of what the project will do. This is of particular importance if there was a decision to remove features or functionality from the original requirements.

Occasionally, stakeholders may panic as a project draws to a close and ask for all sorts of additions. If project closure were postponed until the project had everything it 'needed,' most projects would never end. This is why obtaining the necessary approvals for changes, communicating how changes will be implemented, and updating your project plan is so important. The best defense against any last minute concerns is to continually focus on what stakeholders requested and agreed to in the project plan.

The stakeholders should also be made aware of which groups are responsible for the ongoing operation of the system. We will talk more about these people later in this chapter when we get to project turnover.

One of the last major accomplishments for you and your project team will be a comprehensive project review and documentation of lessons learned.

Comprehensive Review (Lessons Learned)

At the end of your project, you should conduct a comprehensive review to assess the good and the not so good aspects of the project. During this process, you evaluate each phase of the project in order to determine which things went right and which things could have been improved. This kind of review provides you an opportunity to improve your overall project management quality on the next project and benefits other projects. The most critical thing to derive from an end of project assessment is the lessons you learned from the project. You want to assess what went wrong and why, not so you can point fingers at the guilty parties, but so that you can do better next time by avoiding the pitfalls you encountered this time. Lessons learned is something project managers like to avoid working on because they're afraid of backwash on the job they did, but the idea is to gain knowledge about how to better manage projects.

If you are managing a cross-functional project, make sure that the review covers both the technical and nontechnical components of the project. Managing a project with deliverables from multiple disciplines has unique complexities. Even though you may be more interested in documenting what happened during development and testing, information on marketing and sales is equally important.

The following subsections describe some of the areas in which you'll concentrate your review process. All of the information generated can be kept in a single document, or you can choose to write a document for each category. Obviously, the larger the project, the more documentation you're going to need to create for any given category. All of this documentation will go into the project archive, whether it is electronic or paper in form. Whatever format you choose for capturing the output from the review process, keep in mind you will need to summarize this data in a written report, which we discuss later in this section.

Planning

When reviewing the planning process, ask yourself how well the project was planned in general. Were the tasks , activities, and phases well thought out and orderly, or did you have to backtrack to fix some things that you originally had set up in the wrong order? When you have to backtrack on things like this, you can get into a situation where you actually can't go back and fix, or at the very minimum precious time is taken up getting back to the place you can continue from.

Also, you should pay attention to the project plan itself, evaluating its complexity, the number of milestones, and whether you filled it out correctly. Project plans can be laborious if they're too detailed and useless if they don't include enough information.

Organizing

How well did the overall project come together? When you examine the organizational characteristics of your now-finished project, you're interested in more than the project plan itself. Did the team members come in for their various tasks at just the right time, or did some of them have to wait for something else to happen before they could go to work? You should examine how well processes went into place and where you can improve next time. Things like equipment burn documents (documentation that stipulates the steps involved in the installation and configuration of computing equipment), network protocol assignments, coordination of physical equipment installations, and other orchestrated functions should be examined closely to see how you could improve them the next time.

It's especially critical to pay attention to the details of any software development involved in your project. Examine the coding, documentation, and testing of the software development. Pay close attention to the development tools used to see whether they were adequate for the process. Did the code repository system you used to store developed modules meet the developer's needs? Further, was the choice of development language appropriate for the project? Often, developers have pet languages that they'll use for all their work, but some projects may be better suited for a different language.

Executing

The executing phase deals with bringing performance in line with your plans. Things such as team development, stakeholder relationships, performing according to schedule and cost baseline, information distribution, and vendor contract administration happened in this phase.

When examining this phase, you should take a look at things such as vendor relationships and how well they worked out, the value of team meetings in maintaining team member linkages and revolving issues, and effectiveness of stakeholder communications.

You may ask yourself a number of other questions about the execution phase. Were the team meetings effective for team communications and issues resolution? Did the weekly progress reports from the team members provide you with accurate and timely data to assess project performance? Did project status reports paint a clear picture of project progress? Was vendor progress adequately monitored ?

Your focus here should be on looking at where the project worked flowed smoothly versus where problems or issues you did not expect arose.

Directing

Examine your work. Take a look at how well the project was directed through its steps. Like a movie director helping the actors play out the various shots, you should have been there for your team members at all points of the action. It's important to pay attention to the places where the project got off track and how you got it back on. Perhaps you can make adjustments to your next project to avoid such scenarios.

Look closely at the places where team members fell behind schedule. Determine whether what you had to deal with was personnel management or a technical issue. Defining people issues can help you work more closely with team members in the future.

Controlling

Controlling differs from directing. When you have a finalized project plan and are making sure that the deliverables you're creating meet the metrics you set down during requirements definition, you are controlling the project. For example, a piece of code that does a calculation should meet a success criterion that clearly indicates whether the code works as needed and expected. The controlling aspect of the project looks at metrics. When assessing the project, you might ask, 'How well were the metrics formulated, and did they meet expectations?'

Don't forget that during the planning stages you pinpointed the risks to the project. Did any of those risks materialize while in the controlling phase? If so, how did you spot them and then deal with them? Risk monitoring and control is an important facet of any project.

Budget

This is an important end-of-project category. First, take a look at the variances that occurred during the project to see if you can match them to a reason for their occurrence. Spotting the reason could potentially help avoid the same thing next time.

Also, you should evaluate the project budget compared to the way that the corporate budget outlined your budget categories. You do this to make sure that you effectively used the money the way that the company intended you to. Chances are you 'robbed Peter to pay Paul' in certain cases, and this is acceptable, but you need to reconcile that with the company's budget.

Prepare reports that represent what was spent, on what, and where your closing budget stands. You should also show the hours spent on the project compared to the salaries of the individuals working on various tasks.

Preparing a Written Project Assessment

A finalized project assessment needs to be prepared and distributed to all of the project stakeholders. The size of the project and the amount of feedback provided by the project team will dictate how large the report should be; a small project might only contain a paragraph or two for each section, while a large project might wind up being a fairly comprehensive document of many pages.

As with any other project documentation, you should check to see whether your organization has standards or a template for documenting lessons learned. If you have no specific guidelines or template, organize your material around topics such as the project phases discussed earlier. For each section, cover the positive aspects, the negative aspects, and plans for improvement.

Real-World Scenario: Involving Project Team Members in Lessons Learned

Although you can evaluate the various components of the project on your own using the project plan and the project results, to get a more comprehensive lessons learned you should involve the team members.

One way to organize a project review session is to make the session very interactive. Let the team members know in advance which aspects of the project the review will focus on, and ask them to be prepared to contribute input on both what went well and what did not.

You should always set ground rules before you start. You want to stress that the purpose of this session is not to assign blame, but to assess the project so that both this team and other project teams can learn from your experience.

Just sitting around a conference table for several hours can get boring, so we like to keep people moving around. One way to do this is to prepare the meeting room in advance with easel paper listing all the areas of the project you want to cover, and provide each team member with a pad of sticky notes. For each topic, ask the team members to post one positive thing and one negative thing. For each negative comment, a plan for improvement needs to be included. If they encounter this situation on a future project, what would they do differently? Requiring a plan for improvement serves two purposes: it engages the team members in the review by making them part of a problem solving process, and it helps keeps those few team members who may only want to whine under control. This is not the time or place to complain about the pastry or lunch selection at a team meeting. After the team members have posted their sticky notes, you can moderate a group discussion of the items that have been posted. Seeing what others have posted may generate additional thoughts.

When you have concluded the session, collect all the easel paper to use as input for your written report.

 

Positive Aspects of the Project

This is the easiest part of the written report; everyone wants to share successes. Talk about what went right with the project. Provide detail regarding specific tasks that you thought went exceptionally well and why. You may also include any positive comments that customers made about the project and its progress.

It would be a good political idea to also mention positive participation from people from other departments or teams that helped you get your job done. Mentioning other departments has two effects: It reinforces the opinions of people from those departments, putting it in the back of their minds that they'd like to work for you on another project. It also shows other departments that your team wasn't a force of one; you needed them to help you get your job done.

With respect to the constraints of any project, if something went particularly well, it's important to point it out at this time. If your project came in well under budget, ahead of schedule, or with an output whose quality is higher than expected, this should be mentioned in your closure document.

Negative Aspects of the Project

Project managers sometimes avoid writing anything negative about a project, but that really defeats the purpose of doing lessons learned. If you do not document what went wrong and what you would do to change the situation, other project managers are likely to make the same mistake. You have to be careful not to use this portion of the report to point fingers or assign blame. If you had communications difficulties with a particular department, stating ways you could improve the communications plan is more beneficial to future projects than stating 'department X was not responsive .'

If your relationship with a vendor did not go smoothly, list the areas that were problematic such as deliverables being off track, or poor quality and state what you would do differently- more frequent review sessions, more detailed acceptance testing, etc.

Describe any problems you ran into with software or hardware that you purchased- problems that surfaced time and again and weren't a one-time thing. For example, if you had trouble with some firmware updates, software that you had to apply across a lot of the same equipment, you would mention that here. You should also talk about hardware that consistently malfunctioned the same way, regardless of the number of units you deployed.

You should also mention limitations that you encountered simply based on the constraints of the project. You don't have to come across negatively when mentioning a constraint, but it's important that readers know that if you had had more time or budget, you could've brought in a better product.

It's important to stay away from blaming people directly, but also to not be shy about talking about processes that didn't work, promises that weren't kept, and fundamental operations that could've gone better. The point is to clearly state what went wrong and what you would do differently in that situation in the future.

As you are writing your project report, you will also need to be implementing project turnover.

Project Turnover

When a project ends, another work group will maintain the deliverable produced by the project. The project deliverable needs to be turned over to this new team. This is not something that just happens magically; it has to be coordinated between the project manager and the operational groups that will run and maintain the new system.

For an IT project, it may be easy to think about the groups who will operate the equipment and update the system. But your project turnover may be far more involved.

Many systems involve a help-desk function. Your project schedule should include activities for developing and delivering training to the help-desk staff. In addition to making sure the help-desk technicians are thoroughly trained, you need to coordinate when this group will start taking end user calls. Typically, a help desk takes over a new system as it is deployed to the users. If the system is being deployed on a staggered schedule across multiple end user locations, the help-desk management should be involved in the development of the schedule to ensure adequate help-desk coverage as each office comes online with the new application.

Although the development of supporting documentation is part of the project work, updating the documentation is the responsibility of the individual operations groups. You need to make sure that the technical documentation reflects any changes to the project scope or requirements. All documentation should be updated to include any changes as a result of testing or other quality control activities.

If your project was cross functional, there may be user related documentation that will require maintenance and updates as the system is enhanced. If project team members were responsible for development of user documentation, you will hand off the user documentation to the ongoing operations technical writing team. User training material needs to be moved to the training department for the client organization.

If additional technical staff is required to maintain your system or provide end user support, these people may have been brought on using money from the project budget. The length of time these people are charged against the project budget should have been negotiated up front. You need to make sure that you have a written agreement as to when salary dollars or any other ongoing operational expenses are transferred to the operation budget.

Case Study: Chaptal Wineries-Intranet and Email

Closeout of the Chaptal project is straightforward. You need to validate that all the email servers are up and running and that email is able to move back and forth between the sites. Also, you want to validate that the intranet is working and people are satisfied that the information they derive from the pages is useful and straightforward and that information that needs to be put onto the intranet by various stakeholders can be done so with a minimum of hassle.

Email You can use the Exchange Server administrator interface to validate that you see all of the sites in your organization. You pull up the administrator interface and see the California, Australia, France, and Chile sites just fine. You can also see the mailboxes that are associated with each site. Even though systems testing has validated that everything is working well, you send a couple of email items to various people throughout the organization. You include some emails with attachments to make sure that they're being transported well.

You adjust some Exchange routing metrics and are satisfied that email is moving well. While at the international sites, you visited user computers and installed the Outlook client so that users are ready to utilize their email. You now send out an email to the main contact at each site instructing them that the system is available for immediate use. You have already trained your international contacts on how Outlook works and how it interfaces with Exchange-you feel they are prepared to handle most end user problems.

You will now enter into maintenance mode with the email system. You note in your project closeout that you have successfully concluded this step and that the system is in production. From this point forward, new additions or enhancements will be considered a new project. You interview Kim Cox and the international stakeholders to see what input they can provide relative to ways that you could have done things better. This information will go into the lessons learned component of the project.

Intranet The Chaptal intranet site pages have been developed and approved for usage. You're particularly pleased with a page that the contractor developed that allows the winemakers at the various sites to key in information pertinent to the wines being developed. Topics that are interesting to Kim will be the type of grapes used as well as the percentages of mixture of grape varieties (i.e., 40 percent cabernet sauvignon, 60 percent Shiraz, etc.). Also of interest is the specific gravity of the wine, sugar content, alcohol content, container aging (barrel and stainless steel ), and bottling and labeling information. Additionally, Kim wants to keep track of the number of barrels made as well as shipping and reseller information. The application that your intranet Web page developer created elegantly handles all of these elements in a nicely built application interface.

An additional application that Kim would like to have-one that was not included in the purview of the original project-would track the costs involved to maintain tasting rooms at each winery. Currently, French and Chilean wineries that provide tasting rooms for drive-up customers are rare. But Californian and Australian wineries commonly include this feature as a part of their operation. Kim would like to provide tasting opportunities at all Chaptal wineries and wants to track the costs (and revenue) of this side of the operation from site-specific levels. This will be a new project that's tied to the build-out of tasting rooms at the French and Chilean wineries. The Web page developer also created a financial tracking application that allows the various sites to report earnings and expense numbers for final accounting roll-up at the California main site. The next project you will undertake relative to Web development work will involve designing and building a full Internet site that details information about all of Chaptal's wineries from a single site. The lessons learned segment for the intranet site has a very short list. Overall Kim's quite pleased and only wishes that some expandability was built into the intranet interface so that as new wineries are acquired (she's looking at a lovely operation in the Piedmont area of Italy), they can be easily snapped into the existing infrastructure.

You prepare an end user training manual that you'll post on the intranet as well as the lessons learned documentation. You send out notice that the project is officially closed.

You begin work on your next projects: The Chaptal Internet site and the acquisition of Marcello Wineries of Piedmont.

 

Project turnover can sometimes be shortchanged because everyone on the project team is in a hurry to move on to the next assignment. It is your job as project manager to oversee this process and resolve any outstanding issues before you officially closeout the project.

Turnover of various aspects of the project to ongoing maintenance is also a signal to start releasing your team members.

Release of Team Members

The staffing management plan developed during project planning should have addressed any special procedures you are required to follow as part of releasing team members from the project. It is a good idea to review this document as the project starts to wind down to ensure you are in compliance with all human resource guidelines.

You should start communications with functional managers at least a month before the anticipated release date. The functional manager needs to know when staff members will be available to be assigned to a new project or functional work.

Team members may also become anxious about their status, especially if people are rolling off the project at different times. You should explain to team members that as various deliverables are completed, team members who have completed their assignments are released. Unless you are prevented from doing so by labor contract terms or human resource guidelines, provide your team members with as much information as you can on anticipated release dates.

Once all of the closure documents are complete, the project is turned over to maintenance, and the team members have been released, you can start the planning process all over again for your next project.