Getting commercial and internal mobile applications out the door on schedule and on budget largely comes down to effectively managing scope.
Scope management is arguably the key to successfully completing most projects, and seems so obvious it's surprising that this critical aspect is often ignored or poorly managed. For mobile applications in particular, where release dates often have more sensitivity than internal applications, keeping scope tightly managed can make or break a release date. Here are some ways to keep your scope managed, and your releases on time.
You can't always get what you want
Key to setting the stage for successful delivery is having an open discussion about what is possible given the constraints of the app's release cycle. The traditional "triple constraints" model of project management holds that scope, resources, and timeline are the available "levers" to control a project, and that any two can be controlled. While this model is conceptually nice, most projects are offered fixed resources and a hard release date. Even if resources are flexible, there are often external constraints whereby throwing people or money at a problem loses effectiveness after a certain point.
In this case, it's important to determine whether the date or the functionality delivered is more important, as one will have to remain somewhat flexible in order to deliver the other. Generally, release dates are more important than the scope with mobile apps, due to the competitive nature of the marketplace and other external factors. If my next app needs to support Android L by the holiday season, I am marching to an immovable calendar set by entities outside my control. With a release date with little flexibility, scope management becomes all the more critical, and your message should be that features and functions will be reprioritized regularly in order to meet the targeted release date.
A hidden scope is a mismanaged scope
A dangerous assumption that is often made when releasing IT-based products is that everyone knows the scope of what's being released. This creates major problems when release dates near, and all manner of "I thought X was in scope!" requests pouring in. Project plans and repositories do little if they're not detailed enough and regularly reviewed with technical and product-focused staff. Be sure that each feature or requirement is captured, and the tasks that implement that requirement are regularly updated with completion status and effort remaining. When you review these items regularly and interactively, challenges in delivery are quickly identified, and all key stakeholders can debate how work should be reprioritized, rather than receiving an unpleasant surprise weeks later. If you're on a tight timeline, holding these meetings weekly is probably a minimum, and waiting for monthly "stakeholder" meetings is simply not sufficient.
Effective scope management requires that key decision makers on the project get into the details. When scope is managed correctly, your product owners will immediately see when development is missing dates, or key tasks are not completed, and you'll be under the spotlight explaining what's going wrong. Similarly, when functionality that's very important to someone needs to slip, they'll demand concessions from others and create some passionate debate. While uncomfortable initially, these discussions ensure everyone has a stake in meeting the release date, rather than work being thrown to the design and implementation teams with an expectation they'll return in a few months with every item complete. All involved parties will also see early warnings when dates become threatened, and can start developing mitigation plans early.
Scope should never be a monolithic "block" that's unmovable and not subject to modification once agreed upon. Rather, scope should be like one's to-do list, and subject to daily reprioritization and task dismissal. That feature that seemed critical when a project was launched might happily be placed in the next release once dates come under threat, and it's only through regular, sometimes heated conversations that these nuances can be realized and effectively managed.
While scope may seem like it's the purview of the product team, it's ultimately the currency that drives the successful release of mobile applications. Agreeing to a common understanding of whether release date or functionality should drive a successful release, "grooming" your scope transparently and regularly, and facilitating regular reviews of scope are key to getting your mobile app out the door.