critical chain plan building

[mandy]

We have fixed presentation dates with clients, especially in discovery and design phase (because they need to book people for these meetings weeks ahead of time), and how we should deal with that when creating a TOC critical chain plan.

[jamesviago]

good question

a CCPM plan is not a dated schedule by the conventional understanding of a "schedule" - there are dates, but they are an artifact of the mathematics of adding together durations - but the entire premise of CCPM is that the durations are a distribution, not an accurate expectation.

therefore, the dates are not actually the dates upon which things are expected to take place adn should be largely ignored! the accumalated duration +/- accumluated variation (impact on buffers) determines the actual date something will happen.

so what do you do with a date-specific presentation?

well, you plan for it to occur 'after whatever is before it and before whatever is after it'... just like with any other task. Then, you have the meeting according to the appointment in your diary - just as any other task occurs on the date when the resources get around to it. That date (the actual) has nothing to do with the "date" in the plan, as the planned dates are not real dates.

now, what about making sure the prerequisite tasks are ready in time for the meeting... and the post-requisite task resources are raring to go after the meeting? well, that introduces an intermediate due date which, in principle, we try to avoid in TOC. in other words, ideally, the meeting date would not be locked in diaries until the uncertainty has reduced to the point that the date would not be put at risk.

if that's commercially impractical, then you are stuck with an intermediate "drop dead due date" DDDD. the safest response then would be to move the portion of the downstream buffer that relates to the pre-DDDD tasks, to in front of that meeting date, and manage that buffer. obviously, if you do that too often, you defeat the whole point of absorbing multiple sources of variation and your lead time will blow out, so do this VERY sparingly.

That's a big brain dump - and there's probably more, but i think i've introduced enough of the underlying logic for you to take a crack at it...

cheers
James

[petert]

Well, well well. 3 holes in the ground!!
what an insight into why project plans become too long....intermediate Drop Dead Due Dates (DDDD)
the whole point of not having a dated "schedule" is to have little "sitting time" between tasks. but now a 3rd party (internal or external to the project) comes a long and books a date, a locked in date, and now all the gains prior to this cannot be transferred to the project, they all get lost!! if delivering the project early has no commercial value to the client, there is no real impact....
unless capacity has been consumed of constraint resources, and now other projects are at risk because of the imposition of a DDDD, and early completion of prior tasks.

so if "unmoveable meeting dates" could be moved at short notice, and no DDDD's are introduced, and handover of tasks is completed "as soon as practically possible", then projects could be completed very quickly and/or our constrained resources would be able to serve our other projects more effectively.

so a strategy to not create a DDDD would be a breakthrough strategy in project management.
so, what sort of features would be needed to NOT create a DDDD??

[mandy]

Thanks for your response James it makes sense! Most clients we don't need to use a DDDD with, and the project buffer can protect us with shifts in dates. However when you've got clients that are trying to round up 9 senior stakeholders into a room at the same time and their calendars are booked out weeks ahead, your solution helps us to manage this with the CCPM process. This would only be required in our Discovery phase usually.

I have been using duration (elapsed time) in my CCPM, is this correct? or should it be 'Work' (effort) to calculate task time and buffers?

[jamesviago]

the task time should be the answer to a question of the form: "once i give you this (input), how soon can i have it (the output) back?"

so, if i give you the spec, when can i have the code ready for testing?

and the answer is to be in the 50-60% percentile, not the 80-90% percentile.

if you eliminate bad multi-tasking, the duration and the effort should line up pretty closely. multitasking leads to the duration being many multiples of the effort time. in which case the variability caused by multitasking will be many times the variability caused by the task itself - which of course means the first way to reduce variability is to reduce multitasking!!

It all plugs together nicely once you get your head around it.

[petert]

Mandy, groups of stakeholders involved in project plans coupled with DDDD's are a recipe for consumed buffers and gains being lost.

is there another way where the negative effects are not caused, but enough of the stakeholders can have a flexible date that serves their end of approval and communication?

i have an idea as a "pigs fly" solution that is not debugged, but i'd like your suggestion first, to think of a way to cause this effect.