Top 5 pitfalls to avoid deploying Enterprise Mobility Solutions - Episode 1

Are you about to embark on a large scale Enterprise Mobility deployment? Have you already run into your first headache in this immature market? Is mobility and big data a core topic for your business strategy these days to attempt to unlock further productivity? In this series of articles I am going to explore the common pitfalls I have seen companies run into while embarking on these innovative solution deployments, no matter if you deploy well-known brand names like SAP SMP or Accenture CAS or a custom made app.

The Enterprise Mobility Solutions fever is rolling out across the world's large industries like a wildfire. Executives experience and personally use sexy new mobile devices which are currently flooding the market and therefore have a personal reference to at least the hardware and user experience described when the consulting companies or enterprise architects move in with a sales pitch. While the objectives of these projects and programs are often well intended and will truly bring productivity if carried out correctly, there are a couple of very common foundational mistakes which companies commit over and over again as they try to engage in the age of user friendly mobile solutions and devices. This series of articles is all about the most common mistakes typically done in such projects and what attitude program managers and sponsors should have to best steer clear of them.

Don't assume your business know what they need in this brave new world - this is an interactive requirements cycle

This pitfall may sound like an old truth about Enterprise Solutions in general, however there is a reason it's even more accurate for Enterprise Mobility. The mobility industry is now decades old and so are the Enterprise Solutions lead by the core ERPs. However just recently the mobile devices have become sexy enough to attract a mainstream audience (yes, the Apple Newton in the 90s was well intended but did not quite hit the spot) and the Enterprise Solutions have moved in to harvest the benefits. In addition you have the Big Data movement which is also adding to the vortex. The combination is an industry which is experimental and quite immature – not that any solution provider will admit to this fact.

Your end users have just recently started getting used to their new personal tablets, phablets and smartphones and especially the experienced business process experts are not the most agile users of the new technologies. Often your BPEs are in their 40s or more and while their kids could teach them wonders on the new technologies, this knowledge is not necessarily present at the time the requirement documents are being locked down. Hence at the time of blueprint, you cannot expect the envisaged business process and solution to be particularly accurate to what will become end state. Nor will the prebuilt functionality and content from the solution provider due to the infancy of the industry in general to be able to envisage what your users will require and all the new functionality the mobility revolution will bring with it.

So what’s then the correct approach? Make sure you structure the deployment to run cyclically. The base deployment should come with limited functionality and mostly ensure the devices hit the field and that this is done swiftly and at no astronomical cost. Thereafter make sure funding is available for several cycles of refinement where further requirements can be baked into the final product. Enable a simple feedback system (the simpler and more intuitive the better) where end users can suggest and “like” proposed further functional add-ons. This will avoid spending serious funds towards unused functionality or reports. It will engage your end user community quickly and make them feel involved in the process. And most of all, you will have time to build the expertise on-the-fly in the organization while the cyclical program takes place so that your organization is engaged in the growth of the right end state solution and actually become the product experts towards the end of it.

For all of you developers reading this article, you have of course already spotted that the approach fits very well with an agile methodology. Depending on the size, complexity and amount of dependencies of the initial deployment you may want to consider waterfall for the initial wave and thereafter switch into something more “agile”.

This approach is not all that bad if you are a solution provider either. Assuming you are willing to admit that this industry is in its infancy and possibly even your product has an evolution roadmap to embark on, then by engaging at a detailed level with your more experienced customers in a the strategy described here, you will jointly create a win-win situation where the roadmap for your product can be driven by real life end users feeding back their unfiltered needs to your client and therefore to your products roadmap as well.

In the next episode… Why a mobile device strategy isunlikely to last? Stay tuned…