Pages

Friday, February 6, 2009

No Terms of Reference? What you need before writing an RFP

In an ideal world, procurements would have a business plan and clear terms of reference (TOR) document prepared prior to developing and issuing a Request for Proposals (RFP). Procurement professionals realize the upfront planning makes for smoother outcomes from the competitive process, not to mention proactively dealing with potential risks that would affect the resulting contract.
However, due to the size and spread of public sector organizations (and some large private sector organizations), this procurement planning phase may be condensed into 'developing the RFP'. One large organization measured their centralized procurement arm as managing merely 2% of the overall organization spend, meaning the remaining spend came from people not specifically trained in procurement, but those who may be attempting procurement "off the side of their desk"! Not that every business plan/TOR can foretell the future, but it does provide better information to your vendor community to provide a quality response!

I've been called to review/assist with RFPs where there "wasn't enough time to do a full business case/terms of reference". So, the following are some base items help focus and pull something together 'quickly' for situations where there is a 'real' deadline (disruption of service impacting third parties, or life/death situations).

1) Where are you now? with respect to the desired product/service

(eg. you have absolutely nothing;

been using X which is 3yrs out of date, or

current product doesn't provide YZ).


2) What is the 'current situation' - what issues do you want/need to have resolved; or have you been handed a new mandate, goals hoped to be achieved (not necessarily just for the product/service you are buying but the greater goals that trickle down to affect this particular need).


3) Where do you want to be – what is the vision for moving from the current situation? What is it this product/service will help create? A bigger picture will assist vendors in understanding where they 'fit in' - don't limit it to just "provide software that does xyz", put it as "improve access to information", or "save time for clients to ...."


4) Timeframe/budget - whether you publish the budget or not, the budget will determine complexity, trade agreement requirements, legislative/regulation requirements and/or approvals required before entering into a contract.


5) Project limitations - is there something you are NOT prepared to have included (if so, state it up front).


6) Deal breakers – what would make you toss a proposal eg. due to Canadian FOIPPA legislation, you won't consider personal data stored in U.S.; or you won't consider a licencing agreement, and want full copyright, etc...if there is something that you will absolutely not consider, you need to tell the vendors up front, in Canada at least, you could face being sued for 'hidden preferences' if not stated upfront!


7) What "resources" do you have available to the contractor - let them know upfront if you have a project team available to work with them, or steering committee they need to report to, or ... I've had vendors create a project plan expecting client approvals within 3 days and the client couldn't possibly do that - it would have helped had the client stated this limitation in their RFP up front, and vice versa, let the vendors know if there are internal resources for some tasks/requirements so vendors aren't quoting those within their price.


8) What will get you from here to there - in order to get from your current situation to where you want to be, what do you require at a minimum? What do you absolutely need to have, what is a 'nice to have'?

9) What information do you need to see in order to know someone has what you believe you need to get from here to there? (look at your list in item #8)

10) Do you have a project timeline for yourself on this - when does this need to be implemented by, and what is the estimated time you believe a vendor would need to implement (meaning the date you need to start the contract)? From there you can work back the RFP timelines (ie based on contract start date, consider amount of time for contract finalization with the lead and that becomes your RFP closing date; from that date, determine how many weeks vendors would need to provide a response and that becomes your RFP posting date, now you have a deadline to finalize your RFP drafts!!!


Generally, in the absence of a true business plan/terms of reference document, having the above figured out makes it much easier to draft a better RFP. You can certainly research other jurisdictions for what was done for their need, but avoid copying other requirements and terms. Not all situations are the same, nor are policies/legislation/contract law the same between jurisdictions!

Remember the proverb "failing to plan, is planning to fail".

No comments: