PMO Quality Assurance part 3 – tips for scheduling PMO QA reviews

Man picking date for project reviewIn the last post, PMO Quality Assurance part 2 – prioritise projects to review it covered the approach for building an inventory of active projects and then how to prioritise the list in order to focus on the most important projects.  Now it is time to create a schedule of the project QA reviews.  However, before just starting from the top of the list and working chronologically through the calendar, there are a number of considerations to ensure maximum value and minimum interruption.

PMO QA Scheduling Considerations

1. Project Lifecycle

In order to get maximum benefit you need to time the QA review at a time where there is sufficient progress to perform QA, but not too far progressed so remediation action can be taken to correct weaknesses.

If the QA is conducted too early, many of the questions will come back as N/A (not applicable) or as a failing rating.  The project manager will quite rightly state that this is because the project is only starting to mobilise and the sponsor will see the QA as a waste of time and money.

If the QA is conducted too late, there may not be time to make interventions to change the course of the project meaning that the QA is a waste as, while you know there is an issue, there is very little can be done to make corrections.

So, the best approach is to work with the project manager to identify appropriate checkpoints where it will be sensible to conduct the reviews.  This is normally as a project moves from one phase of delivery to the next i.e. completion of mobilisation, analysis / design, build, etc.

2. Avoid Critical Points

There will be times for the project team when there will be many other competing priorities for the scarce commodity time.  For example, when the project team is working flat out to complete the analysis phase to a hard deadline.  The last thing they need is for the PMO trying to conduct a QA review.  This will result in effort being diverted to work on the QA review meaning the completion on the analysis phase may be missed.  That would not be a good for the career progression of the PMO manager who scheduled the review.

3. PMO Bandwidth

Likewise, there will be busy periods for PMO activity.  The PMO should avoid putting themselves under pressure of having to complete multi deliverable’s simultaneously as this usually results in inferior output.

4. Sponsor / Stakeholder Input

It is always worth getting input from the sponsor and / or stakeholders.  These are the people ultimately responsible for the successful delivery, providing funding and the most interest in the (successful) results.  Therefore, it is only right that they should have input when they would like reviews conducted to give them confidence in the outcomes.

Finally….

Like with most things when it comes to project delivery and the PMO, use common sense as part of the decision process.   The next post will cover the mechanics of the QA review.

PMO Quality Assurance part 2 – prioritise projects to review

sign showing prioritiseIn the last post, PMO Quality Assurance part 1, it covered the fact that designing and building a PMO is only part of the journey.  After you have invested all of that time, effort, money and emotion, you need to ensure that the PMO is effective and the tools and processes used.  If not, not a very good return on investment!

A good way to ensure this is for the PMO to establish a quality assurance (QA) review process.  However, a formal QA process will take time to design, implement and execute each review.  As PMO’s typically are run on a very lean basis, this can mean that there is not sufficient bandwidth to execute QA reviews of all the projects.  Therefore, it is important for the PMO to prioritise what projects should be reviewed.

Project prioritisation for QA review

Inventory of projects

First step, you will need an inventory of the projects for which the PMO has oversight.  If you have already established the regular reporting and dashboard routines you should already have the inventory.  If not, complete and exercise to gather all of the projects.

Prioritise Projects

Take the inventory of projects and then prioritise with the most important at the top and least important at the bottom.  My suggestion is to create the prioritised list by applying a standard set of criteria so that all projects are considered on the same basis.

Criteria that can be applied:

  • Complexity – how complex is the project.  New or existing technology, etc
  • Resources – how many resources are required.  Skill sets
  • Duration – length of project (multi year have more chance of challenges)
  • Impact – client / financial / regulatory impact high risk
  • Budget – larger budget usually indicates higher level of focus required
  • Benefits – projects with higher benefits, better return on investment should have more attention

By applying criteria like listed above will provide an initial prioritised list.  This should then be sense checked to make sure that the priorities make sense.

Review list of prioritised projects with sponsor / steering committee

The prioritised list of projects should then be reviewed with the sponsors and / or steering committee.  This will allow them to provide further insights and you may find that there are projects that, based on criteria are low / medium but are important to sponsors so they asked them to be raised in priority.  This is OK as the purpose of QA is to focus attention on the projects important to the organisation.

You will now have an agreed list of projects to prioritise for the QA reviews.

The next post will cover important considerations for scheduling the QA reviews.

PMO quality assurance part 1

quality assured badgeYou have invested valuable time, money and emotion into designing and constructing a PMO.  The tools and processes have been created and published to the project managers.  Sessions have been held with the project teams to ensure they understand how to use the tools and what is expected.  So what is the reward for the hard working PMO manager?  The next big challenge!

After you have mobilised your PMO, the next challenge is ensuring that the project teams effectively use the tools and processes that have been implemented so as to provide maximum benefit.  If not all that investment will go to waste and the risk to successful delivery will increase.

The following can be used to help ensure that the PMO tools are used and add value.

1. Submission Reviews

Part of the role of the PMO is to review all of the regular submissions for quality and ensure that they make sense.  This should be the first step to ensure that the tools are being used to control the project and provide an accurate representation of status.  The review should ensure that the tools are being correctly completed AND that any commentary reflects RAG status, etc.  For example,  if the commentary reads “delays to xyz milestone due to critical resource not being available” yet the RAG status is Green, this is a mismatch and needs to be questioned.

Don’t be afraid in your role as the PMO to raise questions and ask for submissions to be updated.  Part of your role is to ensure that any emerging themes are quickly identified and made visible to stakeholders, allowing them to make an informed decision.

2. Regular Catch-up Meetings

It is a good idea where possible to schedule regular catch up point meetings with the project manager.  This will help build a good working relationship and allow for a better understanding of the workings of the project.  This means the PMO can add more value by identifying where a submission does not include important information (this includes successes that are not being celebrated).

The meetings should be scheduled just after the submissions are due as this then allows for a joint review and any changes agreed.

3. PMO Quality Assurance (QA) Review

PMO QA reviews are a formal review of a project with the objective to identify areas that may prevent a project delivering the stated objectives.  The review is usually at the request of the sponsor who wants an independent check that the project is set-up for success.

The review is typically conducted following a structured approach to test the set-up of the project across the key dimensions:

  • Strategy & Business Objectives
  • Scope
  • Governance & Sponsorship
  • Planning
  • Budget
  • Benefits
  • Resources
  • Risk Management
  • Change Management
  • Communication

The review is fact based and will identify strengths and weaknesses in the project.  The findings and recommendations are then agreed and tracked so that any weaknesses are addressed.  By doing this, it should improve the probability of success.

The next post will provide more information on the steps for conducting a PMO QA review.

How to challenge a project manager who does not adhere to PMO governance

If you were to conduct a survey of PMO professionals, the issue of project managers not adhering to governance and processes would be one of the common findings.  Many PMO practitioners would claim that this non adherence results in many wasted hours of chasing the project managers and a number of confrontations.

Before looking at techniques to address this, it is worth understanding why the project manager does not comply.

Understanding

It can be as simple that the project manager was not aware or understand what was expected, this is particularly true for new joiners or contract / consultant resources who may not be aware of the organisations methodology and approach to change delivery.

Communication of Governance Processes

Now at this point a number of you are thinking “but I did tell them what was required”.  I am sure this is true.  However, take a moment to think how it was communicated.

  • Did you issue an e-mail to all the project managers with a very large Powerpoint attached within which, slide 73 explained the reporting cycle?
  • Did you meet the project and then only make a vague passing comment on what was required without being specific?
  • Did you check to see that the message had been received and understood – classic send, receive, check communication process?

Too Busy

By the very nature of the job, project managers are very busy.  Their number one priority is to deliver the project to the agreed business case.  This means that they need to jump on every emerging risk and issue early.  So they have received the message and know what is expected.  However, they often sacrifice adherence to governance as it is deemed (wrongly) not as important.

Don’t Want to Comply

T-shirt with I hear you but I am not listeningThere are a small group of project managers who have received the message, understand what is required, have the time BUT still not adhere.  The reason being that they see PMO governance as an unnecessary overhead that adds no value.  Or the PMO does not know what they are doing and they decide that they will use their own approach and governance process.

So what can you do to address these common themes in order to be successful?

Understanding

The first step is to make sure that you and your team understand the governance process and test to make sure that the process is required and adds value.  If it does not revise or eliminate.  By doing this you and your team will be confident in articulating the key points and more importantly why they are required.

Communication

Spend time building a communication plan of the governance processes.  This should include the target of audience, method of communication and material.  If you do have large documents that contain all the information, spend time producing brief summary packs that make it easy to understand the key aspects including what you expect the project manager to do by when.  They still should be given the large pack.  However, this should be for them to delve into for targeted information that they are after.

The ideal method of delivery is to sit down and meet face to face.  This will allow you to deliver the key messages and check that they have been understood.  The project manager will then be able to ask questions for clarification.

If you have no other option but to deliver the guidance by e-mail, take time to make sure the e-mail is clear and to the point.  Ensure that there is clear direction on where they will find the important information and what is expected from them.  When using e-mail I like to include an ‘Action Required’ heading so it is clear.

Make sure that you close the e-mail with how they can get further information and assistance.  You should also follow up after sending the e-mail with each project manager to make sure they have received the e-mail, ask if they have any questions and confirm they understand what is expected.  Don’t think just because you have sent the e-mail and, perhaps, see a read receipt, that they will obey.

Another reason for meeting or talking to the project manager is that you can ask them if they see any challenges in complying / completing the required tasks in the required time frame.  Then, if they say they have challenges, you can deal with them early.

Too Busy

The project manager may say quite fairly they are too busy.  You should respect this statement (after understanding the reason for them being too busy in a nice way).  Then, remind them that the governance process is important to the organisation and will help them with their delivery and ask them for suggestions how they would like to address the governance requirements.

Make sure you take whatever steps you can to make this easy for them.  So if you and the PMO team can put some prep work in for the project manager, offer to do this as it will demonstrate you want to help.  This will make them more likely to make the time going forward.  Word of warning, while you can offer support, DO NOT take ownership – you may be held responsible when something does not go to plan!

Do Not Want to Comply

Always the hardest and, unfortunately, can not always be solved.  Take all the steps detailed and as described within Too Busy, offer as much support as you can.  If the project manager still insists on ignoring the requests, you can take the subtle approach of publishing reports without the updates.  Senior management will soon ask where the updates are.  Likewise, peer pressure may persuade the right behaviour.  For this to work you need over 80% of the other project managers to be providing their updates.

If all of this fails you will need to escalate.  This is why it is important that you have a strong PMO sponsor.

Summary

Non adherence to PMO governance processes will be a challenge that will always be with the PMO.  The steps above will help to try to reduce the time and effort to gain adherence.

5 steps for running a dependency workshop

Running a project dependency workshopThe last post covered 5 activities that are needed for a dependency management process.  This included the important step of validating dependencies as, without confirming between the “giver” and the “receiver”, there is a high chance the dependency will not be honoured.

There are different ways of validating dependencies.  This post will focus on the dependency workshop sometimes known as “dependency clearing house”.

Purpose

The purpose of the “clearing house” is simple.  It is to openly validate all known dependencies between the relevant parties (givers and receivers).  Doing this in a workshop format allows for the process to be accelerated and, interested parties to contribute to the discussion.  The result is dependencies that have been well defined and agreed.

1. Capture and tidy known dependencies

Before you can validate dependencies using a workshop (or any method), you do need to complete the up front work, the preparation.  Most importantly the capture of known dependencies, ideally in a common format.

Th PMO can add considerable value by driving this process.  Contacting all stakeholders and requesting inputs.  Making sure submission deadlines are met.  Reviewing and validating the quality of inputs.

The goal is a list of the known dependencies that have been cleansed and clearly articulate the requirement.  It must include who is expected to deliver the dependency – the “giver”.

2. Define attendees and set-up meeting

In parallel to step 1, the dependency workshop should be set-up.  This involves identifying who needs to attend to ensure full representation.  Care should be taken on ensuring that the person attending has the knowledge and authority to agree dependencies.  It is not very productive if the person attending has to take a large amount of items away as actions.

Based on who should attend, a suitable room should be booked (including required facilities – wipe board, flip chart, projector, etc).  The invites should be sent out early to ensure the required person can attend.  The invite should include an agenda and proposed approach.

Where possible send the cleansed list of dependencies.  If this is not possible, send out the invite and advise that the dependencies will be issued separately.  Where this is the case, make sure the list is sent out in plenty of time ahead of the workshop (at least 48 hours) to give the attendees time to discus with their teams to collect feedback.  DO NOT send out 20 minutes before the meeting as this will greatly reduce what can be achieved in the session.

3. Dependency workshop

The workshop should be run to the agreed agenda and start with introductions (why people are in the room) and the approach.

Each area should then talk through where they have dependencies on others.  They should clearly articulate the need and the impact if the dependency is not delivered.  This will then allow the attendees to discus and ask questions, even challenge the need of the dependency and / or due date.

The facilitator should be mindful not to let discussions take too much time so as to ensure all dependencies can be covered.  The facilitator should draw each discussion to a close with the following outcome:

  • Dependency agreed (deliverable and date)
  • Dependency removed (i.e. all parties agree no longer required)
  • Dependency not agreed (i.e. still required but agreement can not be reached)

Where dependencies can not be agreed, the facilitator must ensure that there is a clear owner to resolve outside of the session.  The action should have a target date for resolution.

4. Update dependencies, publish and validate

At the end of the workshop, the PMO can capture the refreshed data.  This should then be shared with all attendees for review and sign-off.  Again set a date for sign-off.

Similarly, the PMO should follow up on the non agreed items to make sure they are progressed.  When they are complete, they should be updated in the dependency register and circulated.

5. Repeat process

Like with so many things in project management, these are not one off events.  To truly give the best chance of delivery, dependencies should be reviewed on a regular basis.  It may not be necessary to run full workshops on a regular basis.  However, the agreed list of dependencies should be maintained and, where necessary targeted sessions with subsets to ensure all is aligned.

In summary

  • Dependency workshops are effective to quickly validate dependencies
  • Preparation is critical – quality of dependencies / workshop logistics
  • Meeting must include people with knowledge and authority
  • All dependencies should result in agreed, removed, not agreed with further work
  • Data should be updated and distributed
  • Repeat the process

Following these steps will help improve the management of project dependencies with the PMO playing a valuable role.

5 activities you need to manage project dependencies

managing project dependneciesIn a perfect world, every project would exist a bubble where there were no constraints. All required resources (people, budget, facilities, technology, etc) would be available to suit the timelines defined by the project. Unfortunately, most of us do not have the benefit of this type of “bubble”. Therefore, the outcome of the project is very dependent on the availability of resources.
Due to this, it is important that there is a structured approach to the identification and management of dependencies. This is where a pro-active PMO can take the lead to help minimise the impact of these dependencies.

Here are 5 activities that the PMO can take a lead to help implement a structured approach to dependency management.

1. Common Understanding

Before embarking on the capture and validation of dependencies, it is important that there is a common understanding what is meant by a dependency. Even if the projects and programmes that the PMO has oversight is staffed by experienced project managers, do not assume that they fully understand what is meant by dependency management.

Make sure that there is a clear, agreed definition. This should be written down and communicated ensuring the common understanding.

It is also important to define a standard process. Dependencies often span different projects. Therefore, all participants must be clear of the process so that dependencies can be captured and communicated.

2. Plans

Before you can start to identify and manage dependencies, you must have a plan. The plan must be constructed to sufficient level with milestones that denote deliverables. These are needed as a dependency should be linked to milestones.

3. Identification

Using the defined process, each project manager needs to identify the dependencies for their project. This can be achieved by the project manager sitting down, reviewing the plan and documenting potential dependencies.

A better approach is to run a dependency identification session. This typically will involve getting a group of people into a workshop who understand the project and / or subject matter.

The aim of the session is for the collective group to identify all possible dependencies. The real power is that as the session is interactive, this will result in people generating additional dependencies building on items identified by others. It also allows for points to be discussed and decisions made if they are true dependencies or not.

For this to work, the session must include the appropriate participants. If the project involves technology, make sure they are represented. The same applies for the Business, Operations, Finance, Legal, etc.

All dependencies should be captured into the defined dependency tool and MUST include who is responsible for delivering the dependency to the project.

4. Validation

After the dependencies have been identified, it is important that these are validated. Until this has happened, there is no commitment that the dependency will be met.

The process can be simply summarised as the following:

The giver (person / project) providing the deliverable and the Receiver (project) who needs the deliverable by a set date.

The dependencies can be validated by a number of methods including:

• Discussion / meeting between both parties
• E-mail agreement

However, if there is a number of dependencies, it can be worthwhile the PMO setting up a dependencies clearing house. This is a meeting with all relevant parities. All of the dependencies are then discussed, agreed or rejected. As with the identification workshop, it allows for collective discussion that helps improve the quality of the information.

5. Continuous Management

It is important, like with most PMO activities, that the identification and validation is not seen as a single, one-off event. While the project may hold a session to identify dependencies near the start of a project. The reality is that dependencies can occur through-out the life cycle of a project. As circumstances change for the project and / or external environment, dependencies will change. Therefore, it is important that the project reviews dependencies on a continuous basis.
The PMO can play a role it making sure that this discipline is followed. By conducting periodic reviews either formally or informally of the dependency registers, this will drive the project to get into a routine of pro-actively managing dependencies.

Summary

• Dependencies are important as they have the ability to stop a project delivering.
• The PMO should take the lead in defining the process and driving the quality of the dependencies that are captured.
• All dependencies must be validated and agreed by both the Giver and Receiver, if not there is a risk the dependency will not be met.
• Management is a continuous process to be effective NOT a one of event at the start of the project.

Challenges to a PMO offshore model

pmo challenges in an offshore modelThe last post, Benefits of an offshore PMO model, covered some of the reasons for adopting an offshore model. This post will cover the challenges.

When off-shoring started to become popular in the late 90′s early 00′s, the main metric used by senior management was the cost per FTE (full time equivalent).  It is very difficult to get past the headline figure that a resource with the same skill set could cost 33% or 25% of a similar onshore resource.  However, this view was short sighted and many other factors that should have been considered were not.  The result being that the saving, service, etc was not as anticipated and in some cases, resulted in work being moved back on shore.

Challenges

1. Context

This step is missed so many times but makes a real difference to the success.  Most people like to have a (high level) understanding of what is being completed and the overall purpose / goal.  This provides a frame of reference to where the tasks being requested fit into the overall process.  By not providing this, it can make it more difficult for the tasks to be understood and reduces the opportunity for the offshore team to make improvement suggestions.  Otherwise, there is a risk that tasks may be completed in a way that is counter productive to the overall objective.

Always take the time to provide the context to all new team members.  Where possible arrange for the offshore team to spend time with the onshore team.  Seeing the working environment first hand will help with the understanding of what is required and the dynamics of the working environment.

2. Poorly Defined Operational Requirements

To make an offshore model work, it is very important that the requirements are clearly documented.  This includes process flows and roles & responsibilities.  All aspects of the operational process i.e. creating milestone reports from the central plan data, need to be documented.  You need to have a comprehensive, step by step guide so that in theory anyone could pick up the manual and, subject to having appropriate system access, execute the procedures.

This requires discipline from the onshore process owners to take the time and ensure that the process is captured, reviewed and refined.  This then needs to be updated on an ongoing basis (especially where process spans on / offshore teams).  In many industries there is a requirement from regulators that up to date operational manuals are maintained so this is not just for offshore teams.

3. Migrating “Broken” Processes

In many cases the existing onshore process is not fit for purpose.  However, when a decision is taken to offshore, the exact same process is migrated.  This type of move is sometimes referred to “lift and shift”.  While it reduces the time to move the process, it does mean that a potentially “broken” process is moved.  For example, the process may be failing onshore, so why move the same process offshore?  The process should be reviewed, considering the fact it will be off-shored, and processes fixed, additional requirements added and those no longer required removed.

The challenge on this is that it is soon forgotten that the process was not working onshore.  Blame is automatically placed on the off-shoring, even though the problem existed for years.  Make sure that problems are addressed or at a minimum documented with clear plan so that expectations are managed.

4. Communication

Usually most off-shore centres have a different primary language to the onshore location.  This means that the precise use of language is required to ensure correct understanding.  If not results will not be as expected.

Avoid using acronyms or colloquialism as they will not be understood.  Try to use clear, straight forward language to explain each step in a process.  Request that the off-shore team explain their understanding as this is a very good way to check understanding.

5. Culture

This is important and often over looked.  There are great differences between regions, countries, etc even for the same organisation.  If you do not understand, you may be disappointed with outcomes.  For example, in Asia you may not be challenged and told that a task can not be completed to the required timescale, especially if the request comes from a more senior resource onshore.  The result is that the deadline will arrive and the task will not be completed.

You must take the time to understand the ways of working.  Then you can ensure to ask questions to allow the team to tell you what can or, more importantly, can not be achieved.  This is also important if you are looking for the offshore team to take a lead in improving processes.  Create an environment where everyone feels that they can be honest.

6. Resistance

Many senior managers encourage and support off-shoring until it involves work close to them.  Suddenly they will be explaining why their processes are complicated and need on remain onshore.  This is very common as people do not want to feel they are losing control.  In this case it is important to explain the process and demonstrate the controls in place for orderly migration with agreed check points.  It is a good idea to start with a pilot that involves less critical activity.

You also will have resistance from the onshore resources whose work is being migrated.  They naturally will be worried if they will have a role at the end of the migration.  In some cases they will, in others they will not.  In both cases open and honest communication on a continual basis is required.  Where there roles will change, explain the journey and what will be expected.  If the role onshore will be demised, explain options, consider retention bonuses, etc.  In all cases remember it is a fellow human being and treat them how you would like to be treated with respect.

Summary

Implementing an off-shore model and migrating activity is challenging.  It needs to be done in a professional, structured and caring way.  All team members must be made to feel included and that their input is valued.  Attention to detail is very important.  Do not assume that the gaps in process will be filled, if it is not in the operations manual it will not.

While challenging, investing the time will yield results.

Benefits of an offshore PMO model

benefits offshore pmoThis post will cover the benefits of an offshore PMO model as it can provide many efficiencies in both time and money.

Offshore PMO Benefits

1. Cost Reduction

This is probably the primary driver for most organisations to offshore.  The great improvements in technology and communication now mean that it is possible for resources to work effectively from almost anywhere.  If you take a moment, I imagine that many of the organisations that you work for have the infrastructure to work remotely by being able to access the network using a secure link through an internet browser.  This means that all you need is a laptop with internet connection and you can access your organisations network.

Given that connectivity is no longer an expensive barrier, organisations can take advantage of the natural wage arbitrage between different countries.  This means that the same skills can be secured at a lower rate resulting in a cost reduction to completing the same work.

2. Extended Working Day

Each country has the notion of what is termed the working day.  For example in the United Kingdom it is between the hours of 9am to 5pm, often known as the “9 to 5″.  The reality is that many work longer than these hours.  However, what this does mean that there is a set “window of time” to complete the required tasks.  Work not completed at the end of the day is usually rolled on to the next day or, workers end up staying late to complete the outstanding activities (not good for morale, work / life balance when this occurs on a consistent basis).

A global workforce, operating in different time zones means that outstanding activities can be passed to the next team to continue.  This means that the work can be completed and, in the case of projects, helps protect time lines.

3. Efficiency

This model is sometimes termed the “follow the sun” model.  I first experienced this in the 1990′s when I was working for a global investment bank.  The 3 primary locations for trading currency was Tokyo, London and New York.  At the time they had trading books in each location running independently.  However, they realised that it would be more beneficial to have a single trading book that could be passed round the globe.

This made me realise that the same principle could apply to most activity.  Software development: required enhancements could be passed to a team in India or Philippines at the end of the working day in the UK, the changes processed over night so that they were ready to test at the start of the next working day in the UK.  The result, greater efficiency as there is a significant reduction in the time the development team or testing team are waiting for work to complete.

I have been able to utilise this with a number of PMO’s I have established.  For example, reports being submitted by projects at close of business, reports reviewed and processed overnight so that there is a management pack to review progress available at the start of the next day.

4. Capacity

A common model is to build a competency of shared resources in an offshore location servicing many areas of the business.  This is a smart solution for a PMO.  Having a pool of skilled resources who understand the project methodology / framework and can execute the different processes provides the benefit of flexing capacity.  Projects move through cycles so, as one project completes, PMO resources supporting that project become available.  As they are fully trained, they can move some what seamlessly to support the next project.

Likewise, the workload can be shared across team members to cover holidays, sickness, peaks in workload, etc even if they work on different projects.  This minimises delays and produces high utilisation.  Taking the peaks in workload as an example.  There could be 2 projects, one reports week 2 in the month the other week 4.  The focus of the offshore team could be that they support the first project in week 1 and 2 then switch to the second project for week 3 and 4.

5. Mobilisation

Having a core competency offshore can greatly accelerate the mobilisation of a project.  As the project is being launched the project manager can place his support requirements into the offshore team and then quickly be provided with skilled resources who can set-up the core PMO processes.  This is a huge time saving allowing the project manager to focus on the project not building the project support function.

Summary

Investing an building an offshore PMO capability provides many benefits to an organisation that should help improve the predictability and quality while being more cost effective.  I am a strong advocate of this model.

Is a PMO role good for your career

pmo careerThe reaction to someone taking a role in a PMO is very diverse.  Some embrace working in a project management office, others feel that it is a backward step, especially project and programme managers.  Therefore, this post will spend time exploring the question if a PMO role is good for your career.

1. Exposure

Working in a PMO will usually provide access to a number of senior executives, even to Board level.  While it is possible you may have a senior executive sponsoring a project or programme you are running, within the PMO you will often find you have to engage with many.  You will be providing them with important MI about the change portfolios across the organisation.  If you build a reputation of delivering quality reporting with good insight to allow management decisions, you will be noticed.

Engaging with this type of audience will also mean you will get to understand what information they like to see.  So if you go on to take a delivery role, this will help you to prepare and run very good steering committees.

2. Discipline

It is quite common for project managers to focus on delivery.  This can come at the sacrifice of discipline.  While there are many who view process as bureaucracy, having good robust processes helps ensure that items are not missed.  I remember a senior executive in 2002 telling me. he would much sooner have a bunch of project managers delivering to the same standard as opposed to superstars who were successful some time but struck out on other occasions.  It is  all about probability of outcome.

Spending time in the PMO will help deliver a good understanding of process so that it can be embedded in future projects.

3. Understanding

The PMO has oversight across an organisation.  Working in a PMO will allow a greater understanding of the organisation, the change being executed, how it links and aligns to strategy and much more.  This information will be very helpful when the next role is taken.

4. Development

PMO’s tend to have to cover many project management skills.  Therefore, it is only natural that working in a PMO will mean that you will have the opportunity to develop and use the skills.  This may include providing mentoring and training other project resources (this is something that can be very difficult when working as a project manager in the middle of delivery).

In summary

A role in a PMO should not be seen as a backward step.  It should allow you to grow your skills, gain a better understanding of your organisation and gain exposure to senior management.  This will mean that you will become a more valuable resource to your organisation.

Working in the PMO career path can be more rewarding than the project and portfolio roles.  However, a word of warning, the type of PMO (reporting or pro-active) can make all the difference to just how rewarding it will be!

Does your PMO practice continous improvement?

graph showing improvement stepsTo design and implement a PMO can be hard work.  It obviously helps if you have set one up before or have the appropriate tools and methodology.  Therefore, it is understandable that when it is up and running, the PMO manager can think their set-up work is complete.  While this may be technically true, the reality it is not.

Up until recently there was an analogy in the UK where something could be referred to as being “like painting the Fourth Bridge“.  This is a structure spans the Firth of Forth connecting Edinburgh to Fife.  The statement comes from the (myth) that as soon as the work teams finished, they had to start again.  The PMO is similar, just because you have set it up, your are not finished, you need to ensure regular maintenance.  In fact, unlike the Forth Bridge, you should be looking to improve.

Why continuous improvement is important

A PMO needs to demonstrate and increase value.  Therefore, it makes sense for the service offering to be continually improved as part of the maturity process.  The reason being that improving the service equates to improved oversight / delivery resulting in increased value for the organisation.  So if you run or work in a PMO, always be striving to improve the service.

How to improve?

The process for continuous improvement should not be difficult or hard.  It should be practical and based on real world events.  What is important is having a structure and process to capture where improvements should be made.

Regular Reviews

Make sure that you have routines to regularly review tools and processes among the PMO team members.  The people executing the routines will know what works and what does not.

Feedback

Make sure that there is a process to capture feedback from stakeholders such as project managers, project teams, etc.  While many will volunteer information without you having to ask, others may need to b encouraged (especially more junior resources or those from cultures not used to providing feedback that can be perceived to be bad).

There are other sources.  The key is having a process that has been communicated, to capture the points as they arise.

On a regular basis, probably monthly, the PMO should review all of what has been captured and determine which ones need action.  Plans should be developed to incorporate the enhancements (note: it is advisable that changes are discussed with those who made the observation to test that the proposed changes to ensure they will make the required difference).

However be mindful of…

Allow Changes to “Bed Down”

When new processes are introduced, it can be painful and users may re-act badly if they don’t achieve the desired outcomes on day 1.  However, it is important to allow new processes to have a period to settle and resist the temptation to make changes.  It also allows other feedback to be captured.  I have often set a period of x weeks to allow the processes become stable and let people know that feedback will b captured but no changes will be made until the defined period has passed.  Obviously if something critical arises you may need to make a quick change.

Giving Notice of Changes

A common complaint from project managers is changes are advised last minute meaning everyone is under pressure to adopt the new change.  Make sure that changes are clearly communicated ahead of when they will be introduced.  Provide training and support to ensure the implementation is trouble free.  If you are moving to revised templates, the PMO can help ease the transition by copying data from the previous templates for the project teams (this is a sure way to build good working relationships).

Frequency of Change

Closely linked to the “Bed Down” point.  Do not make changes to often.  Try to have a set schedule for maintenance updates.  You may want to start with monthly and as the PMO becomes more mature move to quarterly.  This means that the stakeholders know when to expect updates.

In summary

A PMO must adopt the mindset of continuous improvement so as to increase the value it adds.  The process to capture and implement improvements should not be complicated.  Being mindful of the impact of changes, clearly communicating and supporting, will vastly improve the outcome of implementing enhancements to the service offering.