In your postproject evaluations (sometimes called postmortems), you will want to document in writing which methods worked and why. You will be able to look at how tasks were completed, and determine whether the best methods were used. If the process was one that the team found to be effective, you will want to carefully review the process so that it can be duplicated in future projects. If a task was accomplished but the method could have been improved upon, you will want to list exactly what aspects of this process should be analyzed and revamped for future projects. Determine why the revised method would be more effective and what the implications would be if you used it on the next project.

Circle Back

Naturally, it's important to look at the big picture to determine how close the final result was to the original plan. A completed project is rarely identical to that original concept. Trial and feedback throughout, plus testing, tinkering, and confronting numerous obstacles along the way, will change the course and alter the outcome of any project — sometimes for better and sometimes for worse.

You want to have preset levels of what is considered acceptable. Perhaps the new marketing campaign resulting from the project is effective, but the message is not exactly what you envisioned when you started the project. Now is the time to evaluate what is different and discuss whether you sacrificed aspects of the original idea to complete the project, or simply found an easier way to reach comparable results. Quite often, the new approach works very well without all of the details of the original plan. Sometimes, the act of planning a project takes on a larger scope than necessary, and too many details are added simply because everyone wants to have some input. Simple solutions can sometimes be the most effective.

Revisit the Detours

You should also review the changes and decisions that were made along the way. Obviously, if the project came in below budget, some decisions were made that worked in your favor. Hold a team-review meeting and invite everyone in attendance to participate and describe how they succeeded at their various tasks. The learning process is twofold: Not only will future project teams learn from your detailed accounts, you will also improve your skills for your next assignment. In the end, you and your team can have a strong impact on future projects, but only if you carefully retrace the steps you took and the alterations and decisions you made along the way.

If you are asking team members for their evaluations in written form, make sure your questions are simple and to the point. Ask for direct feedback to specific aspects of the project. If you are holding a meeting to get final evaluations (and you should), ask the team whether or not they felt the project really met the intended goals. Find out whether they agreed with how you approached issues that arose throughout the project. Look for constructive criticism. Ask team members to point out what could have been done in a different way, then ask them for suggestions for an alternative approach. You know where the project ended up, now review how it got there and how it might have gotten there in a better, more efficient manner.

The Nitty-Gritty

Let the team know at the onset that when the project is deemed complete, there will be a postproject evaluation meeting. When you are ready for such a meeting, make sure all key personnel have advance notice. Request that they bring as much documentation as they have of their work on the project. Naturally, on large-scale projects, you can't expect people to carry in files of reports, but key information that helps define what they did and how they did it will be useful.

You also need to have your own project records and documentation on hand. Include the original and final schedules, original budget and final expenditures, progress reports, updates, and correspondence, along with other key information that helps you recount the course of the project.

Many aspects are involved in a project's success or failure. The environment, the economic climate, the schedule, the budget, the resources, or the organizational structure could be at the source. You need to differentiate between factors that were within your control and those that were not. If the project failed because of flooding or a hurricane, it obviously was out of your hands. Try to pinpoint each source of success or failure within the project. Ask yourself and team members to think through the various elements that made up the overall project. Consider the following:

• Was the initial plan too complex or too simple to attain the desired results?

• Were the best resources used?

• Was the team missing certain expertise?

• Were there too many or too few people involved?

• Was the communication system effective?

• Was there a conflict that went unresolved and slowed down the project?

• Were there risks that went undetected and caused large-scale problems?

• Were previous projects reviewed and evaluated properly?

• Were the outside experts or consultants effective?

• Did management change the rules, and subsequently the project goals, along the way?

• Did outside agencies, policies, or other political factors impinge on the project's progress?

• Were there external factors that could not be avoided? What were they?

• Should key decisions have been made sooner?

• Should the contingency plan have been implemented at some point?

You should look for ways to improve on the things that did not work toward the best execution of the project and ways to optimize those aspects that did.