Three things wrong with your ERP RFP

Operational requirements serve as a critical Bible when developing an ERP request for proposal (RFP). As the old Yogi Berra baseball saying goes; “If you don't know where you are going, you'll end up someplace else”, and this sensitivity tends to be particularly specific when dealing with enterprise-invasive resources technologies.

Consequently, folks who have never considered the creation and evolution of a substantive RFP tend to believe that these documents need to encompass everything under the sun, when many times more is less. As a result we though we might offer three ways that an ERP RFP can go wrong, while also providing for a couple of alternative approaches to any problems.

1. Measure twice, cut once

The axiom above applies to virtually everything associated with ERP requirements. By their very nature these RFP documents are complex, and prone to intellectual overreach, particularly when adding task elements associated with a plan’s outline.

Recommended reading: plan and write your ERP requirement document with our guide to creating the perfect ERP RFP.

Part of this problem is based on general characteristics associated with ERP as a technology type, since it tends to attract detailed investigation when, instead, common sense is sometimes the better approach. Additionally, however, while the systems themselves offer intellectual challenges, the people doing the work are sometimes more concerning.

Clarity associated with either of these questions resides in the vein of practicality, since you want everything “useful” to be included, but no more than “necessary.” So, in the end of the day, this tip can save a lot of time and sweat by simply checking and re-checking your ERP RFP outline before you send it off the printer, and on to the enterprise distribution list.

2. Primary, secondary, or tertiary; choose one

This tip applies as a subordinate element but still applies to the axiom above. When breaking down various section tasks be entirely sure that “only” primary areas of investigation apply in the majority; and only secondary areas of interest in the event that they are clearly critical to an understanding of the goal of the final requirement.

For example, when considering the scope of various database structures, the total number of required tables may be applicable however; the number of characters within each record in every table is not. So, again, don’t throw everything at the cesspool when the only required element in your plan is the sink.

3. Avoid fat while trimming for impact

Again, this applies to the ‘common sense’ approach to your ERP RFP development. Suppose that you have completed your RFP draft and you think that everything included is necessary to reach you’re planning goal. But here’s the rub, the document still feels ‘fat’, and on further reading, the stated requirements seem “soft” and non-compelling.

In this case, there’s a simple workaround. Yet like everything else in technology, more times than not, ‘simple’ tends to be a lot harder than one might think. So, first clarify and confirm your goal-sets, with an eye toward being entirely comfortable when defending any critical part of your plan. If you can’t, re-work it until you can.

Next, when you complete the previous review evolution, re-validate and remove, if necessary, any task section or element that does not directly support your re-worked plan rationale. After all that, you should understand the ins and outs of your strategic and tactical thinking to the degree that your plan is going to be pretty bulletproof and ready for prime time.