Project management for non-project managers

Dear Bob ... HELP!!! They've just put me in charge of a software project. The only problem is, I don't know anything about project management and don't have time to learn. What I need from you is the answer to the question, if I don't know anything else about project management, what are the three ideas I absolutely have to understand? - Grasping at straws Dear Grasping ... You have to be kidding! Meaning no off

Dear Bob ...

HELP!!! They've just put me in charge of a software project. The only problem is, I don't know anything about project management and don't have time to learn.

What I need from you is the answer to the question, if I don't know anything else about project management, what are the three ideas I absolutely have to understand?

- Grasping at straws

Dear Grasping ...

You have to be kidding! Meaning no offense, one of the better ways for an organization to encourage project failure is to put project managers who lack sufficient training and experience in charge of projects that are too big to be acceptable learning experiences.

But in the interests of giving you at least a slight chance of success:

1. There has to be a business sponsor - someone who wants the project to succeed deep in his or her bones; who is willing to commit resources and arm-twist colleagues on its behalf; and who is willing to take responsibility for decisions that are beyond your authority. No business sponsor, no project. And ... meet with your sponsor every week to review progress and any issues that have come up.

2. The deliverables have to be clearly defined. If you and the sponsor don't know what you're supposed to build there's no way to know if you're finished or not, let alone whether you've succeeded. We're talking about tangible work products, by the way, not vague abstractions. The project's purpose might be abstract (improve throughput) but its work products can't be. They have to be something you can point to (software, documentation, and training materials, for example).

3. Every project team member has to know what he or she should be working on every week throughout the project schedule. The formal term is "Work Breakdown Structure," but it isn't anything more than an outline - a hierarchical description of the tasks, starting with big blocks of effort (interview subject matter experts) and drilling down to specifics. You don't have to do it all yourself, either. Get it down to the level of specific assignments and hand those off to project team members, instructing them to develop a detailed work plan for their assignments.

Done right, tasks should take about a week each, and there shouldn't be any question whether a task is done. Hold a status meeting every week to make sure tasks that should be done are done, and to make sure there's no question what people should be working on the following week.

Are these three concepts enough? Of course not. But if you have to choose three, they're the three I'd home in on.

Good luck with the project. You're going to need it.

- Bob