30 October 2007

Dimensions of Quality

Projects have certain quality standards they have to meet. Some are easy to measure - system avaiability for example. Others are a bit hazy - like useability.

In the past I have written about how there are different ways of defining success for projects. There is compliance with the plan, there is meeting the right ROI threshold, and so on.

Quality still seems like an intagible and ephemeral thing to me. I can't lock it down and I want help.

Do any readers out there want to point me at articles, books or blogs that nail the concept of project quality.


  1. Anonymous1:39 am

    I've never found a book which has given me as rounded a picture as I would like. So, if anyone knows of a book which fits the bill, I love to hear about it too.

    There are plenty of industry/governmental standards which can be found online and do help to concentrate on the mind on the measurable elements of quality but these are just a starting point. It's important to align these with project objectives and keep the old TQC triangle in mind.

    Usability testing is very subjective. The best way I've heard to to measure it is to time how long it takes a user to perform a task and then ask them to rate how easy it was to do. However, it doesn't give you as full a picture as a pilot might.

  2. Heather, I know how you feel.

    I guess there are several dimensions to quality for projects. A few that I can think of include;

    The easy to measure ones
    - Fulfilling the stated product objectives – which you do through rigorous requirements and quality management
    - Delivering to time and cost estimates – which you do through good planning and estimating, and through picking the best solution approach
    - Obliging the local process and governance requirements – usually through the right documentation and stakeholder reporting
    - Financial targets were met

    The hard ones
    - The team feel like they did a good job and were happy with their output
    - The clients and stakeholders are happy with the intangibles of the service delivery – eg the relationship with the project team
    - The stakeholders feel like they were involved to the right degree
    - The project was implemented into the business environment properly – eg effective change management
    - The end user adopt the system and are more effective with it that whatever it was replacing
    - The client feels they got long term value from the project’s outcomes

    Notice the first are about facts and the second set are about emotions.

    As I write this I am thinking about the difference between business process/software (office-work) projects and engineering and construction projects.

    In office-work projects you are delivering a product but it’s still mostly intangible.

    You have to take a service approach to quality – like a consulting or law firm firm as well and engineering type approach where you look at defects and fit for purpose.

  3. Anonymous11:39 pm

    Back in the days of ones and zeros TQM defined quality as "Meeting (or exceeding) customer's expectations."
    A project with clearly defined needs and features + Well maintained change control should provide for a high quality project every time.

  4. This book is all about quality, but it may take you a while to come up with some applications to software.

    If I got a requirement from a product manager saying that the application has to be of high quality, I'd tell them that's nice, and I understand what they mean, but it doesn't work. It's just a matter of getting more specific and finding out what they're really looking for - like any other type of requirement.