This article originally appeared on the BeyeNETWORK.
A long time ago, I had a good friend named John. He came to work at the company I was with and I got to know him well. At the time John came to work in Texas, he was a methodology expert. His company had just sold a development methodology to my company. The methodology was impressive. It came in several black three-ringed binders. It carried with it very official sounding text, along with lots of small line diagrams. It described many steps to be accomplished in the development process.
Prior to the arrival of the methodology, the development at our company was done by a development staff that had been building systems for years. Then, one day, this methodology appeared – and absolutely nothing in the development process changed. The methodology was respectfully placed on a shelf in top management’s office. It probably still remains there today – untouched and unopened – continuing to gather dust.
But management was happy because now the company had a methodology – a standard and official way of developing things. Rumor had it that management paid a lot for this development methodology that was never implemented or even looked at seriously. In fact, no one ever found out what was inside the mysterious and somewhat threatening-looking binders.
I learned later that this story is common to many companies. It wasn’t just my company that should have been considered crazy when it came to a development methodology; it was a lot of other companies as well.
In those days, there were a lot of people who had some very strange ideas about methodologies. The problems with the methodologies were legion. Some of the problems were:
One size fits all. Our company bought a methodology under the presumption that there was one way to develop systems. In truth, there are many ways to develop systems. Systems that are small can be developed one way. Systems that are large and complex can be developed another way. Systems that are operational are developed one way. Systems that are analytical are developed another way. Systems that are centralized are developed one way. Systems that are decentralized another way, and so forth. The truth of the matter is that there are many ways to develop systems. Having just one methodology belies the fact that there are many different ways to develop a system.
There would be acceptance of a formal way of doing things. The developers at my organization had been building systems for many years and had been doing so successfully. The arrival of a new methodology made the subtle statement to all of the developers that their past twenty years of experience were wrong. The new methodology was the right way to do things, and we were all wrong. That is never a well accepted message.
Generating paper had great value. The new methodology placed great emphasis on generating paper. Not getting results in development, but generating a lot of paper instead.
And in truth, there were a lot of other problems associated with our methodology. Consequetly, everyone routinely ignored the methodology. Management sat there smugly thinking that now they were finally in control. The company paid the outrageous bill to the organization selling the methodology. The methodology sat on some bookshelves and gathered dust. And all was happy in Texas.
This quixotic story has been repeated in different forms over and over. In reality, there is nothing wrong with a methodology – if it is understood what the role of the methodology is and should be.
In order to explore what is wrong with a methodology, let’s take a look at what many methodologies look like. Many methodologies have a paint-by-the-number approach. First you paint number 1. Then you paint number 2. Then number 3.
What is wrong with this approach? A methodology that tells you how to do something is bound to fail. Methodologies should tell you what to do, not how to do it. The instant a methodology starts to tell you what to do, the scope of the methodology is grossly limited. A methodology telling you how to develop a system for Teradata is not going to be applicable for the development of an implementation of Oracle. A methodology that tells you how to develop for Business Objects is not going to work for MicroStrategy.
It is the job of the methodology to tell you what needs to be done, not how to do it. The more that a methodology tells you how to do something, the less value it has and the less general applicability it has.
Perhaps one of the greatest methodologies of all times is the Boy Scout merit badge system. Consider the hiking merit badge. In order to pass the test, a boy is told to hike twenty miles. The rules for the merit badge say nothing about how the hiking should be done. There are no rules for wearing certain shoes or certain clothes. The hike may be in mountains or the desert. The hike may be on a seashore or in a jungle. The merit badge system says absolutely nothing about how anything is to be done. Instead, the merit badge system talks only about what needs to be done.
By concentrating on what needs to be done, not how to do it, the merit badge system is generally applicable to boys in Alaska, California, and New York City. The merit badge system is applicable to boys in Great Britain, Australia, and Brazil.
One of the great secrets of a successful methodology is that it is focuses on what to do, not how to do it. Unfortunately, when organizations buy a methodology, they buy it for the wrong purpose. Organizations buy a methodology for the purpose of learning how to do something, and that automatically limits the effectiveness of the methodology.
Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.