Gemba Walk

Go to the place where the work is performed, that is the Gemba walk.  This does not apply just to manufacturing, but also line managers and their respective departments as well as to project management. You want to know what is going on, what could be better, go unto the work space and watch and talk with the people doing the work.

Where the work is performed, depends upon the work.  For example, if you are the manager of a product testing department, the place where the work is performed is likely the lab,  Go where the Hardware In the Loop (HIL) rigs and see how things are going, go to the test rooms where the environmental (hot and cold) and other stimuli (vibration) are administered to the product.  Learn how this work is actually being done. Ask questions about how the work is going.  What sort of things are difficult and why? What can we do to make the … Continue reading

5S

If you have spent any time in the automotive industry you have probably spent time working within a system called the 5S. Continue reading

Mura (unevenness)

The unevenness or mura of the work wreak havoc on our work. Project demands fluctuate and working on multiple projects likewise creates or exacerbates the unevenness. In product development work can get heavy around gate reviews as the project must accomplish certain expectations and milestones are reviewed in the gate activities.  One functional department may not be at capacity, but anther may be running beyond capacity.  The arrival of the work from one department stacks up as input to the next department.  This then creates muda as we have waste in the form of over production.  All of this unevenness has impact on schedule and the people performing the work, and sometimes specialized equipment as the demand fluctuates wildly.

Material that our development team will use may also be subjected to this unevenness, think prototype parts, upon which we will test and learn about the product for the next iteration of the development loop.  When lead times are long, we may … Continue reading

Muri – Overburden

Muri is waste associated with pushing people, processes and equipment beyond the limits or overburdening. An organization may be enamored of working large numbers of overtime hours, but any benefit for such some at a cost, and this is an example of overburdening.

I once worked at a place in which the employees averaged being at the organization for between 10 – 20 years, and had vacation time commensurate with being within the organization per the company benefits manual. The people that had been with the company that long had more than 4 weeks of vacation, which is 160 hours off of the 2000 hours or total work hours approximates 1840.  On top of this time off, the company also offered special days that it gave off to everybody – think Thanksgiving and Christmas for example.  Yet when it came to calculate the work the organization could undertake, the organization used 1980 per person to estimate the total amount of … Continue reading

Muda – Waste

For those familiar with the lean approach to the work or the Toyota Way, you my already know about the concept of Muda. Muda is one of the three categories associated with lean that impact performance and costs to the organization.  Muda is regarded to have seven waste types or areas or actions that cause waste.

Over Production

Just like it sounds, making more of something than the need for that something.  This does not just mean parts, but also extends to work product deliveries throughout the work pipeline. Think SIPOC (Supplier-Input-Process-Output-Customer), in this case any output from a process (P) delivered before the depending process (C) or work can start, leaving the work product just sitting there.  Another variant of this waste would be working on products that are not for the next work process, but some prioritized work that is further down or upstream.  When this is not coordinated well, we end up with rework, and if changes are required … Continue reading

Kanban and Visual Management

Kanban and Visual Management

Kanban is a lean method for identifying and managing the work and the flow, and it does so by creating a pull through environment.  We will start by identifying the work we need to do. Each work item we need to do will end up on an individual card.  The cards will be “pulled” as we have the time and talent to commence that specific work element. The card then moves from the backlog of work items, to the WiP or Work in Progress section of the visual management board.  The visual board may have headings such as:

Backlog Work in Progress (WiP) Work for Review Work Completed / Demonstrated

We will pull items from the backlog and place the card in the state that corresponds to the work, for example, the work moves from backlog to work in progress as the work commences.  It is easy for anybody to see the status of the work. … Continue reading

Project Organization Structure

If you have been a project manager for any time at all, you probably have experienced competing demands from the sponsors for the project.  The sponsor is the person(s) who drive the scope of the project in conventional projects.  In some instances, the project manager may find that there are in fact multiple sponsors and the respective priorities of those sponsors may be at odds.  This is not the only difficulty to which the project manager must respond.

From the CHAOS study by the Standish Group, on project failures and success factors, we find the results below. This study analyzed 23,000 projects in 1998[i], of the factors that enable project success and failure.

Success Factor Influence User involvement 20 Executive support 15 Clear business objectives 15 Experienced project manager 15 Small milestones 10

 

A list of the top 5 factors from this study, demonstrate that importance of the interface between the project, the executives that are supporting … Continue reading

Value, Scope and Change Requests

Value, Scope and Change Requests

Change requests are part of any development project.  Change requests are sometimes necessary as we learn by building and doing the work.   In my experience, change requests often are born from requirements we thought we understood, only to learn by working with the product or system that we really did not have enough understanding to be able to record this in the form of specifications.  We think we are making things better when we spend an abundance of time documenting the requirements, at least those requirements about which there is uncertainty. That is not to say this is not a worthwhile endeavor, we have been in product development long enough to know there are downsides to delivering a product that has no associated documentation.  The testing and manufacturing portions of the work will make use of these requirements documentation and the errant or lack of documentation makes the work of these areas and more difficult … Continue reading

What works: team participation

The team

My first job out of university was with a small product development and manufacturing company. The company developed their own embedded products for sale all over the world.  I do not know how this collection of technicians and engineers ended up as a tight or as close when it came to work.  The group was a collection of characters. The other electrical engineer, we will call Flicky (we had secret names for each of the team members). There was one technician we referred to occasionally as IR because of the unfortunate anagram is name made.  There was a mechanical designer we referred to as BWI, I will explain that later.  There was another assembler / technician we referred to as Wal.

Games with the Team

When it came to the electrical or embedded product idea generation and development, I can recall a game we played.  We would read the specifications together, asking questions where we could of the sales … Continue reading

What does not work – Queuing Theory

Queuing Theory

Queuing theory is the study of waiting lines and is associated with business in determining resources needed to achieve service business throughput objectives, but it does not just apply to services and material handling.

Queuing Theory and Billable Hours

I have worked at companies that had a target for billable hours, that well in the 90%. That is, 90% or more of the hours the employee worked, had to be assigned to specific project work. The organization treated the time an employee was at work and available to work on specific projects, at nearly 100%, so for example, in a 40-hour work week, it was expected that 36 hours or greater were dedicated to specific project activities.  This was recorded in the project schedule.

Queuing Theory and Product Development

The impact of queues on product development and knowledge management in general is explained well in this Harvard Business Review article a snippet of which is found below:Continue reading

Single Sign On provided by vBSSO