Hi,
I am a software developer, place where i work , am soon going to be in a role where I would be required to manage multiple projects, not necessarily in my sweet spot of tech area...Are there any tips/traps or suggestions that I should be keeping while handling them...
Cheers
*) Notice I didn't say "Testing". Quality Assurance begins when the first requirement is drafted.
I highly recommend the book "The Art of Project Management" by Scott Berkun. The author made a similar transition from developer to project manager, and it describes a lot about what he learned along the way.
I'm not a project manager myself, so take what I say with a grain of NaCl. I suppose the best advice I could give is: Remember all the gripes that programmers and developers typically have about management and meet the goals of the project while minimizing the sorts of situations that cause those gripes.
Do NOT get sucked into the trap of trying to do the work yourself or even suggest how others should do it. If someone asks about a piece of code you've written, let them try to work it out before answering.
A good manager will let their people make their own decisions. That doesn't mean that you shouldn't ask pointed questions, that will make someone think about a problem in a new way. You just shouldn't be the one making the decision or doing the work.
You wil NOT have time to worry about the little details. Concentrate on what the business wants. They are the ones who pay your check and those of the developers. To paraphrase my wife "If the business aint happy... Aint NObody happy"
Follow the rule Scotty laid down on the enterprise: Get your estimate, multiply by 4, report that to management. Then when you get done early, everyone thinks you are a miracle worker and the ship doesn't blow up.
On a more serious note, we had very good results using XP methodologies to plan stories/tasks and implement them. We tended to actually meet the programmer based timelines after about our 3rd iteration. This was seldom as soon as the sales folks wanted things, but when they did get them, they got solid code.
The "original estimate multiplied by X" rule can hurt you. You can "over-estimate" yourself out of a job. If you multiply the original estimate by X you'll make it cost prohibitative for upper management to go with your team on certain projects/improvements. Upper management will go to someone else with a better estimate. "Someone else" will give a lowball estimate which in the end won't matter because once management is invested in project A they'll keep pouring money/time in project A to see it completed.
Do not micro-manage. Do not dive into the code. Managers who started out as programmers tend to do this. Look at the big picture. Leave the details to those tasked to handle the details.
Give serious tasks to seasoned programmers. Give trivial tasks to less experienced programmers. This is the most important rule. If you do badly here, you'll have a slow-motion train wreck on your hands. A bad manager can't tell the difference between seasoned and inexperienced programmers, serious and trivial tasks. This is the biggest problem in management. Assuming each worker bee unit (programmer) is interchangeable is a BIG MISTAKE and leads to out-of-control projects. Also, you can have a programmer who is seasoned in "knowledge domain A" but very inexperienced in "knowledge domain B". Don't give that programmer a "B-type" task.
You need tools to do your job. Software tools. Do not rely on paper to keep track of project status because projects are dynamic and paper is... well... paper. If there's a request tracking system (software) already in use, do not change it. Hopefully, if you are lucky, it's a good one. Learn to extract data from it. The request tracking system is your friend. A good request tracking system keeps track of time estimates, who is doing what, when, and how much time it's going to take. Use the request tracking system to get an overall view of the direction of each project. Learn to turn request tracking data into useful charts that show the big picture to upper management. You will need to report the status of each project to higher-ups and you'll get status requests (pings) from them very frequently.
"Me too" on some of the comments here... except I'd be very careful of any software tools. MS Project (or whatever collaborative-web-enabled-monte-carlo-estimating tool you choose) doesn't make a good project manager. Being from a technical background there is a tendency to get sucked into these tools.
You've got a few great suggestions for books to read. Peopleware being a good one on software and the people who make it. Also Scott Berkun's is a great first stop for a new PM. If you listen to podcasts try Manager Tools (find em in iTunes) especially their four part "Horstman's Law of Project Management" series. While this won't focus on the governance or budgeting aspects of PM it'll really help you focus on getting things done.
Also the beauty of project management is that you try different approaches on different projects and see what works for you. It's a great way to learn how to lead teams.
Once you've been in the role for a while you may want to consider some further education in the area such as CAPPM, PMP, a Diploma in Project Management, PRINCE2 Practitioner (only more relevant if you work with PRINCE2). Also consider learning more about the business you are in (eg: Health, Finance, Mining etc), this way you can add a lot more value to your team than technical leadership.
Good luck!