The Proof is in the Pudding

Does a good sales presentation prove you can deliver? We think not. How should clients de-risk project delivery by choosing a service provider based on their proven ability to deliver?

Red Badger has been running as a company for 3 years this May. If you’ve followed our journey or been reading our blog, you will have seen that we as a company have changed a huge amount. We are catalysts for change, being disruptive in our approach if it is necessary. Check out our new tech page on our website and you will find little mention of Microsoft related technology. If you were to wind back time to two years ago, you would have found that Microsoft would have dominated that same page. This transition has been born out of a desire to find the best solution to any problem without fear of change. To be agile and to adapt. As a result the tech stack we have now built up has changed the way we can deliver projects, applying Lean Startup principles to rapid prototyping to quickly prove concepts, deliver quality Minimum Viable Products (MVPs) and build on them.

We’re not just catalysts for change in the technology we choose or the way we deliver projects; we’re always looking for ways to improve everything we do. The change in how we can deliver projects has made us look at how we try to win new business and how we can provide better value to our clients. I want to provide a brief analysis of this. I’m going to look at a traditional RFP process to start with and then compare it to how we aspire to work with clients and how this links in to part of our current service offering.

The RFP

An RFP can vary greatly in quality. Some are so brief that they really give you no steer of what they are asking for, resulting in a round of questions from the vendor just to find out the requirements. Other RFPs are at the other end of the spectrum and are so detailed they take a week to read – how long they have taken to build you can only imagine. How a company issues an RFP may differ from company to company but it may go something like this:

  • The client identifies an area in which they want to improve their business (E.g they want a new, more modern website that will better showcase their brand)
  • The next few weeks/months are spent building out the RFP, defining purpose, scope of work, vision, objectives, requirements etc…
  • The RFP may ask for a varying level of detail depending on the client but at a bare minimum it is likely to ask for the following:
    • A full description of vision
    • Details of project methodologies
    • Outline of technology that will be used
    • A release and support plan
  • They then have to identify a shortlist of potential vendors that they want to work with
  • They issue the RFP to the shortlisted vendors
  • The vendors have time to consider the RFP and express an interest in building a proposal
  • The vendors will be given a timeframe in which to respond – Let’s say 3 weeks.
  • In this time, the vendors are allowed to issue a number of questions to the client to which the client is obliged to respond
  • The vendors then build out a proposal document. This can vary in complexity depending on the client’s requirements but generally will go into a great deal of depth. It may include the following:
    • Exec Summary
    • A full description of vision
    • The solution including a full breakdown of phases: E.g Discovery, Experience Design, Visual Design & User Testing, Development, Maintenance & Support
    • Project Team Details
    • Timelines/Release Plan
    • Pricing
    • A bit on why you should choose us
    • Case Studies
  • The proposal document will then be accompanied by a pitch
    • The pitch will try to portray what is presented in the proposal at a higher level
    • It is likely to be more visual in painting the vision
    • It may include initial wireframes, designs or user journeys
    • But the message getting across to the client will be dependant largely on the skill of the presenter
  • The client receives all of the proposal documents and issues dates for the vendors to present their pitch over a period of 2 weeks.
  • The pitches are presented
  • The vendor is chosen by the stakeholders and the project start date is set subsequent to the signing of contractual agreements.

The above is a very rough outline but the end-to-end RFP process prior to the project start date can take several months. The point at which the RFP is issued to the vendor, to when a decision is made, is also rarely less than a month.

Some of the above is absolutely necessary. However, our aspiration is to change this whole process. An RFP is often much too detailed and the end-to-end process is incredibly long, though my biggest concern is that the vendors are being judged, not on their ability to deliver, but their ability to be convincing during a presentation. Case studies and/or references become the medium through which the client validates their decision but these don’t necessarily represent the client’s requirements. This leaves the client in danger of choosing a less capable vendor on the basis of their case studies being similar to their own requirements.

In short, an RFP process feels old fashioned and cumbersome. It feels like some stakeholders are going through this process only to cover their backs by demonstrating due diligence. It is not progressive and it certainly doesn’t provide best value.

Just Do It

“Just do it” might invoke an initial reaction of “this sounds risky” so let’s use an example of a real project we’ve been involved in that demonstrates a progressive rapid prototyping approach to selecting a vendor.

Last year the BBC launched BBC Connected Studio, the vision presented by Ralph Rivera, Director of BBC Future Media. The vision was to foster near to mid-term innovation projects across BBC’s products by encouraging start-ups, agencies and other individuals to pitch their innovative ideas.

We pitched for the Homepage, Search and Navigation studio. There was a lot of investment from the BBC that went into the connected studio days but I am going to concentrate on how we got from brief to selection. The process went something like this:

  • The BBC prepared an innovation brief with highlights of their business objectives
  • You had a day to come up with a concept and prepare a 2 minute presentation
  • The BBC then listened to and filmed 30+ 2 minute presentations.
  • They narrowed their selection of concepts down to 9 vendors who are invited back
  • The 9 vendors have 2 days to build a rapid-prototype of their concepts at the end of which they have 10 minutes to demo them.
  • The BBC deliberate for a week and then inform 3 vendors that they have been sucessful
  • A pilot phase of 8 weeks is then planned for a date in the future

We delivered the 2 day prototype using our tech stack, effectively re-building the home page from scratch using Node.js, integrating to real data and presenting an MVP.

 

This is not a perfect example as BBC Connected Studio is slightly different to most projects but it does demonstrate how the BBC can make solid judgements based on ability to deliver, not on ability to present. The presentations themselves were kept incredibly short and in fact weren’t really presentations, they were demos.

We have now gone on to complete an 8 week pilot, working very closely with the BBC so they can quickly get an idea of what we’re like to work with on a project, get used to our processes and our technical capability. The project has far exceeded expectations, has been delivered efficiently and on-time to the BBC and is now ready for user testing.

NOTE: In the last 12 months we have also delivered rapid prototypes for News International, LV, RSA, JLT and MoreTh>n.

The BBC was a loose brief because they wanted to encourage innovation, empowering the vendors to be creative with ideas. Some clients may like this approach, some might not. Regardless, delivering an MVP to reduce risk to the client still works for much more specific briefs.

More Specific Briefs

We have recently won another small piece of business that had quite a specific brief. They had a clear vision and wanted details from us that would be included in a traditional RFP such as; details of project methodologies, how the products will be maintained & supported and how we scale. However, they also had a desire to move quickly and with little risk. They have broken the vendor selection down into two phases. Here’s how this went.

Phase 1:

  • A brief is sent out to the vendors. They must respond with a light pitch outlining approach and accompany it with a very small prototype.
  • The brief also sets out some expectations for the prototype. It has quite rich animations. It must be HTML 5 on a mobile device. It must integrate to the accelerometer.
  • We build a pitch detailing our approach, alongside building a prototype. NOTE: You can view technical details of this prototype in this post Simple 3D without Canvas or WebGL
  • We present our pitch alongside a demo of the prototype and a review of the code. (The audience from the client is a mix of both tech and business people. This is also important)
  • We are chosen for Phase 2.

We delivered a pitch that satisfied all of their questions which included some rough wireframes, designs and a release plan but we also delivered a rapid prototype, could demonstrate to them our delivery capability and show them the well architected code. Phase 2 is now about to begin. We are the chosen vendor but there is a further test before the full project is won. Phase 2 is paid for but is only 21 man days. It sets out to build upon the Phase 1 MVP to build a production quality component (1 of over 200 that will need to be built in the full project), with the aim of proving further technical questions before being satisfied that the project is feasible. When the technical feasibility is proven we will move straight into full project mode and get started on the design & build of the following components. In the unlikely event that we prove that the project is undeliverable, the client can stop the project having invested only 21 days on development.

To summarise:

  • The client has chosen the vendor (us) by working with them for just a week
  • The proposal document was light but satisfied their questions.
  • A prototype demonstrated to them that we were capable of delivery.
  • They can now go straight into developing a live component, using this to prove technical feasibility
  • Initial spend is little. Risk is little. Speed to deliver is fast.
  • Once feasibility is proven we are already in project mode and can move straight into the design & build of the rest of the project

The Benefits for The Client

The Lean Startup principles are all about reducing risk. We apply these principles to our project delivery processes, using a tech stack that allows us to rapidly deliver. We like to prove concepts quickly and cheaply by rapidly delivering MVPs and then quickly go from MVP to full release. We’d also like to apply Lean Startup principles to the way in which we work with our clients to start new projects. By building rapid prototypes, working collaboratively with the client during the vendor selection process we bring the client the following:

  • Transparency in the vendor’s ability to deliver
  • Confidence/familiarisation with their processes prior to decision
  • Transparency of culture prior to decision
  • A refined view of vision (Having something tangible that you can see and use is the best way to assist the painting of a vision)
  • An MVP that you can use and build upon when the project gets going
  • A clear comparison between the vendors based on what matters – their ability to deliver quality product.
  • Reduced risk and investment
  • A faster decision

In Summary

I’ve been working on agile projects for nearly a decade now. Back in the early days it was particularly hard to sell but behaviour has slowly changed. The client is often used to agile ways of working and is not surprised when this is our chosen project delivery methodology. Ultimately this is because they now understand that it provides better value, an understanding that was missing a few years ago.

Our aspiration is to avoid the traditional RFP process and move to a rapid prototyping approach to selling.

We believe this provides much better value to the client. However, the journey to get there may be a long one, and I am under no illusion that this will be the only way we engage with our clients any time soon. But we will keep pushing to provide them with better value and hopefully we can convince a lot of them to embrace change, sooner rather than later, in the way that we do.

More Specific Briefs

We have recently won another small piece of business that had quite a specific brief. They had a clear vision and wanted details from us that would be included in a traditional RFP such as; details of project methodologies, how the products will be maintained & supported and how we scale. However, they also had a desire to move quickly and with little risk. They have broken the vendor selection down into two phases. Here’s how this went.

Phase 1:

  • A brief is sent out to the vendors. They must respond with a light pitch outlining approach and accompany it with a very small prototype.
  • The brief also sets out some expectations for the prototype. It has quite rich animations. It must be HTML 5 on a mobile device. It must integrate to the accelerometer.
  • We build a pitch detailing our approach, alongside building a prototype. NOTE: You can view technical details of this prototype in this post Simple 3D without Canvas or WebGL
  • We present our pitch alongside a demo of the prototype and a review of the code. (The audience from the client is a mix of both tech and business people. This is also important)
  • We are chosen for Phase 2.

We delivered a pitch that satisfied all of their questions which included some rough wireframes, designs and a release plan but we also delivered a rapid prototype, could demonstrate to them our delivery capability and show them the well architected code. Phase 2 is now about to begin. We are the chosen vendor but there is a further test before the full project is won. Phase 2 is paid for but is only 21 man days. It sets out to build upon the Phase 1 MVP to build a production quality component (1 of over 200 that will need to be built in the full project), with the aim of proving further technical questions before being satisfied that the project is feasible. When the technical feasibility is proven we will move straight into full project mode and get started on the design & build of the following components. In the unlikely event that we prove that the project is undeliverable, the client can stop the project having invested only 21 days on development.

To summarise:

  • The client has chosen the vendor (us) by working with them for just a week
  • The proposal document was light but satisfied their questions.
  • A prototype demonstrated to them that we were capable of delivery.
  • They can now go straight into developing a live component, using this to prove technical feasibility
  • Initial spend is little. Risk is little. Speed to deliver is fast.
  • Once feasibility is proven we are already in project mode and can move straight into the design & build of the rest of the project

The Benefits for The Client

The Lean Startup principles are all about reducing risk. We apply these principles to our project delivery processes, using a tech stack that allows us to rapidly deliver. We like to prove concepts quickly and cheaply by rapidly delivering MVPs and then quickly go from MVP to full release. We’d also like to apply Lean Startup principles to the way in which we work with our clients to start new projects. By building rapid prototypes, working collaboratively with the client during the vendor selection process we bring the client the following:

  • Transparency in the vendor’s ability to deliver
  • Confidence/familiarisation with their processes prior to decision
  • Transparency of culture prior to decision
  • A refined view of vision (Having something tangible that you can see and use is the best way to assist the painting of a vision)
  • An MVP that you can use and build upon when the project gets going
  • A clear comparison between the vendors based on what matters – their ability to deliver quality product.
  • Reduced risk and investment
  • A faster decision

In Summary

I’ve been working on agile projects for nearly a decade now. Back in the early days it was particularly hard to sell but behaviour has slowly changed. The client is often used to agile ways of working and is not surprised when this is our chosen project delivery methodology. Ultimately this is because they now understand that it provides better value, an understanding that was missing a few years ago.

Our aspiration is to avoid the traditional RFP process and move to a rapid prototyping approach to selling.

We believe this provides much better value to the client. However, the journey to get there may be a long one, and I am under no illusion that this will be the only way we engage with our clients any time soon. But we will keep pushing to provide them with better value and hopefully we can convince a lot of them to embrace change, sooner rather than later, in the way that we do.

Cain Ullah

CEO / Founder

More from Cain