Anyone who’s spent time with me learning or working on projects will have heard my philosophy on project quality: better is the enemy of good enough. Anything other than “excellent” can seem like failure, and yet putting in extra effort that will not be valued by the end user or other relevant parties means that resources (time, money, effort) are spent on things without any return. One area that can be challenging in the study of project management is the difference between scope and quality, and how to determine and measure quality, especially in research management.
It's true what they say – the best way to learn something is to teach it to someone else. I have been teaching project management again this year as part of the Mohawk College and CARA Research Administration Certificate program. I learn a lot in the online discussions in my classes about the breadth of research work in Canada as well as the similarities and the unique challenges that research administrators and managers face in their work. I also learn new things and approaches to project management (old dog, new tricks), and some recent discussions were very insightful and thought-provoking in the area of quality management.
This will be the first of a short series of posts about quality management, to include some of my take-aways from teaching as well as recent experiences in my own work related to quality.
The first few learnings from my teaching experiences:
Better vs good enough: this phrase always gets push-back from people. It sounds like it's not interested in excellence. Not true – if excellence is required, then absolutely that should be the good enough of the project. We still need to define "excellent" for our project. When we start with good enough, and define what that means for the project, then it becomes an objective element of the project. We can measure our work and outputs and see when it is good enough for what we need from the project. “Better” is subjective (ditto for perfect and excellent). How much better? According to whom? How will you know when it is "better enough" to stop? After all, projects are temporary and have constraints like time and funding that require us to define quality objectively so we can know when we are done. Otherwise, we can pursue better and excellent until we run out of time or money (or both) and end up not achieving the project goals. In other words, the pursuit of better might mean we never achieve good enough.
I recall meeting with a team who was working on reducing the volume of material required as input for a certain process. They had been working for quite a while on this, and yet the end of the work always seemed out of reach. When I asked how much of a reduction they were aiming for - how much should the input amount be - the answer was, "as little as possible." By this point, they had already achieved a reduction of 400% (only 1/4 of the amount needed in the previous method), but they had not yet implemented that because they were trying to make it "better." When I facetiously asked, "so is the goal to require zero input material?", they started to realize the difficulty of their quality goal being so vague. By first acknowledging that the work so far was "good enough" to implement (a success), and then setting a measurable goal for future work (a new project aiming for a 10-times reduction in input amount), the work now had clear goals (some milestones also helped).
Know thy project: defining the appropriate quality criteria requires a clear understanding of the project and especially the objectives and the stakeholders. Consider a scenario where we’re preparing a grant application for a research project. Defining the quality criteria depends on whether you consider the work as two separate projects (a proposal and a research study) or as a single project (with the proposal being just one element of the entire body of work). Be clear about what the project is and define the quality criteria for that work. (Spoiler – I consider the proposal to be a separate project.)
Don’t panic: By having clear quality objectives, teams can control any “panic” response to an instance of poor quality. Teams need to guard against reacting in an uncontrolled way to the latest status or piece of data, instead responding in a controlled way to keep the work aligned to project goals. A single instance of poor or lower than expected quality should be carefully considered within the entire project plan and addressed accordingly. To quote the famous project manager, er, philosopher, Aristotle, “one swallow does not a summer make.” One bad result or poor outcome does not mean the entire project needs to be changed.
When helping is not helpful: As research administrators and managers, our raison d’etre is to help researchers, faculty, and staff by providing information, removing barriers, and getting them to where they need to be for success. But this can lead to being too helpful, which then leads to scope and quality creep. A seemingly small request that is outside of what we should do can snowball into something now expected of us by everyone, setting a precedent that can create a scope monster. Similarly, in our zeal to make something excellent, we may try to ensure that our feedback, instructions, or report includes everything that the requestor might need. “Everything” is a big ask in any situation, so by setting that as our quality standard, the scope also increases to an unmanageable and unachievable level.
Several years ago, in a project management training session, one of the participants said that their organization’s approach was to “under promise and over deliver”, and they asked if I thought that was a good approach. I said (as I often do), “it depends.” The difficulty with that approach, from both a scope and quality perspective, is with the modifying words. If we under promise, we have poorly defined the scope and quality of work needed to address the project’s purpose. If we over deliver, we have failed to stick to the project plan. And how do we measure the amount that we should be under or over? Most importantly to me, this is a dangerous precedent to set with stakeholders such as clients or customers, as they will come to expect that you will always provide more than what you promise; they will learn that your proposals and estimates are not accurate or reliable, and will assume that they’ll always get more, even when it’s not achievable, resulting in dissatisfaction at best and loss of business at worst. If you don't over-promise, you'll never have to over-deliver.
Like the other elements of the scope-time-cost-quality balance, quality should be defined in the project plan and then monitored throughout the project, adjusting as needed to achieve the objectives. Efforts to make the outputs unnecessarily better are the enemy of project success as they use up time, effort, and money without achieving what the project needs – meeting the goals on time and within budget. Anything else is the opposite of excellent.
What are your experiences with managing project quality? What about balancing quality and scope? Please comment below or email me at email@example.com with your questions and feedback.
Interested in more on this or other topics? Check out my upcoming webinars and presentations at www.lyricmgmt.com. Follow me on Twitter and LinkedIn for the latest on these and other topics. You can also complete this brief survey to join my mailing list to receive a monthly newsletter with blog posts and webinar schedules, and to be entered in a monthly draw for a prize.
Who is Robyn?
My career as a research project manager is rewarding, dynamic, challenging, and fun. I'm looking forward to sharing my knowledge and experience in communication, organization, and common sense approaches in research management and leadership, and to enabling others to learn and grow in this exciting career.