As I’ve written before (“Offshore development: target the destination, even if you never go there“), the reality of the CTO/CIO’s life is to be constantly challenged to produce more. Most technology executives, given that challenge, focus on squeezing out greater efficiency from existing processes, which is of course a necessary and constant push. What many don’t do is recognize the importance of crisp, formal handoffs of software from stage to stage, and how those can greatly enhance productivity.
Software engineering lessons over the past decades have taught us that software architectural techniques such as encapsulation, data hiding, and well-defined module interfaces are essential practices as systems scale ever larger. Equally, the human side of software delivery needs those sorts of crisp interfaces and neutral handoffs: loose coupling, in other words. Loose coupling entails “minimal assumptions between the sending and receiving parties.” And an increased focus on internal efficiencies (plus deadlines and pressure) can sometimes lead a shop away from that, and into tightly coupled handoffs, because those seem faster and easier. You don’t have the time to do it right, so you end up using a lot of time doing it over. My argument is that (just as it is with object-oriented architectures) it’s worth slightly less efficiency-in-the-small, if certain sacrifices in the hand-off arena can help you attain efficiency-in-the-large.
As I wrote in my previous post, referring to the constant business-driven pressure to “put eight pounds of manure into a five pound bag” when it comes to delivering technology projects,
The main insight here is that finding a viable way to outsource some projects is your ticket to expanding the bag. I’m not even talking about offshoring here, simply about being able to take a chunk of your project load and hand it to an outside entity to get done. If everything could be done that way, then you’d be constrained in your project load only by available money. Sadly, in many shops, almost nothing can be done that way, due to too much interdependency of systems, too much background lore required, and no processes in place to allow for external entities delivering changes into current production environments. My position here is that it’s a key part of your job to change that situation: to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively.
Let me focus in this post on the important role that outside help can and should play in your development portfolio. Specifically, I recommend that you find several (I suggest three to five) vendors who can take on well-defined development projects and deliver them relatively independently of your current core development staff. Pay no attention to the natural sales technique that each vendor will use (e.g., “we want to be your sole provider”), because that’s principally in their interest, not yours. Each vendor will have different skill sets, different availability, even slightly different approaches. Not to mention pricing: when a provider knows that they won’t win every job, by definition, that keeps everyone on their toes in terms of both maximizing quality and minimizing the cost of delivery.
Here are a few key aspects to strive for when embarking on this sort of selective outsourcing:
- Make sure the vendor can and will work within the software delivery approaches that you’ve carefully established. You’ll find that a lot of independent vendors actually aren’t accustomed to the idea of formal handoffs and loose coupling. Educate them, and move forward with the ones who get it.
- Work closely with your company’s legal department to understand clearly what data you can hand off to external entities, and what protection mechanisms need to be in place.
- Design (or redesign) all of your development processes so that it will be relatively painless to keep your vendors working with current builds, data, and necessary interfaces into your key systems. Otherwise, you’ll face a nightmare of integration testing once they deliver.
- Don’t tolerate lack of collaboration (i.e., with other vendors, or with your internal staff, which happens more than you probably suspect) or information hiding. Everyone needs to be part of the team, with all behavior above-board.
- Make sure everyone (the vendors and your in-house staff) understands that delivery is defined as full delivery, not just “working code.” That includes acceptance testing (user and operations both), knowledge transfer, agreed-upon documentation, test scripts, everything.
- Do recognize that functions “down the road” (QA, operations) will be impacted (resource and schedule-wise) almost as much by an outsourced project as by an in-sourced one. Nothing comes for free, and this is often forgotten.
- Make sure that your internal team understands the strategy here. You don’t want to have jealousies or insecurities pop up, simply because not all projects are being done internally.
Most of all, the key lesson I’ve learned from working with outside vendors has to be the notion of putting multiple arrows into the quiver: in other words, actively seeking out and using more than one vendor for the portfolio of outsourced projects. Not only does that make sense from a negotiation and pricing point of view, it pushes and tests everyone to make the hand-offs as well-defined (i.e., not individual-specific) as possible. And that benefits everyone.
