Six Golf Lessons Applied to Mobile App Development and Deployment


One does not have to be an avid golfer to understand the basic concept of playing golf. The game strategy is that the player with the fewest strokes taken to place a small white ball into 18 different cups spread over a 7,000 yard course wins the match.

How do lessons taken from golf apply to mobile app development and deployment? Here are six possibilities to consider:

(1) Creating and writing mobile app code can take a fundamental tip from golf that less is best. Business and social mobile apps all compete for a finite amount of storage space in mobile devices. So, does one try to create an app that reasonably performs multiple functions; or, does one create an app that does only one function really well?

(2) No cheating is allowed. Golf is a self-regulated game. That is why the concept of penalty strokes comes into play. While imitation may be a sincere form of flattery in some industries, blatant copying of business concepts, look and feel, and other proprietary programming techniques is simply plagiarism.

(3) Follow-through is fundamental. You may have heard the golf catch phrase “drive for show, but putt for dough.” Mobile software development strategy is the same. Integration into back-end Enterprise applications can sound flashy (for show), and  they may give the marketing impression that their software is of “professional” grade quality; however, the real genius  (for dough) for a mobile app may be found in the attention to details evident on the front-end where tiny changes can make a big difference in user perceptions.

(4) The right equipment can make a difference. Anyone who plays can testify that golfers are always seeking an edge with their equipment. Hybrid clubs made from high-tech metals and ceramic materials; special grips; incredibly coated golf balls; glove-like shoes; and, much more, have all combined to make average golfers better; and, to make above average golfers superior.

The same is true for mobile technology. Not all mobile devices are created equal and not all mobile OS are created equal. There are ample arguments being made, elsewhere, that the concept of BYOD (bring your own device) should be replaced with CYOD (choose your own device from a list of approved technology offerings). I envision that eventually there will a consolidation of mobile devices and their manufacturers. It certainly has happened with computers. At some future point, the clear technology hardware winners will emerge and the BYOD choices will narrow. Why wait? Narrow your choices now.

(5) Rules and standards are vital to healthy software development. When it comes to device and software security, MAM, and MDM, and other software development issues, there are common-sense rules that everyone should abide by. Trying to shortcut development standards helps no one long-term. Why reinvent the wheel when it already exists? Embrace rules and standards.

(6) Targeting audiences correctly is paramount. Why do you suppose CBS spends millions broadcasting the Masters Tournament from Augusta? It’s just another golf match, right? If you think that, then the Super Bowl is just another football game, right? No, not exactly. The lure of the Masters is that it features the best players, which attracts a certain demographic audience, which advertisers can target to sell their products, which translates into sales – the lifeblood of business.

In 2013, the Masters Tournament broadcast drew a 21 ratings share and 18 million viewers, which was up 26% over the 13.5 million viewers in 2012.  Advertisers got their money’s worth, and then some! Was anyone watching the other channels? I know I wasn’t.

Finally, here’s the best takeaway lesson to be learned from golf by mobile software app development companies. There can only be one Tiger Woods or Phil Mickelson or Adam Scott. And, they compete head-to-head nearly every weekend on a world stage.

How would your company be viewed on a world stage of mobile app developers? Leading the field, in contention to take the lead, an amateur at best, or, never making the final cut? Being good at mini-golf is very different than being able to play on the PGA tour.

Worldwide, there are hundreds of software companies, ISVs, and business consultants that tout they are ERP business partners developing mobile business apps. However, the actual number of companies listed by independent research companies, like Gartner and Forrester, to be real players in the mobility software industry, is a handful. Competition will be fierce for the same audience of buyers and users.

So, how does one make one’s app standout from the crowd? How does one attract positive attention? What gives your mobile app a competitive edge? What is your strategy to win the match, and more importantly, win the hearts of your target audience?

It is worth repeating: hoping for the best is not a reliable strategy.

What to Include in a Mobility Software Style Guide

Several weeks ago, I wrote on this blog that mobile software development should be guided by the use of a style guide for consistency. Since then, I’ve received numerous inquiries asking for more details about the type of style elements that might be included in a guide document.

Here is a snapshot from my Table of Contents page:

ImageI am happy to provide my views; however, adding a complete style guide example here is impracticable due to space considerations. So, I’ve done the next best thing by posting a sample mobility software style guide document on my Linkedin Profile page, which can be downloaded for free for review:

My example style guide document provides the basic elements that many companies might find to be practicable for setting standards for their mobile software development; however, your mobility software style guide might be completely different. And, that’s okay with me.

The important consideration is that one applies a consistent look and feel. As I noted on an earlier blog, companies with large, or, perhaps global, mobile development organizations face distance and communication challenges to provide custom software consistency.

A style guide is a simple tool to help bridge one’s gaps.

One Technique for Defining Enterprise Mobile App ROI

The basic premise of any ROI tool is to show how quickly there will be payback on the investment made.

But, what does this really mean? How can one define Enterprise mobile app ROI?

The answer can seem complex, depending on what is most important to a company. But, the truth still comes back to achieving quantifiable financial improvements for the bottom line.

The easiest way to calculate an Enterprise mobile app ROI is to perform and evaluate time and effort comparisons.

Here’s a simple example. If the time and effort to perform a certain task manually (write results on paper and later key the information into the ERP software) is X; and, if the time and effort to perform the same task with Enterprise mobile apps (real-time) is Y, then it should be straight forward to calculate the time savings difference between the two methods and to calculate the resulting cost savings for a single task.

Then, all one has to do is determine the typical number of task to be performed in a period of time – an hour, a shift, a week, a month, or a year. Multiply the single task savings by the estimated number of tasks to be performed and the ROI picture begins to emerge.

Are these the only ROI factors to consider? Not really.

Perhaps the area where there is the most over-looked ROI savings can be found is in “error corrections,” which is directly tied to efficiency and productivity.

The rule of thumb for error corrections is done by estimating the number of errors that need addressing per 1,000 entries. An entry can be defined as a single transaction or as a single line within a transaction. Companies define this term differently all the time. For this discussion, let’s assume an error is a single line-item within a transaction with some type of problem.

Correcting errors is a nebulous term that can mean anything unexpected that causes a focused level of staff interaction. Essentially, the ERP software may be expecting something completely different than what reality says is right, which triggers the error. Numbers transposed – keyed wrong; wrong quantity entered; wrong location entered; damaged goods that can’t be used; lost products that can’t be found; expedited orders that take priorities over others; QC holds; etc. These are everyday problems for nearly all companies.

Most supervisors I’ve talked to say they spend, on-average, 2-hours to research, to validate, to document, and to correct a single error. Your results may vary.

If a company believes they are 95% efficient daily, that also implies they are 5% inefficient. Those inefficiencies are the errors that must be corrected and fixed. Using the entries rule of thumb above, this means 50 entries out of 1,000 are in error. Fifty entries times two hours each equals 100 hours of staff time required to fix and correct errors. Wow! That’s a lot of time and staff resources!

Error correcting can also become an easy target to realize immediate savings by employing mobile app technology that improves efficiency.

For example, raising and improving efficiency from 95% to 98% would imply that only 20 entries out of 1,000 are in error. Twenty entries times two hours equals 40 hours of staff time to fix and correct errors. That means there is a potential of 60 hours savings difference!

When one does this math, it is easy to discover the financial impact of improving efficiency and reducing error correction time.

And, of course, there are a number of important intangible savings that can be realized from mobile Enterprise business apps including better inventory accuracy, better order fulfillment, better customer satisfaction, and, best of all, repeat business. These are harder issues to quantify true value; but, they are vitally important never the less.

Before You Start Any Mobile Software Development Project, You Must Do This First

Before your IT department or independent software developer starts cranking out Enterprise Mobile software code, there are two foundation core steps that first must be addressed.

You’ve probably already seen their core name acronyms elsewhere: MDM (mobile device management) and MAM (mobile application management). Simply put, MDM will be your rules on which mobile devices will be managed, controlled, and supported. MAM will be your rules on how the applications loaded on supported mobile devices will be managed, controlled, and supported. Your company should  discuss and agree in detail on what these two core steps will be – prior to any code being created or mobile software distributed.

There are too many Internet articles providing in-depth details and advice for both MDM and MAM to repeat their recommendations here.  A recent deep-dive and comprehensive article I recommend is by Galen Gruman, downloadable from InfoWorld:

Your intellectual property, in the form of Enterprise app content, has to be protected. This content is just as valuable as any other intellectual property your company creates or owns; but, it is at greater risk and perhaps the most vulnerable property category your company will ever create. That is because, by definition, mobile “property” can’t be easily locked down, tracked, traced, or deleted without a significant degree of upfront planning.

The proliferation of BYOD, in an age of a very mobile workforce, means that control of Enterprise apps loaded on personal devices will immediately be at jeopardy when trusted employees become former employees.  BYOD means the devices and all of their loaded software departs the premise when the former employee does.

As Galen points out in his deep dive article, common sense guidelines and employee usage policies may offer practical solutions; but, if the nature and use of specific apps is company sensitive – for executive use only, for example, nothing may protect your company interests better than company-issued devices that must be returned by departing employees. Ownership always remains with your company in this regard.

Your MAM and MDM rules should address as many business usage scenario specifics as one can imagine. And, don’t write any code until you can provide a basic framework for where and how your mobile apps are to be deployed, managed, updated, or revoked!

Audience Matters – Five Steps To Consider

Planning an enterprise mobile software application can be daunting to the uninitiated. There are, however, a few planning tips that may help.

Suppose, for this example, that the proposed mobile application is to be related to mandatory sexual harassment training for all employees.

First, step back and clearly identify the intended audience. Do you need app versions to support more than one language? Do you need to support non-literate participation? Do you need to support special needs staffing? Establishing corporate goals based on the answers to these questions will help one to build a consistent, repeatable, computer-based system, with measurable analytics.

Second, with established corporate goals, one can start the program analysis to define the components that should be developed, managed, and, later, archived. If one of the design components is to utilize video clip examples of good behavior versus bad behavior, then scripting, filming, editing, and converting the video into a usable format is near the top of your to-do list. Over dubbing additional sound tracks may provide other language support and closed captions may address those audience concerns. The video presentations probably will need to be placed into a mobile software presentation framework that can easily provide a high quality user navigation experience.

Third, with measurement goals in mind, one can establish a series of questions and answers that the users must successfully complete to demonstrate their participation. Computer-based training is straight forward programming in concept; however, crafting meaningful questions should require the assistance of HR or legal professionals.

Fourth, management of participant records may be critical to remain in compliance with local, state, and federal guidelines for sexual harassment. Your HR or legal affairs staff can provide guidance as to what is required for your location. Sign-ins and unique identifiers are common software techniques to track who has successfully used the mobile app. Is one of the program design criteria to send a reminder to individuals who have not completed the required training? Does your company require periodic refresher courses with email reminders in the future? Will your app need an email interface? Will your app need a separate data base? How long will your organization keep the participation records? Five years? Seven years? Forever?

Fifth, having integrated analysis tools that can provide contextual information may be critical to the success of this example app. Executive dashboards are a highly recommended technique to provide instantaneous feedback on the use of mobile applications. At-a-glance screens with graphs and charts can provide real-time meaningful analysis. Of course, what should be included in the dashboard must be part of the initial design concept in step two.


All Enterprise Mobile Apps Are Not Equal

Like it or not, enterprise mobile apps should not be created equally.

Design and usage considerations aside, there may be many varying criteria for how enterprise mobility apps should be modeled, created, and perhaps licensed.

There are at least three emerging classes of enterprise mobility users: (1) industrial mobile users [industrial mobile devices within the four walls – with constantly working connections], (2) occasional mobile users [in-the-field or remote users on tablets or smart devices – dial-in or WiFi connections], and (3) casual mobile users [middle management or executive users on tablets or smart devices doing inquiries or approvals – dial-in or WiFi connections]. 

Major ERP vendors, like Oracle EBS and SAP, are in the development and roll-out process of extending the footprint of their ERP software to mobile devices. These ERP vendors contend that users of their software should be licensed regardless of how the information is accessed – from a desktop PC, a tablet, or a smart phone. Their licensing schemes to date for these new mobile ERP offerings seem to be gravitating towards a “transaction” specific license so that only the users with that specific mobile transaction need are licensed.

BYOD users have grown accustomed to downloading free or inexpensive apps with very cool interactive features. Imagine the sticker shock when downloaded ERP licensed apps cost hundreds or thousands of dollars for a single ERP transaction!

The jury is still out on how this per transaction licensing model will stand because this is an important economic consideration by IT departments as they try to manage, control, transfer, and contain the growing cost of Enterprise Mobility.

The Roots of Enterprise Mobility Run Deep

If you think enterprise mobility is a relative new phenomenon you might be surprised to discover that its roots run deeper than one might think. Many companies have been using industrial wireless mobility devices, with bar code ERP-connected software, to manage their business and supply-chain operations for over thirty years.

Industrial hardware vendors like Intermec, Motorola, and many similar companies have been providing wireless mobility hardware and software solutions since the mid-1980’s. Those early devices had proprietary text-based programming languages, like IRL (Intermec Reader Language) that allowed for the creation of very simple programs for basic supply-chain transactions. Bar code technology was in its infancy in acceptance as the standard for identifying products.

Those early enterprise mobility devices in the 1980’s and early 1990’s had limited functionality and capabilities for four reasons: (1) Chip technology has clunky, expensive, and power-hungry. Those early devices had variations of the 8080 chip design, which were the heart of early text-based PCs. Battery-life for the early portable wireless devices might go 4-6 hours. (2) Operating systems were primitive and also proprietary by each vendor and CPU. Those early vendors like Telxon, Symbol, and Intermec  hoped that their proprietary marketing schemes and hardware deigns would lock customers into using only their systems and programming tools. That strategy didn’t work out as well as they hoped. (3) Wireless and wired connectivity was problematic and expensive. There were VHF and even a few UHF wireless networks offerings in those early day before the recent advent of WiFi and robust cellular networks. And, (4) software data integration into Enterprise environments was cumbersome and ODBC standards were in early stages of development. 

Despite these shortcomings, wireless enterprise mobility devices became increasingly popular with corporations that faced the prospects of supply-chain mandates. There were two stand-out projects that helped shaped the early acceptance of mobile enterprise technology:

(1) The US Department of Defense LOGMARS (logistical marking) project in the 1980’s mandated that defense contractors add unique bar code identification labels to every product purchased. There were two notable results from this project: Unique ID label standards were formalized and mobile hardware was ruggedized to withstand repeated drops on concrete for field utilization. This project impacted literally thousands of contractors to use bar code technology. Soon, these contractors realized that the labels they were applying for the US Government could also be used for their own internal enterprise tracking use as well. 

(2) The automotive industry, in a major shift in manufacturing practices, moved to a “just-in-time” techniques for their parts suppliers. The hundreds of parts used in building a car would only arrive at the assembly factory just-in-time for their usage. The only way to provide enterprise visibility of the arrival and movement of these parts internally was through the use of enterprise automated data collection technology. Using a label standard still employed today, AIAG (Automotive Industry Action Group) labels provided an automotive industry standard that all automotive suppliers employ. And, the need for immediate visibility of arriving products led to significant improvements in real-time enterprise data  software integration. 

It is hard to imagine today, but until very recently “batch” computer operations were common place. Enterprise main-frame and mid-range software programs ran overnight to refresh tables and programs for management usage. Inquires and look-ups were hours or days-old information at best. Still, batch information was a vast improvement over manual paper methods were information was perhaps weeks and months old. Can you imagine what an Internet environment would be like if this were still a predominately batch computer world? Do a Google inquiry and then wait a day for the answer??

The primary evolution impetus of today’s enterprise mobility can be traced to the introduction of smart devices which were first brought to market about seven or eight short years ago. The first mobile enterprise apps were primarily focused on delivering email outside the enterprise’s four walls.  Palm and Blackberry devices were the popular rage in the early 2000’s and they helped forge a new demand and need for corporate enterprise apps. I have both devices gathering dust n a drawer with other forgotten, now out-dated technology.

Fast forward to today with the now three-year old introduction of tablets, smarter-devices (like Android, iPhone), and full-featured mobile operating systems (like Android, iOS, Windows CE) with native, embedded graphic and video technology and one can easily understand why there is such an interest in extending and expanding the footprint of real-time enterprise software. There are new classes of enterprise users that mobile apps can assist.

What was merely a dream 15-years ago with enterprise mobility technology is now common place. Where will we be in another 15 years? Stay tuned.


%d bloggers like this: