Category: Senior Executive

The Lunch That Changed My (Work) Life

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:

    1. projects involve high uncertainty, and
    2. 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:

    1. 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.
    2. This forces the people who are doing the work to add safety times buy inflating the time estimates for the individual tasks.
    3. Inflating the time estimates, in turn, leads to distorted work and reporting practices and to the student syndrome.
    4. These effects cause the safety time to be misused and masked.
    5. 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.
    6. Masking and misusing the safety translates into a lack of clear priorities.
    7. 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.
    8. 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.
    9. Bad multi-tasking also causes, in downstream departments, overloads followed by under loads. Resources are underutilized.
    10. 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.

Are There Better Ways to Constructing a Project Network?

We need a better way to manage projects. The ways to address the issues we have was time well spent to test and understand them. We developed a list of solution criteria––the elements that any solution to project management issues must meet. These elements came out of a meeting with our senior executives where we discussed the needs of the business and what our team needs to do to meet them. These criteria are:

    • Projects are on time, every time.
    • Cut project duration without compromise on scope, quality, customer service, lead time or budget.
    • Show a positive impact within six months, or less, and is sustainable over the long term.

It’s a high bar. And, with this list of criteria, it will trim any suggestions which can’t meet all three. Everyone has ideas about how to improve and we need the best ones as soon as possible. I don’t have time to hear about more MS Project.

Gary, the Software Salesman

Jim, one of my project managers, brings in his friend, the software salesman. Gary is his name. I can’t help but think what he will try to push down my throat. We’ve tried so many different softwares for so many different problems. I’m taking a deep breath to loosen the tightening in my gut.

But, I trust Jim, because he’s come through for me before. I’ll listen, but my tolerance level is low and my bullshit meter is on stand-by.

After the usual, pleasant introductions, Gary says let’s get to it. He says he has listened to Jim summary of our situation. He’s familiar with all the issues in our environment. For example, the original due dates are not met. There are too many changes. There is too much rework. There are many more, but that’s a good enough start. Jim has also briefed him on the criteria we want to meet for any solution we are looking at. I’ll be testing each of Gary’s claims against them.

The Kind of Project Network We Need

Where Gary starts surprises me. One of the fundamental features his software is that it determines the longest leg of task and resource dependencies. It’s not critical path. His method, the critical chain, is a more recent approach. It’s not something that was developed in the 1950’s.

Interesting, someone also not interested in sticking to the conventional critical path method. A point in his favor.

Gary continues to explain that to start building a project network in this way starts with the end in mind.

Who said that, Steven Covey?

Gary continues, each project must have a single goal and success criteria. He says there are a few, key pieces of information we need to start every project, but these come first. He says some people refer to it as a stakeholder analysis. We’ll look at it in more detail, if necessary.

But, what Gary says next is surprises me even more.

An Important Project Network Building Step

He wants to start building the project network from the final task and construct the project network from right to left. The final task is the only task that does not connect to a successor task, every other task connects to a successor tasks.

I ask him why? Why build a network backwards?

Gary says, when we work backwards we are including only those tasks that are necessary as input to the next step. In this way, we find we need much less detail, yet the end result still meets all the stakeholder needs.

He says, it’s helps to repeat this mantra each time before another task is added:

“To start this task (the successor task) what task or tasks (predecessors) must be finished?”

For example, he says, here is a final task objective and the exit criteria for a project he has helped plan in the past:

The goal of the project is––The vendor will buy and install new video surveillance cameras, servers, software and intermediate disk storage.

The final task name is––Install 230 cameras and associated hardware for the City of Dallas video surveillance system.

The exit criteria for the project are:

    • Complete by August 1, 2013
    • Complete a demo of the system and get sign-off from the Chief of Police.
    • Support the City of Dallas’ crime reduction goals.

Gary writes on my white board:

To start this task, Install 230 cameras and associated hardware for the City of Dallas video surveillance system, what task or tasks (predecessors) must be finished. He says, Get project sign-off from the Chief of Police.

To start this task, Get project sign-off from the Chief of Police, what task or tasks (predecessors) must be finished, asks Gary. He says, Prepare sign-off documentation.

To start this task, Prepare sign-off documentation, what task or tasks (predecessors) must be finished, asks Gary. He says, Complete the internal QA of the video system.

With a straight, flat voice I say I get it. It’s so obvious now that I see how it’s done. It does take a bit more thought on my part, but I don’t see a flaw in the logic between the tasks. We continue like this until we reach a tasks which has no predecessor.

If I read the tasks from left to right, they sound like a short paragraph in any technical manual we have laying around. Intrigued, I ask, what’s next?

Assigning Resource Types & Estimating Task Duration

I assume there is more to the project, but you get the idea, says Gary, there are only three more key elements to add. The next two elements go hand in hand––assign resources to each task and estimating the task duration. Assigning the resources usually means identify the type of resource best suited for the tasks at hand.

Sometimes some resource types are in limited supply and it’s OK to provide a specific person. But, by providing the resource type it helps improve the flexibility of assigning actual team members. Gary says the software will identify which tasks need to be assigned and when. It will also list the resource type(s) assigned to during planning. When the time comes, the resource manager can check which of their team members are best suited to do the work and make the assignment.

That’s makes sense, I say, very convenient. But, what about the task duration, I ask.

Once again, Gary throws me for a loop––the task duration is only the touch time of the task. The touch time means only the time estimated to do the work content, without interruption, given all the required inputs. No more safety time is added to the task estimates.

None, I ask.

None, he says.

With that answer I look to Jim and ask, isn’t it time for lunch? We are experts at adding safety time to every task. We are experts at hiding the safety time we add to a project so that no one can take it way from us. It’s a way of life around here. It’s how we protect our collective behinds. But, there must be something to it since everything else Gary has presented had made sense up to this point.

A Potential Deal Breaker

This morning was a refreshing change from the typical software sales. Gary understood our situation, sold me on practical ways to start dealing with it, and kept me engaged without showing any software. Gary was in alignment with me about the longest leg of task and resource dependencies. He enhanced this concept by making sure the goal at the end of this leg was clear and contained specific success criteria. And, by working backwards, right to left, from this goal, the only tasks we added were the one’s which needed to be there. Nice.

On our way out the door, I hope this safety time issue isn’t a deal breaker. I was so hopeful. Like I said before, we must put in safety time to protect ourselves from so many things. Only including the touch time for each task duration estimate is the most way out thing he’s said so far.

Is the Critical Path Method Still Valid?

Not in my environment, here’s why––it’s does not mention the work resources in the definition. You see, the competition in our industry is very competitive. Our competitors offer new features and better ways of doing things. Some of it is marketing hype, but our customers don’t seem to notice. Price is always an issue. Our customers have folks dedicated to getting the best price from their supply base. Of course, the quality of our product has to meet or exceed specifications. Our industry is regulated and major penalties have been imposed on those companies who have faltered. What does all this have to do with critical path? Who does all this work in our company? Our most important resource––people!
 
And, like everyone else, customers want what they want now. Even when the items ordered from us are being developed and manufactured for the very first time. The lead times we offer are always too long. OK, they say, then tell me when I will get it. We look in our crystal ball and tell them six to eight weeks. And, six to eight weeks later we still haven’t shipped their order. What does all this have to do with critical path? What information are our people using to set these order lead times? The estimates our project managers tell them based on their critical path plans.

The Critical Path

Here’s what I’ve learned––the critical path is defined at the longest path of task dependencies. In a project, we need to do one task and deliver the work of that task to the next task. This next task is dependent on the work of the prior task. Yes, there are many paths through the project, but when we know the longest path we have some idea about how long the project will take to finish. We also know when it needs to start. That’s the theory, at least.
 
But, my team tells me that they already know all this and that’s how they estimate the lead time we tell our customers. I look at them with a slight kink in my neck since our ability to meet the estimates they provide is so poor.
 
I asked some of my project managers if their critical path takes into account the resources who do that work.
 
They tell me, of course, they assign resource to every task in the project plan. Fine, but that’s not what I’m driving at.
 
I ask, does it every happen that we want to start a task, but the resource we’ve assigned to do it is not available.
 
Oh, they say––all the time! So, I ask, if the resource is not available when you need them doesn’t that extend the length of the project?
 
Of course, they say, that’s why we are always looking to add more people to our team. This is a very common issue.
 
I see they are not with me. I ask again in a different way. If the longest path of tasks determines the length of the project and if the unavailability of resources can also extend the length of the project, what’s the result? We can’t be providing reasonable estimates.
 
So, we are dependent on the resources, and the task dependencies, to determine the length of the project.
 
And, that’s usually where the conversation ends or moves to another topic. They have no answer for it. Neither do I, if I’m honest.

A Small Light At the End of the Tunnel

The length of the project must include resource dependencies and task dependencies. The critical path method does not do that. So, why are we using it? I’m talking to the wall.
 
Without taking resources into account it make it difficult to plan the current and future load on our resource. No wonder we never know in enough time which resources are in short supply. When resources are in short supply, it puts more stress on everyone else. And, the stress in our environment is high enough already.

A Better Approach

We need to find a solution which does include task and resource dependencies. We need to get a better handle on how long a project will take. Not only to give our customers better information, but also know the load on our resources.
 
A quick Google search on “includes task and resource dependencies” results in finding this: “For the critical chain method, you would take resource constraints / dependencies into account when planning projects.”
 
What is this critical chain method anyway? This seems promising and seems to fill that gap in planning task and resource dependencies. I’m going to go find out more about it, but first I have to deal with the line of folks waiting to see me.

What Happens When Resource Limitations Are Ignored

The usual hum of the shop has gone missing. It’s not there. Silence. I tilt my head and wonder why I don’t hear anything. Strange. Unusual. My feet propel me out the door and I see the supervisor of the fabrication shop rushing towards me. He tells me his department is at a stand still because one of my IT engineers called in sick. Who is it I asked. He throws up his hands, lets out a deep sigh, and says Roger. What project was he working on, I asked. The Fabrication Shop’s Industry 4.0 shop floor data collection project. Off he goes in a huff.

Put off, I turn around and see my Lab Supervisor coming my way. Now what, I say to myself. Same story: lab shut down, Roger, data collection project. Off in the distance, I see my Shipping department manager. I can already guess what she is going to say.

Where’s Roger?

I can’t believe it. The whole shop is shut down because Roger is not here? It’s time to visit the IT department and find out what, if anything, I can do to help. But, I don’t have time for this! I committed to myself and others I would look for answers to the criteria for a good project management solution. Now, I have to referee the “fights” between the departments effected by the project Roger is working on.

We have most department limping along, but what ties all these departments together? Sure, there is a common IT project intended to collect real-time shop data from each department. We have IT projects running all the time.

From what I can gather, Roger was working with a vendor and testing their equipment under real world conditions. Somehow, this equipment shut down each department it was connected to. It also crashed the production management system. This system releases and tracks our work orders, too. He was to only one aware of how the equipment was supposed to be configured. And, despite repeated calls, no one is able to reach Roger.

Key Resources Working On More Than One Project

When I have a chance, I catch my breath. This is a prime example of how one resource, spread across many projects, can jeopardize our whole business. After the morning I’ve had, I don’t want to go through this again anytime soon. We were able to put a patch on most of the departments effected by Roger’s equipment outage. But, that addresses the symptoms of a deeper problem.

If we ignore the limited resources working between many projects, problems will continue. It’s easy to see the delays have extended our lead times, effected our due date promises, and cost us more operate. I heard myself say, do whatever it takes to get up and running, too many times today. My team stepped up, but how much it will cost to switch back to operating the new data collection equipment. I’ll worry about that later.

Another Project Management Solution Element Identified

For now, knowing how much resource capacity we have and how it is spread across many projects must be an element in our project management solution.

What Does a Good Solution To Our Project Management Problems Look Like?

Some Background

A small group from my final assembly team worked late into the night and we still didn’t get one our most important orders out the door. Dejected and exhausted, I told everyone to go home. We would try again tomorrow, but no one acknowledge me at they shuffled out the door.
 
After tonight, if someone is not aware how bad our due date performance is and the size of the problem they must have their head in the sand. Missing due dates is a reoccurring pattern for us and many customers have lost trust in us. Some have not ordered from us in a long time. The orders we do deliver, we deliver late and pay liquidated damages for being late. We are almost paying our customers to take our products away.
 
Our customers have their own production schedules to meet. When a key supplier delivers late, rescheduling their shop will be necessary. By rescheduling, priorities must be changed to what they can work on. Sometimes crews have to be moved from one location to another; this take time. Subcontractors have to be sent away and may not be available when you need them again. Equipment usage goes down since a machine, or a whole line of machines, needs to be set-up for something else. And, if they are anything like us, their Finance department complains about the higher work in process and take on more working capital debt.
 
I get it, the same thing happens to us. When our suppliers deliver late, we have even less time to deliver a quality product on time. Do we cut corners which may come back as higher service costs in the future? Do we have to work overtime and cut into the already thin margins? Answers I know and keep to myself. I still have to find a way out of this mess.
 
It’s time we decide on what the meaning of a good solution to our project management problems is. The trick will be to make sure the solution prevents any new problems to surface. The cure can’t be worse than the pain we are in now. All we need to do to is define the criteria for a good solution and show the value of each criterion. It sounds simple, but we need to be able to see the solution when we find it.
 
But, I was interrupted by a phone call. On the phone was one of our long time customers. To say he was upset was an understatement. It was his order we didn’t get out the door last night. All I could do was practice my empathy skills and feel the speaker explode in my ear. I’ve been friends with this guy for a long time. He calmed down, apologized and left me with nothing to say. Never the less, I asked him to meet me for lunch. I needed to find a way to repair our working relationship.

A Most Important Lunch

After we ordered lunch, I asked my friend what we needed to do to keep his business. I was surprised by his straightforward answer. It came in three parts––first, deliver your projects on time, every time. This is the only way to restore our company’s trust in yours. Second, continue to deliver the quality product we’ve become accustomed to. We also appreciate your good customer service and competitive pricing. Third, keep the first two things going over the long term.
 
Is that all, I asked. He didn’t take it as a joke. His gaze continued to bore into my soul and I could see how serious he was. He smiled. That’s when I realized it was our friendship that saved our company from disaster. He was giving me one more chance. I wasn’t going to let him down. I was also doing it for myself and the 250 other people back at the plant.
 
On my way back to the office, I started to prepare the speech to my staff about what I committed to. I better be well prepared because I’m sure they’ve had enough of my antics to improve our situation over the years. I hope they will listen one more time.

Agreeing on THE ONE Project Management Problem

Preamble

To claim there is one, and only one, project management problem to solve is daring. But, I’m going to do it anyway. My project team and I are at a cross roads––we will continue to suffer in silence with our project issues or take a bold step towards a search for a new solution. We need something to focus on and use all the energy we have to overcome our one, and only one, problem.

There is something comforting about the familiarity with the project issues we’ve faced. As humans, we crave stability and the familiar, even when it’s bad for us. To search for something different, something outside of our day-to-day existence, and to assume there is only one problem to solve is daring. Or, ludicrous.

The Things That Make Our Lives Miserable

So, let me explain. As I lean back in my chair, I close my eyes and recall the long list of project issues we complain about. These include:

    • All too often promised task due dates are not met.
    • All too often tasks take longer than planned.
    • Too many changes.
    • All too often resources are not available when needed (even when they are promised).
    • Necessary things not available on time, e.g., information, specifications, materials, etc.
    • Fights about priorities between projects.
    • Budget over-runs.
    • Too much re-work.

There are a lot people in our organization who think these issues are a normal part of running a business. We need to suck it up and live with them the best we can I hear them say. They point to themselves and say, “Look at me. I’ve dealt with these problems for 30 years.” They also look defeated. I’ve heard someone else say our problems as leadership issues––if we only had leaders who knew what they were doing everything would be better. They could all be right.

But, I’ve had enough of these issues. I know there must be a better way. I’ve seen the effects that one task has on another. I’ve seen the effects of having integration points. I’ve seen the effects of not being aware of resource dependencies. Our projects average about 200 tasks. The variability inherent in our project networks alone is overwhelming.

Digging Deeper Into Our Issues

But, I’ve also learned it’s not the project network’s fault. It’s the way we are planning and executing the projects that count. For example, every team member knows to add safety time to their task estimates. They hope the time will cover up the variability along the way. We also focus on finishing each task on time instead of focusing on finishing each project on time. Due date performance of the project is more important than any individual task.

Because our company’s poor due date performance, we have lost sales. I’ve noticed some of our oldest customers don’t show up in our order book anymore. Our CFO tells us we pay too many penalties for being late, too. And, our Sales folks are in my office far too many times. They usually have a good joke to tell. But, in their own way they tell me we are not competitive in some markets due to our long lead times. Ouch.

When we do deliver a project, the ROI is so small we all wonder if it was worth it. The obvious reason is that almost every project goes over budget. I don’t know where the company gets the money to cover budget overruns, but I’m glad they do. The competition is always trying to offer similar solutions at a lower price, so most projects don’t have room in the budget for overruns from the beginning. The main reason for budget overrun is that most project take longer than planned. Paying the team resources must happen (or the project don’t get done).

Why do projects take longer than planned? Well, look at our rework hours––too high. Look at the number of change orders, either from our customers or from other departments––too high. But, when I have time to review the reasons for rework or changes in scope, I rarely find specific tasks in the project plan they relate to. So, I know our project plans are incomplete. I also know we have good people planning projects. I suspect the stress and inability to get things done contributes to the incomplete project plans.

Even Deeper

Another reason projects take longer than planned is when there are resource priorities to resolve. Meetings with the related departments need to be scheduled. The scheduling takes time and the meetings always seem to drag on. While this is going on the tasks which need these resources sit idle. And, to look busy my team works on what they can work on (usually by starting tasks before they are ready to start). Meanwhile, the clock ticks on.

There has also been a disturbing trend of good people leaving. In their exit meetings, they all say about the same thing––it’s too stressful, I can’t get anything done and I don’t see anything being done about it. These kind of comments hurt the most. I also know folks protect themselves by not letting me know they are finished with a task. I’ll only give them another one and they won’t get a minutes relief.

In our resourcing priorities meetings the idea of hiring more people comes up. But, our CFO is there to remind us our efficiency numbers aren’t even close to 100%, so we don’t need more people. I do see how busy people are. I see it everyday, but I also know there is a massive amount of multi-tasking going on. I know this because I’m the one making the task assignments. Most folks are supporting more than one project. I estimate that most people are supporting about three to four projects and at least two to three tasks per project. But, what can I do; the projects keep coming.

I’ve tried to limit the number of tasks any one person is working on. But, this is impossible because our Governance Committee is releasing projects at a rate we can’t keep up with. I’ve learned to keep my mouth shut about the overwhelming amount of work our team has to take on. No one ever asks me if I have the capacity to take on more work. But, our company needs the orders to survive.

Summarizing Things for Myself

As I walk to my next meeting, I summarize my situation in my head––on one hand, I am forced to start projects without all the necessary information. Many of our projects are being done for the first time, with a different set of team members, under different circumstances. This is a given. But, information about how long tasks will take, how effective folks are at doing the work, and specter of Murphy (of Murphy’s Law fame) lurks in the background. It seems hopeless––I will never have all the necessary information I need when I start a project. Nor, will I have accurate information as the project proceeds. The amount of uncertainty and potential variability is massive.

Now I’m Dreaming

So, if I could wave a magic wand, I would want to start all projects with the necessary information. We can have a consensus on the project’s one goal. We can have a well defined list of project deliverables. We can have a list of required things from outside suppliers. We can assess all the risks. And, we can determine if the necessary resources in the right quantities are available. How? I don’t know yet.

But, from this starting point, the number of scope changes would go down, the amount of rework would go down, and there would be less multi-tasking. The net effect would be shorter project plans, a better ROI and an improvement in our company’s financial situation. And, the our potential way out of this mess must also include managing the uncertainty and variability.

Meanwhile

But, in the meantime, we are stuck. Must we start projects without the necessary information? Or do we continue to wish we could start a project with all the necessary information. This is the one project management problem to solve. We must find a way to break out of the conflict these two competing actions.

When we had the necessary project information better things happen. Each resource would be better able to successful meet the task’s completion criteria. We could stay within budget and finish tasks close to the original task duration estimates. During execution, we may have to find a way to determine the impact of the the uncertainty and variability.

One day we will be able to consider a project successful––when it meets the customer’s scope requirements, at a reduced cost, and delivered one the promised due date. I don’t know if anyone else see this. This has got to be my focus.

Without find a way to create a project environment like this, we will continue to struggle and survive. That’s no way to spend my days. That’s no way for the talented people on my team to spend theirs either. And, that’s no way to be a part of company everyone can be proud of.

Is making predictions a project management skill?

Yes, it is!  What is one of the end results of gathering project requirements, assembling your team, and planning the project? An important outcome is the expected due date. You may think to yourself that date is going to be easy to hit or it’s going to take a miracle to bring the project in on time. No matter what, you are, in effect, making a prediction about the future.
 
As I’ve mentioned in another blog post, we humans are not very good at making predictions. But, the fact is you agreed to take on the role of project manager. You agreed to lead of group of people towards a goal. You can’t wait to get started or to reach the next milestone. By taking on the role of project manager, whether you like it or not, you have agreed to make predictions about the future.

Risky Business

Do you realize what a risk this is? You may be the kind of leader who like’s taking risks or has been successful at avoiding the negative consequences of risky behavior. For others, we realize that many projects do not proceed as planned or can fail in many ways. For example, you may have experienced one or more of the standard failures:
    • Many of your projects are late.
    • Usually, the original due dates are not met.
    • There are too many changes to deal with.
    • Too often resources are not available when needed (even when they are promised).
    • The budget runs out long before the project is done.
If you get nothing else from spending your time reading this post, I want you to remember one thing:
 
every project manager must deal with the few things which make it difficult to make reliable predictions.
 
Every project manager strings a series of tasks together. Every project manager has to combine parallel work efforts and integrate them. Every project manager doesn’t seem to have enough people on their team. Every project manager finds working with other people difficult. Every project manager is bound by a limited budget. Every project manager agrees to meet or exceed their customer’s expectations. Every project manager hears the ticking of the time left on the clock. Every project manager must deal with the few things which make it difficult to make predictions.

Next Step

Does this sound like you? If so, stick around, because we’ll examine each of the things which make your job difficult when trying to predict the project’s due date. Once you know what they are and know what to do abut them, you can look forward to experience more of these standard results:
    • Most projects are delivered on time.
    • Usually, the original due date is met.
    • Changes to project plans are well managed.
    • Resources are available when needed.
    • The budget supports the completion of the project.
Are you with me?

The Project Management Core Problem Proposal

The way we manage uncertainty in projects fails to protect the due date.

You may ask, “Are you telling me that when a project is delivered late, it’s because the uncertainty was not managed?”

Yes, that’s what I’m saying.

We can do all the project requirements planning as we want, recruit the best team members, and have a budget others would be jealous of. None of these things will help up correctly predict the future. It’s a fact uncertainty exists in all projects.

We also know that the three key objectives of every project––duration, scope and budget, are interdependent. A change in one will have an effect on the others. For example, when many projects are delivered later than planned, we can expect costs to increase. It’s a fact that the longer a project runs, there’s more time to make changes, too

But, what if someone asks for another feature or more functionality beyond the agreed upon scope? Accepting these requests, costs go up and the project will take longer to finish.

Although, one way to reduce costs and reduce the length of the project is to reduce the scope. Many times this seems like a good idea. But, what about work that was underway? Some work may have to be stopped and scrapped. This wastes the team’s efforts and the costs associated with the work.

Salvaging some of the work may help, but this could mean rework. Rework also comes at a cost and the potential for lengthening the project’s duration.

Yes, it’s clear that the three key objectives of every project––duration, scope and budget, are interdependent. But, the cause which effects them all started with the fact what uncertainty exists in all projects. If we fail to manage uncertainty in projects, then many project are delivered later than planned, etc., etc., etc.

So, if we do manage uncertainty in our projects we can improve our on-time, scope, and budget performance?

Yes, that’s what I’m saying.

In the upcoming Core Problem posts, I’ll go into more and more explanation. I’ll give many reasons for why we must manage uncertainty. If we want our projects to achieve the scope, cost and on-time delivery objectives, it’s something we need to do.

What Executives Need To Know About Quickly Improving Performance In a Multi-Project Environment

The Problem

When too many projects are executed at once many resources will find themselves under pressure to work on more than one task. Bad multi-tasking is unavoidable. This is like the stressful feeling you get when you have 99 things to do today and only time for half of them. Within your company, most of your resources feel the same way.

Prolific bad multi-tasking significantly prolongs each project’s lead-time. This makes it harder to meet your promised due dates. If your lead time or due date performance is not what your customers expect it to be, prolific bad multi-tasking usually has something to do with it.

In every multi-project environment, flow is the number one objective. But, what some managers get wrong is their focus on how many projects their company succeeds to start working on. Rather it is how many projects which are completed is what your customers are paying for.

The statement, “the earlier we start each project, the earlier each project will be finished,” is not correct in multi-project environments. As a good friend of mine used to say:

“Not only the first elephant, but also the last elephant, will 
go through a door much faster if they go in procession.”

The Solution

Vast experience shows that in multi-project environments reducing the number of open projects by at least 25%.  This one action reduces bad multi-tasking without causing work starvation. This also reduces the lead time of all projects and increases the flow.

All you have to do is control the number of projects that are open at any given time.

What does it mean to control the number of open projects?

Start with these three things:

    1. The top manager, after consulting with their subordinates, determined the prioritization of all projects. The company is instructed to stop activities on enough (this means responsible for at least 25% of the load) of the lowest priority projects.
    2. Determine and re-assign the optimal number of resources per task and to the remaining, open projects.
    3. The company must also ensure that as time passes the proper amount of work will be always maintained. Defrosting projects too early will, again, flood the system with work. Defrosting projects too late will lead to starvation of work and extend projects’ lead times. So, frozen projects are defrosted at a pace that maintains the reduced load.

The Results

For example, a large Swiss biotech company offers Good Manufacturing Practice (GMP) services for the analysis of biologic, cell line characterizations, impurity testing and cell-based bio-assays. Over the course of three days, the core team and the local works council representative attended our “Increasing Flow” Workshop.

Within one month of implementation, the output of the facility increased 50% from established baseline.

Other outcomes include:

    • Due date performance increased from 65% to 99%
    • Order lead time decreased from 17 days to 5 days (-70%)
    • Employee engagement has increased
    • Net profit over sales ratio increased 35%
    • QA review and the related rework decreased

So, to quickly reduce prolific bad multitasking in your multi-project environment, focus on flow and maintain the reduced level of load on your resources. Your lead times will decrease, your due performance will improve, and the best part–– your stress and the stress on your workforce will go down.

If you want to find out if your organization could get results like these, contact me and let’s work together to find out.  Let’s make it count!

Do Your Customers Have a Trust Issue?


But you’re going to have to serve somebody, yes indeed,
You’re going to have to serve somebody,
Well, it may be the devil or it may be the Lord,
But you’re going to have to serve somebody.
– Bob Dylan (Gotta Serve Somebody / Slow Train Coming
 
In your business, you’ve got to serve somebody. There is a focused, or at least tacit agreement, that your company wants to give the customer what they want. If a good price is something they want, you try to make it efficiently and price it accordingly. If quality is something they want, you try to meet the specifications called for. If certain features are what they want, you try to create a product or service which includes them.
 
But, your company’s environment and the markets they serve seem to be on the bring of chaos some days. This may mean it takes longer to determine how to make something efficiently. To determine the level of quality a customer wants may take more time based on new or unexpected expectations. And, developing or designing new features can take much longer than planned.
 
Customers know what they are going to get, but forcing them to guess when they will get it.
 
Sometimes, customers are willing to wait. They understand novel things take time. The general perception in the industry may be that prices, quality and the desired features may not be available from everyone.
 
But, what if someone in your company made the decision to make a promise to a customer about when they will receive their order? Now, we have a deadline and only so much time to deliver.
 
If you deliver on time, congratulations! But, if you don’t deliver on or before the promised due date, customers who find this an important date don’t seem to take it very well. It may be a single occurrence and find a way to live with the delay. If missing due dates is a reoccurring pattern with your company, they may begin to loose trust in your ability to meet your delivery promises. They may not order from you again or in more damaging cases, expect you to pay penalties for the damage caused by delays to their timeline.
 
Why would your customers feel this way?
 
Let’s take a look at the ways a delayed shipment causes damage. Don’t your customers have their own production schedules to meet? A supplier who delivers late, rescheduling will be necessary. By rescheduling, priorities must be changed to what they can work on. Sometimes crews have to be moved from one location to another; this take time. Subcontractors have to be put off and may not be available when you need them again. Equipment use goes down since a machine, or a whole line of machines, need to set-up for something which can be run. And, the Finance department may complain about the higher work in process and take on more working capital debt.
 
The folks who run your customer’s production operations will realize they will have even less time. They want to deliver a quality product to their customer, too. Will they cut corners to do that? Could there be issues that come back as higher service costs in the future? Will they have to work overtime and cut into the already thin margins?
 
Yet, some customers have learned to live with late deliveries from their supply base. They will place orders with you sooner than they usually do. They are hoping it will give you more time and give you another chance to deliver on time. Or, they will hold inventory of a few, key items to ensure they have, at least, some raw materials available. But, when this inventory is based on a forecast or a guess, obsolete or slow moving inventory has its own problems.
 
But, that’s the way things are.
 
Yes, it may be true that you and your competitors don’t always deliver on time. Your customers don’t have much choice when it comes to deciding on who is more reliable. Your customers want you to be more reliable because they have their own lean, cost, and on-time performance objectives. When a supplier delivers late, these important measurements are effected.
 
Your customer’s labor, inventory carrying costs, engineering, overhead costs can go up; Finance is concerned. Your customer’s Sales folks may have to raise prices and work harder to close a deal. Your customers margins may be squeezed and limit the amount of cash coming into the business; the CEO is upset.
 
Suppliers who deliver late don’t make it any easier to improve a customer’s profits.
 
What, isn’t it my customers responsibility to make a profit? Of course, but look again at the impact your poor deliver performance has on their ability to do that. If I was in their position, I would always be on the look out for a better solution to my late delivery problems.
 
If I could find a supplier who’s deliveries are on time, every time.
 
If they didn’t compromise on their product development, quality, customer service, lead-time or pricing. And, if they could sustain their on-time delivery reliability over the long term, I would begin to trust them again.
 
You may call me anything but no matter what you say
You’re still gonna have to serve somebody, yes indeed.
– Bob Dylan (Gotta Serve Somebody / Slow Train Coming