OR/MS Today - February 1997

February 1997 € Volume 24 € Number 1

Seven Helpful Hints for OR/MS Consultants

How to sell your technical expertise and get clients to acknowledge and appreciate the results

By Harlan P. Crowder

Chaos, complexity and uncertainty. As we approach the new millennium, big public and private organizations are often the victim of chaos, complexity and uncertainty. Local and national governments and businesses from startups to Fortune 100s often appear to function as if the inmates have taken over the asylum. Without doubt, this is a continuing trend: global trade pacts, government deregulation, legislative gridlock, corporate restructuring, contentious and quarreling special interests -- all increase the entropy of social and economic systems in organizations large and small.

What this means for operations research/management sciences professionals is that there is a sharp increase in the demand for our help in understanding and taming chaos, complexity and uncertainty. This booming use of OR/MS methods can be traced to several factors: an increased focus on applications by the OR/MS community, dirt-cheap computers, and a dawning awareness by the people in charge of organizations that some sticky analytic management problems just can't be solved in spreadsheets. The bottom line is this: If you like to solve real problems using OR/MS methods and you desire to make a living doing what you like, then you are in luck. Chaos, complexity and uncertainty are your ticket to the fun house from now to 2000 and beyond.

My intention here is to give some personal insights and suggestions on the practice of professional OR/MS consulting. Professional consultants are interested in solving their client's business problems, not merely designing and building simulation and optimization models. Thus a lot of my discussion deals with client and consulting engagement management. I draw on the experiences of our successful OR/MS consulting practice in the IBM Consulting Group, presenting a potpourri of helpful hints that, unfortunately, our group often had to learn the hard way.

The usual disclaimer: What follows is my personal opinion and is not the policy, official or otherwise, of the IBM Consulting Group.

Helpful Hint 1:

Clients always know best -- except when they are trying to describe their business problems.

The main role of an OR/MS consultant, especially in the early stages of an engagement, is helping the client identify and understand the business problem that requires solution. Most clients know that "something is wrong" and have some plausible sounding ideas about how to fix the problem. In many cases, however, following the client's initial direction addresses the symptom but not the cause of the problem.

We performed a series of engagements for a manufacturer of agricultural chemical products. The first time I visited the client, I was told that they had too much inventory remaining at the end of each year and they wanted to hire me to build an inventory model. After some discussions with several levels of management and operational people, we found that: 1) they indeed had too much inventory at year's end, and 2) the root cause wasn't directly with inventory policy, but rather lack of any idea about how to forecast annual demand for products.

We discovered that the two most important factors for understanding how their product should be produced and positioned over the year were individual customer histories and the weather. Yet this company rarely talked directly to their customers and -- I'm not making this up -- their only use of the weather was to "blame the weather when things go wrong!" We ended up with a series of engagements to build a forecasting model that considered customer and weather history. Solving the forecasting problem solved the inventory problem.

Listen carefully when your clients describe their business problems, but make sure your OR/MS solution solves the right problem.

Helpful Hint 2:

OR/MS consulting engagements have little to do with algorithms and convergence rates.

They have everything to do with DATA.

I estimate that the cost to our clients of framing the problem, building the simulation or optimization model, and interpreting the results is about 15 percent of the total consulting bill. The other 85 percent of the client's cost is involved with identification, extraction, cleansing, validation and formatting of data. Everybody loves the fun part of model formulation and implementation, but there are few people out there that get joy out of cleaning up other people's messy data. To put it bluntly, as information workers, this is about as close as you can get to manual labor.

Don't be lulled into thinking that this consulting engagement will be different. The model doesn't require that much data, everybody agrees on the data sources, the systems people swear that everything you need is easily available, and the client has promised her best people to help you extract and format the data just the way you want it. If you believe this scenario and write your consulting contract accordingly, you will lose money. If you believe it too many times, you will be out of business. (More later about writing contracts.)

Helpful Hint 3:

Is it scheduling or is it planning? Make sure you know, and make sure the client knows too.

Many OR/MS applications involve planning or scheduling operations in manufacturing, transportation and other areas. Most OR/MS professionals know and appreciate the distinction between scheduling and planning: scheduling involves short time periods, disaggregated data, small segments of the business, and answers operational kinds of questions of interest to people who actually do work. Planning involves longer time periods, aggregated data, larger business units, and gives solutions to strategic kinds of problems of interest to people who only talk about doing work.

Planning and scheduling are really two extremes of a spectrum of applications. This spectrum is measured in the kinds of characteristics of models mentioned above: time horizon, data aggregation, business segment, interested party, etc. Most OR/MS models will lie somewhere on this spectrum, depending on the application. Again, no great news for OR/MS professionals.

The problem arises when you work with clients who do not have an appreciation of the concepts of scheduling and planning or the ideas behind building and using mathematical models. In Helpful Hint 1, I talked about defining the client's problem. If appropriate, part of that definition is making a determination: are we doing planning or scheduling? If it turns out that the application under consideration requires a planning model, we want everybody to know that. And in particular, we want people to know that it will not answer operational scheduling types of questions. Conversely, if the application requires a scheduling model, everyone has to know that under no circumstances will the model answer questions of a strategic planning nature.

In concert with the client, I usually write a design document for a proposed model to support a particular application. Included in this document will be a section on the kinds of insights and answers that can be expected from the model, and also a list of the kinds of questions the model will not answer. In effect, we determine and agree where the application is pegged on the planning/scheduling spectrum. Then, six weeks or six months later, when I'm conducting a review session for a strategic production/distribution model and the foreman from the production line asks how this model will help him schedule his line next week, I'm ready. I've got documentary evidence that this guy is in the wrong meeting.

Helpful Hint 4:

Getting into an OR/MS consulting engagement is easy -- getting out can be the hard part.

Call me paranoid, but the first thing I do when I get into a crowded hall is figure out the exits. Likewise, the main thing I want to know in a consulting engagement is, "What do I need to do to get out of here?" Every engagement has a scope, the tasks that need to be accomplished and items that need to be presented to the client for the engagement to be deemed successful. The scope is the heart of the agreement between the consultant and the client; everybody needs to understand and document unambiguously the scope of the project.

Many consulting projects are the victim of "scope-creep," which, as the name implies, is the unintended expansion of the scope of the project. Scope-creep delays the project, costs more money, and usually reflects badly on the consultant.

OR/MS consulting engagements are especially vulnerable to scope-creep because designing and building mathematical models of real-world systems usually generates lots of new questions and areas for more investigation. There is constant temptation to explore some new track briefly in the hope that it will yield some killer insight, thus delighting the client and making the consultant look really good. In most cases, the diversion of effort to an out-of-scope activity will delay the project, cost the client more money -- seldom resulting in delight -- and hurt the consultant's reputation.

Should all the neat and cool questions that arise in the course of an OR/MS consulting project be ignored? Certainly not. They should be well documented and used as the basis for securing what every good consultant wants and plans for: The Follow-On Engagement. If new questions and areas of investigation are really important, they should form the basis for the scope of subsequent projects with the client. Just don't let them block the exit door out of the current engagement.

Helpful Hint 5:

Don't just storm the beaches and ignore the occupation forces.

Ken Fordyce at IBM likes to say there are two types of OR/MS practitioners: the more flamboyant and colorful folks who storm the beaches -- work with clients to design and build simulation and optimization models, test prototypes under unfavorable conditions, get beat up (praised) by clients when project schedules are missed (met); and the more diligent, grounded people who come later to occupy conquered territory -- integrate the modeling application into the enterprise I/S environment, operate the application day-to-day, answer calls in the middle of the night when (not if) things go wrong, etc.

By all accounts, the beach stormers have a lot more fun than the occupation forces, but both groups are vital if an OR/MS application is to successfully solve a business problem. For consultants, this usually means that you can do most of the beach storming and can train client practitioners to perform the more routine follow-on and day-to-day activities. If you skimp on the application maintenance education and training, you run the risk of getting a distress call later, just when you are in the middle of storming a really cool beach.

Helpful Hint 6:

Open the OR/MS technology kimono.

A lot of consulting organizations are very secretive about their methodology, the techniques they use to attack and solve problems. There are a couple of reasons for this: 1) they sincerely believe that they have something that nobody else has and it is such a competitive advantage that they want to keep it a secret, or 2) there is really nothing there and the last thing they want is a client seeing the Little Man Behind the Curtain.

We have found another approach to be very successful: We open our methodology up to our clients and encourage them to learn as much as they can about how we design and build OR/MS models, collect data, and generate and interpret results. If possible, we encourage clients to let us help them acquire OR/MS skills and establish business modeling groups within the enterprise to maintain and extend the analytic applications that we develop for them.

This approach works for several reasons:

It gets more people in the organization thinking about modeling and modeling applications. Even if nobody in the client organization picks up the challenge and starts trying to become a modeler, the fact that we show them what we do and how we do it raises the collective awareness about analytic applications.
The Tom Sawyer Effect. There are a lot of interesting and challenging activities associated with implementing OR/MS applications; if you do your job in the open with energy and enthusiasm, you soon find that people want to start sharing in the fun!
In the end, we are hired by our clients to formulate approaches for solving business problems, not just building models. To the extent that we get our clients involved in our methodology, we are freed to address more far-reaching and important issues while leaving the actual implementation details to the client team.

Helpful Hint 7:

Pricing OR/MS consulting engagements -- Don't worry about giving your client Sticker Shock.

The delicate question of pricing engagements could be the subject of another whole essay. Beginners usually price their services too low, either because they lack confidence to ask a higher price or because they think they can get their foot in the door at a cheap rate and buy business that will be more lucrative in successive engagements. Our experience is: if you want a discount, go to Kmart; we charge full retail.

The usual procedure is to determine what needs to be done and define the scope of the engagement (see Hint 4), determine how much of your time will be required to accomplish the engagement scope, multiply your time requirement by your consulting rate, and give the client your estimate of how much you will charge in consulting fees. In essence, you are delivering a product -- your brain power applied to the problem at hand -- and this is the price of the product.

Usually, if you have scoped the project correctly, there will be little if any grumbling about price. If the client wants to haggle on price, then he or she needs to understand that they are, in effect, changing the scope of the project; if you pay less, you get less.

A quick word on fixed-price contracts versus time-and-materials contracts: Don't offer clients fixed-price contracts unless you really know what you are doing. If you tell somebody that you will design and implement a model and produce results for a fixed price, then when things go wrong you eat the cost. On the other hand, if you give the client an estimate of how much the project will cost based on your time involvement, you have two advantages: 1) when (not if) things go wrong -- the I/S people don't have the data for your model like they promised they would -- then the client eats the cost for the extra effort required by you, and 2) if you happen to finish the project in less time than estimated, with less resulting cost to the client, then you get to be a hero; your reputation is enhanced and you are in a good position for follow-on business with the client.

And finally, promise whatever you will to your client, but always deliver more than you promise. Pick up one of those out-of-scope items that we talked about in Hint 4, or make a report in color rather than black and white, or show the marketing department how they can use the manufacturing model to be more effective, etc. In the end, clients don't want models or reports or GUIs; they want value for their money, just like you and me. In every consulting engagement, slip in a little unexpected value.

Conclusion
Professional OR/MS consulting requires two broad sets of skills: the ability to look at the chaos, complexity and uncertainty of a real-world processes and see a mathematical model, and the skill to sell your technical expertise and get people to acknowledge and appreciate the results of your labor. I've given some helpful hints here on the latter aspect.

When we started our OR/MS consulting practice at IBM five years ago, my colleagues and I had a good command of the technical aspects required to be successful in the market. What we didn't have -- and didn't know that we didn't have -- was a good awareness and appreciation of the process of being an effective consultant. The ideas I've outlined here are little nuggets I gathered as I trudged up that learning curve. I hope an aspiring OR/MS consultant finds them helpful.

This article appeared in Vol. 17, No.2 of the INFORMS Computer Science Technical Section (CSTS) Newsletter.
Reprinted with permission.

Harlan P. Crowder is a senior consultant with the IBM Consulting Group. He uses OR/MS techniques to analyze complex business problems. Dr. Crowder has received the Lanchester Prize from ORSA for work on solving large-scale integer programming problems. He lives in Silicon Valley, Calif. His e-mail address is crowder@almaden.ibm.com

For more information, put the number 1 in the appropriate space on the
Reader Service Form

E-mail to the Editorial Department of OR/MS Today: orms@lionhrtpub.com

Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: 770-431-0867 | Fax: 770-432-6969
E-mail: lpi@lionhrtpub.com