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.

Making it Happen

While it is possible to pontificate and theorize till the end of the millennium, at some point in time, the rubber has to hit the road and certain process improvement steps actually performed. The situation is not unlike those who read up on working out, watch YouTube videos on working out, buy exercise DVDs, talk about working out a lot but never actually work out. They obviously see no fitness improvements and the same is true of process improvement efforts that never actually make the improvement.

A degree of sympathy for this situation is understandable, however. After all, there are numerous challenges in the way of implementing process improvements which I have mentioned in previous posts. A major concern that all stakeholders have with process improvement efforts is the fear that the improvement may end up causing more trouble than benefit. This is particularly true of IT process improvement endeavors that attempt to make significant changes in a short time or the “big bang” style of improvement. I, personally, usually advocate a phased, iterative approach to most organizations. This way, the benefits while not staggering are visible and the risks suitable diminished. The situation is mostly psychological as when management and staff see small changes making a difference, they are more open to the larger improvement efforts and a cascading effect of improvement kicks in. However, all this only happens only when a start is made.

The major shift in paradigm for most organizations now is to go from a department oriented approach to a process oriented approach. However, this involves major changes, upheavals and most importantly the potential disruption of everyday activities that could result in the inability to meet customer targets. The mistake that is usually made is that a proper preparation and accommodation for making process improvement changes is never adequately made. The erroneous expectation is that the IT department can perform and deliver in spite of all the changes and upheaval taking place all around. This is something like expecting your mood to be the same even though the in-laws have showed up to visit.

While it would be great if a large improvement could be easily be made, the reality of the situation usually is that improvements have to be made in small increments. This is because of the aforementioned problems and the fact that people generally have a psychological block towards change and deviation from the status quo. Over and above this, extra staff members have to be hired, proper training doled out and adjustments to the workload and time lines made. In short, the matter has to be looked at from all angles and planned properly. You can’t suddenly decide to implement a process improvement effort after getting charged up attending an ITIL or Six Sigma seminar. The motivation after these kind of events should spark a planning effort for improvement and not the full fledged improvement itself.

On the other hand, with competition as intense as it is, continuous improvement is no longer an option or a luxury. It is a basic necessity and should be included as part of the organization right from the organization’s inception. Therefore, at some point organizations have to make the jump into the water.

Sooner or later, improvement efforts will have to be made. The question is how open and prepared will organizations be to make the efforts. Those that have understood the importance of continuous improvement will reap the benefits while those who attempt to make changes at the last minute will struggle for survival.

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.