|Jim De Piante|
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:And on the BABOK you can read:
- Non-functional requirements, such as level of service, performance, safety, security, compliance, supportability, retention/purge, etc.;
- Quality requirements;
- Acceptance criteria;(...)
(...)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 Luis Seabra Coelho