FACE to FACE

Consultants and suppliers can help you on a major software project. They can also get in the way. Here's what two experts think their roles should be.

By Staff -- Modern Materials Handling, 11/1/1999

Enter consultants and software suppliers. Both can help you. Both can also get in your way. Not to mention in the way of each other. So, who should do what?

We asked two experts. John Hill is a partner at consultant Cypress Associates and once headed up the original warehouse management software supplier. Larry Cinpinski is senior vice president of supply chain software for HK Systems. In an earlier life he was a software buyer at Miller Brewing. Here's how they think the process should work and what they wish the other would do differently.

MMH: Theoretically at least, consultants should serve certain specific purposes. What are they?

Hill: I think we need to act as facilitators who challenge the status quo and established biases of the end user. We need to offer new ideas and approaches. Part of that includes looking beyond software. The physical layout and materials flow needs to be examined. So do operating procedures and policies. Once those are understood, then the consultant can work with the project team to do things better. Not just the same old things faster.

MMH: Does any of that sound right to you, Larry?

Cinpinski: It does. Especially John's last comment. I call it - avoid paving the cow path. I would also say the consultant needs to go beyond layout and flow. The consultant needs to draw out from the project team how the business will run in the future.

MMH: Are only consultants qualified to do that? Or can a software supplier do this up front work just as well?

Cinpinski: Absolutely not. It just isn't appropriate for software suppliers to be involved in the end user's evaluation of how the business should run in the future. A supplier will inevitably lead them in the direction of their software. And that may not always be best.

Hill: I'm glad we agree, Larry. Unfortunately, some software suppliers aren't always willing to just do their part. Some get into the consulting end of the process. One other point. The consultant's role doesn't stop where I did earlier. We also need to offer a formal proven process for requirements analysis and definition, supplier identification and screening, procurement, and implementation. We have to help users minimize risk and contain costs. And part of that includes identifying software suppliers that are a possible fit.

MMH: Does that sound about right, Larry?

Cinpinski: It does. We should be called in after the consultant and project team have had the business discussion, and set the requirements and functionality of the software. I do want to add that the project team has to realize that it needs to be in control of the process at all times.

Hill: That's for sure and holds true when dealing with suppliers, too.

MMH: So what do you think is the supplier's role, John?

Hill: The ultimate responsibility for ensuring that the software meets the project's requirements rests with the software supplier. They also have to bring project management tools and skills as well as post-implementation support and system enhancements.

Cinpinski: Suppliers need to show end users what their software can do. How it meets their needs. How it's going to change procedures.

MMH: During the selection process, do end users need to be careful of any business alliances between consultants and suppliers.

Hill: You bet they do. This is probably going to get me in hot water, but I'll say it nonetheless. Consultants should not align themselves with software suppliers. Unfortunately, just the reverse is happening all too often.

Cinpinski: At some point, end users need to determine if and how a consultant might benefit financially from the selection of a certain software supplier. If end users keep their eye on the functional fit, they'll be better able to make decisions for the right reasons.

MMH: Larry, what do consultants do that you wish they wouldn't?

Cinpinski: Three things come to mind. Most consultants tend to be biased one way or the other. Consul-tants also tend to profess to be experts in all areas. It would be better if they just admitted what they don't know. And finally, they don't always keep up with changes in software.

MMH: Do software suppliers do things you wish they wouldn't, John?

Hill: Larry had three things. I've got four and they all fit under the umbrella of "answer the questions consultants ask of them". Too many ignore request for proposal content and instructions. Others submit boilerplate proposals that bear little resemblance to the request. Then some submit pricing that is tough to decipher. And then there are the reference sites with little relevance to the client's requirements. Why claim interest in a project but not address the end user's key issues?

MMH: Thank you both for sharing your views.