I work with a bunch of different teams… and I think my #1 issue I run into with people is the concept of expectation management. There are a few different definitions of what expectation management is, but here’s what it boils down to for me: Knowing what’s expected of you (deliverables), when it’s due, who needs it, how it affects them, and managing those relationships.
I’m a big fan of people setting their own deadlines. I always feel more comfortable when I can choose my own (I can add a bit of padding if I feel the need), and so I try to extend this to others whenever possible. I also believe that when people set their own deadlines they’re more likely to feel pressure to meet them. When I’m given an unreasonable deadline, the amount of effort I put into reaching it is usually pretty low. If I set myself an aggressive deadline, I’ll work like hell to make sure I hit it.
The deliverables of a project/task are naturally quite important. I find that a lot of people don’t ask enough questions to really understand what the other one wants. ”Well they told me what they want..,” you think. No! They told you what they thought they wanted. Pry deeper, make sure you know with confidence what they’re expecting at the end of this.
The what, and by when, are important. But what’s an order of magnitude more important is managing the relationship.
Are you ahead of schedule? Confident that you’ll get done sooner? Tell the person! You’ll make their day, and they might be able to change other delivery dates in response and get their bigger project done faster because you kicked ass.
On schedule? Tell the person! It’ll let the person know that the due date is still tenable and that they shouldn’t expect delays. They can adjust other tasks accordingly.
Feeling iffy about that deadline? Tell the person! Even if you’re not sure that you won’t hit it, a simple “Hey, things are taking a little longer than I expected because writing an html rendering engine in assembly turned out to be a little tougher than I anticipated.” Now they know that if they have some critical task they wanted to start up right afterwards, they might want to consider delaying it. They might say that only part of what you’re doing is a bottleneck, so maybe if you can focus on getting that part done in time, everything can go ahead as planned. If you bust your ass to hit your deadline, they’ll appreciate that you made up time; again you end up looking awesome, and all you had to do was hit your own deadline.
Blowing the deadline? Tell the person! You should really have told them at the “feeling iffy” stage, but hey, shit happens. Telling them before the deadline lets them readjust.
Seeing a pattern here? Communication. When I get nothing from a team member, I want to believe that everything is going peachy. When I see a deadline go by and I’ve not heard from the person and I don’t have a deliverable in my hand? It makes me think that they don’t value my time. At this point, I don’t care that an html renderer is hard to write in assembly. You’ve failed.
The frequency of updates depends on the project and its length. Use your best judgement for what’s an acceptable frequency. I like to go with weekly updates on a large project, personally. Usually in the form of an email that says what I’ve been up to, and where I’m heading next in the short term.
Nearly everything we do is a small part of a bigger goal. The cascading effect of a task getting derailed can sometimes have disastrous results, let alone when it gets compounded. Missing a deadline isn’t the end of the world if you’ve managed the other side’s expectations.
