uGovernIT

A Practical Approach for IT Governance

Archive for August 2011

The Benefits of Networking on IT Governance

leave a comment »

For many of us CIOs, networking is a way to fight loneliness. I have long held the view that many a CIO finds loneliness in the position. Decisions have to be made, often with sparse data, and even inaccurate data. However, the accountability of the decision solely rests with the CIO. Networks provide a means to help make better decisions. You can classify networks based on open (most can join) or closed (there is a screening process and a select group of people are allowed to join). You can also classify them as on-line or in-person. These can overlap. For example Linkedin is on-line and can be open (I am not a CFO but I belong to the CFO network) or closed (CIO group by Gartner).

On-Line social networks such as Linkedin provide some opportunities to share and learn, and in-person executive networking events attract mostly people looking for greener pastures. A form of in-person network is CIO round tables which is a very structured network (meeting time, meeting place, and agenda are all well-defined). These structured networks are a great alternative to social networks, and provide significant benefits, but the one-on-one cannot be substituted. The old-fashioned approach of a quick phone call chat, a cup of coffee, a lunch or even an after-work drink provide far better value. An informal study of CIOs found that structured networks like CIO roundtables and one-on-one meetings were preferred by CIOs by more than 4 to 1 margin to less focused networks.

Written by Subbu Murthy

August 28, 2011 at 4:48 pm

A Practitioners Approach to Technology Management

leave a comment »

If you look at healthcare, broadly you have two groups: you have GPs (General Practitioners) and Specialists. In our field of technology, we broadly have three groups: BPs (Business Practitioners) – those who understand the business and translate them to technology needs; APs (Application Centric Practitioners) – who understand the core systems such as ERPs, Supply Chain, and other systems that deliver the technology to the business; and IPs (Infrastructure Centric Practitioners) – who understand the underlying infrastructure to run the applications securely and efficiently.

Of course, we can add other practitioner groups. For example, Specialists in healthcare are evolving – podiatrists were not very common a few decades back. The key difference between our field and healthcare is the rigor of training and certification. Although there are some generally accepted certifications PMBOK, CISA, etc., the rigor of credentialing that is prevalent in the healthcare is absent in our (IT industry). One can argue, with validity, that rigor can lead to cost escalations as we have seen in the healthcare sector. However, I strongly believe that rigor such as recertifying ourselves periodically is necessary to bring a modicum of discipline to a sector that is completely unstructured.

Just as there is a need to expand our horizons to understand the nature of the business we serve and understand the “culture” of the people we manage, I believe that there is a need to bring back the fundamentals of engineering into technology and how we manage technology.

Written by Subbu Murthy

August 20, 2011 at 9:36 am

Posted in IT Governance

Reducing Fixed Costs

leave a comment »

In the wake of the recent market turmoils, whether mandated from the boss or not, CIOs no doubt will be feeling the urge to cut costs. A simple and well established approach to cost reduction is reducing fixed costs. Take for example, project management. Initial project reviews, user-buy in, planning, resource allocation, project briefing, and de-briefing after the project is completed all have a “fixed cost” component to it. This process becomes very burdensome for small projects. Creating simple IT Governance mechanisms which are apt for the project category will be helpful to develop efficiencies.

These guidelines help in reducing the fixed costs associated with projects:

1. Develop a simplified project management methodology (PM-Lite).

2. Use simple workflows (automated workflows add more benefits) using a portal approach to oversee these “small projects”.

3. If you outsource these projects, use a set of pre-screened and pre-credentialed vendors who are specifically suited for delivering small projects. This is discussed in more detail in this blog.

4. Set limits on the number of deliverables (such as 5 to 7).

5. Keep the distance between each deliverable small (time and technical relationship).

6. Set simple success criteria such as 10% within each deliverable’s costs and schedule as green, between 10% and 25% as yellow, and more than 25% variance as red.

This simple guideline should not be construed as one shoe fits all. For example, risk management, compatibility with enterprise architecture, adherence to standards, and other project management principles also apply, but they should not become onerous and increase the fixed costs of a project.

Written by Subbu Murthy

August 8, 2011 at 8:52 am

Posted in IT Governance

The Role of Beta Testing

leave a comment »

A large majority of the Google applications stay in Beta Testing mode for a long time. The benefits are obvious: Beta Testing is an economical way to get user feedback, improve product quality, and equally important, gain user adoption. While the benefits are well understood, the costs are not so obvious. Too often product developers enter the Beta Testing mode with a product that is just not ready. I offer some guide lines in this monograph:

Rule 1: Never use Beta Testing to identify software bugs. It may happen, but great care must be undertaken to ensure that the product is rigorously tested, preferably by an independent group before embarking on Beta Testing.

Rule 2: Beta Testing should not be used to identify major functional gaps. These should be done systematically using focus groups of qualified users.

Rule 3: Beta Testing is not a substitute for Pilots. Organizations will still need to deploy the product (depending on complexity) incrementally, and Pilots are a good mechanism to adopt the product. This rule is particularly apt when the product inherently changes the underlying business process.

Used correctly, Beta Testing can be a powerful tool for improving product quality. On the other hand, when the rules identified above are blatantly violated, then the costs are dramatic. The company loses credibility and future products will be treated with apprehension.

Written by Subbu Murthy

August 6, 2011 at 1:16 pm