Scheduling, Monitoring & Control: The Practical Project Management of Time, Cost and Risk (Book Review)

by APM PMCSIG, Association for Project Management (Princes Risborough, Buckinghamshire) 2015
ISBN 978-1-903-49444-8
327 pages, RRP £50 (review copy supplied free of charge by the publishers)
Pragmatic PMO Rating: ****


  • 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.

What’s inside

  • 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.

The Verdict

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!

Related Articles

Images of Projects (Book Review)

This book recommends that project practitioners should consciously view projects through multiple “lenses” or “filters” to gain different perspectives. This approach directs attention to project aspects that might not otherwise be considered, which will affect the action taken, and hence the results obtained.

Considerable repetition of the principles and case study content (mainly to make it easier to use for reference), and overlap between the images caused me to have several déjà vu moments in reading it straight through, but the approach should be useful to PMs (on projects and programmes) and PMOs (to challenge PMs on their view of projects, and to think about portfolios) at all career stages. Continue reading “Images of Projects (Book Review)”

Managing Business Transformation – a Practical Guide (Book Review)

by Melanie Franklin, IT Governance Publishing, Ely, 152 pages,  £24.95 RRP (review copy provided free of charge by the author)
Pragmatic PMO Rating: ****

This book is intended as a practical guide to understanding and managing change that will benefit your business. It covers the differences between change management and project management, and how to integrate the two.

It starts by loosely defining change management (making a large change to a business that involves a large proportion of the organisation), and breaking it into four stages (understanding; preparing; implementing and embedding). Each chapter of the book deals with one stage before finishing with a look at the alignment of change management with the project management that underpins it.

Chapter 1 (Understanding) suggests reviewing the business case to understand the drivers for change, and comparing the “from” state with the “to” state to understand its scale. It recommends cultivating support using a vision statement as early as possible to increase participation and reduce resistance.

Chapter 2 (Preparing) proposes producing a road map to the desired final state, listing what will stop, what will continue and what will start as a result of the change. This “paves the way” for the change and smooths the transition. Plans should be built constructed in both top-down and bottom-up directions, and will not need many updates. Plans should be communicated to stakeholders often enough to ensure the message gets across, and tailored to their needs.

Chapter 3 (Implementing) describes building the change team and ensuring various team roles are represented. It discusses potential emotional reactions to the change, and offers ways to address these to help those affected to move through the change smoothly. It maintains that change managers need more “friends” than average, and offers ways to cultivate this.

Chapter 4 (Embedding) describes how the change progresses from “new” to “normal”. It recommends measuring adoption, and dismantling the old ways. This can be encouraged using financial incentives, celebration, coaching for stragglers, and a managed exit for those who cannot or will not adapt.

Chapter 5 (Alignment with project management) highlights that whilst project teams generally deliver change enablers (e.g. a new IT system), it is others that take these enablers and embed them into organisational culture. Thus the change life cycle is related to and analogous to the project life cycle, but distinct from it.


This book draws useful parallels between change management and project management whilst highlighting differences. The use of voices from people who have “been there” makes the advice real, and the liberal use of diagrams helps to explain the various concepts. At 152 pages this book takes <2 hours to read; with a RRP of £24.95 it is likely to pay for itself many times over with application of just a few principles. Recommended for project managers who want a better understanding of how their projects fit into the bigger picture.

Related Articles:

Business-driven PMO setup – Practical insights, techniques and case examples for ensuring success (Book Review)

by Mark Price Perry, 2009, J Ross Publishing, USA. ISBN 978-1-60427-013-6, 494 pages, RRP £60
Pragmatic PMO Rating: ****

The stated aim of this book is to show the reader how to create and maintain a business-driven PMO, because PMOs that are driven by the needs of the business succeed, whereas when PMOs are driven by other motivations fail.

The book sets this out in a pattern of alternating chapters – one explaining a point from a theoretical or academic perspective, which is then supported by a shorter chapter or two demonstrating that point working in practice.

Rather than go through summarising each chapter, I thought it might be more helpful to list some interesting points or “Aha!” moments that I found in this book (and there were many).

On projects and project management generally:
  • Involve operations early in projects. Document operational concerns and deliver against them. Get handover documents signed, and exit project staff as quickly as possible.
  • Don’t use part time operations staff on projects, as their primary loyalty will always be to operations. Make dedicated project people accountable with project-specific targets, contracts, etc.
  • Project managers should focus more on managing relationships and taking action, and less on managing RAID logs and keeping documentation up to date. Aim to produce the desired result rather than the planned result (although if these are the same then so much the better!).
On PMO setup and development:
  • A PMO should articulate its business value at or before inception, or expect to defend the additional cost.
  • Don’t “sell” the PMO to Management. Ensure the PMO delivers real business benefits, and let these speak for you. The main source of inadequate Senior Management buy-in to PMOs is probably the result of them having been “sold” a PMO they didn’t really want or need.
  • Most PM methodologies are geared towards large complex projects, but these often make up a tiny percentage of the PMO’s project portfolio. A PM methodology needs to be flexible and scalable to suit the size and complexity of the project being managed.
  • Methodologies should only be used at all if they improve results – “Best Practice” may not be a good fit for your organisation and its projects.
  • Not really an “Aha!” moment but one I very much agree with (see my posts on Watermelon and Green Side Up reporting) – if a project continually reports green RAG statuses across the board, then the budget and timescales were probably inflated – you should expect to see a range of RAG statuses in the lifespan of any project.
  • Project KPIs should reflect the needs of the business, not some internal, myopic, PM-specific measures. As people work to targets, you may as well direct their efforts to truly desirable outcomes.
  • Measure quality not in terms of how closely the plan was followed (it may have been the wrong plan), but how satisfied the customer is with the deliverables.

To sum up, some books once read get passed on to a colleague or put on the shelf and never looked at again. For me, this is not one of those books. Now that I have finished writing this review I will be reading this book again from the start, but this time with a highlighter pen in one hand and a pad of sticky bookmark tabs in the other!

I didn’t pay for this book (it was a gift – not from the publishers!) but I think it is well worth the cover price.

A Project Prayer

The programme team I have been working with has a daily stand-up meeting that has acquired the “morning prayers”. It got me wondering – given the opportunity, what should a project or programme team pray for? Here’s what I came up with…

Our Sponsor, who art in the executive suite
Hallowed be thy business case.
Thy vision come
Thy mission be done
In actuals as it is in the forecast.
Give us this year our annual budget
And forgive us our delayed milestones,
As we forgive those who delay our inbound dependencies.
And lead us not into scope creep,
But deliver us from change requests.
For thine are the deliverables,
The outcomes and the benefits,
From Go Live into BAU,
What would your project or programme team pray for? Let me know in the comments.

SharePoint for Project Management – How to Create a Project Management Information System (PMIS) with SharePoint (Book Review)

by Dux Raymond Sy, O’Reilly Media Inc, 232 pages, £25 RRP
Pragmatic PMO Rating: ****

This book is intended as a “how to” guide for setting up a Project Management Information System, aimed at the practising Project Manager (PM) or Project Management Office (PMO) Manager. In this it is completely successful. The book (safely in my view) assumes a reasonable level of familiarity with both standard office use of computers, and a reasonable level of familiarity with PM principles and techniques, taking this to build a PMIS, so often referred to in PM textbooks as an essential resource but rarely explained or explored in any depth.

Chapter 1 deals with what SharePoint is (a system that enables individuals in an organisation to easily create and manage their own collaborative websites), what a PMIS is (a standardised set of PM tools available within an organisation and integrated into a system), and whether you need one (if you are running anything more than the smallest and simplest projects then you probably do).

Chapter 2 deals with the structure and hierarchy of SharePoint sites, and takes the reader through the creation and customisation of the most basic elements of a SharePoint site (as a practical exercise if you have the necessary resources handy).

Chapter 3 builds on this foundation by adding PMIS elements such as a shared calendar, contacts list, risk list, and document library, using these as opportunities to explain how these SharePoint features work.

Chapter 4 covers the introduction of stakeholders, managing their access to information using groups with varying permissions.

Chapter 5 gets into the use of SharePoint’s document and collaboration features, with a good description of how document check out / check in saves us from playing “whoever saves last keeps their content”, and an overview of SharePoint’s native version controlling approach and whether you need it (you probably do!). This chapter also covers wikis, document workspaces, and discussion boards (with examples you can try out), all of which are intended to promote team collaboration.

Chapter 6 goes into the use of SharePoint’s built-in features to track project progress, with a warning against using the too-basic Project Task list as your only Gantt chart tool. There is a good detailed section on customising lists to use as fairly well-featured Risks and Issues Registers, and a section showing how to manage the items in these lists with SharePoint’s built-in Workflow capabilities. This chapter even goes so far as to show you how to build a pretty serviceable Change Control system using the workflow feature with a customised list.

Chapter 7 takes a look at the Reporting options available. This chapter helps the reader to learn how to set up special views and web parts to create a Project Dashboard, and how to set up alerts to stay informed about what’s happening in the PMIS.

Chapter 8 deals with the integration of Excel with SharePoint, showing how to achieve bidirectional information exchange. Unfortunately direct synchronisation with MS-Project is not possible, but the book suggests an alternative approach to minimise the pain (keeping the management of the MSP plan in the hands of the PM, but allowing the Project team to report updates using a task list).

Chapter 9 rounds off the book by explaining how to shut down a project and its associated SharePoint site, even capitalising on what you have learned from your experience by saving your site as a template.

The issue of how to get users to interact with and properly use a SharePoint site is dealt with in just two pages right at the end of the book. I guess that is not surprising in a book that is really aimed at the technical rather than people aspects of creating a PMIS in SharePoint, but I still found it a little disappointing as this is crucial to adoption and uptake.

Overall, if you implement all the practical exercises in this book then you will end up with a very usable PMIS for very little outlay. You will still need to convince your team members that this is a Good Thing and that using the PMIS facilities is better than storing copies of documents on their Desktop before emailing them to multiple reviewers for comment, but you will have the tools for them to pick up and use.

In a PMO role on a Programme of over 100 team members that uses SharePoint as its document repository, I have referred to this book as my SharePoint ”Bible” most days; as a result it has quickly become well-thumbed! I would recommend this guide to anyone wanting to set up a low-cost, practical PMIS and who wants guidance on how to do this without getting bogged down in technical minutiae.

Related articles

What has the PMO ever done for us?

What has the PMO ever done for us

With all due acknowledgement (and apologies) to Monty Python’s Flying Circus, whose film The Life of Brian inspired this post.

THE INTERIOR OF A DIRTY CITY PUB. A SHADY BACK ROOM WITH A CONSPIRATORIAL ATMOSPHERE. We join a meeting of the Project Managers’ Revolutionary Front, where Brother Reg (the chairman of the meeting) is proposing a motion to the members (all Project Managers), and a CxO guest.

REG (gesticulating at a complex diagram on a flip chart): …So we break into the PMO, set fire to the methodology and sabotage the automated status report reminder email! Who’ll second me so we can take a vote?

[Apathetic silence]

BRIAN (a project manager): Are you sure we should actually be ransacking the PMO, Reg? I mean, some of the stuff they do is really quite useful…

Reg: Useful?!  Don’t make me laugh! What has the PMO ever done for us?

Brian: Well, the project management methodology makes sure we all talk the same language; before we had a PMO we didn’t know whether we were using PRINCE2® or the PMBoK®!

NIGEL (another project manager): That’s right Brian, and they update the methodology with Lessons Learned so it’s relevant to our projects and not over-bureaucratic…

SISTER SUSAN (another project manager, under her breath): Unlike these meetings…

[Sniggers all round]

Nigel (quickly): They do health checks to identify where our projects may be at risk, and help us to bridge the gaps.

Susan: And they develop user-friendly document templates to save us time

Reg: OK, so there are two things the PMO has given us…

LORETTA (a CxO): Well, they distil all the project reports into concise, executive-friendly information so that we know what’s going on.

Brian: …and they build project plans that we can actually use, rather than just stick on the wall and ignore like we used to…

Loretta: …and they prepare exec-specific views of the plans…

Reg: Well yes obviously planning, but what else?

Nigel: They keep an eye on the details for us…

Brian: And that’s where the devil is, isn’t it people?

[Nods and murmurs of general agreement]

Nigel: Yeah, like actions for completion; risks for review…

Brian: Exactly! They liberate us to manage our teams to deliver on time, to quality, and within budget.

Reg: Alright, I accept the PMO vitally underpins delivery of the project portfolio, but apart from methodology management, terrific templates, intelligent information, practical planning, and monitoring the detail, what has the PMO ever done for us?

Susan: Well, remember those “zombie” projects that we should never have started but that just wouldn’t die? They got those stopped…

Loretta: And that freed up some budget for projects that actually deliver benefits!

Reg: Hmm, this meeting isn’t really going the way I planned it.

Susan (just loud enough for everyone except Reg to hear): Maybe he should have got the PMO to run it!

[Amused guffaws. Reg looks frustrated. The laughter fades into awkward silence; the meeting seems to have rather lost its purpose]

Reg: All those in favour of going for a curry?

Project Psychology (Book Review)

by Sharon De Mascia, Gower Publishing Ltd, Farnham, Surrey, ISBN 978-0566089428, 181 pages, £60 RRP (review copy provided free of charge)
Pragmatic PMO Rating: ****

This book addresses a gap in the Project Management literature – how people and their behaviours contribute to project failure, and shows the reader how psychology can improve the chances of project success.

Chapter 1 begins by looking at the skills and attributes needed by the project manager and the project team members. It covers how these might differ from those needed by Business As Usual (BAU) teams and managers, and how to factor them into recruitment or team member selection using psychometric tests.

Chapter 2 covers project leadership, exploring how successful leaders use emotional intelligence to build relationships and trust with colleagues, furthering their engagement and motivation.

Chapter 3 explores the nature of teams, from the roles that people adopt within them to the relationships that form and that can help or hinder project success.  It covers the characteristics of high-performing teams, and how to foster a vibrant team culture.

Chapter 4 describes how team leaders can develop and motivate team members through coaching, and the skills needed in order for this to be successful.

Chapter 5 looks at the importance of stakeholders and how to engage them effectively. It covers how to negotiate with them and even coach them whilst maintaining good relationships.

Chapter 6 examines the methods of communication now available to project teams, and how emotions and non-verbal communication affect the transmission and perception of messages. It gives practical suggestions to improve communications with team members and other stakeholders.

Chapter 7 examines the psychology of risk, covering human behaviours to be considered alongside formal risk management. This includes the effect of single personalities within a team, and effects arising from the team itself.

Chapter 8 covers conflict, offering techniques for using it positively; for example using a coaching approach to understand the reasons for conflict and to facilitate a win-win outcome.

Chapter 9 looks at change management, and this can be used in project management to ensure that change is sustainable through winning “hearts and minds”.

Chapter 10 examines ensuring the project board provides sufficient levels of appropriate challenge to ensure that the project steers clear of “groupthink”.

Chapter 11 looks into why organisations find it so difficult to learn from mistakes, and how to improve this using public wikis or learning logs, and reducing defensive behaviours.

Chapter 12 covers project closure, describing measures that may help with this emotional time, especially if the project was not a success.

The book closes by summarising what has gone before, identifying the underlying principles and suggesting some behaviours that project manager can use to improve their own results.

I would not have thought of buying this book, but am glad I have read it. It gave me several “Aha!” moments (of understanding) which I am sure others would have too. It offers a good balance between psychology theory, and practical techniques to improve project results. Recommended for all project managers seeking to improve their people skills.

Related articles

Gower Handbook of People in Project Management (Book Review)

by Dennis Lock and Lindsay Scott, Gower Publishing Ltd, Farnham, Surrey, ISBN 978-1409437857, 908 pages, £100 RRP (electronic review copy provided free of charge)
Pragmatic PMO Rating:  ***

Let me start by saying that this is BIG book. As it would take me a very long time to read the whole thing (and I doubt that the book is meant to be used that way) I will base my review on a selection of chapters that appeal to me rather than the whole thing.

Starting with Chapter 17 – The Project Office Environment, this is not as I was expecting about the business context of the Project Office, but all about the physical aspects of the office (lighting, desk layout, even carpet!) and how they can affect a project team’s performance. Most of this would apply to any office environment of course, but the chapter makes mention of special factors (such as the visibility of the project manager or director) that have special significance for projects. Some useful points are raised – for example the provision of a dedicated, lockable meeting room that can be used as a “War Room” for a particular large project or programme.

Chapter 6 – Project Management in the Private Sector outlines that projects in the private sector could be run according to a variety of methodologies (as opposed to PRINCE2® which is commonly used in the public sector), and in many cases also using the bare minimum of documentation required to get the project done quickly but in a robust manner – these documents are often made pre-requisites to obtain project funding. Private sector PMOs are also more streamlined than their public sector equivalents, and are often tightly focussed on budgets and delivery. Private sector PMOs will prioritise new projects based  on financial return, and the seniority of the sponsor (although these people will see project sponsorship as a relatively low priority). Project managers are likely to get caught up in organisational politics, and may find themselves the scapegoats for projects that have “gone wrong”.

Chapter 16 – People in Supporting Roles covers those roles that do not involve directly managing projects, and that may not be dedicated to a single project or programme – typically these roles find their home on the PMO. Amongst other things, the PMO is interested in: ensuring a consistent approach to the management of projects; development and provision of PM templates; development and maintenance of corporate PM methodology; training of PMs; demand / capacity management; estimation; planning; project control and administration. In a large PMO these functions may each be performed by one or more dedicated people, or in a smaller PMO each person may cover a wide range of roles. This chapter also covers some of the functions in the wider organisation that will support project activity.

This book has 63 chapters that average at about 13 pages per chapter. Each chapter has an introduction, some discussion and a conclusion, and is written by a current practitioner. I think that rather than being read from cover to cover, this book should be treated more like an encyclopaedia – it could be the first place you would go to in order to research a topic, to be followed up in more detail if need be. In this application, the book does a good job across a wide range of subjects. The £100 RRP is high enough to cause a sharp intake of breath, certainly, but it should be borne in mind that for this price you are getting at least 3 times the content of a more standard-sized book. This would be a good book to have on the shelves of a university, an organisational PMO, or a PM practitioner looking to develop their knowledge of the people aspects of PM.

Related articles


Spontaneous teamwork – the best kind?

Spontaneous teamwork - the best kind

I recently saw a great example of spontaneous teamwork. I was making my way up one of those very long escalators you find in London tube stations. Some way above me and ahead of me, a woman took off her hat and put her hand on the moving hand rail, but without realising it let go of her hat. The hat slid quickly down the steeply sloping polished surface next to the hand rail. It slid past several people but a man about ten rows behind the woman caught the hat. The hat was then passed forwards by various people and within little more than ten seconds was returned to the delighted and grateful woman, who until then had not even realised it was lost.

I noted several observations from this little scene:

  • This team formed completely spontaneously – no-one was assigned roles or organised from above (but then this was a very simple little task)
  • Nobody told the team what to do – they saw there was something that needed to be done, and they did it
  • No-one in the team had anything to gain from their actions, except the satisfaction of doing something good, and of seeing the woman’s smile when her hat was returned (although granted they were there anyway and it was very little trouble to them to help her). She was positively beaming – I think it was an expensive hat!
  • The recipient was delighted with the result because she got something she wasn’t expecting.

So how can we apply these observations to teamwork in project management? Here are my thoughts:

  • If you are lucky enough to have an experienced and mature team, let them organise themselves as far as possible – show them what needs to be done and then hold back, only stepping in if it looks like it’s not going to work.
  • Explain to the team what the end goal is and that you need their help. They will feel more motivated to contribute if:
    • they can see what the goal is and agree it is worthwhile
    • they can see how their actions contribute to reaching the goal
    • they will receive recognition for achieving the goal
  • If you want to delight your sponsor, you can deliver a little something extra that they didn’t know about (but that is easy and cheap for you to provide, that the sponsor finds desirable and that they didn’t have to pay any extra for!). B.Be careful here though, as they may expect similar extras in future that are difficult and expensive for you to provide, and providing too much as free extras could lead to your sponsor undervaluing the delivery they did pay for.

What do you think? What PM lessons occur to you from this little scene?