Lean in the Office: Single-Piece Flow and FIFO

Executive Summary:

Though the literal applications of single-piece flow and First-In-First-Out (FIFO) have limited opportunity in a project-oriented, office environment, the phenomena of clogged process systems and waiting work created by doing too much all at once are common.  Make your office and transactional processes more efficient and effective by applying the principles, if not the literal practice, of single-piece flow and FIFO.

The Rest of the Story:

Excepting repetitive, consistently similar processes like order entry or engineering change requests, it is difficult to find places in the office environment where Lean methods such as single-piece flow and First-In-First-Out apply.  Even our e-mail inbox is not a good place to practice FIFO because of varying priority and urgency.

However, the Lean principles that drive single-piece flow and FIFO can save us from surprising quantities of man-hours wasted and time lost in a project-oriented, office environment where the tasks are not repetitive, but always different.  By examining the principles of single-piece flow and FIFO we can make our offices more efficient and our projects execute more quickly.

First, let’s examine a common office or transactional process where the single-piece flow and FIFO concepts can be applied directly and effectively, but often aren’t.  It will allow us to examine how to apply the Lean principles in the office directly, and also to examine the principles so we can make a translation to other processes and examples.

For the sake of discussion, let’s examine the processing of engineering change requests.  If your office doesn’t do engineering, this example might apply to any variety of requests, including Information Technology (IT) service requests, or financial authorizations, etc..

So we are all on the same page, let’s consider the engineering change request (ECR) process to work generically as follows.  When an engineer makes a change to design documentation, that change must be communicated to all of the processes and data systems that have something to do with turning the design into an actual product.  Production and material or supply ordering systems must be notified of the change and must change accordingly.

Typically the process begins with the engineer filling out a form that explains the change and why it is necessary.  The form is submitted to the process and enters the queue.  When the form is picked up, after waiting its turn, it usually goes through a process of review and approval. 

Someone checks to make sure that the form and information are correctly completed and the process is enabled.  Someone will review the request and make sure that it makes sense and is appropriate – that it’s not going to create a problem.  Finally, the notification of the change will go to everyone responsible for an affected system so the change can take effect.  The data in the system us updated to show the change and the revision code for the documentation is ratcheted.

Sounds simple right?  If you have an engineering function, how long does it take to actually execute the process described; days, weeks, months?  If your answer was multiple days, weeks, or even months, you are not alone.  It’s common.

Now answer this, if you “walk” an ECR through the process, stopping at each desk and approval with that form in your hand, can you get it done in a single day, or less?  Most of us would probably answer in the affirmative.  Are your alarm bells going off yet?

When we “walk” our form through the process and get it done in a single day, it shows us the process time or “lead-time” to which we are entitled.  Therefore, all of the other days, weeks, or months that it takes a request to work its way through the system are waste.  Go ahead, you’re allowed to groan.

How does something that should only take a few hours end up taking weeks?  Here are some common occurrences.  The people processing the forms may or may not take them in order.  Certainly, many ECR processes allow for some variety of urgency or priority preference to be placed on different requests.  Those with lower priority wait.  The people reviewing the requests have other duties too.

The other duties of approvers may seem, at any given time, to be more important or urgent than reviewing requests.  Certainly, they are probably more interesting.  So, the requests don’t get reviewed until something changes that perception of urgency or importance or interest.  Usually that requires that someone else makes it painful for the reviewer to procrastinate any longer, which happens when the request has sat around long enough to get a certain level of attention.  Then, when attention finally is directed to the requests, they may or may not be handled in order.

Additionally, many ECR processes use approvals where notifications would be more appropriate.  For example, many request processes have a standard list of people that need to review the request.  Maybe the Marketing Manager is on that list because an engineering change could necessitate changes or impacts to marketing materials, product catalogs, or otherwise affect customers.

However, if an engineer simply replaces one screw with another that costs less, that Marketing Manager could care less.  Still, the request will go to that manager for approval and sit there.  Every approval, appropriate or not, is an opportunity for that ECR to sit in “inventory” and for the people or other resources associated to “wait.”  How many standard approvals does your request process require?

I could write a whole book just on the subject of the sources of waste for ECRs and how to streamline ECR processes.  For now, suffice to say that the requests in the system create or experience a great deal of “waiting” or “inventory”-time to use Lean lingo.

OK, so let’s look at the Lean solution to the inventory and waiting problem called single-piece flow and FIFO.  Philosophically, single-piece flow and FIFO battle against processing in batches.  Anything piling up in a queue or pile or batch is sitting and not getting done.  In other words, it’s experiencing wasted time and opportunity.

An ideal application of single-piece flow and FIFO for the ECR process would look like this.  A form would be submitted to the system.  The form would be error-proofed or “poke-yoke” to a degree to minimize the need to review the form and information, or eliminate the opportunity for an error to be introduced, thus eliminating the necessity to review the form for errors before processing the request.

Allowing that a review of the change is necessary and unavoidable, the resources necessary to make the judgment would immediately review and either approve or reject the request.  Approved requests would enter the data system with the changes and new revision code, and only the appropriate, parties would be notified.  It would take place just as fast as “walking” an ECR does, if not faster.

The resources for review and approval and otherwise processing the changes would be dedicated to the process in sufficient quantity to more-or-less handle a steady flow of requests without letting a queue build up that couldn’t be drained back down in a few hours or at most, a day or two.

Now, we all understand that for most of us, it’s simply not appropriate to dedicate an engineering manager or two to the ECR process for the sole purpose of reviewing and approving requests.  We couldn’t expect to pay someone with the right knowledge or experience to sit and do that job.  Even if we did, in that role they wouldn’t stay knowledgeable.  Their involvement in the whole business and function of engineering is what makes them knowledgeable.

So, pragmatically, we must accept that our requests are going to wait until that authority has an opportunity to break away from other things to review and approve requests.  We can set guidelines or rules such as, requests have 4 business hours to be reviewed before the alarm goes off, for example.  (Every office culture would need to develop its own appropriate rules and consequences)

Also, requests should be processed in the order they are received (FIFO).  Eliminate the system of urgency or importance preferences.  It causes more harm than it solves.

See if this sounds like it happens in your office, in some similar way or shape.  Two ECRs are submitted.  One is for a change to a design already in production, one is for a design that failed testing and needs the change to go back into testing, so it can pass and launch as a new product.  The Marketing VP notifies the ECR process team that he needs the in-development ECR to process with greater priority because the failed test is pushing back the launch date and the business depends upon it.

So the ECR team pushes the in-development ECR through first and engineers begin making phone calls and visiting various approvers to expedite the process.  Suddenly, dozens of people are not getting real work done because they are trying to get the ECR done.

Meanwhile, the in-production ECR is sitting and getting no attention.  Unfortunately, the reason for the request is that the production floor is out of the material typically used, and won’t get a re-supply in time to prevent the production line from stopping.  A source of equivalent material is on hand, but the design documentation is too specific to allow the substitution.  An engineer has evaluated the situation and determined that the substitution is a good option and therefore, filled out the request to change the documentation.

While the in-production request is waiting, the engineer and production team talk with the test lab and inform them that they need to produce a sample with the alternative material and run a verification test so the quality documentation for product certification can demonstrate that the substituted material has been tested and approved.  They communicate the urgency and the test lab agrees to set up for the test.

Subsequently, the in-development ECR is processed first, and hits the test lab and wants to re-enter testing.  The test lab has re-configured to run the other test though.  Now the test lab manager goes to a number of different leaders and tries to get two different VPs to settle the debate over whether the in-development project, or the production floor change is the bigger priority.  This takes another day at least.

In the mean time, the in-production ECR is finally processed and the samples are produced for testing.  They get to the test lab, get set up, and start running just in time for the command decision to test the in-development project first.  So they stop testing and re-configure the lab, which takes another day and begin testing the new-product-to-be.  When that’s done, they reconfigure the lab, another day, and finally test the substitute material.

Unfortunately, the extra days going back and forth in the lab and with the leadership has caused the launch to miss its big day and cost the business a great deal of money moving press releases and accommodating distributors, retailers, and customers.  Likewise, the substitute material was not verified in time to prevent the production line from shutting down.

If the first ECR had just been processed with single-piece flow urgency (immediately) and the second ECR processed right behind it, no one would have waited for more than perhaps an hour, at worst a single day.  Days would not have been wasted debating priority, and days would not have been wasted jerking the test lab around.  Both efforts might have made their deadlines.

When everyone can count on the process taking one or two days, instead of anywhere from 2 days to 2 months, people don’t go out of their way to work around the system.  Working around the system for one piece, creates excess waste for every other piece.  Make the process efficient and consistent and it will stay that way.  Don’t allow anyone, including the VPs to work around it.

The single-piece flow and FIFO methods eliminate or minimize pieces of work stacking up and waiting in queues.  Everything is handled with the same priority, and that priority is “immediately.”  Yes, the ECR we are handling at the moment might not be urgent while the one behind it is.  If so, get it done immediately so that you can get the urgent one done.  Don’t make any ECR wait and no ECR ever will.

It is a very simple concept.  Changing people’s discipline and habits and expectations to implement it is not so simple.  You will need to pull out some solid change leadership methods to make it happen, but it definitely works.

So would we apply the same practice to our e-mail?  We can, but it isn’t always that simple.  A request to put together a presentation to be delivered in three weeks might come in moments before an invite to an urgent meeting.  If we spent 6-hours working on the presentation and then read the e-mail about the meeting, we would miss the meeting.  That doesn’t make sense if the presentation isn’t due for three weeks.

We might not fulfill all of the tasks delivered in our e-mail in-box exactly in order, but we can read our e-mails in order of delivery and prioritize tasks or respond.  That way we don’t start at an interesting topic and process from there, fail to finish reading our e-mail before going home, and end up missing an important piece of information when it was relevant.

Let’s get even more difficult.  What about projects?  Every project is different, they don’t take the same resources, or the same amount of time, and we have resources to work on more than one project at a time.  Does it make sense to do only one project at a time?

Let’s look at that.  The purpose of single-piece flow and FIFO is to eliminate waiting and pieces of work sitting around without getting done.  Therefore, the correct answer to the question of doing only one project at a time must be the one that creates the least opportunity for work to be sitting (inventory) or for resources to be “waiting.”

The short answer is that an organization should do more than one project, but a project team should not.   Here is also where I call the remedy a disease and the cure a cause.  Let me explain.

Your business might have enough resources to do more than one project and probably does so deliberately so that it has that privilege.  Good.  The problem is not in an organization doing more than one project at the same time, the problem is doing too many.

Recall the ECR process discussion above.  We said the ideal state is dedicated resources to the process, but that dedicating approvers is simply not pragmatic.  We accept that the request will have to wait for an approver with other duties to make time to review and approve the request.  That reality identifies the key to eliminating waste in the forms of inventory and waiting.  Other duties are the cause of waiting and inventory.  We otherwise call the phenomenon of multiple duties “multi-tasking.”

When we work on a project, we naturally experience periods where we are waiting on someone or something to do something in order to continue.  We as human beings hate to wait, so we find something else to do while we wait.  We pick up another task.  Managers know this takes place and deliberately assign multiple efforts to personnel so that while personnel are waiting on one effort they can work on another and further the business objectives in a planned way.

Therefore, multitasking is a symptom of the waste of waiting.  We treat it like a remedy and plan things such that resources are allocated to multiple projects.  However, what happens when we pick up a task and then our previous task returns to our workspace for our further work.  Do we drop the second right away and pick up the first, or do we keep working on the second and let the first sit?

The answer depends on a lot of things including urgency, how interesting one task is, how well we are paying attention, and how many of these multi-task commitments we have.  Think for a moment.  Are your assignments really limited to just two?  How many work assignments are you juggling right now?  How many of them are sitting while you are working on one?  How many people are waiting for you to do your piece so they can do theirs?

If your answer to the last question is, “none because they all have other things to work on too” then this last assertion is for you!  Multitasking is not a cure for the wastes of waiting personnel and sitting work, it is the cause!

Take the following mental exercise very seriously.  Pick one of the projects you are on.  How long will it take for that project to get done?  Now, imagine that every member of that project team, including you, has no other assignments.  If you didn’t work on anything but that project for 8 hours a day, 5-days a week, how fast could your team get the project done?

Such a scenario may not sound very attractive to most professionals.  We know that we’ll spend some time waiting and that our different assignments are probably part of the appeal of our jobs.  But we also know that things would certainly happen a great deal faster.

A pragmatic adaptation of the single-piece flow and FIFO concept of the Lean methodology to a list of projects is as follows.  Assign one project to a single team.  Let that project be that team’s sole priority.  Let team members who are waiting invest their free time in improving the processes to minimize that waiting phenomenon.  Let them help team members with their tasks to speed up work and eliminate waste.

Allow managers to assign tertiary tasks to members of that project team which they are allowed to do while they wait.  These can be research and development assignments, non-urgent problem-solving challenges, or learning new skills.  The key is, they must be assignments that can be picked-up or dropped at a moment’s notice when the work for the priority project re-appears.

I have worked with more than one organization to improve the rate at which engineering design and product development took place.  We made a large number of process improvements that each made its own contribution to the improvement.  I keenly observed, though, that the closer we moved to the model I described of a single priority project assignment and only tertiary tasks for multi-task work the faster everything moved.

We have a human behavior of inserting one more thing in our agendas until we feel the pain.  If you don’t see it, go to your favorite restaurant and order your favorite appetizer, entre, and desert.  Tell me that you put your fork down before you get that uncomfortable feeling in your belly and that you didn’t exceed your necessary calorie intake for your dinner meal.  Yeah, we do it at work too.  We keep giving our teams just one more bite of work until they complain.

Unfortunately, the complaint of too much work occurs well after we have multi-tasked our personnel into a zone where our projects and tasks are spending more time sitting than getting processed.  Just spend one week with a piece of scratch paper and take notes every time something that you could be working on isn’t getting done because you are working on something else.  Compare that with how much you actually got done.

Take those numbers and multiply it by the number of people in your office.  Granted, it’s just a ballpark number, but that should give an order-of-magnitude estimate of just how much is sitting in your office.  I dare you to try it.  You will be astonished.  I dare you too to estimate a dollar value.

Assigning only a single project to a project team and allowing some tertiary work to occur as it may, might not be exactly the application of single-piece flow or FIFO to which we are accustomed in the production environment, but it fulfills the principle of eliminating the opportunities for work to sit waiting to be worked.  In an ideal case the project would never experience any sitting time and the people working it would also refine their methods to a degree where they don’t experience any waiting either.

We may never find that ideal state in most of our business environments, but I have experienced without a doubt that the closer to it we get, the faster our projects get done and the faster their savings or revenues or profits hit our bottom line.  It can be a huge business saver.

Take a good look at your office habits and behavior.  Look for opportunities to banish multi-tasking and to apply single-piece flow and FIFO either directly to your request processes or similar opportunities, or in principle to your project portfolios and teams.  Even when Lean can’t be applied directly, the principles hold true and can be applied in the office and transactional environment for significant benefits.

Stay wise, friends.