Building the IT Consulting Competency

IT consulting groups are springing up all over. Forming consulting "teams" has become a popular strategy designed to enable IT organizations to get closer to their customers. Some work well; many do not. What accounts for the differences? This article focuses on the critical success factors (CSFs) necessary to improve IT performance through internal consulting initiatives. It includes an action plan to create successful IT consulting groups that will provide services in technology consulting, process redesign, and change management.

In the Beginning
If you have as much gray hair as I do, you have seen significant changes in how information technology services are delivered. Even if you have not yet experienced your tenth high school class reunion, you have seen lots of changes. The days of throwing user requirements over the transom and hoping that what comes back not only works but resembles what was asked for are long gone. Today's users are intimately involved in not only specifying what they need but also in creating the final deliverables.

What has not changed, however, is the perception users have of IT professionals. Although some IT departments deliver every project on time, within budget, and meet all user requirements, others still operate like The Gang That Couldn't Shoot Straight. Their business clients (is that not a better name than "user"?) feel they are not being serviced appropriately and that the cost of the services they do receive is exorbitant - and they give their IT departments bad reviews. They then spend buckets of money on external consultants because they believe that someone can certainly "do it better" than their own people.

The response from the "Rodney Dangerfield" IT departments is to try and "get closer to the customer." They have watched how international consulting companies, as well as a host of local consultants work. They believe that the only difference between themselves and their external competition is that the consultants charge too much. The obvious solution is to create an internal IT consulting group. They announce the new organization and conclude that they are now "closer to the customers." The former applications programmers are designated "consultants" and are told they have responsibilities for specific business units. The business clients are told that the consulting fees that will be charged are at substantial discounts from the "gouging rates charged by the Big Boys."

Several months pass, and then - not infrequently - the Chief Information Office or the Vice President of Applications Development are invited to "pursue other opportunities." Little substantive change has occurred. The situation may, in fact, be worse. Business clients are more unhappy than before; they perceive they are getting the "same old same old" results from their IT "consultants" (who do not seem to understand the business of the business unit, their clients' business needs, or the urgency of their requests). The demand for outside consulting services increases, instead of declining. There is no joy in Mudville. IT has struck out, again.

A Better Approach
Here is a look at a success story and what can be learned from it. A large midwestern full-line insurance company created an internal IT consulting team including several people from its information management group. The insurance company had its share of successes and failures. Today, after several changes in IT strategy and direction, the consulting team still provides valuable services to its customers. If the company made a movie of their story, it would be a wonderful epic film, but with many still shots depicting disasters.

To their credit, senior executives stuck with the initiative and encouraged the team to learn from their difficulties as well as from their successes. Ultimately, the team succeeded and served its clients more effectively than ever before. The Senior Vice President of Business Consulting Services will say that three critical success factors were identified at the beginning. First, the consulting team had a business plan that focused on understanding client needs from a business perspective. Second, they had - and used - a set of methodologies to ensure consistent results. And third, they hired the right people and provided appropriate training.

Creating a competent IT consulting organization is not a slam dunk. Making the organizational changes and then using the Nike slogan, "Just Do It," is a surefire recipe for failure. IT professionals may not have the requisite skill sets needed for consulting success - and they need more than skills. They also need a set of processes and tools that undergird every successful consulting business.

The Business Plan
A well-constructed business consulting unit could stand on its own if it were to be spun off from the company. The business strategy is well articulated and the financials are real. The business strategy addresses the purpose of the organization, including mission, products, and services provided (and products and services not provided); marketing strategies; and any research and development it might undertake. The financials show the actual rates charged for ser vices and do not use unreal dollar transfers, i.e., "funny money."

The mission of this business consulting unit was to enhance the business performance of its clients by providing services they could successfully deliver and by brokering services that they could not successfully deliver. Further, they determined that they could not be experts in all business aspects of insurance, but would specialize. For example, they might have great experience in claims but limited experience in underwriting. Consequently, they would broker underwriting work but do the claims work themselves.

The most common type of work was developing business specifications that were then used in the purchase or development of software. Actual coding was done by a specialist group within IT, but the consulting organization developed strong project management capabilities. Also, they developed capabilities in business process redesign and change management.

The unit marketed its services aggressively. Staff were assigned to business development roles in each operating unit. Their charge was to identify business needs as well as help their clients think of their businesses differently. Much time and money was spent on taking clients to seminars and conferences where they could expand their horizons.

The financials required that the consulting unit deliver a specific rate of return. They established a billing rate 20 percent below the average rate charged by local consultants, were able to pay their expenses, make their contribution to overhead, and hit their required rate of return. (Getting to this point, however, took a long time and grayed the SVP of Business Consulting Services' hair.)

Methodologies
It never fails to astonish that so many IT departments either have no systems development methodologies or fail to adhere to those they may have paid six figure prices to acquire. Among the value-adding services that many consulting companies deliver are the methodologies to which they are committed. Granted, many customers will argue that consultants often adhere too much to "the book." A good project manager, however, knows the importance of using methodologies at appropriate levels of depth.

The insurance company bought several methodologies. First, they had a systems development methodology that allowed for flexible use based on client needs. They also had a project management tool that was used on every project, regardless of size. They also had methodologies for business process redesign and change management. The most important point, however, is that they developed a strong culture of adhering to the use of these methodologies.

People
People are the cornerstone of every great organization. Making the IT consulting organization successful requires that the right people be in the right positions to work appropriately with the clients. As the group's vision and mission are clarified, position descriptions should be developed. These descriptions need to define the competencies required so the applications developers will understand where they might fit best in the new organization and what skill sets they will need.

The writer worked recently with a small company that had created an IT consulting group that worked with twenty former applications developers, now IT consultants. A training program was conducted and included basic presentation skills practice. All twenty had presentation skills poorer than one would expect from high-school seniors. Presentation skills are essential for IT consultants. They also need skills in facilitation, conflict resolution, interviewing, data collection and research, critical thinking, project management, and client management. These skills can be acquired and used most effectively when customized to individuals and their responsibilities.

The insurance company was very careful when selecting people to work with clients. They created position descriptions, did skills assessments on all employees, and then matched individuals to the appropriate jobs. For the first two years, their training budget was three times that of the rest of the company. While training consisted of many of the skills mentioned above, people also were trained in the insurance business. Specialized areas, including process redesign and change management, were critical for those who desired to become experts in these areas. A formal mentoring program was incorporated to ensure that the staff continue to develop professionally.

After creating their consulting group, the insurance company found that the clients were still unhappy. The focus of the consulting group had been on their own people and not on listening to what their clients had to say. A focal point of the current effort is a client listening program (CLP). The CLP requires that the consultants listen to and document all opportunities and feed what is learned back to the organization. Active listening is done whenever the consultants are with clients (even including special events). For example, when consultants and customers attend seminars they complete reports that become available to all members of the client team.

An important part of the CLP focuses on projects. Each project starts with a statement of work (SOW) that defines exactly what the client can expect from the project team. But before the project begins the project manager also establishes with the client a "soft statement of work" (SSOW). The SSOW is about "how consultants and clients want to work with each other." For example, the SSOW details what clients can expect in terms of work habits, frequency of reports, types of reports, etc. The SSOW is reviewed frequently with clients in a "How am I doing?" approach to management. The SSOW is one of the most important relationship-building tools in internal consultants' tool bags.

Exhibit 1 shows a summary of the content of both the SOW and the SSOW. Remember: The SOW defines the contractual relationship between the client and the consultant and the SSOW defines how the parties will work together to accomplish the objectives of the SOW.

Exhibit 1. Statement of Work vs. "Soft" Statement of Work. Note: The content of a SSOW is flexible and can include many more items than those listed here. The SSOW should be considered as the way in which work will be conducted and should be shared with all members of the project team and reviewed frequently with the client.

Statement of Work: The contractual relationship between the client and the consultant; the objectives and what is to be accomplished.	Soft Statement of Work: How the parties will work together to accomplish the objectives described in the statement of work.
Content of the Statement of Work	Content of the Soft Statement of Work
1. Functionality of the Deliverables defines what each module or component of the completed project will do.	1. Consultant and Client Roles defines precisely what roles the client and the consultant will play on the project.
2. Performance Objectives defines the goals of each module or component.	2. Staffing defines who will be on the project and for what length of time.
3. Schedule defines when the client can expect that each module or component will be running and the schedule of other significant tasks.	3. Work Relationship defines whether this is a "doing" assignment, a "coaching" assignment, or a "teaching" assignment.
4. Other Vendor Relationships defines significant relationships with vendors who might impact the progress of the project.	4. Reporting defines when reports are expected, in what format, and who receives them.
5. Fees defines the fees and related expenses that the client will be expected to pay and the schedule of those payments.	5. Conflict Resolution defines how conflicts are to be resolved and an agreement is made that problems will be raised quickly and resolved with expediency.
	6. Work Environment defines where the work will be done, when the consultant will be on site, and describes the work space that will be provided in the client's site.
	7. Dress defines what dress code the client expects.
	8. Other defines all other items that will make for a cordial and pleasant work environment.

Point of View
All consulting firms have their "point of view." The point of view positions the consulting firm with its clients; it is an "approach document" that defines what clients can expect from the consultants. For example, a consulting firm might position itself as the expert firm in a particular line of business, knowing more than its clients. A firm might also position itself as the "doer," doing all or most of the work itself with little effort required from its clients.

The point of view adopted by the internal consulting group of the insurance company was that they were business partners with their clients. They professed to know about the client's business but certainly would not know more than the client. They also believed that they were educators who would work closely with their clients not only to do the work together, but also to help them learn how to do the tasks themselves on future projects. Finally, they always found ways for their clients to shine by having them make the key presentations to senior executives, by having them featured in company articles about the project, and by insuring that the clients always got the credit - not the consulting group.

Getting from A to Z
Now, assume that one still wants to create an IT consulting group within a company and asks, "How do I get started?" Here are seven action steps:

1. Decide what is going to be done. Establish what products and services will be provided and what will not be provided. Create a point of view that everyone, IT staff and clients alike, can understand and appreciate. Also, build a three-year plan with appropriate financials. It will take that long.
2. Acquire the right methodologies. Not only is it necessary to acquire the right methodologies, one must also put in place the standards for working with them. One of the primary advantages that large consulting firms have is their methodologies and their ability to stay true to them.
3. Get the right staff. Once you know what you are going to do, make sure to have the right staff. This may require training internal people as well as hiring people who have "been there, done that."
4. Provide strong leadership. Leadership has to be client focused with a strong commitment to excellence in everything that the group does. Often, hiring an experienced leader who brings little political baggage is critical to the group's success.
5. Listen to the client. A strong listening program that provides substantial feedback to clients is essential to success. The most common complaint from users is that "The IT people don't listen to me." Effective consultants listen, listen, listen, and provide substantive feedback
6. Learn from mistakes. Not all projects will be successful. Not all staff will be successful. The adage in the insurance company was, "Fail forward." Learn from each mistake, correct them quickly, adjust processes, and move on.
7. Build from strength, not weakness. You will want to add to your group's portfolio of services, and you should. Take incremental steps, however, and build on what you know something about, and with which you have had some success.

Remember, building an effective IT internal consulting team is not a "slam dunk." However, it is not rocket science either. To create a powerful client-responsive IT consulting group requires that its purpose and business plan be well thought out, implemented with a client and business focus, and be designed to provide consistent service at a reasonable cost. Perhaps it is rocket science after all!

About the Author
Dr. Leslie D. Ball is chairman of the management information systems department in the management school at Northeastern University, and was formerly assistant dean of information systems at the UMass-Amherst Isenberg School of Management. For the previous 10 years he was a partner with Computer Science Corp.'s (CSC) Integration Company where he managed an international business processing re-engineering management consulting practice. Before CSC, he was on the faculties of Babson College, Arizona State University, and Northeastern University. He has consulted with over 100 companies in the United States, Europe, and South America, helping senior executives understand the business impact of new computer technologies. Dr. Ball is the author of over 80 journal articles and two books. He serves on the executive Board of the Society of Information Management.

© Copyright 2007 Auerbach Publications