PMO tips – project and PMO planning for significant events

pmo planning for significant events like the OlympicsWhile writing post “Keeping projects on track over the summer holidays“, it made me think about the plans that many organisations make when major events are held such as the Olympics, World Cup, etc.

For example, when the Olympics was held in London in 2012, many organisations in and around London made contingency plans.  The reason for this was that for the duration of the Olympics and ParaOlympics, it was highly likely that there would be a number of challenges to the normal working day:

Visitors

Increased number of visitors to the areas in an around the stadiums.  All of these people needing to get to the stadiums meaning the travel systems being placed under extreme stress.  The daily number of people using the travel systems greatly increasing making it a challenge for workers on their daily commute.

Road Closures

For some major events, it can be common practice to close or divert roads.  This makes driving very difficult, delay buses and push more people onto other modes of transport such as the underground (making the problem even worse).

So what…..

The ‘so what’ in all of this is that all the extra people and transport challenges will make it difficult for people to go about their normal working day.  During the London Olympics many organisations made plans for staff to work remotely, not to arrange any key face to face meetings in London and, generally accept productivity will reduce.

PMO Action

In a similar way to proactively manage staff holidays.  Similar assessments should take place for the significant events (such as the Olympics) (see post on Project Holiday Planning).  This will allow the PMO to identify potential problems and help put mitigating plans in place early.

Take Away Thoughts

While you may think the Olympics in London is very specific, the principles of identifying potential events that will impact project delivery is universal and timeless.  The Olympics will be held every 4 years like the World Cup.  There are other key events that will impact particular Cities and countries.

The lesson is that a good PMO or project leader should automatically be thinking and identifying events that will impact the projects under their control and take positive, proactive action.

PMO tips – keep your projects on track during the summer holidays

Holiday project ganttWe are now nearing the end of June and the holiday season is fast approaching (the period mid July to mid September).  This is the time many of the people working on projects decide to take their main holiday of the year, which can be a period of 2 – 3 weeks.  With so many people out of the office, it is only natural that productivity and progress slow down.  Therefore, I wanted to share some tips and ideas how you can demonstrate the value of your PMO by being proactive.

Holiday Plans

Before putting contingency plans in place, it is good to understand if there is a problem.  Make sure that each project has put together a holiday planner showing the dates when project resources are out of the office.  In fact it is good practice to prepare a holiday planner at the start of the project and then keep it up to date.

In the UK it is normal for people to take 2 weeks holiday.  In Europe this can be up to 4 weeks and in certain countries you will find very limited staff in the office in August.

Having a clear understanding of the holiday dates will act as an important input to assess impact on the deliverables and plan.

Key Deliverables / Milestones

Ask the project manager to review all the key deliverables and activities over the period July to September.  Make sure they consider the resources who will be on holiday and then evaluate how this may impact deliverables and what this will do to the overall project timeline and benefit realisation profile.

Dependencies

In a similar way to Deliverables, ask the project manager to identify where key dependencies need to be delivered during the period.  This will then allow a check with the project manager who is the ‘giver’ to assess if the delivery will be delayed due to staff holidays.

This is where a proactive PMO can add real value as they should have a good overview of all the key milestones and dependencies allowing them to quickly identify potential hotspots.

Decisions

Are there any key decisions or sign-off’s required from senior management or sponsors over the holiday period?  If so, will they be in the office and able to attend the appropriate steering committee, etc.  Again show your value to the project managers by building a holiday schedule of senior management and sponsors.

Where they will not be around, see if there is a way to accelerate the decision meeting, arrange for an empowered delegate to be appointed to take the decision.  On this it helps if you can layout something like “If deliverable meets x,y, z criteria then it is possible to sign-off / make decision”.  By doing this you help the delegate to make the decision as they know their boss has laid out the criteria.  Likewise, it helps the project manager to remember what standard they need to meet.

Run Rates

When all the information has been pulled together, it is worth looking on how it will impact the run rates.  In many cases, project planning does not take into account holidays.  This is normally OK when there is a only one or two people out.  However, when there are lots of people, this will reduce the run rate.

It will reflect very well on the PMO if they can identify that not so much budget is needed in a given year providing senior management to redeploy the surplus funds on other projects.

Conclusion

Using some or all of these tips will demonstrate that you are a forward-looking, proactive PMO that delivers real value.

If you look at all of these tips, none are rocker science, just good practical, common sense.  Unfortunately this type of thought process gets lost when people are focusing on near term deliverables.

This leads to my overarching tip.  As a PMO manager, always think ahead to try and identify what will cause problems in the future.  Doing this gives you the best chance to take action and avoid issues.

Project Deliverable Tracker (the fields you need)

Woman pointing at project deliverable tracker signThe last post, How to know the project is done, covered 4 principles that could be used to help ensure that a project delivered the required outcomes. One of the principles being the use of a Deliverables Tracker to monitor and store key project outputs.

This post will expand on the practical components of the Deliverables Tracker.

Before you start

It is important that the project managers have taken the time to define the deliverables for the project. If not, it will be nearly impossible to populate a Deliverable Tracker. However, while this is in progress, you can create the template to capture and track the deliverables.

Overview

The Deliverable Tracker is simply a log of the deliverables that must be completed for each project. A simple solution is to use a spreadsheet application such as Microsoft Excel as this will allow the filtering and searching of data. It is also possible to build more sophisticated trackers using applications such as SharePoint. This will then allow the automation and integrated storage of deliverables.

Key Data Points

The following gives an overview of the data fields you should capture within your Deliverable Tracker.

Unique ID

Each deliverable should be assigned a unique reference. This will help make it easier to search for a specific deliverable, especially if the tracker contains deliverables for multiple projects and programmes. It will also help the traceability back to the original requirements.

Aim to use the same unique ID as what is used by the project. This will eliminate the risk of confusion and the need for cross reference tables.

Work Breakdown Structure (WBS)

It is good practice to use a WBS when structuring project plans. Therefore, you may wish to capture the WBS that has been assigned to a deliverable. However, take care when tracking multiple projects as there may be a risk that the same WBS may be used across different projects.

You can even consider using the WBS as the Unique ID if there is no risk that there will be duplicates.

Description

This should be a clear and concise description that details the deliverable. It should allow for anyone to understand what is being delivered without having to refer to the underlying project. This is also useful if part of the process is for an independent review of each deliverable against the tracker.

Business / Function

For a large organisation you may wish to include a field to indicate what area of the organisation owns the deliverable. This will then allow the data to be filtered to create specific reports I.e view of deliverables for specific business. You may wish to have separate fields for each if it is possible to have Functions within a Business.

Region / Country

This allows for data to be filtered to give reports based on Country or Region. Again you may wish to use separate fields to allow better filtering and report production.

Project / Programme

If the tracker is being used for multiple projects, this field will allow the filtering by project.

Owner

This should be the ultimate owner for each deliverable. This is the person responsible for the final sign-off and acceptance of the deliverable. The deliverable should not be marked as closed unless it has been signed off by the owner.

Baseline Completion Date

In order to track progress, it is important to capture a target date for each deliverable. This will then allow the tracker to be filtered to highlight those that are past the due date so that action can be taken.

Actual Completion Date

This will capture when the deliverable has been completed. This is important so as to provide an audit trail if any questions come up in the future.

Deliverable Status

This field allows for progress to be captured. For example, it is good to know that the deliverable has been started as this will give more confidence that it will be completed by the required date. Likewise, it will allow for reports to be generated where deliverables have not been started but due in next 4 weeks, they may need attention.

RAG Status

This can be used to indicate if the deliverable is on track or not. While this is similar to Deliverable Status, it is useful for providing simple reports where each deliverable can be shown with the RAG status. Then the ones that are Red can be prioritised.

Summary

Using the above to construct a Deliverable Tracker will help you monitor progress and allow analysis of data to focus on exceptions. It is also a good idea to consider developing exception reports that are generated on a regular basis to send to the different owners. This helps propmt action by effectively delivering a “to do” list to each area.

How to know the project is done! Hint: Deliverable Tracker

How would you answer the following question from the project sponsor:

“How do I know the project is done?”

This is a very interesting question as what the project sponsor is really asking is:

“Have the required project outcomes been delivered?”

Project manager thinking if project is completeThe answer is important as the sponsor has typically committed valuable resources (budget, people and time) to achieve a result. Therefore, the sponsor is fully in their right to expect a positive response.

Take a moment to think about your current project or programme and, if this question fills your with fear, panic or simply makes you feel uneasy, the following 4 principles can help.

1.Clear scope and outcomes

While this may sound obvious, there are many active projects that do not have clearly defined scope. Even more do not have a clearly defined outcomes.

Understanding both is critical for the project manager. Without knowing the scope and the required outcome, how can the project manager define and direct the work to achieve the required result? Answer: they cannot.

So by not having this clear understanding, the project manager is putting them self at a disadvantage before they have really started. Not the way I would choose to start a project.

At the start of any piece of work, make sure you take time to capture the scope and required outcomes. Keep asking questions until you and the team are clear as it is far better to remove ambiguities at the start.

2. Document scope and outcomes

If you have completed step1, good work. Now you must document the scope and deliverables in a clear and concise format that can be understood by all stakeholders. Remember, it is easy for misinterpretation of the written word. Therefore, ask for peer reviews to ensure that the document is clear.

Ideally the outcomes will describe each important deliverable and the metrics that will be used to measure if they are complete. Agreeing these at the start of the project is far easier than waiting until the end of the project.

3. Agree scope and outcomes

It is important not to assume that just because you have created a document that the sponsor has read and understand the detail. Therefore, it is advisable to set up a review session with the sponsor and any other stakeholder to walk them through the key points on scope and outcomes. Taking this step will help ensure a common understanding and will allow misunderstandings to be resolved. Make sure that the document is updated to reflect any changes.

At the end of the session, ensure that all parties formally acknowledge and agree the scope and outcomes. This signed off document will then act as the baseline for the project manager to deliver the work. It also means that the project manager has got a reference to validate the deliverables as they are completed.

4. Track progress

Having spent time agreeing the outcomes (deliverables), it is important to track progress. Regular reporting will assist. However, to ensure a robust process, outcomes should be translated into milestones and a deliverable log should be created.

This will allow for progress against each deliverable to be tracked and will highlight where deliverables are late or missed. There can even be an independent process to assure each deliverable and a standard method for storage. This ensures that all the deliverables can be found at the end of the project.

For details on the data points and fields you should include in a Deliverable Tracker, visit the post, Project Deliverable Tracker (the fields you need).

Summary

The purpose of a project is to achieve an outcome. Scope will help define the outcome and ensuring that the scope and outcomes are clear, documented, agreed and tracked will help ensure that they are achieved.

What is one of the biggest frustrations with a PMO?

The project fire drill 4 step action planIf you were to ask people involved in project and change management what is one of their biggest frustrations when it comes to a project management office, what do you think their answer would be?

The most precious commodity to most project teams is time. This means that it must be used extremely wisely. So for this reason, most project teams dread and loathe “project fire drills”!

What is a “project fire drill”?

Just in case you are new to the project world and have not heard of the term “fire drill”. This is the name used to describe a piece of unplanned work, usually with an unreasonable deadline in a response to a request (usually senior management). For those who have been involved in projects, even if only a short time, you probably have been impacted by at least one.

How can a PMO help ease the pain of a “project fire drill”?

A good PMO will always be looking for opportunities to help and support the projects that they support. The following 4 tips are methods a PMO can provide value and help ease the burden on the project team.

  1. Push back

The best way of stopping the impact is by pushing back on the person / area making the request. It is unfortunate that many PMO’s simply accept the request and feel obligated that it must be actioned.

When you receive a request, ask some simple questions to understand the reason for the request, the required outcome, importance, etc. Use the questions to assess if the request makes sense and if it makes sense. From the questions you may identify that the request does not meet the required outcome. It may even be irrelevant.

If this is the case, explain the concerns to the requester and try to get the request stopped. Word of warning, the requester may be simply acting on behalf of senior management so you will need to help provide them with logical arguments to help them to push back or, at a minimum seek further clarification.

  1. Service request centrally

The PMO should be the hub for project information. Therefore, if the request is reasonable, it is highly likely that the PMO can service the majority, if not all of the request from the data they hold.

If this is the situation, the PMO should populate as much of the request as possible and then send on to the project manager (or appropriate person to finalise).

Important: even if you can provide all of the information, make sure you provide this to the project manager to review and sign-off. Even if they trust you, make sure they are aware of the request and what you propose to submit.

  1. Early messaging

Project people like to plan and avoid nasty surprises – like “fire drills”. If are warned that a request will be coming, try to brief the project teams so that they are aware. While “fire drills” are typically unannounced and out of the blue, sometimes a PMO may start to pick up on themes emerging that may result in requests being made.

As soon as you are aware or sense a theme, communicate to the project teams. This must be done in a structured way as you do not want the teams to rush off and take action before the full details of the request are available.

  1. Consistent messaging

When a request has been made, it is important that there is consistent messaging from all team members. If a deadline has been set for submissions, make sure that all team members communicate the same timeline. It is not helpful if different deadlines are being communicated. This will confuse people and make them not trust the dates being set. This will typically result in missed deadlines.

Make sure that all teams are clear on what is expected. Publish clear guidance as this will help the teams respond. This is all linked to the theme of trying to add value and help ease the pain on the project teams. Do not simply forward the request to the project teams without reviewing and providing clarity.

Summary

It will never be possible to eliminate “project fire drills”.   So the next best thing is to have an established method to deal with the requests. The 4 steps listed above are a good base to form your own plan that will mean that you and your PMO will provide more value to your organisation.

Checklist for rolling out a PMO process

Roll out checklistThe PMO is responsible for ensuring that PMO processes and templates are being used across each project and / or programme within their scope.  This helps ensure standardisation that in turn should help improve the management and monitoring.

A PMO can invest a lot of time and effort in designing and developing a new process.  However, if it is not used correctly (or even not at all), the return on the investment of time is minimal.  Therefore, the process of rolling out a new PMO process does need planning if it is going to be effective.

Below is a check list of what should be considered to achieve a successful rollout of a new process.

1.Confirm objective and need

This is very important.  You should only look to develop and implement a new or updated process if there is a clear objective and need.  If not you may invest time and effort in a process that will not be used as it will be seen as being bureaucratic.  This is not a good use of anyone’s time nor will it reflect well on your PMO.

When you are clear on the problem being solved.  It is worth testing the concept with friendly stakeholders across the project.  This will allow for validation and refinement.

2. Advance warning

This step may not always be possible.

Where possible, provide advance warning to the stakeholders across the projects that the new or changed process is coming.  This will help when it comes the time to rollout the process.  It also gives people an opportunity to raise any early concerns.  This may be a very useful source of challenges across the project that the new process will help address.

Capturing these and incorporating them into the design will help ensure the process provides value.  It also helps avoid a lot of re-work at the time of rollout.

You will also find that there will be stakeholders who will ask to be involved in the design phase.  This is good as it provides you with the people to help in any pilots.

3. Develop PMO process and template

With the objective and need, you can start work on developing the process and any templates.  The aim is to keep the process simple and to avoid adding any step or data point that is not needed.

Review the process and template against the original objectives to make sure it addresses the need.  Again, test the proposal with friendly stakeholders and amend as appropriate.

4. Schedule communication and training sessions

Before you rollout the new processes and templates, take time to develop training material and training sessions with the people who will need to use the new process.  This will build on the advance communication and help ensure that all users understand:

  • Objectives and need
  • Overview of the process and supporting templates
  • How and when they should be used
  • Opportunity to ask questions
  • Timeline for rollout

5. Rollout PMO process and templates

This is the last step.  If all of the previous steps have been followed it should not be a surprise and should be fit for purpose.

The rollout should clearly communicate when the new process should start to be used and what support is available.

All process, templates and training material should be made available.

6. Continuous improvement

When a new process is implemented, it is common that adjustments will need to be made.  Make sure the users know how to provide feedback.  It is also a good idea to set a period where you will gather feedback and then make changes and issue a consolidated update as opposed to re-acting to each item and issuing multiple revisions.

Summary

Following the steps above will provide a solid framework for rolling out processes and templates for your PMO.  You can find additional information in the post on “Are your processes embedded and BAU?“.

 

 

PMO Business Case Review Checklist (plus free template checklist download)

For any project to have a chance for success, it is important to start with a solid foundation. A key part of this is to have a robust business case that has been agreed, and signed off by the sponsor(s). For more information on why this is important view post 5 reasons why a project should have a business case (you may also want to take a look at the post Why sponsors do not want their project to have a business case).

Example of PMO Business Case Review Checklist

The reason for the business case is to ensure that the project has been though through and a credible case developed that makes sense. This means the business case should have a good idea what will be done, the cost, the benefits and if it can be achieved.

A PMO can play a valuable role in helping to ensure that the business case is robust by performing reviews ahead of any formal review and sign-off. This is a worthwhile exercise as it helps improve the quality of the case. The project manager should view this as a positive as opposed to a hindrance as it is far better to catch potential issues in a less formal review so that changes can be made to give the case a better chance of approval.

This review can be greatly assisted by using a checklist. This will help to ensure that important areas are considered. While not an exhaustive list, areas for consideration include:

Alignment to strategy

Resource, time and budget are typically scarce. Therefore, they should only be invested on business cases that help move an organisation in the required direction.

Solution

There must be confidence that the solution has been considered and that it can be clearly explained.

Risk

Very important. How much risk is in the solution? A business case with a high payback but very high risk may not be delivered. Understanding the risk is an important part of the decision.

Buy-in

It does not matter how compelling and good the business case is, without “buy-in” the project is destined to failure.

Resources

Projects are delivered by people. So a check must be made that resources will be made available and that they have the required skills.

Budget

A project will need investment. The budget must be agreed and allocated if the project is to deliver to agreed timelines. Slow budget approval can seriously damage progression.

Return on Investment (benefits)

Most business cases, unless they are mandatory / regulatory type changes, should have some form of benefits. These must be clearly defined to allow a considered investment decision.

Technology

Most projects involve some form of technology change. It is important to understand what technology will be used, if it is new or established, hardware requirements, etc. New untested technology can be very high risk.

Summary

The above checklist gives some ideas on areas of the business case that should be tested. This is not an exhaustive list and you should add other areas applicable to your organisation. The aim is to conduct a thorough review to help improve the business case.

Free PMO / Project Business Case Review Checklist

You can download a free checklist template that you can update and use. It does contain a number of questions you may wish to ask against each of the headings listed above.

Download Free PMO Business Case Checklist TemplateIf you find it useful please can you share your appreciation by using the social media links on this page.

PMO closure checklist

Closed signWhen a project comes to an end, one of the steps will be to close the PMO supporting the project. The reason being that the services are no longer required and the resources can deliver more value by being redeployed.

In the same way that there is a process for project closure, the same applies for a PMO. It is important that the closure is conducted in a structured way.
Below is a checklist of key steps that should form part of the PMO closure.

1. Resource Management

This is the most important item. There must be a defined approach for the roll-off of resources from the PMO. It is rare for the entire PMO team to finish on the same day. What typically happens is that the team reduces over a period of time. This is logical as the requirements from the project should also be reducing as it nears closure.

The plan can be a simple table listing each resource, their role and planned roll-off. For contractors, it is helpful to include the contract end date as this may influence when a resource is rolled-off.

As part of the planning, it is important to consider the skills and knowledge for each resource. There will be resources that it is important to retain for the benefit of the organization. Therefore, those resources must be identified and action taken to find new roles to retain the knowledge. Important: do not wait until the PMO closure to think about how the resources will be deployed as it normally takes some time to reallocate resources. It is also important to let people know that you wish to retain them, especially if they have important skills, otherwise they may find a new role themselves outside of the organization.

2. PMO Review

The project closure process aims to collect what went well and what could have been done better. The same applies to the PMO. A review should be completed on what went well with the aim that the other PMO’s in the organization can benefit.

In a similar way, what did not go well should be understood. The aim being that other PMO’s can make changes and improve the outcomes.

3. Knowledge Transfer

Linked closely to the PMO Review, it is important that knowledge is transferred and retained by the organization. This helps maximize the benefit from the investment.

The PMO may have developed templates, processes, presentations, Sharepoints, etc. This information should be stored in a way that makes it accessible to other PMO’s. A readymade set of PMO templates and processes will help speed up the mobilization of other PMO’s.

4. House Keeping

This means making sure that all outstanding items are either closed or transferred. For example, it is good practice to make sure that all projects are closed (i.e. risks, issues, dependencies, milestones, change controls, etc). Final status reports completed and project officially closed.

It maybe that there are still outstanding benefits to be realized from the project. Therefore, arrangements need to be made to transfer the tracking to ensure that they are not forgotten and the benefits are realized.

Summary

The above provides a number of key points that need to be considered when closing a PMO. By having a structured approach it should help ensure that key resources and knowledge are retained.

Gaining support for a PMO

Man with PMO business caseYou may have been asked to set up a PMO or, you may have a strong desire to set a PMO up for your organisation as you believe (know) that it can deliver value. Unfortunately, many will not have the same view and this will greatly hinder or even stop the journey of setting up the PMO.

This is a real shame as organisations with a PMO typically enjoy a higher success rate than those who do not. Interestingly the Global State of the PMO: An Analysis for 2015 by ESI found that PMO’s still use classic indicators to measure success based on budget and delivery as opposed to using metrics to demonstrate the value delivered by the PMO. This in turn means that the senior management level (72% in the survey responses), continues to question the value delivered by a PMO.

The takeaway is that anyone embarking on securing approval to set up a PMO, must ensure that they win the support of all key stakeholders. When you think about this, it is no different to securing the support and funding for a project. If the business case does not make sense, you would not approve the project to proceed. The same principle applies to the PMO.
Therefore, it is critical to have a clear structured approach on how you are going to secure the support and funding for your PMO.

Business Need

Every business case must start with a business need. What is the problem that you intend to solve? Why will solving this problem help? Asking and answering these questions will help focus why you need your PMO.

Important: While tempting, do not try to set up a PMO if there is not a need. This does not equate to value for your organisation.

Examples may be:

  • Standardization of process
  • Independent view of status
  • Improved rigour
  • Faster mobilization
  • Improved delivery against business case.

Further information can be found in the post, What is the benefit of a PMO.

Build the PMO Business Case

It is important to clearly articulate the need and benefits of a PMO in the form of a business proposal or business case. This can be in the form of a standard business case template or a presentation.

Tip: it is important to know what format resonates best with the stakeholder(s) that you need to convince to provide their support. For example, if you know that they respond better to presentations, you may need to prepare the standard business case template and then take the key points and prepare a Powerpoint presentation. Yes, this is extra work. However, if it helps the stakeholders to connect with the proposal, it is worth the investment of time.
The art is to present the compelling reasons why the organisation needs a PMO. If you have done your homework, it should be easy for them to say “yes”.

Define what success will look like

This helps to ensure that you secure the support. You should look to convey what the sponsor can expect if the PMO is implemented. How it will make things better for them. To give this weight, it is important to define what measures will be used to demonstrate success. This makes it real and shows that you are confident with your proposal.

Build Support

While the sponsors may be providing the ultimate support and funding, there will be many stakeholders with a vested in the PMO being a success (or not). Make sure that you have identified those key stakeholders and invest time ensuring they understand what you are trying to achieve. How it will help them and be sure to address any questions or concerns.
Doing this ahead of the final approval will help that the sponsors hear positive feedback. It is also important that you act quickly to address and negative messages that you may hear directly or, more commonly, indirectly.

More information can be found in the post, PMO Stakeholder Analysis.

Summary

Following these steps should help to construct a solid business case and secure the support of sponsors and stakeholders. This is important as without this support, it will be very difficult, if not impossible to achieve your objective of setting up a PMO.

Why as a PMO professional you should sometimes say “no”!

Before everyone working within a PMO starts saying “no” to every request that comes their way, below is a true story that demonstrates the right way to say “no”.

There were 2 senior project managers, they will simply be referred to as Project Manager A and Project Manager B. Both had a lot of experience delivering large projects and dealing with senior stakeholders. However, discussions with the Business stakeholders was very revealing.  The perception of Project Manager A was that he never delivered, always went over budget and therefore was not very good. In stark contrast they thought that Project Manager B always met timelines, over delivered and was therefore very good.

This was somewhat puzzling as upon reviewing the projects they worked on, their delivery records were similar. This required further investigation. What was very revealing.
Project Manager A had a style where he never appeared to write anything down, sometimes he did not even open his note book in a meeting. This gave the perception that he was not paying attention. As such there was a tendency to agree to extra scope without knowing if it could be accommodated and the possible impact.

Project Manager B always captured the information and then played it back to the stakeholder for confirmation. Scope was never taken on-board without the appropriate analysis and the initial answer to the request was typically “no”.

So, you may wonder how they both delivered to the same level but with such different perceptions from the stakeholders?

Take moment to look at this diagram below.

project plan showing 2 deliveries

As you can see that while both project managers delivered to the same level, Project Manager A had promised much more while, because of saying “No”, project manager was perceived to have over delivered. If Project Manager A had said “No”, he would have also been seen to over deliver.

This real life example illustrates an important point. It is the natural working style of many PMO professionals to want to help and take on more work. However, it is counter productive to tell the different stakeholders that you will take on work, enhance reporting functionality, etc and then fail to deliver. This only serves to create the perception that the PMO is not doing a good job.

So, it is important to adopt a structured approach for taking work into your PMO.

1. Does the work really belong with the PMO?

Important one to watch. Many projects will look to push work they do not want to do into the PMO. Make sure you check it is legitimate and belongs in the PMO. As soon as you take it on (even just to help), the perception will be that you are accountable and that it is nothing to do with the project manager.

2. Capture and Document Requests

Keep a list of the requests, especially where enhancements are needed i.e. such as when new reports are required. Conduct the proposer impact analysis and work out if the request is valid, if not let the requester know that it will not be taken on and the reason. Estimate effort. This will allow the work to be scheduled. The schedule should be communicated to stakeholders to manage expectations.

3. Deliver Changes to Agreed Schedule

If you commit to make changes / take on work by a specific date, make sure you meet the deadline. If timelines are slipping, let the stakeholders know as soon as possible (ideally providing a solution at the same time).

Finally…..

It is very important you say “no” in the right way. Simply saying “no” in a negative, unhelpful way will not win friends. When a request is made, listen, let the requester know that you can not commit until you have reviewed. Explain the process. These steps will ensure that you are seen as being helpful without risking over delivering.

Some simple concepts that will serve the PMO (and project teams) well.