25

I've been struggling in a peculiar situation since a while ago and would like your inputs on it. In our project (which is a maintenance project), there are some tasks that are done from time to time (on a weekly basis) and, although simple, needs to be done carefully to avoid the usage of wrong information.

However, there are some cases where a couple of lower level fellows repeatedly commit the same mistakes, over and over.

Task details:

  • This task itself is fairly simple (check the data in an Excel Spreadsheet, compare what is currently in place in the database, generate the inserts based on Excel data)
  • It's extensively documented and
  • I've done so many meetings to openly discuss about these very same issues that I lost my count.
  • this specific task is a kind of 'special copy and paste' where some SQL insertions are generated (for the sake of avoiding some heart attacks, this process is being automated)
  • This task is in place for over one year, and we had at least one every month (usually a lot more)

I know such routine processes are boring, but still one needs to understand (and I've reinforced it n times) that any information being changed in production, needs to be done carefully.

As of now, we have some higher level peers reviewing the data (and in most of the cases, raising flags), which is a waste of efforts... but that's the only solution we found so far to avoid bogus data going live.

How would you deal with such cases?

Improve this question
2
  • 1
    Adding a bounty to check for further insights... which doesn't mean that any of the answers already in place aren't good enough.
    – Tiago Cardoso
    Commented May 29, 2012 at 17:10
  • Hi all, thanks for all your insights, I believe we have a bunch of great approaches here that are potentially usable by other peers. I believe David answer is the most straightforward (replacing the person) but my underlying question was related to what to do before firing / moving this person to another project. For this reason I'd say it's not the best answer for the question (although it might be the best answer for the scenario).
    – Tiago Cardoso
    Commented Jun 4, 2012 at 16:19

15 Answers 15

Reset to default
22
+50

While we all like to trust that our team is going to do what they're supposed to, it doesn't always work that way.

Given your previous comment to Zbigniew about automation and firing, this is a good instance to institute checklists.

Write up a simple checklist of the steps that have to be followed (including what/how info to update), and make the employees check the boxes as they go, and sign off when they're done.

While seemingly a retreat in trusting people, sometimes you have to go that route. This system will give you some immediate benefits - you're know who didn't do the task correctly, you'll have supporting documentation if you have to escalate with the employee (if it doesn't improve), and you'll make them responsible (and more importantly - accountable).

Improve this answer
2
  • 1
    Hi Trevor, the idea of the checklist clearly stated (instead of a process to follow) will be the solution applied for this specific case, thanks for your collaboration!
    – Tiago Cardoso
    Commented Jun 4, 2012 at 16:17
  • 1
    Terrific Taigo, thanks. And best of luck with your situation.
    – Trevor K. Nelson
    Commented Jun 4, 2012 at 19:15
18

If there was a cog in your manufacturing machine that was well worn and slips and causes the rivets on your widget to be out of specs and tolerance levels, what would you do with the cog?

rbwhitaker: "but people aren't cogs...." This is the challenge, isn't it: treating people well, making them feel needed, wanted, valuable, while make the unpopular, non emotional decisions treating us human capability enablers exactly like tool enablers, system enablers, process enablers, money enablers...because that is exactly what we are. The hard, unpopular truth is companies, and their projects, do not exist so people have some place to go everyday. We are there to enable a capability, and we go away when we are no longer needed. We may not like how that sounds, but our feelings are not relevant.

The performance curve, if you believe it is normally distributed, says you will most likely have very average people on the job. Current thinking says the curve is not normally distributed at all, but instead skewed to the left, i.e., positively skewed. This means few produce the most; most produce little. These few individuals who "repeatedly" perform poorly are very unlikely they will even approach the MODE much less climb to be a high performer. They could, just not likely. It's a hard, crappy decision, but you're the PM. You HAVE to make the tough decisions. And you HAVE to consider what we know about human work behavior. And you have to deliver the goods. This means, act like a leader and replace the cog and turn the machine back on and deliver.

Improve this answer
4
  • Allocate to another machine, maybe? hehe. Good answer David, as usual directly to the point.
    – Tiago Cardoso
    Commented May 23, 2012 at 22:16
  • 2
    +1 for David. I would suggest introducing the deadline for improvement. Of course one can always dig deeper and ask whys, for sake of better understanding the co-workers. Nevertheless, it's a simple task and lenient expectation.
    – Bartosz Rakowski
    Commented May 30, 2012 at 11:17
  • 1
    I can understand your point in this particular situation, but people aren't cogs, and treating them as such is an excellent way to lose even the employees you want to keep.
    – rbwhitaker
    Commented May 31, 2012 at 23:18
  • 1
    As I understand the situation, we have a "soft" part of the process behind us, so discussion is about an escalation part.
    – Bartosz Rakowski
    Commented Jun 4, 2012 at 11:49
14

Have you asked them why they get it wrong so frequently?

Do they think they're just careless when they do it or do they believe there is an underlying issue that causes them to not pay it as much attention as they should?

It could be that they're frequently task switching or feel under a lot of pressure to get these sort of tasks done quickly to move onto other work. There may be other reasons (genuine or perceived) that cause them to not pay full attention to the task.

Improve this answer
1
  • +1 - i think understanding the why is rather important here !
    – the_reluctant_tester
    Commented May 31, 2012 at 3:55
9

I would start with answer "talk to the person and explain the importance of the task", but mentioned that you had done it, so I won't.

In such case, I see two solutions:

  • If the person has some software background and the case allows you to do so - automate the process. As you mentioned, routine processes are boring and automation is a creative approach to boring tasks,
  • Fire the person, so you stop wasting your time and effort.
Improve this answer
1
  • Hi Zbig, we're already in process of automating this task... but still the problem is a little deeper: if the coworker is not able to realize the information provided in the Excel, even the automation won't solve the problem. Besides, firing - although faster - isn't always the best approach (unless there are other reasons for such). Thanks!
    – Tiago Cardoso
    Commented May 23, 2012 at 19:43
5

Some alternatives I can think of are:

  • Establish metrics that tie into performance evaluations/bonuses. Target an error rate of X% to qualify for top rating, X+Y% for second highest, etc. Or better yet, target a decrease in error rate over time to give them incentive to improve.
  • Have them deliver early so that their work can be QA'd. If you find more than X errors in an hour send it back to them to redo.
  • Manage your own expectations. Anything with manual intervention is going to have errors so don't expect perfection.
Improve this answer
3
  • Hi Doug, these are good suggestions that I already used (I'm informally taking care of some people's performance) and we agreed that the correctness of these tasks would be part of the appraisal process. The errors keep coming (which means the appraisal will reflect it) but still I'm interested in have the root cause solved... and about the QA, that's what the senior guys are doing, and I'd expect to avoid having such reviews (as these tasks are extremely simple).
    – Tiago Cardoso
    Commented May 23, 2012 at 22:12
  • 1
    Don't tie it to appraisals. People make mistakes. It happens. If you are asking for a lot of manual work, mistakes are impossible to avoid. If "lower level" people keep making mistakes, maybe they shouldn't be doing it? Maybe it's not as simple as you think it is? Can you not automate any of it? Sounds like some well written software should eliminate the manual work entirely.
    – CaffGeek
    Commented May 24, 2012 at 14:46
  • @Tiago, in my opinion QA is not a good use of senior team member time. All you need is someone who is independent. Depending on what is an acceptable error rate QA only needs to be done on a proportion of the data. For example I've seen QA start at 10% of data, increasing in 5% increments to 20% as threshold numbers of errors are reached (e.g. I have 1000 points, start my QA with 100 but if I find >5 errors I look at another 50 points, if I find >2 more error I look at another 50, if I find >2 more errors I send back to be redone).
    – Doug B
    Commented May 24, 2012 at 16:21
5

If the higher-level peers are spotting the problems, they must be using some kind of heuristics, tests or monitoring to do so.

I suggest pairing up your higher-level peers with the lower-level people next time they check for problems, so that the lower-level people will understand how to test and monitor their own work. Once they have that understanding, they may want to test each other's work in order to avoid blind-siding themselves.

Even better, understanding the tests that are used may give them a better understanding of the purpose and value of their work, which may lead them to find better ways of doing it accurately, be that automation or otherwise. I find telling people to follow a process is rarely as effective or interesting as asking them to meet some particular test or goal or to deliver something valuable.

If they still don't get it right, it may be that this kind of work is completely unsuited to their strengths. For instance, they might be highly creative and responsive people without the mental rigor needed for repetitive tasks (most software developers are like this). If that's the case, you may want to train up someone with a different mindset who will have the patience and tenacity you need (a tester, for instance).

If on the other hand they were hired specifically to do this kind of task, you may want to take a look at your hiring practices.

Whatever you decide, dealing with the people involved will only deal with the symptoms, not the real cause which sounds as if it's systemic.

Improve this answer
1
  • Great insights, Lunivore! Will review them carefully and see the outcomes we have. Thanks!
    – Tiago Cardoso
    Commented May 30, 2012 at 16:16
4

To answer your question : move them to another team. So that they get a fresh chance to prove themselves.

My thoughts : Making a technical guy do this kind of routine work is not good. You should get this whole thing automated. If your boss / you is not convinced that a small investment is not needed in automating this, then I feel sad for your juniors. If you are convinced, and there are some other genuine constraints, fine, I can understand.

One of the best thing a computer can do is to match if the data from source A is same as B. If so, insert this set of queries. A human, being made to do this processing every time taxes the brain to do useless stuff.

I do agree the employees need to know how the process works, and why is it is there. But I dont agree that is of greater importance than applying is mind.

Improve this answer
3

Why is it that the higher level peers can spot the problem but not the lower level ones? Does it require domain knowledge to tell if the data is right? If so, then I'm not sure that this is really a people problem.

Mistakes happen all of the time when people do stuff manually. For example, I mistyped a half dozen times while typing this answer. But I have the domain knowledge to recognize a typo so I caught the errors and fixed them. If domain knowledge is required then you need to get these people trained in the domain or create a quick and dirty verification app or some sort of verification procedure that these people can run prior to claiming being done.

IOW, without knowing all the details of your particular situation, I question your placing the blame on people who possibly haven't been trained enough to know whether their work is accurate or not and not providing them any tools to verify their work.

OTOH, if these people are just plain careless then why wouldn't you want to simply get rid of them or at the very least not assign them to tasks that require precision?

Improve this answer
2
  • Thanks Drunk for your comments. In this specific case, there's no domain knowledge required (the task is almost over documented), this process is in place for over an year (thus it's not a matter of some mistakes, but several mistakes across months) and we've done several training sessions about the same very topic. Also, I continuously ask if there's anything to be clarified, and no improvements are suggested... which (I believe) put me in a situation I don't know how to handle :)
    – Tiago Cardoso
    Commented May 29, 2012 at 17:08
  • 1
    Well then I think you should know exactly what needs to be done. In particular, these people are not capable of doing this particular task properly. Not everybody is detail oriented and that is a good thing. Rather than fit the square pegs in the round hole, either give them something else to do that they are more capable of doing and assign someone else to the task or get rid of them entirely and hire somebody with a more detail oriented focus.
    – Dunk
    Commented May 31, 2012 at 21:55
3

I would NEVER assume that peer review is a waste of efforts. On the contrary, it saves you a lot of time fixing bugs that otherwise could go into production and cost you a lot more.

In your case, I would force peer review even before the SQL is executed. Make someone else (better two) look at it before executing. Catching an error in a query is faster and more reliable than in data scattered all along the database.

For the answer about the guy, I can't totally agree with the cog example suggested by Espina. You can't just fit any cog wherever you want. As you said, this job is boring as hell, maybe he will be more motivated working to automate it. As a leader, you should try to take these boring and demotivating tasks away from the team, do it yourself for a while and delegate them a task to automate it. You will have more confidence on the data being pushed into production (since you are doing it) and the automated solution would be implemented faster, since the team doesn't have to bother with these kind of monkey jobs anymore.

And always remember, if you care for bugs going live, peer review is the key.

Improve this answer
5
  • I do agree that a review (in this case) is a must to avoid issues down the road... the problem is the overload it causes in the team. Let's think of a process of washing a car. If you have a newbie around, of course a review will be required to advise what went wrong. The problem is that after 6 months you're still putting a more seasoned guy to review such a simple thing. Better to drop off the newbie and keep the senior doing it by itself (which is a less waste of effort, but still waste).
    – Tiago Cardoso
    Commented May 30, 2012 at 16:41
  • Don't look at review as an overload, it's a necessary step in any serious development model. Even if you work with the best team, they're humans, and humans makes a lot of mistakes. Each bug you let pass to the next step in development will cost you about 10 times more to solve. Also, seniors are vulnerable to self confidence, they can make the same unnoticeable mistake for years thinking it is right or is the only way to do it. I apply extensive reviews with my team, as it helps not only to catch bugs ASAP, but also to spread knowledge among us, improving the learning curve for everyone.
    – eMgz
    Commented May 30, 2012 at 17:08
  • My point is... the whole team has the understanding that this process is almost as simple as sending one mail... who'd like to be reviewing mails? I completely agree that anything beyond the obvious must be reviewed, my concern is that the instructions are 'take it from here, paste here and run there' and still we have problems for over than 6 months...
    – Tiago Cardoso
    Commented May 30, 2012 at 17:18
  • Well, given that, can this guy program at all? If not, I don't know what he is doing in your team.
    – eMgz
    Commented May 30, 2012 at 20:47
  • To make things worse... it's not even a development project.. is a maintenance project.
    – Tiago Cardoso
    Commented May 30, 2012 at 23:21
3

If he is making the same mistake again and again , are we sure that the peers who are reviewing his work or him , not applying the same(and not working) measure to guage him again and again

Is the review process working for the person in question ?

Basically, has someone looked at why is this happening repeatedly ?

Lack of skill, motivation,grudge or general lethargy ?

Has he been asked "have you been given the amount of support and guidance(that you want) to get it right the next time ?"

if yes , and if he gets it wrong the next time , then maybe it is time to relieve him of the current role , unfortunately.

Improve this answer
3

What you need to do is an Ishikawa diagram (aka fishbone) with the involved team members. This will help you find the root cause and address it.

  • process
  • people
  • materials
  • equipment
  • management
  • environment

You mentioned automation, but you don't seem to think process is the problem. You mentioned repeated training, so you don't think management is the problem. You have suggested people are the problem, so you may be able to find a sub cause and address it there.

I sugest you leave all options open and do some form of root cause analys, both individually and as a team. We simply don't have the contextual knowlage to do it for you. Once you have the root cause, you will which of the sugestions offered will be of most help.

Improve this answer
1
  • Hi sFreebairn, welcome to PMSE! My point is: the whole process worked smoothly for over than 4 years until the person responsible for the task changed. I can't think that the other people that already worked on the same tasks were so outstanding to mitigate process / documentation / material whatsoever problems by themselves.
    – Tiago Cardoso
    Commented Jun 4, 2012 at 14:50
3

Another way to look at this is, if work allows, to give the job to two people - one to QA. If the same people do this, then they could be swapped around each time. At least this gives two sets of eyes. When keying boring data, errors are bound to happen.

I'm pretty long in the tooth now, and when I got my first IT job back in the early 80's at a high street retail bank, they still had data keyers (they still had punch card readers but that's another story). They were called Data-Prep. They were a team of girls (all female, all under 25 - so we spent a fair deal of off time up there :) ) who sat at number keypads typing in cheque numbers at a blur. Their job was mind numbingly boring and prone to error (due to speed and monotony), so everything was keyed at least twice (in this case by random people from the team) and compared. Errors were thrown away and thrown back in the pot to be rekeyed again (twice). What I am saying is that, if possible, finding a way to compare data entry from two sources highlights errors before committing (it's easy to make a mistake, but hard for two people to make the same mistake in the same place).

Also, looks like it is not unreasonable to put more pressure on getting that automation in - after all you have the higher-up peer group on your case, so use them to push for resources - a year for something so minor compared to production risk is nuts IMHO.

it may also be cost effective to get some temps in to do any keying (data entry) - techies are no good at monotony - and will hate you for it too!

Improve this answer
2
  • hi mate, thanks for the answer. The idea of having someone doing QA for this process seems to be a waste of efforts since this process worked fairly fine for several years until this moment (without QA, only one person doing the scripts and taking responsibility for them). That's a specific case with a specific person, and QA'ing isn't productive. Besides, although I understand that keying are boring, sometimes one needs to prove that can do simple things to move on.
    – Tiago Cardoso
    Commented Jun 4, 2012 at 14:47
  • Sure, but that leaves you with only one option - you can't justify going around them, you failed trying to go through them, so all that is left is to remove them. Suggest, therefore, you look at giving the job to someone else (and then deciding what to do, if anything, with the one(s) you replaced).
    – Wolf5370
    Commented Jun 4, 2012 at 15:00
3

This is personal opinion of course, but in this situation, I would take the two lower level people and put them in charge of double checking each others work. Limit the amount of reviewing done by superiors, and give them some responsibility.

Improve this answer
1
  • Hi Samuel, welcome to PMSE! We were doing it... until the other lower dev left the project, hehe. Thanks for the suggestion.
    – Tiago Cardoso
    Commented Jul 5, 2012 at 19:06
2

Here is my 2 cents:

  • 1) Ensure that the documentation, queries etc are in the appropriate version control system.
  • 2) Escalate to the functional manager the technical member reports to.
  • 3) If the situation occurs again after 1 and 2, ask for a replacement resource that might be a better fit for the maintenance effort.
Improve this answer
1
  • Turns out that more than once the documentation was updated in SVN and still some templates used were outdated (i.e., no SVN refresh from time to time)...
    – Tiago Cardoso
    Commented Oct 19, 2012 at 11:17
0

Since you have more than one making this kind of mistake, have them proof each others' work before turning it in.

Improve this answer
1
  • 1
    Hi, welcome to PMSE. "As of now, we have some higher level peers reviewing the data (and in most of the cases, raising flags), which is a waste of efforts... but that's the only solution we found so far to avoid bogus data going live." - This was actually included in the question, so you're repeating something the asker already said. If you have a solution and can explain why it's a good solution, please feel free to edit and expand this into a fuller answer. See How to Answer for more guidance.
    – jmort253
    Commented Apr 12, 2014 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.