What advice can you give to someone who is going to assume a role of software development project manager for the first time?
Please list up to 7 things in order of importance and focus on quality and relevance of every piece of advice, rather than overall quantity of tips given. Less than 7 is perfectly OK.
Get some training. If you've no Project Management experience you could learn a lot in terms of techniques from a basic course.
Do some reading. There are lots of good books out there which will help you. Peopleware, How to Win Friends and Influence People and The Mythical Man Month seem like good places to start. They're all on Joel's Management Training Reading List.
When you're a PM you're there to deliver the project not to be liked. There's no point shouting at people all the time but occasionally you will need to highlight when people aren't doing what they're supposed to be doing and you mustn't shy away from this.
Don't micromanage your people. Good leaders give their people what they need to do their jobs.
Set realistic goals and give your team some wiggle room. Under promise, over deliver.
Insist on standards and good documentation. People come and go throughout projects and it is important that those down the line can pick up where others left off.
In no particular order:
If you choose to ignore this advice:
Be realistic about timescales. Developers tend to be over-optimistic over how quickly they can do something, so never ever reduce their estimates, and - if possible - add a contingency to their estimates.
Remember the "nine women can't make a baby in one month" rule. Throwing more people at a failing project will simply increase costs; it will often not (significantly) reduce development time.
Communicate, communicate, communicate. Hold daily stand up meetings with the team and ask them how they are progressing, what is holding them up and what they plan to do next. Keep your customer informed of progress: both good and bad.
Remember the iron triangle of requirements, development costs and development time. If requirements change, the end time will change, and costs will go up. If the end time is moved forward, reduce the requirements or the costs will go through the roof.
If possible, involve the customer early on and often. What they think they want may not be what they need. Show them early prototypes and get requirements changes agreed early. That way you keep costs and delivery dates under control, give your customers confidence and deliver what they need.
I've found Behind Closed Doors - Secrets of Great Management to be a great help to me. I find all of these concepts to be very important, they're hard to prioritize. I'm sure I'll look at these in an hour and want to re-order them...
Make sure you determine and communicate to all stakeholders what the team is working on for the next month, and maintain that 4 week rolling schedule.
Don't ever (EVER) promise something you cannot deliver.
Give specific feedback to people early and often.
Get out and walk around. There is only one way to get an accurate gauge of the feelings and mood of the team.
Have a weekly one-on-one meeting with all of your reports.
Get good (through practice!) at running focused, productive meetings.
When the team is fully committed, the only way to meet a shorter date is to revisit the priorities and cut scope.
Lots of other good advice here, particularly the reading. The other advice I'd give is to "Take charge."
The first time I was assigned a team-lead position, I thought I could just let people do their jobs, and everything would come together. It doesn't work that way. You shouldn't be tyrannical, or be a micro-manager, or ignore what others tell you, but it is up to you to set the goals, the direction, and the standards for the team.
Acting like a leader is very unnatural for a lot of techies, so they avoid it. But it is really not that hard. Team members want you to make decisions and tell them what to do, so just do it.
Learn programming, so you really understand what lives among your developers.
Theses items are important for you:
Run effective meetings. Have a goal, stick to that goal and try to keep the duration to a half hour. You'll want people to come prepped, so if it's status meeting everyone should be prepared to answer about their facets of the project.
Apply Pareto's Prinicple (80/20) rule. On each project you'll to determine what are the important deliverables for the system, and what are the important deliverables for the business units. They may not match, and you'll have to bridge the gap with numerous discussions with the business stakeholders. In most cases only a few of the objectives will truly comprise the bulk of work. If these are the important ones, focus there, complete them, then move on to the "nice-to-haves".
If your project involves creating a database for non-technical users and they are the decision makers for the project, be sure to talk about cardinality of data and what constitutes "a bad, painful change". Be upfront and get them to focus on what the data represents. Do not relent when they come back 3 weeks later and ask you to change primary keys, etc.
Be firm setting your goals. While you need to let the developers do bottom up estimates, you need to make sure they are not letting ego get in the way. Yes, as a developer I have done that on projects but one my first PM position I was too much of the "friend". Guess what? Late project. As PM your job is to keep the star athletes well trained and hungry for victory.
If you do not have testers, insist that your developers come up with test plans, and if you can, before they start coding. Get the team to think in terms of how they will validate, easily, that things work. Just use Excel.
You may want to have someone else be the note taker at the meetings where you are directing the action. You need to be unfettered to gauge reactions, diagram on the white board, etc. Remember, you need to keep the objectives in mind while others discuss the details. There may be hidden gems in comments that you'll want to jump, and if you have to stop to take notes you'll kill the dynamic.
Two documents that are the most important: ERD and Use Case narratives.
Good luck. It's a lot of work.
Is this your only role, or will you be programming too? If the latter, be very aware of your time management - particularly at crunch time. It's all too easy to get bogged down in your own development and lose sight of the bigger picture.
Get an official charter to manage the project. This is how you assume the project manager’s role, this gives you the authority to make decisions and take responsibility. It will prevent many power struggles from taking place. Power struggle is the last thing you want as a less experienced manager.
Whether you joined a new project or you took an existing job over one of the essential things to do is to take stock of decisions that had been made before you assumed the role. Look for these things that you're not comfortable with. Make the stakeholders involved aware of your concerns, re-negotiate. You steer the ship and you're the one who takes responsibility. This is why being a software development project manager really worth it when you care about outcome: you have a great opportunity and actual ability to make real impact on very broad range of issues.
Never take part in cover-ups; never cover up yourself, never lie. The truth will eventually surface and will cause irreparable damage to your reputation, to the relationship with the team and stakeholders and to the project itself. Communicate the bad news as soon as you're reasonably confident things are or going to turn out sour. Communicating bad news is, unfortunately, part of the job, and probably the most difficult one. However, by doing it timely, accurately, not waiting before you have no other option by break the news, you earn trust.
Make effort to avoid making decisions outside project management scope that are better made by owners of respective functions. As an example, avoid making technical decisions when your team has a specialist to consult with. Unless you officially wear multiple hats try to stick to your area of responsibility, even if feel very strongly about something outside your job scope. You can always make suggestions though.
Never loose your temper, never panic. When you feel like it, try to think of some constructive questions to ask instead. Information helps you re-gain the control over situation. Nothing is a "cock-up", "problem" or "disaster". It is a situation. Your job is to manage situations; as opposed to let them happen in unmanaged manner.
Do not worry about making wrong decisions. Just run them past your team or stakeholders involved, they will always correct you. You are not alone.
Get formally trained in project management if you're not yet.
The following is based on 20+ years of software development experience.
1) Software development projects succeed or fail based on the Project Plan.
2) If the task is not documented on the project Plan, IT DOES NOT EXIST.
3) Your project plan should be based on software releases.
4) Everything necessary to complete the release should be on the Project Plan.
5) Don't expand the features in a release once on the Project Plan.
6) Review the project plan with the end user/customer at least once a week.
My golden rule of Management:
Understand that each member of your programming team has individual goals and interests. They will range from more money, more recognition, learning new technology, etc. As a project manager I think it is your job to first learn each member's personal goals. Then you have to align their personal goals with the specific tasks you are asking them to perform on the project.
I think the whole selfless team member is BS. Everybody has goals and aspirations and the only way to get the most out of each person is to make them believe (and hopefully it is the truth) that the goals of the project are in line with their individual goals.
I'm guessing that since you are on SO you have a technical background. Based on that unproven assumption i'll make three gross generalisations.
Generalisation 1) You'll be good at reading and can learn from text books. Do so, you'll learn a lot. Just pick one or two books and implement what looks achievable on your first project. I liked The Art of Project Management and Death By Meeting. Plus if you really want to start learning PM'ing grab the PMBOK as a reference tool to look up all the PM jargon. However don't read through that first. It won't seem to practical or useful, just keep it for reference.
Generalisation 2) You'll have an *Pod and know how to use it. Try some podcasts such as The PM Podcast, and PM Lessons Learned have had some good (and some dull) podcasts. The PM Podcast is pretty solid and entertaining and has some good sessions on Authority and Virtual Teams. Most of the more recent PMLL ones are good. Especially the ones on Risk Language and Soft Skills. (PS: Don't be put off by the site designs, subscribe to the podcasts and go from there)
Generalisation 3) You're good at the hard skills but not the soft skills. Most people are anyway, but if you have a technical background you have to stay away from all the tools out there. None of them really work better than the basic level of MS Project, Word and Excel. If you start thinking of the latest agile job tracking neural network estimating sharepointapedia enabled web2.0 tool then you are not a Project Manager. You are a Developer. If you start spending more than 10% of your time on the tools you have, you are not a PM. You are a secretary.
Hope this helps, and good luck :)
http://www.manager-tools.com/ really makes the difference for me. Very sound advice and downtoearth hands on podcasts!
My first advice would be to read Steve McConnell's excellent book Software Project Survival Guide. It's written for people in exactly your position. You can get the other six pieces of advice from the book.
If you are a developer, it is a new world: you will need to take pride in others' programming achievements because you will not have time to do your own.
Treat people like adults and they will respond in kind (usually). For those that don't, tell them in private that they have the choice to be treated like an adult or a college intern.
You will have to learn to choose the battles in terms of pushing back against marketing/management. This only comes with experience, alas.
Reflect on the best people with whom you've worked and use their ideas. Be sure to make evaluations a 2-way conversation. e.g. The best profs in school, IMO, are the ones who had an eval half-way through the course.
Rule 1: Know which hat you are wearing.
You are taking on a managerial position. That means that you programming days are over. You can't do the fun technical stuff and manage people at the same time. That doesn't mean that you can't jump in and help one of your workers, but you can't spend much time at it.
Rule 2: Back your people.
Your main job is to insulate your workers from upper management, and facilitate interaction with other levels of the company. If one of your guys needs access to resources in other departments, you have to negotiate that for them. Don't let anyone else assign tasks to your workers, and especially don't let anyone else discipline them. That's your job. Make your praises in public and your criticisms behind closed doors.
Rule 3: Delegate and follow-up.
Once you have done those project management thingys to generate the tasks to perform, you have to get your workers to do them. How you do that is your own style. You can be all supreme dictator, or nice and paley-waley. You can assign the tasks youself, or let them chose. The only thing is you have to be consistant.
You need feedback to see how they are performing. That may mean periodic meetings and reports, or just visiting them occasionally to see what they are up to. Keep your BS filter on high, because you are going to get only an incomplete version of the truth.
Assuming you have determined that there is a problem, you have to react before things get out of hand. You may have to pull the employee off the job, or even fire him. Perhaps it is a personal problem that interferes with the work environment. You may need additional resources - more programmers, computers, printers, secretaries, etc. Sometimes the best action is to do nothing right now.
Rule 4: Substantiate your own BS.
If you make a promise to an employee, make sure you remember it, and follow through. If you are making a claim to upper management such as an estimate, try to make it at least plausable. Try not to be railroaded into making a decision you are not comfortable with. Most decisions can be postponed.
One more thing..
About Meetings
I guess I am among the few people who actually enjoys meetings. I must say, I have been to enough. Some of them were actually good, but the majority were a complete waste of time. These are the rules I've come to know.
Start on time. This is the golden rule of meetings. If you are running the meeting, don't wait for stragglers. If it is someone else's meeting, show up at the appointed time. Don't be too early. If you have some preparation to do, have all of the materials ready, reserve enough time for murphy and test everything beforehand. Close the door at the start time.
Have an agenda. If you are running the meeting, make sure everyone has the agenda in a timely manner. Once the meeting starts, follow the agenda. Have clear-cut rules to modify the agenda. If you are invited to the meeting, make sure you know the agenda.
Keep Records. Write down the date and time the meeting starts and the attendee's names. Jot down pertinant info. Follow the agenda. Identify speakers. Don't rely on the published minutes - they will be biased, even if unintentionally.
Don't allow anyone who is not invited. The worst thing to disrupt a meeting is when Billy-Bob invites his cousin who proceeds to puke all over the boardroom table (true story). If the President of the company drops by, you can poll the attendees to see if he will be allowed. (Sometimes it's best to do that behind closed doors)
Keep control of the meeting. If you are running the meeting, you are responsible for it. Robert's Rules of Order is the bible. You don't have to be strict and structured, but knowledge of the rules can help you maintain control.
Finish on time. If things are taking longer than expected, you can formally extend the meeting, table it for another time, or even drop it completely. Sometimes you may have to prioritize the agenda to utiilize the available time.