Schedule setup: How to customise MS-Project® text fields to show diagnostics

Part 1 of a series on customising fields in Microsoft® Project® to make working with project schedules more useful.

How do you set up a framework to enable you to quickly identify and review project schedules for common schedule setup logic errors, without having to deduce and apply complex combinations of filters? This is the approach I have used successfully on several programmes.

Schedule Setup - How to customise MS-Project text fields to show diagnostics

When you are pulling together a collection of project schedules to create a useful programme schedule, you may find that they are of variable quality, and may contain some fairly basic schedule setup errors. To avoid wasted effort, I recommend you first check incoming project schedules for commonly-occurring schedule setup logical problems. This post follows on from how to create a useful programme schedule by providing a bit more “nuts and bolts” detail on how to do this.

What we are looking for, where it comes from and why we don’t want it

Resources assigned to summary tasks

  • Sometimes Project Managers (PMs) do this deliberately, e.g. to show a single person overseeing a group of tasks.
  • More often, though, it is a “hangover” from an earlier schedule stage, where the PM assigned the resource to a single placeholder task that was later broken down into more detail. So you will probably find the same resource assigned to the lower level tasks as well.
  • Unresolved, this can lead to artificial over-allocation of the resource and hence inflation of cost forecasts if the schedule is being used for this purpose.
  • If the resource allocation to the summary task is being used to show ownership, it is probably better to use a separate (task owner) field for this.

Summary tasks with links (predecessors and/or successors)

  • Sometimes Project Managers (PMs) do this deliberately, e.g. to show that something starts when a group of tasks has finished.
  • More often, though, it is a “hangover” from a setup stage, where the PM assigned a dependency to a single placeholder task that has since been broken down into more detail.
  • This can lead to complications establishing the critical path, and can place artificial constraints on tasks, so they don’t behave as you would expect.
  • If the dependency on the summary task is genuine, I recommend that instead you create a “collector” milestone within the summary task, that has all the deliverables in the summary task as predecessors.

Tasks without successors (widows) or predecessors (orphans)

  • Pretty much all items in a schedule should have at least one predecessor and at least one successor The exceptions are: summary tasks, a single milestone indicating the project start, and another milestone indicating the project end.
  • If an item has no predecessors, then it is not dependent on any other tasks and could be done now. So why is it scheduled when it is, rather than now? Why haven’t we done it already?
  • If an item has no successors, then its completion is not required by any subsequent items in the plan. So why are we doing it at all? can it be removed?
  • Items missing predecessors and/or successors also will not be included in the calculation of the critical path through a project.

Placeholders in the past

  • PMs sometimes use “placeholder” tasks (with default date and duration, and no predecessors or successors) as memory joggers for small tasks to be carried out at some point, or a task to be fleshed out with more detail later.
  • By default, MS-Project schedules new tasks on the Project Start date (often a long time in the past) and gives them an arbitrary, default duration (usually 1 day)
  • When enough of these are bundled with other, active tasks into a summary task, the non-completion of the placeholder makes the summary task look much longer than it should be, and woefully behind schedule. This is inconvenient if you are using schedule extracts for stakeholder communications, as it makes things look worse than they are.
  • I recommend scheduling placeholders like these in the future using estimated dates and durations.

Item uses over-allocated resource

  • If a PM allocates too much work to a resource, or a resource is assigned to too many tasks at the same time, the work cannot be performed as scheduled, calling forecast delivery dates into question.

How to do it: logic tests

So how do you easily detect these common schedule setup problems? The answer is to customise a Text field to display a very compact commentary resulting from some simple tests that look for common scheduling logic errors.

To do this, pick an empty custom task text field (in MS-Project 2016, select Project, Custom Fields), rename it something like “Schedule setup diagnostics” and click on Formula:

MS-Project custom text formula dialogue box
MS-Project custom text formula dialogue box

Enter the following formula:

IIf(([Summary] And (([Predecessors]<>"") Or ([Successors]<>""))),"SWL ","") & 
IIf([Summary] And ([Resource Names]<>""),"SWR ","") & 
IIf((Not [Summary] And ([Predecessors]="")),"W ","") & 
IIf((Not [Summary] And ([Successors]<>"")),"O ","") & 
IIf(([Start]=[Project Start]) And [Estimated] And ([Predecessors]="") And ([Successors]=""),"PIP? ","") & 
IIf([Overallocated],"UOAR ","")

Pay close attention to all the brackets and commas. You need them all, in that order!

The Result

This formula uses IF statements and text string concatenation to alert you with short text codes if items in the plan suffer from any of these logical schedule setup problems:

  • SWR = Summary task With Resources
  • SWL = Summary task With Links
  • W = Widow (non-summary task without successors)
  • O = Orphan (non-summary task without predecessors)
  • PIP? = Placeholder In the Past?
  • UOAR = Uses Over-Allocated Resource

Display the new column in your Gantt chart table (in MS-Project 2016, select Gantt Chart Tools, Format, Insert Column, and type the name of the new column, in this case “Schedule setup diagnostics”); any commentary generated by the formula will appear in this new column.

The presence of any of these codes should prompt a discussion with the PM, and preferably the adjustment of the schedule to correct the error (unless it was deliberate) and remove the flag.

So that’s my approach to automating MS-Project schedule setup diagnostics, learned through the experience of getting it wrong and coming up with a better way.

Is this approach useful to you? How do you check for consistent project scheduling logic? How do you check for consistent project scheduling logic like this? What do you use custom fields for? Let me know in the comments.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?

® Microsoft and Project are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

6 PMO productivity pointers for Microsoft® SharePoint® Team sites: Libraries

Top tips drawn from experience

SharePoint tips - Libraries

To create an project or programme information hub, you could do a lot worse than setting up a SharePoint team site as suggested by Dux Raymond Sy’s definitive book on the subject. If SharePoint is already used in your organisation, it’s virtually a no-brainer.

SharePoint document libraries represent a great way to share documents across teams, giving you features like metadata classification, automatic version control, and more efficient document management. Julian Maynard-Smith outlines the benefits of a proper document management system in this great post.

However, there are some things that I have discovered for myself over several years of creating and using project management libraries on SharePoint sites that I would like to share with you.

1. Set up document libraries using reference data and standardised views.

  • Set up lists of reference data you want to be available throughout your site (e.g. project name, project stage, document type, document status, etc.).
  • Create a customised document library template containing fields that “look up” this reference data
  • Create a consistent “family” of useful library views that use this data, such as:
    • All documents (grouped by project, then document type)
    • Draft documents (grouped by project, then document type)
    • All documents grouped by Governance body and then status, sorted by review/issue date (for when you want to check what was reported three SteerCos ago)
    • All issued documents, by project and then document type
  • For more on how these approaches are useful, see my tips post on SharePoint Registers

2. Set up views based on metadata (and maybe folders)

  • People are used to storing files in a shared network drive using nested folders. This works, but locks you into categorising your documents by just one hierarchy. Consider a document library containing contact details could be organised like a paper telephone directory, with folders arranged in counties, then towns, then business/residential, then sorted alphanumerically by name.
  • This is fine if you want to see records for all the businesses in Bedfordshire, as this complies with the filing structure’s hierarchy.
  • But what if I want to see all the residential records across Bedfordshire and Buckinghamshire, sorted alphanumerically by name but excluding those beginning with Z and P?
  • That’s where metadata comes in. By assigning document metadata (information about the documents, aka “tags”) you can:
    • Filter documents, much as you would in Excel®. So you can “slice and dice” the documents any way you like.
    • Group documents by expandable/collapsible category headings that behave and look a bit like folders.
    • Set up and save your own views, and look at documents differently from other users at the same time.
  • Disadvantages include:
    • Users often don’t tag files with metadata on uploading, even though they subconsciously do it in a file share by choosing which folder to put a file in. This could lead to many unclassified documents. The Programme Office (PgMO) could tag documents of course, but to do it all is a lot of admin and the document owner usually knows the document content better than the PgMO. You can of course require users to add metadata, but this can cause problems when the available tags don’t quite fit (so the PgMO needs to add new values to the field list), or a user is unsure of what metadata to add (PgMO needs to educate users).
    • File grouping can only go two layers deep, so you have to apply grouping thoughtfully, and use sorting or filtering below that.
  • An option that works for both philosophies (kind of) is to set up libraries with a standard set of folders, but also set up views that ignore the folder structure, using metadata instead. That way, people can find information using the approach they are the most comfortable with. And the point of a document library is to enable people find the information they seek, faster.

3. Use check-out and versioning

  • OK, so this is covered in Dux Raymond Sy’s book, but its so important, I want to highlight it here.
  • Using this feature:
    • Prevents the absurdity of “who saves last wins” (when two people are working on the same document, making competing changes, and saving the document with the same name)
    • Enables you to “permalink” to the latest version of a document (so that the URL you issue for a document always points to the latest version)
    • Enables you to see all the previous versions of a document (along with who created them when) and reinstate any one of them as the current version.

And why wouldn’t you want all that?

4. Create document libraries from your template

  • To determine how many libraries to create, think about how people will use the documents you store in them.
  • One library per project might make sense; a separate library for sensitive documents (e.g. contracts, quotes, invoices, resourcing plans, etc.) definitely makes sense (to appropriately manage access to sensitive content).
  • Creating new libraries created from your template means that the new libraries will already contain all the document fields and views that you put into the template.

5. Set access permissions at library level

  • Although you can assign permissions at folder and even document level, this can cause confusion as it is possible to assign access to a document, but not the folder that contains it.
  • This means the user can access the document if they are directed to it (e.g. from a hyperlink). However they cannot browse to the document location, so they have no sense of “where” it is.
  • There is effectively a permission “wormhole” to the document that doesn’t pass through any intermediate locations. So the poor user will know the document exists, but it will be virtually impossible for them to find it again without the hyperlink(!). To get an idea of what that looks like, take a look at this.
  • Also, SharePoint is not great at showing you how you have set these exceptional permissions, so it is hard to know who has access to what.
  • Setting access at library level with inherited permissions makes this much easier to handle.

6. Set access permissions using groups

  • Name groups according to who they contain rather than the type of permissions assigned to them. A group created to assign read permissions to library X and called “Lib_X_read” may later be used for another purpose for which that name would become confusing. It would be better to call the group something like “Project Managers” or “Business Analysts”, and assign appropriate access permissions to the group.
  • Although you can assign permissions to individuals, it is better if you assign permissions to groups, and manage permissions by amending the users in these groups.
  • If you accidentally delete all users from a document library, sub-site or (heaven forbid) an entire site collection, then it is much quicker to restore access if users are already in a group such as “<SiteName> All Members” than it is to manually restore access for each and every user or to put each and every user into a group as they really should have been in the first place. Trust me. I know.

So that’s my list of productivity top tips for SharePoint document libraries, learned through the experience of getting it wrong and coming up with a better way.

This article covers only the document library tips that I could explain in a compact form without the need for diagrams or examples. It doesn’t include many other conventions that I use when creating and managing SharePoint team sites to improve efficiency or usability, otherwise this article would have been more like a book (it’s already pretty long)!

If you would like to have the benefits of a document management approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?

® Microsoft, SharePoint and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Image “Trinity College Library (1 of 2)” by brett jordan,, Licence at

6 PMO productivity pointers for Microsoft® SharePoint® Team sites: Registers

Top tips drawn from experience

SharePoint tips - Registers

To create an project or programme information hub, you could do a lot worse than setting up a SharePoint team site as suggested by Dux Raymond Sy‘s definitive book on the subject. If SharePoint is already used in your organisation, it’s virtually a no-brainer.

Project management “RAID” registers are prioritised lists of things like Risks, Issues, Actions, Decisions and so on. Keeping registers helps you to keep track of the factors affecting your project, and the things going on within it, so that the whole thing ticks along more smoothly.

Microsoft SharePoint offers some facilities that can be used for this quite effectively, However, there are some things that I have discovered for myself in several years of creating and using project management registers on SharePoint team, sites that I would like to share with you.

1. Plan reference data

  • Decide what data you want to be available throughout your site – the sort of thing you might set up in Excel using data validation to populate drop-down menus from lists.
  • These lists could contain information such as the programme’s projects, locations, project stages, governance bodies, etc.
  • It may sound odd to consider this at the outset, but you need it in place before you set up the RAID registers. It is far quicker and easier to create registers from a template that refers to pre-existing data lists than to reconfigure registers once you have realised it would be neater for them to use reference data.
  • Set up any governance bodies (such as SteerCos) as SharePoint groups. You can use these anywhere you might use a person, e.g. for things like “assigned to”, “raised by”, and “escalated to”
  • Set up your other reference data as SharePoint lists. This means:
    • Changes in the source list automatically become available for use across the site, including in registers.
    • You can “hide” reference data lists by preventing them from displaying on the main site navigation bar. You will know where to find them for editing (in “site contents”) but most users won’t.

2. Create a custom RAID register template

  •  You will probably want to create a “family” of registers (for Risks, Actions, Issues, Decisions, etc.), that share many fields (Date raised, assigned to, Title, Description, Score, Progress, etc.)
  • I recommend that you first create a risk register (by augmenting SharePoint’s built-in “Issue Tracker” template)
  • Set up relevant fields to “look up” reference data from the lists you created earlier, (e.g. project name, project stage, document status, etc.)
  • Save the risk register as a list template, to use when creating other registers. Of all the registers, the risk register has the most fields, so in order to create other registers you will either be removing unwanted fields from the template or repurposing them slightly. This is quicker and easier than creating registers from scratch, and ensures that reused fields are set up consistently across registers.

3. Create a consistent “family” of RAID register views

  • Most people don’t want to view all the items in a RAID register; they are mostly interested in their items, or open items, or their open items.
  • So, create a core “family” of consistent register views (All items, Open items, My items, My open items), all sorted by due / review date and priority.
  • These can be outline views (containing only a few columns) as their main purpose is to enable quick review and finding of RAID items for updating.
  • Create an “Open and recently closed” items view, which is good for reporting to governance bodies as it shows live items and those that have been closed since the last report / meeting (Date closed >= [Today] -28)
  • If you create these views before saving the risk register as a template, then they will appear in any register you create from it.
  • This means that users see the same logical “family” of views whichever register they are in, so they can find information faster and more easily.

4. Use Excel® for reporting on RAID registers

  • For easy and attractive presentation of RAID data (e.g. top 10 risks, issues, etc.), export the register of interest to Excel (SharePoint Classic view –> Lists –> Export to Excel).
  • Do this from a view that shows all the fields. In Excel, hide the ones you don’t want (for now) using data grouping or by hiding columns, then apply any formatting, filters, and summarisation formulae you need.
  • You can create a workbook containing one worksheet like this for each RAID register.
  • This approach gives you data tables (with detail that you can easily unhide) that can be refreshed with live SharePoint data at the click of a button (“Refresh all” in Excel).

5. How to tell which list item number you’re editing

  • If you’re reviewing a list of items in a filtered view of a RAID register, it’s useful to know the number of the item you’re working on (e.g. “Risk 45” or “Action 199”) so that when you go back to the list you know which ones you’ve updated, and which still need updating. But nothing on the SharePoint editing page gives you the number of the item (maybe because this is not an editable field?)
  • However, the number is there if you know where to look; up in the browser address bar, the item reference number is embedded in the URL, e.g. https://[SharePointServerName]/sites/[SiteName]/Lists/[RegisterName]/EditForm.aspx?ID=##&Source=VeryLongTextString
  • Incidentally, you can resolve this problem by creating a view that shows items that are assigned to [Me], AND of which the Status = Open, AND for which the Modified date is not equal to [Today]; this will only show your open items that you haven’t just updated. But the tip is still true 🙂

6. Link items across registers

  • It can be useful to understand where register items came from, e.g. that the action “Recruit developers” came from the issue “Development behind schedule”
  • For this reason it can be useful to add lookup columns to each register enabling users to link to items in other registers (most helpfully via the item title); this cannot be done in a list template as the other registers need to exist first.

So that’s my list of productivity top tips for SharePoint RAID registers, learned through the experience of getting it wrong and coming up with a better way.

This article covers only the RAID register tips that I could explain in a compact form without the need for diagrams or examples. It doesn’t include many other conventions that I use when creating and managing SharePoint team sites to improve efficiency or usability, otherwise this article would have been more like a book (it’s already pretty long)!

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?

® Microsoft, SharePoint and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Image “Sub Cash Register” by Franck BLAIS,
Licence at

Buses, trains and schedule optimisation

High risk rapid delivery or lower risk slower delivery – which would you go for?

Buses Trains and Schedule Optmisation

Until recently, my morning commute into work comprised a bus journey to the station, a train into London, and another bus to the office. One morning a few weeks ago I was ready about ten minutes earlier than usual so instead of waiting about 15 minutes to catch my usual bus, I took the earlier bus from near my house. I had already bought my train ticket so I didn’t have to queue at the station, instead waiting just a few minutes to get on a train about 25 minutes earlier than my usual one. Once in London I went to the bus stop, and joy of joys, the bus arrived straight away.

All in all, by leaving my house about 25 minutes earlier than usual, I managed to arrive at my desk at least 45 minutes earlier. I had made a significant time “profit”!

There were some unexpected but very welcome fringe benefits too – the earlier trains and buses are less crowded and so I have more chance of getting a seat (making the journey more pleasant) and often enough elbow room to do some work on the way (making the journey also more productive).

It occurred to me that what had happened here was akin to what I do at work with schedule tuning – I had experienced a journey with less slack time (waiting) between the fixed duration events (journey stages) to enable an earlier final delivery (my arrival at my desk).

I now regularly use this approach to get to my desk earlier. Having less slack in the plan introduces risk of course; if any of my journey stages runs even a few minutes late then it all falls apart and the rest of the journey reverts to the (considerably slower) Plan B. But it works enough of the time to make it worth persisting.

Are you able to use schedule optimisation like this to cut the overall duration of your projects? Are you more concerned with earlier delivery, regardless of overall project duration? Or do you go for a less risky plan with more slack?

© Copyright Pragmatic PMO Ltd, first published in 2012

PMOs perfectly positioned to help make project products persistent

How PMOs can smooth the path of projects, to help make changes more “sticky”

Photograph of the London Eye, superimposed with the text "PMOs perfectly positioned to make project products more persistent"

A while back I attended a PMO FlashMob discussion facilitated by Ranjit Sidhu of ChangeQuest and hosted as usual by Lindsay Scott of Arras People.

This session was on how PMOs can help projects to deliver organisational change more effectively. There were several interesting take-away messages, of which I found the most interesting to be:

  • If you want a change to “stick” (without people reverting to the old way of doing things), it is just as important to get the people ready for the change (Change Management) as it is to get the change ready for the people (producing project deliverables).
  • The most successful Change projects allow stakeholders time to “grieve” for the old ways, and time to become familiar with the new ways. These projects put in consistent effort to maintain momentum on the journey from the “as is” to the “to be”, until the post-change ways become “the new normal”
  • Small pilots (preferably including some vocal objectors) can generate early successes that can be used as good news stories to spread the word and help to form positive opinions.
  • Change projects may well be asking BAU workers to carry extra work above and beyond their “day jobs” (with all its targets and objectives). During major changes, a significant proportion of people experience sufficient stress so as to pose a risk to their mental health. What can projects do to help organisations come through the Change experience still healthy?
  • Just telling people about the Change and what will happen will only get you so far. Listening to stakeholders and demonstrating what you have done with their feedback will get you much farther.

PMOs (especially PfMOs) have a unique position on the interface between the projects being carried out to effect organisational change, and the people out in the wider organisation who experience the change happening to them. So PMOs can help changes to stick by:

  • Including change management themes in project reporting (at least as a RAG category, or preferably as a measured deliverable).
  • Devising and delivering approaches to express change management as a quantified KPI.
  • Becoming the “eyes and ears” of projects; picking up informal stakeholder views on projects.
  • Project and Programme PMOs can also make change easier internally by providing good quality inductions for new project team members.

So those were the key points for me (Lindsay’s are here) from what was a very informative and useful session on how PMOs can help to make change “sticky”.

© Copyright Pragmatic PMO Ltd, first published in 2015

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,). This is essential for keeping your schedule on the right track. 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

Strategies for social CPD – Creating a PM community

How learning groups spontaneously form and disperse…

Some people sitting at a meeting table watching another person write on a white board. They may well be having a learning session

A while back I attended an APM focus group facilitated by Dr Michael Moynagh of CPD Futures Ltd on developing strategies to improve the way that project professionals approach continuing professional development (CPD). One of the topics that came up was that established approaches to CPD (including the approach promoted by the APM) are somewhat rigid and introspective, and lack a social dimension. The suggestion arose that some sort of group learning approach might be helpful, e.g. creating a PPM Community of Practice.

I have seen this happen with some success (albeit rather briefly!) in the following situation:

  • The organisation had stated its aim of raising the standard of the organisation’s approach to Project Management (and hence the professionalism of the individual PMs)
  • An entire department of PMs had been through some comprehensive PM training (delivered very professionally and capably by Michael Nir of Sapir Consulting)
  • Following the training, all the PMs were given the opportunity to go on and attempt to gain the PMI‘s PMP certification, which a good proportion of them (including me) took up.
  • For those going on to take the certification, there was a fairly hefty exam in prospect, preparation for which involved a fair bit of study and exam practice (I guess this is the CPD / Learning Community equivalent of a “burning platform”).

As a result, a group of us set up “Lunch ‘n’ Learn” sessions every week or so for several months, in which contributors would take it in turns to give a short (20 mins or so) refresher presentation on a topic (say earned value) and then ask some example PMP questions – all over lunch in a spare meeting room.

This worked quite well, but tailed off as the people sat the exams and either passed (in which case they had little interest in attending further) or failed (in which case they generally didn’t attempt a re-sit). It was good while it lasted though, and produced a few learning points for me:

  1. Communities of practice form spontaneously where there are shared interests and objectives.
  2. Participation is maximised when there is an opportunity for (or even an expectation of) contributions from all.
  3. For a community of practice to thrive, contributors must have a genuine interest in the development of both themselves and of others. Don’t be surprised if a significant proportion of potential participants don’t have such an interest. You can lead a horse to water…

Have you seen PM communities of practice? How were they formed (were they organised or spontaneous)? How long did they last? Were they successful? What approaches do you recommend? Let me know in the comments.

Image by WOCinTech Chat,
Licence at

Related articles

Stakeholder-led Project Management – Changing the way we manage projects (Book Review)

by Louise M Worsley, Business Expert Press (New York) 2017
ISBN 978-1-63157-467-2
191 pages, RRP £28.45 (review copy supplied free of charge by the publishers)
Pragmatic PMO Rating: ****


  • The aim of this book is to provide a stakeholder-centred analysis of projects, and to explain which stakeholder identification, analysis, communication and engagement models are most relevant to different types of projects.
  • Using case studies from around the world, it illustrates what goes wrong when stakeholders are not engaged successfully, and what lessons we can learn from these examples.
  • The book is aimed at project professionals who find themselves involved in managing projects with stakeholders (so that’s just about all of them then!).

What’s inside

  • This book is based on evidence from over 200 project stories gathered over five years, and the common theme of stakeholder engagement as the key differentiator between success and failure.
  • Having first rejected the term “stakeholder management” in favour of less sinister-sounding “stakeholder engagement”, the book starts with a review of the current state of stakeholder engagement both in projects (opportunities for improvement) and other disciplines (opportunities for cross-pollination).
  • It goes on to present a range of models and techniques for stakeholder identification, action and review, including the use of emerging communications technology.
  • It continues with an analysis of the difference between communication and engagement, before finishing off with a review of the main learning points, and what to focus on to create meaningful engagement in projects and programs.
  • In classic text book form (was this book written for PM students?) it finishes each chapter with a chapter summary and a series of questions designed to stimulate reflection.

Some of my favourite take-aways

  • The composition of stakeholder groupings changes over time (sponsors and product users during implementation and after Go Live, widening to include sometimes entire countries in the case of infrastructure projects), so need to plan with the end in mind and engage stakeholders who aren’t yet aware of or interested in the project.
  • If you think you are doing stakeholder engagement and its not making a difference to how you run your project, then you aren’t!
  • Effective stakeholder engagement becomes more important the more greater the technical difficulty of the project, and much more important the greater the human difficulty

    “Projects can no longer choose if they want to engage with stakeholders or not; the only decision they need to take is when and how to successfully engage”

  • Role-based stakeholders are defined by a role they have in the project (Client, Decision maker, Expert). Identify them using organisational breakdown structure analysis, project governance checklists, and asking “who else should I be talking to?”
  • Agenda-based stakeholders represent a viewpoint, usually external to the project, which may not be apparent until a crisis emerges. Although they may be silent initially, these stakeholders often have the greatest impact. Identify these using Focus groups, 1:1 interviews, Strategic tools (e.g. SWOT, PESTLE analysis), successive nomination (snowball sampling)
  • Stakeholder-neutral projects have clear, generally agreed outcomes. Engagement peaks at the project start, and again just before transition
  • Stakeholder-sensitive projects have clear outcomes that affect people and practices. These people need to be considered when designing the outcomes, and engaged throughout the project.
  • Stakeholder-led projects are highly influenced by stakeholder groups and individuals, so engagement is critical.
  • Parallel projects are not directly aimed at programme objectives, but are sometimes set up to safeguard critical success factors for another project
  • Good stakeholder engagement:
    • Gives people a say in decisions that affect them
    • Promises that participation will influence decisions – and demonstrates how
    • Seeks out those potentially affected by, or interested in, a decision
    • Seeks input from stakeholders on how they may wish to participate
    • Provides information, time, and space to allow stakeholders to participate in a meaningful way
    • Is polite

The Verdict

  • This book is written in an easily readable style, is not too long (I read it in 3-4 hrs, and I was making notes for this review) and has some useful pointers on how to improve stakeholder engagement, drawn from both theory and experience.
  • With the amount of information and ideas in this book, most PM professionals should easily be able to find enough implementable suggestions to justify the cover price; so this book is recommended.

Related Articles

What makes a “Good” lesson learned?

How to write a good lesson learned

Following on from a couple of talks I have given recently on why organisations don’t learn as much as they could from running projects, I was asked how to write a “good” Lesson Learned.

This was captured well in one of the responses to my survey

“Many ‘lessons learned’ are merely observations, with no suggestion on how to do things differently. Two or three actionable recommendations are more useful than 20 observations without any suggestions.”

To write a “good” Lesson Learned:

  • The PM should craft a story describing what happened. This could be written, delivered as a presentation, in a face to face conversation, or recorded as a video. The thing to remember is don’t polish it too much and murder the message by suffocating it in layers of “corporatese”; make it Personal, Powerful and Passionate to keep it engaging. Your story should be in STARR format, covering:
    1. Situation: This is what we were faced with (constraints, risk, issue, etc.)
    2. Target: This is the outcome we wanted to achieve
    3. Action: This is what we did
    4. Result: These were the consequences of our actions (nothing new so far I know, but here it comes…)
    5. Recommendation: (the “moral” of the story) So in order to achieve better outcomes in the future, this is how we recommend that people (including us) should behave differently, or how we should change process (rules, systems, etc.) to improve future outcomes (i.e. things to do / not do; IF this situation applies THEN do this, etc.). This is the “so what?” that changes the Lesson from being interesting story to an actionable piece of advice based on real life experience.
    6. …and lastly the PM should include details of how they can be contacted to have a conversation in case they’ve left the organisation by the time the lesson is being watched / read.
  • At the “next level up”, the PMO should consider whether there is more learning that could be extracted  from the lesson, and whether the learning could be transferred to similar projects / scenarios. If so, they could write a more generalised version of the lesson.

What about storage?

I was then asked this follow-up question:

Is this the same lesson you'd store centrally?

I would say that both the original and the “next level up” versions of the Lesson could and should be stored centrally, but the word “store” brings up images of a musty room containing miles of shelves of dusty folders that never get touched again, a bit like this…

Does your Lessons Learned repository function like this?
Does your Lessons Learned repository function like this?

The key here is that the central repository shouldn’t be an information graveyard, where Lessons go to Die.

Instead the repository should be made searchable and social (e.g. using SharePoint?) so that PMs can easily find the Lessons they need; and the PMO should be on hand to help them find relevant information if they need it (for more on this look at this excellent article by Louise Worsley).

And filing shouldn’t be the only thing that happens to Lessons, as that by itself doesn’t ensure they are acted on.

More than just filing

Lesson(s) could and should be used as material for Lunch & Learn or “scar sharing” sessions, or Vlogs, or used in the “Call 3” approach devised by John McIntyre (take a look at this article for more explanation and an example Lessons Learned Vlog).

All of this helps an organisation and the people within it to learn from their collective  experience of running projects and to (hopefully!) deliver better project outcomes in the future.

So that’s what I think. Do you agree? Do you have something to add?

Let me know in the comments!

Image “Wimborne Minster: later books in the chained library” © Copyright Chris Downer and licensed for reuse under this Creative Commons Licence

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