by J David Childs

Created on: September 20, 2011

Many organizations will make most purchase decisions based mainly on the talents of the sales person presenting the product, service, or application. For example, Enterprise Resource Planning (ERP) software applications are often procured and then subsequently forced into the
organization for employees to adapt to the application on the fly, rather than the application supporting the desired process enhancements to the

organization’s business. After some time and internal angst, the organization will often abandon the application, stranding the investment.

So as to mitigate the extreme of stranding a capital investment and minimize negative impacts to changes in business processes, spending the time to document business requirements and existing process workflows, will not only support purchase decisions of software applications such as ERP, but help identify where process improvements can be made by leveraging the new application.

Business requirements should be documented to not only codify what the business users want the application to support in the future, but even the most obvious functionality, such as applicant tracking, or even the general ledger, that is core to the current specific business process.

Requirements should be very detailed and clear to all stakeholders involved in the development, implementation, and subsequent changes. While it is tedious, more details using fewer words, translating to more requirements is more effective than lengthy requirements combined. Be specific and to the point.

Just as important as clear and concise requirement statements are workflows. The first set of workflows is that which represent “As Is” processes. Similar to requirements, granularity is important. This may translate to more workflows, i.e., processes within processes, but the outcome is clarity and understanding by all stakeholders. Similar to requirements, more is likely better.

Documenting business requirements and workflows also support any type of project management methodology after the procurements, including iterative development methods. Some may argue that such documentation is not necessary, but upfront clarity is much more effective and efficient than managing change control processes, especially when customization requires significant coding efforts.

In closing, documenting business requirements and workflows will provide the support for an intelligent and informed purchase decision, as well as set the baseline for development needs. Every stakeholder will know what to expect. That is, what is functional in the application, what workflows are impacted, i.e., how the business will be run the same and what will be different/enhanced, and what functionality remains to be coded.  Further, implementation with the right application will make such changes much more efficient with documented preparation. With the proper documenting, purchasing and implementing has less impact to the budget, as monies are used wisely, and to productivity during the transition.

Learn more about this author, J David Childs.
Click here to send this author comments or questions.