Project Planning using Little’s Law
•Descargar como PPTX, PDF•
17 recomendaciones•3,768 vistas
Project Planning using Little’s Law
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Project Planning using Little’s Law
Similar a Project Planning using Little’s Law (20)
Más de Dimitar Bakardzhiev
Más de Dimitar Bakardzhiev (8)
Último
Último (20)
Project Planning using Little’s Law
- 1. Project Planning using Little’s Law Dimitar Bakardzhiev Managing Partner Taller Technologies Bulgaria @dimiterbak
- 2. In Kanban a project is a batch of work items each representing independent customer value that must be delivered at or before a certain date
- 3. Why project definition says “work items each delivering independent customer value”? Because we have data for “work items each delivering independent customer value”. A project is just a batch taken out from the flow of work. Say the flow processes thousands of work items. We can name a batch of a 100 work items “a project” but we have data for the flow itself and we use that data!
- 4. When planning a project • You need to provide some idea as to when the project is going to be delivered. • You need to provide a quote to the customer of how much the project will cost so she can decide whether to commit or not.
- 5. Little’s Law for production systems
- 6. Little’s Law applies to any system, and particularly, it applies to systems within systems
- 7. Little’s Law holds in case of a project 1. We must have conservation of Flow The average output or departure rate (TH) equals the average input or arrival rate (λ) There are no work items that get lost or never depart from the system 2. The system must occasionally empty, i.e., WIP = 0 Both are true!
- 8. Little’s Law can help us calculate the average Lead Time for a work item. But we need a relationship between the average Lead Time for a work item and the finite time period over which the project will be delivered!
- 9. A Kanban system is a queuing system!
- 10. We measure Lead Time
- 11. Visual kanban system Input Queue WIP 2 Development Test WIP 5 WIP 4 Project Backlog QA NO WIP DEPLOYED!
- 12. Average throughput of the project system equals the average throughput of the development system!
- 14. Calculating Lead time for the project :
- 15. Number of developers we will need:
- 16. Examples
- 19. Calculated delivery time should be used only for the second leg of the Zcurve!
- 21. Z-curve
- 22. When calculating Project lead time we need to: • Account for the other two legs of the Z-curve • Account for Dark Matter • Account for Failure load
- 23. Planned Project lead time is the sum of the calculated project length and a project buffer
- 24. The two essential measurements of project performance are the percentage of the project completed and the amount of the project buffer consumed.
- 27. Percentage of the project completed
- 29. FAQ
- 30. If we have TH data for the Dev System why don’t apply LL directly? TH of Dev system is achieved using a certain WIP limit – say 5 work items of which say 2 in Dev Queue. We don’t know what TH of Dev System will be for WIP=10 work items.
- 31. Why don’t we use TH of the all three Z-curve legs? Because only the second Z-curve leg is representative for the Dev System capability. First and third Z-curve legs are project specific and show special cause variations. We protect the project delivery date from special cause variation using a project buffer.
- 32. If or not the S/Z-curve applies to any batch or just projects?
Notas del editor
- What is a project?
- So what are the questions we need answered in order to plan a project?1) You need to provide some idea as to when something is going to be delivered. You need an elapsed time estimate to give an indication of the delivery date. The client is interested mainly in when the work will be delivered and not that much in the cost. Then when the work starts you need to communicate progress to the client and be able to identify project slippage as soon as possible. These sounds like you are managing delivery date and maybe cost of delay risks.2) You need to provide a quote to the customer so she has a ballpark idea of costs involved so she can decide whether to commit or not. You bill by the hour so you need a time-on-task (level of effort, touch time) estimate to give an indication of the cost of the work. The client is interested mainly in the cost and not that much in when the work will be delivered (lead time).
- Let’s recall what the Little’s Law for production systems is…Where throughput (TH) is the average output of the production process per unit time, work in process (WIP) is the average inventory between the start and end points of the production process per the same unit of time, and lead time (LT) is the average time from starting a job at the beginning of the production process until it reaches the end of the production process (that is, the time the job spends as WIP) in the same unit of time. Note that lead time is also referred to as flow time, throughput time, and sojourn time, depending on the context.http://www.youtube.com/watch?v=W92wG-HW8gg
- Handily LL applies to any system, and particularly, it applies to systems within systems. So in a bank, the queue might be one subsystem, and each of the tellers another subsystem, and Little's law could be applied to each one, as well as the whole thing.
- Now, we ask what conditions are necessary for Little’s Law to be valid.At a minimum we must have conservation of flow. Thus, the average output or departure rate (TH) equals the average input or arrival rate (A). Furthermore, we need to assume that all jobs that enter the system will eventually be completed and will exit the system; there are no jobs that get lost or never depart from the system. In addition, we need some notion of system stability.Notice that our formula is exact, but after the fact. This is not a complaint.It merely says that we are observing and measuring not forecasting.Little's Law holds exactly between any two time instances at which the system is empty.Little's Law is true for the averages for any identifiable segment.
- Little's Law deals with averages. It can help us calculate the average waiting time of an item in the system. In project development we break the project delivery into work items. We are interested in how much time it will take for all the items to be processed by the system. We need a relationship between the average lead time for a work item and the finite time period over which the project will be delivered.
- Consider the figure where the project is presented as a queuing system consisting of two queuing systems in tandem. On the figure we have a queuing system within a queuing system:Project System – it processes the project scope or the batch of N work items each one representing independent customer value.Dev System – it processes components or work items suitable for the development organization. User stories are just an example of a suitable work item type.We have Kanban system within a Kanban system (two tiered board)!Project and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or 𝑇𝐻𝑝=𝑇𝐻𝑡The project will be delivered in the time T. We break down the project into N work items each one representing independent customer value. All the items enter Project Queue or Project Backlog. The size of the individual work items doesn't matter. When breaking a project down we do not consider how many steps the workflow of server S2 consists of. Important thing is that we have two queues - Project and Dev. Project queue has the size of N and Dev queue could be of any size in the interval [0,N]. Server S1 could have service time of more than 0 if for instance what it does is to decide which would be the next item to leave Project queue and enter Dev queue.Consider Fig.1 where the project is presented as a queuing system consisting of two queuing systems in tandem. On the figure we have a queuing system within a queuing system:Project System – it processes the project or the batch of N work items each one representing independent customer value.Dev System – it processes components or work items suitable for the development organization. User stories are just an example of a suitable work item type.Project and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or (𝑇𝐻) ̅_𝑝=(𝑇𝐻) ̅_𝑡We have Kanban system within a Kanban system (two tiered board)!The project will be delivered in the time T. We break down the project into N work items each one representing independent customer value. All the items enter Project Queue or Project Backlog. The size of the individual work items doesn't matter. When breaking a project down we do not consider how many steps the workflow of server S2 consists of. Important thing is that we have two queues - Project and Dev. Project queue has the size of N and Dev queue could be of any size in [0,N]. Server S1 could have service time of more than 0 if for instance what it does is to decide which would be the next item to leave Project queue and enter Dev queue.
- For the Project System we measure Customer Lead Time defined as the time interval between Request Accepted and Delivery to the Customer.For the Dev System we don’t measure the time between Commitment point and first Infinite Queue!We measure Lead time defined as the time interval between Commitment point and Delivery to the Customer.And that is for a reason because Project System and Dev System share the same output which is Delivery to the Customer!
- Let’s see how a project is handled in a kanban system.We have a batch of 10 work items and they move through the knowledge discovery process of the delivering organization.At the end all 10 work items are deployed!The 𝑇𝐻𝑝 of the Project System comes from the Dev System hence 𝑇𝐻𝑝 cannot be bigger than 𝑇𝐻𝑡 and at the same time cannot be smaller!!!!!𝑇𝐻𝑝 and 𝑇𝐻𝑡 are equal!Let’s see how a project is handled in a kanban system.We have a batch of 10 work items and they move through the knowledge discovery process of the delivering organization.At the end all 10 work items are deployed!The (𝑇𝐻) ̅_𝑝 of the Project System comes from the Dev System hence (𝑇𝐻) ̅_𝑝 cannot be biger than (𝑇𝐻) ̅_𝑡 and at the same time cannot be smaller!!!!!They are equal!Consider Fig.1 where the project is presented as a queuing system consisting of two queuing systems in tandem. Client and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or (𝑇𝐻) ̅_𝑝=(𝑇𝐻) ̅_𝑡The "target throughput" comes from the Z simulation of the anticipated s-curve in work item completion. The WIP limit applies to the columns through which the observed lead time was measured previously. These must be consistent.
- Little’s Law holds only for Dev system. That is what we measure and have historical data about. Hence it is safe to discard a work item from the Project system and break conservation of flow requirement on the project system level.Consider Fig.1 where the project is presented as a queuing system consisting of two queuing systems in tandem. Client and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or (𝑇𝐻) ̅_𝑝=(𝑇𝐻) ̅_𝑡The "target throughput" comes from the Z simulation of the anticipated s-curve in work item completion. The WIP limit applies to the columns through which the observed lead time was measured previously. These must be consistent.
- The "target throughput" comes from the Z simulation of the anticipated s-curve in work item completion of the Dev system. The WIP limit applies to the columns through which the observed lead time was measured previously. These must be consistent.T is the time period over which the project will be delivered (lead time) N is the number of items to be delivered or the total arrivals in [0,T]𝐿𝑇𝑝 is the average lead time at the project level or what the client can see𝑊𝐼𝑃𝑝 is the average work in process at the project level𝑊𝐼𝑃𝑡 is the average work in process at the development organization level𝐿𝑇𝑡 is the average lead time (cycle time) at the development organization level𝑇𝐻𝑝 is the average throughput at the project level𝑇𝐻𝑡 is the average throughput at the development organization level𝑇𝑇𝑡 is the average Takt Time at the development organization level𝑇𝑇𝑝 is the average Takt Time at the project levelConsider the figure where the project is presented as a queuing system consisting of two queuing systems in tandem. Client and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or 𝑇𝐻𝑝=𝑇𝐻𝑡. For both systems we have to work with the same time interval for the throughput time and throughput rate i.e. minutes, hours, days, weeks, etc. Also we have to have the same work item type – it is not possible average throughput at the project level to be measured in sites, and average throughput at the development organization level to be measured in web pages. By noting that 𝑇𝐻𝑝=𝑇𝐻𝑡 we have the proof.1𝑇𝐻𝑝 is the takt time that we need to achieve in order to deliver in T weeks. Takt time is the waiting time between two deliveries (two occurrences of an event). 𝑁𝑇𝐻𝑝 equals the mean of an Erlang (Gamma with k as integer) distribution. What does that tell us?So it can be said that the average time T needed to deliver N work items with average Takt Time=1𝑇𝐻𝑝 equals 𝑁𝑇𝐻𝑝 or N times Takt Time.Consider the figure where the project is presented as a queuing system consisting of two queuing systems in tandem. Client and development systems are connected in a way that they share the same output. Output from the development system is flowing into the output of the client system. Hence average throughput of the client system is equal to the average throughput of the development system or(𝑇𝐻) ̅_𝑝=(𝑇𝐻) ̅_𝑡. For both systems we have to work with the same time interval for the throughput time and throughput rate i.e. minutes, hours, days, weeks, etc. Also we have to have the same work item type – it is not possible average throughput at the project level to be measured in sites, and average throughput at the development organization level to be measured in web pages. By noting that (𝑇𝐻) ̅_𝑝=(𝑇𝐻) ̅_𝑡
- And that is the Anderson’s formula applied for calculation the lead time for a project…WIP and LT are for an existing team with history.T is the time period over which the project will be delivered (lead time) N is the number of items to be delivered or the total arrivals in [0,T]𝑊𝐼𝑃𝑡 is the average work in process at the development organization level𝐿𝑇𝑡 is the average lead time (cycle time) at the development organization levelT = time period over which the project will be delivered (lead time) N = the number of items to be delivered or the total arrivals in [0,T](𝐿𝑇) ̅_𝑝 = average lead time at the project level or what the client can see(𝑊𝐼𝑃) ̅_𝑝 = average work in process at the project level(𝑊𝐼𝑃) ̅_𝑡 = average work in process at the development organization level(𝐶𝑇) ̅_𝑡 = average lead time (cycle time) at the development organization level(𝑇𝐻) ̅_𝑝 = average throughput at the project level(𝑇𝐻) ̅_𝑡 = average throughput at the development organization level
- And that is the Anderson’s formula applied for calculation the number of developers needed for delivering a project…WIP is the sum of the number of devs times the allowed number of work items per developer plus the size of all the queues.That formula is to be used very carefully because there is no linear correlation between WIP and LT.
- Let’s have a similar project with major project with 2200 user stories to be delivered. The business wants to know when we will be able to deliver. There are no options for adding more developers to the development organization so we know the average work in process which is 22 user stories. We also have historical data that average lead time for the development organization is 0.4 weeks per user story. Using the Anderson’s formula (1) we have:Let’s have a similar project with major project with 2200 user stories to be delivered. The business wants to know when we will be able to deliver. There are no options for adding more developers to the development organization so we know the average work in process which is 22 user stories. We also have historical data that average lead time for the development organization is 0.4 weeks per user story. Using the Anderson’s formula (1) we have the calculation on the slide.The result should be used for the second leg of the Z-curve, but that is another topic.
- David Anderson’s original example We have a major project with 2200 user stories to be delivered. The business needs the project delivered in 10 months. The questions to answer are: How much money do we need? How many people do we need?So we have N = 2200 user stories, T=10 months = 40 weeks. We also have historical data that average lead time for the development organization is 0,4 weeks. Using the Anderson’s formula (2) we have:Development organization has the policy of 1 work item per person hence we will require 22 persons. That assumes the dev queue has finite size of 0 work items. If the dev queue has finite size of 2 user stories we will need 20 persons.The result should be used for the second leg of the Z-curve, but that is another topic.
- Will we have the average TH on the first week of the project? No. The second week? May be!If we know we’ll going to go slow at the beginning add that into the plan!Also most larger projects tend to go slow towards the end. That’s because may be we have regression effects in our code, we have testing overhead and bug fixing.So add that into the plan too!The calculated T should be used only for the second leg of the Z-curve.
- It turns out that the delivery rate (TH) follows an S-curve pattern.The red line is the Z-curve.Slow in the beginning and in the end and fast in the middle.On the diagram the first work item to be delivered was an architectural design document to be approved by a steering committee..It was of value to the client because the outcome of the project should have been an integral part of the existing enterprise system.
- We really only need three elements or a Z-curve which is a simplification of PMI S-curve.There is a little bit of empirical evidence here that for approximate 20% of the time the delivery rate will be slow. Then for approximate 60% of the time we’ll going to go fast or “the hyper productivity” period.And for approximate 20% till the end we’’ go slow.Numbers my vary depending on the context.But the basic principle about the three sections is correct.
- The "target throughput" comes from the Z simulation of the anticipated s-curve in work item completion. The WIP limit applies to the columns through which the observed lead time was measured previously. These must be consistent.Add work items to compensate for the unknown work or dark matter. The number of work items will grow through natural expansion as we investigate them. It is possible some features willbe broken into 2 or more once you get started on them. My experience is that I would buffer at least 20% for this and with novice teams on a new product (especially if it was a highly innovative new product where we had no prior knowledge or experience) then I might go as high as 100%.Add work items to compensate for the expected failure load in terms of defects, rework, technical debt.Project Buffer is used to protect the project due date promised to the customer from variation in the Throughput.Uncertainty is reduced by aggregation. The project delivery date can be protected by creating a buffer of time based on the uncertainty attached to the aggregate amount of work items to be delivered with the project and to variation in the Throughput.Such a buffer is known as project buffer. It’s size could vary from as little as 15% to as much as 200%.𝑃𝐵 is the project buffer in units of time used¯𝑇𝐻 is the average throughput for the second leg of the Z-curve𝑍𝐶 is the cooficent for accounting for the first and third legs of the Z-curve. Usually is is between 25-50%.𝐷𝑀 is the average percentage of dark matter calculated by appropriate dark matter quotient (based on historical observation). If you don't have history use 40-60% expansion i.e. 1.4-1.6 as the quotient.𝐹𝐿 is the average percentage of Failure load.
- Uncertainty is reduced by aggregation. Project Buffer is used to protect the project due date promised to the customer from variation in the Throughput.The project delivery date can be protected by creating a buffer of time based on the uncertainty attached to the aggregate amount of work items to be delivered with the project and to variation in the Throughput.Such a buffer is known as project buffer. It’s size could vary from as little as 15% to as much as 200%.
- When we use a Project Buffer then…
- Project buffer usage determines whether or not the delivery date is affected.Buffer usage should be monitored as a percentage used.We are visualizing the cumulative buffer usage just like we would visualize a bank overdraft usage.
- 𝑃𝐵 is the project buffer in units of time used𝑇𝐻 is the average throughput for the second leg of the Z-curve𝑍𝐶 is the coefficient for accounting for the first and third legs of the Z-curve. Usually is between 25-50%.𝐷𝑀 is the average percentage of dark matter calculated by appropriate dark matter quotient (based on historical observation). If you don't have history use 40-60% expansion i.e. 0.4-0.6 as the quotient.𝐹𝐿 is the average percentage of Failure load. Failure load tracks how many work items the Kanban system processes due to poor quality. That includes production defects (bugs) in software and new features requested by the users because of a poor usability or a failure to anticipate properly user needs. Defects represent opportunity cost and affect the lead time and throughput of the Kanban system. The count of defects is a good indicator if the organization is improving or not.Project Buffer is used to protect the project due date promised to the customer from variation in the Throughput.Uncertainty is reduced by aggregation. The project delivery date can be protected by creating a buffer of time based on the uncertainty attached to the aggregate amount of work items to be delivered with the project and to variation in the Throughput.Such a buffer is known as project buffer. It’s size could vary from as little as 15% to as much as 200%.𝑃𝐵 is the project buffer in units of time used¯𝑇𝐻 is the average throughput for the second leg of the Z-curve𝑍𝐶 is the cooficent for accounting for the first and third legs of the Z-curve. Usually is is between 25-50%.𝐷𝑀 is the average percentage of dark matter calculated by appropriate dark matter quotient (based on historical observation). If you don't have history use 40-60% expansion i.e. 1.4-1.6 as the quotient.𝐹𝐿 is the average percentage of Failure load.
- 𝑃𝐶𝑡 is the percent delivered out of total work items to be delivered at time t𝑁𝑖 is the number of completed work items at time iN is the number of items to be delivered or the total arrivals in [0,T]〖𝑃𝐶〗_𝑡 is the percent delivered out of total work items to be delivered at time t𝑁_𝑖 is the number of completed work items at time iN is the number of items to be delivered or the total arrivals in [0,T]
- 𝑇0 is the project start date𝑇𝑡 is the date at time t𝑁𝑖 is the number of completed work items at time i𝑇𝑇 is the planned average Takt Time for the project𝑃𝐵𝑈𝑡 is the percent of the Project Buffer consumed at time t𝐴𝐿𝑇𝑡 is the Actual Lead Time at time t𝑃𝐿𝑇𝑡 is the Planned Lead Time at time tUncertainty is reduced by aggregation.The project delivery date can be protected by creating a buffer of time based on the uncertainty attached to the aggregate amount of work items to be delivered with the project.Such a buffer is known as project buffer. It’s size could vary from as little as 15% to as much as 200%.Project buffer usage determines whether or not the delivery date is affected.Buffer usage should be monitored as a percentage used.𝑇_0 is the project start date𝑇_𝑡 is the date at time t𝑁_𝑖 is the number of completed work items at time i¯𝑇𝑇 is the planned average Takt Time for the project〖𝑃𝐶〗_𝑡 is the percent delivered out of total work items to be delivered at time t〖𝑃𝐵𝑈〗_𝑡 is the percent of the Project Buffer consumed at time t〖𝐴𝐿𝑇〗_𝑡 is the Actual Lead Time at time t〖𝑃𝐿𝑇〗_𝑡 is the Planned Lead Time at time t
- Project Queue = 10Dev Queue = 2We have theDev System in place and we try to accommodate the Project System to present Dev System capabilities and not the other way around!Example – if we have a highway with a certain throughput rate would the average daily throughput change if we add 20% more cars to the average daily number?