Project Planning means different things to different people. To some the Project Plan is all of the project management documentation: the project definition document, organisation chart, quality plan, schedule, change control procedure, risk management strategy, etc. (And some use the term Quality Plan to mean all of these.) To others the Project Plan is simply the schedule that shows who will do which work tasks and when, and to them Project Planning is the act of building this schedule.
Here we will use the term Project Planning in this second sense: building the task
by task schedule which we will call the Project Plan.
(If you prefer the terms Project Scheduling and Project Schedule please do a
Large projects and small projects are very different animals in terms of the Project Planning that they need. For a very small project a back-of-an-envelope plan may be perfectly adequate. There might even be no written down plan at all.
But for a large project the Project Planning will need to produce a detailed, formal plan showing precisely who will do which bits of work and when.
Project Planning conceals a trap for the unwary. Most project leaders get experience
of Project Planning on small projects.
They learn a lesson over and over again: you don't need to bother with all that formal
Project Planning stuff. And they're right, you don't need to do much, if any,
formal Project Planning on a small project. But you then give that person a large
project, they know they don't need to bother with formal
Project Planning, so they don't. And you have a disaster in the making.
The course (Project Management Course in UK) shows how Project Planning might be done for a small project and also how Project Planning should be done for large projects. The course stresses that Project Planning is not about knowing how to use a planning tool, such a Microsoft Project or Track-It. Knowing how to use a planning tool is not the same as knowing how to do Project Planning. Whether the Project Planning produces a plan that is shown as a Pert network, a Gantt chart, bar chart, precedence diagram or whatever doesn't much affect how you go about the intellectual job of Project Planning. The course focuses on the important job: building the plan.
The course discusses many aspects of Project Planning including:
Ever finished your Project Planning, built a fine project plan but then found after a couple of weeks that the work wasn't progressing as per the project plan? What did you do - put the project plan in a drawer and forget it? Or revise the project plan to reflect the ways things were? The course discusses the thorny issue of how much it is worth investing in keeping the project plan up to date and offers guidance. Replanning is an important aspect of Project Planning.
Is it really worth having everyone record how many hours they worked? Should we just
record all the hours against a single project time code or should we record hours worked
on each individual project task? And what should we do with all that data! The course shows
how this valuable information can be exploited and how to sell time recording to the project
team (not always easy!). One of the primary reasons for Project Planning is to build
a project plan that you can track progress against. If you don't track actual status against the
project plan you're not really exploiting the investment you made in Project Planning.
Project Planning is one of the topics covered in this
Project Management Course.
Project Management in the Public Sector
Quality Management in Software Development Projects
The Tale of Three Project Managers
Towards a Project-Centric World
Project Management Proverbs, Saying, Laws and Jokes
So You Want To Be A Project Manager?
Free Online Project Management Book
Copyright M Harding Roberts
project planning project scheduling project planning and scheduling planning scheduling project plan schedule task planning activity scheduling project planning scheduling