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.
-- Sig under construction since 1998.
Required reading, Some thoughts
by
emiddlec
·
· Score: 2, Informative
Understand the unique challenges that come with developing software. For instance, developers are by nature generally optimistic about technology, since they are in the business of finding creative ways to make the impossible possible. Listen to them carefully: if they're getting ground down, the project is probably in danger.
Understand the relationship between Quality, Schedule, and Cost. The developers must have control over at least one of these, otherwise the project is probably a guaranteed failure.
Understand that estimates can be off by as much as 100% at the beginning of a project, and only become more accurate over time. Use a unit of measure for estimates that reflects the reliability of the estimate, for instance "Quarters" for estimates that are circulated early to other parts of the company (even if the real schedule is in weeks.) Since estimates generally become more accurate over time, make sure your developers are allowed to update the schedule, and add or remove tasks.
Understand that most software projects are "Death Marches", where at least one major element of the effort is off by a factor of two. (ex: Features, Schedule, and Cost are all dictated to the developers.) These are virtually guaranteed to take longer than scheduled, and lower morale.
Re:Project management 101
by
chochos
·
· Score: 2, Informative
GanttProject is nice. It's written in Java, so it's especially useful if you're not only using Windows. Works on Linux, works on OSX. It's the one I use. Of course it doesn't have all the features that MS Project does, but it's pretty useful for making initial drafts or working with relatively simple projects.
There's also MrProject for Linux, I don't know if there's a binary for Windows. I compiled this on Linux once and it was nice but it broke pgAdmin, I think it was some version incompatibility with GTK or something.
There are some other similar tools here. Open Workbench Is supposed to be really good, although I haven't tried it. iTeamWork is another free tool.
Project Management Institute for sure
by
LinuxWeenie
·
· Score: 2, Informative
You might as a matter of course want to go over to http://www.pmi.org (Project Management Institute) and look into joining. That is the definative place to learn about project management itself. Suggest you think about joining and possibly signing up with PMI (there are likely to be local chapters around whom you can interact with).
There is also a little book published by the American Society of Mechanical Engineers called "The Unwritten Laws of Engineering" by W.J. King (ISBN 0-7918-0641-3). It has a lot of common sense stuff about being the boss and getting along with your boss.
--LW
Solve the Problems of the Developers
by
angel'o'sphere
·
· Score: 2, Informative
As project manager you have 3 prime goals:
Problem solving: figure what is the biggest obstacle preventing your team from making progress, remove that obstacle
Staffing: figure who is he best guy for a job, hire the best people available with your budget, prefer one less or a few people less if needed in favour for better quallified staff
Environment: keep optimizing tools and process! If a goal was not reached, why? Why? WHY? What can we do next time to prevent the same mistake? Different approach? Different tool? Different Process? For that you need to get a clue about "what does a software developer do in his dayly work?" You do not need to understand HOW he does his work, but WHAT and WHY... e.g. he uses a version control system. Why does he do that, what is your benefit? Why is it a deep shit when the server running the version control software is down (Thats a BIG Problem -> solve it -> fix the server or get a new one)
The last thing, Environment, is the most complex. E.g. while I suggest to allways have the BEST tools available, you won't go shopping on your first day and buy a set of 25 different new tools, because then the developers will learn/play the tools instead of developing.
To become a good project manager, you finally only have two choices: shift your career towards medium sized teams, 20 to 30 developers or towards big projects with over 50 to some hundret developers.
If you focus on small and medium sized teames, you have no chance. YOU MUST LEARN SOFTWARE DEVELOPMENT BASICS. You will allways be to close to the matter. A team of _good_ developpers, below 20 developers, simply does not need a project manager. If you want to feel respected and you want to provide value to the team, you need to dig into their work.
OTOH, if you focus on bigger teams you will likely be farer away from developement and the first two points above, problem solving and staffing, basicaly all resource plannings, are more important.
Finally, read something about SCRUM. (google for it) A modern project development approach mainly used in software development. A so called agile process and managment approach.
Regardless where you work, SCRUM will revolutionize your habits.
angel'o'sphere
-- Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Slashdot Mirror
Have a look here:
http://c2.com/cgi/wiki?ProjectManagement
http://www.welton.it/davidw/
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.
Required reading?
The Mythical Man-Month
Dynamics of Software Development
Death March
Understand the unique challenges that come with developing software. For instance, developers are by nature generally optimistic about technology, since they are in the business of finding creative ways to make the impossible possible. Listen to them carefully: if they're getting ground down, the project is probably in danger.
Understand the relationship between Quality, Schedule, and Cost. The developers must have control over at least one of these, otherwise the project is probably a guaranteed failure.
Understand that estimates can be off by as much as 100% at the beginning of a project, and only become more accurate over time. Use a unit of measure for estimates that reflects the reliability of the estimate, for instance "Quarters" for estimates that are circulated early to other parts of the company (even if the real schedule is in weeks.) Since estimates generally become more accurate over time, make sure your developers are allowed to update the schedule, and add or remove tasks.
Understand that most software projects are "Death Marches", where at least one major element of the effort is off by a factor of two. (ex: Features, Schedule, and Cost are all dictated to the developers.) These are virtually guaranteed to take longer than scheduled, and lower morale.
There's also MrProject for Linux, I don't know if there's a binary for Windows. I compiled this on Linux once and it was nice but it broke pgAdmin, I think it was some version incompatibility with GTK or something.
There are some other similar tools here. Open Workbench Is supposed to be really good, although I haven't tried it. iTeamWork is another free tool.
And finally, this is a list of some more tools.
Go hug some trees.
You might as a matter of course want to go over to http://www.pmi.org (Project Management Institute) and look into joining. That is the definative place to learn about project management itself. Suggest you think about joining and possibly signing up with PMI (there are likely to be local chapters around whom you can interact with). There is also a little book published by the American Society of Mechanical Engineers called "The Unwritten Laws of Engineering" by W.J. King (ISBN 0-7918-0641-3). It has a lot of common sense stuff about being the boss and getting along with your boss. --LW
As project manager you have 3 prime goals:
... e.g. he uses a version control system. Why does he do that, what is your benefit? Why is it a deep shit when the server running the version control software is down (Thats a BIG Problem -> solve it -> fix the server or get a new one)
Problem solving: figure what is the biggest obstacle preventing your team from making progress, remove that obstacle
Staffing: figure who is he best guy for a job, hire the best people available with your budget, prefer one less or a few people less if needed in favour for better quallified staff
Environment: keep optimizing tools and process! If a goal was not reached, why? Why? WHY? What can we do next time to prevent the same mistake? Different approach? Different tool? Different Process? For that you need to get a clue about "what does a software developer do in his dayly work?" You do not need to understand HOW he does his work, but WHAT and WHY
The last thing, Environment, is the most complex. E.g. while I suggest to allways have the BEST tools available, you won't go shopping on your first day and buy a set of 25 different new tools, because then the developers will learn/play the tools instead of developing.
To become a good project manager, you finally only have two choices: shift your career towards medium sized teams, 20 to 30 developers or towards big projects with over 50 to some hundret developers.
If you focus on small and medium sized teames, you have no chance. YOU MUST LEARN SOFTWARE DEVELOPMENT BASICS. You will allways be to close to the matter. A team of _good_ developpers, below 20 developers, simply does not need a project manager. If you want to feel respected and you want to provide value to the team, you need to dig into their work.
OTOH, if you focus on bigger teams you will likely be farer away from developement and the first two points above, problem solving and staffing, basicaly all resource plannings, are more important.
Finally, read something about SCRUM. (google for it) A modern project development approach mainly used in software development. A so called agile process and managment approach.
Regardless where you work, SCRUM will revolutionize your habits.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.