Project methodologies often have a template to initiate a project or checklists to ensure a project is ready to pass a tollgate or a formal project milestone. If you look at your company’s own methodology, you will likely find a lot of templates for your project.
Despite all these templates, few methodologies have a checklist for project turnover. Project turnover should be minimized, but project manager changes are a reality.
I’ve seen project managers get promoted, moved to different projects, quit or simply be replaced. When I was a business analyst working on a strategic HR systems project, the director replaced the project manager three times! If you find yourself having to transition a project or inheriting a new project, I found it helpful to have a PM Knowledge Transfer cheat sheet.
The cheat sheet is grouped into several areas:
This section speaks for itself, however, if you have a project charter, be sure to review it. Many organizations lack a quality charter but the key is to review the purpose of the project, high level goals and expected benefits. By providing the “big picture” view, it helps to provide context. Without this context, the incoming project manager will have to stumble through the same points you did when you started the project. Why not make it easy on the new guy?
Every project has stakeholders ranging from the Big Boss (i.e. sponsor) to the Little Guy (individual team members). Identify any key stakeholders, their influence and expectations on the project. Who are the stakeholders who will help remove roadblocks? Who has influence over the project outcome? Who is just a pain in the @#$?
What is the project actually delivering? What deliverables have been explicitly called out of scope? What deliverables might be creeping back into the project? What are the project constraints (budget, time, mandatory deliverables)? Are there any assumptions or dependencies to be aware of?
If the project is in execution, scope has likely changed from the original scope statement or original agreement. I’ve inherited plenty of projects where I reviewed the original scope and the team explained how scope changed. I’ve always found a context diagram to be a useful tool to convey all the people, vendors, and organizations involved with the project.
Every project has its own unique cast of characters, politics and social dynamics. Understanding the personalities, strengths, challenges and idiosyncrasies with each team member will help the new project manager significantly. Be sure to identify the key team members that the project manager can count on as well as any team members who need that extra helping hand.
How is the project being managed? What is the sequence of meetings throughout the week that collect status, communicate status, track issues and report schedule progress? How often does the project communicate with mid-level management, senior management and / or the executive leadership team? Are there any formal milestones, gate review or PMO expectations for the project? This checklist item includes reviewing the communication plan but it also includes all the governance processes to ensure the project is executing correctly.
Hopefully, the project schedule is up to date and it reflects current progress to date and any new forecasted end dates. If you haven’t updated the schedule in a while, remember to update it and walk through the schedule with the incoming project manager. Identify the sections of the schedule that are still developing based on changing scope or priorities.
Review all the actuals to date and cost forecasts as well as any outstanding invoices from vendors. Ensure there is a clean financial hand off to the incoming project manager. If the new PM doesn’t have a clean financial view, the person will waste a lot of time chasing down unpaid invoices and working with Finance and Accounting to clarify past costs.
In software projects, project quality often refers to software testing and defect management. In manufacturing projects, it is also important to review any outstanding manufacturing defects or unacceptable variances. It is important to understand how quality is being tracked within the project so requirements are imple...
(RSS generated with FetchRss)