Quality in Project Management - The What and the How
Many a project fails to meet its expectations or gets cancelled all together. Much is said about failed projects and I am specifically talking about technology projects here since my personal experience is more in this field than subjects like construction.
One reads article after article about scope creep in projects. Another knowledge area often blamed for project failure is budget. But it is not uncommon that the true cause behind the apparent failures is a more fundamental one: Quality. This isn’t a rule but happens often enough to deserve mention.
A project manager’s duties are many and in some cases quality is simply seen as another such duty. And in some cases is even considered a less important one. But fact is that the actions that make up the breadth of a project managers responsibility in regards to quality span all knowledge areas. The importance of quality assurance vs quality control is often missed.
If you have worked in a number of technology firms, ask yourself how many have you seen that had people at the end of the line checking the quality of a product. Nearly every firm has it. And in most companies it is called QA. Using PMI terminology that’s a wrong name for starters. But while the use of terminology is trivial here, the roles that exist in regards to quality are paramount.
In PMI’ism quality assurance are the actions that happen while a project is underway to guarantee a high quality product in the end. Quality control on the other hand is what happens at the end of the line to verify the end product meets quality standards.
In short, most firms focus on the quality control actions (whatever they call it). Yet it is the actions that happen throughout a project (or throughout a product life cycle) which avoid costly consequences or often even the need for additional scope, higher budget etc.
If you wonder why ensuring quality has anything to do with avoiding scope creep then you need to consider the definition of quality. Quality in general is best defined as meeting a standard. And in case of a project it is better stated as meeting specified requirements (those of the client or whoever will consume the end product of the project). Needless to say if requirements are not achieved or let alone not even properly stated then we have a build in quality problem.
A project manager should be aware that his three quality processes (if using PMI methodology) happen throughout his entire project. Having a well thought-out software design is just as important to quality as a developer doing thorough unit testing of his code. Each step of the way has critical actions that ensure quality is achieved at that point.
Waiting to the end of a project or phase to check for quality is way too late.
A project manager might not be a highly skilled software designer who can spot a faulty design for a new piece of code. But neither does he need to be. That is where being an executive comes in. A good executive can spot problems, whether he is an expert or not. A resource hesitating when answering how something should be done is an indicator something might be wrong. A contrary fact when someone explains what they are doing points to a potential issue. And hundreds of other indicators that can be spotted by anyone who is willing to just look at what is going on. Rather than listening to endless explanations.
In anything you do, keep quality in mind as a project (or product) manager.