It is good for a project manager to have some sense of optimism, with boundaries. In our experience, we can see our project team members as well as the project manager, make decisions and act as if we understand variation. Or more appropriately, act if the range of possibilities is quite limited, the belief that the events and actions we undertake to have little variation.
Table of Contents
What sort of things do we use to understand the way things might happen? If we even have data from which we can analyze, we may calculate the average.
Or as we see it more frequently.
The problem with average is that it does not express the range of variation that is possible. Experience suggests teams use averages to make estimates or determination of durations of a task.
Variation is a measure of dispersion, and that dispersion is associated with probabilities. Don’t worry this is not a statistics or math-intensive piece. However, the project team and the project manager must understand the impact variation has on our work, and especially from the schedule perspective.
Dispersion has many possibilities. Not knowing this variation puts our project schedule at risk. We know, projects are doing new things, they are not operations. How are we supposed to know the range of variation in the work? What is the range of possible outcomes, specifically duration, for any given task or event in our project? Well, our organization may have processes for the work, and rather than pay attention to the central tendency or average, find a way to discover the variation, starting with any collected historical data.
Another thing we can do is monitor the actual rate of accomplishment for specific tasks during the execution of that task. We are not referring to the subjective, how much completed at a point in the duration? We are referring to the metric-based rate of accomplishment. For example, if we have 3 specifications to deliver, and we have said three months. We should see progress at a rate of accomplishment akin to this rate. This may sound simple, but it is not. Not at all. What shall we measure? How will it be measured in a way that does not threaten our team? This is not about condemnation or punishment, it is about learning and adapting, and our team members need to know that there will be no Keel Hauling of the team members. Estimates can be difficult to create – we will write more about that later.
Dependencies is a fancy way of saying these things are connected, one thing depends upon another or happens after this first item. There are 4 types of dependencies in project management, finish-start, start-start, finish-finish, and start-finish. This may seem a bit remedial, but we need to lay the groundwork for the later portion of the article.
Finish - Start
We will start with the finish-start dependency. That is, the first task must finish before the next task can start. This is the most common type of task dependency in projects, often demonstrated in a Gantt or PERT chart. We put on our socks before we put on our shoes – assuming we wear socks.
Start – Start
This dependency task 1 starts, which then allows us to start task 2.
Finish – Finish
This dependency task 1 concludes which allows the conclusion of task 2.
Start - Finish
This dependency, as task 1 starts, task 2 can conclude.
For this demonstration, we will consider only the finish-start dependencies and a string of these tasks. We have a string of tasks that
Take a coin from your pocket. Flip it. How did it land - heads or tails? Assuming a non-manipulated coin, there is a 50% chance for heads, and a 50% chance for tails. Each coin toss is an independent event, that is, the previous flip does not influence the depending flip. This is true for a fair coin. So, the next coin toss, will result in either a heads or tails outcome. What about a string of coin tosses? The probability of a string of consecutive coin tosses coming up heads is calculated:
Probability=P1×P2×P3×P4
So for 4 coin tosses, each independent toss has a 50% probability of coming up heads (or tails for that matter). The probability of a string of 4 consecutive coin tosses of coming up heads will be the product of the probability of each?
Probability=50%×50%×50%×50%
Or
Therefore, the probability of 4 consecutive heads from a coin toss is:
Probability=6.25%
Why would any of that matter? What does a coin toss have to do with project management and scheduling?
Let’s look at this string of events from a probability of success for each task. In this instance, we assigned the value to 90% for each task. When we think of 90% probability, we are thinking that is high. If we score a 90% on a test, we are likely closer to happen than not. We believe this to be an aggressive estimate. We will define success as meets objective, cost, and time expectations. That is all three of these things need to be successful.
The next thing we are going to note is that we are going to assume that each of these tasks is mutually exclusive. In real life, this is seldom valid. That is, what happens in task 1, will deliver some artifacts of
Probability=90%×90%×90%×90%
Or
Probability=65.61%
Okay, these project tasks are not like coin tosses. Unlike the coin tosses that are mutually independent, depending on project tasks often have interactions. Specifically, the quality of the delivery of task 1 for example, will have an impact on the quality of task 2. Consider a poorly written specification the result of task 1. Task 2 will take the results of Task 1 and build upon it. A poorly delivered task 1, will have an impact on task 2. So essentially, the actual probability of 4 tasks of 90% probability (65.61%) concluding appropriately, is much worse.
When you think you have effectively laid out your schedule, take a second look. Have you adequately addressed variation? Have we explored whatever historical record we have in creating the schedule? Have we identified metrics that are associated with key tasks, especially those on the critical path where unknown variation will cause the biggest adverse impact to the project schedule? Even before that, have we established an environment where our team members will readily share the state of their work. The project schedule is a living artifact. We think we know things when we make estimates, sometimes these estimates are influenced by executives and management, and not in a good way. We will write more about this in future works.
See more on risk management in our upcoming book later this year from Taylor and Francis.