Back to Articles

Note: This article was written for Consulting to Management, the journal of the Institute of Management Consultants and was published May 2000. The advice provided to other consultants in this article is certainly applicable to our clients.

Consultants are often are called to help turnaround information technology projects that have gone awry. Companies continue to invest heavily in information technology solutions in the hopes of improving operating efficiency and combating the effects of downsizing. Yet, all too often, the actual project benefits are at great variance with the expectations set during the software procurement cycle.

Craig Barrett, President and Chief Executive Officer of Intel Corporation, offered the following "pet peeve" in a recent interview:

"Excessive hype pervades our industry. People are always making outrageous claims about this and that. We need fewer claims and better products."

What can consultants do to help their clients protect themselves from the "excessive hype" and "outrageous claims?"

Just as a hammer doesn't guarantee that nails can be driven into wood with great precision, software doesn't guarantee that operating efficiency will improve. The software does not provide the business processes that teach the company how to "drive" the software. Each department that uses the system must learn how to "drive" the application properly.

Consultants can add tremendous value by assisting users with software selection and implementation. The users, not the M.I.S. department, must drive project from the procurement phase through software deployment. Each department must make decisions about how to use and maintain the software, understand how upstream adds/deletes/changes to information affect downstream users, and learn how to populate the software with company data.

The software is the servant; the client is the master. Beware if it seems that the software has become (or is becoming) the master and the client has become the servant of the software.

• Understand that the "best" software is not necessarily what is best for each business.

"Best" is a relative term. What is "best" for a large division of a Fortune 500 company may be inappropriate for a small or medium-sized company. Acquiring a sophisticated application simply because another firm in your industry has done so can be a prescription for disaster. Acquiring an application "that a company can grow into" can also be problematic.

One of my clients had previously acquired a "state-of-the-art" Enterprise Resource Planning (ERP) system. The software implementation has been an abject failure from the standpoint of user acceptance and value-add to the company. While the application acquired was certainly "the best," it was probably the worst fit imaginable for this particular company.

• Understand the business needs the software application must support.

Many companies undermine their investment by failing to identify their business and application needs before calling in the software vendors. By failing to do this, I'm reminded of the old adage, "If you don't know where you are going, any road will get you there."

Comparing "features and functions" with competing software vendors prior to understanding or defining how you want to run your business contributes to many project failures. Clients often defer to software vendors whom they assume fully understand their business needs.

The greater the number of features and functions, the greater the perception that the software vendor has a firm grasp of the client's problems. Quite the opposite can be true. Though the software vendor would have you believe otherwise, do not assume that the software vendor has a profound understanding of your actual business needs.

• Understand the underlying assumptions/philosophies in each software product.

Every software company has underlying assumptions or philosophies about how companies "ought to" run their businesses. These "assumptions" are often undocumented and only come to light after the software has been purchased and is being implemented.

For example, one software vendor decided that its application should automatically assign a Purchase Order number. There was no provision to include a company's actual Purchase Order number in the application. The software vendor looked at this as a "feature" that would prevent a duplicate Purchase Order number from being assigned. For years afterward, Purchasing, Receiving, Accounts Payable, other departmental users and the company's vendors had to maintain a manual "cross-reference" between the "system-assigned" and "actual" Purchase Order numbers. This caused untold amounts of confusion throughout the company.

A once-in-a-lifetime quirk? No. "Features" like this exist in every software product. How do you find out about these things?

You must consult with departmental users who actually use the application on a daily basis to identify what they like and dislike about the application, what difficulties they have encountered, what things the application does not do that they wish that it did, etc. If possible, have discussions with individuals in several different companies-get as many opinions as you can. One person's "feature" is another person's "bug."

• Consider the company culture and likelihood that the team will be able to absorb and embrace the technology.

Imagine the difference in complexity between the cockpit in a Piper Cub and Boeing 747 aircraft. While both are airplanes, the similarity quickly ends. The levels of sophistication, training, and aptitude required to successfully fly the two aircraft are at opposite ends of the spectrum.

The same can be true of two different applications that essentially do the same thing. Acquiring a "state-of-the-art" application can easily overwhelm your staff with its complexity. It is important to take into account the experience and comfort level of the people who will have to manage the application on a day-to-day basis in any decision.

• Sell the project to the troops, not just senior management.

The decision-makers generally aren't the people who have to use the system day in and day out. Too many applications have been deployed in situations where the troops hate the application as it does little or nothing to help with their actual business needs. This result is normally chalked up to "resistance to change."

It is important to look beyond the sales presentations and go speak with the people in the trenches. Find out what they need. Do not assume that the software vendor knows what is best for them.

One software vendor touts "100% customer satisfaction" in their advertisements. One would have to hope that that information is coming from the people who sign the checks because the people in the trenches think this vendor's solution stinks. The senior executives purchased the software for political reasons, not suitability reasons, to help the emerging software company get the firm's name on their client list. From the user's perspective, the application has adversely affected productivity.

• Do not assume that software vendor's client lists are real and that these clients have wildly successful implementations.

Client lists are often very misleading. Some software firms include companies who purchased evaluation software or who are simply talking about a possible purchase. Some client lists include all clients but don't differentiate which clients have purchased which products. [This is particularly true for companies who are introducing new products.] While the client list can seem impressive, dig deeper to determine whether or not the company is really a customer and the degree of success that that company has actually experienced with the application.

• Conduct in-depth reference checks to understand implementation and support issues encountered by others.

Fast-track software firms are seldom able to keep up with the growth pace set by the sales organization. The software developers and support team are overwhelmed just trying to please customers. It is important to determine how responsive the software firm is to requests. Investigate how well the company handles high impact bugs as well as enhancement requests. And, you need to determine this by talking to a number of users, not just the economic buyer.

• Require that the vendor demonstrate up front that the application can address any unique needs you may have.

Software vendors are notorious for selling "futures"-features and functions that a client would find highly desirable but are not available yet. One should not assume that all of the features and functions touted are available in the software.

If a feature or function is important to you, have the vendor demonstrate to your satisfaction exactly how the software addresses the problem. If the vendor cannot demonstrate the feature or function, the new feature may still be under development or (worse) being considered by product development. You also should inquire whether the capability being demonstrated is part of the existing product, planned for a future release, or will be added to a future enhancement release. If the capability is not in the current product, be sure to assess the likelihood that the functionality will be available in the time frame required. Be skeptical. The easiest product to create in the world is a data sheet.

• The client must accept responsibility for implementation through involvement.

Every consulting engagement should contain one overriding goal: client self-sufficiency. In order for a client to become self-sufficient, there must be one or more people who will take over responsibility for day-to-day management of the application. It is impossible to make the hand-off if no one is available to take the ball. Every information technology project plan should include an exit plan for the consultant. If the client is unwilling to accept ownership, this can contribute to disaster.

• Inadequate budgeting for training and conversion from existing application environments.

When a company rolls out a new application, there is only one opportunity to make a first impression. The user's initial impressions will be very difficult to change. If inadequate training and support budget is available, the users will never embrace the new technology.

During training, it is important to properly set expectations about problems the users will encounter such as performance problems, known bugs, application enhancements being made, etc. If you try to conceal defects, the users will have little faith in your appreciation for their needs.

As most information technology projects take longer and cost more than anticipated, the efforts at the end of the project are short-changed. The likely budgetary targets are the training budgets. Resist the temptation to cut corners here.

• Conclusion

I hope that these ideas are helpful for you and your clients. If it seems that I view software vendors with some skepticism, I plead "guilty." In more than a few instances, I have been called to clean up the mess left behind in board rooms by software sales people setting unrealistic expectations.

Do software vendors act unethically? In some instances, the answer is clearly "yes."

Several years ago, I asked a panel of software vendors why each of their companies had added a feature on their data sheets when none of them had the ability to support such functionality. One panelist responded that in the vast majority of sales situations, the vendor's price for saying "no" would have meant exclusion from future consideration as a software vendor. When a competitor added the functionality, each vendor "added the functionality" to their data sheets.

When it comes to information technology projects, the watch words are caveat emptor-buyer beware.

__________________

If your company is considering implementation of a custom application, you need to be aware of what makes Gardner & Associates different from technology consultants.

• We are management consultants, not technology consultants.

--We are independent of any technology solution providers.  We look for the best technology fit based on our client's needs.  We don't try to force a specific technology into a client's business.

--We look at problems "holistically" - we're concerned about your problem from the perspective of solving a specific challenge across the enterprise and, in some cases, even beyond the enterprise to the extended enterprise (Dealers and Customers), not simply addressing a departmental problem within a company. 

--We're concerned about all dimensions of your problem

• Business process

• User interface--inputs and outputs--of the application

• Integration points with users

• Integration points with other I.T. applications

• Integration of the "knowledge" with the I.T. applications

• Creation, maintenance and status reporting of data

--We have to integrate and, in most cases, define the business process with the technology

--We define the mission for the technology consultants

• We're not technology consultants

--There is no "one-size-fits-all" technology solution--each vendor tends to represent their solution can "do it all"

--Technology that may have worked well in one company may be inappropriate from a company in the same business or industry

--Technology consultants don't do "management consulting" - they provide electronic infrastructure but often know little about the underlying business process or business problem--they rely on firms like ours to assist them.

--They are the builders of roads - they can't tell you where the road should be or what it should look like

• Ability to write about and communicate complex principles across the enterprise

• Our track record and expertise helping clients be more successful dealing with technology consultants and deploying new applications

• Training

• Pragmatism

Take the Next Step:  Here are a number of different ways we can be of service to you as you begin or continue your journey:

--Call us at 888-488-4976 for a no-cost, no obligation discussion about your situation

--E-mail us with your comments & questions

--Contract with us to perform a comprehensive Requirements Assessment

Back to Articles Page