The Project Management Core Problem Proposal

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

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

Yes, that’s what I’m saying.

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

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

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

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

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

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

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

Yes, that’s what I’m saying.

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

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

The Problem

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

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

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

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

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

The Solution

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

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

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

Start with these three things:

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

The Results

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

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

Other outcomes include:

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

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

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

Do Your Customers Have a Trust Issue?


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

Glimpse Into the History of Project Management Performance

While there are many studies which reveal the success and failure rate of many project like the one’s listed below:

In a study by PricewaterhouseCoopers, they review 10,640 projects from 200 companies in 30 countries and across various industries, and found that only 2.5% of the companies successfully completed 100% of their projects.

A study published in the Harvard Business Review, analyzed 1,471 IT projects, found that the average overrun was 27%, but one in six projects had an average cost overrun of 200% and a schedule overrun of almost 70%.

It also doesn’t take long to see that there hasn’t been much change in the results over the years despite the efforts attempted to improve the results.  Maybe you have experienced similar, persistent project problems.

From the infamous Standish Report of 1994:

The Standish Group research shows a staggering 31.1% of projects will be canceled before the ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars.

In June of 2012, a Gartner survey revealed:

In analyzing the collective responses of some 150 participants in the 2011 Gartner five-country survey, the failure rate of IT projects with budgets exceeding $1 million was found to be almost 50% higher than for projects with budgets below $350,000.

From the Project Management Institute Pulse Report:

In 2012, the Pulse research reported dollars lost for that year as US$120M for every US$1B spent on projects. In 2013, that amount was US$135M for every US$1B. Dollars lost is the product of the average percentage of projects not meeting goals multiplied by the average percentage of a project’s budget that is lost if the project fails. Year-to-year variance is caused by changes seen in either, or both, of these two metrics.

From the International Journal of Innovation, Management and Technology, Vol. 8, No. 2, April 2017 shows it’s not an isolated case:

Construction projects around the world have a very poor performance record with respect to being completed within cost, time and quality objectives. Morris considers cost overrun as a “regular feature” for public projects. Causes and factors related to cost overrun in construction projects have been traced worldwide and in specific contexts, e.g., the USA, Nigeria, Indonesia, the UK, Ghana, Kuwait, Philippines and Thailand, Pakistan, Gaza Strip, South Korea, Australia, South Africa, Malaysia, Netherlands, Turkey, Israel, Uganda, and Saudi Arabia.

I’m going to assume many of these projects were lead by professionals or folks who have a lot of experience; at least, enough experience to be assigned to these projects my their manager.

If these folks can produce these kind of results, what chance does everyone else who manages a project have?

Persistent Project Problems Everyone Has

The history of project management goes back many years.  Some say the building of the pyramids in Egypt would not be a good starting point. More recently, Henry Gantt invents the Gantt chart in 1917.  In 1957, Critical path was developed by Dupont. The US Navy’s Special Projects Division used Program Evaluation Review (PERT) for the Polaris project in 1958.

Further development of the project management profession includes defining scrum, using the Theory of Constraints to define critical chain, the Project Management Institute is founded in 1969, earned value comes of age, and Agile Manifesto was published in 2001.

Never the less, it’s not hard to find a wide variety of projects which have problems. Maybe one or more of your projects have struggled with these issues, too:

    • Lack of people, parts, equipment, etc.
    • Not enough time
    • Missed due dates
    • Frequent schedule changes
    • Too much rework
    • Budget over-runs
    • Conflicts over priorities, projects and resources
    • Constant pressure to add more projects

Why, after so many years of project management blood, sweat and tears do we still have to deal with these problems?