As a software project manager, one of your most important responsibilities is to ensure quality. This may seem obvious, but I find that it needs to be reiterated, especially if your team is growing. I have been focusing a lot on quality over the last few months. Not just “nice code”, but things done right, the first time. Over the years managing projects, I can say that one of the single most significant sources of client dissatisfaction is the idea of rework. No one wants to feel like they’re paying to re-do work, nor do they want to have to make sure work is actually complete despite being told so. That’s your job as project manager, you’re the keeper of quality.
So how do we make sure things are done correctly the first time? We do it with a systematized focus on both Quality Assurance and Quality Control. Quality Assurance deals with your process, and is focused on defect prevention. For me, this means that I need to take steps to ensure that the client requests and requirements are translated into specific deliverables for my team. There needs to be a means to measure completion to quality standards, BEFORE the work begins. Here’s an example; a client recently asked us to build a file uploader tool that is drag-and-drop “like the one WordPress uses”. That’s a pretty vague request, there is a lot that the WordPress tool does, such as resize images into predefined sizes, allow toggle to multiple file uploading, store the files in a media library etc. Beyond that, the developers need to know exactly what the user interface should look like. So here are steps you can take for a request like this:
- Clarify requirements: Ask all of the questions up front. Here’s your chance to add some value based on your experience on other projects. Try to suggest things they may not have thought of. Clients LOVE this, and it helps separate you from your competition who will often simply follow instructions without trying to add value.
- Define Deliverables: Write the description in your own words, but in the context of the final deliverables, instead of the tasks to produce the deliverable. Describe the final product in as much detail as you can.
- Prototype: Depending on resources and budget, this can be anything from a sketch on paper to a semi-functional tool. The idea here is to have something visual that the client can begin to experience. Changes in requirements will also come as a result of the client seeing the tool, and this is where you want to make these changes (not once the development is done). Go through as many iterations here as you can to get it right before development begins.
- Incorporate Change Processes: This is important. If there are change requests, you need to have a well-defined system in place to receive, evaluate, and approve the changes. In order to Assure Quality, changes to requirements must be reflected in acceptance criteria.
That may seem a bit cumbersome for smaller web projects, but once you have the systems in place it will always save time overall. So that’s Quality Assurance, with a focus on the process and systems.
Web project managers also need systems for Quality Control, which is more focused on defect identification. So QA prevents defects, QC keeps defects out of the hands of the client or users. The goal is prevention over inspection, but inspection is a vital component. Depending on the size of your team, this may fall on your shoulders as the project manager, or as in my case, we have a member of our team who is (among other things) responsible for QC. Our process is as follows:
- PM assigns tasks to developer
- Developer communicates when complete with QC
- QC verifies complete, or works with developer until complete
- QC communicates to PM that tasks are complete
Again, this may seem cumbersome. It also may seem like too much overhead, but I can assure you that this saves time, and more importantly, improves client satisfaction. Whether it’s you as the PM or someone doing QC on the work, there needs to be a second set of eyes to verify completion. I must admit, it took me over a decade to really believe and adopt this. I always thought that developers (including myself) should just do a better job of checking their own work. But inevitably, things are going to be missed with this approach. It can be compared this to proofreading your own writing. You need that second set of eyes for inspection. Since putting a higher priority on this, we’ve experienced a very significant increase in client satisfaction.