On requirements, freedom, RFPs and hamburgers

Picture this RFP:

After an extensive decision making process, Me&Friends (M&F) has decided that its current needs are best served by a (ham)burger. Consequently M&F is looking for a supplier that can provide it with a burger that fulfills the following requirements:

• MUST not contain e.coli

• SHOULD provide 250 kcal or more

• SHOULD contain cheese

• MUST contain beef 

• COULD contain bacon

• COULD contain a middle bun

• SHOULD be packaged

Proposals should be received no later than 1 hour after receiving this RFP and will be judged on price, distance and provided references.

This is clearly an asinine way of ordering a burger as you'd usually work on look&feel, previous experiences and/or recommendations of friends. Please bear in mind that the same basically holds for the procurement of a high-end car, which is the same order of magnitude as a medium sized website.

Common Sense
So why is it that we lose this common sense approach when it comes to business? Why do we insist on using even more convoluted processes? The procurement process appears to have a single aim: removal of any agility and creativity from the development process.

Check?, check!, check, check, no, check, check

The only advantage that the formal route gives you is a degree of certainty, which is something that is of course never actively punished in the corporate environment. No one has ever been praised for taking a risk if the eventual outcome is negative..

McDonald's
It's the same as McDonald's food: you are certain of a very bland, mediocre burger, but you will never be unpleasantly surprised. Mediocre burger in Shanghai = mediocre burger in Kernersville = mediocre burger in Amsterdam.
Conversely, you will never have the absolute delight of randomly walking in one of Amsterdam's lovely Burgermeester establishments.

It gets worse: since you are actively looking for the cheapest deal (and will for any future project) you do not give any incentive to the selected vendor to provide you with anything more than explicitly required.

Cheapest, thus wins

Consultancy
As Hippo Business Consultants my colleagues and I are often placed in situations where we can not do our job properly. Many companies spend ages coming up with their requirements document, this document becomes leading in the entire development process. This robs me and my colleagues of the opportunity to help a client achieve the full potential of their online environments. It is rare to see an RFP where any experts where actively involved in the drafting of requirements.

The procured system is not used to its full potential (e.g. it's rare to see an RFP demand faceted search). It's a sad situation when an entire project team (including manager) agrees that the chosen solution is not optimal, but you do it anyway, because that's the requirement.

Luckily a lot of project managers I've worked with are smart enough to realize this and allow diverging from the strict requirements (with or without telling the sponsor). Sadly they are still required to work with the defined process, thus creating a lot of overhead and unnecessary (conflicting) documentation.

Rules
As with most rules, I think requirements should be treated as (strict) guidelines. Substantiated diverging should be allowed at (nearly) all times.

Another pressing recommendation I'd like to make: make a reservation (time and budget) of at least 30% for unforeseen features. This will tremendously improve the quality of your end product (and make developers happy).

Using the fork is optional

Now I'm hungry :-)