Use your existing development team. You probably already have developers who would be interested in giving mobile development a try. I would argue that unless there is a compelling reason to let them try a new development paradigm (e.g. you would lose them if you didn’t and their domain expertise is invaluable), keep them where they are – that’s why you hired them. My experience has been that first-time-mobile developers generally do not make a excellent job of their first application. The only exception to that would be very experienced developers backed up by a very strong (in mobile) UI design team.

Build a mobile development team - the most effective but expensive option. It will take time to find the right people, but once you have them you’re in a position to rapidly iterate and have the advantage of the mobile team working closely with the rest of the organization. You need absolute commitment to go this path as you’re going to be investing in people, office space, equipment, etc.

Outsourced project – Outsourcing on a project basis is tempting, especially as it minimizes cost risk. However, it gives you little room for maneuver as you begin to feel what the application is like to actually use and leaves the very awkward question of who supports the app, adds new features, preemptively tests and fixes for new versions of operating systems, devices, etc. I see this as a short-sighted approach. If you’re going mobile, do it properly.

Staff augmentation – The advantage here is that you can get rapid access to experienced mobile developers who are ready to go with their development environments, devices, etc. You have flexibility to start small and grow, or even do the reverse and have a high-effort initial push and then fall back into a maintenance mode. Some outsourced vendors will even work on a fractional basis for maintenance and support work.