We often hear things like “paying for quality is worth it” or “buy a quality product if you want it to last”. With products where quality can be measured easily (using measures like average life of the product, service requests etc.) it is easy to confirm the validity of these statements. But in IT consulting do these quality selling mantras make sense to our clients?

The main differentiators among IT consultants (and consulting companies in general) are the efficiency in developing the application and quality of the final product. Additionally, the results from a highly skilled and experienced consultant can often produce measurable short term benefits, including shorter time to completion, improved functionality in the end product, or can simply be the difference between a project that is completed successfully or not.

To a technical stakeholder (e.g. application architects or senior developers) who can judge the quality of the consultant’s code (via parameters like use of design patterns, ease-of-maintenance, readability, test coverage, ease-of-debugging etc.) the total cost is quite obvious. But for managers and decision makers outside of the IT organization it can be particularly difficult to see these impacts, since they don’t have direct insight into the development process.

A challenge remains in making sure that stakeholders who do not have time (or access) to analyze the code also see this value and that quality is not just equated with “timely and within budget delivery of the project”. In this post, I will try to come up with some key benefits of employing highly skilled, quality IT consultants that can be used to meet this challenge.

Benefits during Development:

Not surprisingly, quality of the work of the developer during design and development drives the defect count in testing, and more importantly if the project is going to meet its date or not. Higher number of defects not only mean extra cost in terms of development team’s effort required to support the testing, it also results in longer engagement of support infrastructure like test environments.

Though not a general rule, many researchers agree that it takes 10 units of work to fix a defect in traditional testing phase that would have otherwise taken 1 unit to code correctly, and sometimes it is too late to incorporate a fix. It is not very difficult to see the value of quality code (and thus quality IT consultant) here! There are many more costs like extra testing cycles, longer deployments etc. that are a direct result of poor job done during development. Even though these things add to the overall cost of the project, they are often ignored, while justifying extra cost incurred in employing quality resources and consultants.

Benefits post deployment:

The quality of the deployed product would decide the number of production issues. Many researchers agree that on an average fixing a defect in production costs 100 times of what it would have cost during coding. Add to that the cost in terms of lost business, extra deployment cycle etc. and you see why it pays to have only a quality product go into the production.

Benefits during future releases including enhancements:

When considering the investment costs of a software development project, an area that is often overlooked are the long term costs associated with maintenance and enhancements over the life of the software.

A project has defined beginning and end dates, and within that defined period it is easy to determine level of effort and costs for the development effort. It is more challenging, however, to quantify how the architectural decisions and the quality of the code written during the development phase will continue to impact the cost of supporting the application long into the future.

Though it is not very obvious, a considerable part of total investment that goes into a software product goes towards its maintenance (and enhancement) releases. We all know that a better designed and developed product is easy to maintain and enhance, compared to a poorly designed one. The cost of such maintenance releases can thus be easily seen as a function of the quality of the initial product release (and releases thereafter).

Loosely speaking, the “cost of poor design” that one has to pay while developing subsequent releases can be termed as “repayment of technical debt” (i.e. if you decide to fix the poor design in your current release). But if you choose not to fix them, but rather circumvent them (of course painfully), it is called “interest on your technical debt”.

This concept of technical debt (principal and interest) accrued while developing a product/project, along with its future projection can be used to successfully explain the quality of the IT consultants. Less technical debt means lesser maintenance cost in future. Effectively, our cost of the product/project could thus be:

Cost of the current development

+

Technical debt accrued during the development of current release

The points listed above are only a few that I could think of but I am sure others can think of many more. So please pitch in and add them to the list via comments.

Be Sociable, Share!

•