I recently began to read an excellent book about project management : Manage It! (pragprog)… I’m far from having finished it, but some sections in different chapters requested all my attention.

It would be too long to review all chapters of the book, so i invite you to read it – but there is one point we often forget in some crappy situations : must know when it’s time to leave. You at least have the choices : accept the current state with opened eyes, moving  to another project in the organization or changing organizations.

The author gives here some warning signs to consider (imagine you are a PM for the following content)

- You have no choice about team members : Many project managers manage projects where team members move with them from project to project. And you have a team member who’s not doing the work you need performed, and you can’t move that person off your team (assuming you have provided feedback about the work or the person’s behavior).

You need to move people off your team when they’re not working out. If you can’t , maybe it’s time for you to move to a different project , or out of the organization.

- Meeting attendance is political: If you can’t choose which meetings to attend because a big Cheese is watching who’s there and who’s not, why are you wasting your time in this organization?

- Your sponsor hangs you out to dry: You’ve asked your sponsor to imagine the end of the project when things aren’t quite right, and you sponsor says “I’ll have your head” – i don’t know many people who work well when they thing they’re being threatened or feel it’s all their fault if the project doesn’t succeed.

- Your sponsor insists that people multitask and won’t take “no” for an answer: You’ve explained the slackdown effects of multitasking, and your sponsor won’t decide which projects are top priority.

If the people who are paid for the big bucks won’t make the project portfolio decisions, ask yourself why you’re accepting a no-win position by managing a project that can’t succeed.

- You’re supposed to contribute technically to the project: You’ve got more than  three other people on this project. And you’re still supposed to write code, test, write documentation, whatever. Somehow, you’re supposed to be a technical contributor in your spare time, when you’re not managing the project.

Managers who write code, they’re not managing the risks, they’re not attending to the testing, they’re not generating the dashboard, and they’re not assessing release criteria. If you work in a meeting-happy place, you’ll need to add all the meetings to your list of work.

If you’re managing the project, helping people see the goal, removing obstacles, and monitoring the progress, you don’t have time to contribute technically.

- All of your projects start with insufficient resources : It’s so tempting to be the hero and save the company. But you’re not doing the team any good when you roll over and accept less than reasonable conditions to start the project. Starting the project with insufficient resources is unacceptable.

If you can’t help your management decide what’s driving the project, you aren’t right for this organization. The organization will continue to take advantage of your good nature  and push you into death march projects.

- You hear “You’re not a team player” all the time: Your job as a PM is to think the project is the most important work the organization has and to act that way. If you act such a way to make your project succees and you hear “You’re not a team player”, then you might not be what this organization needs.

When you’re not right for the team :

- You don’t know enough to manage the project :

- Do you understand how the team works? if you don’t understand the team workflow and the workflow is working for the team, you might not know ebough to manage the process risks for this project.

- Do you understand the problems this project solves ? If you can’t understand the problems, you can’t help to create useful release criteria.

Your manager inflicts help on the team and you can’t push back: We’ve all worked with managers who want to inflict help. And sometimes you allow the manager to “help” the team, and you don’t push back.

If you can’t keep that manager away fron your team, you are not removing obstacles from the team.

- You know too much to manage this project: You have tons of technical experience. And you’ve managed projects before. But this project is near and dear your technical heart.

If you can’t remove yourself from architecture or design so that you can concentrate on managing the project, it’s time to choose. Either manage this project or become one of the technical staff. But don’t try to do both.

When you’re not right for the product

- You don’t have the solution-space domain expertise – and neither does anyone else. You don’t always need solution-space domain expertise to run a great project. But if you don’t have the technical depth in your project team, then none of you understands the technical risks. Decide wether you want to stay with this project.