Body of Knowledge refreshStructure Working GroupPaper 4

16 November 2011

2 draft consultation: comments on approach

  1. P3 management

No. / Comment / SWG
1 / Reference is made to P3 Managers - a generalisation that confuses responsibilities (e.g. project manager vs. line manager) and assumes similarities (e.g. a portfolio manager has a distinctly different role to a project manager). / Definitions of P3 management will be covered in the introduction and included in final draft review. This should address these comments.
The roles are different but for example communication will remain the same regardless of project/programme/portfolio. The behaviours will differ, but this is the Body of Knowledge, not the Competence Framework and so these subtleties will not be covered.
There are clear identifiable differences where content is process based. The Body of Knowledge is not process based. Included in the introduction is content covering P3 and how they relate and differ – when is a project not a programme and vice versa.
2 / The detailed content appears to be of a generally good standard and cover the key topics but the use of the "P3" concept as such an overarching framework leads to a jargon-heavy, artificially-structured and less readable guide for change professionals.
3 / The constraints of the P3 structure also lead to a loss of focus on the project lifecycle and the natural sequential flow of activities through the guide, and to much repetitive and redundant content, especially in the "soft skills" chapters where the distinctions between the 3 areas is broadly irrelevant.
4 / I appreciate that the P3 structure is by now probably a given, particularly as I fed concerns on this in the group review stages before seeing the entire BoK, but as a big fan and user of the old BoK, with its real-world, plain-English style, feel the new version could be greatly improved by the removal of unnecessary jargon and redundant distinctions between the "3 Ps" in every chapter.
5 / Reference to P3 management as a profession – is it one, or two or three?
6 / The BoK appears to be written from a Project Manager view rather than Project Management. This links to a requirement for a consistent Glossary - potentially we have lost some of the clarity about roles.
7 / Some concern that the BoK appears to represent 'stove pipe' or silo project management.
8 / From a 3P perspective the structure seems unwieldy and inconsistent. Inconsistency applies also to authoring.
9 / P3 Management tries to balance the different objectives of Projects, Programmes & Portfolios (P3) and the scale of initiatives. The balance is a little too much towards P3 being a continuum. The advice to mix and match, while valid for the experiences is too sophisticated for a BoK.
10 / Differences between P3 and business-as-usual (BAU) might be highlighted a bit more. For instance, P3 aim at creation and delivery of new products, processes and services, while BAU tackle current and repeating activities within given processes. Sometimes a "grey" area may exist between process improvements and projects, but the management by project approach should be pursued wherever possible.
11 / P3 has been adopted as a reference for discussions of the 3 Ps. Like all distinctions they both add and subtract. For example, some of the material related to projects, inevitably appears under the programme or portfolio section. Will project practitioners look under portfolio section?
12 / Some of the differentiations made between what happens in Portfolio, Programme and Project management create a complexity that does not exist, e.g. Negotiation. The specific concern is that this may produce examination questions that do not add value to the assessment. This is a single example, there are many others.
13 / The importance of having a clear, shared and understood P3 'mission' does not come across.
14 / The key role of the P3 Manager in developing and implementing an organization strategy for the P3 is not evident.
15 / There is a risk that in broadening out to include Programme and Portfolio management we will confuse people about Project Management. In some sections there are distinct differences. / The authoring process has taken account of the distinct differences mentioned in this comment by writing each section by exception.
16 / The inclusion of Portfolio and Programme Management within the BoK is a decision by APM, the level of detail matters, the focus remains with Project Management.
17 / As Team Leader for drafting the Learning & Development section, considerable time and effort went into creating Section 2.2.3 (now 2.2.4) and I was rather surprised and quite disappointed to find that the separate Project, Programme, Portfolio sections had been removed and replaced by a single, general section. / Learning and development will not vary according to project/programme/portfolio.
ActionSWG13: refresh team to check previous consultation feedback.
18 / Not entirely convinced about including 3Ps in one document. Project and Programme are easier to align but Portfolio is different (circular rather than linear) and creates problems - this could be why some of the content is missing and seems 'light' - trying to cover too much at too high a level.
19 / At an introductory level, need to referenfce the 3Ps but then should focus on Project Management. V5 covered Project Management well - trying with V6 to scoop up too much in the same sized bucket.
  1. Portfolio

No. / Comment / SWG
1 / Portfolio is described as having a life cycle. Actually, PfM is an ongoing, BAU activity, as distinct from Project and Programme which clearly do have life cycle. The OGC 'definition' and 'delivery' cycles are not 'life cycles' in so far as thay do not have a clear start and a clear end. / See above.
2 / The broad equivalencing of portfolio management (which is a business management responsibility) to project and programme management (roles generally taken by change professionals) feels incorrect to one who has worked within all 3 areas, and creates a much less clear overall handbook for our main audience - those who are endeavouring to deliver projects and programmes as their main role. I fear that by producing something aimed at too broad an audience we may make it not fully suitable for either group.
3 / But most of the rest of the document seems to assume that the portfolio organisation is also managing the programmes not just coordinating them. Both approaches are equally valid and may be applicable in different organisational situations. Many of my upcoming comments are trying to address this difference between the definition and this draft of the PMBOK, but I don't guarantee I spotted them all.
4 / Text reads 'Setting deals with the factors that are outside the boundaries of the project, programme or portfolio that will, nonetheless, have a significant impact upon the way the work is approached and carried out'. This implies that the 'setting' is outside portfolio, but the setting for a project could well be the programme and portfolio.
5 / Can't understand why we differentiate between programme and portfolio management - only need one or the other?
6 / Portfolio = supplier of resources and a number of programmes, e.g. bulldozers or IT resources.
7 / Once you startfitting into the nuts and bolts, may be few differences.
8 / So difference is about scope and context - programme = numbers of related projects, portfolio = numer of unrelated projects.
9 / Portfolio management is about resourcing a number of programmes - providing a portfolio of resources as a 3rd party supplier.
10 / Different strategic level - portfolio management more strategic, there is momentum behind portfolio management now.
11 / We will encourage grade inflation; everyone will now be a portfolio manager. We should stand form on a portfolio being the totality of an organisations investment in change, not that a portfolio is characterised by contribution to objectives.
12 / Portfolio Management is not primarily about relations between programmes and projects but about their strategic positioning in the organisation. Hence all projects will normally be within the one portfolio. If a large organisation has separate divisons and chooses to exercise portoflio management at the divisional level, the same applies at that level. This will include prematurely closing projects or programmes where they are no longer viable. Should also allow for projects to be closed, even when they are themselves still viable, if they are no longer the highest priority for resources.
13 / The meaning of Portfolio different than Financial Portfolio might be outlined (e.g. In this Body of knowledge the concept of Portfolio is meant to engage projects and programme, which is different than the commonly recognized topic of financial assets potfolios. In some cases, however, in a Corporate portfolio the two concepts might co-exist and the investments in P3 portfolio compete with those allocated for managing of financial assets). Similarly a P3 portfolio might compete with resources allocated to business-as-usual processes. / ActionSWG14: Consistency authors to review.
14 / No mention of "Design Authority" function across the portfolio. So whilst there is plenty of management governance to guide towards outcomes, where does the content richdecisioning happen on how to make this happen? / See above.
15 / Portfolio is described as having a life cycle. Actually, PfM is an ongoing, BAU activity, as distinct from Project and Programme which clearly do have life cycle. The OGC 'definition' and 'delivery' cycles are not 'life cycles' in so far as thay do not have a clear start and a clear end.
16 / Portfolio Management is new and thus there isn't enough information out there at the moment - trying to run before we can walk. Would be better to focus on Project Management at this stage - may need separate documents for each strand.
  1. Programme

No. / Comment / SWG
1 / Programme: In danger of suggesting that programme level quality management is simply about the projects. Can we draw out the QA applied on programme-level only activities (e.g. QA of programme governance activity)? / Sections are written by exception so this is addressed through that.
2 / Programme = executor --> mix of projects.
  1. Balance

No. / Comment / SWG
1 / Soft skills tend to be the things that bring about project failure - balance of softer skills is wrong - too much on techniques, e.g. one page on ethics. / Refer to the scope and purpose of the Body of knowledge.
2 / Needs an editing decision - books on ethics and all we have is one page.
3 / On Requirements Management we have probably too much - could be edited.
4 / Why do some sections have headings for 'Project', 'Programme' and 'Portfolio' management and others don't, e.g. Learning and Development - which would be different for each. No reason why the model couldn't be used here.
5 / The BoK looks like a set of functional silos, this comment is referenced to the Iron triangle and also connects to Risk and Res. Management.
6 / Other organisations are responsible for Law/Accounting, etc - project managers need an awareness of these areas but are not lawyers or accountants and are not 'expert' in those areas. So may be a case for presenting the BoK to give due emphasis to project management technical areas (which is APM's area of specialism).
7 / Monte Carlo and other techniques should appear such as LEAN, AGILE and 6 Sigma. /
  • These are covered in Risk Techniques 3.5.2

8 / There is a wealth of evidence that suggests that the primary causes of Project failure are people related and not due to poor understanding of techniques. So, one would expect that the ‘People’ topics in the revised BoK would be well populated with authoritative information. However, whilst the equivalent of three sides of A4 are devoted to the topic of ‘Requirements Management’ [3.2.5], a key topic like ‘Ethics’ [2.2.3] barely fills half a page. / Refer to scope and purpose of Body of Knowledge. Further supplementary and interpretive material can be produced to expand upon BoK.
9 / It is not that there is a paucity of material in the public domain on Ethics, nor can it’s relevance to Project Managers be questioned - there was a whole workstream devoted to the subject at a recent APM Conference! But the text fails even to mention whistle-blowing, or the dilemmas that can face Project Managers when they learn more about the origins of some inputs to their projects (e.g. raw materials, finance, research material etc.); or the applications to which their project’s outputs may be put (e.g. arms, GM, repression by foreign powers etc.); or the machinations of the organisation on whose behalf they are managing the project. /
  • This comment refers to points that are outside the scope of the Body of Knowledge.
  • It may be an idea to include further reading in Ethics which refers to things such as ‘whistle-blowing’.
  • Personal and corporate ethics would be addressed through the Competence Framework and the code of ethics. Code of conduct is already included within the further reading.

10 / The whole of Performance should be covered, not just quality. /
  • This does not need a separate section.

11 / The structure still feels uneven. Loads in some sections & other sections relatively small.
  1. Structure

No. / Comment / SWG
1 / I do feel that there are certain inconsistencies in logic in the order of the various sections within the document, i.e. I think that the logical order should be governed by importance/necessity within the life cycle. /
  • This comment highlights things which are deliberately not what the structure is about.

2 / Setting. Strategic Management should appear before Operational Management. /
  • All of the sections are alphabetised in order to avoid giving one section more importance than another.

3 / Skills. I consider that these should be listed in the following order, Leadership, Delegation, Influencing, Teamwork, Communication, Conflict Management and finally Negotiation.
4 / Professionalism. I believe Ethics should be the first subject matter followed by the rest in the same order as now.
5 / Management. I think that Organisation should be placed after Business Case.
6 / Scope Mangement. I think this section should be re-ordered as follows, Managing Change, Benefts Management, Requirements Management, Change Control, Solutions Development , Configuration Management.
7 / Financial Mangement. I think that Investment Appraisal should precede Funding, then Budget Control.
8 / We also find it inconsistent that, although APM have stated the change in the nature of the BoK to function based thus removing associated techniques, the technique of Risk Management is still included. It seems that Risk Management is regarded as an essential technique but Value Management is not. If only VM were to be given a greater status, so many more projects would add value to their organisation. /
  • This comment is correct – not all projects have to use value management. Risk management is an essential component of projects; value management is not.

9 / HM Treasury mandate the use of VM in government projects (Green Book) and the OGC commend its use (MoV). Thus in our view Risk and Value Management should be given a similar weighting and treated equally. /
  • HM guidance has decided that value management is worth having and is important; however, this does not mean it has to be given prominence in the Body of Knowledge.

10 / As the APM moves towards chartered status, such inconsistencies really need to be ironed out and perhaps some more reflection on the purpose of the BoK is required rather than rush into the change simply to maintain timescales. /
  • The Body of Knowledge is a separate project, not part of a Chartered dependency.

11 / Why is Control (3.1.2) covered before Planning? / Sections have been alphabetised.
12 / Information Management should be coordinated with the Knowledge Management section (1.1.4) so they work together and do not have inconsistencies. / Check definition –
Action SWG15: consistency authors.
Knowledge management is about organisational, information management is about project specific and are therefore very distinct.
13 / Logical sequencing of topics would be attractive but it is recognised that there will be a wide range of opinions on what that order should be. / Sections have been alphabetised.
14 / Placing certain topics in Interfaces potentially implies that level of understanding required will be less than what will be necessary in reality.
15 / An example is the Value Management text which is buried without reference within Requirements Management and Solutions Development. /
  • This will be indexed and the user will be able to use the search function if viewing the publication online.

16 / The section 3.2.5 is really confused and misses many of the key principles. It moves to and fro between Requirements Management and Value Management.
  1. Diagrams

No. / Comment / SWG
1 / Quoted techniques need simple examples to illustrate them (as one would find in HMT Green Book) / Covered as above.
2 / I note that Section 4.2 and 4.3 are also short with no references or diagrams. Is this a style for all of section 4 compared with other sections? Should we have been told?
3 / I note that Section 4.2 and 4.3 are also short with no references or diagrams. Is this a style for all of section 4 compared with other sections? Should we have been told?
  1. General approach

No. / Comment / SWG
1 / There are also other detailed examples of unnecessary jargon where the previous BoK was very much in plain English, which distinguished it favourably from other PM guides (e.g. "Cybernetic Control" in chapter 3.1.2 of the new version). /
  • By definition, ‘jargon’ means a technical term. However, any ‘unnecessary jargon’ will be defined and explained in the glossary.

2 / Potential danger that the integrative nature of Project Management is not seen? /
  • This will be dealt with in the Introduction.

3 / Might be okay depending on presentation of BoK and links to competency models.
4 / Concern that the structure promotes silo thinking? /
  • This will be dealt with in the Introduction.

5 / The BoK appears to be written from the perspective of a standard life cycle model, front end loaded with less emphasis on agility for example and extended life cycle (ref 1.1.5). / Not in terms of life cycle.
6 / It is recognised that models should not be prescriptive, others are available, there should be choice.
7 / Content does not reflect all types of organisation and the current more feasable practice. Some organisations only deliver projects, e.g. software development houses.
8 / What is the difference between project management and change management? Needs a recognition of how it links and how it is different.
9 / Recommendation: Needs to include guidance on how the building blocks link together, e.g. where is Risk Management applied - the plans could be included in a pathway document. / ActionSWG16: APM to take forward.
10 / How is PM implemented in the organisation? / Portfolio refers to this.
11 / How is PM embedded in the organisation? / Portfolio refers to this.
12 / Your core processes underline this as they include benefits realisation. Don’t fall into the trap of thinking (like in the new MSP) that it happens in “bau”; a programme is a matrix environment and so can happen in both.
13 / The BoK is not pan-sector it has a construction focus. / SWG disagreed with this. This comment is not representative of other consultation feedback.
14 / The BoK should help Project Management professionals deliver successful projects and avoid avoidable mistakes. / Refer to scope and purpose of BoK.
15 / The BoK creates the impression that the topics sit in individual silos, the reality is that they interlink. There are topics, e.g. Health and Safety, that go across all aspects of the BoK, there are also distinct knowledge sets associated with such topics, e.g. Legislation. /
  • This will be dealt with in the Introduction.

16 / The BoK is built on the assumption that organisations are generally the same and does not appear to be accessible by, for example, smaller, non-bureaucratic organisations. / One of the review questions was around scalability of content so this has been addressed through the consultation.

Page 1 of 8