Microsoft Project – Digging into Calculated Fields and Formulas

April 13, 2012 Leave a comment

Custom fields are an incredibly powerful way of extending Microsoft Project with lists, flags and values to suit your particular needs. In addition to customising fields with static data (lists and values), you can create calculated fields which use a formula to set the field’s value based on values in other fields.

Although I occasionally use calculated fields I have to admit that when I do it’s a case of trial and error rather than anything like a full understanding of this feature.  I was suitably embarrassed earlier this week when a colleague asked me to explain how the formulas in calculated fields work, so decided to find out more.

Both of my usual go-to references (F1 and the Inside Out book) do little more than tell me I can use formulas and give a few examples and the syntax of some of the functions. After a little more digging, I came across a comment on MSDN stating that “Microsoft Project uses the same Jet Expression service for formulas that Microsoft Access uses”. Now I’m getting somewhere…

Below are a couple of references that may help you find out more, a guide to the syntax of formula expressions and a guide to creating formula expressions. Although these guides are intended for Access users, I think they deal with formulas and expressions in a more meaningful way than any of the readily available Microsoft Project resources.


The trouble with Stage Gates…

September 7, 2011 3 comments

In common with many programmes, we use a Stage Gate process to control transition between the major phases of our programme. Stage gates are, in principle, very good things. They give the programme’s management, sponsors and stakeholders a chance to take stock of where we are and make an informed decision on whether to proceed with the programme as planned…. The trouble is that they rarely work like that, do they?

Here are some of the reasons we’re struggling with Stage Gates:

  • There is no time built into our delivery plan to operate stage gates. If it was then the stage gates would sit fair and square on our programme’s critical path.
    (Let’s say we have four stage gates, each with a five day review/approval cycle. Each stage gate relies upon the delivery and approval of a defined set of deliverables and the achievement of a well defined set of criteria. If we run the stage gate properly and wait for the deliverables/criteria before running the stage gate that’s twenty days to add to our schedule and the programme goes live a full calendar month late. That’s never going to fly, is it?)
  • A direct result of the above is that the critical activities that really inform the stage gate all run up to the wire as far as the stage gate process is concerned. If the stage gate is due this Friday, you can guarantee that the techies will have planned to work way into Friday night (or, if they’re up against it, across the weekend) to have the environments set up for our next stage start on Monday morning.
  • We have attached “Go/No-Go” decisions to our stage gates. This prompts the question – what happens if the decision is “No-Go”? Do we all pack up our laptops, iPads, flipcharts and stress balls and go home? No-one seems to know.
  • Last, and by no means least, there is an assumption that each stage gate will be passed. As we’re not using a waterfall delivery method many of our project teams have already moved into the next stage, assuming that they are doing so at little or no risk.

So where does that leave us? With a process that really doesn’t seem to work, but is one of the few major controls that our stakeholders cling to. Without Stage Gates, our senior managers would feel like they’re driving a juggernaut down a steep hill with no brakes, so we have to do something to make them work more efficiently.

Because this is a technology-enabled business change programme we have, to date, pinned Stage Gates to the design/develop/test/implement stages of our technical delivery. We’ve done this because these are easily identifiable stages and (surprise, surprise) the technology is defining our programme plan’s critical path so it seems sensible to make these the ‘go/no-go’ points in our programme. But it’s this very decision that’s causing the Stage Gate process to creak at the seams.

There are a couple of things I think we can do to try to improve this situation:

  • First, let’s Stage Gate the business change phases of the programme rather than the technology stages. This will allow us to re-focus attention on our core delivery and, because these are ‘softer’ stages, we can run a more thorough and all-encompassing Stage Gates without holding the whole programme up.
  • Second, let’s face the fact that there are no ‘no-go’ decisions, but there are likely to be ‘carry on with an adjusted scope/timescale/budget/organisation/risk-profile’ decisions., and we should be doing everything we can to make these decisions as well informed as possible.

Taking these steps will, I think, improve how we execute and use our Stage Gates and provide better value from the PMO to our stakeholders. Whether it makes the process any more palatable to the programme team is another matter entirely…

Categories: Planning, Stakeholders

Planning, Part 2: Product Based Planning with Microsoft Project

May 4, 2011 4 comments

In previous posts I have explained our desire to make The PMO Programme as data driven as possible. This supports one of our declared quality management principles, having a ‘factual approach to decision making’, along with cementing the PMO’s role as the custodian of the programme’s “single version of the truth”.

Alongside operating with a fairly basic desktop toolset (Microsoft Project and Office), we’re also working within an organization that mandates PRINCE2 as its project management method.

One of the three techniques described by PRINCE2, product-based planning, will form the basis of the next stage, and all on-going iterations, of our programme planning process.

The technique described here will help us tackle one of the most common issues of many PRINCE2 based projects – which start with good intentions of delivering through product-based planning but end up chasing their own Gantt chart while the product breakdown lies gathering dust on a shelf.

I won’t try to explain product-based planning here – there are plenty of resources already available. (For a quick introduction, I can recommend Dave Litten’s introductory video at What I will do is show how we can make the product-based planning process data-driven using Microsoft Project.

Why use Microsoft Project?

We have limited project management technology available to our PMO, but are determined to make every aspect of our programme as data-driven as possible. This approach both promotes the PMO as the custodian of programme data and reduces rework, re-keying and the promulgation of multiple data sources. I have already mandated that we will use Microsoft Project as the primary database for our project (see post on storing organization structure for a previous example of this approach) and we’ll now do the same for our programme’s product-based planning data. There are many advantages to this approach, including:

  • Further confirmation of the PMO and the programme plan as the primary source of information on our programme, avoiding uncontrolled ‘islands of information’ from popping up across the programme
  • Firmly embedding product-based planning in our overall programme planning and control process. (All too often a project sets out with good intentions and devises a product-based plan only to find that, once in place, the project schedule takes over and the benefits of product-based planning become diluted)
  • Offering a basis for data-driven production of key PRINCE2 programme documents: the Product Breakdown Structure and the Product Flow Diagram, enabling these to be easily updated and reviewed as a key part of the planning and control process

Developing the Product Breakdown Structure

I won’t go into this in detail here, but in summary, this is the process followed to gather the raw data to develop our product breakdown structure:

Our Programme Initiation Document contained a first cut product breakdown structure and (as this is a ‘dynamic’ part of that document that it’s incumbent upon the PMO to update) this will be the basis for this exercise. Unfortunately, the original product breakdown structure consists of a diagram drawn in PowerPoint, so has no ‘data value’, which is something we will correct now. Alongside this we will use the current list of products identified by project leads in our recent high level inventory of the programme. This information is fed into a workshop attended by the programme manager and workstream leads to whiteboard the revised structure in light of their experience of the programme to date. The sanity check for this workshop, used to ensure the debate stays within the remit of the programme, is the ‘project definition’ section of the programme initiation document. The single question asked of the group is this: ‘Does this product breakdown structure represent the totality of the products required to deliver these outcomes and objectives?’

As a result of this workshop we have a draft, whiteboarded product breakdown structure which provides the raw data we need to build our single, consistent and manageable database of product information.

A note on product ‘levels’: Because we’re developing the programme plan here (essentially the ‘level 2’ plan in our planning hierarchy), we’re only interested in the deliverables that affect our ability to plan, monitor and control the programme. If individual teams or projects wish to decompose these products down to a lower level then that’s fine, but that’s something for them to manage in the detail of their individual work plans.

Recording Products in Microsoft Project

It is relatively easy to customise Microsoft Project to store the basic information needed to develop both our Product Breakdown Structure and the Product Flow Diagram. We’ll use a similar technique to that used for storing organization structure – customising columns and recording hierarchy data – but this time we’ll use the Task data structure.

The logic to using Task data is this: Think about a milestone in Microsoft Project – it’s an item that appears on our plan to show key points or achievements, right? Isn’t that just what a product is – the culmination of one or more activities? Ok, so we’ll customise milestones and call them ‘products’. And what’s a milestone in Microsoft Project? It’s a zero-duration task with some special flags set – so we’ll use exactly the same principle to store our product data.

Let’s start with the default Task Sheet view:

The only fields of interest to us are the Task Name, which will contain the product’s name and the Duration, which we’ll set to zero, so I select the other columns and hide them.

In addition to its name, the basic information I need to record a product is:

  • A flag to show it’s a product (to differentiate it from all the task data that will live alongside the product data in our plan)
  • Is it a specialist product or a management product?
  • Is it a simple product, an intermediate product (an integration product or a collective grouping), or an external product?
  • What’s the product’s parent product? (remember that a product breakdown structure is a simple hierarchy, so each product has one and only one parent product apart from the ‘final product’ which has no parent.)

A note on intermediate products: Although the PRINCE2 manual allows for ‘collective grouping’ products to allow lightly related products to be grouped (e.g. ‘quality inspection products’), I tend to avoid these wherever possible as they have a tendency to confuse the product breakdown structure. Most collective grouping products can be changed into intermediate products with a little thought – in the example above, for instance, I would change the ‘quality inspection products’ group into an intermediate product called ‘quality inspection checklist’.

For the ‘product’ flag, I’ll customise the Text record’s Flag1 field (each task record has twenty Yes/No Flag fields named from Flag1 to Flag20):

  • Show Flag1 and customise (using ‘Custom Fields’):
    • Rename Flag1 ‘Product’, like so:

    • Note: the default value for a Flag field is ‘No’, which means we’ll need to set this to ‘Yes’ for each of our products (of which there will hopefully be far fewer than Tasks that aren’t products…)

For the remaining information I’m going to customise the Task data’s Text fields (each Task record has thirty customisable Text fields named from Text1 to Text30 that we can use) as follows:

  • Show Text1 and customise (using ‘Custom Fields’):
    • Rename Text1 ‘Specialist/Management’ (or ‘Product Type’ if you’re sure that’s clear enough)

    • Set up a drop-down list for the field using the ‘Lookup’ button in the Custom attributes area of the dialog. Add the values ‘Specialist’ and ‘Management’. To default the value to ‘Specialist’ (assuming the majority of products will be of this type) select ‘Specialist in the list, check ‘Use a value from the table as the default entry for the field’ and click the ‘Default’ button.

  • Show Text2 and customise as follows:
    • Rename Text2 ‘Product Level’
    • Set up a drop-down list for the field using the ‘Lookup’ button in the Custom attributes area of the dialog. Add the values ‘Simple’, ‘External’, ‘Integration’ and ‘Collective. Set the default value to ‘Simple’.
  • Show Text3 and customise as follows:
    • Rename Text3 ‘Parent Product’
    • Note: as this field will take its value from the Name field of other rows in this view, it would be great to have a drop-down list of those names. As far as I’m aware, however, there isn’t a simple way of achieving this so we’ll have to rely on copy/paste to complete this field for each product.

That’s it. We can now record that each product is indeed a product (to differentiate it from a normal task), show if it’s a specialist product or a management product, whether it’s a simple product or an intermediate product and what its parent product is.

Here’s a completed example using the ‘organising a conference’ products from the PRINCE2 manual:

Where does that leave us?

Now that the basic data structures are in place there are a number of things we can do:

  1. Produce the Product Flow Diagram by adding dependencies between the products and viewing in Microsoft Project’s Network Diagram view (which can easily be customised to use the same shapes and notation as recommended by the PRINCE2 manual)
  2. Begin to plan around the Product Flow Diagram by adding tasks that contribute to the delivery of our products
  3. Develop custom Tables and Views (filtered on ‘Product=’Yes”) in Microsoft Project to simplify the maintenance of our product database.
  4. Use the techniques described in a previous post to generate our Product Breakdown Structure diagram in Visio (and re-generate on-demand after any changes with virtually no effort):

In conclusion

Although extending Microsoft Project beyond standard task/resource data may be quite a paradigm shift for some, it is – as I hope I’ve shown above – relatively straightforward and in no way compromises either the tool or our data. Quite the opposite, in fact, as we’re now well on our way towards a consistent and coherent single source of key data for our programme.

Next Steps:

  • Developing full Product Descriptions and integrating with the core data already stored
  • Producing product status reports and product-based programme roadmaps

Getting to grips with the programme organization…

April 27, 2011 Leave a comment

…producing a programme organization chart from Microsoft Project data

This is a big programme with a lot of new faces and nobody’s quite sure who’s who. People seem to join and leave on a regular basis, so maintaining a current organization chart is becoming quite a headache.

Today we’ll look at how we can:

  • Make the PMO’s Microsoft Project resource pool the definitive source of data on people and project structure; and
  • Take the strain out of updating the Organization Chart by getting Visio to draw it for us.

In summary, what we’re doing is going from this:

To this, without drawing a single shape or line in Visio:

Apologies in advance that this is a rather longer and more technical post than usual (I’ll come back and edit into more digestible chunks when I get time), but it demonstrates two key areas that The PMO Programme is championing:

  1. Ensuring that the programme is data-driven wherever possible and that decisions are supported by reliable facts derived from a single, consistent and reliable source of data
  2. Maximising the use and usefulness of available tools (and, in doing so, beginning to cement the PMO’s role as custodian of programme data)

Before we start: make Microsoft Project the default source of programme data

Note 1: for anyone unfamiliar with The PMO Programme, we are implementing a PMO for a major business change programme, but – for various reasons – we don’t have the benefit of corporate or ‘heavyweight’ tool support, so all of our solutions are based on the tools at hand – primarily Microsoft Project and the rest of the Office suite.

Note 2: this post assumes some basic familiarity with Microsoft Project – at least enough to find the Resource Sheet and have a reasonable grasp of Project’s menus and options

Note 3: this post is written using Microsoft Project 2010 Professional and Microsoft Visio 2010 Professional. Although I haven’t tested it, what I describe below is a technique I’ve used for years and, to the best of my knowledge, is supported in Project/Visio at least back to version 2003, if not before.

I’ll start with a confession. I love Microsoft Project – I say that without any embarrassment whatsoever. If you use Microsoft Project properly (which means you have to go to the trouble of understanding how it works) it will be your single truest friend throughout your project management endeavours. My default position, therefore, is that if I need to store data on our programme then I’ll try to store it in Microsoft Project first and will put it elsewhere only when absolutely necessary.

In my experience, most project managers use the Microsoft Project ‘Resource Sheet’ to record:

  • resource names (usually, but certainly not always);
  • availability/calendar/working patterns (occasionally), and
  • resource cost information (rarely).

In this post I’ll show you how a small change can increase the power and usefulness of the resource sheet.

Step 1: Record the programme’s hierarchy in Microsoft Project

By making a very simple tweak to our Resource Sheet, we can both make it the ‘single version of the truth’ for our programme’s resources and remove one of the most time consuming admin tasks the PMO faces – keeping the programme’s organization chart up to date.

We’ll start with the default, empty resource sheet, which is not a terribly inspiring sight:

I’m not interested in most of the default fields displayed (which are from my default installation of Project 2010 Professional – yours may differ slightly, but the principles are the same), so I’ll select the Type column (which defaults to ‘Work’ anyway, which is fine as I’m only going to enter people details right now) by clicking its header, right click and select ‘Hide Column’ from the context menu.

I then do the same for the Indicators, Material, Max. Units, Std. Rate, Ovt.Rate, Cost/Use, Accrue At, Base Calendar and Code columns.

Although I’ll use many of these fields later (to enter resource cost and availability details), I don’t need to see them for the task in hand and hiding them leaves me with a much simpler view, as shown:

So what am I left with? Resource Name and Initials are self-explanatory (note that Project will try to help by populating the Initials field with the first – and only the first initial of any name entered – my advice is always to ensure that you change this to recognisable and unique initials to avoid any confusion later).

I’ve left the Group field visible as this is a standard way of showing which group, or in our case workstream the resource belongs to.

Because I want to generate the programme’s organization chart from the data held in Microsoft Project, I need to add some more data to describe the organisational relationship between my resources. This is done with a simple person/manager relationship, as shown in the example below:


Person Manager
Bruce Albert
Catherine Albert
Delia Bruce
Edward Bruce

It’s simply a case of saying in the data that Bruce is Delia’s boss and Albert is Bruce’s boss, and Albert doesn’t have a boss, so he must be the big cheese at the top of the hierarchy.

Some points to remember are:

  • This is data driven, so the Person/Manager data has to match. If I said in the above example that Bruce’s boss was albert or Allbert then the structure wouldn’t work, because there’s no Person called albert or Allbert for Bruce to report to.
  • Anyone without a manager will automatically be at the top of the hierarchy – so if you leave Bruce’s Manager blank, Bruce will become a big cheese in a hierarchy of his own.
  • This is a simple hierarchy – a Person can only have one Manager. For programme purposes, this means:
    • Don’t try to include the ‘business as usual’ manager for someone who’s been seconded to a project and also has a project manager
    • Use it to show line reports only – there are other ways to show temporary cross-functional teams which we’ll cover in another post

To implement this structure I already have my ‘Person’ placeholder in the form of the Resource Sheet’s ‘Resource Name’ field, but I need somewhere to store the manager’s name. To do this I’ll use one of the thirty text fields available with each resource record in the Project data structure. I can customise a text field so it’s always available to store manager names as follows:

  1. On the Resource Sheet view, I select Add New Column, scroll down the list of available Resource fields and select Text1, the first unused text field. This shows the Text1 column on my Resource Sheet:

2. I right click the Text1 column header and choose Custom Fields from the context menu:

3. Text1 is already selected in the Field list, so I click the Rename button which shows the Rename Field dialog, which I use to rename Text1 to Manager. Once this is done, the Manager field will always be available in every resource view and table, shown as Manager (Text1). If I had simply renamed to column in my Resource Sheet this would only apply to this view – Text1 would still be Text1 in every other view, running the risk that the data in it might not be recognised as manager names.

Now that’s done, the Text1 column now appears in my Resource Sheet as Manager:

I can now populate the Resource Sheet with all the programme’s members and their managers, remembering the data integrity guidelines noted above. (As every manager also has to be a resource, I like to copy and paste their name from the Resource Name field to the Manager field to avoid any typos.)

I now have a fully populated resource sheet, complete with Resource Names, unique Initials, Workstreams and Managers, like so:

In addition to using this data within Microsoft Project, I can also use it as input to a very powerful feature in Microsoft Visio – the Organization Chart Wizard, which will automatically draw the chart for me based on the data provided.

Step 2: Export the data to an intermediate Excel file

Unfortunately, the Visio wizard can’t access the data directly from Project, so an intermediate step is required to export the Project data to Excel, which Visio can access. To do this, I save the Project file as an Excel File with File/Save As and change the ‘Save as type:’ field to ‘Excel Workbook’. This launches the Project Export Wizard. Follow these steps to complete the wizard:

  1. On the ‘Data’ Dialog, choose ‘Selected Data’ as the format of data you want to export. This allows us to choose the specific fields required by Visio.

2. On the ‘Map’ dialog, select ‘New map’. This allows us to create a new data map that we can save and use whenever we need to update the chart.

3. On the ‘Map Options’ dialog, select ‘Resources’ as the type of data and ensure ‘Export includes headers’ is checked:

4. Now it’s time to choose which of the Resource fields from Project to export to Excel. Click on “(Click here to map a field)”, scroll down the list of available fields and select Name. This creates a default Excel column name and data type for the exported field.

5. Do the same on the following rows for the Group and Manager fields. The completed dialog should look like this:

6. Click ‘Next’ . Save the export map on the next dialog – I called mine ‘Resource Export for Excel’ – which will allow you to run the export more quickly in future.

7. Click ‘Finish’ and Project will create a new Excel workbook containing the Name, Group and Manager fields.

Step 3: Import the data to Visio

  1. Open Vision and create a new diagram using the Organization Chart template. This creates a blank diagram with the organization shape template but, more importantly, makes the Import Organization Data wizard available. In Visio 2010 this can be found in the Org Chart tab of the ribbon. In earlier versions there it can be found under the Org Chart menu item.
  2. The defaults are fine for the first stages of the wizard – the following options should be selected:
    1. ‘I want to create my organization chart from: Information that’s already stored in a file or database’
    2. ‘A text, Org Plus (*.txt), or Excel file’
  3. The next step allows you to locate the Excel file created in step 7 above and specify the language used.
  4. The next screen identifies the Name/Reports To fields that make our data structure work. If you’ve followed the steps so far, this should automatically populate the correct fields as follows:

Leave the ‘First name’ field blank, as the data exported from Project has both first and last names combined in the same field.

5. The next step allows you to choose any other information to display in the diagram. This defaults to the only other field we exported, the name of the Group (or workstream, or project team) that the person belongs to. (This is fine for what I want at the moment, but I may adapt this later to include the person’s role title, which I’d have to store in Project and export to Excel following the steps described above.)

6. The next step of the wizard allows any of the data fields to be stored as shape data in Visio. As we’re simply using Visio as a drawing tool, not a database, we can skip this step.

7. Visio now offers to arrange the organization chart automatically across multiple pages. My advice is not to use this, but manually configure how you want the pages split in the next step of the wizard, so select ‘I want to specify how much of my organization to discplay on each page’

8. The next stage allows me to do just that. The wizard analyses the data and shows me who’s top of the tree:

This is fine for what I need just now, so I press ‘Finish’. Visio now imports the data, draws a box for each person and links them based on the hierarchy data. This is the stage at which any data errors will show up – usually because names have been mis-typed or someone has been given a manager who can’t possibly be their manager. If this happens, find out where the problem is in the source data – in Project, not the intermediary Excel file, re-run the Project export and re-run the Visio import. It’s worth doing this properly, and not just fudging the Excel file, as it will both confirm the priority of Project as the prime data source and will save time whenever the chart needs to be updated.

9. So, assuming your data is correct, Visio should have drawn your organization chart, something like this:


This may look like an onerous process but, believe me, if you spend a couple of hours getting this right the first time, it will save a whole lot of time across the duration of your programme. The export/input steps are stored in the Project and Visio files so next time the process is run it’s just a question of clicking through the two wizards so, no matter how large or complex your structure, the whole thing can be updated in just a couple of minutes.

Next Steps

This is great as a stand-alone, time saving process.

One added benefit comes from the fact that we now have (in our Microsoft Project plan) a list of all the people on the programme and who they report to. We will extract this data on a regular basis and distribute it (in user-friendly Excel format) to all the project and team leaders as a basis for ensuring they have a simple and accessible means to update the data whenever it changes.

Another benefit is that we can customise the data shown in the diagram. We can export, for example, overallocations or cost information or availability to show in a graphical way (which many stakeholders find more accessible than charts and tables) where any pinch-points or opportunities lie in our programme organization.

Programme Planning: Some home truths before we set out…

April 19, 2011 1 comment

Those of you following the PMO Programme will know we’re still in the early days of bringing structure and control to our programme. Not untypically, the programme has been up and running for a couple of months already and we’re only just getting the PMO together, so some rapid catch-up and positioning is required. We’re about to start tackling one of the key tools for managing our programme – the programme plan. But before we get started, let’s go right back to basics and clarify some basic aspects of the programme plan.

This post covers:

  • Plan or schedule: setting the terminology and mindset
  • Planning levels: how many, what for?
  • The changeable nature of plans and how to manage that change

Plan or Schedule?

Let’s get this one straight first.

A schedule is ‘who, what and when’. A schedule is a Gantt chart. A schedule is a list of activities, resources and dependencies that can be optimised to show the most efficient way to carry out those activities. A Microsoft Project ‘plan’ is a schedule. A schedule is part of a plan, but a plan it is not. End, as the youth of today would say, of.

A plan is a description of how we’re going to get from where we are to where we want to be. Yes, it needs a schedule to make sure things get done in a sensible order, but it’s much more than that. A plan understands the organisation it’s working in. A plan understands the assumptions made and the risk appetite of the business. A plan not only includes the who, what and when, but also shows:

  • Tolerances, and how we’re doing against them
  • Assumptions, and which are holding true
  • Risks, and what we’re prepared to do about them
  • Deliverables (or products if you will), and what they are
  • Resources, and what skills they have
  • Costs, and how we’re doing against forecasts
  • All the ‘necessary bureaucracy’ stuff – checkpoints, quality gates etc.
  • Dependencies between projects and between the programme and the outside world

A plan is not a single document – if it was, it would be time consuming and unwieldy to produce, difficult to comprehend and almost impossible to maintain. A plan should be seen as a collection of documents (which may consist of schedules, RAID logs, product descriptions etc.) An effective plan is one which ties each of these components together in a consistent and coherent manner, allowing views of the plan to be taken that meet the needs of varying audiences but stem from the same, single source of programme data.

Planning Levels

When people talk plans, you’ll hear them bandying about terms like ‘level 1’, detailed plans, roadmap, ‘level 3’, plan on a page, programme plan, workstream plan – the number of different type and level of plans is apparently endless.

For the purposes of The PMO Programme, there will be three levels of planning, each aimed at specific types of audience and each with a distinct job to do. These levels are:

  • Level 1: Plan on a page
  • Level 2: Major areas of activity and key deliverables
  • Level 3: Workstream or project plan

I know some plans have more levels than this (many in the world of Agile development routinely produce five level plans to cover individual iterations and releases), but remember this is the programme plan. At some stage the programme PMO has to hand control to project managers (who, after all, are the people who actually know what they’re going to do) and if the individual teams on our programme wish to break their Level 3 plans down again then that’s fine by me – as long as they do it in a way which maintains the integrity of their Level 3 plans and their integration across the programme.

Ok, so what are these levels for?  In summary, and using the schedule as a basis for defining the content of the plan :

Plan Level What does the schedule show? Who’s it for? Who produces it?
Level 1 ‘Plan on a page’-          Major deliverables and milestones shown in a way that makes sense to the business sponsors The Senior Responsible Officer (programme sponsor)The Programme BoardThe wider organisation The PMO in conjunction with the Programme Manager
Level 2 –          All major activities and deliverables that contribute to achieving the programme’s objectives.-          All dependencies between (not within) projects and between the programme and external bodies. The programme management teamThe programme team The PMO in conjunction with the project/workstream managers and the Programme Manager
Level 3 –          All deliverables required to complete the programme Workstream/project managersTeam members The project/Workstream manager in conjunction with the PMO

These three levels enable ownership and handoff to be clearly identified:

  • The Level 1 plan is what the programme manager will carry around at all times, to describe the project to stakeholders
  • The Level 2 plan allows the PMO to ensure the totality of the programme has been considered and all dependencies have been fully articulated and are being managed
  • The Level 3 plan allows the workstream/project managers to manage delivery and report progress/exceptions

Another key thing to remember is that these are not separate plans. They are views of the same plan and there may even be more than one view of each level depending on the precise target audience. Because we’ve declared one of our driving quality principles as a ‘factual approach to decision making’ it is incumbent upon the PMO to ensure that the information presented in each plan is consistent, coherent and comes from a single, undisputed set of facts – in other words there is only one version of the truth, and it’s the truth set out in our programme plan.

The plan’s a best guess – embrace the change.

My programme manager wants to see the whole of our 18-month programme planned in detail. Only then can she be truly in control. My programme manager requires some education.

She needs to realise that a plan is a best guess at what needs to happen and how it needs to be done. Even with a highly experienced team and reliable metrics, it’s still an educated guess at best. A project is a ‘unique endeavour’ after all, and a large programme such as ours is a number of unique endeavours with a complex set of interdependencies, all being carried out in an organisation that’s unused to this degree of change. Chances of getting it right first time are slim at best – and we need to recognise this in our approach to planning. To satisfy my programme manager’s need for detail and assure her that I’m in control of the plan, I need a way of:

  • using the Level 1 and Level 2 plans to make sure ‘the big picture’ is maintained
  • showing her the detail we can be most sure about
  • maintaining this level of detail without descending into ‘planning hell’

In outline, what I propose we do is this:,(and remember we’re not starting with a clean sheet here – some of our projects are already up and running):

Set an initial baseline:

  1. Develop the Level 1 plan to show the major deliverables and milestones that make sense to the business sponsors and stakeholders
  2. Identify the major deliverables that contribute (or ‘roll up’) to the Level 1 plan, based on whether or not those deliverables actively enable the programme’s objectives. (Current plans and the project inventory will help with this)
  3. Use the deliverables identified in step 2 to develop an initial Level 2 plan
  4. Use the Level 2 plan to develop/confirm the Level 3 plans for the next three months only
  5. Use the Level 3 plans to do some ‘bottom up’ cross checks against the Level 2 and Level 1 plans, which may then need to be amended

Implement a regular planning cycle:

  1. Regular (in our case weekly) updates to Level 3 plans are used to monitor progress and identify exceptions
  2. Changes and exceptions to Level 3 plans are used to change (or invoke a change request against) other Level 3 plans and, if necessary, the Level 2 plan
  3. Monthly planning sessions are held at which:
    1. Successes, exceptions and lessons learned from the last month are discussed
    2. The Level 3 plans are developed in detail for another month, to maintain a rolling three-month detailed plan
    3. Bottom up changes to Level 2 and Level 1 can be identified and discussed with the Programme Manager
    4. Level 2 and Level 1 plans can be updated as required (subject, of course, to tolerances and change control as require)

In short, we are:

  • Taking a whole-programme view at Level 1 and Level 2
  • Updating Level 3 plans on a weekly basis and using these to report progress and deal with exceptions against the plan at all lelvels
  • Maintaining a rolling three month Level 3 plan through monthly planning sessions – learning as we go and not trying to plan all the detail up front

The above covers some of the basics that will underpin our programme planning. We’ve not yet  covered areas like how the plan is documented and presented, what tools we’ll use, how plan change control works, dealing with ‘top down’ changes etc. but I think that’s enough for now – we’ll start to tackle these and many other issues once we’re up and running.

Categories: Level 1 Plan, Planning

Quality Planning – Part 1 – Making Quality Visible

April 14, 2011 1 comment

In her excellent blog ‘A Girl’s Guide to Project Management’, Elizabeth Harrin recently commented that she has successfully delivered all her projects over the last year without a single quality plan. Looking at the comments that this post provoked (mine included), I suspect Elizabeth has been in the happy, happy situation of having well-balanced, motivated teams working within reasonable, well-adjusted organisations. I agree with her that quality plans should be unnecessary, but the truth is – especially in environments such as the one The Programme PMO is operating within – we cannot assume everyone is pulling in the same direction to deliver the same outcomes, so some formal statement of our approach to quality is required.

I’m not going to go into the minutiae of quality management here – what I need is a practical and achievable set of actions that will help me both establish the type of quality outcome expected and the actions needed to get us there. (Note: our programme is operating in the absence of any corporate quality mandate or initiatives, so we’re starting from scratch.)

What we don’t need:

  • A 142 page Quality Plan document that delves into the whys and wherefores of quality management, mandates a complicated and resource-intensive quality assurance plan and ultimately achieves nothing other than wasting the two months the author spent writing it (this, I suspect, is the type of quality plan Elizabeth is referring to in her post)

What we do need:

  • Something that clearly defines what quality means to the programme
  • Something that everyone on the programme can easily access and understand
  • Something that provides clear actions and responsibilities to ensure we build the right type and level of quality into everything we do

As ever, my first step is to see what OGC’s P3O manual says about quality management. Hmmm… Astonishingly (and IMHO unforgivably) P3O says almost nothing on quality, apart from referring out to OGC’s Gateway Review Process, which from previous experience is somewhere I have no intention of visiting.

Let’s get back to basics then, and define what we mean by ‘quality’.

Quality Management Principles

The ISO defines eight principles of quality management. Although these principles are defined in terms of the ‘organization’, my experience is that they apply equally well if we consider the programme to be the organization in question. The principles are:

  1. Customer focus
  2. Leadership
  3. Involvement of people
  4. Process approach
  5. System approach to management
  6. Continual improvement
  7. Factual approach to decision making
  8. Mutually beneficial supplier relationships

Regardless of your place in the quality debate, there aren’t many people who would (or would be able to) argue that adopting these principles is anything other than A Good Thing.

First thing to do then is to ‘borrow’ the ISO definitions of these principles and adapt them for our programme. This took me about half an hour and has resulted in an entirely unoriginal but, I think, accessible and useful, document that I’ve rather grandly called the ‘Programme Quality Charter’.

Now, this may seem a bit Mickey Mouse for anyone embroiled in the dingy depths or floating in the blue skies of quality management, but for a programme starting with little idea of quality, and at hardly any cost or effort at all, it’s a giant leap forward.

Next steps:

  1. Issue a copy of the Quality Charter to everyone involved in the programme
  2. Begin to identify the actions required to bring this to life
  3. Plan those actions alongside (and fully integrated with) all the other programme activities

Planning the PMO – Using Stakeholders to Define the Blueprint (Part 1)

April 12, 2011 Leave a comment

Having established the PMO ‘vision’ it’s time to focus on planning the PMO to turn that vision into reality.

If we were planning the PMO at the very outset of the programme then I suspect our task would be a whole lot easier. As things are, however, we have a number of projects already in train, the programme manager’s pulling her hair out. This means one thing – we need to get the PMO up and running and we need to do it quickly.

First stop is our old friend the OGC P3O manual. I turn to section 4, ‘How to implement or re-energize a P30’. Lots of blurb about blueprints and business cases and KPIs, hmmm. Hang on – what’s this? Section 4.9 ‘The Temporary P3O Lifecycle’ – this should be just what I need. Not quite. The guide suggests I need to:

  1. Define and establish the temporary Programme Office team
  2. Set up the environment

This is all well and good, but the descriptions of what to do and how to do it are vague to the point of uselessness. I suppose this is understandable given the huge possible range of size/shape/function of temporary PMOs, but doesn’t get me far.

I need a model to define, describe and plan my PMO and it looks like I’ll have to develop this myself. There is, however, a useful definition of stakeholder groups at the start of section 4.9. The guide describes the ‘focused’ set of stakeholders for a temporary PMO as:

  • Upward – programme or project boards
  • Inward – programme or project team members
  • Outward – suppliers, portfolio office, corporate support functions etc.

(Note: From experience the Programme Manager is another key stakeholder who will need to be treated as a separate case with special needs, but for the time being I’ll stick with the P3O suggestions and see if the Programme Manager really does require special treatment…)

I’ll use this to describe the scope and key information flows for my PMO, as follows:

(Note that I have defined the ‘outward’ facing stakeholders as suppliers – those external to the organisation – only. My expectation is that other internal stakeholders who OGC group alongside Suppliers should be able to glean all the information they need via the programme boards. Making this decision now removes a whole raft of ‘special’ stakeholder engagement. The terms of reference for the programme boards will need to reflect this decision, though.)

Now, this may not be a terribly exciting diagram, but it’s got me thinking that perhaps a matrix showing PMO processes and outputs mapped against each stakeholder group’s needs might be a quick, easy and accessible way to define my PMO and provide a shortcut to my PMO blueprint.

Perhaps something like this:

I’ve decided to set expectations early and make this a two-way flow and include not only the stakeholder group’s needs from the PMO, but also what each group needs to provide to the PMO to make the relationship work. Even at this early stage, it’s not just a question of what the PMO can do for you, but what you can do for the PMO…

Next: Using this model to:

  • Establish stakeholder needs and expectations
  • Define stakeholder responsibilities
  • Scope and define the PMO