Skills Management

With IT being more knowledge centric and requiring an ever greater array of skill sets to get things done, one of the major challenges facing organizations today is the effective management of skills.

Now the skills can be brought on board in a number of ways. There is the option of acquiring In-House talent a.k.a. Full Time Employees. One could get Contractors (which is essentially the same thing nowadays). Consultants could be brought in as well. And then we have the ever present outsourcing option as well.

It is in the regular evaluation, analysis and relevant action in the area of employee/supplier skill set that the effective management of the organizations skills can be successfully undertaken. The ITIL body of knowledge refers to this as Supplier Management and outlines a strategy of classifying suppliers (which can be said to include employees as well) into long and short term suppliers as well as strategic or commodity suppliers. There are, of course, many different techniques and tools to perform the task of managing the skills and suppliers of the organization and these are readily available online. The focus of this post is to emphasize the need for these techniques and the warning to avoid the trap of forever being in fire-fighting mode and not ever getting to perform this important task.

There are many aspects to IT management. Some tasks are considered “essential” such as the successful completion of a critical project. Other tasks such as Skills Management are generally fall into the “we’ll get to them if we can” category. While the completion of the critical project will keep the lights on for tomorrow, it is the other tasks that distinguish a ordinary organization form a world class one.

Negativity Doesn't Help

Last year this blog site did quite well at the Computer Weekly IT blog awards for 2009. Out of a sense of curiosity, I went to the blog site of one of the other sites that had done well also to have a look at what they were up to. I was surprised and dismayed that this other site seemed to do nothing besides ridicule and put down ITIL and other methodologies. Now, of course if a scam of some sort exists and someone is spreading the word on that, they are doing the world a favor. However, to mindlessly put down something that has been designed to help seem seems quite pointless.

The interesting part of this for me is that ITIL is quite benign. You can do what you want with it. You can turn around and have nothing to do with it or you could partially implement some of it or you could go the whole hog and really implement all aspects of it to a rigorous level. The choice is up to you. So why blame ITIL? Why the negativity?

It would seem that people will do anything and everything except the right thing. There is no use in either being negative or attacking something that is there to help. Particularly if the choice is in your hands and you can use it or not as you please. My experience has been that any methodology works if implemented correctly and all methodologies fail if implemented incorrectly. So really it’s up to you.

Beyond Application Development

I come from an application development background myself. Moreover, I was involved in all aspects of app dev including Business Analysis, Programming, Quality Assurance and Project Management. It was only when I was first exposed to ITIL that I realized the tiny little well that I was a part of and the vastness of all the other parts of IT that existed that I had tuned myself out off.

SDLC, which, let us assume, for the sake of simplicity consists of the world of app dev is only a part of the going ons of an IT department. For those of us who have been involved in the SDLC most of our careers, there is a tendency to think only in terms of the application development lifecycle. However, the shift to understanding the entire IT infrastructure is important. There is currently a paradigm shift occurring in the IT industry globally where IT’s services to the business are being considered as opposed to the software IT produces only. The difference being that along with the application (or product) comes a host of related services. Consider a software application. The following will need to be considered once it has been released into operation:

• Support for users during operation including a help desk that will provide at least first line support.



• Continuous security management. This is particularly true for any sort of application that involves transfer of confidential data and financial information
  Capacity Management to ensure that the application can support the agreed upon number of users or load.



• Constant Availability Management checking to ensure that the application is performing as per specifications and to ensure quick follow up if it isn’t.
  Service Continuity Management to ensure that in the event of a disaster, the application can be brought back up as soon as possible.



• A continually evolving relationship with the customer to ensure alignment with customer needs and future needs.



• A strategy that encompasses customer demands and financial considerations to ensure that the correct portfolio of services and applications is chosen, developed, delivered to the customer, operated and finally retired at the appropriate time.



• A set of supporting processes that assist in providing the above services to the customer.

All this and more must be performed to ensure overall customer satisfaction over and above the development and testing of the software. The de facto standard for the services described above is ITIL. It is a large body of knowledge that most professionals will need to spend a significant amount of time and financial investment to master. It is recommended that most people get started immediately if not sooner.

IT Investments

For all the flak, the Government usually takes for being bureaucratic and slow and inefficient, in the world of IT, the Governments of the western worlds in particular are doing well to adopt a lot of sensible policies and procedures to help increase efficiency. In fact, the US Dept of the Interior’s Information Technology Capital Planning and Investment Control Guide (CPIC) is one of the best investment frameworks out there for IT investments.

It actually all started with the GPRA (Government Performance and Results Act) which mandated that all federal agencies had to be results–oriented. This included defining general goals and objectives for their programs, to develop Annual Performance Plans specifying measurable performance goals for all their programs and to publish an Annual Performance Report showing actual results compared to the projected goals for each program. As a result of this, the Government’s Office of the Chief Information Officer came up with the CPIC guide to govern and manage the IT investments for the Government and to align all IT investments to the to the strategic goals of the Department.

The CPIC process consists of circular flow of 6 phases:

• Pre-Select Phase: In this phase, the business recommends IT services based on their requirements. A concept is created and a Business Case for the new IT service is developed, evaluated and approved. Based on these actions a final approval to move forward will then be obtained from the relevant stakeholder.



• Select Phase: In this phase, a project plan is created with established performance goals and quantifiable performance measures. Costs, schedules, benefits and risks are identified and evaluated. With the completion of all steps in this phase, approval is obtained to proceed to the next phase.



• Control Phase: The goal of the Control phase is to ensure that through timely oversight, quality control, and executive review, the IT initiatives are conducted in a disciplined, well-managed, and consistent manner. It is in this phase that the project is moved from the requirements definition to implementation. The project management occurs here with the project progress being monitored, reported and evaluated with course correction taken as needed. This phase is considered complete when the production deployment or implementation is completed.



• Evaluate Phase: In this phase, the actual results after implementation are compared to the projected results and any changes or modifications needed are implemented. A Post Implementation Review (PIR) is conducted in this phase and based on the results corrective action is taken. Once this is completed, the next phase is entered.



• Steady-State Phase: During this phase, analysis is used to determine whether mature systems are continuing to support mission and business requirements. Customer satisfaction is evaluated and opportunities to improve performance and reduce costs are considered. The investment stays in this phase until a determination is made by the appropriate stakeholders to modify, replace, or retire the system. A major enhancement can be defined as, new architecture, or new functionality. The cycle then begins again at the Pre-Select Phase.

The CPIC fits in nicely with ITIL and its Service Strategy Phase. It also fits in well with ITIL’s consideration of IT Services as a portfolio of services which CPIC does as well. The interested reader can easily obtain more information on this and other Investment management frameworks. The question isn’t which one to choose but how well are we implementing and evaluating the one we have chosen. If IT investments are not being performed under a proper investment management process but rather by some sort of emotional, ad-hoc fashion by top executives, then return on investments is going to be low – guaranteed.

The IT Business Gap

Probably the most common phrase heard nowadays is “IT / Business Alignment”. There is also a great deal of information, techniques, methodologies and consultants (myself included) that offer ways and means of making such alignment possible. However, how does one go about it at a basic high level?
One model that comes to mind (and there are various models that exist) is the IT-Business Alignment Cycle which basically consists of 4 stages:

• Plan: The requisite first step in any model, the planning of what IT must provide to the business must be performed first. This involves understanding Business’s needs and the plan for designing and delivering IT solutions that satisfy these needs. A high level of communication should be formulated and maintained between Business and IT for this to be successful on an ongoing basis. The ITIL processes within the domain of Service Strategy are effective in meeting the needs of the planning stage.



• Model: This involves the execution of the Plan conceived earlier to the extent that the required IT services are designed and released to the Business’s live environment successfully. The ability to track CI’s via a well defined Configuration Management is crucial. Moreover, the ability to provide for the IT service’s Availability, Capacity, Security and Continuity should also be handled utilizing the corresponding processes.



• Manage: This involves the successful operation of the IT service being provided to the Business on a day-to-day basis. For this to be successfully accomplished, the IT department must have effective Incident and Problem Management processes in place with a capable Help Desk function in place at the minimum. Effective Change and Release Management processes are also very important. The ability to track and monitor promised service levels is also a necessity in this stage.



• Measure: If you can’t measure it you can’t manage it. This stage actually applies all across the organization and incorporates itself with the previous three stages. The basic premise here is to verify via metrics that the promised services were delivered and managed successfully. This can and should incorporate measuring at levels that are not visible to business at the component level. Measuring IT performance at a functional silo level is also beneficial in order to measure and improve IT functional capability. Continual improvements are a key goal of accumulating and analyzing the metrics in any organization.

A constant iteration of these stages should provide a basic framework for keeping IT and Business successfully aligned. Of course far more information is available on this topic and the reader is encouraged to springboard off of this post and delve deeper into this extremely crucial and significant topic.

The Art of Release

As customers expect modifications to services to be made more and more quickly, the ability to actually make these modifications successfully becomes more and more crucial. Now, a lot of processes and capabilities need to be in place for this to happen, but it is in Release Management that the actual update to the live environment happens. Therefore, Release Management is a member of that special clique of processes that actually have a direct contact with the customer.

Release Management is thought of in many organizations as scheduling and simply making the update in the live environment. However, this is more of a departmental oriented organization’s view of the process. In a process oriented organization, the Release Management process covers the tasks of building, testing and releasing to the live environment. These tasks are carried out using resources and staff from functions (departments) like Development, QA etc. Release Management interfaces significantly with the Change and Configuration Management processes in order to communicate the change information back and forth as needed. The Release Management process also takes ownership of a central location of storage of the master software and hardware spares. This is formally known as the Definitive Software Library (DSL) and the Definitive Hardware Store. The DSL need not be a physical location but could be a database where final builds are stored. This should not be confused with a day-to-day version control tool. The DSL is an important way of ensuring that the latest builds are kept separate and there are no confusions during release implementation. Licenses are also stored in the DSL making it a useful tool in maintaining legal compliance and identifying and locating unused licenses which are a complete waste to the organization.

Details of the Release Management process are freely available on the net. My goal here is to highlight its usefulness and benefits. The benefits include:

• fewer disruptions in the live environment due to changes


• standardization of hardware and software versions


• better management of risks involved in releases including the implementation of a rollback plan


• legal compliance with licensing


• better utilization of licenses

It is, therefore, in the organization’s best interest that Release Management is taken as seriously as possible and steps taken to implement it systematically and rigorously. In today’s competitive world, every little bit makes a difference.

Supply Stability

Supplier management in the past was usually handled by the departmental secretary who chose which corner shop to buy the paper clips and pads from. Advanced version of this function also included choosing the best take-out joint for lunch or snacks. Nowadays, however, supplier management is a major process that is becoming more and more crucial in an organization’s ability to function efficiently and remain competitive due to the increasing complexity of inter-dependency between organizations.

The products or services that are being supplied by the supplying organization are numerous and complex. Consulting, material, equipment, information, knowledge and people are a few examples of resources and capabilities that are exchanged between organizations. While products need to be monitored for quality, price, delivery punctuality etc., the more intangible resources such as consulting and knowledge require further specialized skills in the management of its suppliers and delivery.
Suppliers can be broken down into the following categories by importance:

• Strategic Suppliers: Where goods and services are hard to obtain and require adequate stockpiling for safety. The goods and services being supplied are crucial to the operation of the organization.


• Tactical Suppliers: Less difficulty in obtaining goods and services. The items are not as crucial to the successful workings of the organization.


• Operational Suppliers: Goods and services are relatively easy to obtain and there are alternatives to choose from. The items are not so crucial to the running of the organization.


• Commodity Suppliers: Goods and services are easy to obtain and there are many supplying organizations to choose from. The items being supplied are not crucial to the opration of the organization.

Supplier Management is the process that ensures that external services and configuration items, which are necessary for the service delivery, are available as requested and as agreed at the service level. Some of the responsibilities of this process are:

• To ensure that the supplies are made as per the pre-defined requirements and service levels.


• To ensure that every supply runs through a set of standardized steps and procedures in order to ensure repeatable and predictable results every time.


• To manage the risk to normal service operation due to lower control levels and accessibility inherent in using external suppliers. This involves the periodic assessment and testing of supply quality and service levels provided with the supplying organization.


• To document analyze and review every supply decision and activity.

The best way to handle all this is to implement a well defined and formal Supplier Management process complete with a Supplier and Contracts database and Supplier Manager. The basic sub processes within the Supplier Management process are:

• Supplier Request Recording


• Supplier Selection


• Supplier Evaluation


• Supplier Negotiation


• Supplier Service Delivery


• Supplier Renewal /Termination

The proper execution of these sub processes will ensure the smooth and efficient function of the Supply chain. The act of receiving supplies from another organization is, therefore, seen to be an important one and should be given the importance and respect it deserves by proper planning and execution of a formal process for it.

The Rain in Spain

When Dr. Higgins attempts to improve Eliza Doolittle’s speech in My Fair Lady, he starts with the basics: practicing speaking with marbles in her mouth, repeating basic sounds and words, the most famous being “the rain in Spain is mainly in the plain”. The parallels with an organization seeking to improve its processes are similar in that the basics must be mastered first before one can be the belle of the embassy ball.

What are some of the basics that an organization can put into place while attempting to improve? Some choices are:

Strategy: Easily the most neglected area of organizations worldwide and IT organizations in particular, certain basic techniques of Strategy should be implemented. While full blown strategy methodologies might be a bit much for the beginning effort towards improvement, fundamental techniques of demand analysis, financial management and portfolio management should be implemented.

Customer Point of Contact for Negotiation: While organizations do have this in place in some fashion, it is rarely enacted formally enough to bring its true value and benefits to the table. ITIL’s Service Level Management process is a well defined methodology for achieving this objective. The ability to not merely interact and form a point of contact with the customer but to build a relationship and understand their needs allows for superior alignment of IT with customer’s requirements. This effort returns rich rewards and is definitely much value for money.

Change & Configuration Management: Again implemented by most organizations but not adequately. A good first step for organizations committed to improvement would be to evaluate what they have in place and tighten up and further align with what users require. At an organization that I consulted for in the past, they had a home grown Change/Configuration management tool that had fields and options that users did not need or use and did not have needed fields and options. Clearly they could have benefitted immensely with a properly thought out tool that fitted with their needs better.

Service Desk, Incident and Problem Management: Another set of those processes that most organizations do have in place but could desperately use an overhaul and update of. Common service desk shortcomings are lack of current information made available to service desk personnel, increasing call volumes and increasing and more complex changes to the service. Incident and Problem management also suffer from lack of communication from change and configuration management typically.

Continuous improvement: While there may not exist an organizational maturity to reach six sigma levels at the present, certain basic improvement techniques can certainly be implemented. A basic technique of Root Cause Analysis and resolution to prevent similar mishaps occurring in the future is easy and requires minimal investment. Therefore, there is no reason to not implement a RCA system of continuous improvement, no matter how limited resources are available in the organization.

It is often argued that times are too challenging or resources not available to implement process improvements by those not enthusiastic about improvements. However, there are small and simple steps that can be carried out that yield rich returns for the effort expended. It is possible to get started without a great deal of investment and disruption. With the improvement and stability gained with these initial steps, further and more complex process improvement endeavors can then be undertaken. Even if an organization is dedicated to a large scale process improvement effort, the basics must first be completed successfully. Remember, the rain in Spain is mainly in the plain.

The Need for Strategy

In a study, it was determined that the area of strategy within IT organizations and for that matter even non-IT organizations) is the most undeveloped and under-utilized with the greatest scope of improvement and realizing benefits. I have certainly found this to be true in my own career and dealings with various organizations.

The word strategy instantly brings to mind the concept of long-term planning. A highly reactive response to solving a customer’s immediate problem as quickly as possible is not a strategic activity. However, deciding what new products and service to introduce 3 years down the line is an example of strategic activity. What I have noticed too often in the past is that organizations get into a constant state of firefighting and reactive problem solving which results in adequate strategy never being realized. It is up to management to ensure that sufficient resources are dedicated to strategic activities and kept free of the day to day firefighting tasks.

Strategy is important because it provides the initial roadmap or path to the organizations long term goals and objectives. A wrong decision taken in the initial plan can have disastrous consequences in the long term. Furthermore, possible risks and downturns need to be evaluated and accounted for in the future planning. Over and above all this, the strategy team should evaluate the current products and services and the customer’s happiness with respect to them and make course corrections based on this as necessary. Therefore, it is apparent that the strategy step is crucially important and should not be neglected.

So now that we are convinced of the importance of strategy, how do we go about strategizing? The different areas of strategy, in my opinion, can be broken down to three main components. Understanding of your organization (which includes current products and services, resources and capabilities etc.), understanding the customer (demand patterns, market conditions etc.) and financial information (including Budgeting, Accounting and Charging). These are found in the ITIL body of knowledge as the Portfolio Management, Demand Management and financial Management processes within the Service Strategy Module.

Therefore, with the information needed to adopt strategy for IT services being readily available, there is really no excuse for the implementation of poor strategy. All the greatest generals in history, considered strategy the most important part of their military campaign, beyond even the number and strength of their armies and the technological sophistication of the weapons being used. Indeed, Napoleon Bonaparte won numerous battles simply because of his superior strategic planning. In the battlefield of business, the implementation of correct strategy will ensure economic victory.

IT Information Systems

It is important that IT organizations design and maintain adequate information systems to facilitate the flow of information necessary to achieve their goals. There exist certain guidelines for these information systems within the ITIL body of knowledge.

The overall information database that houses all the others is called the Service Knowledge Management System (SKMS). All the information systems mentioned below as well as any other custom systems are housed within this system. Some of the recommended information systems are:

The Configuration Management System (CMS) which contains the details of the Configuration Items that exist within the organization and their relationships with each other. This system is within the purview of the Configuration Management Process and the Configuration Manager.

The Service Desk System which contains logs of all service requests and customer incidents. This is managed by the Service Desk function and the Service desk manager.

The Capacity Management Information System (CMIS) which contains details of the capacity requirements for the business, service and components. The existing capacity specifications for the systems in place and the Capacity Plan for all the services also exist in the CMIS. This is managed by the Capacity Management process and the Capacity Manager.

The Availability Management Information System (AMIS) which contains details of the availability requirements at both the service and component level. The existing availability specifications and the availability plan for all the services also exist in the AMIS. This system is managed by the Availability Management process and the Availability Manager.

The Security Management Information System (SMIS) which contains the Security Policy for the organization and the various details of the security system in place. This system is managed by the Security Management Process and the Security Manager.

The Supplier and Contracts Database which contains information pertaining to the supplier and contractors of the organization. This system is maintained by the Supplier Management Process and the Supplier Manager.

These are the primary Information Systems that ITIL recommends that It organizations maintain. Of course, there could be other specific to the company systems as well that are beneficial if created and maintained by the organization.

The inter-communication between these systems is also crucial in making the whole communication flow work and must be undertaken by care by the organization. However, if implemented correctly these information systems provide a useful framework for communication and document control within the IT organization.

Excess Capacity

The characteristic feature about IT that makes it different from other types of industries is that there is very little potential for storing or maintaining an inventory of the services being provided. In manufacturing, for example, the manufactured product can be stored in a warehouse and sold later. However, in IT that is usually not possible. Of course, in the case of a manufactured application like say Windows Vista, the boxes of Vista could be stored in a warehouse but due to the short lifespan of software products, this could only be done for so long before the app is obsolete and incapable of being sold. Furthermore, as the software apps can’t be recycled (like steel pipes for example) the stored quantities that aren’t sold are a complete loss. And in the case of non-product services the resources (people, tools, apps, computers) are simply sitting idle if not used to full capacity. The loss in this case is instantaneous and unrecoverable.

Now a certain amount of buffer capacity is necessary so that in the event of some problem or spike in customer requirements, things are still under control and manageable. However, a disturbing trend that I have seen very often is that a lot of capacity is kept as a buffer to compensate for poor management of IT. The efficient and consequently competitive and profitable IT organizations manage their capacity so that they are only taking on the amount of resources and capabilities that deliver value and no more. How can this be accomplished?

To fine tune the resources so that just what is needed is being delivered requires a number of factors to be in place. The first and most important is the correct analysis and understanding of customer demand cycles. This is where the demand management process is of great value.

An ongoing formal relationship with the customer utilizing Service Level Management is also crucial to establish the correct point of contact with the customer in order to fully understand requirements and to implement continuous improvement measures.
Financial management is important in keeping track of the expenses with respect to the planned budget. This monetary bookkeeping can greatly assist with keeping track of customer demand patterns.

At the center of it all, of course, is the capacity management process which plans for and monitors service capacity. However, this process cannot function adequately without correct inputs from the aforementioned processes and other sources.

It is possible to fine-tune and optimize capacity delivery to the customer but only after a proper planned effort is made with other processes in place that provide the relevant information. Organizations seeking to be competitive must make the effort to optimize their delivery or else they will be overtaken by competitors that make this effort.

Product and Service

An observation from being an ITIL teacher is that a common challenge people learning ITIL face is the ability to differentiate between a product and a service. Typically these are folks from a software development and QA background and can only see the world through the actions taken to develop the application.

Let us consider a situation where the IT department develops and releases an application to the business. Now it is easy to consider that the application itself is all that is being provided to the customer. However, the application must also typically be maintained and supported for the customer. The factors involved in this are:

• help desk support


• incident and problem management


• regular contact with the customer


• evaluation and analysis of changes needed by the customer


• making the changes


• releasing the changed application to the live environment

Furthermore, proactive monitoring of availability, capacity, security and disaster recovery must also be performed to ensure that the agreed upon uptime of the application is maintained.

All these actions together provide the overall service for the application to the customer. The application as a product itself delivered to the customer is one thing. But the application functioning as it should at the agreed upon levels for the agreed upon period of time is quite another thing.

Therefore, we see the reason for processes like availability management, capacity management etc. Simply having a department of programmers is not enough as IT now requires the ability to handle all aspects of service provision to the customer. IT departments must evaluate the processes that are required for them to provide service to the customer and then set up and manage these processes within their department. Even programmers should at least be aware of the service aspects of the application being programmed by them.

Connecting with the customer

There are typically two situations when connection of an IT department with the customer at a significant level occurs. One when initial requirements are being threshed out and the other when there is a problem or issue that needs resolution. Organizations nowadays are relatively mature in their handling of the second situation where issues and problems are reported and resolved. This has been mostly due to implementation of incident handling and help desk processes and advents in help desk tools and applications. However, the interaction with customers during requirements is usually not handled very well. Furthermore, a more proactive approach to customer management is largely missing in most organizations.

The ITIL body of knowledge provides the Service Level Management process for exactly this purpose. The SLM process, which exists in the Design stage of the ITIL lifecycle, essentially performs two main functions:

• To determine the level of IT service needed by the business (customer) and


• To identify whether the required services are being met or not and if not, why not?

By the successful performance of these two functions, SLM helps to maintain and improve the IT service provided to the business. But more significantly, the SLM process and the Service Level Manager (the SLM process owner) create and maintain a relationship with the customer. It is through relationships that the ability to truly satisfy and even delight the customer can be achieved. The reason for this is that it is rare for the customer to truly understand what they want in technical terms. Therefore, they do not put down in a detailed requirement specifications document all aspects of what they want. The IT staff members following the spec document then faithfully produce a product or service that does not truly delight the customer but meets specifications. To truly understand the unstated and unspecified needs and desires of the customer, a relationship must them be established and maintained by the IT organization. That way, the customer can be guided into including, in a spec document, what they really want but are unable to put down specifically.

The service level manager, therefore, should have both technical skills and relationship skills which include communication and negotiation skills. The service level manager should also be able to act as an emissary for both sides, the customer as well as the IT service provider.

The SLM process consists of the following high-level steps:

• Cataloguing the services


• Implement Service Level Agreements


• Monitoring, reporting and review of actual service levels


• Review of Service Performance and adherence to SLAs


• Implementation of service improvements as needed

Of course each of these steps has several steps of their own and relevant inputs and outputs. However, it is by following these steps that an IT organization can ensure proper customer service in a proactive fashion.

The old style of informal and unregulated contact and interaction with the customer is no longer the appropriate method of carrying out business. Every IT department should have a formal point of contact with the customer(s) and a proactive process of ensuring service quality and constant improvement. There is no way of avoiding or bypassing this requirement any longer.

Communication Conundrums

Perhaps the greatest challenge and the main cause of issues and problems in IT (or anywhere else for that matter) is lack of effective communication. This is paradoxical as on first thought, the advance in technology and mobile devices nowadays should actually enhance communication. However, we see that in spite of the high tech capabilities to communicate being available, we still run into many “he didn’t tell me” or “ I was never informed about such and such” scenarios. Why is this?

In my opinion, the primary cause for poor communication is a lack of emphasis on this area by senior management. Communication must be deeply embedded in the very fabric of the organizations architecture and the ones to drive this through are the top management. Communication must be encouraged and rewarded, while a “shoot the messenger of bad news” predilection strictly discouraged.

Therefore, achieving successful communication can be divided into two parts: setting up the infrastructure for great communication technically and setting up the environment for communication “mentally” or “psychologically”.

The first part is relatively easy, as there exists an abundance of technology, applications and devices that create the infrastructure for effective communications. A great deal of information on this topic exists on the net and it is beyond the scope of this blog post to go into it in great detail. Furthermore, it is the other part of the problem, the psychological one that I feel deserves greater attention.

I have yet to meet a senior executive who did not believe in communication and publicly acknowledged the importance of it and yet most organizations that I have interacted with suffer from poor communication. Furthermore, these were organizations that had the latest infrastructure, applications and setup to communicate effectively and yet were facing significant shortcomings in their exchange of information, which in turn led to ineffective performance and low quality products and services delivered to the customer. The answer was that although the environment for effective communication was created technically and logistically, it was not created mentally or psychologically in the staff members minds.

Some significant barriers to effective communication in an organization are:

• A change in predisposition required to communicate effectively. Most IT staff members are not used to efficient communication and have to make a shift in their habits to become proficient in this capability.


• The formation of tribes or silos that have poor communication outside of their structure. This is something we have all seen and experienced. The QA department, for example, may deal well with each other internally but are in poor communication with the requirements group or the development group.


• Too much information. If staff members are overwhelmed by too much information, then it becomes difficult to separate the wheat from the chaff and important information can get missed or ignored.


• Lack of standardized terminology within the organization. I have personally experienced test cases being described using three different names at an organization I worked at in the past. Needless to say, the testing was extremely poor and out of control there. This is where standardized methodologies like ITIL and Six Sigma can assist in bringing a standardized terminology throughout the organization.


• Control issues & political games. Certain staff members might wish to deliberately avoid the circulation of information for their personal gains. Tactics of scapegoating, blaming, silence and exclusion are typically utilized here to achieve the control goals by people. It is imperative that management discourage this type of self-centered behavior and set a high standard themselves.

With each of these problems, management can play a crucial role in providing a solution by discouraging negative behaviors and setting themselves up as a role model of positive conduct. Especially important is the avoidance of “shooting the messenger syndrome” by management. Of course, over and above management guidance, the organization needs to foster an environment of easy and efficient communication by incorporating a planned communication strategy. The PMI body of knowledge offers the following communication management processes:

• Communications Planning – determining the information and communication needs of project stakeholders


• Information Distribution – making needed information available to project stakeholders in a timely fashion


• Performance Reporting – collecting and distributing performance information. This includes status reporting, progress measurement and forecasting


• Manage Stakeholders – managing communications to satisfy the requirements of and resolve issues with project stakeholders

Each of these processes is outlined in greater detail in the PMI Body of Knowledge publication and can be modified to suit the organizations individual needs. Clearly, the tools and techniques are available. What seems to be lacking is the determination by all concerned to make it successful.

Communications is the lifeblood of IT and just as a body with poor circulation will be host to disease and degeneration, so will an organization suffer from an array of problems and inefficiencies if communication is not managed and cultivated properly. It is the organizations own interest that the implementation of world class communication practices is given high priority and attention.

Portfolio Management

The products and services that an organization offers to its customers have a life span encompassing conception, development, introduction, growth, maturity, decline and termination as shown in the figure below.

It is up to the business to analyze the market conditions and customer needs and determine when a product or service should be introduced and what the functionality and specifications of the product or service should be. Business, also determines when the product or service has run its course and should be retired from the active pipeline. IT, too should view its connection to the business as a set of services that it provides to its customer (the business).

IT at a fundamental level is a set of services utilized by the business, typically applications and infrastructure provided by either internal IT departments or external service providers. Organizations are now less focused on IT infrastructure and applications than on coupling the infrastructure and applications internally to automate end-to-end business services and to manage them the business services efficiently. The challenge here is the successful matchup of business needs with IT infrastructure. Service Portfolio Management is the process that at the strategic level ensures that IT provides the business with what the business needs presently and will need in the future. The steps involved in achieving this Service Portfolio Management are:

• Define: what IT services exist and what would be needed in the future


• Analyze: based on company’s goals and objectives as well as finances available


• Approve: formal decision of stakeholders on what course to take


• Charter: officially begin the action that has been decided on whether, to create a new service, refresh an existing service or to retire an obsolete service

The point here is that it is not just the business services that are being defined, analyzed, approved and chartered but the relevant IT services that are needed to make the business services work. Companies must now think in terms of IT as a set of services to the business and not just a group of applications and infrastructure. The apps and infrastructure make up the IT service which then supports the business service. The business service makes the sale which brings in the cash.

Therefore, it is important that IT services are planned for simultaneously as business services being planned and implemented with appropriate communication between business and IT. For example, in the Steel Pipe company example in a previous post, the business portfolio would consist of steel pipe 2 feet long, 4 feet long and six feet long. However, the IT services would include email services, laptop and desktop services, networking and internet services, CRM services and programming services of the heavy machines utilized in manufacturing the pipes. If the company was attempting as part of its business to add a new range of steel products to its business portfolio, the IT department of this company should understand what modifications it would need to make to the IT services being offered to the business. If this new business required IT to now develop its own applications as opposed to purchasing off the shelf applications, IT services would have to add Application development and testing to its “menu” of services. This would logistically entail hiring staff and purchasing desktops and servers and operating systems etc. However, looking at IT as a service to the business, we now have a new service that needs to be setup by IT. Clearly, the earlier IT sets about setting this new service up the better for the organization.

Very often IT is not involved in the analysis of how the services it offers to the business should be modified until far too late. It is a sign of high organizational maturity when the alignment between business and IT occurs at the strategic planning stage and not later on in the game. This then leads to a smoother delivery of the required services with fewer defects and less chaos and inefficiency as things have been planned early on and not at the last minute. Less problems, better service and higher employee morale are the result. All of this makes Portfolio Management a necessary process for any IT organization.

Pick and choose

It is easy to get overwhelmed by the extensive array of process techniques that exist nowadays. Just for starters, we have ITIL, COBIT, and CMMI for general overall process and governance. Then, there also exist SDLC, RUP, Agile, Lean etc. We have PMI and PRINCE2 for Project Management. For quality, there exists QAI’s CSTE certification and Six Sigma for continuous improvement. Also, Function Point Analysis and Balanced Scorecards with a plethora of choices exist for metrics. This, by no means is a complete list, but just a few examples to give you an idea.

For an industry that has historically been in chaos due to a lack of set standards, a lot of process choices are now making the rounds. However, this newly available variety coupled with a lack of awareness and understanding seems to cause more problems and a general desire to shy away from process implementation for most people and organizations. Personally speaking, it is only after a great deal of studying lots of different process standards and gaining practical experience in the application of these techniques that I felt prepared to start consulting and post a related blog. For those who have not devoted the effort to adequately train themselves in the area of IT processes, a degree of confusion and frustration will naturally exist. However, it is too often that someone not fully knowledgeable on processes finds themselves in the position of making process decisions for an organization. What inevitably follows is a desire to “play it safe” masked by vague generic comments cloaked with several acronyms that are the current “hot” buzzwords. The “cubicle dwellers” and “naysayers” are only too happy to curtail the process improvement by causing roadblocks every step of the way. No wonder then that most process improvement initiatives die out faster than a speeding bullet and are as successful as the recent financial bailouts have been in restoring the economy.

The first step is to understand the industry that your organization is in, its customers and the products and services being offered to them. This analysis will then provide information on the levels of quality, availability, security, reliability, continuity etc. of the product or service expected by the customer. For example, “high quality requirement” industries like airlines and biomedical (where lives are at stake) would absolutely mandate a Six Sigma initiative as opposed to a typical web design setup where quality, although important (and not to be neglected) does not have the same life threatening impact.

An understanding of the capabilities of the resources available (people, finances and tools) is also necessary. For example, you may wish to implement Six Sigma, but if your staff don’t know the first thing about Six Sigma, then it will be some time (not to mention effort and money) before you can get a Six Sigma initiative in place. Furthermore, if the staff are used to a certain way of doing things then it will require some effort to get a new way of thinking in place. A transition between processes can create new defects that could be passed on to the customer making the aforementioned transition a tricky proposition requiring careful planning and forethought. A certain amount of realism is always necessary when planning anything and IT process improvement is no exception.

With all these factors understood, a realistic choice of process techniques and timetable for implementation can be decided on as opposed to going with a certain process because the CTO happens to be familiar with that process and nothing else (which is too often the case). Most process professionals get stuck with some “pet” technique of theirs that they have some background and knowledge in. They even develop a fanatical obsession with their pet process, blindly disregarding any other possibilities. This is short sighted and self-defeating. Remember, it is the flexible tree that survives the strong winds, not the rigid and unyielding one. What might come as a revelation to some is that processes standards can be “mixed and matched” to suit the organization’s needs. For example, ITIL could be used as an overall process approach with Six Sigma techniques being used for continual improvement. A sample combination of IT processes that I think work quite well synergistically and would serve most organizations capably are:

• ITIL as an overall process technique “umbrella”


• Six Sigma for continual improvement which fits in very well with ITIL


• PMI Project Management techniques for project management


• IIBA’s (International Institute of Business Analysis) for industry standard business analysis guidance


• SOA (Service Oriented Architecture) and Object Oriented Design and development techniques (if producing software)


• QAI’s (Quality Assurance Institute) quality and testing techniques for verification and validation


• COBIT (Control Objectives for Information and related Technology) for governance and SOX compliance (if needed) which fits in very well with ITIL


• Function Point Analysis (if producing software) and Balanced Scorecards which again fit in very well with ITIL and its Key Process Indicators (KPIs)

While at first glance, this list might seem overwhelming for an organization to put together, what must be understood is that all aspects of all these techniques need not be implemented at first pass. Simply what makes sense and provides “the most bang for the buck” within each of these techniques should be identified and executed. And this is where the artistry comes in. Only a professional who has studied these techniques and has experience in their implementation will be able to combine the specific aspects of these tactics to the particular situation at hand. Unfortunately these species of professionals are rare, indeed.

It is also recommended that process improvement activities be carried out iteratively. Too often, organizations attempt to implement everything in one go (Big Bang) with unrealistic goals, timelines and resources. This, then inevitably results in a great deal of chaos and confusion with the naysayers nodding their heads sagely, stating “we told you so; all this newfangled process stuff is just a fad and doesn’t work”. Things then quickly return to the status quo with the organization in an even worse situation than before having expended a great deal of time and resources for nothing. It is important that organizations implement process improvement continuously in iterations, picking and choosing where they can get the most benefit for their particular situation.

It is, therefore, recommended that organizations implement improvements in a recurring phased approach that targets the most attractive benefits to their specific circumstances from a variety of industry standard process definitions.

Benefits for all

IT Process Improvement is a sadly neglected element of most every organization. A common misconception is that only hard-core IT companies need bother with enhancing their IT processes. The truth of the matter is that in today’s age of increasing dependence by the business on technology, the optimization of IT is crucial for any organization in any industry and not just a Microsoft or IBM or Wipro.

A common misconception is that IT process improvement is limited to the IT department only with no interaction with the other departments of the organization. The belief is that adjustments to the SDLC methodology (or RUP or whatever the IT dept uses) is the only domain of IT process improvement. While this is definitely an area that the IT process expert would apply his or her energies to, improving and aligning the IT department’s services to the rest of the organization is also part of their task. In fact it is the fundamental task from a revenue generation point of view.

Let us for a moment consider a company that produces steel rods. No fancy software being produced. No high tech outsourcing – just steel rods, three feet in length, being produced. Let us consider some of the departments within this organization as shown in the figure below:


Now let us consider some of the interactions taking place. The various departments will require communication with each other as well as interaction with outside stakeholders such as customers, suppliers and contractors. In today’s day and age, a well structured network and email will take care of basic communication needs. This network and email setup will need to be deployed and maintained. Over and above this, a comprehensive ERP and CRM application will be needed to manage the resources, activities and information within departments and external organizations. The proper selection, deployment and maintenance of this application will then need to be performed. Furthermore, the machinery used in the production of the pipes will have their own software application written in a proprietary CAD language which will then require skilled personnel to maintain and operate the machinery and the related software. There may be custom applications that have to be designed, developed, deployed and maintained.

While we can go on and on, what already emerges is that a great deal of Information Technology (defined last week as the use of computers and software to convert, store, protect, process, transmit and retrieve data within an organization) will need to be applied and attended to.

Now let us consider two competing steel pipe companies. They both obtain the same raw materials at the same cost. The number and quality of the personnel employed by the two companies is about the same as is their size and infrastructure. Company A takes its IT processes seriously and is constantly seeking to improve and evolve them, whereas, Company B is lackadaisical about its IT claiming “we don’t need to worry about all that tech gobbledygook – we make steel pipes for heaven’s sake!”

Company A utilizing effective Change Management, Configuration Management, Capacity Management, Service Level Management, Supplier Management, Service Continuity Management, Availability Management etc. and implementing improvement initiatives like Six Sigma will enjoy the following benefits over Company B:

• Improved resource utilization


• Decrease in defects/rework


• Elimination of redundant work


• Improved project deliverables including schedule


• Improved availability, reliability and security of IT services


• Improved service quality which translates into improved finished product quality (superior IT provided to the pipe manufacturing dept results in superior pipes being manufactured)


• Services aligned to customer demands which leads to improved customer satisfaction


• Integration of central processes


• Effective documentation and common terminology that helps with repeatability


• Effective metrics that help in understanding the status of processes and production in the organization


• Continuous process, product and service improvement

All other factors being equal, (cost of raw material etc.) this will then translate into higher sales and increased profits for Company A.

So it becomes apparent that even in a “non-IT” organization like a steel pipe manufacturing firm, IT processes and their constant improvement are crucial ways to gain a competitive advantage. And in a case of highly technical IT companies like Microsoft, Adobe, Wipro etc. the importance of IT processes and their improvement is even more significant. The difference between a Microsoft and our steel pipe company is that not only does Microsoft’s IT have to service its internal customers, it creates products and services for external customers as well. The IT at the steel pipe company only services the internal customers (i.e. the various departments within the organization). Other than that, the IT departments are the same in what they fundamentally do in both organizations.

It is usually a surprise to most folks that the ITIL body of knowledge was first implemented in a significant way by the hotel/hospitality and airline industries. After gaining maturity and delivering positive results while being utilized by these industries, the IT world caught on and began to implement ITIL more seriously. This is not surprising when you consider that the goal of ITIL is to align IT with the business and to constantly improve processes and services being provided.

To summarize, IT process improvement is a significant technique that all companies that have evolved beyond manila folders and calculators must utilize to stay competitive.

Awareness

Welcome to the first posting of the IT Process Improvement blog. My goal in publishing this blog is to provide a site where we may share our experiences, learn what’s new, and network with like-minded folks. Experts, novices and everyone in between are welcome to participate and contribute with their perspectives, questions and comments. My posts will vary in technical depth and subject coverage depending on the topic of the post but I will attempt to compose the posts in a way that everyone benefits from the read. Feedback is welcome at viveks@comwick.com.

The title and central theme of this blog site is “IT Process Improvement”, but what do these words really mean? It would behoove us to fully comprehend and understand the significance and implications of this much used but much misunderstood phrase.

“IT” or “Information Technology” is defined by the Information Technology Association of America (ITAA) as “the study, design, development, implementation, support or management of computer based information systems, particularly software applications and computer hardware”. But what do we mean by “information systems”? “Information systems” refer to a system of persons, tools, data records and activities that process data and information in an organization. Therefore, “IT” can be thought of as the use of computers and software to convert, store, protect, process, transmit and retrieve data within an organization.

“Process” as defined in the ITIL (IT Infrastructure Library) body of knowledge is “a structured set of activities designed to accomplish a specific objective”. ITIL further explains that correctly defined processes are measurable, provide specific results, are customer-centric and are traceable to a specific trigger.

“Improvement” as defined by the dictionary is “a change or modification by which a more valuable or desirable condition is achieved”.

So now that we have clarity on each of the individual words, putting it together we may state that “IT Process Improvement” may be defined as “changes and modifications made to a structured set of activities that organizations utilize to manipulate their data utilizing computer software and hardware, that results in value being added to the activities” Or to put it more simply, the goal of IT process improvement is to add value to the organization and its customers by modifying the activities carried out by the organization to achieve its goals.

I had stated earlier that this is a much used but misunderstood phrase. It is much used because management in general and senior management in particular wants to “improve their processes” and be in a “state of continuous improvement”. Their attempts to implement the various process techniques and methodologies then create buzzwords that circulate around the water-coolers and cubicles of the organization. However, companies are rarely successful with their process improvement attempts and most of these well-meant undertakings peter out like poorly maintained jalopies. And this is where the “much misunderstood” statement comes in. Management must be clear right from the beginning about what their goals regarding process improvement are, what they plan to achieve and in what time period, what the costs and impacts to the business will be and the steps that they will take to achieve this. The staff of the organization should be educated on the process model to be followed and the benefits of implementation to the organization as well as to their own work lives emphasized. My experience with attempting to implement IT process improvements in the past has ALWAYS run into these two snags:

1. Unrealistic expectations of the process implementation and its benefits by Senior Management.



2. Resistance by the staff due to:


1. generic resistance to change (inertia, apathy, laziness) and



2. fear of a negative impact on their career and status in the organization if their work should actually be measured and metrics reported.

On the other hand, competition is intense. Perhaps more so in IT than in any other industry in the history of the world. Those that do not change and change fast, simply die. This has been more than validated in the current recession/depression ensuing worldwide. A point that is being made clear by the spate of bankruptcies and layoffs manifesting worldwide is that companies that did not position themselves to be extremely competitive are paying the price. Not staying competitive was never an option and IT process improvement which was generally considered a luxury by both IT and business decision makers has been proven to be a necessity. It was never a luxury in the past and never will be in the future, either. In reality it is an indispensible way that any organization can gain a significant advantage over its competitor in cost-control, superior product design and service delivery and customer satisfaction which obviously translates into increased sales and increased profits. Details of how IT process improvement creates a competitive edge will be addressed in future posts.

So the conundrum we have here is that a state of continuous improvement must be attained if an organization wishes to survive and yet achieving this state of “continuous improvement” requires more than just studying the process techniques or even attaining a certification or two. It takes AWARENESS. Awareness of the need to improve, awareness of the tools, techniques and methodologies out there. Awareness of the roadblocks that one will almost certainly encounter along the way. Awareness by the staff and employees that this is not a way for them to lose their jobs but a necessary part of everyday life to simply exist. And this awareness must exist at every level of the organization for the improvement initiative to be successful.

Hence my desire to publish this blog; I hope that in doing so, I will steadily, week by week, reach out to the IT community and increase the levels of awareness out there so that IT process improvement will be a much more accepted and successful undertaking carried out by organizations worldwide. Fortunately, forward thinking organizations such as SEI, ASQ, PMI, OGC, IFPUG etc. provide a rich source of knowledge and tools for use by IT professionals to stay competitive. Stay tuned for awareness of these techniques and more in future posts at the “IT Process Improvement” blog.