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.

Project inventory overview (planning next years change portfolio)

Diagram showing project planning cycleIn the 3rd and 4th quarters of a year, many organisations are planning and budgeting for the coming year.  This has to include any projects so that the budget can be secured.  This post will provide an overview how to construct a project inventory.

An organisation will undertake a number of change projects at the same time.  In a large, global organisation there could be thousands if not ten’s of thousand projects running at any given time.  Some will be small, such as report changes.  Others could be very large, multi-year projects.  This presents a challenge to many organisations.  How to track and ensure that change projects are aligned to the overall strategy.

In many cases, change will be specific to a specific function or business line and / or a location.  Therefore, it is difficult for the organisation to have a single view of all of the change activity.  This means that senior management will not have a clear sight of how the change budget is being spent, what benefits are being returned and crucially, be able to determine if the change budget is being spent wisely.

This is where an enterprise Project Management Office (PMO) can add considerable value.  The enterprise PMO should be able to link into all of the regional and local PMO’s so as to gain sight of all of the active change projects.  Even in a small organisation, having a central list of all change activity will be a benefit to management.

Objective of Project Inventory

Constructing a Project Inventory is a way for any PMO to quickly add value, especially where an organisation has not had a PMO before.  Instead of having to speak to many different functions, etc to understand all of the change, senior management can simply ask the PMO – a huge time saving.

While Project Inventory makes it sound like a complex process, it is simply a list of all active and planned projects for an organisation.  So for Project Inventory you can think “list of projects”.  So the simple objective of the Project Inventory is to capture all of the active and planned projects in a single list.

Constructing the Project Inventory

The PMO should take the lead on constructing the project inventory.  The approach can be:

  • Pull – ask all of the project teams to submit details of change projects
  • Push – create a central list and then send to project teams to review and validate

If possible I would lean towards the “Push” approach as it demonstrates that the PMO is trying to add value by taking on what work it can and then, only asking projects teams where they cannot complete the task.  This will create a positive reaction as opposed to the PMO being seen as simply making requests of the project teams and offering no support.

The reason this is important is that the project teams should be busy focusing on delivering the projects.  Therefore, a smart PMO will try to avoid making any requests that they can perform themselves without diverting the attention of the project teams.

Standard Format

Collecting the details of the projects is an important step.  However, to make the information easy to understand and compare, it should be in a standard format.  Therefore, if you decide to use either the “Push” or “Pull” approach, the PMO should spend time creating a standard template to collect the data.

While there are enterprise portfolio management tools, the simple approach is to use standard word processor or spreadsheet programmes such as Word and Excel.  I would suggest Excel as this will allow for data manipulation when you have gathered the data.  Another example of using standard programmes is that it makes it easier to share the information as most organisations use these programmes.

The template should include:

  • Project Name – recognised name used to identify project
  • Project Description – short description to allow easy understanding of project purpose
  • Project ID – <optional> used if there is an internal numbering system such as Clarity
  • Business / Function – used to indicate who the project is for
  • Location – used by global organisation to indicate regional or global
  • Investment Type – mandatory or discretionary
  • Budget – indication of approx. budget spend
  • Benefit – indication of project benefit in monetary terms
  • Comments – allows for any additional information

Collecting the above information should provide all of the information to give a high level understanding of the project.  With this information, senior management are able to make decisions on the change portfolio.

Having the information in a spreadsheet, it is possible to total the budget column, sort by Investment Type, allowing for the cost of mandatory projects to be calculated and compared against available budget.  This then will provide how much budget is available for discretionary projects.

Summary

The PMO can provide value to an organisation by collating and providing a central list of projects – the Project Inventory.  This will save management time by presenting a single list with all of the required data point to prioritise and make decisions.

Project close review

The last 3 posts have explored the different aspects of project reviews and how they can be used to improve the delivery of change. This post will cover the dimensions of a review and the types of question to ask.

Lessons Learned Template

Lessons learned mapThe actual lessons learned template should have a logical structure that covers all of the important aspects of a project. It suits a word processor or spread sheet format.
Below is designed to give ideas on how a template could be structured around logical groupings and example questions. Remember, you need to use questions that allow for open and honest discussions that do not look to assign blame. Therefore, it is important that questions and responses are factual and non-emotive.
Overview / Background

Project Objectives – this reminds those involved in the review of the original purpose and makes it more likely that feedback will be relevant and meaningful.

Scope of review – it is important to be clear of the scope of what is being reviewed so as to capture focused feedback. For example, the review may want to target the performance of the technology solution. Therefore, this would be defined in the scope and then could be used as a point of reference during the review feedback sessions (stopping people feeding back on other areas that are not applicable to the review).

Overall Performance
The first part of the review should be used to capture feedback on the high level performance of the project.

  • Project Outcome – did the project achieve the defined objectives
  • Scope – did the project deliver the documented / agreed scope
  • Schedule – did the project deliver inline with the schedule
  • Budget – did the project deliver within the allocated budget
  • Benefits – were the benefits in the signed-off business case realised?

 

All should allow the user to provide feedback and comments as well as examples to back-up any statements.

Project Processes
This should explore in detail the main project lifecycle processes. Where there have been delays / challenges, these should be captured together with underlying reasons.

Initiation

Was the project initiated quickly and efficiently?
Were there barriers to initiation
Were approvals given quickly?

Requirements / Design

Objectives clear, understood achievable
Requirements gathered to sufficient detail
Requirements accurately documented
Tasks captured and understood
Any issues gathering requirements?

Implementation

Testing plans were clear and accurate
Testing covered all functionality
Were there many defects
Were defects quickly addressed?
Was their sufficient implementation planning
Was there a back out plan
If back out was used, was it a success
Was the implementation a success
Were resources suitable trained
Were there post go-live issues?

Control

Progress was tracked against plan
Robust reporting established
Change control implemented and followed
Was there many changes? If so were there common themes
Robust governance established
SteerCo’s well attended
Was there appropriate quality control
Risks, issues and dependencies managed effectively?

Closure

Were all project objectives met
Was the project team released in a structured manner
Was all project documentation completed and archived
Did sponsor sign-off project was complete?

Project Team

While the focus is on the project team. This section should also capture any appropriate findings in respect of sponsor, stakeholders, etc that have had a positive or negative impact on the performance.

Did the team have sufficient resources
Did the team have the correct skills
Was the team recruited in line with schedule? If not what was the impact
Were resources prioritised from other projects
Were BAU resources available as required
Did the sponsor support requests and provide resources?

Depending on who is conducting the review. You can make the questions more focused:

Was the project manager, sponsor effective, etc

Budget

Did the project have sufficient budget
Was the budget approved quickly
Was the budget incorrect? If so what was the reason?

Outcomes

Did the project deliver the required outcomes
Could the outcomes be measured
What was the cause for not meeting the required outcomes?

Findings
All of the key findings from the review should be captured and consolidated within the document. Findings can be captured with the questions. However, it is helpful to consolidate the findings in a separate section with a reference to the finding in the document.
The findings can then be consolidated into themes and analysed to establish what changes should be made to existing processes (or new ones established).
They should be captured using a standard format, preferably tabular format so that they can be easily copied from each lessons learned document and transferred to a central register. This allows for output from multiple projects to be compared and then changes designed for the organisation, not just for a single project.

Summary

It is important to have a structured approach to lessons learned to give the best chance of identifying what went well and not so well in a standard way for all projects. This will allow the information to be captured and then compared against all other projects to identify themes that need to be addressed. The result should be an improvement in an organisations project delivery.

Project review at close of project

project review listThe last couple of posts have been covering the topic of project reviews and how the output can help improve the outcomes of other projects across an organisation (or even later phases of the same project).  When to conduct a lessons learned review focused on the different points where you can conduct a review.  By far the most used, is the review that is completed when a project is complete.  This post will focus on the mechanics and structure of this important process.

Preparation

It is important that the appropriate preparation takes place ahead of the review.  As with anything, if you do not prepare, the quality of output will suffer.

Approach

There should be a standard approach to conducting the lessons learned reviews.  This should ideally be owned by the PMO.   Hopefully, there will already be a defined process to use, if not you will have to spend time creating:

  • Process
  • Tools and Templates

This does not have to be overly complicated.  As you will recall, the objective is to work out what went well (so the organisation can embed and do more of the same on other projects) and what did not go well (so the organisation can identify the root cause and not repeat).

The process provides a standard approach to:

  • Review selection
  • Setting up reviews
  • Executing reviews
  • Analysing findings
  • Defining actions to embed change

Process

This should detail the end to end flow of the process:

  • Overview: provides context of process – useful for senior management
  • Detail: builds on the overview to explain detailed steps of the process
  • Templates: to be used to execute the review process

Review Selection

This will define the criteria for selecting when a review should be conducted on a project.  This will normally be at the end of the project.  However, as mentioned in the last document, this may be at other key phases.

The selection criteria is important as it sets a clear policy across an organisation as to when reviews must be conducted.  This ensures common understanding and allows delivery teams to include in their plans as a formal milestone.  It also educates the organisation and embeds the process i.e. senior management will start asking for the output of the reviews.

Setting up Reviews

With a clearly defined policy, the delivery team should plan the required reviews into the project schedule.  This should be done pragmatically as the purpose is to provide benefit to the project and wider organisation.  Reviews should not be scheduled just because it is stated in the policy.

For example, a review may naturally take place at the end of phase for a multi phase project.  If delivery team is also scheduled to be holding a planning workshop, at a 5 day offsite, for the next phase, move the review earlier or later.

Likewise, if the review is scheduled for 2 weeks after a new system has been implemented, it may be wise to delay to later.  This will allow the team to deal with any production issues, and provide more time for issues and benefits from the project to develop.

Executing the Review

It is important that all of the review sessions are scheduled ahead of time and any supporting information / templates issued.  This is especially important for senior members of staff as their diaries ten to be very difficult to secure time at short notice.

If the approach is to hold a lessons learned workshop, there may be a requirement for inputs to be prepared and gathered ahead of the session.  Make sure that all participants have sufficient time to complete and return the lesson learned template.  This will allow time for the data to be consolidated and any themes identified.

If the information has been gathered and consolidated ahead of the workshop, the information should be packaged so that it can be used to drive the session.

  • Review / discus themes
  • Reach agreement on themes and underlying root cause
  • Review and agree what has been learned
  • Agree practical steps to embed learnings

It is possible for a number of the workshop steps to be completed ahead of the workshop.  However, I find it very helpful to discuss and agree as a group so as to ensure alignment.  It also often leads to additional ideas.

Analysing Findings

The agreed findings and next steps from the workshop should be reviewed and documented.  Particular focus should be on the steps to embed the process.

The PMO should review the findings against output from other projects to see if there are any wider trends across project delivery for the organisation.  It is possible that other projects have raised similar points and these are being embedded.  The check allows for any proposed changes to be refined.

The findings should be captured into a register to ensure that they are tracked through to implementation.  Ideally this will sit in the PMO.  It is a good idea to define and use standard themes so that lessons learned and recommendations can be grouped.  This will increase the value of data mining.

Define Actions and Embed Change

The findings should be sent back to the workshop attendees and any other stakeholders, for review.  When agreement is reached, work can commence to embed the changes.  The register can be used to track progress and to report back to stakeholders.

Summary

In order to conduct a productive lessons learned review:

  • Ensure that there is a simple process with defined tools and templates
  • Schedule reviews at an appropriate time in project life cycle – be pragmatic
  • Seek input ahead of review workshop
  • Hold workshop and review themes, agree root cause and changes
  • Analyse against other findings across the organisation and refine
  • Capture in register and implement

Following this struc

When to conduct a project lessons learned review

The last post, Project and PMO Lessons Learned Overview, provided an overview of the project lessons learned review process.  This post and future posts will go into more detail on the different aspects of the process.  I also would like to state that I will highlight where there are differences with PMO lessons learned.  However, the principles are similar.

Remember the objective

It is worth taking a moment to remember the objective of conducting the review.  After all it is an investment of time and money, and, like other activities, it must add value (those who have read my other blog posts will know that one of my core principles is that PMO and project activities should only be performed if they add value and / or are absolutely required – if not don’t waste time and money performing them).

The objective is to learn from what has happened (good and bad) so that changes can be made to improve the process in the future.  The rationale being, if something has worked well, we want to ensure that all projects use a similar approach as it should provide the same benefit.  Likewise, if something goes badly, it makes sense to take steps to avoid the same issue impacting other projects.

Of course it is not quite as simple, as each project will be different and what has worked well for a project may not be applicable to others.  I want to expand on this point in a future post.

When to conduct lessons learned

Conducting project reviewIf you ask a project manager when to conduct a lessons learned review, I would be confident that the majority would say at the end of the project.  A relatively small minority will say at the end of a significant toll gate.

While both answers are correct, the second response provides far more value to an organisation than the response “at the end of the project”.  The reason being, the earlier that lessons can be identified and embedded into an organisation, the more value they will provide.  So the ideal response to the question would be to conduct reviews on an ongoing basis so as to allow for continuous improvement.

Obviously, it would be impossible to conduct reviews on a continuous basis.  Likewise, you would have to question the value (remember the principle only perform an activity if it adds value).  Therefore, the following provides 4 ideas of where you can use lessons learned.

1. Mobilisation

This may sound counter intuitive, why would you want to have lessons learned at the start of a project?  Well, this is not so much lessons learned from the current project, it is the learning’s and collective knowledge from other projects.

When starting a new project, the project manager should check to see if a similar type of project has been undertaken before (does not matter if it was not finished).  Then request details of lessons learned, arrange to meet project manager, sponsor, etc so as to find out “first hand” more information.

If a similar project has not been completed before, put a request out to the project managers, PMO teams, etc.  There is a possibility that somebody may have completed a similar project at another organisation.  Definitely worth buying them a coffee to get their thoughts on where there may be problems.

Gaining this knowledge will allow you to incorporate these learning’s into your planning.  This should improve the odds of a successful outcome.

If no one has completed a similar project, another approach is to ask for other project managers to conduct peer reviews of your plans, terms of reference, etc.  Good project managers will be able to review and ask probing questions that will tease out potential issues.  Updates can then be made resulting in a more robust approach.

2. Tollgate

In many project life cycles, there are phases of work i.e. Initiate, Design, Build, Test, Implement.  Some organisations define tollgates that need to be satisfactorily achieved in order to move to the next phase.  It can be common to use this in association with gated funding so that the budget to support the next phase can only be drawn down when the tollgate is achieved.

The project team will usually need to prepare evidence that the tollgate has been met to present to the project steering committee.  So, if they have to prepare a presentation, it is logical for the presentation to include lessons learned.  These can then be used to inform and make changes for future phases.

The PMO can take the presentation, analyse, review against defined tools and processes and then, where appropriate, make changes to benefit the wider organisation.

3. Change Request

Most projects will have at least one change in scope, budget or schedule over the lifetime of the project.  This will result in the project team having to create a change request to present to the steering committee or change board to reset the project.

The analysis and presentation provides a similar opportunity to the tollgate review.  The project team will need to provide the driver for the change and why it impacted the project.

Again the PMO should review the reason and workout if any changes need to be made across other projects.

4. Project Closure

Finally, the point where we started, lessons learned should always be completed at the completion of the project.  This will follow a defined template that is specifically designed to capture all aspects of lessons learned for the project.

This review will be more in-depth and will capture inputs from project team, sponsors, stakeholders, etc.  While the feedback will be more comprehensive, it comes to late to help the project so the time invested is for the benefit of others.  The only time it may be a benefit for the project is if it involves multiple workstreams.

Summary

To close I would like to summarise the key messages.

  • Lessons learned does not have to wait until the end of the project
  • Look for natural opportunities to learn and make changes i.e. change control, tollgate, etc
  • Adopt an approach on continuous improvement, making changes even if there has not been a formal review
  • PMO should be the custodian of the learning’s – actively reviewing and embedding organisation changes to improve project delivery

The next post will cover the end of project lessons learned review in more detail including the structure of the template.

Project and PMO lessons learned overview

lessons learned signIf all goes well, a project should eventually come to an end, hopefully with a positive outcome.  However, even though all the project deliverables are complete and the product, process, platform, etc is now handed over into business as usual, there is still a very important project tasks to be completed before the project can be finally closed – a lessons learned review.

It is unfortunate that this step does not get completed at the end of most projects.  In extreme cases of failure the sponsor will often demand a review in the guide of lessons learnt to understand what went wrong.  While this is good, this is normally undertaken with the agenda of finding who is to blame, not to learn.

What is lessons learned

Lessons learned is the formal process at the completion of a project, where a review is conducted on what went well and what did not go well.

Objectives of lessons learned

At a high level, the primary objectives are:

  • Identify what processes and techniques worked for the organisation so that they can be replicated by other projects
  • Identify what did not go well so that other projects can avoid making the same mistake

The overarching principle is to learn from what has happened so that future projects can benefit, resulting in a higher probability of favourable outcomes.

When to perform lessons learned?

Usually a review is completed at the end of a project as part of formal closure.  However, it is also possible to conduct a review at the end of key stages in the project lifecycle or after a particular event (usually a high impact issue).

The reason it makes sense not to wait until the end, is that identifying items to improve early will allow the project and other projects to learn quicker.  If you wait until the end of the projects, there is more chance other projects will have already made the same mistake.

Who performs lessons learned?

Typically it is performed by the project manager and / or project team.  However, sometimes it makes sense to have the review conducted by a team external to the project as they will be more objective i.e. Quality Assurance function, audit, etc.

In extreme cases it may make sense to ask a 3rd party to come in to conduct a truly independent review.

Format

Usually a template with defined questions is used to conduct the review.  This is often in the form of a spreadsheet or word processor document.  The reason for having a set format means that reviews can be completed in a consistent manner and all the appropriate questions asked.

It is important that it is possible to tailor the questions for a specific project so as to provide maximum benefit for the exercise.

The review can be conducted as a formal meeting / workshop with all relevant project team members and stakeholders.  It can take the form of a number of desk based interviews.  Request for information via e-mail or telephone.  In reality it will be a combination.

How to use the output

This is the real power of a lessons learned review – the outcomes.  There are organisations who complete the reviews, tick the box to say it is complete, file the report and then do nothing with the findings.  This adds no value, in fact it destroys value as the review takes valuable time.

The real benefit comes from taking action on the back of the findings.  The conclusions should be reviewed and themes established.  These then need to be fed back into the process on how the organisation executes project delivery.

Ideally, changes can be translated into tools and processes.  This means that there is a higher probability that change will be made.  This is where the PMO can take a lead by reviewing the lessons learned, reviewing against the project methodology and then making changes to embed the process.  The result is that the organisation will take on the lessons and improve.

If the PMO is keeping track of all of the lessons learned reviews, they are also in a very good position to spot trends that may not be obvious.  Again allowing them to make changes to improve the process.

Conclusion

Lessons learned is a very important tool for an organisation that wishes to learn from their projects and improve outcomes.  The PMO is well placed to coordinate the gathering and review of the data so as to be able to update tools and processes that embed the changes.

While it takes time to conduct the reviews, it does provide a positive return on investment in the long run.

The next few posts will focus on specific aspects of the process.

First week in a PMO role

PMO CommunicationThe last few posts, have been focusing on the move from one PMO role to a new PMO role.  To build on this, this post will spend some time considering some of the Do’s and Don’t for the first week in the new PMO role.

Build understanding

If the role is in a new organisation or different part of your current organisation, you will need to get up to speed on what is going on.  Without doing this, there is a risk that any decisions you make, may not be appropriate.  Remember, when you start a role, there will be a number of people watching how you perform.  If you make some rash decisions without taking time to understand, you will struggle with support.

Good ways to build understanding are:

  • Key documents
  • Meet stakeholders
  • Meet the people doing the work (they know what is going on)

Ask questions

While you are building your own opinion through observation, you also need to seek feedback.  As you go about the day, you will be interacting with different internal and external stakeholders.  Take each opportunity to ask how they think things are going – what works and what does not work.

This is the best time to get honest feedback.  As you are not responsible for what has happened before you joined, people probably be more candid with providing feedback as it will not be in respect of what you have put in place.  They will also be aware that this presents an opportunity to influence changes to current processes.

Test feedback

People always have specific items that are important to them or what they are doing.  It may not always be representative of the wider picture.  Make sure that you test the feedback and inputs with other people.  As you speak to more people you will soon identify emerging themes and what items are unique to individuals.

Take action

While it is important not to make rash decisions, you do need to make an impact and demonstrate leadership.  When you have enough data to make decisions, don’t be afraid to push ahead.  It will demonstrate to your manager and your team that you have the courage to make decisions and lead.

In summary

All of the above is very practical and straight forward and no clever / complicated tools or processes.  It really comes down to asking the right questions and (most importantly) listening.  Doing this will set you up for success.

Taking on a new PMO role

Taking on a new PMO roleThe last post, PMO Handover Plan, covered the importance and key elements of transferring the running of the PMO when you are in the process of moving to a new role.  Therefore, it is logical to cover the steps to take when you take-on a new PMO role.

Overview of PMO

Make sure you have a good understanding of the objectives and scope of the PMO.  This will include:

  • Number and types of projects
  • PMO maturity
  • PMO type (admin, managerial, hybrid)
  • Current resources / open vacancies
  • Services being provided
  • Challenges / weaknesses

The aim is to gather a good understanding of the current state and an idea on areas of concern, gaps in service, etc.

Understand role

It is very important to understand the role.  This is important as you need to ensure that what is being asked is achievable, that you have the appropriate skills and that you can be successful.

Ideally there will be a job description.  If there is not, build your understanding and then write one so that your role is clear to both you and, more importantly, your manager.  This is crucial for demonstrating that you have achieved at the end of the year.

Meet your manager

This is closely linked to understanding the role.  Meet with your manager and find out what they require from the PMO, their concerns and expectations for you fulfilling the role objectives.  It is good to use the job description for this conversation.

Make sure that the expectations are realistic.  If not, work with the manager to ensure they are realistic.

Meet the current role holder

If this is possible, always try to spend time with the current role holder.  They will be best placed to provide you with the real insights to what has been achieved, where there are problems and the usual nuances of the organisation and people.

This step should give the real insight to the role and to work out how difficult it may be.

Meet PMO team members

Arrange meetings with the current PMO team members.  This will allow you to understand their roles and gain their input on what is and is not going well.  This can be very revealing compared to the messages from sponsor and PMO manager.

Review documentation

Review available documentation such as:

  • PMO vision and mission statements
  • PMO charter
  • Example reports

This will provide an understanding of the objectives of the PMO and the quality of the deliverables.

Meet stakeholders

Spend time speaking to stakeholders – people who consume the services from the PMO.  Ask them there thoughts on the service – what is working and where there are issues.  Gain an understanding of what they require from the PMO.

These meetings will also reveal who is supportive of the PMO.

In summary

Before taking on a role in a new PMO, you must try to gather as much information as possible about the PMO and the role.  When you have decided to take on the new opportunity (or challenge), spend time engaging PMO resources, stakeholders and sponsor to understand what works and what does not work.  This will then allow you to create a plan that will move the PMO forward and deliver the services that the stakeholders require.

If you can quickly improve the service it will benefit the organization and stakeholders.  All of which should enhance your career.

Word of caution, if it becomes obvious through the data gathering that the PMO is not supported by the sponsor and stakeholders, there are lots of challenges, deliverables are poor, etc, then it might be wise not to take the role.