Category: Analysis

How to use Buffers

Time to Read: 3 mins

Sakichi Toyoda was the founder of Toyota and is considered to be the father of industrial revolution in Japan. The industrial revolution moved us away from hand made goods, to mass manufacturing of goods by machines.

In manufacturing, buffers are used to keep the assembly line running with any interruption; It’s described as having enough supply to keep the assembly running and helps to compensate for any variations in the production process.

We also use buffers in certain aspects of our lives. We add them to our budgets, when we need to travel to an important destination and can visible in all of the ‘stuff’ that we accumulate.


Why buffers make sense
In the context of running an assembly line, buffers make sense. If you find one part that is faulty, if can be quickly discarded (because you have a buffer of spare parts) the spare part is used and the assembly line keeps on moving.

At a surface level, it seems that buffers are a smart safe guard, which clearly has its merits. But a valuable exercise to try is to operate life without any buffers.


A life with our buffers
Living life without buffers can uncover problems that are difficult to identify. When our buffers are always being used and depleted; it indicates that a real problem exists that isn’t just an anomaly.

Sakichi Toyoda knew that buffers were a necessity to compensate for small anomalies, but he also knew that without regular examination, buffers would only be covering up bigger problems.

Using the assembly line as an example; If a large number of parts are being discarded (because they are faulty), then it may be time to speak to the supplier about the quality controls they have in place.


Digging a little deeper
Taking the time to dig deeper can help us to discover why buffers exist in the first place, as opposed to just accept the status quo.

The Toyota assembly line is renounced for the hundreds of small improvements it makes to its assembly line each year. All of those tiny improvements results in a reduction in cost and time to process.

Those who take the time to dip deeper and find the reasons could be called perfectionists and have a somewhat obsessive nature with what they do.


The right approach
Admittedly some problems feel like they are easily dealt with the use of buffers, they give us a certain feeling of safety and readiness.

But we can get closer to a better process by removing the buffers and examining how something work, looking at a cause and effect relationships.

Once the process is improved, we can then put the buffers back in place, because ideally they shouldn’t be part of the process or be used to hide a bigger problem; but should only act as a safe guard for events we can’t control.


The best response when providing estimates

Time to Read: 3 mins
Early on in my career, I was asked to give an estimate on how long it would take to implement a new feature.
Now this was my first ‘real’ job out of university and to be honest I really had no idea on how to estimate.  In an attempt to assuage my discomfort (and try to get some sort of a useful response out of me) my manager added:
“What is an estimate really? Its just a guess, it could be right, it could be wrong.  It’s really just a guesstimate.”
As I progressed further on into my work career, the term ‘guesstimate’ was something that never really sat well with me.  I recently read The Pragmatic Programmer by Andrew Hunt, in which a small chapter was dedicated on how to best handle estimations.
Estimates as guesstimates
A guesstimate implies that there is very little science, process or calculation around making an estimate. And although a guesstimate is sometimes analogous with estimates, providing a guesstimate is not the most appropriate response in all circumstances.
A guesstimate may be appropriate when someone asks ‘when will you be free for lunch’.  In this scenario the worst case is that you end up having lunch by yourself or maybe reschedule for another day.
But if you are working on something a little more serious then a guesstimate may be ill-suited.  Let’s say you were on the Waymo project and developing self driving cars. My assumption is that they are not working off guesstimates.  Mis-interpreting distance, moving objects or road signs would have dire consequences.  In this scenario accuracy is paramount therefore a rigorous estimation approach would be more appropriate.
The point is: How much effort is taken should be dependent on the context.  The more important the context, then the more time and you should be with your estimates.
Implying a higher degree of accuracy

How you describe your estimates is important.  The units that you use can imply a certain level of accuracy.

Going back to my opening example, if I gave an estimate of around 6 months to implement the new feature.  That sounds fine, right?
But if I gave my answer in days i.e. 120 days, which estimate sounds more accurate: 6 months or 120 days?
Using days assumes a more accurate estimation than months, but in some cases you don’t want to be accurate. If I was one month off the original estimate, it still doesn’t sound as bad as being 20 working days off.
Below is a general guide of giving out estimates and which units to use:
> 4 hours =  use days.
> 15 days = use weeks.
> 8 weeks = use months.
> 6 months =  take some more time to think.
Where the best estimates come from
The best estimates come from work that has already been done before.  If someone has completed the same or a similiar job in the past, a real world example would be the best guide in giving an accurate estimation.  If this is not available then there are other strategies that you can adopt to give a more confident and accurate estimation.
Functional Decomposition
Breaking down a task into smaller components will truly give you a better understanding on what needs to be done. This process is often referred to as functional decomposition. Once you have decomposed a larger task into smaller components, you can then estimate on each component and sum the value of every component giving you a final number.
Functional decomposition will allow you to identify any dependencies between tasks that might cause your estimates to creep up.  Another benefit is that it enables you to pin point exactly where your estimates went over or under.  Having the ability to communicate that kind of information gives stakeholders a level of transparency that goes a long way to demonstrate your analysis skills.
Historical records
For some professionals estimating is a regular and vital part of their job.  If this is the case try to keep a historical record on your original estimates versus the actual. Doing this over time will increase the accuracy of your estimates.  You will be able to recognise patterns and add the right contingency and tune your estimation process.
The best answer…
The next time you are asked for an estimate, consider the context and if it deserves something better that a guesstimate,  maybe the best response you can give is: “I’ll get back to you on that” 

Hidden benefits of root cause analysis

Rebecca Hall

Time to read: 3 minutes

I recently watched the Movie ‘Christine’ starring Rebecca Hall (illustrated above).  Based on a true story, the movie deals with issues of being a misfit, living up to the expectations that we put on ourselves and coping with it all.
There are few scenes where we are able to gain an insight into the mind of the protagonist (Christine) as she tries to solve the problems and  dilemmas of life.
If you plan to watch the movie for yourself I would advise against googling ‘Christine Chubbick’ to avoid any spoilers.
Sock puppets 
Christine regularly visits a children’s hospital, and performs a sock puppet show.  She sometimes finds herself talking through her own problems via the sock puppets.  These are great scenes and its amazing to see how externalising problems helps in clarifying what’s bothering Christine.
The “Yes, but..” exercise
Another scene is where Christine is unknowingly coerced into an TA (Transaction Analysis) meeting. She partners up with a stranger and participates in a “Yes, but..” exercise.
You start by stating a problem: ‘My husband won’t paint the house’
The person listening would suggest a solution: What if you hired a painter’
If the suggestions isn’t appropriate then you have a chance to object: Yes, but i can’t afford a painter’
Another solution is suggestedWhat if you painted the house’
The format is repeated until you arrive at a solution that is suitable.  In most* cases solving the problem is completely within your control; we can make a decision or change our attitude without waiting for others to change.
*This statement is not always applicable;  as an example the character Christine suffered from a mental illness.
Root cause analysis
In business the equivalent tool we have is the 5 why’s.  The 5 why’s was developed within Toyota by Sakichi Toyoda.  It was used to advance their manufacturing process.  An example that may come straight out of Toyota:
The car wont start.
  1. Why =The battery is dead
  2. Why = The interior lights were left on for several days
  3. Why = The door sensor stopped working
  4. etc..
  5. etc..
Ancillary benefits
Further to finding the root cause of a problem or failure there are ancillary benefits of using an iterative process when solving a problem.  We are also able to easily identify and question Assumption and Logical Traps
Assumptions is something that we are all familiar with, but to use our earlier example,  when Christine used the sock puppets. it helped her to identify and question her own assumptions; the same can be said of the ‘Yes, but..’ exercise.
On the other hand logical traps are shortcuts that our brains uses in order to make decisions faster.  We do this by identifying patterns, making estimations and trying to make connections all in an effort to reduce the amount of effort that is needed to think.  Logic Traps are very useful and at the same time they can be misleading and inaccurate (hence why we use the 5 why’s)
Other points 
If you are using root cause analysis with a work setting, you may need to go through more than five iterations in order to find the root cause.  Furthermore you may find that there is more than one point of failure.
Self examination is a good exercise to go through and a great to skill to have.  It does take some level of courage to critic yourself and a level of self belief to know that in the end, you will be better for it.  In business prudence is shown when you decide to be proactive and not waiting for the next ‘major incident’ to initiate root cause analysis.
In both cases problems are easier to handle and solve when they are small and not screaming out at you.