I've been reading a lot of anecdotes about bad specs and similar. I have my own, but they are mild compared to what some people have posted here. But a lot of the time, I do not agree with people who say "I should have got better specs" or "I should have made the client sign off on the changes". Somebody should have done it, but if your job description is "programmer" then maybe it shouldn't be you.

A lot of the stories posted are examples of poor project management by someone else. I am not pointing a finger at anyone in the monastary here because the teller of the tale usually is the victim of a bit of gratuitous corporate mismanagement.

Project management is a specific job, it doesn't just mean "the manager of a project". Sometimes it's hard to explain exactly what a project manager does. Jokes abound, like "they take the all blame when things go wrong, and none of the credit when things go right". Partially this is because their job is to make sure that nothing goes wrong. Maybe a description of a good PM is someone who finds out the what everyone needs to complete the project, and sees that those needs are filled. Project management became recognised at the middle of the century during the giant construction projects where there was a need to coordinate thousands of workers, sub-contractors and suppliers to achieve a goal.

As I have presented it, it sounds like nothing you would ever want to be near, but almost all software development is done project style. Even on a one person job that takes a week, you can use many project techniques to make sure you are successful. A six month project should definately use PM techniques.

Another good reason for reading up on the subject is that you will know what your boss should be doing. Many managers do not understand project management at all. "Ordinary" managers often make terrible project managers.

Insufficient specs and scope creep are project management issues, not the fault of the programmer doing the actual coding. If you are in the awful position of being both the project manager and the coder, you will need these techniques all the more. I can't describe them here, and giving a sample would be unfair, like describing Perl as just a scripting language.

I can recommend a place to start, however. The Project Management Institute publishes a reference called the "Project Management Body of Knowledge". This book is the distilled wisdom of project managers. On the back cover it recommends itself to project managers, project team members and project customers and other stakeholders. ISBN: 1-880410-12-5.

The book has advice on defining projects, stopping scope creep, detail on project phases, and much more. After reading it you will understand why having clients asking for changes during testing is a sign of project failure, and how you can prevent it happening right at the start of the project. The only thing it desn't teach you is social engineering - a vital skill for project managers.

If you feel like you are out of control, being victimised by the whims of management and clients, unable to define goals for your project and achieve them... grab the book and learn. There are courses as well.

Disclaimer: I am not associated with the PMI. Heck, at the moment I'm not even associated with a company. But I've worked on enough projects to appreciate a really good PM.

____________________
Jeremy
I didn't believe in evil until I dated it.