Chapter 16

Templates for Control

In This Chapter

Fitting the templates to your project at two levels of detail

Using an overview for some logs as well as detailed entries

Templates for controlling your projects

You might be able to use the control templates in this chapter just as they are, but if not you can adapt them at two levels. First, you can adjust each template to fit the needs of the sort of projects that you normally work with. Second, when you’re starting a new project, you can take a copy of your normal template and adjust again to fit your exact needs that time around. For example, if you have a particularly high risk project then you’ll almost certainly want a more extensive range of information in your Risk Log than you have normally.

As with all the other templates in this book, you can download electronic versions in Microsoft Word and Excel formats from the www.dummies.com/extras/pmchecklists. Feel free to adjust the electronic templates in any way that you like to suit the needs of your projects, even if that’s only to include your organisation’s logo.

For a couple of the logs you’ll find that there are two templates. The first is for an individual log entry and the second if for an overview. To take the example of risk again, you’ll find a Risk Log template for recording information about each individual risk. However, that entry could be quite long if you’ve got to hold a lot of information such as on the management actions. What you’ll find really useful in addition then is an overview of the whole Risk Log so you can look at all of the risks, and that’s where the second template comes in.

For a Risk Log Entry, you’ll almost certainly want to use a word processor app as it will be unwieldy to put lots of text into spreadsheet cells. In contrast a spreadsheet is excellent for the overview where you duplicate limited information with each risk on a single spreadsheet line. That format allows you to scroll up and down and see all the risks, and also to sort the risks according to different criteria, such as severity and review date. Of course, if you’re really computer literate you can build a database in which the full information and the subsets are just different views.

Think carefully before setting up standard databases for things like the Risk Log. While your Project Office may be keen to set up a default database which each project can then copy and use for their risks, such a database can be limiting. The default database may have particular views included, such as one that allows you to see risks grouped by severity rating. However, unless you have database skills you may need help every time you want to view the data in different way. A spreadsheet, on the other hand, is usually much easier for everyone to understand and use. If you have a database then you can always export the required current data to a spreadsheet each time you want to manipulate it, but now you’re just making extra work. Anyway, once again there may be too much information in each spreadsheet cell to be able to get a clear overview.

Change Log Entry

A Change Log is a great idea and the use of it I describe here is based on the PRIME project method, which has a particularly effective approach (though I’m totally biased: I helped design it). If someone puts in a change request that’s not sensible, then it shouldn’t get as far as the Change Log. However if the change is worth considering, then you make an entry in the Change Log and track the change from there. Having all the changes in one place means that you keep a clear view of what’s going on. In a busy project that view can be extremely valuable.

• Change ID: Just a simple reference number or you could prefix it with a letter to show the type of change such as ‘N’ for new requirement and ‘E’ for the correction of a previously undetected error.
• Change name: A very short description of just three or four words if possible so that you can use it as a heading. ‘Adjust order input screen’ is a good example. This will help you find the change quickly if you are looking for it amongst other entries.
• Status: The current status of the change such as ‘Under investigation, being implemented, on hold, referred to PSG, closed’.
• Priority: Perhaps on a scale of 1–5, or you might use a text range such as that based on the MoSCoW acronym (must have, should have, could have, won’t have at this time).

The priority should be set by someone involved in the management of the project, not by the person asking for the change unless they are part of that management team. Most people, particularly junior business staff, think that the changes that they want are all top priority.

• Source: Where the change request or change requirement came from. The source will normally be the person who asked for it but it could be something like a new organisational policy that affects the project.
• Description: Details of the suggested change and the reason why it’s being requested.
• Impact: For some changes this could be a substantial section listing all the different impacts.
• Resource: The staff resource that will be needed to carry out the change.
• Estimated cost: How much you expect the change to cost based on current information.
• Decision: Whether or not the change is to go ahead, who made the decision and when. In many cases it will be the Project Manager who decides on the change but sometimes the matter may have to go to the Project Steering Group (PSG).
• Final cost: The eventual cost of the change after the work has been done. This entry is important to calculate use of the Change Budget. There’s a neat use of this entry in the next template, the Change Log Overview.

Change Log Overview

There can be a great deal of information in a Change Log entry, particularly in the ‘Impact’ section. An overview of the log, which you’ll probably want to hold on a spreadsheet, is very useful with limited information about each change on a single line. As this is mostly a subset of the Change Log entries, only one heading needs explanation.

• Change ID
• Status
• Priority
• Source
• Short description
• Estimated cost
• Decision
• Final cost: This is the entry that gives the final cost of the change when it’s done and is the ‘neat use’ mentioned in the earlier Change Log Entry template section. See the tip below for a steer on how to use it.

If you include a ‘Final cost’ item on your spreadsheet overview and put in a formula to give a total for the column, you can then see exactly how much of your Change Budget you’ve used so far. If you want to track committed money as well as how much you’ve finally spent, you could have an ‘Expected cost’ column as well, once it’s been decided to go ahead with the change. This idea is taken from the PRIME project method which has a powerful but simple range of financial controls. Many other approaches and methods simply don’t cover this aspect of control and leave you to struggle and find your own way, which is an inexcusable cop out. Financial control is obviously a vital part of project management, and that has to include your use of the Change Budget.

Product Definition

For every product on your product planning diagrams you should produce a Product Definition. Product Definitions really earn their keep – they’re not bureaucratic overkill. It’s so easy for someone to misunderstand what’s needed and to then build the wrong thing. The Product Definition spells out exactly what’s needed including, importantly, the quality criteria it must meet.

You’ll produce the Product Definitions while planning, but the template is included in this chapter because once written, the definitions form part of the Work Packages (there’s a template later in this chapter for those) which are an important element of control.

• Product ID: A number, perhaps taken from your WBS (Work Breakdown Structure).
• Product name: The short name, again taken from your product planning diagrams.
• Description: A description of what the product is, including whether it is made up of any sub-products. You should include here any information about what it should look like. For example, you could say of a report that it should be A4 size with the financial information presented in tables rather than in the main text.
• Quality criteria and tests: In this section record what criteria the product must satisfy in order to be accepted. For example, you could say that a report should be understandable to the target audience or that the new office layout should comply with the 11 cubic metre minimum space per person regulations. Against each of the criteria you should then specify what test(s) will be needed to confirm compliance. With the report, you might want to get two people from the target audience to read a draft and highlight anything that they don’t understand.
• Resource: What staff resources you’ll need for building the product and then testing it. Be careful to note any needs for specialists on the one hand and for completely unqualified and inexperienced people on the other.

Think hard when it comes to resources for testing. Sometimes you want people for their lack of experience and understanding. If, for example, you’re installing a new computer system and have written a user guide, the last person you want to check the guide is one of the development team who already knows exactly how the system works. The ideal person is a member of the user staff who has never seen the system before. You sit them down in front of a computer with the test system loaded and say ‘There’s the user guide and some customer information. Please input a new customer record.’ That will show you whether the guide is a good one.

Project Log

The Project Log is a practical and powerful document, which you’ll usually keep on a spreadsheet or possibly in a word processor document. The log is there so you can note down reminders of things to do, Project Memos that have come in and things that have happened. Used imaginatively the Project Log can save a lot of formal and more lengthy documentation.

This template is a bit of a cheat because there isn’t much in it – in terms of the headings anyway. The entries are basically a date followed by a note although, as you’ll see, you can add a couple of bells and whistles to make it more useful still.

• Date and number: The date, and then the number of the entry that day. So, 20-11-20XX/3, the third log entry on 20 November 20XX. Okay, okay; if you’re American you can switch the date format around if you think you really have to depart from the entirely sensible UK format. Good grief, you even drive on the wrong side of the road and misspell ‘colour’.
• Category: The type of entry, such as a note, a Project Memo or a reminder.
• Status: You’ll usually want to keep this very simple such as ‘open, on hold and closed’.
• Notes: The details that you want to record.

Risk Log Entry

This template is for recording details of a single risk. Use further records for more risks to make up the full Risk Log.

A risk is uncertain. If something will happen for sure then it isn’t a risk and should be covered in the plans.

• Risk ID: Usually the next in a number sequence running through the Risk Log.
• Risk name: A short descriptive name of the risk so you can easily understand what it is such as ‘team specialist resigns’ or ‘extra energy savings’.
• +/-: Whether the risk is an opportunity or a threat (an upside or a downside risk).
• Status: The current status of the risk using the chosen range for the project, such as ‘under review, increasing, decreasing, stable, dead’.
• Category: Using your chosen range of risk categories such as ‘business, technical, environmental’.
• Description: A (preferably brief) explanation of the risk and how it is likely to behave. For example, will it come on very slowly where the danger is that it won’t be noticed, or will it happen suddenly requiring a very fast reaction?
• Origin: How the risk was identified and in some instances by whom. For example, it might have been reported by a team member or it might have come from your standard risk list for this type of project.
• Impact: On the impact scale selected for the project (for example 1–5, 1–10). It’s also helpful if you add some explanation on the nature of the impact, not just give a figure.
• Probability: Using your defined scale (for example, 1–5 or 1–10 or a probability percentage).
• Severity: Impact multiplied by probability – where you’ve used a numeric scale for those factors.
• Owner: The person responsible for the risk and who can authorise action.
• Management action(s): The actions selected to control the risk. Where this involves people, specify against each action who will take it.
• Review: When the risk should be reviewed, such as every four weeks or at the end of each Delivery Stage.
• Next review date: When the next review of this risk is due. It will give you a warning if you’ve missed a review because the date will be in the past.

As mentioned at the start of this chapter, you can make this template more sophisticated if you are dealing with a project with a high level of risk. For example, you might find it helpful to record the degree to which the risk is controllable. Something like bad weather is inherently uncontrollable, in the lifetime of your project anyway. Other risks may respond well to your risk management actions.

Risk Log Overview

The previous template covered the full range of detail that you might need to hold on an individual risk. If you have a large Risk Log, you can’t see all the risks at once. Like the template for the Change Log Overview, this one duplicates the control entries from the log. As the headings are a subset of the Risk Log there’s no need to explain them.

• Risk ID
• Risk name
• +/–
• Status
• Severity
• Owner
• Next review date

Stakeholder Log

The Stakeholder Log is another simple log which, as the name suggests, is basically a list of stakeholders. The log is important because you need to keep track of stakeholders and make sure that you’ve got all the necessary management thought through in your Stakeholder Plan. Have a look at Chapter 11 to see a template for the Stakeholder Plan.

• Name: The name of the stakeholder, obviously enough. It could be an individual or something like ‘management board’ or ‘on-line customers’.
• Date identified: You won’t always need this heading on the template, but sometimes it’s helpful to know whether a stakeholder was identified at the outset or later on in the project.
• Interest: What interest the stakeholder has in the project, such as that they will use what the project is finally delivering. Use this section also to note whether the stakeholder has any concerns about the project or is generally supportive.
• Group: Sometimes you can group stakeholders for action. For example there may be a number of stakeholders who just need to be kept informed of progress on the project so you can handle their needs in the same way at the same time. There’s more on this on the Stakeholder Plan template in Chapter 11.

Quality Checklist Template

The Quality Checklist is simply a list of tests, checks and any other quality actions (such as quality audits) that are to be done in a stage, together with a sign-off of each one when it’s done. You can then see at a glance whether something has been overlooked. You compile the list of tests from the Stage Plan and the Product Definitions.

Don’t be fooled by the Quality Checklist. It may be simple, but it’s enormously powerful to help make sure that the required quality is delivered and tests aren’t missed out. In fact, the power of the list is largely because it’s simple; it’s quick to build, fast to check through and extremely low overhead to maintain.

• ID: If you need it, and usually just a sequential number.
• Name: A short descriptive name, such as ‘loading test’.
• Product: The ID and name of the product to be tested, if a product is involved. If the item relates to something else such as a quality audit then just leave this section blank.
• Responsibility: Who is responsible for the test or other quality action.
• Planned date: The date that the test is due to take place, taken from the Stage Plan.
• Sign-off: The signature (preferably) of the person who did the test and the date that it was done.

Version Control Record

Some things in your project will need to be version controlled. For example, you’ll always need to know the latest version of a product that’s been changed, such as a design, or even for some management products such as the Project Plan. To keep track of the products you’ll need a central record for each one being controlled.

Some approaches, such as the UK’s leading project management method, have a horrendously long and complex list of data items for version control. I once designed the control for a rather sensitive computer system where versioning was vital, but I never needed a fraction of the information set down on that method’s standard form. Think through carefully to identify what you genuinely need for version control and don’t get unnecessarily complicated – KISS, keep it simple, stupid.

This template gives you a basic list of headings for version control, but you can always add more if you really need to.

• Product ID: The reference number for the product, usually as used on its Product Definition.
• Product name: A short name for the product so you can recognise it quickly. For example, ‘Floor Plan’ and ‘Business Case’. Stick to the short name you used for the product in your product planning.
• Current version: So people can check whether they have the latest version of a design document, for example.
• Current status: Such as whether a report is in draft or final format, or whether a machine is built, installed, tested or commissioned.
• Last amended: Particularly useful for version controlling documents, the date it was last changed.
• Location: Particularly appropriate for team products (as opposed to products you are using for project management such as the Project Plan). If a product has now been created, where is it?
• Owner: The person currently responsible for the product. For a lot of products that may be the Project Manager until they are handed over for operational use.
• Knowledgeable person: often one of the people who helped build the product, but if they’ve left the organisation you’ll need someone else. If you’re considering a change, this information is incredibly useful so you can check whether the change is sensible.
• Change history: a simple list of changes made, usually since the product first passed test. For each entry include:
  • Date: The date on which the change was completed
  • Change: A short summary of the change
  • Reason: Why the change was made. This entry can be very important. For example, someone may think a change looks weird and should be reversed, until they read this section and see that it was necessary for legal compliance.
• Cross references: Useful for circumstances in which a product is made up of sub-products that are also being version controlled. It’s also useful for things like engineering drawings, where a change on one might require changes on others to keep them consistent.
• Related documents: This is another cross-referencing section but this time for documents. There may be related correspondence, entries in the Change Log and entries in the Project Log.

Work Checklist Template

There aren’t many headings in this template. Good, isn’t it? Try and keep it that way. The Work Checklist is something that you can use to help with stage control. It’s a simple list of the products to be produced in a Delivery Stage so you can track progress by delivery.

• Product ID: The ID from the product plans, such as the Work Breakdown Structure (WBS).
• Product name: The short name, again from the product plans.
• Status: The status, such as ‘Not started, under construction, being tested, delivered’.
• Planned delivery date: The date, taken from the Stage Plan, when the product is due.
• Actual delivery date: The date the product was finally delivered. That means that it had successfully passed all of its tests and checks or was specifically exempted because of a problem in meeting the required quality.

‘Delivery’ in the context of product based planning means that the Team Leader has passed the product over into the control of the Project Manager. For a physical document that might mean hole punching it and filing it in the project records or scanning it and putting the electronic copy in a particular computer directory. However if the product is something like the central span of a suspension bridge then it isn’t going to be ‘delivered’ in the sense of being put somewhere else such as in a filing system – for a start you can’t get it through the doorway of the file store. Instead the Team Leader will notify the Project Manager that the product has been ‘delivered’.

Work Package

The term ‘Work Package’ is used in many approaches to project management and simply means a work assignment given to a Team Leader, or just to an individual if your project is a small one. Whatever the size of the project, though, it makes sense to give the team or the person instructions on exactly how the work is to be managed. If the instructions in the Work Package are straightforward, then that’s great, but still record them. And if they’re straightforward it isn’t going to take you long to set them down – certainly much less time than if there’s a misunderstanding because of a lack of clear instructions.

• Package ID: A number, but in a bigger project particularly you might prefix it to give other information. For example, 6-I-9 might refer to a Work Package in Stage 6, given to the Implementation Team and it’s their ninth assignment in the stage.
• Team: The team or individual who creates the products in the Work Package.
• Product(s): The product or products that the team is to create in this assignment. For each one you should provide a copy of its Product Definition.
• Controls: Controls such as the frequency of progress reporting and what to do if something goes significantly off track.
• Time and cost: When the products covered by the Work Package are due to be completed and delivered. You might also include a budget if the Team Leader is to control the spending too.

As with the other templates in this book, you can add in more headings if you need them. However, be careful not to get too complicated. Don’t start unnecessary duplication of information that is readily available to the Team Leader elsewhere. An exception is for the target date for delivery and any budget because it only takes a moment to record those details and it makes it crystal clear what your requirements are for completion.

Stage Gate Agenda

A Stage Gate is the meeting of the Project Steering Group (PSG) with the Project Manager at the end of each project stage. The agenda is quite long and that reflects the importance of the meeting as reflected, quite rightly, in the international ISO standards and notably the project management standard ISO 12500:2015. Stage Gates don’t happen very often and it’s an essential element of the PSG’s control in order to fulfil its responsibility for good project governance.

The template reflects the three views at a Stage Gate as explained in Chapter 14, Conducting a Stage Gate.

• Stage Gate: The name of the Stage Gate, such as End of Stage 4.
• Meeting details: The planned date, time and location of the meeting.

The Last Stage

A report and check on the stage just finishing.

• Stage Completion Report: The presentation of the completion report by the Project Manager including any matters which she wants to bring to the PSGs attention.
• Stage review: Discussion and questions on how the last stage went overall, including costs and team performance.
• Quality: Specific confirmation that the required quality was delivered for products created in the last stage.
• Forward view and lessons: Discussion on any implications from the last stage for the rest of the project, and also the collection of lessons learned (based on both good and bad experience) that need to be passed on into the organisation for the benefit of other projects.

The Present Position

A review of where the project is at the moment, a decision on whether it should continue and adjustment of any controls.

• Business Case: A check of the recently updated Business Case to see whether the project is still viable.
• Risk position: Evaluation of the current risks, again to help determine whether it’s worth continuing. If the benefits have fallen from the first projections but the negative risk has increased considerably, then it may not be worth continuing.
• Viability decision: To establish whether the project should continue or be closed early. If the decision is to close it, the Sponsor should now give that instruction to the Project Manager and the rest of the agenda will be replaced with discussion of the closure arrangements.
• Project Charter review: To check that the Charter is up-to-date and relevant for the project as it is now.
• Controls review: Discussion to establish whether the project controls are working satisfactorily and review any changes proposed by the Project Manager. For example, does the Project Manager have sufficient delegated authority for change control, or is she having to refer too much to the PSG for decisions? Further adjustments should be discussed if the PSG is unhappy with the degree of control in place for the next stage.
• Risk management review: A specific check to ensure that the risk management is working effectively and to make changes if it isn’t.
• PSG review: The PSG members should honestly and frankly review the working of the PSG in the project up to this point and decide whether individual members are fulfilling their roles. If not, changes should be made now.

This PSG review must be done by the PSG members themselves and has to be brutally honest. It should not be PSG members turning to the Project Manager with fixed smiles on their faces and asking her ‘So, do you think we’re doing a good job then?’ It would be extremely hard for all but the bravest Project Manager (and one who has already abandoned all hope of promotion) to say ‘Well, actually no. You’re less use than a chocolate teapot.’

• Organisation review: A check to ensure that all other people are functioning well and remain the right people for the project. Changes should be made if not.
• PMP review: A check of the Project Management Plan (PMP) to ensure that any changes to controls have been carried through correctly and that the PMP is sufficient for the effective day-to-day management of the next stage.

The next stage

If the PSG has decided to continue with the project, it must then authorise work to start on the next stage, provided that the PSG members are happy with the plan.

• Stage Plan: Presentation of the next Stage Plan by the Project Manager. PSG members must be convinced that the plan is realistic and achievable.
• Resources: Confirmation that funding and the required staff resources are in place.
• Purchasing: A review of any major purchases to be made in the next stage, as recorded on the plans, and any arrangements needed before the money can be spent such as final confirmation from the organisation’s Finance Director if a spend is a particularly big one.
• External controls: A check on any external controls in the next stage so PSG members are aware of them. For example, building inspections or central audit checks on the adequacy of financial controls in a new computer system.
• Approval: Authorising the Project Manager to start work on the next stage. This approval should be recorded and signed, but can be done simply by the PSG members signing a panel on the Stage Plan.

Conclusion

This is to close the meeting and make sure that everyone is aware of the first progress meeting in the new stage.

• Actions: A summary of any actions agreed in the meeting that weren’t carried out on the spot, such as to find a replacement Project User on the PSG if the current one said she no longer had the time to fulfil the role properly.
• Next meeting: Confirmation of the date of the first Stage Review Meeting in the next stage as set down on the Stage Plan.