PMO Career Path

The 3 PMO Career PathsWith any job, there is always a level of uncertainty on how the job will evolve. People are concerned about their prospects and their career path. The same applies to anyone who chooses a PMO career path. This post aims to provide an overview of the options available if you choose to take a position in a project management office.

Start of Career

If you are just starting your career, perhaps your 1st or 2nd job, it is highly likely that you have been recruited in a more administrative role within the PMO. This is normal as project and change management skills is something you learn over time by doing the job.

A lot can be learnt operating in this capacity as you will typically be involved in a number of the core PMO processes i.e. report consolidation. This will mean you will get the opportunity to engage with stakeholders who need to submit into the PMO and gain an understanding of the process.

From this base, you will then have a number of options.

  1. Continue in the PMO

You may decide that you enjoy the PMO environment. This will open up opportunities to take on lead roles such as Reporting, Change Control, etc. Then as you become more skilled (and confident), you will find yourself providing more constructive challenge and then providing guidance. This is a big value add for an organisation.

As your skills and experience grow, you will find that you take on more ad-hoc tasks such as targeted reviews of projects, trend analysis, etc so as to provide meaningful MI and recommendations to senior management.

As you grow in the role, you will probably start to have resources reporting to you giving the opportunity to mentor and build their skills. This will provide you with team management experience.

As you engage with more senior stakeholders, this will open the pathway to take on PMO leadership roles. It will also mean that you should be equipped to design, implement and manage your own PMO.

  1. Project Management

You may choose to go into project management. It is an easy transition from PMO support to migrate into Project support. The skill set and activities are very similar. You should gain experience in helping manage risks & issues, maintaining the project plan and writing project status reports. You also will gain experience dealing with the day to day challenges faced by a project.

Developing these skills will open up opportunities to take on other project roles including business analyst, workstream lead and ultimately project manager.

When you have become an accomplished project manager, you then will have the option to move into programme management and portfolio management.

  1. Business Roles

Working on projects will allow you to work across an organisation. It is one of the best methods to build your network and, importantly, build your reputation. Demonstrating that you can do a good job will open up other opportunities in a company. People are more likely to recruit people they know and trust.

Nowadays, project and change experience is important in many business roles. Therefore, if you have worked on a project for a specific part of the business, you will have naturally learnt about the subject matter. This means that you could consider moving into a business role within that area.

Note: the same applies to a path in technology.

Have a Plan

Now you have a high level understanding of what options could be available, you need to make a plan to give you the best chance of following your chosen career path.

  • Decide what career path you would like to follow i.e. you want to become a project manager
  • Work out your current skills
  • Identify skills you need to add or develop
  • Create a personal development plan to review and agree with your manager
  • Identify if there is any training available i.e. PMP qualification
  • Regularly review progress
  • Periodically revisit the plan (you may decide you want to go down a different path)


Taking a role in a PMO will provide a number of opportunities to develop your career. The important point is to have a clear idea of what path you would like to follow, create a plan and then execute.

Important: Choose a path where you have a passion and that what you enjoy!

Good luck to your success.

PMO Career Resources

The Project and Business Templates provided by PMMilestones contains a number of professional CV’s and business documents that can be helpful for career development.


Different names for a project management office

PMO Definition

In any organisation or industry, you will find a wide range of acronyms being used.  For a new comer this can be very disconcerting as you join a meeting, people are talking energetically using acronyms and you do not know what they mean.

This means you then have a choice, listen intently and try to work out the meaning.  If you can’t use Google when you leave the meeting or ask one of your new colleagues.  The other approach being to wait for an appropriate moment and ask for clarification of the acronym.

I am a firm believer that you should ask for clarification.  After all, if you are new to an organisation, you can not be expected to know all the terms they use.  However, there is a risk that the other people are using recognised industry terms.  Therefore, you may not want to expose the lack of knowledge, especially if you have been hired for having the appropriate expertise.

This same challenge exists for the different names used to describe a PMO.  Therefore, this article and presentation captures a list of the common terms into this article.

PSO – project support office

Some organisations use this term as the service provided is more administration support as opposed to helping to manage a project.

PMO – project management office

Supporting the project to deliver.  The level of management and support will vary depending on maturity of PMO (and organisation).  Please see the posts on the different types of PMO.

Admin / Reporting Clearing, Hybrid, Managerial

PgMO – programme management office

Typically will have oversight manage a number of projects that form a programme.  This may mean that the PMO’s will report into the PgMO.  Just to confuse matters, it has been increasingly common for PMO to be used for both project and programme.

PPMO – project portfolio management office

This will be building a view of the projects programmes in a defined portfolio.  While they can be used to manage delivery, most organisations use them to make decisions on what should be executed and when.

EPMO – enterprise project / programme / portfolio office

This will usually be the overall PMO owning standards, strategy, direction, etc.  It will link to the PMO network to ensure that all projects are aligned to strategy and following defined standards.  Very popular for organisations who want their strategies to be converted into change programmes and executed.

The diagram below summarises the different types of PMO.  While it is easy to see that the PSO provides the lowest “value add”, it is not so simple to as saying an EPMO provide the most value.  Each offers a different type of service so, a different value.

Types of PMO

Types of PMO Presentation

To close

This should provide with a good starting point of all of the common acronyms used to describe a project management office.  It is also important to remember that if someone does use an acronym, do not be afraid to ask them to explain what it means, you may even find that they do not know themselves!

Inforgraphic showing PMO definitions

5 steps to write a good project risk

If you take a moment to review most risk logs, on closer analysis you will find that the quality is variable at best. The reason is that many project teams do not put the appropriate time and effort into capturing and managing project risks. Unfortunately many see the process as a “tick box exercise” that they only do because they think they should and / or they are asked by the PMO. However, the reality is that capturing and managing risks can help prevent the issues that delay a project.

This blog contains a number of posts on risk management. However, there is not one on how to write a project risk. Therefore, this post will cover the 5 steps to writing an effective project risk. Note, the assumption is that you have taken the steps to capture the risks.

1. Title

Every risk should have a title that makes it clear to what the risk relates.

Poor Title: Resources

While the risk may relate to resources to support the project, this title is too generic. It does not specify what type of resources, is there not enough / too many and why they are needed.

Good Title: Lack of Java resources to develop website interface

This title makes it clear that the risk is lack of java resources and that they are needed to develop a website interface. You could even be specific on the actual website if there are a number of other website developments.

While you want the title to be clear, try to keep it short.

2. Risk Detail

Each risk should have a clear description that explains the risk so that the reviewers can understand the risk. As some may not be close to the project detail, it needs to be written using language that all can understand, including avoiding the use of technical / project jargon and acronyms.

Bad Risk Detail: There may not be sufficient resources to complete the project.

While this makes it clear that there may insufficient resources for the project, it does not detail type of resources, when they are required and the work that needs to be completed.

Good Risk Detail: There may not be sufficient java developers to complete the development of the website interface between September and October 2014.

This makes it clear of the type of resources, that there may not be enough, what they are needed for and when.

3. Risk Consequence

The reason for identifying a project risk is that they usually will have some form of impact on the project if the risk becomes an issue. Therefore, it is important to document the consequence so that the reviewers can understand the consequence to the project if the risk is not managed.

Bad Risk Consequence: Lack of resources may cause delays.

Again, very generic and does not really explain the consequence. Surprisingly, this type of statement is far too common in risks.

Good Risk Consequence: Delays to completing the website interface development by 31st October 2014. This will directly delay the testing phase. Each day delay during development will extend the completion date of the project by 1 day.

This statement makes it clear that the consequence of not having the required resources will delay the development of the website interface and will ultimately delay the end of the project.

4. Target Resolution Date

This is the date by when the risk needs to be addressed (mitigating action taken) or accepted (the project is happy to accept the impact if the risk becomes an issue).

Bad Resolution Date: No date specified, TBC (to be confirmed), TBA (to be advised), general dates (i.e. end of year, end of project).

If there is no clear understanding when the risk needs to be addressed, it is usually because it has not been clearly defined. It is common to see generic risks relating to resources and the end date being set as end of year / project. Not very helpful.

Good Resolution Date: This should be the date by when action needs to be taken to address the risk. In the example in this post, java website development needs to complete between September and October. Therefore, the date to address resource concerns must be 1st September 2014 at the latest (the date the resources need to be available). In reality you would want to set a date in August to give contingency i.e. 15th August.

Important: try to set real dates as opposed to ones where it does not matter. If a date is set and missed and there is no consequence, it will mean that other deadlines will not be taken seriously.

5. Mitigating Action

Defining the risk is only part of what needs to be captured. The project team should also provide proposed mitigation (the action to be taken to address the risk).

Bad Mitigation Action: Monitor resources to identify delays.

Another generic statement that states that resources will be monitored. This will probably result in lack of resources only being known when it is too late.

Good Mitigation Action: Identify named resources to complete java website interface and gain agreement that they will be available to support development between September and October. As contingency, engage 3rd party provider of java developers to see if they can provide resources at short notice should they be required.

This mitigating action gains commitment of the required resources and also tries to put in place a back-up plan.


It is important to clearly capture the key components to a risk.

  1.  Title – a good description of the risk
  2. Risk Detail – specific explanation of the risk
  3. Risk Consequence – what will happen if the risk is not addressed
  4. Target Resolution Date – the date by when the risk must be addressed or accepted
  5. Mitigating Action – what steps will be taken to address the risk

Following these 5 steps will help ensure that you capture and define good risks for your project.  If you are a PMO you can use them as the principles for the processes you define and mentor the project teams.

You can find associated project risk resources in the links below this post.

PMO Templates

One of the aims of a PMO is to standardize tools and processes.  One of the core ways that this can be achieved is through the design and implementation of PMO Templates.  This post provides an overview.

What are PMO Templates?

Example of PMO Template dashboardA template is defined as being a “pattern or gauge” or “used as a pattern to make something accurately”.  For example, templates are used in woodwork and dress making to allow something to be cut out consistently.  This is important if the part has to be a precise measurement.  If you did not use a pattern to cut out the sleeves for a dress, you would end up with different shape sleeves.

PMO templates are templates used to define and capture important project information.  At this point it is worth clarifying that there are project and PMO templates.  A project can define how risks will be defined and captured by way of a template.  However, the PMO may define a common standard to be used by all projects.  The template in this case may be referred to as a project template.  But it can also be seen as a PMO template as it is standardizing the process.

Project V PMO Template

To expand on this point.  While project and PMO template terminology is often interchanged, anything that standardized across more than 1 project can be seen to be a PMO or enterprise template.

Additionally there are templates that are specific to PMO.  These usually take the form of templates that allow information to be consolidated.  For example, each project may have their risks captured on a project template.  The PMO would ideally like a template that allows the consolidation and filtering of this information.  This is a good example of a PMO template.

What is the purpose of PMO templates?

The main objective is to define a standard way to capture important project information so that it can be easily consolidated, reviewed and compared.  Without the standardization it would be extremely difficult to produce meaningful reports.


PMO templates should help drive consistency and quality as well as making the consolidation process simple.  This means the PMO can effectively manage and review data.

This should mean the organization benefits from quality reporting produced in a timely manner.  This greatly reduces the risk that important items are missed and become issues to the successful delivery of the project.

Core Templates

A PMO should define a number of core templates:

  • Planning
  • Assumptions, Risks and Issues
  • Dependencies
  • Cost Management
  • Resource Management
  • Change Management
  • Reporting
  • Communication Management
  • Document Management

There are others but this is the core for any PMO.

Create V Buy

Creating templates is an investment of time and money.  Ideally an organization will have a set of defined templates to be used to manage projects.  However, this is not always the case.  Therefore, if an organization does not have predefined templates.  The time and effort to design, create, test and review needs to be factored into the project.  For example, taking the core templates 9 templates, each taking 1 day to design, create, test and review is 9 days effort.  The reality this will take much longer as time will be needed to complete the steps and gain input from stakeholders.

A good option is to look to invest in a set of pre-made templates.  This reduces much of the effort as other people have completed the hard work.  So for a relatively low investment, a project or PMO can purchase a set of templates, customize with organization name and then publish.

There are many contract project and PMO managers who have purchased templates so that they can quickly add value when they join an organization.  A small investment as low as $49.99 provides a huge amount of intellectual property in their kit bag.

Template Resources

There are a number of good providers including Project Management and Business Templates.  For the low sum of $49.99 you gain instant access to over 7,000 templates.  That works out less than 1 cent a template!  So it is easy to see the benefit of investing in professional templates plus when you think that 1 template could take a day to design, create, test and implement, a day of your time is worth more than $49.99.

Post Project Planning Workshop Activities

This is the final post in the 4 part series of project planning workshops.  It covers the activities after the workshop has been completed.  These activities are important to fully realise the benefits of the session.

Write Up

The first activity is to capture all of the information from the workshop into electronic format:

  • Timeline – capture milestones into tables and prepare timeline view
  • RAIDs – capture into the appropriate Risk, Assumption, Issue and Dependency log
  • Carpark – clearly document the issue and who owns the action to resolve

This information should be captured so that it is easy for each workshop participant to view their data.

Important tip: where possible, get someone else to reconcile that the information has been captured accurately.  You should also keep the original workshop material so you have a reference if there are any queries.


Project plan write upThe “write-up’s” should be sent out to all workshop participants for review and confirmation that they are correct.  Where possible, try to capture and publish within 48 hours of the workshop so the discussions are still fresh in everyone’s memory.

Set a deadline for when you want feedback / revisions or confirmation what has been captured is correct.  If there are changes, check against what was captured in the workshop as it may be an error in transferring from the workshop material to the write-up (which should be a simple change).  If the change is different to what was captured in the session, meet to discus so that the reason for the change is clearly understood so an initial assessment can be made if the change is valid.  Depending on the impact of the change you may need to set-up a meeting with some (or in extreme cases) all attendees to discus and agree the proposed change.

Agreed Plan

When all the updates have been received, update the workshop write-up.  This should then be re-circulated until all attendees agree.  At this point there should be an agreed plan recognised by all attendees.


With a plan agreed, work can continue on the required project activities.

Each project / workstream owner should develop their part of the plan to the required level of detail.  Make sure RAIDs are being managed and closed.  All owners of “Car Park” items should aim to quickly resolve so that any impacts to the plan is known and can be incorporated.


Each project / workstream should report progress against the agreed plan.  This should be using the standard reporting process that has been defined.  If the workshop has developed a mobilisation plan i.e. one that focuses on next 4, 8 weeks , etc, it is prudent to look for weekly updates to maintain pace and focus.  Longer term plans can have a less frequent cycle.


The last 4 posts have covered a proven approach to running project planning workshops to help quickly drive out an agreed plan.  The approach is effective and fun (plus helps bring teams together).  This last post is very important.  Workshops take a lot of time and effort to organise.  They also require people to give up significant amounts of time.  So ensuring the output of the workshop is captured and then actively used is where the PMO can really add the value.

How to set up and run a project planning workshop

This is the 3rd post in a 4 part series on planning workshops.  Post Running a Planning Workshop with Resources Costing Less Than $100 provided and overview.  Post Preparing to Run a Planning Workshop, covered the preparation work.  This post will cover the running of the workshop.

Room Set-up

Before you start the workshop, you will need to set-up the room.  You must do this before the start of the workshop.  It will not look professional and will waste everyone’s time if you do not start setting up until the start of the workshop.

It is important to give yourself sufficient time to set-up so you are not rushed and feel stressed (not the right frame of mind to start a workshop).  A good tip is to book the meeting room longer than you need, both start and end.  If the session is scheduled to start at 10am, book the room from at last 9am (ideally earlier).


The first task is to stick the different resources you prepared onto the wall. To do this you should use Blu-Tack (or similar) as this allows items to be placed temporarily onto walls with minimum risk of marking / damaging the wall (note: you should test in a discrete place that the walls will not be marked).

Choose a wall that can be viewed by all participant that allows the timelines to be hung.  As the timeline typically takes a lot of space, the wall should be free from switches, windows, etc.

Then either side of the timeline hang a sheet of flip chart paper for each of the following:

  • Risks
  • Assumptions
  • Issues
  • Dependencies
  • Milestones
  • Car Park

While the first 4 are obvious, it is worth quickly covering the concept of “Milestones” and “Car Park”.


This should be used to place all of the Post-it Notes that have been prepared for the milestones.  If you have multiple workstreams / projects with lots of milestones, it is a good idea to have a separate sheet for each workstream / project.  Placing them on to sheets means that all of the milestones can be easily viewed before placing on the timeline.

Spare Post-It notes should be available to capture new milestones as they will naturally be raised as part of the session.

Car Park

It is very easy for a tricky topic, that can not be resolved, to take too much time to discus.  As the item can not be resolved the conversation becomes circular, achieving little but taking valuable time.  The “Car Park” allows the item to be noted and dealt with outside of the session.  It is the job of the facilitator to close down these conversations in a timely manner where it is clear that resolution will not be reached.  The facilitator should make this clear as part of the start of the workshop.

 Supporting Material

Place any printed supporting material on to the table.  For example, Briefing Packs, existing plans, etc.

Don’t Forget the Energizers…...

Well sweets.  Place them on the table so that attendees can grab when they are in need of an energy boost during the session.

Final Check

  • Make sure that you have enough chairs
  • That displays (if you are using on screen presentation) work
  • Conference line works (note: as the workshop is interactive audio and video conference attendance is not recommended)
  • Tea / coffee / water available
  • Time of lunch / coffee is confirmed with facilities

OK you should be confident that you are set to go.


Use the briefing pack to drive the session.


It is important that everyone understands who is attending and their role.  Best achieved by going round the room and getting everyone to do a brief (less than 30 second introduction – Name and Role).

Purpose / Objectives

Facilitator should confirm the purpose and objectives of the session to make sure that everyone agrees to the common goals.  If people have concerns, requests, etc, the facilitator needs to take a view if this is sensible.  However, it must include creating the project plan timeline.


The facilitator should explain the approach to the workshop and what each of the sheets on the wall be used for.

Planning Assumptions

The Briefing Pack should include a list of Planning Assumptions.  This should be collectively reviewed, refined and agreed by all participants before starting the interactive part of the workshop.  If this is not done, there is a risk that the plan is developed on incorrect assumptions.

Developing the Plan

This is the main part of the session.  Ideally each owner of a workstream / project should take it in turns to place their milestones onto the plan.  As they do so, they should provide an overview of logic behind the milestones and the proposed dates.  This allows the other attendees to understand the milestones, ask questions, raise concerns, dependencies, etc.  This sharing of information will highlight areas of concern and these can be captured on the sheets hanging on the wall for all to view.

This exercise is repeated until all milestones have been placed.  It is then important for all participants to review the time line, RAIDs that have been captured and confirm they are happy with the draft.  Where possible, any items placed in the “Car Park” should be resolved at the end of the session.  If this is not possible, an owner must be agreed to resolve.

At the end of the session the facilitator must summarise and then advise on next steps i.e. output from workshop will be published in x days.  Aim to do this within 24 hours so that the discussion points are still fresh in the attendees minds.

Workshop Take Down

After the session is complete, the items needs to be carefully removed from the walls so that they can be written up.  IMPORTANT: Post-It Notes have a habit of coming unstuck when being transported.  To avoid this, use sticky tape to stick all of the Post-Its on the timeline, RAIDs and Car Park.  This ensures that they will not fall from where they have been placed.

Remember, leave the room the way you found it.


Following the above will allow you to execute a fun, interactive planning session that results in an agreed draft plan.  The next post will cover the planning workshop activities.

Preparing to run a project planning workshop

The last post provided an overview of an approach that can be used to run successful project planning workshops.  This post will cover the preparation work that should be completed ahead of any workshop.  Good preparation is very important.  Just like studying for an exam, investing the time ahead of the event will ensure that it has the best chance of being professional and, achieving the required outcomes.

The following steps should be completed ahead of the workshop.

1. Review Available Information

I have deliberately used the word “information” as opposed to plans as, the plans may not exist.  Any available information such as business case, initiation document, plan (if available), etc should be reviewed before designing the logistics of the workshop.  This ensures that the workshop is based on the level of available data.  It is no good setting up a workshop to create the 30 day mobilisation plan when it already exists.  Likewise, if there is no business case, understanding of outcomes / deliverables, it will be illogical to hold a workshop to create a plan when there is no understanding what needs to be achieved.

2. Attendees

On the assumption information is available, work out who needs to attend the meeting.  Make sure that all the relevant functions that will form the plan are included.  Otherwise, you will have knowledge gaps in trying to create the plan meaning something may be missed, incorrect assumptions made, etc.

Try to minimise the number of people invited.  Having too many people, the “cast of 1000′s”, will hinder progress.  If one area does state they need to invite people with different skills firstly test this is true and, if so, look for opportunities where they can be invited to relevant segments in the day to reduce large numbers for the entire workshop.

3. Logistics

Project planning workshop roomReviewing the available information should allow you to define the objectives of the workshop.  Be specific so everyone has no doubt what needs to be achieved.

Book a room that will hold the required number of people and, has sufficient wall space for sticking the timelines on the wall, flip charts, etc.  You want a comfortable working environment, especially as the session will probably be half to a full working day.  If possible visit the room ahead of the session so you can check layout.

Send the workshop invite early so that attendees can re-arrange schedules where necessary.  The booking should include the objectives and agenda.

4. Planning Briefing Pack

To give the planning session the best chance of success, you must make sure that all attendees having a clear understanding of how the session will work and, what is expected from them.  This will ensure they prepare ahead of the meeting and you don’t end up with too many “I need to take that action away”.

Preparing a simple pack that outlines the:

  • Objectives / goals of the session
  • Agenda
  • Attendees
  • Background
  • Approach
  • Known assumptions
  • Key milestones <if this is available ahead of the session this really helps>

This serves to educate the attendees, allows them to ask questions, clarify items and consider what they need to deliver so they are ready to develop a plan.  This means that everyone should be ready to start the workshop without spending too much time explaining the approach.

5. Preparing Workshop Materials


parcel-paperAt the centre of the workshop is the timeline (created using parcel paper that is available in most stationers or Amazon) and milestones (captured using Post-it Notes).  These must be prepared ahead of the session.

At least the day before, find an area with suitable working room (meeting room with large desk, preferably rectangle).  From the information collected in step 1 and objectives defined in step 3, mark-out the timeline on the parcel paper.  This should be weeks, months, quarters, etc.  The shorter the period, the more chance of achieving the development of a plan.  If you do have dates past 1 year, I would suggest adding a heading at the end that covers future years to capture the milestones.

Going down the left hand side of the parcel paper, list the different projects / workstreams.  If you have a number of functions completing the same project.  You may find that they each have the same workstreams.  Therefore, to make the task easy to think about and not to confuse the plan timeline, have one timeline (one strip of parcel paper) per function with workstreams.

Do not try to squeeze too many workstreams onto a timeline.  You must have sufficient space to add the milestones.  It is far better to add additional sheets beneath each other.  Obviously you are limited by the height of the meeting room.


stickersIf you know the milestones, use the Post-It Notes and write one milestone on a single Post-It.  When developing over multiple projects / workstreams, make sure each Post-It contain a reference for project / workstream and ID of milestone.  For example, if the milestone related to the Finance function, you may choose to use FIN.  You can also look to use different coloured Post-Its to distinguish workstream / project.

The aim is to create a Post-It for each milestone ahead of the workshop.


Doing as much as you can to prepare will help the workshop to go well.  Make sure that the attendees have sufficient time to review the briefing pack so that they can gather additional information so they are ready.

The next post will cover running the workshop.

Running a project planning workshop

At the centre of every project there should be a plan.  This explains what activities need to be completed by when in order to meet the objectives / outcomes defined in the business case.  Having a credible plan is very important.  Knowing what needs to be completed and then tracking progress, allows the project manager to track progress and escalate where required.  If the plan is not credible, progress will very soon fall behind.  So investing the time to develop a good plan is important.

Unfortunately, many struggle to form a good plan due to a variety of reasons:

  • Plan developed by individual / in isolation with no engagement with other people who need to deliver key components
  • Not engaging the correct people so not all of the scope is captured within the plan
  • Estimates incorrect
  • External factors i.e. key holiday periods, projects using same resources, etc are not considered

There are many more.  All can lead to a sense of overwhelm in developing the plan.  The project manager is left staring at the screen wondering where to start.

A very good approach to developing the plan is by way of a planning workshop and breaking down the task so it is manageable and does not overwhelm.


A workshop is arranged with all the relevant participants with the objective to develop:

Short Term Plan

This could be the mobilisation phase, next 4 weeks, etc.  The intent is to focus on the activities that need to be completed in the near term as these should be known.

Longer Term Plan

This is post the Short Term Plan and can be for the remainder of the year, entire project, etc – whatever you feel comfortable trying to achieve.

During the workshop, the group agrees:

  • Key activities, deliverables and milestones
  • Associated risks, issues, assumptions and dependencies

The workshop needs to be held in a room with suitable wall space that can be seen by all participants as the workshop must be interactive as the information needs to be captured on the walls using the following resources that should cost less than $100.

Parcel Paper (the brown paper you use to wrap parcels that comes on a roll)

This is used to create a time line that can be stuck on the wall (this should be prepared before the workshop as you do not want to waste time creating during the workshop).  The paper is used to create strips across the wall.  On each strip a number of projects / workstreams are listed on the left going down the page.  The dates are listed evenly going across the page (note: make sure that there is sufficient room to add a number of items into each project / workstream under each date.  If you have a large number of project / workstreams, add additional strips underneath when you place on the wall.

Post-it Notes (ideally larger size and different colours)

These are used to record the different activities / milestones (where possible document known activities / milestones ahead of the workshop and have them to the side of the timeline ready to place). The Post-it Notes are then placed on the timeline in the appropriate place.  The action of placing some of the Post-it’s will prompt a discussion of what can / cannot be achieved and flush out dependencies.  Being Post-it Notes, they can be easily moved if and when a dependency is identified when planning subsequent projects / workstreams.

Where possible use different colour Post-it’s for different project / workstreams to make them easy to distinguish.

Marker Pens

Use these to write Post-It notes and capture risks, issues, assumptions and dependencies on flip charts (assumption is that most organisations will have flip charts so not in the $100).

Blue Tac

Used to stick the timelines to the wall.

Sellotape (stick tape)

Very important.  When the timelines are complete at the end of the session.  Use the tape to stick the Post-it Notes to the timeline so they do not fall-off when taking the timeline down (most meeting rooms will need to be used by other people so you cannot leave them on the wall).  This ensures that you then can document what was agreed during the session without missing Post-it Notes.


People will start to lose energy, especially in long sessions.  Make sure you have some sweets in the centre of the table to give them a boost of energy when needed.  Also consider having healthy options, the effect is the same.

This should result in 2 plans being developed.  These can then be documented and published for review and refinement.


The benefit of this approach is that a plan can be developed in a collaborative way with involvement from the appropriate stakeholders.  Seeing the plan visually will make it easier for people to understand what needs to be achieved by when and allow barriers to be identified.  Working this way is good for team spirit and helps ensure a feeling of common ownership – very important for success.


This is a very quick overview of a very powerful technique.  Used correctly, it really can fast track the creation of plans.

How to improve the quality of project status reports

Steps to improve project status reportingThe last post, 5 ways to check the project status is correct, provided 5 steps that could help validate that a project status report was accurate.  Following these should identify where there are areas of concern.  However, the real goal is to continually improve the quality of the reports.  This is much harder than it sounds for a number of reasons including:

  • Project managers do not know what is required
  • Project managers are not aware there is an issue – they have not been told
  • Project managers / sponsors do not see why there is an issue – the reports are good enough

Below are some steps that can be taken to address these points and result in improved reporting.

Project Report Template

Project reports should be structured and contain space for all of the appropriate / required information to be provided.

Many project managers will have reports that they have developed and used in the past and, naturally would like to use them for their current project.  If this is the case, ask if you can review the report structure and make recommendations to help ensure the correct information is provided.

A better solution is to develop a standard report template and issue to all projects.  When creating the design, create areas of input that will help drive the user to provide the correct information.  Take a look at the Project Templates page for the other benefits of using standard templates (including making the consolidation much easier).

Training and Guidance

It is a good first step to issue a good template.  However, do not assume that the project managers know how to complete the template, what information should be included, how the information should be written, etc.

Training is very important.  Make sure that guidance is issued and available for future use (i.e. on an Intranet site).  Conduct face to face or virtual training.


  • Context: The purpose, objectives of the reporting
  • Audience: who will be reading (different writing styles may be required)
  • Inputs: Explain each field on the report and examples of what is required
  • Frequency: How often the report is required and period it should cover
  • Sign-off: Who should review and sign-off before submission (i.e. sponsor?)

Allow questions to be asked.  Make sure the project manager knows how to ask questions going forward.

Regular Reviews

Set up regular review meetings with the project managers, ideally before the status report is submitted.  During the review session, you jointly review the report.  This will allow questions to be raised where something is not clear and other recommendations to be made.

Caution: make sure that the review is conducted in a constructive way.  If not there is a risk that it could leads to the project manager becoming defencive and not taking on board any of the recommendations.

Review and Feedback

Post the submission the reports will be reviewed by a wider audience.  Ensure that there is a mechanism for collecting any feedback and passing this back to the project manager.  If they are not aware of concerns, requests, etc, they can not change.

The feedback means that the project manager knows that the reports are being used and not just a “form filling exercise”.  They also will be mindful that the inputs need to be accurate.


Improving the quality of project status reports will not just happen on it’s own.  You need to take actions.  Simple steps being:

  • Define standard project report template
  • Train and educate the project managers
  • Hold regular reviews
  • Provide feedback

Implementing these simple steps should lead to an improvement in the quality of the project status reporting.

5 ways to check the project status is correct!

Do you trust the status on your project reports?It is the duty of the project manager to provide regular and accurate status of their project.  This is typically achieved through project reporting.

It is very important that the reports are a true reflection of status so that sponsors and stakeholders can have confidence in the performance of the project (or take informed decisions where progress is not going to plan).

If the reports are not accurate, then this could result in the status being misrepresented and storing up issues for the future.  The sponsor will not be pleased if a project has been reporting Green for a year, only to find near the end that challenges had not been communicated and the project will be delayed by 6 months.  This is not helpful to anyone (especially the project manager).

To help mitigate this risk, the PMO can play an important role in the review and challenge of the reports.  However, simply reading the report may not be sufficient to identify areas of concern.

Below are 5 tests that can be applied to check if the report really does reflect the status of the project.

1. RAG versus Commentary

A good project status report should provide an overall status (typically RAG – Red, Amber, Green) and supporting commentary.  A simple check is that the commentary supports the RAG.

For example, the project may be reporting Green.  However, the commentary may state “there are significant challenges deploying computer hardware meaning that the deployment of software will be delayed 3 months”.

The commentary clearly indicates that there are challenges threatening dates.  So the project manager should be questioned as to why this issue is not driving an Amber or Red status.

2. Performance versus Budget

This is another simple, quick test.  The project manager should be reporting progress against budget.  If you can see that project is over budget, this could be a sign that there are challenges requiring more resources.  If this is the case this will mean that the project will go over budget and, there could be challenges that will cause delays.

In a similar way, being under budget is not good.  This implies that resources have not been added and that this could mean work is not being completed as expected.   Another sign the project is falling behind.

However, there is a word of warning using this measure.  The variances could be done to poor planning and changing prices.  While this has budget implications, it does not necessarily mean the timeline is under threat.  You should use this measure in line with other checks.

3. Performance versus Milestones

This is a good test if a project is on plan.  A plan is made up of a number of milestones in a period.  Therefore, checking if the milestones in a period have been completed is a good test.  For example if the status is Green but 5 out of 10 milestones have been missed in the reporting period, the project manager should be asked to explain why the missed milestones have not impacted the RAG status.

4. Alignment to Associated Projects

The first 3 tests are very much based on the status report for a single project.  A very good check is how the status of one project compares with an associated project.  For example, a project to deliver a new product may be reporting Green.  However, the associated project to deliver the underlying infrastructure may be Red.  If the business project is relying on the infrastructure to successfully launch, it is difficult to see how the business project can be Green.

Having an understanding of how the projects in your portfolio are linked will help you to better assess the true status of each project.

This situation can be emotive as the business project manager may feel that their project is Green and they should not be penalised due to the infrastructure project.  Remember, the purpose is to report an accurate status so as to manage expectations and allow informed decisions.  Therefore, it is OK to report Amber or Red with commentary advising that the status is being driven by the dependency on the infrastructure project.

5. Word of Mouth

This is one of the most important tests, speaking to members of project teams, sponsors and other stakeholders.  This will usually result in information that provides more insight to what is going on that is not (or cannot) be placed in the status report.  This information is an important measure to which evaluate if the report truly reflects what is going on.


In order to ensure clear and accurate project status reporting, the PMO must do more than accept each report at face value.  By combining the 5 simple test, the PMO will be able to quickly ascertain if the report is accurate or, needs to be challenged and changed.

What do you think?

Do you think that the status reports you receive provide a fair representation of the status of projects?  Use the poll below to provide your feedback.

Do you think your project status reports are accurate?