A Look Into Our Project Management Issues
Only including the touch time for each task duration estimate is the most way out thing he’s said so far. I knew this salesman was too good to be true. There must be a catch and sure enough there is. After ordering our food, Jim, my chief engineer, asks Gary to get right to the point.
“What do you mean by only using the touch time for each task duration estimate,” asked Jim.
I listen for the answer. The touch time of a task is the hands on, working on the task activities. It’s not the waiting, delays, or interruptions which are accounted for by the added safety time.
Gary says, “we all agree that what we are here to talk about are improvements to your current reality. Improvement means change, but not every change is an improvement. So, we need to decide what needs to change before we do anything else. What elements do we need to consider to make the right changes?”
That’s not much of an answer, but I like the passion in Gary’s voice when he said it. I’m willing to listen a little longer.
He continues, “there were plenty of times I had the same gripes you did about managing projects. I’m an expert at bitching and moaning, but that only get’s me so far. One day I decided to look a little deeper at a few of these gripes. Was there something more a deeper analysis might uncover.”
“I assume,” I say, “that you looked into one of our issues, usually the original due dates are not met, for example.”
Gary says, “I sure did. To meet the original due date commitment, you need to do something to bring the schedule back on track. To bring the schedule back on track you must take some expensive action or trim the project content. Why?”
“Because without these actions I’m bound to miss the due date,” Jim says.
I nod and say nothing.
“But, you don’t want to take some expensive action or trim the content. You also don’t want to jeopardize the original commitment of staying within budget,” Gary says. “What ends up happening is you try to do both––taking some expensive action or trimming the project content––when you can.”
“It’s not a nice place to be,” I add, “and I have been in this position many times. Even Jim comes to me when he can’t decide what to do. The real problem is not missing the due date, but the being stuck between a rock and a hard place. Do I take an expensive action or not.”
Gary’s expression doesn’t change, but there is a hint of a resigned, I’ve heard this so many times before face. The waiter takes our order.
He says, “what about one of the other gripes you mentioned––there are too many changes. To meet your original scope commitment, you need to honor the commitments you made to your customer and give them what they want. To give them what they want, you make a change to the project. Why?”
I say, “because the customer demands it. Some of our customers can be very demanding. Or a change is necessary because some other function did something to meet their commitment. For example, we provided detailed specifications to the Procurement department. But, the only parts they could find didn’t meet all the specifications. We had to work around the parts we received. Changes were necessary.”
“I see,” Gary says, “you can decide ignore the change requested. In that way you feel better about staying on track to make the promised due date and stay within budget. How likely is that? I’m going to assume you always end up making the change to the project. You also know you’ll be called on the carpet later because you went over budget.”
How does he know what I’m thinking. I nod. I say nothing.
But, Gary is not done. “Let me check one more gripe,” he says––“too much rework. To meet original scope commitments, you need to act in a way that ensures the original due date will be met, right? To make sure the original due date is met, do the rework. Why? Because to be on time, we must start the project without all the final specifications; this is bound to cause rework.”
“But, you try to not do rework so you can stay within budget and stay within the promised timeline.”
“Again, you are walking a fine line between being very careful to do rework when you have to and not do rework when you don’t. I’m sorry to say, you still end up missing the whole point of the project which is to meet all the original commitments for scope, budget, and due date.”
I wish our food would come so I can hide my surprise that Gary knows so much about our environment. Meanwhile, Jim is trying to avoid my eyes. But, I can feel the tension of doing something or not doing something in each analysis Gary has done.
A Pattern Emerges
He says, “if you look, you see a pattern emerging. Each one of your responses to a gripe, like taking some expensive action, or trimming the project content, or making a change in the project or do rework, look similar. Many times, these are the actions folks like you and Jim take due to some “surprise” that was not taking into account at the start of the project.”
I’m glad to hear other people seem stuck with these issues, too. Our food arrives, but my hunger pangs seem to be gone.
“It is a fact of life that your executives and sales people must specify the scope, costs, and project lead times before a customer will sign the contract. There is not much you can do about that. So, let’s get back to describing this pattern in a generic way. One way to roll all these actions into one generic action statement would be something like:
“Compensate for early mis-estimations or early mis-considerations.”
“Sound about right,” Gary asks.
I nod. Jim nods. I say nothing.
“We could have started with any of your gripes and found a deeper sources of your frustrations. So, let’s remind ourselves what we did. We took an environment as diverse as projects, identified with some similar complaints, and found a common way that relates to our many of our problems. It’s the difficult choices we are forced to make between taking actions to compensate for slipping on one of our commitments and not taking actions to not jeopardize our other commitments.”
I see, the onion has been peeled back and my eyes sting with the realization we have been in all these situations many times. I start to nibble on my food.
Common Things In Project Environments
Gary goes on, “I don’t think you find this surprising since all project environments have two things in common:
-
- projects involve high uncertainty, and
- projects involve three opposing commitments, e.g., due date, budget, and content. We all want the content to be high, the budget to be low, and the time to be short. But, they are opposing because usually the higher the content, the higher the budget, and the longer the time.
Encountering these opposing commitments within a single project is one thing. But, what kind of environments increase the size of these opposing commitments? In environments where there are more than one project; the more projects, the greater the size of the uncertainty and the greater the impact of the opposing commitments.”
“This is our environment. We have many projects underway. But, what has this got to do with using touch time and not including safety times in our task duration estimates,” I ask.
No Sympathy, But There Is Enough Safety Time
“Good question, I wanted to let you know you have my sympathies. But, we’re not here for my sympathy. You are looking for a practical solution. To find a practical solution, we need to dig deeper still. The next question I have for you is this. Why must you take some action which compensates for the early mis-estimations or early mis-considerations?”
Again, I say nothing and hit pause on my lunch. But Gary bales me out again.
He says, “let’s imaging a new project is sitting in your Inbox. After a quick review, you assigning Jim to be the project manager. Remember the project was sold on the estimates made before the project was sold. Somehow between the time the customer accepts the proposal these estimates get turned into commitments.”
“We know the commitments are unreasonable, but what can Jim do. That’s the way business works; that’s the work Jim decided to do. He wants to do a good job and if it was up to me, I would let him pad his task estimates with as much safety time as possible.
“But, there is a limit to the safety your company can add. Too much budget, or too much time, or not enough content, and you don’t have a project anymore,” Gary reminds us.
“So, why is it that to do whatever it takes to meet the endangered commitment, Jim is forced to compensate for early mis-estimations / mis-considerations?”
I understand the question, but adding safety time doesn’t only happen at the project level. I also add some safety to the due date estimates I report to top management.
“Because,” he says, “very often, the safety time we are allowed to include is insufficient to absorb all the glitches that happen during the delivery of a project. The mere fact that we have so many glitches in our project performance indicates the extent to which the safety we are allowed to include is not enough. Right?”
I realized I wasn’t looking at this in the right way. I do see that there is plenty of safety time in our projects. Any project manager that has any amount of experience knows about the opposing project commitments. The project managers try to reduce the stress of balancing scope, due date and budget, and look for every way possible to add in safety time.
Good Reasons for Adding Safety Time
Gary says, “you now see that there is enough safety time, plenty of it, but there are good reasons for it. Let me take a few minutes and try to explain what I mean.”
“When Jim plans out the project, what he is doing is converting the promised commitments into some sort of action plan, right? And, this is where the first cracks start to appear. For example, if asked you what is 10 +10? Your answer would be: 20. Of course, when you have 10 apples and then buy 10 more apples, you have 20 apples. But, is this true about project data?”
Gary pulls out a napkin and draws a short horizontal line with a small vertical line on each end. He points to it with his fork.
Natural Variability
“A task is the smallest element in every project. We all know there is natural variability between the task’s planned estimate and how long it actually takes during execution. To compensate for the variability in each of these tasks and Jim wants his task due date commitment to have a high probability of being met, he will add safety time to the tasks. Right? How much? As he said before, as much as he can get away with. But, it’s never enough, right?”
“Right,” says Jim, “it’s never enough since I usually miss the due date promises I’ve made anyway.”
A Skewed Distribution & Non-deterministic Estimates
“Also, some tasks turn out to have a skewed distribution,” says Gary. “A skewed distribution of task duration can’t be negative, but can take less time than planned. But, it may take longer, sometimes MUCH longer, than its median or average time to complete. Have you ever noticed some tasks are never done? In other words, it has a long tail and describes the likely duration.”
“Task variability and skewed distribution, means task duration are not deterministic. 10+10 does not to equal 20 in projects. When people try to use deterministic number to estimate the duration of a project, the estimates are wrong. Sometimes many orders of size wrong. Senior executives and sales people use what is called the Additive Rule to determine the scope budget and duration parameters of a project before it is sold to a customer.”
I knew those folks couldn’t add. Now I see why. I like this Gary software salesman. I don’t see how he sells his software because he’s made no attempt to pull out his laptop. He keeps saying things I can relate to.
Task Dependencies
After a sip of water, Gary says, “that’s only the beginning of Jim’s problems. What happens when a single tasks varies in duration from the planned estimate? What effect will that have on the successor task(s) that come after it? Can you predict with any accuracy when the successor task will start?”
“No, not at all,” I say.
“Correct, a delay in one task will effect the start of the next tasks. How much variability or uncertainty can be expected? More than the average and sometimes much more than the average. Since Jim has been with you a long time, I assume he is experienced with missing due dates. How much safety time will Jim try to add to the planned tasks of his next projects?”
“As much as I can get away with,” says Jim.
I give Jim a friendly glare. He gives one back to me. We chew our food.
Gary says, “one task is always dependent on the completion of the task before. Not only the content, but dependent on when the content is handed over from one resource to the next.”
Integration Points
“Also, do you know integration points can also add to the uncertainty? Think of the legs of an integration points like the time it takes for all the participants take to arrive to an important meeting. You want this meeting to start on time. The only way to do that is to have all the required participants arrive on time. But, if only one participant is late, the meeting can not start. How late they are determines how much variability in the start time of the meeting there will be.”
“How much variability or uncertainty can you expect? Hard to know, but imagine we have five tasks in parallel, all which must be finished before starting the one task they are integrating into. The probability is that some tasks will finish early 50% of the time and 50% of the time they will be late.”
“What is the probability that the one integration task will begin on time? Answer––0.5 x 0.5 x 0.5 x 0.5 x 0.5 = 0.0325 or about 3% of the time.”
Jim gets it, he says, “the integration task cannot start until all the parallel tasks finish. With a low probability of finishing each leg on time, the integration task seldom starts on time. When enough tasks don’t start on time, tasks don’t finish on time. And, when too many tasks don’t finish on time, the project does not finish on time.”
Gary summarizes where we are so far. “How does your company calculate the length of your projects today? They used the Additive Rule; they add up the task durations to determine project length. Using the additive rule leads top management and sales people to believe the project can be finished well before it can actually be finished.”
“But, the additive rule does NOT recognize the variability of tasks, task dependencies, nor the impact of integration points on project lead time. In projects, 10+10 does not equal 20. The task durations are not deterministic; 10 days could be eight days, but a task could also take 12, or 20, or more days.”
I can see Jim settle down after he takes a deep breath. I have to admit, I’m starting to see Gary’s point about where all the safety time comes from. Single tasks, task dependencies, and integration points are all normal parts of every project. But, what’s new about that?
Safety Time Is Everywhere
It’s as if Gary is reading my mind. He says, “what I want you to realize, is that you have safety time everywhere. The way you are using it today does not seem to be helping you meet your objectives. If there was a way to use it in a different way that helped you, would you be interested?”
“Yes, that makes sense,” I say, “but this is far from convincing me to do something about the added safety. Folks have been managing projects with safety time for a long time.”
Now Gary nods, but Jim interrupts, “and we’ve had problems finishing projects on time or as soon as they could be finished for as long as I can remember, too.”
He’s right, I need to be patient a little longer. The safety time we are putting into our tasks seem like they are there for legitimate reasons.
Multi-tasking, Uncertainty & Safety Time
But, Gary asks us, “do you project team members multi-task?”
Of course, I say, what does that have to do with adding safety time?
Gary say, “within a single project there is a delay in competing a task when resources are switching, midstream, from task to task. This can also effect the start of the next tasks. How much variability or uncertainty can be expected? More than the average and sometimes much more than the average. How much safety time will you try to add?
“As much as I can get away with,” Jim says.
“And, how many tasks are in your average sized project? An approximation is good enough for my purposes.”
I say, “about 250 tasks over a 45-60 day period.”
Gary asks, “how many tasks, dependent tasks, integrations points, and multi-tasking are present in a project with about 250 tasks?”
A lot.
“How much variability or uncertainty can you expect? More than the average and sometimes much more than the average.”
“How much safety time will Jim try to add?”
“As much as I can get away with,” says Jim.
Silence around the table. There is a clink of glasses nearby. Am I supposed to realize that Jim is deciding to add safety and estimate how much to add. Is there something I can do to stop him from doing that?
Multi-project Environments Distort Priorities
After a pause, Gary bring up point about multi-project environments. “Let me first describe what I mean by a multi-project environment. In most multi-project environments, to get better use of people, most of the people are not dedicated to one single project, they multi-task. They are organized in groups, or departments, according to their skills. Each such group performs certain types of tasks for many projects.”
“Sure, we do that, too,” I say, “it seems like, in general, a positive thing to do.”
Gary says, “right, but it can be mis-used because, its usually not enough to have managers in charge of the various departments. Someone has to be in charge of the projects. Otherwise, who will synchronize the project efforts? Who will look after the project as a whole? In multi-project environments we usually see a matrix between department managers and project managers.”
“Unfortunately, in this matrix structure, the project manager’s responsibility does not match their authority. They are in no position to command which person will do what or when. The resources tasked to work on the project report to the department manager not the project manager.”
“Now, put yourself in the shoes of Jim, the project manager. He is tasked with completing a project on time. He is also well aware the project has a high chance of slipping, especially if the resources he needs are not working on his project for a while. Since he can’t dictate, he puts pressure on the department manager. Jim wants to have the department resources work for his project. Not on other non-important stuff like the projects he is not in charge of.
Jim snickers. I laugh.
Gary says, “Jim has to expert a lot of pressure, because he knows other project managers are doing the same.”
I take another deep breath and look at Jim.
Gary says, “but now switch to being the Department Manager. How are they supposed to decide which projects their resources should work on? How do they decide which project deserves to have a higher priority?”
“To make a good decision they need to know two things––1) when is the project due, and 2) how much time is still available. And, as we’ve talked about already, safety times embedded in tasks are masking the estimate of how much spare time is still available. The department manager is making decisions based on faulty information.”
“So, as a Department Manager, what can you do? What every other department manager does––you move your people between projects in an attempt to please them all. How effective do you think that will be?”
“The masking and misusing of the safety time translates into a lack of clear priorities, doesn’t it,” I say.
Gary adds, “it’s worse than that. Multi-tasking also causes, in downstream departments, overloads because of the large batches of work moving through the system. During period of no project work, downstream department experience too much idle time and inefficiency”
I can see bad-multi-tasking is much more pervasive than I thought. I smile at Jim and ask, “why can’t you control your people better and force them to stick to one task?”
Gary hears the frustration in my voice and a slight scowl on Jim’s face begins to show.
Human Nature
But, Gary begins with another story about situation he found himself in many times. “Let me give you an example of human nature as it relates to managing projects. When I’m planning a project, I’ll go find a resource and ask how long a task will take to complete. The resource says two weeks, even though everyone knows the task could take only 3-4 days. Ten days are entered in the project plan.”
“Everyone knows the resource has other tasks to work on. Emergencies do come up. And, as we have seen, the amount of variability within and between tasks is very high. Everyone also knows that once the project is scheduled these task duration estimates will get attached to task due dates. The duration estimates become their commitments. Commitments you will hold them to.”
“Of course,”, I say, “what else can I do to try and keep projects on track?”
Gary says, “We’ll get to that, but stay with me here. What if a resource does indeed complete the task in three to four days. Will they tell anyone? No, because they promised to finish the task on a specific date. Meeting promises is an indicator of their reliability. They will find something else to add to the task or sit on it and not report it complete until the date they promised.”
“Another aspect of human nature I’m sure you know about is how resources deal with the stress of working in your environment. For example, say that I’m already busy with four or five open tasks. I also help the team with an unplanned tasks from time to time. And, if I know when I finish a task all you are going to do is turn around and give me another one, where is the relief in that?”
“Or, with all the other work the resource have on their plate, they could put off the task for six or seven days and finish it in the expected three to our days. This is called the Student Syndrome. And, when does Murphy strike? The day before the task is due, so sometimes it’s late anyway.”
“How much variability or uncertainty can we expect? More than the average and sometimes much more than the average. Human behavior is what it is, but it’s also extending the duration of the project without any corresponding benefits.”
Another pause. “OK, one last thing we need to talk about,” says Gary, “the illusion of time.”
It’s been a long lunch and we’ve gone over a lot of ground. Now, we are going to talk about time? What is time? I look far off into the corner of the restaurant and see nothing.
Another Reason Predictions Are Difficult To Make
Gary looks over his shoulder and says, “we must make predictions about when a project will finish. I’ll give you one example to show we, as humans, are not very good at it.”
“Let’s use this example––at 9am, I am at my office in Itasca, IL and need to be at an important customer meeting in Spring Green, WI. The meeting is 120 miles away and starts in two hours. If I want to be on time, I will have to average 60 miles per hour.”
“About half-way, in Janesville, WI, I stop for a break and I calculate my miles per hour because there were some construction delays along the way. It turns out my average speed was only been 30 miles per hour. My target didn’t change; the meeting is still on for the appointed time, 11am. How fast do I need to go to keep my promise of being in Spring Green, WI in time for the meeting?”
“Let’s see, 90 miles per hour (90 + 30 = 120 / 2 = 60 miles per hour). Right?”
“Wrong,” says Gary, “if my average speed was only 30 miles per hour, it already took two hours! The answer in infinite, I’ll never make it. Time has run out.”
A Quick Summary
“So, take a deep breath and allow me to summarize where we stand:
-
- Using the additive rule in projects leads top management and sales people to have the impression that the project can be finished before they can actually be finished.
- This forces the people who are doing the work to add safety times buy inflating the time estimates for the individual tasks.
- Inflating the time estimates, in turn, leads to distorted work and reporting practices and to the student syndrome.
- These effects cause the safety time to be misused and masked.
- Misusing the safety leads to missing the commitments. And, when people miss their commitments, what do they do the next time they are asked for an estimate? Add even more time or as much as they can get away with.
- Masking and misusing the safety translates into a lack of clear priorities.
- In multi-project environments, the lack of clear priorities combined with the fear that projects will not finish on time, leads to bad multi-tasking.
- Bad multi-tasking increases the lead time of tasks and of the projects.
Now estimates of individual tasks are inflated and it is much more difficult to finish a project on time. And, when people miss their commitments, what do they do the next time they are asked for an estimate? Yes, this negative feedback loop is magnified.
- Bad multi-tasking also causes, in downstream departments, overloads followed by under loads. Resources are underutilized.
- When resources are under-utilized, there is a tendency to release more work into the system so that people will always have something to work on and which increases bad multi-tasking even more.
What does this all mean to you? It means you have an immense amount of safety embedded in the time estimates of the individual tasks. The way you are using this safety time is not helping you improve your project performance. Somehow, you waste the additional time. You mis-use it.”
Check mate. Game over. I don’t know what to say. Neither does Jim. It’s been a long lunch and the lunch rush crowd is long gone. Silence.
“If we can find a way to use the safety it should be more than enough to enable finishing all projects on time. Actually, sometimes even before they are due,” says Gary.
“Can we use what we’ve learned to reverse the vicious cycle we are in? There is a method to my madness. I would not have taken over two hours out of your busy day if I didn’t have a way out. Follow me.”
I didn’t know it at the time, but these two hours were enough to change my work life forever.
