Using modern project management tools to build a project team
Over the past two years I have had the opportunity to work with several New Product Development (NPD) teams. My role as project planner has been to facilitate these teams through the process of developing their project schedules. In this role I have had the opportunity to observe first hand the challenges facing a project manager in the new product development business.
NPD projects in a large, established corporation present an interesting set of challenges: Project teams are typically cross-functional; that is, their members come from the many functional organizations throughout the corporation. The team members are rarely co-located. The work of a NPD team often has never been done before, so little or no prior experience exists. And, as with any project, time is critical (whether by management decree or market conditions), so the pressure to be “in action” is great.
In general, this high-pressure environment is not conducive to good communication. Given this, my challenge has been to develop a process that allows a NPD team to deliver a timely project schedule while working through communication barriers.
The process that has evolved consists of a series of a “professionally” facilitated sessions with the project team and individual team members (professional here means “experienced at facilitating technical professionals and skillful with the tools of modern project management”). Depending on the commitment of the team and the project manager, the whole process takes between three and six weeks. The process focuses on two key deliverables: developing the initial project schedule and creating a common understanding of the project by the team. A special note: Although this process was developed while working with NPD teams, it is highly effective with other white-collar projects such as software development or reengineering.
Step 1. Get to Know the Project
As a facilitator, nothing can hurt your effectiveness with a team more than your ignorance of their project. To counter this, spend a few hours with the project manager and the technical project lead. Learn about the customer for the new product, the market, technology, the team members and their roles, and the project's time frame. With this background, you can go into the team and facilitate the conversations that need to happen.
Step 2. Where the Project is Going: SMART Goals
Use the first session with the team to clarify the project goals. Normally, this is a review session. But, if the team is new, this is your first opportunity to begin building the common understanding.
One technique I have found effective is to provide the team with a definition of SMART goals (Specific, Measurable, Achievable, Realistic, Time-bound) and ask them to state the project goals. Working with a flip chart, you can capture each goal and clarify it so that everyone in the room agrees to the words. To some extent, this is a “wordsmithing” exercise. Yet, I find it to be an effective tool for getting everyone in the room involved. At the end of an hour or two, the team has generated a clear set of goals. Though not necessarily complete, the list is a great start.
Step 3. Assumptions: Don't Take Them for Granted
Most of us were raised to assume with caution. In fact, many of us were taught a cute way to remember why it was important to Ass•U•Me carefully. Despite this, we often, unconsciously, assume. That is why this step of the process is so important. The team needs to know what everyone is taking for granted and what can be taken for granted. Discussing assumptions also provides for a great project framing or conversation.
The process I use to get at assumptions is similar to the goals process. While standing at the flip chart, ask “What are you assuming about this project?” If people are reluctant to state assumptions or they are not sure what you are asking, make up an example. I might prompt the group by saying “Can we assume that all of you are full-time on this project?” This is usually not the case, so I get immediate clarification on that assumption. For further prompting, there are several “standard” categories of assumptions you can work with in product development. The more common categories include the market, customer, technology, manufacturing, and costs. With this process, the team is usually able to fill many flip chart pages in just one session.
I encourage the project manager and the team to review and update the assumptions regularly. This serves as a check for validity of the assumptions and reminds everyone what can and cannot be taken for granted.
Step 4. Work Breakdown Structure: It's Not Just a Tree Diagram
Perhaps you have heard that developing the work breakdown structure can be a step in a team building process. Granted, it's not as exciting as an Outward Bound rope slide, but it is likely the most effective way to get the team to define and understand the scope of the project.
The process for developing the WBS involves a team session, flip chart pages taped to the wall and that most wonderful invention, the Post-it Note. Start with the project name on a 3 x 5 Post-it at the top and center of the “wallpaper.” Then ask the team to write out project tasks on Post-its. As they are written, you can stick the notes to the wall. Once a significant number are generated, ask the team to sort them into groups with common themes. Then give each grouping titles. These titles often become the Level 1 deliverables on the WBS.
The Three-Time Estimate Thought Experiment
To help the “Experiment” I draw out a triangle distribution (skewed left) on a flip chart and indicate the optimistic, likely and pessimistic points on the triangle. Then, using a task from the project's WBS developed in the session, I ask “How long is it likely to take to complete this task?” After getting an answer, I ask “If things go really well, how long is it going to take to complete this task?” After getting that answer, I ask “If things go really badly, how long is it going to take to complete this task?” When trying to coax the worst case out of people, I usually encourage them to use their imagination to think about what could go wrong and to think about having to do the work over again. After getting this duration, I ask “OK, given that this is your worst case, are you still comfortable with your likely estimate?” More often than not, the likely estimate is increased.
Then, using one branch of the WBS, you can work with the team to fill out the detail of that branch and “teach” the team how to develop their sections of the WBS. Before sending the team off to finish their WBS sections, make sure they know how to generate three time estimates (optimistic, likely and pessimistic) for each task they identify. Here, I have found it important to instruct the team on how to perform a three-time estimate “thought experiment” (see sidebar).
Step 5. The Network Diagram: What I Do Affects You …
Upon completion of the WBS and the three time estimates, it's time to work with individuals. To speed things along, each functional person can generate a network logic diagram of their work. So, after some coaching, send them off to develop their functional networks (again with Post-it Notes). Once this is accomplished, work with each individual at the computer to input their tasks and durations. Through the use of some user-definable number fields in your favorite project management software or your favorite spreadsheet program, you can capture the three time estimates, calculate the expected time for each task and insert those values into the duration field of your project management software (some of the newer versions of project management software allow you to write macros to automate all this).
After entering each individual's network into the computer, it's time to link them to each other. This requires one or two group sessions. To speed up the sessions, you can make use of your project management software's filtering capability to generate lists of tasks that have no predecessors or no successors. When the group gets together, use these lists to start the conversations required to connect the functional networks. With this process, I attempt to create the “ideal” network diagram (no nodes without at least one predecessor and one successor other than the start and end nodes). This helps each member of the team see how their work impacts or is impacted by others on the team. It also helps identify missing parts of the project and clarify language. Once you have completed the project network logic diagram, you can identify your critical path and determine your schedule risk profile (the probability of completing your project by a specific date).
Step 6. Risk: What Could Go Wrong?
The risk analysis process starts with a simple group brainstorming session on the question “What could go wrong on this project?” This step in the process gives everyone some insight into the potential pitfalls of the project. It helps everyone realize how they might contribute to avoiding potential problems and provides a starting point for contingency planning. My experience shows that not everyone is willing to participate in this type of discussion for fear that they will be perceived as negative. Try to allay their fears by telling them that a potential problem identified is often avoided or avoidable. Using the learnings from the risk analysis sessions, the team can develop contingency plans and incorporate them into the WBS and network diagrams as necessary.
Step 7. Ongoing Project Reviews: Remembering the Commitments
At this point in the planning process, the team has generated a detailed WBS, a network logic diagram, identified project risks, developed contingency plans and generated a detailed project schedule. Now it is time to use that schedule. The ideal place to do that is in the project review meeting. The purpose of this meeting is to have the team members report on status and allow the project manager to learn about the problems delaying the project.
To facilitate this meeting, start with a list of the “current” project tasks. You can generate this list through the use of your project management software's filters and macro language. I found that selecting tasks that were due to start or finish in the next two weeks worked well because it forced the project manager and the team to focus on the near-term activities.
You can lead the group through this list item by item with either the project manager or a facilitator keeping track of what each person says about their status. The key questions the project manager should ask when they discover that a task is late include: “What are the issues delaying you?” “What actions are you taking to deal with the issues?” “Do you need any assistance?” and, most importantly “What is the new date?” When a new date is given (or if tasks are reported complete) make a note of it and update the schedule for the next meeting.
With this fairly simple process and a few weeks time, a project team can use most of the key modern project management tools to increase their level of communication, ensure that their actions are all focused in the same direction and increase their probability of success. And the project manager can feel comfortable that the team members are working together toward a common outcome. These are the kind of surprises you like to see on a project. ■
Mark R. Durrenberger, PMP, is a principal consultant with Duncan•Nevison, a project management training and consulting firm headquartered in Lexington, Mass. He previously was a project planner and PM consultant at a Fortune 500 company.
PM Network • March 1996