ThinkingStreet.com

Why Consider Outsourcing?

All software companies and corporate IT departments are faced with the challenge of increased demands to produce quality software faster. At the same time, they are pressured to reduce costs, either to become more competitive, or because of budget reductions. In short, everyone wants to do more with less. And most of these organizations consider outsourcing as a means to increase their capacity while reducing overall costs.

Those companies that decide to outsource some of their software development must determine how much work to outsource,

who to outsource with, and how to adapt their processes to meet the new-to-them challenges of managing geographically distributed teams.

 

This article focuses only on the different team structures and communication methods. We also limit the analysis to teams that utilize outsourcing to teams that are in a significantly different time zone. This temporal distribution has a greater affect on communication that geographic disbursement.

Process Overview

There are many ways to structure your development process, but they all share a common description at a high level.

Steps in a software development process

1. Someone identifies market opportunities and captures the results.
2. Someone determines which of those opportunities should be addressed in software and creates captures the results of that analysis.
3. Someone designs a software solution based upon those software requirements.
4. Someone implements a software solution (writes code & tests) that realizes the documented design.

Diagram from Software Requirements - Process and Roles (Tynerblain)

Given this general process flow can be summarized as:

• Determine what is worth doing
• Decide what to do in software
• Decide how to do it
• Do it

And the challenges of doing it are primarily challenges of communication. Certainly individuals need to be capable of doing the individual jobs, but if people don’t have sufficient skills, then no process will yield success. So we’ll assume that people are good - and they usually are - and address the places where process might get in their way.

The Biggest Challenge for Software Teams

In any process like this, where each step relies on the previous step (implementation requires design, etc), you have to focus on communication. There is a lot of communication in a well-functioning software organization - so a lot can go wrong. This article focuses on the communication of intent.

• Why are we doing what we’re doing?
• What is it that I should be doing?
• How do I know if I’ve done it right?

Each person on the team will ask these questions, and each person will have a different answer. As the following diagram shows, a lead developer / designer will answer “Why?” with “Because it is in the requirements”, while a developer on the team will answer the same question with “Because it is in the design.” The following diagram shows how different members of the team define why, what, and how.

Diagram from Communicating Intent With Implementers (Tynerblain).

Different Outsourcing Models

There are basically four different models for organizing your software development team.

1. Insourcing - all of the team members are in the same time zone.
2. Low-level Outsourcing - only the simplest implementation work is outsourced.
3. High-level Outsourcing - some of the higher value technical work is outsourced.
4. Complete Technical Outsourcing - all technical work is outsourced

We make one simplifying assumption - that technical implementation work involves both testing and development. Some teams will outsource only testing efforts, which is a viable approach. And those teams could outsource their quality assurance efforts in any of the four models above. The same basic ideas apply, and we are consolidating our descriptions - primarily because there are benefits to having the same team responsible for both QA and development of the “same level of work.”

In each of the following diagrams, each area surrounded by a dashed-line border is the responsibility of the person (or people) within that area. All of the maroon arrows represent communication or transfers of responsibility among team members within that area. Maroon arrows represent communication across area boundaries, but still between team members who are co-located.

When areas of responsibility are outsourced, they are drawn with a pale blue background to indicate that the team members are not co-located with other team members. Communicating across these boundaries is drawn with blue arrows - indicating that this communication is across the geographic and temporal boundaries that are created when outsourcing.

All of the diagrams show the flow of information in only one direction. This is only to simplify the diagrams. There are feedback loops throughout the process, and they are important to the success of the teams.

The point to realize is that when communicating across temporal boundaries (from white to blue backgrounds), there is a communication impedance, or lag. A question may sit in someone’s in-box for 12 hours, and then the response takes another 12 hours to get to the questioner. This emphasizes the importance of efficient communication across the temporal boundaries in the process and among team members.

In each model, we identify a key to success that targets the largest additional challenge presented by using this outsourcing model. Every model faces many challenges, which we aren’t listing. The first model, insourcing, does not have a key to success - it is our baseline.

Model 1: Insourcing

Keeping all of the work in house, or in nearby time zones, even when outsourced to third party companies, is considered insourcing.

Communication between members of the team is important, and clear lines of responsibility are drawn.

Model 2: Low-level Outsourcing

The first step most companies take to outsourcing is to send the “boring” or “unchallenging” or “low risk” work to an outside company. This makes a lot of sense, as it allows companies to become familiar with, establish trust in, and develop relationships with the third party service providers.

Most companies stop here, or keep this model for a long time, when they don’t achieve the benefits they expected - or when they partner with the wrong outsourcer, and don’t develop the trust and satisfaction that they need to move to the next model.

The key to success with this model is in execution management. Code reads and test reviews are critical to assuring that everything that is intended in the design (and test design) has been achieved.

The primary communication challenge is in interpretation of the code designs and test designs. When the outsourced developers and QA professionals understand what they need to deliver, they can execute effectively. When they do not, teams will spend excess time in iterative communication (with the temporal impedance) to clarify understanding. When the outsourcers have a validated understanding before they begin implementing code and tests, they will waste less time doing unwarranted work - and will be less likely to overlook important deliverables.

Model 3: High-level Outsourcing

In the third model, additional responsibility - that of design - and more abstract tasks are transitioned to the outsourcing firm. This usually happens after the firm has demonstrated their ability to execute as a low-level outsourcer.

The key to success with this model is the communication from architect-level developers and QA professionals to their counterparts at the outsourcing firm. The senior technical folks within the company are responsible for interpreting the requirements, and assuring that their outsourced peers have the same interpretations.

In the previous model, outsourcing teams submit their code and tests for review. In this model, the review process happens at the design level. The internal technical folks will review the test designs and code designs to assure that they will meet the intent of the requirements. The outsourcing team is responsible for individual implementation elements meeting the needs of their designs.

There will still be validation by the originating company that the implemented tests successfully validate the requirements, and that the implemented code passes those tests. Code reads may also still take place, but for a different reason. Code reads will no longer be focused on “does this meet the design goals?” but will instead ask “is this code maintainable and extensible?”

Model 4: Complete Technical Outsourcing

Some companies will make a strategic decision such as “All technical work will be done in India.” While this was initially a shock in the US IT industry, the model is no different than for many companies in many other industries. Most major appliance manufacturers (dishwashers, air conditioners, etc) have an identical approach. They outsource the manufacturing of all of the components of the appliance, and then assemble them, stick a label on them, and ship them. These appliance companies end up with a focus on marketing and product management, and reduce the height of their footprint in the supply chain.

The key to success with this final model is in having a trusted outsourcing partner and excellent requirements. Communication of the proper interpretation of requirements - both by the quality assurance team and the development team is critical.

Writing good requirements is hard. You have to elicit the correct requirements (and all of the requirements). You have to document them in a way that both stakeholders and implementation teams can understand them. And when outsourcing, you often have to deal with cultural or language barriers - the same words and phrases may not be read with the same meaning that you intended when you wrote them.

There are dozens of articles on writing good requirements at the Tyner Blain blog, but the twelve most important elements of writing good requirements are summarized in a single article: The Big Ten Rules of Writing Requirements . Yes, there are 12 rules, but the article started with 10 and got bigger. This article links to a dozen more articles providing details on each of the following elements of writing requirements well.

1. Writing valuable requirements
2. Writing concise requirements
3. Writing design-free requirements
4. Writing attainable requirements
5. Writing complete requirements
6. Writing consistent requirements
7. Writing unambiguous requirements
8. Writing verifiable requirements
9. Writing atomic requirements
10. Writing passionate requirements
11. Writing correct requirements
12. Writing stylish requirements

Writing good requirements is always important - but it is critically important when you use the complete technical outsourcing model.

What About Agile Processes?

Most companies that are using agile techniques are not outsourcing today. That may change in the future. Fundamentally, the process is very similar, but with much more communication. The impedance that comes from communicating across large gaps in time zones is magnified with agile processes. That isn’t to say it isn’t still worth doing - iterative development processes have many benefits over waterfall processes.

The problem is that agile processes require more skill, more discipline, more communication, and more trust than waterfall projects. Over time, more and more outsourcing partnerships can reach the levels of success and trust needed to operate with agility.

Conclusion

The best process will vary depending on the makeup of the organization, the goals of the business, and the nature of the project. There is no single right answer. But recognize that jumping right to the “higher” models without growing your team and your relationships progressively through the “lower” models is a recipe for disaster.

Start at the lower levels, and as you’re ready, and when you believe it will be valuable, move up to the higher levels. And good luck!

About Author:

Scott has been creating software solutions for clients for ten years. He founded Tyner Blain LLC in early 2005 to focus on helping companies achieve software product success. Scott focuses on product management and business analysis these days, but he’s also been a consultant, developer, program manager, project manager, and managed teams of up to 50 people. He has managed multi-continental teams, and helped define successful processes for outsourcing. His writing at the Tyner Blain blog is repeatedly acknowledged as providing thought leadership in helping teams and companies get better at creating great software.

Views expressed here belong to the author and do not represent those of the ThinkingStreet or the author’s employer.

Trackback URI | Comments RSS