As our team has worked on software projects over the last decade, one of the things that we have noticed is that being a bigger company or a smaller company doesn’t dictate the success of your projects. In general, a good project will 
result from planning, process, communication, attention to detail, and constant learning… whether you are big or small. Its likely that at a small company, the communication piece is easier, but the other pieces are just as hard.
When you throw mobile software development into the mix, you add additional complexity that can derail your project even more. As our team has matured we have identified a number of tips and tricks to keep our projects moving forward. As we work with our clients, the following are 10 things we always try to impress upon them to ensure that their mobile projects stay on track:
1. Understand the Implications of Technology Selection
When you hear your management ask the questions: “Can we do a cross platform application?” or “What about this technology all the startups are using?” be ready to have an honest discussion about what you really need out of your mobile technology and what would make the most business sense for the organization.
Considerations:
- Complexity of Your Problem Set – You need to understand what you are going to accomplish by building a mobile application. Who are your users? What types of devices do they have? What connectivity will they have? What sort of performance expectations do they need? What are the key features? Be realistic in your assessment of your current problem set, don’t try to plan for 5 years down the road.
- Strengths of Your Current Team – Understand what your team is capable of. If you have a lot of strong developers in one technology, can you re-use those strengths?
- Long Term Support – If you choose a technology platform and solution, understand the costs of long term support being cheap on technology selection can sometimes hurt you down the road.
2. Plan Your Device Management and Software Distribution Strategy from the Start
We can worry about deployment after we get our apps built is a thought that you must prevent from becoming prevalent. Whether you are an enterprise or a small company, you need to understand how you are going to manage company provided mobile devices and software. Ideally device and software management should be in-place well before you ever deliver any software to your QA teams.
Considerations:
- Device Mix – Understand the types of devices you will be creating a solution for. Are you deploying ruggedized devices/Tablets/Phone? Are you expecting employees to provide their own? Android/Blackberry/IOS/Windows Phone? Tablets/Phones?
- Initial Device Deployment – How are you planning on piloting software to your initial UAT users and pilot sites?
- Complexities Based on Your Org Structure – Larger companies have more segmentation such as geographical or product division.
- Deploying and Supporting QA Regions – You need to understand how you are going to manage your QA devices and how you are going to land software on those devices. This becomes even more important when you need to land software on devices at offshore QA sites.
3. Control Your Scope
Finance VP with budget: Can we add augmented reality to this finance app?
You: “No”
Finance VP with budget: “Why not?”
You: “Can you triple the budget and double the timeline for the project?”
Finance VP: “No”
You: “Ok… we are in agreement”
One of the easier ways to ensure that you project is successful is to say “No, but we can add that to a future release”. Whenever you get a scope creep question from your business owner, remind them of the Scope-Time-Budget triangle: If they want to increase the Scope side of the triangle, they will need increase the Time and Budget sides to make the triangle work.
Considerations:
- Know Your Application’s Goal – Having a clearly written charter that describes the users, usage objective, and ROI will make it a lot easier to have honest discussions around controlling scope.
- Focus on MVP for the Initial Releases – a “Minimum Viable Product” for the initial release ensures that you will not be investing a lot of budget/time into features that are not core to your usage objective.
- Minimal Platform Targets – Limit your initial scope to the most used device by your user base (e.g. Tablet/Phone or IOS/Android).
- Prototype Complexity Early – If part of the mobile app seems complex, create a prototype or mockup to see if it will actually be usable (before you invest a lot of your dev team’s time).
- Usability is More Important than Flashiness – Using standard UI elements may seem boring and not “innovative” but you should be focusing on your app’s goal instead of trying to retrain users on a new UI paradigm.
4. Always be Thinking About Performance
Short-sighted developer: This app worked great on my iPhone 5s, I don’t understand why our employees with Galaxy S’s are complaining
One of the drawbacks of having a consumer mobile industry where devices that double in speed every 16 months is that there is a wide range of performance in the wild. Developers with the latest device will often miss performance issues on older devices. In addition, not all network are created equal. Your team needs to think about all of the edge cases when you have different devices in varying network connectivity states (WiFi, 3g, LTE, busy coffee shop).
Considerations:
- Framework Selection and Focus – Your Technology Selection from item #1 above will dictate a large number of your performance constraints. Be sure that you are aware of those constraints and the frameworks within those technologies that have performance tradeoffs.
- Network Performance for Cellular – Cellular data has gotten better over the last 10 years, but it is still hit or miss at least a few times a day for most users. Be sure to account for intermittent connectivity in your mobile applications.
- Production Size Data – Ensure that your development and QA teams test with data that is of a representative size for production data.
- Data on Device vs Data on Server – Understand the tradeoffs of constant data synchronization, stale data, and data conflict resolution. Weigh these tradeoffs against the network profile for your users.
- Minimum usable devices – If your user-base has older devices, be sure to test on physical instances of those devices (not emulators).
- Tooling for Testing and Measuring – Include application tooling to log performance timing to pinpoint where your bottle necks are.
- Test on Devices Early and Often – Emulators have gotten better, but they still are not up to par for representing actual devices. Get your development teams testing on devices as early as possible.
5. Involve QA from the Start
The two biggest mobile app QA pitfalls that you will hear from inexperienced IT management are:
- Our developers do a good job of testing their apps
- We can just test in an emulator
Testing software for mobile devices is much more difficult than testing software for the web or for desktop applications. The number of variables associated with testing skyrockets when you think about: inconsistent network performance, varying screen size, varying performance, multiple OS versions, user hand preference, user physical limitations, device power state handling, limited device memory footprint…. the list goes on.
With all of these variables, it is critical to involve QA early on to start developing test plans that take into account all of the moving pieces.
Considerations:
- QA Needs Devices and Tools Early – QA should have all of their devices setup at the same time that the development team gets their devices.
- Testing is More Complex on Mobile Devices – The number of moving parts for mobile solutions is pretty high. Your project plan and budget should account for this complexity.
- Data and State Complexity – Simulating production data and varying production states is no easy task. Your QA team will need almost as much technical competency as your development teams to ensure that they can simulate all of the complexities related to mobile applications.
6. Invest in a Designer with Mobile UX Experience
Once upon a time, I had a client who may have actually said “Our designer has done famous ads for the big 4 car companies.”
As much as I appreciate the print ads that car companies put out, that design skill set doesn’t always translate well into mobile design. UX architects with mobile experience understand the nuances of mobile flow, app state, screen resolution, pop-up keyboard, and mobile data capture. Most of these nuances will be missed if you just try to throw a web designer at a mobile application. Investing in and spending extra on a designer with good mobile experience will save you money in the long run and will help your application meet it’s stated goals.
Considerations:
- Desktop and Web Doesn’t Translate well to Mobile – Extra elements and small buttons can render a mobile application unusable.
- iPhone and Android UX is Different – If you are building for a specific set of devices, be sure that you clearly state that to your designer. The UI and UX differences between Android, IOS, and WP8 are very different, trying to build and IOS UI in the other platforms makes that app hard to understand for users who are accustomed to those platforms.
- Leverage Existing UX Patterns – Your Designer should leverage existing mobile patterns as much as possible. Adding new UI techniques may seem cool, but they will typically end up making your app less usable.
7. Get the right tools for everyone on your team
Let me start out with the summary of this point: “If you develop for IOS, all of your developers should have a Mac. “
If you are planning on building for a specific mobile technology (such as IOS), be sure that your team has the right tools for the job. Your team should not be sharing machines to do their development builds. Every developer should have the devices that they will be developing against (whether they are onshore of offshore.) If you try to skimp on tools and hardware, the long term result will be lower quality and project slipage.
Considerations:
- Everyone Needs a Mac for Cross Platform – If you are building IOS apps, everyone should get a Mac. VM Ware is great at running windows 7/8 inside a VM on a Mac (in fact the fastest windows machine I have is a VM on my MacBook Pro)
- Every Developer Should Have One of Each Device – If your developers are developing a cross platform app, they should have one of each of the target devices on their desk.
8. Remember that you will have to support the application
“It only took these consultants 7 weeks to build this, it should be easy for our team to support…. Right?”
Application support is not easy, especially in the enterprise where apps can still have a lifespan of 4-10 years. When you build a mobile application, you need to be thinking about how the help desk is going to support it, how you are going to proactively monitor the app, and how you are going to do bug-fix and improvements in production.
Considerations:
- Hiring and Retaining Sharp People is Hard – Mobile apps tend to have added complexity, you need to find qualified people to support these apps as they go out in production.
- Understand if Supportability is More Important than Performance for Your Apps – Some of the more performant technologies and frameworks are harder to learn and develop against. If you have a cheap IT support VP, you may want to consider using a simpler technology that is easier to support, even if it doesn’t give you the ideal performance.
9. Get the right skills and training for your Dev teams
Train Early, Train Often…
If you want to have a successful set of mobile projects over a long period of time, you need to invest in your internal development teams. Training is cheap compared to the cost of mistakes or the cost of your employees overall salaries. Sending a developer to a 4,000 dollar training course for a mobile technology will likely pay for itself in the first two months of a project.
Considerations:
- Focus on Training Early On – Before you start a project, your developers should all be trained in the technology they will work on. OTJ training is nice, but it can lead to learning through mistakes, which will slow your project down.
- Lack of Process can Kill the Benefits of Certain Technologies – If you leverage specific frameworks for development, but then you don’t have standards and templates around how to use those technologies, different developers will use them in different ways. All of your developers should be using similar processes and approaches to ensure your app will be supportable.
10. Skip “Rolling your own”
Joel Spolsky wrote a great piece on how younger engineers are always more eager to try and build from scratch instead of re-using and fixing existing software. Historically, this has been called “re-inventing the wheel.”
Due to the complexity of mobile development, trying to roll your own frameworks and supporting services can lead to a lot of problems. Your teams should try to leverage existing known frameworks where possible (even if they don’t fit perfectly). Areas where this is the most critical are: security, data synchronization, hardware interaction, and thread handling.
Considerations:
- Focus on Reusing Public Components – Try to leverage open source components if they are available. If your developer must roll their own, they need to be able to clearly articulate what they could of used, and why they chose not to.
- Custom Functionality Leads to Key-Man risk – When a smart developer writes their own framework or service to handle something very complex, you run the risk of not being able to support that component after they leave your company. To be on the safe side, you should always assume any one of your developers will not be around in 6 months.
- Focus Your Teams on Business Functionality – Not Architecture – Your development team should be focused on building a mobile application that solves a problem or meets a business objective. Their primary goal is not to be building frameworks and new architectural component.
