Archive for April 11th, 2008
define what you’re doing before you do it
from the time we’re little, we’re taught 2 lessons:
- respect your elders
- because i told you so
that first lesson can more appropriately mean, “respect those people with more authority than you” and the second as “because you’re not in a position to oppose this.” so many people grow up — go through school, life, and everything — and adhere to those rules. they enable people to lead, not because they themselves can’t lead, but because they we’re always told to follow.
so what’s all this have to do with anything? bottom line: if you tell someone to do something, chances are they’ll do it — if they know how to or not.
as a team leader, project manager, small work manager — whatever your title is — you hold power to tell people to do things that they feel they’re not allowed to challenge. even if you say, “let me know if you have any issues” people generally won’t because that’s both, (a) an admission of a lack of competence, and (b) a waste of time because even if they had a problem, they always ask themselves “would my bringing this up really change the situation?”
when we create project documents to outline the scope, goals, etc. it is vitally important that we define exactly what needs to happen before telling someone to do it.
it sounds completely stupid because it’s rather common sense, but you’d be surprised how many people don’t do it. project documents need to be descriptive, easily understood, and all goals — both functional and technical — ought to be clearly marked out. scope documents (or sections about the scope inside an overall project plan document) are not 10th grade word problems. all the requirements for work should be expressly stated.
recent comments