Avoiding “quality expectation” disasters in a project
- Matthew Verity
- Nov 6, 2017
- 5 min read
Judging the level of quality required to meet the expectations of deliverables is a constant concern for even the most seasoned of consultants, project managers, stakeholder,s and team members.
While experience helps as we carry the memories of successes and failures in this area, we are always at the mercy of misinterpretation statements from clients and managers such as “Oh don’t worry about that” or (on the other end of the spectrum) “quality needs to be front of mind”. Both are statements I’ve heard over and over, the level of expectation variation in both cases is mind-blowing.
As a freelance consultant, I hit these scenarios on a regular basis. Here performing short-term work provides for a larger experience to draw upon here; the human element in having multiple parties agree on expectations means I remain continually aware of the need to deal with this risk.
Perhaps I may at times not get it right every time, I do stick to four key strategies around quality management:
Engage in the conversation early in the relationship to quality expectations;
Deal with the discussions honestly, in as to what - can and can’t - be done based on budget and time (theirs and yours) constraints;
Agree and document expectations; and
Test the agreed expectations as quickly as possible.
Deal with it Early !!
Let me run through a recent project where I was provided the brief as follows: “I need a document written to explain XYZ, not too technical, but not too high level”. For some, the thought of receiving this brief would have ‘hairs bristling on the back of their neck’ and the ‘desire to run to the first exit’ - all being too much to resist. I’ll admit that I am not immune to these feelings but prior to ‘running for the exit’ - I try to delve a little deeper to understand some fundamentals, and then look to plan what it is that I can work through with the client the nuances, in the ambiguity.
The statement ‘they don’t know what they don’t know is true not only for our clients but also for us. The reason we seek out an expert is to often sound out what is possible and so to kick off from here, I like to guide the conversation to ascertain:
Who is the audience of the deliverable?
What are the expectations of the final audience?
How will they be using the deliverable? and lastly;
Whether this is the first part of a wider piece of work, and / or parallel?
Asking the client if they –"Could you walk through what you believe it will look like in the end ?” is a good tool that I have found to help the client visualise and elaborate (and confirm) a case in their head, at the same time allowing you to document some ‘meta’ statements as to what is really required.
Understanding the final audience will often also help in understanding the level of detail that is likely to be expected. Process workers in technical positions are going to be the ones to pick up a deliverable and shred it to pieces on the first-read, as opposed to managers - who may just be after a high-level brief to get them through a current issue.
It is important to also understand the endpoint of the work. Is it a quick win to get to another phase where quality will become the focus, or is this framework that is to be followed such as a QANTAS engineer so to stop planes falling from the sky?
From these conversations, you should arrive at a fairly well (if not at least better) idea of the level of quality necessary. This is then combined with the likelihood of knowing their budget and from here you need now to ensure that they match. This is where it is time to…
Have an Honest Discussion
I may be an optimist, but I do believe that by far and large, most people are smart enough to understand that the level of desired quality is related to the price and explaining why they may not get what they are after. Their budget often will have them re-assess their expectations and or scope.
Now is the time to talk through the reality of the engagement: “Looking at what is required, I believe that I can put together something of a rough document without internal quality control and probable mistakes in X-days, but to get to a better refined outcome is will take 2x days”.
Those looking for quality won’t budge at this stage in understanding the link, whilst it may either end up them understanding that their real outcome is actually only required at a lower quality level and or opt out of the project not having the budget. Even in the event of them opting out, this should be viewed longer terms as a good outcome as you’ve ‘dodged a downstream bullet’.
All conversation at this point should be put in writing as clearly as possible to set the scope of the deliverable which leads to the next key being…
Document It!
While there is an element of covering one’s ‘behind’ always necessary, documenting expectations as thoroughly as possible is key to creating the foundation of a good relationship and an agreed outcome. Moving the earlier statement of ‘I need a document written to explain XYZ, not too technical, but not too high level’…” into a better defined scope of works incorporating measurements such as ‘this will include details such as xxxxxx but to no more than a page per section’ provides a much better measurement for final project review.
Sign-off on this whether through email or formal sign off gets both parties mentally committed to the outcome and ready to move forward into delivery but perhaps it still may not be right, therefore we run through the last mitigation strategy being…
To Deliver and Verify as Early and Often as Possible
So you’ve managed to (you believe) get a grasp on the target, and get you and the client on the same page……but have you really? Unfortunately, this will only be finally be able to assessed once you are complete and you have sign-off, but it is possible to reduce the risk of an end of deliverable crisis by setting interim review points.
As early as practical, try to provide an early subset of the deliverable at what you believe to be the quality standard. If you are wanting to test the “depth” of capability to be provide, you can provide a complete feature for review, or of you ware wanting to test the scope, perhaps deliver a skeleton of the final work. Either way, deliver it as early as possible.
So yes, this may lead to premature failure; if they see what you’ve done and decide that you are on the wrong page or that you’re not delivering what you have asked, but at least early in the phase; you can agree to one of the following:
Address and move on
Close the engagement altogether citing “artistic differences”
Either way, it is a much smaller crisis than arriving at legal conversations after many months of work have been completed.
Conclusion
This topic is one that contains a list of methodology and control structures that is exhausting to even think about. I find myself referring to and utilising some of these tools specifically, generally these offer no better protection against this common project risk than following some upfront and planned activities to avoid that ‘awkard conversation’.
So next time you start a project, don’t ignore the vague and implicit quality expectations, tackle them and look to the following points to ensure smoother dialogue between you & your client:
Address Early
Deal openly and honestly
Document
Test and Verify early and often
Comments