Frequent Deliverables

This builds on an earlier post about 5 things to look for in a Successful Outsourcing Relationship. One of the five most important factors that dictates the success of your outsourced product development is the presence of frequent well defined deliverables.

Almost two decades ago, I had the privilege of teaching contrasting approaches to product development between Japanese and US companies in electronics. The Japanese companies invariably focused on having refined physical prototypes available as the product definition evolved. It allowed the various stakeholders to "touch and feel" the product before deciding on features and progress.

Good outsourced product development has many of the same characteristics. Insist on deliverables that are concrete and representative of final product. Some examples are:

1. Fully functional click-thrus
2. Documentation of business logic, ideally in pseudo-code form
3. Working prototypes of technical risk items
4. Data model with populated sample data
5. Performance numbers
6. Deployed product

These are just some examples, but make sure that they are scheduled frequently, and the ones with the most risk involved (requirements risk, technical risk), happen early in the project. Mix with transparency, and you're protected against partner failure to a large degree.

The Site Visit

This builds on an earlier post about 5 things to look for in a Successful Outsourcing Relationship. One of the most important things to do before you decide to send your work out to an outsourcing provider outside the country is to do a site visit. Let me explain.

My first experience running an outsourcing outfit was in Chennai, India. We had the top floor of a two-story building - there were goats tied up in the lobby of the building, we'd lose power at-least twice a day, and the network was shot - this was when the world was shifting from co-ax. It took me three months to get it all fixed (not the goats though - they belonged to the landlord, so the little goat pellets became an occupational hazard).

Fast forward to India of 2011, much has changed and there are professional outfits in India, but in some companies the culture hasn't changed. There is a lot you can say about how your work will be done based on the working conditions in the company. Some things you may want to find out, silly as they may seem:

1. Is your team working in sweatshop conditions? 
2. What kind of machines do they have?
3. Do they have adequate conference room facilities?
4. Are there adequate whiteboards, markers?
5. How is the work environment?
6. How is the physical security?

If your vendor doesn't care about much of these, lucky if he treats your work any better. So, organize a surprise visit -- call someone you know in the city, or we'd be glad to help if need be.

Why a surprise visit? I was in Technopark, Trivandrum, India visiting one of our partner outfits, when I saw an elephant with a full band outside a building. When I enquired, it appeared that the company in question was welcoming a prospective client. You can imagine how the office looked on the day.

So, before you hand over your hard earned money, give 'em a call and say - "my buddy is in the neighborhood, just 5 minutes away from you. He has a plane to catch in 2 hrs but has kindly agreed to drop in and say hi". If they try to wriggle out, run!

Transparency

This builds on an earlier post about 5 things to look for in a Successful Outsourcing Relationship. One of the five most important factors that dictates the success of your outsourced product development is transparency. Its not an abstract concept, let me explain precisely what it means.

First, a few basics about an "agile" project. Cutting through the fluff, here's what it involves (a great resource to better understand what it takes to have a great dev process is from joelonsoftware) :

1. On a weekly basis, the team (including you) agree on what to shoot for - features and functionality
2. The project lead then breaks this up into tasks -- each task generally not exceeding 8 hours of work - so for a 4 person team, you're looking at about 20 tasks
3. The developers create a spec for each task - not formal, but enough to explain what their approach is
4. They write code
5. There is a daily build setup to run around noon each day, including unit tests
6. There is a smoke test done by the test team for the build (should take no more than 30 mts)
7. There is a deliverable at the end of the week that goes through more rigorous testing

Transparency means:

1. At any time, you should be able to access the code base, see the checkins from each developer (there are plenty of near-free online repositories, we use unfuddle and love it).
2. The project lead should share the task list for the next week with you at the end of every week.
3. You should have access to the spec written by developers for each task - demand that it be done and made available to you.
4. You should have the daily build url. If you're located on the opposite side of the world from your team, thats wonderful - their smoke test issues and broken builds should be fixed at the end of their day, and beginning of yours.
5. You should have access to the bug list - and see that bugs are going through a clean process

This sounds like a lot, but once its setup in a company, its a piece of cake. Demand it.

A Pro-Active Project Lead

This builds on an earlier post about 5 things to look for in a Successful Outsourcing Relationship In my opinion, one of the five most important predictor of success is whether there is a strong player-coach on the ground acting as your Project Lead.

Here are the different configurations that various outfits will propose to you to manage your effort (a) A Project Manager and a Tech Lead (b) A "Senior" resource who will "oversee" your effort (c) A Tech Lead dealing directly with you (d) A hands-on Project Lead who will do part of the work.

(a), (b) and (c) are terrible options if you are trying to develop a product. Here's why:

Approach (a) 
(a) is the option most large outfits will provide you. Unless you have a lot of time on your hands and your schedules are in the order of years, this will drag on. Again, I'm assuming that you're trying to develop a product, not maintain existing enterprise software or add a few features to a mature product. You ask me why? It's common sense when you think about it. The role of a "Project Manager" in most outsourcing outfits is to make sure that the tech guys don't say something stupid to the customer. And they get very good at their jobs in the course of time. Which means that you, the customer, don't get to know about significant risk items till the very last possible minute.

Approach (b)
(b) is an interesting approach. Outfits that make this proposal will usually have one or two very competent folks with a lot of experience - they usually are trying hard to get to be like the big guys, except they have to bid lower. They will blow you away with their knowledge during the pre-sales part of the conversation. The catch is -- they will spend little or no time on a consistent basis on the project.Can't blame 'em -- they're normally responsible for a whole bunch of things in the company -- pre-sales that you just saw, hiring, fire-fighting for larger clients. The "oversight" initially is promised with the best intentions; in reality, its hard for even the best to go through the code and understand issues in a way that serves your purpose.

Approach (c)
(c) is what you get when you hire a team out of a garage. They work great for small well defined "efforts". You want to build a product with this team? I've done it in my past life -- except that the best engineer in my team sat on top of the outsourcing outfit day-after-day, reviewing every task and every line of code. I had to promise to never put him on such a project ever again to keep him on in the company.

Approach (d)
(d) is what you need if you're serious about developing product using a remote team. One of the product companies that I co-founded started with the core team in the US, and outsourcing to a vendor in India. The vendor team was smart, but the lack of leadership within their team coupled with shifting requirements on our part made it chaotic. We wised up, and our team in India now consists of a top-notch engineering lead hired from the US, and a team that he's personally hired and put in place. Our costs have gone down 60% and the quality of our product has improved significantly.

HOW DO YOU TELL IF YOU HAVE A PROJECT LEAD?

These are requirements that you can be upfront about with your vendor, when discussing expectations. The project lead must :

1. Be able to carry on an intelligent conversation with you and add value to any functionality discussions
2. Know the codebase well enough to answer detailed questions from your technical team
3. Have on the tip of their fingertips, detailed tasking data for each team member
4. Be available (their) waking hours with less than 1 hour notice

Be Absolutely Clear about the Expected Outcome

This builds on an earlier post about 5 things to look for in a Successful Outsourcing Relationship In my opinion, the most important predictor of success is whether you (the customer) are absolutely clear about the expected outcome. So you were probably expecting me to expound on how to create a clear functional spec, and about how to scope everything out clearly, and not leave anything to imagination.

Nope. That's not your job as a customer. Your job is to know what you want and be decisive.  Your job is to give clear and prompt feedback when presented with options, and provide clear answers to functional questions. Not just when you kick off an effort, but in the course of executing it. And for god's sake, don't invest too much time in writing detailed specifications -- sounds counter-intuitive -- but I promise I'll explain it in a future blog post.

Sometimes I have friends or friends of friends asking me for help or pointers, and one such request came the other day. The gentleman in question (lets call him "G") is a builder of green housing in Bangalore, and wanted a website that was different and stood out. Our back and forth went like so (I've paraphrased and added color, but haven't taken away from the gist) ..

--------------------------------------------------------------------------------
G> "Need to build a website that stands out from my competitors. Do you know someone who can help me build it?"
Me> "Check out www.templatemonster.com -- any you like there? There are folks that I can point you to that will customize a template anywhere in the range of $200-1000, depending on what you want"
G>"Been through it before, I really need something more unique"
Me>"That could turn expensive -- you're looking at 2-5K"
G>"I know"
Me>"Ok - here's the name and contact info for our partner outfit. They are phenomenal, but just as I told you, expensive"
G>"Thanks! I heard what you told me about expense the first time"
G(a week later)>"These guys are good! I was able to provide them basic directions and they not only got it, but went above and beyond, Thanks!"
--------------------------------------------------------------------------------

I like working with people like G. They know what they want, and why. They ask questions and ask for clarifications, but don't leave you hanging for decisions, or waffle on decisions already made. And many times during a project, especially when developing a product, you run into opportunities or roadblocks -- some require time to think through and reflect, but most can be disposed off quickly if the stakeholder's objectives are clear.

So, when you kick off an outsourcing effort, make sure that you have (a) written down whats important to you in terms of outcome, briefly and clearly, and shared it with your vendor, and (b) make sure that you evaluate, and require your vendor to demonstrate periodically, that you're on course to achieve the outcome you desire.

Five things to look for in an Outsourcing Relationship

Google "Outsourcing to India", you'll likely run into this old article in the CIO magazine. Wait, wait, don't surf away because VERY LITTLE of this applies to you if aren't a Fortune 500 company or thereabouts, and especially if you're trying to get a PRODUCT built. Checklists with 500 variables to cull from 50 vendors? Multi-year deals? CMMI level 5? You must be kidding.

I've been on both sides of this supply-chain, we extensively used providers when I ran my outfit in Atlanta, including elance and guru.com. A stint back in the '90s and since a year ago, I've been on the supply side based in Bangalore. Well, I looked around, and couldn't find anything halfway decent that explains in a nutshell what to look for to find and manage a good partner. No wonder, you find these horror stories that proliferate in blogs…

---------------------------------------------------------------------------------------------------------------------------------
Here's an excerpt
---------------------------------------------------------------------------------------------------------------------------------
Some of the problems we encountered:

• Communication. You will never hear about problems until it is too late. It's a cultural thing. They lose face if they let someone know they don't know what they are doing or that the result is below par. The problem is that there is no way you can manage this and you cannot take actions. You end up with either a dropped project or a bad product. You need to have someone you trust on the ground.
• Infrastructure. Our team was in Mumbai. Many in high tech use Bangalore. The Internet and phone connections were awful and dropped four to five times a day.
• Loyalty. We noticed a dramatic change in resources constantly moving. People were always leaving for another 20% salary increase. It's all about cash and who will give you more.
• Micro Management. If you are to avoid some impact on lack of information sharing about any problem you must micro manage the project. Preferably, you need someone there full time, which we couldn't.
• Cost. Well, it looks cheaper on the surface but caveot emptor. In the end, this cost us more and we were throwing money away. Furthermore, it is not that cheap any longer.
• Quality. In short, we discovered that the code developed in India was either poor or eventually thrown away. Not very well invested time and money.

---------------------------------------------------------------------------------------------------------------------------------

Some of the problems have been mitigated with time -- infrastructure issues to an extent. Some simple checks and balances, however, would have been well worth the above gentleman's time, so here's is my list (sound like motherhood and apple pie, but aren't as obvious as they look on face value, so could use some elaboration that I'll provide in subsequent blog posts).

• Be absolutely positively clear about the expected outcome.
• A proactive project lead on the ground is worth their weight in gold.
• Demand full transparency
• Show up at your vendors offsite or offshore office, or have a friend show up without advance notice
• Chop the project up into well-defined frequent deliverables.

Notice I didn't mention "cost". Nor "expertise". Notice I didn't go anywhere near "size". They all matter, but none of these is likely to get you in deep doodoo as the five things above.