Schedule automation: How to customise MS-Project® text fields to show schedule management diagnostics

Part 3 of a series on customising fields in Microsoft® Project® to make working with project schedules more useful.
So you’ve created a useful programme schedule, and you are now working on keeping it on the right track. You’ve set up fields to calculate RAG status, but what if you want some schedule management information to go with it, in the form of some compact RAG status explanation to go with it, without having to study the baseline vs. forecast dates and % complete, working it out in your head line by line?

This post describes how to customise a Text field to display a very compact schedule management commentary to explain why a project schedule item should be Red or Amber.

Continue reading “Schedule automation: How to customise MS-Project® text fields to show schedule management diagnostics”

Schedule automation: How to customise MS-Project® text fields to calculate RAG Status

Part 2 of a series on customising fields in Microsoft® Project® to make working with project schedules more useful.
So you’ve created a useful programme schedule, and you are now working on keeping it on the right track, reviewing the plan regularly with the Programme Manager and Project Managers. You will probably review the programme schedule regularly – focussing on on items with Red or Amber RAG status –  but how do you use MS-Project to ensure that you don’t skip items that probably should have been marked amber or red?

Schedule Automation - How to customise MS-Project® text fields to calculate RAG Status

This post describes how to introduce some schedule automation by customising a text field to display RAG status (based on performing some simple tests and calculations with dates).

So why would you want to use this approach, how do you do it, and what’s in it for you as a result?

The Why

RAG status is often allocated to project tasks based on the intuition or “gut feel” of the project manager. But too much subjectivity in status reporting can lead to watermelon or green-side-up reporting, in which project status is reported more favourably than it probably should be. The more objective approach presented here introduces some schedule automation, assigning a RAG rating to individual project tasks based on calculation.

This approach can’t account for subjective things like project risks (that takes professional judgement), but it can give a useful “starter for ten” RAG status assessment onto which the PM can layer factors such as risk, or to act as the starting point of a discussion.

The How

Approach: Logic tests

Devise a set of criteria that you will use to determine RAG status, based on the rules or criteria in place for your project or programme. Your central PMO may have some criteria, or you may devise your own. They may look something like this (this assumes the plan has been baselined):

  • Red = Item that should be complete by now but isn’t
  • Amber = Item forecast to finish later than baseline finish date
  • Green = Item forecast to finish on baseline finish date or earlier

You need to formulate the tests in such a way that they can be expressed as a mathematical expression that can be tested and return a TRUE or FALSE result. For example, to test whether an item should have finished by now, test for [Forecast finish date] < [Today’s date]. If the answer is TRUE, the item should have finished by now.

These tests can be made as simple or complex as you like, for example you could enhance the Red test so that Red returns true if the item (is forecast to finish earlier than today’s date) OR (is on the Critical path, and is forecast to finish later than baselined) OR (is on the critical path and has not yet been baselined).

After testing for item completion (because if the item is complete then none of the other tests apply) these tests will be applied in order of decreasing severity (because an item that triggers a Red condition would probably trigger all the Amber conditions too).

Implementing the tests

Pick an empty custom task text field (in MS-Project 2016, select Project, Custom Fields), rename it something like “Auto RAG” and click on Formula (see figure 1).

Figure 1: MS-Project custom text formula dialogue box

 

The MS-Project Switch() function applies a number of tests and performs an action for the first test it comes to that returns a TRUE result. The format is:

Switch(
TestForCompleteCondition, ResultIfTestIsTrue (“C”),
TestForRedCondition, ResultIfTestIsTrue (“R”),
TestForAmberCondition, ResultIfTestIsTrue (“A”),
TestForGreenCondition, ResultIfTestIsTrue (“G”),
TestThatAlwaysReturnsTrue, ResultIfTestIsTrue (ErrorMessage),
)

The TestThatAlwaysReturnsTrue at the end “catches” the condition where none of the previous tests return a True result. Seeing the “ERROR!” result should prompt you to check your tests (or add some more conditions to catch other scenarios).

In “coded” format, such a series of tests would look like this:

Switch(
      ([%Complete] = 100), “C”,
      ([Baseline Finish] , Now()), “R”,
      ([Finish] > [Baseline Finish]), “A”,
      ([Finish] <= [Baseline Finish]), “G”,
      True, “ERROR!”
 )

I have formatted this to make it more readable. Be aware that MS-Project will strip out the spaces and returns, so the formula will look a lot less readable if you ever have to come back to edit it.

Put this in the “formula box” (see figure 2).

Entering the Auto RAG formula in the custom text field formula box
Figure 2: Entering the Auto RAG formula in an MS-Project® custom text field formula box

Once you have a text RAG value, you will probably want to display that as a graphical indicator to make reds and ambers easier to pick out in a long plan. This is done from the same Customise Fields dialogue box as before (figure 1), but this time using the Graphical Indicators option, which gets you here:

Specifying graphical indicators for RAG status in an MS-Project® custom text dialogue box
Figure 3: Specifying graphical indicators for RAG status in an MS-Project® custom text dialogue box

The approach is to test whether the value in the field “equals” each of the RAG status values and to assign an appropriate graphical symbol to each.

The What(’s in it for you)

Congratulations! You have now introduced some schedule automation and given MS-Project the ability to tell you what the RAG status of an item should be, based on a rigid interpretation of whatever rules you have given it, ready to have overlaid upon it any other factors the PM knows about. What approaches do you use to calculate RAG status in MS-Project?

This approach comes to you from my experience of getting it wrong and coming up with a better way. 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?

Copyright © Ken Burrell, Pragmatic PMO Ltd 2017


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

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, 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/

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.

Approach

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.

Result

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.

 

Project data in, portfolio insight out

How do you give senior management a “helicopter view” of all the change that is going on in an organisation, so that they can make informed decisions on how to spend their change budget? Here’s how I tackled it…

Data in insight out

What I found…

I came to a new Portfolio Management Office (PfMO) in which status was being reported in various formats. Reports were consolidated but this was based on low-value-add copying and pasting of information into lengthy reports. Pretty much every project proposal was being approved, with no view of the organisation’s capacity to implement them. This resulted in projects getting in each other’s way, competing for resources and overloading Subject Matter Experts (SMEs*).

The Goal

The COO tasked me with developing an integrated view of the portfolio to enable sensible prioritisation decisions to be made, and with developing a resource view looking up to one year ahead.

There was neither the appetite nor the budget to invest in a software tool, so the solution needed to be home-grown.

What I did

Standardise and integrate

I ensured that project data was being collected in a standardised way to enable automated collation into a portfolio view by developing an integrated “Project Status Workbook”. This is effectively a multi-page spreadsheet combining RAG Status reports, Risk, Issue, Dependency and Change Registers into a single recording and reporting document for each project, with a stakeholder dashboard showing key pieces of information in a simple graphical format.

Then I developed a consolidating spreadsheet, using VBA macros to collate project data in various categories.

Analyse and interpret

I analysed the data to provide management information to the Portfolio Board (e.g. % of Projects Red/Amber/Green; % of projects Delivered on Time/to Budget; Portfolio focus on Run/Grow the Business, etc.).

I charted trends to provide insight into project management effectiveness.

I introduced simple Demand Management, using a simple spreadsheet to compare resource demand (from active and proposed projects, on a FTEs per month basis) with planned supply in various categories (PMs, BAs, Developers, BAU SMEs, etc.) to enable the Portfolio Board (C-Level executives) to assess the viability of the planned project portfolio within the prevailing (tight!) resource constraints.

Whenever a new project request was received, I added in the forecast resource demand to show the effect on the “deliverability” of the portfolio as a whole.

I used a derivative of this approach when carrying out the annual financial planning exercise. This started with the annual portfolio budget figure, and showed how the projects (prioritised by the portfolio board using a weighted scoring approach covering factors such as complexity, benefits, risk, strategic alignment, etc.) chip away at the portfolio budget until it runs out at “The Cut”, beyond which lower priority projects would need to be put on hold, delayed, rejected or stopped.

I overlaid the resource view onto the financial view to see how the scheduling of the chosen projects affected the resource demand.

…and the result?

The Project Portfolio Board received a concise, consistent and informative view of Portfolio Status, and were able to consider project proposals against the context of the organisation’s capacity to implement them. Projects were better prioritised and scheduled so that difficulties related to resource bottlenecks were reduced.

So that’s my approach to generating portfolio insights, learned through the experience of getting it wrong and coming up with a better way. It this approach useful to you? 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?


*I use the term SMEs to mean people from the operational business who are subject matter experts in the processes or business areas that are to be changed. They do not necessarily contribute to the change itself or form part of the core project team, but their contribution is invaluable in shaping the changes that are made and how they are to be made.

How to create a streamlined project management methodology

How do you develop a project management methodology that isn’t too heavy or too light, that respects the experience of project managers, and that is accessible? Here’s how I approached it…

How to create a streamlined PM methodology

I was made the PMO Manager of a department of about 20 project managers. Although I didn’t have responsibility for the project managers or the portfolio of projects, I did have responsibility for the methodology they were working to and for the reporting of project information to the project portfolio board (comprising most of the organisation’s senior management).

Review the “As Is” methodology

At the time I was appointed, I assumed responsibility for managing the methodology – this was a comprehensive rulebook, spanning over 125 pages and including over 30 document templates, that was updated roughly quarterly. This rulebook was generally either blindly implemented in full (by the less experienced project managers, potentially impeding project delivery) or cheerfully ignored (by the more experienced project managers, potentially increasing the risk to delivery).

Seeing that this was not an ideal situation, I reviewed the methodology to identify the key control points and templates that delivered the most value, either for the project managers or for project and portfolio stakeholders.

I involved the project managers, who helped me to identify where things were inefficient and could be improved. I asked some of them to help me develop and test-drive new improved multi-purpose templates and more efficient ways of reporting, that removed the old cut-and-paste consolidation.

Develop the “To Be” methodology in consultation with stakeholders

To improve ease of use (and uptake) I represented the entire project management approach as a process flow diagram or “framework” on a single A4 page, with hyperlinks to the latest templates for each section. I identified the steps and documents that would always be required for the type of projects generally undertaken, and made these items part of what I called the mandatory “backbone” of the new approach. Everything else I made either conditionally mandatory (depending on project dimensions such as size, risk, complexity, etc.) or fully optional elements. These optional elements could be selected from the “toolkit” or not, as the result of a discussion held early on in the project between the project manager and their line manager (who typically was responsible for the project management of a section of the project portfolio). I designed a document to record the choices made and the reasons why any optional element was though not to be relevant or useful to the project; this empowered the project manager to make choices, but also made the project manager accountable for those choices.

Implement the solution and train users

I trained the project managers in the new approach and published it on the organisation’s intranet. I encouraged project managers not to print paper copies of the guidance or templates or to re-use old completed documents, instead pointing them to the intranet site so that they would always be using the latest versions of the PM approach and the templates.

Review performance, and tune the methodology

I carried out regular post-implementation surveys and facilitated review meetings, and integrated the lessons learned into the framework. I abandoned quarterly releases of a weighty manual, instead making changes to templates and guidelines as often as these were appropriate (and informing stakeholders of the changes and why they had been made).

The new framework gave increased flexibility to project managers whilst ensuring their accountability for their project management approach. The project management community bought in to the framework as they had been closely involved in its development.

So that’s my approach to refreshing a project management methodology, learned through experience. It this approach useful to you? 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 detail stuff, why not talk to us about taking care of it all for you?

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.