Is Your RFP a Recipe for Disaster?

Is Your RFP a Recipe for Disaster?


Just like cooking, building the perfect company portal is a TWO step operation. Developing the recipe, then following the recipe.  Unfortunately too many “cooks” charge and start cooking.  Without a recipe to follow you’ll likely end up something inedible.

In this instance, as middle management, you are given the task of managing the outsourcing of your organization’s public facing portal. That’s easy enough right? You’ll Just:

• Gather some input from several of the involved department managers
• Knock out a 3 or 4 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 may have just written yourself a recipe for disaster.

What do Companies See when they Read Your RFP?

First of all, companies you send your RFP to 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 6 forms
• Must migrate legacy shared files
• Must include training
• And on and on…

 Without A Recipe, How Can You Predict The Result?

• 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 multi-page 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.

To Wing It, or not To Wing It?

That is the question. 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 the developer takes, their cost estimates will suffer from the lack of a truly detailed specification.

Did You Want Beef or Fish?

The offer for your project comes back with prices over the map. Some 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 slim to none

Recipe for Disaster

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.)

Recipe for Success

Always break your project into two:

• Creating the detailed specification
• Building to the plan

This may seem like twice the work, and potentially twice the cost, but actually it’s not.

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 announce 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 a two step solution:

• Development of the plan
• Implementation of the plan

To be successful, ensure that these are priced separately. Having a thoughtful, in-depth RFP will establish a firm starting place for the developers to accurately size and price the project to your exact specifications.