In my earlier post on this subject, I outlined Step One, “Assess, then Search.” The idea is to build a frame around the search to help limit the distractions by irrelevant solutions. Once your needs assessment is complete, what do you do with the resulting list?
For Step Two, the actual product search phase, I will explore some of the self-created risks many software buyers face during this important decision process as well as how to work through them.
What is on your technology shopping list?
A thorough needs assessment will guide the initial shopping phase, whether you issue a Request for Information (RFI), search key terms on the Web or seek referrals from other organizations who use similar software. Many use a detailed checklist that moves from general feature to specific function to narrow the list to a select few.
The essential features and requirements should be there, but do not hesitate to add your wish list of nice-to-have features as well. You may not be aware of what is available and if you do not ask, you may never know what you can have within your budget. Most large businesses use a comprehensive matrix of questions and answer spaces, often provided in Word or Excel format to allow the responding vendors to fill in their answers.
One mistake that many purchases make is to become too wedded to their list. As you learn more about what is available, your feature list may evolve and mature. If your needs change, there is nothing wrong with changing what you ask of the prospective vendors. Never be afraid to throw out the information gathering results and start over or at least send out a second round of questions. The vendor needs to earn your business and it is their job to sell you, not the other way around.
When I was pitching software, it was nice to find prospective customers who actually sought unstructured input and suggestions on thorny business needs. Whether in the RFI or during a sales presentation, find a way to open the discussion to allow creative problem-solving with the vendor’s professional staff (not simply a sales executive who may promise you anything to get the deal).
Make sure your checklist addresses these vendor qualities in addition to your software feature needs:
-> Customer Satisfaction with the product AND the company – What do their customers say about each? How willing are they to give you names?
-> History of providing update communications – How well do they alert customers about known issues before the customers report them? Or do they pretend each report is an amazing discovery they have never seen before? (See also, "Is Your Software Vendor Your 'Friend'?")
-> Business maturity – How long has the company been in business and in the software business? How sophisticated are their developers and product design professionals? Who drives development, the Sales department or a professional software design expert?
-> Market focus – How many customers like you do they already have? What do they know about your industry or business model?
Who is on your product selection committee?
Whether you have an IT Department, a single Network Administrator or an outside consultant, make sure you get sound advice and input from your trusted tekkie who is up on current tech standards and trends. Technology changes rapidly and the accepted guidelines from even two years ago may no longer hold. Technical input is crucial to ensuring that your investment will not fall apart under everyday usage.
At least as important, however, are the actual users. IT can guide you, but be aware that they often look at software purchases in terms of how much trouble the product will be to install and maintain, not how well-suited it is to your business operations needs. IT, for example, may prefer web-based solutions because they are easier to deploy and maintain. Users, however, may need more power at the desktop level or off-line capabilities. Who wins a stand-off in that situation? Do the needs of the many outweigh the needs of the few, or the one? On the otherhand, users tend to want products that are not much different from what they already have or know. Ease of use is an understandable demand, but fear of change may color their input and pull you away from a product that will help you grow and expand for years to come.
The software vendors will play to the power on your selection committee. If they see that as IT, you can expect pitches that tout the technology “under the hood” and back-end qualities such as the application product interface (API) rather than features in the user interface or usability. If the vendors sense that users are at the helm, then you should hear more about ease of use, simplicity and configurability for the users and less about reliability, stability or technological limitations. Let them know right away that power is balanced between IT and users, even if there is a chief decision maker in the event of a tie who will consider both sides’ needs and input.
In the final post in this series, I will cover the evaluation phase.
For Step Two, the actual product search phase, I will explore some of the self-created risks many software buyers face during this important decision process as well as how to work through them.
What is on your technology shopping list?
A thorough needs assessment will guide the initial shopping phase, whether you issue a Request for Information (RFI), search key terms on the Web or seek referrals from other organizations who use similar software. Many use a detailed checklist that moves from general feature to specific function to narrow the list to a select few.
The essential features and requirements should be there, but do not hesitate to add your wish list of nice-to-have features as well. You may not be aware of what is available and if you do not ask, you may never know what you can have within your budget. Most large businesses use a comprehensive matrix of questions and answer spaces, often provided in Word or Excel format to allow the responding vendors to fill in their answers.
One mistake that many purchases make is to become too wedded to their list. As you learn more about what is available, your feature list may evolve and mature. If your needs change, there is nothing wrong with changing what you ask of the prospective vendors. Never be afraid to throw out the information gathering results and start over or at least send out a second round of questions. The vendor needs to earn your business and it is their job to sell you, not the other way around.
When I was pitching software, it was nice to find prospective customers who actually sought unstructured input and suggestions on thorny business needs. Whether in the RFI or during a sales presentation, find a way to open the discussion to allow creative problem-solving with the vendor’s professional staff (not simply a sales executive who may promise you anything to get the deal).
Make sure your checklist addresses these vendor qualities in addition to your software feature needs:
-> Customer Satisfaction with the product AND the company – What do their customers say about each? How willing are they to give you names?
-> History of providing update communications – How well do they alert customers about known issues before the customers report them? Or do they pretend each report is an amazing discovery they have never seen before? (See also, "Is Your Software Vendor Your 'Friend'?")
-> Business maturity – How long has the company been in business and in the software business? How sophisticated are their developers and product design professionals? Who drives development, the Sales department or a professional software design expert?
-> Market focus – How many customers like you do they already have? What do they know about your industry or business model?
Who is on your product selection committee?
Whether you have an IT Department, a single Network Administrator or an outside consultant, make sure you get sound advice and input from your trusted tekkie who is up on current tech standards and trends. Technology changes rapidly and the accepted guidelines from even two years ago may no longer hold. Technical input is crucial to ensuring that your investment will not fall apart under everyday usage.
At least as important, however, are the actual users. IT can guide you, but be aware that they often look at software purchases in terms of how much trouble the product will be to install and maintain, not how well-suited it is to your business operations needs. IT, for example, may prefer web-based solutions because they are easier to deploy and maintain. Users, however, may need more power at the desktop level or off-line capabilities. Who wins a stand-off in that situation? Do the needs of the many outweigh the needs of the few, or the one? On the otherhand, users tend to want products that are not much different from what they already have or know. Ease of use is an understandable demand, but fear of change may color their input and pull you away from a product that will help you grow and expand for years to come.
The software vendors will play to the power on your selection committee. If they see that as IT, you can expect pitches that tout the technology “under the hood” and back-end qualities such as the application product interface (API) rather than features in the user interface or usability. If the vendors sense that users are at the helm, then you should hear more about ease of use, simplicity and configurability for the users and less about reliability, stability or technological limitations. Let them know right away that power is balanced between IT and users, even if there is a chief decision maker in the event of a tie who will consider both sides’ needs and input.
In the final post in this series, I will cover the evaluation phase.
No comments:
Post a Comment