Best. Deployment. Ever

By way of follow up to the previous post highlighting several factors that can contribute to headache deployments, here is the list of reasons for success. This list represents the reasons customers are happy and become our biggest evangelists.

  1. Looking to improve process, not just technology – anytime a client’s driving motivation is to enhance or create actual process, we know it is a good sign. Technology is as only as good as the process it supports, and when you support the desired process with great technology, it is a win.
  2. Willing to invest time on the front end of a project – peeling back the various layers of business rules and mobile process can takes a bit of investment and commitment. But without this critical step, even the best mobile technology will struggle at some point.
  3. A single point of contact who “owns” the project – having a primary relationship with one person within the company is critical. Not only does this cut down on miscommunications and confusion, it bolsters the mobile technology’s place within the company as this person becomes the resident expert and champions the new approach.
  4. Having a genuine pain point – yes, in this case pain is good. The recognition that the existing environment is a detriment to the company, only provides more motivation to ensure that the new approach is the right fit and executed well.

Worst. Deployment. Ever.

While we all love to tout our best mobile deployments and write up case studies on our success stories, I was recently challenged to describe what a bad deployment looked like. While each mobile deployment has its challenges, I discovered there are some scenarios that lend themselves to just becoming massive headaches. In our experience, here are a number of factors that can lead to the worst deployment ever:

  1. NON-MANDATED – there is no driving motivation to implement this mobility project. It quickly becomes clear that this is a “want to” vs. “have to” scenario. There is no cost justification, demand for legal compliance, a requirement to meet specific service level agreements or company mandated policy. This is simply a case of “it would be nice if we could _______.”
  2. ROI IS NOT CLEARLY DEFINED – going into the project there was no clear definition of success. Nothing that clarifies “we need to improve productivity by X”, cut operational cost by ___”, or streamline workforce by X.” Without this there can never really be a tangible sense customer satisfaction.
  3. NO DEADLINES – Especially when there is no mandate for the solution a lack of deadline leads to drawn out implementation, delays in pre-production training and a general hesitancy to eventually go live.
  4. OPERATIONS PEOPLE ARE NOT INVOLVED – when the influencers and decision makers are not directly involved in the operations side of the business, there is such a huge disconnect in expectations, a clear understanding of needs and a “boots on the ground” approach. This inevitably leads to all manner of delays and chasing rabbit trails for items that in the end, really really do not provide value to the project.
  5. UNWILLINGNESS TO INVEST TIME ON THE FRONT END OF THE PROJECT – because a successful mobile deployment relies so heavily on operational workflows, it demands a fair amount of investment on the front end of a project to evaluate process, define the proper business rules and work through the current vs. expected process. An unwillingness to roll up the sleeves and wade through this work ultimately leads to greater frustration and headaches as technology is rolled out to the larger team.
  6. NOT CONSULTING THE END USER – working with operational team members is critical but not consulting the actual end user is even worse. Assuming or even dictating how a mobile process should work with out input from the actual mobile worker is the “ivory tower” approach to mobility that typically leads to a fumbled implementation and poor user adoption.

But it’s not always bad. Next up – best deployment stories.