Software Sweatshop

I had a conversation with Pete Segar, the CTO of Ergotron a few weeks ago. I read about him in an article about domestic outsourcing and how it's becoming more of an imperative for mid-market firms. More outsourcing firms are targeting mid-market companies (Pete gets his fair share of cold calls). Ergotron is working with an offshore team in Belarus. The biggest reason for working with them was the fact that they had a local office in Minnesota. This helped reduce the inevitable communication breakdown of working with resources half a world away and provide a level of accountability. The biggest problem with global sourcing is accountability. Software project failure Cost overruns and missed deadlines are a grim reality of most software projects, doubly so for offshore/outsourced software projects.

Another big headache when working with an offshore engineering team is the amount of time it takes to develop an adequate spec. I've always said that finding an offshore software development team is easy, but finding a team that understands you and is committed isn't. Finding an offshore body shop full of programmers is incredibly easy, but the real value is outsourcing is choosing a team with the experience, tenacity, and insight to help you flush out a spec. Most companies that choose to outsource do it because they don't have the resources or experience to build their custom applications. The point of outsourcing is to find a vendor with the right skills and experience to solve your problem. 

The best way to evaluate an offshore vendor is to find out their level of experience solving problems similar to yours. It's not necessary that they are domain experts, but they do need to have a problem solving attitude. This means helping you determine the "what if" scenarios of your application, asking lots of questions, and making sure that their solution reflects their understanding of your problem as a business problem, not a technical one.  A strong QA focus is critical also because it indicates maturity. Your ideal offshore software partner will seek to understand your business and make suggestions, not be a passive accessory. To this effect, Narayana Murthy, founder of Infosys spoke of their shift from problem solvers to problem definers:

"We want to be proactive problem definers rather than reactive problem solvers. We want to be chefs rather than short order cooks. We want to go sell high, so we are selling to a high level executive who has a more complete picture of the problem and we want to be trusted advisors to that senior executive so that we can have a shot at helping him define the problem, and then the solution automatically follows that."

Mid-market CIO's are in a tough spot. On one hand their CEO's are pressuring them to cut costs and pursue a global sourcing strategy. On the other hand they are bombarded with calls from offshore engineering firms in India, Vietnam, Ukraine, Brazil, and the list goes on. As smaller companies look for more than cheap labor when looking for an offshore software team, it's too bad that the Infosys's, Tata's, and Cognizant's of the world that have cultivated vertical expertise aren't beating on their doors for business.

(This is not a new post. I just decided to change the title...)

A lot of offshore companies will tell you (primarily India, Philippines, China, and Vietnam) that if you work with them, the timezone difference will allow them to work while you sleep. They're an asset because you now have a 24/7 development cycle. Sadly, it's often a liability.  

In most cases we've seen, unless the specs are really good, and the development team sees the big picture, a 24/7 development cycle becomes a 24/7 headache. The lesson is that you should either have good specs, or be prepared to pay for specs. A mature development team will tell you this from day one... it's a sign of maturity. We've seen too many floundering projects resulting from poor specs.

I met a guy that was looking for offshore Java developers. He did a lot of research and ended up working with a company in India. As expected, part of their pitch was that they program while the client sleeps, a real 24 hour development cycle. We've heard this pitch before, and in theory it sounds good, but it assumes that the developers don't make any mistakes. In our experience, problems occur when requirements are not clear and there is a lack of communication between both parties. The client ended up working with a "near shore" vendor, but the following advice could help prevent problems with your offshore team.

-Committment on both sides: Make sure you have a local and offshore project manager. The local PM will communicate with users or internal stakeholders and the offshore PM will communicate with developers. It's helpful if they both have experience working with distributed teams.

-The Key to Any Relationship: Whether it's a marriage, a football team, or a team of software developers, consistent and structured communication is the only way to prevent heart-breaking (not to mention bank-busting) misunderstandings.

-Proper Methodology: Agile or Scrum methodology is helpful because it's highly iterative and allows for changes

-Solid QA: The offshore team needs to have a solid QA process in place. Developers aren't the best testers, and they shouldn't have to be. Make sure your offshore team has heavily invested in QA. Ask about their QA process and how they ensure that their work makes the grade.

-Find Solid Developers: Past work, a pilot project, or an exam are all helpful to make sure you're getting a qualified resource. It's not always critical to get an incredibly experienced developer as long as they have a good attitude and are willing to learn. An honest vendor will tell you the strengths and weaknesses of their team.

This excerpt came from a post on Gunnar Skogsholm's blog about software project failure... Software development hard. Right from the beginning there are a million things that could go wrong. This list on comes from

Software is risky business. Here's what can (and usually does) go wrong:

• team dysfunction
• failure to understand software (process, costs, etc) 
• lack of leadership or vision 
• failure to understand, communicate, document the problem domain description 
• failure to architect a solution 
• failure to design a software application 
• failure of project management 
• failure to select good tools 
• failure to select reliable technologies 
• failure to implement the software 
• failure to test the software 
• failure of quality assurance       

Software development is...                                                                                                                                                                

The US economic recession is hitting a lot of businesses hard. I got an email from the CISO of a large publicly traded company saying that they're looking for new outsourcing destinations since wages in India are rising. Apparently outsourcing to Pakistan,  is becoming more attractive, as well as other countries you wouldn't immediately associate with software outsourcing like Slovakia, Vietnam, and Turkey.

But there's more to outsourcing than scouting out the next low cost destination (unless you want to get burned by a  software sweatshop) Outsourcing isn't easy, and unless you're smart, the cost savings won't be the main factor leading to your decision. Tons of reports have suggested that you don't save nearly what you initially expected. It's easy to think that sending work overseas is a cinch; IT'S NOT. Outsourcing works great if there is a clear understanding of the nature of the relationship. Relationships based on trust, partnership, and value should always outweigh low cost. It's a matter of time before your offshore vendor raises their prices. Stop chasing the next low cost offshore destination. Outsourcing is not as easy as you think.

Keep the following points in mind when looking for an offshore vendor:

 
1). Lack of Communication: Expecting to send work to some foreign land without both sides being vested in communicating daily will lead to failure. If you go offshore, be sure that you're ready to spend time discussing the status, challenges, accomplishments, and goals of your project.

2). Undefined Requirements: I recently asked a question about software project failure on LinkedIn a few weeks ago and was overwhelmed by the quantity and quality of the responses. It was actually in response to an article that I found on the Wall Street Business Technology blog about failed corporate IT projects The main theme from the 76 answers (and counting) that I received is that unclear specifications and lax project controls result in failed projects. With onsite IT projects going belly up, can you imagine how hard it is to keep an offshore project on track? Don't underestimate clear specs.

3). Currency Fluctuation: Now this is really sad. Companies that went to India 5 or 10 years ago are now looking for the next low cost country to shift their operations. Don't make lowest cost the only reason for choosing your offshore vendor; it's short-sighted and unsustainable.

4). Corporate Culture: Do you value quality over the lowest cost, do you treat your employees like the geniuses that they are, do you make decisions based on principles and values rather than expediency? Well you better make sure your offshore partner does also. Often times they won't be the cheapest, but they'll be your ace in the hole.

5). Losing Key Resources: Too many offshore projects are hindered because of attrition. This is an all too familiar problem with companies that have sent work offshore. In developing countries like India, wages are rising, diminishing most cost savings. The rising wages mean that there is more opportunity, so top talent is jumping ship for more lucrative opportunities. Does your offshore partner hire generalists or experienced specialists? If your offshore vendor is a "we do everything/one size fits all" firm, chances are they'll have high turnover. Truly great companies are very selective about who they hire and fanatical about keeping them happy. No doubt, not everyone will be a superstar, but experienced team leads will bring the best out of the rest of the team.

...you can’t negotiate with a methodologist.

Needless to say, following a good methodology is an integral part of any respectable software development effort, particularly when you’re working with an offshore team. In fact, most offshore horror stories have less to do with the technical expertise of the developers and more to do with how the project is handled. Many times projects get compromised because the vendor is juggling too many projects at once. Resources are scarce, teams get stretched, deadlines are missed… you know the drill.

Project failures rarely happen at the ‘ones and zeros’ level, so the real trick is to communicate with your team constantly (daily) to make sure expectations are clear and work is being done according to plan. So what you’re paying for is the set of principles that your vendor has established, their culture, their hiring and retention strategies, their growth vision, their industry expertise. The real question becomes, at the moment of truth, are they willing to cut corners and compromise these principles?

Even if they have technical weaknesses, working with principled methodologists who compromise for no one will always lead to success. Companies that define themselves and refuse to compromise will give you the only thing that really matters in business… trust.

I just saw a great video on the Scrum methodology delivered by Ken Schwaber at Google back in 2006.

Scrum is like having a gun to your head; if you can't produce results, be transparent, look for the simplest solution, adhere to strict deadlines, be held accountable, work incrementally and iteratively, respond to dynamic change, and deliver quality, you, your project, your company, and your career are dead. It's not all gloom and doom though, you'll be surprised at what you can come up with if you actually do follow this methodology.

It's perfectly suited for offshore software development. In fact, I can see why distributed software development teams that don't follow Scrum or Agile usually fail.

But as you'll see, Scrum isn't for everyone. It means looking at the facts, good or bad, and making very tough decisions. True adoption of Scrum is a real test of an organization's culture. With Scrum, you can't stick your head in the sand. A very valuable lesson for anyone that's been part of a failed offshore development effort.