Wednesday, June 4, 2008

I know!, INO, I know :-(

In the beginning of IT there were no roadmaps or directions. Everybody had to learn the hard way how to get things done. Based on these experiences, best practices developed, which evolved into Standards. Thus Standards like Prince2, ITIL, TOGAF, ISTQB, etc. are based on solid experience of years of trial and error. In today's IT world, most Standards are available to everyone. If you want to built or migrate a new Infrastructure you could use
a standard in every phase; from gathering Requirements to delivering the final Product.

I know this is a good thing, you know this a good thing, in fact everybody knows this is a good thing. So why is there INO; "In Name Only" ? The most famous INO is PINO (Project Management), but others exist as well such as AINO (Architecture), IINO (ITIL), etc. In fact INO is applicable to every Standard available. How does INO work? A Project is started using one or more Standards. At a certain point the use of this Standard becomes less strict, until at some point it is non-existent. That is when you are in an INO situation.

Why would you ever want to do this? Why choose to use Standards and after that not use them? A good question, to which the answer is often, that it is to hard to do it and it costs too much time. If only the answer was as good as the question. In my opinion you either use a Standard or you don't. In a statement comparable to the Agile Manifesto; I prefer the Rigidity of Standards over the Arbitrary Terror of INO.

Why prefer Standards?, one reason is that decisions are clear and accountable. Everybody knows the rules and can therefor use these rules to make decisions. For example in Prince2, what will be delivered is defined in a Product Description. Before you can deliver less or more, you have to go to a process that makes clear what will be changed, why there is a change and what the impact will be. You may not agree to the change, but it is clear what and why it has changed. With INO, decisions, deliverables and requirements can be changed without notice, without a clear reason and without clear authority. This leads to the situation where no decisions are made, since every decision is swayed by the issues of the day. This uncertainty leads to delay which can eventually turn into failure. So my advice is to stay away from INO and use Standards.

One final thought, should we follow the Standards to the letter? Not necessarily, but make sure that it is clear beforehand what part of the Standard will be followed. Otherwise you have already sowed the seed of INO in your project.

1 comment:

Jeroen said...

Hello Brian,
Good article you posted. I liked the finishing phrase: "One final thought, should we follow the Standards to the letter? Not necessarily, but make sure that it is clear beforehand what part of the Standard will be followed. Otherwise you have already sowed the seed of INO in your project."

Only in your posting I missed one INO: TINO: Testing In Name Only

with regards,
Jeroen