Most people dread standards, they are considered a nuisance at best but are mostly regarded as something specifically crafted to make life miserable. Yet standards are key in a healthy IT organisation. So why is it that people have such negative feelings about standards? In this article I’ll try to explain what the benefits of standards are and give some possible reasons on why they have such a bad reputation.
Perhaps unnessary but let’s first answer the question “what is a standard?“. A standard is a rule that instructs people to use a specific technology instead of alternatives, to perform an activity in a certain way, to use a common template for documentation … In other words, it limits personal freedom and forces them to do things, and always do things, in a certain way.
The case for standards is created around the premise that the IT organization as a whole benefits more than any loss that may be incured in some projects. But how can the IT organization benefit while some projects suffer? The key to explain this is optimization of investments. Investments made by the IT organization in those standard technologies, processes, templates …
Optimization Of Investments
Imagine the following scenario. Five years after an application has been placed in production, some features need to be added. You walk into the IT department and ask the following questions “Who knows what needs to be done, how much would it cost, how long will it take …?”. There are two possible ways this can go.
Option 1, the application was developed with a technology that was hardly used in the last years. Not a lot of people know what needs to be done and those people that did know can’t remember all the details, it’s hard to budget the change and no one really wants to estimate how long it will take. It may not be that bad in reality, but it’s obvious that at least some additional risk is present.
Option 2, the application was developed with a technology that is still being used for most application. Given all that experience, most people have a pretty good idea of what needs to be done, it will cost roughly as much and take as long as similar projects from a recent past. It may not be as positive as pictured, but in this case it’s obvious that risk is kept to an acceptable minimum.
These two options show what I mean with “optimization of investments“. By consistently using an as small as possible set of technologies, investments can be optimized: financial resources are spread less thin, opportunities for gains in experience and knowledge are focused to a small set of technologies …
Similar arguments can be made to show how standardized processes or templates will create benefits for the organization.
Individual Projects Will Suffer
In the introduction I stated that standards may actually make some projects suffer. In fact, it’s an absolute guarantee that some projects will suffer. I often state that I can make any project cheaper by having it not follow a standard.
A project team could be more experienced in a technology that is not your standard (although I suggest you audit your sourcing strategies if this happens), an alternative technology could have a feature that makes life considerable easier … there can be many reasons why a different technology benefits your project more than a standard will.
That is actually the heart of the problem with standards, everyone regurarly is confronted with standards as unbeneficial but rarely see the benefits for the IT organization as a whole.
Picking The Least Worst
When you choose technologies to become a standard, you are not looking for the one that is the best in a (small) number of cases, you are looking for the technology that is least worst in most cases. Yes, you read that right, it’s about picking the least worst. That may be one of the most common misconceptions of standards and is probably the root cause for the many (often useless) debates about changing one standard for a better one. If you change a standard, you are also rendering prior investments obsolete, thereby renouncing benefits. Either that new standard has to be extremely better or keeping the old standard must be awfully bad. In any case, a managed transition is required to safeguard past and future investments.
Changing a standard is not something you want to do in just the context of project, it’s a choice that affects the entire IT organization in the long term and therefore needs to be made at that level.
It also follows from the above that the best you can do with standards is to apply them as often as you can. The more you apply them, the less room there is for rogue technologies, the more experience the organization gains and the less risk there will be in the long run.