Novice Project Planner 1

[backoffice]

I have just been pushed into designing and implementing a project plan. Where do I start?

I was going to take some courses or pick up a book, but I don't have that kind of time. I need to learn about project planning and deployment in a few hours.

Any suggestions on documentation which I can download and read it ASAP? Even if it just gets me started.

 

[mainepe]

Check out my response to DiamondOfficer three threads above, within this same theme area. For a few minutes of download effort, you can get the project management "bible". Also check out pmboulevard.com for copies of PowerPoint presentations that might be more in line with the "few hours" of study you envision.

Here's a template for writing up a project proposal; it will also work as a means to write up a project statement:
Project Name = ?
Project Statement = In one sentence each, explain what is to be done, what the project's goals are, and what the minimum deliverables must be in order to consider the project successul.
Current Situation = How are things now?
Scope of Work = What do you plan to do to change the Current Situation? What will the project's end product be?
Estimated Costs = How much do you think the project will cost, and why?
Benefits and Risks = What do you hope to gain by doing the project, what could go wrong, and how will you address the contingencies if they occur?
Initial Project Plan, Roles and Responsibilities = Who is expected to do what, when, and for how long?

Scheduling a project isn't much different from organizing your "Things To Do" list for your days off. Sit quietly for an hour, and jot down anything/everything you can think of that needs to be done, then sequence the list so it can be done as efficiently as possible and so it reflects "dependencies" (things that must happen before/after other tasks). Next, estimate how long it will take to do each thing, pick a start date, and then estimate the project schedule based on the task sequence and task durations you estimated.

A low-end, though effective, tool for doing this on relatively small, linear projects is MS Excel. I type my thoughts in, put sequential numbers in next to the steps, sort all the data wrt the sequence numbers until I'm happy they're in the right order, and then estimate the durations.

If you understand the work pretty well, then duration estimating will be your bigger challenge. I usually do a "best guess", then augment that with an optimistic (if everything went really, really fantastic, how fast could I get it done?) and a pessimistic (if everything goes really, really bad, what's the worst-case longest time I think this task could take?) estimate. Then combine the duration estimates as follows to compute the task duration to include in your plan:
Plan Task Duration = [Optimistic Duration + (4 * Best Guess Duration) + Pessimistic Duration] / 6

This, too, can be coded in Excel.

One may be tempted to use the Pessimistic estimates for everything, but that's inappropriate because it's not fair to the customer. My approach is an accepted standard practice that accounts for uncertainty in the estimates, and thus protects both the estimator/project manager and the customer.

Ouila, backoffice, eight hours later you will have a "project plan"!

 

[Trainingjason]

In your case, I would buy the step by step guide to ms project.

In it simplist manner using ms project,

Break the tasks downs into phases
Then break the phases down into tasks
When setting the durations give a little leaway, but make it realistic - you may need to research
if people need to travel then take this as another task


Look at your resources, they normally fall into the following categories
people, equipment, materials, rooms

Assign the people equipment material and rooms
Making sure you appreciate the difference between
effect driven 2 people working on a project the time halfs.
Non effort driven, travelling from manchester to london does not reduce if more people are in the car.

If you do not have enough resources, or can not meet the time scale given, then pray. Be careful of responsibility without authority. Go back to your manager and state what resources or extra time you need. Do not give them problems only solutions.

This is a very simplified way to create a basic plan.
If you need more help email

Trainingjason@aol.com
(MS Project Trainer)

 

[greavsie]

To get you up and running with a plan. Look at the scope of the work to carried out within the plan. Draw yourself a workbreak down structure. This WBS can be in phases and also include products. Then consider how this wbs reflects the organisation of your teams. From this comparison you should be able to allocate responsibilities into the wbs. This allows you and the person responsible for delivering the plan to discuss and define the activities, timescales, logic, resources etc. Remember although you prepare the plan you may not be the owner.

 

[elizabeth]

PMI considers the project plan to be the entire plan document, but many people who use automated tools such as MS Project use the phrase project plan to mean the MS Project Schedule. If you don't have much time, the best place to start is really the same place to start if you do: the Project Charter.

Many of the other sites mentioned in this and other posts show a Project Charter template. The point is to get an overview - 1 or 2 pages - to make sure all project stakeholders (steering committee, management, project manager, team members, customers) have the same understanding of the project at a high level. If you don't do this first, you will likely find yourself doing a lot of re-work, and taking all the blame for any misunderstandings.

The preferred method of creating a Project Charter is to sit down with the Project Sponsor/Steering Committee, ask open-ended questions, and hash out the wording during the meeting. But often you have to take a stab at it yourself and then meet with them to modify it. So the Project Charter helps you create a shared understanding of the project at the outset, then it remains your touchpoint throughout the project, as expectations invariably change during the project. Most of the remaining Project Plan documents flow from the Charter, such as the Scope document, the WBS, SOW, Roles & Responsibilities, Schedule, and Budget. When conflicts arise, you look to the Project Charter rather than get into individual opinions and finger-pointing.