The Learning PMOGarret Beggan

Deberiat

(Session and speaker introduction given by Eileen Roden)

1

Garret BegganTransformational Change, PMO and

Governance specialist

Deberiat

My name is Garret Beggan

I started in the Automotive Business, working in dealership quality

Wandered into IT, then PM, then PMO

Sort of ‘accidentally’ got into PMO after fiercely resisting it, because I thought PMO meant boring admin. But now staying here is a ‘deliberate act’

Reason: I’ve found a way for a PMO to make a difference, by doing the following:

- Looking very clear-headedly at the projects landscape

- Deciding what problems we’re going to solve

- Giving projects and programmes the best chance to succeed

- NOT just measuring them to within an inch of their lives and loading them down with reports

2

It’s a also lot harder to retain focus on today’s in-flight programmes and at the same time work out what’s a priority to improve now, or what’s OK now but will need upgrading next year.

Operational focus

Outside the Box

15 years ago, every other job ad was looking for people to ‘think outside the box’

Inside the box

I used to think “can we just concentrate on finding people who can think inside the box?” –it seemed simple enough to me at a project scale, but plenty of people weren’t doing it.

The box keeps getting bigger…

Now many organisations are working at a programme or portfolio scale and there’s a lot more to think about inside a bigger box. Even the best PMOs are missing chunks of it.

1

2

4

3

What use is thinking ‘outside the box’…

..if we haven’t really mastered ‘inside the box’?

15 years ago, every other job ad was looking for people to ‘think outside the box’

I used to think “can we just concentrate on finding people who can think inside the box?” – it seemed simple enough to me at a project scale, but plenty of people weren’t doing it.

Now many organisations are working at a programme or portfolio scale and there’s a lot more to think about inside a bigger box. Even clever and well-informed people are missing chunks of it.

It’s also a lot harder to retain focus on today’s in-flight programmes and at the same time work out what’s a priority to improve now, or what’s OK now but will need upgrading next year.

So rather than smugly expecting people to master what’s ‘inside the box’, I have found it useful to harness lessons learned from delivery (or upfront selection, or post-launch operation) and use the ‘learning PMO’ to support continuous improvement.

3

Keep it realContinuous improvement of what?

Thinking ToolsCreate your own

PMO ‘ideas toolkit’

The PMO as CoECentre of Excellence for

Portfolio, programme and/or project management

Start where you are(Where else can you start from anyway?)

If we are to make continuous improvement ‘real’, we need to know what concrete thing we are going to make better. I’m going to share a framework of key items I have found give a comprehensive foundation.

I’m going to describe using four powerful techniques to develop and improve the framework, one reactive and three proactive.

This approach is most practical to the PMO actingas CoE. But since I developed it in an operational PMO, I think any PMO that will live through several projects should be able to do something similar.

We can start where we are and build a continuousimprovement loop into the way we work. This is an approach that uses common sense and its main tools are things that many PMOs already do to some extent.

So how can we get a ‘learning PMO’ off the ground?

What I’m going to share now is an approach to allow people to start where they are (where else?) and build a continuous improvement loop into the way they work. What I like about this approach is that it uses common sense and its main tools are things that many PMOs already do to some extent.

It follows that this approach is most practical for the PMO acting as a CoE (Centre of Excellence) for programme management or portfolio management. But since I developed it in a temporary – although multi-year – Programme Management Office, I think any PMO with a reasonable prospect of living through several projects should be able to do something along these lines.

I’m going to describe using four powerful techniques to improve the framework, one reactive, which I’ll cover in detail, and three proactive.

And since if we are to make continuous improvement ‘real’, it’s good to know what concrete thing we are going to improve, I’m going to share a framework of key items I have found give a comprehensive foundation.

4

1st Reactive TechniqueHarnessing Lessons Learned

Lessons Learned: the ‘anti-party’ drudgery you have to do to be allowed the REAL party)

Afterwards who remembers either of them?

Hands up who has ever started a project or programme by digging out other people’s lessons learned?

Let’s look in detail at turning ‘lessons learned’ into ‘lessons applied’

Remember, often only the PMO is going to live through project after project in the same organisation, so we are the ones who can make a difference!

Turning ‘lessons learned’ into ‘lessons applied’

It used to be that at the end of every project, the 2 certainties were the Party (yay!) and the lessons leaned session (boo! The anti-party, the drudgery you have to do to be allowed the party)

Afterwards both are filed away in the dusty recesses of individual memories (or police reports, if either goes badly enough).

Hands up who has done a PM or PgM role. Have you ever started a project or programme by digging out other people’s lessons learned? To my shame, I have very rarely done this! Usually we start a programme already on the back foot and fighting to get the first deliverables out.

So let’s look in detail at turning ‘lessons learned’ into ‘lessons applied’ using something more practical than the sweet hope that “Gee, I hope we change the mentality of PMs everywhere”, because that just isn't going to happen.

By the way, I’m going to assume here that when we capture lessons learned, we add them into some kind of log or spreadsheet so they are available for review.

Remember, often only the PMO is going to live through project after project performing the same role in the same organisation, so we are the ones who can make a difference!

5

Methodology: make it very hard for people to misssomething or do the wrong thing by updatingtemplates, ‘how to’ guides and worked examples

Choose 1 key document per lifecycle phase andupdate the template with a ‘lessons applied’section where the PM describes how he/ she is

going to avoid bad thing/ repeat the good thing learned

Gateways & Governance: have the right person ask the right question, and share why the answer is important. The responses need to be evidenced

(right artefact, right assurance, right standard)

The 3 useful places to turn ‘Lessons Learned’ into ‘Lessons Applied’

The best homes I have found to turn lessons learned into lessons applied are:

1. Methodology: Prevent problems by making it very hard for people to miss something or do the wrong thing by updating templates, ‘how to’ guides and worked examples so ‘the way we do things here’ includes steps that incorporate the lessons learned. We can use a ‘collateral tracker’ or ‘process library’ to track the completeness of the methodology over time, starting with a high-level process and rounding it out with templates, detailed guides and worked examples.

2. Gateways: Detect problems by having the right person ask the right question, and share why the answer is important.

The response needs to be evidenced by the right artefact validated by the right assurance to have reached the right standard.

3. Dedicated ‘lessons applied’ section in key documents: Prevent problems by having the PM propose how to avoid a bad outcome or repeat a good one

1 key doc per phase – you’ll need to update the templatePM describes how he/she is going to avoid bad thing/ repeat good thingThe weakest of the 3 responses, so only use where no adequate response possible in the first 2.Consider assessing the ‘lessons applied’ section as a gateway criterion, so it gets expert scrutiny.

6

Lifecycle phases(even for ‘agile’)

1

Artefacts per phase

2

Swimlanes across phases owned by capability leads

3

Drive success factor questions back as early

as you can

4

Don’t be afraid to tailor and be pragmatic

5

Include some observations on ‘sizing’

6

Outcome: lessonsbecome better templates,

‘how to’ process guides& worked examples.

7

The next program isgoing to have to try

harder to get it wrong!

8

A closer look at Methodology…

The first of these 3 ‘homes’ for lessons applied is Methodology. Why? Because we’ll use it to guide people so we prevent a problem arising in the first place.• People can get hung up on Methodology. There isn’t one right way to do it. I want to share what I’ve found useful.• It’s useful to define a lifecycle because usually we have to do some form of the classic Analyse/ Design/ Build/ Test/ Launch routine, even if we shake them up a bit in Agile. And we learn by experience that the foundations of failure in any phase are often set in a previous phase.• Then we can say “in this phase we should agree the scope and baseline it; in the next we should have process designs or building designs, and in the phase following that we should have test checklists and write the training materials…• Now here’s a big thing: a lot of off-the-shelf methodologies are really hot on what Prince2 would call ‘management products’ – so scope documents, PID, PDD, and so on. But the heart and soul of the real programme are the ‘specialist products’ – the work done by the developers or the builders or the track engineers. So think about the path through the lifecycle that these guys need to take, and what templates and guidance we give them and what artefacts we expect from them so we have the best chance of arriving safely at the end together.• Then think forwards and backwards – if we find we have a weakness say in getting time in a test environment or test rig in the test phase, then work out how early we could have started teeing people up for that – maybe the design phase we could already forecast what we were going to need to test and therefore what environments or rigs were needed.• Talk to the PMs and business and tailor the methodology to be helpful while retaining the right degree of rigour and oversight.• You can scale your methodology – think ‘t-shirt sizing’ before any very complicated estimating or sizing model. A small project doesn't have the risk factor of a big programme, so reduce the demands, esp. for management products.• What you’re aiming for is that it’s actually harder for the next project to fail, because the guides or templates make it easier to avoid the bad outcome or repeat the good outcome.

7

Methodology guide ‘real life’ example

Here’s an example to bring it to life. This was the work of a methodologist colleague of mine. We started with a blank sheet of paper.

Several years later, we had a re-usable ‘playbook’ approach and several new artefacts or parts of artefacts directly attributable to lessons we learned from early programmes.

Each ‘path’ or ‘swimlane’ represents a necessary specialism, whether it be the Business codifying what it needs to prepare its people for a change in operations, or a specialist function like Information Security protecting assets and reputation.

For each phase and in each swimlane we can inform programmes what deliverables are needed, what problem each is meant to solve and how it relates to other team’s work (vertically within a phase) or the work in earlier and later phases (horizontally within a swimlane). We can provide templates and ‘how to’ guides so people don’t have to start from a blank page. Over time we can link to a library of worked examples. And we can leverage these deliverables to provide useful KPIs and metrics that add value to reporting and focus attention where it’s needed.

Only the PMO can do this – harness the knowledge of Business, IT and PM specialists and turn it into a useful ‘delivery playbook’ for all!

8

Artefact catalogue ‘real life’ exampleJLR SAP Programmes TURBO

Project Phase Artefact NameDocument

TypeArtefact Type ID

Artefact Description(Purpose and Composition)

Acceptance Criteria

War

rant

y Ph

ase

0

War

rant

y Ph

ase

1

War

rant

y Co

mm

ents

JLR

Busi

ness

(C

entr

al IT

Tea

m )

Cent

ral P

MO

IT S

ervi

ces

Inte

grat

ion

cent

er

of e

xcel

lenc

e

MIS

Man

agem

ent

syst

ems

Proc

ess

Man

agem

ent

JLR

Stee

ring

Co

mm

ittee

Pr

ogra

mm

e D

irec

tor

Prog

ram

me

Man

ager

PMO

Proj

ect M

anag

er

JLR

Solu

tion

A

rchi

tect

Dat

a M

igra

tion

Le

adCo

mm

eric

al

Hea

d of

Tec

hnic

al

deliv

ery

Head

of C

hang

e M

gtH

ead

of S

olut

ion

Del

iver

yHe

ad o

f Dat

a M

anag

emen

tTe

st M

anag

emen

t

Project Initiation Statement of Work (SoW) PM004A statement of work (SOW) is a formal

SOW should clearly define Purpose,

Yes X X

Project Initiation Initial Proposal Document PM003The request describes the needed item(s) and all

The document correctly represets the project in

Yes X X C C

Project Initiation MSA (Master Service Level agreement) PM005Master Service Level agreement.

Commerial agreement to be reviewed and approved

Review & Re-

X X

Project Initiation Letter of Intent (LoI) PM001An acknowledgement showing willingness to

N/A

Project Initiation Request for Proposal Document PM002 RFP by JLR to SI partner N/A A C R

Project Initiation Business Case BCM001The business case consists of the financial

Yes R X C A

Project Preparation Project Scope Document PM102Document detailing the scope of the project

Project objectives are documented

Yes X X X X C C

Project Preparation Project Charter PM104Document detailing what the project is about, how

Yes R I A/R R C C

Project Preparation Programme/Project Team Organisational Model PMO115Organisation structure of TURBO team members.

Yes R X AR R

Project PreparationProgramme/Project Roles & Responsibilities document

PMO101This deliverable documents the roles and

RACI matrix for project defined - based on ASAP

Yes R X R AR C

Project PreparationProgramme Governance Model (applicable for TURBO and eSMART)

PMO108Document listing TURBO governance bodies: scope

Review & Re-

R C AR

Project Preparation Non-SAP Tools Document QM101Covered by tool specific requirement documents &

***If SolutionManager and ALM are implemented

Review & Re-

R R

Project Preparation IT Savings Model / Targets PMDocument describing Cost/Benefits if SAP is

N/A

Project Preparation Issue, Risk and Escalation Management Process Process PMO106Plan detailing Escalation process to be followed

Review & Re-

R AR

Project Preparation Infrastructure Cost Plan TSI102Document describing the cost of infrastructure for

N/A

Project Preparation High Level Project Plan PMO102A high plan detailing the milestones, timelines and

For the entire project, a dynamic Schedule has

Yes X S R R R R

Project Preparation Business Change Methodology N/A I

Project Preparation Business Change Management Strategy Strategy BCM103Document detailing the Change Management

The plants are clear on the way in which the

Review & Re-

yes R C

Project Preparation Solution Composer E2E Process SD102The SAP Solution Composer is an offline PC

N/A

Project PreparationWorkstream Plans (for each phase as per requirement)

SD106Schedule of tasks – it includes definition of the

As per JLR Planning Standards

Yes R S X A

Project Preparation Vendor Management Strategy PM107Document detailing the approach that will be

Yes R A R R R

Project PreparationTOR - Opertational Steering Committee meeting (OSC)

PM105Document detailing the terms of reference,

Yes R X R

Project Preparation ToR – Executive Steering Committee PMO100Defines the role of the executive steering

Review & Re-

R X S AR

Project PreparationTools Assessment & Report (Applicable for any new tool)

QM125Assessing the best tools to be used with the SAP

N/A R

Project Preparation Target Operating Model Diagram Yes I

Project Preparation Test Strategy Strategy QM110The purpose of testing strategy is to develop the

The Testing Strategy and Approach must cover

Review & Re-

C AR

Project Preparation Test Resource Planning Spreadsheet.xls QM116 N/A

Project Preparation Quality Register QM106The quality register is a diary of the quality events

A procedure is in place that will ensure that every

Yes R R

Project Preparation Quality Measurement Framework QM108 N/A

Project Preparation Quality Management Plan Standard QM102Quality Management plan documents the processes

Quality Management Plan The document clearly

Review & Re-

C C C

Project Preparation Quality Gateway Review Form PMO104This review form is used Not a customer

Yes R AR

JLR Central IT Team

And here’s another tool of the methodology. We create a catalogue of artefacts, broken down by phase. We can link to the templates and worked examples. We can explain what each one is for and how it sits in a network of earlier and later artefacts. (Indeed by tracing the network end-to-end we may find a chain of deliverables that disappears part way through and adds no value to the final programme outcome – either a risk that needs addressing by completing the chain, or a fine candidate for pruning altogether). We can map to a RACI – who or which role writes, who reviews, who approves.We can map to governance – which person or body approves a Business Change artefact or a Data Migration artefact.

So if we learned a lesson that we should have involved, say, the Customer Service team more, we might add a CS document, or have CS nominate a reviewer of an existing document, or invite a CS representative to a Governance body that has an approval or oversight mandate.

Just remember, before getting carried away – we added this information to solve a particular problem. Try to be sure you are solving a real problem as you make this more elaborate. Be aware of a natural PMO tendency to make this sort of tool a ‘perfect abstraction’ fit more for the Museum of Intricate Processes than as a solution for your organisation’s real world problems. Over time, you might even want to look proactively for steps and artefacts you can remove from the methodology, because knowledge is so thoroughly embedded it is no longer valuable to spend time reporting on it.

9

Ensure gateway questions responses are:• evidenced by artefacts• Meeting pre-declared standards• Verified by the right people

The owners of capability swimlanes are best placed to decide what artefacts are to be presented evidence and what standard they must reach• The PMO’s role is to create the

Governance ‘big tent’ and pull these parties in.

• We can’t ourselves hope to be the experts in everything, but we can be the ‘go to’ group to facilitate integration.

Again be ready to size and customise appropriately.

Outcome: pointed gateway questions and the inclusion in Governance of specialists who ‘own’ capability swimlanesmake it harder to carry a ‘root cause of failure’ through the gate into the next phase.

A closer look at Gateways & Governance…

The strongest response, conceptually, is to embed the lesson in the methodology so we guide people to get it right from the beginning. But we may instead, or also, build in a check to a gateway that would catch the cause of the lesson learned. Here we are looking to Detect rather than to Prevent. So what would make a good gateway? I suggest:

1. Questions that makes sense to ask at the end of a phase, as the phases are usually dedicated to getting the programme from one defined state to another (e.g. ‘scoped’ to ‘designed’). [In an Agile environment where we may need more flexibility than programme-level phase end gateways allow, the equivalent might be to stipulate certain ‘Must Have’ features as part of the MoSCoW prioritisation. ]2. Questions that can be answered using the artefacts the methodology already stipulates. (If something is vital at the gateway, it’s hard to argue it isn’t vital as a phase deliverable within the methodology)3. Questions where people know in advance what the pass criteria are – so they can prepare appropriately and there is nothing very surprising about the outcome4. Questions where the answers can be verified by the people who know what is needed for the organisation, often the ‘owners’ of a specialist ‘swimlane’ within the methodology .

This overlaps strongly with Governance, in another use of the swimlanes we talked of earlier. The Business, Technology and Programme Management experts who know what should be done at the analysis stage or the building stage are also good people to participate in the gateways. They can confirm that a team, guided by their methodology inputs, gateway questions and acceptance criteria, has achieved a good component design or a new financial product that has convincingly met regulatory requirements. The outcome we’re looking for is that we catch previous sources of failure earlier, or verify that causes of previous success have been ‘built in’ early enough.

10

Gateways ‘real life’ exampleSupport

(Hypercare)Initiation Blueprint Realization

Final Prep& Go Live

Embed &Sustain

IT Support BAU

E E E

R R

E

R

Preparation & Mobilisation

EEBusiness BAU

‘Substantive’ columns Aspect being considered Role responding to the question Person responding to the question Specific sub-question to be answered

‘Guidance’ columns Define artefact to be used in evidence CRUD – whether artefact is created,

read, updated or deleted for the gate event

Acceptance criteria define what success should look like for this artefact.

RG.17. Portfolio & Dependencies Management

Are dependencies with other programmes being managed? This question co-owned by Programme & PfMO

Ref Aspect Responder Resp. name Question for gateway 0 0 0 0 Artefact CRUD Acceptance criteria

RG.17.01TURBO Dependencies List

PMO Planner {name}Have we logged programme interdependencies and are we managing them appropriately?

PIMS log UDates for 'our' projects and 'other' projects are up to date and in alignment. This covers programme-to-programme dependencies between the SAP Programmes themselves (e.g. W2-EMC and W2-TD) as well as with external programmes

RG.17.02 PIMS Portfolio Mgt Head of PMO {name}Have we updated PIMS with any new or changed portfolio info?

PIMS Ideas Log UWe need to check the information reported centrally on strategic drivers, timelines and costs reflects how the programme has developed during Realisation

Here’s a real life example, an extract from a phase end gateway (picture above).

A potential weakness of any ‘Detect’ approach is that the PMO is seen as (or even is) the Bad Guy, catching people out and writing them up for infractions.

What I suggest to make the Gateway process both friendlier and more useful is:- Brief the programmes right at the start of each phase on how they will be assessed at

its end, so PMs and specialist teams can factor it into their plans and priorities.- Give them a reminder to get ready 4-6 weeks ahead of the Gateway. PMO staff can

assist by pulling together the completed collateral and prompting for any that are overdue.

- Hold a ‘dry run’ 2 weeks ahead of the gateway, and use this to identify gaps and agree actions so the team has the best chance of sailing through the real gateway on the day.

Remember we are not back at school sitting exams and trying to check what people truly know so we can score them. There’s a real business waiting to use the programme outputs and we all want the best real world outcome, even if we have to coach programme teams heavily to get it. The gateway that becomes a robust evidence-based check and is ALSO surrounded by lots of help, advice and support for the team going through it will usually be welcomed by all parties.

11

Be realisticI don’t advise more than 10 lessons to address per phase. And as these points are addressed over time by Methodology or Gateway changes, remove them from the list the PM must address and replace them with the next improvement lesson bubbling up

Identify one document per program or project phase which is key to the next phase. E.g. a Design document at the end of Design phase is key to ‘Build & Test’ phase.

Add a ‘Lessons Applied’ section to that document’s template. In it, the PM must address the lessons learned by previous projects from the next phase we’re about to go into.

Set a review question to look at the PM’s response in the phase gateway.Has the PM adequately explained how he/ she is going to avoid the ‘bad thing’ or repeat the ‘good thing’?

A closer look at PM’s responsesection in key documents*…

*BTW, I am indebted to the‘Managing Benefits’guidance for this idea

The 3rd home for lessons learned is adapted from the ‘Managing Benefits’ guidance by Steve Jenner. It is a ‘Prevent’ approach, and useful where we haven’t yet made a change to methodology, templates or gateways that would ‘hard code’ the lesson learned.

The idea is to identify one document per program or project phase which is key to the next phase. E.g. a Design document at the end of Design phase is key to ‘Build & Test’ phase.

Add a ‘Lessons Applied’ section to that document’s template and set a review question to look at it in the gateway. The PM must address the lessons learned by previous projects from the next phase we’re about to go into. For each one, how is he/ she going to avoid the ‘bad thing’ or repeat the ‘good thing’?

We need to be realistic here, so I don’t advise more than 10 lessons to address per phase. And as lessons learned are addressed by the PMO and specialist swimlane owners with Methodology or Gateway changes, remove them from the list the PM must consider individually and replace them with the next improvement lesson bubbling up.

As an aside, you can hopefully see now that our log or spreadsheet of lessons learned should include a field or column to capture how we are embedding them – whether in the methodology, the gateways, or the ‘lessons applied’ section of a key document. BusyPMs don’t need to see any lessons bar those for which manual responses are needed, because with PMO help they will make use of updated methodology and gateways as a matter of course.

12

• Swimlane: business risk added as a separate topic• Methodology: controls artefacts and ‘good enough’

standards set• Gateway: questions about reviewing redacted

versions of earlier IA reports

• Design inadequate• Testing inadequate• Controls inadequate

Case study: controls in a manufacturing company

Internal Audit Challenge

PMO Response

Harnessing organisational energy: pulling IA inside the ‘big tent’Outcome: stronger controls scrutiny and better IA findings

Here’s a case study to bring it all together

- A year to 18 months into a big transformational programme we hit a problem with ‘controls’ – process and authorisation steps intended to avoid deliberate or inadvertent misconduct.

- Internal Audit (IA) found that people could in principle use a new IT solution we had launched to do things they shouldn’t be able to do. We had to fix the problem reactively of course, but I also wanted to fix the cause.

- Together with Internal Audit specialists we set up a new ‘Business Risk’ workstream and set out the steps to take at each phase (Methodology). In this case, because IA cannot be integral to any programme without compromising its independence, we developed an assurance approach and they gave their opinion on its general suitability and robustness. Our aim was to prevent recurrence.

- We also added some new Business Risk questions to phase end gateways, and invited IA to the gates as observers so they could form an opinion of how we were applying the guidance as we moved through the phases. Here the aim was to detect emerging recurrence.

- Finally, IA were able to share redacted audit reports showing the kind of things they had found previously, and brief programme developers individually so they avoided repeat failures.

13

1. Scan the horizonWhen the CEO says “we need to focus more on process” or “we need better controls”, can the PMO get on the front foot?

2. Conduct a pre-mortemImagine yourself at the end or the project, and that it wasn’t a success.What went wrong? If you had your time again, what would you change?

3. Build Communities of PracticeWhat would happen if the PMs could suggest improvements? The data team? The Business users?

Link it all togetherdrive improvements from all sources into our 3 key tools: methodology, gateways, and Lessons Applied sections.

From reactive to proactive…

…Three powerful techniquesfor the learning PMO

I’ve concentrated on lessons learned and how we push them into methodology, gateways and PM responses. But LL of this kind are always reactive. A good challenge would be “must we always wait for a problem to learn from? Can we be proactive?”

Here are 3 ways the PMO can act proactively:

1. Horizon scanning. Keep our eyes and ears open. What strategies is your organisation planning to follow? What is the market doing and how might that impact the future? And therefore, what new or changed elements do we need in our methodology or gateways now to avoid learning lessons the hard way in future?

2. Pre-mortem. This is a thought experiment – gather the project team and imagine yourselves in the future. The project wasn’t a success – what went wrong? At the end of the experiment, get back in your time machine and return to today. What can you do now to stop that bad future from occurring, “learning” the lessons before we have even started?

3. Develop a Community of Practice (CoP) – or indeed several of them, e.g. PM, Data, Training etc. Now harness the ideas of practitioners on what they want to incorporate into methodology, templates, or other aspects in order to improve. :^)

Reactive or proactive, they can all end up in the same 3 places: methodology, gateways or PM ‘lessons applied’ responses.

14

How many ideas can you take away to try out in your PMO?

Thank you

£

Deberiat

I’d really like to know – has anyone been prompted to think of how they could make their PMO a learning PMO?

Especially, any ideas beyond methodology, gateways & governance, and PM responses?

[Author note: since giving this talk, I’ve had some useful suggestions based on Problem Management techniques from Manufacturing, where there is a focus on getting fixes into Production immediately and certainly faster than the next release of a template or methodology. A Learning PMO will often think of ways to adapt lessons from one industry to another, so don’t be put off by ideas from Manufacturing, Construction, or Video Games industries just because you work in, say, Banking or Local Government. As a non-Manufacturing example of rapid lessons application, if IT testing showed a particular coding issue, then holding a team call to share a concern or putting a post-it note on every developer’s screen could immediately turn a lesson learned into a lesson applied; ideally we would then remove these notes as the official guidance caught up.

Another potential improvement over the suggestions here, within the Methodology area, is to consider ‘standards’ as separate from ‘templates’. In the construction industry many historic lessons are applied by way of building standards and codes; by analogy a PMO standard could be a common resource for an organisation even if the templates that refer to or embed it need to be adapted for projects, programmes, agile approaches etc.]

15