PMO set-up: Guide to manual project resource management process

Project Resource TemplateI was recently asked for guidance on how to set-up a resource demand / supply management for a PMO.  The case in question was starting with no resource planning tools and wanted to be able to assess what projects could be delivered in parallel with a fixed supply of resource.

Clearly defining the resource requirement and then having a structured approach to measure progress of the recruitment is very important.  Projects are delivered by people.  One of the main reasons projects fail of are delayed is that the resources are not added quickly enough.

So the quicker you define the demand and start recruiting, the better chance of success.

Below is a high level guide to build a simple resource planning process to support project delivery:

  1. Establish the supply / resource pool

You need to capture details of the resources available (supply).  If you are doing this manually you might want to group resources into generic skill sets i.e. project manager, business analysts, tester, etc.

If the resources are in multiple locations, you should add a field to capture location.

On assumption they are all going to be with the organisation for 12 months you can straight line capacity over 12 months.  For example, if you have 10 project managers, you would place 10 FTE against project managers for Jan, Feb, Mar, etc.

This will then provide a high level view of supply on a month on month basis.

  1. Establish demand

Get each project to complete a 12 month demand profile by generic resource (not just straight line).  This will typically show a ramp up to a peak and then a ramp down near the completion.

The template should be the same format as the one used to create the supply baseline.

When you have received the submissions for all of the projects, you should be able to build an aggregated view of demand on a month by month basis.

  1. Compare demand to supply

Take the demand summary by resource type and location and compare against the supply baseline.  This will allow for the quick identification of where demand exceeds supply.  You then can work with the appropriate projects to see if you can smooth demand.

  1. Monthly Refresh

On a monthly basis, get all of the projects to provide updated demand templates based on project progress.  Establish a process to capture changes in the supply baseline (new joiners, leavers, etc).  Then on a monthly basis, compare demand to supply and identify contentions.

  1. Tools

The manual approach makes using Excel a sensible option.  However, for a more automated version you may be able to use MS Project or look to invest in a resource management tool.

To save time you may want to think about buying a template set as opposed to building them yourselves in Excel, like my PMO Template Framework available in the Members Area.

Obviously this is a generic approach.  You will need to consider what is needed in your organisation before making a decision.

Additional information is available in the post, PMO Tools – Resourcing.  This provides an overview the tools required for a Resource Management process.

Project Meeting Terms of Reference

Project Meeting in progressIn the last post, Project Governance Meetings, I covered the 2 important meetings that should be set up.  However, it is important that thought goes into setting up these meetings so that they can achieve the required outcome.

Take a moment to think about the project meetings you have attended or perhaps are still attending.  Do they achieve the required outcomes or, do you and others think that they are a waste of time with minimal contribution from most attendees?  Unfortunately this is the case for many project meetings.

Why Project Meetings Underperform?

There are a number of reasons why a project meeting is not a success.  Examples can include:

  • No clear objectives
  • Attendees who do not have the required information
  • Attendees who do not have the authority to make decisions
  • Strong personalities monopolising the meeting or pushing their own agenda
  • No person leading and steering the conversation
  • Attendees unclear of what is required of them
  • Materials not issued ahead of meeting for review
  • Important decisions and actions are not captured
  • Decisions being overturned after meeting as key members not present

There could be a number of other symptons of an under performing meeting.  However, the above gives a good idea of the themes.

Where a meeting is not seen to be productive, this leads to a circle of decline.  People will stop attending as they see it as a waste which increases the chances that decisions will not be made or will be overtunred post meeting.

Good news…

There are some very simple steps that you can take to set up a project meeting for success.

Project Meeting Terms of Reference

Creating a meeting Terms of Reference (ToR), is a great yet simple tool.  It describes all of the important aspects for the meeting so that every participant and those outside of the meeting are very clear on the purpose and operation on the meeting.

The ToR should include:

Purpose

This should clearly explain the purpose of the project meeting so that everyone has a common understanding why the meeting is needed.  For example to provide oversight and direction to project ABC.

Responsibilities

This lists out the collective responsibilities of the meeting attendees.  This ensures each attendee knows what is expected of them and it provides the authority.  For example, review and approve change requests.

Frequency

This will define how often the meeting is held i.e. monthly, weekly, etc.

Duration

This will define the length of the meeting i.e. 1 hour.

Attendees / Members

All regular members and attendees should be listed along with their role.  It is important to distinguish between members, who have voting rights and attendees.

It is also important to define if delegates are allowed.  If delegates are allowed there is a risk that the meeting will become ineffective as delegates will not have the appropriate knowledge and / or will not be able to make decisions.  If delegates are allowed they must be able to perform the required responsibilities.

Chair

One of the Members should be nominated as the chair.  It is also a good idea to nominate a delegate chair for when the chair cannot attend.

In some cases you may wish to have a rolling chair with each Member taking a turn.  This can work.  However, there must be a clear schedule to ensure everyone has a fair turn.

The chair is responsible for ensuring that the agenda is followed.  That members and attendees have the opportunity to be heard and ensure that the meeting remains within the terms of reference for the meeting.

Secretary

It is a good idea to appoint a secretary for the meeting.  The responsibility is to ensure that all meeting materials are available in a timely manner.  The key points from the meeting are captured together with actions and decisions.  These will be recorded in formal minutes.

Inputs

Any inputs for the meeting should be clearly defined.  This may include some form of meeting pack with required information i.e. status reports and must include the minutes from the previous meeting.

Outputs

Expected outputs from the meeting should be defined.  For decisions this should include how they will be communicated to other stakeholders outside of the meeting.

Document the ToR

Once you have defined the above, make sure that it is clearly documented.  This can be as simple as a single Word or Powerpoint page.  The aim is to make it clear to everyone so there is no confusion.

ToR Sign-off

The documented ToR can then be circulated to the identifeid members / attendees for review and refinement.  Plus it ensures that the candidates can assess if they are the right person to attend and that they have the required level of authority.

At the first meeting, one of the agenda items should be the formal review and sign-off of the ToR.  The sign-off should then be captured in the minutes.

Summary

The project terms of reference (ToR) is a simple but effective tool to set-up your meetings for success.  The steps above will help guide in setting up your own meetings.

To help further please see the post on the Importance of Meeting Logistices.

 

 

Project Governance Meetings

Project Governance MeetingsA typical project or programme will contain many tasks and activities.  Some will be small some will be large.  Some with short durations, some with long.  There may be one person working on a task or it may be a team.  Given all the dimensions it is important that there is an appropriate project governance structure for the exchange of information, resolution of risks / issues and for making decisions.

The governance structure will depend on the size and needs of each project.  The following are the types of governance meetings that can be used.

Project Working Group (PWG)

A PWG as the name indicates is used to drive much of the day to day work.  The meetings will be held fairly frequently.  Normally weekly, for more fast paced projects it can be more often.

The forum is used to discuss the active work both completed and what still needs to be done.  It can be used to set priorities.

The attendees will typically be those responsible for the completion of the tasks and the project manager.  For larger projects or programmes it might be the workstream lead.

The PWG usually will not have formal minutes.  However, actions and any risks / issues should be captured and tracked.  It is also important to record decisions so that they can be recorded.

The PWG should have a clear understanding of their authority as the PWG may identify risks / issues which they are unable to resolve.  These should be clearly captured so that they can be discussed with the project manager and, where required, escalated to the Project Steering Committee.

Project Steering Committee (PSC)

The PSC will be the next level of governance above the PWG.  It will normally be chaired by the sponsor or more typically the project manager.  The frequency will depend on the duration of the project.  Shorter projects may have a PWG each fortnight, those with a longer duration will typically be monthly.

The forum is used to cover a number of governance items including:

Minutes – the PSC should have official minutes to record who attended, key discussions, decisions and capture actions.  The first point on the agenda should be the official recording that the minutes from the previous meeting are agreed and accepted as final.  This provides an official record of the previous PSC.

Actions – there should be a review of open actions for updates or closure.  All actions closed since the last PSC should be recorded so that the members can review to ensure they are happy that the action has been closed.

Agenda – this will outline what will be covered by who in the meeting.  It should also clearly indicate what decisions (if any) are being sort.

Status – this will take the form on an executive summary and an overall rating using the recognised process i.e. Green.  It is important that all members agree the status as this will be the recorded official position at that point in time.

Plan – some PSC’s may wish to review the high level plan to check progress.  This is sometimes an easier way to view progress.

Deliverables – it is good practice for the PSC to review important project deliverables that have been completed in order to close milestones.  While the deliverable may have been signed-off outside the PSC, presenting for formal review and closure by the PSC helps ensure that the deliverable is fit for purpose and meets the requirements.  It also allows the closure to be recorded in the minutes.

Risks / issues – the PSC should review all of the important risks and issues at a minimum.  There may be risks / issues that require PSC intervention / support.  For example where a priority call is required for assigning resources between different workstreams of the project.  Tip: it is important that the risk / issue clearly states what action is being requested.

Resources – in the mobilisation phase of a project, it is crucial that the project resource plan is tracked.  This allows the PSC to challenge where resources are not being added quickly enough and provide support where approvals are not being progressed.

Budget – it is the duty of the PSC to review budget to ensure that the project is on track.  The budget update should clearly show progress against budget so that the members can see if there is over / under spend.

Change Control – any changes to scope, schedule budget or benefits must be presented to the PSC for formal review and sign-off (or rejection).  This will allow the formal change to be recorded and the project baseline to be updated.

Spotlights (optional) – during the life of a project, the PSC may wish to focus on particular aspects of the project i.e. approach, particular workstreams, areas of concern, etc.  The information can be presented as a spotlight as an update or as an item requiring a decision.

The PSC should have a clear terms of reference that sets the remit and authority of the meeting.  Most importantly it should clearly show what the PSC can and cannot decide.  It must also show the clear escalation route for items that are above the authority of the PSC.

Summary

Every organisation will have their own naming convention for meetings and there may be meetings in-between the PWG and PSC.  There may even by multiple steering committees i.e. project SteerCo feeding into programme SteerCo feeding into portfolio SteerCo.  However, the principles and responsibilities will be similar albeit with increased authority.

Establishing and embedding the governance forums is critical.  Each meeting should have a clear purpose, attendees and terms of reference.  This will help ensure that decisions and escalations can be quickly agreed to keep the project on track.

Project Milestone Reporting Routine

The last couple of posts focused on how the correct use of project milestones can help tell the story of the project.  This has the added benefit that the sponsor and stakeholders will have confidence that the correct progress is being made.  Take a look at Project Milestones: Using Outcomes to Tell the Story and Guide to Project Milestone Levelling.

Having clearly defined and named milestones is great.  However, like with any data, it is only valuable if it is kept up to date.  Therefore, it is very important that all the hard work is not lost and that the plan is kept up to date.  A simple method to solve this challenge is to establish a routine for the regular update of the plan.

  1. Plan Update Schedule

The first step is to define a schedule for when the plan should be updated.  While a project plan should be updated on an ongoing basis.  It is not very efficient to make updates each day.  Therefore, it is a good idea to set a point in time when the plan should be updated each week.  For example, all plan updates to be done by 12:00pm each Thursday.

Setting this as a criteria will ensure that all plans are updated on a weekly basis keeping them up to date.  While the first few cycles will have variable quality (nice way of saying the project teams will probably forget), when they realise the plans are being monitored, over time they will get into a routine.

This also ensures that where there are multiple projects, each with their own plan, all of the reporting will be at the same point in time.  This helps with data consolidation and means senior management can clearly see how each project is performing at a point in time.

  1. Milestone Reporting Criteria

To help the standardisation of data and subsequent reporting, it is important that all milestones are updated using the same criteria.  This will ensure that when a milestone is reported Red, everyone is clear why.

It also avoids the situation where 2 different projects have Level 1 milestones, both are 35 days late but project 1 is reporting Red milestone while project 2 is reporting an Amber milestone.  This is inconsistent and will cause resentment in project 1 as they will end up having a higher level of scrutiny as they appear to be doing worse than project 2.

It is very easy to set standard milestone reporting criteria.

For example, a very simple RAG criteria for milestones maybe:

  • Green: Milestone on track
  • Amber: Milestone at risk
  • Red: Milestone missed
  • White: Milestone not agreed / baselined
  • Blue: Milestone complete

Depending on the duration of the project or programme, it is advisable to set time parameters to the RAG criteria.

For example:

  • Amber: milestone at risk of being delayed up to 30 days
  • Red: milestone at risk of being delayed over 30 days

Extract of Reporting Guidelines from PMO Handbook

  1. Milestone Reporting Review

Before the milestone report is submitted, the project manager must review to ensure it is correct.  This helps ensure the correct status is reported.  It also acts as a reminder to the project manager and will usually lead to them reflecting on what has been achieved, where are the challenges and what needs to be done next.

After the plan / milestones have been submitted, the PMO should then review for consistency.  If there are inconsistencies, they should be discussed with the project team with the objective of making the report factually correct.

  1. Produce Report

When the data has been reviewed and confirmed as correct, the final report can be produced.  This will then be used to help report progress and status to senior management.

Tip: If the data identifies challenges, it is a good idea to have more detailed information available so you are ready to answer questions.  Even better to cover challenges within the commentary of any status reports.  It shows you are being open and transparent.

Summary

Following the steps above will help ensure that project plans are kept up to date.  This will allow there to be confidence in the data and the subsequent reports.

Remember, while project teams may push back saying this is admin, it is the responsibility of all good, competent project managers to maintain a robust project plan.  So you are not asking them to do anything more than what they should be doing.

Guide to project milestone levelling

The last post provided a useful overview of how identifying the correct milestones and making sure that they are written using outcomes, allows for the story to be told to sponsors and senior management.  You can read the post, Using Outcomes to Tell the Story, by clicking the link.

The first step in the process explained why project milestone levelling is important.  In this post I want to expand on the levelling process and how the PMO can help ensure quality and consistency.

What is a Project Milestone?

I thought it worthwhile quickly covering this to ensure common understanding.

Wikipedia states “Milestones are tools used in project management to mark specific points along a project timeline”.  This is a good general definition.  A project will consist of a number of tasks and activities.  The milestone is a way to show when groups of these tasks and activities have been achieved.

This is helpful as a well-constructed plan will have a number of milestones across the entire project cycle.  This allows for a simplified view of the project to be reported (the milestone story) and progress to be monitored and reported.

What is Project Milestone Levelling?

Having clearly defined milestones is important to being able to track and report progress.  However, not all milestones are equal.  This is where the levelling plays an important role.

Milestone levelling is the process of categorising the milestones into a hierarchy primarily to support reporting.  The level of the milestone will be based on importance i.e. what the milestone represents.

For example you could employ a simple process that uses 2 levels.

  • Level 1: Outcomes
  • Level 2: Key Deliverables

For each of the levels you would then provide clear guidance on how each level should be interpreted (see diagram Milestone Levelling below).

It is helpful to provide practical examples of real world milestones as this will help the project teams to relate to their own milestones.

It is possible to define as many levels of milestones as you want.  For example, there should be milestones below Level 2 that are used by the project teams.  However, it is advisable for the PMO to only define as many levels as is absolutely necessary.  If not there is a serious risk of over engineering.  Therefore, by only defining the top 2 levels, you allow the project to have the required level of flexibility to construct their plans while ensuring that the PMO has visibility of the important Outcome and Deliverable based milestones.

Always remember to aim for a practical pragmatic approach.

The diagram below is an example of the guidance that could be published.  This ensures that the milestones identified and captured by all projects can be compared on a similar basis.  This is important when it comes to reporting.

Example of milestone levelling guidance

Project Milestone Consistency

Publishing clear guidelines will help ensure consistency.  However, it is possible that projects may not understand, may not interpret the guide correctly or even ignore the guide.  This is where the PMO should conduct a review to sense check that the guidelines have been applied correctly.

This review should ideally be completed with the appropriate project team member.  It is also advisable to go about this in a consultative manner as opposed adopting an audit approach.  The later will be interpreted that you are “marking the homework to find errors” as opposed to the former which should come across as you helping to make the plan better.

Summary

Project milestone levelling is a simple but powerful tool to enable the monitoring and reporting of progress.  Done right it will promote confidence with sponsors and senior management as they will be able to monitor progress.  The PMO can play a pivotal role in setting the standards and reviewing plans to enable this to happen.

Project Milestones: Using outcomes to tell the story (inc FREE Template Download)

Project planning can be a difficult process, especially in the early stages when the analysis and business requirements have not been completed.  Therefore, it is little surprise that most project managers are happy, even relieved, when they have a first draft plan.

However, in many cases what was captured as the original name / description of the milestone will often remain the same for the lifecycle of the project.  While this is probably factually correct, as most milestones will be captured by the project teams, it is not unusual for the milestone name to be captured in “project speak” as opposed to something that will resonate with the sponsor and senior management.

This is a problem as it may lead the sponsor and senior management to be confused or, even worse, make incorrect assumptions on just what will be delivered.  This will lead to a very big expectation gap later in the project, typically at the worse time when emotions are running high.

This post aims to provide some ideas on the steps you can take to avoid this situation.

  1. Milestone Levelling

The levelling of project milestones is important.  It is fair to say that for most if not all projects, some milestones are more important than others.  These are the ones that represent that something significant has been delivered.

The milestone levelling process allows for the project manager to identify these milestones and then tag them.  The reason for this is that it allows for the significant milestones to be filtered and reported quickly.

This is good for the project manager to keep an eye on the status of the important milestones.  It also allows the project team to prepare reports that provide the important information.  Most sponsors will not thank being presented with pages of A3 Gantt charts and have to try and spot important milestones among 100’s of others!  It is the project manager’s duty to distil the information so that it can be quickly and easily consumed by the reader.

When there are multiple projects or workstreams in a programme, it is important that they all use the same criteria for levelling milestones.  This is where a good PMO will publish guidelines to help ensure consistency.  This means that the sponsor will have confidence that they are comparing milestones on a like for like basis.

The picture below is an extract from the PMO Handbook within the PMO Template Framework and shows how milestones can be levelled.

Example of milestone levelling guidanceMilestone_Outcomes_Template

  1. Milestone Story Telling

When you are living and breathing the day to day management of a project, it is very easy to forget that the project is not central to everyone else in your organisation.  So it is important to remember that not everyone will have the same level of knowledge and will not really know what is going on (even if you have told them and reported it).

It is for this reason that you need to have a carefully crafted story of the journey that you can quickly tell.  This will help ensure that others do start to remember, especially the sponsor.  Constantly repeating the same or similar story of how you intend to get from the project start point to the successful completion will help instil confidence that you know what you are doing and have a plan.

Having the clear concise story is part of the solution.  It is really important that your milestone report tells the same story.  This means that you will be able to use your high level milestone plan to walk the sponsor and senior management through the journey.

This is powerful as the fact that the milestones are printed on paper will make them more real to the audience.  It will naturally lead to your story being seen as credible.

Tip: using the levelling capture the important milestones and then practice your story.  How you do this is a personal choice.  However, sometimes it is good to commit thoughts to paper so that you can then review and refine.  However, do not make it so it sounds like a rehearsed speech and definitely do not read your story word for word from a typed note in front of the sponsor.  This will spoil the illusion of confidence that you know or believe how you are going to get from start to finish.

  1. Milestone Outcomes

This is the other important ingredient to being able to tell the story.

As mentioned earlier, many milestones will be created by project teams and invariably will be written in “project speak”.  This is where technical project jargon has been used to name the milestone i.e. Oracle DB Upgrade Complete, Sprint 4 Complete, GUI Build V1.5 Complete.

This is OK for those close to the project team.  However, very different to a senior sponsor who has a Business division to manage and has 100’s of active projects.

On a similar note, if you was telling a story in step 2, would you be using language like “GUI Build V1.5 Complete”?  I imagine you would not (if you would, you probably need to work on the story)!

One of the most effective techniques I have used over the many years executing and overseeing change is to use “outcomes”.  The principle is simple, a project is typically initiated by an organisation to achieve an outcome.  It could be increase revenue by developing a new service or saving money by making a process more efficient.

It naturally follows that time should be spent ensuring that the significant milestones follow the same approach of using outcomes in the naming convention.

“Implement Web App e-commerce” becomes “Implement online store”.  Straight away the sponsor knows that the online store has been implemented meaning that orders can be taken 24 hours a day!  Far more powerful.

Using outcome based milestones will reinforce the story and the sponsor should know exactly what has been achieved avoiding the dreaded expectation gap.

FREE Milestone Outcomes Template

To help focus on capturing outcomes and instil discipline, you can use the link below to download a template that can be used to capture and translate milestones into outcome milestones.

Milestone Outcomes Template Download

Summary

Investing time in building a solid plan is important.  Then by levelling, creating and telling the story using outcome based milestones should mean you have a happy sponsor.  There is also a side

Milestone Outcomes Presentation

PMO productivity – how to have your project templates available at all times

An important part of setting up a PMO, is implementing a robust tool set, namely PMO and project templates.  These templates take time to create, valuable time that could be used to focus on getting the PMO up and running or mobilising projects.

Problem

If you have been involved in projects and PMO’s for a while, it is highly likely that you will have developed (or purchased) templates.  However, how many times have you started a new role and you can think of a great template for the job but you can’t find it as it is on your home computer or you can’t remember where you stored in on the network, it has been accidentally deleted, attached to an e-mail in your mailbox archive, etc.  All very time consuming and not very productive (or satisfying).

Solution

I would like to share a simple and free solution that will mean that you will always have access to your templates and files as long as you have an Internet connection.

Dropbox is a cloud storage service that allows you to store documents and files on their service.  This means that the files can be accessed by logging in to a website.  This provides 2 important benefits:

  1. Your hard effort of developing templates (or money if purchased) is protected with less chance of them being mislaid
  2. You can access the templates and files from anywhere in the world where there is an Internet connection (subject to any local security requirements at your organisation)

dropbox-pmo-productivityIf you stop to think, if you are starting a project in another part of the world, then realise that you have a great template that could be used but it is on a PC at home, you would have no choice but to create a new one.  With Dropbox you can simply login with a browser and download the template – a big time saver.

Dropbox also allows you to download software that automatically sync files and keeps version control.  This is great where you are working on files between your desktop and laptop.  You can even get the Dropbox app for the iPhone and iPad.

At the time of writing, Dropbox Basic offers a free account with 2gb storage.  You can pay if you find you want more storage.  For example, the Personal account provides tou with 1TB of storage for the low monthly cost of $9.99.  I personally use this option as it means that I can also keep digital pictures, videos, music files as well as project files safe and then access them anywhere in the world.  However, that said, the 2gb space with Basic is more than enough to store the typical range of project and PMO templates.

Summary

This is a great service that can really help save time.  Take a look at the Dropbox website to view the functionality and sign-up for the free account.  Load up your important templates and you have your toolkit ready whenever you need it.

If you don’t have a set of templates, you may want to take a look at our PMO Templates.  Our range of templates includes the PMO Template Framework, PMO Quality Assurance Framework and PMO Resource Toolkit (all will easily fit within 2gb of storage).  Using both the PM Majik Members Area (where members can always access the latest versions of their resources) and Dropbox for when you are working locally with your computer (no Internet access), means you will always be able to access the template you need.

Launch of the Quality Assurance Framework

Quality Assurance Framework resourceLast year I wrote a 4 part series on the importance of quality assurance to make sure that the tools and processes created by the PMO have been implemented and embedded into the projects.  The reason being is that, by applying the appropriate rigour, there is a greater chance of the projects being delivered successfully (or knowing where the problems are early so that timely interventions can be made).

After completing the series of articles, it made me realise that a set of quality assurance templates would complement the PMO Template Framework.  So I am very pleased to announce the launch of the Quality Assurance Framework.

What is the Quality Assurance Framework

Quality Assurance Executive ReportA set of tools and templates to allow the rapid implementation of a quality assurance process so that you can:

  • Prioritise the projects for review
  • Schedule the projects for review
  • Conduct a structured review
  • Produce an executive report
  • Capture and track findings and recommendations

What is included in the Quality Assurance Framework?

The framework comes with all the tools, templates and instructions to allow you to start implementing a QA process today.  It includes:

  • Prioritisation Template
  • Quality Assurance Calendar
  • Quality Assurance Review Template
  • Quality Assurance Executive Summary
  • Quality Assurance Recommendations Register
  • Quality Assurance Framework Guide
  • Video Tutorials

What are the advantages?

Buying an integrated toolkit has a number of advantages:

  • Integrated end to end process
  • Simple to understand and use
  • Saves time creating the tools and process – the review template comes with 120 pre-populated questions!
  • Can be customised for your own questions
  • Ensures that all projects are reviewed against the same criteria
  • Professional output
  • Are ready to use as soon as you have completed your purchase
  • Full instructions ensuring that you can use the framework effectively
  • Full support of practicalpmo.com

Do I need special software?

No the Quality Assurance Framework has been developed to work with the standard Microsoft Office Suite – Excel, PowerPoint and Word.

How quickly can I get the framework?

You will have the complete toolkit within minutes of completing your secure online order.  You will be provided with a link to download a package containing the complete Quality Assurance Framework – even if it is 2am in the morning!

Can I get support?

Absolutely, practicalpmo.com is committed to providing professional products that are designed to achieve results while being sensible, pragmatic and easy to use.  Full support is provided.

Where can I get more details?

Simply visit the Quality Assurance page for full details of this great product and our special offer.

PMO Tools Handbook

milestone-planning-guidelinesA Project Management Office, will invest a lot of time and effort creating standardised templates and processes.  The reason being that this should help improve the quality and consistency of how each project is executed.  It also should mean that project data can be quickly and efficiently consolidated to produce meaningful reporting and management information

Important Point – the benefit of the standard templates and processes can only be truly realised if the defined methodology can be quickly communicated so that the project teams embed the standards.  This embedding stage can be very time consuming especially when project team resources are joining an organisation over a period of time.

The solution to this challenge is training and, the PMO Tools Handbook.

What is a PMO Tools Handbook?

In very simple terms, it is a guide / manual that documents all of the tools and processes that should be used to execute a project.  It should have sufficient information that a new joiner to an organisation can read the handbook and know what they need to do for each process.

What format should be used?

This is down to the personal choice of the PMO, obviously considering any standards mandated by the organisation.  The handbook can be published as:

  • Word document
  • Powerpoint
  • PDF
  • Website / Intranet Site
  • Bespoke publishing platform

It is a good idea for an electronic format as this will allow the inclusion of hyperlinks to additional information or templates.  It also means that the changes can be made as part of continuous improvement where as printed / bound handbooks need to be replaced.

It is also important to make use a format that does allow the information to be printed.  Many project managers like to be able to print and review documents.  A good tip is to produce simple guides that are easy to digest and link into the further detail.

Who should own the handbook?

The ownership should be with the PMO.  It is important that the content is maintained and kept up to date.  It is a hard sell to push people to use standards when the PMO is not keeping on top of their own content.

What should be included in the handbook?

The handbook should contain details that explain the context of the PMO and then the different tools and processes.

Context

  • Purpose & objectives
  • Context & background
  • Vision & mission
  • Design principles
  • PMO responsibilities
  • PMO organisation
  • PMO roles & responsibilities
  • Engagement model

PMO Tools & Processes

  • Planning
  • Cost management
  • Benefit management
  • RAIDs management
  • Reporting
  • Change control
  • Resource management
  • Communication management
  • Procurement management
  • Document storage management
  • PMO contact details

There should be sufficient information to explain:

  • Process
  • Tools
  • Ownership
  • Frequency

It should also include examples of any templates and links to where the latest version can be downloaded.

How to use a PMO Handbook?

It is important that the handbook is made available to all appropriate project team members and stakeholders.  Communication is key.  Therefore for maximum benefit do not just send a link and leave project teams to find and review the handbook.  This will not achieve the required outcome.

The PMO should set up training / orientation sessions with project teams.  While you can set up a large workshop, it is better to work with project teams on a case by case basis with perhaps a couple of the project team and project manager.  This will ensure that there is engagement.  Allow for questions specific to project to be answered and allow the PMO to get a sense of how committed the project are to the process.

Summary

A PMO Handbook is a very valuable tool to communicate and embed the required standardised tools and processes.  Couple with targeted training, standards can be quickly communicated and embed to maximise benefit.

4 Simple PMO Metrics to Measure Success!

Example graph tracking PMO metricsThere is typically a lot of time and effort invested to monitor the progress of projects.  It is usual that the primary reason for establishing a project management office (PMO) is so as to provide an independent view on project performance.  While this is helpful for measuring the success of projects it is also important for a PMO to have a process to measure their own success.

The reason for this is that at some point someone will question what is the value provided by the PMO (especially when there is a downturn in the fortunes of an organisation).  Therefore, a smart PMO will implement processes to track and communicate success.  This means that they are ready to demonstrate value.

As many of the metrics to demonstrate progress will need to be collected over time, the quicker the PMO starts to collect the data, the better they will be positioned to articulate the value they are adding / creating using facts.

There are a number of metrics that can be utilised, some will be specific to each organisation.   Below are 4 ideas of more generic metrics that are very powerful to demonstrate success.

1. Time to Mobilise

A common reason for project failure is slow mobilisation.  Tracking the time from project kick-off (the initiation) to mobilisation being complete, will demonstrate that the PMO has improved the time it takes for a project to become productive.  This can be achieved by measuring the time between a project being formerly started to sign-off of the business case (the usual gate into project execution).  Obviously you can use the recognised gates used by your organisation.

Over time you will build a bank of metrics that show you how long it typically takes to mobilise.  By collecting details of project size and content i.e. IT or even IT, System Name, this information will also help future projects to plan.  For example an IT project can look at previous IT projects for the same system and get an indicator of how long it took to mobilise.  This should result in better plans.

2. Percentage of Projects Delivered

This metric will measure how many projects launched (were started) each year (or appropriate time frame) were actually delivered and achieved the benefits in the business case.  To track this you will need to be able to build a view of the performance of previous years so as to demonstrate how this has improved.

Variation of this metric is % of projects stopped and % of projects that fail to deliver benefits.

Both are good as it will inform the organisation of their success rate.  So if only 60% are delivered, they can factor this into their planning and expectation of the benefits that will be delivered.  Far better than assuming and planning for 100% success.

It would then be possible to analyse this data to identify trends / common factors.  For example, is it a particular type of project that always fails?  Is it a particular team or even project manager / sponsor?

Using other metrics.  Is it where a project is slow to mobilise.

All of this should give some good, actionable insights.

3. Benefit Realisation

With the exception of regulatory or mandatory projects, most projects are started in order to achieve some form of benefit for an organisation.  Tracking the realisation of benefits against business case will provide focus to ensure that the benefits are achieved.  Again the % realised should be measured against previous years.

This is tracked by simply capturing the baseline of benefits against a timescale and then tracking the actuals.  This will highlight where the realisation is delayed, reduced or missed.

Similar to Percentage of Projects Delivered, you will be able to analyse to identify the trends and common factors for where benefits are not realised.

4. Return on Investment

Tracking the overall project costs and benefits will allow the calculation of return on investment (ROI) for the portfolio of projects.  This is a good metric for senior management as it will provide them with insight on the return from investing in change.

By monitoring year on year, the PMO can show if their service is leading to an increase in project ROI.  Again the data can be analysed for trends and this will help corrective actions and / or allow senior management to make more informed decisions i.e. investing in the projects where ROI has historically been higher.

In Summary

A smart PMO will ensure that they have processes in place to track key metrics in order to demonstrate the value that is being added by the PMO through the improvement of project delivery.  Over a period of time the metrics will help identify problem areas i.e. slow mobilisation due to time to gain approval from management, types of projects that fail to deliver, etc.  This in turn will allow corrective action.

The data will also help the organisation to make smart informed decisions to best utilise the change budget.

Use the comments below to add your thoughts and experiences of using project metrics.