Posts Tagged project management
well begun is half finished
college taught me many things. the difference in active and passive RFID tags, what 1080i and 1080p mean, the kinds of multiplexing different cell phones use, and the reasons why digital cable can never really be considered digital. but above all the forumlas, facts, history, and theories i learned, one lesson stands out above all else:
well begun is half finished.
my professor doctor jim janssen taught me that in my senior year in our final course. the lesson is simple — if you do the work that’s needed up front, you’ll have less problems the rest of the way. though the lessson may be simple, actually heeding its words can be quite difficult.
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