Skip to main content

Waste Reduction in Project Environment - A Lean View

Dr. Taiichi Ohno identified seven category of waste in manufacturing and production that can be applied to project management, to make project environment Leaner. Overproduction, Waiting, Transportation, excess inventory, excess motion, non-value-added processing and defects are the seven categories of waste in Lean manufacturing. Here is a brief translation of  7 categories of waste in project management environment, especially in multi-project environment or/and project management system of systems:

1- Overproduction in project environment happens:

  • when a task is assigned to a resource before the task is available!
  • or when a task is assigned to a resource because the resource is available and not because the task needs to be performed.
  • or doing a task as part of the project, but in fact it is not part of delivering the value of the project.
2- Waiting in project environment is one of those killers;
  • when a task is half way through, and a resource is pulled away to work on another task at the same time, the first task experiences waste in time as it waits or it is idle for the resource to perform other task. (inefficient multi-tasking)
  • when a predecessor tasks completes it's work, but it dose not get passed to successor. Therefore Successor experience waste by waiting for its hand off. (kinda No-Early-Work-Transfers)
3- Transportation waste can be translated into project environment as;
  • when wrong or unnecessary dependencies are in project schedule, one task should start only after the input of its predecessor task arrives, however that input is not really necessary.
  • when a review that generates looping back or rework is later in the process than it should be.
4- Excess Inventory in a project environment is;
  • when too much work is in progress (high level of WIP), and organization can not process them effectively. (this is a result of bad project pipeline management)
  • or when a skilled/limited resource is reserved for a task more than the actual time that is required for that task to be completed.
5- Excess emotion occurs in project environment;
  • when time has been put on a task that it is not really needed to be completed for the project or it is not needed for the task to be finished to create value.
  • when  holding onto a task that is complete (keep polishing the output or searching for hand off is all waste)
  • when a task is multitasked, time is required to setting it down or/and picking it up again. Such a time is waste.
6- Non-Value-Added Processing;
  • Adding more reviews and sign offs to deliveries that is not really necessary
  • or when resources are require to accomplish additional tasks within the project that those tasks are not part of the actual project, but are required! (for example, creating tickets/request in multiple systems for different parties to get permission to release/deploy a Web site, or having so many status meetings and reports)
7- Defects may take many forms;
  • wrong, missing an incomplete information (such as incomplete Scope, translating client requirements wrongly to other team members)
  • handing off work when it dose not meet hand off criteria.
What would happen to your projects if you experience less of 4 destructive project behaviors and minimum amount of waste? Simply, everything will be delivered on-time with higher quality!

Now, combine this with a project management framework or methodology such as Critical Chain Management or Scrum and you will get projects delivered even earlier than plan!

Why don't project based organizations reduce 7 wastes? why don't they prevent 4 destructive behaviors? don't they want to deliver projects sooner, faster and with higher quality?!

Because, it is not enough for a Project Based Organization (PBO) to change its mind set alone and expects a dramatic improvement in project delivery. PBO needs to reduce waste and prevent 4 destructive behaviors, and it needs to force its partners and vendors to do the same, and it needs to persuade its clients to do the same, and only then the whole system will be improved!

----------------------------------------------------
Similar and Related Blogs



Comments

Popular posts from this blog

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to Kanban From High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important.  Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.  Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while,

Stay Fitter

1st edition of Fit for Purpose: How Modern Businesses Find, Satisfy, and Keep Customers from David J Anderson and Alexei Zheglov was published in Nov 2017. They wrote the first edition in 7 weeks during summer 2017. I had a chance to provide feedback to them as they were writing and editing their chapters. The book basically talks about what a product and service is made up of, how customers measure the product or service and what metrics company managers must apply at different levels to be always fit for customer purpose (the Why's of the customer). If I want to summarise the book in one statement, it would be like: Align your business to how your customers measure your product and service. When I was reading the chapters, four guys came to my mind: Peter Drucker, Jack Trout, Eliyahu M. Goldratt and Clayton Christenson. The book reminded me of Peter Drucker; because he once made a profound observation that has been forgotten by many, his observation goes like this: "B

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe. At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better . The reasons are simple: It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2 And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next! At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and thei