Software Outsourcing Guide for Startups

Software

Many startups, even when their core is not IT, need new software developed for various needs of theirs. Here are some key strategies to guide how they can go about it.

Outsource

The idea of recruiting a couple of programmers inhouse sounds lucrative some times. Especially when you hear about some outsourcing blues, this thought do surface. But mind you, recruiting technical people, retaining them and utilizing them effectively is not as easy as it sounds. There is a startup that invested in a team of programmers and followed a perfect system of daily reporting from day 1. However, even after 6 months, they had not gone much beyond a login page. Do not fall into that trap.

Also, as a startup, it is important that you stick to your core and not get distracted. Especially, when you do not have any experience of getting software developed, do not plunge into it and expect miracles. There are high chances that it will get overwhelming, to the extent that your core activity may get sidestepped.

Choose Partner Wisely

It is usually difficult to differentiate between those who only give a smooth talk, and those who can actually deliver. Blessed are those who have an X-ray vision to make out the difference. For others, here are some pointers:

  • The right ones will generally be open in their outlook.
  • They will have a balanced view between their needs and those of yours.
  • They are honest enough to admit mistakes and want to make amends.
  • They will ask you when in doubt.
  • They are able to explain their approach, and explain how it looks next to other alternatives

Decide terms that are fair to both sides. Software development does not happen like clockwork, and do not expect it to go that way. Expect issues, and talk about mechanisms how you will get together to overcome them. Keep adequate margins.

Oversee the Work

When you outsource work, your responsibility is not over. If you relax and expect that the outsourcing partner to give you the finished product on a platter after N months, that would be a mistake. There are two aspects to what you need to be watchful for:

  • the functionality and
  • the progress.

You have to ensure the implementation of correct functionality. Specifically, help the partner understand it, and later keep reviewing it to make sure it is going well. Ask your partner to carry out the development in iterations and release the output of iterations for you to see. Watching the product being built incrementally can make wonders in ensuring that it goes in the right fashion. You can intervene before it is too late. In addition to the product, review the design documents or visual models of the product to get insights into the internal working of the application. Examples of such visual models are various UML diagrams, wireframes, flowcharts, data flow diagrams and X-flowcharts (from Xsemble). Out of them, the X-flowcharts are always up-to-date with the changing functionality of the product, and hence are completely reliable.

Set up periodic meets to review the progress. The frequency is up to you — some may want to be a part of a daily standup, some like to do a weekly review, and some are comfortable with a monthly review. More than the frequency, the periodic occurrence of progress meetings is important.

Also, over and above the regular meets, try to find time to answer any questions or review the work when the partner initiates a request. Your quick response could save a lot of unnecessary rework (which translates into waste of money and time).

Be in Charge

Everyone is not a crook, but some are. If you get into a wrong relationship, then you need to be prepared to break it and move on. However, please think twice before you do that and make sure you are not jumping to hasty conclusions. Such a move is always painful to both sides. If your outsourcing is looking inefficient, some times it could be that the outsourcing company genuinely wants to deliver but has some challenge with that. A problem-solving mindset may go a long way here. Take help of an industry expert who could pinpoint the exact issues so that they can be solved with a laser focus.

There are other instances also where you need to look beyond your existing partner. Some times it could be for a skill that they do not possess, or some times it could be for extra bandwidth. Some times, it may happen that you are gearing up to get started on phase 2, but your phase 1 outsourcing partner is not available.

For such situations, you need to be prepared to help your new partner to the desired level of productivity. How is that done? Just retrieve the source code from earlier partner and give it to the new, right? That alone never works. For your new partner, there is an uphill task of going over someone else’s code. It takes substantial amount of time, especially if it is without any supporting documentation or does not have a uniform code structure. Software companies know that it is a thankless job, and most of them will offer to re-write it all over instead of taking over existing code.

Therefore, you need supporting documentation and/or a strategy in which adding further code will be easier. This documentation cannot be prepared overnight. Make sure that your partner documents the footprints they progress, so this documentation is handy when you need. The same documentation also helps the project team.

If you are doing periodic reviews, then you will be better prepared here.

Use Technology

There are some good tech tools that can help in this. There are collaboration tools, there are defect tracking tools, there are work planning / work tracking tools, there are those for configuration management and many others. If your outsourcing partner is mature, they will suggest/ offer such tools. It is always better that the tool recommendations come from them, as they will be familiar to their team and they will be adept at using those. If not, you can bring your own.

At Acism

This last section of this article is about what Acism does about these aspects. From the moment Acism is signed up, it considers itself aligned with the long term interest of the project — including facilitating the ease of switching vendor. 🙂

In fact, on that account, we have an excellent track record of handing over the work in a shape that it can go on in full swing. We have created detailed handover documents and we have trained our own replacements, before we exited. (Those were some short term engagements we took up.)

Acism has woven its processes and tooling towards this philosophy. Specifically:

  1. By default, we offer to do the development in an agile iterative mode. You can review the output of incremental iterations.
  2. We understand how the rigor of processes needs to be different for different-sized work, and we apply the right ones to a given engagement.
  3. We have a invested in creating a project collaboration tool. We have also devised a system of documentation that can especially be useful for large projects that need process rigor.
  4. We specialize in developing with Xsemble. Xsemble’s X-flowchart and Xsemble-generated documentation show you the internal working of the software, over its life. Also, programmers can quickly figure out the short code snippets inside the tiny components and be productive.
  5. We have worked with customers of various levels of technology backgrounds. We take it upon us to explain the strategies we use with the ones who do not have the requisite background.

While the projects that we do benefit from these innovations, we also consult other companies in specific areas of their projects. Companies that have their own pre-existing team (inhouse or outsourced) may find the latter more attractive.