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.

Jon Graham shared the following outsourcing advice for newbies... 

"The outsourcing movement has just reached puberty and will be maturing over the next few years. In the past, it was thought that only large organizations could afford to outsource, but that is not the case any longer. The small to mid size companies are getting into the game as well. However, for the outsourcing newbie's out there that want to take the plunge, there are a few things to consider in order to ensure success."

Whether you're looking at India, Russia, Ukraine, Vietnam, China, Brazil, Montana, or the Philippines, outsourcing isn't easy. Here's a list of tough questions you need to ask:

1. Process: How am I going to manage the work that I am going to outsource? What processes and procedures do I need to have in place? How often do I want updates? What level of information do I need? What delivery model am I comfortable with?

2. Tools: What tools can best help me manage the process I've defined. Do traditional individual tools work; mpps, word docs, emails, spreadsheets? How can I get real time project updates about vital project statistics/metrics? Is there single web-based, software development management (SDM) system?

3. Vendor Selection: What type of experience/skills/corporate culture does my service provider need to possess in order for us to be successful together? Is this a one project stand or is there potential for a long term engagement? What types of work has this vendor done in the past. Interview them as you would a potential employee.

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...