Friday, May 21, 2010
Filling the Skill Gaps: Contracting, Outsourcing and Off Shoring
Well, you’re going to need to augment your work force with external resources. Think of the augmentation strategy in terms of layers. At the core, you have your trusted employees as your resident resource. The core team is the base and lever of the project. In the next layer are the in-house contractors. These are resources brought in by a third party companies who work as part of your organization and will be paid on an hourly basis. The strategy is to implement an option-to-hire policy so that, as you bring in the much needed expertise, you can also exercise the option to hire those contractors who prove worthy of becoming part of the inner core.
In yet another outer layer, you have the augmentation resources provided by external companies working on a statement-of-work basis. While this model allows you not to have to deal with the day-to-day management of these third parties, and you will not have visibility to each individual resource contributing to the effort, you should nevertheless be prepared to exercise appropriate ongoing oversight to ensure deliverables are met and that you are not surprised by missed deliverables.
Some like the idea of using outside contracting services on a per hour basis. I don’t recommend this approach. The only exception would be for trusted former employees who for personal reasons have left the company but still wish to continue working, albeit remotely. Otherwise, external per-hour contractors should only be used temporarily to fill specific gaps in expertise, as subject matter experts. Should you face this need, it is best to secure these outside resources on a retainer mode rather than on a per hour basis (how is it possible to oversee the number of hours clocked by someone working remotely, anyway?). Examples of resources best used in this manner are: DBAs, architects, security advisors, and performance engineers.
Finally, some companies prefer to use off-shore resources either via statement-of-work or on a retainer basis. I personally feel that most companies are ill-prepared to directly deal with off-shore resources (cultural and geographic concerns apply). My recommendation is that, if off-shore resources are to be used, that they be managed by a local third party contractor who will take responsibility for the day to day interactions with the off-shore outfit. Even better, it is also now common for the off-shoring company to keep a touch point local presence. Still, off-shore services should only be relied upon for very specific, non-mission critical components that can be developed with a minimum of explicit functional description, and should never, never be used for core, mission-critical deliverables. Valid assignments for off-shore work are: reports, data mappings (ETL), general tools development (diagnosis, test tools, etc.)
You should also adjust the way you augment resources vis-à-vis skill sets and specializations. A development project that has a well qualified team of developers and a few good project managers will perform better than a team composed of many good project managers but very few qualified developers. The prized quality of good project managers is his/her ability to enable the work of the developers and then getting out of the way as much as possible. I have seen enough horrors stories of management trying to fix a project in trouble by adding more and more project managers! As if a sinking ship needs more captains instead of buoyancy! The best project management work I have seen comes from project managers who were hired as outside resources as they tend to focus more on the delivery of the project without having to worry about internal governance disputes.
Likewise, many prefer to engage the services of external consulting firms to design the high level architecture plan. Needless to say, these high end services are usually very expensive. In any case, it’s best when the architecture is developed by an internal team. Nevertheless, I can see the involvement of external consulting powerhouses in helping to refine specific specialized niches in the architecture. External consulting firms are also often used to “audit” a given architecture or project implementation, but my feeling is that they are usually used in this function when a project is already in trouble or, frankly, when executive management feels the need for external validation of the project. In all fairness, this validation may not be indicative of lack of trust of you or your team, but simply a necessary CYA to better defend the project to the board or to regulatory entities.
In any case, the architecture team should definitely be part of your core team; not augmented with external resources. You still need to have a dedicated architecture team to lead the technology side of the project since the expensive, high level consultants will probably be long gone once the project begins to get intense. The architecture team should be in place to develop the common framework modules; perform R&D on new components, and in general serve as an enabler to the programming community at large. They should establish the desired architecture by example, and they should also be able to establish governance whereby line programming staff has the opportunity to voice their views and preferences in influencing the architecture direction. As discussed earlier, the architecture team will have a number of roles, from defining architecture to enforcing it. Keep in mind the key dictum that the architecture team should also do programming. If you create an architecture team whose only responsibility is to create architecture, they are bound to become like the gods of Mount Olympus handing down un-implementable architecture specifications to the mere mortals in programming.
Finally, nothing will ensure the success of your project more than a strong group of developers, even if this means you will have to sacrifice the size of the team in order to achieve a higher degree of quality. Measuring the performance of a group of experienced programmers has shown that the difference between the best and the worst performance averaged a factor of 10 to 1. Think about it: a good programmer is on average ten times more productive than a lousy one!
Getting great programmers is, of course, never easy. If you identify great development resources to augment your team, try to bring them onboard in any capacity you can. Beware of the prima-donnas (the best programmers are often the ones that brag the least). They can be contractors or consultants or, if possible, you should hire them. You should be prepared to pay better than market salaries and entice them to join your effort in light of its exciting challenges. Good programmers go for the thrill of the challenge even more than they go for the salary.
There are some who say that IT departments in your average Fortune-500 company can’t aspire to the recruitment of top development talent. The allegation is that good developers prefer the smart, entrepreneur, technology-led start-ups over those big boring corporations. I’m not sure that I subscribe to this view. Granted, many of the brightest want to make their fortune quickly and so head for the cool and sexy frontiers of new development. However, cool and sexy can also be an attribute of a transformation technology project, and I do believe that a well-formed and well-led technology transformation project will appeal to many a talented programmer.