Project Quality Requirements

In this podcast, Ricardo talks about the project quality requirements, he explains that sometimes the quality requirements are set when the project is near the end, and sometimes the project manager does not involve the customer early in the project and the requirements are made in the light of their understanding. Ricardo also explains that the quality requirements need to be tangible and relevant.

Download (6 MB)

Episode transcript

The transcript is generated automatically by Podscribe, Sonix, Otter and other electronic transcription services.

Hello everybody welcome to the five Minutes PM. Podcast Today I like to discuss and try to understand why we have the Mt of problems that we usually have in our Project regarding Quality Y most of the time, when we deliver the project result's to the customer, the customer's say, Oh, this wasn't as exactly what I was expecting. Four in something like that, why we face these kind of trouble in school?

The answer for that Quality, Requirements what his Quality Requirements Requirements are statements that clearly address all the Quality standards and they are agreed with the customer. And why does the shoe hard to create why it's so hard to create? There's a statement first, most of the time, both the customer and team and pro as a team, they always understand what are the risks.

Acquirements when the are very close to the end. So they don't spend enough time to discuss, to simulate the requirements that they need to make clear statements. And usually what they do, they put a lot of v*g and big words like, Oh, the customer must be happy. We need to deliver a good product or something like that. It must be cheap. I know.

Good. This is so obvious. Everybody does that all the time. If you don't believe are a good product in a good price, that address the client needs, Y you are doing the project. So this is pointless. I want to understand what is the real meaning of the word. Good for the customer. Good is what is what? For example, if I'm developing an it system, what does good a software?

What does good? Is it good to have a backup plan? Is it good to have performance? Is it good to have a very nice look? I don't know. It depends. It depends on which products you are creating. It depends off your customer. It doesn't depend on your desire. Depends on the disagreement. So a lot of companies, they have based on their own only structure, they have something like much more Zulu movement in the other two, understand the technical people.

When they start developing the Project in laid there, they go to the customer and say, what what's going on in? What do you need to explain to me? So and this results in the rules, Requirements incomplete, unfeasible, and inconsistent. You create statements that are, they're only to fill the blank page off the Quality management plan. The are not there to solve your problem in what are the Quality Requirements that will solve your problem.

First of all, do you are mandatory? The irrelevant. So don't waste your time. Putin Quality Requirements that are pointless. So put the mandatory, the Quality Requirements that if you don't reach them, you will be in the trouble. Second, their physical, their feasible, that team that is producing project. They can do that. They are compatible with the skills, knowledge, and the ability of the team that is developing D R and D bagels.

The are clear. They're clear, I'm building a new home. So I want to address the Quality Requirements with my contractor. I want a room that just big enough for a King size bed or a chauffeur at a desk and the wardrobe, and a want to have some free space. So this are my Quality Requirements it's clear. It's not a baby bassinet.

It's a King size bag. It's a very common when we see buildings in construction that their trying to sell, they produce small seats is most sofa. So the people that come in they've filled a space much bigger. That it's real. And this is fake. This is a fake quads requirement because this doesn't adverse the client needs. We need to understand that. And also that Quality Requirements must be verifiable.

I can task. I can bring a measuring tape and I can see the size. I can see I can task the Quality Requirements. So its not in the fields off the ideas. It's not a feel. The client must be happy. This is not a quite requirement. We need to understand and translate happiness numbers. Okay? The client would be happy if you delivered the system that support a access, immediate access four, 10,000 people seem stunned as Lea and also do an online the capping system.

And also it's easy enough for the customer to fill all the information in less than 30 seconds. So this is a requirement. Those are really fireable. This are reliable. I can test, I can trace them. I can trace. I can understand. During the development of my project, the requirement pieces that are being matched, I can see that I don't need to weight up to the end. I can trace all the requirements, understand where the quality of the requirement change.

They need to meet this requirement. Otherwise they're pointless. And if we create there's a statement clearly with a good proposal and sharpness, we can do a much better project for our customer or a much better because with both, we would agree in what we need to deliver. I hope you win joy at this podcast. See you next week with another five minutes PM. Podcast.

Menu

Resources & Insights

Products & Services

More Resources & Insights

Ricardo Vargas

Podcasts

Project Quality Requirements

Search in Podcasts

Latest podcast episodes

Book recommendations