In my professional life as a project manager and now a project engineer, I need to be cognizant of the "triple constraint": cost - time - quality. The rule of thumb is that you can maximize any two at the expense of the third: you can get something done better and faster if you're willing to spend more money on it, or sometimes better and cheaper if you allow a more reasonable time frame. Completing something faster and cheaper will inevitably lead to a drop-off in quality. One trap that it seems easy to fall into is mistaking "quality" for "customer satisfaction". The latter is, of course, the ultimate goal, but an unsatisfied customer is not always a quality problem and the hoops through which we jump to make the customer happy are not always a quality improvement.
The Project Management Institute defines "quality" simply as how close a product comes to its specifications. In other words, it answers the question: "Did you deliver what you promised?" If it works intermittently, is missing a feature, or otherwise doesn't meet the stated goals then you have a quality problem. More often, though, I've seen things like this:
"We've been using the videoconference system you put in for us last week. It's great, but I can't figure out how to send my laptop over the video conference."
*checks drawings* "The laptop doesn't go out over the video conference. Didn't you read the submittal drawings?"
"The whole point was to share powerpoint presentations with the other office. It's useless otherwise."
"OK. I'll fix it.".
This is not, of cour fixing a quality defect but adding functionality which was missed in the originl scope. The result will be more feature-rich and lead to a hapier customer, but nt be higher quality.
No comments:
Post a Comment