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?"
Use goals, not deadlines...
by
LostCluster
·
· Score: 3, Insightful
Programming is an activity based upon trial and error. As a result, it's very hard to predict how long writing any given piece of code is going to take. It's good to have a schedule of targets for the progress of a program, but you can't turn those target dates into deadlines without the risk that your programmers will rush through the task and deliver buggy code.
Re:Use goals, not deadlines...
by
shufler
·
· Score: 4, Insightful
In an ideal world, this is how all programming projects would operate.
However, we live in a world where deadlines are very real, very important beasts which will gladly destroy us if we ignore them.
Upper management, shareholders, customers, or whoever expects the product by a certain time, not because they are fucking inconsiderate pricks, but because without the program, they cannot do whatever it actually is, that they do.
What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had
Speaking as someone who has been on both sides:
Don't be a fake, your people will pick up on it.
Don't pick sides. You aren't there to make friends, you're there to get a job done.
Don't be afraid to say "I don't know" and defer to one of your people. It boosts their morale.
Ensure you can back up your decisions with facts and data. Bad decisions will cost you respect and potential promotions. They may even get you demoted or unemployed.
Don't talk shop with your people outside of work on a social level. Those that don't go out socially could perceive your decisions as biased. Ideally you'll minimize social interaction with small groups of your people.
You can't demand respect from your people, it must be earned.
A good manager should be though of as firm yet fair. Not a friend, not a drinkin' buddy, not someone easily influenced.
Basically: you're a Grown-Up now. Your options are quite simple: take the ball and run with it or fail and go back to where you were. Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...:)
Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...:)
38? Dude, you are old!
Re:My advice?
by
egarland
·
· Score: 3, Insightful
I agree with everything in the parent post. I'd add some more:
Remember, you're job is important. Doing it well will make everyone's lives easier.
Work hard but don't get buried. If you are too busy you can't do your job right.
You're a coordinator. Just like in a real-time device, things break if they get overloaded. Managers are often ridiculed for not doing real work but this is actually important. All my good bosses had free time in their day. All my bad ones have seemed overworked. It's ok to get involved in doing actual work but it's best to say away from the deep projects (ones that require a lot of time to wrap your head around and pick back up if you get interrupted) and remember to keep a little time in your day to sit around and just let whatever's going on stew in your mind. Part of a project manager's job is to see obstacles that will show up in the future. It's hard to do that when you are head down working.
-- set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Great list:) Here's a couple of skills and tasks I consider essential:
Know management: get yourself a good introductory book (not a 21 day guide to being an MBA). The areas you need to understand are general management, marketing (seriously!), and operations. Project management is part of the operations function. You need to understand basic management concepts like planning, leading, organizing and controlling.
Understand quality, productivity and risk: these are core operations concepts that managers need to grok. They afford the world view you need to do things right, and to do the right thing, so that what you actually deliver is valuable to the customer. Take a look at my essay, The Quality Gap.
Enhance communications: as a manager once of your functions is to facilitate. Do this by improving communications. Be a conduit for dialog, but also put people (inside and outside the team or company) in touch with each other, and encourage them to talk directly and to communicate this information back to you and to other team members.
Protect your team: another of your functions is to be an interface. You should be involved in all communication, and people shouldn't be communicating without your knowledge. As an interface you establish the lines of communication, and ensure you are getting feedback on them, and spreading that information where it needs to go. At the same time you need to protect your team from unreasonable demands from customers and from managers outside the team. Know when to step in and say "this is my team, hands off". Most programmers don't like dealing with "business people" -- they will appreciate your intervention.
Know how to plan: get the tools and knowledge to create and monitor a project schedule. All estimates must come from the technical persons who will actually do the work! Be sure to include time in the plan for planning (!), requirements documentation, design, implementation, testing, configuration management and packaging, customer acceptance test, and maintenance. Understand the dependencies! Never forget that all this time your team is likely to be taking support calls, asked to provide a quick estimate on some other project you're quoting on, fix a few bugs on other products, talking on Slashdot;) In my experience you can only count on about 6 hours of project work per day!
Delegate and defer: you don't have all the technical or management knowledge to do everything. Don't be afraid to delegate, to defer decisions, or to accept the advise of those above, beside and below you. Everyone has a wealth of personal knowledge and can contribute to any problem you are facing. Welcome their advise, even if you don't follow it -- they will appreciate it, and it can benefit you.
Insist on sign-off: requirements must be signed off. Changes to requirements must be signed off. Customer acceptance tests must be signed off. Sign-off is a basic risk management techique that protects the company, the team, and your butt.
-- i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Plan to debug, you'll have to anyway.
by
LostCluster
·
· Score: 4, Insightful
A good rule of thumb is that you should allocate the same length of time to debugging as writing the original code, because a program that works under pristine conditions might look finished to the untrained eye, but it isn't. Every possible "exception case" such as when the user gives an out-of-bounds valus needs to have a specific error trap written to handle the error before it crashes the program.
"I don't know" is not a crime.
by
Doc+Ruby
·
· Score: 2, Insightful
When you don't know the answer to a question, say "I don't know". Listen to the reaction of the questioner. If possible, provisionally accept any answer they give, provided it checks out, then check it out. Either yourself, or by assigning that task to someone. Always follow up as briefly as possible with confirmation or correction. Once you've been the conduit for an answer you learned, you should remember it, so you don't have to say "I don't know" again, when you should know after the first round.
If you do this well, you can say "I don't know" quite often, keeping your manager status and respect based on your validation and info distribution alone. Of course, you should also be learning the answers to questions, even anticipating the questions as much as possible. The key to keeping your dignity is not to pretend to know what you don't, and to enforce the scope on questions you're responsible for answering.
--
--
make install -not war
Learn how to say "No"
by
GoofyBoy
·
· Score: 4, Insightful
Actually, learn how to say "Go to hell and leave me and my programmers alone.".
Note: I'm not saying to not listen to your end-users/customers and understand them. Just don't become this mindless "Yes-man" and sacrifice your team.
-- The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Re:Learn how to say "No"
by
caseydk
·
· Score: 2, Interesting
My boss is doing exactly this right now.
Last week, one of the VP's was chewing my ass because some code that was moved into production 3 hours after its creation wasn't 100% correct. I stuck up for myself and said, "this is the very first initial version, it's not going to be perfect".
After the VP left, my boss assured me that the VP "is on our side". Oh, and he called me to come into work although I had Strepp throat.
Project Managers, support your people. You don't have to risk your jobs, but try to keep reason in the decision making process.
Re:Learn how to say "No"
by
j3110
·
· Score: 4, Insightful
Well... It's the managers job to be more tactful. Get the priorities of the end user and have them rank the issues in terms of importance. A lot of times, you'll find that the end user is just saying "Wouldn't it be cool?" instead of "I would be willing to go over budget and wait a week for that!" They tend to get irrate when you go over budget and pass deadlines, especially when it's because of something they requested. No one wants to hear "I didn't know it would cost me that much!".
The best thing to do is try to weed out the genuine concerns of the end user and present them to the dev team before making any estimates. Nothing angers a developer more than telling him that he has to stay up all night trying to meet an impossible deadline; and nothing angers an end user more than not having what they asked for for the price you give them or when you promised it. Always overestimate to the end user, and underestimate to the developers... it will all come out somewhere in the middle, and everyone will be happier. You won't have to slave drive your employees if something comes up (there is always something), and you won't have to apologize to the client.
When doing your job, a manager must maintain respect and integrity. If you aren't given enough freedom to do that, I would resign and go to development or look for another job. Don't let them corner you into failure quietly! Let them try to find someone else who thinks they can do the job.
-- Karma Clown
Re:Learn how to say "No"
by
dutky
·
· Score: 3, Insightful
Actually, learn how to say "Go to hell and leave me and my programmers alone.".
I'll second this, but it is only half the story: A good project manager has to be able to say "no" to everyone. You have to say "no" to unreasonable requests from clients/superiors in order to keep your team-member's plates clear to work on the important stuff. You also need to say "no" to your team-members when they either want to go off the reservation for whatever reason.
A good manager, of any kind, acts as a wall between their people and the rest of the organization. They take care of conflicts and keep the team from getting distracted. They get the team what it needs to do it's job, and keep everything else out as much as possible.
Read Slack and Peopleware by Tom DeMarco and Timothy Lister.
WardsWiki has some good stuff
by
DavidNWelton
·
· Score: 2, Informative
Communicate, and use good tools
by
revans
·
· Score: 4, Insightful
The Project Managers job is not to:
design the product
code the product
build the product
QA the product
release the product
sell the product
nor fix the product.
Your job is to try to get all the people who do these jobs to communicate with one another, and to try to be aware of and consider solutionS for ALL the issues involved with the product. To that extent you need good tools to make all the issues as plainly visible to all the constiuents as possible. Which leads to the question: what is the best toolset to do this?
A caution
by
McMuffin+Man
·
· Score: 2, Insightful
Asking employees what they want from their manager is something any good manager should do. But it is important to remember that what they're telling you is what it looks like from their side. Listen for what frustrates them more than for what they think you should do, because frequently it's as much about how you do something as what you do.
For example, my team was frequently frustrated by sudden changes of plans from their previous manager. When I was on the team, so was I. When I asked what I should do differently, "stick with the first plan" was a frequent answer. Once I was in the hot seat it became clear to me why we frequently had to make certain changes. Since I couldn't just stop the change, instead I started explaining to people why I was asking them to do things.
This frequently takes a lot of time, and frequently involves a lot of discussion while they go over the same ground that led me to the decision. They come with a reason to change my mind much less frequently than they probably would have supposed. The upshot of this, however, is that now they see why we need to make these decisions, they have a chance to change the decision when it was really as dumb as it looked at first glance, and so they feel a little less like it is something that is done to them by unreasoning powers.
The point here, again, is that I didn't change what I was doing all that much, but I changed how I was doing it a lot.
Can I work for you?
The thing that has frustrated me the most with managers is being given a decision without any of the logic behind it. I remember submitting proposals for things we should be doing that if they gave me a few weeks of time (and an insignificant amount of budget) I figured I could save our team serveral hours of work a week. I put in the proposal (well researched). They asked for some clarification and to add a few things. I did so. At the end they said no. I can handle a proposal being turned down, but tell me why! Giving me a better understanding of why my proposal was turned down will save me frustration and probably time the next time I do up a proposal. No matter what I did, I couldnt' get a reason for it. After that, I hardly proposed anything any more. Some ideas I just went ahead and did, others I just dropped as soon as I thought of them.
I know in the long run my productivity dropped as did my morale. Its was the major factor in me looking (and finding) a new position.
Re:A caution
by
bitingduck
·
· Score: 2, Insightful
that's a great point-- I even saw a similar thing in a presentation by Colin Powell that my boss a couple levels up had put on our section web site-- "Informed troops fight better"
Everyone involved in a project should have a picture of the overall goal of the project (who the end customer is and why they want it), as well as be given insight into why their boss is making the decisions they're making, and as much as possible some insight into why the boss's boss is making whatever decisions are going on at that level. Things that look silly or futile from down at the bottom can make a lot more sense in the context of the larger project, (or at least the bigger picture can expose that the silliness and futility are caused at a level beyond the project manager's control.)
Make a real effort to understand the projects you manage. Nothing is more frustrating than telling your manager what the project does, how it works, and what your role is, every single week. Not knowing all the details about feature a and b is ok, but at least know about feature a and b.
Have as few meetings as possible. Managers seem to love meetings, underlings hate them. I do recommend one-on-one meetings with all your direct reports, but don't make them weekly. That's just overkill. Once a month, or twice a month at the most.
Don't ask your employees what they need for a project and then veto it down. It will just kill morale. If you have a limited budget, tell the employees what the budget is and ask what they would like to use it for, they will have a better idea what things to pick. Also, don't ask your employees to spec out a system with features A, B, and C and after getting the recommendations, grill the employee why features A, B, and C are necissary. That's really blows:O
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.
Re:Work Breakdown Structure
by
Bill+Dog
·
· Score: 2, Insightful
Front loading the analysis usually uncovers many things that were ignored.
Which should include, depending on the developer's situation, time for interruptions, such as customers calling, and having to suddenly run off and put out a fire somewhere in already installed/was-supposed-to-be-working code. Also include time for mandatory corporate "training" that comes due every now and then, filling out forms/dealing with corporate bureaucracy for travel reimbursement et al. Also include any system downtime that frequently recurs, such as periods of not being able to get into email or connect to a resource, or where the connection is so ridiculously slow that you read a book in between mouse clicks (try vss over vpn cross-country!). So assign me 20 tasks Mon morn that I've estimated each at "a couple of hours", but despite MS Project showing everything adding up neatly, don't expect them all done by Fri evening.
Listening is probably the most important skill you can develop. You'll be bombarded on all sides: executives, programmers, sales people, marketing, etc. You're going to have to be able to listen to all of them and make decisions. Don't let any one group override and other particular group; you'll be tempted to let your programmers make all of the decisions, but remember that the reason you are there is to develop a product to sell for $$$.
Learn how to communicate effectively in both written and verbal forms. If you're seeing that the schedule is falling behind, don't wait until the last minute to alert the rest of the team to it. Put together a plan (we lost a lot of time because feature X was much more complex than we planned. We can either cut feature Y and hit our date, or add feature Y as planned on slip the date by a month) and present to the other decision makers in a concise fashion. Don't be argumentative...just logical.
Remember again that development does not take place in a vacuum; chances are your manager along with other executives made date and revenue commitments based on the development schedule. If it slips, or features change, they need to know ASAP. They have customers to sell to who need to know what's going to be in the product. They have marketing collateral and website updates that need to get in place. They have sales and tech support people that need to be trained. Your job is to make sure that all of these things can happen. The number 1 goal of any for-profit company is to make money. You need to give both your programmers and the other key stakeholders you work with the ability to do that.
-- It's "no one," not "noone." Who the hell is noone anyway?
What advice can you guys give me on not becoming a PHB?
It's hard to be a PHB without having hair. You'll still make stupid decisions, but you'll look cooler doing it.
A couple of things
by
rjshields
·
· Score: 2, Insightful
Admit it when you make a mistake or get things wrong, and learn to say sorry. People will find it easier to forgive you.
Remember that there's no "I" in team. Do what's best for the team at all times and never let things get personal.
Expect software projects to take longer than people initially think. Dilbert once said that to come up with a realistic estimate, you take your initial estimate and multiply it by eight. He has a point there.
I have worked with PMs who can do none of these things and it is no fun working with them at all (that's an understatement).
-- In this world nothing is certain but death, taxes and flawed car analogies.
Re:Project management 101
by
jeif1k
·
· Score: 3, Insightful
MS Project is your main tool - learn it - live it.
Maybe it's your main tool.
You'll eventually become an old hand at doing project estimates!
That's nice. But projects aren't about delivering estimates, they are about delivering products.
How I do it.
by
TomTraynor
·
· Score: 2, Insightful
If you use project management software (and it is a good idea to use it if you have it) I use the following metrics for % completed:
0 - Not started (obvious)
25 - Activity started
50 - Work in progress
80 - Ready for team review
90 - Team review done and ready for client review
100 - Completed and signoffs completed.
When holding meetings try to set a standard number of days in advance for a notice. Also set a short and simple agenda. One that I usually use has the following items:
Minutes from last meeting
Project Status update
Upcoming deliverables
Other
Executive summary report template for sending to the client and your bosses. Keep everyone up-to-date at a high level, they probably don't want the gory details.
My meetings usually lasted 15 to 30 minutes each week. If they are on time and no problems I don't want to hear the gory details, they can send me a note on that. The only thing I want to hear is if there is a problem and what they have done to solve it and if they need me to help. On the 'Other' I poll each team member to see if they have anything to contribute.
If the client has praise I make sure that the team and their bosses know this. If there are problems I don't make them public, but, I discuss privately with the person to see how we can resolve the issue. Never ever put a team member down in front of the others or publically criticize the member.
At the end of the project hold a team meeting to review the project and the lessons learned. I usually bring in munchies and drinks.
-- Panic now, beat the rush!
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.
What advice can you guys give me on not becoming a PHB?
Always wear a crucifix. It should keep you safe but if it were to somehow fail and you begin to turn, the smoke from your roasting flesh will be noticed by your subordinates. Assuming you've been good to them before your fall, they will drive a stake through your heart as an act of mercy.
--
"Prepare for the worst - hope for the best."
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
Starting PM
by
astrojetsonjr
·
· Score: 2, Interesting
Get Rapid Development: Taming Wild Software Schedules by Steve McConnell.
Read it cover to cover twice. (Most PM's will do step one but never read the book)
Find Top 10 Risk List in the Best Practices and do it.
Profit!
Start doing the other best practices in the book
More Profit!
The book is a great summary of information. Your primary job is a communications agent between everyone on the project, not as a coder, designer, etc.
While you may asked to plan, you'll need to get the estimates from people that have done this before. Use an estimation tool like SEAT to make estimates, not your gut feel.
A project tool like MS Project or LBM, etc. is really your friend. Learn it and use it. Next to e-mail and Powerpoint it is your most used tool.
Good luck!
Re:Project management 101
by
jeif1k
·
· Score: 2, Insightful
Also, MSProject is a reasonable product. It does get the job done. Even though it comes from the Evil Empire -it still is a decent tool.
I don't think MSProject (or its clones) gets the job done: it forces you to represent far too much detail and complexity far too early, and it will discourage you from exploring alternatives or making necessary changes.
I think good project planning, like good design in general, is still best accomplished with paper, pencils, index cards, and tape.
You are both a leader and a salesman
by
gristlebud
·
· Score: 3, Interesting
As a Project Manager, you are responsible for interfacing between your clients and the team that reports to you. You are the face of the company. Dress nicer. Tighten up the e-mail etiquette. Use capital letters, punctuation, and spell check. Every time. Always assume that someone will forward your emails to your team, your client, and your boss.
You are the leader of your project. You need to set an example for the attitude and morale of the teams that report to you. Always show up on time, and leave late. Never, never bitch about the customers or senior management. Never appear frazzled or irritated, as that attitude invariable trickles down to your team.
You are responsible for everything that happens on the project. Not just the technical execution of the work, but also the accounting, invoicing, reporting, vendors, and subcontractors. Follow up on everything, because if it doesn't happen, it's always your fault.
Always take opportunities to sell yourself and your company. Take every opportunity to call, or preferably visit your clients. I'm serious about this. Find out what your marketing budget is, and spend every nickel on visiting your clients. Eventually, they'll give you more work just to get rid of you. When dealing with a client, always keep your game face on. Know that you represent the best damn (whatever) company out there, and don't be afraid to take risks. Ask your clients often for more work. This can be a little uncomfortable, but rest assured that your competition is chasing the same work you are.
Expect excellence from your teams. If you don't know enough about the subjects to judge whether the people are producing what they should be, find a trusted advisor who does know, and get their opinion. After clearing it with senior management, quietly solicit some bids from other companies (even overseas companies) on a task-by-task basis to make sure that you are getting the most out of your teams. However, don't be an ogre. Find out the difference between regular, everyday complaining that technical people do all the time and the honest-to-gosh complaining that signals something's really wrong.
Limit senior management involvement. Always ask for help when you need it, but always propose a solution or a set of alternatives. You should try and schedule project reviews monthly or quarterly between senior management, QA, yourself and the task leads to make sure the project is on schedule and meeting performance objectives. Don't cc: half the damn company on every e-mail, and never when you chew someone's butt.
Try and grow scope whenever possible. This ties into face time with the customer, but also knowing what other services your company can provide, and also knowing the specific scope of your project, so that you know when the client requests are going out of bounds. When you do win more work, make sure everyone knows it. This will be one of the things that your boss will be evaluating your performance on.
Clients will always try and get more than what they are paying for, but limit the amount of freebies you give them, and ham it up a little when you give them one. ("You know, I could get fired for this, but since you're one of my best customers, I can make this happen.") Also, don't ever be afraid follow up on an invoice that is getting late. This might be a little embarrassing to the client, so this is probably best done over an e-mail.
As much as possible, define what your requirements are to the teams that report to you. Not just "I need XYZ done," but "I need XYZ done by 21 December. You have 64 hours to do it in, and use charge code ABC123.QQ." If the teams have problems delivering, find out whether it's a problem with your schedule, the team's resources, or if you have unreasonable production estimates.
Celebrate your teams' performance. Even if you're managing the project from hell, find something they're doing right, and send out a quick e-mail to your boss an
-- OK...
I can do this. I am, after all,
a superhero!
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.
Information
by
the_womble
·
· Score: 2, Insightful
Keep people informed, not jsut your management, but anyone on the project. When i had a job where I was basically a domiain expert, the biggest difference I noticed between the most experienced (and best) of the project managers I worked with and the least experienced was that the former kept me (and everyone else) in the loop. No surprises, especially no nasty surprises. Most importantly no problems with the client that I did not know about.
Slashdot Mirror
Programming is an activity based upon trial and error. As a result, it's very hard to predict how long writing any given piece of code is going to take. It's good to have a schedule of targets for the progress of a program, but you can't turn those target dates into deadlines without the risk that your programmers will rush through the task and deliver buggy code.
What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had
Speaking as someone who has been on both sides:
Don't be a fake, your people will pick up on it.
Don't pick sides. You aren't there to make friends, you're there to get a job done.
Don't be afraid to say "I don't know" and defer to one of your people. It boosts their morale.
Ensure you can back up your decisions with facts and data. Bad decisions will cost you respect and potential promotions. They may even get you demoted or unemployed.
Don't talk shop with your people outside of work on a social level. Those that don't go out socially could perceive your decisions as biased. Ideally you'll minimize social interaction with small groups of your people.
You can't demand respect from your people, it must be earned.
A good manager should be though of as firm yet fair. Not a friend, not a drinkin' buddy, not someone easily influenced.
:)
Basically: you're a Grown-Up now. Your options are quite simple: take the ball and run with it or fail and go back to where you were. Heh, I re-read that and I thought "Man, you sound old." and I'm only 38...
Trolling is a art,
A good rule of thumb is that you should allocate the same length of time to debugging as writing the original code, because a program that works under pristine conditions might look finished to the untrained eye, but it isn't. Every possible "exception case" such as when the user gives an out-of-bounds valus needs to have a specific error trap written to handle the error before it crashes the program.
When you don't know the answer to a question, say "I don't know". Listen to the reaction of the questioner. If possible, provisionally accept any answer they give, provided it checks out, then check it out. Either yourself, or by assigning that task to someone. Always follow up as briefly as possible with confirmation or correction. Once you've been the conduit for an answer you learned, you should remember it, so you don't have to say "I don't know" again, when you should know after the first round.
If you do this well, you can say "I don't know" quite often, keeping your manager status and respect based on your validation and info distribution alone. Of course, you should also be learning the answers to questions, even anticipating the questions as much as possible. The key to keeping your dignity is not to pretend to know what you don't, and to enforce the scope on questions you're responsible for answering.
--
make install -not war
Actually, learn how to say "Go to hell and leave me and my programmers alone.".
Note: I'm not saying to not listen to your end-users/customers and understand them. Just don't become this mindless "Yes-man" and sacrifice your team.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Have a look here:
http://c2.com/cgi/wiki?ProjectManagement
http://www.welton.it/davidw/
- design the product
- code the product
- build the product
- QA the product
- release the product
- sell the product
- nor fix the product.
Your job is to try to get all the people who do these jobs to communicate with one another, and to try to be aware of and consider solutionS for ALL the issues involved with the product.To that extent you need good tools to make all the issues as plainly visible to all the constiuents as possible. Which leads to the question: what is the best toolset to do this?
Asking employees what they want from their manager is something any good manager should do. But it is important to remember that what they're telling you is what it looks like from their side. Listen for what frustrates them more than for what they think you should do, because frequently it's as much about how you do something as what you do.
For example, my team was frequently frustrated by sudden changes of plans from their previous manager. When I was on the team, so was I. When I asked what I should do differently, "stick with the first plan" was a frequent answer. Once I was in the hot seat it became clear to me why we frequently had to make certain changes. Since I couldn't just stop the change, instead I started explaining to people why I was asking them to do things.
This frequently takes a lot of time, and frequently involves a lot of discussion while they go over the same ground that led me to the decision. They come with a reason to change my mind much less frequently than they probably would have supposed. The upshot of this, however, is that now they see why we need to make these decisions, they have a chance to change the decision when it was really as dumb as it looked at first glance, and so they feel a little less like it is something that is done to them by unreasoning powers.
The point here, again, is that I didn't change what I was doing all that much, but I changed how I was doing it a lot.
Make a real effort to understand the projects you manage. Nothing is more frustrating than telling your manager what the project does, how it works, and what your role is, every single week. Not knowing all the details about feature a and b is ok, but at least know about feature a and b.
:O
Have as few meetings as possible. Managers seem to love meetings, underlings hate them. I do recommend one-on-one meetings with all your direct reports, but don't make them weekly. That's just overkill. Once a month, or twice a month at the most.
Don't ask your employees what they need for a project and then veto it down. It will just kill morale. If you have a limited budget, tell the employees what the budget is and ask what they would like to use it for, they will have a better idea what things to pick. Also, don't ask your employees to spec out a system with features A, B, and C and after getting the recommendations, grill the employee why features A, B, and C are necissary. That's really blows
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.
Listening is probably the most important skill you can develop. You'll be bombarded on all sides: executives, programmers, sales people, marketing, etc. You're going to have to be able to listen to all of them and make decisions. Don't let any one group override and other particular group; you'll be tempted to let your programmers make all of the decisions, but remember that the reason you are there is to develop a product to sell for $$$.
Learn how to communicate effectively in both written and verbal forms. If you're seeing that the schedule is falling behind, don't wait until the last minute to alert the rest of the team to it. Put together a plan (we lost a lot of time because feature X was much more complex than we planned. We can either cut feature Y and hit our date, or add feature Y as planned on slip the date by a month) and present to the other decision makers in a concise fashion. Don't be argumentative...just logical.
Remember again that development does not take place in a vacuum; chances are your manager along with other executives made date and revenue commitments based on the development schedule. If it slips, or features change, they need to know ASAP. They have customers to sell to who need to know what's going to be in the product. They have marketing collateral and website updates that need to get in place. They have sales and tech support people that need to be trained. Your job is to make sure that all of these things can happen. The number 1 goal of any for-profit company is to make money. You need to give both your programmers and the other key stakeholders you work with the ability to do that.
It's "no one," not "noone." Who the hell is noone anyway?
What advice can you guys give me on not becoming a PHB?
It's hard to be a PHB without having hair. You'll still make stupid decisions, but you'll look cooler doing it.
Admit it when you make a mistake or get things wrong, and learn to say sorry. People will find it easier to forgive you.
Remember that there's no "I" in team. Do what's best for the team at all times and never let things get personal.
Expect software projects to take longer than people initially think. Dilbert once said that to come up with a realistic estimate, you take your initial estimate and multiply it by eight. He has a point there.
I have worked with PMs who can do none of these things and it is no fun working with them at all (that's an understatement).
In this world nothing is certain but death, taxes and flawed car analogies.
MS Project is your main tool - learn it - live it.
Maybe it's your main tool.
You'll eventually become an old hand at doing project estimates!
That's nice. But projects aren't about delivering estimates, they are about delivering products.
0 - Not started (obvious)
25 - Activity started
50 - Work in progress
80 - Ready for team review
90 - Team review done and ready for client review
100 - Completed and signoffs completed.
When holding meetings try to set a standard number of days in advance for a notice. Also set a short and simple agenda. One that I usually use has the following items:
Minutes from last meeting
Project Status update
Upcoming deliverables
Other
Executive summary report template for sending to the client and your bosses. Keep everyone up-to-date at a high level, they probably don't want the gory details.
My meetings usually lasted 15 to 30 minutes each week. If they are on time and no problems I don't want to hear the gory details, they can send me a note on that. The only thing I want to hear is if there is a problem and what they have done to solve it and if they need me to help. On the 'Other' I poll each team member to see if they have anything to contribute.
If the client has praise I make sure that the team and their bosses know this. If there are problems I don't make them public, but, I discuss privately with the person to see how we can resolve the issue. Never ever put a team member down in front of the others or publically criticize the member.
At the end of the project hold a team meeting to review the project and the lessons learned. I usually bring in munchies and drinks.
Panic now, beat the rush!
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.
Always wear a crucifix. It should keep you safe but if it were to somehow fail and you begin to turn, the smoke from your roasting flesh will be noticed by your subordinates. Assuming you've been good to them before your fall, they will drive a stake through your heart as an act of mercy.
"Prepare for the worst - hope for the best."
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
The book is a great summary of information. Your primary job is a communications agent between everyone on the project, not as a coder, designer, etc.
While you may asked to plan, you'll need to get the estimates from people that have done this before. Use an estimation tool like SEAT to make estimates, not your gut feel.
A project tool like MS Project or LBM, etc. is really your friend. Learn it and use it. Next to e-mail and Powerpoint it is your most used tool.
Good luck!
Also, MSProject is a reasonable product. It does get the job done. Even though it comes from the Evil Empire -it still is a decent tool.
I don't think MSProject (or its clones) gets the job done: it forces you to represent far too much detail and complexity far too early, and it will discourage you from exploring alternatives or making necessary changes.
I think good project planning, like good design in general, is still best accomplished with paper, pencils, index cards, and tape.
As a Project Manager, you are responsible for interfacing between your clients and the team that reports to you. You are the face of the company. Dress nicer. Tighten up the e-mail etiquette. Use capital letters, punctuation, and spell check. Every time. Always assume that someone will forward your emails to your team, your client, and your boss.
You are the leader of your project. You need to set an example for the attitude and morale of the teams that report to you. Always show up on time, and leave late. Never, never bitch about the customers or senior management. Never appear frazzled or irritated, as that attitude invariable trickles down to your team.
You are responsible for everything that happens on the project. Not just the technical execution of the work, but also the accounting, invoicing, reporting, vendors, and subcontractors. Follow up on everything, because if it doesn't happen, it's always your fault.
Always take opportunities to sell yourself and your company. Take every opportunity to call, or preferably visit your clients. I'm serious about this. Find out what your marketing budget is, and spend every nickel on visiting your clients. Eventually, they'll give you more work just to get rid of you. When dealing with a client, always keep your game face on. Know that you represent the best damn (whatever) company out there, and don't be afraid to take risks. Ask your clients often for more work. This can be a little uncomfortable, but rest assured that your competition is chasing the same work you are.
Expect excellence from your teams. If you don't know enough about the subjects to judge whether the people are producing what they should be, find a trusted advisor who does know, and get their opinion. After clearing it with senior management, quietly solicit some bids from other companies (even overseas companies) on a task-by-task basis to make sure that you are getting the most out of your teams. However, don't be an ogre. Find out the difference between regular, everyday complaining that technical people do all the time and the honest-to-gosh complaining that signals something's really wrong.
Limit senior management involvement. Always ask for help when you need it, but always propose a solution or a set of alternatives. You should try and schedule project reviews monthly or quarterly between senior management, QA, yourself and the task leads to make sure the project is on schedule and meeting performance objectives. Don't cc: half the damn company on every e-mail, and never when you chew someone's butt.
Try and grow scope whenever possible. This ties into face time with the customer, but also knowing what other services your company can provide, and also knowing the specific scope of your project, so that you know when the client requests are going out of bounds. When you do win more work, make sure everyone knows it. This will be one of the things that your boss will be evaluating your performance on.
Clients will always try and get more than what they are paying for, but limit the amount of freebies you give them, and ham it up a little when you give them one. ("You know, I could get fired for this, but since you're one of my best customers, I can make this happen.") Also, don't ever be afraid follow up on an invoice that is getting late. This might be a little embarrassing to the client, so this is probably best done over an e-mail.
As much as possible, define what your requirements are to the teams that report to you. Not just "I need XYZ done," but "I need XYZ done by 21 December. You have 64 hours to do it in, and use charge code ABC123.QQ." If the teams have problems delivering, find out whether it's a problem with your schedule, the team's resources, or if you have unreasonable production estimates.
Celebrate your teams' performance. Even if you're managing the project from hell, find something they're doing right, and send out a quick e-mail to your boss an
OK...
I can do this. I am, after all,
a superhero!
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.
Keep people informed, not jsut your management, but anyone on the project. When i had a job where I was basically a domiain expert, the biggest difference I noticed between the most experienced (and best) of the project managers I worked with and the least experienced was that the former kept me (and everyone else) in the loop. No surprises, especially no nasty surprises. Most importantly no problems with the client that I did not know about.