• Risks

• Unknowns
◦ known unknowns - complicated
◦ unknown unknowns - complex or chaos
◦ known knowns - order
• parameter and value, iteration
• Aim
◦ To be first
◦ To be best
• Rules
◦ actions cause outcomes
◦ dependencies, interdependencies, variability affect outcomes
• hurry up and wait
• why can't we finish on time?
• Why can't we stay within the budget?
• Chapter Two
◦ chaos factor in development
◦ how long it will take is an unknown
◦ how many times to repeat to get it right is an unknown
◦ framework of Rolly
‣ start all asap
‣ keep moving
‣ focus attention on slowest
• Chapter Three
◦ each subsequent task would need a good setup before starting fast
◦ switching loses setup time and teardown time
◦ not having advanced warning means the need to make sudden decisions that cause slips
◦ there can be a chain of delays
• Chapter Four
◦ A lot of coordination means tech or trouble
◦ as else where tasks can suffer procrastination
◦ variability and lack of control is a bitch
◦ the ability to ensure what is promised is given causes variation
◦ So we need a God view and plan
◦ overcome the need to make people work versus switching
◦
• Chapter Five
◦ Growth is it's own problem if we don't have resources in time
◦ adding of margin of error for each task is common
◦ consider subcontracting
• Chapter Six
◦ Question of reuse of work and time saving
◦ giving too large a safety means being late to the market
◦ the costs can be huge
◦ wait until something becomes urgent then it will rush through anyway
◦ to calculate we need to work the chain till payback and figure out how to max that
◦ Charger
‣ some managers just overpromise as that looks good
‣ they know that they can only wait for escalation to complete
‣ and that they just need to nego with the customer if they are still late
◦ Plodder
‣ budget enough for delays
 ‣ never willing to be early to avoid shorter timelines next time
◦ Optimizer
‣ best of the first two persona
• Part Two: Start Later Finish Sooner
• Chapter Seven and Eight
◦ concepts
‣ dependency
‣ interdependency
‣ variation
‣ unknowns
‣ switching losses
‣ you need a system of systems approach
• taking a linear view will result in unpleasant surprises
• You need a system to coordinate between steps
◦ to speed or slow down
• take note of both positive and negative variation
• Chapter Nine
◦ necessity logic
‣ what needs to occur before a task can be successful
‣ a project is a chain of such tasks
‣ the needs are the dependencies and can be tasks too
◦ bird's eye view
‣ use it to schedule tasks
‣ fallacy of "sooner you start, the sooner you finish."
• it causes delays
◦ possibility of "start late and finish early"
‣ less waiting time
‣ less switching
• less setups
• less teardowns
◦ Failure to see the wasted time is common
‣ most just track the elapsed time
‣ not tracked is the setup and tear down times
◦ Failure to see multitasking is bad
‣ at the resource level
‣ It should be done at the PM
◦ Gating
‣ like at the start of freeway
‣ stagger start of project so resources does not multitask
◦ TOC
‣ CCPM
• critical chain portfolio management
• saves up to two thirds of time
‣ variability
• task duration
◦ how long each task will actually take
• iteration variability
◦ how many times a task needs to be repeated
• by aggregation the variation into a end of chain buffer
◦ take advantage of statistics for more stable results
◦ takes advantage of positive variation, a day gain is a day gained, and vv
◦ use aggressive but possible
 ‣ use median time period
• training is needed to address the new times
• critical path pushes to a pessimistic forecast schedule
•
‣ Throughput
• rate a business makes money
• it measures of the firm's goal
• It is not net income which is a snapshot in time
• Chapter Ten
◦ story
• Chapter Eleven
◦ Necessity logic
◦ Necessary tasks chain
◦ Dependencies
◦ Sys. view – bird's eye view
◦ Chains of dependencies
◦ Gating – Stagger proj. starts
◦ Proj. priority – gate based on Multitasking = bad, due 2 change-ovrs. Single-tasking – helps
gain time
◦ TOC – Critical Chain Portfolio Mgt. Benefit = finish in 1/2 - 2/3 time Aggregated time buffers @
strateg. pts. Task duration var. & Iteration var. Remove safety time from tasks
◦ Time buffers at strat. pts. in sched. Positive variation, take advantage of it More done quicker
= more capacity Throughput – rate of making money
◦ Software reflects a worldview
‣ so is it correct?
‣ otherwise it will bandaid over your problem
‣ kick the can down the road
• Chapter Twelve
◦ critical path
‣ the longest series of dependent tasks
‣ optimizing creates gaps / floats
‣ the gaps lengthen the project
‣ rigid schedule
‣ fixed duration with safety factor included
‣ tasks may be incomplete but on time
• critical chain
‣ first define ending by requirement and timeframe (cost)
‣ next, work backwards to beginning with
‣ tasks to start as late as possible
‣ duration is one that occurs 50% of the time
‣ conflicts are resolved by moving the tasks to the left / earlier
‣ instead of delays moving the completion to the right
‣ recognises the variability and exploits it
‣ defeats psychological factors in teams
‣
◦
◦ resource leveling
‣ leveling is based on task and resource dependency
◦ When we use up duration with completion highly probable
‣ we call it the red zone
◦ CC starts with end in mind
‣ work backwards to reduce likelihood of missing out objectives, or outputs
 ‣ what is that future reality measured using ODSC
• objectives
• deliverables
• success criteria
‣ How?
• ask questions about the future reality (To Be)
• 5W1H
• ask who are the customers / stakeholders
• ask what the benefits are
• ask what the costs will be
• ask what the risks are
• If the firm is a for profit, the goal is to make money
◦ Else we need to ask what the goals are
• ask what time is available to make the money
• Chapter Thirteen
◦ work backwards to focus on benefits (outputs) and not tasks (inputs)
◦
◦ construction of a project
‣ A project goal is broken down into a series of steps WBS
• construct a template??? for future similar projedts
◦ to reduce the work for future work
• We need to account for each task
◦ duration
‣ aggressive but probable
‣ most likely to be complete
◦ iterations
‣ aggressive but probable
‣ most likely to be complete
• take the portfolio approach
•
◦ Why use critical chain?
‣ Have you ever had a sponsor just ask you to cut times off a project?
• Why?
◦ to address sandbagging
◦ because it will be late for the market
◦ How to do Critical Chain
‣
‣ step 0: create a template for the typical project
‣ step 1: create project network (WBS)
• all tasks
• all sequences
• all dependencies
• step 1a: id resources for each tasks
◦ set durations (abp and hp)
◦ set iterations (abp and hp)
‣ step 2: establish lead time for project
• identify your resources for each tasks
• calculate ABP times and HP times and iterations
• resolved conflicts
• Ask what the desired completion date is
• put the times into a calendar with as late as possible
• level the load
 ◦ move ahead the task
◦ add resources
◦ split resources
• aim to determine with certainty when we will be done
• Identify the critical chain
• add a project buffer
• branches have feeding buffers
•
• There is a difference between cutting project timeline by half and CCPM with ABP
times
◦ there is no buffer plan so everyone is under pressure
◦ performance drops
• delays lead to cost overruns
• Bigshot reduced to add pressure
• safety is the HP time summed minus the ABP summed
• safety buffer is available for all tasks
• advantages include no need for cost overruns to catch up
‣ step 3: If project does not meet desired timeline
• challenge the assumptions
◦ do we need all the locations, plot twists, complexities?
◦ make the bet or fold
◦
• Chapter Fourteen
◦ TOC holds that every firm needs a system constraint to govern flow
◦ consider it as a master valve or flow regulator to right size the business
◦ we need a flow regulator for fast, smooth flow and not turbulent flow
◦ if we have a regular car we know it has a speed beyond which it will not work well
◦ so we keep our demand (pedal) below that constraint / valve
◦ we are just admitting that we have sized our system for the correct demands
• Part III Speed to Market
• Chapter Fifteen
◦ Estimated time to build a project network template is one to three weeks full time
◦ software not only will cost money but will embed your poor project logic making it harder to
change, building up bad habits that could spiral out of control
◦ We need to invest some time at the key levels to make change happen
• Chapter Sixteen
◦ There are thirteen separate steps to build a project network
◦ Step 1: ?
◦ Step 2: ?
◦
◦ Question: In order to start this task, what must we complete first?
◦ Ask what is really needed not good to have: try to remove waste
◦ Step Three: Challenge the Assumptions
‣ are the serial work really necessary? Can they be done in parallel?
‣ can we add resources?
‣ can we change what we are doing?
‣ "Sometimes we need to ask whether all of this work is really necessary for the end
deliverables. And do we need a project of this scope at this particular time? Or can we do
something with similar objectives, but do it faster and with less investment?"
• we can split one big project into two smaller projects with less deliverables
‣ It must show how the dots are connected
• concept to bottom-line (profit) results in step by step fashion
• Chapter Seventeen
◦ story
◦ main point is to have a consolidated operations so that optimisation can be done
• Chapter Eighteen
◦ project delays cascade into other projects
◦ how to align the projects?
‣ use the resources as gatekeepers
‣ like parents helping clear a bus queue
‣ DBR
◦ synchronisation
‣ offsets your work to eliminate conflicts for resources between projects
‣ reduce multi-tasking
‣ prevents one project's delays from impacting another
‣ first decide which is the priority
‣ next decide the resource that will be herbie
‣ rule to choose herbie
• heavily loaded
• limited capacity
• early in project (maybe we can shift?)
‣ the synchronisation buffer is based on previous task variability
• do fmea to id what can go wrong and impact severity
• the project buffer is the last line of defense
• The size of the synchronisation buffer is taking care of all the rest of the resources
◦ the ABP finish of one task must have a gap to the start of the next task
• herbie will provide advance warning of the next task
◦ Aim is to take advantage of early starts
◦ Aim is to avoid switching
◦ It is ok for no activity to occur
• Chapter Nineteen
◦ The feeding buffer is like a fuel gauge that should have green-yellow-red for easy warning
◦ Resources pacing themselves??
‣ if resources are given more than one thing to do (I never did this) and expected to pace
themselves, they will procrastinate given too much time
‣ don't expect or reward heroics too much
‣ look for perfectionists causing long tails
‣ don't expect people to be or look busy or they will
‣ don't allow procrastination
‣ are they delaying their project task deliberately?
‣ single-tasking message and scrum to build in the control
‣ the structure or organization is what builds in the climate
‣ Focus on just one job at a time
‣ buffer monitoring system for each third
• yellow = watch closely and recovery plan to protect the buffer
• red = action to bring back to green
• don't act till red
• Add daily monitoring
◦ Standup Meetings
‣ using daily short stand-up meets before info radiator
◦ Consider not going for a bridge to far
‣ be careful of skipping steps without info into market
• Chapter Twenty
◦ image is that of a relay runner passing a baton
• Chapter Twenty One
◦ If you cannot do quick changeovers
‣ your customers will be the larger customers who can fulfil large MOQ
‣ be careful of offering incentives for volumes, it makes you fight for the precious few large
customers who have the volume
‣
‣ they will have large cash kitties
‣ Fast Turnaround / Setup
• SMED single minute exchange of die
‣ smaller orders are better for customers cashflow
‣ the need to find low capex solutions to dramatically increase setup
◦ Aggregation of demand
‣ what is a nodal layout / laydown of supply chain
• central warehouse and regional warehouses (buffers)
◦ Velocity
‣ combining Lean, 6 Sigma, TOC
◦ be pure with your context and assumptions