Are you in? Confirming your team members’ participation

To confirm the identities of the people who’ll work to support your project, you have to verify that specific people are still able to uphold their promised commitments and, if necessary, recruit new people to fulfill any remaining gaps.

As you contact the people who will support your project, be sure to do the following:

1. Inform them that your project has been approved and when the work will start.

   Not all project plans get approved. You rarely know in advance how long the approval process will take or how soon your project can start. Inform team members as soon as possible so they can schedule the necessary time.

2. Confirm that they’re still able to support your project.

   People’s workloads and other commitments may change between the time you prepare your plan and your project’s approval. If a person is no longer able to provide the promised support, recruit a replacement as soon as possible (see the later section “Filling in the blanks” for guidelines).

3. Explain what you’ll do to develop the project team and start the project work.

   Provide a list of all team members and others who will support the project. Also mention the steps you’ll take to introduce members and kick off the project.

4. Reconfirm the work you expect them to perform, the schedules and deadlines you expect them to keep, and the amount of time you expect them to spend on the work.

   Clarify specific activities and the nature of the work to ensure everyone is on the same page.

Depending on the size and formality of your project, you can use any format from a quick email to a formal work-order agreement to share this information with the people who will be involved in your project.

As Figure 13-1 illustrates, a typical work-order agreement includes the following information:

• Identifiers: The identifiers include the project name, project number, and work breakdown structure (WBS) code and component name (for more on WBS, see Chapter 6). The project name and number confirm that your project is now official. You use the WBS code and component name to record work progress as well as time and resource charges.
• Work to be performed and deliverables or results to be produced: These details describe the different activities and procedures involved in the project, as well as outputs of the project.
• Activity start date, end date, and number of hours to be spent: Including this information reaffirms:
  • The importance of doing the work within the schedule and budget
  • Acknowledgment from the person who’ll do the work that they expect to do the described work within these time and resource constraints
  • The criteria you’ll use to assess the person’s performance
• Written approvals from the person who’ll do the work, their supervisor, and the project manager: Including these written approvals increases the likelihood that everyone involved has read and understood the project’s elements and is committed to support it.

Be sure you specify all this information when reconfirming a person’s commitment to your project. The longer you wait to specify these details, the greater the chances are that the person won’t provide the support you had hoped for.

If you choose not to use a formal work-order agreement, be sure to write down all key information that clarifies your agreement and document approvals from the team member and their supervisor by email or some other durable means. Asking for signed approvals encourages people to consider carefully before they make any commitments and serves as a reference and reminder of exactly what was promised.

Assuring that others are on board

Other people may also play a role in your project’s success, even though they may not officially be members of your project team. Two such groups are drivers (people who have a say in defining the results of your project) and supporters (people who will perform a service or provide resources for your team).

Two other special stakeholders are your project champion and your project executive sponsor. Both are people in high positions in the organization who strongly support your project; who will advocate for your project in disputes, planning meetings, and review sessions; and who will take necessary actions to help ensure your project’s success (see Chapter 4 for more on these different types of project stakeholders).

Contact your project champion and all other drivers and supporters to:

• Inform them that your project has been approved and when work will start.
• Reaffirm your project’s objectives.
• Confirm with identified drivers that the project’s planned results still address their needs.
• Clarify with supporters exactly how you want them to help your project.
• Develop specific plans for involving each stakeholder throughout the project and keeping them informed of progress.

Some people will be interested in your project but won’t define its planned results or directly support your efforts. As you identify these observers, as they’re often called, choose those individuals you want to keep informed of your progress throughout the project and plan how you’ll do so (see Chapter 4 for tips on how to identify project observers and Chapter 15 for different ways to keep people informed about your progress).

Filling in the blanks

If your plan identifies proposed project team members only by job title, position description, or skills and knowledge (and not by specific names), you have to find actual people to fill the specified roles. You can fill the empty roles by assigning responsibility to someone already on your organization’s staff, by recruiting a person from outside your organization, or by contracting with an external organization. If you don’t have the authority to hire a person yourself, work with the functional manager to whom the new hire will report.

Whichever method you choose, prepare a written description of the activities you want each person to perform. This description can range from a bulleted list in email for informal projects to a written job description for more formal ones.

Write down your needs for each category of personnel separately. At a minimum, include the following information in your role descriptions:

• Project name, number, start date, and projected end date
• Necessary skills and knowledge
• Supervision to be provided
• Activities to be performed and start and end dates
• Anticipated level of effort

If you plan to look inside your organization to recruit team members for roles not yet filled, do the following:

• Identify potential candidates by working with functional area managers and your human resources (HR) department.
• Meet with the candidates to discuss your project, describe the work involved, and assess their qualifications.
• Choose the best candidates and ask them to join your team.
• Document the agreements you make with the new team members.

Also, if you plan to obtain the support of external consultants, work with your organization’s contracts office. Provide the contracts office with the same information that you provide your HR office. Review the contract document before your contracting officer signs it.

In addition to filling your empty team member roles, work with people in key organizational units to identify people, other than team members, who will support your project (for example, a contracts specialist or a procurement specialist, as long as they aren’t officially on your project team). After you identify these people, do the following:

• Meet with them to clarify your project’s goals and anticipated outputs and the ways in which they will support your performance.
• Develop plans for involving them and keeping them informed of progress throughout your project.

Depending on the size and structure of your organization, you may be able to utilize qualified, available resources from other areas of the company who may be “on the bench” waiting for their next project to start. It’s quite possible that many of the skills you need to round out your team are transferrable skills that are not specific to your project or your organizational unit.

For example, let’s say your organization, a contract e-commerce website development firm, is structured by business units aligned to specific markets within the retail industry, such as apparel, home goods and furniture, sporting goods, electronics, and so on. You are tasked with initiating a project within your business unit to develop an e-commerce website for a well-known online apparel retailer. However, you have recently learned that all of your business unit’s Java developers are assigned to other long-term apparel projects for the next six months. Your client expects their website to be live in six months! In speaking with your colleagues in other business units, you learn that they are not experiencing the same resource drought and, in fact, are even considering the need to downsize their existing staff. Does it really matter, in this particular example, if the Java developers assigned to your team routinely work on apparel projects or would competent (and available) developers from the electronics or sporting goods business units have the same skills and ability to translate your project’s requirements into technically-sound Java software code? With an open mind and some creative thinking, you may be able to turn this scenario into a win-win for everyone!

Reviewing the approved project plan

As soon as people join the team, have them review the approved project plan to reinforce the project’s goals, clarify the work planned, confirm the feasibility of time and resource estimates, and identify any potential problems. Meet as a group to discuss people’s thoughts and reactions after they’ve reviewed the plan.

Team members who contributed to the proposal can remind themselves of the project’s background and purpose, their planned roles, and the work to be done. They can also identify situations and circumstances that may have changed since the proposal was prepared and then review and reassess project risks and risk management plans.

New team members can understand the project’s background and purpose, find out about their roles and assignments, raise concerns about timeframes and budgets, and identify issues that may affect the project’s success.

Developing team and individual goals

Team members commit to your project when they believe their participation can help them achieve worthwhile professional and personal goals. Help team members develop and buy into a shared sense of the project goals by doing the following:

• Discuss the reasons for the project, its supporters, and the impact of its results (see Chapter 5 for a discussion of how to identify the needs your project will address).
• Clarify how the results may benefit your organization’s clients.
• Emphasize how the results may support your organization’s growth and viability.
• Explore how the results may impact each team member’s job.

Encourage people to think about how their participation may help them achieve personal goals, such as acquiring new skills and knowledge, meeting new people, increasing their visibility in the organization, and enhancing their opportunities for job advancement. Obviously, projects aren’t only about helping team members achieve personal benefits; however, when team members can realize personal benefits while performing valued services for the organization, the members’ motivation and commitment to project success will be greater (see Chapter 16 for more on how to create and sustain team member motivation).

Specifying team member roles

Nothing causes disillusionment and frustration faster than bringing motivated people together and then giving them no guidance on how to work with one another. Two or more people may start doing the same activity independently, and other activities may be overlooked entirely. Eventually, these people gravitate toward tasks that don’t require coordination, or they gradually withdraw from the project to work on more rewarding assignments.

To prevent this frustration from becoming a part of your project, work with team members to define the activities that each member works on, the nature of their roles, and the impact of their contributions to the team as a whole. Possible team member roles include the following:

• Primary responsibility: Has the overall obligation to ensure the completion of an activity.
• Secondary or supporting responsibility: Has the obligation to complete part of an activity.
• Approval: Must approve the results of an activity before work can proceed.
• Consultation resource: Can provide expert guidance and support if needed.
• Required recipient of project results: Receives either a physical product from an activity or a report of an activity.

If you prepared a responsibility assignment matrix (RAM) as part of your project plan, use it to start your discussions of project roles with your team members (see Chapter 12 for details on how to use the RAM). Make sure you don’t just present the RAM and don’t assume that everyone knows what it is and how to interpret it. Take the time to encourage questions and concerns from team members until they’re comfortable that the roles are feasible and appropriate. Revise the RAM as needed throughout your discussions.

Defining your team’s operating processes

Develop the procedures that you and your team will use to support your day-to-day work. Having these procedures in place allows people to perform their tasks effectively and efficiently; it also contributes to a positive team atmosphere. At a minimum, develop procedures for the following:

• Communication: These processes involve sharing project-related information in writing and through personal interactions. Communication procedures may include:
  • When and how to use email to share project information
  • Which types of information should be in writing
  • When and how to document informal discussions
  • Who is responsible for key communications (i.e., status reports, project plan and budget updates, etc.)
  • How to set up regularly scheduled reports and meetings to record and review progress
  • How to address special issues that arise
• Decision-making: These processes involve deciding among alternative approaches and actions. Develop guidelines for making the most appropriate choice for a situation, including consensus, majority rule, unanimous agreement, and decision by technical expert. Also develop escalation procedures — the steps you take when the normal decision-making approaches get bogged down.
• Conflict resolution: These processes involve resolving differences of opinion between team members (see the later section “Resolving conflicts” for details on two conflict resolution procedures).

Supporting the development of team member relationships

On high-performance project teams, members trust each other and have cordial, coordinated working relationships. But developing trust and effective work practices takes time and concerted effort.

Help your team members get to know and be comfortable with one another as soon as your project starts by encouraging them to do the following:

• Work through conflicts together (see the next section for more on conflict resolution).
• Brainstorm challenging technical and administrative issues.
• Spend informal personal time together, such as having lunch or participating in non-work-related activities after hours.

Resolving conflicts

With most projects, the question isn’t if disagreements will occur between team members; it’s when. So you need to be prepared to resolve those differences of opinion with a conflict resolution plan that includes one or both of the following:

• Standard approaches: Normal steps that you take to encourage people to develop a mutually agreeable solution
• Escalation procedures: Steps you take if the people involved can’t readily and reasonably resolve their differences in a timely manner

All together now: Helping your team become a smooth-functioning unit

When team members trust each other, have confidence in each other’s abilities, can count on each other’s promises, and communicate openly, they can devote all their efforts to performing their project work instead of spending their time dealing with interpersonal frustrations.

What follows is a description of one widely-accepted project team development model, called the “Tuckman Ladder.” However, other development models exist that could be equally or better aligned with your, your team’s, or your organization’s style. Most of the methods cover similar stages of team development with minor differences, so familiarize yourself with more than one and choose the one that speaks to you. This book reviews the Tuckman Ladder model.

Help your team achieve this high-performance level of functioning by guiding it through the following stages:

• Forming: This stage involves identifying and meeting team members and politely discussing project objectives, work assignments, and so forth. During this stage, you share the project plan, introduce people to each other, and discuss each person’s background, organizational responsibilities, and areas of expertise.

• Storming: This stage involves raising and resolving personal conflicts about the project or other team members. As part of the storming stage, do the following:

  • Encourage people to discuss any concerns they have about the project plan’s feasibility and make sure you address those concerns.
  • Encourage people to discuss any reservations they may have about other team members or team members’ abilities.
  • Focus these discussions on ways to ensure successful task and project performance; you don’t want the talks to turn into unproductive personal attacks.

  Initially, you can speak privately with people about issues you’re uncomfortable bringing up in front of the entire team. Eventually, though, you must discuss their concerns with the entire team to achieve a sense of mutual honesty and trust.

• Norming: This stage involves developing the standards and operating guidelines that govern team member behavior. Encourage members to establish these team norms instead of relying on the procedures and practices they use in their functional areas. Examples of these norms include:

  • How people present and discuss different points of view: Some people present points of view politely, while others aggressively debate their opponents in an attempt to prove their points and, sometimes more accurately, disprove others’ points.
  • Timeliness of meeting attendance: Some people always show up for meetings on time, while others are habitually 15 minutes late.
  • Participation in meetings: Some people sit back and observe, while others actively participate and share their ideas.

  At a team meeting, encourage people to discuss how team members should behave in different situations. Address the concerns people express and encourage the group to adopt team norms. Establish ground rules for what is and is not appropriate conduct during meetings, including whether or not it is acceptable for meeting attendees to read and send emails or if side conversations are allowed while someone is addressing the entire room.

• Performing: This stage involves doing project work, monitoring schedules and budgets, making necessary changes, and keeping people informed.
• Adjourning: This stage involves the completion of project work, formal closure of the project, and the official release of resources to focus on other projects and tasks.

As you guide your team through these developmental stages, keep in mind the following guidelines:

• Your team won’t automatically pass through these stages; you’ll have to guide them. Left on their own, teams often fail to move beyond the forming stage. Many people don’t like to confront thorny interpersonal issues, so they simply ignore them. Your job is to make sure your team members address what needs to be addressed and become a smooth-functioning team.
• Your involvement as project manager in your team’s development needs to be heavier in the early stages and lighter in the later ones. During the forming stage, you need to take the lead as new people join the team. Then, in the storming stage, you take a strong facilitative role as you guide and encourage people to share their feelings and concerns. Although you can help guide the team as it develops its standards and norms during the norming stage, your main emphasis is to ensure that everyone participates in the process. Finally, if you’ve navigated the first three stages successfully, you can step back in the performing stage and offer your support as the team demonstrates its ability to function as a high-performing unit. Your involvement will increase again in the adjourning stage, as many typical project-closure tasks are your responsibility.
• On occasion, you may have to revisit a stage you thought the team had completed. For example, a new person may join the team, or a major aspect of the project plan may change.
• If everything goes smoothly on your project, it doesn’t matter whether the team has successfully gone through the forming, storming, and norming stages. But when the project runs into problems, your team may become dysfunctional if it hasn’t progressed successfully through each stage. Suppose, for example, that the team misses a major project deadline. If team members haven’t developed mutual trust for one another, they’re more likely to spend time searching for someone to blame than working together to fix the situation.
• As the project manager, you need to periodically assess how the team feels it’s performing; you then have to decide which, if any, issues the team needs to work through. Managing your team is a project in and of itself!

Selecting and preparing your tracking systems

Effective project control requires that you have accurate and timely information to help you identify problems promptly and take appropriate corrective action. This section highlights the information you need and explains how to get it.

Throughout your project, you need to track the following key performance indicators, or KPIs:

• Schedule achievement: The assessment of how well you’re meeting established dates.
• Personnel resource use: The levels of effort people are spending on their assignments.
• Financial expenditures: The funds you’re spending for project resources.

See Chapter 14 for a detailed discussion of the information systems you can use to track your project’s progress.

If you use existing, enterprise-wide information systems to track your project’s schedule performance and resource use, set up your project on these systems as follows (see Chapter 14 for information on how to decide whether to use existing information systems to support your project’s monitoring and control):

• Obtain your official project number. Your project number is the official company identifier for your project. All products, activities, and resources related to your project are assigned that number. Check with your organization’s finance department or project management office to find out your project’s number and check with your finance or information technology (IT) department to determine the steps you must take to set up your project in the organization’s financial tracking system, labor recording system, and/or activity tracking system.
• Finalize your project’s work breakdown structure (WBS). Have team members review your project’s WBS and make any necessary changes or additions. Assign identifier codes to all WBS elements (refer to Chapter 6 for a complete explanation of the WBS).

• Set up charge codes for your project in the organization’s labor tracking system. If team members record their labor hours by projects, set up charge codes for all WBS activities. Doing so allows you to monitor the progress of individual WBS elements, as well as the total project.

  If your organization’s system can limit the number of hours for each activity, enter those limits (see the later section “Setting your project’s baseline” as well as Chapter 14 for how to establish targets for your project’s schedule, resource needs, and budget). Doing so ensures that people don’t inadvertently charge more hours to activities than your plan allows.

• Set up charge codes for your project on your organization’s financial system. If your organization tracks expenditures by project, set up the codes for all WBS activities that have expenditures. If the system can limit expenditures for each activity, enter those limits.

Establishing schedules for reports and meetings

To be sure you satisfy your information needs and those of your project’s stakeholders, set up a recurring schedule of status reports you’ll prepare and meetings you’ll hold during the project. Planning your communications with your stakeholders in advance helps ensure that you adequately meet their individual needs and allows them to reserve time on their calendars to attend the meetings.

Meet with project stakeholders and team members to develop a schedule for regular project meetings and progress reports. Confirm the following details:

• What reports will be issued
• Which meetings will be held and what their specific purposes will be
• When reports will be issued and when meetings will be held
• Who will receive the reports and attend the meetings, including who is considered mandatory and optional
• Which formats the reports and meetings will be in and what they’ll cover

See Chapter 15 for a discussion of the reports and meetings you can use to support ongoing project communications.

Setting your project’s baseline

The project baseline is the version of your project’s plan that guides your project activities and provides the comparative basis for your performance assessments. At the beginning of your project, use the plan that was approved at the end of the organizing-and-preparing stage, modified by any approved changes made during the carrying-out-the-work stage, as your baseline (see Chapter 1 for a discussion of the project life cycle stages). During the project, use the most recent approved version of the project plan as your baseline (see Chapter 14 for more discussion on setting, updating, and using your project’s baseline to control your project).