The art of the RFPBy Katrina Burke, Oxygen, a DXC Technologies Company on
In this blog I want to cover off the importance of defining business processes and project scope accurately in the RFP. In order to mitigate risk and ensure a high level of confidence in the proposals, organisations need to know what is critical and what questions to ask system integrators (SIs). I have witnessed SAP projects where the initial timeframe and budgets have been severely challenged. This, of course, can be attributed to many factors, however, one way to mitigate this risk is to ensure that expectations, scope and complexity are clearly articulated in the RFP.
Be specific when defining business processes
What often comes back to haunt a business in the delivery phase of an IT transformation is the RFP’s lack of specificity with regard to all the processes that will be impacted by the project. In the worst case scenario this may result in the contract not being sufficient to deliver everything that the business needs to achieve, which in turn, means readjusting budgets to make up for the shortfall.
Take procurement as an example. There is a standard out-of-the-box solution for procurement, which unless stated otherwise, SIs will put forward and price accordingly. However, what if each division of the organisation in question does procurement differently and the processes can’t be changed because they have been legislated by law to be a particular way? If that knowledge is imparted in the RFP, the SI will put forward a much more nuanced proposal with more time and cost built into the areas where perhaps custom processes need to be considered.
The effort and time that is allocated to building out a process is heavily dependent on the complexity of the process. The more an organisation can articulate the complexity of the process, the more accurate the market responses will be.
Many RFPs these days stipulate ‘standard best practice process’ or ‘adherence to out-of-the-box process’ and this is an excellent approach, however, organisations should be prepared for what this means during delivery. If a given process in the business cannot be delivered using standard SAP models, this will likely be raised as a development (part of a WRICEF list) and can lead to a variation in cost. To ensure adherence to best practice, some very rigorous governance structures need to be applied to assess and approve non-standard processes and hence keep the project on budget and time. (I will outline a suggested process in a future blog).
Failure to be specific will end up costing money, or even worse, the SI will fail to deliver what is needed because the solution put forward cannot accommodate the variation that is required. Being specific around business processes ends up ensuring the right software solution is selected from the start – hence it is extremely important to get right.
Cloud v on-premise
This is particularly true when organisations go to tender for cloud solutions, because they tend to be fixed solutions with very little flexibility to accommodate custom processes. SAP’s on premise ERP solution has 20 years’ development behind it and can be adjusted to do almost anything an organisation wishes it to do. But companies should be cognisant that that isn’t the case with cloud solutions. They are unlikely to have the flexibility to meet specific and complex business requirements.
In my next blog I will discuss how an organisation should approach its tender document in order to mitigate that problem, and talk about the best way to handle scope creep – something that needs to be considered at the RFP document stage.