Risks and Mitigation Strategies in App Development
Published on November 30, 2020
Development of digital products like mobile apps and internal software tools is fun and exciting and sometimes trendy.
It’s also rigorous, expensive, and never a guaranteed success.
Given the length of time and investment of resources needed for mobile development projects, it’s important to identify potential risks and put strategic plans in place before any coding actually begins.
In that light, we’re sharing some common risks we’ve encountered at JMG around execution of services, deliverables, timeline, and budget, and the mitigation strategies we have in place for each to increase success of our projects.
Three common risks for the execution of services include developers moving on, an agency going out of business, and a breakdown in communication.
Developers Moving on
As with anything in life, people come and go. When you’re working with a technical team, you want to know how they handle developers moving on mid-project.
One of the strengths of working with a smaller team is their flexibility and ease of bringing in new team members. At JMG, we frequently plan for the unlikely case that someone gets in a catastrophic accident where they can no longer work. In that case, we have additional team members who can pick up where they left off, along with a network of friends who can come on board in a pinch if we need them.
Company Going Out of Business
In this economy, the uncertainty of the COVID-19 virus is enough in and of itself to cause businesses to fold. Knowing how a company is structured in terms of their financial position, the strength of their client load, and expansion goals can give you confidence in their future outlook.
Smaller teams typically work with minimal operating overhead. For instance, our team has been a lean organization from the start and primarily works remotely, mostly out of a necessity borne from the beginning of our company (apparently, my basement wasn’t a very comfortable environment for everybody).
Of the three risks identified for the execution of services, based on nearly a decade of developing software professionally, this risk has the highest chance of occuring.
Breakdowns often come as a result of the project not being a priority for either the client or the agency. The longer a project takes, the less enthusiasm the team has, and the more likely it gets put on the backburner in favor of more exciting projects.
A mitigation strategy here is simple: establish a consistent schedule to chat and share progress. Set clear expectations at the beginning of the project for when all parties are available to chat, and work with a team that prides itself on responding as fast as they possibly can.
Any project of significant size runs into this problem from time to time, and our mitigation strategy is to constantly follow up with our clients to make sure we all get what we need.
Modern best practices with software development handle a lot of the risks associated with the deliverables. Code shouldn’t be lost if it’s routinely committed into a shared code repository, for example.
The biggest risk here would be a seismic change to one of the underlying platforms upon which your app is built. For example, maybe Google changes the terms of their Mapping API making its use unfeasible.
Our mitigation strategy in this case would be to alert our client of the change, then come up with a strategy to work around it and execute the change. It might result in a delay to the schedule, but you as the client should be kept in the loop the whole time, working together with your tech team to come up with a solution that works for everyone.
Breakdown in communication and changes to scope are two risks that could affect the timeline.
Breakdown in Communication
As mentioned already in the Executing Services section, the biggest hindrance to completing a project on time tends to be a lack of constant communication. You want to work with a team whose strategy is to over-communicate to make sure you are always in the loop with where things are at.
In the event that something happens where we foresee a delay, we tell the client as soon as possible. We’ve learned from past experience that the sooner we share bad news, the sooner we can work together to come up with a solution and move on.
Changes to the scope
Every software project we’ve worked on has ended up in a slightly different place than when we started. This is part of the nature of working with software; as users use the software, they find ways it can be better.
Our mitigation strategy here is to be crystal clear with our user stories up front. When an idea surfaces during development, we make a note of the idea and save it for the next phase. Our project managers are really good at keeping projects focused, which keeps projects on track and delivered on time.
If, however, a feature that we didn’t predict becomes necessary to include, we issue a change order and adjust the timeline as necessary. Again, it comes back to communication: we are happy to build anything you want, but we need to be realistic about what we can fit in with the bigger vision.
You know the importance of a budget for your organization, and the tech team you work with should know it too. You want to work with a team who will do everything they can to build software for the budget given and bring your vision to life.
We have a lot of experience with estimating how much software is going to cost, but if an estimate for building software is way off, we work with our client to explain where we screwed up and figure out how to move forward.
The other risk associated with budget falls under Changes to the Scope as addressed in the previous section, when features are added to the project that weren’t part of the original plan. In this event, we scope out the feature and tell our client what the additional investment will be.
If you’re leading the charge on a digital product within your organization and concerns like these keep you at night, give us a shout. Let’s see if we can help.