Lesson 20: Quality, Part 5
This is the last lesson about the Quality theme.
Based on AXELOS PRINCE2® material. Reproduced under licence from AXELOS. All rights reserved.
Note: PRINCE2 2017 edition is now called PRINCE2 6th edition.
- 00:07 – So welcome back. We have another exercise and this is based on the Project Product Description.
- 00:14 – So this is the content of the Project Product Description. You can see them here.
- 00:19 – So have a look and see if you spot something which is perhaps incorrect, okay?
- 00:25 – So maybe it’s all correct, but if there is something, I’d like you to spot it.
- 00:28 – Take your time and again, use the manual. It’s a good example here of using the manual.
- 00:34 – Don’t look at me. I don’t have the manual. Okay.
- 00:43 – So let me give you the answer.
- 00:46 – This is the Project Product Description and not the Product Description. So there is a difference.
- 00:51 – So we should replace the words Quality Criteria with Acceptance Criteria.
- 00:56 – They sound very alike and it is confusing, which is a pity, but you must know this or you must know where to find this very quickly in the manual if you cannot remember it.
- 01:07 – So, tip here then is to use the manual. Yeah.
- 01:10 – Yeah. It’s important. Now the contents of the Product Description. Let’s look at these.
- 01:16 – So, this is an overview of all the contents.
- 01:20 – Can you spot something that might be incorrect in this document?
- 01:23 – It could also be correct, so I’m not telling you.
- 01:32 – Alright. In this section or in this case, everything is okay. There are no issues with this document.
- 01:38 – All the sections are correct, okay? Maybe I should have tried to change one.
- 01:45 – The next question. We have a new PRINCE2 Project Manager and they are trying to use the Quality Register, so they’re trying to get into it, and what they do is that when a quality test fails, they mark it as failed in the last column, that’s fine, but then when they try to add a new quality test, they don’t know whether to add a new row or just use the existing quality row and add in the new due dates for that quality test.
- 02:16 – What would you advise them and why?
- 02:19 – I have no idea what PRINCE2 says, but what I always do, both for this and also for the configuration management system is that we have one table, that is for the items, for each piece of product, for example, and then each of them is connected to another table which is for all different activities we do for that.
- 02:41 – We do the test once, it fails. Then we go to the next row which is in the second table connected to one row in the first table. We do the test again, fails again.
- 02:52 – We do it again, again, and again until it passes the test. Yes.
- 02:56 – That’s my preferred way. Okay.
- 02:59 – Because we have all the information, because you can change the same field in one table.
- 03:03 – It’s failed for now but after a while, you pass the test and you change it in the same row, and if you want to add new rows, I think it would be very distracting in the main table.
- 03:15 – You won’t have a clean list of all sub-products.
- 03:20 – So your suggestion is to use a different sheet then for that. Two tables. Two tables, okay.
- 03:25 – Yeah. It’s a spreadsheet or a database. Yeah, alright.
- 03:28 – And also for the risk management system. One table for the risks and then for the responses, I always connect it to another table because one risk can have more than one response and one response can be used for more than one risk.
- 03:45 – Yeah, yeah. That’s where it gets confusing where you have one product, but you’ve got lots of different tests for it and trying to have a relationship is not so easy.
- 03:53 – So, what PRINCE2 advises is that we should create a new row and not to use the existing one and the reason is because that failure is history information, it’s important information that we can use later.
- 04:06 – For example, at the end of a stage, we can go and look back and say, “Which team had the most failures in their tests at the beginning or during that stage?” and then we can go and do something about it. We can try to say, “Well, how can we improve this in the next stage?” So this history information for failing is really important. So we should add it to a new row.
- 04:27 – By the way, to add something to that, I’ve always combined the Quality Register with the Configuration Management Systems.
- 04:34 – That’s a good idea. Yeah.
- 04:37 – Okay. The next one, the Project Manager wishes to use the MoSCoW technique.
- 04:42 – Now up to now, we’ve set the MoSCoW technique for product descriptions, but they want to use it for the Project Product Description.
- 04:49 – Is it a good idea for the Project Manager to use the MoSCoW technique for the Project Product Description that we use in the Starting Up a Project process?
- 04:58 – Okay. In the Project Product Description, we explain the product, the scope of the product and it can be based on the major features.
- 05:05 – Do you mean assigning MoSCoW labels to each feature of the Project Product Description?
- 05:10 – Yeah. Yeah. Using the acceptance criteria. I would say that’s a good idea, even though you put it in a way as if the answer should be no.
- 05:17 – I’m trying to be like a PRINCE2 question in the exam paper, yeah.
- 05:21 – I would say it’s a good idea. Correct. Yes, it’s a good idea.
- 05:24 – You can definitely use, you should actually prioritize the requirements even in the main product description.
- 05:30 – Now you can use any prioritization method you like, so it’s MoSCoW or something else, but of course, PRINCE2 makes it clear that MoSCoW is a good one to use.
- 05:43 – Just one thing if I may add. We start a few major features in the project and then in a predictive system, something that is not Agile, you will almost immediately break them down into smaller pieces.
- 05:58 – In an Agile project, you will do it more gradually, but anyway you will have the major features in the beginning and then you will break them down.
- 06:07 – The priorities will work all the way during this process.
- 06:12 – In the beginning, you have one major feature with a priority that maybe, for example, a Should-Have and then you will break it down into 20 or 30 smaller features and those features can be Should-Have’s or Could-Have’s, but they can’t be Must-Have’s.
- 06:26 – So that will be equal to the parent feature or lower than that.
- 06:31 – And there are things like that. So, for example, in DSDM we have a special system.
- 06:39 – It’s a fixed price type of project that is not fixed scope and it’s still Agile.
- 06:46 – We start with the major features, we assign priorities to them, and then during the project in our Agile approach, we break them down and so what practically happens is that we will be adapting with the details of each feature, the way each feature is formed and delivered instead of the high-level features.
- 07:07 – The high-level features are defined upfront. Okay.
- 07:11 – I like the concept of a fixed price and it’s the number of features that can be played with.
- 07:17 – Yeah, fixed price, fixed time. Yeah. Alright.
- 07:21 – The next question is based on the Quality Register.
- 07:23 – So this is an example of a Quality Register here, and I want you to look through the different sections and the headings and the information in this and try to detect something that might be incorrect with this.
- 07:34 – Again, use the manual because you have to be aware of what the Quality Register might look like.
- 07:40 – So what do you think is wrong with this document?
- 07:44 – And the only tip, it’s somewhere near the top of the table.
- 07:50 – You just go on. I don’t have the manual and that’s too much information for me.
- 07:55 – Yeah. So a Quality Register can include or should include the producer, the reviewer, and approver for each product it’s working on.
- 08:03 – So in this example, I have used the producer and reviewer, but also I have added maintenance instead of approver. So that’s incorrect.
- 08:11 – So you should have been, yeah, hopefully you were able to detect this.
- 08:16 – The next question. At the end of the project, the Senior User wants to add the following lesson to the Lessons Report about quality, and they say that product descriptions can be updated during the Stage Boundary Process, but quality criteria should not be allowed to be updated because that causes too many issues.
- 08:35 – Is that an appropriate thing for them to say?
- 08:41 – We had a similar thing before and we agreed that it’s a good idea to change them, didn’t we?
- 08:46 – Yes, but I’m focused here on the quality criteria section of the project, not high-level requirements, I think.
- 08:53 – Okay, but anyway, I think it’s a good idea to keep it dynamic and change them because things change in the environment.
- 09:02 – Yeah, sure, definitely, and this is where the relationship between quality requirements and requirements are actually the same.
- 09:09 – So, if the requirements change, it will affect the quality criteria as well because we’re always asking different questions to ensure that we can deliver that level of quality that’s expected.
- 09:20 – So, of course, it should be allowed to change.
- 09:23 – Maybe PRINCE2 might give the idea that everything has to be decided upfront or well in advance, but that’s not the case. We can use it very, very agile and we should use it in that approach as well, as long as we’re doing the right thing.
- 09:37 – Alright. So, just to emphasize one part of that.
- 09:42 – When we change something in the scope, we usually have to change something in the quality definition.
- 09:47 – Yeah, yeah. That may be helpful, I think.
- 09:50 – And, of course, we cannot make changes randomly.
- 09:53 – Any change we have to make still has to go through the Change Control Cycle as well.
- 09:57 – So, everything is properly managed within the project.
- 10:01 – Right, now we’ve reached the end of the Quality Theme. Oh finally!
- 10:05 – Now we can talk about interesting things in project management. Okay.
- 10:09 – We can let the fly back in now into the room. Alright.
- 10:12 – Okay. See you on the next theme. Bye bye.
Well done… one more theme is completed!
The next theme we’re going to discuss is Plans.
Scenarios/questions we’ve discussed in this lesson
- These are the typical sections of a project’s product description. Are these sections correct?
- Purpose
- Composition
- Derivation (source)
- Development Skills Required
- Customer Quality Expectations
- Quality Criteria
- Tolerances
- Acceptance Methods and Responsibilities
- These are the typical sections of a product description. Are these sections correct?
- Identifier, Title
- Purpose
- Composition (Source Products)
- Development Skills Required
- Quality Criteria
- Quality Tolerance
- Quality Methods, Skills, Responsibilities
- Scenario: The PM is new to PRINCE2 and is not sure how to use the quality requester. E.g., when a quality test fails, they mark it as failed. However, when planning a new test, they are not sure whether to create a new row in the quality register or just add a new target date to the existing row. What would you advise them, and why?
- Scenario: The PM wishes to use the MoSCoW technique to prioritize the acceptance criteria in the project product description. Is this a good idea, as the MoSCoW technique is only mentioned in the Plans theme?
- Exercise: This is an example of a quality register: Can you detect whether there is an issue with it?
- Product descriptions can be updated later during the SB process, but quality criteria should not be updated during the SB process. Is this correct?
Here you can submit your questions related to the content of the course. (For other questions, use the support system). The trainer's reply will be email to you in 48 hours.
This lesson is part of the first 30% of the course, which is available for free, even without registration.
You can purchase the course to access all lessons, additional material, and coaching:
More info and purchase options