Friday, February 17, 2012

Beginners Guide To Project Management
Part 13, The Quality Plan

It may seem an exaggeration to include quality planning on this Beginners Guide to Project Management but the fact is that you do it all the time in your projects even if you're aware of it - and if you don't I'll show you right next that you should. The reason being that one of the things you try to do when you manage a project is that its results are useful and people use it - and that's quality for you.
And the purpose of this article is precisely to make you aware of it and to explicitly consider quality when you're planning. This can be done in a very light weight fashion, there's no need of an elaborated, 100 pages long document for your plan on every project. In fact, in some projects, you may just need to think about it for 10 minutes. But just do it!

Previously on the “Beginners Guide to Project Management”

Introduction

Initiating

Planning


Quality
Starting from the beginning, quality is making sure that your client is happy with the project's results. Period. That is accomplished in 2 fronts: the results of your project and the project itself and how you manage it.
When you think of the results of your project, you aim for "fitness of purpose". You get enough quality if the project's result do what it is needed to do. That means a lot: a happy customer, a happy end-user and compliance to any quality policy and standard used by the client organization. At least these. In short, quality is making sure that your project's results are in fact used after the project ends and you leave the scene.
But when you think about the project itself, there are also things you can do to assure the quality of the project. This side of quality is focused on the processes in place, on the way things are done. In fact, if you're reading this article you are doing it already as you're trying to get the best ways to manage your project, assuring that nothing important is left aside.

Quality Assurance
The phrase Quality Assurance relates to the steps taken in assuring that the things are being done the way they're supposed to. In terms of the project, it could be making sure you use the Project Management Book of Knowledge (PMBOK) framework, for instance. In terms of the construction of your project's results, it could be the use of test driven programming (if you're developing software). There are both under Quality Assurance. This doesn't mean that the end result will be of high quality but it makes sure no basic mistakes were made.

And Quality Control is...
...making sure defects don't get out to the client. For instance, and in another front, all factories do it: after the products are made they pick up a sample and test it from one end to the other (or most factories do). If too many defects are found then you can try to find what caused them and solve the problem that originated them in the first place. Next turn around, you should expect less defects.

Quality Plan
Even if you're just thinking about the quality of your project and you're not writing a word about it, you should consider the quality requirements for your project and its end products. But if there are any such requirements, they must be addressed. And in this case, you must focus on how the project documentation will demonstrate compliance to them. In these cases, a written, formal quality plan may even be mandatory. If your quality issues are all related to making sure your project's end results will be in fact used, it's possible you can skip this written formal overhead. Just don't forget to consider quality in the planning phase - written or not. A formal quality plan can be as complete as this one I found on The Washington State Department of Transportation website.
In any case, writing the acceptance criteria for your project's results is usually a good idea. And if you do it, keep in mind that the criteria should at least be objective and possible to measure. "The interface is easy to work with" is a really bad idea for criteria; but "No bugs will be found by the test team prior to release" is probably a good idea (provided you specify what the tests will be, how long they will take and so on).

How to start the Quality Plan
Most of the planning output will be useful as input for the quality plan. But at least consider the project scope, your stakeholders, the cost and schedule, your risks (oops, I will come to on the next article of this series) and the entire context of the project (is there any regulation on what you're building? Does it need any kind of approval before hitting the market? Does the organization follow some quality standards that you're forced to follow as well?).
These will prompt a series of quality requirements that must be addressed, some of them may even end up showing in your Work Breakdown Structure - and yes, you probably have to go and update some of the other planning outputs. Again, although I'm presenting all these in separate topics you may deal with them several at a turn or go back and forth between them.
The main thing is that your quality management plan describes how the project team will deal with quality issues like implementing the organization's quality policy if there's any.

So keep in mind that...
Start thinking about the quality issues in your project for 10 minutes and see where it leads you to. On some projects you'll know from the start the you'll need a complete, formal, written quality plan, but always give it at least 10 minutes of your thoughts. From there consider what the end results must comply to in order to fit their purpose and think about the building process itself and the project management issues. Think about metrics: what objective, measurable metrics must you project and its end results satisfy. If you do this you're on the good way to have a happy customer.

Images from http://www.rallydev.com/

Posted by

No comments: