Don’t Base Your Project Decisions on Assumptions

Yesterday’s I posted a blog reply to question that was posed at the forums: How to deal with a slacker. Today I wanted to emphasize one important factor when making decisions: making assumptions might not be the best way to deal with things.

If you think that somebody hasn’t get stuff done, be absolutely certain that you have clear evidence about that.

And by “good evidence” I mean that you’ve specified what the guy should do, and then compare the results. The following type of assignments are quite good examples of “clear evidence”:

  • You’ve given assignment to a person to create a document that contains game requirements. The document never arrives.
  • You’ve given a written list of tasks that require person to create a list of graphics engines for the project. He has said to you that he will do that, but the list never comes.
  • You’ve asked the person to program part of the game (such as “basic AI where the computer will chase the player”), yet you don’t get to see any lines of code.

Here’s some examples of “bad evidence”.

  • You wanted (in your mind) that the guy would email the rest of the team – but he never did. Well guess what – perhaps the guy didn’t know that he was supposed to email them.
  • You asked the guy to “help you out” with the project, and aren’t happy with his performance. Well guess what – perhaps the guy has a different idea what “helping” means. Perhaps he thought it would help doing the game design, and you think it meant doing the project schedule.
  • You give a task (by email) but never get it confirmed. While it perhaps shouldn’t be your task to make sure everything is confirmed, you must be aware that the other guy might never received your assignment. If he hasn’t confirmed that he understood what he needs to do, then I wouldn’t assume that he is going to do much about it. Bottom line is: get things confirmed.

When you give assignments, you might want to consider these two factors:

  • You listed clear tasks or defined what “responsibility” really means in writing. By definition, it must be possible to say when the condition is met. Avoid situations where you can say that the task is “almost finished” or “maybe done”. You should be able to say that the task is either done or not.
  • Make sure that the other party confirms and understands what he is supposed to do. In army they asked us to repeat the commands – and there it worked pretty well. Sometimes you might require the other guy to tell that he knows what you expect from him.

Don’t assume that the other guy understands what you expect from him. Don’t base your decisions on assumptions.

Juuso Hietalahti