Consultants often encounter and toss around the phrase industry standard. The phrase is in almost every RFP I’ve seen; it’s been the subject of debate for decades in lawsuits over non-performance; it’s often used as a marketing term; and you may include it in your consulting agreement (“will perform all work according to industry standards”), although I don’t recommend it.

What does industry standard mean? According to Answers.com, industry standards are:

Orderly and systematic formulation, adoption, or application of standards used in the industrial sector of the economy. An industrial standard is a generally accepted requirement to be met for the attainment of a recurrent industrial objective. In the automotive industry, standardized tire sizes are an example.

If only putting together IT solutions were as simple as designing and assembling a vehicle. The evolution of IT has always been much more rapid, and it continues to accelerate; however, the components and methodologies employed are more complex, so the process of developing standards takes quite a bit more time. As a result, much of what passes for industry standard in IT employs technologies for which there are no standards.

In other industries such as manufacturing, the impetus for adopting industry standards is to make sure you do things The Right Way. But, especially in software development, sticking to standards often means you’re doing things The Wrong Way. By the time a software standard finally gets approved, it’s almost always obsolete; and I don’t just mean obsolete as in “it needs updating” — I mean it’s irrelevant. Its raison d’être has evaporated. I’ve served on standards bodies and watched my work become merely the decoration on a headstone for dead software. Sticking to those standards might keep you safe, but it may also make you outdated.

Also, software development methodologies evolve to keep up with the complexity of newer software components. The old standard waterfall cycle of requirements/design/implementation/testing/acceptance worked well as long as you could nail down the requirements in advance, but that doesn’t happen too often anymore. We now have to repeat this cycle on a weekly or even a daily basis because testing and acceptance often generate new requirements. (Part of the beauty of test-driven development is that it streamlines part of that cycle by creating the tests prior to the implementation.) As software becomes more complex, developers have to create new ways of dealing with that complexity. This doesn’t mean that you shouldn’t have a methodology, but you can’t afford to slavishly follow any industry standard methodology; you always need to creatively adapt any approach to the realities of your situation.

Thus, we see in software design and development the emergence of fluid, informal standards. These standards may be specific to an organization or a developer community, but they are free to evolve within limits to meet new challenges. These sorts of standards (or best practices) are in place to fulfill the goal of doing things The Right Way (or at least, avoiding The Wrong Way — I like the freedom of There’s More Than One Way To Do It or TIMTOWTDI). But because the standards can evolve without fanfare or an act of Congress, you may easily find yourself in the situation where what you implemented as industry standard five years ago is no longer an industry standard today. It may not even compile.

If you asked three experts about the industry standard for how to approach a specific problem, you would be lucky to get only three contradictory answers. The rapid evolution and complexity of software development leaves many theories about the efficacy of one approach over another largely unproven; therefore, it’s almost always a good idea to prototype your solution using a few approaches rather than deciding on a specific standard in advance.

This is why my contract doesn’t mention industry standards; if my consulting work were to ever come down to a legal battle, it wouldn’t be hard to find expert witnesses who could testify either pro or con about my methodology or technology choice. I advise you against mentioning industry standards in your contract unless you’re prepared to define the specific standards to which you adhere.

Get weekly consulting tips in your inbox
TechRepublic’s IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!