Project Communication and Collaboration

Keeping It Smooth

In this chapter, we’re going to look at the skills that help you keep everything running smoothly. First, we’ll consider the importance of communication and collaboration, and discuss some tips to help you communicate effectively and foster a collaborative environment for your team.

We’ll then look at managing change (one of the biggest challenges for any project manager!), providing you with tools and techniques to help you make the right decision as often as possible—and to recover gracefully from any missteps.

Communication and Collaboration

Communication is about imparting and receiving information, while collaboration is about working together as effectively as possible. In this section, we’ll not only talk about how to keep the project’s stakeholders informed, but also about how to help your project team members work together both within the team, and with the stakeholders, customers, and management.

Communication

Communication is an everyday part of everyone’s life—so why does it deserve attention in project management? Good communication can make a project, just as bad communication can destroy it. If people involved in your project are confused, trouble is on the horizon.

The only thing worse than confusion is when there is absolute clarity … over different versions of events! If you and your team members believe that installing the new computer system and software is what your project is all about, but the customer thinks you have promised to eradicate all paperwork, sooner or later this mismatch of expectations is going to become a big problem.

Being able to communicate effectively is a key skill for any project manager. Communication isn’t just talking and emailing, though—good communication involves three key aspects: form, method, and content.

Form

In your previous interactions with people, you’ll already have experienced the various forms of communication. You’ve undoubtedly experienced interpersonal communication: one on one communication, including conversations, arguments, and negotiations. You’ve probably seen or given presentational communication, typically in one to many situations, where one person at a time communicates to a group. And you’ll know all about many to many communications, which ranges from the productive team discussion to the mini-riots in which both sides become increasingly emotional (think of discussing politics around the dinner table).

Each of these forms of communication can involve one- or two-way communication. In most situations, you’ll want interaction, so you’ll probably need two-way communication. Occasionally, though, you’ll just want to impart information, in which cases one-way communication may be just fine.

It’s important to remember that the form of communication isn’t the only element that will determine how interactive communication will be—even if you set up a meeting with the intent that it to be a two-way discussion, other factors can cause one-way communication to occur. For instance, if one group has a great deal of power over the other (as in the case of student-teacher meetings), the less powerful group may be hesitant to speak.

That said, there are some general guidelines that you can use: If it’s personal, individual, or sensitive, deal with it one-to-one.

Whether Jim’s ongoing illness is causing project delays, you are concerned that Ankur won’t want to work on the new burger chain contract because of his religious beliefs, or simply that Alex is being promoted, these situations—and others like them—should be dealt with individually first, in a one-to-one meeting, rather than in a group setting.

Separate meetings that have different purposes.

If you want to update stakeholders on the progress of the project, inviting them to the team meeting in which team members will discuss the achievability of the project deadline isn’t smart. Run a separate, short presentation for the stakeholders, and make time for a lengthier team meeting to encourage open discussion—without senior management in the room getting upset.

Choose the appropriate format for your purpose.

Consider what you’re trying to achieve and choose the best form for that purpose. Presentations are good for informing groups of people of progress, a decision, or an upcoming change. They aren’t a good format for discussion—if you want two-way communication, hold a meeting instead. Similarly, turning the team meeting into a series of one-to-one discussions with individual members isn’t a productive use of anyone’s time except yours, so schedule mini-meetings instead, or just catch up over coffee!

Method

Every day, we’re faced with multiple decisions about which communication method we should use—phone, email, voicemail, instant messenger, letter, fax, meeting, video conference, audio conference, desktop sharing, text message (SMS), podcasts, video casts, blogs, wikis, and more.

When you’re choosing a method of communication, there are some basic considerations that you should review, such as whether the method promotes a push approach (that is, information is pushed out to the receiver, as it is via an email or presentation), or a pull approach (in which the person who needs information asks for or collects it when it’s needed, as is the case with blogs, noticeboards, and so on). Also keep in mind that some methods support different forms of communication better than others. For instance, email is a good method for one-to-one and one-to-many communication, but terrible for many-to-many discussions or conversations.

Possibly the most complex consideration when you’re selecting a method of communication involves assessing people’s expectations of that method. Some people view email as a high priority and will deal with it accordingly; others believe that it’s a low-urgency form of communication, and that if something’s important, people will pick up the phone and talk to one another.

As an example, my personal preference for the hierarchy of communication methods can be explained like this. The best way to get hold of me is always email. Instant messenger is probably a close second, but unlike some people, I’m not logged in all the time, so an email still may be read faster. I let my phone go to voicemail often and will frequently check my email before I access my voice messages.

Faxes get routed to my email inbox, but it can take me weeks to get to real hard copy mail, partly because I travel so much that I’m seldom in the office, and partly because I expect anyone with an important question to email me! Planned face-to-face or virtual meetings (whether they’re audio or video conferences) are fine, but unless you send me an electronic invitation at least a week in advance, I’m unlikely to be able to carve out the time for your meeting. Of course, this hierarchy is complex and very personal, so my usual advice to colleagues and acquaintances is just, “The best way to get hold of me is email,” rather than a long and involved prescription of preferences!

How does your personal hierarchy of methods compare to this? Is email king for you too, or do you prefer for people to come and talk to you in person, or at least to pick up the phone? Now think of the person who’s your opposite in terms of his or her communications preferences. How are that person’s preferences different from yours? If you send him or her an email, will it be given a different priority than you intend?

For example, my friend Simone, who’s in Human Resources and very much a people person, is uncomfortable with some communication methods, which she views as impersonal. If something’s urgent, Simone expects a phone call. Not only that, but that if it’s truly urgent, she expects that you will not only leave a voicemail message, but that you’ll ring back again if you don’t hear from her in an hour or two.

The point here is that it’s important to understand how these communication preferences will affect your project. It may be worth having a team discussion about communication, to help your team members understand which parties are happy to be interrupted with a request for help, and who would prefer to get an email or an instant message asking them to signal when they have five minutes to talk.

Of course, you also need to understand the preferences of your key stakeholders and the project board. You might spend hours carefully crafting project status update emails, only to find that the stakeholders are still coming and perching on the edge of your desk, asking you how it’s going. You’ll get frustrated because it feels like you’re repeating yourself, and they’ll get frustrated because you keep sending them long emails when all they want is a 15-minute briefing on a Monday morning, so they understand what’s going on.

Content

In addition to the forms and methods of communication, there’s also the question of the actual content—the information you’re trying to convey. This may include facts and figures, a project status update, a summary of recent meetings, or a key project decision. But, whatever your content, you need to make sure that you’re clear on three issues:

1. purpose         What are you trying to achieve?

2. structure       How are you going to present the information?

3. outcomes      What should the people receiving the information do once they have it?

When you’re considering the purpose of your communication, you need to think about it not just from your point of view, but also from those of your audience. First, define what you want to achieve: for example, “update the project board on the project’s status.” But what do the project board members want? Do they just want to receive the information? Do they want reassurance that the project is on track? Do they want to know if any key decisions need to be made? Or all the above?

Once you’ve defined the purpose of the communication both for yourself and your audience, you can focus on structure. What sort of structure will communicate the information most effectively, given the communication’s purpose? If the purpose of the project status update is to reassure the project board that the project’s on track, you want to make that point obvious as quickly as possible. That’s why many people choose “traffic light indicators” for their status updates—anything communicated in green is on track, anything in yellow or orange has issues, and any points that are made in red are in jeopardy. These visual cues mean that the message behind the words is brought to the forefront as quickly as possible.

Most people will finish reading an email, watching a presentation, or sitting in a meeting with one key thought in their heads: “What do you want me to do about it?” You should always answer this question in your communication. Sometimes it will be as simple as recording a list of “next steps” for your team after a team meeting. Other times, you’ll need the project board to go away and decide about how to proceed, given an issue that has been encountered. Whatever outcome you desire, the more obvious you make it, the more likely you’ll be to get it.

Next Communication Details

Sometimes you don’t need any action from your audience—especially if the communication was purely informative. In this case, it’s smart to round off your communication with information about when the next communication will be scheduled or issued. This reassures people that no further action is needed on their parts, other than turning up to the next meeting or reading the next email.

Creating the Feedback Loop

It’s very easy for us project managers to get focused on how we’ll be communicating to the project team, stakeholders, and project board. However, it’s just as important to make sure that everyone out there knows how to communicate back to you! You need to know about great ideas, issues popping up on the horizon, and potential risks and opportunities just as much (if not more so!) as stakeholders need to be informed of the project’s progress, and the team needs to know when the deliverables are due. The way to achieve these goals is through a feedback loop.

Giving the Option of Anonymity

Sometimes, in particularly political environments, it can be worth creating an “ideas box” into which people can drop slips of paper on which they’ve explained ideas they’ve had for your project. If you want to be slightly more high-tech, you in an environment where being overly negative, realistic, or even just too honest could cost staff members their next promotions, creating these anonymous avenues can be both very important and very valuable. could create a web page to allow people to submit their suggestions anonymously.

Depending on the culture of the organization where you’re working, you could establish the feedback loop in several ways. You might set aside ten minutes of each team meeting to allow people to voice their concerns or share ideas they’ve had. You could also make a point of having a quick, regular coffee with your key stakeholders, to give them the chance to informally share their ideas, experiences, and expertise. Sometimes, you’ll need to actively pursue this interaction, but sometimes, by making clear that your door is open, and dealing constructively with the concerns brought to your attention, you can create an environment where people automatically feel comfortable coming and talking to you.

Collaboration

Collaboration, although it requires excellent communication, is about working together as effectively as possible. As the project manager, most of your interaction with the stakeholders and the project board will focus on communication. However, with the project team, collaboration is the focus: as project manager, you’re responsible both for leading the team and for fostering an environment in which the team can collaborate effectively.

Where successful communication primarily relies on a good communication flow, collaboration is about forming relationships. With a new team working on a new project, your team members may feel unsure about each other as well as the new challenges they’re undertaking. Even if the individuals have worked together in the past, there may still be aspects of the new project that will introduce uncertainty.

Turning Groups into Teams

Putting individuals together makes them a group, but only when they can work together effectively will they really be a team. Helping your people to become a team, rather than remaining a group, is one of the most important roles you have as a project manager.

But how do you go about it? First, you need to understand how group dynamics work. There is, of course, an entire field of study that deals with organizational psychology and groups in the workplace. Here, we’ll look at a simple model that explains the stages that groups go through as they become teams, namely forming, storming, norming, performing, and adjourning.

In the forming stage, group members get to know each other, and start to understand what the point of the group is. In project terms, this stage typically takes place when the team is originally formed, and the Initiating phase is underway. It’s a time of information gathering and introductions. At this stage, people are usually still very independent and focused on themselves: what does the project mean for them? What will they be doing?

As project manager, you can help smooth the forming stage by making time to understand your team and giving them a chance to get to know each other. Encourage the team members to share information about their backgrounds, past experiences, and reasons for wanting to work on the project. Share information about the project they’ll be undertaking, but don’t overwhelm them with details of exactly what each team member will be doing.

The group then progresses to storming, where differences of opinion come to the fore. Confrontations about how to proceed with the project, who should decide which deliverables are owned by whom, what the best approaches will be, and what tools should be used, will abound. For those group members who don’t enjoy confrontation and conflict, this can be a very painful stage. Others may revel in the perceived competition and push to “win,” or have their proposed ideas or methods chosen.

In project terms, storming is most likely to begin during the Planning phase of the project. Depending on the maturity of the individuals on the team, it may involve only a short period of time, but some groups never move out of the storming stage. Since it’s not the most productive state for a group to be in, your role as manager is to help the team to achieve consensus and a route forward as soon as possible. The main things to emphasize are tolerance and patience—help people to respect each other’s opinions and experience, and to realize that the conflict won’t continue forever!

Next comes the norming stage, where group members start to work together more easily. Often, this stage involves agreeing on standard ways of working, tools that will be utilized, and the ways in which issues and conflicts will be dealt with. The group starts to feel more like a team at this stage, with members trusting each other more and starting to help each other more frequently.

There is a danger in the norming stage that the group can become too conformist.

It’s in such situations that phenomena like groupthink—where the group automatically assumes that the idea that the group agrees on must be the best and ignores outside inputs or different ideas—can surface. It’s important to keep an eye out for these kinds of problems, and to address them by actively promoting the con-sideration of different ideas by the team. Beware of Groupthink!

Performing is the most productive stage. The group is now truly a team, and together they can achieve much more than they could as a collection of individuals. They rely on each other for help and support, and though this doesn’t mean that there’s no disagreement, it does indicate that healthy ways of dealing with differing opinions have been developed.

Often, teams acting in the performing stage need very little managing—they can make decisions, allocate work, complete it, and keep track of their progress. This doesn’t mean that a project manager is no longer needed, but that you’re most likely to be working with the team, rather than having to direct them, which might have been necessary in the earlier stages while the group was forming.

The final stage that teams experience is adjourning—the team is disbanded, usually when the project is completed. Some even refer to this stage as mourning, since after being in a performing team, individuals feel a real sense of loss on separation. Often individuals will have built up strong relationships with other team members and may stay in contact long after the initial team has been disbanded.

Team dynamics is one of the trickiest areas for new project managers. Sometimes, your role will require you to get in there and get your hands dirty—deal with conflict, make changes to the structure of the team, and so on. But at other times, the best thing you can do is to do nothing, allowing the natural progression of the cycle to develop the team.

Sadly, there aren’t any prescriptions for how long it will take the team to move from one stage to the next, nor how to move a group along. As you gain more experience, you'll become more adept at doing the right thing at the right time, but to start you off, here are some top tips for each stage of the process:

Forming

Make time for people to get to know each other at the start of the project. Diving straight into the work without making time for this important process means that your team members will remain tentative with each other—they, and the project, won’t gain the benefits of their working as a proper team.

Storming

Accept that conflict is normal and that suppressing it won’t move you for-ward—the disagreements will simply remain simmering beneath the surface.

Let team members sort it out, and only step in when things are going too far.

Some raised voices can be okay but screaming insults—or worse—obviously is not.

Norming

It can be tempting to just sit back and enjoy the peace and quiet when the team is involved in this stage. They’ll be getting on with their tasks, and generally working well with each other. Your main role is to keep an eye on whether the team is becoming too inwardly focused or succumbing to groupthink. Also, continue to support relationship building and encourage new ideas at this stage.

Performing

Your primary role here is to preemptively avoid anything that could interfere with the performance of the group. Be a filter for them—don’t let anyone (including management!), or anything, bug your team. Take away as much of the administrative burden as you can, and let the team focus on achieving as much as they can together.

Adjourning

Different people will handle the team’s break up differently. Accept this but be sure to celebrate the work that the team undertook together!

Fostering a Collaborative Environment

As project manager, there’s a lot you can do to help create a collaborative working environment for your team. Some of the following tips will be more effective at certain stages of the team development process just discussed, as identified below.

Encourage relationship building.

People need to build up at least a basic level of rapport before they’ll be able to work together well. If possible, get the team together in person at the beginning of the project for one or two days. Brainstorm project approaches run some exercises and leave plenty of time for individuals to interact with each other one on one. (Forming, Storming)

Reward collaboration.

Members of your team need to feel that they’ll be rewarded for helping each other. These rewards don’t need to be anything as big as a salary incentive—simply acknowledging the team member’s individual contributions publicly as and when they’re made is enough to show the value of their work. You could also encourage your team to thank each other in the team meetings. (Storming, Norming, Performing)

Discuss communication preferences up-front.

We talked in the previous section about people having different preferences for the ways they communicate and interact with each other. Discuss these preferences up-front and let each team member identify his or her preferred method of communication. Create a poster or sheet that reminds everyone that Adam, Rob, and Jas all prefer email, Sinead, Layla, Priya, and Victoire prefer face-to-face meetings, and Li, Arun, and Kai are fine with either instant messenger or telephone. (Forming, Storming)

Set up a regular team meeting.

As well as making it easier for you to communicate information to the whole team, team meetings provide a valuable opportunity for discussion and relationship building. Encourage team members to raise concerns or ask for help from each other in this forum. (Storming, Norming)

Define an issue reporting and resolution process.

Accept that there will be differences of opinion and realize that this is a symbol of a healthy team! Make sure everyone knows how to raise a concern, and how a decision will be made about it. If you agree the process early on, it will be easy to make sure you follow it consistently and will help people to feel that they’ve been listened to and treated fairly. (Storming, Norming)

It may be difficult to carve out time for these

“soft” pursuits. Even people in your group may object, citing that getting on with work is more important than getting a lot more than a loosely-coupled group. The time invested in this objective will Making Time for Soft Work to know each other. You need to make time, because an effective team can achieve pay off handsomely in improved productivity.

Working Remotely

These days, many of us find ourselves working with people who are spread across both time and space—working together in an office is almost a luxury! So how do you collaborate effectively with a team that you might never have met in person? How do you ensure that team works well across multiple locations and time zones?

The first thing to understand is that the same issues matter—it’s only the way in which they’re achieved that’s different. At the end of the day, people are still people. Interpersonal relationships are still important. You can have just as rich a working relationship with someone you only ever talk to over email, instant messenger, and the phone as you do with the person who sits next to you in the office.

Here are some suggestions for helping remote teams to work together more effectively:

Share lots of contact details.

Create a document that contains your team members’ contact details—their names, addresses, phone numbers, fax numbers, email addresses, and instant messenger identities. Add a photo so that people have a picture of who they’re communicating with. Make it as easy as possible for people in the team to communicate with each other, and to view each other as real people—not just names behind email messages.

Pull together a skills matrix.

Document the skills your different team members have, so that if someone needs help with a issue or task, he or she doesn’t have to wait until the next team meeting to ask for assistance. This tactic helps to replace the “ask around the office” option that collocated teams have.

Create group spaces.

In real offices, a team can grab a meeting room to discuss something at short notice. Try to create the same opportunity in the virtual environment—set up a dedicated teleconference number used just for that team and create a wiki or bulletin board where updates can be given by team members when an intensive team task is being worked on. If collaborating is made easy, it’s more likely to happen.

Be respectful of time and routine differences.

In the office, it’s obvious when someone isn’t working. When team members are working remotely, people need to adjust to each other’s routines—an issue that’s often further complicated by many freelancers and remote workers working from home offices. Be clear about who works when—if your team members are spread across different time zones, make sure that details of where everyone is, and the current times in those locations, are easily accessible.

Overdo it personally.

You need almost to over-invest in relationship building. Often, if you’re working with a team whose members are all based remotely, you’ll become something of a hub—team members may be more likely to come to you than to go to each other. Become a facilitator—know everyone’s strengths, weaknesses, skills, and preferences, and match them appropriately as the need arises.

Transitioning from Project to Personal Plans

The other big challenge for collaboration is to shift gear from focusing on the project, to homing in on personal plans—a challenge that requires you to look at the project in a different level of detail. As we discussed during the Planning section of Chapter 3, at a project level, the focus is almost always on the items that are being delivered. But, people actually work on tasks day-to-day—they define what’s needed to create the deliverable in question and follow a process to build the components that will combine into the final product.

Although each deliverable should have one (and only one) owner who’s accountable for making sure that item is completed, there will, of course, be a need for individuals to work together on different tasks. Being able to effectively define and delegate tasks is something that your team members will need to get used to and become good at.

The process of taking a deliverable and breaking it into the tasks required to achieve

it won’t be a foreign concept for you. Every day we all decide that we want to achieve something (a goal or deliverable) and work out what we need to do to make it happen. The challenge lies in doing this in such a way that everyone involved understands what’s needed and makes sure that progress is made.

It’s at this point that items like project specifications and design documents come into their own. Having a written record of what needs to be achieved can be a very powerful tool for making sure people are working towards the same goal. There are other ways to help ensure that the image you have of what you need to do, or build is the same as the picture in your teammates’ minds. You might involve the team in informal sketching sessions with just a whiteboard and pen, storyboarding a process or system (such as mapping a customer experience or interaction). For more technical projects, you might want to use UML (Unified Modeling Language), or even mathematical specifications.

The most effective way to communicate the project’s components, and explore how they translate into individual tasks, is to take the approach that works for everyone involved. For instance, if you’re designing a web site, Adobe Photoshop mockups may be clearer for everyone than code decompositions, unless you only need to communicate with developers who can read code as easily as they can normal prose. Likewise, using UML is only a good idea if everyone involved in the project can easily understand it—you don’t want people expending more effort to understand the communication technique than they spend considering the idea you’re trying to communicate.

To be honest, there are countless different approaches for helping your team to collaborate. What’s important is not that you choose the trendiest or most talked about one, but that you allow the team to choose the method that will help its members collaborate most effectively. Both the preferences of individuals in the team, and the nature of the project, will need to be considered, but the critical thing is that everyone feels comfortable with the method chosen.

Effective Leadership and Management

A project manager has two roles—one as manager, coordinating the efforts on the project, the other as leader, making sure that the project delivers the right results.

Stephen Covey’s 7 Habits of Highly Effective People illustrates the difference between leadership and management with these lines:

“… envision a group of producers cutting their way through the jungle with machetes. They’re the producers, the problem solvers. They’re cutting through the undergrowth, cutting it out.

The managers are behind them, sharpening their machetes, writing policy and procedure manuals, holding muscle development programs, bringing in improved technologies and setting up working schedules and compensation programs for machete wielders.

The leader is the one who climbs the tallest tree, surveys the entire situation and yells “Wrong jungle!”

Making sure that progress is made as quickly and efficiently as possible while ensuring that everyone’s heading in the right direction is a key skill for any project manager.

Paul Hersey and Ken Blanchard developed a model for understanding how people’s needs for direction and management differ depending on the situation they’re in. In the same way, the style of the manager or leader should change to fit what individuals need most from them.

There are four main styles of behavior leadership and management:

S1: Directing

Directing involves close supervision, defining roles and tasks in detail, and telling the team member what to do and how to do it.

S2: Coaching

Coaching, which is more interactive, entails helping the team member to come up with his or her own ideas and follow them through, but still required you to define roles and the broad approach.

S3: Supporting

With this style, day-to-day decisions (such as which tasks to complete) rest with the team member; the manager participates in those decisions on an as-needed basis.

S4: Delegating

Wholesale pieces of work are given to the team member to own; that team member chooses when to involve the manager.

Team members can be at a variety of developmental levels:

D1: Low Competence, High Commitment

The team member’s keen and motivated but lacks some of the knowledge or skills required.

D2: Some Competence, Low Commitment

The team member has some skills, but still needs some help and direction, and may lack motivation.

D3: High Competence, Variable Commitment

The team member’s experienced, and has all the right skills, but might lack the confidence or motivation to just “go it alone.”

D4: High Competence, High Commitment

The team member’s experienced, confident and motivated—possibly even more skilled than the manager in the relevant arena.

The diagram Figure 4.2 illustrates how the management style should match the development level of the team member. For instance, a D1 team member ideally requires S1 leadership—the team member is keen, but lacks knowledge or skills, so he or she would require close supervision and direction. The key point here is that it’s crucial that you match your management approach to individuals’ development levels. Let’s look at a couple of examples to illustrate why.

Example 4.1. Example: S4 to D1

First, let’s consider the situation in which a brand-new person joins your team. Your project is to develop a web site that collects customer orders, complaints, and queries, and provides the functionality necessary to deal with them. The new guy’s role is testing—he’s going to be going through the whole site looking for bugs and inconsistencies. On his first day, you show him to his desk, sit him down in front of the computer, and then rush off to an all-day meeting somewhere else.

Example 4.2.

Example: S1 to D4

As a counter example, imagine you’re going on holiday for three weeks. While you are away and that things are on track when you return. Even though this col-league is arguably more experienced than you, you prepare copious notes and instructions, explaining the most basic concepts of project management in intimate detail. The most likely outcome is that you will seriously annoy—if not insult—your col-’ll come back to find that the key things you wanted doing (like making sure the regular status reports go out) haven’t happened, and though your project is on track, your working relationship with your colleague is permanently damaged! capability (she’s probably better than you!) and you’ve been treating her with an S1 style (directing in minute detail). Had you simply delegated the work and asked her nicely to continue the couple of things that were different in your project (that is, matching her D4 capabilities with an S4 style), you’re away, a fellow project manager will be making sure that your project pro-league by treating her like a rank amateur, and she will just keep your project on track in her own way, ignoring your instructions. You Again, the issue here is a mismatch of styles. Your colleague is at a D4 level of d both be much happier.

Why won’t this situation work? He’s likely to be at D1 (eager, but not sure of what he should be doing or how) and you’re treating him with the S4 style, delegating the entire piece of work to him. The best result you can expect is that you come back to find out that he’s worked out vaguely what the web site is about and has made some notes about not liking the color. The worst-case scenario is that he’s annoyed and no longer motivated to do well—you might even find he’s not there when you get back!

Bear in mind that all the people in your team will be at different stages of development. Also remember that they won’t be approach all tasks with the same level of capability and confidence—your strongest technical person may need no help at all with technical matters (D4), but she might need a lot more help from you to prepare a presentation for the project board (S1 or S2). Try to predict who’s going to need your help and with which tasks, and you’ll find it much easier to manage your own time and involvement as well!

Tools and Best Practices

Let’s consider some tools and best practices that will help you keep your communication and collaboration running smoothly.

Email Etiquette

We all know how to use email. Using email effectively, however, is another matter entirely! By introducing a little structure and adopting a few tips, you can drastically improve the efficiency of your email communications:

Write a good subject line.

It should be descriptive and specific. For example, “Project ABC Approval: Final Sign-off Requested by 5pm 29 Nov 08” is better than “Sign Off Please.”

Use cues to indicate the action needed.

Make clear whether something is just FYI (For Your Information) or whether approval, action, or input is needed. Put the key verb in the subject line.

Reverse the structure.

Typically, when we’re communicating a recommendation, request, or summary, we assume we need to talk through the background, the process, and the results before getting to the real point of the message. People are busy. Help them out by placing a summary of what you’re telling them, or what you need them to do, right at the top of your email, with the details to follow in subsequent paragraphs. Your readers will then have the choice to trust your summary and act, or to read the rest to understand your reasoning.

If you need something done, set a deadline.

It’s difficult to convey priority well in an email, and the myriad of other tasks that your recipients needs to complete will often take precedence over whatever you ask of them. Setting a reply-by date helps them to focus on getting back to you when you need them to, rather than letting your request drop to the bottom of their to-do list.

Use lists and bullet points.

Lists and bullet points are easier to scan than paragraphs and will allow the people reading your email to get the key points much more quickly.

Be specific about responsibilities.

Make it obvious in your email who’s meant to take ownership for a task or next step—put their names in bold or capital letters, so that they can’t be missed. Don’t leave any next steps undelegated—place a name alongside each one, and if everyone needs to do the task, such as updating the issue list, then say “all.” Emails are not a good place to solicit volunteers for a task.

Keep it short and simple (KISS).

Emails that are longer than about three paragraphs won’t get read. Make sure any point that’s actionable is right at the beginning, along with the key information you are imparting.

Know when to step outside of email!

Email is a wonderful tool, but sometimes things are better dealt with over the phone, instant messenger, or in person. If emails are flying back and forth, either when you’re trying to explain something complex, or when there’s a disagreement brewing, consider stepping out to another medium. Don’t let things escalate out of control in a nasty email spiral!

Meeting Standards

Meetings are frequently reviled in the workplace, mainly because people end up sitting through so many meetings that seem pointless. The biggest courtesy you can pay to your colleagues is to make clear the purpose of the meeting up-front, so they can opt out if they aren’t needed. There are a range of other tactics you can use to ensure your meetings are always effective:

Publish an agenda up-front.

Make sure that everyone knows what will be discussed. An AOB (any other business) section is a common inclusion, but your colleagues need to trust that if a discussion arises in which they should be involved, you’ll request a separate meeting that involved the right people, rather than making decisions without them.

Make clear whose attendance is required and whose is optional.

It’s easy to simply invite everyone to every meeting. It’s also a lazy approach. Keep the list of “must attend” invitees as small as possible, and only add people to the “optional” list if they truly might be interested in the meeting.

Pay attention to logistics.

If the purpose of your meeting is to map out a new business process, holding the meeting in a small room with no whiteboard or flip-chart is nonsensical. If you want to have a short meeting, don’t provide chairs—stand-up meetings are easy to keep short. If you want people to participate fully in a brainstorming or problem-solving exercise, make sure the environment is comfortable. Book the meeting room with the comfy chairs or take everyone out to the nearest coffee shop. Think about whether providing food, coffee, and so on, would be a smart move.

Keep it short.

There are very few real situations where a meeting should take longer than one hour, let alone three or four! Usually, long meetings like these are amalgamations of smaller meetings, but someone has been too lazy to break them out into their component parts. Rather than thinking, “How do I get—and keep—everyone in the room?

” ask yourself, “What's the smallest group that could discuss this issue and make the right decision?”

Use a “parking lot.”

Have a flip-chart, whiteboard, or (if you are teleconferencing) a suitably labeled document that can act as your “parking lot.” Whenever anyone starts getting into a very detailed discussion that would be better dealt with outside the meeting, “park” it by noting it on the parking lot page. Of course, as the project manager, you’ll need to make sure that these issues are dealt with, otherwise, you’ll just be trying to silence discussion.

Project Status Updates

Keeping everyone—from the project board, to interested stakeholders—informed of the project’s status is important. A best-practice approach to doing this is to send out project status updates either electronically (via email or as a document attached to email) or on paper.

In some organizations, you might even want to hold a regular update mini-meeting, although you should be very careful about doing this unless you’re certain it will be appreciated by participants. You don’t want to create another pointless meeting that people will only resent!

It’s important that stakeholders know when they can expect an update. Updates should be regular and always delivered to the same schedule, if possible—for ex-’s also good to be clear about the original update time? Predictability Is Key ample, a weekly update sent every Thursday.

The typical format of a project status update is as follows:

High-level status

The project’s high-level status is typically indicated by a combination of description and traffic-light coding: on track (green), some issues (yellow) or off track (red).

This paragraph describes the current state of the project.

More detail

This section’s makeup will depend on the nature of your project. You might include the highest-level project plan you have, showing the different phases and whether they’re on track or not. Alternatively, you might want to list the key issues that require attention, so that the Project Board can understand what you’re struggling with.

Attachments

Common attachments include the current project plan, an issues list, and the original Project Initiation Document, to remind everyone of the original reasons for undertaking the project.

Plans

As you might expect, your project plan is a key element of your communication and collaboration. All the people in the team (and some stakeholders outside of it) will need to know what will be worked on next, what the key priorities are, and how the work will be distributed.

You can reduce work for yourself and increase the likelihood that your project plan will be kept up to date if you use it as a way of communicating work allocation. You can add people’s names to indicate who owns a deliverable and add color-coding to impart status information.

Don’t ever just blindly send out your current project plan to anyone who asks about the project. First, think about whether it’s the best way to communicate with them. Does it have the right level of detail? Does it contain the information they need? Consider creating a cut-down version if that’s needed, rather than swamping people with too much detail. Think Before You Send!

Issue Tracking Software

As soon as you encounter more than one or two issues with a project, the value of establishing a central list where issues can be logged, prioritized, and resolutions recorded becomes apparent. Several different software options are available, some of them open source and free, others incurring the sort of cost that requires senior management approval.

As always, the point is to find the simplest thing that works. For some teams, issue tracking is as simple as a spreadsheet in a shared space; for others it’s a tie-in to full-blown project management software. To successfully choose an approach to issue tracking, you’ll need to work out which tool will be used, and what issue tracking process will be followed before you encounter any issues. It’s easier to educate your team about a process when they aren’t worrying about how to fix a specific problem.

The main value of issue tracking tools is that they let you see the current in one place. You can then easily prioritize the issues that need to be addressed most urgently and put others on hold (or even decide not to invest effort in resolving them). Sometimes, issues are put on hold when it’s realized that a project activity might resolve them. I once worked on a project in which several issues were discovered as we worked to automate a process. But all the issues were placed on hold because we realized that instead of dealing with the issues individually, a completely different tack was needed to achieve the project itself. We eliminated the process that was being automated, and achieved the business goal in a different way, so the issues eventually moved from “on hold” status to “will not fix” status.

An issue tracking system will also help you to consider assigning the ownership of different issues to people within the team, and redistributing the workload, for example, when it becomes apparent that one person is having to deal with ten times as many issues as anyone else.

Identifying and categorizing the root cause of issues is not always useful during the project, but it’s invaluable when you’re looking back on what you’ve done. For instance, if 80% of your issues in a project were the result of design misunderstandings, there’s probably something you can do to change the design process in future. You might not be able to eliminate all the issues, but you could certainly identify them earlier on, when making a change would be cheaper, or preempting them before they become problems.

Wikis

Wikis (web sites to which anyone can add new or edit existing content) can also be useful for issue tracking, but their true value lies in knowledge management. If you have a team that’s collaborating on the development of a new software system, for example, using a wiki to collate the rough technical documentation provided by multiple team members can work very effectively.

The wiki’s organic growth potential, and it ‘to form a double-edged sword. When wikis are being actively used and maintained, soon as the amount of information that’s being recorded grows beyond a certain point, or becomes very diverse, problems arise. At that point, you either need to invest time to add structure, prune and reintroduce content to the right sections, or move to a tool that has an inherent structure. Outgrowing Your Wiki s ability to be updated easily, combine and are focused on a specific topic or set of topics, they work well. However, as It may be worth agreeing some sort of structure up-front, but the beauty of wikis is that they evolve, growing organically as new information is added. As with any software solution, you need to make sure that the wiki meets the team’s needs, and that your team is comfortable using it. Mandating a new tool without providing any support is almost always a waste of time and, potentially, money.

The RASCI Matrix

RASCI is a collaboration matrix that defines different roles that people in the project can play, either for the entire project, or for individual tasks. RASCI goes beyond communication to define the involvement of individuals in deliverables and work.

When you have lots of people involved in a project, or stakeholders trying to get more involved than you’d like them to be, RASCI provides clarity and can help you to explain why someone’s involvement is (or isn’t!) needed.

RASCI is an acronym that can be explained as follows:

Responsible

The person who’s responsible for delivering the piece of work (usually a project deliverable) is the first person to identify. For any given task, only one person should be responsible.

Accountable

This person is “on the hook”—he or she must make sure the deliverables are completed. In a project situation, the accountable person will almost always be the project manager. You’ll approve the deliverable, checking that it meets the appropriate standard, and that it won’t damage any other aspect of the product or project.

Supportive

Supportive parties are people who can help support the person who’s responsible, usually by providing help or resources.

Consulted

The consulted people are those who have information that might be needed, be it data, experience, or skills. They will typically be consulted to deliver the work.

Informed

These are people who don’t need to be involved with, or to approve the work, but would like to know what has been done.

An example RASCI matrix In this example, the project involves creating a web site for a pie shop. The lead designer is Natalie, who’s responsible for delivering the web site design. The project manager is Meri, who’s ultimately accountable for making sure the deliverables are up to scratch.

Timo and Laura are the marketing folks involved in the project; they playing a supportive role were the web site design is concerned, using their experience of marketing the pie shop to help Natalie understand what the key branding messages will be.

Saul is the main web developer in your team, and he needs to be consulted about what’s feasible in terms of design. Fadil and Laurence are going to be building the back end of the web site, where the pages that users see connect to a database. They don’t feel like they need to have a say in the design process itself, but as it will affect the work they’ll be doing, they’d like to stay Informed.

For any given task or deliverable, the RASCI concept is applied to work out who should be involved in the process, and in what capacity. It’s essentially just a very specific way of detailing roles and responsibilities for a set of deliverables.

The crucial point to note is when you use the RASCI matrix, you must ensure that it’s developed collaboratively. Those involved need to agree on which role they will be fulfilling—you can’t just write up the matrix, email it out, and expect everyone to fall into line!

Managing Multiple Projects

One of the happy side effects of having created all the project documents, from project plan to issue lists, is that they make managing multiple projects much easier. It is almost a luxury these days to only work on one project at a time—many of us find ourselves juggling several projects, and the people on our teams are assigned to many different projects, too.

This can cause complications: team members who don’t have 100% of their time assigned to your projects can find themselves torn between the priorities of completely different pieces of work. You may also find it difficult to keep track of all the details of your different projects if you try to keep them all in your head.

Using the project tools makes it easier for you, as well as your team. Emails that are very clear about responsibilities and deadlines help team members to prioritize their work. Status updates help the stakeholders to know what’s going on, but they also provide a helpful refresher on the project’s status when you’re switching between projects daily. Issue lists help to ensure that barriers are broken down, and that issues aren’t forgotten. Plans help to direct work.

You may even find that you want to expand some of the tools to cover multiple projects—status update newsletters that contain details of all the projects being worked on might be beneficial if the stakeholder group is roughly the same for all the projects. Beware, however, of overintegrating: it may be useful to you to have one plan for all the projects, but unless the teams are the same for each project, it may simply confuse everyone else.

Managing Change

In projects, change is as much a certainty as death and taxes are in life. Dealing with change not only pragmatically but positively is one of the hallmarks of a great project manager. In order to do so, you need to be able to understand the different types of change and reasons for change; to communicate the impact of change effectively so that the right decision can be made and lastly to effectively implement change as necessary.

Types of Change

There are several different reasons why change might be required, but for all those reasons, there are essentially just two types of change:

1. change arising from a new requirement

Some change arises from a new need that is discovered during the project. Usually this occurs because of a change either in internal circumstances (something within the organization or project) or external circumstances (something in the wider world, be it government, legal requirements, or similar).

2. change arising from an undocumented requirement

This type of change occurs when an existing need that was somehow overlooked, deemed to be out of scope, or otherwise remained unaddressed, is identified as being a necessary part of the project scope.

For instance, when the Enron scandal hit in the US and the new SOX (Sarbanes Oxley) requirements were introduced, any financial projects running at the time suddenly had a new set of requirements to deal with. SOX not only impacts how the accounting itself is done, it also affects the processes within the company. Technical systems projects would have felt a similar impact when the Y2K problem came to the fore.

Of course, new requirements might be much more mundane than these examples. If you were developing a reporting system for a business that experienced a reorganization, the reporting areas would change because of the reshuffle. Obviously, continuing with the old structure isn’t going to make sense, because people aren’t working like that anymore, so the change is necessary and unpredicted.

Undocumented requirements can often cause change—consider the cake shop web site project we mentioned in Chapter 3. The client on that project might presume that your team would create the content for the web site as well as completing the technical work to set it up. If this expectation was overlooked in the listing of assumptions during the Planning phase, it could well become a change that will be requested at some point during execution.

It’s important to understand which type of change you’re dealing with, because the type of change is very likely to affect the perception of how that change should be dealt with. If the project board and your stakeholders feel that you overlooked an obvious requirement (that is, the change is an undocumented requirement), they probably won’t take kindly to your suggesting that extra funding is needed to accommodate this need.

Before we get ahead of ourselves and talk about money, however, we need to talk about dealing with requests for change and how to decide whether changes will be made or not.

Change Control

Change control involves having a process for collecting requests for change, investigating the impact of each change, prioritizing those impacts, and getting approval to make a change (given its impact).

First, let’s take a step back. I’m sure you’re thinking, “Why do we need such a big process for something as simple as making a change? Surely we just do what the customer asks?”

In a perfect world of unlimited time, funding, and resources, you’d be right. We’d take the list of potential changes and just work through them, one by one. But I’m sure that you can think back to a time when “just a few small adjustments” snowballed into days and weeks more work for you or your team—even though that work was never really part of the plan? You’d make the requested change and then something else would need to be changed as well, until eventually the end product was so different from the original design that it was unrecognizable.

Your role as project manager is about making the project happen on time and within budget and delivering the agreed scope and quality. Part of the point of having you there is to make sure that the project doesn’t cost more than it delivers—that there’s an acceptable return on investment. No one wants to spend $100,000 on a project that’s only worth $50,000.

Change control, then, is really a process of ensuring that the impact of a change is really considered before you go ahead and do it. As with the issue tracking process, it’s important to define how changes will be registered and considered up-front, so that when the first changes come along everyone knows how they’ll be dealt with.

The Change Control Process

Though your change control process may be heavily tailored to your environment and project, there are several key steps that will apply in all circumstances:

Gather the change requests (CRs).

You want to have some basic information on each requested change, including the benefits it will generate and which parts of the project it affects.

Understand the impacts.

Your first step, on receiving a change request, is to form an understanding of the change and what it’s going to mean for the project. Will it mean a design change? More work? Less work? Will you need to get a specialist in to make the change, or could your team handle it?

Communicate the impacts and get a decision.

Make sure that the project board understands what the change means for the project in terms of cost, time, scope, and quality. At the end of the day, the final decision rests with the board—your role is to make sure they have the appropriate understanding to make the right call. There should only be three possible decisions: yes, make the change; no, don’t make the change; and investigate the change further.

When you’re communicating the impact of a change, make sure you inform refer them to the original reasons why the project was undertaken, and have them consider the question, “Does this change help drive those original needs?” Does the Change Fit the Project? the board about the cost, time, quality, and scope impacts of the change. Also

Communicate the decision.

Whether the change is going to be undertaken or not, you need to make sure that you let the stakeholder who proposed it (and any others affected by it) know what the outcome of the review process was. Be careful not to fall into the position of justifying the decision—if the requesters want to argue with the decision, they need to argue with the project board, not you!

Execute the change.

If the decision was to go ahead with the change, then you’ll need to adjust your plans accordingly, and execute the change. As with the rest of the project, you’ll need to ensure that you have control mechanisms in place. That way, if implementing the change turns out to have greater impact than anyone anticipated, you can spot it early and escalate the issue to the board if needed.

Whether you choose to execute the change control process on paper or in electronic format is up to you—consider the nature of the organization you’re working with. Personally, I believe that project managers should work to make change control as easy as possible. However, some project managers actively discourage changes by making the change control process arduous—for instance, using paper forms that must be filled out in triplicate before they will be considered.

Viewing change as the enemy is not a constructive approach. Some changes will indeed mean more work, but stakeholders might also identify real opportunities that’ll make a big difference to your project’s effectiveness. Involving the project board to make the decision based on the potential value of individual change requests will hopefully weed out the gold-plating requests—those that are nice to have, but not essential—leaving only those that make a real difference.

Change Request or Project Deliverable?

One of the most difficult situations you will have to deal with as a project manager arises when stakeholders (and maybe even the project board) feel that something you see as a change was implicit in the original scope of the project.

This leaves you in a very difficult position—you have agreed to a certain scope and expanding that will have obvious cost and time implications. Your customers, on the other hand, evidently thought it was in your original quote, so they’re quite appalled that you want to discuss additional resources or time to make it happen!

It’s at times like this that your diligence in the Initiating and Planning phases of the project will really pay off. Revisit the Project Initiation Document and the project plan. Was the deliverable identified there, but you’ve somehow overlooked it? Try to understand why the customer’s perceptions differ so much from yours on this point.

If you find that the deliverable wasn’t included in the original scope, you have two options. You can agree that it was implicit in the scope and agree to complete the change without additional resources or time. Alternatively, you can point to the scope that was signed off by the board, show that the deliverable in question was not included, and negotiate more resources or time, depending on what’s needed.

Of course, there are times when playing hardball on these issues doesn’t seem the right thing to do in terms of preserving your relationship with the customer. You may well decide to take a short-term hit to build the long-term relationship. If you choose to take this approach, however, take the opportunity to revisit the project scope—if you’ve already found one hidden assumption, there may well be others. Don’t get stung by the impact of misperceptions—or miscommunications—repeatedly. Get everything out in the open and work out whether you need a full renegotiation of the project if you discover that the customer was expecting the project to include lots of extras that you haven’t planned.

Tools and Best Practices

The change control process can be assisted using several tools.

The Balance Quadrant

Sometimes it’s best to try and illustrate the impact of a change visually. Although we’ve already talked about the four key areas in the quadrant being time, cost, quality, and scope, it can be very powerful to place these four aspects in a grid and illustrate what the impact of each change will be.

For example, in communicating the impact of a change to add new functionality to a web site that you were building, you could present the two scenarios illustrated in Figure 4.5.

What this diagram indicates is that, whichever path is chosen, it’ll entail additional cost and an increase to the project scope. You need the board to choose between is a two-week delay on the project’s launch, and a higher instance of bugs if you launch on time but have had to divert resources to work on the extra functionality.

Stakeholder Reviews

Encouraging change may seem a strange thing for a project manager to do. After all, change seems to result in all these difficult discussions and decisions, right? While that’s true, ensuring that change takes place at the right time can be very powerful.

Stakeholder reviews provide a means for inviting input and anticipating potential change early in the process, when changes will likely be less expensive to make.

The later you leave change, the more expensive it will be. It’s almost always more difficult and costlier to change something that has already been built than it is to change the design before a single brick (be it literal or figurative) is laid.

This point is obvious in projects that produce something physical. Everyone understands that asking for the windows in the house you’re building to be moved six inches higher after the walls have been built will be expensive. Making that change while the design is still on paper is straightforward and cheap; making it later in the process means breaking down bricks that have already been laid. Illustrating this point is a simple matter of walking around on site.

The problem in knowledge work is that the detail of what needs to be reworked, knocked down, or rebuilt is more difficult to explain. The deliverables seem more ethereal, so stakeholders may misunderstand their impacts. For instance, if you’ve designed your database system with the storage of text files in mind, a sudden change of requirements that means you need to accommodate audiovisual content will have a big impact on this aspect of the project.

Involving stakeholders early, so that they can highlight missing pieces of the puzzle or communicate their bright ideas for improvement is a smart way of getting ahead of the curve. Manage change or it will manage you!

So, what does a stakeholder review involve? Essentially, it’s just a matter of meeting with stakeholders and reviewing the project plans with them. If you’re building a product, you might show them the early design sketches or prototypes.

In the technology realm, this kind of user involvement is best practice in any case—many aspects of the interaction design, usability testing, and user-centered design processes rely on the product’s early exposure to users.

Be careful, though, that you don’t go too far. The point of stakeholder reviews is to gain input, not to try to have your stakeholders and users design the product themselves.

Change Requests

Change requests (CRs) can take many forms—you may be happy to accept CRs via email, provided the required information is provided in each one. You might want people to fill in an electronic form or summarize what they want in a Word document. The important point is to garner enough information quickly, so that you can evaluate the scope and impact of the change.

Typically, a change request involves these sections:

Proposer: the details of the person who’s requesting the change, including his or her contact details

Description: an explanation of the change that’s being requested business benefit a description of the value the change will deliver, and how it will be delivered

Priority: an identification of the importance of the change requested

There should also be a section either on the change request form itself, or in the tracking system you’re using, to collate the CRs together, enabling you and your team members to add in information about the impacts of the change—effectively answering questions such as, what would be involved? How much would it cost? And how long would it take?

Change Review Boards

If you don’t receive many change requests, you might just add an agenda point to your regular project board meetings to discuss the proposed changes. However, if you’re getting a large number of CRs to consider, or you need to have a decision on a CR before the next project board meeting, you might want to call a change review board—a meeting that will allow you to consider the different CRs and make decisions about which to proceed with.

If several different CRs are vying for resources, it may be smart to invite stakeholder advocates to come to the board and “make their cases” for the changes they requested. Much as you’re giving the project board the hard facts (including the time, cost, impacts on scope and quality), organizational considerations that you’re not well placed to comment on may also come into play. In such cases, bring in one advocate for each change request, and give him or her a few minutes to present the case for that change.

This kind of approach can have several positive effects:

■ The project board receives extra information that can help them make the best decisions for the project.

■ The stakeholders get to see the value of the other change requests that have been submitted. They may realize that other needs should take priority for the good of the project, and the organization.

■ Some stakeholders may find that they will benefit from changes proposed by another area—changes that may possibly even negate the need for their own change request to be acted upon.

In this kind of meeting, your role is largely that of coordinator. You want everyone to get a fair hearing, and for decisions to be made at the end of the meeting. Try to keep people focused on the value of the changes by asking direct questions about the value that each change will deliver and trying to defuse any overly emotional reactions.

Re-planning Sessions

The outcome of many change requests is an agreement to go ahead and make the change. If several CRs have been considered and approved, a larger re-plan may be needed than if just one or two changes have been given the go-ahead—though of course, that will depend on the nature of the approved changes! Either way, the approval of changes provides a good opportunity to bring your team together for a re-planning and brainstorming session.

As in previous planning rounds, involving the team will really help them to feel a sense of ownership for the deliverables they’ll be working on. It’s also a great chance to find opportunities to work smarter rather than harder.

For instance, if several the changes that have just been agreed are going to affect the same aspect of the product, making the design changes for them all together will likely be a sensible approach. You might even find some overlaps which mean that the total impact of all the changes is less than the sum of the individual impacts!

Summary

We started this chapter by considering communication and why it’s so important to successful project management. We discussed the forms (one-to-one, one-to-many, many-to-many), methods (email, face-to-face meetings, instant messenger, and so on), and contents (purpose, structure, and outcomes) of communication, as well as the different preferences that people have for the aspects of communication.

We then talked about collaboration and saw how you can take a group of individuals and turn it into a team that works. We talked about the process of team formation, which involves the steps of forming, storming, norming, performing, and adjourning (or mourning). We talked about the difference between management and leadership, and saw that, as people have different levels of ability and motivation for tasks, you need to alter your management style accordingly.

We then explored a range of tools and best practices that can help you to communicate and collaborate effectively, including rules for email etiquette, meeting standards, project status updates, plans, issue tracking software, wikis, and the RASCI matrix.

The second part of this chapter addressed the issues associated with managing change. A defined change control process is essential to the success of any project, and it allows you to ensure that change requests are collected, the impact of the proposed changes are considered, and a measured decision is made about each.

The tools and best practices that we discussed in relation to change control included the balance quadrant. stakeholder reviews, change requests, change review boards, and replanning sessions.

Now that we’ve discussed communication, collaboration, and handling change, it’s time to set our sights on the home stretch: closing the project and moving on to other endeavors.