The organizational process assets output is where the formal sign-off of the acceptance of the product is documented, collected, and archived for future reference. Documenting formal acceptance is important because it signals the official closure of the project, and it is your proof that the project was completed satisfactorily.
Another function of sign-off is that it kicks off the beginning of the warranty period. Sometimes project managers or vendors will warranty their work for a certain time period after completing the project. Projects that produce software programs, for example, might be warranted from bugs for a 60- or 90-day time frame from the date of implementation or acceptance. Typically in the case of software projects, bugs are fixed for free during the warranty period. Watch out, because users will try to squeeze new requirements into the "bug" category mold. If you offer a warranty, it's critical that the warranty spells out exactly what is covered and what is not.
This is also where the other project records and files are collected and archived. This includes the project planning documents (project scope statement, budget, schedule, risk responses, quality plan and baselines, and so on), change records and logs, issue logs, and so on.
Project or phase closure documents are included in this output. These include documentation showing that the project or phase is completed and that the transfer of the product of the project to the organization (or department responsible for ongoing maintenance and support) has occurred. In the case of a phase completion, the transfer would be the official hand-off to the next phase of the project rather than to an operations or maintenance group. If your project is canceled or ends prematurely, you should document the reasons for its premature end as well as the procedures for transferring the completed and uncompleted deliverables.
Historical information and lessons learned are used to document the successes and failures of the project. As an example, lessons learned document the reasons specific corrective actions were taken, their outcomes, the causes of performance variances, unplanned risks that occurred, mistakes that were made and could have been avoided, and so on.
Unfortunately, sometimes projects do fail. You can learn lessons from failed projects as well as from successful projects, and you should document this information for future reference. Most project managers, however, do not document lessons learned. The reason for this is that employees don't want to admit to making mistakes or learning from mistakes made during the project. And they do not want their name associated with failed projects or even with mishaps on successful projects.
You and your management team will have to work to create an atmosphere of trust and assurance that lessons learned are not reasons for dismissing employees but are learning opportunities that benefit all those associated with the project. Lessons learned allow you to carry knowledge gained on this project to other projects you'll work on going forward.
Lessons learned can include some of the most valuable information you'll take away from a project. We can all learn from our experiences, and what better way to have even more success on your next project than to review a similar past project's lessons learned document? But lessons learned will be there only if you document them now. I strongly recommend you not skip this step.
They'll also prevent repeat mistakes in the future if you take the time to review the project documents and lessons learned prior to undertaking your new project.
Post-implementation audits aren't an official output, but they are a good idea. These go hand in hand with lessons learned because they examine the project from beginning to end and look at what went right and what went wrong. They evaluate the project goals and determine whether the product or service of the project satisfies the objectives. Post-implementation audits also examine the activities and project processes to determine whether improvements are possible on future projects.
Organizations might conduct post-implementation audits instead of lessons learned sessions. Documenting and gathering information during this procedure can serve the same function as lessons learned if you're honest and include all the good, the bad, and the ugly. Let's hope there's very little ugly.
Real World Scenario
The Cimarron Research Group researches and develops organic pesticides for use on food crops. It is a medium-sized company and has established a project management office (PMO) to manage all aspects of project work. The PMO consists of project managers and administrative staff who assist with information handling, filing, and disbursement.
Terri Roberts is the project manager for a project that has just closed. Terri diligently filed all the pertinent project documents as the project progressed and has requested the research files and engineering notes from the director of engineering to include them with the project archives as well. All information regarding the research on this project is included with the project archives. The engineering department chooses to keep its own set of research records as well, but it's important to keep a copy of these notes with the project archives so that all the information about the project is in one place.
Terri's assistant has indexed all the project documents and recently sent notice of formal acceptance and approval of this project to the stakeholders, project sponsor, and management team. This notice officially closes the project. The next step is to archive the files onto CDs and store them.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.