I have recently been asked to reincarnate a process that died a sad death.  The premise was, a list of minor/major faults caused by members of the department.  My managers wanted this list to be "managed" by those who were involved in the failings.  I can't understand how I am meant to incentivise the team to fill such a report out.  I am told that no one will be disciplined for filling out the report and that it is only there so that the department can get a feel for where improvements can be made.

You can guess why the old one died - no one filled it out.

Do any of the members here have an alternative to the above which accomplishes the same thing?

I would most appreciate an outside view.

Kind regards,



London, UK


jennrod12's picture

 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.


JK0108's picture

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. 





Kevin1's picture

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



MichaelP's picture

 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.

MarkLDN's picture

 A preliminary thank you all for what look like great responses.  I hope you don't mind if I disappear for a month on study leave and revive this when I am back (forgot to subscribe so only just seeing this).  Your efforts will not be fruitless to help my department and I out.  Looking to give back how I get on.

Best regards,






MarkLDN's picture


Once again, all of your contributions were very much appreciated.  I have amalgamated the above information into a concise document which can be found here.  It is a Google Doc open for editing by anyone with the link.  Perhaps others who read this thread will find it useful for their own purposes.

I plan to hand the document over to my manager for their review and I will feedback to this thread how we progress with implementing an approach to error reporting.

Kind regards,