Every
now and then, I see posting in a LinkedIn group asking for software
recommendations for some particular business category.
Let's
be real for a moment - if there are 100 software options available, maybe half
of them can work for any particular company.
The recommendation that you receive could be for an option that won't
work for your business.
Start with your requirements
I
have come to this position from my experience.
If you start with your requirements, you will not be looking at software
that doesn't really fit your business needs.
And, your requirements may get you looking at solutions that fit your
business better than others.
A
while back, I worked with a company that implemented proprietary software for
their email solution at a time when there were many cheaper, easier
options. Once they spent the money on proprietary
software, they didn't want to dump it [lose the investment] for one of these
cheaper, easier solutions. So, today
they continue to spend money for maintenance and customization.
Mitigate
your risk
Any
company can end up purchasing a solution that is not the best fit. A good first step to mitigating risk is to
start with a requirements document. You
will be able to ask more informed questions of your potential suppliers. You will be better equipped to make sense of
their answers. You will increase your
chances of making a better decision.
Your Thoughts...
What
has been your experience?
Scott, I must say that most of the requirements documents I see are a waste of time. I received one last week from a large government agency. It had all the standard boxes that needed to be checked - do you have this..do you have that. This laundry list mentality of purchasing software seems to completely overlook the fact that the reason some software is better than others is often not a factor of having more features. Rather, it has to do with design. We seem to better understand the importance of design when we buy most other goods, especially consumer goods and even consumer software. So why are we so unable to understand that design is just as important if not more important for enterprise software.
http://successfulworkplace.com/2013/01/24/a-fool-with-a-tool-is-still-a-fool/
Precisely why I wrote this after seeing nonsense being posted from an SI.