Section 11.1. Prevent Major Sources of Project Failure

11.1. Prevent Major Sources of Project Failure

By getting involved in your software projects and not leaving all of the decisions up to the vendor, you can prevent many of the most common causes of outsourced project failure.

11.1.1. Get Involved

There's a broad misconception that it's possible to somehow extract the work from an outsourced project team without getting involved in the day-to-day management of the individual team members and their tasks. The conventional wisdom goes something like this: you're paying the vendor to handle all of the management overhead, so they should also be able to handle any personnel management problems that arise. This might work in some instances, but in other cases, it leads to a client who is unhappy with the vendor, and to a vendor who does not really interact with the client.

In fact, that very management overhead at the vendor can be a major source of problems on your project. For example, an in-house development team in an organization can standardize on a single language and platform; a vendor, on the other hand, must be ready to take on a broad range of technologies for many different clients, most of which will not have any application whatsoever to your project. To accomplish this, the vendor has an incentive to keep all of the programmers on the team cross-trained in multiple technologies. One way to do this is to make sure that each programmer is only assigned to any one project for a short period of time, in order to expose him to many technologies. This means that long-term engagements can be difficult to set up: many of the people on your project will see that by staying on your team for a long time, they are falling behind on the technologies that allow them to advance within the vendor's organization. This does not necessarily work against you, but it certainly does not work to your advantage.

Similarly, most good outsourcing vendors will put effort into cross-training other people in their organization on best practices learned from each client. While this can be good (because it can potentially help them address your needs better), it also means that some of your project team members will be allocated in part to helping other project teams internally at the vendor.

In other words, there are many ways that your needs and the needs of the vendor are not perfectly aligned. This makes senseyou have two different organizations, with different businesses and goals. But this difference introduces distance between the client and the vendor, which can lead to some specific ways that many outsourced projects fail.

The most common response to thisand the most serious mistake that a project manager can make when working with an outsourced projectis to assume that it's the vendor's responsibility to fix every problem that comes up in a way that will guarantee that the software gets built properly. There is very seductive logic here: "I'm paying the bills, and the vendor will lose my business if they don't get this right, so they have to take care of everything!" This attitude fails every time. The vendor does not have enough information to build the software properly, and a hands-off project manager who leaves everything to the vendor will find that the software that is delivered does not meet the needs of his organization.

11.1.2. Constantly Communicate Project Goals

The people working on your project have different goals than you do. Many of them may see the tasks that you give them as simply an opportunity to expand their knowledge. Others are completely devoted to the work that you have given them, but they don't necessarily see the context in which you have asked for it; all that they know about the project is what you have told them, and they don't (or can't) have an intuitive understanding of your organization's needs because they don't work there.

What this amounts to is the fact that you are the only person working with the project team who has your organization's needs and goals in mind. As a result, outsourcing teams are much more susceptible to the "Do what I mean, not what I say!" problem. An in-house project team almost always has a grasp on what it is that the organization does; people get an enormous amount of context just from working at an organization. Team members at an outsourcing vendor lack this context, and, unless you work to provide that context for them, that can lead to serious project problems.

For example, programmers who have worked at an accounting company for any length of time will have naturally absorbed some knowledge of accounting. When these programmers are given a task, they will immediately see why the organization needs that task done in terms of that accounting knowledge. They will be much better equipped to fill in the gaps when presented with incomplete requirements.

If the same task is given to a team at an outsourcing vendor, the programmers will not have the same background or knowledge. Even if that vendor has experience with other accounting projects, the team members do not spend each day working at an accounting company, talking to other people who do accounting, or reading the company newsletter about the latest clients. They do not come to the table with the same expectations about the software that an in-house team would.

This is why it is especially important to communicate the goals of your project to your team all the time. You need to personally make sure that the team members understand your organization's needs, and that the tasks they are performing are in line with its goals. Since they are not immersed in your organization's culture, you have to be the ambassador of that culture, so that they are always kept on track. You have to act as a rudder, constantly steering the team toward the goals of the project. That could mean that you need to have daily discussions with someone from the team. You may need to spot-check work from selected team members to make sure you are getting what you think you are asking for.

This can be very difficult and time-consuming, but it is easily the most important thing that you can do to make sure your project does not fail.

Many outsourced projects fail because their project managers fail to understand or do anything to compensate for this situation. They often blame the vendor for not understanding what they are saying. This is frustrating for everyone involved: the project manager feels betrayed by the vendor, while the vendor feels like the client did not adequately communicate his needs or goals. Nobody is happy with a failed project.

But despite how many project managers feel about their projects, in most cases this is not the fault of the vendor. Rather, it's a fact of life due to the way the outsourcing industry is structured. Each vendor has its own business to run, and it's absolutely understandable and expected that they would want to train people and encourage them to grow within their organization. It often falls to the project manager of the outsourced projectin concert with the management team at the vendorto balance the vendor's needs with the project's goals. This means that you must form a relationship with their management that allows you to deal with that problem and to reach an acceptable compromise.

The more you are able to integrate the outsourced team with your organization, the more context they will have. If you are able to dedicate multiple people at your organization to communicating with the outsourced team, the team stands a better chance of understanding the complexities of your organization's environment, and of ultimately meeting your organization's needs. It doesn't always fall to the project manager alone to communicate the culture, context, and needs of the client organization. The more people you can involve in that process, the better it will be for the outsourced team. If your organization is willing to put in the effort, they can build a sense of teamwork between your organization and the vendor's that would not be possible to build on your own.

11.1.3. Make Sure the Project Is Estimated Well

The further away you get from a task, the easier it seems; the devil is usually in the details. Outsourcing allows you a lot of distance from your projects. For example, if your own team is making estimates , you often expect those estimates to be examined and questioned by senior management. But an outsourcing company does not have the same checks, and also does not have the same implicit trust. In some ways, you're far more likely to distrust them; but you're also much more likely to have little or no visibility into the way they run your project.

Sometimes it's the client's fault that realistic goals are not set for the project. There may be a lack of due diligence on the part of the client contracting the outsourced servicesfor example, choosing companies based on cost only. Some companies may be cheaper because they don't understand the project being proposed, while some may be cheaper because they just aren't very good. (For some reason, clients don't care what the reason is for a very low price until they see the final product, or lack thereof).

On the other hand, sometimes it's the vendor's fault. Vendors tend to promise things they can't deliver. (This shouldn't be too surprisingmost software engineers have experienced projects where the promised deadline was unrealistic.) Many vendors are perfectly aware of the myths about outsourcing, and are happy to let you continue to believe them. ("Your project can't fail because there are many people sitting in the wings, just waiting to jump on if the project starts going downhill."^[*]) When you're talking about a software project, it's going to be a long time between when the contract is put in place and the point when you figure out that the project is not progressingespecially if you don't have good checkpoints in place.

^[*] Remember Brooks' Law: "Adding manpower to a late software project makes it later." (See Chapter 10.)

One effective way to prevent the vendor from taking on work that the team cannot perform is to understand their capacity from the outset. Ask them to show you the results of a project of similar size. (If they have never taken on a project of similar size, you may want to switch vendors!) Get involved in the estimation process, and make sure that the people who are going to do the work buy into the estimates that the project plan is based on.

Don't be afraid to meet with the vendor's project team and hold your own estimation sessions, once the project team is assembled. It is not uncommon for a vendor to have a separate estimation team that provides estimates when a contract is being negotiated; this team may provide estimates that are sufficient for a contract, but insufficient for planning your own organization's goals. By getting personally involved in the estimation process, you can ensure that your project plan is better grounded in reality.