"We must prevent this from ever happening again!" - the most wasteful words in Engineering 5

[geesaman.d]

Tossing this out for discussion, the corrective action / preventative action process and how it can drag a business process into the trash.

It seems common for mistakes of moderate severity to coincide with situations where the implications are amplified. The cost ends up being outsized. Then when senior management gets involved, the declaration is made: "This must never happen again!". Improvements to the process are proposed that greatly reduce the severity or cost in the future, but are rejected because they don't meet the standard of "never". Finally, a new process is agreed upon (extra review or signoff, extra checklist, etc) and a new burdensome step is added to every transaction for years to come.

And yet, the process is really a skeleton of a process with oversized bandages protecting a handful of spots, with each spot being one of these CAPAs. Risky business persists, with the risky transactions finding ways to bypass the bulky bandaged spots, and the individuals handling the transactions are too busy forcing the transactions through the checklists and approval processes to actually observe and think. The company doesn't stop getting burned and doubles down with bigger, thicker bandages. The process becomes covered in bandages and lacks agility. (Now our process is a mummy - honestly I apologize for this analogy). The company loses to competitors who are smaller, more thoughtful, and less burdened by bloated processes.

I'm a huge fan of the CAPA process. It's the overuse of absolutism that ruins it. When a CAPA adds cost or lead time to every transaction, the real question is where to best draw the line. How do you fight process bloat? How do you advocate a little moderation to executives who are making a name for themselves as being the one who "put that issue to bed forever"?

 

[IRstuff]

Tell them "never" equals "infinite cost," but offer up that "9d%" equals reasonable cost

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[LittleInch]

Well this is all about risk really.

The thing that gets me is people wanting to make everything "safe" or risk free.

The only way to do that is not to do it.

It should be about reducing risks to an acceptably low level.

So in the business sense if "must never happen again" then you need to stop doing that sort of business. Then you might not have a company which makes any money but it won't happen again!

So that's what I say. There's no such thing as safe unless you don't do it. It's about an acceptably small risk. That level of risk is different to everyone. I used to jump out of airplanes for fun and accepted the risk of hitting the ground at high velocity. To me there was an acceptably low risk. To lots of others they wouldn't be.

I loved the mummy analogy by the way. I think it works very well.

A company I work for has a document check sheet that was a good idea but totally useless unless you have 4 times the hours you are allocated to actually review the bloody thing. Everyone just pays lip service to it. But now it's there no one will take it away.

Remember - More details = better answers
Also: If you get a response it's polite to respond to it.

 

[CWB1]

Call me confused but are we discussing process or design failure prevention?

Design failure reoccurrence prevention is simple - max the specific failure mode's risk level on all future DFMEAs then design around that possibility or cancel the project.

Process failure is another animal entirely bc it involves the human factor, and ultimately the root cause simply is ignorance making excuses for others. Poorly managed companies make excuses to justify needing unique (read: convoluted) processes, excuses to justify being constantly behind schedule and/or overbudget, and even excuses to justify hiring consultants to train their PMs and/or transition to a different (usually worse) flavor of PM. Process failure reoccurrence prevention is also simple to execute but difficult for many to stomach, particularly in small businesses - eliminate excuses. Adhere strictly to standard process and strict performance accountability, ensuring folks know that piss-poor performance will result in a layoff. Many employees will grumble, some will leave, but ultimately you'll end up with a highly efficient staff that is very happy to be rid of the dead-wood.

 

[TigerGuy]

This reminds me of an assignment in university. We were working out how to distribute resources among different roads to maximize the access to emergency facilities after a disaster (which road should be the best built, etc.).

The final question was along the lines of "what would your approach to the model if you had infinite resources?"

Most of us responded that nothing could be designed as failure proof, no matter what resources were available.

 

[geesaman.d]

Call me confused but are we discussing process or design failure prevention?

I was discussing business process failure. The whole shebang from pursuing a quote to delivery. At my company we customize the design for many sales, so risk in our design process is directly affected by the effectiveness of the business process up to that point.

But I did fight the issue within the Engineering department - one time I had managers who insisted we needed a checklist for every order and that every time a new design error occurred, it was added to the checklist regardless of its size/impact. (You could make a 1000-line checklist and still miss most of the design decisions in an average order). I think they wanted to show off for upper mgmt by having a process to clear out CAPAs and give the appearance of never making the same mistake twice. (I think they also knew that if they bloated the system, they could build a new, less bloated process and take credit for that too.) We finally settled on brief design review meetings for orders of considerable cost/complexity/sensitivity at both the beginning and end of the engineering phase. Those doesn't help us catch a missing locknut on a BOM, but it helps us immensely in adding the right notes on the General Arrangement drawings, planning for the best design solution, and generally not overlooking important high-level stuff.

As it stands, we still have a detailed digital job tracking system that was created because the company didn't like how long it took to engineer orders and release to production. They also wanted to have a single engineering owner on every single job so that they could get direct support immediately. Any issue whatsoever was blamed on lack of visibility. We tooled up such a system and invest probably a half hour per order supporting it even today. Other than the PMs, nobody in the company ever looks at that job tracking system, and nobody aside from the job PM even knows how to find the engineering job owner in the system. That's a big fat bandage, but it will eventually go away when we migrate to a new ERP system.

 

[LionelHutz]

The company I work for pushes for checklists for every manufacturing step. In the new ERP system I put a checklist that asked the person to enter answers. For 6 months the people just did the right click and sign-off on these questions. When I pointed out that not one person had asked how they enter the answers I got told that we just need to make the check lists better. A check list is rather pointless when no-one actually spends the time to check what is called out in each point.

 

[LittleInch]

Lionel - My point exactly. They are there to make it look good to QA auditors...

Remember - More details = better answers
Also: If you get a response it's polite to respond to it.

 

[cranky108]

Best is to make one question that can not be checked. So if checked will result in a fail. Then move that question around on every new set of checklists. That way they pay a little attention.

 

[CWB1]

I had managers who insisted we needed a checklist for every order and that every time a new design error occurred, it was added to the checklist regardless of its size/impact. (You could make a 1000-line checklist and still miss most of the design decisions in an average order)....They also wanted to have a single engineering owner on every single job so that they could get direct support immediately. Any issue whatsoever was blamed on lack of visibility.

Those managers sound like they're on the correct path. When you look at a project plan, every seemingly insignificant task should be visible and have an owner, bottom to top (project) level. Every junior member of the team, regardless of their dept should be able to look at each project plan and see the relationship between various depts' tasks, as well as see/understand their own workload without making any assumptions/guesses. Even if your junior's only doing "insignificant" tasks like bolted-joint analysis, there should a BJA task listed for every part retained with fasteners so that everything is accounted for in the budget and timeline before you begin. Every task should also be linked to a standard task database continuously compiled from other projects so you know that each BJA costs $X and requires Y hours. With this data, your PMs also should be able to quickly build 90%+ accurate project plans and budgets, and taking these to 99.9% accuracy is only a quick engineering review instead of weeks spent creating project plans from scratch. When projects are late and overbudget the first thing I look at is the level of detail of the project plan. In those cases its usually ~10% of what it should be, rather than a detailed plan its a mile-high guess.

 

[geesaman.d]

You can certainly join them, because they performed poorly enough that our owning company sold the entire company to a competitor and that management team largely vanished.

A detailed project plan seems sensible for medium to large projects where multiple individuals are creating content.

In our case one engineer does all of the design work for our projects, so the engineering project plan is 1) draft a GA drawing 2) draft additional component drawings 3) draft the BOM and 4) get all of it peer-reviewed before releasing. All of those tasks go to the same person except for the sub-task of the peer review. There is no whitespace to manage, only progress.

Those managers thought that if anything was done incorrectly on any of the drawings or BOMs, it should go on the checklist. Didn't matter how job-specific the circumstance or trivial the error. That would checklist would bloat very quickly and become more work than engineering the jobs.

 

[CWB1]

More likely the company failed bc entrenched employees fought change, seen that many times.

1-4 sounds like a few dozen tasks which is more than large enough to have its own project plan. If you're simply modifying existing products, start with the original project plan and delete non-applicable sections. Roughing out six months' plan should be ~5 mins, final review ~30. If it takes more than about a week I have a formal plan.

Checklists belong in general how-to guides/standards, not your process. Whenever you find an issue tho you should review the process for gaps bc the main purpose of process is to prevent issues. If your process is good then people are to blame and accountability needs to be maintained, so either fix the process or the people.