When you think of quality as a PM, does your mind race to the quality management plan section of your project management plan? If so, do you think you normally cover all aspects related to the other nine knowledge areas? If not, it may be time!
Quality is somewhat ephemeral, isn't it? It's like asking, "How long is a piece of string?" We have to get much more succinct than that when we are dealing with quality on projects. Consider using a Deliverable Expectation Document, where you go over a deliverable with a client, and define the level of quality needed, to which requirements it relates, and who will review and sign off the final deliverable. Maybe this is the Definition of Done and/or the Acceptance criteria in an Agile project.
So, how does quality relate to the other knowledge areas? What should you consider when composing your Quality Management Plan? Or conversely, what should you consider about quality in each of the other plans? Here is my take on it:
- Scope - Of course, scope is where we start with quality. What is in scope, what is not in scope. Once we understand scope, we can start asking questions about the level of quality required. For example, if the scope of the project is to create a manual set of processes to help in the selection of products for monthly sales in a do it yourself store, what does quality look like? Do you know? Of course you don’t! You will need to discuss with your sponsor and stakeholders to figure that out. Maybe part of the process needs to take into account several factors, such as what is overstocked, what is being phased out, or what will draw customers to buy other related items that are not on sale. Or maybe it is about rotating from department to department to make sure everything in the store is covered over a period of time so that all types of customers are drawn to the store. So what does quality mean in this example? Probably that each of these situations are taken into consideration in the processes so that all the needs are met.
- Time - Quality processes take time, and time is money. So we must always pay attention to the cost of quality. It is fairly obvious that you can’t introduce so many quality-related processes that we spend 90% of our time in the project performing then. On the other hand, if we don’t have sufficient effective quality control processes, we may spend a lot of time in quality assurance finding issues that shouldn’t really be there, and sending work back to be redone. And as we all know, rework costs time …. and money!
- Cost - We’ve already established that any process will cost time, and so it will also cost money. We’ve also established that rework, caused by ineffective quality control processes, costs time, and so it, too, costs money. What is the cost of the quality processes you will have to implement? What is the cost of not implementing them? Rework: time and money!
- Risk - What are the risks associated with quality? They are always present. There is the risk of not being sufficiently detailed in finding out what we are supposed to be building and to what level of quality. We try to mitigate this with DEDs/Def of done/Acceptance Criteria, and so on. There is that risk of rework. There is the risk that the product as produced will not be accepted. There is even the risk that we may try as best we can to get the definition of quality down accurately through discussions, models, documents and definitions, but that we end up getting it wrong anyway! So, taking quality into account during risk planning, identification, quantitative analysis, qualitative analysis and response planning is critical.
- Communication - Communication deliverables need quality definition like any other. And, of course, communicating what needs to be produced, who will define it, who will approve it is just as important. So, quality comes into play when producing communication deliverables, and is also used as the main tool in defining the required levels of quality for each of the project deliverables.
- Human Resources - Quality is, of course, something that each member of the project team must own. They should be asking very detailed questions about what it is they are supposed to be producing, to what level of quality, and asking questions about how to ensure they are producing the right thing the first time, that which is expected by the client (QA). They should also be asking about the processes for ensuring they have produced the right thing (QC). If they don’t feel they have the skills to meet the expected level of quality, they should speak up, ask for training or mentoring, and even to be replaced if the timing for it would be poor, so they can work on a project where their stronger skills can best be utilized. Your team members should be asking questions like, “Where’s the DED or Definition of Done?”, "what are the quality assurance processes?”, “What are the Quality Control processes”? "Who will be accepting the product I am producing?”, “Who are the relevant stakeholders?”, and so on. Your team produces the deliverables that must meet the defined levels of quality and acceptance criteria. They must perform any necessary rework to get their deliverables into the required state. They are key. They control and assure quality.
- Stakeholders - Of course, your project’s stakeholders are key to defining required levels of quality by being instrumental in development of DEDs, DoDs, and detailed definition of what the deliverables should look like, who should be involved in the requirements definition and who will review and accept the final deliverable. They help define your work. They sign off on your work. They can send work back for rework. Could they be any more important? Your client and sponsor are in this group, and so are all the others who can impact your project’s quality expectations. Who could be more important? If you have the best team on the planet, producing exactly the wrong things to the highest levels of quality as defined by the wrong stakeholders, you have nothing. So, find out from your sponsor who to involve, then involve them!
- Procurement - Quality is just as important when it comes to procurement. You need to translate your stakeholders’ quality requirements for your vendors and then you need to be sure your vendors are producing the right stuff. You may also want to get into the internal processes of your vendor’s deliverable production and overall project management so you can be sure they are running a quality operation. If not, you may find that the deliverables sent to you by the vendor are not what you, or more importantly, your stakeholders, expect. And as we all know, the buck stops with you, the project manager. You are responsible for quality on the project, and that includes everything delivered by a vendor. So in your planning, what processes will you have in place to ensure quality work from the vendor?
- Integration - So, we have seen that quality permeates ALL of the nine other knowledge areas, and must be dealt with in all process groups. Integration is the realm of the PM and by its very name insinuates interplay among them all. As we have seen, quality is no exception. In fact, it is probably the rule. So build it into your projects. And remember - you can't test quality
How do you plan for, assure and control quality on your projects?