Project Management Templates

Over the past several couple of weeks I’ve discussed many project management-related templates and documents that are commonly used. And along the way over the past 10 months there have been a few other templates and documents discussed.

In an attempt to provide a one-stop document to link to all those templates and documents discussed so far, I’m going to pull them all into this article as a list with available links. Hopefully, having the accumulated list available in one place will be helpful to our readers.

Again, not all of these will be links to templates…some will merely be links to documents that have been discussed in greater detail in previous articles.

• Statement of Work
• Project Status Report
• Communication Plan
• Communication Plan
• Risk Management Plan
• Lessons Learned
• Lessons Learned
• Requirements Traceability Matrix
• Market Analysis
• Project Management Methodology
• Quality Management Plan
• Project Request Document
• Project Charter Document
• Business Case Document
• Change Order Request
• Change Order Request
• Resource Request
• Onsite Visit Progress Report
• Procurement Plan
• Lessons Learned Survey
• Disaster Recover Plan

Summary

As discussed in most of these articles, if having the actual template in a Word doc format would be helpful, just let me know and I’ll be happy to send it to you if I have it. In some cases, I may be able to send you an actual example document from a real project allowing you to better see how I’ve populated some of the information with meaningful data. I’ll revise and republish this article as I make more templates and documents on these and similar topics available that I think would be useful to our readers.

A Lessons Learned Template

Lessons Learned – often talked about, a discussion that is usually planned…but often forgotten.  You’re at the end of the project and the plan is to pull both teams together to go over lessons learned in great detail and for the benefit of all – but it often doesn’t happen.  Team members move on to other projects or post-deployment issues are taking up everyone’s time.

Lessons Learned sessions can be very helpful – and if you’re luck enough to keep yours on the project schedule, then this template may help you.  It looks a little rough pasted into this post and one of the tables turned into a bullet list, but I think you’ll get the idea.

As always, if you want the Word doc template, let me know…and please feel free to share your version as well.

PROJECT LESSONS-LEARNED DOCUMENT

The purpose of this template is to help the project team share knowledge gained from experience so that the entire organization may benefit. A successful Lessons-Learned program will help project teams:

• Repeat desirable outcomes
• Avoid undesirable outcomes.

A. Your project team should begin to use this document at its first project meeting. Continually recording Lessons-Learned throughout the project is the best way to ensure that they are accurately recorded. Topics to consider include all of the following (feel free to change the list). The Lessons Learned Checklist is also available as a guide to discussion.

B. At the end of your project, use this document to summarize your experience.

During your discussions:

• Be positive
• Do not place blame!
• Focus on successes as well as failures
• Indicate which strategies contributed to success
• Indicate which improvement strategies would have the greatest impact

The signatures above indicate an understanding of the purpose and content of this document by those signing it. By signing this document, they agree to this as the formal Project Lessons-Learned Document.

Documenting Lessons Learned

It is my belief that the act of conducting and documenting a Lessons Learned session with your team and your customer is critical and one of the least utilized tools of the project management trade. Seriously…the project is basically deployed and you’re ready to move on to other things. One of the last things on your mind is to examine the good and the mostly bad things that went on during the project.

However, when utilized, this can be very helpful and critical information both for you as a PM on your future projects and for your organization. It can also be very helpful for your customer and your own tech support in post-deployment support situations.

Carl Pritchard outlines his version of a Lessons Learned report below from his book “The Project Management Communications Toolkit.” Again, by including it here, I do not necessarily agree with everything stated, but I think as PMs it’s important for us to understand the various ways to handle such activities because what works in one industry or for one customer or project may not work for another.

The Lessons Learned Report

Purpose

Lessons learned are used at midpoints of the project and at project completion to catalog significant new understandings that have evolved as a result of the project. They are used to build the knowledge base of an organization and to establish a history of best and worst practices in project implementation and customer relations.

Application

Lessons learned should be applied across the organization to facilitate consistency. They should be used and reused as new projects evolve with concerns similar to those addressed by the original lesson learned.

Content

Lessons learned include detailed, specific information about behaviors, attitudes, approaches, forms, resources, or protocols that work to the benefit or detriment of projects. They are crafted in such a way that those who read them will have a clear sense of the context of the lesson learned, how and why it was derived, and how, why, and when it is appropriate for use in other projects. Lessons learned represent both the mistakes made on projects and the newer “tricks of the trade” identified during a project effort.

The content of a lesson learned report should be provided in context, in detail, and with clarity on where and how it may be implemented effectively. Because lessons learned are often maintained in a corporate database, the lesson learned documentation will frequently include searchable keywords appropriate to the project and the lesson.

Approaches

Although forms, databases, and simple documentation are the norm for documenting lessons learned, the approaches to cataloging the information can vary widely. Some organizations capture lessons learned in on-line cartoons and captioned scenarios. Others post lessons learned in hallways and project war rooms. Most capture lessons learned in simple document files or databases. The storage medium is not nearly as important as ensuring that the content includes detailed, in-context information about why the lesson was deemed important enough to store and what specific action can be taken to implement the lesson on future projects.

Considerations

Storing lessons learned information is one critical consideration, but equally important is the establishment of protocols to ensure access to the information on a consistent basis. Lessons learned may be captured and logged in depth, but if they are not accessed by project managers in the future, they do not serve any real function. Access may be encouraged through creative documentation approaches (like cartoons), physical location (hallways and project war rooms), or by including the mandate to access lessons learned as a key component of the performance criteria for project managers and team members.

More on Lessons Learned

It is my belief from my years of project management that performing a lessons learned activity is one of the most critical processes for future project success and yet also one of the most overlooked and underutilized. We tend to get to the end of a project and breathe a sigh of relief and move on. Rather, we should hold one or more formal sessions with our team and our customer to identify what worked and what didn’t.

The customer always has a lot to say about any implementation and their opinion and input matters greatly. It’s best for you to hear it in a formal lessons learned process rather than have your customer follow-up with your CEO and give him an earful.

I’ve published some of my thoughts on Lessons Learned previously including an article from February 2009 titled simply “Lessons Learned.” Here, I present some further thoughts on lessons during the project implementation process from Jason Charvat’s book “Project Management Nation.”

Lesson Learned During Project Implementation

“What could be simpler than buying some computers, throwing them on a desktop, plugging them in and turning them on?”

The question is simple: The answer is much more complex. Complexity is almost always underestimated until well after the start of the planning process. Many of the elements of deployment require special coordination and handling due to the lack of direct control over the processes or compounding dependencies. Complexity can come from the technical nature of a project that attempts to take advantage of a new technology not yet tested by the corporation and requires full integration into the existing systems. These factors don’t surface until the project manager demands action or some form of change. Implementing a solution without testing it properly is not acceptable.

I Wish I Had Known That

Look for early warning signs that planned business benefits will not be delivered.

• It is not clear that achieving the business benefits is the top priority of those managing the project.
• Time scales and resources for training, testing, and implementation support have been eroded by project slippage, and there are proposals to cut corners.
• Acceptance testing is being carried out by IS specialists and there is no involvement from the business.
• Other parties, who were not previously identified as part of the project, are now being identified as needing to be involved in acceptance testing and implementation.
• Staff involved in developing and agreeing to the original business objectives have moved on.
• The supplier has not demonstrated that the new system is compatible with existing systems and peripherals.
• The solution needs to be tested and demonstrated within the proposed environment (including links to existing systems). Have the tests for accepting the system from the supplier been planned and agreed upon? Has the process for data conversion been planned and has sufficient time been allowed for it?
• All necessary on-site preparations were not included in the planning (e.g., accommodation, cabling, safety, and security).
• All dependencies, such as slippage on other related projects, have not been taken into account.
• Too little attention is paid to testing the final solution.

Closing Out the Project – Part 2

In Part 1, we started the process of covering some critical questions to ensure all of the project “i’s” are dotted and “t’s” are crossed. The list can be much longer, but I’m choosing to cover 9 basic questions to look at when shutting down your project. We’ve covered the first three – now for Part 2 we’ll cover items four through six highlighted in bold letters below:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?
• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?
• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

What were the major concerns with the project?

No matter how perfectly a project goes, there are always concerns. You may have been able to mitigate whatever issues came up, but they still happened whether they knocked your project off course or not.

What we want to do here is document what those major issues or risks were. They key questions to ask during this process would be:

• Was the concern anticipated in advance (meaning was it something your team or customer foresaw as an issue or risk and thus you were already looking out for it)?
• Did the concern end up affecting the project adversely in terms of time, money, resources, or progress?
• Did it affect customer satisfaction and if so, in what way?
• How did you react to the concern and was your action the appropriate one in hindsight?
  

What are the key lessons learned from the IT project?

For this activity, it’s most beneficial to sit down with the customer post-deployment and formally discuss and document lessons learned. This is somewhat similar to reviewing the major concerns in the previous question, though this one is best done face-to-face – or by phone – with the customer as their insight will be invaluable…and is critical feedback to have. As I’ve stated before, your customer may have been unhappy with things and you had no idea – and now will be your opportunity to find some of those things out and understand how to better react in the future.

What would you do differently?

Knowing what went right and what went wrong, how the project turned out and how your customer feels about it, now you can look at what you would do differently in the future. There may even be other opportunities with this customer and having a plan for a different course of action on specific issues that arose on the engagement can be an invaluable piece of information going forward.

Re-review the issues and risks faced on the project and asked yourself and your team – did we react appropriately and, if not, what should we have done differently. Chances are, the issues will show up again in another project and you’ll be ahead of the game. If we don’t learn from our mistakes, we are destined to repeat them.

Next

In Part 3 we’ll further discuss these items in terms of the project closeout checklist/review…

• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?