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 :
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 :
- Be able to carry on an intelligent conversation with you and add value to any functionality discussions
- Know the codebase well enough to answer detailed questions from your technical team
- Have on the tip of their fingertips, detailed tasking data for each team member
- Be available (their) waking hours with less than 1 hour notice
Posts
No comments:
Post a Comment