December 16, 2009
General IT, ITIL, Standardization
No Comments
Policy creates structure for an organization. Policy limits errors, waste and creativity. Policy makes the irresponsible produce expected results. It can also corrode high responsibility levels.
A creative, high initiative and responsible person can be structured to carefulness, seriousness and inactivity. Excellence demands more than thinking outside the box – it requires acting outside the limits. Quantum leaps means taking risks, not only managing or mitigating them. Emphasis on policy and structure builds an organizational system, a machine producing the expected output. Geniuses, the wildly creative and people of outstanding initiative and responsibility create the unexpected. Sometimes the brilliant. Sometimes havoc. But desperately avoiding the trouble will leave out the excellent. With policy one can regulate and make all the people behave according to the rules.
There is much to recommend toeing a party line. Well organized groups can raise the standard of output. Toyota comes to mind. Henry Ford pioneered it. But it will never foster an Einstein, an Edison or a Da Vinci.
Individuality must be preserved for an organization to excel. And policy must never replace common, uncommon or even rare sense. The essence of good structure is to keep it minimal and really, really simple. The litmus test is if an organizational concept can be conveyed to a ten year old in 15 minutes. If not, it’s too complex, too cumbersome.
Unfortunately some policy is needed. But only because all the people are not brilliant and in constant synchronization. Because an army of telepathic geniuses needs no command.
May 23, 2009
General IT, ITIL
2 Comments
Sure, George liked sushi, but that was not why they called him “Gollum”. The reference to “Lord of the Rings” was not due to him having big eyes or a fair skin complexion either.
George was not the social type. A bona fide nerd, one of the best in his field. He knew the network by heart, the routers, switches and the relation between all the servers and infrastructure components. He was the heart of the IT department.
His acute lack of social skills had scared away any potential girlfriend. He was the typical troll on the Internet forums, a bully by keyboard and shy in real life.
Most of the users would avoid the Gollum, even when their PC was dead. They used a co-worker’s PC for a few days until she came back less snivelling from the cold. They worked from home or went to more meetings -until they had to give in and call 4400, the number to the IT department. The others in IT didn’t take the phone, they ware even more shy than George, or perhaps intimidated from him upbraiding them for every mistake they made.
So George would do the honour. He would aggressively grab it off the hook, anticipating another mindless stupid question and inquire in a less than friendly voice; “What?”. As a stuttering user tries to explain that the accounting program would not abide by her commands, George would go with his usual intimidating routine. Not because he truly believed he was above a mere user in intelligence or skills, although he was, but simply because this was his way of covering up his social insecurities.
He hated the users. He hated the business side of the equation. He hated stupid questions. He loved reading Dilbert.
Feared by users and co-workers alike but respected for always getting the job done. Nobody wanted George. They needed him.
One day when all hell was loose, the General Manager came down and with smoke and sulfur let loose a mixed barrage of demands, criticism, accusations and insults. George was trembling inside while looking his usual cool on the surface. This didn’t help as the GM wanted to impinge on him. He wanted a reaction. It became a traumatic event for the IT hero. Inside his head George noted all the criticisms and complaints which he later compiled into one long list.
Systematic as usual George went to town with this. The outpoints needed correction, the list needed to be closed. He gathered the forces of IT - all his co-workers were rallied. The penalty for not succeeding in impressing the GM: The outsourcing of the whole of IT and George & Co out on the street.
Time went. The General Manager was held at bay by promises of a structured and standards compliant IT department.
George had created the perfect structure catering for all the issues on the GM’s problem list. With 26 processes and 4 functions, George had created ITUL - The IT Universal Library. Elaborate flowcharts, excellent policies, Key Performance Indicators with the ultimate dashboard showing metrics in flashy graphs and bells and whistles. This was sure to impress any pointed haired boss.
The presentation outshone the Gollum and the GM was sufficiently confused to accept the elaborate structure.
George got what he wanted; A Service Desk as the single point of contact for all communication to IT. He would recruit a half-wit nice babe to take the calls. Enough of him enduring stupid user questions. He would be left alone.
And with the Service Level Agreements between IT and the Business, he could calmly point to that contract when friction arose.
With policies and processes left, right and center he didn’t have to take responsibility for anything but following the structure. And the GM had put his signature to it.
Ah, he was off the hook. IT was done with the human interaction. It had boiled down to structure and removed the intangible from the equation - stuff like compassion, inspiration, creativity and the human touch. It could now be programmed and treated like any computer. It was measurable, correctable and predictable. No surprises and a gradual increase in persistent results. Life was again calm.
The competitor, on the other hand made a quantum leap the next year by inspiring the best of their technicians to revolutionize how IT could enhance business opportunities. But that is another story entirely.
—–
In looking at this sequence of events, one may wonder if George actually got to the root cause of the General Manager’s frustration. If it wouldn’t have been better to bridge the gap in understanding between the Business side and the IT side. If he would have taken the responsibility to ensure that the General Manager gained enough knowledge of IT to better understand what powerful tool it can be in generating value for the company. And if George gained better understanding of the business, his own frustration may have been mellowed. Building a better understanding may have gotten the company much further than building a stringent
structure.
Attitude, inspiration, creativity and understanding is far superior to any structure, policy, process or tool. Because structure, policies and processes are just tools - to help the company innovate and create value.
The real value lies in the people. Let the people run the structure, not the other way around.
Quantum leaps come from creative genius. And the genius may not be all that obvious. Inspiring the hidden genius may be a key to quantum leaps.
June 11, 2008
General IT, Free Software, ITIL
No Comments
With the advent of ITIL, COBIT and other IT Governance frameworks, a comforting assurance in the field of IT is more real than ever. But is assurance really enough?
A Service Level Agreement is defined (wikipedia) as “An SLA is a formally negotiated agreement between two parties. It is a contract that exists between customers and their service provider, or between service providers. It records the common understanding about services, priorities, responsibilities, guarantee, and such?collectively, the level of service. For example, it may specify the levels of availability, serviceability, performance, operation, or other attributes of the service like billing and even penalties in the case of violation of the SLA.”
When an ISP delivers IT services to a customer, the customer is assured by the SLA given in the contract. The assurance is based on the customer’s trust in its vendor, its size, financial strength and history of the relationship as well as the actual contractual text. The penalties given to the customer in case of SLA violations is ordinarily covered by the ISP. The amount is usually low, amounting to fractions of the monthly bill.
An ISP is covering its base by making sure it is not liable for any damages caused by downtime, response times, service time or lack of adequate performance. These costs are instead covered, often without a conscious decision, by the customer. The penalties offered in an SLA are usually a small fraction of the actual cost of damages caused.
The tradition of insurance is sadly lacking in the field of IT. This may be attributed to the complexity of the technology. The great divide between business and technology is widening with the perceived complexity of systems involved. The attentive reader may have noticed the use of the word “perceived” in the preceding sentence. It was purposefully included as irony in case someone should miss the obvious reality that technology is vastly lacking in complexity compared to humans and the many fields of human interactions.
Perceived complexity may appear as a result of a desire on the part of the originator to protect his own position. By surrounding himself with a mystic complexity, the person may seem to enjoy reverence if not understanding from others. There are additional reasons for the great divide.
Complexities does not beget understanding or indeed assurance. It begets blind trust in those who apparently understands the intricacies. And insurance is harder to come by.
The great divide is furthered by the introduction of proprietary software. Here the user is barred from inspecting how the software really works. The so called “source code” is closed from inspection. It is not only practically impossible to see the software’s inner make-up, it is even illegal.
Compounded by an obscured security track, the path of proprietary software alienates possible insurance. Proprietary software has often used security by obscurity as a defence from cracking or data theft. Actual security is secure by design, not just by obscuring the security holes. By simply obscuring the flaws, there is no good way to make sure the secrets remain.
By opening up the source code, the software maker will have to address the security risks directly and handling them by design rather than obfuscation. The common objection to opening the source code is that the cracker will gain access to how the software works. In practice this potential risk is balanced by the need to factually address security. It also adds the benefit of possible insurance, a novelty in the field of IT. Insurance of IT is made possible only as the insurer is allowed to inspect the systems he is to insure.
Insurance of IT may very well be the next big market for insurance companies.