How to ruin your project

How to Ruin Your Project Andy Jordan May 10, 2010

A few years ago I was addicted to Minesweeper--that free game that comes with Windows. The largest size has 99 mines and 480 tiles. I found this game incredibly frustrating because you could make more than 450 correct decisions--and then as soon as you made one wrong move the game ended in failure. It seems to me that quality is a bit likethat--you spend the entire project building up the quality, making sure that there is not a single misstep and then one bad decision and the project quality is destroyed. In this article I want to look at some of the areas where those bad decisions are commonly made and see if I can help you navigate through the minefield (sorry, I couldn’t resist…). In the beginning If you don’t lay a foundation thatallows for quality deliverables then you have no chance of success later on. In projects that means ensuring that the requirements are complete and accurate, and quality has to play a very large part in that. It’s not sufficient to document the features that need to be built; you also need to define what makes those features acceptable to the client. That can be simple and straightforward--thesystem has to be able to process 10,000 transactions per hour, for example. That’s a target that is either achieved or not. In many cases though, the acceptable quality is not so obvious. How do you define whether the user interface of an application is acceptable? In the real world the problem is frequently not addressed in the requirements; instead, it’s left until the application is built--andthen the problems start because there is no measure of acceptability. Instead, we are faced with managing unchecked client expectations. If instead the requirements identify how the UI will be rated (an end user survey with a target average score, the amount of time taken to complete certain standard transactions, the amount of user errors, etc.), then you are setting yourself up for a much greaterchance of success. Also at the start of the project is the issue of where quality sits in the priority list of project constraints. In the past we all thought of the triple constraint of time, cost and scope, with quality being balanced between the three. In the latest version of PMBOK, PMI has moved away from the triple constraint in favor of six project constraints: time, cost, resources, scope,risk and quality. This give a perfect opportunity to have a conversation with the customer at the outset about where quality fits in that list of constraints. If quality is second only to risk in the customer’s list, then we should make project decisions that put quality ahead of cost, resources, time

and scope. Of course we work with the customer throughout the project to make thosecompromise decisions, but if it’s addressed in the requirements then we have a documented authorization not to sacrifice quality to save a few dollars or a few days. Pressure compresses quality One of the biggest problems that I have with project quality is just how willing team members (and project managers) are to let quality slip when things get tough. It seems as though it’s seen as a “lesser” targetthat can be sacrificed if we get behind schedule or over budget. It seems to be perfectly acceptable to cut corners, especially in processes. This is not usually because the importance of quality isn’t understood, but rather because the connection between a quality outcome and “doing things the right way” isn’t acknowledged. This isn’t always the kind of problem that you can address in theconfines of a single project-it needs to be addressed by the PMO through training and enforcing process. But as project managers we have to ensure that we are creating an environment where the importance of processes is stressed, where the need for quality is paramount (assuming that it is an important aspect of the project) and where staff understand that they won’t be criticized for putting quality...