Project Planning Pointers

Like a piece of machinery, plans need a good design, room to breathe, and good maintenance…

Project Planning Pointers

A while back I attended an APM presentation on the role of the dedicated Project Planner, part of a series given by Andrew Jones, at the time of Athena Project Services.

His presentation contained several key points that resonated with me so I thought were worth restating in the light of my own experience.

  1. Estimates need to have a solid foundation. No, a finger in the air won’t do here. Base your estimate on a similar project that was done recently. Base it on productivity figures and lines of code. Base it on PERT or three-time estimating if you like, but be comfortable with how you derived it and have at least some idea of the potential error margin. I have used all of these estimating techniques at some time or other, and knowing the likely accuracy at least gives you a guide for how much contingency to build in, which brings me to…
  2. Build in some contingency. A knotty one, this! In most plans where I have explicitly built in contingency, I have been required to remove it to reduce timescales. In most cases, of course, something has then happened to increase the project timescales, and the final delivery has ended up where it would have been with contingency in place, except that the project is now Late. No wonder project managers are tempted to build in “secret” contingency, and deliver on time?
  3. Update the plan with actuals (durations, costs, etc,). If a task was late due to a delay, add in a task showing this delay and label it accordingly. The schedule then acts as an audit trail for delivery. If any of the tasks are repeated, use the actuals from iteration 1 to refine the estimates for iteration n. Follow through and see what the impact is on delivery. I have found it is very difficult to get people to care about activities once they’re complete, but this approach does mean that you can apply your learning from the past to the future, and best of all this happens while the project is still running.
  4. Manage the Critical path. Make sure you make good use of dependencies, and as little use of time constraints as possible. I always do this as much as possible, as it enable you to see the effect of any changes on the critical path at the touch of a button. The plan should be a useful mathematical model of the project, not just a pretty picture on the wall of some coloured bars linked together.
  5. The act of developing the plan is as important as the plan itself. Or perhaps more important! Thinking through the steps in detail, rehearsing the project in the team’s collective mind, is a great way of identifying potential pitfalls and managing them while they are still risks, if appropriate.

What are your experiences? Do you agree with Andrew and me? Do you have any planning tips you would like to share?

© Copyright Pragmatic PMO Ltd, first published in 2013

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: ****

Overview

  • 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

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

How to take charge of your project portfolio’s annual budget

Project and Programme Managers (PMs) are used to managing projects within a budget for the project stage or the whole project, but they sometimes overlook the context of the organisational annual budget; this is especially important if the project spans multiple financial years.

How to take charge of your project portfolio's annual budget

Project funding approval for a whole project or project stage can be thought of as the Portfolio Board deciding that the project’s Business Case is viable, and that the project should go ahead.

This approval can be given once for the whole project (usually if the project is relatively small, short in duration, low in complexity and risk), or gatewise at the beginning of each stage (usually if the project is relatively large, long in duration, high in complexity and risk). This approval can also be separate and distinct from the financial year budgeting process (figure 1).

Figure 1: Financial year vs. project budgeting
Figure 1: Financial year vs. project budgeting

Inclusion of project funding in the financial year budget can be thought of as (usually) the Finance department deciding that the organisation can afford to spend £x on projects as a whole, with the projects making up the budget being selected based on some prioritisation rationale.

So a project managers’ forecasted project costs need to stay not only within the budget for the project (current stage and overall), but also the financial year budget (this is especially important if the project covers more than one financial year).

So how to apply this to portfolios? I was brought into a PMO facing an annual project budget considerably smaller than the previous year’s, with no way to forecast whether the proposed portfolio could be delivered within budget. The organisation had also mandated moving labour spend from Consultants, via Staff Augmentation (comprising flexible resources and independent Contractors), to permanent Internal staff. This is how I approached it:

  1. I devised a standardised way of classifying labour costs to enable comparison across projects (projects had previously been accounting for labour costs in a variety of ways).
  2. I introduced an approach requiring PMs to validate their remaining project cost forecasts every reporting cycle when updating actual costs.
  3. I created an automated report to extract financial data from the project portfolio system and present a monthly breakdown of costs over the financial year (with actuals in the past and forecasts in the future). Labour was broken down further (Consultancy / Staff Augmentation / Internal) to reveal trends (figure 2).
Figure 2: Breakdown of monthly costs by standard cost category
Figure 2: Breakdown of monthly costs by standard cost category

Thus, stakeholders could see every month whether the portfolio was on track to deliver within the financial year budget and track the movement of labour from high towards lower cost labour sources as mandated.

After a few months monitoring, I noticed that there was a “bow wave” phenomenon, with projects seeming to “push” cost forecasts in front of the current month (figure 3). I suspected this was because the projects were forecasting to use up the remainder of the funds allocated to them, so I challenged the PMs to ensure that the forecast to the end of the year represents the forecast cost of the work remaining.

Figure 3: Project cost forecast "bow wave"
Figure 3: Project cost forecast “bow wave”

 

After some revisions to the forecasts, and delays to a number of projects (some deliberate, and some arising from outside the organisation), the outcome was that all the projects in the portfolio could be delivered well within the new lower budget, with a surplus being returned to the organisation.

Does your organisation monitor against annual financial budgets as well as end-to-end or gatewise project budgets? How does your PMO ensure that projects stay within all of these? Let me know in the comments.