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?"
98 comments
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.
For the sake of humanity, don't pull a DNF.
Re:Use goals, not deadlines...
by
Slime-dogg
·
· Score: 1
Try to stay ahead of the people's needs, and predict what they will find useful in the future. My department has done this successfully. I would have to say that my boss lets me have quite a bit of autonomy, and I produce good stuff for him. Very few items have real deadlines, and those things are usually menial tasks like scanning & editing & converting things, or programming projects for less responsive and less responsibile organizations.
Provide the required amount of support, but always keep an eye out for what is holding people back. Try to get it written and tested before people ask for it. If they don't ask for it, give a demo and show why it's useful. This will increase their efficiency for one, and also will lessen the likelihood of them requesting something else. Rinse, repeat.
Another good tip is to develop very generic tools that you can mold into many things. A good example is our reporting system. I wrote it so that it is very non-specific, and works with our database very well. It just happens to integrate well into every other web application that we have, so we run all of our reports through it now. There is no more need for Crystal or any other extra crap like that.
Lastly, it's wise to understand that a manager's job revolves around organization and communication. Don't hoodwink yourself into thinking that you'll have time to do coding. Also, don't try to stick your finger into your underlings' code, or dictate to them how they should program. This only causes distress and anger on their part, and only wastes time on your part. If your programmers can't do the work without you, go hire someone that is more qualified to replace them. Firing people is one of the hardest things to do, but it's a necessity.
-- You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Re:Use goals, not deadlines...
by
legirons
·
· Score: 1
"it's very hard to predict how long writing any given piece of code is going to take"
Not true. You just need to learn how to estimate. The best method is to simply repeat your question as often as needed, in a more urgent tone of voice. Do this enough, and you'll be able to precisely estimate any project, no matter how vague or how far in the future, long before the customers have decided what the project will consist of.
Sometimes this method gives you bad estimates, which you'll be able to spot, because it'll always be 8 months. "How long will it take to write x?" 8 months. "How long to write a project plan?" 8 months. "Make me a cup of coffee?" 8 months.
The problem there is that you're asking a person who might know something. The solution is to ask someone else, preferably with no knowledge of the systems involved.
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...:)
All great points. One additional point, reflected from current experience:
Respect people's time. Understand that people have other priorities and that they can't be spending all their time working on yours. Obviously this varies with each project.
- B
--
"I either want less corruption, or more chance
to participate in it." -- Ashleigh Brilliant
Re:My advice?
by
Anonymous Coward
·
· Score: 0
And at the same time you'd realize how much I was joking, bro. No hard feelings.
You may find this funny: I too am in my 30s.
peace.
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
I agreee with a lot of this. I've never been a manager, but I've been under the best manager I could ever imagine for the past 11 months... that comes to an end next week due to a buyout and me transfering departments... joy.
Anyway, I agree with all of these points except for the "not a friend, not a drinkin' buddy". I've become great friends with my manager, and it hasn't hurt our professional relationship in the least. It motivates me that much more to do a good job, because I know that my work reflects on him. He also does an excellent job protecting me from other evils around the office.
As far as the "don't talk shop with your people outside of work" might be a good rule for larger groups, but doesn't seem like a problem for my situation. All of our group hangs out with one another at some point... so this might be something to look at on a case by case basis.
Respect is huge, and it can only be earned... but I think friendship at least to some extent can be a huge plus as well.
-- I farted
Re:My advice?
by
Anonymous Coward
·
· Score: 0
Oh yeah, there's always exceptions. My point was that in a larger group there will always be those who have other interests socially and won't participate in extracurricular activities. It'd be easy to have them labelled as "not team players" as they label the others as "ass kissers" etc.
I work in a place with a great social atmosphere (I'm on the Social Committee in fact). We have something called TGIF after work every Friday in our library where anyone from lab monkey to DG can gather to chit chat about what they're working on, etc. What you don't see are all those same people going out to party together after. There's a definate line there.
I see your point. I think it's also probably important for me to note that I do work for a company that is only about 4-5 years old, and it had a slight dot com atmosphere. We didn't have the chairs and all that, but we do have a ping pong table and some arcade games, along with free snacks and beverages. When we had a good quarter the whole office would be invited to go out to a place like a Dave and Busters and have some food and drink on the companies tab. I wasn't even 21 when I started here, but I still went out and enjoyed the festivities. Having something like that every few months, with smaller events in between really kept all of us happy and made us a better team (IMHO). But it is all very circumstantial.
Pay attention to what people are actually producing and how it's advancing the project-- some of your best workers will quietly go about doing a great job, and often go unrecognized as a result. People who pull off heroic efforts to recover from near distaster often get rewarded even when the disaster was essentially of their own making. The people who plan well and do things on time and correctly prevent disasters, too, but they do it so well that nobody even notices. Make sure they know that their work is valued and rewarded.
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
Re:My advice?
by
Anonymous Coward
·
· Score: 0
Dude? I guess 38 would sound old to a 13 year old. Duuuuude!
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
Re:"I don't know" is not a crime.
by
dprust
·
· Score: 1
I agree; people who can't say "I don't know" are not management material. The kind of people that can't say "I don't know" are usually the programmers, in my experience, who all too often put way too much weight on what they know and not enough (or any) on whether they can work well in a community, which is far more important. There's nothing I hate more than a analytical personality putting others down for asking questions or misunderstanding something. That is the worst possible quality to have in management as well.
Re:"I don't know" is not a crime.
by
forkazoo
·
· Score: 1
My daddy always used to say:
"I don't know," is never a good answer, but it is often the right answer.
Time and time again, I've seen management make weird ass technical decisions which every techinical person disagreed with. It's a bad thing. If the majority of your programmers say that Ruby is the right language for teh job, they may be right. Sometimes you do have to steam-roll over people with legit ideas in order to get anything done, but don't do it arbitrarily, just because you have the power to.
As a little example, we did a team-building thing today at work. I have been with the company for two weeks, and I had one of the biggest bosses on my team. I wound up getting the instructions, so I started reading what we had to do, and coordinating. Some bosses would have started by taking the paper and running everything themselves. Instead, everybody just went with the flow, and because there weren't any squabbles about who got to write down the answers, we won. Also, I now have a deeper respect for the boss, because I know that he is more concerned with getting the job done, than being in charge.
Re:"I don't know" is not a crime.
by
Bill+Dog
·
· Score: 1
My daddy always used to say:
"I don't know," is never a good answer, but it is often the right answer.
Reminds me of my asm instructor in college -- on exams he would actually subtract points for wrong answers (and do nothing on questions left blank). He told us guessing is a bad habit to get into, and he didn't want anyone writing, say, auto-pilot software, just guessing when they weren't really sure.
-- Attention zealots and haters: 00100 00100
Re:"I don't know" is not a crime.
by
bitingduck
·
· Score: 1
Sometimes you do have to steam-roll over people with legit ideas in order to get anything done, but don't do it arbitrarily, just because you have the power to
In my experience it's better not to steamroll, but to actually get the relevant people together (everyone affected by the decision) and be very explicit about the fact that you don't know whether it's the best decision (and that it probably isn't), but that some decision has to be made in order for the project to move forward, and there isn't enough information to make a better decision. Ideally you then document that decision in a design file, along with notes about alternatives, and as much as possible (but without making things so general that it drives the cost up) continue in such a way that you can revisit the decision later and possibly make a different choice without having to redo too much work.
The situations where this seems to happen is when the problem is underdetermined, and you need to select a couple of the free parameters and make them public to the team so that everything is self-consistent, even if it's not optimal everywhere. At some point you figure out enough to make a better decision and can then go back and propagate the change without too much pain.
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.
Especially as your customers (internal and external) will notice really soon that you are a Yes-man (if they are not completely braindead, but in that respect most of them aren't) and you will be that "Yeah, he always promises the sky but never delivers" guy everyone really hates and that finally noone even belives the time of day from.
What everyone wants is to get the job done, but no empty promises you cannot live up to.
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.
Re:Learn how to say "No"
by
gristlebud
·
· Score: 1
Saying no is a lousy thing for any project manager to say, and is one of the traits that would get them fired from any successful company. Project managers should be acutely aware that their competition is never saying "No" to your customers. A project manager's proper response is: "Sure no problem, but..." For example:
Employee wants time off: "Sure, but either get your work done or find someone to cover for you."
Client wants you to do something that your company doesn't do: "Sure but I'll have to get back with you." Find a subcontractor to do it, and add 10% to their price.
Client wants work done Christmas day: "Sure, no problem, but I'll have to charge double-time and a half." Then find a non-christian who will do it for straight-time.
Workers threaten to walk off when you tell them that they need to work overtime: "Sure, no problem." Solicit bids from India for their job, and "accidently" leave them in the break room.
-- OK...
I can do this. I am, after all,
a superhero!
Re:Learn how to say "No"
by
Tim+Browse
·
· Score: 1
I think you misread the submission - it says "What advice can you guys give me on not becoming a PHB?" (my emphasis)
Re:Learn how to say "No"
by
gristlebud
·
· Score: 1
Understood. No-one wants to be a dick, especially someone who just came up from the trenches. Double-especially if you happen to now be supervising the people you've been working with. Every tech person in the world has all kinds of good ideas about how to run projects, but very few get the opportunity to demonstrate it. Kudos to you for wanting to maintain yourself as a "B" while not becoming a "PHB".
However, being a manager is hard. Whereas a tech person is required to go to work, do a competent job, and meet schedules, a manager is required to:
Go to work
Make sure that the people that are working for him are doing a competent job and meeting their schedule.
Make sure the client is happy with the product and schedule.
Make sure the client has paid their bills.
Deal with your workers problems, both personal and professional. Make sure those problems don't impact the project.
Handle changes in scope and schedule from the client such that your workers won't mutiny, and the client won't get pissed off and go the competition.
Work with sales so that the workers have something else to do once the current project ends.
The point of my post, although perhaps poorly worded, was to demonstrate that you need to be able to put a positive spin on the challenges that are going to face you. If you remain a manager, at some point, you will have to make a decision:
Do you want to be unpopular because you asked your people to do something difficult, or do you want to be unpopular because you told a client "No", and now you have to lay people off because the client took the work to a competitor?
-- OK...
I can do this. I am, after all,
a superhero!
Re:Learn how to say "No"
by
BlizzyMadden
·
· Score: 1
Also, consult your programmers to see if something is possible before just telling the customers "sure, we can do that". I've had to make a hack job program to "trick" our main product into doing something it was not meant to do because of this. As you can imagine, it's no fun supporting crapware like this that I was embarrassed to make in the first place.
most 'managers' are people managers, not resource managers (esp not human resources!).
Project managers do that - they act as the interface between the 'project' and the people doing the project. They are different to people managers, but still require people manager skills..
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?
Re:Communicate, and use good tools
by
Anonymous Coward
·
· Score: 0
Isn't that was software is for? Perhaps we could outsource middle managers to India and do all of that coordination by email at the very least. It'd save a LOT of money.
Every feature, milestone, or anything else the "customer" asks for should be written down on a 3x5 card, along with a time estimate for/just that task/. Anytime the client wants to change something, or add a feature, it has to be written down on a 3x5 card, along with a time estimate your team (not you) provides. This helps the client understand what scope creep is. Any new task takes X hours to complete, and thus obviously delays the project past the original completion date by that same amount. Indoctrinate your programmers to ignore "can you also make it" requests from the client. If it's not given to you on a 3x5 card, then it's not part of the project. If it delays the project to add that feature, then the client has to agree to the new delayed end date.
You're there to insulate the programming team from the customer interruptions, not to advocate the customer's cause. Quality comes first, deadlines last. If the customer wants to meet a deadline, then they have to decide what features to leave out.
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.)
Go to Business School if you want to succeed
by
Anonymous Coward
·
· Score: 0
Management is not a new thing someone learns from reading/. It takes time and experience.
Business School will give you the foundation to excel.
Re:Go to Business School if you want to succeed
by
desertfish
·
· Score: 1
Only require what you really require
by
BornInASmallTown
·
· Score: 1
When you give a requirement (for a piece of functionality, for a coworker, for a supplier,...) make sure that what you ask for is what you really want.
For example, - Don't require team members to work 8am to 5pm each day. Instead require what you really want: that they execute on their part of the project within the specified timeframe and allocated resources. For some team members, this will necessesitate that they work during the so called "normal business hours", but for others, it won't - Don't require code to be written in [pick your favorite language] simply because it is open source, free, and wonderful. Instead, require what you really want: that code is written in a language that maximizes productivity and maintainability and enables the team to complete the project on time and on budget.
MS Project is your main tool - learn it - live it.
As someone else mentioned, your main purpose is to be the glue that hold the various groups working on a project together. This is done through meetings, and schedules.
You need to communicate, and clear up other's mis-communications. Keep asking questions - get the people to explain to you why something is going wrong. You'll eventually become an old hand at doing project estimates!
-- Have you compiled your kernel today??
Re:Project management 101
by
AndroidCat
·
· Score: 1
Any equivalents in OSS?
-- One line blog. I hear that they're called Twitters now.
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.
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.
Well - many people have to do project time estimates to when the contract.
You are right about the job being - deliver the product, but if you don't have the contract in the first place, you're on the bread line!
So - my point to the guy was that he needs to ask questions to learn HOW the work is done. This makes him better at his job in the future - and less of a pain to the people he has to bug all the time to get their progress reports!
Also- like it or not - MSProject is the standard schedule package in use with maybe 99.99% of the market share. I don't like that there isn't a good alternative (at least MrProject isn't up to snuff yet... need to look at GanttProject mentioned above..) You also need to use whatever the rest of the company uses - the project manager RARELY gets to pick the tools.
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.
For goodness sake - That should be "WIN" the project.
-- Have you compiled your kernel today??
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.
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.
Make sure that the estimates include time for clarifying requirements and for the various forms of testing. I've worked with developers who will leave that out thinking that developing and coding are the same thing.
The other thing to do is follow up and make sure that the estimates are being met. Once they begin to slip reanalyze the estimates and give your customer a heads up.
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.
-- Attention zealots and haters: 00100 00100
Re:Work Breakdown Structure
by
Godeke
·
· Score: 1
I'll take it that your work situation isn't very good. If you are being assigned to work at 100% workload you have a poor project manager. Actual working time varies from company to company: we have very few meetings, but we have overhead like anyone else and therefore don't expect 40 hours of assigned work to be completed in 40 working hours.
Unless someone is totally unaware of reality, they should be using the "Working Time" defaults in the scheduling software to exclude meetings and other known overhead. Then for each employee the "Resource Availability" should be set to whatever percentage is reasonable for your environment (which sounds pretty low in your environment: a sign of structural disfunction, not scheduling per-se). Once you do that, if the scheduled hours from the team is reasonable, the schedule will be reasonable. Reasonable doesn't mean perfect, but the goal is for your team to be able to have an average completion time that is within the ballpark of the estimates. Likewise, the amount of working time vs overhead is checked to ensure that extra overhead isn't creeping into the system. That's about all you can do (other than feedback loops on the estimates) to ensure a reasonable schedule.
Regarding "was-supposed-to-be-working" code, we charge those incidents back to the original developer of that change (good CVS commit logs and the schedule make it pretty clear who owned a change). Our estimates include development *and* testing time, which throws a lot of programmers at first because they think they can just toss something together and throw it over the wall. It doesn't take long for the time estimates to start assimilating that requirement though: the programmer will consistently underperform estimates that were made, and after a couple of weeks we will come to a new agreement on estimates. The person who has to make the emergency fix obviously isn't penalized for such an emergency, but more than one in a blue moon of that nature is another sign of a disfunctional organizational system... the owner of repeated emergency repair inducing code won't be with us long unless *that* changes. (Test driven development really helps stop much of that in its tracks).
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?
Remember all of your Bad Bosses
by
rueger
·
· Score: 1
Treat people with respect and listen to what they have to say. Being a bully or demanding 60 hour work weeks is not productive and results in a bad product.
If you haven't done so take some courses in Conflict Resolution techniques or Interest Based Problem solving.
Relish your role as the middle man - your role is twofold:
When the staff need to protect themselves from some unreasonable demand they can refer it to you. They can then rely on you to carry their concerns upstairs in a neutral fashion.
Likewise you are the person to take management's sometimes incomprehensible demands and presents them to staff in a way that they understand and endorse.
Also, planning is good, lots of planning is even better. Before the work starts you should have sketched out the near exact results that the company wants in the product.
Probably no-one in the company know how to do that kind of planning work. Hire a facilitator who does something along the lines of Open Space group faciltiation for a day or two and let them guide you through refining your project and developing a realistic and measurable plan.
All of these people managing and planning skills are specialties, but they can be learned. Some up front money in training or outside help can save you a lot of grief down the road.
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.
You don't say your sorry, that wouldn't be good. People don't forgive their co workers and project leaders if they say they are sorry. But they do forgive project leaders if they do own up to their mistakes.
Right or wrong, you make decisions that affect and direct the entire team. The best way to do that is through accountability.
If you make a wrong decision, its YOUR fault. Its not the teams fault or its not a specific team members fault.
if as a whole, the team makes a wrong decision, its not THEIR mistake, but OUR mistake.
If the team as a whole does a great job, its OUR project, not MY project.
-- I follow the SDK and GDN principles..
Spelling Dont Kount, Grammer Dont Neither
You don't say your sorry, that wouldn't be good. People don't forgive their co workers and project leaders if they say they are sorry. But they do forgive project leaders if they do own up to their mistakes.
You wouldn't say sorry if you screwed up a project? Maybe this is a cultural difference, but I find that people will generally forgive you more easily if you aplogise. Apologising in itself is paramount to admitting responsibility.
I would agree that it's very important to be able to own up to one's mistakes. Some people seem to find it hard to do this and perhaps see it as a sign of weakness. These people will probably find it harder to win people's trust and forgiveness.
-- In this world nothing is certain but death, taxes and flawed car analogies.
I disagree, there is certainly an "I" in team, and there will be as long as the team has a human being in it.
The important thing to do as a manager, is to be aware of all the different "I"'s throughout the team and to keep them well fed. Then the "I" doesn't get in the way.
Also, be prepared to leave the project and move on to new ones. Software development always needs new talent and new brooms and that means developing the programmers to set up new projects and help you manage them, and bringing in new talent from your competitors and school.
Don't force a formal approach at all times. The programmers need to play with code, then offer what they've discovered as new sub-projects - you can't plan development without some toy code to start from. Also plan for refactoring and debugging.
Documentation should be finalised *after* the code is finished (which means not quite ever finalised), and specifications should be changed whenever thinko's are encountered during coding, and all users of an altered spec should be notified. users of a spec must not be permitted to work around a bug or thinko - the spec should be changed if it causes problems for other code. Adaptors should be written to support old code that *ought* to remain using the old spec ("ought" is decided on a case by case basis).
You need to identify the tools to automate as much of this as possible because communication is broken by people and politics - get the technology in there doing this stuff for you - that means you need a project admin to run the support systems.
Kicking a dead whale down the beach
by
peter+hoffman
·
· Score: 1, Insightful
Don't expect people to do what they volunteered to do or have been asked/told to do. If you don't keep checking on them they will begin to screw off.
The biggest mistake I made when starting out was to assume everyone was as interested in the success of the project as I was. Many times you will be the only person interested in the success of the project. Not even your boss or customers will be really interested. I have found this to be true on dozens of projects.
It's a fine line between keeping people moving forward and being overbearing but you have to find it.
Talk to everyone in your team, every day. It will give you a far better idea of how things are going than progress reports and formal meetings ever will. The conversation doesn't have to be about the project, complain about the weather, whatever.
Believe time estimates, if you start trying to trim them to meet artificial dates your team will start multiplying the number they first thought of by a fudge factor and you still won't meet the date.
Nobody outside the team gets to talk to people inside without clearing it with you every single time. You're the manager, you have to know everything that is happening with the project, and you're the one who knows if the team member can spare the time to be disturbed.
The point about outside the team gets to talk to people inside without clearing it with you every single time is an excellent one, but I'd be careful about being quite so strict. Talk to your team and get them to understand that the main thing is to never make commitments to people outside of the team without clearing it with you.
Beware the senior manager or exec who goes straight to developers and asks "how long do you think X will take"!
Surround yourself with the best people you can hire, beg, borrow, or steal. Your team should include a few "old hands" who have been through a number of projects before. Listen to what your people say, try to get them what they need, and try to insulate them from extraneous demands on their time.
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.
"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)
10 - At least one person available to work on the project
20 - Have some sort of requirements
50 - All software has been written
75 - Software has been tested and shipped
90 - Customer is using the product, isn't moaning as much anymore
100 - Customers have stopped phoning you with annoying questions
Yes, I agree with this list. In software development the customer will always find bugs that didn't show at your testings, and he will almost always have some additional feature/change requests. So when you've shipped to the customer the first time you've still got a long way to go. That way won't produce as much code as before but it will take longer to produce it. By this I mean it's quite fast to write an application but after a certain size it can take up to a few days just to locate and fix a single bug (if the system is very complicated).
By the way, as a hint to (future) managers: if you notice a developer is hunting a bug for hours and doesn't find it, talk to him and let him explain how this bug manifests and discuss with him what could cause this. Or if you don't know enough about programming, get that developer to explain and discuss with another developer. Quite often the first developer then gets to see the missing piece (or the other does, which is as good):-)
I had just this situation yesterday: I was hunting a bug for about three hours. Then my boss came along and saw my frustration. I explained this bug and discussed for about three or four minutes with him and then suddenly I got enlightenment and fixed that bug within a minute:-)
> Never ever put a team member down in front of the others or publically criticize the member.
I just quit a job where I was constantly criticised in private and then the higher bosses were told how great I was in front of me, often within the space of a few minutes. This was extremely discomforting (especially since I was usually criticised for doing precisely what I was asked to do - or for not pointing out a problem when I had previously been glared at for pointing out future problems - even in meetings when asked to raise issues).
To the OP asking for management advice:
If you have criticised your staff, don't make yourself look like a nice manager to your bosses in front of him/her, since it makes you look like a cheating, slimey son-of-a-bitch. Remember that glares and body language are the same as words - or more powerful. You can't hide them, so remember what you felt at the time, and stay consistent with that.
Don't ever pretend that you are being nice to somebody because of the words you used even though they know you hate their guts because of your body language - it is despiriting and depressing. So if you can't be happy with somebody despite an error don't be a manager, because your body language will be clear, then your words will tell them you are a liar.
Though my perception could currently be influenced by the treatment I have recently received from an idiot boss with a string of unkept jobs who barely understood the job he was originally taken on to do, let alone software development.
I never pretend if I don't like someone. I try my best to keep my feelings to myself and work as a professional with the person. When I have a problem I try to work with the person privately on what the problem is and what we can do.
At the end of the project where I am the team lead I must do an evaluation on each team member and that is a bitch of a job. My last project took me a day to do for the six members of my team.
I suggest that you have a look at Extreme Programming (read the book, not someone's web site!), which contains several useful ideas for sw of good quality on a predictable timetable. Although personally I found the more notorious features such as pair programming to be worthwhile, you will probably want to avoid these at first. This is ok - you don't have to adopt the whole thing.
One useful idea is the concept of "project velocity": get your team to estimate the time for activities in ideal days, i.e. without interruptions, meetings, etc. Measure how long it actually takes, and use this ratio for planning purposes. BTW, if you do this, don't communicate the original estimates upwards without renaming them to something like "work units".
If possible, work with the customer to break down the work into "stories". These are roughly the same level as a use case - a self-contained feature of the system, small enough to be completed in a few days by a couple of programmers. Then on a weekly basis decide with your customer which stories will be implemented next, and develop the sw in such a way that you always have something executable, even though it is incomplete. Again, this helps with a predictable timeline, and it also helps politially by letting your customer see the progress. Not always possible though - easier to do if your customer is internal.
Something that I try to do is to document my instructions. I find it surprisingly easy to forget the detail of what I've told someone to do so that things get missed out and only come to light when they are reporting back. Being explicit in an email also makes sure that I actually understand the task myself. I then make sure that I re-read the email before checking progress.
BTW, in programming you're used to getting something perfect. You may worry that you don't do this when you are managing. This is almost inevitable, but remember that you only have to be better than the opposition, not perfect.
Good luck!
take anti-depressants
by
fred+fleenblat
·
· Score: 0, Flamebait
...if you want to piss off your underlings.
Like everyone else, I've had to put up with a couple of real hardcore asinine bosses over the years. They were annoying, but after a while you get used to their rants and having to explain things to then three times before it sinks in. It's okay, I can deal with that.
The ones I can't stand are managers on ant-depressants. They are just ass-kissing zombies who do not accept any feedback from anyone except their supervisor. It's like they're toddlers again and they hate everyone but they love themself and their "mommy" figure, usually their immediate supervisor. If their supervisor is insecure and has a preference for yes-men there is just a total blockage of information transfer up the management chain and all pointful work ceases.
I know that some people really need AD's to get through life, nothing wrong with that, but these people should not be in the chain of command at a tech company where complex decisions that balance competing interests need to be made.
Just my opinion.
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.
Never hurts to educate yourself with some techie business books. I like Crossing the Chasm by Geoffrey A. Moore, especially the way he talks about the "whole product" customer proposition. The Innovator's Dilemma by Clayton M. Christensen was also a fun read, though it's not directly related to your problem per se.
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
Learn to treat your staff as equals
by
Anonymous Coward
·
· Score: 1, Insightful
Managing programmers and other well trained specialists is not like managing unskilled workers. Don't try to order them around; just, direct their expertise towards your business needs.
Unlike an unskilled worker, a specialist is valuable because of his special knowledge and skills. He knows more about his area of expertise than you do, by definition. Don't try to tell him how to do his job. Instead, tell him what needs doing: let him figure out how. That's exactly what he's trained to figure out.
Your role, as manager, should be to ensure that your programmer has all the resources he needs; hardware, software, and most importantly, accurate information. Otherwise, you may end up with the perfect solution to a problem you don't actually have, and no solution for the problems you do.
Be aware that programming is closer to R&D than to manufacturing. It's the art and science of specifying, in very precise way, exactly what your business requirements are, in terms simple enough for a machine to understand.
So, always be as precise as you can. Remember, programmers can only create what you ask for, not some idea hiding in your head.
Respect your people. Learn as much as you can about what they do, can do, and can't do. Specialists spend their lives learning things in an attempt to do useful work; you'll get along better if you at least try, too.
Try not to do your expert's job for them. Don't tell your IT specialist: "I need a database" when you really just want a report. Ask for what you really want.
Understand that staring at a screen, trying to make a system work can be very frustrating. Be patient.
Programmers have to be precise, like an accountant, and at the same time, creative, like an author. They have to write code that is fast, efficient, and at the same time as clear and understandable as possible. They balance a lot of intangibles on a daily basis, with little or no external recognition. They're often under a lot of stress.
Think of an author who has to finish a book by a given deadline. Now, add in the requirement that all the punctuation in his hand-typed novel must be perfect, or the book will not be published, and you've got about the right level of stress for a programmer a week before a serious deadline.
So, to sum up, respect your people, stay out of their way, give them the resources they need, and understand the stress you're putting them under.
Oh, and don't be evil. Everyone hates evil people.:-)
-- AC
Learn from others' mistakes (and successes)
by
qaseqase
·
· Score: 1
Project management is about managing the trade-offs among finite resources (time, people, money) to reach some defined goals in the context of an organization. Yes, you need (1) good skills in working with people and (2) domain-specific skills (IT operations, development, etc). In addition you need to develop specific skills and knowledge in project management.
The project management profession has grown out of the experiece of failures and successes across many industries, organizations, and types of projects. Learn from those who have figured out what works and what is likely to go wrong. The Project Management Institute http://www.pmi.org/ has a lot of good reasources, and PMI certification would probably be worthwhile for you if you wish to pursue project management as a career focus. Learn the PMBOK - project management body of knowledge -- as well as the latest ideas specific to software projects.
Project management is cross-disciplinary, so a generalist is often more valuable than a specialist. Plan to keep reading and learning across all the relevant disciplines.
Agreed on socializing aspects
by
Ars-Fartsica
·
· Score: 1
I agree that one must keep some social distance. You may be forced to crack down on team members at some point or disappoint them in some manner, and its going to be much harder to do if you are drinking buddies.
It pains me to say it, but polite but distant seems to be the safest mask to wear in the office.
I'm going to provide the same management advise I once gave to a relative. This may have already been said in this thread but I'll give it a go.
1. A manager's job doesn't involve "Knowing" anything; it involves knowing who knows it and connecting them to the people with the questions.
2. A manager doesn't solve or identify problems; a manager brings what could be problems to the people with the knowledge to solve them,
and then LISTENS to their advice before making a decision.
3. A manager is not an employee's friend, confidant or buddy, but their boss. So, no matter how much you may personally like the person,
if they work like jack shit fire them.
Just my 2 cents,
p.s. I seriously doubt I had much influence, but the relative in question went from a "team lead" position to manager of half a multinational's account base in 5 years.
-- "Secrecy is the keystone of all tyranny. Not force, but secrecy... [sic] censorship.
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.
Get Rapid Development: Taming Wild Software Schedules by Steve McConnell
And when you've read that, get Software Project Survival Guide by the same author and read it once - a year.
--
My opinion? See above.
Re: Do Yourself a Favor and Keep Consultants Out
by
was_ms_now_linux
·
· Score: 1
Keep the consultants out - and stick to those who are primarily techie service providers. The job of the consultant is to stir stuff up and replace you and your team with one firendly to their company.
As a manager, you are going to be responsible for coordinating the activities of developers, business people, testers, and system administrators. You're first rule is: I don't know nothing about nothing.
Your experts are going to be your business people, developers, testers, and sysadmins. Listen to what they have to say. Don't poo-poo anybody because they are not good communicators.
Once you have mastered the art of listening and understanding what people want and need, then you get to start trying to wrestle them to get on the same page. But you can't do that unless you listen first.
-- The radical sect of Islam would either see you dead or "reverted" to Islam.
you bastard
by
Anonymous Coward
·
· Score: 0
You soon or later will sell off to the dark side, once you see you have office hours and full package and bonuses, with no accountability whatsoever, then you will do whatever is requiered to keep your status quo even if that means kicking out a guy that puts your ignorance on the spot light, all this throwing the company name to hell, wait a minute this happened to HP with Carly Fiorini.
Damn that I've seen this hypocrisy going over and over.
25 - Not started (getting it listed is half the work half the time)
30 - Activity started
35 - Work in progress
40 - Ready for team review
55 - Team review done and ready for client review
85 - Completed and signoffs completed.
And that last 85% optimistically assumes that the client had a clue what they required and the team had a clue how to deliver those requirements. In way too many projects, either installation or initial use blows enough holes in the fantasy that it becomes best to regard it as having been a prototype.
-- --
Our systemic servants do not good masters make.
I actually have separate entries for team reviews, client reviews and signoffs. I try to keep each line to a specific task. Makes for a large Work Breakdown structure, but, you see at a glance who the bottleneck is for a project. For a simple one person project I usually have about 150+ items. Top line items are for project management. Followed by Pre-Analysis tasks, then Analysis, Design, Development, Testing, with Implementation being the last.
-- Panic now, beat the rush!
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!
You will deal with smart people
by
Anonymous Coward
·
· Score: 0
Programmers are usually smart people, and they don't bend easily. I recommend you read an essay by Paul Graham about managing geniuses.
You haven't said if it is a small or large team. Since you are an assistant, I'll assume it is a large team.
Do: Make a small schedule and identify the milestones. "Socialize" the milestones. Find out if there are any objections to the milestone! Dig! Identify and remove objections: If someone is late or can't do something, find out why. Dig, cross reference. Remove the objection. If the objector objects too much, flag the person. Have no opinion on anything: you are pure communication. You don't know about software. You don't have to, but you must understand what you are building and how one thing depends on another, or you are worthless. Listen to the people at the very bottom of the trench that others build on, and at the fringes that manage other people's stuff.
Dont: let management make you responsible for the schedule. You are just a reporter. Let people slide. hold them accountable. Talk about "Teams". No one is here for your idea of social engineering.
Never: Take the "group" to play. You can't make people under the gun work together better by taking them to the park, or playing games, or anything like that. If you experience root problems, deal with them, and don't pretend that feel good things will make engineers feel good. It will make your mediocre engineers feel good and your good ones angry because there is too much work to do.
--
Ed Barbar, President and General Manager, Furnit USA
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.
I got linked to this site from/. some time, and I've since read a lot of the articles. There are lots of good ideas in here for making productive development teams.
http://www.joelonsoftware.com/index.html/
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.
First Time Project Management
by
realsablewing
·
· Score: 1
I ended up doing project management for the first time a couple of years ago and I've picked up some items that can help.
Study up on your people skills. I know a couple of people who don't have a strong technical background but they have great people skills. They also seem to do the best job. Look for project management classes in your area for more info on this topic.
Don't be afraid to cut scope or features. Sure, the users would like the upper right corner to turn pink when they hover over it on even days and blue on odd days but is it required for the software to function? Or a developer has come up with a great idea to improve the software, it would involve just a simple fix, really, just a complete rewrite of the system, which would break all backwards compatability, no big deal. Don't be afraid to say no, by limiting scope, you can stay witin budget, schedule and quality guidelines, mostly.
Set firm dates for feature completion and code completion in order to meet schedule. Yeah, it would be great to add just one more item in after the feature complete date, but there is almost always some impact in other parts of the system that will push other items out for completion. Don't fall prey to tempation.
To keep on budget, keep any eye on hours spent on solving different parts of the problem. Remember the developer saying it would only take 2 days to finish up that item and it's now 2 weeks later and he still only needs a couple of days? You may still have lots of time left, but those hours could've been spent on getting something else done that would now be complete.
These are just some highlights. Check out some good Project Management books, like Project Planning, Scheduling & Control, by James P. Lewis, very good, practical book that does a good walkthrough of project management concepts.
Good luck, you'll need it!
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,
... that should be a good start.
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.
most 'managers' are people managers, not resource managers (esp not human resources!).
Project managers do that - they act as the interface between the 'project' and the people doing the project. They are different to people managers, but still require people manager skills..
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?
Read up on team/extreme programming.
/just that task/. Anytime the client wants to change something, or add a feature, it has to be written down on a 3x5 card, along with a time estimate your team (not you) provides. This helps the client understand what scope creep is. Any new task takes X hours to complete, and thus obviously delays the project past the original completion date by that same amount. Indoctrinate your programmers to ignore "can you also make it" requests from the client. If it's not given to you on a 3x5 card, then it's not part of the project. If it delays the project to add that feature, then the client has to agree to the new delayed end date.
Every feature, milestone, or anything else the "customer" asks for should be written down on a 3x5 card, along with a time estimate for
You're there to insulate the programming team from the customer interruptions, not to advocate the customer's cause. Quality comes first, deadlines last. If the customer wants to meet a deadline, then they have to decide what features to leave out.
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.
Management is not a new thing someone learns from reading /. It takes time and experience.
Business School will give you the foundation to excel.
When you give a requirement (for a piece of functionality, for a coworker, for a supplier, ...) make sure that what you ask for is what you really want.
For example,
- Don't require team members to work 8am to 5pm each day. Instead require what you really want: that they execute on their part of the project within the specified timeframe and allocated resources. For some team members, this will necessesitate that they work during the so called "normal business hours", but for others, it won't
- Don't require code to be written in [pick your favorite language] simply because it is open source, free, and wonderful. Instead, require what you really want: that code is written in a language that maximizes productivity and maintainability and enables the team to complete the project on time and on budget.
MS Project is your main tool - learn it - live it.
As someone else mentioned, your main purpose is to be the glue that hold the various groups working on a project together. This is done through meetings, and schedules.
You need to communicate, and clear up other's mis-communications. Keep asking questions - get the people to explain to you why something is going wrong. You'll eventually become an old hand at doing project estimates!
Have you compiled your kernel today??
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?
Treat people with respect and listen to what they have to say. Being a bully or demanding 60 hour work weeks is not productive and results in a bad product.
If you haven't done so take some courses in Conflict Resolution techniques or Interest Based Problem solving.
Relish your role as the middle man - your role is twofold:
When the staff need to protect themselves from some unreasonable demand they can refer it to you. They can then rely on you to carry their concerns upstairs in a neutral fashion.
Likewise you are the person to take management's sometimes incomprehensible demands and presents them to staff in a way that they understand and endorse.
Also, planning is good, lots of planning is even better. Before the work starts you should have sketched out the near exact results that the company wants in the product.
Probably no-one in the company know how to do that kind of planning work. Hire a facilitator who does something along the lines of Open Space group faciltiation for a day or two and let them guide you through refining your project and developing a realistic and measurable plan.
All of these people managing and planning skills are specialties, but they can be learned. Some up front money in training or outside help can save you a lot of grief down the road.
Three Squirrels
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.
Don't expect people to do what they volunteered to do or have been asked/told to do. If you don't keep checking on them they will begin to screw off.
The biggest mistake I made when starting out was to assume everyone was as interested in the success of the project as I was. Many times you will be the only person interested in the success of the project. Not even your boss or customers will be really interested. I have found this to be true on dozens of projects.
It's a fine line between keeping people moving forward and being overbearing but you have to find it.
Surround yourself with the best people you can hire, beg, borrow, or steal. Your team should include a few "old hands" who have been through a number of projects before. Listen to what your people say, try to get them what they need, and try to insulate them from extraneous demands on their time.
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!
One useful idea is the concept of "project velocity": get your team to estimate the time for activities in ideal days, i.e. without interruptions, meetings, etc. Measure how long it actually takes, and use this ratio for planning purposes. BTW, if you do this, don't communicate the original estimates upwards without renaming them to something like "work units".
If possible, work with the customer to break down the work into "stories". These are roughly the same level as a use case - a self-contained feature of the system, small enough to be completed in a few days by a couple of programmers. Then on a weekly basis decide with your customer which stories will be implemented next, and develop the sw in such a way that you always have something executable, even though it is incomplete. Again, this helps with a predictable timeline, and it also helps politially by letting your customer see the progress. Not always possible though - easier to do if your customer is internal.
Something that I try to do is to document my instructions. I find it surprisingly easy to forget the detail of what I've told someone to do so that things get missed out and only come to light when they are reporting back. Being explicit in an email also makes sure that I actually understand the task myself. I then make sure that I re-read the email before checking progress.
BTW, in programming you're used to getting something perfect. You may worry that you don't do this when you are managing. This is almost inevitable, but remember that you only have to be better than the opposition, not perfect.
Good luck!
...if you want to piss off your underlings.
Like everyone else, I've had to put up with a couple of real hardcore asinine bosses over the years. They were annoying, but after a while you get used to their rants and having to explain things to then three times before it sinks in. It's okay, I can deal with that.
The ones I can't stand are managers on ant-depressants. They are just ass-kissing zombies who do not accept any feedback from anyone except their supervisor. It's like they're toddlers again and they hate everyone but they love themself and their "mommy" figure, usually their immediate supervisor. If their supervisor is insecure and has a preference for yes-men there is just a total blockage of information transfer up the management chain and all pointful work ceases.
I know that some people really need AD's to get through life, nothing wrong with that, but these people should not be in the chain of command at a tech company where complex decisions that balance competing interests need to be made.
Just my opinion.
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.
Never hurts to educate yourself with some techie business books. I like Crossing the Chasm by Geoffrey A. Moore, especially the way he talks about the "whole product" customer proposition. The Innovator's Dilemma by Clayton M. Christensen was also a fun read, though it's not directly related to your problem per se.
EricYou mean you don't want to become a Psycho Hose Beast?
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
Managing programmers and other well trained specialists is not like managing unskilled workers. Don't try to order them around; just, direct their expertise towards your business needs.
:-)
Unlike an unskilled worker, a specialist is valuable because of his special knowledge and skills. He knows more about his area of expertise than you do, by definition. Don't try to tell him how to do his job. Instead, tell him what needs doing: let him figure out how. That's exactly what he's trained to figure out.
Your role, as manager, should be to ensure that your programmer has all the resources he needs; hardware, software, and most importantly, accurate information. Otherwise, you may end up with the perfect solution to a problem you don't actually have, and no solution for the problems you do.
Be aware that programming is closer to R&D than to manufacturing. It's the art and science of specifying, in very precise way, exactly what your business requirements are, in terms simple enough for a machine to understand.
So, always be as precise as you can. Remember, programmers can only create what you ask for, not some idea hiding in your head.
Respect your people. Learn as much as you can about what they do, can do, and can't do. Specialists spend their lives learning things in an attempt to do useful work; you'll get along better if you at least try, too.
Try not to do your expert's job for them. Don't tell your IT specialist: "I need a database" when you really just want a report. Ask for what you really want.
Understand that staring at a screen, trying to make a system work can be very frustrating. Be patient.
Programmers have to be precise, like an accountant, and at the same time, creative, like an author. They have to write code that is fast, efficient, and at the same time as clear and understandable as possible. They balance a lot of intangibles on a daily basis, with little or no external recognition. They're often under a lot of stress.
Think of an author who has to finish a book by a given deadline. Now, add in the requirement that all the punctuation in his hand-typed novel must be perfect, or the book will not be published, and you've got about the right level of stress for a programmer a week before a serious deadline.
So, to sum up, respect your people, stay out of their way, give them the resources they need, and understand the stress you're putting them under.
Oh, and don't be evil. Everyone hates evil people.
--
AC
The project management profession has grown out of the experiece of failures and successes across many industries, organizations, and types of projects. Learn from those who have figured out what works and what is likely to go wrong. The Project Management Institute http://www.pmi.org/ has a lot of good reasources, and PMI certification would probably be worthwhile for you if you wish to pursue project management as a career focus. Learn the PMBOK - project management body of knowledge -- as well as the latest ideas specific to software projects.
Project management is cross-disciplinary, so a generalist is often more valuable than a specialist. Plan to keep reading and learning across all the relevant disciplines.
It pains me to say it, but polite but distant seems to be the safest mask to wear in the office.
I'm going to provide the same management advise I once gave to a relative. This may have already been said in this thread but I'll give it a go.
1. A manager's job doesn't involve "Knowing" anything; it involves knowing who knows it and connecting them to the people with the questions.
2. A manager doesn't solve or identify problems; a manager brings what could be problems to the people with the knowledge to solve them,
and then LISTENS to their advice before making a decision.
3. A manager is not an employee's friend, confidant or buddy, but their boss. So, no matter how much you may personally like the person,
if they work like jack shit fire them.
Just my 2 cents,
p.s. I seriously doubt I had much influence, but the relative in question went from a "team lead" position to manager of half a multinational's account base in 5 years.
"Secrecy is the keystone of all tyranny. Not force, but secrecy
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!
Keep the consultants out - and stick to those who are primarily techie service providers. The job of the consultant is to stir stuff up and replace you and your team with one firendly to their company.
http://www.softwareobjectz.com
As a manager, you are going to be responsible for coordinating the activities of developers, business people, testers, and system administrators. You're first rule is: I don't know nothing about nothing.
Your experts are going to be your business people, developers, testers, and sysadmins. Listen to what they have to say. Don't poo-poo anybody because they are not good communicators.
Once you have mastered the art of listening and understanding what people want and need, then you get to start trying to wrestle them to get on the same page. But you can't do that unless you listen first.
The radical sect of Islam would either see you dead or "reverted" to Islam.
You soon or later will sell off to the dark side, once you see you have office hours and full package and bonuses, with no accountability whatsoever, then you will do whatever is requiered to keep your status quo even if that means kicking out a guy that puts your ignorance on the spot light, all this throwing the company name to hell, wait a minute this happened to HP with Carly Fiorini.
Damn that I've seen this hypocrisy going over and over.
- 25 - Not started (getting it listed is half the work half the time)
- 30 - Activity started
- 35 - Work in progress
- 40 - Ready for team review
- 55 - Team review done and ready for client review
- 85 - Completed and signoffs completed.
And that last 85% optimistically assumes that the client had a clue what they required and the team had a clue how to deliver those requirements. In way too many projects, either installation or initial use blows enough holes in the fantasy that it becomes best to regard it as having been a prototype.-- Our systemic servants do not good masters make.
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!
Programmers are usually smart people, and they don't bend easily. I recommend you read an essay by Paul Graham about managing geniuses.
http://www.paulgraham.com/gh.html
Vilmos
You haven't said if it is a small or large team. Since you are an assistant, I'll assume it is a large team.
Do:
Make a small schedule and identify the milestones.
"Socialize" the milestones.
Find out if there are any objections to the milestone! Dig!
Identify and remove objections: If someone is late or can't do something, find out why. Dig, cross reference. Remove the objection. If the objector objects too much, flag the person.
Have no opinion on anything: you are pure communication.
You don't know about software. You don't have to, but you must understand what you are building and how one thing depends on another, or you are worthless.
Listen to the people at the very bottom of the trench that others build on, and at the fringes that manage other people's stuff.
Dont:
let management make you responsible for the schedule. You are just a reporter.
Let people slide. hold them accountable.
Talk about "Teams". No one is here for your idea of social engineering.
Never:
Take the "group" to play. You can't make people under the gun work together better by taking them to the park, or playing games, or anything like that. If you experience root problems, deal with them, and don't pretend that feel good things will make engineers feel good. It will make your mediocre engineers feel good and your good ones angry because there is too much work to do.
Ed Barbar, President and General Manager, Furnit USA
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.
I got linked to this site from /. some time, and I've since read a lot of the articles. There are lots of good ideas in here for making productive development teams.
http://www.joelonsoftware.com/index.html/
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.
- Study up on your people skills. I know a couple of people who don't have a strong technical background but they have great people skills. They also seem to do the best job. Look for project management classes in your area for more info on this topic.
- Don't be afraid to cut scope or features. Sure, the users would like the upper right corner to turn pink when they hover over it on even days and blue on odd days but is it required for the software to function? Or a developer has come up with a great idea to improve the software, it would involve just a simple fix, really, just a complete rewrite of the system, which would break all backwards compatability, no big deal. Don't be afraid to say no, by limiting scope, you can stay witin budget, schedule and quality guidelines, mostly.
- Set firm dates for feature completion and code completion in order to meet schedule. Yeah, it would be great to add just one more item in after the feature complete date, but there is almost always some impact in other parts of the system that will push other items out for completion. Don't fall prey to tempation.
- To keep on budget, keep any eye on hours spent on solving different parts of the problem. Remember the developer saying it would only take 2 days to finish up that item and it's now 2 weeks later and he still only needs a couple of days? You may still have lots of time left, but those hours could've been spent on getting something else done that would now be complete.
These are just some highlights. Check out some good Project Management books, like Project Planning, Scheduling & Control, by James P. Lewis, very good, practical book that does a good walkthrough of project management concepts. Good luck, you'll need it!I used to be an adult but then I grew up.