12

I guess you know the situation, that with some of your colleagues you manage to establish a common way of communication right away (whatever you talk about is understood perfectly by the other one), whereas with others it takes a while or maybe never gets established.

I understand that to a large extent that's related to communication skills in general, but I think it is particularly important when you as a project manager assign tasks. You explain the overall objective, how this fits into the overall project, within which time the results are expected, maybe give indications how you think this can be solved, and your colleague agrees and indicates everything was well understood (which may or may not be true).

What seems to me very important in that regard, is that just because of fear of not being understood to start micro-managing.

So which possibilities come to your mind how to make sure that you managed to express yourself understandably? How do you deal with people that, for whatever reasons, would not come back with questions for clarification to you and rather spend a day or even week on something that does not contribute to the overall progress?

|improve this question
5

I believe that offer to the colleague the opportunity to let him explain what he's going to do is one of the most simple and effective way to review if you made yourself clear enough.

Notice you don't need to actively asking him 'okay, so what you're going to do now?' but offer enough space to let him explain how he's intended to do the task, what he believes he may need and if he can see any possible obstacle.

In case you have clear in your mind what the goal is (if you don't know / understand what you're asking, you need to clarify your questions first!) you might foresee possible problems / scenarios to be discussed. In case none of them are raised, maybe the colleague didn't get a vision of the whole scenario or he misunderstood your message. Either way, recap the topic before move on.

|improve this answer
  • Thank you, I think particularly lining out that there is no need to ask actively 'okay, so what you're going to do now?' but still offering enough space for proper feedback can be quite useful. – bonifaz Mar 19 '11 at 20:34
4

I don't believe that the assignee should describe how he/she will complete the task, as suggested by @Tiago. It is the assignee's job to determine how the task will be accomplished. It's not the project managers job to determine how; instead, his/her job is to determine what needs to be accomplished.

What I typically do is have the assignee repeat back what the goal of the task is. If he/she doesn't understand the goal, I'll be able to clarify, based on his/her original interpretation of what he/she thought the task was about. Some people repeat back this information on their own, and I've come to appreciate the people who understand the importance of repeating back communications as confirmations of understanding.

This is also why face to face communication is paramount to making sure instructions and goals are crystal clear. Body language can help communicate understanding versus confusion, as well as apathy and listlessness.

A great example of how confirmations are helpful is in the military. The military uses confirmations to help avoid accidentally blowing up troops or civilians because one soldier said 7 degrees and the other soldier heard 10 degrees. When the artillery unit confirms "10", the soldier on the front line can confirm/reject the instruction and re-clarify. No one does anything until the front-line says "Yes, you understand. FIRE!".

In addition to confirmations, I also set pre-determined, scheduled check-in dates where one of us will approach the other to see how things are going. I always leave the door open for the assignee to come to me at any time with a question or a problem, but I try not to bother them until the check-in dates we agreed upon.

Not only do the check-in dates help me Avoid Being a Micro-Manager, they also hold both of us accountable for managing the communications. This gives the assignee plenty of room to breathe and ownership of the task, while still giving room for any adjustments, should we discover discrepancies in the check-in meetings.

|improve this answer
  • Sorry, I think I do not understand the exact difference between "the assignee should NOT describe how he/she will complete the task" and "the assignee repeats back what the goal of the task is", where you seem to be against the former, whereas supporting the latter. Naturally, the assignee often is not aware of each and single step required to achieve the final goal, but in my understanding, the difference is not that substantial. Can you please clarify? Thanks. – bonifaz Mar 19 '11 at 20:39
  • 1
    @bonifaz - If you're working at McDonalds, you'll probably want your teenage, about-to-go-hide-behind-the-dumpster-and-smoke employee to explain, in detail, the steps you want him/her to take to properly clean the fryer without damaging it. But when you're dealing with highly educated, highly motivated, experienced professionals who are capable of working independently and solving their own problems, you let them choose how to complete that task. What you're asking them to read back to you is what the goal of the task is, not the steps required to get to that goal. – jmort253 Mar 19 '11 at 20:57
  • 1
    To elaborate, I may tell you "@bonifaz, the deployment absolutely 100% must not break as the client is counting on 100% uptime.". This doesn't mean I should tell you how to do your job. It's up to you, the expert, to determine how you will make sure that 100% uptime is maintained. All I need you to say is "@jmort253, I understand the client needs 100% uptime and cannot afford any downtime. I have some ideas for how to do this, I'll get started and check in with you in 3 days so we can review and make adjustments to the plan that I will create". – jmort253 Mar 19 '11 at 21:01
  • @jmort253, thanks for your clarification. In general I agree with you then, however keeping in mind that there is still some "it depends" in it, e.g., level of knowledge of assignee in that particular domain, how well you are able to estimate his insights, ... – bonifaz Mar 20 '11 at 14:21
  • @bonifaz - Agreed. You have to use your best judgement. However, you can eliminate the need to micro-manage by selecting the best, most qualified person for that task. – jmort253 Mar 21 '11 at 4:37
2

I suspect that the task assignment was perfectly clear (how can you not understand "I want you to complete Task X by Friday"?) but the task scope was vague. Specific acceptance tests are strongly encouraged on all tasks, even when adequate specs are available.

|improve this answer
  • @Steven - Can you give an example? I'm not sure I understand. This seems to me like you're suggesting waiting until the deadline to determine if the assignee understood the task? As a PM, I want to know you understand what you're going to need to do so you don't come to me in 5 weeks with a 2 door sedan instead of a dump truck. – jmort253 Mar 19 '11 at 6:39
  • @jmort253 - you're on the right track in your answer: verify the goal of the task with the assignee. Whenever possible, each task should also have tests to ensure that the goal is met. In your example, I can think of two obvious tests: (1) a picture of a dump truck and (2) a spec like 'vehicle must be able to routinely carry 2000 pounds of dirt 300 miles, and to unload in less than 1 minute' – Steven A. Lowe Mar 19 '11 at 14:53
  • @Steven, I think that basically everything can be misunderstood, therefore I think that both of your dimensions mentioned should be verified. – bonifaz Mar 19 '11 at 20:42
  • @bonifaz everything can indeed be misunderstood; i don't understand your comment, for example ;-) – Steven A. Lowe Mar 20 '11 at 1:58
  • 1
    Wow, you both make very good points! Communication is tough, and I think that if we combine what @Steven is saying regarding acceptance tests with what @Pawel said about making people feel comfortable asking questions, then we can help overcome communication challenges. – jmort253 Mar 21 '11 at 4:40
2

There's one piece we're missing here. One thing is to hear recap of the assignment from the assignee but another thing is clearly setting expectations.

For me the problem starts earlier - if we just deal tasks and expect people would know how they're expected to act we basically ask for communication issues. We should start with clearly setting your expectations, e.g.:

  • if anyone has any issues they should ask
  • if they aren't sure whether they should ask they should ask
  • if they're stuck with the task for longer than [put something reasonable here] and they used [Google/local knowledge base/etc] they should ask
  • if they make any assumption they should at least make PM aware of it or ask
  • if, for whatever reason, neither of above rules doesn't apply they should ask

The same (setting expectations) applies to reporting, Make it clear how often you expect updates and what information they should include. Also, if possible, make it more comfortable to people who report to you - if one developer hates to drop you an email at the end of day, let him come to you for a quick chat or call you instead and share his update. The more comfortable people feel the more likely they're going to follow the rules. Of course another perspective is the size of the project - you're not going to have a hundred chit-chats everyday if you run such a big project.

|improve this answer
  • Thank you @Pawel, I think the points you are mentioning contribute to the overall communication network to be established with your team members. Even though contributing, I think it does not help to fulfill clarification of properly communicated task assignment directly. – bonifaz Mar 19 '11 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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