Planning a project
People don’t like to plan. It’s much more fun just to do, and the nice thing in just doing, is that failure comes as a complete surprise. Whereas, if you have planned, failure is preceded by a long period of despondency and worry.
Making assumptions (and recording them)
There is a very good piece of advice for anyone – ‘never assume anything’ – but there are always likely to be a fair number of assumptions in a project, especially at the planning stage. You need to think through the assumptions that you are making, and then record them. The purpose is to make them explicit, so that they can be confirmed as correct (or not) when the plan is approved, at which point they cease being ‘assumptions’.
So, are you making assumptions about the staff available to you, or about the products or services that are to be supplied from outside your project? Are there other assumptions – for example, assumptions about the benefits claimed in the business case? If you are relying on anyone outside your control, are you assuming that a central support office will look after all your document management work or provide expertise in the planning and control tool that you have to use.
You may be assuming that any project board members assigned to monitor external risks will do that monitoring and give you feedback. If you are assuming that, say so. If every part of the specification is not yet available, as often happens with projects to meet government legislation, you will need to record your assumptions as to when that information will be made available. Are you making assumptions about how any changes to the project will be funded? And so on.
How do I plan what to do?
There a number of things you will need in order to be able to plan your project. In particular, you will need some type of work breakdown structure (or product breakdown structure in PRINCE2) and work (or product) flow diagrams. You are also likely to want a network analysis diagram showing duration, a schedule (for example, a bar or Gantt chart, showing tasks, dates and resources) and specifications (or product descriptions in PRINCE2), all of which are covered in greater detail in Some tools and techniques, as well as the budget and, finally, resource plans. Alongside all of this, you will need to be estimating the risks involved. See the topic on Risk Management. You may well find that some risks are significant enough that they require changes to the plan so that the risks are managed.
It is worth noting that at the start of a project quite a bit of the plan may well be ‘soft’ – that is, outlined as necessary, but not worked up in detail. For example, at the start of a project, it may be clear that a handover to operational staff will be necessary as the project ends, but the detail of the best way to do this may be unclear at the beginning. What is necessary, though, is that the stage plans must be firmed up before that stage (or phase) is started.
Should I break the project into stages? If so, how?
It is usual to sub-divide projects into stages or phases. There may be different reasons for doing this. There are good management reasons (the approach commonly adopted in PRINCE2), as before each new stage is entered the organisation’s management wants to assess that the project is still viable and that it will still deliver what is needed (these points are sometimes referred to as ‘gateways’ in the public sector). So stages are determined at points where the project board or committee can satisfy itself that what has been achieved to date is satisfactory, before authorising more expenditure and the commitment of more resources.
There may also be various technical reasons for determining stages – for example, a project may have a number of clear technical phases, such as Requirements definition, Design, Build, Test and Implementation. To make each of these a stage enables the project to be properly controlled and allows management to determine whether they are satisfied with progress at each stage. It is important to remember that projects should be cancelled if they are not going to achieve their objective(s) – otherwise, they rapidly become a waste of money and resource.
What is a work package?
A work package is an identified group of activities that are clearly defined or specified, and then allocated by the project manager to a named individual, who is accountable for delivering the product or output of the package. Work packages are specified clusters of work within a stage of a project.
Work packages are logical groups of activity that should be identified from a Work breakdown structure. The project manager needs to make sure that the person to whom the package is delegated clearly understands what is needed, what the budget for it is, when it is needed, what quality method will be used to check its output, what standards are to be followed and how progress will be monitored and reported. If it is being contracted to a third party, a clear and detailed written specification will obviously be necessary – but a document covering this information for packages allocated internally is also considered highly valuable.
How do I choose milestones?
Milestones can vary a lot, according on the type of project you are undertaking. So it is important to understand their purpose, which is to mark a significant, measurable event during the course of the project so that progress can be monitored. Often, it is when an important deliverable is due, but it can be the point at which a lot more resources are going to be needed or even when the likelihood of a significant risk is going to be known (for example, is there going to be a strike?).
Milestones may occur at stage ends, or in the middle of a stage, so there is no definitive timing, but it is best to try to space them out throughout the project rather than have them bunch up at the end, when it may be too late for corrections! Once established, they must appear in the project plan and on the project schedule.
Don’t forget, also, that time and effort spent on communicating and all communications milestones should be explicit in the plan.
How will progress be reviewed?
As we have just mentioned above, there are two main ways – through stage ends and milestones. Each stage end is a point at which the project manager reports to the project board on progress to date; the same occurs when milestones are reached. Not only is progress to date reviewed, but the detailed plans for the next stage are assessed and agreed. In addition, any likely impact on the final project output should be identified; in other words, is the project still running to time, cost and quality objectives? If not, you need to consider what the likely outcome is now and analyse its impact on the business case.
But it would be rash to leave progress reviews to arbitrary dates, so most projects have tolerances built into them (budget, quality, and deadline) and it should be a requirement that if these tolerances are threatened, the project manager should file an Exception Report to the project board, explaining what is happening. This provides an interim opportunity to review and make any corrections necessary. Progress may also be affected by risk and a Risk Registershould therefore be established, so that risks that have been identified can be monitored and managed.
How do I plan to get the benefits delivered?
You plan to get the benefits delivered by first of all understanding what they are! They should be defined in the Business case and may be tangible, intangible or a mixture of both. They will tend to fall into one of three categories:
- Will the project improve revenues?
- Will it cut costs?
- Will it improve the internal or external processes and services that the organisation currently uses?
It’s important to understand what benefits are expected and bear them in mind throughout the planning stage of your project, which means that you should build in the necessary activities/products or services to deliver them. Remember that in most projects, benefits come after the project is finished – so it is vital the project delivers outputs that are ‘fit for purpose’!
Should I allow for a contingency? How much?
There are basically two types of contingency – one occurs because of a lack of analysis, design or knowledge, while the other is the kind of unknown contingency that crops up during a project. Typically, the contingency plans and amounts of money will have been identified at the final authorisation stage of the project; in other words, after project definition and planning (or the PID in PRINCE2).
At the same time, the authority to release monies or activate a contingency plan should have been identified. This may be delegated to the project manager for some amounts, but more likely to the project owner/sponsor or held at an even higher level for release when necessary. Amounts will vary according to the level of uncertainty in planning and estimating. For many typical projects, this is likely to be in the order of 5 to 10 per cent of the overall budget. For high risk innovative projects involving new technologies, the sums may need to be far greater.