GovernIT

Out of all the major mistakes you can make when embarking on an IT Governance program, 3 stand out for their impact – complete failure of the program!

1. IT driving IT Governance

Business has to own and drive IT Governance. IT Governance is the business of governance of IT and hence business has to ensure that IT is aligned to the short and long term needs of the business. A simplified example of doing it wrong is when IT is asked to cut costs and and it cuts in places where long term strategic advantages are affected.

2. Thinking IT Governance is solved by a Process Framework or model

No single framework can work in establishing true IT Governance – as most models are focused on solving problems in one area of IT. COBIT is the most suitable framework for an overall Governance structure, but it only talks about the “what” – for the “how”, you will have to look at specific models for detailed guidance. ITIL for service management and CMMI for application development and maintenance are excellent choices (and industry standards!).

There are other areas, such as managing the portfolio of IT projects and their value to the business. There are no formal standards for such things and you might have to bring in reputed consultants to help you draft one for your organization.

3. Thinking that deploying a tool will give you IT Governance

There are a large number of organizations where improper deployments have become white elephants. Often, management confuses reporting with a working system – leading to deploying tools that can churn out good-looking reports and dashboards, but not really actionable information.

Tools can automate your processes and bring in consistency and effectiveness, but only after you have thought through the controls, defined processes and trained people.  

In short, full IT Governance is only for those who can stay the distance, investing time, effort and money. There are no quick-fix solutions here.

   Send article as PDF   

Much has been written and debated on Cloud Computing, but the verdict has still not been reached in the halls of Corporate IT.

CIO.com has a great series on what Cloud Computing means for the CIO (and IT departments) and surprisingly, makes a case against it; but only because it is not ready for large-scale deployment.

Currently, barriers against adoption of cloud computing are in the realms of technology accessibility and security. While the first can be worked out over time, security remains an essential element that needs to be balanced.

However, considering that cloud computing offers IT the opportunity to reduce costs through hardware and application consolidation, improved outsourcing capabilities, rapid deployment of new technologies, security may just become a footnote.

While public cloud computing services from Google, Microsoft (yes!), Amazon and other will continue to increase, these will primarily attract customers from the small and medium business segments, where IT is not a competitive advantage. Very large organizations may opt for private or hybrid clouds, simply out of fear of data integrity and privacy concerns. also, custom application development is not possible in the cloud computing scenario.

One scenario that remains to be played out is the use of proprietary software or open source software to drive the cloud. I suspect that over the long run, businesses may not care what is used, as long as it meets requirements consistently. For example, office software, email, instant messaging etc may be open source, while special software such as company applications will continue to remain proprietary. There may be other solutions that are available in the cloud, like salesforce.com, but the lack of customization options can be a deterrent to some.

In the end, the level of control available to the organization in using its data will determine if cloud computing is here to stay. If the cloud provider vanishes tomorrow, can I get the only copy of my data? If the cloud provider hosts my data in a country where privacy laws are biased towards the government, will there be any issues?

Technology has never been a barrier to adoption. Control and trust are the keywords which will decide if cloud computing is here to stay.

   Send article as PDF   

The Standish Group has released the famous CHAOS report(http://www.standishgroup.com/newsroom/chaos_2009.php), which talks about success and failure rates of software projects all over the world. This report is obviously based on a small sample of the total software projects executed all over the world, it is significant since it is almost the only report of its kind.

Compared to the earlier report, the number of projects that are successful has gone down (to 32%), while the number of cancelled projects has gone up. From my perspective, this is a good thing and a bad thing.

The bad thing being the drop in success rates, while the good things is that there seems to be increased monitoring of projects and cancelling them when it becomes clear that they will not deliver expected value.

However, respected researchers like Robert Glass(www.robertlglass.com) have questioned the research methodology and criteria used to collect and analyze the data.

I think that due to such questions, the Standish Group has quietly removed the Summary report (costing $99) and replaced it with a “CHAOS Manifesto” (costs $1000) that (hopefully!) provides in-depth information on the results of the research and the research methodology itself.

   Send article as PDF   

One of the most controversial elements among IT staff is the use of checklists to verify accurate completion of activities.

Most implementations of IT frameworks, particularly in application development and IT services, strongly advocate the use of checklists as the first record of verification and/or validation. The reasoning behind it is quite simple – verify if critical activities/items have been completed and the resultant output meets the requirements.

At the outset, people create a checklist to verify a long list of things to be checked, with the opinion that all of them are important! Over a period of time, “Process improvement” adds more items to the checklists, resulting in a checklist that takes more time to fill than the activity which it verifies. Result – no one uses it in spirit, defeating its very purpose.

A look at other industries shows a different trend though. Manufacturing, construction and even pilots routinely use checklists to ensure nothing of relevance is left out. Let us a take a detailed look at the Airline industry.

Pilots use a number of checklists, before, during and after takeoff  – sometimes using as many as 17 different checklists for each flight:

• Pre-flight checklists on safety, external inspections, cockpit inspections, before engine start, starting the engines, before taxiing, during taxiing
• Take Off checklists – before take-off, line-up, during take-off, after take-off, Climbing, Cruising
• Landing checklists – Descent, before landing, going around, after landing, shutdown, before leaving aircraft.

In addition, there are other checklists for abnormal conditions, such as emergency landings, loss of cabin pressure etc.

Two things differentiate checklists in other industries and checklists in IT – one, the target for applying is potentially infinite in IT and the items are not necessarily sequential.

Checklists in IT usually check for standards adherence and may have some questions to check for common mistakes. The problem with this is that standards have to be checked through the output and may occur hundreds of times, which may not be humanly possible.

The best way is to automate the standards verification process, through tools such as static analyzers, scripts to check authorized installations of software across the enterprise etc. Checklists must be used only for checking logical errors, common mistakes in applying principles and other areas, where automation may not be optimal.

Unfortunately, most IT Frameworks mandate organization-wide definition of standard checklists that become outdated quickly. Effectiveness can be improved exponentially by requiring that checklists be used by IT, but the contents of the checklists can be defined by the teams themselves. This is a COBIT-style approach, where control points are defined, but it is left to the teams themselves to define how they will pass the control point.

The Personal Software Process by Watts Humphrey (SEI CMU), for example, recommends that software developers create their own checklists based on their work style. For more information on PSP, visit the SEI website.

   Send article as PDF   

I recently read an article on IT measurement titled, “IT Metrics: Feast or Famine.” It is an interesting piece, emphasizing that metrics should exist for a reason and it makes sense to periodically check if that reason is itself still valid!

As a long time designer of measurement systems, I have a few observations on IT Metrics, which I share with you below.  Some of them are humorously written, but true nevertheless:

• A useful set of metrics cannot be defined in one go. It takes a minimum of n² iterations to arrive at a stable set of metrics, n being the number of stakeholders who will report the metrics
• Metrics that measure the positive side of a transaction are more easily accepted. For example, instead of the number of test failures, the number of tests passed stands a better chance of being accepted
• The reporting format is usually the most debated part of a framework. Since this is what everyone will finally see, there will be much angst on how the information is represented. In many cases, the success or failure of a measurement system is measured by the reporting framework
• A basket of metrics, with freedom for managers to select different metrics goes down better than a small set of core metrics that are inflexible
• Senior management always want comparison – between projects, projects in other departments and against industry standards (specifically in the same type of business). Without this “referential”, no metrics program will be accepted, even though everyone tells you to start small
• Someone will invariably ask for traffic light colors in your reporting, even though you stress a thousand times that no metric should be looked at in isolation
• Someone will invariably ask for a “Dashboard”, no matter the contents

   Send article as PDF