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?"

History

Pay attention to history [slashdot.org] ... It's bound to repeat itself.

Based on what I've seen...

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 [catb.org].)

Re:Based on what I've seen...

The evidence suggests to me that either you can do it (presumably with some practice) or you can't.

I'm going to have to disagree with this one. Project Management in general is a pretty mature field. I deal with project managers from the oil, gas and chemical fields every day and these guys and gals are well trained at what they do. There is very little "hey, we're just good at it." Most project managers work their way up the system during their careers, learning different aspects of a project from the bottom of the project team on up. Plus, companies will send project managers to either outside PM training, or for the larger companies will have their own, interior colleges.

The reason all this time and money is spent training project managers is because a good project manager (in those fields) can literally save billions in capital costs, hundreds of millions in lost opportunity costs and workers lives. Project systems are pretty well defined and they usually require proper front-end-loading to make sure the project team knows exactly what they're supposed to be doing it before they actually start execution. Plus, there are formal risk analysis steps performed so the team knows what might come back to bite them in the ass so they can be prepared with the appropriate contingencies.

Now, with respect to software, from what I have seen anecdotally there's just not the same kind of rigor placed on most software projects, even large, very expensive software projects. The upfront definition tends to lack the type of detail you see in other (physical) capital projects. I don't know if its the idea that "Hey, its only software, its no problem if we change crap halfway through implementation" that causes this or something else, but its a killer when it comes to controlling cost and schedule, not to mention the ramifications that has on the project team (low moral, work crunches, throwing bodies at the problem, etc.).

The moral of the story (I'll stop rambling here) is that project management is very much a learned skill. Although its not as mature in the software field and software specific project management training may not be as available as more PM training specific to more traditional industries, its still worth looking to get as much training as possible. It will pay back in spades. Also, as someone above mentioned, network your butt off with other IT PMs. Learn from others what works and what doesn't work. Also, start formulating a company-wide project system with you colleagues. And go read up on the successful IT PM jobs. From what I understand Boeing did an awesome job with the software development associated with the 777. See if there are any case studies about how they did it floating around.

Re:Based on what I've seen...

Now, with respect to software, from what I have seen anecdotally there's just not the same kind of rigor placed on most software projects, even large, very expensive software projects.

The fundamental problem is that we honestly don't seem to know what rigor to put in. I know what we need. Bob knows what we need. ISO knows what we need. Several book authors know what we need. Unfortunately, many of these things end up quite contradictory, and scientific studies are impractical and borderline impossible. Between that and endlessly moving requirements, we just haven't been able to really nail down what makes a good manager, i.e., what makes for a well managed project. It's not like most engineering projects... or rather, it's just like most other engineering projects, multiplied by ten or twenty.

(And at the risk of sounding elitist, I'd also personally add that the average programmer is really quite astoundingly incompetent, both due to the wildly changing world we live in, and a basic lack of skill (compounded by the difficulty of mentoring in said wildly changing world). Would you want to drive over a bridge where the senior engineer on the project has only three years experience in building bridges? Yet, how can you have much more than three years experience in .Net?)

Every field has its own trials and tribulations, and I don't mean to minimize other fields, but software really is a mess.

I don't know if its the idea that "Hey, its only software, its no problem if we change crap halfway through implementation" that causes this or something else,

I believe the observation goes back all the way to The Mythical Man Month that this, which should be software's greatest asset and turn a software project into something vastly easier to engineer than a bridge, has been turned into its greatest liability through the mechanisms you propose, and the resulting higher-order effects.

The moral of the story (I'll stop rambling here) is that project management is very much a learned skill.

Looking back, what I meant to emphasize more is that you don't seem to be able to pick it up from books, and further that some people can't seem to learn it at all (though that shouldn't be surprising). But I did not say that as clearly as I meant to.

This might change if A: We could nail down a One True Way to manage (not even "the" one true way, "a" would do nicely) and B: Somebody wrote a good book on it. In the meantime, I just haven't seen the evidence that a real manual on management has emerged. You can benefit from a lot of people who will tell you what not to do, but there isn't so much work on what to do.

(Example: The classic Mythical Man Month book has a lot of "don't" essays, including the eponymous one that basically says "don't throw manpower at a project expecting it to be perfectly fungible", but the suggestions on what to do are tentative, untested hypotheses about building software teams on a "surgeon" model, which IIRC had a note added in the 25th Ann. Edition to the effect that he still hadn't tried it yet.)

Know thy underlings

In all groups, there are offical, and un-official designations. I, for example, am an Infastructure Software Developer. But, I am also the team's go-to guy. I have no long term projects, only short ones, so people bring me things to work on, on the side. There are the guru's who everyone goes to and the loners or the popular people. If the boss knows the groups working, they can interact more effectivly. Also, don't be afraid to let the programmers have a little extra room to develop and imagine. If you become a slave driver, your project will fall behind and mabey even fail.

If you want to be the best, think back to when you were in the team and what your first boss (or first good boss) were like... if they sucked, do the total opposite. If they did things well, and you remember having a good time, do what they did.

I will leave you with a quote from futurama. "If you've done your job right, it won't seem like you've done anything at all." - God

Create a Good Environment for the Coders

Well, for one, creating a good environment for the coders can help (meaning no tiny cubicles without a door)!

Remember how to manage people

Your chief weapon is surprise...surprise and fear...fear and surprise.... Your two weapons are fear and surprise...and ruthless efficiency.... Your *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the penguin.... Your *four*...no... *Amongst* your weapons.... Amongst your weaponry...are such elements as fear, surprise....

Heh

I am a Project Manager, having worked my way up from the trenches. I've been a PM for 6 years, developer for > 15.

My advice to you is to get the hell out now while you still can.

All joking aside, get yourself certified; that will give you a base of knowledge that will help you understand what you're doing.

The following a Must Reads:

• The Mythical Man-Month
• Code Complete
• Rapid Development

I personally don't jive with RD, but the book is an excellent source of knowledge and is applicable outside of RD. Also, get yourself educated in risk management and estimations (work breakdowns). I haven't seen any good books on either -- maybe I need to write one :)

Good luck.

Another thing

You'll do yourself a favor if you network with other IT PMs.

Many people have been where you are now; tap their experience and avoid the pitfalls they got to live through.

You can find a bunch at the local PMI Chapter [pmi.org].

I for one...

Welcome our new green-horned overlords.

Know your people

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

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.

Determine your real role.

I have seen the term "project manager" applied to a full spectrum of job duties. I think most people will agree that a project manager is responsible for insureing that a project is completed on time and on budget. (Although that should be the responsibility of everyone.) Beyond that one goal there may be many secondary duties. Part of the confussion may be that a project manager is also tasked with other duties such as designer, lead developer, or HR management. Responsibilities will also depend on the size of the project. So the first step should be to talk with management to determine your exact responsibilities, and to talk with other project managers within your organization. Once you have an understanding of you role then you can start looking at reading material.

There are some basic management skills you will want to work on. When leading technical people you need to convince them the project is good ("buy in"). Lots is written about this and most of it can be summed up with "Treat people with respect." You need to know how to critise properly by asking the right kinds of questions. In general don't ask questions that can be answered with a yes or no. It is harder then you think. Budgeting time is very important. Gant charts (ala MS project) are usefull.

Management speak

Well since you're moving up the food chain, I think it's appropriate that you learn to decipher the management speak, so to say... :D

Management Speak: You needed to be more proactive.
Translation: You should have protected me from myself.

Management Speak: I'd like your buy-in on this.
Translation: I want someone else to blame when this thing bombs.

Management Speak: We want you to be the executive champion of this project.
Translation: I want to be able to blame you for my mistakes.

Management Speak: We need to syndicate this decision.
Translation: We need to spread the blame if it backfires.

Management Speak: We have to put on our marketing hats.
Translation: We have to put ethics aside.

Management Speak: I see you involved your peers in developing your proposal.
Translation: One person couldn't possibly come up with something this stupid.

Management Speak: There are larger issues at stake.
Translation: I've made up my mind so don't bother me with the facts.

Management Speak: I'll never lie to you.
Translation: The truth will change frequently.

Management Speak: Our business is going through a paradigm shift.
Translation: We have no idea what we've been doing, but in the future we shall do something completely different.

Management Speak: Value-added.
Translation: Expensive.

Management Speak: Human Resources.
Translation: A bulk commodity, like lentils or cinder blocks.

Management Speak: The upcoming reductions will benefit the vast majority of employees.
Translation: The upcoming reductions will benefit me.

Traceability is the king of software development

As a manager your duty is to ensure your developers don't do things that waste time or money. You need to do at least these things:

1. Figure out what the real requirements are. Don't simply believe that customer's (in house or not) know what they need. Don't treat customer's like idiots: they are the most valuable resource you have to ensure the software you deliver is actually useful.
2. Get the business folks to prioritize the requirements so that you can reduce scope effectively. You will have to reduce scope--better to be ready for it than to be surprised when the time comes.
3. Ensure that *everything* your developers do can be traced back to a requirement. If someone is doing something that can't be traced back to a requirement they are wasting time and introducing unnecessary complexity.
4. Never forget that your job is to bring value to the business. Don't rule out non-software options when you see them.

These ideas ultimately lead to or from, depending on how you look at it, to "build only what you need".

Run, don't walk and get the following

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

Your New Role

"Shit rolls downhill" is a common misconception. Your new role is to prevent this. Protect (but do not isolate) the people below you from those above.

The Secret Consultant's Rules

Not much of a secret since I talk about them regularly, but still, these are the secret rules of TQM, Six Sigma, and most other successful projects:

(1) know what you want
(2) know how to tell if you got it
(3) tell everyone (1) and (2)
(4) allow the front-line people the autonomy (and safety) they need to make changes, and
(5) reward them for achieving (1)

I've seen projects and programs and processes fail for missing any of these steps, but its pretty amazing how often people fail either (4) or (5).

2 possible methodologies

There are two methodologies I like.

1) Extreme programming - this is good if you have a kick ass team and clients that are receptive to the idea of working with your development team. However, if you are in that situation, chances are any methodology would work anyway, since this methodology assumes best practice for everything.

2) Rational Unified Process - this is good if you can afford it. Its more adaptive to situations where your developers are not as stellar and clients are a bit more unreceptive. But the nice part is that it adapts. Note: you don't need to use the Rational tool set in order to use this methodology, but its nice to have anyway.

A great book

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.

Yup ...

Two books: Fred Brooks' famous "The Mythical Man-Month" and Tracy Kidder's "Soul of a New Machine". The former is all about managing large, heck, gigantic software projects. The latter is about managing small, highly motivated teams effectively.

TPS reports?

get rid of 'em. everyone will love you

Learn from the master:

/usr/src/linux/Documentation/ManagementStyle

Learn this Secret

Hit yourself in the head with a hammer. Notice how itt feels good when you stop!

A few pointers

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!

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.

Remember Your Roots

You've been a developer, so remember what it's like. You'll be working with a lot of people who probably don't understand software development and software developers. You're the developer's advocate, so don't forget how to think like one.

Some Philosophy

Always always always be helpful. Make it so your people can do their work. Provide and get out of the way. The worst managers, IMHO, are those who look for failures and a place to hang blame. Anyone, I mean anyone, who is berated or belittled will never want to do their best for you and company. But if you help them and teach them, they will always give their best.

Monoculture

Make sure there is some level of monoculture in your .. culture. You want everyone to be comfortable and to some degree, even a small one, interchangable. You want skill level to be similar, style to be similar, documentation to be similar. Heck, even the same for some things. Of course, there needs to be some level of difference to allow freedom, to allow people to be people and not cookie cutters.

Document tasks and results

Documentation.

I'm not talking about a manual for your product, I'm talking about keeping track of what you do, what your staff does and what the results are. It may be laborious to do so, but there will be times that you'll be glad you did. Also, you may wonder why something was done a certain way a few years ago; having some kind of knowledge base written down will be invaluable.

Document the code. Make sure that people adopt javadoc-type conventions. Check out Doxygen [doxygen.org] if you're not doing Java development, and make it a policy that people need to comment their code in places that are not painfully obvious. Programmers can be quite fat headed at times about this, because "hey, I know this, and if you can't read this then you aren't good" or whatever. What is obvious to them might not be obvious to others, and if you want to do a quick scan over some code, its easier to read a comment defining a block than figuring out their "spark of genius du jour" (sometimes people write things overly clever thinking that its more efficient when in reality its not and only making things harder to maintain).

The point of this is that:

1. Your staff will not be the same forever; people move to other projects or other jobs.
2. You will forget details.
3. You will find it difficult to recall exactly what you and your staff did several months ago, especially if the project is large and fast moving.

I'm not saying that the above points are absolute, but in case you do find yourself in any of those positions...

By keeping documentation, you will always be able to back up, defend, promote and prove (or disprove) your ability to manage. Now you just need to make sure you make the right decisions; nothing can help that except experience and good judgment.

Tom DeMarco

Read everything Tom DeMarco has ever written. Read it now. Run don't walk to Borders (or wherever) to see what they have, then Amazon (or whatever) for the rest.

The Deadline is silly, but it's a good read and has excellent information and might be the first one you read. Peopleware is the most important book. Read Slack last, as it's least connected to specific software projects, and more on management, in general.

Management is a service in search of an ethos

A lot of what's been said above can be reduced to this:

Management is a service to your coworkers: those people are under your care, not in your power.

There was also a remark about having some degree of "monoculture" in your group. What that person wanted to say was that your group needs an ethos, a group identity, a sense of common cause even when goals are ill-defined.

There's one piece of excellent reading about the early days of WinNT... and its not the one at winsupersite... I found via slashdot over a year ago and can't find now. It was an account as told by someone on the team or it might've been Lucovsky or Cutler. In any event, it went deeper into what was different from the early OS development at Microsoft about the early NT effort, discusses "ethos" briefly, and touches on how difficult that ethos was to maintain as the project grew. That last part was a bit heart-breaking to read...

My tips

1. Remember, you are a professional working with other professionals. Your team consists of Software Engineers, not hackers/coders/programmers. Getting in that mindset helps a great deal, because you're not slapping together some product, you're engineering it.

2. Look into any project management methodology that uses iterative development. You want to do iterative development as much as possible.

3. Get as much detail as possible in a "written" spec up-front. It doesn't have to be a formal document, an email will do as long as you have something you can show the customer that they wrote when the requirements change.

4. Put in a formal change request proceedure, and make sure that the person actually making the change gives a time estimate for it before you agree to do it. Come back to management with the actual cost of the change in terms of missed deadlines, lost functionality, etc. This is where iterative development can save your ass, because you can push some functionality off to the next iteration with minimal effect on your current development.

4a. Require that the person requesting the change go over a minor "speed bump" in order to request a change, something on the scale of sending an email or filling out a web form on your intranet. You'd be suprised how many change requests disappear when the person requesting it has to do more than ask for it when you happen to pass by them in the hall.

As for books, your biggest problem is going to be putting in some sort of software development process. Almost every company out there still does seat-of-the-pants development, with lousy results. I'm a big fan of the Rational Unified Process, just be sure to customize it down to the parts you actually need. As another poster said, you don't need any of Rational's software in order to use RUP, just read their books about it.

Once you have some sort of process in place, the rest of the job becomes relatively easy, because you have the information you need to actually manage the process.

Re:Pot-Holes.

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.