Are You Working For The Beatles? Maybe Bob Dylan?
As both a veteran musician and management consultant fascinated by organizational behavior, I'm consistently intrigued by the parallels between the two worlds. Case in point, consider the dynamics of organizational decision making through the lens of three musical icons. The Beatles decision model was both extreme, yet resilient in requiring absolute consensus between all four members. The resulting decisions were not always correct, but almost always well-implemented by the force of that commitment. Their breakup was triggered by the abandonment of that principle, after the death of their original manager. Paul went to his new father-in-law's firm for management services; the other three went another way.
Bob Dylan operates on the other end of that continuum, making 90 degree (or sharper) turns with his music, image and persona with little to no external consultation. He navigates these changes swiftly and abandons them at equal speed with requisite agility. His decisions may not be as well-implemented, or even well-formed, but can be more easily modified or eliminated in favor of something brand new.
Between these two lies the Steely Dan model. This band, led by Donald Fagan and the late Walter Becker, remained the operational and creative center, as personnel came and went around them. Unlike the Beatles, the true nature of the partnership was never revealed; but like the Beatles, their decisions seemed perfectly aligned between them. With two heads usually coming to consensus more quickly than four, this seems more efficient. But their agility was never tested, as their success apparently never compelled them to abruptly change direction.
So what, beyond this detour through classic pop music, does this matter? Simply that it can pay to be aware of and better understand the decision making dynamics in your organization through different lenses; especially how it copes with change. It's seldom reflected accurately on any org chart.
Some RFP "Do"s
Share your Objectives in the RFP. Objectives are not system features (e.g., "To process customer orders via a web-based technology platform""); they instead reflect the outcomes resulting from implementing the desired solution (e.g., "To reduce our order processing time by 30% by the end of FY 2019"). They have a side benefit of identifying misaligned expectations among stakeholders.
Incorporate functional and technical requirements and preface them with "The ability to...", which forces the next word to be a verb. Using only nouns (e.g., "Inventory reports") doesn't tell the responding vendor much.
Reserve the right to incorporate the vendor's response into the final contract. This mitigates the overoptimism that often accompanies a sales-authored RFP response.
To share or not to share your budget in your RFP? We understand the concern of vendors inflating their price to get that last nickel, but if you have an extremely lean budget and don't share it, you may end up with a stack of unaffordable RFP responses. If you don’t know enough about the particular solution marketplace to ballpark a cost range, the best answer may be C. None of the above. Consider publishing a Request for Information (RFI), which can set forth your requirements and your questions (including cost ranges) to which vendors can supply answers in a non-binding response. You can then re-use much of your RFI for a much tighter and better-informed RFP.
Some RFP "Don't"s
Whenever possible, don’t mandate an end date. We understand that these are sometimes set beyond the control of the RFP issuer, but fixed end dates are usually considered a risk that will uplift the vendor price.
Don't overuse open-ended questions. Although it's almost inevitable that some are required, they make a comparative evaluation more difficult.
Don't be overly prescriptive. This is an application of the What Not How mantra. Particularly in selecting packaged software, you may discourage the best solution providers from bidding if you implicitly or explicitly mandate a particular deign approach. RFP responses is an expense for these vendors, and many will elect not to bid if the implied design is counter to their approach, even if their solution best solves your problem.