How to Ruin Your Project
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 like that--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 that allows 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--the system 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
Please log in or sign up below to read the rest of the article.
|
"I only hope that we never lose sight of one thing - that it was all started by a mouse." - Walt Disney |




