This blog contains part two of an interview with Clint Padgett, the author or The Project Success Method.
Q: Can you describe a project network diagram for us?
A: A project network diagram is a logical model of the project that captures the sequencing requirements among the activities. The following is a very simple example:
The project activities are represented as boxes (or “nodes”), and the precedence relationships are represented as arrows connecting the activities. The diagram flows from left to right. The simplest and most common type of precedence relationship (as illustrated above) is drawn from the right-hand (finish) side of the predecessor activity to the left-hand (start) side of the successor activity. This “finish-to-start” relationship means that the successor activity cannot start until the predecessor activity is finished.
The project network diagram is an extremely valuable tool in planning and controlling the project. It allows us (or the project management software tool) to quickly perform calculations that determine the project duration, the start and finish dates for each activity, the connected series of activities that drives the project duration (or the “critical path”), and the “slack” on other paths. The diagram allows us to assess the impact of proposed changes to the plan, to update the status of the project based on the status of the activities, and to forecast workload and cashflow. Without the project network diagram, many of these analyses would be extremely laborious, if not virtually impossible, to perform.
In my book, I show examples of more complex project network diagrams and explain the analytical process of developing the diagrams.
Q: How do you define “back-scheduling from the deadline” and why do you think it is the incorrect approach?
A: Back-scheduling from the project deadline is a very common approach to forcing the project schedule to meet the deadline. Basically, it involves working backward from the deadline and specifying a required finish date for each activity. It always results in a schedule that looks good on paper.
The reason that I don’t recommend this approach is that the resulting schedule almost never works; that is, the project will virtually always fall behind the schedule. In my book, I explain four reasons why these schedules don’t work. Here I will focus only on the reason that I believe is most important.
I firmly believe that one of the most important factors in keeping a project on schedule is for the team members to be committed to the schedule. For them to be committed to the schedule, they must believe that the schedule is feasible. However, when the back-scheduling approach is used, the team members typically view the resulting schedule as a fantasy. The planned durations for the individual activities are seen as arbitrary and forced. As a result, the team members do not commit to the schedule. In fact, they tend to disregard the schedule. No wonder the project falls behind schedule!
Please don’t misunderstand me here. I am not suggesting that it is acceptable to produce a schedule that does not meet the project deadline. I am simply saying that back-scheduling from the deadline is not a good way to develop the schedule. A far more effective approach is explained in my answer to the next question.
Q: You recommend a process called “forward scheduling and strategic compression?” Can you describe this for us?
A: First, the team members estimate the “normal” durations of the activities assuming that each activity will be performed in the most cost-efficient way. This approach to estimating tends to maximize the team members’ commitment to the duration estimates. The duration estimates are regarded as reasonable.
Using these estimated “normal” activity durations and the project network diagram; we perform scheduling calculations to determine the initial project duration and completion date. This initial project completion date is usually later (sometimes much later) than the project deadline. We also determine the connected series of activities that drives the project duration (again the “critical path”).
Then the team figures out how to compress the project back to the deadline. They focus on the critical path and select only one activity at a time to compress. The activities are selected strategically based on a set of known characteristics of activities that are the best ones to compress. Once an activity is identified as an attractive candidate for compression, the team member responsible for managing that activity is asked whether the activity can be compressed. If so, the activity manager specifies how the activity can be compressed and estimates the compressed duration and the cost of compressing the activity. After considering several attractive alternatives, one activity is selected by the team for compression. The scheduling calculations are again performed to see what happened to the project completion date and the location of the critical path.
This process is repeated – one activity at a time – until the project completion date meets (or even beats) the project deadline. It is often amazing how much the duration of a complex project can be shortened by compressing only a small number of well chosen activities. In performing this analysis, we also consider the trade-offs between the costs of compressing activities and the savings (especially reductions in opportunity costs) resulting from finishing the project earlier.
An important point here is that because the team is directly involved in deciding how to compress the project, we do not lose their commitment to the schedule. The schedule is not an arbitrary fantasy. They figured out how to get the work done on that schedule!
The entire process of forward scheduling and strategic compression is explained in detail and illustrated in my book.
Q: Estimating the time it takes to complete activities is one of the most difficult tasks. Do you have any recommendations about how to approach this?
A: First, it is important to recognize two different ways of thinking about “the time it takes to complete” an activity. One is the work content of the activity, or the number of staff-hours of work required to perform the activity. The other is the duration of the activity, or the period on the calendar between the start and completion of the activity.
Let me illustrate with an example. Suppose a project manager asks a member of the team to estimate the duration of their activity, and the activity manager responds that the activity will take about 40 hours. What the activity manager probably means is that the activity will require about 40 staff-hours of work, which is not an estimate of the activity duration. Now suppose the activity will be performed by two people, who both work eight hours per day, five days per week. Further, suppose these two people are involved in more than one project activity at a time and are also expected to perform non-project work. Let’s also surmise that on average, these two people can devote about 25% of their time to the activity once it begins. That is two hours per day for each of two people or a total of four available staff-hours per working day. Using these calculations and assumptions, it looks like it should take about ten working days (40 staff-hours of work / 4 available staff-hours per working day) to complete the activity. Therefore, the estimated duration of the activity is ten working days.
Here is my recommended approach for estimating activity durations:
• Determine the scope and quality requirements of the activity being estimated.
• Specify the technological approach that will be used to perform the activity (equipment to be used, etc.).
• Specify who will perform the work.
• Estimate the number of staff-hours of work required to perform the activity.
• Estimate the average availability of the people who will perform the activity, considering their other responsibilities.
• Divide the number of staff-hours of work involved in the activity by the number of staff-hours available per day to work on the activity.
For some activities, there is one more step. If the activity is subject to delay or interruption by common uncontrollable factors (such as weather), we adjust the duration estimate (not the staff-hours of work required) upward by a percentage to reflect the expected impact of the common uncontrollable factors on the duration. This is a risk management technique. We want the duration estimate to reflect the real environment in which the work will be performed, not a perfect world where it never rains.
Q: You talk about critical paths. Can you explain what you mean by this term?
A: Probably the best way to explain critical paths is with the following very simple example, which is based on the same network diagram I introduced earlier.
There are three paths of activities through the project as follows:
• A-B-D-F with total duration of 22 days.
• A-C-D-F with total duration of 27 days.
• A-C-E-F with total duration of 25 days.
Path A-C-D-F is the critical path, because it has the longest total duration. This is the path that drives the duration of the project to be 27 days. Of course, a project can have more than one critical path. In this example, if the duration of Activity E were six days, then path A-C-E-F would also take 27 days, and the project would have two critical paths.
It is important to know the critical path(s) as we plan the project, because if we need to compress the duration of the project, we must find a way to compress all the critical paths. It is also important to know the critical path(s) as we execute/control the project, because any schedule slippage along any critical path will delay project completion.
Of course, the critical path(s) can change both as we plan and as we execute/control the project. In fact, the critical path(s) for any given project is/are likely to change many times over the life of the project. Fortunately, the project network diagram and the project management software tool make it easy to update the calculations to find the critical path(s) at any time.
Q: What tools are contained in the book to help organizations improve their project management?
A: The main focus of the book is highly structured and integrated processes for defining, planning and controlling projects. Within the context of those processes, some of the tools that are described and illustrated in the book are:
• Project charters to define the scope, objectives, stakeholders, constraints, assumptions, risks, and other key attributes of the project.
• Work breakdown structures to analyze the project into manageable activities and to indentify which member of the project team will take responsibility for managing each activity.
• Project network diagrams to analyze and capture the sequencing requirements among the activities.
• Schedule calculations to determine the project duration, the critical paths(s), and other key schedule information.
• A logical and strategic process for compressing the duration of a project.
• A list of typical characteristics of activities that are the best choices for compression.
• A process for anticipating and resolving resource overloads.
• A recommended way to organize the project budget.
• An effective approach to updating the status of individual project activities and using that information to determine the status of the project as a whole.
• A tool/approach for developing operating procedures for projects that involve several different organizations.
• A project management office to own and maintain the project management system and to support project managers and their teams in applying The Project Success Method.
Q: Do you have any recommendations around how to approach the topic when individuals in an organization are very resistant to changing the existing project management process?
A: Experience has proven to me that the most effective way to overcome resistance to adopting The Project Success Method is to convince a project manager and his/her team to try the methodology on just one project and see how well it works. The selected project should be strategic and complex enough to be a reasonable test for the new methodology. The team should be trained on the methodology, so they know what to expect and how to participate effectively in the process. Expert coaching should be provided to help the team apply the methodology correctly. It is also helpful to provide support in applying the project management software tool so that the project manager and team can focus on the project rather than the software tool.
I have used this approach many times with The Project Success Method. Time and again, the project team achieves success and they understand how the methodology contributed to their success. They also typically find that The Project Success Method is easier and less stressful than their old muddling-through approach. As they say, “Nothing succeeds like success!” Once the methodology has proven its effectiveness, other project managers and teams will be lining up wanting to get trained and to use the methodology.
Q: Is there any other information you feel is important to discuss?
A: It is important to understand that when an organization adopts The Project Success Method, they should expect to reap three important benefits:
Successful project performance. The organization should achieve success on individual projects - delivering the projects in accordance with scope and quality specifications, on time, and within budget.
Quality of work life. Members of the project teams should experience less stress, confusion, frustration, and conflict. These benefits derive from documented project requirements and plans, clarified roles and performance expectations, mutual accountability and support among team members, precise project communication, and effective problem-solving.
Strategic competitive advantage. Organizations that develop the ability and the confidence to perform projects successfully can routinely “beat their competitors to the punch” in building and maintaining strategic advantage through new products, processes, systems, technologies, marketing initiatives, special events, mergers and acquisitions, and so on.
About Clint Padgett:
Clint Padgett is the President and CEO of PSI. Since joining the firm in 1994, he has provided consulting, training, and account management to clients in a wide range of industries, such as: manufacturing, food/beverage, electric utility, and technology. His project experience covers many traditional and special applications, including product development, equipment installation/startup, facility construction/moves, marketing, software/hardware system implementation, and international sporting events. Immediately prior to joining PSI, Mr. Padgett was an engineer for a Fortune 100 company. In that capacity, he assisted in the development, field-testing, and rollout of new equipment, as well as managing and improving quality assurance for several of his company’s major suppliers. He is a graduate of The Georgia Institute of Technology with a Bachelor of Electrical Engineering. He also holds a masters degree in Business Administration from Duke University. His professional associations include the Project Management Institute, the Institute of Electrical and Electronic Engineers and the Product Development & Management Association, among others. Additionally, Clint is a published author and frequently speaks at conferences on the subject of project management.
