Chapter 9

Establishing Controls

In This Chapter

Getting in control – staying in control

Balancing the control against the needs of the project

Checklists for thinking about controls

Checklists for creating the control documents

It’s one thing getting a project up and running, but it’s another keeping it in control so that you can move smoothly through to delivery. You’ll have to think through and plan the controls before you get caught up in the busyness of the project, and that’s why this chapter comes in the Planning section of the book.

A key message for any project is get it in control – keep it in control. It would be nice if this chapter could just give you a ‘how to’ checklist to achieve that control but, of course, it isn’t quite as easy as that. The nature and degree of control you’ll need depends on the project, any standards in your organisation and, perhaps surprisingly, you; there’s room here for your own preferred way of running projects.

As you come to think about control, the point to remember is that it’s all about balance; the control needs against the overheads of those controls. A highly complex, high-risk project with dozens of people involved will need much more in the way of control than a simple, low-risk project that only involves you and one other person to help.

Watch out if your organisation, or Project Management Office, is one that tries to apply a one-size-fits-all approach to projects. That leads to even small, straightforward projects being swamped in excessive controls and heaps of paper designed with much bigger and more complex projects in mind. The result is excessive work and unnecessary overheads, which are in nobody’s best interest. It’s certainly not in your best interest if it’s you that ends up having to do all the unnecessary work! You may need to work with your Project Steering Group to challenge unnecessary controls and get exemption from irrelevant ones.

This chapter is to help you think through what you need by way of control … and also what you don’t.

Another warning? Well yes, because organisations make a lot of mistakes around the area of control. Where they have tried to take a more flexible approach it’s common to fall into a different trap. They adjust the degree of control required according to the size of the project such as large, medium and small projects, and that’s wrong. For example, a very big project may actually be very low risk and need little in the way of controls for risk, while a much smaller project may be extremely high risk and need very sophisticated risk management. So, think about the whole range of characteristics of your project, not just its size.

Project Characteristics Checklist

When you’re thinking about the degree of control you’ll need for your current project, consider these characteristics.

• Size: The size of the project isn’t the be-all-and-end-all when it comes to thinking about control, but it’s still a factor. A very big project with a lot of people and money involved will usually need more control than a very small project with just two or three people and a small budget. Please note the ‘usually’ in the last sentence though because there are exceptions arising from the other characteristics.
• Geography: If your project is to be run across several sites, or perhaps even in different countries, you’ll need more control than you would if everyone were in one place.
• Business criticality: If the project is extremely important to the business – perhaps a new product launch or re-branding – then it justifies more careful control than if it won’t have a lot of impact if it fails.
• Complexity: Complex projects need greater control than simple ones.
• Inter-project dependency: You’ll need less control if your project is stand-alone than if there are a lot of inter-project dependencies where your project will affect the running of other projects and their work will affect yours.
• Business impact: You’ll need more control if the project will affect other parts of the organisation rather than just the area where the project is running. There will certainly be more in the way of communications but you may also need to co-ordinate the integration and include things like pilot installations.
• Organisational experience: If your organisation has run lots of projects like this before, the project will need less control than if this is the first project of this type that’s ever been done. Experience pays since project staff have a better idea of what’s involved and how to avoid the known problem areas.
• Project Manager experience: If the Project Manager is very familiar with this sort of project, then controls can be lighter than if this is the first time that he or she has ever run a project like this.
• Timescale: If the project must deliver to a tight timescale, and particularly where the end date is fixed as well (such as the end of a financial year) then you’ll need more control than if delay would be regrettable rather than devastating.
• Visibility: If the project will be highly visible, such as to customers, donors (for a charity), government or shareholders, you’ll need to exercise more control to be quite sure that things go right. Reputation damage from the failure of a high-visibility project can be very severe and is often underestimated.
• Risk: A high-risk project needs more control than a low-risk one. Have a look at the overall risk level, as well as other items in this checklist that are risk-related, such as the last one about visibility.
• Quality: If your project requires extremely high-quality delivery, such as with safety-critical systems, it will need more control than if the project is genuinely ‘quick and dirty’.
• Teams: Will you have a single team, a few teams or many? A single team working through the project is much more intimate and you’ll be more aware of what’s going on, so your controls can be simpler.

Your assessment of the different project characteristics will affect the nature of the controls, but then also the plans of how you will set up and operate them. Plans such as the Risk Plan, the Quality Plan and the Communications Plan go into the ‘folder’ known as the PMP – the Project Management Plan. You’ll find more about the PMP in Chapter 2.

Stage Decision Checklist

The big control in projects is the Delivery Stages. It’s a Project Steering Group (PSG) decision on how many there should be in the project. If the PSG wants to authorise less at a time and check the project more frequently, its members will specify shorter stages and that will mean more Stage Gates (the review at the end of a stage). However, while the PSG’s control is greater with more stages, so are the overheads. More stages mean more Stage Plans and more Stage Gates, and they cost time and money. If the PSG wants fewer Delivery Stages, even down to just one where it authorises all the work to be done in one go, the overheads are reduced … but then so too is the PSG control.

So what factors should a PSG and the Project Manager bear in mind when thinking about stages and stage boundaries? You might even think a checklist would come in handy here.

• Finance: The maximum that the PSG is willing to authorise at a time. If the limit is $1 million, and a block of work is estimated to cost $1.6 million, it will have to be done in two Delivery Stages with a Stage Gate between them.
• The timing of major spends: Have a stage end just before, not just after, a major spend. The PSG can check the project, then authorise the project continuing into the next stage and making the big investment. That’s much better than spending a whole heap of money on something really expensive, then having a Stage Gate and deciding that the project is no longer viable and that it should be stopped early.
• Major deliverables: Sometimes in projects there are one or two really significant deliveries during the project and not just a big one at the end. Often these interim deliveries make a good stage boundary as a natural break point at which to pause and take stock.
• Major resource change: A small change of resource, such as one supplier team leaving and another one arriving, is not a reason to have a stage boundary. However a big shift, perhaps from one major supplier company who did most of the work in the first part of the project to another major supplier who will do most of it in the last part, is a good stage boundary. In that case you’ll probably want to change the Project Supplier on the PSG too.
• Supplier payment points: Small suppliers in particular can’t wait until the end of a long project to be paid. They will have gone bust long before then because of their need to pay staff. Often, then, you will have to set up ‘staged payments’. You can adjust the project stages accordingly to check the supplier’s work at the end of each Delivery Stage and then pay them.
• Time: This factor is rather like the finance in the first point on this list. The PSG may have a maximum time that the members are willing to go without having a thorough review at a Stage Gate. Stages will be different lengths, but the PSG may specify that no stage is ever to be longer than 12 weeks, for example.
• Risk: In a low-risk project, the PSG will normally be happy for stages to be longer than in a high-risk project.
• Key decision points: A point in the project where an important decision is made can be a good stage end. The PSG may not be involved in making that decision but if it could affect the running of the rest of the project, or even determine whether there is to be a ‘rest of the project’, then it’s another good point at which to take stock.
• Planning horizons: Sometimes you can’t see clearly to the end of the project. However, you can see the first bit clearly, and you know that when you reach the end of that you will be able to see the next bit, and at the end of that you should be able to see to the end of the project. I think of it as being like driving down a foggy road. You can use these ‘planning’ horizons – or at least one or two of them – as a factor in the stage length decisions.

Progress Report Checklist

Everyone calls them ‘Progress Reports’ but usually Progress Reports report more than just progress. They actually report the state of the current stage. Dashboard reporting with diagrams such as ‘petrol gauges’ can be particularly effective for the reports. You may deliver the report verbally in the form of a business presentation instead of a paper-based or emailed one.

Whichever form of report you use, here’s a checklist of information so you can think through what your project will need and what it won’t.

• Delivery: The products which have been delivered (quality checked and signed off) compared with what was planned to do by this point.
• Stage spend: The stage spend to date compared to the budget for this point, and the projected spend for the rest of the stage compared to the plan.
• Project spend: Your current projection of the final project cost compared to the original estimate.
• Time: If your projections show that the stage will finish on time, or early, or late. If it’s early or late, by how much will it vary from the plan.
• Change: The amount of change budget used in the stage so far and the extra staff time used to carry out approved changes.

It makes sense to have a separate change budget. The stage budget is for work that is planned but changes, by definition, are not planned. It’s logical to fund changes separately, but the spend is conditional. If nobody asks for any changes, the Project Manager cannot use the change budget for other things. Otherwise the important warning sign of overspending in the stage could be disguised and so missed.

• Team performance: The degree to which teams are exceeding, achieving or falling below the expected performance. That has implications for the delivery of the rest of the products in the project. It may be, for example, that products are consistently being built with less effort than expected and so the whole project may come in early. In turn, that could affected scheduled resources (people and equipment) that will now be needed earlier than originally planned.
• Quality: The degree to which the required quality is being met. You might use a measure such as the number of products passing test first time, or the ratio of re-work time (correcting errors) to original build time.
• Risk: The current overall status of risk, such that it is falling across the project or increasing, as well as comments on the status of individual key risks and reporting of any new ones.

Problem Solving Checklist

Even in the best-run projects, things are going to go off track. When something does go wrong, use this checklist to help understand the problem and to decide what you’ll do about it. This checklist is broken down into three areas to make it easier to zoom in on the things you’ll need; timing problems, resourcing problems and spending problems.

Timing problems

If things are taking longer than expected, have a look at these causes and things you might consider to help get things back on course.

• Team availability: If things are taking longer than expected, check whether the team working time to build products is greater than you estimated or whether your staff have less available time to work on the project than expected. If the team’s availability is reduced, try to free them up to get the resource levels back to what was planned for. You will usually need to involve the members of the Project Steering Group who agreed that resource in the first place.
• Unexpected work: Is the delay to work that was already planned for, or has extra but necessary work been discovered? If known work is off track, look at the next bullet point. If extra, but essential, work has been identified, review your plans. Talk to your team members to see whether they can see anything else that’s missing. It’s better to get all of the bad news now rather than have this instance as merely the start of a whole string of similar problems.
• Extent: If products are taking longer to build than planned because of unexpected complexity, check whether the delay is likely to just affect those products, or whether this is the start of something bigger, and you have underestimated the work needed for all products.
• Supplier delay: Check to see if the teams are waiting on suppliers who have missed deadlines. If so contact the suppliers. If the supply is subject to contract, work with your contract staff.
• Inter-project dependency: If your teams are waiting on a product being sent in from another project, contact the other Project Manager to get an update and to remind him or her of the impact on your project. Also review your controls for getting early warning of delays on interfacing projects.
• Quality: Check to see whether products are failing test, and the delay is because of the need for re-work and re-testing. If quality is the cause, look at why products are failing. Is the quality set incorrectly? In that case you may need to revisit your quality plan and individual product requirements.
• Early completion: This might look strange on a list of problems, but check it out because early completion can indicate a problem. Are teams finishing early because products are not being built to the right standard or because vital quality checks are being missed out? If the work is proving less complex than expected, assess the remaining products to see whether it is likely that the whole project can be delivered earlier.

Resourcing problems

It’s not uncommon that the major problems in a project arise not from the work itself but from the staffing, whether in the suitability of your people or their availability. Use this checklist if you are hitting difficulties in this key area.

• Quality: no, this isn’t a mistake and a repeat from the earlier list. This time it’s where you have a lot of problems with achieving the required quality level, but the specification is correct. You should now look at why staff are stuggling to meet the quality levels. Have you got the right staff or suppliers, and do they have the right facilities and equipment needed to achieve the standard you require?
• Non-conformity: If supplier products are being delivered below standard, contact the supplier quickly to try and find the reason and if it’s just a glitch. If it isn’t a one-off glitch and you have a poor supplier (so that’s why they were so much cheaper) you have a real problem. You may need to terminate the contract and quickly look for another supplier. Contact your legal or contracts people now to discuss the problem and don’t wait until it has got bigger.
• Staff change: you need staff stability in the project, and if staff are being taken off unexpectedly then you have a resource reduction. Even if the replacement staff are just as skilled, it will normally take time to get up to speed on your project. If a lot of unexpected staff changes are happening, talk to your PSG and spell out the impact.

Spending problems

If the spending pattern is different to what you planned for this point in the stage, check out this list.

• Delivery: How does the spending compare with delivery? If your teams are ahead of schedule, the spending may be on track even though they have spent more than was planned for this point.
• Early spending: There’s a world of difference between early spending and over-spending. For example, if equipment is being bought early because it’s on special offer at the moment, the eventual spend may be below budget.
• Increasing costs: If things like equipment and facilities are costing more than was budgeted, an overspend may be unavoidable. However, you may need to warn the Sponsor if you think the overspending will continue beyond any flexibility within the stage budget.
• Changes: If approved changes being carried out by suppliers are proving very expensive, you may need to change your change control approach to minimise changes. That could have a negative impact on your project, but not as negative as running up huge unforeseen bills.

A lot, or even most, suppliers are very good. However, you have to be streetwise and on the lookout for those suppliers who aren’t as ethical – and that can be big companies as well as smaller ones. If suppliers are putting in huge bills for even minor changes, you have a problem. It’s a bit late for this project but an important lesson for future ones. Some suppliers will put in a very low bid, and even understate the work involved, in order to win the contract. Then, hidden away in the small print of the agreement is a huge charge for extra work, and that’s how they make their money. Be very careful to check the charges for additional work when you work with your contracts staff to set up the contracts. And don’t fall into the trap of thinking that it doesn’t matter too much because you can’t see that you’ll want anything added in.

Change Checklist

You must have change control in your project if you are to avoid scope creep, the big project killer. Just in case you’re not familiar with the term, scope creep is the gradual and uncontrolled inclusion of a large number of very small changes in the project, but with no extra time or resource to do them. Each change is so small that the project is just supposed to absorb the extra work; it’s only a ten-minute job after all and what’s that on a $50 million, two-year project with 60 staff? Cumulatively the small changes add up to a huge total, and occur frequently enough to kill the project, which now can’t deliver to the required time or within budget.

Change control is not to prevent change, but to consider whether the change should be made. If it should, you’ll usually need additional time, money and staff resource to do it.

When you get a change request, have a look at this checklist to see if you think it should be done.

• Essential: You may stop immediately on reading this point. The change is essential and must be done, perhaps for legal compliance or because it involves the correction of a serious error. It’s a no-brainer.
• Benefits boost: Assess whether the change would increase project benefits.
• Benefits reduction: Check whether the change would reduce benefits in any area. Be especially careful with shared projects where several organisations are taking part. If a change eliminates all the benefits for one of those partners, they will pull out and that could bring the whole project down.
• Time impact: Check how long it would take to implement the change and whether you have that time available. Clearly this point will be more significant if you have a fixed delivery date for your project.
• Resource impact: Check what staff resource would be needed to perform the change and whether you have that resource available or could get extra.
• Cost impact: Check what the change would cost, and whether sufficient change budget is available, or whether extra funds could be obtained.
• Risk: Check the impact on risk. The change might increase or reduce negative risk, or help you take advantage of an opportunity (upside risk).

Change Options Checklist

A lot of people asking for a change want it done right away, and of the rest most want it done yesterday or preferably the day before. You have some options with your final decision on whether or not to carry out a change; it’s not simply ‘yes’ or ‘no’. Even if it’s ‘yes’ it doesn’t always have to be right now. This checklist sets out the possibilities.

• More information: In some instances you may need to ask for more information to make an informed decision. Don’t make a poor decision based on inadequate information when with a bit more detail you could make a good decision.
• Yes: Okay, you’ll carry out the change right now. You have the time, change budget and authority to commit to it.
• No: You don’t think that the requested change is advantageous, so you turn it down. It helps if you explain your reasons to the person who asked for the change.
• Refer: The requested change is worthwhile, but big. The time, cost, impact or any combination exceeds your delegated authority so you refer it to the Project Steering Group for a decision.
• Perhaps, but later in the stage: It’s a good change, but minor. You don’t want to use up all of your change budget on trivial stuff at the start of the stage and then have nothing left for something important later. So you tell the person asking for the change that you’ll do it towards the end of the stage if you still have budget left but if you don’t, you won’t.
• Perhaps, but later in the project: A good change again, but too big to accommodate in this stage. You’ll talk to the PSG about having the work added to a later stage in the project.
• Perhaps, but not in this project: Again the change may be a really good one with substantial business benefits, but you don’t have time to carry it out in this project. You may be up against a fixed deadline and carrying out this change would mean missing the deadline and the whole project failing. However the change will be recommended back into the organisation for adding into a future project or doing as a stand-alone job. That recommendation will normally be made through the PSG and often by the Sponsor.

Communication Pattern Checklist

Part of your control decision making is on how staff can communicate. Communications can be sensitive, particularly where you have teams in different departments reporting to different managers who want to be kept in the loop, or even in control of what is happening. The communication pattern may already be fixed as an organisational norm, but you think that for the project to run well you’ll need to change it. Here are some options, with a few diagrams this time.

• The star: This option is where the Project Manager is in absolute control and all communications must be through him. It means that the Project Manager knows exactly what is going on all the time, but it has high overheads and can lead to the project staff feeling disempowered. Figure 9-1 shows the star.

  

• The hierarchy: This allows some communication at lower levels, but referral through higher level managers for communication across teams. It can lead to delays and misunderstandings (‘chinese whispers’), but it does put the managers in control. Figure 9-2 shows the structure of a typical hierarchy.

  

• The bridge: If you are stuck with hierarchical communications in your organisational environment, you may be able to set up some ‘bridges’ to allow specialists in different teams or parts of the organisation to communicate directly on particular aspects of the project. Figure 9-3 shows a hierarchy with a bridge.

  

• The network: where project staff can communicate freely with each other, no matter what team they are in, and the Project Manager and Team Leaders will never even know about some of the discussions. This works well with experienced teams … and very secure Project Managers and Team Leaders. Figure 9-4 shows the structure of a network.

  

Quality Crosscheck Checklist

The last thing you want in a project is quality games, where on the surface everything appears to be okay, but actually important tasks haven’t been done properly. The last chapter included a warning about poor Quality Audit, that merely checks that test documents have been signed. What it should be doing is checking that the quality has actually been achieved, not merely that someone signed something.

You may trust your staff, and that’s great, but be aware that even good people will sometimes cut corners if they are under pressure. An installation in one of my projects went wrong once because of something that had been tested and signed off as okay. When I challenged the member of staff involved he said ‘I didn’t test it.’ He was a very good guy, but he was under more pressure than I’d realised and he hadn’t told me. I simply said ‘Don’t ever do that again.’ and he never did. The matter was put right and the installation went ahead, but it taught me to double check on essential areas of quality.

So how do you crosscheck to ensure that the right quality is actually achieved? Here are a few ideas to help.

• Set a realistic level: If you set the quality level of the project at an unrealistically high level, everyone will see that it’s nonsensical and they won’t take any of the quality seriously. Get the level right at the outset.
• Emphasise quality: Talk to your project staff about quality at the start of the project and at the start of each new stage. Tell them to tell you if they come under pressure, not start cutting corners.
• Brief your quality auditors: If you have quality auditors on your project, talk to them about what checks are to be done. That will help prevent merely superficial checks.
• Carry out spot checks: Say at the start of the project that you will be calling in on some of the quality checking to see how it is going, but don’t say on what products or when. Then go along at a time that a check is supposed to be being done and make sure that it is, and by the right people too.
• Follow up on failures: If something does fail that has already passed test on that point, go and find out why. See whether someone is signing things off without checking them (as in the example just before this checklist).
• Re-test: Test a random sample a second time using different people. If you find faults in the second test, you’ll know that the first one wasn’t done properly.
• Suppliers and your staff: Where suppliers are building a product, involve your own specialist staff in at least some of the testing rather than the supplier doing the build and then all of the testing.
• Suppliers and right of access: If something is being built for your project, but on the supplier’s site, get a clause put into the contract so you have right of access and can see your stuff being built, not just take delivery at the end. For some products it won’t matter how it’s built provided that it works, but for others it might matter very much.
• Look for unlikely success: If all products are passing test first time, or only have trivial errors, make sure that they are being properly tested.

Some suppliers have learned that saying everything was perfect the first time around just leads to suspicion and investigation. However, if they say that minor stuff was wrong and has been corrected, they can get away with missing out tests without being detected. I’m not out to run down external supplier companies, and in my experience most of them are pretty good. However, be aware that some unethical ones are out there, and even large and supposedly professional companies can stoop to such behaviour on occasions. So, when looking for ‘unlikely success’ (the last point in the checklist above), include checks where a range of products only had trivial errors, not just those that had none.

Risk Review Checklist

Many risks change during the life of the project, and even the project itself may change over time. A downside risk or threat that didn’t seem too significant early on in the project may have become much more significant later on and so justify a change of action.

You might review risks at set points, such as towards the end of each stage, or on a regular basis, such as every four weeks. You’ll have set down your choice of review pattern in the project Risk Plan and agreed it with the PSG. As you review the risks during the project, watch out for the following; for some you may need to get input from other people.

• Project change: Consider whether any significant changes have occurred in the project since your last review, and if so, whether they are likely to affect risk. For example, if the project end date has been brought forward because delivery is now needed earlier, risks that have delay as an impact are now likely to be more sensitive.
• Environment change: Has anything changed in the marketplace or business environment in which the project is taking place that could affect some risks? Perhaps you hear that your company made more profit than expected last year, so risks concerning funding availability will be reduced.
• Probability: For each risk, is it more likely to happen, or less likely, or has the probability stayed the same since the last review?
• Impact: If the risk were to occur, would the impact be the same as before, or do you think it would be greater or less?
• Management actions: If risk management actions are being taken to control a risk, are they working?
• Near misses: For threats in particular, even if there have been no instances of the risk happening, have there been ‘near misses’ which indicate that the management actions need changing?
• Overall risk level: Look at the overall risk level across your project. It may be that none of the downside risks has increased significantly in severity, but just about all of them have increased slightly. You need to check on the cumulative effect then, not just shifts in individual risks.

‘Near misses’ can be very significant for some risks and the international ISO standard for risk recommends watching out for them. For example your project staff may be at risk of injury when using the powerful machines needed for some of the work. At the start of the project you arranged for safety training and you supplied warning signs. If there have been no reports of anyone being injured, you may think that your risk management is working well and there’s no need to do anything more. However, if there have been lots of near misses where someone was almost injured but a colleague just managed to pull them clear in time, then you need to take further action after all, and you need to take it quickly.

Project Log Checklist

The Project Log is a really useful document, and all the more so because it’s extremely simple. You can usually have it as a word processor document or a spreadsheet. It functions as the Project Manager’s diary and journal during the project. In thinking about the sort of things you should record in it during the project, consider this checklist.

• Reminders: Just like in a diary, write in reminders of things that you need to check. For example, you had to use a particular supplier because your organisation has fixed up a three year call-off contract. However, you hear that on an earlier project there were problems with supplier staff not turning up at the times they were needed, and that it caused several delays. So you make a note in your Project Log to check on the day that the supplier staff are supposed to arrive that they actually have.
• Actions: Picking up on the example in the Quality Crosscheck Checklist earlier in the chapter, you may have decided to attend some of the tests. Put them in your Project Log ‘diary’ then so that you don’t forget, along with any other actions that you have planned.
• Authorities: You can use the Project Log to record authorities and so avoid more formal documentation. For example, the Sponsor said in a conversation today that he approved an extra spend of $500 because an extra bit of specialised equipment will speed up the work and make up some lost time.
• Records of conversations: It’s helpful to record important details of conversations, such as phone calls to suppliers. Note the name of the person you spoke to, the date and time of the call, and briefly what was said and agreed to. If there is any disagreement afterwards, it’s very impressive if you can list the dates and times of your phone calls, say who you spoke to on each occasion and what they agreed to.
• Points to remember: Some project standards include having a Lessons Learned Log, but that’s often unnecessary and you can just note things down in your Project Log – good and bad – that will be helpful for future projects, or even for later in this one.

Lessons Checklist

Following on from the last point in the Project Log Checklist, lessons learned in this project can be extraordinarily valuable for future projects. If your organisation doesn’t keep track of lessons, then you can do it personally for your own projects. The problem is that you always think that you’ll never forget a particular incident or lesson but then, 15 months later, you’re scratching your head and saying to yourself ‘I know that there was something important in that project that I said I’d never forget’.

In considering what sort of experience to pass on to future projects have a look at this checklist. You can make notes as things happen, but there are also key times to think about lessons you’ve learned, usually at the end of each stage and then again at the end of the project.

• Problems and ‘why?’: When investigating a problem, find out why it happened. Then think whether the difficulty could have been foreseen and even prevented. If you could have done something, that may be a useful lesson which could help a future project avoid the same problem.
• Warning signs: If you did hit a serious problem, were there any warning signs that went unnoticed? Perhaps if you had been looking and picked up on them, it would have prevented the problem becoming so serious. That early warning information may be a real help a future project.
• What went right?: Think what worked particularly well and, again, why. Would this work just as well on similar projects in the future, or perhaps it would even work well across all types of project.
• Improvements: You may have done well, but could you have done things even better? Perhaps something could have been done more simply or faster.
• Project management: Did you find a better way of managing part of the project?
• Next time around: At the end of each stage and at the end of the project, think ‘If I had to do this again, what would I do differently next time?’

Sometimes experience from a project should be passed back into the organisation immediately, rather than waiting for the Project Completion Report. Think about it like this: Suppose another project hits a serious but avoidable problem but doesn’t warn you, and you then fall into the same hole a few weeks later. What would you say to that Project Manager next time you see him in the staff restaurant? ‘Thanks a lot Fred. You knew I was running a similar project – you might just have warned me.’