Slashdot Mirror
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?"
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.
No Zen is good zen
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
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.
Trusted Computing FAQ | Free Dawit Isaak!
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.
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.
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).