Category: PMO / Portfolio Manager

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.

Why Does My Project Team Think There Is Always Enough Time?

The Status Meeting

This afternoon, I dread going into the office. We are so far behind on so many projects. In the afternoon status meeting, I’m sure I’ll have to go into my standard list of excuses to explain why. And, how long will it will be before the others suspect that I have no idea about how to get back on track. There has got to be a better way.
 
Before the status meeting, I have some time to check in with a few of my team mates. I see everyone seems glued to their monitors or are typing away on something. A few people are already on the phone. If everyone is so busy, how did I get so far behind? I leave them along and start to think back to the beginning of a project’s planning phase. I ask each resource on the project how long a task will take to complete. The resources says two weeks (even though everyone knows anything about the task would say it would take only three to four days). Never the less, I enter ten days into the project plan.

Everyone Is Busy

Back in the office every resource has other tasks to work on. And, emergencies do come up. So, it makes sense to add in the extra seven days to protect the task’s due date. It’s the least I can do for my team, right? When dates are used to focus attention on completing tasks, dates become very important to the resources, to me, and to the managers I report to.
 
I look around and everyone is focused on their task due dates, I’m sure of it. If I’m rushed during our weekly status meetings, it’s the only thing we talk about. Sometimes there is an underlying feeling I can’t quite put my finger on. When a resource tells me they are going to miss their due date, I want to know why. I want jump in and fix things. I may have even blamed them for misrepresenting the effort needed or being negligent at not being able to estimate a proper task duration. It can get very heated. Not good.

My Flashback

I flash back to a meeting I had with Karen. She needed some help deciding on her priorities for the day. She was explaining to me that when a task she’s been assigned to is available to start, she will make a quick check to reminder herself about how much time was negotiated for the task. She will also estimate about how long the task will take to complete. She admitted that if there was enough time, she would put this original task aside and continue work on all the other tasks assigned to her. As the due date of the original task drew closer she would switch and do her best to get it done in the few days she had remaining. This worked out most of the time, but sometimes something would come up and she would miss the task’s due date anyway.
 
My daydreaming ends when I realize my eyes have glazed over. But, could this meeting with Karen be the source of some of my issues? For the original task, if she could focus on it and get it done as soon as she was able to start, the task would take no time at all. And, what if all my resources had the ability to start and finish most tasks without interruption? Could that be the key to getting our department back on track? It would help and I could use all the help I can get.

Two Basic Conditions

I wrote down that my project resources could only work this way if I continued to allow these two conditions exist:
 
    1. the safety is not removed from each of the tasks during planning.
    2. my resources believe during execution there is more than enough time.
I can see how why my project team think there is always enough time.
 
So, my next step is to do something about this situation, but what?

A Source of Multi-tasking You May Not Have Noticed

Oh no, what have I done? During my last governance meeting, I agreed to take on another project. The VP made it sound urgent plus it wasn’t very big. So, what’s the big deal? When I arrived to the morning meeting, I realized I was already loaded and have been working hard these past few weeks to stay even. Now, I’ve added more to my plate. It doesn’t look like anything is going to finish anytime soon. This would take some of the pressure off, but that’s wishful thinking.
 
So, let me think about it––it’s interesting that during times where getting things done relies on finishing tasks. I should be focusing on finishing tasks instead of what I usually do––reporting on how many tasks have started or how many projects have started.
 
But, I can’t think about that right now. I realize I have a much bigger problem––If I’m in this overloaded situation, so are my team mates. If they’ve started more than one thing, I can count on one hand how many they have finished. What’s worse is that I was the one who assigned these tasks to my team. Not good.

Digging Into the Details

As I sit and dig into a project’s details, I’m looking for tasks to finish. I see some promising places in the network where a few predecessor tasks are done, other predecessor tasks are not even started. Of course, the single successor task these tasks are feeding can’t start until all predecessor tasks are done.
 
For two of these predecessor tasks, I dedicated one resource each. For the other two tasks, I only have one person, Marvin, who can do the work (even though we planned on having two people with similar skills doing the work). It seems like there is always a shortage of available resources. I can think of only a few times where I had everyone I needed at the time I needed them.
 
I also remember assigning both tasks to Marvin and left it up to him to decide on which task to start with. What I found out in my status meeting this morning, he made progress on both tasks. For a second I was excited to see both tasks had been worked––progress! But, wait a minute! I need tasks to finish, not start.
 
When I assign tasks, I’m expecting the resources to start them. I need to force myself to limit the number of tasks I assign to my team. Or, not give them the option to choose the one they want to start with. This is counter to what everyone else is doing. No wonder everyone seems busy all the time.
 
What’s a project manager to do? Which task does the resource get assigned to? Sometimes, it feels like the only thing to do is to flip a coin? Once the resource is assigned, could they switch to the other task and work on it without finishing the one they started on? Sure! And, what if Marvin goes back to the original task? Both tasks will take longer than planned. How much longer? Who knows.
 
But, what worries me ever more is I can’t predict how long both tasks will take to complete under these conditions. You see, both tasks are estimated to take two days. But, if Marvin switches back and forth between them, how long will they take? I do know that the sooner two tasks start, the later both would finish because of the switching between both tasks. Later means longer. Longer means delays. Delays mean this project is, or will be, in trouble soon. Not good. Not good for me.

Focus On Finishing Projects, Not Starting Them

I’m looking at this all wrong. Instead of focusing on each task, I should be focused on the effect each task has on the project’s due date. It’s finishing a project that counts, not this funny business of trying to finish tasks on time. As long as the tasks take, on average, more or less than the estimate, it will be easier to predict the project’s due date.
 
But, somebody show me in the project management software where I can see the effect of all the task variability on the project’s due date? It’s not in the software I’m using. I don’t have time right now to do the research. I’ve got to do a better job of focusing and getting things done rather than showing off how busy I am.

In the Meantime

I’ll be a bit more forgiving when my team mates miss their task due dates. I’ll get them some help to catch up, if necessary. That seems like a temporary fix since I still don’t know how these delays effect the project’s due date. There’s got to be better way.
 
Until I find it, here’s what I’m going to do:
    1. Trim the number of places in the project networks where two or more tasks need to be completed before the successor task can start. (I’ll call these places “integration points).
    2. If integration points remain, I’ll try to assign enough unique resources to do the work for all the tasks.
    3. When it comes to assigning the work, I’ll check with the resources before the assignment to limit the number of tasks I assign them.
These steps should help, but I’ll be looking for some help. Is it’s a feature in a different project management software? There has to be a better way. I can’t be the first project manager to encounter these problems.
 
Never the less, I’m going to focus more on finishing tasks rather than starting them. I’m going to focus on finishing more projects before I agree to take on more. I may be less popular with my managers. But not finishing projects on time, breaking the budget and not delivering all the expected features will make them like me even less.

What Can Project Managers Learn From the Actual Start Time of Any Meeting?

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

Do You Control Your Project Dominoes Or Do They Fall Without You?

What did I do? I promised to deliver this project in three months and on a specific date to the whole senior staff. I know better!  Never promise a single date; there are too many tasks, one right after another, each one with a high level of uncertainty. Too many things can go wrong. I’m bound to break my promise.

But, I promised anyway. My customers demanded it. What do I do now? As project managers, making promises is something we do all the time. The three main things we promise are:

    • the project will deliver everything asked of it
    • the budget will be controlled and not exceeded), and,
    • the project will finish on a specific date.

Even if the project is delivered on the promised date, what is my confidence level that my two other important parameters––the budget and the full scope described in the specifications document––will also be found acceptable? I’m in a deep, dark hole.

My lack of confidence comes from knowing about the variability of one task (See blog post What So Interesting About a Single Task). For the smallest project element––a single task––there will be a difference between how long the task is planned to take to how long it will actually take. Variability is at the heart of every task in every project.

Dominoes

But, what happens when we string a series of tasks, with a lot of potential variability, together? Watching one task after another get checked off is a satisfying experience. It’s a lot like watching hundreds of Dominoes fall into a pretty pattern.

But, this project is made up of over 200 tasks. In many places in the project network, one task must finish before the next one can start. These tasks are in predecessor order, which means the first task must be completed before the second task can start. The second task must finish before the third task can start, and so on. Can we predict the effect of one task’s variability on the next? Yes, we can, up to a point.

The Dependency of Tasks

Theoretically, if a project has three tasks, each tasks is planned to take three days, the total planned duration is nine days. Let’s be generous and say that each three day task will finish on time only 50% of the time. What’s the chance that these three tasks will finish after nine days? Flip a coin for me.

If the three tasks finish after nine days, it means there was little to no effect of variability across the three tasks. But, a single task planned for three days rarely takes three days to finish. Why? There are many inputs to the planning of a single task, e.g., the tangible information used to complete the work, the task description itself, the resources required, the agreed upon success criteria, the risks involved, and the task duration estimate. Each of these elements are only known once the task is being worked or has been completed.

What if almost every aspect of the single task planning was underestimated?

For example, each planned three day task took only two days to complete. That’s a total duration of six days, not nine.

What if almost every aspect of the single task planning was overestimated?

For example, each planned three day task took four days to complete. That’s a total duration of 12 days, not nine.

What if almost every aspect of the single task planning was both underestimated and overestimated?

For example, one task took two days, and the other two tasks took four days. That’s a total of 10 days, not nine. For example, one task took one day, and the other two tasks took five days. That’s a total duration of 11 days, not nine.

It’s easy to talk yourself out of corner if your project is effected by fire, war, terrorist activity, strike, lockout, flood or natural catastrophe. Even if your project is not effected by these things, do you find yourself making a bigger deal out of even the smallest excuses when you have to explain why you are or are going to be late?

Summary of Task Dependency

Why did I give in and make a promise about the project’s due date? I could blame it on our customers who is looking to find a supplier who’s deliveries are on time, every time.  We would get more business from them (as long as we don’t compromise on the product’s features, quality, customer service, lead-time or pricing). And, if we can sustain our on-time delivery reliability over the long term, our customers would begin to trust us again.

But, at the end of the day, I have a reputation for making good on my promises. This time, I’ve exceed my own inflated optimism. In a moment of cockiness and self promotion, I may have set myself up for failure before the project starts. I only have myself to blame.

To predict the actual duration of a single task is hard enough. To predict the actual duration of a many single tasks dependent on each other in a predecessor relationship is even harder.

One Way Out

In your projects how many single tasks are there? And, how many of these single tasks are where the successor tasks are dependent on the predecessor(s)?

I know there has to be a better way. But, what due date should I have promise? Generally, I try not too paint myself into this dark and lonely corner.  If pressed, one way out is to give a range of dates, from the best case to the worst case. Your software may not support this, but try to figure it out.  It’s the only way to avoid being disappointed and manage some self-respect.

What’s So Interesting About a Single Task?

Everyone, whether they are a project manager or not, likes stability. Having stability means you can count on things being about the same from day to day; like gravity. Or McDonald’s. What we don’t like in our lives, especially if we haven’t planned for it, are the moments which are fickle, unstable or arbitrary. Like the weather. Or the Hubble Constant. Dealing with variability is part of every project manager’s life.

Whenever you feel like a project is hard to manage, does it feel like you are playing a professional version of “Whack-a-mole?” If so, let’s take a closer look at the most basic element of any project plan––a single task. Let’s see if we can detect where this feeling of instability comes from.

Single Task Elements

A single tasks contains the “smallest effective dose” of project information required to describe a package of work. We usually describe a work package with at least three things:

    • A description of the work
    • The resource(s) required to do the work
    • An estimate about how long the work may take under agreed conditions

We could also include information like the expected outcomes, the key inputs, and identifying the success criteria.

Single tasks are like single cell organisms you learned about in Biology class. Single cell organisms contain all the elements required to sustain life. To sustain life, single cell organisms need to display organization, ability to grow, ability to reproduce, and the ability respond to external stimuli.

In projects a single task is organized with other tasks. These tasks are organized into a project. As more and more single tasks are added to the project plan, the project grows in size. Single tasks can reproduce and morph into other similar tasks. And, single tasks planned one day will respond to various external stimuli when they encounter reality.

The Time Between Planning & Execution

These single task elements are generally well understood. But, here’s one which might not be––what about the condition the task was in when it was planned to the time until the task was completed? For example, a single tasks is planned with the information listed above and given an estimated duration of three days. Many hours, days or even weeks later, the project manager decides this three day tasks is ready to start. The task is worked by the assigned resources. Once complete, do you think is will take exactly three days? Maybe.

Many variables and decisions were considered during the planning phase of the three day task. Many variables and decisions can change before this task is considered complete. The original estimate of three days is unlikely to be the actual duration because of the inherent variability within each element used to describe the task. The actual duration could be two days, or one day, or four days, or six days, or ten days. Or, you could say the task is planned to take an average of three days. This also implies a degree of variability.

As the task is worked, more information about the work is available––the task description may no longer represent the original intent. The resources assigned may no longer be available; different resources were assigned. The resource assigned were available, but didn’t do their best work. The task inputs were passed along from prior tasks without all the expected data; unplanned rework was necessary. Some days it seems like the actual execution of the tasks has no resemblance to the task imagined.

Task Time Variability

But also consider the nature of task time variability. Will the actual duration be a nice bell shaped average of three days?

What happens when someone asks us, “Can I get a minute of your time?”  For one thing, it never takes a minute. It could take five minutes, or ten minutes or more depending on how interesting the topic is. The bell shaped tail to the right of the curve can be long. A discussion like this never takes less than a minute. The bell shaped tail to the left of the curve can be short.

In summation, whenever you feel like you’ve spent your day playing “Whack-a-mole”, look and see if it was due to the differences between what was planned and what actually happened. Do a quick check to compare:

    • How the task was described and how it actually turn out?
    • Who was planned to do the work and who actually did it?
    • How capable you thought the resources were and how they actually performed?
    • How well the success criteria were met or did you have to cut some corners?
    • Did something unexpected happen which effected how long the task took to complete?

Even in the smallest project element––a single task––there will be a difference between how the task was planned to how it was executed. Variability is at the heart of every task in every project. And, since all projects are made up of more than one task how much variability can we expect?

Dealing with variability is part of every project managers life. You could say it’s a fact of life. How well do you do this part of your job?

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?

Do You Have Forever To Finish a Project?

No, you don’t. If you don’t have a deadline, what you are working on is a hobby, not a project.

There are a wide variety of projects. All have the same three parameters––what we have been contracted to do, how much we can spend to do it and how long do we have to do the contracted work.

This last element, how long, is particularly disturbing. It requires us to make a prediction about the future––when will the project be completed.

Are we allowed to take forever to finish the project? No. Everyone seems to want it done as soon as possible or on a specific date. In other words, we are trying to hit a target. And, my definition of a project target is a downrange destination which takes time and energy to reach. A prediction. A hint of a forecast. A guess?

At the same time, you are expected to coax your team into meeting the unique elements your customer has foisted upon you. And, to do so with a limited budget (a budget somewhat less than infinite).

The Nature Of Predictions

But, here’s some news which puts even more pressure on doing both of these things while trying to hit our project due date target:

Philip Tetlock, author and psychology professor at Penn State, conducted a long-running experiment. He included about 300 experts and tracked the accuracy of about 80,000 predictions over the course of 20 years.

He found that experts, relative to a baseline group of Berkeley undergraduates, did somewhat better. How did they do relative to a random guessing strategy? Well, they did a little bit better than that, but not as much as you might hope.

Do you think your project predictions are any different? Check out my short summary of the success rate of a wide variety of projects of those which came before you.

A Portfolio of Predictions

Yet, the bigger problem for us project managers is to make a prediction about a due date for not one project, but often for a portfolio of projects. Compound this with the demand for the number of projects your organizations expects you to deliver is higher than ever.

What do you think happens to project managers who make promises and then don’t deliver on them? (I still cringe when I think about the times I had to tell someone a project was going to be late. What was worse, were the pitiful excuses I had to make to justify the delay. Quite sad.)

Delivering a reliable flow of projects to completion is essential for us to support our organization and our customers. Delays in project delivery lead to cost over runs and reduce the trust of the businesses we support. We also delay the much needed benefits each project is expected to deliver.

No, you don’t have forever to finish a project. If that’s not hard enough, you also have to hit your promised, due date target. Good luck.