Section 11.2. Management Issues in Outsourced Projects


11.2. Management Issues in Outsourced Projects

There are some important ways project management is different for an outsourced project than it is for a project developed in-house. It's not just the relationship with the vendor that's different; it's also the relationship between you, your management at your own company, and your team members. By paying special attention to transparency, information sharing, and communication, you can make sure these relationships lead to a successful project.

11.2.1. Actively Manage Your Project

If you have a relatively small project with well-defined requirements, known acceptance criteria, and a specific deadlinein other words, a fixed amount of work in a fixed period of timethen the project will probably work out fine. The success of a project like this hinges primarily on the technical competence of the programmers and on their ability to work together as a team. This is especially common when an organization that has never developed software before needs a specific piece of software written and does not want to build up its own IT infrastructure.

If you are a project manager at an organization that makes software as part of its core operations, then you are probably not in this situation, and your outsourced projects will probably not be this simple. They are much more likely to involve an open-ended commitment (one that, in some cases, could go on for years). Many organizations that outsource their work do not have a good grasp on their requirements, and often have not put much thought into what they need from the project or the vendor (other than "working software"which, in practice, is not an easy thing to pin down).

The truth is, many outsourced projects don't go well. What's more, the clients at those projects don't necessarily realize that their projects have started to go bad until they receive a piece of software that does not do what they need it to do. This situation is harder to prevent here than it would be in an in-house project, for several reasons. If you are getting a much cheaper labor cost than you would for your own employees, then you might have a much larger project team than you are used to managing. You might also be used to having a lot of visibility into how your projects are going, because your in-house programmers talk to you routinely and give you (and your users and stakeholders) a lot of status updates.

When you are managing an outsourced project, the status doesn't readily present itself. If you have a good management structure in place, you can trust your delegated managers at the vendor to relay the status to you. However, the most reliable way for you to get a good handle on the status of your project is to collect it yourself. If, for example, you are building a project, you should ask for nightly build reports and unit test results. You should track the lines of code produced on a daily or weekly basis, and you should have access to a defect tracking system with metrics. Numbers like that can give you regular snapshots of the health of the project.

You should know the names of the people on your team. Ask for a CV or resume for each person. Have regular conversations with at least one representative for every projectminimally, you should talk to that person weekly. But if you really want a handle on how your project is going, you, or someone in your team, should talk to someone from the outsourced team every daythe same as you would if they were in your office! (Luckily, with instant messaging, it is very easy to keep in touch with a large team by adding them all to a buddy list and spending time each day shooting messages to them.)

One effective way to make sure that you will get all of the information that you need to run the project is to set up a communications plan with the team lead at the vendor. Make it clear from the outset of the project exactly what information you need them to gather for you. If you do this, it is very important that you only ask them to gather information that will actually be useful to you, and that you use it and review it with them: if you do not use the information that they gather (or if they do not see how it will be useful), then it will just seem like busywork to the team, which is demoralizing and counterproductive.

If you don't make sure that the people at the vendor know why you are asking for this information and what you are using it for, it's very easy to build up an environment of distrust with your outsourcing vendor. The only way to combat that is with transparency . In other words, somebody at the vendor is going to spend half a day each week gathering data for you. Make sure that you respect that time.

The best possible scenario is when you've set up standards that let the people at the vendor monitor themselves. You want the team to be as autonomous as possible, while still being productive and giving you information that you need to monitor the project. Your goal should be to have the team assist you in managing the project without losing control of it. One way that you can do this is by setting up an inspection process where the team can inspect documents and report the results to you (see below). If knowledge that you need to know has been properly transferred, you can write a quiz, and have all of the people on the team take it independently and send you their results. The key is that you must know at all times what the team is doing, and that it's in line with what you want them to do.

11.2.2. Share Information with Your Management

Many senior managers think that software development should be free. They think their internal IS departments are overpaid. Now they're cutting a big check to an outsourcing company, and they expect everything to be smooth and easy; there should be no problems or difficulties whatsoever. If you're the project manager on a project in this environment, you are set up for a thankless job.

When senior managers have unrealistic ideas about outsourcing, a project manager's successes will almost certainly go unrewarded because there is already an expectation that outsourcing is easy. If you do well as the project manager, the credit will go to the outsource company. What's more, in an environment like this, there is little incentive not to failif you do, it will be blamed on the outsourcing company. People are already biased against outside organizations handling their business; nobody wants you to waste money, but they won't blame you for somehow being "snowed" into thinking that another company could do as well as your own organization.

On the other hand, many senior managers have a much more realistic view of outsourced projects. They realize that they are difficult to manage, and that they require a lot of work and overhead. In this case, it is even more important that they are kept in the loop; you will need them to support you in case you make any controversial decisions, if you need further funding, or when you need their approval.

Regardless of the attitude of your senior management toward the project, it's always a good idea to keep them informed of everything you are doing. This means that you need to constantly go back to your own senior management and make sure that you still have their buy-in. If your boss thinks that managing an outsourced project is easy, you will have a very difficult time explaining why you spend so much time managing it. You must make sure your organization's managers understand what it is that you and your outsourced team are accomplishing, and how you are dealing with them on a day-to-day basis. You are the bridge between your organization and the vendor; it is your job to bring transparency to the process. Just as you have to focus on constantly steering the vendor team into meeting your organization's goal, you also need to constantly steer your organization's management so that you are always apprised of their goals and they have visibility into how the vendor is meeting those goals.

To provide adequate transparency into the project, you must give status reports to your organization's senior management. Any metrics that you use to track a software project will be useful; you should make them available. Encourage your management to visit the outsourced team and meet with the vendor's management. All of the methods in Chapter 10 for making a project transparent should be applied. In this way, you can make sure that your management can actively get information whenever they need itand you can help them understand just how difficult the job of managing an outsourced project is.

A large part of establishing an understanding with your managers is sharing the issues that you are resolving, so they understand the effort you are putting into your projectespecially when it comes to managing the team. It may seem obvious to your senior managers that the team doesn't work for you, but it's not obvious that this can create its own set of problems. There's a difference between being someone's client and being someone's boss. You don't set the performance goals of the software engineers; it is rare that you even know what they accomplish in their careers.

11.2.3. Build a Relationship with the Vendor's Management

You must have a good relationship with the entire upper management of your vendor organization. You must know who to escalate to if things go wrong, and you need to be able to trust themand have them trust you as a credible and knowledgeable source of information for your project. You have to partner with the management of your project at the vendor company. They need to understand your goals. And most importantly, they need to understand that when you ask them to change the way they do their work, you are doing it to help them continue making money from your organization.

It is very important that you maintain this positive, cooperative relationship with your vendor's management. This is not always easy. There are times when the vendor has procedures in place that make it more difficult for you to see what's going on in your project, communicate with your team, or do your work in other ways. When this happens, don't just go in and make a bunch of changes. Instead, carefully discuss the problems and reevaluate the procedures that caused them. There is nothing wrong with the vendor having a business to run. Vendors need to keep their employees happy and challenged. Sometimes there are situations in which the vendor's goals are simply different than yours, and you must reach a compromise by being open, honest, and transparent.

One common mistake that many project managers make is to set up a complex or convoluted escalation process. Some vendors come to the table with these escalation procedures prebuilt, inserting a layer that blocks communication between you and your team. A policy that puts an escalation process in place will typically require that a team member first talk to the project lead and then to the manager at the vendor (and often one or two other people) before they are allowed to communicate directly with you. (This time-consuming process is often put in place specifically to bolster the management hierarchy at the vendor.) Often, the escalation procedure resembles the playground game of "telephone," where a message is passed from person to person until it is essentially unrecognizable. This is not a good way to communicate, especially when a problem is serious enough to warrant the involvement of the vendor's senior management (who will not know the specifics of the problem and are therefore more likely to obfuscate it).

Some people are more comfortable with an escalation process in place than without it. Middle managers at a vendor like it, because they can intercept problems that might be potentially embarrassing (such as an incompetent team member). They can better manage the client's perception by only allowing the "good" questions to be asked: for example, they can tweak the questions to make them seem less negative. Many project managers also like the escalation process, because it provides distance (and cover) if the project starts to go wrong. The further they are from the project team, the less culpable they are for its failuresit gives them a sort of "plausible deniability."

There are often good reasons for this. Many outsourcing clients are very hands-off and do not want to be "bothered" with the day-to-day operations at the vendor. Sometimes that makes sense, like when the client has little IT or project management experience. Many clients who have outsourced work honestly can't handle the idea that any mistakes have been made, and, even though that's a completely irrational and unrealistic expectation, they will use it as a reason to start renegotiating or dismantling contracts. These procedures are there to protect the vendor from crazy or irrational clientsand there are an awful lot of those in the outsourcing world!

However, since you are a good project manager and a reasonable person, you can work with the vendor to adjust things so that they work better for everyone involved. If there is a convoluted escalation procedure in place at the vendor, you are perfectly within your rights as a client to modify it or, even better, dismantle it entirely. This is okay, even if that's the "regular way" that clients interact with your particular vendor. The benefit of doing things the "regular way" does not outweigh the increased chance of miscommunication, scope problems, and requirements problems. Provided you take responsibility for your part of the end deliverable, you should be able to work with the team in the way you are most comfortable.

In addition to escalation, there are other procedures at the vendor that might not suit your method of working. Their system for performance reviews might reward your team members for things that are important to the vendor's organization but are not necessarily important to your project. For example, they might be rewarded for years of service at the vendor. It looks great from the vendor's perspective to have a team of "seasoned professionals" (who may have been around for a long time, but may not necessarily be stellar performers). If a vendor can quickly assemble a team of people with many years of experience, they can use this as a sales tool to get more lucrative contracts. Therefore, when they are recruiting potential employees, some vendors might offer a compensation package that rewards years of experience over knowledge. What's more, some vendors work very hard to prevent attrition because it looks worse for clients, and so will work very hard to keep from losing employees who have seniorityeven if these employees are not all that great at their jobs.

It's not just hiring and firing practices that might not suit your project. There may also be trouble with the specific ways that vendors reward employees. It is common for vendors to reward employees for seniority with things like increased responsibility and access to new technology. This can be bad for your project: it is very unlikely that you will need to change your team members' responsibilities or switch technologies over the course of your project, which means that you are cutting your team off from what they traditionally expect as a reward for seniority. In other words, if you are developing a piece of software in Visual Basic, the chances are that you will not change to Java over the course of your project. If people on your team feel that they are falling behind in their technical skills, they will look to switch to another project at the vendor.

Look around your own organization: you can probably think of one or two people who have been there a long time, yet are not great employees! There's no reason to think that this isn't also true at the vendor. The bottom line is that a team member with years of experience in IT or seniority at a vendor is not necessarily competent. This means that the less you rely on the vendor's management to assign responsibilities to and reward your team members, the more control you have over your project. The best way to handle this is to set up your own system of rewards. For example, you can offer a bonus based on actual performance rather than seniority. To do this, you need to have a good handle on how well each person does her jobwhich, once again, means that you need to communicate with them. This works especially well if you personally assign tasks to the team members, rather than relying on the vendor's management to do that for you. This will require that you do your own project planning (see Chapter 2), and that you find ways of objectively measuring the performance of the people on your team.

It's not just processes at the vendor that need to be adjusted for your project. You may need to adjust them in your own organization as well. For example, your organization may have security policies or intellectual property policies that make it more difficult for you to manage your projects. These are problems you would normally never have to think about, but, since you are working with an outside vendor, you may now have to take them into account. Sometimes companies do not have policies in place to share information between the client company and a subcontractor. This slows down the process of creating software and sometimes makes it impossible for the expectations to be met.

Many project managers find it difficult to communicate project priorities to the team. Just as you might be the sole point of contact for your organization, you may be working with a single point of contact in the vendor's company who handles your requests. They may misinterpret you, or never actually understand your goals. Unless you negotiate for it, you may never actually have access to the team.

11.2.4. Build a Relationship with Your Team

You don't have the same kind of relationship with the team that you would with a team in your own organization. As project manager, you do not directly hire the resources assigned to the project. You can veto any team member, but you do not have immediate access to employment history, performance reviews, personnel files, salary information, or other important information you would usually need to make those decisions. If someone does a bad job, your only recourse is to have him moved off of your project. It's likely that he is never even told that there was a problem; he's probably just been told that he's been reassigned. This means that your team could contain people who were removed from other projects in the past due to performance problems and don't know it.

You have to gain the respect of the people you have hired to do your project. The simple fact that you're paying the bill doesn't establish you as the ultimate authority in how the vendor should manage the project. It's your job to establish yourself as a credible partner and to work with the people at the vendor, in order to make sure they meet your goals (and to assure them that you respect theirs!).

It's a common misconception that, because you are paying a contractor, you have more control over the work product. Somehow people assume that by simply writing a big enough check, a vendor will snap to attention and build exactly the software they need. After all, their payment depends on the client's satisfaction, right? So the vendor must be doing everything they need to do in order to satisfy the client. This is an odd attitude: you also pay your employees, and their performance reviews are dependent on your satisfaction as well, but that does not guarantee that all of their projects will succeed. The truth is that outsourcing projects are at least as likely to have problems as in-house projects. And when they do have problems, you have only a few possible recourses. This means that you actually have less control over the performance of individual outsourced team members and their work products than you would with an in-house team.

Being the sole point of contact with the subcontract team is a big change for many project managers. When you are the project manager for an in-house project, your team has access to the entire organization: they can talk to managers, stakeholders, users, etc. This is not the case on outsourced projects, where the vendor must route all communication through the project manager. This introduces many potential pitfalls into your project. The most costly problems involve the project scope and software requirements. If you do not describe the project adequately, you will end up with software that does not meet the needs of your organization. An in-house project team has many more opportunities to catch these problems.

This requires that you pay a lot of attention to your project team members, possibly more than you would to an in-house team. This is paradoxical, as most project managers are more likely to spend time with an in-house team than they would with a team at a vendor. It's not only your job to communicate your company's needs to the team, it's also your job to understand the needs of each team member. For example, if your team member needs clarificationand it is essentially impossible to run a project where a team member does not need clarification!you are that person's only resource for gathering the information. If you do not provide a communications path from the team to your organization, they will simply make assumptions about any missing or unclear requirements. This will almost certainly lead to a misunderstanding. Sometimes those might be small problems that are easily corrected once the build is delivered. But small problems can snowball into big ones, and that could lead to software that does not do what you expect it to.

One of the hardest parts of working with your project team is correcting problems. Keeping a team motivated when they are not performing as well as you would like them to is difficult enough when they are in-house (see Chapter 10). It is even more difficult to handle this situation in an outsourced environment. Not only is the team in another organization, where you don't have the same access to them, but they also do not have the same goals as you do.

Expecting your project team to give you credibility in reviewing their work is like expecting your car mechanics to listen to your criticisms of how they fix your car. Most of the clients that your team has dealt with in the past have probably been relatively hands-off. The clients have been mostly ignorant of how software is built at their organization, so it's likely that some of your team members have never even been addressed directly by a project manager at a client. Now they're faced with a project manager who is taking the time to evaluate their work in detail. This new attention may not necessarily be welcome at first, especially since you will almost certainly ask them to make changes to how they work.

You need to be aware of the fact that when you are saying something negative, you need to present it with a lot of objective supporting evidence. Over time, you will gain credibility with them. But, at least initially, you will have to prove that you know what you are talking about. You will not be recognized as an authority just because you are paying the bills. This is a reasonable attitude for the team members to take, since it's true of most of their clients. You have to give them good reason to understand that you are different.

The way to build up credibility with your team is to show that your interests are in line with theirs, and that you are often right. It's no coincidence that this is exactly what you need to do with your team in your own organization. The difference is that when you are a project manager of an in-house project, you come to the table already in an authoritative role. With this team, you have a much different role. You have wide authority to modify the team and to add or remove people, but you start out with very little credibility to make technical decisions (although you do have the authority to do so).

It's very important to see this from the team members' point of view. Consider a project in which the project manager is trying to guide the team toward making technical decisions that they are not fully comfortable with. In an in-house situation, if this situation leads to a failed project, the team can stand behind their manager and point to a decision that was made for them. With an outsourced project, the project manager is accountable in his own organization, but the team members are just as accountable in the vendor's organization. If the vendor loses the contract, the team members will be blamed and their careers will be impacted. So it takes some work to get them to trust youand rightfully so.

It's harder to earn the trust of the vendor team than it is to earn the trust of an in-house team. You are not at the vendor every day, and the team does not know you and does not have the opportunity to get to know you. This is especially difficult when you make an unpopular decision, whether it concerns team responsibilities, technology, specific approaches to problems being solved, or some other decision. Every group in every organization discusses decisions that are made by managers; usually you will be there to defend those decisions if they are misunderstood. However, in an outsourced situation, your decisions have legs. People may attribute motives to your decisions that you did not intend. They may see those decisions as personal rather than professional. And worse, they may not feel comfortable enough talking to you to ask you about them. Team members have spent their careers at the organization learning its particular culture and processes, and the client is suddenly making changes to them. Often, you have not had time to evaluate how your changes will work with the process: this is another barrier to earning the team's trust, and you need to take it into account when working with them. The more open you can be to the team members' perspectives, the more intelligent your decisions will be. (Don't forget that you generally benefit from team members' experiences on past projects!)

You cannot expect to be at the vendor every time your decisions are called into question. This is why your partnership with the management of the vendor's company is so essential. They are your ambassadors to the team, and, if they trust you and understand why you have made your decisions, you can depend on them to smooth out these problems. This is why you need to be transparent with them about your decisions and the reasoning behind those decisions.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net