Advice for a New Software Project Manager?

Tom O'Neill asks: "I have recently been promoted to 'Manager of Software Development' at the small business I work for. I have been developing web-based software professionally for about 6 years. I have seen the software development cycle work and I have seen it fail. Are there any project managers out there with some advice for a green horn like myself? Are there any books or other reading material that I could read in order to manage a software project effectively?"

Comments

Based on what I've seen...

[Jerf]

Are there any books or other reading material that I could read in order to manage a software project effectively?

No.

(Semi-serious. The evidence suggests to me that either you can do it (presumably with some practice) or you can't. If there is a group of people who can learn it from books, they are lost in the noise. Nor does there seem to be a way of knowing in advance whether you can. Like I said, semi-serious; I don't fully mean this but it's not fully a joke either.)

I for one...

[Anonymous Cumshot]

Welcome our new green-horned overlords.

Know your people

[Reemi]

My personal tips, based on that projects are executed by people:

- Know the people you work with, understand the way they communicate progress/problems. Everyone is different

- Create an atmosphere where delays are acceptable, but only when pre-announced. This avoids surprices just before a deadline and allows you to take actions in time.

- When assigning a task, let the receiver make a time plan and commit to it. You'll find out they are in general too optimistic but highly motivated to make it because they made this promise towards you. Never push a deadline on them if you can avoid it.

- Don't ask for too many progress reports, talk with your people and ask once in a while a snapshot of the current task. Non-performers can be identified in an early stage this way.

All items I mentioned are human related. Why? Because my experience is that in most cases that is the only area where one can (is allowed to) make a difference.

Re:Know your people

[MrResistor]

I would add to this:

- Be an advocate for your team. Determine what they need and try to get it for them, and more importantly shield them from other managers.

IMO, this is the single distinguishing factor in the the good managers I've had. Even in a seriously messed up company, and good manager can make all the difference in employee morale, and happy employees are productive employees.

What's more, regular people (read: non-MBA types) tend to want to be loyal, but that has to go both ways. If your subordinates feel that you're on their side most of them will be willing to go to the ends of the earth for you.

I've had seemingly great jobs where it took effort to put in my minimum time just so I could get out of there, and I've had crappy jobs where I happily put in 60 or 70 hour weeks. The manager makes all the difference.

Re:Pot-Holes.

[museumpeace]

I wonder if commenter means "Code Complete" by Steve McConnell. You have asked for books yet other commenters have said, in effect, "look to your people, not books". Much wisdom in that advice but you did ask for books...keeping the balance between book-learned management and gut instincts of a good, naturally people-oriented, manager is just a gift.

Anyway, not that anybody would ever be dumb enough to entrust ME with project responsibility but the books I have read and thought useful are the above mentioned McConnell book [the authors favorite among his 4 or so titles] and another by him: The software project survival guide [ a book I keep at work so am only giving the title from memory]
If your leadership duties are more than supervisory, ie you are expected to make technical contributions, Malveau and Mowbray's Software Architect bootcamp" might be worth a peek too.

Run, don't walk and get the following

[jordandeamattson]

You really need to read the following books, as you move up the chain:

1. The Pragmatic Programmer
By Andrew Hunt and David Thomas

2. Pragmatic Version Control
By Andrew Hunt and David Thomas

3. Pragmatic Unit Testing
By Andrew Hunt and David Thomas

4. Pragmatic Project Automation
By Mike Clark

5. Code Complete, 2nd Edition
By Steve McConnell

6. Debugging The Development Process
By Steve Maguire

7. Joel on Software
By Joel Spolsky

8. Testing Computer Software
By Cem Kaner, Jack Falk, Hung Quoc Nguyen

9.Managing the Testing Process
By Rex Black

10. Lessons Learned in Software Testing
By Cem Kaner, James Bach, and Bret Pettichord

11. Peopleware: Product Projects and Teams
By Tom DeMarco & Timothy Lister

I also second, The Mythical Man Month by Brooks.

Some said that you can't learn anything from books. I just don't buy it. You can learn a lot from the mistakes and successes of others. Just like a great coach looks at films of other teams (learning from their mistakes and successes), you can do the same.

Take time to read books written by those who have been in the trenches and apply the lessons learned.

Yours,

Jordan

A great book

[stargazer1sd]

I'm surprised that nobody mentioned the Quality Software Management series by Gerald Weinberg. There are 4 volumes; you want to start with the first one. This is a great series, if you can take the time to properly digest the contents.

This series is concerned with the management process rather than any specific techniques. It won't make you a great manager by itself, but I found it helpful for knowing when I was heading in the right direction.

Re:Heh

[Anonymous Coward]

ESR Book + Microsoft Project & Visio = Recipe for Death.

Seriously, developers don't wan the PMs walking around saying "Don't use RPC! RPC is Bad!" because they read it in Huckberry Unix.

A few pointers

[Jorkapp]

Here's a few good pointers to follow when managing subordinates:

• Don't over-supervise or they may either not like you or their work.
  
• Treat them fairly, equally, and with dignity and they will respect you. Playing favourites or doing your whole Drill-Sergeant routine won't help.
  
• State what is expected of them and be specific. Giving specific tasks ensures that what you want to be done gets done with a minimum of confusion.
  
• Allow social activity since they will not only want to share ideas about the project but relax as well.
  
• Recognize good performance. For example, if they're ahead of schedule then bring in coffee (or take them out, either way). You can recognize both individual and group performances, but be careful not to play favourites with the individual recognition.
  
• Explain changes. Simply telling them to change such and such just "because you said so" will serve no purpose but to have your subordinates get more cranky and disrespectful towards you. If you cannot think of an excuse for the change, then consult the group on what they would think about the change.

Don't forget, they look to YOU for leadership.

Master, I have a cunning plan!

[strangedays]

1. No plan involving turnips as a critical component, will succeed.
2. Being a professional software developer has bugger-all to do with being a manager. It does mean you can fool yourself into believing you still understand the technology, for a while.
3. Traceability is your best freind. If you don't understand why, find out fast.
4. There are no technical reasons projects fail, ever, with no exceptions. Read this one again, its true and I mean it. Failure is always a management failure. However, managers are by definition too arrogant and defensive to admit this. Plus, they are in a great position to lie about failures. Trust me on this one.
5. Jump into the sh*t, its only up to your neck most days, and the devil doesn't go skiing till high noon.
6. Develop a cynical, dry, in your face wit, you need a bullet proof, reliable, sense of humor, its not an option, its a survival mechanism.
7. You are a fully qualified software development project manager after you grok where you screwed up your first, second and third major project. The apprenticeship usually costs several companies, many millions and many years. Tough. Software projects are like poker games, its never free, they did ask you to play for them didn't they?, and they gave you the table stakes. So go ahead and deal.
8. Technical folks will constantly present pet ideas, gizmos, design and methods or languages as solutions to management, communication, legal and cultural problems, etc. No one knows why, but they do. They mean well. Please listen politely, smile sweetly, thank them profusely, and then ignore them completely or you are doomed.
9. Make sure you will enjoy the ride.
10. Never, ever give a Date, whatever the provocation, whatever they promise, for anything other than the next phase of a project, where you have full specification, component list, dedicated resourcing, identified dependencies, and an obscenely large, hidden, fudge factor.
11. No date is ever "off the record" If you mumble dates in your sleep, sleep alone. This is the only way to be a hero.
12. No one ever knows how long any software project will take.
13. Software projects never finish, some are simply gracefully abandoned and success declared.
14. No responsibility without authority. Ever. No exceptions.
15. Charge a lot for your services, no mercy, client pays.
16. There are many, many, more critical items you will certainly need to know, but thats all for free (please see prior point)

    Good luck, you will need it.