With regards to selecting software, there can be a slightly different approach depending on what problem the business is trying to solve. For example, if the problem is very discrete, then selection can be straight forward. The larger the problem, or the more departments it touches, the more complex the selection process should be.

Software selection needs to cover requirements in the following areas:
1. What business problem(s) needs to be solved?
2. For each problem, does it matter the manner in which it is solved? If so, define the ‘how’ as separate requirements.
3. Where is your business going next and what software tools do you need to accomplish this? This one can be a bit hard to define in detail since it is a future rather than current issue, but the more detailed you can be, the more certain you’ll be that you selected a solution that can grow with the business.
4. Infrastructure and technical requirements – do you need or want a cloud solution? Do you need something that runs on Linux? Need to support older versions of operating systems? These items are different from the business goals, but do speak to the state of the business and so shouldn’t be ignored.
5. Consider integration requirements. Does the new software need to ‘talk’ or exchange data with existing systems?
6. Consider vendor services. What services can the vendor provide in order to ensure success with the new system? This might mean data conversion services, training, custom programming, ongoing support, etc. Some vendors only sell software and bring in a third party to provide services. If this is an untenable situation for you, then it needs to go on the requirements list.

Keep in mind that requirements shouldn’t look like a features list. A features list, in addition to being a vendor’s marketing tool, is a much looser description of a concept. It lacks the general intent and detail of a software requirement.

As you well know, this topic warrants more than a few hundred words, but I’ll leave it there and let others have the floor!

M Scott Schaffernoth

Chief Tech Coach, Winnovative Technology Consulting, LLC

Posted on Aug. 31, 2011

Recommended by:
Antoine Fournier

In addition to the above, you also want to get all of the people involved at the table so that you establish a clear definition on what all of the "departments" agree are the requirements.

If you attempt to implement a system with a top down approach, the users will resent their lack of input and submarine the effectiveness of process and user adoption.

Bill Wood

President, R3Now Consulting

Posted on Aug. 31, 2011

I have written an entire series on the whole software and vendor selection process. Although the title is about SAP / ERP it also applies to nearly any enterprise application and vendor selection...

==========================

Overcome SAP-ERP System Integrator Sales Tactics parts 1 through 7

http://www.r3now.com/overcoming-sap-erp-system-integrator-sales-tactics-1

http://www.r3now.com/overcome-sap-erp-system-integrator-sales-tactics-2

http://www.r3now.com/overcome-sap-erp-system-integrator-sales-tactics-3

http://www.r3now.com/overcome-sap-erp-system-integrator-sales-tactics-4

http://www.r3now.com/overcome-sap-erp-system-integrator-sales-tactics-5

http://www.r3now.com/overcome-sap-erp-system-integrator-sales-tactics-6

http://www.r3now.com/overcome-sap-erp-system-integrator-sales-tactics-7

==========================

As an example, from PART 1 of the series, after the introduction, here are some of the first steps:

(OUTLINing is not working so well... but you get the idea)...

•Establish a Steering Committee
•Define Near Term and Long Term Objectives
•Determine interface requirements
◦Which system(s) do you want to replace
■ What are the license and maintenance cost considerations
◦Which systems will stay
◦Which systems may need to be modified because of the change
◦Which systems will need interfaces
•Refine Scope with Complex or Exception Processes (see the POST LINK on Using SAP Solution Composer for SAP Scope – Process Alignment)
•Evaluate the need for “traditional” third party software (taxes, EDI, fax or e-mail integration, etc.)
•Confirm software and hardware budget estimates
•Select a Project Team and a Project Leader
◦Define Authority
◦Engage them in the scope and selection efforts
•Create a Review Process

Art van Bodegraven

President, Van Bodegraven Associates

Posted on Sept. 1, 2011

In addition to all the above, I'd suggest a hard look at process design/redesign specifics to get early reads on where software née to be adapted and where process might (without sacrificing process execution effectiveness) need to be modified. The process and technology components of the equation, at minimum, must be part of an integrated whole.

In parallel, in addition to getting affected departments involved, I'd strongly encourage targeted (and thoroughly planned) employee/team development and communications initiatives. These are independent of, but integrated with, the software and process efforts to leverage new capabilities for sustained accomplishment.