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, https://www.flickr.com/photos/x1brett/6382651341, Licence at https://creativecommons.org/licenses/by/2.0

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, https://www.flickr.com/photos/66971402@N04/7569786950/
Licence at https://creativecommons.org/licenses/by-sa/2.0/

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

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

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?

The Agile PMO – Leading the Effective, Value Driven, Project Management Office (Book Review)

by Michael Nir
Self-published by the Author as a Kindle eBook on Amazon.com, 46 pages (estimated, 10,400 words), £2.65 RRP (review copy supplied free of charge)
PragmaticPMO Rating:  ****

This book leads with a single central principle – that a PMO’s sole reason for existence is the creation of value for the organisation, and that the single most effective way it can do that is by managing the allocation of resources to projects. Of course, tools, methodology and processes are all good things to have, but identifying how to deploy resources for the best return on that investment is where a PMO really comes into its own.

I initially found such a forceful statement a little hard to swallow, but the book shows (using example scenarios drawn from the author’s consulting experience) several ways how the PMO can fail if it chooses to focus its efforts in other directions.

If a PMO fails to establish the necessary authority and credibility with the Project Manager (PM) community at a sufficiently early stage, it becomes relegated to performing only supportive, administrative work. This is so time-consuming that there is no time to develop more useful services, value delivery is limited and the PMO will be cut as soon as funding decreases.

If a PMO focuses on methodology, the PMs may superficially complete templates and processes just to keep the PMO quiet, but the completed templates and processes may bear little relation to reality. Unless the methodology is focused tightly on improving project delivery, this type of PMO merely increases administrative burden on PMs without enhancing value. Again, the PMO will be cut as soon as funding decreases.

PMOs that function mainly as a home for PMs do little to create value (other than managing the PMs as resources). Despite this it can persist for a long time as business value is not even considered, and the PMO duties are usually carried out by fairly junior (cheap) people.

PMOs that try to implement everything (resource management, methodology, templates, etc.) at once can appear to PMs as dictatorial rather than collaborative. This results in resistance to change and ultimately wasted effort in a failed implementation.

PMOs that focus on software tools before methodology, processes and templates spend a lot of time and effort customising the tool to accommodate the variety of approaches in the organisation. This is a very labour-intensive and expensive activity!

PMOs that implement an unsuitable methodology risk creating unnecessary barriers to implementation that slow down project delivery and upset customers.

So then, having covered several interesting (and familiar!) ways in which the PMO can fail, how is it to succeed? By treating the implementation of a PMO as a Change process, it is possible to increase the likelihood of success. Steps include: creating a sense of urgency; Creating a coalition of supportive stakeholders and engaging them to avoid surprises; Creating a vision with SMART short and long term objectives to instil pride; Communicating the vision regularly and consistently to instil trust; Empowering people to contribute and help to remove obstacles; Generating quick wins to gain support; and Embedding the changes in organisational culture.

Doing all this while focussing effort and new initiatives on the areas that will deliver the most benefit to the organisation soonest (and it helps if these also have influential and vocal stakeholders!) brings the best results.

The value created can be measured in terms of increasing the number of projects being delivered in a given time (since completed projects create value). As the availability of resources (people and/or money) is usually the single largest barrier to delivering more projects, increasing project delivery is often best achieved by creating a view of project and resource status to enable the most effective utilisation of resources across the project portfolio.

This is not a heavyweight book – you can read it from cover to virtual cover in about half an hour. Although it doesn’t go into detail describing the ideal approach (which in any case would differ in the detail from organisation to organisation), for me just as much of the real value in this book comes from the examples of what not to do and how that leads to failure.

Well worth the purchase price!

How to keep your programme schedule on the right track

Having created a useful project or programme schedule, how do you use it as a delivery tool? Here’s the approach I have used successfully on several recent programmes.

How to keep your programme schedule on the right track


During the final delivery stage of a multi-year relocation and Change Management project, with a few weeks to go before moving ~800 people and their equipment between sites, I was managing the integrated programme schedule to confirm we were in a position to move on the planned dates (or not!).

The Steering Committee (SteerCo) and Internal Audit wanted reassurance (via a series of pre-move readiness meetings) that we would be able to move on the planned dates, to know that the Business and Stakeholders would be happy to move on those dates; and for the programme to take any appropriate action to enable this to happen.


To enable this, I created a suite of intermediate “collector” milestones on the programme schedule:

  • “People ready” to move (reflecting the completion of Change Management activity, both “Must have” and “Should have”)
  • “Systems & Building ready” to receive the People ( both “Must have” and “Should have”)

I worked on the basis that in order to be in the “Must have” category, the absence of the deliverable had to be big enough to stop the move; otherwise it wasn’t really a “must have” but a “should have”. I made these intermediate milestones immediate predecessors of the first move (with any slack available between these and the first move date being explicitly shown as schedule contingency).  I obtained current information on forecasts and actual start/finish dates through weekly Workstream Lead (WSL) reports and regular 1:1 schedule review sessions, and updated the schedule with this information.


I monitored the plan (and especially the critical path leading up to the first move) for the effect on the final deliverables of any updates. Each time I updated the plan with new information, I checked to confirm we were still on track to deliver the final deliverables on the planned dates, adjusting the contingency buffer if necessary.

In this way I spotted anomalies – for example, having updated the schedule with revised dates from weekly WSL reports, I noticed final delivery milestone had moved 2 weeks later than planned. Each WSL’s detail plan appeared to be on track in isolation, but taken as a whole programme (taking dependencies into account) the final deliverables were late.


My typical approach to finding the cause of an anomaly such as this is to trace the predecessors of the slipped deliverable, working backwards in time to find where the delay is ultimately coming from (usually this is from missing or outdated inter-workstream or inter-project dependencies, raising the need for greater detail or revised dependencies).

In the case of the example, I isolated the problem to the start of a technology Pilot, which in turn was dependent on an IT system becoming available following Technical Testing and User Acceptance Testing (UAT).

Re-plan, Recommend, Resolve

I then analyse the situation and propose some remedial options, in the case of the example these included:

  • Removing the IT system from the Pilot scope (introducing a quality risk)
  • Shortening the duration of the Tech testing before the UAT and Pilot (also introducing a quality risk)
  • Combining the Pilot with UAT by selecting UAT users for the Pilot, killing two birds with one stone (recommended approach)

The programme team opted to implement the combined UAT / Pilot approach I recommended, bringing the programme back onto schedule. The approach for Change Requests is similar:

  • Create a new version of the schedule (or insert new activities in such a way that they don’t affect the “real”, working schedule) to use as a “what-if?”schedule.
  • Make the changes as detailed in the Change Request, making or breaking dependencies as appropriate.
  • Assess the impact on the delivery dates, resource utilisation, financial forecasts, and make a recommendation to the programme director and ultimately the SteerCo to accept or reject the Change Request.


As a result of using this approach:

  • The programme was kept on schedule, to deliver on time;
  • SteerCo and Internal Audit were reassured that the run-up to moving was in hand, as they were kept up to date on an ever-diminishing list of pre-move “must have” deliverables;
  • The Go/NoGo decision on moving was taken in the full knowledge that: all “must have” deliverables would be in place on day 1; most “should have” items would be in place on day 1, and the missing “should have” items would become available on specific dates post-move.

In this way, the schedule was transformed from a collection of dates and coloured sticky notes on the wall into a dynamic tool with which to proactively manage programme delivery.

So that’s my approach to keeping a programme schedule on track, learned through training and experience. It this approach useful to you? How do you keep your programme schedules on track?

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?

How to create a useful programme schedule

How do you integrate the schedules of multiple projects into a single programme schedule that concisely conveys time-related information? This is the approach I have successfully used for several programmes.

How to create a useful programme schedule

I was brought into a programme which had only rudimentary programme spreadsheet-based plans, and which was therefore unable to forecast how delays in one part of the programme would affect other parts of the programme, or to assess the potential impact of change requests. Senior stakeholders needed a programme “road map” (to assess overall progress towards delivery deadlines, and to obtain some guideline forecasts for the annual budgeting cycle), and the programme director needed a detailed view of the activities leading up to delivery.

Purpose of the schedule

A programme schedule should not just be a pictorial representation of what we think will happen, or a rigid list of events to which the programme should slavishly adhere. Instead I believe it can and should be a flexible model of the programme’s activities that can forecast potential problems, be adapted to overcome those problems, and be used to enable on-time delivery.


Where they already existed, I used task lists and brainstorming session outputs as a starting point. I developed these by meeting with project managers (PMs) and workstream leads (WSLs), capturing their thoughts on the key activities of their projects directly into Microsoft® Project® (MS-Project), challenging duration estimates and dependency relationships as we worked. I refined the resultant draft schedules using stakeholder input before getting them agreed by all parties and baselining them.

Where there were no plans at all, I either held planning sessions or translated process flow diagrams prepared by Business Analysts into MS-Project plans, cross-linking these with dependences into an integrated and resourced programme schedule, with the critical path identified and highlighted.

I also worked with contributing PMs / WSLs to standardise elements of their plans (e.g. use of custom MS-Project fields) for easier integration into a programme schedule.

From this programme schedule, I prepared resource and financial plans for budgeting as required, custom filtered views (missed milestones, items due to start or finish in the next four weeks, etc.) for progress tracking, and highly summarised “road maps” for senior stakeholders.

I kept the schedule updated with progress and with the outcomes of approved Change Requests; I regularly reviewed forecasts against the schedule baseline to identify potential slippage; and prepared “what-if” plans showing the impact of proposed changes.


In this way, the schedule was transformed from a collection of dates and coloured sticky notes on the wall into into a dynamic tool with which to proactively manage programme delivery.

Under this approach, the Programme Manager has a good forward view of the critical path to delivery (and the potential pitfalls along the way) and the Programme Board has a good overview of progress achieved so far, and the activities still to come.

But what about when things change? What do you do then? More about that in a separate post.

So that’s my approach to creating a useful programme schedule, learned through training and experience. It this approach useful to you? How do you keep your programme schedules on track?

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.


What does your PMO stand for?

(well OK, mostly the “P” part…)

All over the web you will see people asking or debating what the “P” stands for in PMO. The “MO” stands for “Management Office”, but the “P” can stand for Project, Programme or Portfolio depending on the organisational context.

Axelos use the term P3O® to cover all three, but this is also confusing as the insertion of the “3″ makes many people think that the final “O” is actually a “0″ (zero) rather than the “O” of “Office”.

This can of course lead to confusion, so I suggest making a small alteration to remove the ambiguity. In my own writing I use:

  • PjMO = Project Management Office
  • PgMO = Programme Management Office
  • PfMO = Portfolio Management Office

This makes it very clear which kind of PMO we are talking about. Simples!!

What do you think?