Chapter 8

Creating the Plans

In This Chapter

Planning as a foundation

Solving problems on the plan, not in the project

The levels of planning

Checklists to help you get the plans right

Fail to plan: Plan to fail

It’s an old saying but it’s true. Like many people, you may be under pressure to ‘get on with the real work’ of the project and so be in danger of cutting back on planning. However, planning is real work. With a good plan you’ll be in control, you’ll avoid firefighting problems that were avoidable and you may even deliver earlier. The plans give you a clear view of what you need to produce, how and when. Then you can check that everything fits together and that you really can deliver. The idea is to find and solve problems on the plan, not hit them in the project. A major cause of failure in projects is poor planning, or not planning at all. Now the answer to under-planning isn’t over-planning, but good, well thought-through plans for the level of control that you’ll need this time around.

You’ll often need to work at two levels of planning and sometimes three. You do the project level planning in the Planning Stage where you create the full Project Charter and the Project Management Plan (PMP), and the PMP in turn contains other plans such as the Risk Plan. Have a look at Chapter 2 if you’re not familiar with these key documents. Usually you’ll then want to create a lower level plan for each stage as you approach it, and even at the third level of team assignments (Work Packages) if those assignments are complex.

You’ll find this chapter useful at all of the levels, but you’ll use it most intensively in the Planning Stage.

Business Case Checklist

The Business Case is an essential part of the Charter and includes the justification for the project. Make sure that your Business Case is sound and that you have thought it through.

You’ll need to revisit the Business Case as you carry out other parts of the planning, and then throughout the project. Make sure that you keep it up to date with the very latest information.

• Justification: Check that the justification is clear, accurate and fair. Have a look at Chapter 5 for more on the justification types; it isn’t just about business benefits.
• Complete benefits: Are you confident that you’re not understating the project’s value by missing any key benefits? Check for benefits even if your project is mostly justified by something else. You’ll find a checklist in Chapter 5 to help you think through the areas.
• Accurate benefits: Have you explained the benefits clearly and categorised them correctly? Where other people have set down benefits, make sure that they’re real and not just wishful thinking. Again, Chapter 5 will help you check out this aspect.
• Uncontaminated benefits: Check that each benefit will be a direct result of the project, not something else. Beware of ‘benefits contamination’ where something other than the project could have led to the benefit, such as where the benefit will occur anyway whether the project goes ahead or not.
• Prudent benefits projections: Ensure that you have erred on the side of understating rather than overstating benefits following the accountancy principle to be prudent. Overstating the benefits can be very damaging.
• Specific benefits measures: Where benefits are quantifiable, make sure that for each one you’ve stated clearly how it will be measured and when it will come on stream so that it can be measured.
• Realistic costings: Hand-on-heart, are you sure that your project cost estimate is realistic, even if you can’t be one hundred per cent sure at this point? And if you can’t be completely sure of the cost, simply explain that.
• Realistic resource estimates: So many projects are late because there was more work than people realised. Check carefully to ensure that your staff resource estimates are realistic. Check it with others if necessary, perhaps including those who will be doing the work.
• Realistic timing estimates: Is your estimate of the duration of the project realistic in the context of the resource levels you have in mind? If you haven’t already, check it out with people who have done this sort of work before.
• Evidenced content: Have you got good evidence to back up the Business Case entries such as the project cost and timescale, or are they just guesses? Depending on the time you are doing this some rough estimating may be inevitable, but if so then explain that.
• Complete document: Make sure that all of the relevant sections of the Business Case are properly completed. Have a look at the template in Chapter 11 for a default list of contents.
• Clear and understandable text: Make sure that the Business Case will be easy for others to understand, including people not familiar with the detail of the project such as senior organisational managers.

The Business Case may be seen as a stand-alone document. A Projects or Finance Committee may treat it that way to approve the funds. For that reason you should usually include things like cost, timescale and major risks. That’s not mere duplication of information stored elsewhere, such as in the plans, but rather it reflects how the Business Case will be used.

The Business Case checklist includes a check for being prudent. Overstating benefits can be damaging in two ways:

• Your organisation may run the project when it’s not really justified. That may result in another project not going ahead when actually it would have been a better choice.
• When the project fails to deliver on the overstated benefits it will probably be seen as a failure – and perhaps you will too. Had the Business Case been realistic and more prudent at the start, the project would have been seen as a success and, who knows, you might have got that promotion after all.

Product Planning Checklist

The product-based or product-led approach to planning 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. If you’re not familiar with the product-based approach, have a look at the UK edition of Project Management for Dummies (Wiley) or hire in Inspirandum to deliver a training course for you to really unpack the power!

The Work Flow Diagram is a particularly powerful in product planning. If you’re not familiar with this type of diagram, have a look at the title page of this part of the book, Part III, and you’ll find an example.

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 licences. If you need them then include them on the product diagrams but also your applications for the licences 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. See the Remember point below for more on the bottom up checks.
• 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.

Workshops are great for planning and particularly for producing the Work Flow Diagram. If you have people in the workshop who are experienced and who represent all the areas involved – such as both business and technical staff – you can get the initial diagram drawn up and checked rapidly, often in two or three hours.

The two ‘bottom-up checks’ are essential to check the accuracy of your Work Flow Diagram. Starting at the bottom of the diagram, work up to check each product. For each one ensure that every dependency arrow feeding into it is correct. Then, for that same product, check that you don’t need any other products in place to build it, only the ones already shown feeding into it with an arrow. It’s the second of these checks that often shows up essential bits of the project that you hadn’t realised were there.

Activity Planning Checklist

For activity planning most people use an activity network (usually a Precedence Network) followed by a Gantt Chart since this is what is provided by the mainstream project scheduling software. Use the product names as headings, 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 productto 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 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.

As an alternative to entering a lag into a following activity, I usually prefer to show [waiting time] as an activity, and I use square brackets to make it clear that it isn’t project work but rather a ‘null’ activity. The null activity avoids mysterious gaps on the Gantt Chart. I do the same for [contingency] time so that it’s visible on the plan, but with square brackets again to show that there’s no work involved.

• 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.

Think flexibly about staff capacity and be prepared to negotiate. Suppose that someone is available to your project for 50 per cent of their time and to another project for the other 50 per cent. You might be able to have them for 100 per cent of their time in Week 27 to get that time-critical five day job done, and then not at all in Week 28 to make up for it. You can return the favour when the other project has something time-sensitive to do. Think about that in the context of the Critical Path where you need to keep things moving along.

• 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’ activitites: 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.

Estimating activity durations is distinctly tricky. For some help have a look at Chapter 23, Ten Tips for Estimating.

Resources - Staff Checklist

‘Projects are about people’ my old boss used to say, and quite right too. Getting the right people in the right place at the right time takes careful planning; it’s all too easy to overlook things and to make mistakes. Have a look at this checklist to help dodge avoidable staffing problems on your project.

• Completeness: Check that you’ve allocated resource to every activity. At first that may be a skill (Broadcast Engineer) rather than a named individual (Ann), but you should have individuals clearly identified before the plan is completed.
• Staff availability: Check that the named specialist staff are actually available when your plan shows that they’ll be required.
• Staff flexibility: Are the named specialist staff available either side of the planned time, in case the project is slightly ahead of schedule at that point or slightly behind?
• Manager availability: Confirm that the members of the Project Steering Group have the availability to perform their role. That means being available to make key decisions when something comes up, not just available for the pre-planned meetings.
• Staff selection: Have you got the best staff for the project from within your organisation, or just who happens to be available? Making an effort now to get the right people will have a big impact on project performance and delivery.
• Supplier availability: Check that suppliers have staff available at the time that the plan shows that they’ll be needed. This check may be part of any contract negotiations.

Don’t rely simply on the terms of a contract for supplier staff availability. As with staff from within your own organisation, you want the right staff, not just any staff. It has been known for suppliers under resource pressure to send in whoever happens to be available, such as trainees. It’s often better to adjust the project around the availability of good supplier staff rather than get unsuitable people sent in who then take longer to do the work anyway – or who start cutting corners to meet contract deadlines.

• Reserves: If there’s a risk that key project staff could be called away to other work (such as operational emergencies) have you identified reserves? If so, check also that the reserves have the availability to step in, perhaps at very short notice.
• Preparation of reserves: If you do have reserves, have you included things in the Communications Plan to keep them ‘in the loop’ of what’s going on? That way they can get up to speed more quickly if they are called upon.
• Resource levelling: Check that the resourcing is correct and achievable. Watch out for, and resolve, any conflicts such as a staff member being allocated for five full days of work in a week when they are only available to the project for two days each week.
• Project Memos and change: You’ll need to put in an allowance for project management resource to deal with things such as problems and changes. You’ll probably need to make a similar allowance for team specialists to help too, so don’t schedule them to full capacity on the planned work.

Resources –Equipment Checklist

In the pressure and high profile of planning your use of staff resource, it’s easy to overlook the resourcing of equipment. Look through your product plans and think whether you need any particular equipment.

• Product creation: Check whether your staff will need specialised tools or equipment that the project must provide.
• Office equipment: It’s easy to overlook the everyday items. Think through what your teams will need, such as large whiteboards, flip charts, extra wide printers and desk lamps.
• Testing: Check whether special equipment is needed for testing. That might include electrical instruments, test jigs or computerised test equipment.
• Scheduling: Check when equipment will be needed and confirm that it is available at that time. You may need to book it from the area of your organisation which is supplying it, or put in an advance booking with a hire company.
• Backup: Consider what you will do if necessary equipment is not available when you need it. That unavailability may be because of breakdown or another project being delayed and using it for longer than expected.
• Compatibility: If you are using bits of equipment that must work together, check that they are technically compatible, including having the right connecting leads.
• Safety: Think about any safety precautions for dangerous work or kit, such as barriers, warning signs and protective clothing.
• Buy or hire: Would it be better to buy new equipment and sell it on afterwards rather than risk not being able to get it, or old worn equipment breaking down? That can also help if you are not exactly sure when you’ll need the kit or for how long.
• Maintenance: Where you are using equipment from within your own organisation, think about how essential it is to the smooth running of the project. Would it be advantageous to have it checked out and serviced in advance (preventative maintenance)?

Compatibility and cables can be important. A company working on a deep sea survey project got a survey ship into position ready to send down a mini-submarine – a remotely operated vehicle (ROV). Then the operators found that they had not brought the correct cable to connect two essential pieces of recording equipment. The vessel had to return to port to collect the right cable, but by the time it had returned to the survey location the weather had deteriorated. The ship had to wait two weeks on station for the weather to moderate enough to send the ROV down. Two weeks lost because of one short length of cable with the wrong connectors.

Resources – Facilities Checklist

You may think that this section only affects projects that need things like specialised engineering facilities. However, read on because the need for facilities is usually wider than that, and that might just affect you.

• Team rooms: Do your teams already have suitable accommodation, or is that needed especially for the project?
• Meeting space: Staff need to come together occasionally when they are working mostly from home, and for that you need meeting space. Think also about meeting facilities at the start of the project for things like planning and risk workshops. Think whether you need meeting rooms for stakeholder briefings during the project and towards the end of it.
• Security: If staff need access to secure areas for some or all of the work and they don’t already have it. Check whether existing team rooms need to be made secure.
• Tests environments: Check whether you need special environments, or facilities that are equipped with a range of different devices to test things on, such as with some new software.
• Laboratories: Check for the need for labs or ‘clean environments’ for any aspect of the work.
• Training: Lots of projects involve user training. Your project may need facilities for that, even if it’s just meeting rooms in your HQ building. A lot of organisations are short of meeting space and rooms need to be booked a long time in advance, particularly big rooms.
• Additional sites: Consider whether you need additional sites or accommodation for the duration of the project or for parts of it. For example, if you are extending a building as part of the project do you have storage space for the building materials?

The training aspects of projects are often underestimated or overlooked altogether. A major public organisation in the UK implemented an expensive new information system. Extensive user training was an essential part of the project but nobody had thought about the facilities that would be needed to train the large number of staff involved. The delivery of the whole project was threatened when it was realised, very late in the project, that training facilities were needed and that no suitable rooms were now available. It caused big problems, but ones that could have been avoided with more careful thought and planning at the outset.

Budget Checklist

It’s not just about what money you need, but when you need it. Cash flow can be important to your finance department. Check this list out to help ensure that you’ve considered all the cost areas, and distinguish clearly between purchases and ongoing overheads such as organisational staff time. A useful framework for the budget is to use your product plans. For each product, show what it will cost to build it in terms of staff time and materials. Then don’t forget to add into the budget the cost of the project management and control.

• Equipment: What you need to buy or hire and when.
• Supplies: Consider things such as laser printer toner, stationery and raw materials to test new machines.
• Supplier staff: The cost of supplier staff time. Supplier staff costs will be a capital expense, not an ongoing ‘revenue’ cost where staff are employed by your own organisation anyway.
• Organisational staff: Yes, it may be an ongoing cost for your organisation, but you still need to say what their time will cost. Your staff have to be paid for and staff time is often the biggest project expense.
• Structure: Talk to your finance department about how the budget should be structured. For example, it will nearly always be necessary to show what money will be committed in which financial year.
• Procurement plan: Cross-check your budget with your Procurement Plan, if you need one, to ensure that they are consistent.

The Four Dogs Checklist

Intrigued? Well, perhaps not if you have read the UK edition of Project Management for Dummies or hired me in to give a project management or project governance course! There are four factors to keep in mind while you’re planning. The four factors are like four dogs pulling on a piece of project canvas, each with a corner of the canvas in its teeth. Have a look at the illustration at the front of Part I if you haven’t already noticed it. Make sure that the canvas is in the right tension and that the plan is achievable. The dogs are:

• Scope
• Time
• Cost
• Quality

Using the four dogs illustration, check that the canvas is in the right tension by asking ‘Can we deliver that scope, by then, with that resource (cost and staff) to that quality level? Is it do-able?’ If, you don’t believe it to be realistic – ‘do-able’ – stop now and work with your Project Steering Group to get the project in balance.

If the project isn’t balanced across the four key factors then it will be extremely difficult or, often, impossible to deliver successfully. If the plan is telling you ‘This isn’t going to work’ then listen up. In his 100 Rules for NASA Project Managers Jerry Madden notes ‘The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.’

The Four Dogs model is great for control as well as the initial planning. If a dog pulls a corner of the canvas, something has to give way because the project ‘canvas’ is very strong – it won’t stretch and it won’t tear – so don’t imagine for a moment that one factor can change with no impact on the others. So, if the project is suddenly wanted earlier, think which other dogs get pulled by this ‘Time dog’. Perhaps you’ll reduce the scope and do less. Perhaps you’ll put more staff onto the project to do things faster and meet the new deadline. Perhaps you’ll save time by reducing the testing (although that’s not usually a good option). You may do things in combination and move more than one of the other dogs, such as reducing scope slightly but also adding more resource.

Risk Category Checklist

Risk management is an essential part of any project. Very many projects fail or are badly damaged because of things that were foreseeable, controllable and even preventable. Most risk management in projects is about the negative, downside risk – spotting threats in advance and then working to control them. Some may be about positive, upside, risk to take advantage of opportunities. You should record all identified risks in a Risk Log, and you’ll find a template for Risk Log entries in Chapter 16, Templates for Control.

Risk categories can be really helpful to give structure to your risk identification. You can work through the categories one at a time and think what risks there may be in that area. You can also use the categories as an indicator of who should take responsibility for a particular risk. For example, the Sponsor might take responsibility for the business-related risks.

The next checklist is a full set of risk categories. You almost certainly won’t want to use all of them, so take out the ones you don’t need. For the ones you do need, you may even want to go into more detail for some. For example, if you work on government projects then you may prefer to have two categories. One category for political risk to discriminate between organisational politics such as the relationships between departments and another for national politics such as a change of government. As always, adapt the checklist to make it as relevant as possible to your project types.

• Political: Things like changes of government. These will affect public sector projects but others too, with changes of national policy or availability of funding.
• Economic: Changes in the national economy that can affect the project, such as an increase in consumer spending making the project to develop a new product more urgent.
• Legal: Risks related to likely changes in the law, regulations and codes of practice.
• Market: Shifts in demand or the appearance of new competitors or collapse of existing ones. That could affect projects such as those involving new product development and rebranding.
• Technology: Risks where technology developments elsewhere could impact on your project to make it even more viable, or perhaps making it not worth continuing.
• Business: Such as organisational changes in strategy or priority that would affect the project.
• Operations: Risks that could affect the running of the organisation, such as additional downtime for upgrading the production line, and which could lead to the temporary reduction of production capacity.
• Reputation: Things that could affect the image of the organisation, for example to the public or potential investors.
• Environment: Risks related to things such as waste disposal, ‘Green policies’ and chemical hazards.
• Supplier: Risk where you are dependent on your supplier. That is likely to be greater where the supplier is external but it could affect supply from within your organisation too.
• Technical: Technical risk occurs when the project involves doing something unusual or complicated with equipment, where things could go wrong or take much longer than expected.
• Resource: Risks concerning the availability and skills of project staff. That includes staff sickness, but also delays in staff being made available to your project because of over-running of other projects.
• Schedule: Risks affecting the project timeline, such as work being more complicated than expected, or a large proportion of the activities being on the Critical Path or near critical.
• Finance: The availability of funding and it being there at the right time
• Facilities and equipment: Risks to do with the availability of special equipment and facilities needed for the project, such as test rigs or laboratories.

When you’re identifying risks discriminate between risks and impacts. Overspending isn’t a risk but rather it’s the result of a risk happening; it’s an impact. Being late isn’t a risk either but another impact. Think what the risks are which could lead to that impact, such as unreliable suppliers causing delay.

Risk Action Checklist

All of the major project methods and approaches suggest categories of risk action. The headings in this checklist are suggested by the Project Management Institute (PMI) – an American based organisation but now with chapters worldwide. There are two subsets of risk actions.

The first subset is for negative, downside, risk – the things that could go wrong. Downside risks are often referred to as ‘threats’.

• Avoid: Stop the risk happening. If you have floor sockets for power in your office, people won’t be at risk of tripping over trailing leads from wall sockets because there won’t be any trailing leads.
• Transfer: Where you can give the negative impact, or at least some of it, to someone else. So, taking out insurance would transfer the financial part of the risk impact.
• Mitigate: Reduce the chances of the risk occurring and/or the impact if it does. Giving all of the project staff a big pay bonus (especially you of course) might reduce the chances of someone leaving. After that, having a replacement staff member on standby ready to step in if someone does leave would reduce the impact of the loss. The replacement person would still need time to get up to speed in the project though, so you wouldn’t have eliminated the impact, just reduced it by minimising the time needed to get a new person in place.
• Accept: This means accepting the risk without taking any action, often because the work or cost would be disproportionate to the impact if the risk does occur. You should still record the risk though and that’s for two reasons. First to record the considered decision not to take action, and second so that the risk will be monitored during the project. It may be that if circumstances change, action will be justified after all.

The second subset is for positive, upside, risk – the things that could go really well in your project. Upside risks are often referred to as ‘opportunities’.

• Exploit: The upside risk, or opportunity, might happen. To exploit it is to try and make sure that it does happen.
• Share: It can take money and effort to pursue an upside risk. It may be worth getting someone else to help fund the opportunity, perhaps in exchange for a share of the benefit.
• Enhance: The opportunity, if it happens, will be really good. Can you take action to make it even better?
• Accept: This is the same acceptance action as for a threat, you won’t take any action. If the positive risk is realised you’ll be happy, but it’s not worth extra effort and money to chase after it. It’s a conscious, recorded decision not to take action.

If you’re already a career Project Manager, or are thinking of heading that way, do consider joining one of the professional organisations. The PMI has a very large international membership, and in the UK there’s the APM – the Association for Project Managers. Such organisations are widely respected and have lots to help you, such as events and seminars. Do a web search to check them out.

Risk Plan Checklist

As part of your Project Management Plan (PMP) you should include a Risk Plan. You won’t always need all of the elements of the PMP, but you’ll always need a Risk Plan. In the plan you set down how you will manage risk in this particular project. Check your plan against this checklist.

• Review: Explain whether the frequency of risk review will be according to a factor such as probability, or at the end of each stage or at set regular intervals during each stage.

You can have a rolling review to spread out the work of risk review. If every risk is to be checked every four weeks, you could look at 25 per cent of the risks each week rather than have a huge monthly task. Have a ‘Last reviewed’ item on each Risk Log entry where you can enter the date to prevent any confusion.

• Reporting: Make clear exactly how project staff should report new risks that they’ve spotted or changes in status of existing risks, or if a risk actually happens. The reporting mechanism doesn’t have to be difficult – perhaps just a phone call to the Project Manager – but it must be crystal clear.
• Practicality: The risk reporting mechanism should be simple and fast. Some risks happen very quickly and the last thing you want is some long-winded procedure with undue documentation. ‘No Bloggins, I won’t pass on this risk because it isn’t properly recorded, in triplicate, on a form RK/113/Rev6.’
• Interfaces: Make sure that it’s clear how risks will be passed to other affected projects, up to programme level if your project is part of a programme of projects, and into your organisational risk management system if it has organisational implications.
• Risk Log access: Normally everyone should have ‘read only’ access to the Risk Log so that they can be aware of all of the risks and be vigilant in watching them. If there are any restrictions because of security or genuine confidentiality, then check to make sure that you’ve explained that in the plan.
• Authority trigger points: The plan must be absolutely clear on where the Project Manager must inform the Project Steering Group immediately of a new risk – or a status change in an existing one – and where this can be left to the next progress review or report.
• Communication: Don’t repeat the detail of the Communication Plan, but do explain how risk information will be communicated, such as in team briefings at the start of each stage.
• Clarity: Check that the Risk Plan is written simply and clearly so that everyone involved in the management of the project will be able to understand it – from Sponsor to Team Leader.
• Checked: The details of the plan should be checked out with the Project Steering Group before being finalised. Although the Project Manager is responsible for the plan, the Steering Group must be happy that the controls are sufficient since it is that group which is responsible for project governance.

Quality Plan Checklist

“Project Management is about delivering on time and within budget.” So say many people, but they’re wrong. What’s the point in delivering a heap of unusable garbage on time and within budget? Delivering to the right level of quality is vital in any project, and in the Quality Plan you sets down how you’re going to do that in this project. Have a look at the checklist to help make sure that your plan is a good one.

• Quality level: The level of quality you need to achieve in this project. Make sure that it’s both correct and realistic. Delivering too low a level will cause operational problems later, or could even mean a failed project. Delivering an unnecessarily high level just drives up project overheads for no reason.
• Standards: Check that you have listed all of the standards that will apply to the project. That means organisational standards, such as for technical work and safety, not just external ones – important though they are. You may need to get input from subject specialists.
• Mechanisms: Individual tests of project products will be set down on their Product Definitions. Overall though, what mechanisms will you use for checking things? Your thinking here will help make the resource plans and budget realistic.
• Audit: It’s one thing talking about quality, but it’s another actually delivering it. The plan should set down how auditing will be done to make quite sure that tests and checks have been carried out, and by the right people too.
• Clarity: Make sure that the plan is clear, simple and understandable.
• Checked: As with the Risk Plan on the last checklist, ensure that the members of the Project Steering Group are happy with the plan before it is finalised.

Watch out for the quality box ticking trap. Quality audit that only checks to see that documents have been signed is superficial and completely ineffective. The audit shouldn’t be checking that bits of paper have been signed, but that the tests were actually done. An awful lot of people approve an awful lot of things without looking at them properly, or even at all. And that includes you … doesn’t it? No? So you never click a box on a computer or phone app installation then to say you have read and agreed with the terms and conditions when you haven’t even opened the link to look at them? Don’t let your project quality slide into the abyss with people just ‘going through the motions’. You’ll find a few ideas for quality cross checks in Chapter 9.

Stakeholder Log Checklist

The checklist after this one, for the Stakeholder Plan, includes an item to check that the plan is complete and covers all of the stakeholders. This checklist is to help you think about all the possible stakeholders for entry in your Stakeholder Log if you are using one. As always, you can adapt it for your own organisation so that it’s useful for successive projects. This checklist focuses on people who are not working in the project itself, but you may prefer to extend it to project staff such as the Steering Group and team members.

• Senior managers: Relevant top managers who may be affected by the project or need to be consulted about it. This category can include a management board.
• Directors: Directors may be stakeholders not just because of their personal interest in the outcome of the project, but because they may be questioned about it by others and so need regular information.
• Shareholders: For private sector organisations.
• Donors: In the charity sector, it may be important to keep regular donors in the loop. You may even use the project as a means of boosting enthusiasm for your organisation’s work and so increasing the level of donations.
• Organisational managers: Managers in the Finance Department and the HR Department might be involved in redeploying your project staff when the project is complete.
• Affected managers: Managers of business units such as other departments who may be affected by what the project will deliver, the work of the project while it is underway (such as disruption), or both.
• User staff: Those who will actually use what the project is delivering.
• Staff associations: You may want to include staff associations both for consultation and information reasons. At the least they may need to know what the project is doing, but they may also be able to make a valuable contribution.
• Customers: Including potential customers. If the project is to change the customers’ dealings with the organisation, they may need to be informed or some even consulted. That consultation is common, for example, in some public sector organisations such as hospitals.
• Partner organisations: Do you need to inform partner organisations about the project? That will obviously be very important if it directly affects shared work.
• Suppliers: Often overlooked, suppliers may also be affected and may need to be informed or consulted, such as with a project affecting the way payments are made.
• Government and legal: Agencies that must be made aware or consulted about your project, or where one or more permissions must be asked for.
• The public: In terms of interest in your organisation, or being affected such as with a project to extend your HQ building.

Stakeholder Plan Checklist

The Stakeholder Plan is part of the PMP and useful if stakeholder management will be a significant part of your project – and in many cases it will. Check that your plan is a good one by working through this checklist.

• Definition: The plan should define what ‘stakeholder’ means if this term is not well established in your organisation. Some view stakeholders as only being those outside the project, while others take it to mean that it includes people inside the project.
• Completeness: Check that the plan covers the management of every known stakeholder. You can cross check with your Stakeholder Log if you have decided to use one.
• Groupings: Are the stakeholders set down in sensible groups according to the management actions you will need to take?
• Sensitive: Check that the plan is suitably worded so that it won’t be problematical when others see it. For example, you are likely to make opposition greater if you have listed someone who has genuine concerns about the project under a heading of ‘Determined troublemakers’ … or worse.
• Specific actions: Check that the management actions for each group are specific and clear, not vague. It’s no good making an entry such as ‘Needs to be kept informed’. Informed of what?
• Timing: Have you made the timings of actions clear? For example some things such as progress updates may be on a regular basis while other actions may be at set points, such as just before the project completes.
• Communications: Check that the actions in the Stakeholder Plan that involve communications are reflected by entries in the Communications Plan, covered by the next checklist. The two plans must be consistent.

When thinking about stakeholder management, watch out for stakeholders who are very much in favour of the project and who are highly influential. Your first reaction may be to think that no action is needed since they are already strongly in support of the project. However, think again – you need to keep them that way.

Communications Plan Checklist

Communications problems are an ongoing and major source of project problems leading to failure. The ‘Comms Plan’ is a very practical plan to think through what communications are needed and the best way of carrying them out. The plan should be structured with repeating blocks of information, one for each communication saying what it is, who prepares it, who is to receive it, what is in it and how it will be communicated. It’s hard to think of everything, but think of everything you must or something or someone is going to get missed and that could have huge implications. Here’s a checklist to help, divided into three communication areas.

Inbound communications

This first subset of the checklist is for communications coming in over the project boundary from outside.

• Organisational risk: Information from the organisational risk system about new risks, or changes in risk status, that could affect your project
• Interdependent projects: The state of other projects and changes in them that could impact your project, such as a change to a specification or a project delay which means that you’ll be getting your copy of the spec later than expected.
• Business change: Notification of changes to organisational policy, strategy or priorities that could impact the project.
• Change: How someone outside the project should communicate a change request. It can be chaotic, for example, to allow anyone and everyone to bombard the Project Manager with change requests. You may then set down that changes have to come through the Project User manager on the Steering Group. Having to go through one of their own managers can be a disincentive to business staff to make trivial requests.
• Finance: Information from financial systems to report project spending, and changes to the availability of finance if that is a factor for your project.

Comms within the project

The next subset is for communications between the people actually taking part in the project.

• Risk: Information about new risks, changes to existing risks or risks actually occurring. This will be based on the requirements set down in the Risk Plan.
• Quality: Information on quality work, such as that a test has been performed and the product involved has passed that test. You can use a simple mechanism such as a Quality Checklist, but you’ll need something in place so you can keep track of quality activity. You’ll find an example of a Quality Checklist in Chapter 16.
• Stage progress: Reporting progress to the Project Steering Group at regular intervals, such as with a monthly meeting or report. The Comms Plan must specify the frequency and the content of such reports or meetings.
• Team progress: The Project Manager should set down exact requirements for team level reporting in the individual Work Packages (the work assignments given to teams). However it’s sensible to have default information in the Comms Plan so ‘normal’ Work Packages can just say ‘as Comms Plan default’ rather than keep repeating the same information over and over. The reporting may be by email, or something like a regular meeting where the Project Manager meets with all the Team Leaders once a week.
• Project memos: The range of memos to be used and who can send them. For example, can any team member send a memo to the Project Manager or must they go through their Team Leader? Think carefully about this, there are pros and cons for both options.

In some methods and project standards, Project Memos are known as ‘Issues’.

• Warning and crisis: The PRIME method uses two levels of escalation of something to the Project Steering Group if something is going wrong and it is outside the authority of the Project Manager to deal with it. Whatever mechanism you use, make sure that you have spelled out how such warnings will be communicated, for example by a phone call to the Sponsor.

Outbound communications

This final subset is for communications going out of the project to the organisation beyond.

• Progress: How the project will inform others of progress made, such as organisational managers and other stakeholders with an interest in progress.
• Interdependent projects: Progress and change information that will affect projects that have inter-project dependencies with this one.
• Risk: New risks and change in existing risk status that could affect other projects or organisational risk management.
• Finance: Information on money committed and spent in the project.
• Stakeholders: Stakeholder Management normally involves significant communications, such as to maintain interest. This section should be consistent with the comms requirements set down in your Stakeholder Plan if you are using one.
• Public and media: Communications such as public announcements, press releases and other media related information. These communications should normally be reflected in the products of the project itself, but referenced in the Comms Plan to show that they are covered. If the requirement is covered in the Stakeholder section above you won’t need a separate entry. However, if public and media communications are high profile in your project, perhaps involving specialist staff such as an organisational Press Relations Department, you may prefer to keep this specialised section.

Types of Project Memo

The previous checklist on the whole of the Comms Plan noted that you should specify the types of Project Memo to be used in the project. As an example, here’s a set used in the PRIME project method, but as always you should adapt the list to meet your exact project needs.

• Issue: An idea, problem or anything else not covered by the other memo types.
• Question: Where someone in the project needs guidance from the Project Manager. It may be easier to get this verbally, but in projects covering different time zones the question might be sent by email.
• Change Request: To ask for a change to a product that has already been completed, or where the definition of it has already been agreed and signed off. This is part of the change control and is highly effective in helping to avoid the problem of scope creep.
• Non-compliance: If a product fails test then normally it’s put right and will successfully pass test the second time around. If there is some significant reason why it can’t or won’t meet its quality criteria, though, it’s reported to the Project Manager as a non-compliance. The Project Manager will take control to ensure that the non-compliance is resolved.
• Warning: A communication from the Project Manager to the Sponsor that something is off track and it requires action beyond the Project Manager’s delegated authority to deal with it.
• Crisis: A communication from the Project Manager to the Sponsor to say that a key project objective will now not be achieved or that an identified ‘showstopper’ has been encountered (such as your development being overtaken by a competitor). A crisis will often result in the project being closed down.

Communication Media Checklist

How you communicate is important if those communications are to be effective on the one hand and economic on the other. Here’s a checklist of some things to consider.

• Phone calls: Don’t forget them. With such poor email discipline in many organisations, phone calls can be particularly effective; they’re fast and they build a personal relationship too. The best way for the Project Manager to report a serious problem to the Sponsor may well be a phone call.
• Teleconference: Group phone calls which can be useful where one team needs to discuss something with another.
• Video conference: Not as good as a face-to-face meeting for project staff, but usually much better than a phone call or teleconference.
• Interactive development: Office software increasingly has the functionality for people in different locations to develop a diagram or document interactively – a sort of web based workshop.
• Meetings: Another communications medium that is often underestimated. Poorly run meetings are a well-known waste of time and effort. However a concise and well run meeting can be a fast and effective way of transferring information.
• Presentations: Some reports might be better in the form of a business presentation with brief notes for people to take away afterwards. This medium can work well for regular project progress meetings with the Project Steering Group.
• Road shows: Taking a display and presentation onto different sites can be a whole lot better than brochures or long text documents. You might want to consider roadshows to pass on project information to each regional office or to major customers.
• On-line presentations and demos: An effective medium if done well, but it can reflect badly on your project if it is done poorly. The advantage is that people can look at the presentation when they want to, and more than once if they want to see it again.
• Dashboard reporting: Long and wordy reports are a pain in the rear end and few people read them properly. For progress reports from Team Leaders to the Project Manager, and from the Project Manager to the Project Steering Group, dashboards work really well. You can have ‘petrol gauges’ showing stage and project spending for example. A really powerful element is the Work Flow Diagram, colour coded to show delivery. Have a look at the UK edition of Project Management for Dummies for much more on product planning as a means of highly effective progress control.
• Email: Okay, you’ll need it, but try to minimise it and then use it well. The advantage is that an email does provide a written record of something. The disadvantage is that an important email may be hidden amongst a mass of other emails in the recipient’s in-box and go unnoticed for some time.
• News sheet: For communications to everyone in a large project, or to keep in touch with stakeholders, consider a news sheet. It can be an electronic one. Used imaginatively to circulate information when it’s needed, a news sheet can reduce the number of inbound enquiries and so the resource needed to deal with them.
• Websites: Having a project website can save a lot of email. People can just come and look if they want information about the project rather than, for example, getting unwanted information emailed to them ‘in case they want to know’. It can also be a good way to keep stakeholders informed.

Think carefully about how much really needs to be written down. Over-documentation is a real problem in many projects, particularly those using project methods which seem to be more concerned about documentation than delivery. You want a successful project, not a well-documented failure.

Procurement Plan Checklist

You’ll have procurement information in your plans and in the budget. However, if you have significant procurement in your project then you may also want a Procurement Plan to give a clear view on what procurement actions are needed and when. Use this checklist to help make sure that your plan is right.

Under your organisation’s contracting procedures, you may need action to start and progress procurement long before the item and the service is actually needed in the project. The Procurement Plan will include the various actions.

• Contract cross check: For every contract that you know about, make sure that all the actions are set down in the plan with dates. Those actions may include things such as Invitation to Tender (ITT), contract negotiation and final selection.
• Lead times: Check that there is sufficient time for the procurement process to happen before the item or service is needed in the project.
• Involvement of specialists: Ensure that you’ve noted the need for specialist input, such as lawyers and contract staff. If any of the procurement even looks like it might be problematical, ensure that you have recorded the need to involve legal specialists at the outset. Lawyers would rather be consulted at the start so as to avoid problems than be called in later because of a crisis where something has gone badly wrong.
• Project staff resource: Ensure that you have noted the need to involve project staff. Lawyers and contract staff aren’t mind readers and need input from those who understand the projects and its needs.
• External products: Check the external products on the Work Flow Diagram. For those that involve procurement (and not all will) check that you have the details in the Procurement Plan.
• Budget and plans: Check the Procurement Plan and the project budget against each other, then against the Project Plan and Stage Plans to be sure that they are all consistent.