Project Management Checklists For Dummies Cheat Sheet - dummies
Cheat Sheet

Project Management Checklists For Dummies Cheat Sheet

From Project Management Checklists For Dummies

By Nick Graham

Project management checklists are essential tools for the busy Project Manager (that’s you), and the checklists in this Cheat Sheet are the ones you’re simply going to have to have.

The Key Project Management Checklists

The most important project management checklists — the real top-line items — fall under three main headings: Kick Off, Project Planning, and Project Control. These are the lists that you need to complete before any project can get the green light. They go like this.

Kick Off

The three documents in Kick Off work up the idea for a project from a one-side overview to an Outline Charter. You add more detail at each point when you have established that the project is worth progressing.

  • The Idea: A one page overview of the basics of the idea for the project.

  • The Recommendation: Typically five to ten sides of paper, exploring options, recommending one, recommending not to go ahead after all, or perhaps recommending that while the work should be done, it doesn’t need a project to do it.

  • The Outline Charter: Okay, it’s looking like a viable project now. The Outline Charter sets down the scope and an overview Business Case and is developed using project expertise, not just business expertise.

Project Planning

If the managers in overall charge of the project and its preparation, the Project Steering Group (PSG), accepts the Outline, it’s time to start the project itself, and that begins with the Planning Stage. You’ll need some major documents here for project approval and then control. Three major planning documents exist, but the second one — the Project Management Plan — contains quite a few other plans.

  • Project Charter: The strategic view of the project. This will be maintained throughout. Amongst other things, it contains the scope statement to say what the project is, the objectives, and, importantly, the full Business Case.

  • Project Management Plan (PMP): The tactical view of how you’ll manage the project. You’ll need some or all of the following:

    • Project Plan: With the product, activity, and resource plans and also the budget.

    • Risk Plan: How you will control risk on the project, including reporting procedures.

    • Quality Plan: The level of quality to be achieved, and how you will achieve it.

    • Communications Plan: What information will be needed and how it will be communicated.

    • Stakeholder Plan: If you have a significant amount of Stakeholder management to do, how you will do it.

    • Procurement Plan: If your project will involve a significant amount of procurement. This shows what will be bought and when, including lead times.

    • Other Controls: Details of any other controls to be used, not covered in the other plans in the PMP.

  • Stage Plan: The plan for the first Delivery Stage so you can move ahead promptly when the Charter and PMP are approved.

Project Control

During the Delivery Stages, the Closure Stage, and the evaluation of the project, you’ll need some further documents. This checklist is to help you think through what you’ll need, and perhaps what you won’t need.

  • Stage Progress Report: For the Project Manager to report progress to the Steering Group, possibly copied to others such as organisational managers and Project Managers of any interfacing projects.

  • Team Progress Report: Where you have a project with multiple teams working, the Team Leaders will need to inform the Project Manager of progress on their current work assignments.

  • Stage Completion Report: Produced at the end of each stage, this report is used by the Project Manager to inform the Project Steering Group of how the stage went. So, what was the final time and cost? Were there any problems that will affect future stages? This report may be given as a presentation at the Stage Gate.

  • Project Completion Report: Produced by the Project Manager at the end of the project, it reports how the whole project went. It should also record any lessons learned during the project, good and bad, that may be of value to future projects.

  • Project Evaluation Report: Produced after the end of the project, this sets down information on benefits realisation (what the actual benefits were compared to what was expected when the project started) and the suitability of project deliverables after an initial period of use.

  • Project Issue (or Project Memo): A communication from anyone in the project to the Project Manager, but you may choose to use them for written communications between the Project Manager and the Steering Group too.

  • Work Package: A work assignment given to a Team Leader by a Project Manager. It sets down what work is to be done and how. A project team will work through one or more Work Packages in a Delivery Stage.

Justifying Your Project

This project management checklist helps you check the justification for your project and so generate the basis for a sound Business Case. It’s easy to be too focused on benefits, or even a given level of financial benefits, when you’re thinking about whether a project is justified or not.

However, while achieving business benefits is the most common project justification, it isn’t the only one. Have a look at this list to check your project out.

  • Benefits: Okay, the most common justification first. The project will pay back with business benefits which outweigh the cost and effort involved in running the project.

  • Compliance: You have to run the project whether there are benefits or not. That might be compliance with legal requirements or something like a head office instruction that ‘All regional offices will run a project . . .’

  • Enabling: The project itself won’t deliver benefits, but it will put something in place that will allow other projects or operations to deliver benefits. Infrastructure projects often fall into this category, such as a project to install a new computer network.

  • Maintenance: The project just has to be done, even though there is not any benefit in the normal sense of the word and it’s not mandatory (where it’s needed for legal compliance). Replacing worn out equipment or redecorating the HQ building are often just ‘maintenance’ projects.

Product Planning Checklist

The product-led approach to planning, set out in this checklist, is hugely powerful as well as being very logical. One of the advantages of the approach is in flushing out hidden bits of the project to give you a more complete view of what’s involved. Good product plans lead to complete activity plans, realistic resource plans, and more accurate costings; all of these are really helpful for project control.

As you check your products, think about these areas.

  • Risk: Check that you have included risk-related products, such as assessments of technology developments in competitor companies.

  • Inter-project dependencies: These occur where you can’t start to build a product in your project until you have received something from someone else’s project, such as a copy of a design specification.

  • Communications: Internal project communications don’t need to be put on the plan, but there may be other important communications products that do, such as briefings for business staff, a website and publicity materials.

  • Training: A lot of project planners forget user training. Check that you have included relevant products such as training materials, room bookings and staff attendance schedules.

  • Orders: These are important where you have external products coming in from outside the project, many will need an ‘order’ product; they won’t arrive by magic.

  • Installation: Where you have an external product, such as a Pink Widget bought from a supplier, check if you need an ‘Installed Pink Widget’ product which may be something that your project will create.

  • Legal issues: This covers items such as licenses. If you need them then include them on the product diagrams but also your applications for the licenses because they’re products too.

  • Inspections and approvals: This includes such requirements as building inspections and electrical safety certification. The approval certificates are products, but so too are applications to ask for them.

  • Logic: Check the flow of products on your Work Flow Diagram. Ensure that the dependencies are complete, necessary and logical.

  • Completeness: Check that all of the products identified on any list or Work Breakdown Structure have been carried forward to the Work Flow Diagram, then that you have done the ‘bottom-up checks’ to ensure that nothing has been left out.

  • Management products: Although your main product diagrams will only show team products, list the products you need to manage the project separately, such as progress reports and Stage Plans. Don’t overlook them; they’ll need time and resource to produce.

Activity Planning Checklist

This checklist forms the basis for putting together an activity network for your project management. You usually follow it up with a Gantt Chart, since this is what the mainstream project scheduling software provides. Use the product names as headings, and then under each one list the activities you’ll need to build that product. When you come to check your activity plans, run down this checklist.

  • Completeness: Have you copied every product onto the activity plan as a heading? Except for the external products, make sure that you have at least one activity listed for each product to cover the work required to build it.

  • External products: Check to see if you need any activity for something coming in from outside. Although your project isn’t responsible for creating that item, you may need an activity to check it or install it.

  • Quality: Ensure that you’ve included the necessary quality activities, such as testing each individual product, and then project-wide quality activity such as quality audits.

  • Correct dependencies: Be sure to check every activity dependency to be confident that it’s accurate and also that it’s in line with the dependencies you identified on your Work Flow Diagram.

  • Overlaps: Make sure that you haven’t missed any overlaps where a second activity can be started before the first is completely finished.

  • Lags: Check for lags where a second activity can’t start immediately after a first one is complete. For example, you can’t start the induction training of new staff the day after the employment contracts have been sent out. Most people will have to work a period of notice with their current employer before joining your organisation so you may have to allow for a four-week lag, and probably even more.

  • Inter-project dependencies (inbound): Note any inter-project dependencies on your product plans. Then make sure that the timing of your activity is consistent with the availability of the necessary input from the other project(s).

  • Inter-project dependencies (outbound): Where another project needs stuff from your project, make sure that you will be producing it in time. Can the other project live with a pause while it waits for the product to be ready, or will you need to adjust your project to create the product earlier?

  • Holidays: Check that all of the scheduled activity is on working days and avoids public holidays. If you are using a computer tool, it should have warned you of any problem, but even so make sure that any national holidays are correctly shown in the project calendar.

  • Staff availability: Ensure that staff are scheduled for project work only when they will be available. Check that you’ve taken into account things like booked personal holidays and work on other projects.

  • Staff capacity: Check that the work scheduled for project staff is in line with their capacity. If someone is only available to your project for ten per cent of their time, make sure that their activity reflects that with a one-day job taking ten elapsed days.

  • Lead times on supply: Make sure that you have sufficient lead times on things like supply. A supplier won’t deliver goods to the front desk one second after you have emailed an order.

  • Lead times on approvals: Check that you have a realistic turnaround time on approvals. This check applies both to internal approvals (such as agreeing design specifications) and external ones (such as planning permission for building extensions).

  • Critical Path: Be clear about which activities are on the Critical Path, and also watch out for those that are near critical. Your activity network will be especially useful here as the chains of activities don’t show up very well on a Gantt.

  • Contingency: Have you got sufficient time contingency in the plan, and is it visible? Something is bound to go wrong, and having no contingency is simply asking for problems at best, and project failure at worst. Make sure that you have contingency to protect the Critical Path, or the Critical Chain if you are using that technique.

  • Crashable activities: Identify which activities could be crashed if you come under time pressure. Crashing an activity means reducing its duration by putting more resource on the job. Some activities are suitable for crashing, but others aren’t.

  • Management products: Check that you have activities and brutally realistic timing for creating and updating management products, such as producing Stage Plans, keeping the Business Case up to date and creating regular progress reports.

  • Control: Don’t forget your project management time for checking progress, risk, quality, and the other aspects of control. And be realistic about how much time you need for it, too, or you’ll face unnecessary pressures and bigger problems because you missed things and didn’t take corrective action in time.

  • Project memos and change: Make sure that you’ve built in and resourced continuous management activities for things such as problem investigation, investigating newly identified risks, dealing with change requests and simply visiting team members to encourage them.

Project Completion Checklist

Here’s a project management checklist to help you get organised and make sure that you don’t miss anything. There’s quite a lot to do toward the end of a project, so you’re a long way from putting your feet up, breathing a sigh of relief, and thinking it’s all over.

  • Product completion: Check to be quite sure that all project products are completed, which includes successfully passing any tests and checks. If you’re doing version control, you should check that, too, and make sure that everything has a complete status.

  • Signoffs and handovers: Check that all necessary products have been signed off as okay, and that any handovers to users have been done.

  • Handover documentation: If there should be formal handover documentation (such as legal documents), check that it’s been completed and is properly stored.

  • Acceptance criteria: Check to ensure that the project acceptance criteria (set down in the Charter) have been met. Hopefully that will be all of them, but see the tip below if not.

  • Resource release: Finalise the release of project staff back to their home departments, or perhaps on to new projects.

  • Celebration: Assuming that the project was successful, it’s time to celebrate with the project staff. Although you might think this is a light-hearted point, it’s actually a serious one. It’s important that you mark the achievement by thanking the staff for their work and celebrating the success. And don’t forget supplier staff and support staff when preparing the invitation list.

  • Physical resource release: Arrange the return of equipment and the release of accommodation, such as team rooms and perhaps even whole sites.

  • Benefit measures: Often, some benefits will already be visible at the end of the project, so they can be measured now and reported now.

  • Metrics: Calculate the final totals for financial spending, staff hours, performance, and any other figures required for the Project Completion Report.

  • Cost code: Arrange for the project cost code to be closed, unless it is to be kept open for any modification to products after project closure.

  • Assess the controls: Think back over the project and evaluate to see whether the controls worked or whether there were problems.

  • Assess the plans: Think back and assess whether the plans worked, or whether they were too detailed or not detailed enough to exercise effective project control.

  • Assemble lessons information: Prepare a statement of lessons learned during the project. Check back through your Project Log to make sure that you pick up everything relevant.

  • Project Completion Report: Prepare the Project Completion Report together with a business presentation, if this is required by the Project Steering Group (PSG).

  • Project Completion Meeting: Ensure that preparations are in hand for the completion meeting of the PSG (it’s like a final Stage Gate), such as a room booking, presentation equipment, and refreshments.