In one company, client executives complained that Corporate IT didn't understand their strategies, their people, or their needs. When they demanded a single point of contact, the CIO assigned a set of business units to each of his senior leaders. Thus, each leader had two roles:

Role #1: Manage a technology-engineering or service group, ostensibly available to all clients.

Role #2: Serve as liaison to a set of client business units, ostensibly representing the entire IT department.

Phil headed up a group of IT applications developers for financial systems such as the general ledger, accounts payable, and tax. So he was assigned to the Finance department -- not for just his own team's projects, but for all projects and services delivered to clients in Finance. He was considered the "relationship manager" on behalf of all IT to the CFO.

His peers were given similar dual roles for other applications domains and clients. Sam, for example, managed customer applications and was the liaison to Sales and Marketing clients. And Bev managed human resource applications (employee data) and was the liaison to the HR department.

In this IT department were the following groups (among others):

• Phil, financial applications + Finance clients
  
• Sam, customer applications + Sales and Marketing clients
  
• Bev, employee applications + Human Resources clients

Weak Client Liaison Function

Clients rightly want their IT liaisons to be readily available. The Sales function should spend most of its time with clients.

In terms of time commitment alone, this is a full-time job. But Phil had a big group to manage. He couldn't spend sufficient time with clients attending their meetings; getting to know the people and their businesses; working with them to discover new opportunities; brokering clear agreements; delivering account reviews; resolving relationship issues; etc.

Beyond that, the Sales role requires specialized skills and methods, especially critical if this function is to do more than facilitate relationships and take orders. One example is a method to discover really strategic opportunities.

Phil knew that to do this function well would require study and experience. This was not a matter of capability. He felt confident that, if given proper time and training, he could learn to perform the client-liaison job well. But while he did so, who would manage his applications development group? Phil just didn't have time to do both.

In truth, even if he had the time, Phil didn't have the right background. He was an IT expert, not a finance professional. He understood their accounting processes; but he didn't really understand their business challenges and strategies.

Most of the time, Phil remained focused on his original Engineering job for a number of reasons. Project pressures demanded it. Technology was his first love and the focus of his career. And the people in his group depended on his guidance, coaching, and leadership.

Thus, the Sales function remained a gap. These senior managers did provide a point of contact which improved relations. But they didn't do much to add value to clients' strategic challenges.

Product-driven, Not Strategy-driven

To the extent that he did spend time with clients, most of Phil's interactions were with the Accounting department, the primary users of his financial applications.

However, Phil couldn't help but notice that his traditional clients were some of the least influential of the Finance department's senior management team. He saw that Jane, the manager of a small Financial Planning and Analysis group reporting directly to the CFO, seemed to get a lot more attention.

So Phil called Jane. He told her he was looking for high-payoff, strategic IT projects, and wondered if he could serve her in any way. Jane invited Phil to drop by.

When he did, Phil found Jane in the midst of analyzing staffing cost trends. What she really needed was access to employee data, market data, and data-analytics tools.

But what did Phil recommend? Can we honestly expect this manager of financial applications developers to prescribe anything other than extensions to his general-ledger application!? Despite his best intentions, technological bias crept in; and the project that Phil suggested was only of mild interest to Jane.

This structure put Phil in a conflict-of-interests situation. As an expert in a set of technologies (financial applications), he was paid to be biased -- the natural bias of a specialist. At the same time, in the client-liaison role, Phil was expected to be unbiased and represent the entire IT product line.

No matter how well-educated and well-intentioned Phil may have been, organizational forces were working against him. It wasn't that Phil made a conscious decision to be parochial. Phil honestly believed that the financial solutions to which he was dedicated were the greatest thing since sliced bread, and he just didn't see opportunities outside his own specialty.

This rainbow of Sales and Engineering led to product-driven, rather than business-strategy-driven, recommendations.

This conflict of interests was not lost on Jane. She found it difficult to trust the objectivity of someone who also had responsibility for (and hence a vested interest in selling) one particular solution.

Barriers to Teamwork

In this case, Jane persisted and got Phil to recognize her need for a solution other than financial systems. But then he ran into another problem. The other groups who supplied needed data and tools were busy serving their own clients.

For example, Jane needed employee data. But Bev's clients in HR set priorities for her staff. Jane and Phil's Finance project didn't make their list.

Of course, Phil still had to find a way to get the job done. When he couldn't get help from Bev, his group developed a small HR application (outside their domain of expertise).

Similarly, clients outside the Finance department had trouble getting help from Phil's group, since his priorities were set by the CFO. As a result, multiple overlapping financial applications cropped up throughout the company. This structure led to costly replication of efforts and dis-integration of data.

Ultimately, the structure devolved into client-dedicated Engineering groups (as discussed in Chapter 4). Productivity and quality suffered. And enterprisewide synergies were lost.

Alternative

This mixture of clients and technologies was an attempt to fill a gap in the structure: the Account Sales function.

But Sales is not a part-time job for an internal service provider's senior leaders, any more than engineering and manufacturing executives can serve as a corporation's sales force in their spare time. Sales should be a separate group, within internal service providers as it is within companies.

Some may say that their organization can't afford it. But the truth is, a small, dedicated team of Sales professionals will perform far better than the same number of person-hours spent on client-liaison work distributed among the managers of other functions.

And some may say that their clients won't accept a "sales" function in an internal shared-services organization. Okay, so give it a different name. But in addition, define the services that Sales delivers (Chapter 15) to help clients understand its value to them.

The bottom line is: Sales is a profession in its own right, and it warrants dedicated specialists.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....