Specialist in effective change.
Accredited MSP™ and PRINCE2® trainer.
PRINCE2 2017 My Issues
This is an overview of the Issues I raise for the PRINCE2 2017 edition by Axelos.
This list of issues follows a review of the PRINCE2 2017 guide.
The following list of issues is based on a cover-to-cover read of the PRINCE2 2017 guide. I used three types of issues:
| High | Breaching principles | |
| Medium | Could lead to misunderstanding and poor practice | |
| Low | Would rather not see this in PRINCE2 guidance or small recommendation. | |
Issues contain links for further reference where necessary.
| Severity | Chapter | Description | |
| 1 | Low | 1, 2.5.2, 3.3, 7.3.6 | The term "Sponsor" is used. In the PRINCE2 context this is not a good term. Avoid it. The term "Sponsor" is typically used by Suppliers in "Delivery Only"/Supplier-led project approaches. In this view a Sponsor is someone who is not involved at all in the project and will never take any responsibility; compare to the sponsor of a sports club. Although I can more or less understand using the term "Sponsor" in the context of MSP, in PRINCE2 the term should be avoided or used with careful explanation. |
| 2 | Medium | 1 | PRINCE2 can be used in mergers and acquisitions, according to the guidance. I very much doubt this statement unless we are talking about projects in the context of a larger programme (under the guidance of MSP). |
| 3 | Medium | 1.3 | Key message: minimum requirement. Applying the Principles should be sufficient. Demonstrating the rest (how?) can easily lead to bureaucracy. The quote "users ... have freedom" is very unfortunately and indicates rigid prescription. |
| 4 | High | 2.1 | Uses an example of an IT project. This indicates a project dominated by specialists and their skills, without a Business Case, without proper ownership and "delivery only". The correct position should be: "There are no IT projects; only Business projects possibly with an IT component". Since especially IT made a huge mess of PRINCE2 (confusing the goal and the means to a goal, delivery only, (internal) supplier led), this should be avoided. Almost by definition an "IT project" breaches the principles of Justification, Organization, Focus on (BUSINESS) products and Management by Stages. |
| 5 | High | 2.5.3, 2.5.4 | 2.5.4 discusses specific issues in a commercial environment. But especially in a functional organization (as 2.5.3 shortly discusses) INTERNAL suppliers cause their own problems and often cause a far bigger threat: internal politics based on conflicting interests between departments. This should be discussed as well. |
| 6 | High | 2.5.4 | A very severe issue! The chapter describes a situation with several customers with several customer's business cases, accompanied by examples (e.g. joint venture). These are situations where PRINCE2 will almost never be the right approach; usually it will simply be impossible to appoint an Executive. MSP will be the suitable approach. See issue 2. |
| 7 | High | 2.6.2 (and in every following chapter) | "If the project is commissioned by a customer". Why "If"? This is always the situation in the PRINCE2 context. I assume this sentence refers (incorrectly) to the situation described in one of my most popular articles, PRINCE2 for Suppliers. Especially in the chapter about Benefits (6.6.3) this leads to very strange ideas; is a supplier going to tell a customer to do their Benefits reviews? Very unlikely. In every chapter, the phrase "or the customer" is used. Wrong, for the same reason. |
| 8 | Medium | 2.6.3 | This chapter could be expanded for more clarity. My discussions on PRINCE2 and Waterfall and my views on Agile are very much in demand. There are good reasons for that. |
| 9 | Medium | 3.4 | Keep it simple: Management Stages are defined by risk. All examples given in the chapter are risk-based. By using the examples rather than the simple cause (risk) the text may be misleading. |
| 10 | Medium | 3.5 | Scope tolerance explained by "to deliver only 50% or more of its should do". A very strange and very poor explanation. Shows poor understanding by the author? |
| 11 | Medium | 3.5 | Risk tolerance. A poor and very partial explanation. |
| 12 | Medium | 4.3.1 | Suggest that the PMI's project management plan is the same as the PRINCE2 PID. This ignores the basic differences between PMI (a Supplier's approach) and PRINCE2 (a customer's approach). See this page. |
| 13 | Medium | 6.2 | Describes that an initial version of the Business Case will be produced while starting up the project. In previous versions there was different terminology. The Brief (output of SU) contained and still contains the Outline Business. But the Initial Business Case was in previous versions a part of the PID. In the 2017 version the term Initial Business Case seems to be dropped as output of IP (and as part of the PID) which is not a bad idea. The current terminology could cause confusion between versions. The term "Initial Business Case" should probably be dropped completely, as is suggested later in the same paragraph. |
| 14 | High | 6.2.3 | "Senior User (...) is also accountable for confirming that the forecast benefits are realized". No, the Senior User is accountable for realizing the benefits. "It is usually advisable that the Senior User comes from an area of the business impacted by the change". No. For the same reason it is not advisable but a Must. This is an unacceptable form of watering down the role of Senior User and is very risky in any project. |
| 15 | Low | 6.2.4 , 6.3.3 | "Senior Supplier: accountable for the supplier business case" This statement is irrelevant in this context "If they (supplier's business case) exist". They always do exist. Even internal suppliers (such as an IT department) will have their own reasons (business case) for undertaken the project. Ignoring this fact is usually very dangerous and will lead to politics and power struggles. |
| 16 | High | 6.2.4 | Described the role of Project Assurance in the context of the Business Case. Project Assurance is not a role; every member of the Project Board have their own assurance responsibilities (as more or less described earlier). What is described here as Project Assurance responsibilities are all in fact responsibilities for the Business Assurance responsibilities of the Executive. What is described is impossible and even undesirable for the other parts (User/Supplier Assurance) of the Board. |
| 17 | Medium | 7.2 - Fig. 7.3 | Project Assurance is shown as a separate staff/support department. In fact Project Assurance is just another responsibility of every individual member of the Board and not a separate body. Obviously each individual member of the Board can delegate some responsibility to another person but will always stay responsible, as described in 7.2.1.5. There has always been confusing about Project Assurance, often resulting in bad practice (such as one person in the role of Project Assurance for the entire Board). This diagram does not help. Project Assurance should for the Project Board members be described in similar fashion as Project Support is described for the Project Manager (7.2.1.9): not optional but allocation of a separate individual ... per member is. See issue 16 |
| 18 | Medium | 7.2.1.4 (7.2.1.3) | On the support topic this chapter ignores maintenance/support problems. Suggestion: If the supplier will be responsible for maintenance/support after the project, a service level agreement (or similar) should be one of the project's products. If the supplier will not be responsible for maintenance/support after the project, there should be Senior User responsibilities. This issue should not be played down. Unlike the text states, the distinction is important and addresses a lot of real problems that are mentioned by people from ITIL environments. |
| 19 | High | 7,2,1,6 | The suggestion that a Change Authority can authorize Off-Specifications is very dangerous. Basically a Change Request comes from the user (see this page) while an Off Specification comes from a supplier. A Request for Change by definition always proposes to deviate beyond tolerance, so should always be escalated to the Board; this is the reason for appointing a Change Authority. But an Off Specification, when raised by a Team Manager, can often be managed by the project manager (corrective action), using one tolerance (example: cost) to protect another tolerance (example quality). If an Off-Specification is escalated to the Project Board, it is good practice that the Senior Supplier should answer to the Executive because mutual agreement is breached. This is less likely when a Change Authority is used for these issues. Using a Change Authority (and a Change Budget!) for Off-Specifications? Suppliers would love it! |
| 20 | High | 7,2,1,7, 7.3.4 | "the project manager comes from the supplier". This is common practice but at the same time a major risk. The supplier always have a business case that is conflicting with the customer's business case and that is why the project manager should come from the customer. Apart from the conflicting business cases, a supplier's project manager will simply be unable to do any work on the benefit's side. This issue can easily be seen as a breach of the Justification principle. |
| 21 | Medium | 7.2.1.10 | The most important constraint for combining roles is missing: combining Customer and Supplier roles in the Board are not to be combined. "Not recommended" is simply too weak, for obvious reasons. |
| 22 | Low | 7.3.3 | Describes possibility of several projects within a programme with the same project board members, even alignment of stage boundaries. As a MSP trainer I would suggest this would indicate poor project design by the programme: probably skill based projects with many interfaces between them. |
| 23 | High | 7.3.4 | "There may be a joint project board" (with the customer and all suppliers). What does this mean? A project board is a join between customer and supplier by definition. "The Executive may be supplied by the customer"? This is always the case! Very strange and not clear. |
| 24 | Medium | 7, 7.3.8.4 | The chapter ignores the fact that during a project (at the end of each stage) the project board and the teams can change. This is usually the result of a true product focussed approach. Paragraph 7.3.8.4 even recommends against this practice. |
| 25 | Medium | 7.3.8.5 | Should clearly state the responsibilities and commitment of project board members. They commit to the usage of resources. |
| 26 | Low | 8.1 | The term "Quality Assurance" for many people is a very confusing term because it has little to do with their perception of quality. Would it not be better to rename it to "Corporate/Programme Assurance"? |
| 27 | Medium | 8.2 | "The quality management approach will define how and when the quality register is reviewed and updated". A far too formalistic and procedural approach. Quality is too important to describe it in this way. |
| 28 | Medium | 8.2 | "during the initiating a project process as the product and quality control measures are being defined". Could create a lot of confusion; only the main products and the ones in the next stage. Manage by Stages, remember? |
| 29 | High | 8.3.2 | "frequently the case that more than one organization is involved in a project". This in fact the basis of PRINCE2 and of the Organization theme |
| 30 | Medium | 8.3.7 | Quality responsibilities: On product level the guidance should be that the customer of the specific product should set the criteria and should check the quality. This could be the end-user but could also be (possibly more frequently) the (or a) receiving team. Quality responsibilities on this level are impossible to describe in the general approach. |
| 31 | Medium | 8.3.8 | Acceptance criteria: "ease of use, ease of support, ease of maintenance, appearance" are presented as measurable criteria? These are all subjective and not measurable. |
| 32 | Medium | 8.3.8 | Acceptance criteria: "running cost, availability, reliability, performance" are all criteria probably impossible for the project to demonstrate. These measurements will be demonstrated after the project, while using the products (as 8.3.10 attempts to explain). |
| 33 | Medium | 8.4 | The Quality Review Technique is in most cases still largely far too procedural, bureaucratic and extensive. Nice for overly detailed exam questions but not for real guidance. The tailoring principle should have been discussed here. |
| 34 | High | 9.2.1 | "In some customer/supplier contexts it could not even be appropriate for the project manager to see the details of a supplier's team plan". This is wrong. The team manager is primarily under the control of the project manager. The team plan should therefor also being approved by the project manager. Any details solely between the team manager and the supplier's organization are not part of the PRINCE2 team plan and should be irrelevant (because out of scope and control) to the project and the project manager. If not, risks and politics will be introduced. Remember the principle of roles and responsibilities. The mentioned details would be part of a different plan between the team manager and the supplier's board, both in different roles now (!) as described in PRINCE2 for Suppliers (the organizations diagram). |
| 35 | High | 9.3.1.2 | Tip: transition/business change in project's scope/plan. Not in the PRINCE2 context. If this would be desirable in PRINCE2, take the guidance from MSP on board and have a discussion about the Senior User, similar to the MSP BCM. Currently this is out of scope, making the tip useless and potentially confusing. |
| 36 | Medium | 9.3.1.2 | Page 107, first line: "The plan is broken down ...". Assume this should read: "The product is broken down ..." |
| 37 | Medium | 9.3.1.2 | Consideration on product breakdown. Suggests that suppliers could have their own preferences. "Neither breakdown is wrong". But following the supplier's preference introduces a major risk of incomplete scope, poor quality (criteria) and in general poor communication to the users. |
| 38 | Medium | 9.3.1.2 | Consideration on product breakdown. A weak and incomplete description of external products ("created by other projects or purchased or hired directly from a supplier") and an even weaker example (earth moving machine). |
| 39 | Low | 9.3.1.2 | Page 109: "The product flow diagram may be derived from a benefits map". Good guidance but since this tool is not described in PRINCE2 also a useless and possibly confusing suggestion, |
| 40 | High | 9.3.1.5 | page 112, Assessing resource availability "The number of people who will be available (...) Should be established". Please note this should be in the plan, approved by and committed to by the board. Not doing so, creates the all too often occurring practice that the project manager is responsible for finding people; a job the project manager does not have the power for. While planning, the board should advice and support. |
| 41 | Low | 9.3.1.5 | page 112, Assigning resources. On defining "task owners". Why so complicated? Use Team Managers by default. |
| 42 | Medium | 9.3.1.7 | Analysing risks to a plan is placed unfortunately. This should happen before documenting a plan, especially because implementing risk measures cost resources and time. |
| 43 | High | 9.3.3 | Severe issues with described Agile practices. |
| 44 | Medium | 9.3.3 | A management stage for the SU process in an Agile approach? This is not possible at all; pre-project is never plannable so not a stage (as explained in all previous versions!). |
| 45 | High | 9.3.4 | Supplier's plan for the customer's project manager to maintain their plans. Completely unclear what is supposed to be achieved here. Whatever it is, it is unnecessary within the normal PRINCE2 approach; everything is and should be already covered by the normal plans and hierarchy. If this is purely about the background of the supplier's business case related information, the whole chapter is unnecessary and confusing. |
| 46 | Medium | 9.3.4 | If described well, this should be the kind of information partly describing why a PID is rarely a (single) document. Confidentiality and/or specific domains (products) which could have the same impact on users and suppliers: specific, tailored filters of the PID. |
| 47 | Low | 10,2,1 | Table 10.1: Since risks are perceived differently by Executive, Senior User(s) and Senior Supplier(s), the whole Project Board - not just the Executive should ensure that the risk management approach is appropriate. This would also be more consistent with the described responsibilities for Project Assurance. |
| 48 | Low | The frequent references to the "Agile approach" make it seem like this is a very new and different approach. In fact it is not new and not different. The writers seem to have an unhealthy obsession with what is "new" and "different" for them and it shows a disregard for what PRINCE2 always really was. This occurs throughout the guidance; an rather annoying example can be found in 10.3.5 |
|
| 49 | High | 10.3.6 | "In a commercial context (...) need for more than one risk register" This is inconsistent and dangerous; probably a faint, not well thought through attempt to solve the problem that I described here. This seems to be the key recurring issue with this 2017 version. What was the goal here? More integration with MSP? Finally giving in to the commercial demands of many typical suppliers (mainly IT) that could never work with PRINCE2 but wanted a piece of the commercial action? |
| 50 | High | 10.3.7 | Discusses the need for a Risk Budget and rightfully states that this is probably only useful for more complex projects. But next, the chapter describes that during the project risks will occur or not, and new risks will be identified. The text however, does only recommend a provision in the Risk Budget. The conclusion is that the guidance assumes that the Risk Budget should be defined once and kept stable during the project. This is unworkable and inconsistent. Just as any other part of the PID, including the Business Case and the Project Plan, the Risk Budget is also not stable and should reviewed at the end of every stage. This is especially relevant since the (updated) Risk Budget will have an input on the Business Case, Continuous Justification (Principle) of the project. |
| 51 | High | 11.3.5/6 | There is a fundamental difference between a Request for Change and an Off-Specification, the reason why they can not and should not be managed the same way. A RFC by definition comes from a user of the product (this may be a "receiving" team; "the customer of a process is the next process"). But an Off-Spec by definition is raised by a delivering team; they can not meet the specification of what is required. This normally means that a RFC is beyond tolerances, so should be escalated to the Board, while a Off-Spec can often be managed by the PM because the Off-Spec is beyond the tolerances of the Work Package but not necessarily of the Stage Plan. In this case the PM should first look at corrective action. Only when this is not possible, escalation should follow. For more or less the same reason it is very unwise to use a Change Authority and a Change Budget for Off-Specs. Failure to deliver by a supplier should not be handled in a relatively informal way. The Change Authority and the Change Budget should only be used for cases where the user changes their minds; not for failure. This reasoning makes the description of a "Change Authority for Work Packages" a strange view, hinting at micro-management and unnecessary bureaucracy. A Change Authority should be for products on the level of the Board; products they approved as part of the plans. |
| 52 | Medium | 11.3.5 | In previous versions, PRINCE2 suggested that the Senior User(s) could be considered as a Change Authority. This has now been dropped (in favour of a vague suggestion of Project Assurance. In many cases the Senior Users as explicit Change Authority would actually help to bring the number of RFC's down while increasing their quality. |
| 53 | High | 11.3.6 | Because of the previous point, it is very unlikely to discuss a Change Budget with a supplier. Involving the Supplier will likely lead to using the Change Budget to be abused and to hide failure and low quality. |
| 54 | Medium | 11.4.1 | Insinuates that the PM can only take corrective action on issues that can be managed informally (and therefor not need the Issue Register). This is incorrect, see issue 51. |
| 55 | High | 11.4.3/4 | These chapters make a severe mistake, not understanding the difference between taking corrective action by the PM (to keep things within tolerances) and escalating a situation that can not be kept within tolerances. A breach of the Management by Exception Principle. It also severely undermines the role of the PM. Proposing corrective action: "If any of the proposed options would take the stage or project beyond any tolerance (...)" refer to the Board is therefor not the right way. 11.4.4 corrects this description a bit but this does not make 11.4.3 less wrong and unclear. |
| 56 | Medium | 11.4.4 | Table 11.3. Following the previous issue, "instruct that the off-specification to be resolved" automatically means a request for an Exception Plan. Otherwise the PM would not even escalate to the Board. |
| 57 | Medium | 12.1 | "Tolerances (...) for cost and time (...)." "(...) may also be tolerance levels (...). Apart from these lines being a breach of the Continuous Justification Principle, this is also not a Best Practice; it is the common practice of focussing only on cost and time. This is in fact a key reason for failure: short term thinking, leading to low quality, leading to overruns of time and cost and lower benefits. Not in line with the spirit of PRINCE2. Strictly spoken (and for the mindset, this is important!), time (usually) and cost are not targets. Benefits, quality and scope are. Time (usually) and cost are consequences. |
| 58 | Medium | 12.2.1 | Table 12.1. There are cases when Time is critical to the Business Case. This should be added to the table. |
| 59 | Medium | 12.2.2.1 | The example "if weekly checkpoint reports are required, the stage plan will have to include what is to be achieved week by week". Make no sense. A checkpoint report is reporting on basis of the baseline for the work which in this case is the work package and possibly a team plan. So, this/these baseline(s) ideally (!) will have to include week by week achievements, not the stage plan which is the baseline between Board and PM. |
| 60 | Medium | 12.2.2.1 / 17.4.1 | The Team Plan should be added to the controls for the PM. (Table 17.3: project manager only reviews the team plan.) See issue 62. |
| 61 | Medium | 12.2.3 | On work package level exceptions, the PM will advise of any corrective actions? The team manager is under the control of the PM, so the PM will not advise but will decide and take responsibility. |
| 62 | High | 12.2 / 18.4.1 | No mention at all of the Team Plan. This is later followed up by the processes; the Team Plan is made obsolete and in this view should be scrapped completely. This attitude however is not justifiable. The Team Plan is in certain situations a very important control (e.g. ever managed a team abroad?). When used, it should be approved and baselined by the PM. The current view on the Team Plan is inconsistent and poor. The view seems to be that the senior supplier is the main recipient (approver of the team plan). This would be in conflict with the Organization theme where the Board direct the PM, with an unified view on the project. The conclusion is that the guidance on the team plan is very inconsistent. See issue 60. The TM's activity "Accepting a work package" largely describes this point a lot better. It only again turns wrong when it describes that in a commercial environment the PM could not be allowed to see (parts) of the team plan. In this case it is no longer a team plan in PRINCE2 terms. Also, the suggestions that the senior supplier and assurance should approve and be consulted go against clear roles and responsibilities. Whenever this happens (and it often does) it goes beyond the PRINCE2 scope and should not be described as guidance, merely as events outside the project a PM can't control. See also issue 103. |
| 63 | High | 12.2.2.4 | Table 12.2: "Senior Supplier to ensure that progress towards the outcome remains consistent". This is not possible and not feasible (if the term outcome is used in the proper PRINCE2/MSP way). The Senior Supplier will have their own Business Case (always conflicting with the Customer's) and their own limited scope of the project: focus on delivery. Outcomes of the project are entirely on the Customer, especially Senior User side. |
| 64 | High | 12.2.2.4 | Table 12.2: Describes the Project Assurance function incorrectly; not as separate responsibilities for each member of the Board. The generic description is far from accurate. "Verify the Business Case (...)" is basically a Business Assurance function. |
| 65 | High | 12.3.3 | "In agile (...)". This is an ignorant statement by an Agile evangelist, possibly confusing users of previous versions. A quote from an old version of PRINCE2: "the only objective measurement of progress is quality", which is basically the same statement. Also this paper shows what was always promoted, based on principles. |
| 66 | High | 6 / 13.1,4 / 15.2 | There is no mention anymore of realizing and measuring benefits during the project; only post-project. The Benefits Review Plan is omitted or poorly described elsewhere. In any larger project Benefits usually could and should already be measured during the project. So (post-project) benefits reviews would also be planned during Initiation. During closure there will be an update. Measuring benefits during a project (if possible) helps the Executive and Senior User to assess continuous justification and viability of the project. Ignoring this view undermines the most important Principle. See this paper. |
| 67 | High | 14.3 | "request for proposal in a supplier environment". See issue 7. Every time the guidance uses the phrase "or the customer", it will be the reaction to a contract signed by the customer and corporate management of the supplier. Corporate management of the supplier will then mandate the their Supplier-side Executive. Possibly the end of SU will turn a request for proposal into a contract. Basically again this issue is about the wrong and confusing phrase "or the customer" in numerous places in the guidance. |
| 68 | Medium | 14.4.4.1 | Table 14.1: Whoever provided the mandate has to approve and appoint the PM. Often there is no need for this; the Executive could appoint and approve the PM. |
| 69 | Medium | 14.4.3 | Confirmation and approval by whoever provided the mandate of the appointment of each member of the Project Management Team. There usually is no need for this; often it even undermines the members of the Board. |
| 70 | Medium | 14.4.3 / 14.4.5 | Â Ignores the fact that the approach can - and often will - determine the supplier to be used for that approach. |
| 71 | Medium | 14.4.6 | "decide upon suitable management controls for the project". This should not be described as a part of the planning of the initiation stage. Too early and not relevant. |
| 72 | High | 15.3 | "the project board to meet its responsibility for (...) continuous justification". This is the accountability of the Executive. It is certainly not the accountability of the Senior Supplier because they have a different business case. |
| 73 | Low | 15.4.1 / 15.4.2 | "Inform (...) the Host Sites". What does this mean? Techno-babble alert? |
| 74 | Low | 15.4.1 / 15.4.2 / 15.4.3 / 15.4.4 / 15.4.5 | Project board may assign project assurance. This is wrong and a poor interpretation of project assurance. There is always project assurance when there is a board; it is simply one of the responsibilities of board members. Individual members can appoint people to support them in their assurance duties. They can appoint them at any time, whenever necessary (tailoring). |
| 75 | Medium | 15.4.2 | Discussing the approval of the PID talks about reviewing risk and risk responses. There is an important distinction between the PID and the Project Plan that is a part of the PID. Risks and risk responses are mostly part of a plan. Not just the project plan but also a stage plan. A poor statement that should be moved to the next page where viability and achievability of the project plan is mentioned. |
| 76 | High | 15.4.2 | "Confirm all the expected benefits" is simply not possible because expected benefits will not be stable. It should state: "all expected benefits at this time". |
| 77 | High | 15.4.2 / Table 19.3 | The "or the customer" issue - see issue 7 - here (page 184) becomes unrealistic and very inconsistent. A supplier can never assess expected benefits of the customer. Obviously this issue will also have its consequence for the benefits management approach. |
| 78 | High | 15.4.3 | Seek approval for the stage plan by corporate or programme management? If approval by corporate or programme management is required for a stage plan, that would indicate micro-management or a inconsistent or incomplete project plan. For an exception plan on the level of the project plan, this statement is correct. |
| 79 | Medium | 15.4.3 / 17.4.1 / 17.4.3 / 20.4.3 | The product handover should be in accordance with the change control approach. Very confusing when configuration management is called change control and real change control is hardly discussed. See also issue 89 |
| 80 | Medium | 15.4.4 / 17.4.7 | A suggested response to an exception report is to increase tolerances. Since tolerances are part of a plan, this is in fact the same as creating an exception plan (and a new baseline). If described properly, it should show that even exception plans can be handled relatively informally (tailoring). |
| 81 | High | 15.4.4 | The guidance states: In response to a highlight report, action should be taken. E.g. produce an issue/exception report. In a well controlled project this would be extremely unlikely. It would mean that something went wrong before the highlight report which was not controlled properly. If it would occur, lessons should be learned and controls should most probably be reviewed. |
| 82 | High | 15.4.4 | Confirm the updated Business Case by comparing against the outline Business Case? No, against the Business Case version that was part of the PID. The outline was an input for that version. |
| 83 | High | 15.5.2 | If a decision at a stage end can not be taken by the board and they have to ask corporate/programme management, there should be a serious question about the power (role/responsibilities) of the board, especially the executive. |
| 84 | High | 15.5.3.3 | "If a project is run from a supplier perspective". It never is! That is the point of PRINCE2, even in the situation I described here and here. This paragraph and the next support issue 7. |
| 85 | High | 16.3 | "the reasons for undertaking the project as defined in the supplier's business case MAY be different from those defined in the customer's business case". They always are by definition! Customer and supplier seeks very different benefits; the customer's cost is directly related to the supplier's benefits. This is also normally not restricted to commercial relationships; many internal suppliers (e.g. an IT-department seeks more influence and power through higher budgets. |
| 86 | Medium | 16 | "Seek approval for [individual part of the PID] although the project board may prefer to review it later as part of the PID". Excellent point but described poorly. The (formal) decision at the end of Initiation should be a formality; the PID should be developed in strong cooperation with the board. When finally presented as a whole, there should not be any surprises. |
| 87 | High | 16.4.3 | Figure 16.4: Very unlikely that the development of the change control approach will create Configuration Item Records; only for the small number of management products approved so far. During this activity no (relevant) products are planned or created. The preceding text could also be confusing: unless the project is very small, not all detailed products will be planned (manage by stages) |
| 88 | Medium | 16.4.3 | The guidance on the change control approach describes configuration management, but not change control. The ITIL approach, only technical change management; registration in configuration management? |
| 89 | High | 16.4.6 | Project controls: tolerances for delegated authority. Not sure what this means. But if this is about delegation (Board - PM - TM) this can not be true. Tolerances should be set by a plan. Describing it already in the controls is ineffective. |
| 90 | High | 16.4.6 | Related to the previous issue: focusing on the relationship between project manager and team manager, especially escalation, should not be (too strictly) defined in the project controls; they are work package controls. One size usually does not fit all and - possibly more important - this is usually not an item the Board should be concerned with. Management by Exception, Management by Stages, Tailoring should be applied. |
| 91 | Medium | 16.4.7 / 20.4.3 | Include a product for service agreement or contract in the project plan. This is not always necessary and not even always true. Apart from what is described in issue 18, there is no need to create a separate product in the project plan; it can be a part of another major product. Also, it can (and hopefully will) occur in the appropriate stage plan. It is, however, very important that this subject is covered. |
| 92 | High | 16.4.7 | "Confirm the selected people's availability". It is not the PM responsibility. Confirming availability and commitment should be clearly described as the project board member's responsibility. |
| 93 | High | 16.4.8 | A proper Business Case should also discuss cost of operational use and maintenance/support. Should be added to this chapter. |
| 94 | High | 16.4.8 | The Benefits Review Plan, introduced in the 2009 edition, is now severely watered down in this 2017 edition. No more detailed mention of the importance and timing of benefits reviews and the relevance for the Principle of Continuous Justification. |
| 95 | High | 16.5.4.2 | Suggestion of an agile approach in the PID, to be approved by the board. Even the suggestion of low-level tools, such as "epics" and "user stories". Again, an indication of micromanagement and/or only thinkable (but probably inappropriate) for a very small project. |
| 96 | Medium | 16.5.4.3 | Initiating from the supplier's perspective: this does not necessarily mean that the customer's initiation should be approved. A supplier can be contracted per stage or even per work package. |
| 97 | Medium | 17.4.4 | Although partly time driven, most likely reviewing the stage status is event driven. Triggered by completed work packages, issues and risks. |
| 98 | Medium | 17.4.4 / 17.4,6 | Reviewing the stage status and Capturing issues/risks are described too abstractly and formalistic. Suggests a highly bureaucratic approach that is not always necessary or suitable. |
| 99 | Low | 17.4.6 | 2009 issue: The Issue Report is not a report, only causes confusion and the term adds nothing. It is nothing more than a description of an issue, probably just an entry in the issue register. When escalated it becomes part of an exception report. Keep it simple; currently the issue report is a confusing term without much value. This point is properly presented in Table 17.9 (but only there) |
| 100 | Low | 17 | As also in previous versions: Far too much has been made of the daily log. The chapter almost gives it the status of an important, formal product. It is not, it is only the PM's "to-do-list". |
| 101 | Medium | 17.5.4.2 / 17.5.4.2 | The paragraphs on controlling a stage "agile" and "from a supplier perspective" are misleading. Apart from the low-level agile techniques, there is simply nothing new or unique there. This guidance should always, under any circumstances be attempted and was always the proper PRINCE2 view (mainly manage by exception). |
| 102 | High | 18.4.1 | Table 18.1: the team manager approves the work package? Obviously not. Also the senior supplier does not approve a work package, see issue 62. The table also shows that the PM is the producer (P) of the team plan. This is completely wrong. The TM is the producer of the team plan. The PM should approve (and baseline) the team plan. Again: see issue 62. Also, this is inconsistent with Controlling a stage. |
| 103 | Medium | 18.5.2 / 19.4.1 | Table 18.4: team plan should be developed at the same time as the stage plan. Since stage and work package have completely different scopes and timings, this is usually not necessary and normally even ineffective. Prepare team plans whenever they become relevant. The underlying assumption probably is that a team works continuously during a management stage. This is (usually) not a valid assumption |
| 104 | Medium | 20.4.3 | See issues 18, 80 and 92. Also: post-project service and maintenance should normally be arranged. Not just in exceptional situations, as the guidance suggests. |
| 105 | Medium | 21 | Chapter 21 on organizational adaptation is very weak. Apart from common clichés, the chapter does not add much. Most examples are weak and indicate poor usage and a mechanical approach. The real challenge for improvement of project management is about improving the behaviour of corporate management, especially the behaviour of the project board members. This often also involves reducing the power of internally focussed staff departments, controlling their standards rather than benefits and quality (e.g. Finance and H.R.). The chapter is particularly weak because it mainly describes the standardizing, procedural approach that these staff departments all too often pursue. |
| 106 | High | 21.1.3 | Example of organizational tailoring (A, Page 279): this example is very poor. The idea that a project always has five management stages, based om specialist activities is not in line with the PRINCE2 Principles. Basically the text already proves this point: stages based on activities are clearly not focussing on products. Other principles will be breached as well: continuous justification and managing by stages. Activity based stages are almost certainly technical stages, not management stages. |
| 107 | High | A.2.5 | External procurement, sourcing options in the Business Case? As described, this is not a business case topic, rather a project approach topic. |
| 108 | High | Gloss. | Page 382. The term Quality Assurance has been defined incorrectly. It is far wider than just corporate quaity control. See issue 26. |
| App. A | Several issues have consequences for Appendix A |
comments powered by Disqus
Ben u als Opdrachtgever verantwoordelijk voor een project?
Bent u opdrachtgever? Vertegenwoordigt u belanghebbenden van een project? Dan is de Workshop Opdrachtgevers voor u een belangrijke bron van informatie. U kunt hier ideeën opdoen hoe u uw rol beter en effectiever kunt invullen.