How to Get Mobile App Development Requirements Right— The First Time

By Rachel Nitschke | Apr 05, 2016

In 1961, Alan Shepard piloted the mission into space. When reporters questioned him later on what he thought about as he waited for liftoff, he famously replied, “That every part of the ship was built by the lowest bidder.”

This sentiment echoes the practices of many companies in evaluating development teams with such high-stakes digital products. Outsourced teams with rock-bottom development prices seems like an easy solution to ease the budget, but what many miss in structuring a team this way is the creativity that experienced development teams bring to the development process. Evaluation processes need to not only evaluate how equipped the team is to handle product development, but also the intangible element of how well they can apply creative solutions. Part of that stems from working side-by-side with designers on the development in a product team, where both can benefit from brainstorming.

Dedicated product teams are the most effective configuration, for both creativity and understanding of your mobile product. Your product will have dedicated developers and designers working on it, and are able to use their deep understanding of the context of your product. Think about chefs working in a kitchen: each chef preparing one meal for table will create a better experience for the customer than a team of different chefs rotating in and out for each step, which is how some agencies approach development teams. A master to-do list dictates which tasks are upcoming for all of the products, and developers pick them up as they finish others. It’s easier on the agency, but the product loses that cohesive team.

Security is a major concern for companies pursuing digital products. The possibility of hacks of customer or company data and the million-dollar damage that comes with it is enough to dissuade any management team from investing in digital transformation. Experienced development teams can help to outline the data encryption and other precautionary measures required for a specific digital product. Security solutions need to be customized to the needs of the product, and experience in doing this needs to be included in any RFP.

In order to identify vendors with the right experience, you need to outline the back-end integrations, platforms and devices applicable to the product. Even if this is not set because you are looking to the development team for guidance, you should still provide the universe of possibilities so the vendor can insure that the resources are available.

A common resource problem is API shepherding. Too often, when writing the requirements for a mobile product, the manager of the product assumes the APIs are ready and functioning. By the time development launches, however, the team realizes this is not the case and thus, causes significant delays and cost overruns. Documenting APIs is also absolutely necessary for the experience of the development team and ability of the API to perform. Numerous tools exist to automate these tasks. Swagger, Mashery I/O Docs, and Apiary.IO are a few. You should provide a minimum level of documentation to evaluate an API’s ability to meet design requirements and build a necessary fake API server for development if needed. Your documentation should include a version history to note changes to APIs. It should also include a section outlining any policies and authentication requirements.

The final portion of your development section should address the methodology the development team follows for developing mobile applications. Not all methodologies are created equal; some methodologies will be more effective for your product and team. Consider how often you want to be communicated with and how much tweaking you will want to do based on user feedback.

Agile vs. Waterfall Development for Minimizing Risk

Agile software development focuses on iterative builds of small, client-approved portions that are delivered as soon as they are ready. Variations include scrum, XP, and DSDM.

  • Regular, iterative releases for new features
  • Continuous user feedback
  • Constant communication with clients
  • Dedicated product teams

Waterfall software development is a sequential design process, where each step is completed one after the other with meticulous documentation. The project is delivered all at once.

  • Focus on record-keeping
  • Lowers impact of development employee turnover
  • Long development cycle
  • Release of the entire product all at once
  • User feedback after launch

Questions to include in the RFP:

  1. What type of development methodology does your team follow?
  2. Explain the major steps of your process of developing an app from start to finish. Watch out for long development cycles with no user feedback and a lack of incorporation of the design team.
  3. How will your team minimize risk? Some firms will give relatively standard answers here. Look for ones that include the business case in their development.
  4. Provide three examples where the development team applied creativity to a development issue.
  5. [If needed] Does your team have the capability to provide API shepherding as part of the project?
  6. Will you provide a dedicated product team who handles all tasks for the application? How will the team be configured?
  7. How often and well does your team communicate with clients?
  8. Explain how you would approach the security of this application.

Understanding Your Maintenance Needs

Creating a digital product, rather than completing a project, also creates another wrinkle for traditional RFP creation. Digital products are never finished, but projects are completed. This mirrors the reality of applications, who require regular maintenance and new version releases to address issues. Case in point: Throughout 2014 Amazon, Walmart, and Geico updated their respective apps between 20 and 25 times, and earned the highest average ratings in the App Store.

It’s important that the vendor is able to create a plan for each release, with analytics and measurement ongoing after the first release to improve the later iterations. The analytics and measurement should stem from the business KPIs outlined, as well as general usability and performance of the application.

Apple releases a new version of its OS each year, and at the very least, the application needs to conform to version specifications to remain functional. There are also new features with the releases that can make an impact with the user experience, such as the heightened sensitivity of the 3D touch that allowed for different actions based on the amount of force in the touch.

  1. How will an ongoing engagement for maintenance of the application work, in terms of pricing and labor? What type of maintenance plan can you provide?
  2. How will the performance of the app be measured after the launch through analytics? Will someone at the agency monitor and collect this data?
  3. What analytics do you recommend? What tools does your team use to monitor performance?
  4. Provide two examples of projects with ongoing maintenance and analytics, specifically describing how the app evolves with each release and why the specific analytics tools were selected.

Crafting Your Quality Assurance Strategy

Showing the timeline to the management team immediately turns into a discussion of where can cuts be made. Too often, this area is quality assurance of the application. Hershey’s made this mistake during their legacy ERP modernization– and saw $100 million worth of orders go unfulfilled.

Every RFP needs to assess the QA capabilities of agencies, who are guilty of the same mindset when it comes to QA. It’s cheaper to not test on real devices by using simulator programs, but these miss crucial bugs. The same applies for solely relying on automated testing, as opposed to including manual testing in the process as well. Automated testing is a great predictor of software behavior, not human behavior. You may be gambling on the quality of the product and risk botching the launch.

Questions to include in the RFP:

  1. Explain your QA process. Make sure that there is a thorough and rigorous process in place. Does the QA team learn about the process through their own experience?
  2. Does your QA team and development team work closely together?
  3. How many full-time employees are involved in QA? While it may not be completely necessary to use only FTEs, relying on all subcontractors poses risk.
  4. Does your QA Team test manually, automated or both? Do they use any simulator programs?

The world has changed for mobile apps, and with this guide, your team will be able to take full advantage of the technology with a forward-thinking and ROI-driven vendor for you next digital product. Download the editable template below to easily create your RFP.
requirements_for_mobile_apps

Get in touch

Marketo Form