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).


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.