How to manage risk of "just in time" delivery?

Question

One of the functional units involved with most of our projects has a philosophy of "just-in-time" completion of deliverables. I believe that the root cause of this is understaffing or inefficient use of resources, and in reality becomes more of a "kick the can as far down the road as I can" philosophy.

Unfortunately I am not in a position to solve the root cause, so have to deal with the issue in my project plans.

To inject realism into the project schedule I could move towards a "complete no later than" approach, but this will increase the number of tasks on the critical path by an order of magnitude. I am quite confident that this is setting ourselves up for failure as something is bound to go wrong.

Are there any suggestions out there for addressing the schedule/critical path risks associated with just-in-time delivery?

Answer 1

Aside: I may be reading too much between the lines of this question; I think this is a workplace politics problem rather than a strict PM problem. As a consequence, my answer is correspondingly pessimistic, jaded and cynical.

What is the probability that the functional unit will fail to deliver? What is the impact on the project scope/schedule/quality?

There is usually no hard data on which to base these two estimates; that leaves you with two subjective estimates, which is an unpleasant place to be in an inter-office argument. I would develop some estimates based on assumptions.

• Assume that Functional Unit X will miss their JIT target 70% of the time, by less than two business days; what happens to my schedule.
• Assume that Functional Unit X will miss their JIT target 10% of the time by more than 5 business days.
• Assume that Functional Unit X will hit their target, but the product will be unsatisfactory for our needs from a QC point of view. (speed increases defects; catch those before they become your problem.)

Then develop risk mitigations.

• IF Functional Unit X missed their JIT delivery, then we could purchase from competitor Y. It would cost 30% more, but would permit us to meet our deadline with acceptable quality."
• IF Functional unit X is more than 1 day late on their deliverable, then we inform customer that our deadline will slip by X days, or by Y quality.
• In order to compensate for the chance that Functional Unit X may miss a JIT delivery, we will keep stock of Y on hand. (somewhat tougher with software).
• In order to deal with the risk, we are including an SLA that Functional Unit X produce a prototype by date Y

Those are "pretty" textbook answers. Reality tends to be much less cosmetic. For most of us, those are totally unrealistic answers. But they demonstrate that you're aware of the problem and you're doing your best to work around it. The onus transfers to those who are doing less to solve the problem.

The hard nose gritty goal here is to convince management and stakeholders that you did more planning and *better planning" than the "kick it down the road" approach. If things go south, the guy who can demonstrate the better pre-planning will avoid some of the blowback. Your best chance is to proactively solve the problem; but sometimes we're dealt situations where the ton of bricks is already falling and the best we can do is shout a warning and get out of the way.

Answer 2

This speaks to pessimistic targeting on your estimations. Sounds like the team has a long runway and, as Parkinson's Law suggests, the team is taking advantage of every bit of it. There's another phenomenon, as well: Student Syndrome.

Challenge the team: target more aggressively. Cut your durations and bring your dates in at baseline time.

Answer 3

Add buffer to your project. There are two ways to do this:

1. Either taking a Critical Chain approach and have a bucket of buffer for the whole schedule (this would be my recommended approach), or, for a more quick and dirty approach...
2. Add time between the delivery date and the start of the next task.

This kind of situation is dealt with extensively in the Theory of Constraints literature.