I am a Sales guy in my present life. Before that I was a project manager, project lead and a developer. In the last 15 years, I’ve been part of many software projects in various capacities; seen some success stories and seen a fair share of failures as well. I’ve been asked to write this article based on my experience with various projects, clients from different geographies. Before I started to write this, I thought of Googling what other people have said on the same topic. I was overwhelmed by the number of articles, studies and research papers I saw. Wow! I wondered if there is anything new for me to say that has not been said already. When in doubt, go to the BOSS (who is always right). He reminded me to write my experiences. So, here I go.

Before I actually start on the reasons, let me share one peculiar thing that I found in my study of already available material. Most of the articles and studies available on the subject, focus majorly on the reasons for failure on the vendor’s side. In my experience, I have seen that both the clients and vendors can work very hard to fail the project. So, here’s my angle to attack this story. Developing of software product is a journey that starts from idea to Go Live to maintenance. The cause for failure can be inducted in this journey at any stage by any stakeholder. 

I’ve said earlier that right now I am a Sales guy. Every now and then, I get a chance to talk to a new potential client. I get to hear about their ideas for the development of new softwares. In today’s world softwares are not only developed by companies to help in their operations, but to be used by end users directly. These softwares can be in the domain of social applications, entertainment, e Commerce, education and what not. Many a times the client is just a person with an idea and not a company trying to develop something. Most of the time, the idea already have a competitor product available in the market. Most of the time, the person has the idea, maybe has a little money with himself, has no concrete financial plan, but is very passionate about the idea. And the best thing is that more often than not, the person would not have given a deep thought in documenting the idea, giving a shape to it. It is something floating in his head.

• An individual (with an idea)
• MINUS market research 
• MINUS documentation of idea 
• MINUS positioning of idea 
• MINUS financial plan 
• EQUALS Recipe for disaster from very start

I can see at the beginning only that this project will fail, not in developing the project, but in taking it to a success. 

What do I do as a Sales guy? Do not put my hand in it? But I have my targets to fulfill and more often than not I get these kinds of people only. Most of the sales guys will take the project. They will take it for whatever money the client has. Why leave the $$$ that he have, even if one know that those are not enough for his product to be a success. In nutshell, such projects are doomed even before they start, even if the project is developed successfully. In six months after launch, the product will be nowhere to find. And many such projects will never see light of the day. In the middle of the development only, client will realize that his idea was not so great, or his preparation was not so great or he is not as equipped as he thought he is to compete. So, the project is dropped. 

So let us now consider that the client is well prepared. He has documented the idea, done the market research, positioned the idea well (or at least have a clear idea of how he wants to do) and most important, have the finances available. I am now diving into the area where all the other researches have already published a lot; on the vendor’s side. 

What is the fascination of doing projects in a fixed price? In all these years, I failed to understand clients’ fascination to get the vendors to commit to a fixed price. It is important to say here that I am not against fixed price model, at all. You want a small update to some existing work, it is well defined, fixed price is okay. You want a small application to be developed, it is well defined, fixed price is okay. I have a problem with clients who think they are building a huge project, who know there are multiple different parties and stakeholders involved, multiple different integrations involved, where project is expected to run more than 6 months. In today’s world, industry is not following waterfall model any more. Nobody is spending or willing to spend months in requirements definition and documentation. Nobody is willing to spend months in analysis and system design. Still there are people who want to have full end to end turnkey engagements and expect it to happen in a fixed price model. Please take a note, budgeting a project is different from having a fixed price on a project. Budgeting for a project is paramount, but does not necessarily mean that there has to be a fixed price model for the project. In today’s world, things are changing rapidly. Every 3 months, there is a 2.0 of something. There is a 2.0 of even what and how end users want in every 3 months. The focus in such projects becomes “what is the bare minimum needed to adhere to scope” rather than “what’s good for the product”. When your project is running for a year, the world is changing on the sidelines, and you are bound to be affected by those changes. Such projects will have less scope for flexibility; and in today’s rapidly changing world ability to be flexible and ability to adapt the change is the key. In such a scenario, clients who have huge projects and want to tie vendors in fixed price model are doomed to fail. Vendors will succumb to the clients’ pressures for fixed price model. But such projects will always run into problems. So Dear Clients, we know you love to have a fixed price, but then be prepared to resist your temptations for change, be ready to resist your inspirations from what is happening around you. We know this is not possible. 

But the book of software engineering has a term to handle this, “Change Request Management”. It’s a SHAM!!! Believe me, it’s a SHAM!!! Even if the vendors understand it, even if the Client understand it (which happens only in dreams), people spend hours analyzing these, debating these and all that effort goes unaccounted for, and more often than not the debates happen because the first effort is to try and push this idea out or be considered as a Change Request. Hours of effort from multiple people go in establishing whether it is a Change Request or not and afterwards people actually start working on it. A big LOSS, from where I see. Managers are living their life on it. Does the project benefits from it? Project does not, only one or the other party benefits from it. Project does NOT!

So, budget for the project, budget for the scope, budget for the modules, budget for the tasks and budget for the people but stay away from Fixed Price. That will give you flexibility to move the budget where you want to focus more. That will give you the flexibility to change and adapt to the changing needs of the world. That will help you to make better decisions in favor of the project. There are better things to hold vendors’ necks for than Fixed Price. 

Most clients do the fatal mistake of thinking that just by hiring a correct vendor their job is done. It is not. Do not see this as “offshore development”, see it as a partnership of “onsite-offshore” engagement. It is better to have a combination of team at onsite as well as offshore. Manage some parts onsite and some parts offshore. Outsourcing everything offshore may not be a very good idea. At the very least, have one technical head onsite. If you can’t find one, your vendor will be more than happy to ship one, to be with you to share your dreams. So remember, it is a marriage between onsite and offshore. You need people on your side as well. 

Another mistake clients do is to put their entire focus on choosing the vendor company and then letting the company choose the team. Treat yourself not as a client, but as a part of the team. Participate in not just selecting the vendor, but selecting members of your team as well, even in the offshore team. Yes, it is important. Your project is going to be in the hands of these people. The project will be as good as the team is. So, talk to them, select/reject them. Be ready to change them, if required. You do not need a team of all rockstars. You need Horses for Courses. Your project will have different kinds of needs for skills and skill levels. Choose people with appropriate skills and experiences. A good mix of skills and experiences is what required to get all different kinds of tasks done in the project. If you choose the right team, there is a great chance that you will have a successful product. If you do this, you will get a chance to speak to everyone on the team and this will ensure that there are no communication problems (which happen all the time with offshore teams and studies put communication problem as a key problem for failure of offshore projects). 

Project manager is a key person on your project. It is very important that you choose the right guy here. He is your eyes and ears in the offshore team. You get the right guy here, all else will fall in place. He is YOU getting your job done. So, pay highest level of attention if getting the manager for your project. At the same time, do not get too many managers on the project. Get more hands who will actually work, produce and only optimum heads to manage them. Getting the balance right, is important.

Another aspect to pay attention when you choose your vendor is to know how strong their HR team is. Will the vendor’s HR be able to provide the required skilled people for your project? Do they have the availability of the people? If not, do they have the strong HR processes to get the people on-board quickly? Do they have the training and development processes to get people trained for your project? Look for this factor. 

TOOLS is the final thing that you need to make sure success of your project. Make sure that your vendor has and use all the different tools that are required to run an offshore project. You can not do the fatal mistake of treating emails as the tools for your project. You need various tools for communication, collaboration, knowledge base, task management and planning, issues management, resource and effort tracking, code repositories, virtual meetings. If you and your teams does not have these on the project, you will never be able to enforce and ensure transparency. If you have the transparency, you will always be able to make the right decisions to take your project in right direction. 

Finally, you do not offshore because you do not have time. You offshore, because that brings optimal cost/quality balance to your project. You have to give time even if you offshore the project. Be prepared to give that time. 

You tick all the factors given above; your offshore project will never fail!