I had lately some discussions about subcontracting with people featuring different points of view. I believe there’s no single universal answer to a question whether to use subcontractors. It all depends on a situation you’re in. When you’re a decision-maker you should always weigh both pros and cons of having a subcontractor in a project -- even in two similar situations, but happening in two different moments of time a result can differ.
Pros
1. Costs. When you have a task for fixed amount of time (no matter if it’s a week or a couple of months) it’s usually cheaper to find someone who’d do the work on contract basis. You don’t need to spend money on recruitment and sometimes it can be really expensive. The shorter or more shattered the work time is the bigger are your savings. When you need few hours of consulting every fortnight, it’s a perfect example. When you don’t know how often you’d need help, it’s probably good case to think about subcontracting.
2. Competence. You can’t specialize in everything. When you work on complex projects it’s likely you have some components to develop in areas where you have little knowledge. If you do it once and don’t plan to have them in your standard portfolio it’s good idea to find competent subcontractor who’d do it for you.
3. Flexibility. The bigger your organization is the less flexible you are. The more projects you do simultaneously the less flexible you are. The more serious commitments you’ve done the less flexible are. It’s because there’s a lot of actual work to do with the highest possible priority, where you can’t fail and it’s hard to find new hands to help. The answer is “subcontractor.” You can find one for whom new task will be the highest priority and he’ll do it be Monday overworking himself during whole weekend. Your team won’t do it. Maybe because during the weekend they struggle to finish another highest-possible-ever priority project. Or maybe because you just don’t want to have overworked the team. With the subcontractor you don’t really care if he’s overworked or not -- he isn’t your employee, so I guess he won’t quit.
4. Access time. It’s faster to subcontract another company than to recruit some new developers. You craft some standard agreement and start working. Recruitment takes more time and you have probably higher standards then for subcontractors. I’d think ten times before taking a primaballerina developer into my development team. I wouldn’t think more than a minute before taking a primaballerina developer as a subcontractor. It’s also tricky when you have a task for a dozen of people. While finding single, competent person in very short time is sometimes possible, I wouldn’t take the task to find a dozen of them unless I have “demigod” title on my card. On the other hand finding a subcontractor with a dozen of competent people in short amount of time isn’t extremely hard.
5. Equipment. You just don’t need it in the case of working with subcontractors. You don’t buy a computer, a desk, a chair; you don’t look for a room or something. You just don’t care about the equipment. Subcontractor cares.
Cons
1. Knowledge outsourced. When you outsourced a task you don’t learn anything about it. You won’t know what issues appear and how to deal with them. You won’t know all tricks and hooks implemented to make it working. You won’t go through documentations, RFCs, news groups’ posts and so on. You won’t learn the technology on the very low level, what gives you real understanding of what is actually done under the hood. It’s OK when you don’t plan doing anything in that specific area. However if you can think about another projects requiring the same knowledge I wouldn’t pay external company to learn something *you* need know.
2. Support level. That’s not true in every situation but is oh, so very common. You subcontracted something and cooperation was cool during design, development and implementation stages. But now it’s a maintenance time. Your subcontractor won’t earn a lot on support agreement, at least not as much to keep the level of financing he had earlier from you. Their motivation to cooperate with you, counted in bucks to earn, is much lower. So is the level of support. And that’s the case if you’re lucky. Sometimes ex-subcontractor doesn’t care any more if you have a problem -- their role ended with having an invoice paid. It’s your customer, not theirs. It’s you who care, not they. You pay forfeits for being late with bug-fixes? Ouch. It’s *you* who has a problem I guess.
3. Quality. There’re many extrinsic factors which improve a quality: tests on different levels, code reviews, statistics, etc. On the other hand I can think of only two important intrinsic factors to keep high quality: will to get things done well (which is a character feature so it’s rather not controllable) and perspective of maintaining the code in a long run. When working with subcontractors you can deliver some extrinsic quality-boosters, but they all vastly increases your own effort to have project completed. On the other hand it’s hard to deliver any intrinsic quality-booster, because you don’t manage subcontractors in a way you do it with your own developers. Unless you find reliable subcontractor I would be really afraid of poor quality of delivered code. Unfortunately, experience suggests that it’s really hard to find reliable subcontractor and vast majority of code produced that way is poor quality. Remember you’ll have to support it.
4. Other contracts. Does your contract with a subcontractor pay her rent? And is it true in the long run? In most cases the answer is negative. She’ll have almost for sure other projects to do. They’ll become more prior to yours. Don’t expect you’ll be treated in a way you treat your biggest customers than.
5. Lack of control and influence. Compare level of control and ability to influence work of your team and some external company which does something for you. You don’t control subcontractors well. You have to trust that anything they say is true. Sure, you can employ a complex system of controlling the work, but it won’t ever work superbly and you’ll spend a lot of time checking other’s work. Wouldn’t be wiser just to do the work?
6. Organizational effort. Preparing and signing an agreement. Double-checking specifications. Checking status on a regular basis. Registering all tasks, features and bugs submitted to do by the subcontractor. Managing formal communication. Losing time for pushing phones and e-mails from the customer to the subcontractor. You don’t need to do most of that when you don’t have the subcontractor. And it’s still easier to find a bunch of good developers than a good project manager, who has to deal with all those subcontracting things.
7. Costs. Yes, I know I mentioned costs on pros side. Subcontracting can be cheaper, but it can be more expensive too. Generally, an hour of work of subcontractor is more expensive than an hour of work of your colleague. You save the money during the time when the subcontractor doesn’t work for you. However, if the task is rather constant and long subcontracting will be probably more expensive. And one more thing -- usually official time and cost estimates are bigger than the reality. With subcontractors you pay for estimates now matter how easy (or how hard) the task was.
When you think about having a subcontractor in a project consider all those factors. Sometimes a single one of them can be a decision-maker -- e.g. when time is crucial and you don’t have enough your own developers it’s quite possible that nothing else matters. The thing, which is the most important here, is that there’s no universal answer. Subcontracting can’t be treated as a cure for all sicknesses, yet sometimes it works well.
Software Project Management is a blog where you can find observations, advices and thoughts about different IT projects - from micro-ISV's applications up to carrier grade solutions. Topics include but are not limited to software project management, software design, software development, team management and general ideas about software business.
沒有留言:
張貼留言