Having reached this stage in the book, you are in an excellent position to deliver your project successfully. You clearly understand why you are doing the project, what it will deliver, and how you will deliver this.
The goal you must now strive to achieve is to deliver your project predictably to the defined scope, quality, time, cost and level of risk. Everything you have done up to this point will help this now you must make it happen. To achieve this you need to:
Apart from starting the project, these tasks are not one-off activities, but a continuous set of work for the project manager through the life of the project. On a small project such tasks will not keep you 100 per cent busy and you will have time to do other things. On larger projects the role of the project manager is a full-time one.
To be effective as a project manager requires that you keep yourself immersed in the day-to-day work of the project and understand what is happening. You also need to keep talking all the time to the project team, telling them what needs to be done and finding out how they are progressing. Project management is not a hands-off activity, it requires focus, attention and ongoing interaction with everyone involved in the project.
Before I define how to perform these tasks on a live project I explain the key items you must manage, and introduce four pieces of useful project management jargon:
Measuring and managing progress on a project
The most important task for the project manager is to manage progress that is, to ensure that a project is moving forward, at an adequate speed, to deliver the desired end result in the timeframe wanted without spending more money than was expected.
Managing progress is about ensuring that the pace of work being done by yourself and other project team members is matching that planned and required. To be able to determine this, you must have a way of measuring progress. Because you have a plan, you have something to measure with and that is one way to think of the plan, as a project manager's measuring device. However, a plan is simply a view of how the future might work, it is not a statement of reality and no project ever goes exactly to plan. The plan provides a baseline for the project manager to assess whether things are going fast enough or not and if they are not, to take action to speed them up again. Consider a single task on a plan:
In both cases, if you want the project to stay on time you must take some action to get the task completed on time. Remember though, when you developed your plan, you put in the reasonable time to complete a task not the maximum, so you are almost certain to run late on some tasks. Running late in itself is not a problem, and you should expect it to happen now and again but you need to know that it is happening, decide what to do about it, and implement the action you have decided upon.
The key to measuring progress is to understand that progress is about completing tasks, and not just working on them. Just because you are five days into a ten-day task does not mean you are halfway through it, it simply means half your time is used up. From a project manager's perspective, being halfway through a task means you have completed half the work that needs to be done. It is often very difficult to assess quite how much of a task has been done, so the simple rule of thumb for a project manager is that a task is either 0 per cent complete, or it is 100 per cent complete and finished. You should only accept that tasks are complete when they are 100 per cent complete.
To measure progress, you must collect information on how much work people have done. Whilst it is good to trust people, as the project manager you don't just want people to say they have done tasks, you should ask for evidence. If a project team member is meant to have produced a report, ask to see it. If a project team member is meant to have done some market research, ask him to show you the results. If a project team member is meant to have ordered 50 PCs, ask her to confirm when they will be delivered. If a project team member is meant to have thought about and planned some work, ask to see the plan. Some tasks create an easily identifiable physical deliverable whilst others do not, but even those that do not usually produce something which can be measured indirectly or have some impact that can be assessed. Consider the situation in which one of the tasks requires a team member to meet and interview a specialist for advice for evidence, ask to see the meeting minutes or notes. Perhaps a task requires a project team member to motivate some staff: for evidence talk to the staff yourself do they seem more motivated?
Once you have a view of the work completed, you can check this against the plan to see if you have made as much progress as planned. You should check two main things:
There are two ways of looking at the rates of work being done and money being spent:
Sometimes you will find your project is moving ahead successfully. However, if everything always went according to plan, you probably would not need a project manager. And the key reason for measuring progress is to understand when you must take action to speed things up!
If you are behind on time relative to the plan, or over-spent, of course you do have your contingency to dip into. (In Chapter 3 I introduced adding contingency time and budget to a project, so you have some buffer in case things do not go according to plan.) Your aim should be to try to complete the project without using any contingency, but sometimes this cannot be done. Perhaps you have built ten days' contingency into your plan, and find after a couple of weeks that you are running two days late, then you are still on target to complete your project within your contingency time. You should try to recover these two days by doing some other tasks more quickly, but this cannot always be done. Do not forget the project's contingency is finite, and you may also need to use it later in the project. Hence another good rule of thumb is that you must use contingency no faster than the project's overall progress. For example, when you are halfway through, you should have used a maximum of half of your contingency, and preferably less. If after two weeks of a 12-week project you have used up the entire planned contingency, then you should be concerned and you are probably going to be late in finishing your project.
Problems that get in the way of project progress are called issues by project managers. Much of your time will be spent resolving issues. Issues can arise in any task you are doing whether or not it is a project and can take many forms. Your car may break down on the way to work: this is an issue. A colleague you needed to meet up with to complete some work may fall ill on the day you needed to meet her: this is an issue. A piece of equipment you wanted to buy for which you have 1,000 may cost 2,000 and you do not have the money: this is an issue. The computer program you are writing may be more complex than you thought and will take you ten days to write rather than the five you planned: this is an issue. If these problems occurred as part of your project, you must find a way around them.
Project management is a structured way for ensuring an objective is met, and it has a structured process for resolving issues. By applying a structured process, issues are more likely to be resolved successfully. The steps to sort out issues are:
You can prevent many of the worst issues by predicting what might go wrong in future, and taking some action now to avoid this prediction becoming true. This prediction is done by looking at project risks.
Because the future is not fully predictable, risks are present in everything that you do. You may be planning to launch a successful new product next year, but there is a risk your competitors may do something similar first. You may have some land on which you want to build a house, but there is a risk you will not get planning permission. You may want to fly to Indonesia next week, but there is a risk all the tickets have been sold already. You may be planning to paint your front room, but when you remove the existing wallpaper there is a risk that the plaster work underneath is in too bad a condition to be painted.
In a project, some of the risks will be related to the assumptions you made in planning the project. (These assumptions should have been documented in the Project Definition.) An assumption is, essentially, a best guess not a fact. For every assumption there is a risk that it is not true, and if it is not true this will have an impact on your project. Consider two different examples in the Project Definitions in Chapter 2. Two assumptions were 'the wallpaper is OK to paint over' and 'the market research we performed 6 months ago still provides a reliable view of the opportunities in the market'. If either of these turns out not to be true then it will have a major impact on the projects. In the first case, when you start to paint it will not work, and your project will end up taking longer as you may have to find another way to paint the room. In the second case, if the market research is wrong then the product being developed may not sell and the whole project will be a failure.
If you know what the risks are, you can take action now to stop them occurring and having a negative impact on whatever you are trying to do. However, the list of possible risks is almost infinite, and so you need to find a way to focus on the most important risks only. To do this, you need to have some easy way of assessing and prioritising the risks you focus on. Prioritisation of risks can be done by looking at two aspects of risk: the likelihood that the risk will happen, and the impact on the project if it does.
There are many ways of measuring impact and likelihood. In practice, on all but the most complex of projects, it is sufficient to measure them by judgement and using a simple descriptive score. Both impact and likelihood can be judged to be high, medium or low. This descriptive score is going to be used for some simple arithmetic, so it is converted to a numeric score of 1 (low), 2 (medium) and 3 (high). The priority of your risk is simply the arithmetic result of multiplying the impact score by the likelihood score. The risks with the highest score are the ones you must worry about most, and have the highest priority to take some action about.
For example, consider the following four risks relevant to a project to launch a new product:
If you were going to prioritise one of these risks to take some action about, it should be the fourth as it has both a high likelihood of happening and will have a high impact if it does. You can probably forget the first, and with the availability of alternative suppliers you have a good solution for the second. The third one needs to be explored a little more, for although the likelihood is low, the impact is so high that you may want to do even more research to make the likelihood of your research being wrong lower still.
Project management is a structured way for ensuring an objective is met and it has a structured process for managing risks. By applying a structured process, risks are much less likely to occur and have a negative impact on the project. To manage risks:
In terms of a strategy for handling any one risk, there are many different things you can do, but generically the approaches are to:
How often have you had a clear idea in your mind of what you want, but when you started to do some further work found that your ideas change? Projects are not immune to such changes, and project customers will often ask for some change to the deliverables whilst a project is already under way and fully planned.
The problem is that you have agreed a time and cost within which to complete the project. If you change the deliverables, you may also impact the end date, or the cost of the project. Given that project management is a structured way for ensuring an objective is met, it has a structured process for managing change. By applying a structured process, changes will only be undertaken if they are agreed with the customer, and he or she understands the impact of them on the project. The approach to manage change is to:
Poor change control is a very common reason for project failure.
Top of Page