Doing the Right Things for Your Customer

Customers are a demanding group … that’s a given. When we have all of our regular project responsibilities to deal with on a daily and weekly basis, how do we know when we’re doing the right things for our customers? How do we know we’re managing them well, responding to the right requests, saying ‘yes’ when we should and saying ‘no’ when we should, and ensuring that our actions are not detrimental to the forward progress of our project?

You can’t always base it on customer satisfaction levels. Because attentive ‘do-anything-for-the-customer’ behavior may get a project manager and team high marks mid-way through a project. But upon implementation, if they’ve said yes to too many things that ended up modifying scope and delivering a system to the customer that is ultimately not what they ordered, then that customer satisfaction at the end of the project will be low. The end user community will have a product that they didn’t sign up for and that’s a very bad thing.

In order to ensure we’re doing right by our customers, we first need to have confidence in what we’re doing. And we need to have confidence that we’re doing the right things for the project. We can do that in a few ways, including:

Read more »

Onboarding with Success

When you’re asked to jump on a new project how do you go about doing that to ensure your best chance for success? That may often depend on why you’re being asked to take over the project … and it can be for any one of the following reasons:

• Previous project manager failed to manage the team and project effectively
• Previous project manager lost the customer’s confidence
• Previous project manager lacked the expertise to lead the project based on new direction
• An emergency necessitated an early departure for the project manager
• Co-management became a necessity due to changes on the project Read more »

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.

The Onsite Visit Progress Report

Here’s a template that may or may not be applicable to your project situation.  I’ve only had to use it a couple of times because, in general, the regular status report will usually suffice.  The topic: The Onsite Visit Progress Report.

This type of document is not really meant for routine customer onsite visits.  I would never use it for an onsite visit to kickoff a particular phase of the project.  You could, but I believe it would be overkill as that is just routine activities and is covered both by the project schedule and the project status report.

However, if you must go onsite to the customer for some corrective-type action, then it is entirely possible that a communication mechanism such as this document may be your best way to get down in writing what you plan to do, what you actually accomplished and problems that were encountered.  This will help justify what work you performed, the hours expended, etc. as you get further down the road and need to justify budget overages to your executive management and/or your customer.

For me, it was very helpful to use when I had to take a team onsite in the middle of a the development phase to break through some barriers we were experiencing due to some requirements confusion.  It was helpful for our team to have the purposes and outcome documented, and it was very helpful for the customer and for my management to see the progress in a separate document from the regular formal status report.

PROJECT ONSITE PROGRESS REPORT

[Save file name as: client name ONSITE PROGRESS yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

TRIP OBJECTIVE

Provide a brief description of the onsite objectives. (1 or 2 sentences)

PROGRESS

Provide the progress notes from the onsite visit.

PLANNED

Provide a list of the planned activities for the next visit or to be performed remotely that have been taken away from this onsite visit along with expected completion times (List of action items to be addressed).

ISSUES

Provide information on issues encountered during onsite visit along with items to be addressed by vendor and client.