Introduction
The project manager’s credo: ‘I think therefore I plan’
For many people project management equals scheduling and scheduling equals project management. A quick look at the contents of this and many other training workshops on project management will show that this is not true and these notes explain how this idea erroneously arose.
The software tools used to plan projects are called project management software. This is a wholly inappropriate name and if you have been presented with a ‘Project Management’ software tool and told that you are now a project manager you should object.
Project management involves a whole raft of ideas and concepts and heavily relates to and totally relies on people. It is often useful to prepare and maintain a project plan but the plan is not an end in itself – it is a means to an end.
The purpose of planning
Why bother to plan? Even if you had an infinite number of monkeys and they all had PCs with a planning tool and they all generated an infinite number of project plans you can be sure that they would miss the one that accurately predicts what will happen.
In fact the only way to draw a truly accurate plan for a project is to wait until it is all over and draw it up based on history.
It is also true to note that the average elapsed time between the publishing of a plan and the work actually proceeding in a different direction is very short. Notice that we don’t say that the plan ‘went wrong’ – there is a mistaken belief in many people that if work doesn’t go to plan something must have gone wrong.
It is almost inevitable that work will not go ahead in the way you planned. There are any number of challenges, opportunities and events that will conspire to make sure that the work does not proceed to your plan. So why bother?
There are many good reasons to plan and here are three key ones:
Planning ahead
A project manager that brings together the team to plan learns a great deal about the project and the work that was going to be needed. This process starts people thinking about the contribution themselves and their teams will be expected to make.
Good project managers involve the team in a planning exercise where he or she will try to understand the sequence that the work must follow and the timing that is probable.
The team will uncover all sorts of issues and problems and in so doing, will avoid those problems becoming disasters.
The project manager is also welding together a project team of experts who, hopefully, will become interested and enthusiastic to make the project a success.
It is too much to expect that the team doing the planning will eventually do all the work. That would be great and it does happen sometimes but more often than not the team will change over time as some leave, pass on work to sub-ordinates and other people who get involved later in the project life cycle. At least late joiners will feel that someone who knew what they were doing had a hand in building the plan.
So getting a group of people together to think ahead about the work that they are going to do and trying to understand the sequencing and timing has great benefits.
Just giving them time to think ahead and start to work together is an investment well worth making.
A large British telephone company occasionally takes its new project teams off to a luxurious hotel with first class food and a swimming pool and asks the team to spend a few days defining the new project, creating the first outline WBS and project plans and generally getting to know each other and the project.
You may not have a budget for such extravagance but the idea is valid. Time spent at these early stages is nearly always repaid. Regrettably it will be an invisible benefit as you will never see the chaos that would have ensued if you had not planned in this way.
So planning ahead is a great way of starting a project
Monitoring and control
A plan gives you a measure against which to monitor progress. As things start to happen and work gets done it is going to be vital to check what is happening and how that compares with the plan.
This will allow you to understand the implications of a delay in one area and how that might impact on some other activities that await the outcome.
No project manager can or indeed should attempt to avoid all delays but the project manager has an absolute duty to warn the project team and the stakeholders about these delays and to understand their impact. It might well be that another group are investing heavily in overtime to prepare for an event that, they do not realise, has been delayed.
It is the project manager’s role to keep ahead of the project and keep everyone informed of when his or her contribution will be expected.
Project managers should use the future tense very often in their work conversations. The present tense requires immediate action and the past tense is about what has happened. The future tense is about what you are trying to make happen.
If you do not have a plan, how can you possibly know how you are doing? A plan gives you a yardstick, a measure against which to monitor progress. If all else fails monitoring a plan will give you an understanding of what actually went wrong and who let the project down.
It is not always a crime to be late, it is always a crime to not realise you are late. The last thing a programme and a project manager needs is a nasty surprise.
Communication
A plan is an excellent way of telling everyone what you plan to do and when you expect their contributions to be required.
You will generally get a very warm reaction if you talk to team leaders and other specialists and discuss the project with them, get them to help plan their contribution and ask them how they wish to be kept informed. If you design a report or a form of communication with them that meets their needs and you promise and actually do keep that up to date all the time, you will make yourself popular and influence people.
Who should plan?
This is by no means a simple question and it does not have a simple answer. The common answer is: the project manager.
But first a short history lesson.
On construction and heavy engineering sites a project planner frequently works very closely with the project manager who has overall control of all of the people, contractors and other companies working on the site.
Many of these contractors plan their own section of the work and the overall project planner plans everything else and tries to integrate all the planning into a coordinated whole.
The members of the contractor teams and directly employed teams have no other objectives; for the time they are on the project they are 100% available to the project team.
The techniques of project management have spread from those industries into IT and the ‘high-tech’ industries where they have been widely adopted. But there are very significant differences.
The net result of this is that in most organisations running a whole portfolio of projects, the project managers do all the planning. They plan their projects in isolation having adopted an approach from those who were truly isolated on sites where they were building dams, hospitals and shopping centres.
In most organisations you can often find three project managers all planning to use the same resources at the same time which is unlikely to work even if those resources were not planning holidays and training courses and the normal business as usual for the same week.
What really is the point of planning to use resources over which you have no control and little influence?
Here is a better approach: Plan with many people.
Wise and efficient organisations distribute the responsibility for planning across programme managers, project managers, functional managers and specialist teams.
Everyone plans his or her own ‘sphere of influence’. Therefore some plans do focus on specific projects but other plans focus on the work that a specialist team is doing on a wide range of projects and in some organisations every individual has their own plan.
Many people think ahead about their programmes, projects and teams and are able to predict reasonable accurately what they will be doing in the near future.
Not all plans are project plans. In fact there may be more ‘work plans’ covering the workload of specific teams and individuals than there are project plans.
The problem that this creates is in connecting the many plans together. Given a system of inter-connecting these work plans, project plans and programme plans, we would have a system where everyone plans their own area and somehow these many plans interact with each other.
Planning techniques
Network planning is a technique for modelling a project. Later on the model will be used for critical path scheduling.
In essence the planner identifies the activities that need to be done and gives each one a description to remind everyone what it is the planner meant. The planner also estimates how long each activity will take. The planner does not at this stage know when each activity should take place.
We also identify the way in which certain activities depend on others for example you cannot test some software until it has been written.
You then enter details of the activities and their links into a project management software package. The software works through the data and calculates when each activity can and must start and finish and shows this on a schedule, bar chart or Gantt chart.
The logical flow of work expressed in a network diagram will be transformed into a timescale by the project management software.
In this next section you may learn how to produce precedence diagrams. These are sometimes called Critical Path Diagrams, PERT charts or simply Critical Paths. These are the input side of project management software.
In essence these diagrams demonstrate the activities in your plan and the way in which they depend on each other. If you prepare a diagram showing that the walls must be built before the roof you will achieve a number of valuable objectives.
For example both you and the team will understand how some activities must happen before others, how some can proceed in parallel and how the whole project is going to develop to its objective. Using the software to calculate your network will result in the timing of each activity – when you can expect it to take place.
You may think that the process is dead simple and straightforward and it may be to you. But you can be sure that there will be considerable misunderstanding about the sequencing of the work amongst the team.
The likelihood is that you will either prepare this diagram using some project planning software (a.k.a. project management application) or using Post-It notes and a handy wall. Either way you will probably enter details of the diagram into a planning system.
The basic concept is that you
- work out with your team the activities that need to be done to deliver the project – a work breakdown structure is a great tool for this stage;
- use the precedence diagram to understand how some activities must precede others;
- estimate the time or work required to perform each activity;
- enter the data into a project planning tool.
The tool then calculates when each activity can start and finish. It does a calculation and draws a Gantt or bar chart showing you the when each activity is planned to take place (Henry Gantt is reputed to have invented his eponymous chart during the 1st World War).
You will now have a model of your project – it is a time budget and it is called your project plan or schedule.
The software will never forget the sequence you defined so it will ensure that you never plan to test a module before it has been built.
As the project proceeds it is very likely that actual progress will differ from planned. To reflect this you will normally update your plan frequently (often weekly or monthly) and re-issue the plan to all stakeholders.
We will use the term activity. Some software tools, refer to these as ‘tasks’. In some systems an activity contains many tasks. In others these terms are interchangeable but normally the lowest level at which one person does one job, is called an assignment.
Many organisations and all software tools use their own specific form of language and occasionally these coincide. It might be a good idea to find out what your colleagues mean, there may even be a published methodology laying out such terms in your organisation.
There are three components you should use: activities, headings and links.
Activities
An activity represents some work taking place. Activities always take time and may or may not involve people. Examples include:
- Design user interface
- Write Specification
- Build Code
- Assemble test data
- Await delivery of hardware
- Watch paint dry
This list suggests the sort of terms you might use to describe the work you intended to take place within this activity.
These words are called ‘descriptions’ and they are a major way of indicating the work you had in mind when you planned the project. You may be able to use your PM software to back these up with longer notes and documents but a short and accurate summary is invaluable.
All of these descriptions include a verb, something teachers used to call a ‘doing word’ because doing something is likely to take time.
Descriptions like ‘User Interface’ and ‘Hardware’ are useless, as everyone will assume something different about what you meant. Always check for a verb in your activity descriptions.
In the precedence notation an activity is represented by a box. Boxes are normally all the same size so you do not get long boxes for long activities or short boxes for short activities. Conceptually the left hand side represents the start point of the activity and the right hand side represents the end of the activity.
Activities have inputs and outputs. The inputs are the components that will be required before the activity can start and progress and outputs are the components created as the activity is carried out.
Thinking in these terms helps you to understand that flow that will dictate the sequence and therefore timing of your activities.
Headings
Most software packages help you to group activities into sensible and appropriate groups.
The Work Breakdown Structure introduced the idea of breaking down the work into useful groups and these headings develop this principle. Headings are very much part of an OUTLINE and work in much the same as the outline that your scribe is currently using to assemble the contents of this book. Headings include activities, for example:
Documentation
- Develop overall documentation design
- Design document layout standards
- Write first draft User Guide
- Write first draft Installation Guide
- Gain approval of first draft documentation
- Prepare final draft User Guide
- Prepare final draft Installation Guide
- Gain approval of final draft documentation
Headings may be referred to as work packages. A work package is often a group of activities that a specific team or department are required to perform for a specific project.
Here ‘Documentation’ is the heading and there are eight activities within it, i.e. there are eight activities that are required to complete the work package.
Headings may include activities and other headings so that you can create a hierarchy of headings and sub-headings and sub-sub-headings in an attempt to group your activities sensibly.
This is very much the WBS approach. So you can use the WBS pretty much as is to create a list of activities and headings. Some software tools allow you to create the WBS on screen and they automatically generate the list of headings and activities for you.
Choosing your activities and headings is a headache and a major contributor to successful planning and control.
Granularity is the word that is often used when trying to decide whether you have too many small activities or not enough large ones.
It would be quite legitimate to have an activity described as ‘put man on mars’ but this would provide little value apart from setting down the overall timescale of around a decade.
It would be equally legitimate to have a activity called ‘screw inspection hatch on to rocket launcher’ which might be expected to take 5 minutes. This would be a very precise level of planning and your chances of getting the right 5 minutes are vanishingly small.
There are projects where 5 minute long activities are vital but I am trying to get you to think about the wide range of possible levels of granularity you might use.
There are no firm rules to guide you in your selection of activities so here are a few tips.
Some activities are going to be carried out by one member of your team. In this case you need to search for a level of detail appropriate to that person. Most plans for an individual in a project management environment are at least one day long and usually less than a fortnight. Exceptions include attending a specific meeting taking a few hours and monitoring some process or delivery over a few months.
Assuming you have a reasonable level of respect for your team, you should not attempt to tell them how to spend their day to the nearest few minutes. You should be setting them objectives for the week or month and hoping that they will be sensible enough to plan their time effectively.
Other activities may be carried out by an agency. By agency we mean another group, perhaps within your own organisation but perhaps not. You might have a team of documentation specialists who will contribute to your project by writing the user guide to your next software product. You may use an external contractor to install a number of desktop computers overnight or to run your advertising campaign. In these cases you will almost certainly plan at a much broader level.
You need to be very clear about what you want the agency to do and when you expect they will be able to start on the work and when you want them to finish. You might reasonably expect them to plan the detail of the work and you might expect them to give you a copy of their plan. So you plan at a work package level and they plan the detail.
The more detail you impose on your internal or external contractor, the more you tie their hands and reduce their flexibility. Use only enough detail to give you the control you need.
For many people the first level of breakdown is the work package level. Where these work packages are to be carried out by member of team they are broken down into activities typically between 3 days and 3 weeks. Where these work packages are to be carried by another agency you should probably stop at the work package level that is more likely to be in terms of weeks and months.
It is very tempting to go on adding more and more detail to your plan. This is especially true of planning consultants who feel that they can be seen to be doing useful work and earning their vast fees only if the plan is huge.
Big plans are rarely valuable, as they tend to overwhelm people. Make your plans appropriate to the need.
Consider for a moment the time it is going to take to keep a plan full of short activities up to date. You are going to need to check on progress on hundreds of activities and update and republish the plan frequently. The more activities, the longer this will take. You can very easily get lost in the woods without ever seeing the trees. Don’t be fooled into the idea that vast numbers of highly detailed activities will give you better control. It will give others loads of opportunities to discuss why they couldn’t do something or why they failed to perform and many will use the excuse that your planning is too complex to ignore the whole plan.
Discuss with the people in your team the level of detail they think will best help the project along. There are times when great detail is essential and there is time when a broad-brush approach will do fine. A collective decision on granularity is the best route to take.
You do not need the same level of granularity throughout the plan throughout the project. Many plans, in the early stages of a project, have a detailed first and second stage and much more broadly defined later stages. There will be time to develop the detail for these later stages later on. On some projects the work content of the later stages only become clear after the first few milestones have been achieved. This is called rolling wave planning.
Links
Links are used to connect activity and headings together to indicate the precedence, or the flow of work from activity to activity.
There are three main types of links and different software tools treat them slightly differently.
The simplest link is called a finish to start link and clearly indicates that one activity cannot begin until another has been completed.
The arrow indicates that the first activity is the predecessor of the second activity. It is essential to ‘Design the user interface’ before starting to write the specification for the user interface.
The ‘Design’ activity is an input to the ‘Write’ activity.
You are allowed to have as many links coming into and out an activity as you need. Links may connect activities with activities, headings with headings and headings with activities. You can therefore represent an activity that will allow a whole other group of activities to proceed or an activity that must precede a specific activity or group of activities.
Activities that precede another are called predecessors and activities that must follow others are called successors. In the example above we say that the Design Specification for User Interface and Finalize Menu Structure both precede the activity described as Write Specification for User Interface.
Most project management software allow other types of link and these are used to represent more complex situations than the simple finish to start.
A start to start link indicates that one activity cannot start until a period of time after another starts. The successor cannot only begin sometime after the predecessor.
These links are much more common in construction where bricklayers start building walls and a few days after they have started, a carpentry gang starts inserting the windows. Or a gang starts digging a long trench and another gang follow behind dropping pipes into the hole.
You really would like to indicate that a certain amount of work has to be achieved on the preceding activity before the successor can commence but this is too complicated for planning techniques and most tools so you have to make do with a time delay.
A finish to finish link indicates that a succeeding activity cannot be completed until a certain time after a predecessor.
The last bit of trench must be complete before the last pipe can be dropped into place. The last bit of wall must be complete and allowed to dry for 2 weeks before the last windows can be fixed.
Finish-to-finish links make sure that succeeding activities never catch up with preceding activities.
These complex links are normally drawn in the same way as simple links but occasional you may see the correct, purist way of drawing such links so here is what to expect.
Let's imagine the design and writing of the user interface can proceed in parallel whilst overlapping. The design team are going to start designing the user interface dealing for the first of several modules and pass them over one at a time to the writing team. You could create a whole sequence of activities like this:
- Design module 1
- Design module 2
- Design module 3
- Write specification for Module 1
- Write specification for Module 2
- Write specification for Module 3
..and link each pair.
Alternatively you could group them together into one design activity and one write activity and show an overlap.
Note how the start-to-start links emerge from and disappear into the left hand (input) side of the activities and that the finish-to-finish links do the opposite.
Complex links are not that frequent in the high tech world and most people get by with the simple start-to-start connection.
Some tools allow only one link between a given pair of activities. That means you cannot link a pair of activities as shown in the diagram above – you have to choose either a start-to-start or a finish-to-finish type of link.
There are three simple rules about this:
- If the preceding activity is shorter than the succeeding use a start-to-start
- If the preceding activity is longer than the succeeding use a finish-to-finish
- Keep your eyes open and keep checking that due to a change or delay you are not scheduled to do the impossible. It can happen that updates and changes cause impossible plans to be prepared and printed and these will cause much jocularity amongst your colleagues all of which will be at your expense.
There is a fourth kind of link called a start-to-finish link. It indicates that a succeeding activity cannot end until a preceding activity has begun. It is very rare and you are unlikely to need this.
Choosing the right links and right kind of links to use is again something best done collectively.
Once your precedence diagram is complete your software will produce a range of reports based on critical path analysis.
Thanks to Geoff Reiss for contributing this book
