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

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: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).