Software outsourcing is a disaster waiting to happen; we all know that. First, you find a company that promises you everything you could wish for in a product—on-time and in-budget delivery, highest quality, beautiful user interface, cutting-edge technologies, and hassle-free lifetime support. So you send the first payment and your journey starts. The team hardly understands your needs, the quality is terrible, all your time and budget expectations are severely violated, and the level of frustration is skyrocketing. And the “best” part is that you can’t get away or else all the money you’ve spent so far will go down the drain and you will have to start from scratch. You have to stay “married” to this team because you can’t afford a “divorce.” Is there a way to do software outsourcing right?
Yes, it is possible to do it right and truly hassle-free, but you have to be ready to twist your management philosophy.
The basic fundamental principle here is that 1) you should openly and frequently communicate your concerns with the outsourcing team, and 2) they should openly and frequently communicate risks and issues with you. These are two major success factors in software outsourcing that are very often neglected.
I learned this principle from Wei Liao Zi. He said, according to Military Strategy Classics of Ancient China, p.239:
When information from below reaches up high, and the concerns of up high penetrate to below, this is the most ideal situation.
Let me demonstrate a few practical examples of software outsourcing disasters and explain how they can be avoided if you follow said 2,500-year-old principle.
It Takes Forever and I’m Over Budget!
It’s always 95 percent ready, and you always have something that is not implemented or is broken. They’ve done a lot of work, you’ve paid a lot of money, but a market-ready product is not yet there. It takes week after week and month after month; the backlog always has something, and you simply can’t finish this. You’re starting to see this project in your nightmares, and Prozac doesn’t help anymore. How does this sound? Familiar?
I hope you do realize that no matter what kind of contract you signed with your software outsourcing partner, how many schedules you’ve baselined, or how many promises were made, they want to keep you as a client forever. Well, for as long as you have something in your bank account.
You want your business to succeed and flourish, right? They want the same for their business. Your success means a product that is finished and launched to end users. Their success means a never-ending process of writing software for you. These two goals have very little in common. I would even say they contradict each other—when you succeed, they fail.
Of course, they will tell you they want to finish this product for you and get new contracts in the future. They will say their primary motivation is to make you happy and obtain a good reference. They will assure you that customer satisfaction is more important than money. However, I’m suggesting you be strong enough to face the reality—it’s all lies.
The majority of software outsourcing projects fail. The vast majority (see the latest CHAOS report). Software developers realize this better than you, mostly because they see how it happens every day. And your project is not an exception. Thus, let’s forget about these beautiful promises and focus on the ugly reality—you’re on your own.
Keeping in mind the principle I mentioned above, here is my recommendation: Make sure the team understands 1) your real time, cost, and scope constraints, and 2) the consequences of their violation. This is about the first part of the principle—you should openly and frequently communicate your concerns. What usually happens is that the outsourcing team remains unaware of a real business situation and only hears “I need this ASAP” every second day.
“ASAP” is not a deadline. Moreover, it’s a very de-motivating substitute for a realistic milestone. When the team doesn’t know when exactly you need the product, what exactly has to be ready by that date, and why, it starts to work against you. The emphasis here is on “why.” For most business owners, it’s difficult to answer this question.
Why do you need the product to be ready by the first of June? Just because you are sick of waiting? This is not a reasonable answer. You’re sick of it but you still have money in your bank account. They will keep invoicing you, and they won’t respect you. They won’t treat you as a strong and goal-oriented business person. You either aren’t smart enough to identify your time constraints or you’re hiding them from the team. In either case, they won’t appreciate that behavior.
Here is how a properly defined time and cost constraint may sound:
Features A, B, and D must be ready before
the first of June, because our marketing
campaign starts on the fifth of June. If
we don't have them ready, I will lose $25,000
in marketing costs. If this happens, I will
have to cut the monthly development budget
in half.
When the software outsourcing company, your partner, hears this definition of a deadline, it becomes a real partner of yours. Now its goals are aligned with yours. If the milestone is missed, you will suffer and they understand exactly how. Besides that, they see how your suffering will be transferred to their shoulders too.
Stop asking them to finish everything ASAP. Stop calling them twice a day and yelling for an hour about their poor performance. Stop using language in business emails. Stop making all this noise. It doesn’t help you anyway. Moreover, it only makes the situation worse, because you’re losing respect and they’re starting to treat you like a cash cow—a rather stupid and emotional one.
Instead, do your homework and define your realistic milestones. Think about your real time, scope, and budget limitations. Write them down in very short and concise sentences. Make sure your constraints are realistic and their descriptions answer the main question—why.
Why do you need this by the first of June? Why do you want to spend less than $50,000? Why do you need all five features to be in version 1.0? Why do you want your web app to be ready to handle 1K concurrent sessions? Why do you need a mobile app in the first release?
Answer for yourself and make sure your answers are understood by the outsourcing company. Don’t hide this information.
The Product Is So Clumsy
You want your web app to look like Pinterest, react fast, be easy to use, and make you proud when you show it to your friends. But the product they created for you is clumsy, slow, and to be honest, ugly. You’re asking them to do something about it, and they keep giving you promises. The project keeps consuming your money and its budget grows, but the look and feel is not getting any better. It is far from Pinterest, very far. The frustration is growing, and you don’t see any reasonable way out of this. The only advice you’re getting from your friends is to re-do it all from scratch with a new web development team. How does this sound? I bet it’s familiar.
I believe the root cause of this dead-end situation is a fear of conflict. At early stages in the project, you try to do everything you can to keep a good relationship with the outsourcing company and not to offend anyone. You don’t want to control anyone’s work because they may take it as an insult. You don’t want to express your quality concerns because they may de-motivate the team. You just hope they will improve the product in the future, but when the future comes, it’s too late.
Again, keeping the age-old principle in mind, I would recommend that from the first day of the project, you establish a routine procedure of checking their results and expressing your concerns. In our projects at Zerocracy, we ask our customers to be present in GitHub, review our releases frequently, and report any inconsistencies found as GitHub issues. We encourage project sponsors to be as pessimistic and negative about our quality from the beginning of the project. We realize this is how we can minimize the risk of a “piled-up frustration.”
Try to do the same in your project that is outsourced to an offshore developer. Don’t be afraid to offend them. Iterative and incremental criticism is a much healthier approach than feedback-free peace that ends in war. Find a way to keep your outsourcing team aware of your opinion about its results on a regular basis. Don’t try to be nice to save a project. You’re doing yourself a bad favor. Instead, be open about your concerns. Remember the first part of the principle above—you should openly and frequently communicate your concerns. This is how you stabilize the project and minimize risks.
Also, it’s a very good practice, from time to time, to invite technical reviewers to generate independent opinions about the product under development. Read my other post about this subject: You Do Need Independent Technical Reviews!.
I Can’t Rely on Their Promises
You call them, make plans, declare milestones, define features, set priorities, agree about quality, and then hang up. In a few days, you realize it was a total waste of time. They don’t keep their promises because there is always something new happening. Someone is sick, some server is broken, some piece of software appears to be mal-functional, some code is no longer working, etc. You call again, express your frustration, make strong accusations, restructure milestones, redefine features, reset priorities, and in a few days start over. Been there, done that? Sound familiar?
In my experience, this unpredictability and unreliability of a software outsourcing team is in most cases caused by a project sponsor himself or herself. This happens when you don’t listen to them or they are afraid to tell you the truth, which is usually the same thing. Some call this “fear-driven development.” The team is afraid of you, and in order to keep you on board as a paying customer, has to lie to you.
Basically, they are telling you what you want to hear—that the end of the project is close, that currently open bugs are easy to fix, that performance problems are minor, that the quality of the architecture is outstanding, and that the team is very motivated to work with you. When you hear any of the above, question yourself—Do you encourage them to tell the truth? Do you reward them for bringing you bad but honest news?
Once again citing the fundamental principle mentioned above, I would recommend you make sure your reasoning for awards and punishments is transparent to your software outsourcing partner and is based on project objectives, not your personal emotions.
In one of my previous posts, I wrote that a happy customer is a false objective for a software development team. A customer who is promoting this objective is a terrible customer who is doomed to fail the project. If you reward your team when they make you happy with good news, you are training them to lie to you. If you expect them to deliver good news, you are discouraging them from telling you the truth and from doing what is good for the project, not for you personally.
You’re discouraging them from arguing with you. In other words, you’re throttling the channel of information that is supposed to come to you from the people working for you. You’re isolating yourself, and the team is starting to work against you, not with you.
Here is a practical recommendation. First, regularly announce your reasonable objectives and constraints, like I explained above. Make sure the team understands your business plans and the “why” reasoning behind them. Second, regularly ask team members about risks and issues. Ask them why they think project objectives may be compromised. Even better, let them document risks regularly and report them back to you. Reward them for being honest in this list of risks.
Try it and you will be surprised by how many interesting things that risk list will contain.
