As an experienced web company that’s been around for a few years (10, at time of writing) we often get invited to tender for some good-sized projects. But in responding, how do we communicate the quality of our work in a ‘testable’ way, and how do we tackle the potentially delicate issue of some aspects of the request being a bit, well, crazy? Here’s a recent example of how we did this – and won.
Normally the invitation to tender is in the form of a document called an RFP (Request for Proposal) or RFQ (Request for Quote). We’ll stick with RFQ for the sake of this example.
The project requirements laid out in the RFQ were a great fit for our company. But the RFQ was proposing a very aggressive timeframe given the volume of work to do. One school of thought suggests that you just say “Yes!” to everything in order to win the project, then negotiate your way out of the tough stuff with the help of the small print in your offer – once the client has paid the deposit, of course! This approach doesn’t work for us. It’s not how we want to kick-off a new business relationship. Our sales people are accountable for what they sell – and not on commission – therefore we’re looking for an open and honest dialogue with the client right from the beginning – including pre-sales.
So our response to the aggressive timeframe issue was completely honest. We advised that the project as described wasn’t achievable in the suggested timeframe, and that a more appropriate timeframe (to ensure quality and completeness) would be at least 2-3 times longer.
On the issue of quality – the RFQ referred to the need to make the website(s) standards compliant. Reality check #1: many RFQs state this, but (in our experience) not that many clients know much about this issue in detail, or know how they might go about actually checking/validating websites for this. Reality check #2: despite our best efforts, it can be quite challenging to keep a website 100% standards compliant forever, even if it was 100% standards compliant on ‘live’ date. Why? Because content management systems (CMS) often allow contributors to add and manage quite sophisticated content (e.g. multimedia presentations, code ‘snippets’ cut and pasted from other sites), and it’s not always possible for the CMS to ‘force’ this content – or strictly speaking the code around the content – to be standards compliant.
All Itomic sites are designed and built to be standards compliant when they go live. We go one step further. After a new Itomic site goes live, we initiate a quality checking process which includes standards compliancy checking. The main bulk of the checks are performed by a non-technical staff member who was not been directly involved with the project so that they can review it with a fresh pair of eyes. If any quality issues are identified, the production team is notified and the issues resolved at no additional charge as part of our 3 month warranty guarantee period. (We also encourage a “feedback loop” so that the root causes of these issues are identified, allowing us to adjust our processes to reduce the chance of the same issues being re-introduced again).
The RFQ asked us to provide examples of previous work, but didn’t explicitly say “and make sure the examples you give are standards compliant”. So we gave lots of examples, but didn’t explicitly take the time to re-run our quality checks on those sites.
Cutting to the chase (with this particular example): we won the project. In our first day of meetings with the new client, they offered up the following insights into our bid versus the others:
- They were well aware of the crazy timelines! Indeed, they took a conscious decision to leave the timelines in the RFQ by way of a test. Whoever responded by saying “sure, we can do that” were rejected on the basis that either they were telling fibs, or they simply didn’t have the experience or expertise to know that the timelines were unrealistic.
- Of the tenders that were left, Itomic was the only company where all the sites we referred to (as previous examples of our work) validated as standards compliant. Naturally we were delighted that our quality checking processes had served us so well, but at the same time acknowledged that even we were a little surprised at this great result, given the aforementioned challenges in keeping sites standards compliant after the live date.
We know we can’t win ’em all. We always take the time to ask a company why we didn’t win their business (so that we can improve for next time), but don’t always pro-actively ask a company “why?” when we do win their business. In this particular example, we didn’t have to ask, and what we did learn helped to reinforce two aspects of the way we like to do business: honesty (tell ’em like it is!) and quality.