Fog Creek Software
Discussion Board

Project Management for Beginners

I am a brand-new, out the box Project Manager on my first day on the job. I have prior experience as a software developer for the same company, and a degree in Computer Science. That's it :)

What are the best and worst things I could do now?

Thursday, October 3, 2002

Best thing: Read Peopleware

Worst thing: Not reading Peopleware

Jan Derk
Thursday, October 3, 2002

Not done any project management myself, but I'm an arrogrant little sod who knows everything so I can give you great advice

You should have a single goal in life: Motivate your programmers! Every single activity should be towards that goal. A motivated programmer produces good, high quality, maintainable code and works constently at high levels of productivity. A demotivated programmer produces buggy drivel slowly.

I reckon you should read these:

*The Joel-on-software archives.
*Code Complete by Steve McCormack (I hope I've spelt that right)
*Rapid Development by Steve McCormack.
*The Dilbert Principle by Scott Adams.

Mr Jack
Thursday, October 3, 2002

I got to agree with Jan. I finally read Peopleware last month (disclaimer: I'm not a project manager... yet) and have to agree it's probably the most important book to be in any software project manager's collection.

Thursday, October 3, 2002

<<I'm an arrogrant little sod who knows everything>>

Aren't we all?

Jan Derk
Thursday, October 3, 2002

"I have prior experience as a software developer for the same company, and a degree in Computer Science. That's it :)"

If that is really it, the worst thing you can do now is manage a project. Because you don't seem to have the education to do so (whether formal or informal).

The best thing would be to invest time and possibly money in getting educated. Seek out a course, or teach yourself, but get informed.

Peopleware, as mentioned, would indeed be a good starting point. But try to find real life cases you can study as well, such as colleagues doing a good job right now.

And most of all, whatever you do, think things through, but be decisive, find confirmation, but don't be a push over.

Thursday, October 3, 2002

As a project manager, I think the most important thing is to get the right team members.  At least one good programmer who can set the standards everyone else can follow.  I would also recommend looking into Extreme Programming to find best practices.

Kevin Clary
Thursday, October 3, 2002

Reading books is definitely good.  And realizing you're in over your head, as some have mentioned, is good.  If you didn't have some sense of that fact, you wouldn't be here.  And I think it's possible to swim instead of sink in this kind of situation, if you find you really want to.  You probably don't know that right now - you know programming, so you know what you like and dislike about it, but management is new.  Remember that you are evaluating that kind of work, as much as others are evaluating you.  If in the next few months you decide that in the long run you would rather work as a programmer, you'll have to get back to that somehow.

Right now though - the best thing I did for myself was stop writing code.  I'm not saying that experienced PMs never write code, of course, but that a former developer finds it easy to go back into a room and write code *instead* of confronting the problems the team is faced with in the most efficient manner possible.  Usually they are people problems and process problems rather than technology problems, since developers are focused on the technology.  So if at all possible, stop writing code.

The thing I didn't do, that I most wish I had, was focusing on the long term situation, relationships, and setting things up for the next project.  If you read Agile Software Development, by Cockburn (after Peopleware and McConnell's Rapid Development at least), he talks about the creation of software as a game.  More like a sports season, really, where each project is a game which builds on the last.  And instead of trying to do the project as one in a series, I accepted my boss's goal of winning *this* project at all costs.  If I had it to do again, I probably still couldn't both succeed at that project *and* make the organization change enough to succeed the next time.  But I would try harder.  Hopefully you have a more supportive environment than mine, so you don't have a strong instinct telling you to set up a skunk-works style project as the easiest way of doing the task at hand.

Good luck!  Whether you want to do a PM's job in the end or not, the experience will make you a better developer.

Thursday, October 3, 2002

The books that have been recommended to you by others are good ones. But books will only take you so far. Since you've already been parachuted into the trenches you'd better hit the ground running.

Here's a few suggestions:

1. Ask your management to send you to PM training. There are lots of week-long training seminars designed to quickly ramp up people in your shoes.

2. Find a mentor. Do you know any PM's that you respect ? Most people would be flattered to be asked. Once you find a mentor, don't abuse the relationship.

Good luck.

Tom Dratler
Thursday, October 3, 2002

I'll add one book to the reading suggestion list: McConnell's "Software Project Survival Guide".

It's sort of a condensed version of "Rapid Development" in that it presents one reasonably good set of best practices (maybe not the best way, certainly not the only way, but a pretty good way).

As it says on the back cover: "Congratulations, you're in charge. Now what?"

Bill Tomlinson
Thursday, October 3, 2002

My only advise: try not to be an asshole and everything will be fine.

Leonardo Herrera
Thursday, October 3, 2002

... and no whining.

nowhere man - split personality
Thursday, October 3, 2002

I'd recommend XTreme Programming: Installed along with Rapid Development and PeopleWare.

Oh, and Mythical Man Month, by Brooks.  Brooks rocks.

As for your people:  I'd recommend paying close attention to emotions, rumors, and hallway conversations.  It's been my experience that there is usally a "secret" development schedule that is probably later than the one your are displaying publicly.  (Often, the "Software Ships" date is really the secret "code complete" date.)

Make sure you periodically ask your people "what do you think?" and be prepared to change things.  You can also ask "What can I do to help?" and be prepared to change things.  (Make sure you have the authority to change things.  If SR mgt really wants the project done, they will let people wear jeans/t-shirts, work at home, offer small amounts of free food and a reasonable incentive, etc.)

I had a sr. manager ask "what can I do to help?" awhile back, and we told him mt. dew and free snacks.  We walked in the next monday to FOUR CASES of 24-oz mountain dew.  (That 24*4, they were double-sized, and our team was only 4 people.) 

The dev team proceded to write code like a mug.  (Quality suffered, but that's a different post ...)


Matt H.
Thursday, October 3, 2002

While Peopleware isn't a bad read, I'd think that you might be better served with Deadline (also by De Marco).  It's amusing, and it doesn't go into huge depths, but it covers a wider selection of topics, including how to manage upwards and not just downwards.

Thursday, October 3, 2002

The person who suggested "Software Project Survival Guide" by McConnel was right on the  money.  Interesting data on how many software projects fail vs how many succeed.  Another good thing in the book is to always have a top ten risk list of risks to the project. 

Thursday, October 3, 2002

More listening less talking.  I had a manager who'd walk in every morning, chew the fat, and then as "is there anything I can do for you?"  And then he'd stay the hell out of my way for the rest of the day.  For me, that was the best kind of management.

Monsur Hossain
Thursday, October 3, 2002

dude you might as well change your career if you don't know about project managment and you have started project managing.

Talk about hindsight!

vividly vivid
Thursday, October 3, 2002

I agree with everything that's been said,
but I want to add a slight counterbalence.

It's easy for a programmer to define what
make a good PM from the point of view of a programmer, but that's not the only thing that makes a good PM. You have to deliver to your boss as well, and sometimes that means annoying your team (such as when you have to cut the cool feature they all like).

Likewise your team will be really happy if you let them all experiment with Extreme Programming, but you've got to be sure that you deliver the project on time while they are learning the techniques. If you management is OK with that fine, but don't fall into the trap of 'the new techniques will be so efficient we'll learn them and still get the project done on time'. That never happens.

No disagreements with the book lists, but if you haven't had any PM training and only have time to read one, read Rapid Development first (or my personal favourite Steve McConnell, Software Project Survival Guide). If you don't understand the principles from that, Peopleware won't help you. (OK, Peopleware should be your second read).

It's very true that you won't meet your deadlines if you don't keep your programmers happy, but you won't keep your programmers happy if you get your estimates wrong, or don't allow enough debugging time.

David Clayworth
Thursday, October 3, 2002

Would you have talken a job as, for example,  a C++ programmer if you knew nothing about C++?

Thursday, October 3, 2002

80% common sense
10% methodology
10% personality
"Software project survival guide" is good too.

Thursday, October 3, 2002

"Would you have talken a job as, for example, a C++ programmer if you knew nothing about C++? "

Please dont insult C++ programmers by comparing their skills to PM!

Daniel Shchyokin
Thursday, October 3, 2002

Actually one more thing, being a good PM requires some knowledge of programming, while being a good C++ programmer does not require PM skills!

Daniel Shchyokin
Thursday, October 3, 2002

Find out what the project is and document it, and not.

Christopher Wells
Thursday, October 3, 2002

Get ready for some on the job training, be there when important decisions are made.  You will learn skills that will increase your market value and flexibility.  Find an area where local project managers are weak and do that part better than anyone else (that is probably people skills).

Presuming you like it, get your company to pay for your project management certification.

Thursday, October 3, 2002

Two more suggestions.

Find someone who already does the job well, and learn from them. You can't be the only PM in your company. And don't let anyone convince you that PM is a lesser skill than programming. Nobody who's done it believes that.

David Clayworth
Friday, October 4, 2002

Oh, it's very possible to be the only PM at a company, it just has to be a small enough company.  And it's probably easier to be in a situation where you have other PMs but not anyone suitable for a mentor, and that's what a lot of this advice helps with.

Even if you do have someone to talk to, you'll make the most of his time if you think your problems out and research it a little, become able to describe the options and their risks for someone who probably isn't as deeply involved as you.  Not only that, but you (and your mentor) get that sense of validation when you go to them and explain your problem, and they have nothing to add.

Friday, October 4, 2002


Project management is not cooking that you go

1 tea spoon sugar
2 spoon of vinegar
100 grams of pasta

What kinda of reply is that?

vividly vivid
Friday, October 4, 2002

"Would you have talken a job as, for example, a C++ programmer if you knew nothing about C++? "

That's not the point. The guy was promoted.

"What kinda of reply is that?"

A metaphorical one, I would venture to say.

Please, don't lower the level of discussions in this forum. The guy was nice to ask us because he wants to do his new task right. Management is _not_ a science. It have aspects that aren't exact or predecible. It's plagued with political issues, psicological quirks, etc.

I would say a novice manager is going to screw a lot of things. The only hope is that he doesn't screw it too bad.

Leonardo Herrera
Friday, October 4, 2002

Vividly Vivid.

95% correct.
5%  incorrect

Sunday, October 6, 2002

I would ask if you really want to become a project manager?  If you are a die-hard programmer and really enjoy it then I would suggest that you think again.

Another book to read, and one that I am currently reading, is The Psychology of Computer Programming.  I think it has a lot to say to both programmers and managers.

I would suggest seeing if your local library has it as its kinda pricy.

Sunday, October 6, 2002

As someone who was in a similar situation just a few months ago, I can totally relate to your problem.

My advice goes like this: a PM's job is to remove obstacles, encourage and motivate the team to succeed, and change processes and culture to facilitate building the best software the team can produce.

The first two are relatively easy - you find out what pisses people off and fix it , and you find out what motivates the team (and the individuals in it)

Changing processes and policies is really hard. Workplace culture is often so engrained in a team that they automatically hate any change, simply because it's "not the way we do things around here". Find a process or a methodology that aligns with the teams goals , and then persist. Be prepared for lots of arguments.

My approach was to put my development background to good use by developing a small intranet app that supported the new process. A Project site that informs the whole company of product progress complete with real-time schedules is invaluable for upper management, and if designed effectively makes life easier for your developers - they update their estimates and design docs on the project site, and then nobody has to pester them,ask stupid questions or project manage them out of existence... It makes your job easier becuase you can clearly see what's being completed and what isn't - you can see where problems are and concentrate on those areas.

Course, there's always the Circus Theory of Project Management: If you have too many balls in the air, throw one to some other clown...

Gordon Taylor
Thursday, October 10, 2002

*  Recent Topics

*  Fog Creek Home