Why do so many outsourced software projects fail?

...especially at the early stage?

If you haven’t been working with remote teams (especially development teams) in the past it may be challenging to start successful cooperation. Many things can go wrong - starting from lack of trust, through lack of experience with managing teams and IT projects (which are a bit specific) ending in misunderstandings regarding what we want to build together.?

Let me share my experience on how you can reduce the risk and what the team can do to change the lack of trust into fruitful and long term cooperation.

Share your vision

Yes, it seems like a sentence from the advertisement, but it may be a game changer especially in the early stage of the cooperation. Based on the vision the software company will be able to sit with you and start talkin about Roadmap, which may be very helpful and bring lots of value (even if during this meeting won’t be created any line of code). It will allow the Software company to plan resources and avoid misunderstandings on the later stage. Of course, it’s not possible to give an exact estimation based on the roadmap, but the team leader, business analyst or project manager with your help should be able to build a plan of what will be the rough sequence of the modules and functionalities you need. Of course, if you feel you can do this on your own it’s even better. It is important to have a roadmap and share it with the team.?

First things first - Prioritize requirements

When the roadmap will be ready it’s time for cross checking all modules to determine what depends on what.The dev team may be very helpful finding some technical cross dependencies, which may not be obvious, but will have a great impact on the delivery order of modules. Another thing worth mentioning - in specific situations some modules may be required for a specific date and there is no way to postpone this. If this is the case - you may have to lower the priority of some other modules (keeping in mind also the tree of dependencies) to be sure that you will be on time with the “must have” functionalities. As the task is not simple for someone who hasn’t done this before - we always offer our help in this area. One day of work of experienced engineers will save you days or maybe even weeks in the future. Of course you don’t have to specify the priorities for the year ahead :) It’s completely enough to understand the priorities for several months as (again from my experience) the priorities can change and it’s also fine.?

The estimation - be on time, be on budget

If you already know what has to be done it’s time to start estimating the tasks. For this stage you will need experienced developers, so at this point you will need to rely on your development team. It would be also good to start using some tool, which will help you store the current state of each functionality. The problem is that your team may also have a problem estimating some business domain tasks … in such a scenario the best option is to start estimating not in a specific (measurable) unit of time, but switch to virtual units. Usually such units are named “story points”. But what can you do with virtual units?!?! It turns out quite a lot! No, on the first day you won’t know how performant your team is, but after several days you will be able to compare the results. Several lines above I wrote it would be good to start using some tool for project management - this is exactly why it’s so important. With proper tools you will be able to track the progress, check if the work performance is linear, verify what are the bottlenecks, etc.?

Adopt tasks and plans the team velocity

After the first 2 sprints you will probably know your team velocity, so it’s the first time when you can adjust your plan and decide what to do next. Hopefully all planned tasks will be finished on time, but reality shows (especially in the beginning of the cooperation) that not everything is perfect. It’s a very good time to talk with your team about this. At this stage communication is crucial to achieve your business results. Please keep in mind that your team is skilled in development, but you are the expert in your business area. You will need to learn the team about the business, users, behaviours and customs. If you will help better understand your business and intentions - your dev team will bring better results for you.

All points described above are somehow related to existing methodologies of managing software projects, but there are also unique values we developed on our own and they bring great value to our customers, so I believe it time to share it to the world.

Proper “mindset” of your dev team (leader)

It’s difficult to describe what “proper mindset” means, but from our experience the most valuable attributes of the team leader are reliability, responsibility and involvement. Why are they so important? It’s very common nowadays that companies “sell the team” and forget about customers, there's needs and business goals. In our approach we stick very close to customer requirements looking not only at specs and tasks. The sentence I constantly repeat mentoring younger colleagues is “Who’s and what problem you solve”. This obvious sentence sometimes becomes an eye opener and changes “the rules of the game”. Having answers for the question “what my customer needs” we are able to help better and propose the most valuable solution for the problems we solve.

Synergy effect

Synergy effect is another attribute unique to the Neti. As a small and agile team we are able to easily communicate between teams, share knowledge and also solve problems of the colleagues involved in various projects. It’s not possible to achieve similar results when you deal with a multinational outsourcing company having thousands of developers, but in our scenario it’s not a problem at all. We meet regularly, know each other and know who has expertise in what area. Thanks to such a friendly atmosphere your team may always count the experience of all Neti developers.

Self-managed teams

The next value we have which is worth each money but difficult to. I will try to describe it based on the example from our small company: Several years ago we started cooperation with one of our customers (which we still support in development) and the beginning of the cooperation was really tough. The customer had no trust in us: all our work was always verified a few times, every reported time was checked, every additional task or task which took more time than expected was discussed to ensure that it was a good decision on our side. The deadlines were very tight and expectations … let’s say incomparable to the market standard. Hard time, but after several months without even a single failure the rules of the game have changed: there was no verification of the work, no daily verification of the timesheets, etc. The team members have changed during these 5 years and from the initial composition there is still only 1 member but the approach we started from hasn’t changed even a bit and the trust that we have built pays off to this day. How does cooperation look nowadays? Our customers don’t bring us long specifications, mockups or “definition of done“ any more; just a few sentences which describe the problem or idea is enough and we already know what needs to be done.?

Conclusion

Finding the right development team is not an easy task and being able to effectively cooperate when you have no such experience is a really challenging topic. Fortunately you are not helpless; you have tools and methodologies to measure the progress of the work and being able to predict when the new functionalities will be released. In addition you should pay attention to the behaviour of your team. It will guide you to take strategic decisions related to your team and will give you transparency in the context of delivering your project on time and on budget.