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!
TOM / EOM – sounds like a soup you might order. But for the purpose of this discussion, put your appetite to one side, and think about Digital Transformation.
TOM or the Target Operating Model is the staple of the consulting framework in transformation environments. The logic being, you have an initial operating model and you enter a transitional phase, driven by internal and external change, and you emerge with a new “target” operating model. It’s an excellent construct and very useful for delivering change.
In the digital arena, though the idea of the Target Operating Model is challenged because of a number of reasons.
Critically, it assumes that the change is a finite and one time activity. This is no longer true. Consider the landscape today. You enter a phase of virtualisation of your servers and networks, and before you finish that you’re in the middle of the mobility revolution. You combine cloud and mobility to create another transformation and everybody is talking about big data and social analytics. And then there’s the Internet of things, machine two machine and smart environments waiting to happen. So which points do you pick as the start and end of the change? And if you took this whole set as one change, would you even survive it?
And then, if the change is not a finite or a single event, what do you assume as your end state or ‘target’ environment? And if there is no target environment you can define, how can you create a target operating model? Would it not be outdated even as you were implementing it?
There could be an argument that these individual technology waves do not affect the business model and are just technology changes. I would disagree with that. Yes, moving from one vendor to another, or upgrading from version n to n+1 is a technology change, though even those projects need to be seen as business change projects. But the waves of technology I called out earlier – from Cloud, to Mobile, to IOT are all pretty fundamental shifts – often creating deep changes in business models.
To add to these problems, as this article in the Forbes highlights, many organisations undertake digital transformation without actually knowing what it is. Many don’t really understand the transformation, many others just see it as platform upgrades.
So here’s the bad news, your digital transformation project is not a one time exercise, there is no target environment and so your target operating model may be in need of an update by the time it’s bedded in.
The likely scenario is that there will be multiple waves of transformation. And here onwards they will all be digital (or at least until we come up with a new word).
Which leads me to my proposition – that perhaps the right way to think about this is as an Evolving Operating Model, rather than a Target Operating Model.
What would be the key features of an evolving operating model? Here are three key ones, though there may well be more.
Building a change capability – at the core of this is the creation of a Culture of change adaptability. I’ve consulted for many organisations where the smallest change has to be handled with kid-gloves and is a source of anxiety and organisational stress. These are all big changes we’re talking about, so there’s a lot of work to be done to make people change friendly. This should ideally be reflected in contracts with employees. HR needs to take a leading role here and ep build a culture of change through awareness, education, self-empowerment and counselling. At the same time, leadership needs to invest by ensuring the right people are chosen and then given the time to grow into this change culture. Based on my experience, there are parts of the world, such as Europe, where this would be a harder process than, say, in Asia. European business cultures are much more rigid about roles and function, and these are often defended by regulation. Also, in Europe, there is often a much higher premium on matching exact experience to a role, rather than bet on adaptability. One of the ways to address this is to balance the majority of such fixed role people with a handful of adaptors – people who can foster a pro-change environment within the business.
For example, I met a European company in the travel segment who could not even change business rules in their enterprise apps, or implement a mobile app store without validating the decisions with worker councils.
Funding Change: Not a capital expense but the cost of doing business: Build in the cost of change into your cost of running the business. Rather than the one hit capital expense of a digital transformation project, budget for change annually, that LOBs and divisions can draw from, with the right checks and balances to ensure governance is provided. There is every likelihood that each of the next five years will require significant changes to some part of your business or the other. Rather than running it as a giant centralised project, or leaving this to individual departments and LOB’s who may not value this investment, organisations should explore creating an investment bucket which is made available to teams based on their justification, against a stated vision. But this investment is locked down for change efforts and cannot be used for other purposes.
Earlier this year, the BBC announced a program of saving £48m and reinvesting at least £29m of that into Digital Transformation services across channels, mobile and digital journalism. Cooperative Bank had set aside £500m on IT alone, to enable it’s digital transformation. Your budgets may be comparable to BBC, or Cooperative Bank, but in all probability they represent significant amounts of money.
The big bang approach assumes that one large and hugely diverse project is the best way of optimising the way this budget is spent. Reality may be very different.
Instrument your company: Build an instrumented organisation where process change can be systemised easily, using BPM, middleware, SOA, and other architectural approaches. This is fundamental in order to plan, implement and measure change. For example, if you want to change your mobile customer service layer, with new processes without necessarily having to make big changes in your CRM or ERP systems, you need a decoupled approach that will allow you to modify or even replace your mobile front end without always having to change a legacy application. But also, it will be faster and quicker to implement a new process if the systems can change quickly, rather than become a symbol of the organisational inertia.
A good analogy and one you hear often in business discussions is about turning the tanker. We talk about large businesses being like large tankers – hard to turn. But your digital transformation should not be seen as that one awkward turn. It’s more like suddenly being in an environment where you will need to turn and often. The real challenge here is actually, how do you stop behaving like a hard to turn tanker?
I was recently in a discussion about digital architecture. There were half a dozen people in the discussion and everybody had a point of view, but there were two things prventing the discussion moving forward. The first was that we didn’t have an agreed view of digital architecture – a ‘what’. And the second was we didn’t have a ‘why’.
My knowledge of technology architecture is limited at best. You would not want me anywhere near an actual architectural design discussion. But it was the ‘why’ question that fascinated me. Why is this relevant? Why should we bother discussing this? What’s at stake here?
Let’s take a look at the competitive environments we live and work in. Increasingly, we are finding ourselves in a world of hyper-competition. What do I mean by that?
First, we are competing on new parameters. Most industry leading businesses have done the basics, so the battleground for competition has shifted. Often the differentiation itself comes from an information driven or ‘digital’ part of the service. Last month, in New Jersey, US, I agreed with a colleague that a primary basis for choosing a rental car would be the quality of the SATNAV system. But it is also likely that you have done enormous amounts of optimisation on your operational models. I just read about UPS’s optimising routing by minimising the number of left turns (in the US) and their innovation on how to land cargo planes.
Second, we are competing with entirely new types of players. Broadly there are 2 new types which require us to think harder. The first is the entry of established providers from other industries. For example, traditional banks have to worry about retailers many of whom are launching banking services. The second is the emergence of disruptive start ups. Once again, for Banks, you have new providers like http://www.simple.com or Square – each of whom may individually survive or perish, but collectively, they will pose some serious threats to your business model.
Consider two more key trends:
One, technology is now a part of the product. Almost every product. You can call it ‘smart’ or you can hide the technology but the chances that the tech component of your product is increasing annually as a percentage of your product’s value are extremely high. From Nike to Nest, everybody is doing this.
Two, there is an ongoing service-isation. As most companies seek that sweet spot between pure products and pure services, technology, and specifically software, is often the delivery mechanism for the service component. After all, when you buy the Nest thermostat, what you’re really buying is the service of ambient temperature at home. Or when you buy a washing machine from Samsung, for example, you’re really buying the service of cleaning clothes. So could Samsung theoretically also send you analyses based on weather to let you know when clothes will dry faster without a dryer? Or perhaps it might analyse the performance of your washing and let you know that you’re overloading the washing machine on weekends. You can easily think of ways in which almost every product can enhanced by a service layer, which is driven by data and software.
What does all this mean to our discussion on digital architectures? Here are some questions to ponder:
1. If your competitor provides any core service at a lower cost than yours, could you survive in the long run? If a broadcaster can run a channel at 10% lower operating costs, or lower ad-sales costs by 10%, can their competition survive? Does your architecture allow you to run core services at a competitive cost model?
2. If your competition can get new services to market faster than you can, would you retain customers?
3. How do you compete against companies that have no legacy? You can get away in an internal discussion by talking about how much of a challenge your legacy is, when it comes to making changes or adding a new service. But do your customers care, when they can get the same thing elsewhere?
4. Is your digital architecture designed to handle the new requirements of competition, new services, and the technology component of your products?
So coming back to the challenges of digital architecture, I believe there is an absolute requirement set and a competitive requirement set. The absolute set may contain things such as scalability and response time. We learnt from the early days of the web that traditional architectures and spikes on websites were not a match in heaven. Even now, major sites crash when the world flocks to see something unfold or buy something everybody covets. Architecture that can handle spikes is a critical requirement in an absolute sense. You can estimate the boundaries and plan for them. Speed/ response time is another – we did a project once where it would take a few seconds to respond, and that was unacceptable, of course. After due analysis we discovered that each request was being routed via enterprise servers across the atlantic and back, so obviously even the physical set up needs to be understood. Other absolute requirements may include security and handling specific functionality such as streaming or transactions.
But to my points above, all of this will point to navel gazing unless you also consider your competitive requirements for your architecture. This leads to benchmarking the costs of key processes, the time taken for changes, new products, upgrades and of course, your customer interface.
So whether you’re like UPS – extracting the last bit of efficiency so you can be that half a second faster than the competition – or whether you are the competition to UPS, the focus of your digital architecture needs to be (a) ensuring it can do all the things you need to do for your customers and (b) ensuring it allows you to be compete – by making you faster, cheaper, quicker or better.
That should be the starting point of the discussion for digital architecture.