Posted by
timothy
on from the don't-be-a-jerk dept.
TrippTDF writes "I just took a new job at a small software company as an assistant project manager. While I have a little management experience, none of it is related to software. What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had?"
Work Breakdown Structure
by
Godeke
·
· Score: 3, Informative
As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
Slashdot Mirror
As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
Sig under construction since 1998.