Friday, March 16, 2012

How to Embed Quality into Scope

Jim De Piante
I recently had the privilege to interview Jim De Piante as part of my volunteer job for the Information Systems Community of Practice of the Project Management Institute. I've known Jim for some time now and it's always a pleasure talking to him, the truth is that I always learn something from him. And this time it was no different. At one point he said "Things are already complicated enough. There’s no need to complicate them further. I would rather simplify things. I don’t see any value in treating quality as a fourth constraint. Quality is a part of scope. How you manage quality is another matter altogether. But quality is not a new constraint. It is an aspect of what you are creating and is (or can and should be) specified as an element of project scope.".


It immediately occurred to me that this actually isn't new, although it was new to me - at least put this way. In fact you do it frequently in Construction when you have to build according to some regulation like when you build in a high seismic region: you just make it part of the scope. You'll have requirements for some extra amount of iron on the reinforced concrete or foundations that support much more weight than the weight of the building or much more flexible than usual.
By this time I was thinking highly of myself, a natural human mistake. So I started checking the usual suspects in these matters: the Project Management Book of Knowledge (PMBOK) and the Business Analysis Book of Knowledge (BABOK). And in fact they both consider this at some point.
You can read on the PMBOK about requirements:
(...)Components of requirements documentation can include, but are not limited to:
- Non-functional requirements, such as level of service, performance, safety, security, compliance, supportability, retention/purge, etc.;
- Quality requirements;
- Acceptance criteria;(...)
And on the BABOK you can read:
(...)Non-functional Requirements: capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.(...)
I couldn't agree more about keeping things simple (just check this previous article "KISSing Project Management"). In fact, keeping it simple is the story behind the Beginners Guide to Project Management (this is a link to last article on this series about the Risk Management Plan, still work in progress) and eventually I will review it. But making quality part of the scope is something I will definitely change when I review it. Everything should be made as simple as possible, but no simpler!
(BTW, this quote is attributed to Albert Einstein but actually the correct quote is "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.". There's some debate on how this quote turned into "Everything should be made as simple as possible, but no simpler")
As for the "no simpler part", there are projects where quality may not be reduced to just a set of quality requirements (at least in terms of process) so pay attention to that!

So as a rule of thumb you can safely go with this:
Always start thinking about quality as in "fit to purpose" and turn it into requirements to embed them into scope. If that's not enough, develop it further.

Posted by

No comments: