Digital agencies: a complete guide to winning RFPs.

If you’re CTO of digital agency, you must read this post, it will take you only 10 minutes and help you win some deals. Don’t change tabs, turn off TikTok and stop playing Clash Royale.

As you compete for a new RFP you’ll need to provide a technical vision for this project, a vision that will out beat the competition, as sharp as your agency’s creatives do. While architecture will never make you win, it can certainly make you lose.

A good way to do it is to propose a modern architecture based on headless front-end and microservices back-end. In this article, we’ll cover the main advantages and present you with some interesting use-cases and insights. We’ll also provide a guide to setup a team, make budget estimates and timeline while you know almost nothing about the project.

1. Architecture vision: microservices and headless.

You may respond to your project with Wordpress, Drupal, Magento, SAP Hybris or Salesforce. But those monolithic approaches are the past. If you want to shine you’ll need to propose a modern architecture using headless front-end application, using ReactJS, VueJS or AngularJS and a back-end set with microservices.

Imagine you’re responding to an RFP to create a new website for a luxury hotels chain. You might propose the following architecture :

So first thing first, what is headless all about?

Headless means you decouple the front-end and the back-end of your application. When doing Drupal, Symfony or Wordpress you usually use templates where your business logic is generated, your back-end engine generates then HTML pages that are served to the end-user.

With this approach, your front-end UI is tightly coupled with the back-end application. If you need now serve a mobile application you’ll have to create all from scratch. A partner that wants to publish your offer on their site? New development. Each new feature even cosmetic one requires deployment and work from both front and back-end teams.

That’s why the headless, decoupled approach is so popular. You basically separate your front-end application from your back-end code. Your front-end is now created as a standalone ReactJS or VueJS application and communicates with the backend through API. Nowadays, we would strongly recommend using GraphQL to describe your API.

What are the main advantages of headless :

• Your business logic is now entirely accessible through API, you can connect to those APIs mobile apps, third party, TV screens, Amazon Alexa or whatever other channels
• You improve the security of your project as you can easily close the API in case of a DDoS attack while still presenting an almost functional front-end application to your users
• Performance is way better as end-users browsers load only meaningful data from the API, not entire HTML pages.
• You break adherence between front-end and back-end teams.
• You can deploy a microservices architecture in the backend

Why should you use microservices?

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

So what are the benefits of using microservices for your project :

• Developer independence: Small teams work in parallel and can iterate faster than large teams.
• Isolation and resilience: If a component dies, you spin up another while and the rest of the application continues to function.
• Scalability: Smaller components take up fewer resources and can be scaled to meet the increasing demand for that component only.
• Lifecycle automation: Individual components are easier to fit into continuous delivery pipelines and complex deployment scenarios not possible with monoliths.
• Relationship to the business: Microservice architectures are split along business domain boundaries, increasing independence, and understanding across the organization.

But building a complete microservices architecture is complex and risky. To help you with this task, we strongly recommend using code.store.

2. Change the rules

You may respond point by point to the client’s RFP and compete with a dozen other agencies on small details. But it reduces your chances of success.

Your client may ask to implement Drupal CMS or just a mobile app, you can simply respond to the initial demand or you can go further and suggest a better approach, a better architecture, a different way. It will demonstrate your capabilities and help your customer doing better choices. It will also put you in a strong position in front of your competitors.

You should also provide more details than are asked in the RFP.

Think about features that might go with the project and that were not asked :

3. How to reassure your client?

You have to put yourself in the mindset of your client. They’ve launched an RFP process and have to select the right vendor. For you, it’s just another project, another client, another RFP. But in front of you, you have a girl or guy, who bet their careers on this RFP. If they select the wrong vendor and project go south, that may mean no bonuses, blocked career path or even being fired. That’s why so often tenders are given to ‘friends’, not because of some kind of passive corruption (even if it exists) but just because they know how this “friendly” company functions.

So your primary goal during the RFP process is to reassure stakeholders in your capabilities. “With us, it’s gonna be ok.” It should be your mantra.

You need to carefully explain that you’ve considered every aspect of the project :

• You have to explain your vision of the project and how you came with the solution you’re proposing: personas, market research, user journey, pain points. List everything that made you make the UX and UI you’re showing.

• Explain your approach to SEO and analytics. How you’ll track and ensure that the new project will be perfectly SEO friendly.

• Performance: how you can ensure that the website or application will be fast as hell. What CDN will you use? What is your caching approach? How you’ll monitor all that?

• Show that you care about details, that no aspects of the project are random. Even your creative process must be explained, so you can show your client your mastery.

Examples and references

The last way to create reassurance is to demonstrate past projects. Usually, we see agencies just showing a list of slides about pas projects at the beginning of the presentation. It’s a pity. The reader did not create any connection with your response, and you drop your most powerful bullets in the beginning.

You should instead drop references and examples of projects you’ve done in the past connected with the client’s features. In an ideal RFP response, each complex/core feature of the project should be illustrated by an existing project.

4. How to organize your project

The overall timeline should be split into three main phases: a discovery phase where you’ll validate RFP assumptions, the iterative build phase, and post-go-live support phase.

Even, if almost every single person on earth knows what SCRUM is you should explain to your client how exactly her project will be executed. You shouldn’t be scared of going in detail. The girl or guy reading your response can always scroll down if they are not interested but if they have the smallest doubt about your capability of execution, you can be out.

Look at this example. We explain, week by week what exactly will happen, how we prepare a sprint, what the client needs to do during each meeting and what are the SCRUM ceremonies he needs to attend.

A good next slide would be to zoom-in in the next few weeks post-project signature. What happens once they gave you a go? What exactly will happen, who is needed on their side?

The team in a microservices project

Here a classical story: you bid for a project, propose a plan and team organization and client asks if his teams may work on some parts of the project with you.

It might be because he wants to reduce the budget, prepare knowledge transfer or simply because he used to agile projects and wants to participate to create maximum value.

With a classical architecture, as you would do with a Wordpress, Drupal, Magento or any other monolithic stack you will probably have difficulties to accept :

• Shared responsibility makes it difficult to decide who is accountable for the overall quality of the project and delays
• Any internal problem will be immediately visible and without the right dose of account management, it might be problematic, specifically during tough times.
• Culture mismatch, delivery policies, management misalignment are also potential dangers for your project.

With a headless & API-first microservices approach it’s very easy to split the project across multiple teams.

We would suggest following possible project organization (to adapt for each bid) :

Basically your project will be usually led by the front team. Working closely with product owners they create the project with the help of UX, domain experts and users’ representatives. You will let them a couple of sprints of advance.

Back-end teams are also nourished by the product owner and everybody works on the same back-log. To avoid adherence inside the project you should implement GraphQL and define a global data graph representing your project. So teams work in the following order :

1. UX and product owner prepare user stories
2. Product owner, tech leads and business stakeholders work on data graph from user stories
3. Front-end team completes a sprint based on GraphQL types and queries produced in step 2
4. Involved back-end teamwork on their stories

Even if this approach looks like a Frankenstein-agile, teams are still cross-functional, we simply split the project into independent and isolated teams. You can split back-end teams by domain (finance, logistics, …), IT software they have to talk to (SAP, Salesforce, PIM, DAM, …) and they can be yours or clients’ or even third parties. And of course, you can make them all work on the best platform to build microservices projects: code.store

5. How estimate your project

Estimation is a complicated task. You’ll almost always be wrong in your initial estimates and it sounds so anti-agile. Or is it?

At the end of this chapter, you can download our template with examples from a real project.

When pitching for projects, IT services companies or digital agencies, have to create a proposal, which includes a budget. Even if you’ll work in an agile way you still need to provides range estimates: large companies work with yearly budgets, legal and procurement will ask for a budget too.

So how can you stick to agile, provide maximum value and yet give an estimation of your project in the very beginning, during the RFP process?

First step: list your epics.

Strategic planners, account managers, and UX will start work on plan producing ideas, iterating with client’s teams. Your role, while preparing global project estimates is to get a list of epics. Core features. Based on that list, which will change and live during the entire RFP process you can start filling different buckets.

Second step: the buckets

Each epic of your project will generate high-level stories in different buckets. For example, if your project is an e-commerce site, checkout epic will need UX and front-end, a back-end order management API, integration with third-party software like a PIM, DAM, WMS, payment gateways, logistics. So let’s list all the buckets you’ll usually need to fill

• Front-end: UX, UI, ReacJS, native iOS / Android apps. Each epic will probably have some impacts here
• Back-end: business logic that supports your epics. It’s the core of your project
• Third-Party systems: it might be integration with a CRM, ERP, WMS, PIM, DAM or anything else
• Setup: imports and migrations are usually needed when you replace an existing system.
• Migration: if there is already an old version of the project you’re bidding on, you need to carefully think and estimate the migration path and the deployment procedure.
• Environments setup: continuous integration, staging, VPNs, GIT, production environment, unless you use our platform, code.store, you’ll consume a lot of days to setup or support client’s teams during the setup of your project. Do not underestimate this step, specifically when dealing with whale-sized accounts.
• Documentation: you’ll always want to skip this one but it’s key. While building your project you’ll need a ton of documentation. Writing down detailed user stories, describing architecture, integration mapping, migration process, data graph…

Step 3: Estimation Template

So now you’re ready to go through the estimation process itself. During the real project, you’ll probably use estimation poker over your sprints with complexity points (you know, the 1,3,5,8,13 and 21 things).

But, during the RFP the estimation must be done in a totally different way because you’re aiming for a different purpose. While sprint estimates are here to correctly pack teams with enough work based on their velocities, during the RFP you need estimates for :

• Show how carefully you analyzed the clients' requirements
• Make no room for “line by line” negotiations
• Open a door for negotiation by prioritizing the backlog
• Out beat competition so when your offer is compared to others there will always more details and line than in theirs. (If your competitors are cheaper than you, but had presented a 10 lines quote for a 500K$ budget, you can easily argue that they’ve probably forgotten something and the client will end-up with an x2 budget at the end of the project).

We would suggest having the following features in your estimates :

• Lines represent your epics & stories, all activities that will be performed during the project based on your creatives & strategic plan proposal.
• Columns would represent people profiles
• Cells represent man-days and dollars

It must be important to make your template in the way where you can :

• Easily make sub-totals by versions (MVP, V1, V2), add remove features to each version
• Make any feature optional
• Put priorities on each line
• Automatically calculate the number of management and quality assurance days based on the development days.
• Calculate a min/max based on the information you have about a particular story.

The last one is important. While in some cases (government or very large organizations tenders) the client will ask for a fixed number, in general, you do not want to drop a number. For several reasons :

• You want room for negotiation
• You want to be flexible and adapt the budget based on the competition
• You want to show to your client that you’re realistic and aware that any digital project will be changing and changing a lot.

So you want to give your client a min/max range.

The best way to do it is to add on each story (line) an uncertainty factor, ranging from 1 — you know almost nothing about the story to 6 — you’re almost certain of your estimate.

Example: you’re estimating a ‘ Facebook connect sign-in’ feature. You’ll probably put a 6 here because you’ve done it 10 times before, the API is public and you know exactly how long it will take. This feature does not depend on anything else than Facebook.

Another example: you’re now estimating the synchronization of SAP products in your e-commerce platform. We would put 2 to 3 of UF here because there are many things you do not know: how products will be sent to you (asynchronous XML trough SFTP or JSON REST API), how often, what’s inside (only fields you need or a complete junk of 200 SAP fields), will it be incremental or delete & replace, etc…

So how UF impact your estimates? Globally for your estimation grid, you can set factors for each UF level. For level 6, 1 estimated day equals 1 in the minimum and 1 in the maximum, but for level 1, the one you know nothing, 1 estimated day means 2.5 days for the max. Obviously there are different ways to setup those multiplicators depending on the client (emphatic and organized or a client from hell).

Here an example you can use.

6. Some tricky questions you might get during the RFP

How can you reduce the budget?

Basically we would suggest avoiding any discussions about daily rate cards. Once negotiated you’ll be stuck with them for the entire lifetime of your relationship with the client.

A first way to do, at the very end of the negotiation, is to simply offer a one-time, exceptional discount.

A better way, specifically for the first project with a client is to offer him a back margin or a discount, calculated at the end of the fiscal year and based on the revenues generated with the client. For example: “I’m ok to give you a -5% discount at the end of the years if our revenues with you will reach 500K$.” It will please the procurement and will encourage the client to send you more business.

The final move is to avoid developing parts of the project by re-using components you’ve already done for other clients. You can do it using code.store.

How can you guarantee that we’ll be live on Month/Day?

You should immediately check with your client why this particular date is so important to him. Is there some global marketing plan or just board of directors announcement? In many cases, you should emphasize here on the agile way of organizing your back-log. As you’ll work on the stories with most business value, even if by the estimated go-live date there are some missing features, only the less important ones will remain.

Can you implement the project using X technology?

Usually, that question means two things: either the client knows/feels comfortable with this technology, or there is a competitor pushing / selling hard it. It might be tempting to say yes, but you should not. You’ve proposed your vision and architecture, saying ok and switch would mean that you were not really convinced by your vision and globally you’ll be out of the game.

Instead, try to argue and analyze why he wants it and maybe get some insights that other competitors will not get. Why this technology is so important to them? How can you train them on yours? Provide them additional on-site resources, training, etc… Introduce some external experts on the subjects or the editor behind the technology you’re pushing.

How many projects your project director follows at the same time?

Here they usually refer to past dramatic experiences with vendors who sold 5 projects but failed to hire enough project directors, resulting in burn-outs and lack of customer support during the build and run phases. Bring the potential project director in the call/room and let him talk about his day to day work.

It will make it sound more realistic and will create an invisible emphatic connection.

How can you guarantee we’ll stay in the announced budget?

Again it sounds like they got terrible previous experiences with vendors who announce a budget and it doubles during the build. This is where you can play your transparency joker card, explaining that this is exactly why you’ve proposed a min/max range. You should also say that you can engage yourself on a global fixed price just after the discovery phase. You still win the project, and there is almost no chance client would drop-out after a discovery phase even if the budget doubled. Because they have control and do not feel locked-in.

7. Offer OPEX vs CAPEX

Procurement and business unit managers usually prefer OPEX to CAPEX. Large investments in digital projects are hard to justify, they impact business unit margins and their amortization is complex to calculate.

On the other hand, as an agency, you want to get recurring revenues. Having recurring revenue contracts, ideally with intellectual property creates more value for you.

We would suggest you create your project using code.store platform and start sell your components to your client as a subscription, mixing leasing of the development cost, hosting and support.

For example, you create an invoice generation microservice, that takes info from SAP, some other internal services and generates a beautiful invoice for the end-user. This development would cost your client 50 man-days, let’s say 30k$. If you know that the average lifetime of the project is 3 years, and you need 20% of the build budget to manage yearly support. This feature TCO over 3 years would be, including a 2K$ hosting cost: 30+6+6+6+2 = 50k$.

You can now suggest to your client to provide him this service from code.store platform for a 1.7k$ monthly fee or if you like risks for an X$ per invoice unit price. Everybody is happy. Your client gets an OPEX, you get 3 years recurring contract that worth 61k$ instead of 50k$ and you’ve created intellectual property for your agency.

8. How to close the deal?

There is no rule here. But usually, you need to spend the maximum time with the client before the decision process. Create positive beneficial interactions with as many stakeholders as possible. You need to show that you understand the business of the client, that you can help well beyond this small project. That you’ll be here for a long time.

Try to ask your best references to contact the client and talk about you. You can try doing the same about your competition.

It’s important to keep asking precise questions during the whole RFP phase.

Change the rules of the game at the very last moment. For example at Adyax we’ve done it several times :

• A client created an RFP to migrate a large corporate site to Drupal 8. At the end of the pre-decision discussion, we’ve challenged him to include all countries in a global site-factory. All our competition was left behind
• We’ve pushed to include a complete self-care user zone on top of an e-commerce site, so competition responding with Magento would need a lot of custom work to be done, resulting in a higher price tag.

Usually, try to grow the cake size or, in a more risky move reduce it :

• Replace a site by social media pages or a mobile app
• Replace a large e-commerce project with a lighter Shopify version
• Change complex CRM workflows by implementing a chatbot
• Or convince them they’re not ready and sell a discovery phase & user journey analysis before they relaunch an RFP

Hope this article helps you. Want more help and advice? Contact-us!