They want us to record our mistakes in a "Development Log"

 At first glance, this process sounds horrid.  However, I worked in a department where the staff ran projects that were all very similar.  We had so many issues, and sometimes someone's project would be unsuccessful for the same reason that another person had already encountered.  We wanted to minimize that, so we set up a tracking system and for every project you had to declare if it was successful, unsuccessful (not completed), or "successful with issues" (meaning completed, but not on time).  Everyone was really open about their unsuccessful and "successful with issues" projects for two reasons - one, so that no one else would suffer the same failure, and two, because the feedback went back to people responsible for improving the process to make sure that type of failure was fixed and did not recur.

The staff saw the positive results of reporting their failures almost immediately in the process improvements that resulted from their reports, and in co-workers who were saved from having the same type of failure.

We kept metrics, too, and of course the goal was to keep the successful % very high.  The point is, we weren't all about the failures, but all about how few failures there were and how to continuously make sure there were even fewer.  As we reviewed each project (briefly) there were a lot more successes than failures, so there wasn't a negative tone.

I don't know if your process can be more like that - showing quick results to prevent future failures and reporting both the successes and failures so that the failures are not all everyone sees, but it worked great in our case.

Jenn

Hi Mark,

We started with error reporting in a separate tool for ISO9001 certification a couple of month ago. Every employee could use it to report an error. Each error is revised from one specific manager which is responsible for this error reporting.

We made trainings with each employee and told them:

- reported errors will not be used to punish somebody

- error reporting needs to be brief and gentle

- some processes will be enhanced, so there is a need to report an error

We learned some lessons: 

- some employees started to use the error reporting to blame other departments or employees.

- some employees are refusing to report errors - to not blame other departments

- you need to include a responsible person who causes the error in the report. It is easier to report an error - for some employees - if they don't need to name a specific employee - simply choose the manager of that team. This is our default now.

Internal error reports are handled in a very short time frame (keeps erverybody motivated). The specific manager talks then back to the reporter (or non-reporter). Some error reports will be edited or deleted. Sometimes errors are reported after a chat with an employee from the specific manager.

In general it is very helpful to have this internal error quote - another option could be to build up an internal error database. 

Regards

JK0108

The Six Sigma approach is to ask where the process can be improved.  Processes are notorious for having gaps which allow people to fail.  In most situations the process can be improved.  The weak idea is to catch the errors before they can be compounded.  The stronger approach is to redesign the process so that the error can't occur.

Consider an assembly line where items are being put in boxes.  Rather than counting or weighing the box to see if the minimum number of items were put in it, design the box or the machine so it can't be closed unless it has the right number of items in it.  Say the open box is sitting on the scales and if not correct weight, it won't be closed.

If you stick to process problems, then this will not cause people to feel threatened.

Harder to do with services, but usually possible with some creative thinking

regards

kevin

 The ITIL approach would be a post-implementation review, where everybody involved in the project discusses what went wrong, what was sub-optimal and what could be done differently the next time. The discussion is very open and has lead to some substantial process improvements at work.