Category: Uncategorized

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 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