Category: Project Manager

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.

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.

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

What Is a Project Anyway?

You may be familiar with common, everyday projects like road construction, a new building, or an addition to your house. These kinds of projects seem to have no end sometimes. Other projects do have a deadline, like the local 10k race on Labor Day, the grand opening of a new grocery store, or the first day of school.

Definitions

All of these projects meet the standard dictionary definitions:

    • an individual or collaborative enterprise that is planned to achieve a particular aim
    • a temporary, rather than permanent, social system, constituted by teams, within or across organizations, to do particular tasks under time constraints
    • a set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations

Projects Examples

Using these definitions, we can include other more mundane activities as a project:

    • Brewing a cup of coffee with an Aeropress
    • Going on an over night camping trip
    • Organizing a school play
    • Making a pizza at home
    • Launching a new, digital marketing campaign
OK, the last one isn’t mundane, but expand your project definition a little bit for a minute. There is almost always some planning involved, some set of activities you do by yourself or with others, and some sense of time to complete the activity.
 
Projects are not sacred events, reserved for engineers or general contractors.  We all co-ordinate tasks and sometimes “manage” many simultaneous projects.  To be successful in our lives, we need to bring together the right people for the right reason, with the right resources, at the right place, at the right time.
To improve the likely-hood of success, there has been a long history of developing tools and techniques applied to the management of projects.

Measuring Success

Notice how many parts of the project’s definition are needed, e.g., people, the reasons, resources, place and time. And, don’t forget there is a conscious or sometimes unconscious way of measuring success such as:

    • How does your Aeropress coffee taste?
    • Did we forget anything on our camping trip?
    • Did all the actors remember their lines?
    • How crispy is the crust on our pizza?

These definitions of success are in stark contrast to larger corporate-type projects, for instance. 

Large project success criteria include things like:

    • Meeting or finishing under the original budget
    • Delivering all the features and benefits described in the multi-page contract
    • Organizing all the 10k race participants at the starting line at the start of the race

But, don’t be mislead, even our small, personal coffee, camping, school play or pizza projects can be measured by three important elements:

    1. How much did the project cost?
    2. Was everything delivered as planned?
    3. Did the project take a reasonable amount of time or was it completed on time?
Usually, in a wide variety of projects, the objectives for three elements must be achieved in order for the project to be successful.
 
If you take a few minutes today and look for these elements in the things you do, you’ll see almost everything is a project; make it count!