In software outsourcing not every thing is as it seems…
Magicians are a wonder to watch; even when you know what they are doing. Perhaps the most impressive thing is how easy they make it look. The reason it looks easy is they have practiced;they made all the mistakes before they got it right. You just don’t get to see the mistake, if you are lucky.
Magicians make magic appear so easy. Competent outsourcing partners make outsourcing seem easy. So easy, in fact, you may even want to give it a try. Just like trying to do magic, it doesn’t take long to figure out it is easy only when you know what you are doing.
In many ways outsourcing success is easy!
Though when experienced partners team up it’s magic! But outsourcing can rapidly turn to a comedy of errors when inexperienced partners try it and rely on flawed assumptions. Herein this document are some of the myths of successful outsourcing. These myths, mistakes and the universe of outsourcing magic are explored in a world deeply rooted in hard fact reality.
Mostly the myths will seem like common sense, yet it is not the logic or belief that make them myths. Rather it is how people act and conduct business which makes them so. These common actions people take conflict with logic. The conflict between action and logic is what creates these myths.
Myth: All culture problems arise geopolitically or regionally.
Picking an outsourcing partner need not be complicated. For success it is best to not to consider national culture but clarity in communication. Though regional or national culture is important and discussed further on in this article it is NOT the most significant cultural issue.The myth of national culture is often articulated in things like “The QRS people are good programmers.” Yet, reality is: the greatest impact on success or failure is the culture of language, the culture of personalities and corporate culture. Perhaps corporate culture being the most important. To make sense of the impact of corporate culture in picking an outsourcing partner it may help by first comparing how you pick a personal service provider.
Consider for a moment how you found your dentist or doctor. You probably asked family, friends or coworkers for a referral. And how did you find your auto mechanic? Did you also ask your friends; perhaps your neighbors? This is a simple method isn’t it? It is easy but it doesn’t guarantee that you will be happy with their choice. It only improves the probability for success.
Why not? Because there are personalities and styles involved almost every business transaction, both as a buyer and a vendor.
Perhaps the least considered element of software outsourcing is compatibility of corporate cultures. Sure we call it “culture” but it really is personalities or styles. Individuals and corporations both have definitive personalities. Some companies focus on the bottom line, others focus on the employees while others still focus on their clients. Some are service oriented others are… “on hold forever” when you call. Compatible cultures refers not just to the quality of the product produced, or the level of expectation but the combination of product, communication (dialog) and the overarching relationship.
“What does this have to do with outsourcing?” You ask.
The answer is: “Everything.” Culture is the woof and weave of the fabric of successful outsourcing. What makes for a successful partnership on a personal level and a corporate or business level is an understanding and acceptance of the other partner’s way of doing things. If you take the fundamental premise that your partner is there to help you reach your objectives shouldn’t you find someone who is of similar mind set with similar values? Surely you would agree. But how do you do that?
Myth: I want a partner.
Most often when we consider language in outsourcing we often think of English Vs. Indian,English Vs. Russian or English Vs. Xyz. Reality however is a different thing; communications,or lack thereof, actually it comes down to English Vs. English. Almost every time it renders to the question of what do words actually mean in English? Confusion often comes into outsourcing with terms like “partnership” or “easy project”.
We do a good job, so with great frequency people and companies ask to have us do outsourcing as their partner. Sometimes it is VERY successful and others it begins with a red flag warning. For example when someone says “We are looking for a partner who will share our success” we immediately ask for their definition of partner.
Often ‘partnership’ means they want their partner to be a Venture Capital partner.They want their partner to deliver at or below our development cost in exchange for future profits.Business opportunity overtures are usually accompanied with terms like “easy project”, “clone of ABC.?OM… But with these changes” or “shared profit”. Partnership is a wonderful catch phrase. And we, like all vendors, look for long term relationships which will extend beyond the initial offering.The problem arises when a partnership offering is one sided and not clearly defined.
What really does partnership mean to you? Does it mean your outsourcing vendor is a virtual CIO? Does it have a budget? Or is it simply a vehicle to deliver code on time? Is your development partner really a partner or just an employee? How much of a role do you expect them to play? This may seem a judgment about what kind of a relationship works but it is not. It is a statement; Outsourcing software development works best when the relationship is defined before it begins and the roles are not switched after coding begins.Problems arise when clients say one thing and mean another.
Actually, what most people mean when they say “partner” is they want a reliable vendor.
Myth: “Yes” means: “Yes!”
Regional customs and culture do have an effect on the success of an outsourcing project. Again, most often regional issues have to do with understanding the imprecise nature of English as much as they are regional. But regional issues should not be discounted. Even within the US there are regional variations. Beware however, in certain countries the word “Yes.” Doesn’t necessarily mean “Yes, I agree” or “Yes we will deliver on time.”
Be advised to check culture and usage; ask your partner what things mean. Remember it is your money; It is your project, therefore it is your responsibility to communicate clearly.
Myth: Partnership means Venture Capitalist.
Software developers, like ourselves, are bombarded daily with great ideas and even more not so great ideas. People ask vendors to be partners to develop clones of successful sites. They come to us when they have no, or little money, no business plan, no understanding of the project requirements, no understanding of what it will take to bring their project to market, no software specifications, no revenue projections and no contract. Many prospects will explain there is an opportunity to make millions and millions of dollars. Inevitably these prospects will promise to reward us with obscene riches if only we will do all the work for free, or close to it, and provide business guidance, and marketing guidance. They want us to do this gratis so long as it doesn’t conflict with their view of themselves as the “Gods of new ideas.” No feedback or input is allowed except for “It’s the greatest idea in the heavens.”
Software developers are just that software developers,and though the quality of work product may vary from one to another the role remains predominantly to produce functioning code.
Partnership isn’t of itself a taboo word. In fact it is a beautiful thing when it works.
Myth: Partnership may be magic and even seem like alchemy, but it is best when it includes a large dose of mind reading!
Prospective clients actually say things like “I want my site to go BAM!” Or maybe they are more subtle – “I can’t explain what I want but – I will know when I see it!” “We want a clone of ABCD.com, except…”
Herein are the pieces of myth (excuses):
- You don’t know how to articulate so you use vague terms.
- You don’t want to provide project detail because you are lazy. (Oh, sorry, the Politically correct term: you are too busy)
- The partner is smarter than you and can figure it out what you want.
We are not in high school; We are however, in business. We earn our living writing quality code not mind reading. But we know the excuses and the language of failure lie resident and disguised in generalities and incomplete thoughts – what happens is this: If, and this is a very big “IF”, your partner has the knowledge, business acumen and skill to ask, they will ask you the questions you should have asked yourself in order to complete the detail.
This is where the myth conflicts with reality:when you don’t provide the detail you will pay for both the development of the questionnaire and the development of the software. (THE COST GOES UP WHEN YOU DON’T DO YOUR HOMEWORK.)
Bad partnering more often results when the definition stage is incomplete or skipped. Without a clearly defined goal or specifications it is closer to mind reading than it is code writing.
Mind reading usually concludes with the client and vendor entering the Twilight Zone of outsourcing. It is therefore best to avoid mind reading whenever possible.
Myth: All proposals are created equal.
When prospects arrive with vague specifications for their project(I want a clone of…) The vendor has two choices in responding.
- First they can bid an inclusive package price.
- Second, they can bid an la carte price.
In the first case the proposal is based upon the business strategy it is best to bid accurately from a full set of specs, failing that it is appropriate to bid worst case. Here the assumption is the client wants everything. This gives some wiggle room to deliver in the event there are surprises or undisclosed requirements. Often when a client has to budget, it is best to have an accurate assessment of cost up front. More importantly, bidding it to a fair expectation of anticipated requirements, cost and delivery provides both the vendor and client an accurate expectation. The vendor is able to guarantee the delivery schedule while allowing for some minor variations without upsetting good relations with the client.
The second case scenario employs a different strategy. Vendors will bid low intentionally with the knowledge that the price will rise as the client adds all the requisite features. Cost overruns and delays are expected with this strategy as the vendor and client hash out the detail. The post contract overruns is expected by the vendor even if not known by the client. The detail will be worked out over the most obvious things: “Oh you want management reports? You didn’t say you wanted reports, they weren’t in the specs that will be extra. Etc. Etc.”
All proposals are NOT the same. There is a definitive and measurable cost to success.The cost to fail is often higher especially after you factor in emotional capital, delays, frustration and the total dollars spent. The point is you usually will pay for success either way whether you get it or not.
Though every client wants to get the very best deal they can they forget it is in their best interest to have the vendor be profitable. The vendor needs to be in business a) to complete the project and b) later to do upgrades and additional work.
In proposal review it is the responsibility of the client to know which pricing schema the vendor is using and whether that schema is the best for them.
Myth: All coders are created equal
Many prospects wrestle with this myth in odd ways. It appears to be rooted in the false logic and fundamental misbelief which often manifests in one of two thought processes:
1. “All programs are equal. So being equal, it would make sense without a justification I understand, to go with the low bidder”.
2. “All programs are not equal. So, it would make sense that the highest cost would equate to better quality, therefore I should go with the high bidder”.
Neither of the above is an accurate representation, but still, sometimes we all get lucky. Knowing that there are differences, most people don’t understand the return on investment (ROI) of software. The value in software and its ROI are related to the purpose and function of the software.
The myth is really all about understanding value. Software is a tool, and all tools have an underlying principal of value. To make sense of the value of tools lets look at car tires.
You pay for quality whether you get it or not.
What are some of the hidden costs? Well, if you have a website delivery system which is slow, potential clients may leave if the process is cumbersome. You may need to add staff to do all the work because they are waiting for the program to respond. It may crash or not be portable to newer versions of the OS or need re compilation when the capacity is exceeded. There are many considerations which make software ROI good or bad.
Now, if all coders are not equal, wouldn’t it make sense to check to see if they have done similar work? Well yes, but this question leads to another myth.
Myth: Similar work for other clients will guarantee our project.
Why is this a myth? Because looking at other sites or sample projects will not tell you the whole story. This is not to suggest you avoid looking at vendors other work as a benchmark, but you need to talk to the vendor’s clients. Try to ferret out if the clients have the same set of values as you, do they use English the way you do? Ask them what worked best, what they could have changed. Ask about the relationship, because your project is different then theirs, but how they interact in the(here is that word again) partnership which is what you need to understand. Check references for the technology and expertise but always speak with people on the relationship.
Here is a useful rule of thumb to understand how to find the appropriate partner for you:The best of a profession will congregate together naturally. The best programmers will congregate together because of the challenges. The best in any field enjoy the challenges of leading their industry.This will manifest itself in a few ways. A firm with a high turnover is a clue to a management problem. Ask about turnover. Over 10% turnover is a warning sign. It means that in 2 years you could see anywhere above 20% of the original development team gone. Anything over 10% turnover is a red flag.
Your partner needs certifications such as Brainbench, Microsoft and Sun.These will tell you something about the quality of their code, though you should check to be sure they actually have certifications. You really want to know is what percentage of the team is certified.
But be advised, many inept programmers have been certified, and many skilled ones never bothered to get tested. Certification is not a requirement but “icing on the cake”. To be sure there is good cake below the icing, ask for resumes, look at sample code, talk to their clients, etc. This will give you an understanding of their ability, but once you have identified qualified candidates it is the way they do business and communicate which will make or break a project.
Myth: Our software engineers are standing by!
Imagine people starting a project like building the software application of their dreams. It’s just like building a house, and for whatever reason – some one gets ill, funding or shifting priorities stalls the project. Clients will return believing that even after a month of non communications the development team will be instantly plugged in and work resumed.
Software engineers are not stored in vending machines.
Look for a “client centric” company who will take their promise to deliver quite seriously. Robbing Peter’s staff to work on Paul’s project doesn’t do either Peter or Paul any good.
Myth: Coders are interchangeable parts.
Occasionally clients act like their coders are machines forgetting that though in another country their coders might be well educated and highly civilized. Everyone wants the very best. All will express this during the selection stages. But after selection some clients will demand instant response from their vendor. Perhaps it is because they don’t have a personal relationship with their vendor. It is easy to forget they are people and to see them as “Coder Man” by day …”Super Coder Man” by night. But all joking aside a good vendor relationship will be built on strong communications channels and personal interaction.
Not withstanding any companies commitment, even the best are not available 24/7/365.
To appreciate this myth in the client vendor relationship is to understand how you treat your local staff. Isn’t your “partner” just an extension of your staff? Your partner is comprised of people! Some are married and all have personal lives, just like you. Though most coders are very logical people some may not be the most diplomatic, but it is true the higher the education a person has, the more civilized. You should treat them with the same respect you would if they were in the next cube.
Coders are fully aware there are rush requirements from time to time, and moments of client panic. Many will take personal pride and accommodate these “emergencies.” However it is essential in order to elicit their cooperation, you treat them as humans and express that message in your communications with them. For example we had one client who sent a cashier’s check to his program manager (PM) because the PM had come in over a couple weekends to help get the client’s application up and running. As this was a revenue generating application the client showed appreciation appropriately. Coders will bend the rules when they are treated with respect and will be inflexible when treated like an interchangeable part.Who can blame them?
If you treat your coders special you will likely get something special.
Myth: The contract is absolute.
Most first time entrants outsourcing can be expected to make a number of assumptions regarding contracts. The first is that an abusive Non Disclosure Agreement (NDA) or Non Compete Agreement (NCA) will protect them.
We have reviewed contracts which, if we were to sign, would require us from developing any “similar” project for 10 years. Some want us to give them any code we develop for other companies as part of our agreement or tell them about other projects we have done or will do during the designated period. Generally speaking, these contracts are drafted by lawyers who don’t understand business; they understand law. We don’t sign agreements with this kind of abusive terms. What are the differences and what makes a good or bad contract?
- Consider a partner who has the requisite skills to do your project likely learned on some similar projects in order to qualify to work on yours. This goes to qualifications and would be absurd for them to give up all future work to contract to you.
- Consider that your partner earns their living writing code not competing with you or stealing someone else’s code and giving it to you. Should they offer you should run!
- Consider that in order to develop your application quickly and effectively they need to rely on libraries of macros. These macros will lie in many applications some similar some not.
- Consider that your partner is in another country and if your NDA or contract is abusive it won’t even be enforceable in the US much less than enforceable in another country. And if it were enforceable would you have the resources to enforce it?
- Consider that if you spend the time finding a reliable partner – a trustworthy partner – a simple 2 or 3 year NDA is adequate, if for no other reason as the technology will make most any program obsolete in 4 years. Furthermore the expiration period usually begins on the termination of work.
Thus a long term working relationship could extend any NDA forever.
One thing which makes a relationship work is knowing a contract is that it is only a framework for the relationship not the relationship itself.
Myth: All software belongs to me. (He who pays — owns everything.)
This myth goes hand in hand with the myth: the contract is absolute.
A bit of legalese here… Authorship in software is defined in the way the source code is expressed and the look and feel of screen shots. This authorship is protectable as a copyright.If an employee creates software,then the copyrights are automatically owned by the employer as a work made for hire. When source code is created by an independent contractor, then the independent contractor owns the copyright, unless properly assigned or otherwise transferred in a written agreement between the developer and the independent contractor. That transfer should be spelled out.
Use of open source applications and applets that may be embedded into a program by a careless developer or an independent contractor may negatively impact the rights of the developer or the owner.
The problem of what is owned by who might seem easily remedied with a restrictive contract or NDA. But that would return us to “the contract is absolute” myth. Actually it is helpful to understand you may own the finished product, and the employed macros and tools used in the development may be owned by another or live in libraries where they are reused. This is particularly true when you ask someone to employ their libraries and tools in order that they may expedite the development of your product.
Please be careful, but more importantly, be reasonable and check with your attorney.
Myth: You can control costs by tightly managing.
This myth is again prevalent in neophytes to outsourcing software development.The mistake is embodied in actions where the client demands hourly reports. The “What did you do for 5 hours on Friday? That should only have taken 1 hour!” are useless and demoralizing ventures.
The myth is wrong. You simply can’t tightly manage the project if it is resident in someone else’s shop and expect to have a successful relationship. But you can manage the relationship. What does this mean? Perhaps an example will help.
A client came in with a project which was partially developed by another vendor. They had perhaps $50,000 invested in it and, though there were warning signs of danger, we ignored those warnings and agreed to help him finish his project. It was a straightforward hourly billing.
A month into it he wanted weekly reports of everyone’s productivity. He wanted reports on what they worked on and what was accomplished. Then after two months he upped the requirement to daily reports.
The problem is this: clients want the best code possible. Yet many are afraid vendors will unnecessarily pad their bill. The logic is flawed. The best way to explain it is by analogy.When the plumber comes in to fix your pipes you know right upfront that the plumber will buy his parts at wholesale and charge retail plus a markup for that service. It comes with the territory. You know the markup on a small fitting will be a higher percentage than on a water heater. Do you believe it is important for him to do a good job than a cheap job? Logical reasoning is simple: do you want your plumber back again to re do their work? If you pay the price for a qualified plumber and he does a good job it should be OK for him to make a couple dollars profit off the parts.
Conclusion
The magic in successful software development outsourcing is relatively simple:
- Communicate with your outsourcing vendor (partner) regularly.
- Communicate with your outsourcing vendor clearly.
- Treat your outsourcing vendor with the respect you would if they were in the next room.
- Make sure you both agree on the scope of relationship before you begin.
- Make sure you both agree on the scope of work before you begin.
- If the relationship doesn’t work leave it with dignity not a fight.This extends past the current relationship, meaning don’t punish your new vendor for mistakes made by the previous vendor. Rather find the right one and be a good partner and always pay your bills on time.
From a vendor’s side – we may not always want to admit it – the reality is outsourcing software development arena is much like baseball arena. At any given time there are only a handful of “pro teams”. There are more AAA players than proplayers, more AA then AAA and more A players than any of the others. Though Enterra is a proteam,we are not the only one.We know that not every client should team with every vendor.
From a client side – they may not always admit it – the reality is they may not always want to pay the price for a pro game, they may find AAA or AA more exciting in a smaller stadium.
There are many opportunities to succeed and many more to fail.Picking your team should be done intellectually but if your gut says “no,” you should consider listening. And don’t let greed be the decision maker. If it looks too good to be true it usually is.
Knowing what you want and articulating it will help you past the myths and traps. But unquestionably, the most important rule for successful partnering is to understand the software vendor can be an asset. And like all HR assets you should treat them as you would want to be treated.
Do you like the article and want us to develop your project? Feel free to contact us here!
This entry was posted on Monday, December 29th, 2008 at 11:10 am and is filed under Outsourcing.
