Vendo
rs will define scope at the highest level possible to avoid contractual problems during the implementation. Ideally scope is defined at a low level (the requirements in an RFP) but vendors will resist this partly because they would now be contractually responsible to implement detailed requirements that may turn out to be more challenging than initially thought.
So, if vendors are willing to define scope at the requirements level, they need to spend a lot of time during the sales cycle to make sure that they can actually do exactly what is required. They will try to qualify their response to requirements with wording such as “any changes to standard functionality will require additional work”. So, there is a battle between the vendor and the prospect to nail down the scope. The prospect does not want surprises during the implementation that lead to increased costs. The vendor does not want to spend a huge amount of time during the sales cycle (not paid-for time) to nail down scope or disclose missing functionality. The vendor will say that the scope will be clearly defined during their discovery or blueprinting phase of the implementation. The trouble is that there could easily be more costs when this happens. What do you do?
We recommend that you identify all the requirements for which the vendor has either excluded from scope or qualified their response enough to render it not contractually required – let’s call these gaps. If you have lots of gaps, we recommend that you segregate them into critical and non-critical lists. Get the vendors to nail down the critical gaps during the sales-cycle but wait until the blueprinting phase to nail down the non-critical gaps. Non-critical gaps should be implemented only if there is a business case to do so.