Friday, March 25, 2011
Beginners Guide to Project Management
Part 03 Where to start
Part 03: Where to start
After checking what Project Management is and where it fits, it’s time to start working. Or isn’t it? This part 3 of the Beginners Guide to Project Management covers the project start with the business needs that originate projects.
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
Start focused on the end
In general, and Project Management isn’t particular in this case, it is very useful to keep in mind what your end state is, what you need to have in order to say that your job is done. When managing a project, the project ends after you deliver the required outputs you were hired to deliver, right? That’s the “Closing the Project” part from the previous article. Now these outputs demand some work in order to come true - and this is the “Carrying out the work” part. And if you’re doing some work you should plan it before starting it so you know how long it will take, how much it will cost, what resources you’ll need and so on - the “Planning the Project” part. So what do you need to have as a Project Manager before you start planning your project - "Starting the Project" phase?
The Project Charter
If you go to the literature on Project Management, the Project Charter is the most common answer. The Project Charter is a document that authorizes the Project Manager to commit resources to deliver some outputs also described on this document on a very high level. This makes every sense in most situations as it’s a good idea to be authorized to work on whatever you’re working.
Suppose you start off doing a project to deliver some management tool for a warehouse and keep on adding features till you end up with a full Enterprise Resource Planning software including financial consolidation. This is OK, really, as long as people don’t expect it to cost the same and to take as long as it was initially estimated. So the Project Charter is most suited to use when things go wrong than to help you start doing your job, which is the point of this article.
Wants and needs
So what is it that makes you start a project? This is very clear if you think about your personal projects: you do them because you need its results! It's as simple as that, there's no rocket science here. Somehow you measure the benefits (could be money, fun, recognition, or anything else positive that sounds good to you) against the costs (could be expenses, invested time, your health lost or something else negative) and decide it’s a good idea; the same goes for the organization that asks you to do that project: for some reason, they need its results.
So my perspective on starting a project is to make sure it makes sense, that it’s useful for the organization requesting it. And then, by all means, cover your back as good as you can and get a Project Charter signed off.
So the organization wants to do a project. But do they really need to do it? If there’s no need you should discard such projects whenever you can - and point out that there’s no need for them. To evaluate this need you must start asking “Why?” a lot and to as much people involved as you can. Usually, when someone asks you to get some outputs with a project, they don’t talk much about the outcomes they want (more about outputs and outcomes on the book review of ”The Art of Funding and Implementing Ideas”, but outputs are what your project must deliver and outcomes are what the organizations wants those outputs for - for example, an output can be a new product but the outcome is the replacement of an old product to maintain the company's sales on that particular segment). And the outcomes are the most important thing at this stage so you can understand what is expected for your project to accomplish. It’s no use for anyone if you deliver what you’re hired to deliver but it’s of no use for anyone - and this happens a lot. Or is it just me?
You should start asking "Why?" to the person that is requesting you to do the project. And assert his role for the project: is he the one who benefits the most if the project is done? Is he who’s paying for the project? Was he mandated by someone else and has no interest whatsoever?
Then do the same to everyone that has a role in your project, besides the previous ones mentioned: the people who are going to use it, the people who are going to maintain it (remember the product life cycle from the previous article?), the business leaders who thought the project was a good idea, the supporting departments (Financial, Human Resources, and IT for starters) and everyone else that has a clear interest on the project at this phase: either because they’re going to benefit or suffer because of it, or because they can influence how the project runs.
I hope you’re convinced with these arguments that asking “Why?” is the best way to start a project. But I also hope you find it kind of short - because it is. Before you fill comfortable to plan the work to be done there’s a lot more to know about the project. You already know why people want these project’s outputs, but... what are the outputs? This is the next question these articles will answer: "What?"
Posted by Luis Seabra Coelho