Friday, April 1, 2011

Beginners Guide to Project Management
Part 04 What to do

On this article you’ll find the necessary information on what you need to know about your project outputs prior to planning, namely what your projects outputs are.

Previously on “Beginners guide to Project Management”
Part 01 – What is Project Management
  • Defining a project
  • Defining what isn’t a project
  • What is Project Management
  • Where do projects come from
  • Outcomes and outputs
Part 02 – Context for Project Management
  • The project life cycle
  • The product life cycle
  • The Project Manager
  • Project success
Part 03 - Where to start
  • Start focused on the end
  • The Project Charter
  • Wants and needs
  • Why?
Outputs and outcomes, again
So by now you already know why your project is necessary. And you should have a good idea what are the outcomes that your project is supposed to help achieve. So the next step is to check what are the outputs you have to deliver. Just don’t forget that the project outputs or deliverables have the purpose to help the organization achieve the intended outcomes.

The Project Charter, again
The Project Charter should include a high level description of the work to be done and hence it should include the outputs or deliverables of the project. The thing with the Project Charter is that (i) either you built the Project Charter yourself or (ii) it was given to you as is. In any case, there should be a scope description in it that you, as a project manager, must understand. After all, you’re the one who’s going to build it, right?

About scope
Scope has a special meaning for project managers. In practice, it translates into the “Why?”, “What?” and “How?” and you should use them accordingly to your audience. If you’re discussing your project with:
- a board, you should probably stick with the “Why?” bit;
- functional managers, you should probably stick with the “What?” bit;
- the project team, you should probably stick with the “How?” bit.
But discussing the scope of the project is a bad idea. What part of the scope are you talking about? The reasons (why), the outputs (what) or the tasks (how)?
Just a note: The first time I saw this so formalized was on a webinar by Bob Jewell.

The “What” part
The “Why” part was covered on the previous article and we’ll leave the “How” bit to planning, which will be in the next articles. But even prior to planning you should have a good idea about what your project will deliver. And make sure that what is written in the Project Charter is what is really needed by the organization. The only way I know to accomplish this is, again like in the “Why” bit, by talking to people involved in the project. The next paragraphs include the most important things you should be worried about when discussing the “What” with the people involved.

Alternative outputs
Are there other ways to help the organization achieve the outcomes it needs? If you can, try to get 3 different sets of outputs that still enable the organization to get the required outcomes: the cheapest ones (with a focus on cost), the fastest (with a focus on time) and the best (with a focus on quality). In most cases, the outputs you will be contracted to deliver is a combination of outputs from these different sets. And sometimes, there is only one set of outputs that will satisfy the required outcome.

Wants and needs
Sometimes wants and needs sound the same, but wants and needs are different things. Keep this in mind at all times and focus on the needs. If someone expresses a want in a meeting, explore it and question the person until you get to the needs behind that want. This is not always easy, but it’s essential to succeed.

You’re not planning
It’s all too easy to see yourself planning the project in these meetings. It’s good to keep in mind that you are not planning what you will deliver yet. You’re just checking out if there are alternative ways, if it makes sense, if this project is what is needed. And you’re not committing yourself. Yet.

Next steps
The next article on this series will be a case study that will serve as a guide. The objective is to have a fictional project where these suggestions are applied to so you can have a feeling of how you can apply this guide to real case scenarios.

Posted by

No comments: