Should I Outsource?

Should I Outsource? The pros and cons of outsourcing are significant, as are the potential gains for companies that are successful. This short video introduces some of the ways outsourcing can be a boon to growth and efficiency, but also points out how important it is to make the right strategic decisions about sourcing.

With outsourcing, we can speed up our operations, lower our costs, and even open up entire new markets. But we don’t want to become one of the nightmare stories you hear about.

Outsource For The Right Reasons

Apple could never have become one of the world’s richest companies if it had not expanded outside the United States. With outsourcing we can automate our business processes, so that we don’t need a large internal staff, or we can turn to China for incredible manufacturing capacity. We can put offices around the world and have 24 hour operations by following the sun. We can even bring on board an entire new department overnight, if we need to.

But, it’s easy to make mistakes. Business culture is very important, and incompatible business culture leads to problems. For example, Audi recently had to recall thousands of cars because their Chinese manufacturer had substituted a substandard material, and gas pedals started snapping off.

It’s important to realize that different cultures and different markets are better suited to particular needs. Cost, quality and skill varies around the world. Technology is strong in China, but intellectual property protection is not. Apple gained huge advances by engaging with Foxconn in China but, 24 hours later, there were clone iPhones popping up on the market.

Multiple cultures bring complexity. And it’s important to remember that America is pretty isolated. Most of the world focuses on building very strong long term relationships. It’s those relationships that protect your business. Trusted relationships are key, and in most of the world, it’s more important to have experience and a trusted relationship than to have a written contract.

Compensating for business culture and communication differences

By far the most common, most glaring misstep U.S. employers make in foreign markets is to assume that people, by and large, act more or less the same in a business setting. It’s a mistake I’ve seen in almost every International project, whether the global team is Russian, Indian, Asian, or South American. Business in a foreign country is not like business at home.

Business culture and communication

In the U.S. we have become very insular, expecting behavior from our workforce that simply doesn’t exist in other cultures. For example, we take for granted that employees will be outspoken and even downright vocal about anything they aren’t happy with. “The squeaky wheel gets the oil,” as the saying goes. But it turns out, that saying doesn’t apply in very many cultures. In fact, the global project manager needs to recognize that in some cultures, speaking out is an anathema, in any setting. This has come up with almost every outsourcing effort I’ve managed throughout Asia: People will seem to contribute extensively or not at all, depending on the culture.

While this looks like a communication issue, it’s actually power distance. Power distance is the degree to which a supervisor and a subordinate are separated by culture and society. Throughout most of the world (especially Asia), power distance is very important. It introduces a formality into the business relationship that doesn’t exist in many Westernized countries.

One strategy to begin overcoming this problem is to initiate collaboration up-front. This can be a particularly effective tool for establishing peer relationships early in the game. While speaking out is not a given, it’s almost universally true that people open up to their peers before opening up to managers (and this is especially true in Asia, where group orientation is predominant). Initiating a project with an on-site collaborative session kickstarts the drive for interactivity. We’ve found that it’s critical to stage the session appropriately. It has to be at one location, the entire team should be present, and the environment should be tailored to create effective, collaborative conversations. Remember, it’s more about building the team than about making real progress on the project.

Successful projects — and therefore successful project management methodologies — recognize that communication is a common point of failure, and put measures in place to compensate. That means taking steps to create strong team communication, and continuing to facilitate collaboration throughout the project, and using methods that encourage rich, complex communication (like frequent, short video calls). It’s very important that the team has the right tools to establish effective communication, so don’t skimp on them.

Training versus development

Mike Myatt, Chief Strategy Officer N2growth, recently posted a very savvy article regarding the difference between training (a typically rote, stale process) and development (more dynamic, needs-based, and effective) in the context of leadership. What I really liked is his point-by-point comparison of the strengths and weakness of training versus development:

  1. Training focuses on the present — Development focuses on the future.
  2. Training focuses on technique — Development focuses on talent.
  3. Training adheres to standards — Development focuses on maximizing potential.
  4. Training focuses on maintenance — Development focuses on growth.
  5. Training focuses on the role — Development focuses on the person.
  6. Training indoctrinates — Development educates.
  7. Training maintains status quo — Development catalyzes innovation.
  8. Training stifles culture — Development enriches culture.
  9. Training encourages compliance — Development emphasizes performance.
  10. Training focuses on efficiency — Development focuses on effectiveness.
  11. Training focuses on problems — Development focuses on solutions.
  12. Training focuses on reporting lines — Development expands influence.
  13. Training is mechanical — Development is intellectual.
  14. Training focuses on the knowns — Development explores the unknowns.
  15. Training is finite — Development is infinite.

I couldn’t agree more. When it comes to leadership development, you can’t “train the leader.” Training on technical, procedural topics is of course highly effective, but leadership requires too much contextual differentiation, too much innovation, and frankly relies much more on innate skills that can only be developed over time, not absorbed from a short training course.

Thinking creatively by taking your ideas to trial

What are some of the best techniques for testing an idea before launching it? One strategy is to put your ideas on trial, literally, testing their validity by leveraging the mindshare of your employees.

This is exactly what Richard D. Fain, chairman and C.E.O. of Royal Caribbean Cruises, did when he wanted to find out whether investing in new computer systems or better company policies was a worthwhile idea. He organized a mock trial consisting of two teams of six people. Each team was given a position to defend, and two months to prepare their arguments for or against the planned upgrade.

“I had heard endlessly beforehand why we needed to do each of the things,” says Fain (New York Times). Fain sat as one of five judges listening to the debate between the teams. He also organized a jury of 40 employees to watch the entire proceeding. In the end, rather than proceed with both projects as originally planned, only one of them was launched. The debate structure provided a powerful forum in which to vet and defend ideas. “All of a sudden, you saw elements that nobody had raised, so you saw weaknesses on both sides,” said Fain.

Putting your ideas on trial is a fantastic exercise to explore and vet an idea’s viability. Perhaps equally important is that it’s also a powerful team building exercise. By creating teams and a mock jury, the entire company takes part in the decision making process. People love to be challenged and show off their capabilities — even when tasked with taking the “opposing counsel” individuals will shine. Since it’s a game, it becomes a way to show off and demonstrate depth of understanding and skill.

Successfully applying lessons learned

In theory, capturing lessons learned at the end of a project sounds like a great idea. Who wouldn’t want to reflect on what was done right, what could be done better, and then apply those lessons to the next project? In practice, though, it is sometimes a different story. It may be a lack of time, resources, interest, or follow-through that causes lessons learned to fall by the wayside. Or, even if they are captured they may not necessarily be implemented. So what makes successful application of lessons learned possible?

Probably the most important factor to me is accessibility. Actually capturing lessons learned is relatively easy (as long as it’s embraced by project and team leadership). Problems, issues, ideas are still fresh in people’s minds so voicing them is not the problem. Management needs to recognize this and embrace the idea that some time needs to be invested in capturing lessons learned — and not just at the end of the project, but throughout its lifecycle. In my experience, this is pretty easy to achieve.

It’s returning to the information and using it in the future where most organizations fail to follow through. 

Having a system in place that makes sure the lessons learned knowledge base is consulted and used in the future is critical. My favorite approach is a well structured, collaborative, wiki-like system. For example, Atlassian’s Confluence has proven great in the past. It offers an open information repository that anyone can contribute to. It’s rich in terms of media integration, and it has version control and sufficient security to ensure that nothing gets lost. 

But most important, the system needs to provide a ready reference library. That means an excellent search capability and well thought out keyword or classification systems. Project managers and leads need to know they can consult the knowledge base, quickly find relevant lessons learned, and apply them to their current project. 

This also means capturing a lot of information. The tool is only useful if it really has a significant knowledge base. Lessons learned need to encompass the positive as well as the negative. Project performance statistics need to be in there. Specific development problems and solutions. Having a cross-reference to your support system or ticketing system is a great idea, because the team can look up generalities and then link directly to hands-on end results from past projects. 

Building the right kind of system is critical. Think about building a reference library. What does it take to feed the library, and what does it take to make it easy to access?

Fix your boss (or, reduce risk to quality using a matrix approach)

How do you ensure that one person doesn’t derail your entire project? Most of us have been there before, unfortunately. Maybe it’s a co-worker who doesn’t work well with the team. Maybe it’s your boss, who has to oversee every single decision even though he’s an overtasked bottleneck. Either problem poses a critical risk to your project: Delays, mistakes and rework because one person isn’t part of a streamlined process.

Probably the most difficult situation is the latter — a boss that’s too hands-on, or perhaps an external resource that is too busy, yet absolutely must approve every decision. The story usually goes something like this: He’s a great guy, pretty easy to get along with when it comes right down to it — but he’s also insufferably “hands-on.” He’s just got to review every critical decision, contributing, fine-tuning and tweaking until it’s just right. This micro-managing mentality is causing all kinds of bottlenecks: Decisions are held until the last moment, changes are made late in the game, and your entire department suffers — staying late to “catch up” after your boss delivers his final word on any given issue. But here’s the real kicker: He’s good at what he does, and even though it creates internal chaos the finished product is that much better for his input.

QS1Consider the image to the right: A critical “quality spike” representing the single project resource that is overloaded. This resource does raise project quality, but the spike also represents a huge bottleneck to the project.

Your department has tried everything: Getting him involved earlier in the game (it doesn’t work, his schedule is booked and it always presses to the last moment); Involving other review sources so your boss’ input is minimized (that helped a bit, but the other sources don’t like it when your boss overrides their contribution); You tried publishing the “departmental cost” figures that show all this inefficiency (but the powers-that-be seem to feel this is “just the cost of doing business”).

This is not a simple problem. It gets right to the root of the dynamics created in working teams. How can the situation be improved, realizing positive gains in a habitually entrenched process that some recognize as painful, but overall is regarded as good enough?

There are really two issues that need to be dealt with here. One is obvious, one perhaps a little bit less so. Most strategies up until now have focused chiefly on the primary goal:

“How can we minimize the negative impact of a critical resource (our ‘hands-on boss,’ for example) that doesn’t work efficiently with your team?”

The problem with this approach is that it attacks an entrenched problem head-on, and often does so using a single head-on approach to solve the problem. When an attempt fails, that approach is discarded and another tried. The principle flaw here is that each attempt to solve the problem is, in and of itself, not effective enough to get the job done. A secondary flaw is that each separate attempt tends to get lost in the chaff of day-to-day operations. We all know there’s a problem, but nobody is really tasked with studying it, compiling the entire scope of the problem and its impact, and somehow bringing about a solution.

For example, when your department produced some figures on costs to the organization, those figures clearly showed that, through inefficiency, rework, and last-minute changes, your team suffered. You even went so far as to tie it to actuals, a dollar figure that represented all that overtime and rework — but, it was accepted as “the cost of doing business.” Since it didn’t work, it was discarded — but the fact is, it’s only part of the overall puzzle.

So the head-on solution won’t work. Let’s consider a more subtle approach to the problem:

“How can we make the critical resource less critical?”

This would achieve the same result, but it’s really an entirely different problem — one that can be attacked somewhat obliquely. Rather than focusing on how to change the way your boss works (aka “the critical resource”), try focusing on changing what your boss needs to work on.

The first step toward a solution is realizing that solving this problem is a project, just like any other. It needs a project lead and sponsor. It needs to be handled as an iterative project, and the team needs to recognize that incremental improvement toward an ideal is acceptable. You aren’t going to discover a single silver bullet that solves the whole problem — that’s just not the nature of human team dynamics.

Make it a project initiative

Once your “quality improvement project” is up and running it will snowball. Here are a few steps that will get the ball rolling:

  1. Initiate the project. Don’t think of this as a “workplace problem” that needs to be fixed in the short term. Instead, create a project initiative around it and get some mindshare going. Someone is going to need to lead the project, even if it’s unofficial — that person will keep the forward momentum.
  2. Focus on making many small improvements across the board. For example, in the case I described above, consider how involving other review sources did in fact help, but not always. That’s an incremental improvement, and it raised the quality of the project a little bit.

QS2Now, consider the impact of this approach over time. If numerous improvements can be implemented, and each one raises project quality just a little bit, it has an inevitable outcome: Your boss is going to have less to worry about, and less to be involved in. This is shown visually in the second image — as the overall quality matrix delivers improvement across the project, the “critical spike” that represents your boss’ workload begins to shrink. This is a quality matrix at work.

The goal is simply this: Dilute the need for your boss to be involved in every decision, by raising the bar in as many places as possible. You will gain a “double whammy” by not only reducing the amount of work he needs to contribute to, but also by increasing his own efficiency since he’ll have less to worry about. The bottleneck will begin to dissipate.

Assemble your team

Get involvement from everyone that’s affected by the problem — your team, your peers, other departments that might be affected. Of course, part of the finesse in this kind of project is to make it clear exactly what problem you are solving without making the project sound subversive or offending the wrong people. Your boss may be a terrible bottleneck, but also remember how valuable he or she is — this isn’t about cutting him out of the picture, going around him, or changing policies you don’t like. It’s much better to focus on things like qualitative improvement, streamlining projects to avoid inefficiency, or developing lean principles. Make it positive, in other words.

Identify key risks

Your probably already know what the main pain points are. Your team experiences them all the time: Loss of productivity, overtime, last minute changes, introducing new errors, reworking something that could already be finished. These are the lesser symptoms of an endemic problem: What are the potential risks if the problem goes unaddressed? Certainly continued loss of efficiency, higher expenses to the company and lower employee satisfaction come to mind. Perhaps there’s even a trend of some team members transferring out of the department to find a better working environment. More dramatic effects can include missed product deadlines, problems with released products or lowered perception of the department’s attention to quality. All of these can have a real financial impact on the company.

Identify those risks that are most significant. Those should become the focal point for initial improvement. This is a “risk driven” model, where high risk is identified — in other words, the most painful or potentially painful result of the problem gets the most attention as early as possible. Generally it’s best to tackle a few things at a time. While the list of risks could be very long, if you try to solve every problem at once it’s going to be overwhelming.


Once you’ve identified the top few risks, pull together your project team and identify candidate solutions. You’re designing something new here, so it’s going to seem like brainstorming — which is exactly what it is:

  1. Can more attention from outside experts improve the overall product, lowering your boss’ need to be involved?
  2. Would the quality assurance organization be a helpful partner in achieving this?
  3. Could changes in the project timeline better accommodate your boss’ hectic schedule? Perhaps driving for earlier involvement (or longer project schedules) would help.
  4. Can the team multitask, effectively putting several critical paths into play so that if one gets stalled waiting for your boss, the others move forward?
  5. Would better tracking systems and information management help solve the problem? Perhaps your boss would benefit from a system that brings more organization and immediate answers directly to him.
  6. Perhaps greater visibility into the project timeline and reasonable deadlines would both improve responsiveness and provide some firm schedule guidance.
  7. Information radiators (such as task boards, timelines and assignment lists) might help keep people up to speed on overall project status (and what has moved from “medium” to “high” priority).
  8. A widely accessible system that assigns tasks and prioritizes those tasks would increase visibility of current goals as well as get everyone united about what needs attention first.

Every organization is going to discover different solutions that help its specific situation. It will likely take time to hit on the first few steps that move in a positive direction — but those are the ones you want to hang on to.

Include a quality improvement element

Organizations that have the benefit of a formal quality assurance and improvement group should try to leverage the group’s knowledge. Quality assurance is about auditing and measuring progress toward improvement. Most quality assurance groups tend to be very good at measuring improvement over time, and putting that knowledge to use will help in gathering metrics and identifying what’s working, and what isn’t.

Track your progress

Measure, act, measure again, and adjust. This is the heart of most agile development methodologies — and most scientific methods.

The most important thing to do is realize when improvement has taken place. That means tracking information — metrics — about your organization’s efficiency. This can seem pretty amorphous when dealing with a problem such as this. Remember that it comes down to improved efficiency of individuals. Some teams will have simple metrics that are easy enough to track, such as number of projects completed on a monthly or quarterly basis, or number of cases filed. When all else fails, the number of hours committed to rework is a great metric, because it tracks directly to risk identification and mitigation up front. That is, if you properly identify a risk and mitigate it early in the project, the amount of time spent in rework related to that risk goes down.

This is one reason it’s important to have everyone affected by the problem involved: It’s going to require everyone to look for these signs of improvement. It might even require tracking hours spent in rework. Fortunately, with the goal in sight (less time spent reworking and fewer overtime hours) it shouldn’t be too hard to commit people to some moderate tracking.

Gather metrics on what works and what doesn’t work. Emphasize incremental improvement as a desired outcome: Track the results of each effort, and keep the best practices. The important thing here is to demonstrate improvement over time, so that everyone sees each action as contributing to the solution, not as a failure in delivering the end result.

One of the most important goals in creating a project mentality is the positive group effect. Seeing each practice as part of a solution keeps it alive — as opposed to trying something and perceiving failure. As the team, department or company works together to deliver a solution it becomes a self-reinforcing effect. Even your boss might notice, and actively start to take part.

Not a panacea, but trying: Comindwork is attractive

Management tools probably don’t bring to mind excitement and visions of “getting things done” the agile way. Nevertheless, it’s an important aspect of running any project — whether agile or not — and there are some tools, believe it or not, that are easy to use, hugely helpful in managing a project and sometimes even a little bit of fun.

One such tool is, a fabulously rich project management software as a service (SaaS) site. While not right for everyone or for every situation it’s definitely worth taking a look at.

Comindwork combines over 250 project management related capabilities under one roof, yet does it with a web interface that is, by and large, a breeze to use. Some of the strengths of the service include traditional project management tools, knowledge management, collaboration tools, information sharing and versioning, and both agile and traditional waterfall management tools (e.g.: think Gantt).

The entry point is easy, and that’s another strength for comindwork: A small team can get started for somewhere around $20 a month (for teams of 10 or fewer, it’s $1 per day that you actually use the service — if nobody logs in, it’s no charge). This offers up a wealth of really advanced tools at a fraction of the cost of most large scale management infrastructure. For companies that don’t have a system in place, it’s easy to give comindwork a spin.

Here are a few of the things I like about comindwork.

It all starts with the personal dashboard. I’m a huge believer in personal (meaning, customized and personally relevant) dashboards, especially if they follow the basic principle of “Getting Things Done” methodologies. Distraction is bad, focus is good:


With the project dashboard, you can:

  1. Get a bird-view on all activities where you are involved, see who changed what and when
  2. See your nearest milestones
  3. Check team members’ status and mood
  4. Easily access detailed project-specific dashboards

It offers both traditional (meaning, typically, “large scale”) project management and agile management philosophies living under one roof. At first glance I was taken aback by any system that can claim to offer this mix of tools, but comindwork manages to pull it off. On the traditional side, there are Gantt charts and round-trip import and export of Microsoft Project files, not to mention a whole host of reporting capabilities. On the agile end of the spectrum, to-do lists, tasks and very easy time tracking support simple progress monitoring. Unfortunately, burndown charts have yet to make an appearance, although there’s enough information available that they may not be entirely necessary.

Knowledge management and collaboration are central to the product. Blogs, to-do lists, milestones and business wiki support which codify and share tacit knowledge are tightly integrated into the project. In fact, one of comindwork’s strengths is that so many services are so tightly integrated. For example, linked business wiki entries, tasks and time commitments can be shared and kept up-to-date, with progress being reflected in round-trip Gantt tracking in Project. Notifications of all activity take place automatically, sending out instant email messages or daily digests that summarize project activity.

One of the problems I’ve run into with customers that have no pre-existing system is simply keeping track of all the project artifacts and versions of each. With email flying everywhere, documents being authored, and half the team not knowing how to use source management repositories, how can you hope to keep track of every artifact the team produces? I like to implement a policy of “email doesn’t exist,” but this means you need a tool that’s going to support the policy.

In other words, if someone wants to get something done, it should be in a system, not flying around in email. The idea of half a dozen versions of a document living on everyone’s desktop is just unacceptable to me. Comindwork provides file versioning and drag-and-drop upload. This makes it possible to implement the “email doesn’t exist” policy, and comindwork does a great job of delivering an easy to use tool:


Having a convenient and ubiquitous place to store project artifacts makes it easy for the team to share, manage, and collaborate. Comindwork put enough effort into the interface that it’s not painful:

  1. Create a convenient tree-structure of your documents
  2. Make common actions on a set of files (mass-delete, mass-move)
  3. Provide comments to any file version
  4. Versions are stored automatically whenever you upload a file with the same name. Check all revisions and easily revert if required
  5. Use drag & drop area for native multiple files upload

You can even email files directly to a folder in your comindwork project.

For more demanding projects, you can design custom workflows to support the security, policies and customer demands of the project. This is an essential tool in my mind. Any project management solution needs to be able to grow with the project. Custom workflow makes it possible:


You can create graphical representation of your business process, modify the process with appropriate business rules and make sure your project is enforcing necessary policy:

  1. Define, control and track states and transitions in your business process
  2. Encourage process automation and standardization
  3. Break your business process into easy to follow step-by-step workflow diagram
  4. Reconfigure your business process as needed
  5. Clearly define your business process and avoid miscommunication and inconsistency

If you’ve been casting about looking for how to get project tracking off the ground, take the quick tour and see what you think. It’s not a panacea that will fit all project’s needs, but it is a very solid tool that’s been seeing a lot of success lately.

If you decide it’s not for you, take a look at Atlassian’s JIRA too. JIRA is by far my favorite project management tool, especially if you’re agile-oriented. It requires a bit more of an up-front investment to get off the ground (both in terms of deployment and financial cost), but in my opinion, it’s one of very few first-rate tools available today. I’ve been trying to finish a detailed article on JIRA for some time now, so check back in a bit.