There are always reasons and/or business justifications for wanting to mobilize a business process. Something has motivated the individual or company to march down the path of mobilization, so when considering whether to buy or build a mobile solution these additional factors should be considered:
Tolerance for risk
Opportunity costs
Expected ROI
Competitive advantages
Let's briefly discuss each of these considerations.
Tolerance for Risk - Are you willing to risk attempting to develop an enterprise mobile solution for the first time (If your team is an experienced mobile development team, then you can ignore this point)? It can be done but the first time requires a lot of thought, design meetings, trial and error, debugging and above all else - time. What if the design cannot scale? What if the synchronization engine that your developer made is too slow? What if after 8 months the system is still only half complete and full of bugs?
Opportunity Costs - This is one of the most common issues that IT managers discuss with me. Most often IT departments are already over worked and behind schedules. The last thing they need is a another new project added to their list and schedule. IT managers are already annoyed at their current workload, and now the business unit is asking them to develop a completely new and unproven mobile solution? The IT manager is not happy, all they can think of is the headaches this will cause.
The questions the IT managers ask the business unit managers are:
What project should I delay in order to insert this new project into the schedule?
Who is going to support it?
Can I hire more developers to develop and support a mobile solution?
These questions then force the business unit manager to go back to senior management and ask them to re-prioritize other IT projects in favor of the mobile solution. Now all the business unit managers get involved and defend their particular interests.
The opportunity costs can be considerable if you want to code/program the complete mobile application yourself internally.
Expected ROI - If the business unit requesting the mobile solution expects to save $53,000/month by mobilizing their work order management system, then every month that passes without the mobile solution being deployed wastes $53,000. So if coding your own solution from scratch takes 3 months longer than using a mobile software platform or out-of-the-box mobile application, you must consider the $159,000 you just wasted.
Competitive Advantages - We have developed many mobile solutions for companies that are considered competitive advantages, solutions that provide new and unique revenue opportunities for our customer. We have seen this in the automotive industry, the beef industry, the concert and event promotion industry and many more.
If the business justification of the mobile solution is motivated by a competitive advantage, then the length of time it takes to code a mobile solution from scratch must be considered. What if the mobile solution takes 5 months to code from scratch, but only 5 weeks with a mobile software development environment?
If your organization has Microsoft .NET programmers that are available now and they have a lot of time on their hands, then yes it is possible to develop your own enterprise mobile application. Here are a couple of questions before you start:
Have your programmers completed successful mobile applications before? If this is their first time, there may be a steep learning curve that must be factored into the equation.
Is the same programmer going to code the mobile application, code the security, code the synchronization logic, code the database integration and code the business logic? If there are multiple developers/programmers involved - ask question #1 about each of them.
Are these programmers going to also write your user guide and document the solution?
How long will your programmers stay with your organization? What if the programmer leaves? Who will support it and maintain it?
There are many parts to an enterprise mobile solution. It is rare for even an experienced .NET programmer to have experience in all of the components. Here are some good questions to ask a programmer before you start coding your mobile application:
How do you plan to sync the data?
What sync engine will you use and why?
How will you connect to the enterprise database remotely from the field?
How do you handle security?
How will you integrate the data into existing database systems?
How will you glue all these components together in your application so it all works?
How will you support multiple mobile devices- Windows Mobile, WinCE, Tablet PC, Windows PC?
These are all questions that need to be answered before a programmer begins. Here is the problem - often a programmer views their component (the mobile application on the handheld PDA) as 90% of the project. Which simply is not the case. The majority of the time and effort is in connecting all the different components together, integrating and testing.
I have often heard a comment from a programmer that the mobile application is done, although it takes another 8 weeks before it could be deployed. The mobile application is often the smallest part of the project. Many programmers can code a simple PDA application. However many enterprise mobile applications need much more than a simple, stand alone PDA application. They may require full synchronization, remote connectivity, device management, integration, security and more.
It is important to recognize that mobile applications are not just developed by one person in a dark room with a computer. The business unit manager can order a mobile application to be developed but someone must design it, develop it, test it and approve it. Do you really want the programmer to complete the entire application on his/her own, or do you want a person who understands the business to be involved? Here are some considerations:
Do you want the mobile application to look exactly like the paper form in use today? If you don't specify differently, the programmer will make it look like a small piece of paper on a mobile device.
Do you want the programmer to dictate your business process, or do you want to tell the programmer how the business process should work?
Do you want the programmer to tell the field workers how, when and where they should sync the mobile application, or do you want the business users to tell the programmer.
Do you want the programmer to select the mobile handheld computer, or do you want the business unit to describe their requirements to the programmer?
Do you want the programmer to tell the business unit when the mobile application is complete and final, or do you want to test it and approve it?
Most of these questions have obvious answers. The business unit (the organization that will benefit or suffer from the mobile application) needs to have active input into the design, development, testing, deployment and support of the application, it’s not a one programmer job.
The problem many projects suffer from is that active involvement was not anticipated or planned, therefore, it either does not happen or comes as an inconvenient surprise.
