Want email updates from me?
Want more unvarnished truth?
Looking for something? Look here!
What I'm saying now
What you're saying...
I think tag clouds are pretty, and not to be taken overly seriously
111 Chop House 75 on Liberty Wharf 9/11 A Broth of a Boy ABCs Abiouness accountability activities alcohol Allora Ristorante Analysis Angry Hams ANSI/TIA 942 Anthony's Pier 4 Apple Application Armsby Abbey Arsenal Arturo's Ristorante Ashland AT&T Audio Automation baby Baby Monitor babysitting Back To School Bad News Bangkok Thai Bar Bay State Common baystateparent BBQ BCP BeeZers Before I die I want to... behavior Big Bang Bike Bill of Rights Bistro Black Box BlackBerry Boston Boston Marathon boundaries Boyston BPO brand Breakfast Bridge Bring Your Own Technology Budget Burlington Burn Burrito buyer BYOD Cabling Cambridge Camp Campaign career Casey's Diner Castle casual cCabling Cell Phone Central Square Change Management Cheers Chef Sun ChengDu Chet's Diner Children Chinese Christmas Christmas Families Holiday CIO Cloud coddle collage College College Acceptance co-lo Co-Location Co-Location Tier Power Cooling Comfort Food Control Country Country Kettle Crisis customer dad Dad Phrases damage daredevil Data Center Data Center Design Davios Day Care Dead Death declaration Del Frisco's Design Desktop Video dinner Disaster Recovery Divorce Do Epic Shit dodgeball Downtown Crossing DR driving Droid Easter Economic Kids Edaville Education Elbow Night Elevator Employee Engagement Erin Etiquette Evaluation events Exchange Expiration Dates Facebook Failing family Fatherhood Favorite things Flash Flemings Fogo de Chão Food Hits and Misses Format Foundry on Elm Foxborough Frameworks fraternity Fraud French Fried Clams friends fun Fusion Generations germs Girl Scouts girls Global Go/No Go GPS Grafton Grandchild Grandpa Harry's hazing Healthcare Healthy Choices while Dining Out Help Desk Hisa Japanese Cuisine Historic holiday Home hope Horizons hose Hot Dog Hurricane IIT Assessment incident Indecision Indian Infrastructure Inn Innovation Internet Inventory Management iPhone IT IT Assessment IT Satisfaction Italian Jack Daniels Jakes Restaurant Janet Japanese Jazz Joey's Bar and Grill JP's Khatta Mitha kickball kids Laid off Lakes Region Lala Java Leadership Learning legacy Legal Harborside Les Zygomates L'Espalier Liberty Wharf lights out Linguine's loss Love Lucky's Cafe M&M Macys Thanksgiving Day Parade mai tai Managed Application Services Managed Services managers Mandarin Manners Mark Fidrych marriage Mary Chung mass save Maxwell-Silverman Mediterranean meetings Memorial Day memory Mendon Mergers Mexican MiFi Migration Ming III miss MIT MIT CIO Symposium Mobility Moes Hot Dog Truck MOM money Mother Moving on Name neanderthal neighborhood Network New York Marathon newborn Northborough Not Your Average Joe's Nuovo Nursing On-Call Operations Operators Oregon Club Organization Pancakes Pandemic Parental Control Parenting Patch Peeves People Perserverance UMASS growth Play Plug and Run Predictable Pride Problem Process Production program Project Management propane PTA. PTO PUE QR Quick Response Rant Real Estate Realtor Recognition Red Rock Resiliency Respect restaurant Restaurant Guy RFP ribs Ritual Root Cause Analysis Sam Adams Sandy Sapporo savings School Sea Dog Brewing Company Sea Dog Steak and Ale Seafood Seaport Security Sel de la Terra Service Service Desk Service Indicator Light sharing SHIRO Shit Pump Shriners SHTF Simplification Skunk Works Skype Sleep sleepovers Sloan Smith & Wollensky soccer Son SOP sorority spanking Squarespace staffing Starbucks Status Reporting Steak Steve Jobs Storage Strategy stress Summer Sushi swimming Tacos Acalpulco teacher Technology Teen Telephony Temperature Strip Tenka terrorist Testing Texas BBQ Company Text Thai Thanksgiving in IT The Mooring Thomas Thought Leader Three Gorges III TIA 942 Timesheets Toby Keith Toddlers traditions Transition treehouse turnover TV Twitter unspoken moments Valentine's Day Value Vendor Venezuelan Verizon Vermont Video Vietnamese voice VoIP Watertown Wedding Westborough Korean Restaurant Westborough MA. StormCam WiFI Wi-Fi Wilbraham Wine Worcester work work life balance working Yama Zakura Zem Han Zitis

Entries in RFP (2)

Monday
Apr232012

The Importance of a Quality RFP

This guest post by Matthew Ferm talks about an important topic….RFPs.

We spend a great deal of time creating and facilitating Request for Proposals (RFPs).  Clients request RFPs because it helps them to make decisions.  We like doing RFPs because it brings precision and process to something emotional, the sales process.

I would like to tell you we don’t want to interfere with the vendor/customer relationship, but it would not be true.  We teach our clients to strive for fact-based and unemotional procurement decisions.  This is the opposite of how vendors (including Harvard Partners) sell customers.  Vendors try to convince customers the vendor’s products are unique, special, and something the customer MUST have.  Deep down inside, we all want to own the “shiny object” and be better than our peers.  Unfortunately, that is not always the best answer.

The RFP process brings parity to procurement decisions and a good RFP process allows the solution with the best value to rise to the top.  A good RFP should also be quick and simple for the vendor to complete.

What makes a quality RFP?

  • Statement of Purpose – It is important to clearly state why the RFP is being issued.  The reader of the RFP (vendor) is looking to uncover the problem being solved by the RFP.  This is what good salespeople do.  Hide the true purpose of the RFP and your response will probably not meet the mark.
  • Detail – Details matter.  The more detail you put in your RFP, the more accurate (I did not say detailed) your response will be.  Details will also save the vendor time in creating their response.  By removing ambiguity you remove wasted time.
  • Setting Expectations – Let the vendor understand the process and when they will receive a response.  Appreciate that they have put time and effort into responding and deserve to know what is going on.  Allow them to contact you for status.
  • Response Template – Whenever possible, give the vendor a template for the response.  It will save you time when compiling responses and it will save the vendor time in creating the response.
  • Non-Technical Response – We are typically asked to create RFPs for technology procurement by people who are not that technical.  They are decision makers who rely on their vendors and others to be technical.  Pack an RFP response with too many technical acronyms and too many speeds and feeds and you lose them.  By creating a detailed RFP you cause the response to be mostly yes, no, and pricing.  This is something a non-technical person can understand
  • Allow for Errors – When we evaluate RFP responses we work to uncover a bad response and give the bidder the opportunity to correct their mistake.  Most of the time this was due to a bad assumption on the part of the bidder.  In the spirit of getting the most accurate information for our client, we feel bidders should be given the opportunity to correct mistakes.

While we strive for high-quality RFPs we also recognize the need for the vendor and customer to have a strong, positive relationship.  RFPs do nothing to make that happen.  We recommend prospective customers visit with each vendor, prior to the RFP process, and allow the vendor to ask questions and sell the customer.  This gives the prospective vendor an opportunity to get to know the sales people and delivery team.  After all, in the end, “people buy from people.”

The RFP is a great tool to aid in the quality and timeliness of the decision-making and procurement processes.  Like any project, your procurement process needs a plan.  Think of the RFP as both a requirements document and project plan rolled into one.  With a clear understanding of the problem and expectations, vendors can focus on proposing a better and more cost effective solution.

Monday
Sep262011

How to Select a Co-Location Provider using an RFP

In a recent post, the case was made for companies with modest data center needs to explore co-location.

We made our case and the executive team agreed.  Having an agreed upon direction, it was now time to do something.  And the client was stumped.

“Let’s go visit them,” the enthusiastic client espoused. 

We would recommend visiting a couple to ground yourself in some of the various dimensions…and then would quickly go back to a conference room to understand requirements.

“Our systems are important.  We need to put everything in a Tier 4 data center.”

The ANSI/TIA-942 standard defines the concept of Tiering, as a way to distinguish design considerations.  The standard is quite lengthy, and is summarized below.  You’ll see “N” mentioned.  “N” stands for NEED….and is always debated since everything else drives from it.

 

Tier 1

Tier 2

Tier 3

Tier 4

Delivery Paths

One

One

One Active

One Alternate

Two Active

Capacity Components of Support

N

N+1

N+1

N after any failure

Points of Failure

Many + Human Error

Many + Human Error

Some + Human Error

Fire, EPO & Human Error

Yearly Downtime

28.8 Hours

22.0 Hours

1.6 Hours

0.8 Hours

Site Availability

99.67%

99.75%

99.98%

99.99%

 

While there are some commercially available Tier 4 co-location facilities, unless there is a specific business requirement, we find most co-location facilities at a Tier 3 level provide the kind of availability one would expect for a paid service.  The yearly projected downtime between a Tier 2 and a Tier 3 is substantial (don’t assume the “yearly downtime” happens once a year.  For example, what if it worked out the 22 hours (Tier 2) was spread over a year in weekly increments?  While the facility would be hitting its uptime goal, your systems outage time (quiescing applications, database, and systems, rebooting, then bringing up systems, databases and applications) could add to hours each week!)

With a good understanding of the capabilities available and your business needs, a Request for Proposal (RFP) can be put together.

Putting together an RFP can be a fun task, or maddening.  The key to the RFP process is using the development period to driving alignment of the company parties. 

At the most basic level, the RFP should cover:

  • Company Background (don’t assume people know your company)
  • Stated Requirements (high level)
  • Growth considerations (this is the hard part….and often drives initial buildout costs)
  • Key Questions (on how delivery is provided)
  • Response format (similar response formats make comparisons easier)
  • Any specific legal topics (such as a need for background checks)

There is a fine balance in writing RFPs.  Companies need to be specific enough deliverable solutions can be proposed, yet broad enough to allow creativity.

For example, one area driving costs in RFPs is around power/cooling.  The company needs to identify what the heat load is of the equipment envisioned to be placed, in kilowatts (kW). 

If the company is running a dense environment, it is tempting to express this in watts per square foot (W/SF)

When W/SF are used, some providers may be automatically “disqualified.”   How?  A data center designed for 50W/SF can indeed support 100W/SF….it just takes twice the space and appropriate chilled air distribution! 

So smart companies analyze their needs, and let the co-location providers respond.

Philosophically, we prefer shorter RFPs to longer ones.  Providers need to have time to put together responses.  If the RFP is “too big, too heavy,” some providers may not respond at all or will respond generically with their capabilities, while not answering the underlying questions in the RFP.

Once the RFPs hit the street, you need to put a cone of silence on vendor conversation at ALL levels.

Next week, we’ll talk about how to analyze the responses.

Have a favorite RFP story?  Share it with the community.  We’d suggest masking company names…