Internal Discovery: Needs Analysis

First, discovery is both internal and external. Unfortunately, many businesses short-cut the internal work and open themselves up to vendors much too early. Two common reasons for this are – “we’re just fact finding” and “we just don’t know what questions to ask or even where to begin looking.” This direct contact with product vendors, however, means marketing packets, wordy emails, relentless phone calls, demos, and much more – they know who you are and have entered you into their database. How long do you think it will take before you’ve reviewed so many systems that your eyes get glazed over, or the water gets muddy?

It may help to view this as the equivalent of visiting the pharmacy to inquire about medicine but skipping the doctor visit to get a skilled, guiding prognosis. It’s important to “diagnose” the symptoms, hear from those impacted by any change, hear from knowledgeable resources, etc.  Do this BEFORE allowing hungry, commission-based salespeople (biased pharmaceutical reps) access to your TIME and RESOURCES. In doing so, your efforts will establish a Needs Analysis document that will guide you through a sea of software solutions on the market while filtering out those that really don’t meet your system requirements. One of my favorite sayings is “Proper Planning Prevents Poor Performance.” Be diligent, and don’t skip this preparation step.

Below are a few Needs Analysis steps to consider:

• Ask some initial questions:
  • What exactly is the problem(s) and when did it begin?
  • What has been done to resolve the issue(s) and why hasn’t it worked?
  • Who is most impacted and how?
  • Can our current software vendor reasonably help us resolve things?
  • What costs are associated with this problem?

• Talk to others:
  • Pull together internal staff that is impacted by the problem(s).
  • Call your software vendor or local consultant.
  • Post information about the problem(s) on user community sites.
  • Search the product knowledgebase, if applicable, for resolutions or work-arounds.

• Document:
  • Information from internal staff.
  • Feedback from those solicited externally or online.
  • Format findings into a categorized system requirements list.

To read full Blog post and/or comment, visit - http://blog.solutionexplorers.com/