Friday, July 26, 2013

Value of keeping Quality in the delivery of a Product or Service

Response to Discussion on LinkedIn about Quality:  http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=260290748&gid=2054322&commentID=152704926&trk=view_disc&fromEmail=&ut=2aP7y5BX0LFlQ1

I agree wholeheartedly about the value and importance of Quality in the overall delivery of any product or service.  Often times end users don't realize that delivery of any type is like a 3 legged stool where Time, Cost and Quality are all directly correlated;  you cannot take away one without impacting the other. 

The way I have always tried to operate is to gather requirements that meet system user’s needs, and then deliver a scope where we will be delivering a quality solution in a timely manner.   What happens after that is users come back and want the same functionality developed in a shorter period of time.  They ask if we can add more resources in order to decrease the delivery time.  Sometimes the answer is yes, but then that has a direct impact on cost.  If the answer is no, then a discussion of critical path ensues and analogies regarding how you cannot put 9 women in a room together for a month and deliver a baby are discussed.    Finally, and far too often it is decided that yes, we can finish the development in a shorter period of time, but there will be no time left for Quality Assurance to verify the required functionality performs as specified or not enough time to do thorough regression testing to verify that existing functionality continues to perform as expected. 

Now, what are the results you get: a dissatisfied user group who is unhappy that you were unable to deliver on time, the opportunity costs of having to redeploy your team to deliver the expected functionality rather than having them move onto the next project, and across-the-board frustration that could negatively impact the overall relationship.  As opposed to not bending, let’s think about keeping Quality components in your project even if it means delivering at a later date so we can all be ultimately satisfied with a product or solution that meets needs the first time.   At the end of the day, or in a year from now, do you want your customer to remember that you could not deliver a quality solution when you promised or that you pushed back so you could deliver a fully operational (think Death Star) solution that meets their needs?


No comments: