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.

The Lessons Learned Survey

Another useful tool in the Lessons Learned process is the Lessons Learned Survey.  This is a survey that can be sent to team members during or after a project, to solicit their feedback on how the project was conducted. It applies to any project; and questions can easily be added to focus on additional areas for your project.

A survey like this can be very useful for capturing lessons learned from the project while they’re fresh in people’s mind. The results can be summarized and recommendations passed on to future teams.

It’s usually best to send this survey by email to members of the project team. Let them know that results can be kept anonymous (to encourage people to be frank in their assessments). Send out this survey before any group “lessons learned” meetings. The feedback you receive from the survey can help point to particular areas that should get special exploration in the group lessons learned meeting.

Again, use this if it’s meaningful to your projects – it’s just another template or project tool that I’ve picked up along the way and wanted to share with our readers.  I’ve found it to be helpful in gathering post-project information from my team members on several key projects.

Post-Project Survey

SECTION 1: General Project Issues and Communication

The questions are geared to your particular project but wherever appropriate you can comment about release-level issues too.

Note: add any particular comments you wish….

1. How clearly defined were the objectives for this project?

___Very ____somewhat ___not very ___not at all

2. How clearly defined were the objectives for your work?

___Very ____somewhat ___not very ___not at all

3. How clear were you on your role in the project?

___Very ____somewhat ___not very ___not at all

4. How adequately involved did you feel in project decisions?

___Very ____somewhat ___not very ___not at all

If you did not feel involved, what decisions did you feel left out of?

5. How efficient and effective were project team meetings?

___Very ____somewhat ___not very ___not at all

What would you change?

6. How efficient and effective were technical meetings?

___Very ____somewhat ___not very ___not at all

What would you change?

___Very ____somewhat ___not very ___not at all

8. How adequate has cross-functional participation been?

___Very ____somewhat ___not very ___not at all

What were the problems encountered in the project-functional area relationship, why, and how could they be fixed? What cross-functional participation, if any, was lacking?

9. Do you feel appreciated, recognized and rewarded for your efforts?

___Very ____somewhat ___not very ___not at all

What if anything has been lacking?

10. To what degree is do you feel the entire team was committed to the project schedule?

___Very ____somewhat ___not very ___not at all

What if any issues are there?

11. To what degree have any “people issues” gotten in the way?

___Very ____somewhat ___not very ___not at all

What issues?

12. What communication, organization, structural problems in general were encountered, and how could we have done better in these areas?

SECTION 2: Schedule Estimation Issues

NOTE: This survey isn’t intended to collect exhaustive data on everything right now. We might decide after the post-mortem to work with a sub-group to investigate certain estimation issues, in order to help us improve next time around. This survey just helps us ferret out the rough scope of any issues.

Which of the following estimation issues did you personally have and what was the impact?

___ I was diverted to work on another project full-time.

Project: ________________________________________ Diverted for how long? ________________

Impact on your project work: ____________________________________________________________

___ I overestimated the amount of time I would have each week to work on this project.

The other work that interfered was ________________________________________________________

The amount of time per week it took up was ________________________________________________

Impact: calendar schedule slip of ____days ____weeks ____ months

___ My initial schedule did not include some pieces of technical design or coding work that I subsequently realized I had to do.

Describe briefly: ______________________________________________________________________

Impact (additional hours of work): ________________________________________________________

___ My initial schedule did not take into account certain project “other” work such as attending other people’s design reviews, doing two rounds of my own design reviews, etc.

Describe: ____________________________________________________________________________

Impact: calendar slip to my work of __ days __ weeks __ months

___ My estimates for particular tasks were not accurate.

Describe: type of task, how “off” the estimate was (days, weeks).

Why was it difficult to estimate?

What would help produce better estimates next time?

__ I unexpectedly had to re-do some work.

Describe: (Did something in the system design change that forced you to redesign? Was there a spec misunderstanding? etc.)___

Impact on your schedule: _______________________________________________________________

What could have helped prevent the problem?

Knowing what you know now, how would you do the scheduling/estimating process differently next time to avoid any problems noted above?

SECTION 3: Design, Implementation, Test Processes

1. How effective was our architecture/system design process in phase 2 and 3?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

2. How effective were our functional specs?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

3. How effective were our design (or implementation) specs?

__Very __somewhat ___not very ___not at all

Comments:__________________________________________________________________________

4. How effective were our design reviews?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

5. How effective were our code reviews or hardware reviews?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

6. How well were interfaces defined?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

7. How well were design and interface decisions documented?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

8. How effective has interaction/cooperation between technical “Sub-teams” been?

___Very ____somewhat ___not very ___not at all

Comments:_________________________________________________________________________

9. How useful was your unit testing?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

Did you take unit testing into account in your schedule? ______________________________________

10. How smooth do you feel Integration has been?

__very __somewhat ___not very ___not at all

Comments (why/why not?):___________________________________________________________

11. How comprehensive was integration testing, especially to allow SQA testing to get off to a good start?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

12. How well is the build process working?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

13. To what degree did you have the tools you needed for testing?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

SECTION 4: Perceived Project Life Cycle, Development, or Process Issues

1. Is there any way in which you think our development process hampered this project?

If so, how?

2. What would you change about our development process?

3. What would you like to better understand or see better documented about how to use our process on this type of project?

SECTION 5: Closing

1. What were up to 5 main causes for schedule slips, and how could we avoid those causes in the future?

2. Was the project significantly delayed/hampered by outside dependencies (outside to the project, that is)? Which ones? How can we resolve these issues?

3. What were the main bottlenecks on the process?

4. What were the main sources of frustration in the project?

6. For the next project, how could we improve on the way project was conducted?

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.

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?

Attributes of a Successful Project Manager – Part 2

In Part 2 of this three-part series we will look at further at Jason Chravat’s presentation of the attributes of a project manager from his book entitled “Project Management Nation: Tools, Techniques, and Goals for the New and Practicing IT Project Manager.”

In this segment, we’ll discuss the need for the project manager to have:

• General knowledge of project management
• Understanding of technology and some technical background
• Ability to work successfully as a problem resolution professional

These are just a few more of the key areas of expertise that the project manager needs to possess. Read on for further discussion.

Knowledge of Project Management

The first step for a newcomer to become qualified in project management is to complete a program of education. Meeting with others who are learning about project management is helpful, but it takes time. Alternatively, a prospective project manager can gather the information on his or her own. Those new to the profession don’t always need degree programs or pay large sums of money just to learn project management. Many of the world’s leading project managers learned their skills and techniques from experience and on-the-job training. That’s where the best secrets lie, and that’s why I thought sharing my experiences with project management would be helpful.

Technical Authority

Project managers often tell me that, as project managers, they do not need to understand the technology or technical issues because the technical resources working on the project will be responsible for the technical detail. Unfortunately, in the IT environment today, it is important for all project managers to be well-versed in the relevant project technology (including its applications and processes) and be able to communicate on technical issues with the “techies.” The majority of organizations that employ project managers insist that the project managers be able to take technical decisions and that they possess the necessary technical skill sets to be on a similar level as the technical staff.

I have heard many IT resources complain bitterly about project managers who haven’t got the foggiest notion of what needs to be done technically. The result is often that many of these resources simply carry on with their own development process and view the project manager only as an administrative manager who coordinates time sheets and ensures the delivery of status reports.

Project managers who are not well versed on the technical level find themselves (1) isolated, (2) lacking in credibility, (3) not consulted technically on major development issues, (4) not taken seriously, and (5) possibly even provided with false information. Project managers who understand the technology and can use it practically can apply such knowledge with outstanding results. Project managers also need to be certain that they have obtained the necessary project authority from the project sponsor and then communicate this to all stakeholders. This senior executive involvement often does the trick!

I always encourage project managers to make technical decisions if and when an opportunity arises, or to be involved in any way possible, by playing the role of facilitator or negotiator with the staff.

Sun Tsu said…

If the general’s employment of his mind is not in harmony with the army, even though the formation’s lightness and heaviness are correct, and the front and rear are appropriate, they will still not conquer the enemy.

Ability to Identify and Resolve Problems

Problems will arise on any project, no matter how much planning and effort have been made to avoid them. Recovering from any such problem means that the earlier the project manager can address the problems, the better. Identifying problems may require the project manager to review tasks with resources in order to find the real causes of these problems. If the causes are not within the manager’s own control or authority, then he or she must go to the project sponsor and seek advice there.

As alarming as this may seem, it may mean stopping the project until a solution is found, which is a good suggestion. Remember, the earlier you make the input to correct things, the smaller the input required.

Continuing to let tasks and milestones go off track will make it more difficult to correct the situation.

In Part 3, we’ll look at the project manager’s need for an ability to make timely and critical decisions, effectively select and manage a team of skilled resources, and to have a professional approach when dealing with management, teams, and the customer.