Initial Results of Using CCPM to Plan Projects

No two projects are the same. Our place in the business universe is far from ordinary. The things our engineers can do would knock your socks off. Although we have customers who buy from us over and over again, what they want is never the same. Although our project managers lead these projects, the project teams never have the same members. And, the vendors we use to provide goods and services for our projects never know what to expect from us.

After One Month

But, after a month of planning projects the CCPM way, a pattern, a rhythm, and drum beat has emerged from the chaos. The calm voices, the productive meetings and an improvement in our performance measures is almost spooky. It may be the calm before the storm.

There are eight projects in flight which were planned and scheduled the new CCPM way. We have about 20 more projects to go. But, already the amount of distractions and people running to me for answers has gone down. No dark clouds are on the horizon.

I don’t know by how much, but the number of emails from upset customers has dropped off. Of the few measures we are using to track our performance the number of nasty emails per day is the one I am using. I want them all to go away someday, and someday day soon.

Don’t Expect Miracles, Yet

It doesn’t take long to bring me back to reality. My daydream was shattered when I hear our CEO bellow, “Why do I have to hear from one of our best customer, MegaForm, that their project is going to be late? They are threatening to pull the next order they have with us and send it to one of our competitors.” Our CEO has a temper, but today his voice was flat and firm. But, below the surface, I saw the dragon straining to be unleashed.

Remaining calm, I say, “I won’t give you excuses. Let me look into it and see what I can do. One of our best project managers is leading that project, so there must be a reason.”

The majority of our projects are still waiting to be re-planned. My hands are sill full with the unplanned ones. But, it’s how our customers are managing projects. It’s what our competitors are doing it. It’s what the professional organizations tell us are the best project management tools. How could they all be so wrong.

Somewhere along the line, the world has been suckered into a mediocre status quo. And, some folks think that’s alright. Some folks like it there. Although, we are not out of the woods my any means, I see there is a different way and a way which may raise us above the mediocrity. Right now other people’s way of doing things is not my problem.

Before I could say anything else, his back was to me as he huffed out of my office. Still, my anger was building, but after a few deep breaths and I felt the feelings pass. It’s a good thing, too, since Jim was the next person to walk into my office.

More Good News From the Front Lines

He says, “Hey boss, I want to give you an update on how our Labor Day project is going. Have a minute?”

“Sure,” I say, “give me as much detail as you want. Tell me everything.” I took another deep breath.

He grins and sits in my guest chair. He says, “As you know, we started this project on the recommended start date, which was the same day we finalized the planning. I immediately prepared to start the tasks the software suggested to start during the first week.”

“Yes, I remember that,” I say. It was a turning point which I won’t soon forget. Would this be the solution we were looking for? Time will tell.

A New Way to Request Resources

Jim said, “I asked the manager of our Accounting Department for someone to fill the Financial Analyst position. We need to set up the budget tracking process for this project. In the fine print of our contract, we agreed to provide the City with a detailed breakdown of our expenditures.”

‘We did,” I asked, “Did you get the resource you needed?”

“Like every other department around here, they are all overloaded. But, when I specified which resource we needed, for how long we needed them, and showed her the priority of this project in our portfolio, I had no problem getting them.”

Usually, getting the commitment from department managers for project resources is a well rehearsed and civilized battle between two Japanese sumo wrestlers. I asked, “How did the task assignments go?”

Assigning Tasks Redux

Jim said, “Fine, I didn’t include a due date when assigning the tasks like you asked. I was careful to only use the estimated task duration as a guide. I also stated when the task is complete, be ready to pass your work on to the next resource. This will cut the multi-tasking, Parkinson’s Law and the student syndrome behaviors.”

By focusing attention on the task due date caused all kinds of bad behaviors. Jim’s use of using the task duration should keep these behaviors at bay. I wonder if folks will add their own date to the task when it is assigned. If the task duration is three days, they could look on the calendar three days from now and pick the due date for themselves. Let me ask Jim about this when he finishes his report.

Effects of Exposing Management Capacity

I asked, “How long did it take to assigning all the first week’s tasks?”

He said, “Less than two hours. I know what you are thinking, what did I do with the rest of my day. I know we expect to free up capacity, but I didn’t think it would happen to me. I did have to take time to hold some hands to get the daily days remaining updates. But, I asked myself, what else can I be doing to move this project along.”

“And,” I said.

A Leader Emerges

“I looked ahead in the schedule and tried to think of all the things which would slow things down. I’ve heard you say time and time again to be paranoid. Be paranoid. But, don’t be hysterical. So, I found a few documents we need to have and some folks who need to have a clear desk in the next few days. I was clearing a path for the project team to follow. I’m a few steps ahead of them and can see things before they do.”

“That’s one of the things Gary, our software non-salesman, expected would happen. Putting project managers in a leadership position is much better than managing things by pushing a string through the forest.”

“It felt good being out front for a change. Not only can I see better, but I’m not being pressured to make decisions under duress. But, there is a temptation to intervene even when I know I shouldn’t.”

“What do you mean,” I asked.

“I’m so used to sticking my nose in and trying to help. When the indicators show I don’t need to, I’m helpless somehow.”

I said, “You are not helpless. You said it yourself, it’s better to be out front leading the team through the jungle rather than being in reaction mode. That’s a move in the right duration. You are also in a much better position to deal with the unexpected we know are behind the next corner. Murphy as been pretty quiet so far, but I don’t think that will last.”

“Thanks for that. I do need some reassurance from time to time,” Jim said.

One Way to Evaluate Disruptions to the CCPM Schedule

I said, “When you do come up against something that you think will cause a delay, let me know. In the software, we can make a copy of your project, make the changes we will need to make, and see what the impact is. If we like what we see, we can use the updated plan or stick with the one we have.”

“Good idea. But, I only want to use the updated plan if the change turns out to be a major disruption. I want to avoid changing the tasks along the critical chain. That would also be a major disruption. If the critical chain changes, all your looking ahead efforts are lost. Wasted,” I said.

Jim said, “I’ll be sure to let you know. The other change we made is having the team make their own daily updates to the task’s day remaining estimates. This will help us see any deviations as early as we can.”

That answered my question. Our project resources may add a date to the end of their task assignment. But, being reminded every day that all we want is a days remaining estimate should counteract the date they set for themselves.

“That’s all I have for you today, boss,” Jim said, “I’ll get out of your hair.”

“Come back anytime. When you have positive status to report like this,” I exclaim. “I can use all the positive news I can get. It’s also a good idea to plan on sharing your efforts with the other project managers in our weekly staff meeting,” I said.

Rising from his chair, Jim said, “I’ll be glad to. As good as it feels hearing good news, it feels good giving some good news for a change.” With that, he disappeared.

Silence. I’m now alone to worry about how I’m going to get the next projects planned and scheduled.

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.

I’m Not Pushing My Project Resource Too Hard, Am I?

 
Jackie storms into my office, slams the door, and lands hard on the chair in front of me. She starts by explaining how stressed out she is and that she has too many things to work on. Then she starts to cry. I’ve learned to let folks get through their feelings on their own and be empathetic to their situation. Jackie has reached the end of her rope. She is the last person I though would do so.
 
When Jackie composes herself and is open to talking, she needs some help sorting through her priorities. She says there are some things at home she needs to take care of and needs to cut back on the overtime she’s been working. With all the pressure on our team and how far behind we are, I agree to reduce her overtime. Together, we review the tasks she needs to focus on.
 
Jackie leaves my office, lucky I got off so easy. But, I may not be so lucky the next time or with someone else on our team. One thing Jackie said was that she was reluctant to let me know when she completes a task. She says others feel the same way. Why, I asked. She stares are me and asked me what happens as soon as they report completion of the task?
 
I blurt out, I immediately assign another task. Silence. She says nothing and lets the silence sink in.

I’m Part of the Problem

It is hard to admit that I have been part of the problem. Why didn’t I see it sooner. I know everyone is busy. At least they look busy and now I know one reason why. They are “polish” the finished work. They could report the task compete early, but they don’t want to immediately be assigned more work.
 
But, I’m always looking for ways to start more tasks. One of my clues it to recognize when one of my folks does admit they are finished with a task early. I check to see how much earlier than their original estimate is against how much time it took them to actually do the work. If there is a big enough difference, I’ll file that away. I’ll use this information again them next time we are “negotiating” the task duration estimate of a similar task.
 
No wonder the planning of project is so contentious sometimes. I know they they can do tasks in much less time, but my folks seem to resist letting me enter the shorter times into the project plan. I’ve realized in the past the team needs the extra time in their task duration estimates. They need to account for all the other work they have, the emergencies which come up, and for folks like Jackie, to find some breathing room.
 
Is my behavior as a manager getting us any closer to our goal? We must finish projects on time, within budget and with all the features and benefits our customers expect.

Efficiency Isn’t All It’s Cracked Up To Be

Although our company doesn’t measure the productivity or efficiency, there is an unwritten rule that everyone needs to be busy. But, where has that got us? If Jackie is any sign, not very far. Not how I want to be recognized as a manager. And, not how I want to be known as a person.
 
I am pushing my folks too hard and for the wrong reasons. But, I can’t think more about this right now. I’m late for the dreaded quarterly budget meeting with the CFO.

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.

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?

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!