I’ve spent the past several years of my career focused on custom mobile projects for some of Salesforce’s largest and most prominent customers. Many of these projects have been showcased in some very memorable Dreamforce keynotes, and I’ve had the pleasure of leading a team of the best and brightest and working with some amazing customers at the same time. Over the years, I’ve found that some things work better than others. Some businesses approach custom mobile development projects in ways that help ensure their success over the long term. Others get in their own way. We always do our best to guide projects toward success, and this post is a collection of some lessons learned over the years.
1. The mobile device landscape moves fast, and so should you.
IT groups are tasked with keeping the technology landscape sane and reasonably unfragmented. It can be tempting to try to put the brakes on mobile development projects while you figure out your device strategy for the next 3-5 years. After all, you don’t want to waste money and time developing an app for a device that you won’t be using in 5 years, and hardware device leases run for several years. If you’re building a tablet app, is it better to go with iPads or with Android Tablets? Or is it a better long-term strategy to focus on a Windows device that combines touch-screen tablet functionality with a laptop?
The real answer is nobody knows. The device landscape moves so quickly that three years from now we might all be using some new magical device from a company none of us has heard of yet. You can try to hedge your bets by building a hybrid app with Cordova or using a MEAP that claims “write once run anywhere” functionality, but while you’re dithering about making up your mind or building an app that can be ported to any possible future platform, your competition will be rolling out their solution, capturing your market share, and leaving you behind.
It is possible the app you’re building now will be replaced in 5 years. The device landscape will shift, and your business objectives will shift. The market will change, and you’ll be a VP somewhere else anyway. It’s far better to focus on the here and now — solve the problems that you have today, make sure to define and focus on the KPIs that will make the project successful over the short term, and don’t be afraid to re-adjust your direction in the future. You’ll have more experience, more information, and will make a better decision then anyway.
2. Custom apps are like pets, they need care and feeding
If you’re planning to build a custom mobile app, whether it’s an internal project or something you’re working with an external consultant to build, you need to plan for maintenance. It’s not the sexiest aspect of mobile app ownership, but it is the reality of living in a world of constant updates. Apple, Google, and Microsoft roll out Operating System updates to your users frequently. You need your users to update quickly because they security patches are usually a part of these updates, and users want to get new OS features. Salesforce rolls out new releases three times each year. We don’t live in a world anymore where you can write a .net app with ActiveX controls for IE6 and let it sit completely unaltered for the next 10 years. Successful consumer app vendors are testing their builds on beta OS releases to catch any issues before their customers see them. They’re also taking customer feedback, prioritizing it, and implementing new features continuously. You should be doing the same thing if you want your app to be successful. This kind of care and feeding requires a long-term commitment to the health and success of the project you’re working on today.
3. Deploy a Mobile Center of Innovation
The Mobile Center of Excellence is a well established IT concept, but falls short. Mobile COEs are tasked with the role of ensuring that various business and IT groups throughout the company are coordinated and standardized in the way in which they approach mobile projects. Cloud technologies like Salesforce have enabled business groups to embark on custom projects, and the goal of the Mobile COE is to bring stability and consistency to these types of projects. They are responsible for establishing guiding principles and best practices, and ensuring that the various business and IT teams that may be working on mobile projects aren’t missing out on opportunities to coordinate with each other. They also usually choose recommended or approved tool sets and ensure that mobile development projects aren’t creating architectural or security issues for the organization. Gartner recommends that Mobile COEs be established for only a few years before these decisions are rolled back into core IT teams.
The Mobile COE sets the bar too low. It sets the focus only on standardization and consistency, not on innovation. Innovation is inherently risky and failure prone. The most successful partnerships I’ve seen between business and IT groups have been when all parties are committed to taking calculated risks, working closely with end-users during the development process, and acknowledging that the best technology decisions are the ones made as an integral part of projects that are solving real business problems. When planning a Mobile COI, we should focus on individuals and interactions more than process and tools. Making technology decisions as late as possible might seem irresponsible, but “Just In Time” decisions are a well-established principle of Lean development, and help teams make better informed decisions. They also enable a team to more quickly recognize when they’ve made the wrong decision, and to “fail fast” in order to make a change in direction with as little impact to the project as possible. As Henry Ford said, “failure is the opportunity to begin again more intelligently”.
4. The user is extraordinarily important
We tend to undervalue the user. After all, in a lot of organizations, the end users come and go. Traveling sales or field service roles often have a high turnover rate. We build project teams that include senior Subject Matter Experts who worked in the field years ago. We worry about pulling sales reps away from selling rather than making sure their voice is heard during design. We focus on pleasing executive stakeholders and managing a project toward being “on time and on budget”. We undervalue the impact a great user interface can have, both in how effective it is for the user and also how it reflects the brand that we are putting in front of our customers. We forget about user adoption and change management, and forget that users are pretty good at finding ways to not use tools they don’t like.
The user is key to the success of the project, and key to recognizing a return on the investment being made. If users aren’t able to voice their needs, and have their voice heard during the development process, we risk building a solution in search of a problem. Do ride-alongs with users during design phases, gather user feedback at regular intervals during development and then show them when you’ve made adjustments based on their feedback. After you’ve launched the initial version of the app, these users will be your biggest cheerleaders because they had a role in making it what it is. Make sure to give them a way to provide feedback for future versions. It’ll make the project more successful in the long term.
5. Re-use what you can re-use, but don’t go overboard
As a group, we’ve historically focused a lot on using accelerators during development. We’ve built and maintained Salesforce synchronization engines that are the underlying framework for hundreds of offline-capable iOS, Android, and Hybrid mobile apps built for our customers. Our Digital Sales Aid stands apart as a sales tool, but also as a starting point for creating bigger and better things. They’ve been incredibly successful. That said, over the years, we’ve also dumped time and money into accelerators that have never been used (maybe don’t mention that to my management). If it doesn’t solve a core and fundamental need like offline synchronization, it’s probably worth considering it a one-off that doesn’t need the extra effort necessary to make it a truly reusable component.
6. Open and honest communication
Custom development is messy. If it’s worth building it custom, it’s probably something that hasn’t been done before, at least not in quite the same way you want it. No matter how experienced the team is, they will still be learning new things and making mistakes along the way. As an internal or external consultant team, it can be tempting to try to keep the “sausage making” hidden away, and provide the customer with a single point of contact for requirements gathering and status reporting. Unfortunately, this gives no real visibility into the process or interaction with the team, and that means decisions will be made in isolation. Software development is best played as a team sport, and one of the most important things you can do is make sure the full project team is meeting daily with the customer’s “Product Owner” — someone with full authority to make decisions regarding the application being developed. A strong, active, and decisive Product Owner can be the key to a custom mobile development project’s success or it’s failure.
These meetings take time away from work getting done, so you’ll want to keep them very short, but be sure to have everyone cover what they’ve finished, what they’re working on next, and anything that’s blocking them from getting work done. Action items should be followed up on later. This is a core element of Scrum, but many of the mechanics of Scrum can help make projects successful regardless of methodology being used. Daily scrum meetings with the full team are extremely valuable in opening lines of communication and allowing the Product Owner the ability to make decisions on what to prioritize, and what to cut.
Salesforce Mobile & Emerging Technologies Practice
As Mobile Practice Director, Tom leads a team that architects and develops commercial and enterprise deployments of mobile apps for many of Salesforce’s largest customers. The Salesforce Services Mobile & Emerging Technologies practice is dedicated to helping Salesforce customers achieve more through mobility and innovation. With hundreds of custom mobile projects under our belt, our dedicated practice has years of experience building enterprise mobile solutions with Salesforce technologies. If you want help transforming your business with Salesforce, contact us via your Salesforce Account Executive.