Quality

My wife is constantly reminding our kids that they need to follow all of the directions when doing their projects and make sure that all of the objectives of the project are met.  But it that quality? I guess that really depends on whether you want to measure quality during the build process or whether you want to measure quality as at the end of the process.  I'm going to argue that in the IT field we need to measure it both ways.

Quality at the end of the process - the delivery of the application to the business client - is very important as this is how IT is predominantly measured by the client:  were my needs met and if they were met how well were they met?  If you don't meet the needs of the client it doesn't matter whether you built it ahead of schedule and under budget because the client is not going to be satisfied.  We don't do JD Power & Associates surveys of all of our work, but maybe we should.

Quality during the build isn't something that the client concerns themselves with, that much, but it has a direct impact on time and budget.  Fewer mistakes during the build process means a faster time to finish and a lower cost.  So, while it may not seem important it has a vital role in the cost of the product at the end of the process.  To be honest, this is where most projects fail to perform any measuring and this is where the most important information about the build process can be found.  Measuring the end result is fine for final reports and is something that you can parade around on your business card, but it doesn't tell you how well the job was done on a daily basis, just on an overall basis.

In my opinion, understanding how well the project is doing on a daily basis, the quality of the work that each person creates each day, is just as important as the end result.  But, hey, that's just my perspective.