Body of Knowledge Refresh 2011:
Additional Review: Risk Management – July 2011
1. Definition of good practice:
‘The knowledge and practices described are applicable to most projects most of the time, and
…there is widespread consensus about their value and usefulness’.
A Guide to the Project Management Body of Knowledge (PMBoK®Guide) Third Edition,
©2004 Project Management Institute
Do the drafts reflect good practice?
3.5 Risk Management







3.5.1 Risk Context





3.5.2 Risk Techniques

On the whole yes. Call contributors agreed that in 3.5 there
are some things that they don’t believe articulate good
practice very well, and is ambiguous. RM goes against the
process – gives a framework to have some structure in
managing risks.
Fundamental principles need to be drawn out more – need
for greater clarity (long sentences, ambiguity).
Back to front - fundamental definition saying ‘something is
not something’ – should define what it is.
Tone whole way through is ‘journalese’. RM is about id and
management of… Making it a process has advantages but RM
is not a process.
Negative introduction to some of the text. Should define what
it does, not what it doesn’t do.
Frequent asides before author gets to the key point. Masks
whether or not author feels that those asides are
fundamental to RM or whether put in to provide stylistic
curlicues which makes it difficult to understand where the
author puts the balance.
Para ‘no project, programme or portfolio is executed…’ Too
long and needs to be broken down. Para is convoluted. If
trying to discuss with someone who doesn’t have English as
first language, sentence structure is too complex. Could lead
to misinterpretation.
General – para 2. Disagree – perception is shifting.
Project operational – there are 4 elements that effect the
organisation – programme specific that affect operations of
organisation, and programme in keeping with MoR. Seem to
be 3 in this draft.
Refers to what programme manager will do – not clear
whether by programme manager role, or programme team.
Not specifically to do with risk context, and more to do with
RM and should be under programme RM. Key characteristics
(definition of standards, escalation criteria, governance, etc –
as provided in April reviews) have gone down a level –
describing business processes.
Need to sift through it and re-order some of the concepts to
sit within other 3.5 sections.
Quite like idea of saying ‘techniques range from simple to
complex’ with examples. And signpost to other techniques
e.g. PRAM Guide. Good approach for BoK.
2. Are they pan-sector?
a. Does the content avoid industry/sector bias?
b. Is the content scalable (taking into account the range of
projects/programmes/portfolios from small to large, and the range of
complexity)?
Definition of pan-sector:
Generic, non industry specific content that can be applied regardless of industry or sector.
3.5 Risk Management
Yes
3.5.1 Risk Context
Yes
3.5.2 Risk Techniques
Yes
3. Do any key concepts relating to the section need to be added?
a. Definition
‘It should be succinct, and … independent of the level of project/programme/portfolio at
which the section is applied’ Section template guidance
b. General section
‘Generic description of the topic including universal principles independent of
project/programme/portfolio levels…Any terms that tie the text to a particular level
should be avoided. In some cases, especially in sections 1 [Context] and 4 [General], this
will be most, if not all of the content’ Section template guidance
c. Project content
‘An explanation of the application of this topic at a project level is to be
included…Anything that applies to programmes and portfolios as well as projects should
be included in the general section. This section may reasonably be divided into projects
that are part of a programme, and those that are independent components of a
portfolio’ Section template guidance
d. Programme content
‘An explanation of the application of this topic at a programme level is to be included
here, where applicable. Where the general principles need to be adapted, enhanced or
extended for specific programme application, where content is different or additional to
that for project aspects to this topic, it may be added [here]…Anything that applies to
projects and portfolios as well as programmes should be included in the general section.
If there are no such applicable adaptations, enhancements or extensions, please enter…
‘NO SPECIFIC ADAPTATION REQUIRED FOR THE TOPIC FOR PROGRAMME
MANAGEMENT’’ Section template guidance
e. Portfolio content
‘An explanation of the application of this topic at a portfolio level is to be included here,
where applicable. Where the general principles need to be adapted, enhanced or
Page 2 of 7
extended for specific portfolio application, where content is different or additional to
that for project and programme aspects to this topic…it may be added [here]…Anything
that applies to projects or programmes as well as portfolios should be included in the
general section. If there are no such applicable adaptations, enhancements or
extensions, please enter…’NO SPECIFIC ADAPTATION REQUIRED FOR THE TOPIC FOR
PORTFOLIO MANAGEMENT’’ Section template guidance
3.5 Risk Management


Project dimension – not included risks to business from
project.
Disagree – room for definition of RM in context of project.
3.5.1 Risk Context

Need something for project management.
3.5.2 Risk Techniques
TO SEND THROUGH
Page 3 of 7
4. Does anything need to be amended and why?
a. Definition
‘It should be succinct, and … independent of the level of project/programme/portfolio at
which the section is applied’ Section template guidance
b. General section
‘Generic description of the topic including universal principles independent of
project/programme/portfolio levels…Any terms that tie the text to a particular level
should be avoided. In some cases, especially in sections 1 [Context] and 4 [General], this
will be most, if not all of the content’ Section template guidance
c. Project content
‘An explanation of the application of this topic at a project level is to be
included…Anything that applies to programmes and portfolios as well as projects should
be included in the general section. This section may reasonably be divided into projects
that are part of a programme, and those that are independent components of a
portfolio’ Section template guidance
d. Programme content
‘An explanation of the application of this topic at a programme level is to be included
here, where applicable. Where the general principles need to be adapted, enhanced or
extended for specific programme application, where content is different or additional to
that for project aspects to this topic, it may be added [here]…Anything that applies to
projects and portfolios as well as programmes should be included in the general section’
Section template guidance.
e. Portfolio content
‘An explanation of the application of this topic at a portfolio level is to be included here,
where applicable. Where the general principles need to be adapted, enhanced or
extended for specific portfolio application, where content is different or additional to
that for project and programme aspects to this topic…it may be added [here]…Anything
that applies to projects or programmes as well as portfolios should be included in the
general section’ Section template guidance.
3.5 Risk Management









3.5.1 Risk Context


Author views that shouldn’t be included e.g. para 2 page 1.
Needs to be succinct.
Poor English e.g. Final word on page 1 ‘both’, Para 1, page 2.
Rename process phase as steps (due to specific meaning for
phases/stages).
PESTLE should be in 3.5.2 (already in 3.5.1 – no need to have 2
mentions)
Unjustified assertion that something is ‘important’ or ‘critical’.
By having in BoK it is already important.
Terms used in quotes devalue the meaning of the terms.
Final para, page 2 – looks like coming from project managers
point of view which unwise in BoK.
Page 3 – portfolio RM likely to take lead from corporate RM.
Not defined in isolation.
Difficulty in understanding purpose for having 3.5 and 3.5.1
Definition not in keeping with purpose i.e. broader context of
Page 4 of 7






3.5.2 Risk Techniques

RM – business environment, risk culture (existing and/or
intended). JL to send through suggested alternative definition.
2nd para goes back into definitions of RM. Should go to 3.5.
3rd para – upside/downside risks – revisiting threats and
opportunities discussion from main section. When take 3
elements out of 3.5.1 running below 250 words. Risk context
is a rich area for discussion (business environment, culture,
appetite – 3 substantial points that could be discussed).
Scalable talked about twice but not expanded upon.
PESTLE duplicated.
Portfolio – emphasis not on macro-shocks. Don’t agree with
any elements under this section. Should be much more about
the business including other projects and programmes. RM in
portfolio bias here not risk context for portfolios. Align RM
culture with organisational RM culture and appetite and
energy for achieving change.
Need to be clear on use of ‘environment’ to ‘context’ to
minimise confusion with various meanings (even within BoK
structure).
Page 2, para 5 – project to programme – needs to talk about
all directions of travel (project to BAU, BAU to project,
etc).Diagram would be helpful here. MoR diagram is good,
could be improved.
Unhappy to leave programme and portfolio empty.
Programme – escalation, standardisation/consistency
Portfolio – making link to the business whether strategic or
financial (http://www.afaprojects.com/blog/?p=474)
Page 5 of 7
5. Have the APM definitions been adhered to (APM Body of Knowledge 5th edition glossary)?
3.5 Risk Management

3.5.1 Risk Context
Terminology consistency e.g. APM reference of non-projects
as BAU, v. day-to-day.
 5th edition – only applicable to project management.
New section – not in 5th edition
3.5.2 Risk Techniques
New section – not in 5th edition
6. Has existing content from 5th edition been reviewed and edited/incorporated?
3.5 Risk Management
Kind of, but not very well.
Significantly different world if now looking at programme and
portfolio.
3.5.1 Risk Context
3.5.2 Risk Techniques
7. Have the items in the 1st draft feedback been referenced in the content?
3.5 Risk Management
3.5.1 Risk Context
3.5.2 Risk Techniques
8. Have any diagrams or tables used directly support the content, and have they been explained
or referred to in the text?
3.5 Risk Management

Discussion around process (PRAM process) whole dialogue
could be bullet form to make more precise. Doesn’t relate
well to the diagram – doesn’t articulate diagram very well.
Not fundamentally wrong, but almost every para expressed in
complex way or unnecessary initial pre-amble. Needs to be rephrased.
3.5.1 Risk Context
3.5.2 Risk Techniques
9. Are there any other references that could be incorporated into the further reading?
a. Does further reading fall into one of the following categories:
i. Further reading or notes that directly support the content
ii. A list of further reading for the section i.e. further reading which although
not directly used have contributed to the ideas in the content
Page 6 of 7
iii. More general sources from the management or technical literature that is
considered to be important and which are relevant in a more general
sense to the readership.
b. Have UK (or other relevant) standards that the content is compliant with
been referenced?
c. Are further reading items publicly available?
3.5 Risk Management
See feedback from previous reviews – lots of references provided.
3.5.1 Risk Context
See feedback from previous reviews – lots of references provided.
3.5.2 Risk Techniques
See feedback from previous reviews – lots of references provided.
10. Out of the issues we’ve talked about, which ones are the most important to you, and why?
3.5 Risk Management



Needs to be looked at to draw out fundamental principles,
and style used (negative approach).
Needs to be clearly stated.
Starting with 3.5 then filters down into 3.5.1 and 3.5.2
3.5.1 Risk Context
See above
3.5.2 Risk Techniques
See above
Page 7 of 7