The PMO Programme

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 http://www.youtube.com/watch?v=YdRbVC8U13I.) 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