In the December Issue of Innovative Thinking, we gave some of our predictions for the New Year. Starting 2007 with this issue, we continue to sharpen our focus on ERP Done Right - with an explanation of RFP vs. RFP - What's the difference and why should I care? We'll be offering a series of articles aimed at providing you with the best practices to achieve the best results. Stay tuned. You won't want to miss a single issue!
Don't miss our What's new section. We're getting great feedback on the WORD SCRAMBLE feature.
RFP vs. RFI - What's the difference and why should I care? By Paul Sita, Principal, Innovative IT Consulting, LLC. Paul can be reached at 631-549-1685 or email@example.com.
All consultants use RFPs - don't they? One of the frequent questions we get from clients looking for an ERP package is the difference between an RFP (Request for Proposal) and an RFI (Request for Information).
They assume that consultants always recommend RFP’s, well because, that’s just the way they think consultants work - with lengthy documents full of checklists and checkboxes, designed to eat up hours and cost them $$$$.
I’m happy to report that this is not the case! We don’t recommend RFPs. We rarely use them. And it isn’t because they take too much time. It’s because RFPs don’t lead to good results. It is increasingly difficult to get quality vendors to respond to RFP’s. It doesn’t give them sufficient opportunity to really communicate their strengths (and for you to determine their weaknesses!) so in many cases if you commit to the RFP process you may be defeating your purpose by excluding the best potential vendors.
The old way. Traditional RFPs were designed to query vendors about every aspect of their system, designed to “catch” them and trip them up about features and reports that the client needed. This was useful at a time when packaged software was still an immature industry and every package had some functionality, but was lacking in other areas.
Most of the modern ERP systems do all the basic things. On this checklist approach, many of them rank quite well. But what does that mean to you, the client looking for the right ERP solution for your organization?
Our approach. The Innovative Approach uses the RFI as a tool for focusing on client-specific needs and to establish a dialogue with the ERP vendors. It’s part of our collaborative process that we call Knowledge Sharing.
The How is as important as the What. It’s much more important to get into “deep discussion” about those aspects of your business that are really unique and competitive differentiators for you, than engaging in dialogue about things that all vendors can handle. It’s much more important to see how vendors engage in dialogue, what caliber of personnel they employ, and how flexible they are to determine what sort of a business partner they will be. Vendors are smart. They don’t want to waste time with clients who may not be a good fit for them – and by employing a well constructed RFI, they know that we will find out quite quickly if they have a good fit.
Finding the right partner, not just the right solution. Also, the key differences between ERP solutions can’t be ascertained on “static” pages. Differences in user interface, ease of use, layout of information - are all key differentiators, and clients will react differently based on any number of factors. We have been involved in situations where a solution “rated” very well, but the client couldn’t stand the vendor’s personnel, making them a bad choice.
The RFI is part of the screening process. Information from the RFI is used to SCREEN OUT vendors, not make choices. The RFI is a screening tool, and a vital part of the communications process. It establishes the dialogue and provides a framework for proceeding. The RFI can help eliminate vendors from the process, it can’t be used to select a vendor.
So what's in the RFI? It contains enough information about the client and situation so that a vendor can understand the business situations and drivers for an ERP project.
It contains enough information about company-specific requirements that are MINIMUM and MANDATORY requirements, going beyond the what in many cases to the HOW. These requirements have to be spelled out in a relatively few pages (8-10) so that vendors can do their own assessment of their fit, ask intelligent questions where appropriate, and respond without an excessive investment of time on their part.
It clearly spells out what our process, time lines and decision points are – to facilitate the vendors deciding if they want to participate in our selection process, and if so, what’s required of them and when.
Lastly, it contains enough information so that a vendor can provide realistic budgetary estimates about their solution based on license counts, users by functional area, short term/long term, support costs, hardware required, 3rd party licenses required, etc. These are not “negotiated numbers”, they are usually list prices, although a vendor may sometimes indicate that an XX% discount is typical. This information is used to compare at a high level, the various solutions.
Summing up. So there you have it. The RFI is the right tool because it puts the focus squarely where it needs to be – on you the client, and your specific needs. Failure to fully uncover and articulate your key requirements is one of the reasons for ERP project failures and cost over-runs. (Not having a good consultant leading your ERP selection process is the second most critical mistake that clients make. Smart people armed with a checklist is no substitute for experience. For more information or assistance with your ERP project, call the experts at Innovative.)
RFP or RFI? Not a contest! RFI is the winner by a knockout!
Why are project deadline dates missed?
By John Pellegrino,Principal, Innovative IT Consulting, LLC. John can be reached at 631-549-1685 or firstname.lastname@example.org.
This is a frequent question for many large projects, especially in the IT industry. Although the whole answer is dependent on many factors I will discuss one simple, yet often overlooked, item that will reduce the risk of this significantly.
In order to accomplish a large project we often break it into phases, each with its own deadline date. Typically these are called milestones. After defining these we break the phase into smaller, manageable tasks that will get us to the milestone. Then we start doing the tasks. But we need to ask ourselves one more question as we do the task – is the task being done in a way that is consistent with the milestone we are trying to meet?
An example will serve to highlight this point. During the software selection process we gather requirements in order to produce a request for information (RFI) from vendors (see our main article). As we discuss these requirements with various people in the organization do we need to know the fine details of exactly what they want to see on the data entry screen? No, this is not needed until implementation. If we allow this level of detail discussion to occur at this time it will lengthen the time it takes to perform the task. If this happens more than a few times, we run the risk of missing our deadline!
Stay focused on tasks that lead to the completion of the current phase’s objective and milestone and perform those tasks in a way that leads to a timely completion.
Join the blogging community - there's a lot in it for you. (see links below) We won't stop trying to get all our visitors to comment. Your voice is critical. Ask your questions, and offer your opinion. Don't forget to sign up and get updates delivered right to your in box.
Word Scramble time.
“A process of eliminating potential vendors from a software selection process. (1 word)
_ _ _ _ _ _ _ _ _ N R C E I E S G N
Answer to last month's word scramble.
“A practice of putting a variety of common software modules and options together." (BUNDLING)
In February we'll continue ERP Done Right with a focus on Scripted Demos.
We want your feedback. Contact us