12.6. Administrative Closure
Administrative closure is catchy term used for doing the paperwork. We all know that most projects are not considered complete until several reams of paper have been printed, forms have been filled out in triplicate, and fourteen file boxes have been filled with documents we'll never look at again. OK, that's the downside view. The upside is that there are important documents that are actually useful that should be completed during project close-out. We'll look at the common categories, but your organization will no doubt have additional or different requirements for paperwork. Create a list of required paperwork as you begin your close-out process (you can define it in your processes and procedures during your project organization phase if you're really on top of things). Past projects may give you some insight into what to use, but remember that past projects may not have used a solid project management methodology and might be incomplete from your new IT project management perspective. If you've been keeping your project data up to date, you shouldn't have much difficulty completing the administrative closure activities. Any shared team project data on network servers, drives, or intranet locations should be removed, archived, or deleted, as appropriate. Don't leave a physical or electronic mess behind.
Make sure you address all security issues. The rule of thumb in any kind of security is grant enough to get the job done (and not a speck more). In the case of your project, additional permissions may have been granted and wherever possible, those special permissions should be revoked at project closure. If your team was granted special building or network access, that access should be revoked (unless it's still needed and appropriate). If your team was granted special access passes, passwords, or access to sensitive or confidential data, need for this access should be reviewed and, where appropriate, revoked. As you know, most network break-ins or compromise of confidential data happens from the inside of companies, so be sure to restore appropriate security permissions to project team members to avoid creating security gaps.
The kinds of paperwork you should complete at this point will vary from company to company and from IT project to IT project. To get you started, here is a general list of paperwork you may want to complete as you close out your project:
18.104.22.168. Proper Disposition of Paperwork
File final copies of project plans and related paperwork. Think twice before shredding documents. If you're confident they are no longer needed, will not be needed in the event of a lawsuit or other legal action, and if they're sensitive or confidential in nature, they're good candidates for shredding. Consult with your firm's legal counsel before shredding documents if you're not sure. Shredding documents to cover your tracks is often illegal and almost certainly unwise. A great question to ask yourself is: would you do this if you knew you would get caught? If the answer is no, you probably shouldn't do it. That includes entering false or misleading data in reports, changing data after the fact, and shredding certain documents (by the way, if your company is involved in any kind of lawsuit, talk to your attorney before shredding any documents, even if they're completely unrelated to the lawsuit. Shredding can give the appearance of impropriety even where none exists).
In many cases, shredding unneeded documents is just fine and preferable to them simply being thrown into the trash. For all documents that will be preserved, use your company's document management system for storing and archiving documents. If none exists, you can store your files in hard or soft copy, but be sure they are well marked. Include the project name, project manager, project sponsor, client (if any), dates of the project, brief description of the project, and brief description of the stored documents. Whatever you do, make sure you file final copies of documents (mark them as such) so no one is wondering exactly which version is stored. Pick a system and stick with it or work with the appropriate people at your company to develop a system for company-wide use.
12.6.3. Regulatory Issues
During the definition of project specifications, you may have identified legal or regulatory requirements associated with your project. If so, you will probably also have to fill out paperwork to satisfy these legal or regulatory requirements. For example, if your project deliverables include shipping technology overseas, you may need to fill out export paperwork or certifications regarding the equipment and the legal export of certain technologies. If your project is subject to legal or regulatory requirements, you should already be aware of them. Some requirements stipulate project specifications or deliverables. Other requirements may simply be end-of-project reporting requirements. If you're not completely certain, talk with your project sponsor, legal, or financial advisor about potential requirements. If in doubt, ask. Failing to conform to requirements can cause massive legal and financial problems down the line.
12.6.4. Personnel Performance Reviews
Not all IT project managers will be required by their organizations to provide performance reviews for team members, so this may or may not be part of your project close-out activities. However, everyone needs feedback about the work they've done and as the IT project manager, you're in the best position to provide that feedback from a project perspective. During the organization phase of the project, you defined various processes and procedures for the team to use. During the planning stage, you defined the work to be accomplished, the timelines, budgets, deliverables, and quality required. You have all the elements, then, for providing performance feedback. You may choose to formalize team performance requirements, especially if you will be required to conduct a formal performance review at the conclusion of your project. Check with your HR department regarding an appropriate format and for guidelines on conducting the session if you've never conducted a performance review before. There are organizational and legal guidelines that should be followed.
22.214.171.124. Performance Review Elements
What elements should you include in the performance evaluation? Again, it depends on how your company runs, and if there is a defined process, you should consider using that. If none exists or you want to create one specific to IT projects, here are some general guidelines:
Performance reviews or evaluations should be a positive experience for both parties. The team member should come away from the session having a better understanding of his or her strengths and weaknesses. They should feel good about their contribution to the team and have clear ideas about how to improve performance in the future.
126.96.36.199. Delivering Performance Reviews: Below Expectations
Certainly, not all team members will exceed expectations and you'll need to be prepared to deliver more difficult news to underperformers. One thing that is absolutely key to a successful performance evaluation, even if the performance was sub-standard, is that the information in the review should never be a surprise. Performance should be measured, evaluated, and managed throughout the project cycle. At the first sign of trouble, take steps to manage performance (just as you do with your project). For instance, let's say that Alex is a smart, talented, nice guy who thinks that team meetings are a waste of time. As a result, he skips the second team meeting. Don't wait until Alex skips the third and fourth and fifth team meetings to address this. Team meetings should be productive events (so make sure they are) and Alex's absence makes it difficult for the team to form a bond as a team, communicate to everyone on the team at the same time in the same manner, assign duties based on team availability, and update team members regarding concerns, issues, or potential problems. That's not fair to the rest of the team and allowing this behavior to continue will demoralize the others ("Alex gets to skip, why should I have to attend?"). Don't use the performance review session as the place to address this issue. Talk with Alex, explain that team meetings are not optional and that should he have to miss a meeting for a legitimate business need, he should let you know in advance. This nips the behavior in the bud and lets Alex know that the team is expected to work as a team and participate as defined in the guidelines for team membership. If Alex's behavior continues to be a problem, you should continue to address it. That may include removing Alex from the team if the behavior continues. At performance review time, you will be able to then recap the issues rather than address them for the first time.
188.8.131.52. Delivering Performance Reviews
During the performance review session, focus on behaviors, work habits, and deliverables. In Alex's case, you might say, "Your attendance at team meetings was spotty, you missed 8 team meetings in a six month period. We discussed the importance of attending and participating in team meetings several times. The below average rating in this area reflects this issue." That's clear, unemotional, and states the facts and the behaviors. Choose language that is not accusing but that clearly states the facts. Don't try to sugarcoat them or minimize them. If you've addressed Alex's behavior in the past, these statements will not come as a surprise. If you hold Alex accountable for being a responsible team member, he may perform better in the future and become a star player. If you don't hold him accountable, his bad behavior will continue.
Keep this in mind as well: Everyone needs to retain their dignity. Unless someone has willfully been causing problems (in which case you may have removed them from the team), most people are trying to do the best they can. Factors such as problems outside of work, health issues, conflicting job expectations or requirements, and more can cause work performance to slip. Provide everyone the ability to retain their dignity even if you are giving them a "below expectations" review. With practice, you'll become more comfortable and competent delivering all kinds of performance reviews, but if you're new to this, talk with your HR folks for guidance on how to deliver this type of review. They can give you tips, help you avoid common pitfalls, and perhaps most important, provide appropriate language to use during the review.
Even if your company does not require a formal performance review, you may choose to sit down with each team member and provide formal or informal feedback. Everyone likes to hear how well they did and many people are open to constructive feedback so they can grow and learn. Use this opportunity to finish out your IT project leadership duties on a strong, positive note.