Oops! The input is malformed!
Originally published April 12, 2013
Years ago I had a job going around the country doing design reviews for many organizations. Over the years, I probably did 50 or more of these design reviews.
We looked at any and all reasons IT systems could be improved – everything from performance to development to operation of the systems to the cost of systems and much more. Everything was fair game in one of our reviews. At the end of the review, we tidied up our notes then sent a written report to management. Then it was on to the next review.
One of the phenomena that we saw over and over was that some organizations could make a given technology sit up and hum while an organization down the street could not make the same technology work to save their lives. In case after case, an organization would try to build systems in a technology, fail, and then go on to the next technology, where they would fail again. And at the same time, other organizations could make any technology work.
After seeing this phenomenon repeatedly, we came to the conclusion that it was not the strengths or weaknesses of the technology that meant success or failure. Rather, it was the organization that tried to use the technology that was the deciding factor in terms of success or failure.
What were the factors that seemed to separate the successful companies from the unsuccessful companies? The following is a subjective list of what we perceived to be the factors that made an organization successful when adopting new technologies:
Hands-on experience and control. In case after case, organizations that had a problem and then wanted to hire someone else to come in and solve the problem for them were the least successful. Organizations that had the attitude of “wake me when it is over” were simply asking for a failure. (Does anyone remember this nonsense: “With 4GL technology, we don’t have to worry about coding because with 4GL coding we can do it fast.”) In the cases where a consulting firm is brought in, a winning practice has always been to have a few employees embedded in the project at key places.In a word, organizations that succeeded were the ones that were willing to grapple with problems on a firsthand basis, were willing to recognize problems as soon as they arose, and were willing to use common sense. That was true in the past, and it’s still true today.
Believing all of the technology hype. Organizations that wanted to buy a new technology and treat the technology as if it were a silver bullet were the ones that got into trouble. There was an almost mystical belief that a technology had some magical power. And in case after case, organizations discovered that products have shortcomings, despite the vendor hype. Vendors around the world sometimes over-hype their new products. It simply is the way the industry is. And many organizations wanted desperately to believe in the fairy tales the vendors were spinning. (Does anyone remember this nonsense: “Don’t worry about performance – computers are getting cheaper all the time.”)
Not willing to address or even acknowledge problems in their early stages. Often when something goes wrong it can be addressed early on with minimal damages. But many organizations simply wanted to bury their heads in the sand and hope for a miracle. By the time the problem was recognized and was fully manifested, the cost of repairing the damage was usually awful. (Does anyone remember this immortal line: “Just program it quickly now, and we will tune performance in later.”)
Not using common sense in looking for and addressing problems. In many cases, there was a belief in a methodology, a technology, or a consulting company that simply was not justified. Once again the organization was looking for something magical to happen when an ounce of common sense could have alerted and/or averted problems. (Does anyone remember the wisdom: “We don’t have to worry about programming because in the future programming will be so easy that anyone will be able to do it.”)
Recent articles by Bill Inmon