Post a new topic
    0 Replies Latest reply on Jan 11, 2014 3:13 PM by chicagocio

    Contract Out or Build In House?

    chicagocio Scout

      In a town like Chicago, CIOs or people in that role for small businesses will face this dilemma: Do you build the IT solution/software in-house or contract out?  It's been my experience that most of the time the best answer is fairly straight forward once you identified some of these factors:


      1. How well can you articulate your business processes? If you or someone on your staff has a great ability to describe the data your business works with and the processes that it runs on then you could do okay contracting out.  One sign that you do have this is that you have good documentation on your processes already (used maybe for training new hires).  Notice the focus on articulation and not "understanding". Understanding won't help a vendor understand, good articulation will.  If you don't have this, contracting out will be a nightmare that you keep having everytime you have a new IT project.
      2. Duration of work.  Obviously if you have a project that you don't think will have much changes after it's initial release then that favors contracting out.  But if the release is one of many to come, you should consider hiring someone internal. Employees, even with benefits will tend to be cheaper than vendors if there looks to be long term maintenance and ongoing work.
      3. Importance of work.  If what you are building is highly customized and will be critical to your day to day operations that I would lean more to someone who is is an employee. If it's important to your operations, you'll likely have to change it often. Ergo, duration of work is long, thus maintenance costs favor an employee.
      4. Built to sell.  If you are building something with intention of selling then I lean more to contracting out for that.  Building something with the intention of selling to another company implies a temporary project to me.
      5. Uncertainty of success.  If you are prototyping something and you aren't sure if it will sell or work, then contract out.  Don't hire someone if you already know there's a decent chance you'll have to let them go.

      There are some factors though that business leader's do consider but I believe they go in the wrong direction with.

      1. IT experience of internal staff.  When you don't believe you have the skillsets in-house to do the job the instinct is to contract out.  But the more relevant issues are what I listed above.  If looking at those lends more to the idea of doing it in-house then hire someone be an internal employee to do the work.  It can take a few weeks to find the right person, but if this is a project that's going to be a living and breathing thing for years to come then take the extra few weeks to get the right person.
      2. Ease of getting a vendor vs hiring a person.  Getting a contractor may seem quicker and easier, but remember that if you don't have much experience giving software requirements then the projects are going to be more difficult instead.  You have to choose where you want the difficulty.  My suggestion, take on the paperwork of a new hire which is over once it's done versus the non-stop higher costs and complications of an outside vendor.
      3. It's critical to business operations.  Up above I indicated that if its important to your operations then you hire in-house.  Once exception is if what you need is critical but not really customized or unique, then hiring a vendor who specializes in that specific IT need is the better way to go.  Don't make IT a function of your company unless it needs to be.  Just like you'd hire a plumber or an electrician, you may find it best to contract out even if it's important.