Around 12 years ago I was engaged on a project by a large financial institution in Hong Kong. It was very much the "Bread and Butter" type of project I have worked on for banks over many years – a new office build and migration of several offices and a Datacentre. Nothing spectacular or unique to shout about.
During the project my client asked a question I've had asked many many times on projects, but it was asked in such a way that this time I couldn't side-step it quite so easily; "Can I see your Quality Management Controls please? …"
'Oh Sh **! "I thought, this will be a challenge for me. Well, I got something thrown together and it was enough to shut the question down for the remainder of that project. Thank god. But I did really understand what I was doing and I don't think the client really did either, in hindsight.
Not long after, with the same client but in a different country, the same thing happened and it was time to pull my socks up and learn what this beast called "Project Quality Management" was all about. I mean who really gives a damn about quality on projects as far as project management goes … eh?
It's so basic and simple that when I did learn about it I had one of those "how stupidly simple is this .." moments. In fact, since that time the relevance of Quality Management and controls have shown to be a fundamental building block of project management and is so relevant that I can't see how I ever managed without it.
Actually I was managing quality, informally, in the same way most PM's do – casual checks and balances.
So here's the essence of Project Quality Management:
If I say I want a Red Roof and I'm going to pay you for it, when I come back I expect to see a Red Roof. OK? If there's a good reason why you can't give me what I ask for then I expect you to manage the change such that I will agree with the outcome.
Does this make any sense? I'm not great at getting the words down sometimes. Basically quality is the process, controls and framework that we need to use to assure that what the customer asks for is what the customer gets at the end of the project – and that includes management of any changes along the way.
So don't get confused by the term. I did for a long time. Can you imagine me standing in the door way to a new Datacentre and making sure the place was spotless and shiny like a new car .. and thinking that was about "Quality". Dah!
In projects, "Quality" isn't about craftsmanship, or finishes or unblemished surfaces or any of that good stuff – unless that is specified by the customer as part of the "requirements".
Aha! Requirements ..
..No no, don't ask him what he wants, we'll be here forever, just give him something that will do most of the job and he'll be happy and pay us ..
No he bloody won't !! At least none of my clients would. Herein lies yet another missed key element of projects. The relationship between all the core controls, which are fundamental to success, is the dependency between the Agreed Requirements and the Final Outcome.
If Quality Management is the process of assuring that what as asked for is what is delivered then it makes sense that the "what was asked for" requirements are details enough that they can form a valid and usable check list at the end of the project, Does it?
Why am I asking you this .. Of course it does. Every half decent methodology teaches you that you start any project with the signed-off requirements. Right now I'm smiling and wondering how many of you poor souls reading this are thinking how many projects you've been on where the requirements were not signed off, or were too loose or vague or non-existent. I know you are there I can sense the guilt from here. I've got that T-shirt too.
The single hardest part of any project .. listen very carefully now … is getting the customers detailed requirements, documented and signed-off !!!
The single hardest part of any project .. listen very carefully … is getting the customers detailed requirements, documented and signed-off !!!
There, I said it twice to make sure it sinks in ..
You cannot manage Quality if you have no bench mark against which to measure the delivery.
I want a roof …
Yes sir, how big would that be?
Just big enough to stop the rain coming in … And how about the overhang sir – should we make that into a porch or veranda for you? …
It's like being asked for a piece of string and not being told how long a cut is needed. You will always get it wrong if the customer decides to change his mind. Given that most projects are longish jobs, there's ample time for people to change their minds and their requirements don't you think? I can tell you they do 100% of the time.
With the detailed requirements clearly stated and in sufficient detail, it then becomes possible to manage Quality. And guess what .. it also then becomes possible to manage Change and Risk too. They all hang, for their success, from the fundamental detailed Requirements.
So, have we learned something today? If you are a PM then I hope this has enlightened you or at least reinforced what you already knew.
If you're a customer of PM services, I hope it has woken you up to the single major critical success factor of your project investment, that you and you alone are accountable for – your requirements! So don't give us PM's a hard time when we hound you for them in the future!