Can you afford to have an in-house IT development staff?

I was going to start this post by listing dozens of technologies that are in common use today by many IT organizations and software development companies.  I've been in the IT industry for close to 50 years and have seen literally hundreds of technologies come and go.

You can rest assured that the technologies you are using to run your business today will be obsolete in the very near future.  If you are a large company, just look around and you will visibly see many technologies such as that old mainframe in the computer room, maybe an IBM midrange computer stuck in a corner, dozens of PC based applications often running on isolated servers in specific departments around your organization.

Do you support all the modern web browsers?  Do you support all of the popular mobile phones?  Tablets?  Personal computers?  These technologies all require specialized skills.  Can you afford to hire people with these skills?

Sadly, I no longer believe that you (the largest or smallest) company or organization should have in-house application developers on your staff.  Today, I strongly recommend outsourcing your software development and/or implementation of purchased package software products.

If you try to maintain your own IT development staff, you will over staff with people who are not productive often called architects who constantly review emerging technologies.  Some of you will attempt to cross train existing people who never develop a proficiency in the new technology.

Why not just contract for experts that you need.  This technique can work, but there are some major changes you must make in order to be successful in outsourcing your IT development.

First and foremost you need a small but strong staff of systems analysts who know your business and your requirements.  You do need a small but expert staff that can lead your systems analysts in writing requests for proposal and statement's of work that clearly define what a vendor will deliver.  Note, I recommend always using fixed price contracts putting the development partner in a position to share the risk with you of delivering a system that meets requirements and does so  within the time frame you agree to.