As PMO, my manager is requiring me to measure both delivery and quality metrics. I can easily measure delivery by monitoring slip rates. I am having difficulty on measuring quality.
2
-
What type of project is this?– Thomas Owens ♦Commented Sep 19, 2011 at 0:58
-
1Hi Thomas, the projects varies a lot - process development, setting up an infrastructure, developing a new service product.– Impe6Commented Sep 19, 2011 at 5:33
Add a comment
|
4 Answers
The worst thing you can do is measure something for the sake of measuring something. It is a waste of time, no one will care, and you will quickly train people to ignore you.
The sources of things to measure are all ready all around your project. And of those things, you should take the time to measure only those that are of concern or of significant threat and you should be flexible enough in your quality program to remove a metric when it becomes stable and pull in another. Things change during a project, areas of focus change, and so should your metrics.
Sources are: Statement of Work, Proposal, Plans, Processes and Procedures, Risk Log, Issue Log, Service Level Agreements, and your project team after you interview them (what worries them, what are they already tracking, on what are they reporting).
You are looking for promises made, assumptions made, and places where performance variability exists.
If you find yourself "making up the metric," throw it away. The metrics are already there.
BTW, your delivery and quality metrics are the same thing. So time is a quality metric.
answered Sep 19, 2011 at 10:30
Measure the amount of time spent doing bug fixes or number of bug fixes after release. This can be as simple as counting number of support tickets after you go live.
answered Sep 19, 2011 at 23:03
-
The number of bugfixes after release is growing. So, the quality is dropping?– SergiusCommented Sep 20, 2011 at 5:47
-
First you must clearly define what you want to measure and then the appropriate metric.
What to measure In PRINCE2 you have the concept of the product description. Part of the description is the measure of quality. It is usually described in the context of the project and well understood by all involved. This is critical for your reporting.sample. Once you have an agreed definition of quality you now know what to measure.
Metric The tighter you link the metric to the project and product (deliverable) the more real it is. I find the easiest place to get this is from the "senior user", the person who represents the final users of the system or product. They are usually expert in their domain and will usually tell you what to the users is the important measure of quality and progress. This avoids abstract measure (lines of code, man-hours, etc)
I would close by saying that the measure of quality in a project will usually be different from project to project simply because what is important to the stakeholders in one project will not be the same in another.
If you are not sure how to measure quality then you should start simply and plan to improve the quality of your quality measurements. For instance, maybe you have little or no documentation. A quality metric might be something dumb like "Number of pages of documentation." Its ridiculous I know, but it is a starting point. If you have no pages of documents, then you have 10, then 100, then I'm sure your quality is increasing. Later you can change the metric to measure the content of the documentation (e.g. measure updates to the documentation per day, per month - whether more or less updates are good....?) Not a complete answer but maybe a starting point. Don't be afraid to adopt and drop metrics as you learn more about them. Continually improve them.
