Saayan's Blog

Much has been said for and against outsourcing software development. And yes, many models of outsourcing have been championed. In this 3 part series, I will explore my own software outsourcing model that I think works for small companies.

Assumption - the company that is outsourcing is small; the company that is being outsourced to is also small.

“Small” is a relative term. In the Indian context, small can mean a company with 50 employees. In the Australian context, “small” can mean a 5 employee or less company. It depends. By the way, I like the term “it depends” - a lovely expression to keep things open ended without committing to anything and sounding very wise at the same time. But, I digress.

In the first part of this 3 part series, I shall attempt to identify the problems faced by small companies that want to outsource. These are not only issues, but also contradictions.

The Issues for the Client

The client is the company that wishes to outsource software development. From the client’s angle, there are a few issues:

1. Process

Small companies do not have the luxury of following a sophisticated process - for example, CMM. But without some rudimentary process, this is bound to fail.

2. Structure

Not enough people and resources to establish a delivery structure. Yet, there has to a framework for delivery. And this is talking from delivery acceptance angle. Without structure, communication breaks down.

3. Cost

Not enough spare cash to throw around. If a 10 person company is outsourcing the work of 1 headcount, it is outsourcing 10% of the work. For a headcount of 2, it is 20%. Each outsourced headcount need to save cost for the company. Cannot maintain redundant resources. This causes a significant tactical issue in case the developer assigned by the vendor company decides to leave the project. More on this later.

4. Cohesion

The hallmark of a good software design is high cohesion. What is cohesion? - verbatim from webster - the act or state of sticking together tightly. Cohesion is important for projects as well. Small companies naturally have small project teams. Typical size is about 3 or 4 people per project. If you outsource 1 person’s work from a team of 3 people, you are breaking the cohesion by 33.33%. That number does not feel good.

5. People Management

Remote management of software developers is a sure recipe for disaster. But then, if a company is outsourcing 1 person’s work, how is it going to manage that 1 person? That 1 person is a part of a 3 or 4 people team. And that team’s manager need to manage this 1 person remotely. How do you do this?

6. Requirements Management

How do you specify your requirements? Do you write down every nut and bolt in a beautiful colorful document and send it across to your remote developer - and presto, he / she produces exactly what you want? Wake up - this is utopia - has never happened and will never happen.

And, how do you do change management? Your customer may feedback on a prior release saying that there should be a search box in the top-right corner. Fine, it is just a box, right? Wrong. This box is Pandora’s box. Anyway, how do you change that lovely screen-shot in your first requirement specification and let your remote developer know that he has to implement a search box (and the search functionality of course). Small monkeys indeed have quite long tails.

7. Out of Sight, Out of Mind

It means - when the remote developer is out of sight (which is the case here), then the client company is out of its mind. People get very uncomfortable by what they cannot see. Here is a small company that values every single dollar - paying a few thousand dollars a month for a person whom they cannot see. Not really a warm fuzzy feeling, is it?

8. Communication

How do you communicate to your remote developer? Directly? Or through a point of contact in the vendor company? This opens a can of worms - like how do you handle coding emergencies - like, lord in heaven forbid, the remote developer’s submitted code has broken your build? Do you call this guy 10,000 kms away or you send him an email? What do you do?

9. Post Delivery Support

Will the vendor jump ship after delivery? How to ensure post delivery support? What are the cost implications? How does the client make the vendor accountable after the delivery?

10. Quality

How to ensure quality of the delivered product? What to do if the delivered work does not meet expectations?

11. Dispute Resolution

What to do if the vendor’s work does not match requirements? How to resolve this without having a severe impact on the overall project?

The Issues for the Vendor

The vendor is the company that is providing outsourcing services. The issues from the vendor’s angle:

1. Process

Clients will typically outsource 1 or 2 people’s worth of work. Cannot afford a rigorous process on per client basis. Have to come up with a process that works across several client companies.

2. Structure

The vendor has is own project structure internally. But the client views the structure from another angle. How should the structure support these multiple views without contradictions?

3. Cost

Need to keep per-client overhead to a minimum. Cannot maintain redundant resources on per-client basis.

4. People Management

Every developer is accountable internally and externally. Internally to vendor’s own lead or project manager. Externally, to the client’s project lead or manager. This can be very confusing. How to resolve this?

5. Requirements Management

Clients, who are small companies, typically carry the specification in their head - not on paper. They do not have a spec, forget about giving the vendor a spec. So, how do you develop without spec?

Also, small companies typically do not follow formal software development process. This means, they change their requirements at the drop of the hat. How will the vendor handle change management?

6. Communication

How will the vendor manage communication with the client? Will it give direct access to the developer?Or, will it have a level of indirection - means a point of contact - through which communication will be channeled?

7. Post Delivery Support

How to do the post delivery support? Bugs in software are inevitable. Will the client be charged for the time to fix the bugs? Will bug fixing be done free of charge? If there are requirement changes after delivery, how to handle that?

8. Dispute Resolution

How to handle disputes concerning software not matching requirements? What strategy to follow to avoid this situation?

In Part II of this series we shall address these issues. The model will evolve from the solution and we shall see it in all its glory in Part III.