Wednesday, March 31, 2010

#6 Lack of Technical Expertise

In an effort to reduce software development costs, more companies are looking to outsourcing.
However, all too often, despite every effort to choose the right partner, IT executives find themselves stuck in a nightmare. In the beginning all seems to be a honeymoon; low prices, qualified people, etc. but further into the relationship, once you are committed, suddenly everything changes.

Maybe it sounds repetitive, but focusing only in the price could be the biggest mistake ever. Besides cultural differences or time zone difference, the absence of relevant technical expertise has been a key factor in the failure of software development outsourcing.

Dean Davison – Vice President of Service Management Strategies at META Group writes in "The Hidden Costs of Offshore Outsourcing" offshore vendors often lack developer experience. On average, IT organizations going offshore will experience a 20 percent decline in application development efficiency during the first two years of a contract as a result of such differences”. We have clients that say they had productivity losses of 50% when they went offshore.

When building software products not only is experience, but also specialized knowledge is required. The right expertise can mean the difference between success and failure. The offshore vendor’s lack of experience represents a significant risk to the Client.

American companies have been struggling with the lack of technology knowledge and experience of offshore teams. We can assume that all offshore teams have been already trained in the common technologies (e.g. C#, .Net, Java, etc), but the truth is that most of the time they are trained at the client’s expense, without their knowledge. When coupling the rate of attrition with the growth rate of the company, it is fairly easy to see that experienced resources move up or move out and leave inexperienced resources in their place.

The most common areas where a team will have to be trained are:
• Cutting edge technologies
• Client’s development environment
• Client application architecture, design, tools, etc.
• Client specific domain knowledge


What does it mean?


When you partner with an outsource provider you may need to provide domain training in conjunction with project kickoffs. Some refer to it as knowledge transfer.

In many cases, the client’s team may go offshore to visit the offshore partner, and/or some senior members of the offshore team may need to come onsite to get up to speed. Either way, face to face meetings will facilitate collaboration between both parties. Be aware of the vendor that suggests their offshore team come onsite for months at a time. That suggests they have a lot to learn and there may be another partner out there with more relevant experience.

Back to: 10 Ways to Fail at Outsourcing

Tuesday, March 30, 2010

#8 Fixed Price Contracts and Agile Project Management

A classic way to fail at outsourcing is not so obvious to the client or the vendor, and that is to attempt to fix the price, scope, and time line for a sizable engagement. Yes, fixed bid engagements ARE risky to the client!

The client believes that they are limiting the risk of cost and time overruns by getting a vendor to accept a contract with a specified price, scope, and time line. What they do not recognize is that CHANGE is INEVITABLE. Ultimately as the project progresses clarifications will be made to the requirements. Some will result in additional scope and effort beyond the original contract. To then engage in submitting change orders is standard procedure. However, the effort to identify the change and the subsequent negotiations to accept or reject the change can ultimately bog down the team and cause friction between the internal and vendor teams.

If you recall the last 20-30 years of software development with Waterfall lifecycles, a great deal of effort was put into identifying and documenting all the possible requirements. Sometimes, Business Analyst teams would spend 6-9 months documenting every last detail. Then, they would pass the requirements to various vendors for a bid. Eventually the client would choose a vendor that seemed to understand, had the most relevant experience, and would be willing to drop its price to match the lowest bidder, even if the lowest bidder was eliminated for other reasons.

Typically, at this early stage of software product understanding, the 2 parties would come to a contractual agreement, fixed price, fixed (perceived) scope, and fixed deadlines for finishing. The process for dealing with change, if dealt with at all, was identified as a change order process.

And the results are in on this style of contractual and project management.

70% of software development projects FAILED.

This is part of the reasons why Agile project management came into being.


So, particularly with Software-as-a-Service (SaaS) product development where early feedback from customers and investors is critical, smaller, adjustable scope engagements are much more appropriate.

Most companies that would consider outsourcing have a hard time trusting their new potential partners, probably with good reason.

So how do you create the right contractual agreement to match a flexible project management style?

The answer appears to be a little bit of everything. Allow for a fixed bid starter engagement that allows the foundations of the relationship to be set. 4-6 weeks seems about right, but it will probably depend on the size and duration of typical engagements in your field. Then, as both parties are comfortable with each other, a flexible scope, target cost agreement can be worked out. Imagine here a dedicated Agile development team with a fixed monthly cost and some performance objectives.

The following resources are very helpful for understanding the conflict between fixed bid and Agile project management.

Selling Agile: Target-Cost Contracts
How To Sell Agile To Fixed Bid Contract Clients
Agile Contracts - Lean Software Development

Back to: 10 Ways to Fail at Outsourcing