Thursday, February 11, 2010

Great Expectations

These days it is difficult to ignore the benefits of offshore development. The potential cost reduction's beneficial effect on a company's profit margin warrants investigation. I am sure a lot of readers are thinking that this is old news, yet I feel that there is significant room for innovation in this model that will make it even more attractive to those who have not tapped these resources for whatever reason.

My experience is mainly with companies based in India. Over the years I have had varied success but on the whole it has been positive. Keep that in mind, because the sheer volume of teams vying for your business is more than overwhelming. They are persistent and tireless in pursuit of your projects and as you would guess, many make promises that they cannot keep. The important part is to have a plan and go into the endeavor with realistic expectations. “Too good to be true” is a sound rule here.

Some ways that you can raise your chances for success with your software project is to use the commonsense methodologies that you would use in any other instance where you are evaluating an unknown.

The first thing to do is to be specific about what you want. If you have technological constraints be clear in your solicitation that you only want to hear from companies that have significant and relevant experience. If you haven't decided on technology (say Ruby on Google App Engine vs. .NET on Azure) ask for a company that has done project work closely related to the functionality that you wish to develop/enhance. If you know both of these, ask to only hear from those that fit the bill in totality. Remember, there are so many offshore development shops that you have a very good chance of finding more than a few that will meet both criteria.

After you have found a few companies to consider, ask for pricing. This varies widely. There are larger (less risky) shops that charge more. You'll find a that with the more established company the benefit to you is the savings on infrastructure and employee services. These shops usually not only charge significantly higher rates, but they have team size quotas and require deep contractual agreements. The smaller companies usually provide the best deal financially, but you have to be on your game in the evaluation period.

When you have boiled down the competition then it is time to do exactly what you would expect, ask for demos of their work that directly relates to the functionality that you wish to build. And then ask for the contact information. Speak to the client that they built it for. Not only must your potential resource be technically apt, but they must be manageable and accountable. Ask the reference your operational questions. They must be able to produce “local” references. I have found that these references are usually very forthcoming in their critiques.

Now it is time to work on you. What do you expect?

From my experience I expect that I can enhance my chances for success by implementing a model where my trusted local team provides detailed technical documentation and that we schedule the resources ourselves. The more specific we can be about not only the look and feel, but how to implement technically the better the results. This model necessitates a local architect. However, if you were to go the 100% offshore resource model, then I would ask you to be sure to continue to provide impeccable functional specifications (painfully detailed) and insist on technical documentation back that could win a Pulitzer Prize.

This is a lot of commonsense advice. The benefit to hearing it though is that it may help to counteract the many sales pitches that a newcomer to off shoring will receive. You may be promised the world at an unbelievably low price, but to take it at face value may put you in a situation where you are disappointed and your effort is endangered. While I have provided some of the steps that will help you create a successful relationship, nothing replaces experience. Working with someone that has gone through this process before will help ensure your expectations. Not only does an experienced offshore manager enable the day-to-day, but they better understand the culture and can provide valuable contacts with trustworthy sources.

So good luck with your team setup. I am always excited about global resources and the technology that enables us to benefit our bottom line while enhancing someone else's standard of living.

Best wishes,

Brian

Monday, February 1, 2010

What's your group mindset?

I've been reading Mindset by Carol Dweck, Ph.D. This is her take on the psychology of success. It deals with what she calls a “fixed mindset” and a “growth mindset”. A major theme in this book is that those of us who have the growth mindset embrace challenges (and even failures) as an exciting way to learn. She explains that people who believe that they have the capacity to become more intelligent look for ways to learn new things and therefore DO become smarter. On the reverse side of this coin are those who live with a fixed mindset. Here she believes live the people who have bought into the belief that your IQ is static. They spend a lot of energy proving their worth time and again attempting to seem smart and avoiding situations where they are challenged. After reading through a good portion of this, I began to reflect back on how this applies in a startup technology company. Can an organization have a collective mindset? I say yes.

Going into a startup technology endeavor (I'll say software because that is what I do) a battle scarred vet is going to know that no matter how well the upfront planning was done, unexpected challenges loom around many corners waiting to derail even the best efforts. Now, top-notch technical specifications is one of the ways to reduce the risk and therefore the impact of these “unknowns”, but there will still be some and how the team deals responds to them builds the development culture.

Applying Dweck's theory it is plain to see that the group has the choice to view the challenges as a way to learn or as another roadblock on their way to success. What example will the team lead set? Here is my hope: that early on the manager rubs his/her hands together and says“ahhh, here is an opportunity for us to increase our knowledge base, gauge the amount of time necessary for unknowns, and prove our expertise as a team”. What I mean here is a) solve a problem once and it is solved forever if a short article up on the team wiki b) time how long it takes to resolve the issue and use that factor in development estimates going forward (keep revising this as the team gets better at it). Here is a wonderful metric for evaluating the team. c) Show off! It is a good feather in the group's cap that they were hit with undocumented technical challenges and only took x amount of time to overcome them. This approach/attitude is one of the building blocks to creating an exciting team that thrives in the often unknown technical environment of a startup.

For brevity's sake, I presented just the positive side of the argument. I think we can all see what kind of group is built with a fixed mindset. I am encouraged to reinvigorate my own attitude this week when the inevitable challenge arises. I think my phrase will be “Oh! Good, this is a cool issue to work on. Who is lucky enough to spend some cycles puzzling on this one?”

Good luck,

Brian