- This book is a good reference guide to Planning, Scheduling, Monitoring and Control, with most of the topics covered at introductory to intermediate level in relatively informal jargon-free language with plenty of helpful diagrams.
- The guide is aimed at students and practitioners, so I’m a bit puzzled why it begins with a chunky explanation of how projects are defined and the documents used. At 20 pages this section is too hefty for the completely uninitiated, but has nowhere near enough detail to be useful an already-practicing project manager (who would be better off referring to one of the BoKs or methodologies). I guess however that novice Project Planners may find it useful for context and orientation, and it signposts topics for further reading.
- The book gives a useful and succinct description of the differences between planning and scheduling:
- Planning is the art of deciding on the best way to do the project, defining scope and deliverables, and getting agreement from the stakeholders. It is broader than scheduling and logically happens earlier.
- Scheduling is the science of estimating how long it will take and how much it will cost to deliver tasks, and sequencing them to create a logical model of the future that can predict when project outputs can be delivered. This model progressively becomes fact as estimates are revised and activities completed.
- Next there are tips on planning and scheduling, including some suggested approaches for creating and quality-checking the documents. It describes how to set a schedule baseline, how to evaluate the impact of any changes requested (using offline, static copies of the live schedule), and how to update the baseline to take account of approved changes.
- Monitoring approaches are then described, with a warning that no one of these gives a complete picture of the project’s status. Earned value analysis (EVA) comes closest, but requires significant effort
- The book recommends regular schedule co-ordination meetings, to review recent progress (recording reasons behind any slippage for analysis later) and future tasks within an agreed time window, allowing team leaders to plan the near future in detail.
- There is a good introduction to quantitative schedule risk analysis (a.k.a. Monte Carlo analysis) and the value it can bring to both schedule and dimensions by giving the PM statistically-derived forecasts of final delivery date and cost. Some of the diagrams here could be clearer, but I am told these will be reviewed ahead of the next print run.
- The book also outlines how forensic schedule analysis can be used to establish the cause of delay(s) in litigation scenarios.
- At the end there is a helpful glossary and a list of abbreviations.
Some example tips
- Schedules should have an appropriate density (amount of detail) for their purpose: Low density for communication e.g. to executives; Medium density for the reference plan; High density for day-to-day management of delivery teams’ work. A schedule with too much detail is just as bad as a schedule with not enough detail, as it is difficult to manage and won’t be used.
- Schedules should record a baseline (when we agreed it would be delivered, updated with any approved change requests), a forecast (when we now believe it will be delivered), and “as built” (when we actually delivered it, including any unexpected extra events). These may be in the same scheduling document but will not usually be displayed at the same time.
- Where a team is producing a string of broadly similar deliverables and can be thought of ticking these off a list, it may be more helpful and easier to manage using a spreadsheet tracker rather than scheduling software.
- Schedule item names should be understandable without reference to WBS headings (which may not be visible if a filter is applied) – task names should start with a verb (lay bricks; paint walls) to indicate activity, and milestone names should express a state in the past tense (walls built; plumbing complete)
- First sequence tasks in logical order (using mostly easy-to-understand Finish-to-Start relationships), then allocate resources. Then apply resource levelling by first delaying tasks with free float (so delaying them does not delay successor tasks), and only then delaying tasks with no free float but some total float (so delaying them delays successor tasks but not the overall finish date)
- Identify dependencies between projects, label these clearly in the schedule including whether these are inbound or outbound. Meet regularly with the PM at the other end of the dependency link; review whether the current forecast date works for both parties and agree any remedial action required. Any changes in delivery date to be the subject of change control.
- A budget is a planned upper limit on resource to be consumed for a given task or tasks. It is often expressed financially but not always; it could be expressed as terms of days of effort, quantity of materials, etc.
I recommend this book for early and mid-career PMs and PMOs. I would have scored it higher if not for the somewhat incongruous section on project definition (which one can simply overlook) and a few mathematically doubtful diagrams (harder to ignore). I expect that my review copy will become dog-eared through use!
|Full title:||Scheduling, Monitoring & Control: The Practical Project Management of Time, Cost and Risk|
Association for Project Management (Princes Risborough, Buckinghamshire) 2015
|RRP:||£50 RRP (electronic review copy provided free of charge)|