Organizing a Team Project

As a project manager, your job is very similar to the team leader from one of your favorite spy caper movies: putting together a team that has all the skills to get the job done. You will need to deal with many issues that rarely come up in a spy movie, however, such as characters who dodge work and complain about the difficulty of the job. This article will help you deal with some of these problems. It is excerpted from the book IT Project Management: On Track from Start to Finish, Second Edition by Joseph Phillips (McGraw-Hill/Osborne, 2004; ISBN: 0072232021).

Organizing a Project Team

Think of your favorite spy caper movie. Remember how the team in the movie is assembled? Each member has a specialty: explosives, gadgets, luck with the opposite sex, and other necessary skills to get the job done. Notice how there’s never just an extra character walking around slurping coffee, dodging work, and whining about how tough his job is? Unfortunately, in the world of IT project management, you’ll have both types of characters.

As a project manager, you will recruit the die-hard dedicated workers who are genuinely interested in the success of the project. These team members are exciting to be around as they love to learn, love technology, and work hard for the team and the success of the project. The other type of team members you’ll encounter are nothing less than a pain in the, er, neck. These folks could care less about the project, the success of the company, or anyone else on the team. Their goal is to complete their required hours, draw a paycheck, and get on with their lives.

The reality is, however, most people want to do a good job. Most team members are generally interested in the success of the project. If you get stuck with one of the rotten apples, there are methods to work with them—and around them. This chapter will focus on how you, the project manager, can assemble a team that works well together. Your team may not be in any spy movies, but parts of the project can be just as exciting.

Assessing Internal Skills

Whether you get to handpick your project team or your team is assigned to you by management, you will still need to get a grasp on the experience levels of each team member. If you have an understanding of what your team members are capable of doing, the process of assigning tasks within the WBS and creating the project plan will go much easier for you.

As a project manager, you must create a method to ascertain the skills of your team. It would, no doubt, be disastrous to your project if you began assigning tasks to team members only to later learn they were not qualified to do the work assigned to them. In some cases, this will be easier to do than others, especially if you’ve worked with the team members before, interviewed the team members, or completed a skills assessment worksheet.

Experience Is the Best Barometer

As you gain experience as a project manager, you will learn which people you’d like on your team—and which you wouldn’t. If you are a consultant brought into the mix to manage an IT implementation, you’ll have to learn about the team members, their goals, and their abilities.

You must use strategies to recruit and woo knowledgeable and hard-working team members onto your team. This means, of course, you’ll have to do fact-finding missions to gain information on your recruits. As Figure 6-1 demonstrates, you have available to you many methods to assess internal skills.

Once you’ve started your fact-finding mission, rely on multiple methods to assess internal skills:

  • Prior projects Obviously if you’ve worked with your team members prior to this project, you’ll have a good idea who’s capable of what tasks. You’ll also have a record, through historical information, of who’s reliable, dependable, and thorough, and has other traits of a good worker.

  • Organizational knowledge You may not have worked directly with particular team members who have been assigned to your project, but you might have a good idea of their track record. Let’s face the facts: in your organization, it’s likely there are people you haven’t worked with, but you know the type of workers they are by their reputation, their ability to accomplish, and what others say about them. Gossip is one thing, but proven success (or failure) is another. The best way to learn about someone, of course, is not through hearsay, but to work with him or speak directly with his manager.

  • Recommendation of management You may not have the luxury of selecting your team members like you’re picking a kickball team at recess. You’ll probably be able to recruit some members of your team, but not all of them. Functional or Senior Management will have an inside track on the abilities of employees and can, and will, recommend members for your project. Management will also be able to select individuals who can commit time to the project.

Figure 6-1.  Assesment of Internal Skills is derived from multiple sources


  • Recommendation of team members Most likely, you will have other IT professionals within your organization whom you trust and confide in. These folks can help you by recommending other winners for your team. These individuals are likely in the trenches working side-by-side with other IT pros. Use their “scouting” to find excellent members to work on your project.
Resumes and Skill Assessments

Another source, if you have privy to the document, is the resume for each team member. A resume can quickly sum up the skill set of a team member. You may want the project team to create quick resumes for you in order to learn about the experiences of individual members. Use caution with this approach, however. Resumes have the connotation of getting, or keeping, a job, and your team members may panic. If you want to use this method but are uneasy using the word “resume,” have the team members create a list of projects they have worked on, their skills, and other past accomplishments. This will give you a way to quickly understand the collection of talent and then assign work to the team.

A collection of skills will also allow you to determine if you have the resources to complete the project. For example, if you’re about to create a database that will span 18 states, with multiple servers, and provide real-time transactions for clients, it’ll be tough to do if none of your team members have worked with relational databases before.

Create a Roles and Responsibilities Matrix

A Roles and Responsibilities Matrix is a method to identify all of the roles within a project and the associated responsibilities to the project work. This matrix is an excellent way to identify the needed roles for the project participants, identify what actions they’ll need to take in the project, and, ultimately, determine if you have all of the roles to complete the identified responsibilities. Here’s a quick example of a matrix for a software rollout project: Here’s the legend for this matrix:


Project Manager

Application Developer

Network Engineer

ZenWorks Expert

Create the application





Test the application





Package the application





Test the application release





Push the application to the workstations





Here’s the legend for this matrix:

A = Approves
R = Reviews
P = Participant
C = Creator

The Roles and Responsibilities Matrix can help the project manager identify the needed resources to complete the project work—and determine if the resources exists within the organization’s resource pool. Later in the project, the project manager will use an even more precise matrix called the Responsibility Assignment Matrix (RAM) to identify which tasks are assigned to which individuals. We’ll talk more about this coming up.

{mospagebreak title=Learning Is Hard Work}

Within the IT world, a requirement for certification has become practically mandatory. Certifications such as the PMP, Microsoft Certified Systems Engineer, Oracle DBA, and even industry certifications like CompTIA’s A+ and Network + are proof of knowledge in a particular area of technology.

Individuals can earn these certifications based on training, experience, or a combination of both. Certifications are certainly a way to demonstrate that individuals have worked with the technology, understand the major concepts, and are able to pass the exam. Certifications do not, however, make the individual a master of all technologies. As Figure 6-2 demonstrates, a balance of certification and experience is desirable.

Figure 6-2.  A balance of certifications and experience proves expertise.

Within your team, whether there or certifications or not, you’ll need to assess if the members need additional training to complete the project. Training is always seen as one of two things: an expense or an investment. Training is an expense if the experience does not increase the ability of the team to implement tasks. Training is an investment if the experience greatly increases the ability of the team to complete the project.

When searching for a training provider, consider these questions:

  • What is the experience of the trainer?

  • Can the trainer customize the class to your project?

  • Would hiring a mentor be a better solution than classroom training?

  • What materials are included with the class?

  • What is the cost of the course?

  • Is there an in-house training department that can deliver the training, provide assistance in developing the curriculum in-house, or assist in contracting with an outside trainer?

  • Would it be more cost effective to host the training session in-house?

These questions will help you determine if training is right for your project team. In some instances, standard introductory courses are fine. Typically, the more customized the project, the more customized the class should be as well. Don’t assume that just because a training center is the biggest that it’s also the best. No matter how luxurious a training room, or how delicious the cookies provided, or how slick the brochures are, the success of the class rests on the shoulders of the trainer.

Creating a Team

You can’t approach creating a team the way you would baking a cake or completing a paint-by-the-numbers picture. As you will be dealing with multiple individuals, you’ll discover their personalities, their ambitions, and their motivations. Being a project manager is as much about being a leader as it is managing tasks, deadlines, and resources.

You will, through experience, learn how to recognize the leaders within the team. You’ll have to look for the members who are willing to go the extra mile, who do what it takes to do a job right, and who are willing to help others excel. These attributes signal the type of members you want on your team. The easiest way to create teams with this type of worker? Set the example yourself.

Imagine yourself as a team member on your project. How would you like the project manager to act? Or call upon your own experience: what have previous project managers taught you by their actions? By setting the example of how your team should work, you’re following ageless advice: leading by doing.

Defining Project Manager Power

Project managers have responsibility. And with that responsibility comes power. When it comes to the project team you are seen as someone with some degree of power. Get used to it, but don’t let it go to your head. While the project manager must have a degree of power to get the project work done, the extent of your power is also likely relevant to the organizational structure you’re working in. For example, recall that a functional organization gives the power to the functional manager and the project manager may be known as just a project coordinator.

A project manager does, however, wield a certain amount of power in most organizations. The project team can see this power, correctly or incorrectly, based on their relationship with you. Their perception of your power—and how you use your project management powers—will influence the project team and how they accomplish their project work. The five types of project manager powers are

  • Expert The project manager’s authority comes from having experience with the technology the project focuses on.

  • Reward/penalty The project manager has the authority to give something of value to team members, or to withhold something of value.

  • Formal The project manager has been assigned by senior management and is in charge of the project. This is also known as positional power.

  • Coercive The project manager has the authority to discipline the project team members. This is also known as penalty power. When the team is afraid of the project manager, it’s coercive.

  • Referent The project team personally knows the project manager. Referent can also mean the project manager refers to the person who assigned him the position; for example, “The CEO assigned me to this position so we’ll do it this way.” This power can also mean the project team wants to work on the project, or with the project manager, due to the high priority status and impact of the project.

Hello! My Name Is…

If your team works together on a regular basis, then chances are the team has already established camaraderie. The spirit of teamwork is not something that can be born overnight—or even in a matter of days. Camaraderie is created from experiences of the teammates. A successful installation of software, or even a failed one, creates a sense of unity among the team.

It’s mandatory on just about any project that team members work together. Here’s where things get tricky. Among those team members, you’ve got ambition, jealousies, secret agendas, uncertainties, and anxiety pooling in and seeping through the workers of your project. One of your first goals will be to establish some order in the team and change the members’ focus to the end result of the project. Figure 6-3 illustrates the detrimental effect personal ambitions have on the success of a project.

Figure 6-3.
  Personal ambitions must be put aside for the success of the project.

By motivating your team to focus on the project deliverables, you can, like a magician, misdirect their attention from their own agendas to the project’s success. You can spark the creation of a true team by demonstrating how the members are all in this together. How can you do this? How can you motivate your team and change the focus from self-centric to project-centric? Here are some methods:

  • Show the team members what’s in it for them. Remember the WIIFM principle— “What’s In It For Me.” Show your team members what they personally have to reap from the project. You may do this by telling them about monetary bonuses they’ll receive. Maybe your team will get extra vacation days or promotions. At the very least, they’ll be rewarded with adding this project to their list of accomplishments. Who knows? You’ll have to find some way for this project to be personal for each team member.

  • Show the team what this project means to the company. By demonstrating the impact that this implementation has for the entire company, you can position the importance of the success (or failure) of the project squarely on the team’s shoulders. This method gives the team a sense of ownership and a sense of responsibility.

  • Show the team why this is exciting. IT project managers sometime lose the sense of excitement wrapped up in technology. Show your team why this project is cool, exciting, and fun, and the implementation will hardly be like work. Remember, IT pros typically love technology—so let them have some fun! It is okay to have a good time and enjoy your work.

  • Show the team members their importance. Teams need to know that their work is valued and appreciated. You can’t fake this stuff. Develop a sense of caring, a sense of pride, and tell your team members when they do a good job. Don’t let them feel like they are as valued as the slave labor used to build the Egyptian pyramids. Let them own the technology, use the technology, and be proud of their work.

{mospagebreak title=Where Do You Live?}

In today’s world, it’s typical of a single project to span the globe. No doubt it’s difficult for team members to feel like they are part of the same team when they’re in London and their counterpart is in Phoenix. Ideally, collocated teams communicate better, work together better, and have a sense of ownership. Reality, however, proves that noncollocated teams exist in many organizations, and the project manager must take extra measures to ensure the project succeeds, regardless of the geographical boundaries. When dealing with noncollocated teams, your team will likely be built around subteams. A subteam is simply a squadron of team members unique to one task within the project or within each geographical area.

For example, as depicted in Figure 6-4, a company is implementing Oracle servers throughout its enterprise. The company has 12 locations throughout the world. Some of the same tasks that need to be accomplished in Madison, Wisconsin, will also need to be performed in Paris, France.

Rather than having one team consisting of six members fly around the globe, the project manager implements 12 subteams. In this example, each subteam has six members. Of the six members, one is the team leader for that location. All of the team leaders report to the project manager, the 73rd member of the team. The team members in each location report to their immediate team leader. Implementation of the Oracle servers at each location will follow a standard procedure for the installation and configuration. The path to success should be the same at each location regardless of geography.

Certainly not all projects will map out this smoothly. Some sites may not have the technical know-how of others, and travel will be required. In other instances, some sites will require more configuration than others, or an increase in security, and other variances. The lesson to be learned is that when teams are dispersed, a chain of command must be established to create uniformity and smooth implementation. The phrase “out of sight, out of mind” often proves true when dealing with dispersed project teams.
Figure6-4.  Subteams are crucial to large implementations. 

Finally, when working with multiple subteams, communication is paramount. Team leaders and the project manager should have regularly scheduled meetings either in person or through teleconferences or videoconferences. In addition, team leaders should have the ability to contact other team members around the globe.

In some instances, team members from different teams will need to work together as well. For example, the communication between two servers has to be configured. The teammates responsible for this step of the configuration will need to coordinate their configurations and installation with the teammates who have identical responsibilities in other locations.

Building Relationships

When an individual joins your team, you and the individual have a relationship: project manager to team member. Immediately the team member knows his role in the project as a team member, and you know your role in relation to the team member as the project manager.

What may not be known, however, is the relationships between team members. You may need to give some introduction of each team member and explain why that person is on the team and what responsibilities that person has. Don’t let your team members just figure things out for themselves. In a large project, it would be ideal to have a directory of the team members, their contact information, and their arsenal of talents made available to the whole team.

On all projects, your team will have to work together very quickly. It’s not a bad idea to bring the team together in some type of activity away from the workplace. Examples of team building exercises:

  • A bowling excursion

  • A hike and overnight stay in the wilds

  • A weekend resort meeting to learn about each other and discuss the project

  • A trip to your local pool hall for an impromptu round of team pool

Team Building Exercises Work

Don’t discount out-of-the-office team-building exercises. Professional team building exercises are available around the globe:

  • Rhythm Journey ( Led by Paulo Mattioli, these team-building programs help teams find and thrive on their synergy.

  • Project Adventure, Inc. ( This company creates exciting staff development programs specifically for your organization.

  • Outdoor Adventure River Specialists ( Get out of the conference room and onto the river where you will become a team.

  • ETD Alliance ( This web site provides more information on experiential training and development. An excellent starting point for locating team-building activities for your company.

Interviewing Potential Team Members

Remember your first big interview? You shined your shoes, made certain your hair was just right, brushed your teeth, and had a breath mint just in case. Your goal was to get the job, so you did your homework: you researched the company, investigated the position, made certain your resume and references were up-to-date, and then gave it your best shot.

Guess what? As a project manager, you may find yourself conducting interviews to woo internal employees onto your project team. You’re mission will be twofold: impressing the candidates while at the same time learning about them to see if they are the right fit for your project team.

Why You Need Interviews

If you are one of the lucky project managers and you get to handpick your project team, you’ll need to interview potential project team members. You, or you and the project sponsor, may discuss which employees should be placed on the project and why. The type of work to be completed will serve as your primary guide for the talent needed on the project. You may also need to look for other attributes such as aptitude, track record, and current workload.

An interview will help you ascertain each prospect’s level of ability before you invite that person onto the project. Or, in the instance the individual has been assigned to the project, an interview helps you learn about her abilities and how they may contribute to the project.

Interviews for IT projects can be completed formally, with resume, or informally conducted over lunch or coffee. Regardless of how the interview is completed, you’ll need to learn if the prospective team member will be able to complete the type of work you have in mind. This means, of course, that you’re looking for a specific type of worker based on your planning.

An interview, even if it’s a simple, informal meeting, allows you to discuss the prospective team member’s abilities and how they can help on the project, and it gives you an insight into the person’s goals, ambitions, and outlook regarding work. Interviews allow project managers to learn about the team members, their assets for the project, and how much of a learning curve may be required if the interviewee is to join the team.

{mospagebreak title=How to Interview}

Your goal when interviewing potential team members (or team members who have been assigned to your project) is to determine what their role in the implementation may be. Any project is only as good as the people completing the work. Your team will be a direct reflection on your own abilities, so this task is one of the most important you’ll have on the entire project.

When interviewing potential team members, you’ll need a job description for each open team position. A job description is needed for two reasons:

  • So that you may share with the prospect what role needs to be filled

  • So that you can focus on the attributes of the ideal team member

A job description is more than a title for a role on the team. A job description details the activities of the role, the scope of the position, the responsibilities, and the working requirements of the team member. A job description should be clear, concise, and easily summarized. For example, here is a job description for the role of a team member responsible for creating logon scripts: Logon script creator—This team member will be responsible for the creation, testing, and implementation of logon scripts for several thousand users. The logon script creator will be responsible for following the logon guidelines as assigned by management, updating current logon script procedures, and documenting the various logon scripts created.

You will also need selection criteria to determine which prospect is the best fit for the team role. The selection criteria will stem from the job description, as it should be a set of requirements that, if met, indicates the individual would be able to wholly complete the tasks of the job description. Selection criteria can include

  • Education

  • Knowledge on the tasks

  • Experience with the tasks

  • Skill sets applicable to the tasks

  • Accomplishments within the company

  • Other essential qualities such as aptitude, leadership, and the ability to work with others

Many project managers balk at completing interviews. Don’t. They are not difficult if you’ve prepared. Interviews can help you properly assign tasks to team members during resource assignment and scheduling. To prepare for an interview, develop good questions. When interviewing, there are several question types that you should know and use:

  • Closed question These questions must be answered with a yes or no. For example: “Have you ever created a batch file before?”

  • Essay questions These questions allow the candidate to tell you information—and they allow you to listen and observe. For example: “Why are you interested in working on this project?”

  • Experience questions These questions focus on the candidate’s behavior in past situations, and they allow you to see how a candidate has acted to predict how he may act in future situations that are similar. For example: “How did you react when a teammate did not complete a task on a past project and you had to do his work for him to complete your own? How was the situation resolved?”

  • Reactionary questions These questions evolve from the candidate’s answers. When you notice a gap or an inconsistency in an answer, use a follow-up question that focuses on the inconsistency without directly calling it a lie. This gives the candidate the opportunity to explain herself better or flounder for an explanation. Reactionary questions also allow you to learn more information that may be helpful on your project. For example: “You mentioned you had experience with Visual Basic. Do you also have a grasp on VBScript?”
  • Questions not to ask In the United States, it’s illegal to ask candidates questions that aren’t related to their capacity to do a job. Basically, avoid questions that center on child care, marital status, religion, racial background, or physical disability. Use common sense, and this area of the interview should not be a problem.

Interviews are a great tool for learning about your potential team members. They are also an opportunity for potential team members to learn about you. Invite the candidate to ask you questions about your role on the project and the importance of the project. When conducting an interview, allow the candidate to do most of the talking so you can do most of the listening.

Managing Team Issues

Without a doubt, people will fight. Fortunately, in most offices, people are mature enough to bite their tongues, try to work peacefully, and, as a whole, strive to finish the project happily and effectively together.

Most disagreements in IT project management happen when two or more people feel very passionate about a particular IT topic. For example, one person believes a network should be built in a particular order, while another feels it should be constructed from a different approach. Or two developers on a project get upset with each other about the way an application is created. Generally, both parties in the argument are good people who just feel strongly about a certain methodology of their work. Figure 6-5 demonstrates how arguments over technical implementations take a project off schedule.


Figure 6-5.  Arguments take a project off schedule and increase costs.

There are, of course, a fair percentage of contrary and pessimistic people in the world. These people don’t play well with others, and are obnoxious at times. They don’t care about other people’s feelings, and much of the time they don’t care about the success of your project.

Unfortunately, you will have to deal with disagreements, troublemakers, and obnoxious people to find a way to resolve differences and keep the project’s momentum.

Dealing with Team Disagreements

In most projects there will be instances when the project team, management, and other stakeholders disagree on the progress, decisions, and proposed solutions within the project. It’s essential for the project manager to keep calm, to lead, and to direct the parties to a sensible solution that’s best for the project. Here are seven reasons for conflict in order of most common to least common:

  • Schedules

  • Priorities

  • Resources

  • Technical beliefs

  • Administrative policies and procedures

  • Project costs

  • Personalities

So what’s a project manager to do with all the potential for strife in a project? There are five different approaches to conflict resolution:

  • Problem solving This approach confronts the problem head-on and is the preferred method of conflict resolution. You may consider this approach as “confronting.” It calls for additional research to find the best solution for the problem, and is a win-win solution. Problem solving can be used if there is time to work through and resolve the issue, and it works to build relationships and trust.

  • Forcing With this approach, the person with the power makes the decision. The decision made may not be best for the project, but it’s fast. As expected, this autocratic approach does little for team development and is a win-lose solution. Forcing is used when the stakes are high and time is of the essence, or if relationships are not important.
  • Compromising This approach requires both parties to give up something. The decision is a blend of both sides of the argument. Because neither party really wins, it is considered a lose-lose solution. The project manager can use this approach when the relationships are equal and it’s impossible for one party to “win.” This approach can also be used to avoid a fight.

  • Smoothing This approach “smoothes” out the conflict by minimizing the perceived size of the problem. It is a temporary solution but can calm team relations and boisterous discussions. Smoothing may be acceptable when time is of the essence or any of the proposed solutions will work. This can be considered a lose-lose situation as no one really wins long-term. The project manager can use smoothing to emphasize areas of agreement between the stakeholders within a disagreement, minimizing the areas of conflict. Smoothing is used to maintain relationships and when the issue is not critical.

  • Withdrawal This approach is the worst conflict resolution tactic because one side of the argument walks away from the problem—usually in disgust. The conflict is not resolved and it is considered a yield-lose solution. The approach can be used, however, as a cooling off period, or when the issue is not critical.

{mospagebreak title=Phases of Team Development}

Teams develop over time, not instantaneously. As a project team comes together, there are likely people on the project team who have worked with one another before just as there may be people on the project team who have never met. Because projects are temporary the relationships among project team members are also often viewed as temporary. The project manager can see, and sometimes guide, the natural process of team development.

The goal of team development is not for everyone to like each other, have a good time, and create life-long friendships. All of that is nice, but the real goal is to develop a team that can accurately and effectively complete the project scope. Within team development there are four stages the project team will pass though:

  • Forming This stage allows the project team members to come together and learn about each other. They feel each other out and find out who’s who and what each other is like.
  • Storming This stage promises action. There’s a struggle for project team control and momentum builds as members vie to lead the project team. It is during this phase that people figure out the hierarchy of the team, and the informal roles of team members.

  • Norming In this stage, the project team’s focus shifts toward the project work. Control on the project team has been established, and people learn to work together.

  • Performing In this stage, the project team members have settled into their roles and are focusing on completing the project work as a team. During this stage, a synergy is developed; this is the stage where high-performance teams come into play.

Project Management Is Not a Democracy

Despite what some feel-good books and inspiring stories would like to have you believe, project management is not a democracy. Someone has to be in charge, and that someone is you, the project manager. The success of the project rests on your shoulders, and it is your job to work with your team members to motivate them to finish the project on schedule.

This does not mean that you have permission to grump around and boss any member of your team. It also does not mean that you should step in and break up any disagreement between team members. Among the team, you should allow some discussion and some disagreement.

This is what teams have to do: they have to work things out on their own. Team members have to learn to work together, to give and take, to compromise. Figure 6-6 shows the power of team decisions. Step back and let the team first work through disagreements before you step in and settle issues. If you step into the mix too early, then your team members will run to you at every problem.

Figure 6-6.   Teams can make decisions on their own.

Ultimately, you are in charge. If your team members cannot, or will not, work out a solution among themselves, you’ll be forced to make a decision. When you find yourself in this situation, there is an approach to working through the problem. Here are recommended steps to conflict resolution:

  1. Attention Meet with both parties and explain the purpose of the meeting: to find a solution to the problem. If the two parties are amicable to each other, this meeting can happen with both parties present. If the team members detest each other, or the disagreement is a complaint against another team member, meet with each member in confidence to hear that person’s side of the story.

  2. Listen Ask the team members what the problem is, allow each to speak their case fully without interrupting, and then ask questions to clarify any of the facts.

  3. Resolve Often if the meeting takes place with both team members, a resolution will quickly boil to the surface. Chances are that you won’t even have to make a decision. People have a way of suddenly wanting to work together when a third party listens to their complaints. They both realize how foolish their actions have been and one, or both, of the team members will cheer up and decide to work together.

  4. Wait If this is not the case in your meeting, don’t make an immediate decision. Tell the team members how important it is to you, and to the project, that they find a way to work together. Sometimes even this touch of direction will be enough for the team members to begin compromising. If they still won’t budge, tell them you’ll think it over and then you will make a decision within a day or two—if the decision can wait that long. By delaying an immediate decision, you allow the team members to think about what has happened and you give them another opportunity to resolve the problem.

  5. Act If the team members will not budge on their positions, then you will have to make a decision. And then stick to it. If necessary, gather any additional facts, research, and investigations. Based on your evidence, call the team members into a meeting again and acknowledge both of their positions on the problem. Then share with them, based on your findings, why you’ve made the decision that you have made. In your announcement don’t embarrass the team member who has been put out by your decision. If the losing team member wants to argue his point again, stop him. Don’t be rude, but stop him. The team members have both been given the opportunity to plead their case, and once your decision has been made, your decision should be final.
Dealing with Personalities

In any organization, you’ll find many different personality types, so it’s likely that there are some people in your organization who just grate on your nerves like fingernails on a chalkboard. These individuals are always happy to share their discontent, their opinion, or their “unique point of view.” Unfortunately, you will have to find a way to work with, or around, these people.

Here are some personality types you may encounter and how you can deal with them:




The Imaginary Leader

These individuals think they are managing the project this week and will be running the company next week. You know the type, always first to raise their hands in school and remind the teacher if she forgot to assign homework.

These people really do want to lead— they just don’t know how! Give them an opportunity by allowing them to conduct an occasional team meeting or organize upcoming activities. If you can, try to show them how to lead with tact instead of their rudeness.

The Mouse

These individuals are afraid of doing any activity on the project without explicit directions from you. They’re so afraid they’ll make a disastrous mistake, they require your guidance on each part of their work.

Encourage these types to take charge of their duties. Tell them that you have confidence in them to do the tasks that you’ve assigned to them. If they do make a mistake, work through it with them to build their confidence.

Your Favorite Uncle (or Aunt)

This persona is the office clown. Always playing gags, streaming toilet paper around someone’s cubicle, telling jokes, and sharing stories around the office. Not only are these types of people great fun, but also they’re great time wasters.

Often these folks don’t have enough to do, and so they assume everyone else is under the same workload that they are. Give these people more assignments, and they’ll have less time to kill. If that doesn’t work, politely share with them that their jovial activities are appreciated, but not always necessary.

The Cowboy

These people love excitement. They are happy to try anything out (like rebooting  a server mid-morning) just to see what happens. Their experience may be great, but their swagger, ten-gallon hat, and stunts aren’t always well thought out.

To deal with the Cowboy types, encourage their enthusiasm but  discourage their ability to make on-the-spot decisions without thinking about the results of their actions. These individuals are generally smart and eager to help, but need a touch more guidance from you. 

The Prune

These sourpusses are as much fun as  pocket full of thumbtacks. They don’t care about your project, think the  technology sucks, and take their hourly breaks every twenty minutes.

Granted, these folks are hard to work  with. They’ve got more problems  personally than the project you are  managing. You can start by befriending them and then sharing the value of their work on the project with their superiors. This transfers some responsibility of the  work onto those Prunes. And tell them to smile a little

{mospagebreak title=Use Experience}

The final method for resolving disputes among team members may be the most effective: experience. When team members approach you with a problem that they just can’t seem to work out between themselves, you have to listen to both sides of the situation.

If you have experience with the problem, then you can make a quick and accurate decision for the team members. But what if you don’t have experience with the technology, and your team members have limited exposure to this portion of the work? How can you make a wise decision based on the information in front of you? You can’t!

You will need to invent some experience. As with any project, you should have a testing lab to test and retest your design and implementation. Encourage your team members to use the testing lab to try both sides of the equation to see which solution will be the best.

If a testing lab is not available, or the problem won’t fit into the scope of the testing lab, rely on someone else’s experience. Assign the team members the duty of researching the problem and preparing a solution. They can use books, the Internet, or other professionals who may have encountered a similar problem. Experience is the best teacher, as Figure 6-7 demonstrates.

A method for resolving issues by testing should be implemented.

Figure 6-7.  A method for resolving issues by testing should be implemented. 

Disciplining Team Members

No project manager likes the process of disciplining a team member—at least they shouldn’t. Unfortunately, despite your attempts at befriending, explaining the importance of the project, or keeping team members on track, some people just don’t, or won’t, care. In these instances, you’ll have little choice other than to resort to a method of discipline.

Within your organization, you should already have a process for recording and dealing with disciplinary matters. The organizational procedures set by human resources or management should be followed before interjecting your own project team discipline approach. If there is no clear policy on team discipline, you need to discuss the matter with your project sponsor before the project begins. In the matter of disciplinary actions, take great caution—you are dealing with someone’s career. At the same time, discipline is required or your own career may be in jeopardy.

As you begin to nudge team members onto the project track, document it. Keep records of instances where they have fallen off schedule, failed to complete tasks, or have done tasks halfheartedly. This document of activity should have dates and details on each of the incidents, and it doesn’t have to be known to anyone but you. Hopefully, your problematic team members will turn from their wicked ways and take your motivation to do their jobs properly. If not, when a threshold is finally crossed, then you must take action.

Following an Internal Process

Within your organization there should be a set process for how an unruly employee is dealt with. For some organizations, there’s an evolution of a write-up, a second write-up, a suspension of work, then ultimately a firing. In other organizations, the disciplinary process is less formal. Whatever the method, you should talk with your project sponsor about the process and involve her in any disciplinary action.

In all instances of disciplinary action, it would be best for you and the employee to have the project sponsor or the employee’s immediate manager in the meeting to verify what has occurred. This not only protects you from any accusations from the disgruntled team member, but it also protects the team member from your disappointment by having a member of management present.

Removal from a Project

Depending on each situation, you may discover that the team member cannot complete the tasks required of him on the project, and removal from the project may be the best solution. In other instances it could be that the team member refuses to complete the work assigned to him for his own reasons and is a detriment to the success of the project. Again, removal from the team may be the most appropriate action.

Removing someone from the project requires tact, care, and planning. A decision should be made between you and the project sponsor. If you feel strongly that this person is not able to complete the tasks assigned to him, rely on your documentation as your guide. Removal of a team member from a project may be harsh, but it’s often required if the project is to succeed.

Of course, when you remove someone from the project, you need to address the matter with the team. Again, use tact. A disruption in the team can cause internal rumblings that you may never hear about—especially if the project team member that was removed was everyone’s best friend. You will have created an instant us-against-them mentality. In other instances, the removal of a troublemaker may bring cheers and applause. Whatever the reaction, use tact and explain your reasons without embarrassing or slandering the team member who was removed.

Using External Resources

There comes a time in every organization when a project is presented that is so huge, so complex, or so undesirable to complete that it makes perfect sense to outsource the project to someone else. In these instances, no matter the reason why the project is being outsourced, it is of utmost importance to find the right team to do the job correctly.

Outsourcing has been the buzz of all industries over the last few years—and certainly IT has been a prevalent reason for companies to “get someone else to do it.” There are plenty of qualified companies in the marketplace that have completed major transitions and implementations of technology—but there are also many incompetents that profess to know what they’re doing only to botch an implementation. Don’t let that happen to you.

Finding an Excellent IT Vendor

Finding a good IT vendor isn’t a problem. Finding an excellent IT vendor is the problem. The tricky thing about finally finding excellent vendors is that they keep so busy (because of their talented crew), they are difficult to schedule time with. So what makes an excellent vendor? Here are some attributes:

  • Ability to complete the project scope on schedule

  • Vast experience with the technology to be implemented

  • References that demonstrate customer care and satisfaction

  • Proof of knowledge on the project team (experience and certifications)

  • Adequate time to focus on your project

  • A genuine interest in the success of your organization

  • A genuine interest in the success of your project

  • A fair price for completing the work

Finding an excellent vendor to serve as your project team, or to be integrated into your project team, is no easy task. Remember, the success of a project is only as good as the people on the project team. It’s not just the name of the integrator, but the quality of the individuals on the integrator’s implementation team that make the integrator great (or not so great). Never forget that fact. Figure 6-8 demonstrates how a vendor can be integrated into your project team. The success of the project is dependent on the payment of the vendor. The project manager should oversee the process.

Figure 6-8.  A vendor must have vision and dedication to the success of the project

Size doesn’t always matter. Those monstrous integrators and technical firms that have popped up in every city over the past few years don’t always have the best people. Some of the best integrators you can find anyway are small, independent firms that have a tightly knit group of technical wizards. Do some research and consider these smaller, above-average tech shops. You may find a diamond in the rough.

To begin finding your integrator, you can use several different methods:

  • References Word of mouth from other project teams within your organization, contacts within your industry, or even family and friends are often the best way to find a superb integrator. A reference does something most brochures and sales letters cannot: it comes from a personal contact and lends credibility.

  • Internet If you know the technology you are to be implementing, hop on the Internet and see whom the manufacturer of the technology recommends. Once you’ve found integrators within your community, peruse their web site. Use advanced searches to look for revealing information about them on other web sites, in newsgroups, or in newspapers, or magazines. Know whom you are considering working with before they know you.

  • Yellow pages When all else fails, open the phone book and call and interview the prospective team over the phone. Prepare a list of specific questions that you’ll need answered. Pay attention to how the phone is answered, what noise is in the background, and how professional and organized the individual on the phone is. Is he rude? Is he happy to help? Take notes and let the other person do much of the talking.

  • Trade shows If you know your project is going to take place in a few months, attend some trade shows and get acquainted with some potential vendors. Watch how their salespeople act. Ask them brief questions on what their team has been doing. Collect their materials and file them away for future review.

  • Previous experience Never ignore a proven track record with a vendor. Past performance is always a sure sign of how the vendor will act with your project.

{mospagebreak title=Interviewing the Vendor}

Once you’ve narrowed your search to two or three vendors, it’s time to interview each one to see to whom the project will be awarded. In the interview process, which the vendor will probably consider a sales call, remind yourself that this is a first date—it’s a chance to find out more information about the vendor.

Document all parts of the meeting: How difficult was it to arrange a meeting time? How polite was the salesperson? Did the salesperson bring a technical consultant to the meeting? All of these little details will help you make an informed decision. In such meetings, pay attention to several things about vendors’ representatives:

  • Do they pay attention to details? Are they on time? Dressed professionally and appropriately for your business? Are their shoes shined and professional? How vendors pay attention to the details in their appearance and presentation to win your business will be an indicator of how they will treat you once they’ve won your business.

  • How organized are their materials? When a salesperson opens his briefcase, can he quickly locate sales materials? Are the brochures and materials well prepared and neat, and not wrinkled or dog-eared? Again, this shows attention to detail, something every project requires from the start.

  • What is their body language saying? Pay attention to how they are seated, where their hands are, and how animated their answers become. A salesperson should show genuine interest in your project and be excited to chat with you. If she seems bored now, she will likely be bored when you call to discuss concerns down the road.

  • What does your gut say? Gut instinct is not used enough. The meeting with the salesperson should leave you with a confident, informed feeling. If your gut tells you something is wrong, then chances are something is. If you’re not 100 percent certain, and you probably shouldn’t be after one meeting, do more research or ask for another meeting with the project integrators.

Looking for a STAR

When you are interviewing the potential integrators, you need to ask direct, hard- hitting questions to slice through their sales spiels and get to the heart of the project. One of the best interview techniques, especially when dealing with

Figure 6-9.  STAR is an interview methodology. 

potential integrators, is the STAR methodology. Figure 6-9 demonstrates that STAR means Situation, Task, Action, Result.

When you use the STAR method, you ask a situational question, such as “Can you tell me about a situation where you were implementing a technology for a customer and you went above and beyond the call of duty?”

The vendor should answer with a specific Situation, followed by the Task of the situation, the Action he took with the task, and then the Results. If the potential vendor doesn’t complete the STAR, add follow-up questions, such as “How did the situation end?” to allow the vendor to finish the STAR question.

This interview process is excellent, as it allows the project manager to discern fact from fiction based on the vendor’s response. Try it!

Know What You Want

When you procure materials or resources from vendors, know exactly what you want from the procurement process. In the Statement of Work (SOW), the seller fully describes the work to be completed and/or the product to be supplied. The SOW becomes part of the contract between the buyer and the seller. It is typically created as part of the procurement planning process, and allows the seller to determine if it can meet the written requirements of the SOW.

Particular industries have different assumptions about what constitutes a SOW. What one industry calls a SOW may be called a Statement of Objectives (SOO) in another. A SOO is a document describing a problem to be solved by the seller. Some specific terms the project manager should be familiar with are shown next.




From seller to buyer. Price is the determining factor in the decision-making process.


From seller to buyer. Price is the determining factor in the decision-making process.


From seller to buyer. Other factors—such as skill sets, reputation, or an idea for the project solution—may be determining factors in the decision-making process.

Invitation For Bid (IFB)

From buyer to seller. Requests the seller provide a price for the procured product or service.

Request For Quote (RFQ)

From buyer to seller. Requests the seller provide a price for the procured product or service.

Request For Proposal (RFP)

From buyer to seller. Requests the seller provide a proposal to complete the procured work or provide the procured product.

Cinching the Deal

When you’ve just about made your decision, it’s time to follow up with a phone call to a few references. Now most references that you’ll be given by the vendor will no doubt be excellent and prepped. Not that anything’s wrong with that; everyone wants to put her best foot forward. Ask the vendor what type of work was performed for the client and when the work was done.

If the work the vendor completed for the client is not directly associated with your project, ask if that vendor can provide you with another reference where similar work was done. In addition, the date of the work should be fairly recent, hopefully within the past six months.

Once you’ve called the references, reviewed your research, and have narrowed the field down to at least two integrators, ask for a quote in response to your Request For Proposal (RFP) by a specific date. Be firm about your deadline, but at least a week from the request is adequate time for a vendor to complete and return a proposal to you.

An RFP is a formal request from your company inviting the client to create a proposal of the work to be completed and provide you with a cost estimate. An RFP does not guarantee anyone the job; it simply formalizes the proceedings of the selection process.

Once you have the vendor’s proposal in place, read it. If the technology to be implemented is not within your grasp or the grasp of anyone in your department, ask for a second opinion. Hire an IT consultant whom you trust, who is somewhat familiar with the technology to be implemented, and have him read the proposals and rate them. Having another set of eyes look over the proposals can help you make a more informed decision.

Once you have made your decision on which vendor the project is awarded to, get the scope of the project in writing, including the price, in the form of a contract. The vendor may, and should, have their own contract that they use whenever implementing technology. Review the vendor’s contract, and if necessary have your attorney look it over and make any amendments or changes.

As painful as contracts are, they protect you and the integrator. Contracts should require that the vendor guarantee their work for a specified amount of time. The technology to be implemented will determine the amount of time expressed in the warranty and the type of guarantee provided.

There are many different types of contracts available. Based on the project work, the expected duration of the project, and the relationship between the buyer and seller, the contract type will be determined. Here’s a quick overview of the common contract types and their attributes:

Contract Type


Risk Issues

Cost Plus Fixed Fee(CPFF)

Actual costs plus profit margin for seller.

Cost overruns represent risk to the buyer.

Cost Plus Percentage of Cost (CPPC)

Actual costs plus profit margin for seller.

Cost overruns represent risk to the buyer. This is a dangerous contract type for the buyer.

Cost Plus Incentive Fee(CPIF) 

Actual costs plus profit margin for seller.

Cost overruns represent risk to the buyer.

Fixed Price (FP)

Agreed price for contracted  product. Can include incentives for the seller.

Seller assumes risk.

Lump Sum

Agreed price for contracted product. Can include incentives for the seller.

Seller assumes risk.

Firm Fixed Price (FFP)

Agreed price for contracted product.

Seller assumes risk.

Fixed Price Incentive Fee (FPIF) 

Agreed price for contracted  product. Can include incentives for the seller.

Seller assumes risk.

Time and Materials(T&M) 

Price assigned for the time and materials provided by the seller. 

Contracts without not-to-exceed (NTE) clauses can lead to cost overruns.

Unit Price

Price assigned for a measurable unit of product or time (for example, $130 for an engineer’s time on the project). 

Risk varies with the product. Time  represents the biggest risk if the amount needed is not specified in the contract.

Before any implementation begins, and once the contract details have been worked out, do some prep work before the project begins. For example, if the project is an operating system upgrade on your servers, create a full backup or system image of your servers. If the technology is a new application to be developed with hooks into your database, assign the appropriate levels of access security to the database for the developers, but don’t give the developers greater permission than what they need to accomplish their work. In other words, prepare for the worst-case scenario, but hope that you never have to use it.

{mospagebreak title=After Hiring the Consultant}

Consultants know what they know—and what they do not know can hurt them and your project. In other words, consultants need to learn about your environment, how your standard operating procedures work, who they should talk to, and so on. Consultants need to know how to get things done within your organization. You cannot throw a consultant into your organization and expect him to have the same level of detail, same level of expertise, and same organizational knowledge that you have. It takes some time and some guidance.

For this reason alone you should demand and require that the consultant attend project meetings, be located close to the project team, and take an active role in meeting the project team members and stakeholders. He needs to get involved in order to be successful and productive. Most consultants and experts, if they are worth anything at all, will be eager to follow these rules and requirements. Often it’s the project manager who wants the consultant to feel comfortable and not get into the mix of things so quickly. This limits the consultant’s ability to contribute.


Interview with Bill Farnsworth

Name: Bill Farnsworth
Title: Senior Partner Strategy Consultant
Company: Microsoft Corporation
Years as an IT project manager: 5

Bill Farnsworth is the Senior Partner Strategy Consultant for Microsoft Consulting Services in Northern California. Bill is a Microsoft Certified Systems Engineer, a Microsoft Certified Trainer, and a Microsoft Solutions Framework Master Trainer. In addition to his Microsoft certifications and experience, Mr. Farnsworth is also a Certified Novell Engineer, a Certified Novell Instructor, and a Certified Internet Architect.

Q: What is the best thing about IT project management?
A: The best thing about IT project management is being able to take a concept to completion. Projects develop for a variety of reasons: to solve a business problem, to address technical issues, to provide proof of concepts, and so on. But all successful IT projects result in a delivered product that, in some way, addresses a need in the company. I like working on the team that delivers that solution.

Q: When you begin to create a team for an IT project, what do you consider first?
A: Ideally, I look for the business problem we are solving by forming the team. This is a critical element in determining the composition of the team. While technical expertise is also critical to the success of an IT project, having representatives on the project team who understand the business problem we are trying to solve is the main consideration.

Q: When a project has been initiated, that is, management has approved it but no formal implementation plans have been created, how soon do you begin to organize a team?
A: Organizing the team as early as possible is very important. Setting an environment where you can best ensure consistency by having the same team evaluate the business problem, define the scope of the project, propose the solution, and then develop and deploy the solution is the best case. By forming the team after some of these steps are already complete, the team may not support or understand some of the underlying justification or may not agree with the scope of the project from the outset. I feel successful projects depend on forming the project team at the earliest point possible.

Q: How does a project manager recruit and motivate team members to be excited about an IT implementation?
A: Project team members like to have a sense of ownership. Owning an identifiable piece of the solution to a problem the company is facing is motivating. Approaching candidates for the team and demonstrating how their contribution will directly affect the team, the project, and the company is an effective way to recruit and motivate team members.

Q: What are characteristics of a successful project manager in regard to creating a project team?
A: A successful project manager needs to be able to motivate, coordinate, and facilitate the activity of the team. No project manager can complete all, or even a significant portion, of the work the team needs to accomplish. The project manager should work to ensure that the project team has what it needs to accomplish its goals. A successful project manager will also seek to prevent herself from being a bottleneck for communication and information with the project team, or within the team itself.

Many failed projects result from a project manager who interacts with team members individually, and then represents team members’ needs, concerns, and input to other team members. Similarly, project managers also place themselves between the project team and the project sponsor for the project, reducing the team’s exposure to the business requirements, and the impact their project will have on the business. Being a bottleneck in these ways is one of the easiest methods to ensure partial or complete failure of a project. Removing yourself as a bottleneck, and ensuring communication and information sharing within and between the project team and the business, is one of the key contributors to a successful project.

Q: What are characteristics you look for in IT professionals when you are considering adding them to a project team?
A: The IT professionals’ technical knowledge is, of course, very important. However, it is just as important to identify team members who are willing and able to participate on the project team. Having a less experienced, more motivated team member could be better than a more experienced, time-restricted member. Looking at team candidates’ time commitments, technical knowledge, organizational understanding, creativity, and ability to work within a team will give project managers some insight into how effective they can be as team members.

Q: What type of questions do you ask potential team members to determine their involvement on the project team?
A: I ask candidates for the project team what their approach to the role will be, what they hope to accomplish, how they deal with ambiguity and conflict, what their contribution to the team would be, and what they see as the perfect team dynamic. These kind of openended questions give me a good insight into how they are going to interact with the other team members and if they see their role as contributing to the solution or more as an obligation of the job. Positive answers to these questions, as opposed to stories about how projects have failed in the past, typically show an optimistic and productive approach to the project.

Q: What can a project manager do when his team does not have the technical expertise to implement the project?
A: There are several options for the project manager in this case. Dependent on the timeframe of the project, training the project team to enhance technical expertise is an option. If this is not a viable option, recruiting additional team members from within the organization who do have the required expertise is also an option. If this is not possible, or the organization does not have individuals with that expertise, finding outside resources, such as contractors, or hiring to fill the need are other options. Which of these options is best for any given project depends on the time and money available to the project manager.

Q: When it comes to decision making, what is the best approach: allow the teams to make the decision or should the project manager take charge?
A: Project managers who make the effort to solicit feedback, engender discussion, and promote shared decision making typically deal with less resistance from the project team as the project proceeds. If the team makes a decision together, through consensus, votes, or other methods, and the project manager has created a team environment that supports those decisions, the team will develop a culture of bringing up issues or disagreement before a decision is made, allowing for issues to be addressed before moving to the next phase of a project. The team must, however, agree that, after the team makes such a decision, this becomes the team decision and that any individual disagreement must be minimized in light of the team decision. In some cases, the team may not be able to come to or agree upon a decision. In these cases, the project manager may need to make the final decision with the understanding that the initial disagreement will have to be abandoned to ensure the successful progression of the project.

Q: What is the most difficult part of creating an IT project team?
A: The most difficult part of creating a project team is identifying the skills, both technical and soft, that will be required in future phases of the project. Without knowing the architecture or other details of the solution, knowing which technical skills might be required or which organizational contacts and relationships could best be leveraged in later phases is difficult. It’s possible to add team members as the project progresses, but having those team members on board as early in the project as possible helps ensure that their skills and contributions can best be utilized.

Q: What methods do you use to deal with conflicts among team members?
A: Conflicts about the direction of the project can usually be addressed by consensus, as long as the idea of consensus has been positioned and agreed to by the team at the very start of the project. If the team “signs on” to the idea of team agreement at each milestone, and that the team’s decision is everyone’s decision after that milestone is reached, conflict is easier to address.

While this approach does not, in any way, eliminate disagreement, it does allow the team to make progress as the team members “agree to disagree,” as long as the majority of the team agrees on one course of action.

Q: How do you address team members who are less than thrilled being involved with the IT project you are in charge of?
A: In a perfect world, those team members would opt out of the project. In reality, taking the roles of less-than-enthusiastic team members and assigning them to other team members can help persuade difficult team members that they can either change their difficult attitudes, if they want to remain in their roles, or they can easily be replaced if their attitudes become counterproductive to the project. The project manager should make it clear that those who contribute to the project, with a positive attitude, will be encouraged to do so; and that those who insist on maintaining a discouraging mood will have their role, and thus their exposure to the rest of the team, reduced or, if possible, eliminated from the project team.

Q: What has been the most rewarding experience you’ve had in regard to creating a project team?
A: The most rewarding experience with regard to forming a project team has been the single project I have run in which the team remained intact for the duration of the project. The initial core team remained on the project from start to finish. The feelings of ownership, accomplishment, and impact were extremely rewarding. In addition, each of the other members became great advocates of the approach we took to the project: a team of peers, decision by consensus, equal valuation of contribution, and so on.

Q: What traps can IT project managers fall into when organizing a project team?
A: One of the easiest traps project managers can fall into is selecting team members based on personal relationship or other characteristics that make them more likely to support the decisions of the project manager. There can be a tendency to select team members, for instance, who support the technology to which the company is migrating. However, this usually prevents the selection of team members who know the legacy system very well, and could contribute a great amount of historical, organizational, and operational information to the project team. Similarly, selecting project team members who will support the project manager under any circumstances prevents the team from benefiting from healthy exchanges of disparate viewpoints and approaches.

Q: What advice can you offer for aspiring IT project managers?
A: Observe project teams you work on and the dynamic that project managers create and maintain. See what works and what doesn’t and make conscious decisions to use what has worked and avoid what hasn’t. Using historically successful techniques borrowed from successful project managers will often help you succeed in projects you manage in the future. Don’t be afraid to develop creative approaches, but don’t force a creative solution to a problem when you have seen another approach work in the same situation in the past.

{mospagebreak title=CHAPTER SUMMARY}

Teamwork is the key to project management success. As a project manager, you must have a team that you can rely on, while at the same time, the team must be able to turn to you for guidance, leadership, and tenacity. When creating a team, evaluate the skills required to complete the project and then determine which individuals have those attributes to offer. Interviewing potential team members allows you to get a sense of their goals, their work ethics, and what skills they may have to offer.

Subteams are a fantastic way to assign particular areas of an IT project to a group of specialists or to a geographically based implementation. When creating subteams, communications from the project manager and the team leaders is essential. Subteams require responsible leaders on each team, and a reliable, confident project manager.

When disagreements flair among team members, you must have a plan in place before the disagreement happens. Document problems with troublesome team members in the event that a team member needs to reprimanded or removed from the team. The project sponsor should be kept abreast of the situation as the project continues.

Should the scope of the project be beyond the abilities of the internal team, the project can be outsourced. When outsourcing the project, you need to use careful consideration in your selection of an integrator. Project managers should rely on references of vendors, their ability to work with the technology, gut feelings, and word of mouth to make a decision.

Building a project team is hard work, but it is also an investment in the success of the project. Once again, the success of any project is only as good as the members on the project team.


1. When creating a project team, why must the project manager know the skills of each of the prospective team members?

A. It helps the project manager determine the budget of the project.

B. It helps the project manager determine how long the project will take.

C. It helps the project manager determine if he wants to lead the project.

D. It helps the project manager assign tasks.

2 . Of the following, which two are methods the project manager can use to assess internal skills?

A. Prior projects

B. Reports from other project teams

C. Recommendation of management

D. Projects the project manager has worked on

3 . When requesting an internal resume to recruit team members, why must the project manager use extreme caution?

A. Resumes have the connotation of getting, or keeping, a job.

B. Resumes have the connotation of pay raises.

C. Resumes have the connotation of relocating users.

D. It is illegal, within the US, to ask for a resume once the individual has been hired.

4. Of the following, which one is not an example of team development?

A. Training for the project work

B. Industry certifications

C. Team events such as rafting

D. Forming, storming, norming, and performing

5. When is training considered an expense?

A. When the cost of training is beyond the budget of an organization

B. When the time it takes to complete the training increases the length of the project beyond a reasonable deadline

C. When the training experience does not increase the ability of the team to implement the technology

D. When the training experience does not increase the individual’s salary

6. The project team is in disagreement over which OS to use on a new server. The project manager tables the issues and says the decision can wait until next week. This is an example of which project management negotiating technique?

A. Confrontive

B. Yielding

C. Coercive

D. Withdrawal

7. What is the best way to create reliable, hard-working teams?

A. Fire the team members who do not perform.

B. Set the example by being reliable and hard working.

C. Promise raises to the hardest working team members.

D. Promise vacation days for all that are hard working.

8 . How is camaraderie created on a team?

A. By years of working together

B. By creating an us-against-them mentality

C. By the experiences of the team as a whole

D. By creating friendships on the team

9 . Why is the WIIFM principle a good theory to implement with project management?

A. It shows the team how the success of the project is good for the whole company.

B. It shows the team how the success of the project is good for management.

C. It shows the team how the success of the project will make the company more profitable.

D. It shows the team how the success of the project will impact each team member personally.

10. What is a subteam?

A. A specialized team that is assigned to one area of a large project or to a geographical area

B. A specialized team that will be brought into the project as needed

C. A collection of individuals that can serve as backup to the main project team

D. A specialized team responsible for any of the manual labor within a project

11. What is the key to working with multiple subteams?

A. A team leader on each subteam

B. Multiple project managers

C. Communication between team leaders and the project manager

D. Communication between team leaders, the project manager, and the project sponsor

12. Of the following, which is a good team building exercise?

A. Introductions at the kickoff meeting

B. A weekly lunch meeting

C. A team event outside of the office

D. Team implementation of a new technology over a weekend

13. Why should a project manager conduct interviews for prospective team members?

A. To determine if a person should be on the team or not

B. To learn what skills each team member has

C. To determine if the project should be outsourced

D. To determine the skills required to complete the project

14. What is the purpose of conducting interviews of existing team members? Choose two:

A. To determine if the project should be outsourced

B. To determine the length of the project

C. To determine the tasks each team member should be responsible for

D. To determine if additional team members are needed

15. When a project manager asks a vendor for an RFP, what is he asking for?

A. A Request For Proposal so a decision can be made based on price.

B. A Request For Proposal so a decision can be made based on the proposed solution to the WBS.

C. A Request For Proposal so a decision can be made based on the proposed solution for the SOW.

D. A Request For Proposal so a decision can be made based on the proposed schedule.

{mospagebreak title=CHAPTER EXERCISES}

Exercise 1

In this exercise you will create a job description for a web application developer from a project scenario. You will be given prompts to guide you on the creation of the job description.

Scenario: You are the project manager for Cardigan Adhesives Corporation. You have been assigned as the project manager for the development of the new corporate Internet site. The web site should be easy to navigate for all guests. In addition, the web site will have an application that will query a database to report on inventory, cost of goods available, and online ordering.

Answer the following questions to begin creating the job description for a web developer. If you are uncertain of the answers, use the Internet to research web developers and the types of activity they are required to do.


Your Answer

What is the primary purpose of this role on the team?


What type of software will the team member be using to create the application?


What type of database is being queried?


To whom will the team member report?


What other activities will the team member be responsible for?


What are some personal traits that this person should have?


Based on your answers, create a job description that is appropriate for a web developer on this project. A solution appears at the end of this chapter.

Exercise 2

In this exercise you will create a 12-question interview to assess the skills of a prospective team member using the project scenario provided. Prompts will assist you to create key questions for your interview. On questions that you find relevant, create reactionary questions for the interviewees’ expected answers.

Scenario: You are the project manager for Cardigan Adhesives Corporation. You have been assigned as the project manager for the development of the new corporate Internet site. The web site should be easy to navigate for all guests. In addition, the web site will have an application that will query a database to report on inventory, cost of goods available, and online ordering.


Your Question for the Prospective Team Member Interview

How important is the level of experience for this job?


How important is it to you that this person know web development software?




How important is an industry certification for this role?


How important is the ability of the individual to work with web design software?


How important is experience with databases for this project?


What are some web technology requirements and how does this relate to the interviewee?


How important are security concepts on a web application?


Will the e-commerce portion of the project be done in-house or outsourced?


What type of personal traits are you looking for in this role?


Create the next two questions that are relevant to the position on your own:




{mospagebreak title=Quiz Answers}

  1. D. The project manager should know in advance of the WBS creation the skills of the team members so that she can assign tasks fairly. A skills assessment also helps the project manager
  2. A, C. Experience is always one of the best barometers for skills assessment. If the prospective team member has worked on similar projects, that person should be vital for the current implementation. Recommendations from management on team members can aid a project manager in assigning tasks and recruiting new team members.
  3. A. Resumes can show the skill sets of prospective team members, but they have a tendency to imply getting or keeping a job. In lieu of resumes, project managers can use a listing of accomplishments and skills to determine the talent of recruits.

  4. B. Industry certifications are a valuable source for proving that individuals are skilled and able to implement the technology. Certifications on their own, however, do not provide team development.

  5. C. Training is an expense rather than an investment when the result of the training does not increase the team’s ability to complete the project. A factor in determining if training should be implemented or not is the time of training and its impact on a project’s deadline.

  6. D. This is an example of withdrawal. While this method often is the failure to effectively come to a decision, it can be effective when a decision is not needed immediately. This approach can allow the team to “cool off” on the decision and move into other pressing matters.

  7. B. A leader leads best by doing. By setting the example of being hard working, reliable, and available to your team members, you will show them the type of workers you hope they are as well. Leading by fear, or through an iron-fist mentality, should not be an option in today’s workplace.

  8. C. Camaraderie is an element that can’t be forced upon a team. Years of working together, friendships, and us-against-them mindsets do not create camaraderie. The experience of the team as a whole is where camaraderie stems from.

  9. D. WIIFM, the “What’s In It For Me” theory, personalizes the benefits of the project for each team member. By demonstrating what the individual will gain from the project, you help increase that team member’s sense of ownership and responsibility to the project.
  10. A. Subteams are not less important than the overall project team. Subteams are collections of specialists who will be responsible for a single unit of the project plan, or a geographical structure.
  11. C. When working with multiple subteams, the project manager and the team leader of each subteam must have open communications. The subteams should follow the change of command through each team leader, to the project manager, and the project manager to the project sponsor.
  12. C. A good team building exercise is something out of the ordinary that gels the ability of the team to work together. Luncheons and introductions at meetings are standard fare that don’t always bring a team closer together.
  13. A. Interviews of prospective team members allow the project manager to determine if those people have assets to offer to a project. Because the team members are prospective, the project manager can conduct a typical interview using formal or informal approaches to ascertain the level of skills from each prospect.
  14. A, C. In some instances, interviews can determine if the project, or more likely portions of the project, should be outsourced because of the skills required or the timeline of the project. Interviews of the existing team members, if they’ve been assigned to the project manager, can help the project manager determine the tasks each team member can be responsible for.
  15. C. An RFP is a Request For Proposal to the SOW, or statement of work. The RFP typically means the buyer is open to recommendations and solutions from the seller. The decision to buy is not made on cost alone.


Exercise 1: Possible Solution



What is the primary purpose of this role on the team?

Web developer

What type of software will the team member be using to create the application?

ColdFusion, Java, Visual J++, or any other web development program

What type of database is being queried?

ColdFusion, Oracle, SQL, Lotus Domino, or others

To whom will the team member report?

The project manager

What other activities will the team member be responsible for?

Working with the database designer, the database administrator, the web developer, and other team members

What are some personal traits that this person should have?

Hard working, fast learning, dedicated, focused

Your job description should be something like this:

Web developer: This highly skilled, focused individual will beresponsible for creating a commerce-enabled application that  communicates with a SQL database. Experience in Visual J++,  XML, and SQL Transaction statements are a must. Experience working with SQL or Dreamweaver a plus.


Exercise 2: Possible Solution


Your Question for the Prospective Team Member

How important is the level of experience for this job?

How many years have you been working as an application developer?

How important is it to you that this person know web development software?

What type of web development applications do you work with?


Can you give an example of a particular web development project where you found a faster or better solution?

How important is an industry certification for this role?

Have you ever taken any classes on the applications you work with? Reactionary question: Have you earned any certifications from the associated vendor?

How important is the ability of the individual to work with web design software?

Have you ever designed any of your own web pages? 
Reactionary question: What web software did you use to design the site?

How important is experience with databases for this project?

Have you ever worked with SQL (or the database you specified for this job description)?

What are some web technology  requirements and how does this relate to the interviewee?

What type of web servers have you worked with? For example, UNIX, IIS, Linux?

How important are security concepts on a web application?

What type of security mechanisms have you worked with?
For example, how did you address security with other commerce-enabled designs?

Will the e-commerce portion of the project be done in-house or outsourced?

Have you implemented e-commerce applications from the ground up?
Reactionary question: If so, what are some examples?

What type of personal traits are you looking for in this role?

What’s your average day like?
Reactionary question: How often have you worked overtime?

You create the next two questions that are relevant to the position: 

What’s the best thing about web development?


If you could change one thing in web design, what would it be?

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye