Posts Tagged project management
wiggle room
mythbusters ran a pirate episode once where they tried to see if you could escape from being burried to your neck in sand. as they found out, it’s impossible to escape from wet sand because as you move some sand away to clear space to move, more water and sand will fill up that space. it provides you with no wiggle room to free your limbs and your body from the sand.
perhaps the most important part of project management when creating schedules for work is the inclusion of wiggle room. there are issues that occur when working on projects — large or small. some of these issues are known, and some are unknown, and some are even known to be unknown in that you know the issue will occur, but not when or what impact it would have on the project. as much as we’d like to — the fact of the matter is that we cannot fully remove all risks and issues from a project. what we can do, however, is to study those risks and issues and minimize their effects. one of the best ways to do this is by scheduling wiggle room. Read the rest of this entry »
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