Six Golf Lessons Applied to Mobile App Development and Deployment

Image

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:  www.linkedin.com/in/jerryhorne/

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.

Wired Predictability versus Mobile Unpredictability: Mobile App Usage Impacts Scalability

Is scalability a scary IT concept for your enterprise mobility app development? If might be for some and here’s why:

Historically, scalability for recent software development projects was defined by known factors. IT departments built and designed scaled network to accommodate a reasonably static number of hardwired desktop devices. Server farms were scaled by algorithms that could predict data base growth as based upon a reasonably static number of hardwired devices. Desktop PCs ruled the scalability matrix because usage was a reasonably known quantity and it was predictable.

Mobility software adds a whole new layer of scalability complexity because the number of connected mobile devices can quickly outstrip the number of wired devices. Mobile app usage is nebulous at best and, by definition, in a BYOD world, usage is unpredictable.

Here a few specific Enterprise mobility scalability issues:

(1) The application architecture must accommodate a sliding scale number of licensed users-on-demand. Managing and budgeting for a growing number of licensed devices may be a challenge.

(2) The front-end app functionality must be easily adaptable to include new features because of user demand. Mobile users seem to be more demanding than wired users antidotal reports have suggested.

(3) The backend app interfaces may need to be seamlessly linked to additional programs or databases concurrently. User expectations may force software to go in directions IT departments didn’t foresee.

(4) The communications technology must be robust enough to allow for an increasing number of simultaneously connected wired and mobile devices. Internet connectivity, along with voice, data, and video, may all be competing for the same bandwidth. Does a frame-relay connection work for you, or, do you need a T1 or better? What’s your latency and can you live with it in a mobile world? Do you have a tripping point where the answer would be no?

(5)  The app code must allow for an increasing number of simultaneous devices with varying device operating systems. BYOD devices come in a variety of OS flavors. Users expect support for their favorite device. OS support may not come cheaply for your mobile app development needs.

How many issues apply to your situation for your mobile app software development?

One way to lessen the scalability impact of an unpredictable mobile environment is to plan for your worst-case scenario – and then perhaps double it.

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.

How Hollywood Thinking Can Help Mobile App Development

Right brain versus left brain

Analytic versus creative

While everyone uses a bit of both sides, would most agree that software programmers by training and disposition exhibit more analytical than creative tendencies?

Not that long ago – less than ten years – nearly all enterprise mobile apps were text based. And, of course, the wireless Industrial mobile devices were primarily monochrome at that time (and many are still in use today). Software mobility programmers didn’t have to worry about graphics or colors or visual designs because it was all text. All they had to do was program mobile code to reflect Visio logic flow charts. These were straight forward programming tasks.

The exact date of when the world of mobile programming was turned upside down is debatable. Many would argue it really started in earnest on January 9, 2007 when Steve Jobs introduced the iPhone at MacWorld. It changed once again on January 27, 2010 when Steve introduced the iPad at a press conference in San Francisco.

Since then, mobile software programmers have been forced to consider and include visual design elements as they never had before. Abruptly, the analytical programming guys were also tasked to be creative. Talk about fish out of water!

So, how can IT managers today help those analytical programming guys address creative design image concerns and needs?

Take a hint from Hollywood.

Movies are complex visual creations, just like mobile apps. And, with the advent of computer created graphic special effects, movies have increasingly become huge technology IT projects.

However, movie directors don’t use Visio logic flow charts to construct the plot outline of a movie. Why? Logic flow charts don’t convey much information beyond what to do next if the answer is yes or the answer is no.

Movie directors need more contextual visual content and information. They use story boards.

Story boards are short-hand visual representations of all of the design and graphic elements that may be included in a single scene on the silver screen. Story boards are collaborative efforts from and used by graphic artists, designers, editors, and many others.

A storyboarding technique can be employed to assist programmers to aid their development of a uniform look and feel for their mobile screens, too. The best news is that everyone already has a handy tool on your desktop for just such a purpose: PowerPoint.

PowerPoint is a nifty graphic tool that can be utilized to create storyboards for an entire mobile app – screen-by-screen and function-by-function. And, using the embedded hyperlink capabilities in PowerPoint, one can simulate simple navigation to show what will happen if one pushes a screen button or enters a specific value.

The best part of using a PowerPoint storyboard is that it is a realistic visual representation of your mobile app that can quickly be created so that executives and other interested parties in your company can grasp intent, review content, and give final approval prior to any code being written.

Image
Mock-up menu screen created in Powerpoint

Your company may save both time and money if you have collaborative meetings with your creative marketing team and your analytical programming team to hash out what is possible and what not possible before you have expensive project creep.

As the saying goes, one picture can be worth a thousand words and storyboards are a simple way to move forward with complex mobile application development.

Mobile Apps Need Mobile Style Guides

Mobile app development should first start with a mobile style guide in place.

For better or worse, your mobile app presents an image of your company’s brand excellence.

And, the effort your company puts into protecting and fostering your company’s brand image should be no less when developing your mobile apps. Programmers may find they need to work closely with graphic designers, marketers, and, maybe even lawyers to provide a polished and completed product.

There are four key considerations that all mobile style guides should contain to help provide consistency: (1) a consensus user interface for navigation techniques like swipes, pinches, etc.; (2) visual placement guidelines for images, graphics, colors, menus, icons, and text boxes; (3) allowances for font usage for readability – and perhaps support for multiple localized languages, too; and (4) guidelines for the use of legal descriptions, notices, and version releases to protect your product.

And, if your app is to be supported by multiple mobile operating systems and screen sizes, then specific considerations for each system option may need to be included within your style guide.

Style guides for mobile apps may be similar in concept to other corporate style guides used for company logos and other graphical presentations. However, mobile style guides may quickly become multiple page documents to cover the various elements found in mobile apps.

If your company employs remote-based programmers, or if your company hires third-party consultants / programmers to provide custom mobile application software, then a corporate mobile style guide should be mandatory and required if your company wants to have a consistent look and feel for all of your mobile apps regardless of the original point of coding.

Continuity, consistency and creative design can all merge hand-in-hand with a bit of pre-planning. Mobile style guides are a simple and efficient way to help your company manage your mobile development efforts.

Business Mobile Apps: Planning and Strategy – Five Key Matters to Consider

The mobility parade is gathering steam and rolling down Main Street USA. Where are you viewing this parade? From the street corner watching as it passes by, or are you an active participant sitting on the main float that everyone else admires? The reality may be a bit of both, depending on where you are in your mobility development cycles and in setting your business goals strategy.

Here are five matters to consider:

User Matters – Who will use your app and what will be the end-result of their usage? For example, do you have a user’s group that provides feedback for your products or service offerings? How do they communicate with your company? Got an app for that?

Competition Matters – What are your competitors doing in your market space and does their efforts give them any advantages? Are you being proactive or reactive to your market environment? Are you playing catch-up or leading your sector? Got an app for that?

Collaborator Matters – Unless you live and work in a vacuum, your company interacts with other companies in many ways: suppliers, partners, logistics, sales, channels, marketing, and much more. What can you do to make your collaboration efforts better and easier? Just because you always have done it one way does not mean it can’t be improved. Got an app for that??

Compliance Matters – In the supply-chain world of business, mandatory compliance issues are an everyday reality. Proper labels for this, correct documentation for that, serialized markings here, and security/anti-counterfeit features seem to be popping up everywhere. Sharing information freely, quickly, and rationally is not just good business, it is has become required, mandated and increasingly regulated. So, how are all those additional business processes and procedures working for you? Need help? Got an app for that?

Executive Matters – Rarely does any pipedream mobile project become reality without an executive sponsor. That’s because pet-projects and software development budgets are controlled by executives who set company priorities and objectives. Executive discussions for mobile apps often come back to financial issues of cost vs. perceived benefits received. But, is it always about dollars or should it also be common sense? Perhaps someone should develop a mobile business app to assist in making mobile business app decisions. Who’s got an app for that? No doubt it would sell well.

Return on investment is always crucial in mobile app development conversations. But, the problem is that tangible and intangible returns are not always easy to calculate or quantify – especially with regard to some of the matters above that may be thrust upon an executive team (especially matters are government or industry regulated as a cost of doing business). And, not every team member executive is qualified to discuss or understand all of the tangible or intangible matters.

As my friend John Schiff at Oracle is fond of saying, begin your mobile app planning and strategy with the end in mind. I believe John is exactly right. If your executive team determines that the end results are justified, then make a strategic corporate decision to live with it, regardless of the perceived ROI economics. Go make your mobile apps!

Enterprise Mobile Apps: Location and Accessibility

Pick your favorite mobile carrier and check their coverage map. While over time cellular coverage provided by Verizon, Sprint, ATT, and others, has improved, there are still significant gaps where cellular or WiFi coverage is spotty or non-existent. Why should this concern you or your IT department’s mobile Enterprise strategy?

The answer is simple: accessibility.

As discussed in previous entries, the audience and their location for your app’s usage may dictate how to prioritize software development. Perhaps more importantly though, is how accessible does your app need to be to function properly?

Generally, there are two common approaches for mobile business apps: real-time and store-and-forward.

Real-time

As the name implies, this type of mobile app is fully interactive and demands a “live” connection either directly to an Enterprise environment or to an Internet connection that, in-turn, links to an Enterprise environment. Apps that feature look-ups or inquiries require live accessibility all the time.

Store-and-forward

As the name suggests, store-and-forward mobile app are generally self-contained to capture unique information on-demand and/or to interact with a downloaded data file for “real-enough” validation. Perhaps the best illustration for this type of environment would be mobile route accounting sales apps that may have downloaded customer files or vehicle inventory files that allows the user to perform sales transaction tasks with a number of remote clients throughout the day. Then, at the end of the day, all captured information is uploaded into an Enterprise environment for final processing of all financial transactions and to update and/or relieve Enterprise inventory quantities on-hand.

Accessibility Matters

So, how and why does accessibility really matter to your mobile Enterprise application development strategy?

Suppose your IT department decides that your company’s mobile apps should all be created on only one common development platform. And, suppose your IT department determines that a cloud-based real-time development strategy offers the best development flexibility.

If your company discovers that a mobile app might conceivably be used in geographic areas lacking in robust cellular connectivity – which will interfere with the app being able to function properly in real-time, then your entire app development strategy may be flawed from the start. And, the last thing your IT department will want to do is support two different mobile development platform strategies.

Examine where your mobile audience works and lives, and then factor-in the role of accessibility in your Enterprise mobility development strategy. In this case, the old real estate axiom applies: location, location, location matters.

%d bloggers like this: