FREQUENTLY ASKED QUESTIONS

Needs Analysis and Requirements

What are the different kinds of requirements?  Generally speaking, they can be broken down into two groups:  Functional and Technical.

Should all requirements be given the same weighting?  Not all functional areas within the organization are or should be considered equal.  Let’s assume for a second that your software evaluation was only considering two functional areas: accounts payable and finance.  And let’s assume that the project sponsor has decided that accounts payable is the major focus of the evaluation while finance is a minor focus.  Wouldn’t it then follow that the individual list of requirements for accounts payable should get a higher weighting than finance?  It would not make sense to give them an equal rating.

This seems like a lot of work.  Is all of this really necessary?  Defining what you require in a software package is, in my opinion and experience, the hardest part of the entire evaluation effort.  It is very easy to say what you don’t want.  But the effort of defining your requirements is a very intentional and disciplined act.  The degree of probability that you will get the best software match for your organization is directly proportional to the amount of focus and hard work that go into the requirements document.

This is the beginning of the relationship between your organization and the software vendors.  You will make a declaration of need.  The vendors, heart swelling with love and desire, will declare back that they feel your need and will be able to satisfy all of your software desires—and then some.

What is the best method to illicit requirements from my user base?  On smaller projects, the functional area team member may begin compiling the list of desired and required features and adding these to the precompiled list he obtained from other sources.  On larger projects, requirements are typically gathered through an interview process.  Numerous people from a functional area are “interviewed” to determine what their normal processes are and what is important to be included in the requirements document.  These interviews do two things:  one, they gather the desired information, and two, they begin the process of getting buy-in from rank-and-file members of your organization who are not on the project team.  They will more likely support the final decision if they feel that they had some input.

Software Evaluation Projects

Who are the best software vendors?  There is no ‘best’ software vendor.  You need to be thinking in terms of ‘best fit’ software vendors.  You want the vendor whose functionality best fits your detailed business and technical requirements at a price that is within your capital investment budget.

What type of scoring mechanism do you use during the software evaluation process?  Over the years we have developed some moderately complex scoring mechanisms.  They are difficult to describe in a question and answer format.  I think the question is the wrong one.  I think the question should be more along the lines of how much of the final decision is based on ‘hard’ scoring and how much is based on impressions and intuition?

So, here is my answer to that question:  Approximately 50/50…and that answer lends itself to the notion of the art of software selection versus the science.  Generally speaking, the “art” relates to working and dealing with people—and with using your intuition and experience to navigate issues.  It’s a process of discernment and trust in your instincts.  “Science” relates more to the mathematical compilation of a functional score for a particular vendor.  It also relates to the creation of an empirical evaluation mechanism.  Software selection involves both of art and science.  You have need both.  Despite what some say, you just can’t come up with a “score” for a vendor and say that the highest scoring software vendor wins.  Similarly, you can’t just go on vibe either. You need both art and science, and you need to know that and accept it going in.

How is choosing software different than purchasing other products and services for my organization?  Software is unique in that it is one of the few major capital expenditures (and maybe the only one) that is critical to your business, BUT is always changing, improving, and therefore making the initial product obsolete at some point.  A change by your competitors to a newer solution, one that has some new functionality that gives them a competitive advantage, might be enough to make your organization lose market share, and force you to make a change yourself.

The smart move is to stay abreast of the software market, and to be thinking at least 18 months out.  To be proactive, not reactive.

What is the hardest, most time consuming aspect of the software selection process?  The hardest part for you is going to be defining your business and technical requirements.  In order to get a requirements-to-functionality match, the requirements definition process is critical…and difficult.  Some companies hire it out to consultants, but the consultants still have to interview key personnel, and you will still have to review their work.  The second most difficult thing to do is to decide to pull the trigger and decide that the sheer cost of the acquisition will necessitate your company to go through the process in a mature and methodical manner.

When hiring a consulting firm to help and provide value during the software evaluation process, what should we be looking for?  I would focus on a couple of key areas:  One, have they done this before and do they have testimonials and references.  Two, do they have a proven methodology and can they explain it to you.  Three, ask if they are willing to only work on the software evaluation, and not on the accompanying implementation.  Four, ask them how many people they are going to put on the engagement – for most software evaluations, one person should suffice.

I am concerned that if I hire a consulting firm, a team of consultants are going to descend upon our workplace.  Can’t this be a one-person consulting job?  You are right to be concerned about this.  In my business, we call this ‘piling on’.  See my answer to the previous question.

What is the best way to conduct software product demonstrations?  Hmm…not sure about the ‘conduct’ part.  But I can tell you the best way to ‘control’ them.

A scripted demonstration is where you tell the software vendors exactly what it is you want to see in their software.  And you lay it out for them in advance…in a script.  If you do not do this, you increase the probabilities significantly that you may not select the vendor that best fits your requirements and needs.

What are the benefits to using this technique?  There are a number of them, and the implications are huge.

You maintain control of the demonstration.  By determining what you do and don’t want to see—and by communicating this upfront—you keep the agenda tight and focused on your needs.  These scripts should flow as if people were doing their normal jobs, except that the software vendor salesperson is showing you how you will be doing it if their product is selected.

It takes some salesmanship out of the equation.  By taking most of the demonstration down to “boring” functional items (which tie back to your business objectives), it takes away from some of the discussion of the newest features that may or may not be relevant to your business.

It will tell you whether the software vendor salespersons are winging it or really want your business.  Are they willing to work for your business by taking the time to create a terrific scripted demonstration?  Are they listening to you?  Will they listen to you in the future?  It has been my experience that they are not interested in doing a scripted demonstration.  It is much easier to do a regular sales demonstration, but it is possible that you have already seen this.  You should be interested in the meat and potatoes.  Hold the flaming dessert for later in the process, thank you very much.

It will clarify whether your business objectives will be handled by the software.

It makes the software vendor salesperson “show you.”  It provides a forum where all statements by the salesperson can be followed by “show me.”  It is impossible for the salesperson to hide in this environment.  If he is representing an inferior product, it will come out in this process.

Is it absolutely necessary to send out a Request for Proposal (RFP)?  In general, you should create an RFP when any of these conditions exist:

1. The price of the software can be negotiated
   
2. There are multiple vendors that can provide essentially the same solutions to your business and system problems
   
3. There are multiple solutions available for your business and system needs
   
4. The lowest price does not necessarily win

Think of the RFP as the intermediary between you and the software vendor.  It is the document that allows for consistency of answers among software vendors and allows each party to work from the same group of rules and understandings.  It is an ongoing interpreter between the project team and the software vendor, and will continue to be used in this regard through the final implementation.  The document sets the framework for everything that happens going forward.

What is a vendor long list and how do I obtain one?  You can’t obtain one…you have to create it.  A vendor long list is the list of vendors who survived the initial round of “tire kicking” that occurs at the beginning when your organization begins talking about needing a new software solution.

At this point, the two efforts—requirements definitions and vendor pool identification—should come together.  Significant work has occurred on both work areas.  It is highly probable that key functional requirements have developed by the folks working on those deliverables and could be included in any work documents that will be created to further eliminate vendors.

Determining which vendors will be on the long list is more of a process of exclusion rather than inclusion.  We are looking to exclude “no chance” vendors based on a high-level review of cost, functionality, technological direction, and vendor maturity.  The number of available vendors in the initial pool will drive some of this as well.  The process of going from the preliminary vendor list to the long list will be a different one if you start with one hundred vendors than if you start with fifteen vendors.  You will be much more motivated to begin striking vendors when the initial search brought in a hundred vendors.

Do vendor reference checks really work?  Mostly, no.  Many companies are unwilling to give direct, unbiased recommendations…and are also unwilling to say what their role may have been if things didn’t go as well as planned.  Also you should be aware that the software vendors are only going to give you their Cadillac implementations as references.  A better tactic is to find references that are not on the vendor-provided list.

I was recently advised to go visit the offices of my software vendor of choice.  It seems like a waste of time – what do you think?  I agree with you.  Not the greatest use of time or money.  I think you can be swayed both positively and negatively by the reactions you get from visiting their offices.  (Do you really care if the lead software developer has a clean desk or a messy one?).  I see this more as a box checking exercise.

Software Implementation Projects

How much transactional history should be converted?  There are different schools of thoughts on this…but here’s mine:  Only convert as much history as you need, not as much as you want.  This advice is contingent on your company having access to your prior system.  From a financial accounting perspective, I would bring over the current year summarized or individual transactions.  If you do prior year comparative reporting, then you will want to bring over the prior year transactions.  Beyond that you have diminishing returns.  Why?  Because the human cost of having to balance these transactions outweighs the benefits received.

Make a point to review your initial knee-jerk reaction of how much transactional history you need to bring over.  Upon reflection, the amount that you think you need is usually less than what you actually need.  Think cost-benefit.

Should these implementations have an in-house, internal project manager or an external, for-hire project manager?  Or both?  The answer to this is usually obvious.  There always seems to be somebody who has the right temperament and experience to navigate the myriad of issues and personalities.  Some key characteristics of a good project manager are:

• Calm
• Organized
• Handles difficult people and situations well
• Slightly reluctant at having the role
• Runs a tight meeting
• Is both tough and tender hearted
• Has the respect of the majority of the people to get the job done

This should not necessarily be assigned by job function.  The IT manager may not be the best person to serve as the foreman of this effort.  Base the decision on the characteristics I listed above.  An IT manager or controller who runs a lousy meeting and is obnoxious will make this effort more difficult than it needs to be.  Instead, for example, use the senior, savvy operations manager who may have no software experience whatsoever.

Consider hiring a consultant to be your project manager when:

• There are no obvious candidates within your organization
• Your organization is “tight” on resources and you don’t want to overload staff personnel
• You want an independent third party to be your project leader

I have been on a number of satisfying engagements where this role was shared.  But even in this scenario, you only want just one leader.

What should the software company’s role be during the implementation?  They should be in charge of the product at a minimum – insuring that it operates as advertised during the evaluation phase.  Some software companies have service divisions that help during the implementation.  This help can come in the form of data conversion services and/or training.  For larger and more complex implantation efforts, I would be wary of employing them to run your project.  You will want an independent or in-house person to be in charge of your project.  At the end of the day, the employee of the software company will be representing his company…not yours.

Are canned implementation work plans available for purchase?  Yes, they are – but not from us.  The reason these canned plans are not a good idea for you is that EVERYBODY’S implementation is different.  Do not accept a software vendor’s canned work plan.  If you do this, you will be fitting into their way of implementing rather than insisting that they custom their approach to you.  Canned work plans are good idea as a starting point for creating your own custom plan.

Do you recommend a manual/data entry process for data conversion or an electronic approach?  It is a function of the number of records to be converted.  If it is a ‘small’ number, then a manual approach is a consideration.  The ultimate answer will depend on the time cost of creating the electronic conversion protocol versus the benefit received (time not spend doing it manually).  Having said this, our preference is electronic.  With the tools available today, this is usually the right call.

Our company is concerned with our operations grinding to a halt while this software migration effort is going on.  What do you suggest?  Good for you – you should be concerned.  A way to think about this is to equate the software implementation to a highway construction project.  You have to keep the traffic moving while you build the new highway.  Orchestration is a key concept to remember.  You want to orchestrate the go-live procedures and process as many times as you need to prior to the actual ‘switch-over’ date.  This methodology will reduce risk and anxiety, and will additionally reduce the amount of down time as you migrate to your new system.  Bottom line – there are proven tactics and techniques for these software implementations.  Your operations should not grind to a halt.

Have you ever participated in a software implementation that failed?  No, but I have had them be more difficult than they needed to be.  Watch this video – this is the presentation I give at the beginning of every new engagement.

When a software selection project falls out of the sky and onto your plate, you need a strong heart, a sharp brain, and the courage to tackle the task.  This is the book that provides all three, and more.  It is a clear and methodical map through the unclear and needlessly chaotic process of software selection.

Click Here
To Learn More About The Book