Project managers will talk about the importance of the work breakdown structure (WBS) and the critical path, but they often have trouble getting a project team to move effectively from laying out the deliverables in a WBS to creating and focusing on an accurate critical path for a project. The importance of the critical path itself is often glossed over as the scheduling tasks become more complex. Simply put, the critical path consists of those project activities on which the project manager should focus when managing the schedule component of the triple constraints. If the critical path slips, the project slips and the project manager is faced with the added reporting challenge of explaining this to the project sponsors. One hurdle that often must be addressed, especially on projects with large project teams, is being sure that the project team understands the meaning and importance of the critical path and shares the focus of the project manager.
If the team has a solid understanding of the development steps for getting to the critical path, they can be much more effective in providing the required input. The overall concept is simple. The WBS defines the deliverables of a project; activities identify the work that must be done to produce the deliverables; dependencies for activities establish the logical order of the work that must be accomplished; and duration estimates establish how long activities will take to complete. If all of these components are available, the float for each activity can be determined. The critical path identifies the project activities with zero (or negative) float. These cannot slip without impacting the end date of the whole project.
Project managers live this progression in every project and easily see these relationships and the logical steps of this process. When team members don’t share the same level of understanding, it often can be frustrating for the project manager and lead to miscommunications with the project team. Without the proper emphasis on the importance of the input to each of these steps, it is easy for the critical path to be erroneously skewed; an error which is often discovered only during the execution phase of the project.
Because it is the team members on whom the project manager depends for the activity list, estimates, and dependencies that feed into the critical path, building an environment that facilitates this understanding is good for the project and by extension, good for the project manager. Being able to communicate these input needs effectively to team members can speed the creation process and increase the effectiveness and completeness of the schedule.
This paper will discuss some key concepts on schedule creation and lay out a practical methodology for building knowledge within a project team on the importance of the critical path.
This paper relates some of the practical experiences from our company’s program to improve the capabilities of our project managers and project teams. This program is a focused effort to add discipline around the project management methodology and provide tools and techniques to our teams to increase their chances for project success.
One recurring lessons learned from discussions with our teams involved questions around communications and the criticality of activities that were being assigned. Team members often didn’t understand why one activity “had to be done,” but other seemingly similar activities could run late with little or no repercussions. This occasionally led to bad feelings and the rumor of favoritism on the part of the project manager---neither of which makes the project manager’s job easier.
Walking the team through a quick and focused program on developing and using the critical path has gone a long way to increasing the understanding of how the project manager uses the critical path, why a subset of activities get so much attention, and why the team is often called on for extra efforts.
We built this program based on some simple assumptions:
- Fundamental project management knowledge is a benefit to all employees
- An understanding of our project management methodology helps lay a foundation for more effective team communication
- Knowledge of how the inputs and outputs of the methodology will be used puts the team in a better position to provide useful information in project planning
We know that the information presented here is very basic for all but the newest project managers. It is not intended as training for project managers, but rather for project team members. It is intended, however, to make the project manager’s life easier. This is accomplished by making their communications with the project team clearer and the needs of the project more readily understood by the entire team. This, in turn, eliminates follow-up explanations, potential errors or omissions due to miscommunications, as well as possible re-work on project activities.
Everything we do is aligned with the practices and principles laid out in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)---Third edition (Project Management Institute [PMI], 2004). Our approach was to develop several in-house training courses, with each course designed to quickly key in on a specific need for a project team. Specifically, the information provided should be able to be put to use immediately. We developed “Quick Classes” of 1 to 4 hours for key concepts and get these in front of whole project teams or individual members in open enrollment classes. These are timed to coincide with the related project planning task and serve as vehicles for a continuous improvement process for project management capabilities and as team-building exercises.
This paper will present some of the content we have worked into our program with regard to the progression from the WBS to the critical path. We encourage you to take anything you find valuable and work it into a program with your own project teams.
Understanding the Basics
As a basic curriculum for our teams, we offer three introductory classes in-house:
- Project Management Fundamentals
- Introduction to the Work Breakdown Structure
- Estimation and Scheduling
These close many of the gaps that our project managers find in their team members’ knowledge of project planning and provide definitions and practical examples of much of the project jargon that can confuse communications. This paper will focus mainly on the estimation and scheduling information, although the other two classes provide the foundation information that must be successfully understood and executed if the scheduling process is to be begun on good footing. The following represents the major points presented to projects teams that attend this training.
Creating the WBS
Before estimation and scheduling are addressed, the WBS must be created. This is the critical first step to successful project planning. Without going into too much detail on WBS creation, we make the following assumptions:
- The WBS focuses on project deliverables.
- The WBS is a hierarchical representation of all of the deliverables (work) of a project.
- The WBS serves as a framework for subsequent planning activities.
It cannot be overemphasized how important the disciplined creation of a good WBS is to a successful project planning methodology. A quick quality check for a WBS is to see if every component name consists of only nouns and adjectives. Deliverables are always “things.”
You should note one of our findings that we believe is probably shared across most companies: once the WBS deliverables have been broken down into several layers (e.g., Level 4 or 5 of the WBS), teams have a difficult time not beginning to insert activities (verbs) into the component names. Once this begins, it is usually a good indicator that the WBS is complete (at least for that leg of the hierarchy) and the team can begin to move on to the next phase of planning.
After the WBS elements have been created and bought into by the team, each should be assigned to the team member who will be responsible for their delivery. This member will now be responsible for the remaining critical components needed for the creations of the project schedule:
- Defining the activities (tasks) needed to produce the deliverable
- The identification of predecessors---any task that must be completed before any of the newly defined activities can begin (for the sake of simplicity, we’re assuming finish-to-start relationships)
- Estimating the time duration it will take to complete the newly defined activities
We encourage team involvement in the creation of all project planning components and the expectation is that the members responsible for project deliverables (WBS elements) will assemble their “subteams” to assist in the creation of the above components rather than create them individually.
Define the Activities
Defining activities is usually one of the easier assignments for a project team. Once they have been assigned a deliverable from the WBS, it is usually easy to facilitate the creation of the activities needed to create the deliverable. Everyone knows you have to make a list of the things you are going to do, and everyone has a pretty good idea how to do this.
In our class, we go through an exercise that reinforces one simple instruction:
“List everything you need to do to create ‘Deliverable X.’ Use a ‘verb/noun’ syntax for clarity.”
The use of the verb/noun syntax makes it easy to distinguish an activity from a deliverable by the name alone. This is a desirable distinction when items are referred to out of context of the project management tool, for example, on reports.
The first run-through of this exercise usually captures the critical “80%” of the activities. It is rare, especially if you are working with a team, to miss a critical activity. This first cut will also give the team an idea of the magnitude and complexity of what they are working with in producing this deliverable and an idea of the number of iterations they will need to complete their list.
The level of detail to which the team will take the list will be based on several factors:
- Complexity of the deliverable (more complexity equals a need for more detail)
- Experience level of the project manager and/or the team (less experience equals a need for more detail)
- Familiarity with the deliverable (less familiarity equals a need for more detail)
- Risk tolerance established for the project (low tolerance equals a need for more detail)
Using common facilitation techniques, the team should be encouraged to loop back through the list as many times as necessary and add or subtract until a consensus is met that the activity list is complete.
Identify the Predecessors
When talking to the teams about schedule dependencies and the predecessors they identify, we emphasize keeping it simple and clear. Dependencies and predecessors are highly linked and can usually be discussed interchangeably.
For our discussions with the team, the first cut at looking at dependencies is limited to finish-start relationships. This avoids all of the confusion around trying to explain the intricacies of the other dependency relationships, which are seldom used outside of the project manager’s need to truly fine-tune the schedule.
One point of confusion in this area that we have found beneficial to clarify early on is the concept of mandatory versus. discretionary dependencies. Teams will often begin identifying finish-start relationships only to start veering off into discussions of “Does Activity Y really have to finish before Activity X can start?” Spending a little time getting the team to a common understanding of this distinction can keep the meeting focused on the high-level task.
Mandatory dependencies represent a “hard” sequence of events that must be followed, such as “parts must be on hand before assembly can start.” Discretionary dependencies can be viewed as representing a “soft” or potentially flexible sequence of events. Often the “normal way” of doing things is viewed as a “hard” dependency when other options can be explored. For example, normally a building is constructed from the foundation up, with each floor being dependant on the floor beneath. Modular building techniques now allow all floors to be constructed in parallel with the final assembly task added to the end of the schedule.
In our class, the predecessor exercise is kicked off with some example data and a simple query to prime the pump:
“For Activity X, what other activities are usually completed before Activity X can be started?”
This is repeated for every activity on the list and, at the completion of the process, the team will have a relative schedule that identifies the order in which activities will be done in each leg of the project network diagram. There is not enough information yet to let the team know how the activities in different legs of the network diagram relate to each other.
In the class example, which is kept to a small number of activities to allow the team to quickly work through the concepts that we are trying to reinforce, we take some time at this point to demonstrate how a few dependency changes can dramatically change the configuration of the network diagram. This simple revelation has been an eye-opener for several team members and demonstrates/reinforces the need for the team to give appropriate consideration to each step in this process.
The team is then moved to the actual project activities list and the exercise is done again with the live data.
Estimate the Duration
Now that the team has the deliverables (WBS), the activities, and the relationship dependencies established, the final step needed to create the critical path is to estimate activity duration. Anyone who has spent much time perusing project management course catalogues knows that there are many multiday classes out there on just this topic.
Although most team members (who hopefully are subject matter experts for the activities that they are asked to estimate) will give a reasoned and defendable estimate, if you do not have some discipline around this process, you can waste a great deal of time determining which estimates meet acceptable standards for the project and which do not.
We have found that much of the resistance toward being asked to do an estimate stems from the lack of a clear and consistent understanding of exactly what is being asked for. People are uncomfortable around what they don’t understand, and two schools of thought can develop that can dramatically skew a critical path in one direction or the other:
School of Thought #1: “Not my problem”
“If estimates are not attributed, there is little risk to the estimator. Therefore any number given works, so why waste a lot of time on something that is going to be the responsibility of the project manager?”
School of Thought #2: CYA
“If estimates are attributed, the estimator will be held accountable. Finishing early is better than finishing late; padding the estimate offers the opportunity to look good and avoids the risk of being the bottle neck for the schedule.”
To address these two possible practices, our estimating exercise starts out with three objectives:
- Explaining how “estimates” are defined and assigned at our company
- Demonstrating how estimates are a critical component of defining the critical path
- Providing tips and techniques for creating effective estimates
Defining ‘Estimate’ for Your Organization
We try to impress upon the team that we want estimates to reflect the work and duration needed to accomplish the activity assigned and that it should not include contingency padding to handle potential risks. We ask for confidence levels, ranges, and anything else that will help the project manager understand the accuracy of the information being provided.
Our class material introduces the concept of PERT estimates as a way of demonstrating to team members that the project manager understands that things can go well or badly. And we explain how contingency will be handled separately as part of the risk management planning.
To get to PERT estimates, we use questions along the following lines:
- If you are on this activity full time, how many hours of “heads down” time would it take for you to complete it if everything went trouble-free?
- How many hours would it take if there is a normal amount of problems?
- How many hours would it take if just about everything goes wrong?
We further identify these as estimates that represent a 20% chance, a 50% chance, and an 80% chance of being achieved, respectively. These are the Optimistic (O), Most Likely (ML) and Pessimistic (P) estimates.
The standard PERT equation of (O + 6ML + P)/ 6 gives the PERT estimate, which is usually a little higher than the ML value.
The “heads down” qualification in the PERT questions helps to define the actual “work” hours that will be needed to complete the activity. Because no one works “heads down” all day, you have to come up with a rule of thumb on how much time on average is actually spent on “work.” We assume 6.5 hours per 8-hour day on average for “work” with the rest going to admin, meetings, personal, and so on..
The last step on getting to duration is to have the team member establish what percent of the standard 40-hour work week they can dedicate to the project. The resulting equation is:
# Days duration for the activity = hours of work divided by % dedicated time divided by daily average
Using our company’s standards, if a team member estimates 60 hours of work for an activity and they are dedicated to the project 50% of the time, we would get a duration of 18.5 days or over 3.5 weeks (60 / .5 / 6.5 = 18.46). This is a big jump from the “week and a half” which is often the quick conversion made for a 60-hour estimate.
Building your duration using this methodology can avoid a great deal of the ambiguity that can show up in estimates. If you get an estimate of “10 days,” you don’t actually know if that is 10 calendar days, 10 work days, 80 hours of “work,” which could take significantly more than 2 calendar weeks, or just a guess with nothing to back it up at all. Adding discipline to the process can make everything a lot clearer to everyone.
Identifying the Critical Path
Once you have all these pieces assembled, every major project management software package in the market place will derive the critical path for the team at the push of a button. This scheduling function does a forward and backward pass through the activities and derives the float for each activity. Activities selected as critical path have zero (or negative) float, which indicates that they must start and finish on their designated dates, or else the end date of the entire project will be impacted.
This concept of float is often not well understood by team members, and it is well worth the time to run through some examples to reinforce this with the team. Introducing the team to concepts such as early start/finish dates, late start/finish dates, total float, and resource constraints help team members understand the relationships between the information that they have provided and how the software is determining the critical path.
Building on the earlier example that established dependencies, we go through an exercise adding estimates, building the network diagram, and highlighting the critical path. We then introduce changes to dependencies and estimates to demonstrate how the critical path can change dramatically with seemingly small changes. This reinforces the concept of activity priority, which in turn is important to the team’s understanding of where to allocate their time.
As a final step, the project manager should get a “gut check” from the team that the identified critical path looks like a reasonable result. If the path has omitted expected activities, if unexpected activities are included, or if it just doesn’t feel right to the team, the path should be examined in order to understand what is causing the anomalies. Likely candidates are often unnecessary or forgotten dependencies, erroneously entered durations, or misunderstanding some of the configuration setting of the software. Once the team has gone through these training exercises and there has been activity involved in the steps of developing the critical path, they have a much better understanding of the project requirements and the relationship of their responsibilities to project success.
We believe our program to build project management as a management core competency not only for project managers but also for project team members enhances our teams’ abilities to work effectively. These capabilities improve the understanding of the components of the project management methodology and the logical progression of the creation of the work breakdown structure through to the creation of the critical path. The focused nature of the training attempts to put project knowledge in front of the team just before they need it and provides the double benefit of being a team-building event as well as building skills.
These benefits in turn create a team environment that is more conducive to clear communication around assignments, schedule demands and project priorities. All of these reduce the complexity of the ongoing communication tasks of the project manager and reduce the possibility of conflict within the team. Everyone’s lives should get easier and projects should have a better chance for success, all with virtually no down side. Who could ask for more from a few hours invested in training?