This post is about an aspiration. It is about how I want Red Badger to engage with clients in the future. How we can avoid old fashioned Request For Proposal (RFP) processes and just get on with what we should really be judged on. Our ability to build products.

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.

Before last year closed out and we headed off for festivities and copious amounts of booze I mentioned a new idea to introduce Red Badger employees the opportunity to use their training budget (£2,000 each year) to invest in our own ideas.  I am pleased to announce that the first event will be taking place internally on the 31st January – 1st February.

The team will consist of myself, Sari, Haro and Joe, the theme of the idea I have chosen is around real-time social media coupled with music festivals, think foursquare meets waze, facebook and beyond.

The new name for these rapid prototyping events after a collaborative effort over the web (as some of us are on client site) using http://beta.mural.ly/ (a great collaboration application found by Sari) is Firestarter Events.  Along with the name we now also have a couple of logos to kickstart the branding and get things well under-way.

As I previously mentioned I am hoping for this process to be as open as possible and will post successes and failure throughout the two days.  In the mean time you can check out the agenda and invitation that was sent out to the team below:

Agenda | Invitation

Watch this space for photos of the event and more importantly the end MVP that we will be releasing live at the end of the two days.

Thoughts

So as the year is closing out and we head towards 2013 I started to think about what I might be able to do in regards to the £2,000 training budget that we get here at Red Badger.  

At Red Badger we are a growing company and to start schemes such as Google’s one day a week (20% time) to innovate is not particularly viable (not yet anyway …).  The other point about having one day a week to work on your own products is that you may not have an idea or products that you feel you can really work on.  I feel it turns the time into being a little be wasteful and really only focuses on things you can do in your discipline.

So rather than forcing the issue and trying to find a training course that ‘could’ be a good fit and not getting much value.  I have formulated an idea around the ethos of how we have run some of our previous rapid prototyping projects such as BBC Now!.  

Additional to this I recently discovered show on Bloomberg called TechStars where start ups spend three months in an incubator scheme to raise investment and get their company off the ground (Episode 1).

The new Red Badger scheme is formed from mixing rapid prototyping with an incubator type event…..

Idea

I put forward the idea to the guys here at Red Badger to allow any employees to embrace and innovate internally by allowing investment in our own ideas when we have them.  The application process being that we can book any internal resources to develop our ideas using the training budget as a catalyst investment over the two days (in a rapid prototype format) and end up with a (M)inimum (V)iable (P)roduct.

The event itself is to be a very informal affair and a great laugh with a specific focus on delivering the MVP.  Beer, food, crank on the tunes and start developing!

This is great for many reasons as it allows any person of any discipline within Red Badger to get their ideas off the ground and test the market.  Red Badger can then see if these ideas are worth investing more time after the MVP is in the wild and being tested by users, they also then have ownership for any successful ideas that get off the ground and prove value.  

We are a consultancy here at Red Badger and my opinion is that this scheme lends itself very much to bringing our team together, company culture and aspirations as a business.

It is important to note that the ideas can be absolutely anything, not limited to that of internal or improving Red Badger processes.

Future

I want this to be a very transparent process to show successes and more importantly failures of running this type of event.  This scheme in its own right is an ever evolving process and has never been done before so there will be plenty to learn.

The first project that has got approval is scheduled to go ahead at the beginning of the New Year.  I will post up the planned agenda for the event in the coming weeks.  I would be interested in any thoughts and ideas people might have with a scheme such as this (good or bad).

So, you may have seen our recent blogs about the BBC Connected Studio for Homepage, Search and Navigation – Creative Studio and Build Studio.

So far the experience has been an incredible one. The BBC have run two fantastic events that have been very well organised and almost militant with their timing. In brief, the Creative Studio had 32 teams presenting which was then whittled down to 9 for the Build Studio.

It sounded like the BBC judges had an incredibly hard time in choosing the finalists to go into the funded 6-8 week rapid prototyping Pilot phase because there were some incredible ideas amongst the 9 participants.

We are really pleased however, that we have been chosen as one of the three teams to go through to the Pilot stage. The other two are Kent Lyons and Goss Interactive so congratulations to both of those as well.

Our original concept in the Creative Studio combined a number of ideas including a time based homepage combined with varying levels of manual and automatic personalisation and the semantic web. In the Build Studio we had 2 days to focus on one idea and the BBC wanted us to explore the timeline view. It was a bit of a risk but the team chose to rebuild the prototype for the homepage from scratch using Node.js (rather than using the existing PHP codebase that was provided)  in the 2 days allocated.  This was integrated to real BBC data and demoed at the end of the 2nd day.

So, in the Pilot we will more than likely be taking the timeline view further and making it production ready. We haven’t yet defined the requirements for the 6-8 week project and it going ahead is subject to some business case analysis and agreement being reached on costs, deliverables and timescale. If it does go ahead however, once we have built it, the pilot will be live to the public on the connected studio site so the BBC can gather some real feedback before making a decision on whether to implement it into bbc.co.uk.

So far the Connected Studio has been a great experience. We have given the opportunity for a a number of our staff to be involved (the team for Build Studio was entirely different to Creative Studio) so it feels like it has been a real team effort. We’ can’t wait for the pilot to begin.

Last Wednesday I was invited by one of our partners, Fluxx, to talk at an evening event they hosted; The DNA of Innovation.  They wanted me to share my war stories from working in Concept Labs and Rapid Prototyping, something we have years of experience with here at Red Badger.

The Concept Lab has become an ever popular way of exploring and proofing big ideas and new concepts, but making it work and getting it right is far from easy.  Having worked on a whole stack of challenging Labs over the last 4 years, Head of Experience Design at Fluxx, Paul Dawson, asked me to share some of those experiences with luminaries invited from 15 of the worlds most notable brands.

The key theme of a lab is that of discovery – for good or bad.  You take a multi-disciplined crack team, set them some large goals (and lots of them), give them the best tools, the best tech, remove all impediments and then lock them away in a collaborative space for 3 – 6 weeks and let them prove, or disprove, the objectives of the lab.

The idea is not so much to do things differently than you normally would, crazily churning out awful code, but to distil the best industry process down into your 3 – 6 week period, using the bare essentials of each process; taking away as much as you can, but stopping just before your yield drops.

With that thesis in mind I decided to apply the same methodology to my talk and take three Labs I’d worked on and, in just 10mins, whip through what each set out to achieve, what we did and what we discovered.  As we toured through Labs for Tesco, Haynes and Microsoft – looking at concept artwork and videos of working product it was great to see the audience immediately “getting it”.

That’s what Labs are so great at doing – bringing lots of tough ideas to life, quickly.

“Pocket Mechanic” (a Lab we conducted for Haynes) is a case in point, the actual rapid prototype below was put together in less than a week, but every time we put it into someone’s hands to play with – they love it. They instantly see the value in the concept. That’s pretty powerful stuff.

If you can put a device, with working software, in the hands of a decision maker and show them something within 4 weeks, it makes their decision a lot easier than if you simply tell them you can do something.  What’s more, the subsequent decision about what to spend the real money on is going to be a much wiser and confident one if much of the discovery work has already been done.

In a Lab, failure is an option; you set out with lots of tough goals, safe in the knowledge that you expect some of them not to work.  The value in making your mistakes early, in a controlled environment, as opposed to the production development cycle cannot be underestimated.

It’s important to remember that Labs work best when the goals are many and tough – for the team it should feel like a challenge, it should be intensively productive and if you really have the crack team you need, they’ll revel in it.