Lesson 18: Quality, Part 3

Based on AXELOS PRINCE2^® material. Reproduced under licence from AXELOS. All rights reserved.
Note: PRINCE2 2017 edition is now called PRINCE2 6th edition.

00:06 – Welcome back. Our next scenario is with a city or town that wants to build a new canal bridge at a cost of about 1.5 million Euro.
00:17 – So, during the Starting Up a Project process, the town hall is advised by some expert not to prioritize the acceptance criteria as this will highlight the less important requirements and these may then be dropped during the project.
00:31 – Is that an appropriate thing to do? Sounds logical?
00:34 – Does it? From somebody’s point of view.
00:43 – It’s always helpful if we have prioritization for acceptance criteria and even sometimes for the features themselves because who knows how it’s going to go with the project. Yeah, and not all features are equal, of course.
00:57 – There are some which are really, really necessary to have.
01:00 – Yeah, yeah, but what happens if there is that if you don’t have prioritization, then it doesn’t mean that the less important features will get more, it means that the more important features will suffer. That’s a problem. Yes.
01:16 – That’s something that no customer wants to happen.
01:18 – And it could make the end-product being useless in the case where we have a shortage of budget or something throughout the project. Yeah.
01:27 – So acceptance criteria, it’s a very, very good idea to prioritize this and it should be prioritized.
01:32 – So let’s look at some examples here. Let’s say that we had a bike and pedestrian lane on the bridge.
01:38 – Okay, we could make that a must, it’s a Must-Have.
01:41 – The bridge must support trucks of 3.5 tons, yeah, because there’s traffic going through the city, that’s a good idea, and remote control lift bridge so we don’t have to have a person there but it can be done remotely, we can lift it up because it’s a canal bridge.
01:56 – That would … those are all good examples of Must-Have.
01:59 – Now let’s look at lower or examples of perhaps what we could leave out.
02:04 – So, for example, if somebody said, ““Well, we’d like to have a bridge which could be a tourist attraction and help bring people to the city.” That’s a nice idea, but maybe it’s not really necessary.
02:16 – And another person says, “Well, we’d like to have seating on the sides of the bridge as well so people could sit there, maybe have lunch, and look on the canal.” That’s perhaps also a nice idea, but it’s not necessary for their bridge to function.
02:28 – So, if we do have to make some cuts in the project, we could start with these lesser requirements and make sure that we meet all the main requirements.
02:39 – Shall we talk about what a Must-Have and Should-Have and Could-Have mean?
02:44 – Maybe they don’t know. Well, that comes up more in the change where I give an example of this.
02:50 – If you just want to mention something now really quickly, sure. Okay. Sure.
02:54 – It’s a very useful method of prioritization. Yeah. It’s called MoSCoW prioritization.
02:59 – Technique. MoSCoW prioritization technique. Sorry.
03:05 – Well, practice actually. Yeah? Okay. Yes, because MoSCoW prioritization belongs to DSDM. I see.
03:12 – It’s a proprietary concept. Oh yeah. It belongs to DSDM and they call it a practice. I see. Okay.
03:17 – So there we have four labels - Must-Have, Should-Have, Could-Have and Won’t-Have this time.
03:23 – A Must-Have is something you need to have in your product, and if you don’t, you won’t be able to use the product because of the regulations, for example, or the nature of the product.
03:34 – If it’s a banking application, it’s not secure, then you can’t use it.
03:40 – Yeah. Or a car with no steering wheel, that’s a Must-Have.
03:45 – Yeah. A Should-Have is something that you should have in your product, but if you don’t have, you will have problems, but you can come up with workarounds.
03:55 – That’s the difference. We cannot have workarounds for Must-Have’s.
04:00 – A good example for a Should-Have?
04:05 – For example, I always use a Business Case example.
04:08 – So, perhaps if it takes 1 Euro to invest and you get 10 back, then it’s a Should-Have.
04:14 – It’s a good idea. For example, if you’re building a new website and you don’t have an automatic password renew feature, that can take a long time and some administration to renew everybody’s passwords to do it manually, but you can spend a little bit extra and get a new module and then that can be automated. That’s a good idea.
04:32 – That’s actually something we did long ago. In one of our projects, we wanted to release it as soon as possible and therefore we didn’t add a feature for people to reset their passwords. Yeah.
04:43 – That was a Should-Have because you will have problems if you don’t have it, but you could do it manually.
04:48 – They could send an email to the admin and they would reset their password. So that’s a Should-Have.
04:53 – Yeah. The way I see it is every Should-Have should have a Business Case attached to it, a little feature.
04:58 – It makes business sense to do it and the rest then don’t have a Business Case, they’re lower level.
05:03 – Well, they can have still because even inside Should-Have’s, we have different priorities and inside Could-Have’s, we have priorities. Okay. Also even inside Must-Have’s. Alright.
05:15 – And that comes from the Business Case. Some type of business justification.
05:18 – But I go into more examples on this. Actually we have an exercise in the further themes, so we can discuss that further.
05:24 – Alright. Okay, so we can leave the examples for then. Yeah.
05:26 – And the Could-Have is something that you would like to have in your product, but there won’t be a problem if you don’t have it.
05:35 – That’s the difference between a Should-Have and a Could-Have.
05:38 – So what happens if you have it, do have it, then you would be able to generate more value in your product, that’s the difference.
05:46 – And Won’t-Have is simply something you don’t want to have.
05:49 – Alright. Good. So our next scenario is a town project or a city project where they’re having an eco project.
05:56 – So they’re going to add more plants and shrubs and trees in as many places in the town as possible.
06:02 – Now we’re in the Starting Up a Project process of this project at the moment, and the Executive says that the acceptance criteria should not be allowed to change.
06:12 – Once this is defined at the beginning of the project, it should not be allowed to change for the rest of the project.
06:17 – Are they correct in saying this? I mean is that an appropriate thing for the project to do?
06:22 – Not to change the acceptance criteria? Well, you can replace the acceptance criteria here with anything else and the answer will be no.
06:30 – Even the justification of the project can change.
06:33 – You can start a project for a certain thing you have in mind, for a certain goal, and then during the project, you can change it. Yes.
06:42 – That’s not exactly a project example. It’s more of a program, but think of Viagra. Yeah.
06:49 – How it changed during their program. It was first what was the first objective for the drug? Thinning of the blood or something. Yeah.
06:58 – But you know more about Viagra than me. So I can So, anything can change and we should be open to that because otherwise your project won’t be dynamic enough and the plans that you have, if you don’t keep updating them and adapting them to the reality, then they won’t be useful in your project.
07:19 – What happens is that you will end up managing your project intuitively.
07:24 – All the plans will be just fancy things you print and put on the wall.
07:29 – Correct, yeah. So to sum up, it’s a very bad idea unless you’re 100% sure of the requirements in the Starting Up a Project process, and how many projects are you 100% sure? Hardly any or none actually.
07:41 – Also, we expect to learn nothing new during the project.
07:44 – Again, there are not many projects where you learn new things, so there’s not many projects like this.
07:48 – So it’s a bad idea for them to do.
07:51 – Now it’s good and useful to have ideas or good and useful ideas will appear all the time during the project.
07:57 – So it’s important to be able to learn from this and then to …
08:01 – and then the acceptance criteria should be allowed to change because of that.
08:05 – The next scenario we have. So let’s look at the quality criteria in product descriptions.
08:12 – So which one of the following is a good example of a quality criteria statement in a product.
08:18 – So the first one is, I’ll just list two. The first one is search results must appear within 2 seconds, that’s one, and the second one is interface must be good.
08:29 – I think that’s really simple. The second one is not clear enough. It’s not the real criteria.
08:36 – There’s a bug here. Okay, let’s try to ignore it. I can go on.
08:42 – That’s fine. It can happen to everyone. Yes.
08:45 – So the second one is not really a criteria because you can never say if you’ve satisfied your criteria.
08:52 – It’s just an idea. So you can start with that, but then you have to make it clear and measurable, but for the first one it’s measurable and we can say, “Okay, now we’ve passed the test or we’ve failed the test.” Yeah, okay. Will the fly affect the quality of our quality video? Well It’s an extra feature which we added in actually. Yeah. It was by design.
09:17 – So quality criteria needs to be specific and measurable.
09:21 – So search results within 2 seconds is a good example.
09:24 – This is very measurable and it’s easy to understand. Interface must be good.
09:28 – This could mean lots of different things for lots of different people, or mean nothing to other people.
09:34 – We could rephrase that and say 9 out of 10 people should be able to use this interface without any additional help.
09:40 – That makes it measurable. So that’s where we should define our quality criteria a bit better.
09:46 – Alright. Our next scenario and we should announce a special guest.
09:54 – So our next scenario. So during the Initiation Stage of the canal project, the Quality Assurance role says that the producer, reviewer, and the approver for each product should be defined in the QMA document, that’s the Quality Management Approach document. Is that a good idea?
10:13 – I’ve never had a good relationship with the quality review technique in PRINCE2.
10:19 – I’m not saying that it’s a bad thing, maybe you can answer this question.
10:24 – Well, I think I spoke too quickly because my question wasn’t exactly like that.
10:29 – So, I said during the Initiation Stage of the canal project, the Quality Assurance person says that for each product, we should have the producer, the reviewer and the approver defined in the QMA approach document.
10:44 – I’m trying to catch you out. Okay. Okay. You don’t know.
10:48 – I’m waiting for you to answer. No problem. No problem.
10:50 – I’m not comfortable answering that. Yeah. That’s no problem. You know, quality is not my thing really.
10:54 – Yeah. So, actually no. This is not a good idea even though the person thought it was a good idea.
11:00 – The producer, reviewer and approver needs to be linked to the product itself.
11:05 – So it has to be included in the Product Description document.
11:07 – It does not belong in the QMA document.
11:11 – And this information can also be added to the Quality Register to show that when a particular product has to be approved and so for each quality task that’s linked to the Quality Register.
11:23 – Our next scenario. During the second stage of a project, so we’re in the Controlling Stage process, the Executive asks the Project Manager, “Why bother maintaining quality records and why not just mark the result in the Quality Register?
11:39 – Just tick that it’s done and why bother maintaining all the other quality records that we need to prove that quality was actually done, the test was done?
11:48 – Well, we may need it later on. When?
11:51 – Later on when we go on with the project. For example, we come up with a new problem, we want to go back and see what was the root cause of the problem.
12:00 – That helps with that. Also, creating historical information that can be helpful in other projects in the future.
12:07 – Yes. It’s very important. It has to be done. Yeah.
12:10 – We need proof all of the time and especially when we perhaps hand over the product at the end of a stage or at the end of the project, we need to show that the products have reached a quality acceptance criteria and that could be an outside certification or something that’s signed by somebody inside the project as well.
12:27 – So, we really have to prove that quality products are checked.
12:30 – It’s also what the Project Manager needs because the Project Manager doesn’t check the products for quality themselves, they will use information from other people.
12:41 – I can keep focus very well and talk. Yeah. You’re good in that. Thank you.
12:45 – I have a suggestion. Maybe we can go for another coffee.
12:49 – And ask the fly to leave? Yeah. Find another course.
12:52 – Yeah. That’s a good idea. I think it’s just fine. Yeah. Okay. See you later.

We’ll continue the Quality theme in the next lesson.

Scenarios/questions we’ve discussed in this lesson

Scenario: A town wishes to build a new canal bridge that will cost about €1.5 million. During the SU process, the project is advised not to prioritize acceptance criteria as this will show the less important requirements, which may be dropped. Is this appropriate?
Scenario: At the end of the SU process in a town eco-project (the town wishes to add more plants, shrubs and trees in the town), the executive says that the acceptance criteria should not be allowed to change during the project as this is not allowed in PRINCE2. Is this correct?
Quality criteria in product descriptions: Which of the following are good quality criteria?
- Search results must appear within 2 seconds.
- The interface must be good.
Scenario: During the initiation stage of the canal project, the quality assurance role says that the producer, reviewer and approver for each product should be detailed in the Quality Management Approach document. Is this correct?
During the second CS process in a project, the executive asks the PM, “Why bother maintaining quality records and why not just mark the result in the quality register?” As a PM, how would you respond to the executive?

Lesson 18: Quality, Part 3

Contact your trainer to ask questions