The bottleneck law has its origin in the Theory of Constraints, created by Dr Eliyahu Goldratt and published in 1984 in his book “The Goal”.

The law says that every system, regardless of how well it works, has at least one constraint (a bottleneck) that limits performance.

The law allows us to deduce the response time and performance limits of a process – essential information for IT services and software development projects.

 

Bottlenecks can involve people, information, tools, procedures, and may be internal or external to the organization. 

A bottleneck is the stage in the process in the form of sub-processes or activities that limit or block the flow. The throughput in the bottleneck is lower than in the rest of the stages. In other words, it is the stage at which the elapsed time for a work unit to pass through the system is largest.

For example, let us have a look at the process of “laundry washing-drying-folding”

The bottleneck is the drying machine because at this stage of the whole process the lead time is largest.

Processes involve different people, activities and tools and each of these has different performance. Therefore, if the activities of a process has to be executed in a sequential manner, for example

            Washing-drying-folding
            Flight check-in- luggage check – flight boarding
            Requirements definition- analysis-design-implementation – testing – delivery

How to resolve a bottleneck?

In the Kanban: Successful Evolutionary Change for your Technology Business book by David Anderson you can find more details about how to resolve a bottleneck depending on whether it is caused by a capacity constrained resource or by insufficient resource availability.

Here I will only summarize the approaches to bottleneck resolution:

• Fully exploit the bottleneck resource: make sure that the resource only does the activities she is specialized in and assign the remaining activities to other resourcesFor example, we have a specialist in software integration and because of his involvement in various projects he becomes a bottleneck. An option will be to let him do only integration tasks and assign other tasks to other team members.
• Increase resource availability – the frequency with which the resource is available even for a shorter time.Example: The integration specialist can dedicate one day a week to each project. A more efficient solution is that he/she dedicates each project half a day twice a week than a full day only once a week.
• Automate part of the activities .
• Increase the resource (elevate the bottleneck) – usually the most expensive solution.Following the example above this is equivalent to hiring another person with the necessary knowledge and experience in software integration.

Related posts

• The Project Management Principles that (Almost) Nobody Teaches
• Little’s law
• The effects of the variation
• Esteban, the “bottleneck” (a real case)

Thank you for reading my blog.

References

• David Anderson, Kanban: Successful Evolutionary Change for your Technology Business 
• Eliyahu Goldratt, The Goal
• Theory of Constraints

The origin of Little’s Law is the Queuing Theory and it is perhaps best known law in the IT systems performance modeling.

The law shows the relationship between Lead Time, Work in progress (WIP) and Throughput.

• Lead time: The period between the entry of a request in the system and the receipt of the request. It is measured by the elapsed time (minutes, hours, etc). The request may be a requirement, a user story, an incidence, material, a request from a user, etc..
• Work in process (WIP): the number of requests (work units) that are being processed, i.e. they have entered the system, but have not got out yet
• Throughput: the number of work units leaving the system at a given time, e.g. 3 user stories per day.

The conclusions of this law are equally interesting and important:

• The larger the WIP, the longer the lead time, i.e.the more it takes to finish the job started . In other words, to meet development or service deadline, we must reduce the work in process, or finish it before starting a new jobs. However, in lots of cases exactly the opposite happens: the teams start working on lots of tasks so that the whole project “goes” faster. Another reason for which one wants to ensure a lot of ongoing work is to achieve high resources utilization.Whatever the reason, assuming that the Throughput does not change, the increase of work in process also increases the time required for its completion (the Lead time).

• Focusing on reducing Lead time helps identifying obsolete activities that are carried out . Eliminating them has two positive effects: (1 ) eliminates waste in processes, and ( 2) reduces total WIP, which leads to shorter Lead time and a more efficient development .
• The higher the Throughput, the shorter the Lead timeThere are different ways to improve performance: automating value-adding activities (automating non-value-adding activities is equivalent to automating waste production), improving processes or adding more resources. If you decide to add more resources, observe the overall lead time because the additional resources add more work in progress as well.
• Each Lean initiative seeks to minimize waste and shorten production cycle. Reducing the production cycle is equivalent to reducing the Lead time. Minimizing waste includes an analysis of current inventory and the steps to reduce it. This is equivalent to reducing WIP.

Why is this law important for Project Managers?

1. Little’s law is a tool to know the real performance of a software development team or an operations one
2. Provides predictability
   E.g. if we have to implement 50 requirements and the average team capacity is 5 requirements per week, the time that we will need is
   50 requirements / 5 requirements per week = 10 weeks.
3. Shows that the larger the work batch, the longer the processing time, the Lead time
4. Explains why multi-tasking delays instead of accelerating work completion.
   Usually people believe that working on multiple tasks in parallel increases productivity. Therefore, assigning several tasks to a person is a common practice in the companies. However, unlike the machines, people are not so good in the execution of parallel processes. Increasing work in process also increases the time to change and re-start a task and therefore reduces throughput. As a result, the time to execute the work gets insufficient, and the started but not finished job begins to accumulate.
   In short, Little’s law helps finding the balance between the work in progress and Lead time.
5. Provides the foundation to reaching optimal WIP limits. If WIP limits are below the optimal level, there are underutilized resources and performance is low. If the WIP limits exceed the optimal level, then work units start piling up in queues and this also reduces performance.
6. Helps understand the effects of blocking a job or having to fix errors on project or service deadlines. In both cases it reduces Throughput and hence increases the Lead time.

Important conditions for applying Little’s Law:

Little’s law is very useful, however in addition to knowing the formula you have to take into account the conditions that have to be met for the law serves you:

• Use average values for all parameters: average lead time, average WIP and average throughput
• Units must be consistent, i.e., if we measure throughout in a week, the lead time also has to be a week, as well as the average WIP
• The system has to be stable, i.e. all the work that enters the system, has to go out of it; the total WIP at the beginning and at the end of the period has to be constant, the average arrival rate of work has to be equal to the average departure rate of work.

To summarize, the correct use of Little’s law helps achieve a smooth and steady workflow, and improves the predictability of projects and IT services. Work in process (WIP) is a key factor for project performance and the time to complete a software development or a service. Limiting WIP reduces Lead time and, in addition, leads to reducing waste in the workflow.

Related posts:

• The Project Management Principles that (Almost) Nobody Teaches
• Bottleneck Law
• The effects of the variation
• Esteban, the “bottleneck” (a real case)

References

1. Little’s Law on wikipedia
2. Little’s Law – an article in .pdf format
   

I have been doing project management for seventeen years already. I have carried out software development projects for a bank, for civil engineers and for document management.

I have applied practices of

• Rational Unified Process (RUP)
• Earned Value Method
• PMBoK
• CMMI
• Agile Project Management (based on Scrum )

Although I was always trying to apply correctly the methods, identify and address risks properly, communicate with the team on a daily basis (this has never been a problem in our projects), communicate with the customer often, I have suffered the problems of (more…)

I started working as software development project manager in 1996. We were a team of 5 people, young and motivated, developing a facility management system for a bank.
Just to give you an idea of that time, we had internet access on one computer only, so we were checking the team’s email (not the individual ones) twice o three times a day. The mobile phones were like the one you see on the picture bellow, i.e. no sms, no WhatsApp, nothing of this type.

That was the only project we were working on, i.e. there was no resource sharing among projects and no influence from other development undertakings.

Do you remember that time too? :-) (more…)

“If you do not actively attack risks, they will actively attack you”
– Tom Gilb

What I usually see in the risk tables of project or service plans are “deliver late”, “surpass the budget”, or “does not pass customer acceptance due to unclear requirements”.

At the same time, teams most often complain from not being able to meet deadlines, and surpassing budget.

Obviously we are rather attacked than attacking risks.

Why analyse defect data?

What can we do to protect better the projects and the services from the risks?
Logically, understanding better the causes and the circumstances for the problems should help.

Have you checked what part of the total delivery time (lead time) is effective development, rework due to defects, or waiting for some input? In other words do you know the efficiency of your process?

When estimating the delivery time, did you include the time for rework and waiting?

My experience shows that few companies systematically analyse their defects and blockers with the aim to understand their root causes and act on them. Blockers are sort of defects in some of the processes involved in carrying out the work, e.g. managing suppliers, scheduling, handling customer information, etc.

Several times I have seen surprise on the faces when people realize that resolving blockers and fixing defects takes them more than 30% of the total estimated effort, prolongs project duration with more than 20%, and affects significantly customer satisfaction.

If you want that your work be fit for purpose, you should listen to your defect data (including blockers) and act adequately.

How to analyse defect data?

Analyse defect data is not so difficult – there are several techniques that help with this. The main reason for not taking advantage from this valuable source of information is that the majority of the companies still do not collect data about defects and/or do not know what this data say.

A simple practice that you can use to learn from your defect data is to follow these steps:

1. Classify the defects based on criteria that emerge from telling the story of each defect. For instance, we started working without getting commitment from the customer about the functionality, dependencies with another system were not taken into account, the person involved was new and with insufficient domain knowledge, etc.
2. Analyse the causes and look for patterns. Although each story has its individual aspects, problems share great part of the roots.
   Focus on the lead time and efficiency of resolving the defect or blocker
3. Decide how to address the causes as to prevent them from occurring.

What do defects have to do with risks?

Most of the problems are recurring at least until we manage to preclude them completely.

This means that we have to be prepared to see our experience again in the future. The point here is how we can identify the risk well in advance and effectively avoid it.

Mirroring the past through the “now” point is a simple and helpful technique.
The problem from the past becomes a risk in the future. The causes from the past convert to risk symptoms that we have to carefully watch for.

Which is the right place to discuss risks?

Lots of teams try to mitigate their risks individually and independently on the others. This is not very effective especially when there are dependencies between the services.

I assume you conduct some periodic meetings at which you review your projects and services. If you use the Kanban routines (cadences), the ideal place is the Risk Review meeting.

Image copied with permission from David J Anderson’s post “Kanban cadences”.

Make sure that you have a good understanding of the entire context to be able to make pragmatic decisions about how to hedge risks.

Summary

• At team level not understanding the causes for the defects and blockers makes you vulnerable to project and service risks
• At organization level not addressing properly the risks reduces your fitness for your business purpose.
• Applying a pragmatic approach to defect analysis, understood and shared by all stakeholders, facilitates risk hedging.

Related posts:

• The Two Mortal Enemies of Meeting Deadlines
• Project Management: 4 Actions That Will Help You Sleep Better

In 1992 Bill Clinton chose an interesting slogan for his political campaign:

Of course, there were many other important topics for the country and a lot of factors that were influencing their resolution. However, Bill Clinton’s key message was focused on the core driver for the country, the economy.

I frequently meet companies that struggle with the need to reduce delivery time for their projects and services, provide more competitive prices, and adapt better to changing customer needs.

It is difficult to introduce drastic changes in organizations where hierarchical structures and responsibilities have been settled for long years and any disruption scares people and makes them resist. For such organizations, the need of change is definitely recognized. How to approach it, however, is not yet completely clearly. (more…)

This month I had an interesting service for the IT department of a bank. I say ‘interesting‘ because they asked me to visit them, see how they were carrying out and managing their projects and tell them how I found it. Nothing about particular problems they want to resolve, objectives they are pursuing, or a method that is interesting form them. Just come – see – and give us your opinion.

I went with a good dose of curiosity and with some anxiety because I did not know what to expect.

The context

To understand the context I asked both the software development team and the business users (the customer) to describe their workflow as well as any difficulties they had in their daily work (a problem per post-it).

A summary of the current situation can be drawn as follows:

The pains that need urgent treatment according to the prioritization of both teams are:

1. Poor user requirements (defined at the level of idea)
2. Insufficient business analysis
3. Task estimation problems – users do not understand why developers need so much time to the work, there is pressure to reduce the estimates, and then the problems of not meeting the dates appear
4. Frequent priorities changes
5. High workload and inability by the development team to respond quickly to user requests.
6. Lack of risk management

The analysis of the problems can be summarized like this, reading the tree bottom – up.

“Quick wins” are needed.

What vitamins should I prescribe them that will bring them
noticeable improvements in a short time?

Defining an estimation method would help, also establishing criteria and policies for managing requirement changes and risks, but all this will take time and effort. In addition, they have to be accepted well by the people, both the users and the developers.

Listening to the pains and fears of both sides the following image appeared in my mind:

What lays at the bottom of the problems is the matching between the user requirements, in the business people language, and the development team work, with all its creative and technical aspects.

 

No technology or formal method will give positive results in short time, if the communication between people fails and there is a lack of visibility in the work that is carried out.

I confirmed this idea with the team and all together we came to the following two elements of the “quick win” solution:

• Work in multidisciplinary teams

• Use a shared kanban board to visualize the work in progress and facilitate its understanding and management.

Now back to the pains that need urgent resolution. All of them will be positively affected by this simple solution, won’t they?

At least the team and I are convinced so.

What is your opinion?

If you think this experience can help a friend of yours, forward her the message. She will pay you back the favor at another important to you moment.

Related posts:

• The Project Management Principles That (Almost) Nobody Teaches
• What is Kanban?
• The Focus And The Involvement, Key Elements In Improving Processes

How many from your recent projects or services did you deliver on time? Of course, complete and without the need to work overtime or on weekends.

Four years ago I started collecting photos of the problems that software development organizations face, regardless of the working method they use. Last year I started expanding my collection with photos from industrial companies.

Do you know which the most recurrent pain is? (more…)

Throughput is relatively less known measure for traditional project management companies (based on PMBoK, Prince2, CMMI). However, I believe it will be gaining more respect in the near future with the spreading of the Lean concepts.

Throughput is the amount of work items delivered in a given period of time (e.g. week, month, quarter).

When we say delivered we really mean completed and possibly delivered to the customer. I.e. money is collected at the end of the process.

To understand the throughput concept, let us assume that during the last five weeks a team has delivered respectively 4, 6, 4, 2, and 3 stories per week. If there are started, but not finished stories, they do not take part of the calculations.

The average throughput for these five weeks is (4+6+4+2+3)/5 = 4 stories/week (rounded).The standard deviation is rounded to 1 story/week.

Throughput is based on real data of team’s capability to deliver. Throughput variability reflects the impact of factors such as story size, complexity, urgency, and person’s skills.

Throughput can be used for planning purposes. For instance continuing the above example, the team can estimate that their throughput (delivery rate) will be 4±1 stories per week without making any detailed estimation of the individual stories.

In Kanban, however, throughput is mainly used for tracking team’s performance. Logically, the objective is to continuously improve it.

 

Throughput and velocity

Throughput is similar to the agile metric velocity, however it is used differently.
Velocity is measure used in eXtreme Programming and Scrum. It shows how much work a team can complete on an iteration or sprint. The work is usually measured in story points.

Going back to the previous example team, let us assume that the five user stories delivered during the last two weeks are of 3, 4, 1, 5, and 3 story points respectively.

Then the total number of story points that can be completed in a 2-weeks sprint is 3+4+1+5+3 = 16. That is the velocity of the team is 16 story points per sprint.

Velocity also varies because of factors like story complexity, story size, changes, team skills level, etc.

Agile teams use average velocity to estimate how many features they will be able to deliver in future sprints. However, they still have to estimate the individual user stories in order to define the backlog (the scope) of a sprint.

So, although velocity is associates with speed, in fact it is about the load, usually measured in story points, which a team can carry during a fixed period of time (iteration, sprint).

Throughput and resource estimation

Throughput can be used for estimating resources.

According to the Little’s Law

If a team keeps a steady pace of work, then the average delivery time (lead time) for a certain type of work or a class of service can be considered a constant.

The delivery rate (throughput) is the target rate to be achieved in order to meet customer deadline.

Based on this we calculate the number of work items to be processed for that duration.
E.g. suppose that lead time for a story is 0,25 week. The target delivery rate is 20 stories/week. Then
WIP = 20*0,25 = 5 stories.

Assuming that a person can only work on a single story, we need at least 5 people for implementing the complete job on time. To be on the safe side (no precise formulae for this), we would better start with a team of 6 people. :-)

 

To sum up, throughput is easy to collect. It is a valuable measure because it keeps you focussed on team’s performance. In addition, knowing team’s throughput decreases the effort for estimating stories (requirements), provided that they are split to reasonably small chunks. Moreover, through Little’s Law, the throughput allows estimating the resources needed for completing a given job within the time expected by the client.

Related posts

• Little’s Law
• Lean Kanban Analytics: Pragmatic Project Management