Project Management For Programmers?

welshdave asks: "I'm a senior web developer in a medium sized company where the project managers have no programming experience of any sort. I'm of the opinion that project managers should understand the projects that they're managing and want to move into project management myself. I'm aware that I may meet resistance from the current project managers - many of them have been hired with no previous experience of anything. Previous suggestions to senior management that myself and other developers would feel better with a technical person running projects have been dismissed. As a result we are routinely told to skip testing or to implement the impossible, with an emphasis on how things look rather than how well things actually work. Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?"

Comments

Get certified and go to the local PMI meetings

[bons]

PMI has all you need to know about certification and there are PMI meetings just about everywhere". Attend a few of those and you'll either be networked enough to improve things or fins a better job.

Eject, eject, eject

[vinsci]

You're on what's called a death march project. (See AntiPatterns, chapter 7, Software Project Management AntiPatterns).

Never work with a project manager who hasn't been a developer himself. Find a better employer - there's no way you can really succeed where you are now. Your projects will fail, be late, overrun budget, be of sub-standard quality, all of which are things that will ultimately reflect on your CV's. Naturally, any smart people in your projects all know this and work morale will erode.

Suggested reading

• AntiPatterns. Refactoring Software, Architectures, and Projects in Crisis. William J Brown et al. Wiley 1998. ISBN 0-471-19713-0.
• The Mythical Man-Month. Anniverary edition with four new chapters. Frederick P Brooks, Jr. Addison-Wesley 1995. ISBN 0-201-83595-9.
• Software Project Survival Guide. Steve McConnell. Microsoft Press 1998. ISBN 1-57231-621-7

Me? Got 20 years in this business. Lot's of projects.

If you can't find a better employer, become a project manager yourself, it's not rocket science. Read up, take a PM course, do it the way it should be done.

Re:Eject, eject, eject

[WNight]

Yes. Managers don't need to be experts in the things they're managing but they really need some experience in it.

A building manager who'd never hammered a nail or hung gyprock wouldn't understand the consequences of their decisions on the people who have to do it. They can bluff their way through by having a nose for bullshit - trying to guess if they're getting the full truth or not, but this is just guesswork.

In a programming example. Many companies have a policy that all programming must be done in one language, usually C or C++. If your manager has never programmed he won't know how much savings you'll get from writing a text parsing tool in Perl or Python over C, for instance. So they're unlikely to relax the rule. A manager who'd programmed would understand that every language has its strengths and that by letting one technical violation slip, they're saving a ton of time.

This is where trying to read the employees fits in. You try to guess if the programmer is serious, or if they just like language X more than language Y and are trying to let you program in the language of the week or are serious that it'll pay off.

It's not as easy as it looks

[James Youngman]

There's much more to successful project management than there appears, particularly when the PM is also managing the relationship with an external client. It's the PM's job to make the client happy and (usually) deliver a profit. In a software context, this normally means delivering some software that works (see the Properly Testing Your Code thread).

As a technical person, skills that you will need to gain in order to be a successful PM will include

• Understanding the business context and business drivers
• Managing client relationships (even for internal clients)
• Estimating and planning skills
• Tracking progress against plan - and taking appropriate action (pay attention to this one!)
• An understanding of what timescales are realistic. For example, is it realistic to estimate design:code:test in the ratio 3:2:1? (answer: no).
• Understand that you need to make it possible for the client to change their mind half-way through
• Delegation skills (you can't do it all yourself, you know!) and motivational skills (i.e. understand the kinds of things you can / can't ask of people).
• Risk analysis/mitigation
• Personal organisation and time management
• (In some shops) Project accounting skills

Also, don't underestimate how much work this is. If you are team leading (i.e. working for a PM) then you can expect to lead a team of up to 8 and have the interaction with those staff and the PM take up 100% of your time (i.e. no time left for coding anything yourself). If you are a PM, you won't be able to directly supervise that many staff, because you have the added responsibility of steering the ship. Techies-turned-PMs are frequently tempted to take on the odd technical task - but resign yourself to the fact that you will have to delegate it to one of your staff in order for it to get done on time.

If you are having difficulty communicating the impossibility of a task, consider making a weekly/monthly report document that shows progress against plan and the outstanding issues and risks. Many of these will not change from week to week, but putting them there provides one place where (s)he can refer to them.

If something is impossible, then demonstrate in the report why it is impossible, and suggest an alternative. When presenting a problem, your many many times more likely to be successful in getting things changed if you also suggest a workable and realistic solution.

Re:Only bad managers demand the impossible

[calibanDNS]

You've had a much better experience with this than I have. I've only had one instance so far where I've had to tell the PM that it was impossible but the problem was that he didn't believe me. His reply was "So, you don't know how to do this?" so I gave him a mathematical proof as to why it was possible. This PM has a Masters in Strcutural Engineering from a well-respected university, so I thought that should be enough, however he simply crumpled it up and told me that he would write the code since I obviously didn't understand what he wanted. A couple of months later he raises the issue with me again and tells me that he is having trouble implementing it. Knowing that he is going to ignore my proof if I show it to him again I came up with the most basic and realistic data set that I could that would be unsolvable. I then asked him to try solving this data set by hand. Two days later when he came to me and told me that he didn't think it was possible I had to fight very hard to hold back the "I told you so" because I was hoping that this incident would convince him that in the future if I say "impossible" then he should consider the possibility of something really being impossible. Unfortunately nothing has changed and I am now looking to change jobs.

Anyone know a company that doesn't treat its developers like morons and that is hiring?

Re:Don't want to discourage you, but...

[sql*kitten]

I think you're right in this. A project manager should, in my opinion, be responsible for planning and control, and not for any tech-stuff. In my company, there is a group of persons that discusses with the customers about what they want, and what is possible. THAT's a point where tech-expertise is needen. When the specs are settled, it is handed over to a PM to make sure it gets implemented.

A project manager has a set of skills that are distinct from by complementary to the skills of an engineer. A project manager who starts their career as a project manager often has great skills for, budgeting, say, and understands the administrative details as a role. The reason that these people fail is that, lacking an engineering background, when creating plans they are unable to accurately estimate time and resource requirement, and even worse they are unable to identify critical paths, dependencies and opportunites for parallelism.

The ideal structure is to have a project manager to take care of the details, and a system architect to see the "big picture" and have overall responsibility for planning and executing the project. If the project manager is in charge, then that individual should have at leat 5 years experience "in the trenches" on similar projects, and should have the authority to set priorities and trim the feature set if necessary.

Re:Oh Please!

[Fnkmaster]

This is pure trash. The fact is that most programmers don't and don't really care to understand much about the business. That's exactly the reason that you need technical leads or TPMs who understand both the business requirements and enough of technology to make reasonable trade-off decisions, and either work closely with a business-oriented PM/requirements person, or have excellent rapport with upper-management (i.e. have their trust - not be perceived as a lying technology person).

Re:Who writes the specifications?

[deblau]

If you explain to them that their pet feature will make the project take twice as long, or three times as long, will they really still want you to do it? Or will they say, "Oh shit, well in that case forget it."

They'll say, "Find a way to make it work, on time and within budget, and laws of physics be damned". This is the primary problem with most bad PMs; they don't listen. OTOH, this is also the primary problem with most bad (i.e., non-business-knowledgable) coders. In my experience, the proper action is to communicate with the PM, find out why the feature is so important, ask if it's OK that 5 other features won't get done for this one, etc. It may be that the PM isn't clearly communicating, or it may be that the coder doesn't want to do boring work. Which do you think is the case?

If they really don't know what they are doing, then they will probably fear a paper trail that documents that you warned them the pet feature would double the time to implement.

You assume they care about the product, and that they have ethics. No, what'll probably happen is they'll either bury the report or play politics. Remember, like everthing else, shit flows downhill.

If your boss is an asshole, and says something like, "If you can't do it I will get someone who can!" Or, "If you can't do it within this time constraint I will get someone who can!" Call his or her bluff.

Yeah, that'll make you real popular. Let's play dick-swinging, chest-beating games with our boss. They'll love you after you prove them an idiot to everyone in the office and shove it in their face! Heaven forbid, maybe your boss is having a family crisis, find out what is going on before jumping to conclusions. If they're being unreasonable, then there are things you can do (talk to HR, let them know you're having problems working, see if there's an ombuds, use an employee feedback mechanism...)