How NOT to write a SharePoint RFP or RFQ
Let’s say you need an intranet, public facing portal or similar project. Let’s also say you’re the lucky manager that gets tasked with directing the outsourcing of the project.
“No big deal,” you say to yourself. You’ll Just:
Gather some input from several of the involved department managers
Knock out a multi-page description of the project
Attach 15 pages of required purchasing terms and conditions
Launch it to 3 or 4 qualified organizations and pick the best response on the basis of price.
Piece of cake, right?
After all, you only distributed your SharePoint RFP to developers or agencies with established credentials and everyone you’ve spoken with has told you this is the way they do their outsourcing.
Unfortunately, you’ve just entered the land of “self fulfilling prophecy” and, odds are, you’re not going to like it.
What Happens Inside the Companies that Receive your SharePoint RFP?
They open and read the RFP. They completely understand the 15 pages of “purchasing terms and conditions”. This is all about billing cycles, required insurance, etc. Nothing vague here. Then they read the description of the project… It’s 3 pages of goals, dreams and wish lists with phrases like:
Design must be “edgy”
Must automate some forms.
Must migrate legacy shared files
Must include training
And on and on…
At this point, the odds of you getting what you need disappear. Here’s why…
The descriptions, while helpful, lack the detail required to accurately size the engagement.
The statement about automating the forms could mean anything. (From a simple four-line contact us form that submits to a list, to several multipage forms with automated lookup fields connected to support lists with results submitted securely to a list via a custom Web part.)
The element about training, omits the number of people to be trained, the level of competence to be attained and the manner of verification.
Migrating the legacy shared files into a SharePoint environment is a common endeavor, but the lack of detail surrounding storage requirements, content types and destination library structures makes accurately sizing this component of the project impossible.
Developers are Faced with a Dilemma
Without the level of detail that only a true project specification could provide, the developers that will bid on this project are faced with a dilemma.
They could create a detailed list of questions and send them back to the offering organization.
They could guess, based on experience.
Regardless of the approach they take, their cost estimates will suffer from the lack of a truly detailed specification.
And then the bids come in…
The pricing is all over the map. Some offers are 4 times the cost of others!
You know something’s wrong, but what can you do, it’s a legal process and you’re in the middle of it, you have to see it through.
You select one of the lower offers from a “real” company. You think this is the best path. It may be but the odds that you’ll be happy with the results are very low.
Enter the “Self Fulfilling Prophecy”…
The company you selected proposed a fixed price for the project and now they meet with your team and begin to develop the first detailed project plan.
Odds are, as they were one of the lower bidders, your needs will exceed their estimates. If they do, you’ll start to experience a subtle shift in direction on several key tasks. The level of automation and scope of these tasks will be reduced to fit the budget. When the project is completed the resulting site will require a higher level of manual participation by staff. The user experience and available site features will have been diminished from the original vision.
The final result could be a failure of the business initiative, or an expensive “repair” by a second, and sometimes a third, developer.
The lesson here is that a developer will develop to the proposed SharePoint budget NOT the requirements they learn about after winning the bid. It’s either that or they go out of business. (They could raise “out of scope” objections or talk about “phase two implementations”, but that’s another blog.)
The Answer…
Always break your project into two projects:
Creating the detailed specification
Building to the plan
This may seem like twice the work, and potentially twice the cost, but actually it’s LESS.
You use your original SharePoint RFP, exactly as it was written. But, you use it to solicit for the development of a detailed project specification and blueprint. Set a budget for this specification, and announced what the budget is. (You might think in terms of dedicating 10% of the total project budget to creating the specification)
Once you have the detailed specification and blueprint, you add your purchasing and legal terms and conditions to it, and put that out to bid.
The benefit of having all of your bidders working from a far more detailed document will be apparent in two ways:
There will be a far narrower price range in the bids offered
The cost of the implementation will be reduced because the vendor will be starting with a detailed specification.
The net result of taking this approach is that you will dramatically increase the odds of ending up happy with the result.
The moral of the story is that most IT projects require two steps for the solution:
Development of the plan
Implementation of the plan
Make sure they are priced separately, if you want to be successful.