From August 2011 to August 2014, I spent 3 years building up Cognizant’s mobile practice from scratch in Europe. Together with my colleagues we learnt a very large number of lessons, many of them the hard way – still have the scars to show for it! During this time, globally, we worked with an ever increasing array of clients, projects, partners, and challenges. From this collective gold-mine of experience, I’m distilling 10 key learnings. The number 10 here is arbitrary and could easily be 15 or 20. But here are my top 10.
Worth mentioning, these learnings are not about how to build apps or solve technical issues, but about how Enterprises go about embracing mobility.
1. The App Launch Is The Start, Not The End of the Journey
Too many businesses bring out the champagne when the app hits the App Store, as though the job is done. This is a bit like an F1 team heading off to the pub after getting the car to the start line of the race. The real work may just be beginning. Especially if you’re focused on the actual business outcome and not just taking a narrow ‘IT approach’.
Even if you just wanted to get the app launched, you would still be advised to wait for at least version 3. Invariably, the version 1.0 of the app will have a ton of assumptions or choices which will not withstand contact with reality. Often after a couple of iterations these have been weeded out, so you’re approaching stability by Version 3.
In any case though, this is just getting to the races, as I mentioned earlier. You still have to do run the race – i.e. deliver the business outcome and program. Having a clear set of milestones around business objectives will enable you to think beyond the launch of the app.
One of our clients had plenty of anectodal evidence about how the app was doing but it wasn’t something they were tracking any more. Consequently, they always found it hard to fund projects. Another client revised the application through the year continuously making changes and improving the user experience. Not only did the app do very well, but it created a tremendous business impact as well.
2. Analytics Canot Be An Afterthought
I once met a CIO who had to keep pointing to app-store ratings while presenting the mobile updates to his board, but still didn’t have analytics embedded in his app.
Everybody agrees the value of analytics and it’s role in the lifecycle of the mobile app. But all the head-nodding that goes on at the early stages of discussions doesn’t usually translate to actual investment of time, effort and money to baking in an analytics model into the early stages of the app. All too often, its treated as something that’s really important but ‘we’ll come back and fix this in the next version’. The next version never arrives, as you well know, for a lot of apps.
The huge logical fallacy here is also, of course, that we will magically know what needs to be changed in version 2.0 or that we will be working off a frozen product roadmap, with no thought to what people are actually doing.
The right way to do this is to think about the key assumptions that your app depends on (e.g. ‘users will check the app outside the home’) and build in data collection and analysis models that validate or disprove these assumptions. The latter is more critical to the improvement of the app obviously.
3. Governance May Be More Urgent Than Strategy
This is a very bold statement, but bear with me here.
For many businesses there is a massive opportunity and innumerable opportunities to deploy mobile solutions. Trying to corral all of these into some sort of master-plan may be both unfeasible and counter-productive. And in most businesses, nobody is waiting for the strategy. As the saying goes, anybody in middle management with a budget is building a mobile app.
There is a debate to be had about what exactly a mobile strategy implies. But given this situation, a more urgent need, usually, is to create a governance model around the dozens of apps being built right now, in your business, by big and small providers, and in very disparate environments. The governance process needs to define methodolgies, processes, gates and frameworks – around those aspects, such as security or middleware which will form the basis of your enteprise mobility strategy.
The likely scenario is that all these apps will need to be integrated, maintained and enhanced. And the only way to do this with any control of costs and complexity is to ensure they follow published guidelines, no matter who builds them.
I’ve met companies who have built over a hundred apps. They no longer have any control or even track of all the apps built, the amounts of money spent or what it is costing them to manage these apps, annually. There doesn’t seem to be any point taking about strategy in this situation.
4. Structure Around MCOE To Get The Best of Biz & Tech
The oldest truism in IT is that business and IT have to work hand in glove to ensure success. Yet, when it comes to Mobility, this is probably even more true, and very rarely followed.
The reason it’s more critical, is that mobility is a highly consumerised technology, in a nascent stage of maturity and lacks the standardized business case references of more mature technologies, with huge opportunities for specific innovations. A major airline we spoke with explained that converting a bunch of paper based manuals (which had to be mandatory carried on all flights) into iPads meant that the fuel savings across flights could more than pay for devices for the whole company.
And the reason it’s rarely followed, is that there is also no clear standard for how mobility should be structured. In some businesses it’s a part of an omnichannel strategy. For others it’s driven by IT. For still others, it’s part of the innovations group. And others follow a bit of each. Often, Enterprise Mobility is owned by whoever has been brave enough to volunteer for the job. This is much more a marketing challenge than an tech problem.
In the absence of a clear hierarchy, the MCOE is often a very good way to get the key people into the core thinking group. End user computing, IT and applications, security and compliance, marketing, line of business managers and HR and internal comms – all of these teams could potentially have a seat in the MCOE, in addition to architects and vendor managers.
Analyst firms such as Gartner have argued that establishing the MCOE is the most important piece of your strategy. I would definitely agree that it’s a critical structure to put in place for the next 3 years, at least two of our global clients are well down the way towards establishing a Mobile COE.
5. User Centred Engagement Redesign – It’s Harder Than It Sounds
There are two premises which put mobility projects completely outside the comfort zone of IT. They involve Engagement Redesign and User Centred Development.
Traditional IT has usually put the application complexity front and centre. Large amounts of information being stored, retrieved and used by users who are themselves multi-tasking. The PC era has lasted for some twenty years and even on the web, much of the engagement has been PC led. Suddenly we are forced into a rethink. People aren’t coming to the website. They are engaging with you on social platforms, apps, or other new ways. The digital world is blending with the physical world. The problem is no longer about how to put all the information in front of the user, it’s actually how to get the user to stay engaged. Not just how, but why? And there is a great upheaval in progress that traditional IT has never had to deal with.
The sharp end of this change, is the user centric development approach. The combination of consumer-grade technology and experiences, the shift towards engagement centric applications and focus on simplicity means that the entire development approach needs to be modelled around the user. This is not the black magic of ‘creative’ work, but the scientific application of service and product design principles, and ensuring that the user experience is what drives the features and app functionality.
All of this makes it incredibly hard to reconcile this with traditional IT approaches. Be prepared to rethink a lot of stuff, if you’re invested in traditional IT processes. This is why so many businesses are still trying to work with digital agencies as well as systems integrators, to bring these worlds together.
6. Mobile Strategy – Riding The Penny Farthing?
All of this is not to say that strategy doesn’t count; it does. The question though, is: what exactly is strategic in this space?
The biggest challenge that we’ve seen is what I would call the penny-farthing challenge. Your organisation is like the penny farthing cycle. The little wheel in front is the digital part of your business. Agile, fast moving, new features and releases every 6 weeks. The large wheel is the traditional part of your business. Slower, harder to move, locked into your traditional systems and ERPs. Nothing happens in 6 weeks. Yet, these two wheels have to move at the same speed, given that they’re part of the same entity.
The answer lies in the gearing of course. The piece of the puzzle that ensures that these two wheels turn at their own speeds but the business as a whole moves forward in a cohesive manner. In your business, this is the all important middleware that allows these two wheels to turn at their own speeds. Getting this layer in, and getting it right is probably one of the most strategic decisions for enterprise mobility. Arguably, much more important than which apps to build.
An energy company for whom we built a mobile strategy started with the idea of defining business cases but ultimately moved towards establishing a middleware platform as the defining area of the strategy.
7. Skills Shortage
Certainly, one area of strategic importance is the skill mix. Given the speed of evolution of the technology, coupled with the surge in adoption, the team and skills you bring to the table can make all the difference between success and failure. Thus it is, that everybody is looking for those gilt edged developers, designers and architects who can build the path into the future. Customers, vendors and disruptors are all competing int he same skills market.
You don’t need an army, but certainly the core team you put together is again, an extremely strategic success or failure factor. A number of disparate skill-sets are required for mobile success – from service design, to architecture, to device optimisation.
As much as technical competence, the trick is in finding people who are comfortable dealing with the unknown, and capable of setting their own standards.
8. Product Maturity Is Low. Plan for It
Undoubtably, you will evaluate some off the shelf products – MEAP/ MCAP/ MADP or some variation of the theme. Cross platform tools, api managers, MBaaS layers – take your pick. Just remember that we’ve had 3 generations of products in the the last 3 years. And M&A activity abounds even in the nascent space. Feed Henry was just acquired by RedHat. Antenna was acquired last year by Pega. SAP and IBM have build up their product suites through acquisitions. There is therefore a risk that the product you choose may be acquired or merged/ morphed over the next 12-18 months.
There is also therefore the high probability that you will discover in the course of your project that the product doesn’t exactly do what it ‘says on the tin’. This is not a pot-shot at product companies. It’s a reminder that you can’t get to the levels of maturity we expect in traditional products, because they simply haven’t had enough time yet, and the landscape keeps shifting. So planning for a few bumps in the project will help you save some sleepless nights.
For one of our Nordic clients we faced a huge amount of trouble in trying to integrate an off-the-shelf middleware tool with an enterprise product which formed the back end. It almost came to the point where we were ready to walk away from the project to cut our losses, but fortunately the collective decision to stick with the project meant we stuck with it and it’s now a successful product.
9. Over-Investing in Project Management Pays Heavy Dividends
Taking the earlier point into consideration, along with the complexity of networks, devices, operating systems, business expectations, testing issues, and fast evolving user needs, you can not over invest in management of the early stages of your project.
Project management is definitely more complex in many ways for mobile apps, than for traditional projects for the reasons above. I can certainly point to more than one excellent project which owes it’s success to the policy of over-investment in early stages. We hired a top notch project lead with specific product knowledge and his input helped reduce a significant component estimate by about 30%, in the course of a half hour call. This one incident itself made his involvement financially worthwhile and the early brought a lot of confidence from the stakeholders involved. The application in question is being rolled out across dozens of countries globally.
10. Are You Ready to Di-Phy?
Digital + Physical = Di-Phy (this is entirely my imaginative acronym)
Somebody defined the smart phone a while ago, as a remote control for the world. Increasingly, it is becoming the bridge between the digital and physical worlds. Traditionally, in the digital environment, you would be on a desktop/ laptop and in an information universe which was only loosely connected to the physical world. You might comparison shop for a TV for hours, but then you would take a printout to a real world store and struggle to match specific model names and numbers to the in-store variants.
As everybody knows, the smart phone changes that and allows users to scan and compare from inside a physical store. Also, the point of search or sale is everywhere. Virtual and augmented reality models are blending the real world and the digital worlds. Add to this the presence of wearbles, sensors and the IOT and you have an emerging scenario where the line between physical and digital is increasingly blurry, and this opens up a white space for new business models and solutions that create entirely new value for users and customers.
You need to be thinking about the physical aspects of your business – your products, your supply chain, or your distribution and retail, and look for ways in which the mobile phone can in fact become a point of access, management and control, of the physical environment.
As I said earlier, there are many more lessons we’ve learnt from the volume and diversity of the mobile projects we’ve undertaken. This is just my list of 10 that seem critical to me right now. I would love to hear your views on lessons learnt!