1. The Learning PMO
Garret Beggan
Deberiat
(Session and speaker introduction given by Eileen Roden)
1

2. Garret Beggan
Transformational
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

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

4. Keep it real
Continuous improvement
of what?
Thinking Tools
Create your own
PMO ‘ideas toolkit’
The PMO as CoE
Centre 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 acting
as 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 continuous
improvement 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

5. 1st Reactive Technique
Harnessing 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

6. Methodology: make it very hard for people to miss
something or do the wrong thing by updating
templates, ‘how to’ guides and worked examples
Choose 1 key document per lifecycle phase and
update 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 template
PM describes how he/she is going to avoid bad thing/ repeat good thing
The 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

7. 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: lessons
become better templates,
‘how to’ process guides
& worked examples.
7
The next program is
going 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

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

9. Artefact catalogue ‘real life’ example
JLR SAP Programmes TURBO
Project Phase Artefact Name
Document
Type
Artefact
Type ID
Artefact Description
(Purpose and
Composition)
Acceptance Criteria
WarrantyPhase0
WarrantyPhase1
Warranty
Comments
JLRBusiness
(CentralITTeam)
CentralPMO
ITServices
Integrationcenter
ofexcellence
MISManagement
systems
Process
Management
JLR
Steering
Committee
Programme
Director
Programme
Manager
PMO
ProjectManager
JLRSolution
Architect
DataMigration
Lead
Commerical
HeadofTechnical
delivery
HeadofChange
Mgt
HeadofSolution
Delivery
HeadofData
Management
TestManagement
Project Initiation Statement of Work (SoW) PM004
A statement of work
(SOW) is a formal
SOW should clearly define
Purpose,
Yes X X
Project Initiation Initial Proposal Document PM003
The 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) PM005
Master Service Level
agreement.
Commerial agreement to
be reviewed and approved
Review
& Re-
X X
Project Initiation Letter of Intent (LoI) PM001
An 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 BCM001
The business case
consists of the financial
Yes R X C A
Project Preparation Project Scope Document PM102
Document detailing the
scope of the project
Project objectives are
documented
Yes X X X X C C
Project Preparation Project Charter PM104
Document detailing what
the project is about, how
Yes R I A/R R C C
Project Preparation Programme/Project Team Organisational Model PMO115
Organisation structure of
TURBO team members.
Yes R X AR R
Project Preparation
Programme/Project Roles & Responsibilities
document
PMO101
This deliverable
documents the roles and
RACI matrix for project
defined - based on ASAP
Yes R X R AR C
Project Preparation
Programme Governance Model (applicable for
TURBO and eSMART)
PMO108
Document listing TURBO
governance bodies: scope
Review
& Re-
R C AR
Project Preparation Non-SAP Tools Document QM101
Covered by tool specific
requirement documents &
***If SolutionManager
and ALM are implemented
Review
& Re-
R R
Project Preparation IT Savings Model / Targets PM
Document describing
Cost/Benefits if SAP is
N/A
Project Preparation Issue, Risk and Escalation Management Process Process PMO106
Plan detailing Escalation
process to be followed
Review
& Re-
R AR
Project Preparation Infrastructure Cost Plan TSI102
Document describing the
cost of infrastructure for
N/A
Project Preparation High Level Project Plan PMO102
A 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 BCM103
Document 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 SD102
The SAP Solution
Composer is an offline PC
N/A
Project Preparation
Workstream Plans (for each phase as per
requirement)
SD106
Schedule of tasks – it
includes definition of the
As per JLR Planning
Standards
Yes R S X A
Project Preparation Vendor Management Strategy PM107
Document detailing the
approach that will be
Yes R A R R R
Project Preparation
TOR - Opertational Steering Committee meeting
(OSC)
PM105
Document detailing the
terms of reference,
Yes R X R
Project Preparation ToR – Executive Steering Committee PMO100
Defines the role of the
executive steering
Review
& Re-
R X S AR
Project Preparation
Tools Assessment & Report (Applicable for any
new tool)
QM125
Assessing 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 QM110
The 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 QM106
The 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 QM102
Quality Management plan
documents the processes
Quality Management Plan
The document clearly
Review
& Re-
C C C
Project Preparation Quality Gateway Review Form PMO104
This 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

10. 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 swimlanes
make 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 outcome
4. 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

11. Gateways ‘real life’ example
Support
(Hypercare)
Initiation Blueprint Realization
Final Prep
& Go Live
Embed &
Sustain
IT Support BAU
E E E
R R
E
R
Preparation &
Mobilisation
EE
Business 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.01
TURBO
Dependencies List
PMO Planner {name}
Have we logged programme
interdependencies and are we managing
them appropriately?
PIMS log U
Dates 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 U
We 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

12. Be realistic
I 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 response
section 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. Busy
PMs 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

13. • 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

14. 1. Scan the horizon
When 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-mortem
Imagine 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 Practice
What would happen if the PMs
could suggest improvements?
The data team? The Business
users?
Link it all together
drive improvements
from all sources into
our 3 key tools:
methodology,
gateways, and Lessons
Applied sections.
From reactive to proactive…
…Three powerful techniques
for 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

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