If you are a small/medium sized business or even a consultant/agency who is looking to build an offshore development team, then this post is probably for you!

Building an offshore development team is a lot like being a Basketball Scout without having the privilege to personally go and review each player before offering them a contract.

Yes, it is pretty tricky! But the good part is, you do not have to offer a long-term contract to your development team while outsourcing, and the best part is that the cost factor goes down considerably.

While there are a lot of factors to consider while building your offshore development team, but one factor that stands out from the rest is the execution speed.

Delivery time is important, and the speed at which we deliver a project is the key for any business/company to grow.

It is easily one of the most important “make it or break it” factors.

Over delayed development projects can lead to a slow and painful company death.

What exactly is optimal speed?

Extending the basketball analogy above, in simple terms – it is the fastest that your team can quality for the NBA playoffs, such that you do it in the minimum number of games without hurting the fitness level of the team/players.

In technical terms – this can be defined as the best possible development speed which can be attainted to deliver the best quality end product.

With that being clear now, let’s take a look at the most common factors which slows down and limits this optimal speed during development.

FACTORS WHICH DELAY A DEVELOPMENT PROJECT

Factor #1 – Unclear Project Requirements:

Unclear Project Requirements is the #1 reason for system bugs, which in turn is one of the leading factors in increasing the timeline of any development project.

While system bugs are a major concern for any development project, imagine having a feature which was not at all needed. Unclear project requirements can lead to the development of certain features which are not only useless in the system as a whole but are not required and approved by the client.

Let me take this further with our basketball analogy – In an ideal world, every three-pointer and free throw which your team hits, would go in, but that is not usually the case. This would mean our every 7’ tall “Center player” would also be a good shooter, but then, unicorns don’t exist, do they!

Similarly, a perfect specification document is a dream which every development team wakes up to. In a world where Ned Stark is still alive, our SRS document would clearly define everything to the execution team, and all the work would be done in a single flow without any further delays in meetings etc.

But…………

Hence, it is important to understand that a totally perfect project specification can never be reflected to the offshore development team in one meeting. It is important to have a good communication model in place so that the project requirements are properly relayed and addressed whenever required.

Factor #2 – General System Bugs:

System bugs, as mentioned above, are one of the leading factors in the slowdown of the execution speed and project delivery. They are inevitable, no matter how experienced or kickass your development team is, bugs are like the “Dark Side of the Force”, it simply cannot be avoided.

In addition to the “general system bugs”, there are a lot of additional factors which tend to increase the overall oddities in the system, the major ones being – unclear requirements, communication gaps and change in the execution team.

It is very important that your offshore team has an in-house testing team in place, which is constantly working with the developers to find and report any bugs as early as possible.

Let us take our Basketball analogy again here – Consider your star point guard, John, gets in a stiff challenge early in the first quarter of the game. Now, you take John off for some minutes, but the game still has a long way to go, so you send him back in the next quarter.

John looks a little rusty, but is still completely owning the opposition team. He finishes the game with a few breaks.

John now goes for a medical after the game, and it turns out that he has stretched his hamstring a little too much, and will probably be out for the next 5 games.

Now, if John would have been properly tested and taken out in that first quarter only, then he probably would have missed just 1 game instead of 5. Shame on you medical guy!

Similarly, bugs which are not found early in the system, tend to increase the “technical debt” of the software, and can slow down the project considerably.

Factor #3 – Disturbing the “Iron Triangle”

“Iron Triangle” is basically a project management system which helps us to understand the constraints involved in a project in a better way.

I will be keeping the quality as a constant here, since we only focus on delivering quality solutions, and even you should. Why settle for second best, when you can get the best? (Shameless Ad)

To get a quality final product, it is important to consider the “Triple Constraints” of the triangle, which basically means:

• You cannot expect a quality product by changing only one of the three factors – scope, cost and of course time – and keeping the rest of them same, in any given case.
• Below are three scenarios that shine some light upon the above:

• Delivering a pocket-friendly solution with scope intact (time will increase), or
• Delivering a time friendly solution with scope intact (cost will increase), or
• Delivering a pocket-friendly solution with a specified timeline (scope will change)

• Considering this from a speed point of view – It can be clearly seen from the above example, if you change the project scope/budget and want the timeline to be the same, then you cannot expect the same quality of product to be delivered.

It is also important to NOTE here that speed of a project with a fixed scope can only be increased to a certain level.

Over speeding usually is a result of cutting some corners during development which increases the “technical debt” of the system to a point where the bugs in the system increase resulting in a lot of re-work. At times, this can even lead the developers into a corner – which is a small, cold and very dark place to come out of, thereby decreasing the overall productivity. Factor #4 – Bad Transition from the UX/UI Team It is often seen that clients complete the UI side of the project in-house or locally and outsource the development side of the project. One of the major problems this leads to is an incomplete transition from the UX/UI team to the development team.

It may be due to the difference in the time zones of the two teams or language barrier or even both. For example – the UI team is from some East European country like Ukraine and the development team is from an Asian country like India.

Developers need to understand the UI properly – its purpose, how will it be useful for the end users, problems that the end users might face and how will the users interact with a specific section. You cannot expect to give the frontend of any website/application and expect them to deliver a properly working solution as per your expectations a month later using the SRS which you sent.

The end result will most probably be…………

The best possible solution to this problem is having an end-to-end development team with in-house UI/UX experts who will work together along the course of the project.

Factor #5 – Choosing the Wrong Development Model

Speaking from past experience, a lot (emphasis on the word “lot”) depends on the development model that we choose for a particular project. It is very important that the development team works on the most optimal model for each project in order to have an apt cost/time productivity.

Let me explain this with the help of a brief example – Consider that you are an individual consultant/development agency who is looking for an offshore team to work on a project. Now you want the development team to work on fixed cost waterfall model, but you did not explain the different workflow models to your client.

After a point of time, the client would like to release a beta version with only limited features before completing the project. After the beta is up and running then the client would like to push for a beta 2, and then a final product release.

This would create 2 problems:

• Increasing the workflow load – The product releases have increased from 1 to 3. Each release needs a lot of user testing after it is completed, something which the waterfall model is not equipped for.
• No timeline increase – The increased workflow would mean that the offshore team would need additional time for the final deliver which has not increased.

Such problems can only be solved when proper business expectations are conveyed from the client’s end, and project management models are properly defined by the offshore development team to ensure that everyone is on the same page.

It is important to consider the pros and cons of each model before selecting the same.

Before we wrap this blog up, here is a quick run-down of the various development models along with its important for specific types of businesses.

HOW TO CHOOSE THE RIGHT DEVELOPMENT MODEL

1. Waterfall

Waterfall is top-to-down sequential model which uses the trickle down approach. The development is divided into phases which are taken care of in a sequential way. This model is usually used for fixed cost-and-workscope projects.

The speed level in this process is not really that high since we follow a step-by-step approach, but it often leads to high productivity as only 1 team is working on one set of deliverable at a point of time. Other teams are free to work on other projects.

Who is it helpful for – Local/small businesses who are looking to outsource their development projects in a cost efficient way.

2. Agile

Agile model of development is an incremental model where development takes place in an incremental fashion. There are constant additions in the system, and after each addition a beta version of the software is released. These rapid cycles of development result in a stable release as the final product.

Who is it helpful for – Projects which require constant version releases to test with a specific number of users, before going for a full version release. More specifically startup Mobile/Web app based businesses.

3. Kanban

More than a stand along model, Kanban is more like a process-management system which promotes rapid development and delivery by allocating specific tasks to specific team members.

Using this system, team members know what task to do, when to do it, and how much time needs to be spent on it.

Who is it helpful for – If you are a developer/development firm who is looking to setup an offshore team, then this system is probably the most effective for your needs.

4. Scrum

Which brings us to our last software development model which is again based on the agile methodology. Scrum basically promotes more responsibility for each individual team members. The development team remains focused on reaching a common goal.

Who is it helpful for – Medium/Large businesses which want a particular end product without caring a whole lot about what will be involved in the development process, methodology or the technology. “Get This Done!!” are the basic set of instructions in such situations.

WRAP UP

To wrap it up, let me highlight a few important points before we sign off.

• Not all of us need a Silicon Valley team to take care of our development work.
• If you are looking to build a productive offshore team to keep your costs lower, then it is important to look for a team which is time-efficient and fast paced.
• The top factors which contribute to speed of execution and overall productivity going down is re-work, which in-turn is a by-product of

• Unclear project specifications,
• Communication barriers
• Improper team transitions, and most importantly,
• System bugs

• Other factors which contribute to the speed & productivity going down is the change in the “iron triangle” of the project, and not having the proper understanding of the development models.