You are here

You are here

What should a mobile development and delivery RFP look like?

Matthew David Digital Leader, Accenture

Sourcing mobile development is not easy. With all of the delivery models available, there are still several open questions. What will be your development environment, and who are you targeting your solutions to? What are the policy and governance tools that will be used to manage a solution post-production? More important, what questions do you ask vendors as you're searching for the many available solutions?

As you create your own request for proposal (RFP) for mobile development and delivery tools and platforms, you should be keenly aware of the different models that can be used to source mobile development. This article explains those models and describes how to build an RFP that will make vendor responses easier for you and your team to evaluate. 

First step: Define the project

The basic sections of an RFP outline the scope of the work. Mobile solutions almost always fall into two categories: small (under $50,000) and medium (under $500,000). RFPs for both project sizes should include the following:

  • Executive summary
  • Definition of the components/visual presentation
  • Questions to ask each vendor

Executive summary

An efficient mobile solution is tactical. The focus of the solution is to give a user access to information, allow her to make a decision, then close the app in less than one minute. The executive summary is a great way to test how tactical the mobile project is. Can the executive summary be written in 140 characters to pass the Twitter Test?

Components and architecture

The second section of the RFP outlines the components and architecture of the project. What APIs are you using and how will they connect with the solution? How is data moving? Where are the security levels? By addressing these areas, you give the responding vendor a clear understanding of what you hope to accomplish with the project.

Details—such as code standards, governance guidelines, wireframes, and information architecture—should be added to provide a full understanding of what impacts the work. The goal is that you manage the expectations of the project for each vendor to avoid confusion and surprises.

Vendor questions

The final section of the RFP is an opportunity to quiz the vendor regarding its skill set. Questions should include:

  • Can you provide evidence for mobile solutions that have been delivered, along with the ROI your customer received after using the solution?
  • What is the model of delivery used by your teams to manage projects?
  • What tools do you use to validate consistent code quality?
  • How do you test for remote connectivity?

Ask qualifying questions around the following core capabilities:

  • Mobile technology/development
  • Mobile design
  • Quality control

When you have the RFP document defined, the next step is to choose the appropriate delivery model.

Second step: Define the mobile delivery model

Determining the size of your project can have a direct impact on the various types of delivery model you want to leverage. There are four models that can be used to deliver mobile solutions. They are:

  • Augmented staff
  • Managed service delivery
  • Boutique
  • Crowdsourcing

Augmented staff

The most common method of delivering a solution is with augmented staff. There are quite literally hundreds of companies that keep a catalog of developers, designers, and computer scientists on record. Augmenting a project with the key people works great when you know exactly what skill set you need and how this person will fit with your team.

The challenge I have with this approach is that the day-to-day management of the individual is still up to the leader of the team. Your time is precious, and day-to-day management is time-consuming. Consider how much time will be needed to manage each person before you commit to adding more iOS or Android developers to your team.

Managed service delivery

Managed service delivery is similar to augmented staff, with one exception: The service provider manages each team member. The approach I request for managed service delivery is the size of the delivery model versus the scale of the project. For this reason, I use the following “T-shirt” sizing methodology when screening the budget for the project:

  • X-small project (below $50,000)
  • Small ($50,000-$250,000)
  • Medium ($250,000-$500,000)
  • Large ($500,000+)

You also need to outline the competencies required for the project to be successful, such as:

  • RESTful API development
  • JavaScript/HTML5
  • UI/UX creative elements
  • iOS/Android native app development

Checking off which technology is needed provides a framework for the size of the team required to deliver the solution. Once you have the framework, it is a matter of scaling to meet the budget. Is this 100 percent exact? No, but I give the scope of the project to the managed service provider, which will have its project managers, Scrum leads, developers, and designers. This is the method I prefer to use because it gives me an opportunity to grow a relationship with a strategic partner.


The boutique is, in many ways, similar in concept to managed service. The difference is that a boutique specializes in a particular function.

An example is Internet of Things (IoT) technologies that are highly specialized. The boutique approach can find you the highly skilled company that works on small, expensive projects.


The ultimate way to source a project is with crowdsourcing. The model works when you post a clearly defined idea to a crowdsourced delivery site such as The best ideas are smaller in scope such as:

  • Develop UI UX for a mobile app that has to have X, Y, and Z functions
  • Build iOS app for iPhone using APIs A, B, and C
  • Reduce the time it takes to return a dataset

Crowdsource communities often have hundreds of thousands of members all over the world. The objective of this delivery model is to ensure that each company sponsoring a project is getting immediate access to the brightest minds and sidestepping the middleman.

Cash prizes are awarded to the winners of each project. For instance, a UI design campaign can have a 24-hour turnaround competition awarding $2,000 to the winner and three $500 runner-up prizes. The particular time frame, the award, and the size of the target group in the delivery community will determine the number of results. The power of crowdsourcing is that it forces the good ideas to float to the top.

Third step: The foundation for success

Building mobile solutions is relatively easy. What is not easy is ensuring that those mobile solutions remain operational and secure.

The following criteria identify the foundation for success:

  • Governance
  • Developer tools
  • Communication

Governance defines how to design an app that meets your company standards, what the certification process looks like, and how to communicate progress.

The developer tools you currently use to manage mobile solutions should be clearly identified. List build tools, regression testing, and UI tools. The vendor you pick should adapt to your toolset.

The communication tools and cadence should also be clear. Break down what communication meetings you expect (meetings, standups, retrospectives, etc.) and the tools you use (email, instant message, Slack, Skype, etc.).

The mobile world is changing quickly. The method of developing an RFP is also changing. There are an increasing number of options companies can choose from to pick a vendor. The continuous delivery cycle that mobile is dictating necessitates a new set of tools needed to ensure successful delivery.

Have you acquired tools or a platform for mobile development ? What suggestions do you have for development organizations who are going through the decision-making process? Let us here from you in the comments section below.

Keep learning

Read more articles about: App Dev & TestingAgile