Sometimes, there is that one person who has to be at the meeting before the meeting can start. But, sometimes they are late. How late? The length of time, it seems, is proportional to how important they are to the meeting. The more important, the longer everyone will wait. It’s like the old joke about experimenting with a piece of buttered bread tied to the back of a cat––which side will hit the ground first? It turns out, it’s proportional to the price of the carpet.
Anyway, while I was waiting for this important person, I use my time to look over the Gantt chart of the next project. I started to see something interesting. There are four tasks, which need to be complete, before the task they are feeding can start; an integration point. If any of these four tasks are late, the successor task will also start late; like the three people waiting on our fourth to start our meeting.
The successor task has a due date. The resource working on this task and I had a conversation about it last week. It was important to review the possibility of meeting the due date on this task since it includes a key meeting with one of our main customers.
Are we going to make that date or not? My day dreaming was interrupted by the sheepish hello from the person we were waiting for; 15 minutes late.
There is no guarantee the successor task will start on time. So, there is no guarantee the successor task’s due date will be met either. Is it possible the successor tasks could start early? Slim chance of that. It’s more likely they will start late, but how late. Who knows! The only way I’ll find out is when it happens and that will be too late.
I do start to wonder if giving up trying to control the variability is even possible. Some other project managers think it is possible. When they insist on a dead line or due date as part of a task’s assignment, they try to limit the amount of variability.
But, is the agreed upon date valid? What if the task finishes before the due date? The resource who finished the task is being measured against the due date they agreed to. There is a good chance the resource will not tell anyone the task finished early. There was a chance to speed up the project and start on the next dependent task.
What if the task looks like it will finish after the agreed upon date? The resource may be pressure to cut corners and try to finish the task on the agreed date anyway: that’s what they agreed to. If the resource continues to work past the due date, there may also be added pressure from me to get the task done as quickly as possible so the project “stays on track.” I already have a tenuous relationship with this person. Pointing out to them they are late isn’t going to help. And, it’s possible the quality of the work or the functionality expected may also suffer.
The use of holding resources to the agreed task due date seems like it can cause other issues. These issues could be future rework, customer complaints, or lost sales. But, we’ll deal with these issues later. I’ve got enough on my plate as it is.
For now, I need to realize there is another source of variability embedded within almost every project––integration points. Maybe I should be trying to look for ways to control the variability after all.