Proximity in Operations

The time to work together is sooner rather than later
(Courtesy of www.engineeringdaily.net)

The strongest operations will purposely locate the engineering as close as possible to the manufacturing operations.  It has been proven over and again that this encourages dialogue between he two groups which benefits the operation.  But what about  within an engineering organization?  Are there good ways to set up an organization to maximize the engineering talent?

One of my earlier posts relayed my positive experience with Integrated Product Teams (IPTs).  This involved having members from different functional groups together in one group to successfully design and support a product.  However it is not enough to have these members in one group.  They must sit together or near each other to make it work.

At Boeing I was a structural design engineer.  My closest associate I worked with was the stress analyst.  It was our job to work together to develop a statically and dynamically robust design that would be eventually manufactured.  So he and I sat next to each other , even sharing a common table between us.  This allowed us to lay out drawings and sketches to discuss design details immediately rather than travelling across an office to work together.  Other functional members sat close by so even though I interacted with them less frequently, they were close by to discuss details.

Better designs evolve when everyone resides near each other
(Courtesy www.astrocenter.tamu.edu)

Many companies still embrace they idea of  the same functions (i.e. stress, design, manufacturing, etc) sitting together in an engineering operation.  But this idea allows groups to become an "us" versus "them" philosophy that stagnates production.  It is better to sit together and then "we" can use engineering skills to a better advantage.

Work Breakdown Structure (WBS)

The key component to managing any project in an operation is the work breakdown structure (WBS).  It is the very essence of what tasks and steps are needed, who will perform them, and when they are due to keep the project on task.  It takes effort to build the WBS to be effective, but there are several tips to remember to help.

An example of a WBS for a dinner party
(Courtesy www.chrisitaindenard.wordpress.com)

First, keep the tasks small enough so that one person can work on them independently on a full time basis.  By assigning the task to one person, you have established responsibility belongs to one person and he or she knows it is all on them to keep on track. If the task is too big, one person will be overwhelmed and the quality of the completed end item will suffer.  If you have two or more people assigned to a task, each may think the other(s) will complete it and as a result no one will see it finished.

Second, keep on top of the program schedule.  This sounds like a "no-brainer" but from my experience some project managers believe tasks can be performed on auto-pilot.  Depending on the project you should have at least one or two schedule reviews every week in order to address schedule challenges or delays.  It will happen so it's a good idea to be able to be ready to establish work around actions that will bring tasks back on target.  Management will ask what you are doing to fix the problem so have a plan developed quickly.

Third, get management's understanding that sometimes you need help.  There will be times when you need additional help due to unforeseen circumstances.  You or your designates may not be able to fix it by themselves.  That's why it's a good idea to sit down with your boss and get their buy in that they can get you help immediately if you need it.  A good manager will have a sense of urgency and support that will drive them to borrow or pull resources to you to help complete the process.  You won't really know until it happens but it's essential to prepare them for the possibility of a request in advance.

Establishing work tasks is essential to successful operation
(Courtesy www.sciencephoto.com)

Experienced Workers in New Positions

(Courtesy www.islinguists.com)

One of the benefits of hiring an experienced worker is you can expect him or her to be able to ask the right questions, look for answers on their won, and generally find out how to do their job without a lot of oversight.  However if a person is hired to your organization based not as much on direct experience but on common, transferable skills, it  is essential that there be some allowance for learning for the new position.

From personal experience, I have had this happen to me.  I was hired as an experienced engineer at Boeing to help out a group.  However the new group's task (passenger seat integration) was new to me and required some initial learning and mentoring that I never received.  Needless to say my experience was not a pleasant one and I eventually left the group.

Here are some ideas to integrate an experienced worker into a new role:

• Find out how much experience he or she has in the new area. Then fill in the gaps with classes, training, and mentoring to get that person up to speed.  It shouldn't take long for an experienced worker to grasp the new details so this is time well spent.
• Get feedback from the new worker.  Sometimes managers (especially younger managers) are reluctant to talk to a seasoned worker.  Get over it.  Your organization's success depends upon the solid performance of it's workers.  Let them know you care.
• Find out what areas the worker excels at and give them projects that showcase those skills.    They can help your organization by tapping on previous experience while learning the new job at hand.  

(courtesy: www.cochrenfoundation.com)

From an engineer's perspective it is important to know that while many skills are transferable there may be gaps that need to be filled in.  Don't just throw someone into the deep end of the pool and hope they know how to swim.

Database Management

For an operation to be successful many items need to be tracked in some type of database or software system. These systems are often used by manufacturing, engineering, and even management to track an event or project that all three groups (and more) have a stake in.  If one person is in charge of input and output of the database (including management report outs) then if is a straightforward process as long as you can depend on that person.

Database management requires keeping status current
(Courtesy: 8u.fotomiser.com)

The problem comes when you have many people tasked to keep status on a project.  I have been personally involved in several of these scenarios and it is always a struggle to keep the database updated on a regular level.  One such program required the engineers to track data set releases and provide revised  estimated completion dates (ECDs)  if scheduled events were going to be late.  As the focal for the database, I would often have to track down particular engineers and extract a new ECD and input it into the database for them.  It was a lot of extra work which was unnecessary if the engineers were more diligent.

There are several things that could have been done better to help the process go better:

• Have management emphasis (and enforce) the importance of keeping databases current with the latest information.  Employees will focus on providing updated information if management is keeping emphasis on timely updates.  Management must not just send e-mails out requesting updates; they need to personally talk to those who are tardy on their inputs.
• If several groups use the database, assign one person in that group to be responsible for ensuring updates are happening.  It is pointless for one single person to be responsible for inputs of hundreds of users.  Break the task up and get help.
• Schedule daily stand up meetings to allow those who are tardy to explain to upper management why they haven't kept up.  I guarantee that this will ensure the database is current.

(Courtesy: www.gettyimages.co.uk)

Rejections on the Floor

An inevitable fact of life in operations is the occurrence of errors or rejections on the shop floor,  Upper management is always striving to "eliminate rejections", "work smarter", or some other catchy slogan to eliminate errors.  But the best you can do is to implement checks and balances in the process to help reduce the error count.  What you do when you have an error on the floor is just as important as trying to avoid it initially.

(Courtesy www.unlimitedchoice.org)

Many medium to large companies have an error reporting system established whereby standard rules are followed when a rejection occurs.  Once an error is reported or written up (usually by Quality Assurance) it is essential that the information is accurate.  Some key things to check:

• Are the correct part numbers listed in the rejection write-up? I have seen many error reports (often called rejection tags) that have the incorrect part numbers and or descriptions in error.  This is a problem if there was ever a need to go back and look at a repair later and the records were in error.
• Is the error write-up clearly written? If there is confusion on what is really in error, then the incorrect analysis and repair methodology will not effectively address the issue.
• Will a repair impact downstream users?  If your repair will effect any downstream users you must coordinated before you provide your repair fix (disposition).  Otherwise bigger problems may occur that will adversely affect schedule.

For those weighing on the repair, be certain they have the necessary skill and experience to effectively analyze the problem.  An inexperienced mechanic or engineer may have good intentions, but a lack of experience in a key juncture of the operation could be a problem further down the process.

Finally it is essential to keep a record of the different rejection scenarios that one encounters on the shop floor.  Some times repairing the error requires a unique fix that should be shared with others to help educate them.  This is most important if it is second shift or a weekend and subject matter experts are unavailable.  A good database will help locate a similar issue to consult for you rejection at hand.

Rejecting discrepant parts is a fact of operations management
(Courtesy www.blg.gov)