I’ve been impressed with how many CEOs, CMOs and CIOs became early adopters of the iPad.
Here are some things I am hearing from the C-Suite:
- I use the iPad for remote desktop access. It is lighter and has better battery life than a notebook.
- We are designing product demos on tablet computers for our sales staff to use in face-to-face customer meetings.
- We are designing tools to let our sales and support teams access inventory and other ERP data on the iPad.
- We are investing in iPad applications as part of positioning our brand as a high-tech market leader.
Is it the Holy Grail or Trojan Horse?
The iPad may very well be the Holy Grail that allows companies to radically transform how they communicate internally and externally. This is because the iPad represents a new era in user interfaces and collaborative computing.
On the other hand, the rush for iPad apps might be a misguided example of a Father’s Day gift defining corporate strategy, violating the long-held maxim that “business requirements, not technology, should drive solutions.”
These initiatives are causing havoc within corporate IT departments. CIOs are being pressured to fast-track a product for which they may lack the infrastructure to support. The iPad is still version 1.0. It is rated only 3.5 stars (out of 5) on Amazon.com. It has its own set of programming language and protocols, making it more difficult to develop applications for the iPAD than it is for .NET, J2EE or open source platforms.
Furthermore, Apple doesn’t provide the level of customer support or developer support to which large enterprises are accustomed, and the products represent a risk in terms of hardware support and information security.
But there are steps that business users and IT departments can take to maximize the likelihood of success for their tablet computing initiatives.
How to make your enterprise iPad projects successful:
With the iPad, the traditional rules of software development are still true, but principles of “agile” are more important than ever:
- First define vision, then business requirements, then functional requirements, then technology.
- Use prototyping and rapid releases to help visualize requirements.
- Realize that you might be “building one to throw away,” and this is good.
- Choose expert suppliers who understand or will rapidly understand your business and your culture and help you to see ‘what is possible’.
- Realize that “problem definition” and “choosing what to build” are 90% of the battle. The technology piece isn’t easy, but it’s relatively easy compared to the business challenges.
- Don’t silo your project within marketing or IT. Make your projects collaborative cross-enterprise effort with strong executive champions. Business users should understand and respect concerns from IT and Purchasing, and at the same time, IT and Purchasing need to add value by supporting these projects.
- If you want to be cutting edge and make a huge business impact, you need to move quickly and stay agile. Cut through the red tape, and make it happen. If you want your project to move the needle, treat it as a strategic project, and act accordingly.