Leadership

Don't blindly follow industry standards in your IT consulting work

Industry standards constantly evolve and change, which is why IT consultants should adapt best practices for each situation.

 

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!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

42 comments
gary
gary

Has anyone ever notices the similarities between standards and fences. Like fences, we use standards as protection. We hide behind them and hope that anything that might bother our tranquility will be stopped by them. Also like fences, standards challenge us to climb over them and to get to the side in the hope that the world will be better in a place where will can roam and to what we want to do. So, one should approach standards with that same healthy attitude that we have for fences. They will always be fences but there will also be adventurous souls who will climb over them.

reisen55
reisen55

Each and EVERY client is different. I philosophically contend that there are not three versions of Windows XP (Home, Pro and Media) but rather perhaps over a billion - because each and every single computer running it has DIFFERENT SOFTWARE installed and each single file, each small DLL piece of horror changes the thing. Not one computer is alike to another one. EVER. My clients are a mixed lot, some are tech saavy (few) so I have to work around and with staff to find ways to creatively solve issues that go against INDUSTRY STANDARDS. My only standard is what works for my individual client and also whatever works for my sense of value as a practicing professional. The two go hand-in-hand and compliment each other.

PMPsicle
PMPsicle

A big part of the problem is that so few people in IT (both writing the standards and trying to implement them), understand the terminology of standards. Should, May, Could, Must. Those are the four most important words in the standards development business. And their meanings are far more precise than many people may be aware. If the word "must" is used, as in the phrase"the SCUBA system must provide sufficient air mixture for one person", then you MUST obey that phrase to be in compliance with the standard. (For our example, the alternative is to kill the diver). Anything else is optional. Should means just that. Think of it as a STRONG suggestion. If you don't you are still in compliance but the result just won't be as good. "SCUBA should be designed to be used under water" (Firemen use specialized SCBA (no U)gear without being under water). May is only a suggested alternative or in some cases, an allowed (but not recommended) alternative. "SCUBA gear may be single use for rescue applications." Think disposable for submarine rescue. Could is a list of possible alternatives. Think of it as illustrative suggestions. "SCUBA gear could be painted in high visibility colours, or corporate colours." It sounds silly but the differences are important. (Yeah, I used to work for a mainline standards developer). Glen Ford, PMP http://www.trainingnow.ca http://www.learningcreators.com/blog

dcolbert
dcolbert

I came into an organization where there were no BKMs, no best practices, no adherence to "industry standards". It was anarchy. Complete chaos. Someone described it to me as "organic growth". Fine, but it was an overgrown bush turned into a tree that had never been pruned. But my experience is largely limited to enterprise architectural engineering - I can't speak to best methodologies for software development. I can say that my experience with software designers has been that those who have a methodical, process oriented approach to design and implementation may not be as stellar, but they are more reliable than the mavericks who always "shoot from the hip". As a matter of fact, that general observation applies throughout I.T. Methodical, process driven employees are slow and steady and deliver consistent, reliable results over the long haul. The guys who break rules and take chances and fly by the seat of their pants are OFTEN the "data center rock stars" who burn brightest, but they tend to crash and burn far more often, too. So, maybe I'm wrong, as this relates to the software development lifecycle - but in general, I think that BKMs and Best Practices and well defined processes, with reasonable flexibility - are core requirements to effective IT operations. Anyone who has worked at Intel is familiar with their P100 certification process for data center landing servers. For general rank and file IT - the P100 process is a nail-pulling exercise in corporate bureaucracy. And, for most Intel IT datacenter support, I think that bureaucracy serves a purpose. But Intel is smart enough to relax those standards for emerging groups that must be more innovative, fluid, and flexible. When Intel decided to adopt an initative to become a completely 100% eBusiness organization by 2003, the group they charged with delivering that goal was exempted from the P100 policies. That didn't give the group free range to act with impunity. Many other BKMs, BPs and processes were in place. But P100 restrictions were removed from this group. So, reasonable flexibility is one thing. Saying that you should operate without limits or definitions is quite another.

donovantrue
donovantrue

What about ITIL or COBIT? Weren't they created to standardize IT scenarios?

Sterling chip Camden
Sterling chip Camden

... the great thing about standards is that there are so many to choose from. Certainly there are times when you must follow a standard -- if you're going to consume a web service, for example, you have to follow its protocol and grammar. But beyond that, the application of standards should not be taken as a rubber stamp on your approach. Standards are made to be improved upon.

Sterling chip Camden
Sterling chip Camden

That is true. It's always been true to a certain extent, as even device drivers can change overall OS behavior, but it's much more true now in this era of componentized software. Back in the day when you got everything from IBM or DEC, you could at least console yourself with the idea that maybe someone has already tested this specific configuration before. Not so any more -- not that I'd want to go back to the days of a single software vendor (glances sneeringly at Microsoft).

Sterling chip Camden
Sterling chip Camden

... "could" and "should" statements shall be omitted from the standard, but may be included in a supplemental document profiling recommended practices.

Sterling chip Camden
Sterling chip Camden

There's a big difference between cowboy coding and keeping your methodology flexible. The former has no methodology. But on the opposite extreme, getting locked into documented standards can be just as bad as "shooting from the hip". The point is to think about what you're doing -- neither blindly rush in, nor blindly follow.

Sterling chip Camden
Sterling chip Camden

Both of those efforts focus on generally accepted "best practices" rather than hard and fast standards -- precisely so they can evolve with technology. They're guidelines more than standards.

thomas_w_bowman
thomas_w_bowman

Title was a motto of an ambitious 'typewriter' company in the early 1950's (IBM, my Father wrote much of their original policy, and promoted that motto). Of course every installation has 'Standards', some make more sense than others. I've been extended time and time again to help sort out what's working and what makes more work (without more value), for example I've seen Programs 'cloned' so that they would satisfy naming in slightly different processes - but when the function is the same, why multiply maintenance (and associated testing) ? Of course try to work with what the client wants to standardize - but when needed, work with that client to 'fix' broken paradigms. Resistance melts when quality/cost/timesavings and risk reduction can be documented. On my current assignment we have defined 'special' naming for 're-usable' code or processes, where all that needs to change can be set up as parameters. On a prior engagement I was able to deliver a criteria-driven adjustment (Medical Claims) process that was 'due' in 3 weeks, but had a 1000 hour estimate (and was prone to missing updates that occurred to 'normal' processing) by simply writing the criteria selection code and sending selected claims to the 'normal' process (using internal MQ instead of replicating the adjudication processing). By discarding all of the redundant code and getting an exception for a batch process to send online transactions - I was able to test in 4 weeks and implement in 6 - about 1/4 of original estimate (although I used DBA and System Programmer time in addition to my effort, so total hours were 2/3 of estimate). The savings began almost at once as mandated changes were made to the 'normal' process...I was asked to make the previously required redundant update, and was able to tell them that the update to the 'normal' process had already taken care of that issue (and was ready to use whenever they wanted - no added testing would be needed). Indeed, some 'Standards' can become expensive and counterproductive. The value I can offer is to THINK, and get processes to work accurately, efficiently, and in several cases CHANGE the 'Standards' to allow results to require a minimum of work and maintenance. That's what I tell prospective clients, which are few because I spend years on a 'three month contract', by doing so I also demonstrate that my 30+ years of experience has value that can't be offered by 'resources' with 3-5 Years (or who might be constrained by too much concern for 'Standards' and not as much for effectiveness, accuracy, and delivering what best satisfies requirements. Also, the least enforcable yet potentially valueable Standard is requirement for Documentation.

Marty R. Milette
Marty R. Milette

...that one of the biggest 'slams' against Microsoft from most Open Source folks is that they don't stick to arbitrary and obsolete standards. Microsoft generally works with a certain standard until they out-grow it, and then EXTEND it to suit their needs. The open-source crowd consider the strategy a giant 'conspiracy' -- solely designed to lock them out. Others consider it the only way to make advances in processes, procedures and technology.

jck
jck

some consultants need to learn to quit being so anal and think outside the box more?

PMPsicle
PMPsicle

Unfortunately, it ignores two things. First the size of the standard (after all this is a saleable product and needs to be large enough to justify its expense (see the date standards which are neither used nor sold)). Second, most professional standards (i.e. CSA, ISO, BSA, ANSI, UL) are either written collaboratively or at a minimum voted on by a cross section of interested parties. Your method means anyone who is against a particular clause is trapped in a Yes/No vote. There is no real compromise. By leaving the clause in, there is a compromise of using "should" (giving Yes/No/Maybe).

Marty R. Milette
Marty R. Milette

...gets to make the rules. I've seen a lot of contractors come in and start slamming established practices and standards within minutes of their butt hitting the chair. These folks have NO CLUE about the corporate structure, organization, or how things are done -- as a result, they think (and express the thought) that established practices and standards are 'stupid' or 'archaic' or 'obsolete' (according to their supposed 'superior' knowledge and skills) without considering how their piece of the puzzle MUST FIT into established systems. Many things are done less than 'optimally' FOR VERY GOOD REASONS that the newbie simply doesn't understand. Maybe you don't like waterfall -- but that is how the project is organized and how things MUST be done. Maybe you don't like the coding or naming standards used -- but again, you MUST use them or you will cause problems for yourself and others. Maybe you don't like the tools used. Tough beans -- SOMEONE evaluated the options and picked the best option for THEIR needs -- a long time before you likely came along. Aside from the obvious faux-pas of having the person authorizing your invoices hear that 'you think' the systems, practices and procedures that HE/SHE developed suck -- we still need to adhere to the requirements of our clients in order to be perceived not as 'the arrogant know-it-all' but as 'a member of the team'. (Like it or not.)

dcolbert
dcolbert

Rigid dogma stifles creativity, but lack of discipline creates a mess. You've got to find a balance in the middle that allows you to be creative and flexible, but have recreatable, managable process in place.

Henknum
Henknum

Every consult you make, you have to know the business where the IT is used. Standards you have to work with, only the standards that you can use for that business you can take. The rule is use the standard, but......

Sterling chip Camden
Sterling chip Camden

... because Microsoft's extensions are not usually open, the extensions become a lock-out (or lock-in) rather than helping to move the software community forward.

RookieTech
RookieTech

jck couldnt have said it any better

PMPsicle
PMPsicle

Companies like CSA, UL, ANSI and BSA exist to write standards and then test against those standards. Key word - companies -- as in revenue, costs, profits. As a certain management team liked to say not-for-profit does not mean non-profit. People get upset paying $100 for a 3 page standard - even if it includes a 30 page how to with it. A 40 page standard is easier to swallow (especially when one's business depends on following it). That's the first point. The method to write the standard generally goes -- Engineer writes, submits to a cross section of interested parties, gets feedback, incorporates feedback, resubmits until consensus is achieved (first vote), submits to all members for voting (acceptance vote), publishes. (Yes, there is variation - CSA for example combines the first three steps. And a failed vote does mean that the steps need to be repeated. Or in some cases the whole project is shelved.) The problem is that if someone strongly feels that a particular should really is a must, then the chances of getting a consensus (first vote) is reduced. Similarly getting adoption is also reduced (since their opinions are representative of their group). By seperating the shoulds and the musts you are making it very obvious which is required and which is optional. So there is no compromise possible. It either is required or isn't. This tends to harden the positions of the various stakeholders. And positions are often pretty hard without the need for more incentive. In addition, if seperate, a change of should to must or must to should would, in fact, require a rewrite. (Even during development). Which costs money. In a normal standard shoulds and musts along the grey line change place quite frequently during the writing process. Does that help?

Sterling chip Camden
Sterling chip Camden

A standard (musts, shalls) and a profile of recommended practices (shoulds, mays). That's what the RSS board has done, separating the RSS 2.0 Specification and the RSS Profile.

Sterling chip Camden
Sterling chip Camden

I don't worry about stepping on toes -- clients learn that what I tell them is what I really think. I've got plenty of clients who appreciate that, so I don't need to waste my time on those who want to be stroked politically. Yes, what I recommend has to fit with what they've already done. That's a big constraint that I have to deal with every day. But you're not helping the client if you just roll over and play status quo when something obviously needs fixing.

jck
jck

Only ever saw one piece of one of the movies. And most of the time, I was busy swiping the slobber off my chin from seeing Kiera Knightley. Ah...what a lovely lass she is. :)

maclovin
maclovin

If you look at the post above me, he said, "they're more like guidelines...." -Pirates OTC :D

jck
jck

Chip's right on. ITIL is a methodology or approach to doing things, not a guideline or playbook for what to do for what scenario. TBH, I think that "best practices" are fine in any field...so long as you realize that IT is [b]NEVER[/b] "one size fits all". You can never predict when hardware will break. You can never tell when a customer requirement will change. You can never tell when a patch will gimp your OS. You can never tell when an "enhancement" will blow up the functionality of one of your favorite development controls or methods. Oh well...blah. I might become a manager sometime soon. I better read up. :^0

Sterling chip Camden
Sterling chip Camden

Each consultant has to find the path that works for them. That path can change as time goes by. Back when .NET first came out, I was big fan. It was a significant improvement over earlier MS offerings (thinking MFC here) and was more coherent and powerful than the Java offerings at that time. But as time went by, I began to feel constricted by the .NET Framework and the C# language (we won't even mention VB). When Chad introduced me to Ruby, I suddenly began to realize why C# had seemed so restrictive. Since then, I've been exploring many other languages such as Lisp, Haskell, and Python -- and I've come to appreciate the multiparadigmatic approach to programming. Heck, even Microsoft sees that writing on the wall, and they've introduced F# and made extensions to C# in that direction. But they're behind the rest of the world still, and the .NET Framework is holding them back to some degree. Add to that that it's closed, and for me it no longer presents an advantage. That said, many consultants may find comfort in doing everything the Microsoft Way. When I do have to use MS languages, I try to stay in that Way as well, because to stray from it inevitably leads to frustration. But I'd rather not follow that path at all if I can help it.

Marty R. Milette
Marty R. Milette

Chip and I are kind of on opposite sides of the fence. Not far apart, just on different sides - tossing over the occasional grenade. :) Different people take different approaches with their careers. Some choose to be 'generalists' -- casting a wide net, hoping to catch more fish. Others tend towards being 'specialists' -- casting a smaller net, but after the bigger fish. Neither method is inherently wrong -- it depends on the kind of fish you are trying to catch which method ends up being more successful. It also depends on the individual. There isn't any 'one size fits all' solution -- this is an extremely volatile industry. Picking the 'right' horse today you can watch him turn into glue tomorrow. (Like some of my friends who jumped on the Novell certification bandwagon -- did great, but not for very long. IPX/SPX also lost against TCP/IP as VHS did against Beta.) I can certainly understand how it is attractive to try and 'hedge ones bets' by becoming platform/tool agnostic. I can also understand the attraction of getting everything for free. (I can't count the money I've spent on certifications, MCT fees and Technet/MSDN -- but it has DEFINITELY paid itself back many hundreds of times over.) For ME, biting the bullet and deciding to focus 100% on Microsoft technologies turned out to be the right move. It's been 15 years now, and once I became certified, I've never had a shortage of very well paying work -- regardless of markets or financial conditions. Not everyone can say the same. Looking at today's market, in Europe at least, we're seeing that instead of 'Systems Engineers', job postings are for extremely narrow specialists -- like a VoIP Engineer - salary 150K GBP (That's about $240K per year.) I was driven away from the open source side of the fence by stupid problems -- such as no two products being able to talk to each other, or products that don't take any advantage of the hardware they are running on -- and who don't give the the developers any decent access to the power of that hardware. I don't want to have to waste time and effort building kluges and interfaces between products. I LOVE the Microsoft Leggo-block style where you just snap together the pieces you need to build the solution. I LOVE being able to spend 100% of my time solving BUSINESS PROBLEMS rather than wasting it trying to get data or commands from one application to another. One of my favorite examples (and most horrible memories) is the University system I had the misfortune to have to use. Open source from end to end. You had to log into the main portal, log on again to access the library system, log on again to access your transcript, log on again to to access course materials, log on again to go to the discussion groups. (The concept of single sign-on either totally escaped them -- or they simply couldn't make it work.) Worse than that, every system had a completely different look, feel, menus and overall user interface. YUCK! In terms of learning curves -- I also really like the fact that once you UNDERSTAND the 'Microsoft way' of doing things -- that knowledge can be leveraged across the ENTIRE product line. Learn ONE language, a bit of SQL, and some basics on how to invoke and manipulate objects -- and that knowledge can be leveraged from a single client system and single-user application, all the way to a 100 server farm, serving millions of users across a dozen applications. Just look at the different 'project types' there are in Visual Studio to get an indication of how much power you have. Everything from a text console app to COM components to web applications to ActiveX controls to Silverlight applications -- with ONE development environment and ONE language. Chip and I have two different views -- his is that open products make his life easier -- mine is that a single, proprietary set of products designed to work together make my life easier. Go figure! :)

Sterling chip Camden
Sterling chip Camden

and they certainly have every right to pursue that in any legal way that works for them. But the consequence of it is that life becomes more difficult for developers as multiple "standards" emerge. Often we're faced with the decision of whether to "standardize" on Microsoft technologies or the rest of the software world, and even interfacing between the two can become onerous. Sure, other languages and OSes differ from each other in significant ways -- but for open source alternatives because you can see the sources you can figure out what's going on. The same is not true with Microsoft products -- you're left to rely on their documentation, which is usually geared towards an end-user or at best an application coder, not a metaprogrammer. Don't bother calling them, because their tech support is usually less informative than the MSDN docs. So it's often an exercise in trial and error when it comes to doing anything out of the ordinary. I'm not trying to tell MS what to do -- that's not going to go anywhere. But I can decide to use open products whenever I can to make my own life much easier.

Marty R. Milette
Marty R. Milette

...anything in the Microsoft Shareholder Annual Report about them having a responsiblity to move the entire software development industry forward. I'm just delighted that they have the ball$ to move themselves and their customers forward -- not being held back or crippled because 'some' folks want to hold the world back to their own limitations. Right now, I have a developer working on some extensions to my custom toolbar product that would be IMPOSSIBLE to do without some of the VERY cool Microsoft tech.

PMPsicle
PMPsicle

Considering how sick I've been for the last week .... I think undead is all I can see for the moment. ]:)

Sterling chip Camden
Sterling chip Camden

... and jck's comment about "thinking outside the box" is right in line with that.

TNT
TNT

I thought the article was about avoiding the term "industry standards" (not avoiding the use of best practices) and to get caught up in creating an elegant solution instead of the industry standards de' jour.

jck
jck

Both for knowing it wasn't negative, and the well wishes. I got a fortune cookie the other day that the paper (I kept it) says: "Good things are coming to you in due course of time." Well, I hope that means both a job I enjoy and a place I enjoy working for, as well as a female to go home to at night, cuddle up on the couch, and enjoy a bit of the vino by the fire. BTW: If I get a wife, the late-night consulting thing is defintely OUT. :^0

Sterling chip Camden
Sterling chip Camden

and here's hoping you get your wish. Keep your eyes open, some opportunity will come your way.

PMPsicle
PMPsicle

But then we'd miss out on your deathless prose. :D

jck
jck

I just had a really stressful day yesterday, and someone's comment tipped me over the edge. Loved the article, as I do most of your stuff. Wish I could get my biz going and get out of this office, 8-5, working to others' standard type of routine. And yeah, I would do it but the economy here in FL is still in the crapper. Plus, the elderly retirees are tight with the pennies anyways. Hopefully things pick up, or I move on to greener pastures.

Editor's Picks