Over the weekend, I ran into an old friend and he shared something familiar in an interesting way: a project is late when we run out of time. Simple. Then we asked me somethings which made me stop and think. He said, when you are managing a project, how do you know if you will run out of time? Not simple. I’ve spent so much time worrying about why my projects are late, but not a lot of time looking into the nature of time itself.
To my friend, I explain that at the beginning of the quarter we launch and/or continue to work on our portfolio of projects. At this point, I’m willing to admit I don’t how if we know we are going to reach our project due dates on time. I don’t even know when we get about half way through a project. I do know that I can’t wait until last few days of the month, or more important, the last few weeks of the quarter to find out. There is not enough time to respond and make sure projects finish when they are supposed to.
My friend sympathizes with me and tells me a story that might help me. He says, let’s say you are at the office in Itasca, IL and you need to be at an important customer meeting in Spring Green, WI, 120 miles away. The meeting starts at 11am, in two hours and its 9am right now. You will have to average 60 mph (miles per hour) if you want to be on time.
He continues, about half-way, in Janesville, WI, you stop to pick up a quick coffee and calculate your miles per hour so far. It turns out, your average speed has only been 30 mph. The target didn’t change; the meeting is still on for the appointed time, 11am.
He asked, how fast do you need to go in the second hour to keep your promise of being in Spring Green, WI in time for the 11am meeting?
I say, 90 mph (90mph + 30mph = 120mph / 2 = 60mph), right? Wrong, he says! If your average speed was indeed only 30 mph, you already used up the two hours! The answer in infinity, you will never make it. Your time has run out.
I’m embarrassed to not be able to get a simple math problem. I also realized there are two different project elements––time (2 hours) and distance (120 miles). These elements are linked. Hand in hand. One doesn’t exist with out the other. Every project has an estimated duration. And, there are many paths to reach the project’s goal. Each path requires the team to “travel” different distances to reach the end of the project.
Today, on my way into the office, I realize we need to consider time and distance when making decisions about other things like:
-
-
When should we start a project so that we don’t run out of time?
-
Which projects are using up time faster than planned and which one’s are moving along?
-
Which tasks should we focus on to recover time if we need to?
-
What effect do start dates, projects using up time too soon, and efforts to recover list time have on resource loading?
-
I’m glad I ran into my friend, but he left me without a good solution. More questions than answers. I turned off the car, closed my eyes, and took a deep breath. With all the late projects I was managing, Monday mornings are not the best time to be thinking. It’s time to be doing. But, I promised myself I would think about a solution to this project and to all the project problems I’ve uncovered so far.