Project Planning Guide

The key to a successful project is in the planning. Creating a project plan is the first thing you should do when
undertaking any kind of project.

Often project planning is ignored in favour of getting on with the work. However, many people fail to realise
the value of a project plan in saving time, money and many problems.

This article looks at a simple, practical approach to project planning. On completion of this guide, you should
have a sound project planning approach that you can use for future projects.

Step 1: Project Goals

A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or
indirectly impacted by the project.

As a first step, it is important to identify the stakeholders in your project. It is not always easy to identify the
stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are:

 The project sponsor.

 The customer who receives the deliverables.
 The users of the project outputs.
 The project manager and project team.

Once you understand who the stakeholders are, the next step is to find out their needs. The best way to do this is
by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real
benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be
recorded and set as a low priority.

The next step, once you have conducted all the interviews, and have a comprehensive list of needs is to
prioritise them. From the prioritised list, create a set of goals that can be easily measured. A technique for doing
this is to review them against the SMART principle. This way it will be easy to know when a goal has been
achieved.

Once you have established a clear set of goals, they should be recorded in the project plan. It can be useful to
also include the needs and expectations of your stakeholders.

This is the most difficult part of the planning process completed. It's time to move on and look at the project
deliverables.

Step 2: Project Deliverables

Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet
those goals. Specify when and how each item must be delivered.

Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be
established during the scheduling phase, which is next.
Step 3: Project Schedule

Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify
the following:

 The amount of effort (hours or days) required to complete the task.

 The resource who will carry out the task.

Once you have established the amount of effort for each task, you can work-out the effort required for each
deliverable, and an accurate delivery date. Update your deliverables section with the more accurate delivery
dates.

At this point in the planning, you could choose to use a software package such as Microsoft Project to create
your project schedule. Alternatively, use one of the many free templates available. Input all of the deliverables,
tasks, durations and the resources who will complete each task.

A common problem discovered at this point, is when a project has an imposed delivery deadline from the
sponsor that is not realistic based on your estimates. If you discover this is the case, you must contact the
sponsor immediately. The options you have in this situation are:

 Renegotiate the deadline (project delay).

 Employ additional resources (increased cost).
 Reduce the scope of the project (less delivered).

Use the project schedule to justify pursuing one of these options.

Step 4: Supporting Plans

This section deals with plans you should create as part of the planning process. These can be included directly
in the plan.

Human Resource Plan

Identify by name, the individuals and organisations with a leading role in the project. For each, describe their
roles and responsibilities on the project.

Next, describe the number and type of people needed to carry-out the project. For each resource detail start
dates, estimated duration and the method you will use for obtaining them.

Create a single sheet containing this information.

Communications Plan

Create a document showing who needs to be kept informed about the project and how they will receive the
information. The most common mechanism is a weekly or monthly progress report, describing how the project
is performing, milestones achieved and work planned for the next period.

Risk Management Plan

Risk management is an important part of project management. Although often overlooked, it is important to
identify as many risks to your project as possible, and be prepared if something bad happens.
Here are some examples of common project risks:

 Time and cost estimates too optimistic.

 Customer review and feedback cycle too slow.
 Unexpected budget cuts.
 Unclear roles and responsibilities.
 Stakeholder input is not sought, or their needs are not properly understood.
 Stakeholders changing requirements after the project has started.
 Stakeholders adding new requirements after the project has started.
 Poor communication resulting in misunderstandings, quality problems and rework.
 Lack of resource commitment.

Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log; write down
what you will do in the event it occurs, and what you will do to prevent it from occurring. Review your risk log
on a regular basis, adding new risks as they occur during the life of the project. Remember, when risks are
ignored they don't go away.

Congratulations. Having followed all the steps above, you should have a good project plan. Remember to
update your plan as the project progresses, and measure progress against the plan.

Goals and Objectives

Goals and objectives are statements that describe what the project will accomplish, or the business value the
project will achieve.

Goals are high level statements that provide overall context for what the project is trying to achieve, and
should align to business goals.

Objectives are lower level statements that describe the specific, tangible products and deliverables that
the project will deliver. The definition of goals and objectives is more of an art than a science, and it can be difficult to
define them and align them correctly.

Objectives are concrete statements describing what the project is trying to achieve. The objective should be written at a
lower level, so that it can be evaluated at the conclusion of a project to see whether it was achieved or not . Goal
statements are designed to be vague. Objectives should not be vague.
A well-worded objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound (SMART

Goals
Goals are high-level statements that provide the overall context for what the project is trying to accomplish. Let's look at
an example and some of the characteristics of a goal statement. One of the goals of a project might be to "increase the
overall satisfaction levels for clients calling to the company helpdesk with support needs".

The "Real" Project Plan

"I need a project plan by tomorrow morning." As project managers, that's what we hear. But we know that what
the boss usually means is that s/he wants a project schedule. There is a problem though, how can you come up
with a schedule without having the "real" project plan first?
The project plan, or project management plan as defined by PMI (for simplicity, we'll call it project plan in this
article), is completely different from a project schedule and is the result of the planning processes. A change in
the project plan can affect the project schedule. The project plan describes how the project work will be
performed. It is the primary source of information for how the project will be planned, executed, monitored,
controlled and closed.

The development of the project plan is an iterative process in itself. It is composed of a single document or a
master document with a series of subsidiary documents, each defining one or several areas of the project
management process.

The project plan content varies based on the project scope and complexity of the project. PMI says that the plan
includes:

 The project management processes selected by the project management team.

 The level of implementation of each selected process.
 The descriptions of the tools and techniques to be used for accomplishing those processes.
 How the selected processes will be used to manage the specific project, including the dependencies and
interactions among those processes, and the essential inputs and outputs.
 How work will be executed to accomplish the project objectives.
 How changes will be monitored and controlled.
 How configuration management will be performed.
 How integrity of the performance measurement baselines will be determined and used.
 The need and techniques for communicating among stakeholders.
 The selected project life cycle and, for multi-phase projects, the associated project phases.
 Key management reviews for content, extent, and timing to facilitate addressing open issues and pending
decisions.

A subsidiary plan may include but is not limited to:

 Project scope management plan;

 Schedule management plan.
 Cost management plan.
 Quality management plan.
 Process improvement plan.
 Staffing management plan.
 Communication management plan.
 Risk management plan.
 Procurement management plan.

Project scope is the part of project planning that involves determining and documenting a list of specific
project goals, deliverables, tasks, costs and deadlines.

The documentation of a project's scope, which is called a scope statement, terms of reference or statement of
work, explains the boundaries of the project, establishes responsibilities for each team member and sets up
procedures for how completed work will be verified and approved. During the project, this documentation helps
the project team remain focused and on task. The scope statement also provides the project team with guidelines
for making decisions about change requests during the project.

Writing a successful scope statement means that you include directly, or by reference, other documents,
including your:

 Project justification
  Project product
 Project deliverables
 Project objectives

The plan may include these other components, once they are known, in a subsequent iteration, but is not limited
to:

 A milestone list.
 A resource calendar.
 A schedule baseline.
 A cost baseline.
 A quality baseline.
 A risk register.

A project plan is not a one-time deliverable that remains static throughout the project. Updates arising from
approved changes during project execution may significantly impact parts of the plan. The project plan must be
kept in sync with approved changes and this is an iterative and ongoing process called rolling wave planning
and the results of these iterations are documented as updates to the project plan.

Now that we know what a "real" project plan is, it is time your boss does too. Don't you think so...? Well, I do.

Five Essential Elements of Project Management

Initiate. The initiation process authorizes the overall project or the next phase of a project. In this phase, project objectives
are established, scope is defined, and responsible parties and deliverables are identified.

Plan. The planning processes are precisely that--the defining and refining of the best courses of action to take to attain the
project objectives. Planning falls into two categories: core planning processes and facilitating processes.

Core processes are those that have clear dependencies that require them to be performed in essentially the same order on

most projects. Examples include scope planning, schedule development, resource planning, and cost budgeting.

Facilitating processes are entirely dependent on the nature of the project and are performed intermittently and as needed--

though they are not optional. Some of the facilitating planning processes include quality planning, staff acquisition, and risk

identification.

Execute. Planning paves the way for executing, which involves coordinating resources, human and otherwise, to carry out
the overall project plan. Because of the ongoing role execution plays in project management, its processes are also divided

into core and facilitating subgroups. The central core process, project plan execution, oversees facilitating processes such as

team development, information distribution, and solicitation.

Monitor and control. As the figure below shows, controlling processes have a strong presence in all but one of the
project management stages. These processes ensure not only that project objectives are met, but also that corrective action

can be taken should a problem arise. In this phase, performance reporting and risk monitoring and control are core. These

watchdog processes work with facilitating processes such as cost control, quality control, and schedule control to ensure the

project stays on track.

Nine Knowledge Area Definitions

Project Integration Management This process coordinates the other areas to work together throughout the
project.

Project Scope Management is a set of processes used to ensure that the project includes all of the
requirements and no new requirements are added in a way that could harm the project.

Time Management involves processes to ensure that the project is completed on schedule.

Cost Management involves processes to ensure that the project is completed on budget.

Quality Management ensures that the project meets its requirements, or does what it is expected to do.

Human Resource Management includes all of the processes used to develop, manage and put the project
team together.

Communication Management determines what information is needed, how that information will be sent
and managed, and how project performance will be reported.

Risk Management involves identifying, managing and controlling risk of a project.

Procurement Management is the group of processes used to acquire the materials and services needed
to complete the project.

What is Project Management?

More specifically, what is a project? It’s a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a
project team often includes people who don’t usually work together – sometimes from different organizations and across multiple
geographies.

The development of software for an improved business process, the construction of a building or bridge, the relief effort after a natural
disaster, the expansion of sales into a new geographic market — all are projects.

And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need.

In order for any business to benefit from the successful conclusion of a project, the initiation of the project must be agreed to and based
on business criteria targeting specific SMART business objectives.

All projects must be measured and prioritized against this criteria, presented to senior management for approval, and then initiated
based on management direction and business priorities

Project management, then, is the application of knowledge, skills and techniques to execute projects effectively and efficiently. It’s a
strategic competency for organizations, enabling them to tie project results to business goals — and thus, better compete in their
markets.

It has always been practiced informally, but began to emerge as a distinct profession in the mid-20th century. PMI’s A Guide to the
Project Management Body of Knowledge (PMBOK® Guide) identifies its recurring elements:
Project management processes fall into five groups:

A project goes through six phases during its life:

1. Project Definition: Defining the goals, objectives and critical success factors for the project.
2.
3. Project Initiation: Everything that is needed to set-up the project before work can start.
4.
5. Project Planning: Detailed plans of how the work will be carried out including time, cost and resource
estimates.
6.
7. Project Execution: Doing the work to deliver the product, service or desired outcome.
8.
9. Project Monitoring & Control: Ensuring that a project stays on track and taking corrective action to
ensure it does.
10. Project Closure: Formal acceptance of the deliverables and disbanding of all the elements that were
required to run the project.

Project management knowledge draws on nine areas:

Integration Scope Time

Cost Quality Procurement
Human
Communications Risk management
resources

All management is concerned with these, of course. But project management brings a unique focus shaped by the goals,
resources and schedule of each project. The value of that focus is proved by the rapid, worldwide growth of project
management:

Definition of 'Project Management'

The planning and organization of an organization's resources in order to move a specific task, event or duty toward
completion; project management typically involves a one-time project rather than an ongoing activity, and resources
managed include both human and financial capital.

A project manager will help define the goals and objectives of the project, determine when the various project components
are to be completed and by whom, and create quality control checks to ensure that completed components meet a certain
standard.

'Project Management'

Project management is often closely associated with engineering projects, which typically have a complex set of
components that have to be completed and assembled in a set fashion in order to create a functioning product. Project
managers use visual representations of workflow, such as Gantt charts and PERT charts, to determine which tasks are to
be completed by which departments

Read more: http://www.investopedia.com/terms/p/project-management.asp#ixzz2AiMDJb7L

What is Project Management

Project management is the science (and art) of organizing the components of a project, whether the project is development
of a new product, the launch of a new service, a marketing campaign, or a wedding. A project isn't something that's part of
normal business operations. It's typically created once, it's temporary, and it's specific. As one expert notes, "It has a
beginning and an end." A project consumes resources (whether people, cash, materials, or time), and it has funding limits.

Project Management Basics

No matter what the type of project, project management typically follows the same pattern:

1. Definition
2. Planning
3. Execution
4. Control
5. Closure

Defining the Project

In this stage the project manager defines what the project is and what the users hope to achieve by undertaking the project.
This phase also includes a list of project deliverables, the outcome of a specific set of activities. The project manager works
with the business sponsor or manager who wants to have the project implemented and other stakeholders -- those who
have a vested interest in the outcome of the project.

Planning the Project

Define all project activities. In this stage, the project manager lists all activities or tasks, how the tasks are related, how long
each task will take, and how each tasks is tied to a specific deadline. This phase also allows the project manager to define
relationships between tasks, so that, for example, if one task is x number of days late, the project tasks related to it will also
reflect a comparable delay. Likewise, the project manager can set milestones, dates by which important aspects of the
project need to be met.

Define requirements for completing the project. In this stage, the project manager identifies how many people (often referred
to as "resources") and how much expense ("cost") is involved in the project, as well as any other requirements that are
necessary for completing the project. The project manager will also need to manage assumptions and risks related to the
project. The project manager will also want to identify project constraints. Constraints typically relate to schedule, resources,
budget, and scope. A change in one constraint will typically affect the other constraints. For example, a budget constraint
may affect the number of people who can work on the project, thereby imposing a resource constraint. Likewise, if additional
features are added as part of project scope, that could affect scheduling, resources, and budget.

Executing the Project

Build the project team. In this phase, the project manager knows how many resources and how much budget he or she has
to work with for the project. The project manager then assigns those resources and allocates budget to various tasks in the
project. Now the work of the project begins.

Controlling the Project

The project manager is in charge of updating the project plans to reflect actual time elapsed for each task. By keeping up
with the details of progress, the project manager is able to understand how well the project is progressing overall. A product
such as Microsoft Project facilitates the administrative aspects of project management.

Closure of the Project

In this stage, the project manager and business owner pull together the project team and those who have an interest in the
outcome of the project (stakeholders) to analyze the final outcome of the project.

Time, Money, Scope

Frequently, people refer to project management as having three components: time, money, and scope. Reducing or
increasing any one of the three will probably have an impact on the other two. If a company reduces the amount of time it
can spend on a project, that will affect the scope (what can be included in the project) as well as the cost (since additional
people or resources may be required to meet the abbreviated schedule).

Project Portfolio Management

Recent trends in project management include project portfolio management (PPM). PPM is a move by organizations to get
control over numerous projects by evaluating how well each project aligns with strategic goals and quantifying its value. An
organization will typically be working on multiple projects, each resulting in potentially differing amounts of return or value.
The company or agency may decide to eliminate those projects with a lower return in order to dedicate greater resources to
the remaining projects or in order to preserve the projects with the highest return or value.

Project Management Resources

The role of the project manager is one of great responsibility. It is the project manager's job to direct,
supervise and control the project from beginning to end. Project managers should not carry out project work,
managing the project is enough. Here are some of the activities that must be undertaken:

 The project manager must define the project, reduce it to a set of manageable tasks, obtain appropriate
resources and build a team to perform the work.
 The project manager must set the final goal for the project and motivate his/her team to complete the
project on time.
 The project manager must inform all stakeholders of progress on a regular basis.
 The project manager must assess and monitor risks to the project and mitigate them.
 No project ever goes exactly as planned, so project managers must learn to adapt to and manage change.

A project manager must have a range of skills, such as:

 Leadership;
 People management (customers, suppliers, functional managers and project team);
 Effective communication (verbal and written);
 Influencing;
 Negotiation;
 Conflict management;
  Planning;
 Contract management;
 Estimating;
 Problem solving;
 Creative thinking; and
 Time management.

"Project managers bear ultimate responsibility for making things happen. Traditionally, they have carried out
this role as mere implementers. To do their jobs they needed to have basic administrative and technical
competencies. Today they play a far broader role. In addition to the traditional skills, they need to have business
skills, customer relations skills, and political skills. Psychologically, they must be results-oriented self-starters
with a high tolerance for ambiguity, because little is clear-cut in today's tumultuous business environment.
Shortcomings in any of these areas can lead to project failure." - J. Davidson Frame

Many things can go wrong in project management. These things are often called barriers. Here
are some possible barriers:

 Poor communication;
 Disagreement;
 Misunderstandings;
 Bad weather;
 Union strikes;
 Personality conflicts;
 Poor management; and
 Poorly defined goals and objectives.

A good project management discipline will not eliminate all risks, issues and surprises, but will
provide standard processes and procedures to deal with them and help prevent the following:

 Projects finishing late, exceeding budget or not meeting customer expectations.

 Inconsistency between the processes and procedures used by projects managers, leading to some being
favored more than others.
 Successful projects, despite a lack of planning, achieved through high stress levels, goodwill and
significant amounts of overtime.
 Project management seen as not adding value and as a waste of time and money.
 Unforeseen internal and/or external events impacting the project.

Project management is about creating an environment and conditions in which a defined goal or objective can
be achieved in a controlled manner by a team of people.

Planning a Project Using a Work Breakdown

Structure & Logic Network
By Duncan Haughey, PMP

Projects don't just happen they need planning. Involve the whole project team in developing the plan, not just
the project manager. This ensures team members experience is considered and each person is fully committed
to, and has ownership of the plan. A good project plan provides the following:

 A road map (including clear milestones) everyone in the team can follow.
 A realistic project timescale.
 Details of resource requirements.
 Validation of the estimated cost.
 Identification of task slippage.
 Early warning of problems.

It pays to use previous experience and lessons learned from similar projects.

 How long did it take?

 How much did it cost?
 What were the problem areas?
 What were the successful areas?

Running a project without a plan is foolish. Working without knowing where you are going is likely to lead to
problems and possible failure. Running a project without a plan, is like trying to find your way in a strange city
without a map. As the saying has it, "If you fail to plan, you are planning to fail."

Work Breakdown Structure (WBS)

To identify the individual tasks in a project, it is useful to create a Work Breakdown Structure. The WBS is the
foundation for the detailed project plan. Get the team together and brainstorm all the tasks and subtasks in the
project, in no particular order. Write them down on sticky notes and put them on a whiteboard. Once everyone
has thought of as many tasks as they can, arrange the sticky notes into groups under the major areas of activity.
Add, change, remove and shuffle the sticky notes until the WBS is accurate, complete and logical. The purpose
of a WBS is to decompose the project into steps and sub steps.

Logic Network (Time Chart)

A Logic Network shows the sequence of activities in a project across time. It shows which activity logically
precedes or follows another. Create a Start (left) and End (right) sticky note and put them on the whiteboard.
Arrange the WBS sticky notes in the logical sequence of activities from left to right. Join the notes with an
arrow in and out; some may have more than one arrow. All connecting lines on a network enter at the left
(beginning) of the activity box (sticky note) and exit at the right (ending). Lines do not enter the top or exit the
bottom of the activity box. Unconnected lines are not allowed. All activities must connect to another activity, or
the start or end of the project. Write the time every activity will take on each sticky note to calculate the project
duration. You have created a Logic Network that will help you understand the dependencies in your project,
timescale and its workflow. This technique can reveal important information that could be overlooked.

Milestones

Look for milestones in your Logic Network. A natural milestone may occur any time a series of parallel
activities come together in a point. Control the project by defining a concrete deliverable for each milestone. A
concrete deliverable is something you can see or touch such as a design specification, prototype, model,
software module.
Using Project Management Software

The information from your WBS and Logic Network can be input into a software package such as Microsoft
Project to provide a detailed plan. Enter the tasks, predecessors, resources and time estimates into the software.
Once entered, the software will create the charts and graphs automatically. Don't expect the software to plan or
manage the project; it's just a tool.

Checklist

Here is a checklist to help you create a well thought out, detailed project plan while building a committed high
performing team.

1. Define what needs to be done using a Work Breakdown Structure.

2. Discover the best approach for getting everything done by developing a Logic Network.
3. Develop work and duration estimates of how long each team member needs for each task.
4. Calculate how long the project will take to complete its critical path and milestone schedule using the Logic
Network.
5. Calculate and chart the number of people needed and the percentage of each team member's time for each
phase of the project.
6. Adjust and refine the project plan to level individual workloads and smooth the number of people needed
during the project.
7. Creatively optimise trade-offs to deliver the best results in the shortest time.
8. Use the joint planning process to intensify team members' commitment and ownership.

Project Plans: 10 Essential Elements

By Trevor Roberts 9 Feb, 2009

Firstly, I need to make sure we are all on the same page when it comes to what a plan is. Many people (and a
distressing number of project managers, too) think only of a Gantt chart when they think of a project plan. You
may recognise it as what you get from Microsoft Project. This is better called a project schedule, in that it shows
when we expect the various sections of the project to happen. We will come back to this later.

What we want to have in our project plan is:

1. Aim of project
2. Outputs
3. Quality criteria
4. Resources
5. Management structure
6. Milestones
7. Tolerances
8. Dependencies
9. Risks
10. Schedule

Let's have a look at these in turn, and see why they are needed, and what we want to achieve with each of them.
1. Aim of Project

What do we want to produce? The aim of the project is a mixture of the reasons for doing the project and the
benefits that are expected from it. This section of the plan can be either fulfilled by linking to the main business
case, or by restating it in language for the expected audience. For example, your business case may have been
written for high level approval in your organisation. You may want to now put it in terms the project executive
expects.

2. Outputs

Given the aim of the project, what do we actually need to produce to get there? What will your completed
project be made up of? These need to be clearly defined. For example, your project's aim may be to upgrade the
IT infrastructure in an organisation. Your final output would be a completed computer network, a new computer
on every desk, and all appropriate software installed and ready to go.

3. Quality Criteria

Now we have the outputs, we need to understand what quality they need to be of. In the example above, we
have an output of a completed computer network. However, we need to know that the network can actually
cope with the amount of traffic going over it!

This means we need the completed output to be of a certain quality, and we need to define what that quality is.
These targets tell you what success is, what completion of the project is. They need to be SMART:

 Specific: Clearly defined and precise.

 Measurable: e.g. not "new computers," but "computers with 2Gb of memory," etc.
 Attainable: Don't ask for the impossible.
 Relevant: Is the criterion actually related to the aim of the project?
 Time-based: Enough time to achieve this. There is no point expecting a year's worth of work in one week!

It is important you take some time with the stakeholders in your project to produce this list. The final customer
of the project will naturally be very involved, but don't forget your business head - don't promise everything
without considering the costs. Your project executive, and a representative of those who will be doing the work,
will have major inputs into this also.

Finally, you will also need to decide who has the final say over the quality of the outputs. Hopefully your work
on defining the quality criteria will mean there are no arguments over the quality (i.e. no qualitative judgements,
only quantitative) but you need to make sure you schedule in time and people to do the evaluation work.

4. Resources

We have now set down what outputs we need to produce, and what quality they need to be at. This means we
are now in a position to look at the resources we will need to achieve this. Resources include staff time,
particular knowledge or skill sets, money (e.g. buying equipment), and time (some tasks can't be increased by
throwing more people at the problem, e.g. delivery times, setting time for concrete, etc.).
5. Management Structure

How are we going to manage the work? You need to describe the general approach to the project here. Who
will be the decision makers for the various different streams of work? For example, you may be doing a
significant procurement - who makes the decision about what company to buy from?

How will we share progress on the project? Who will we share it to? For example, you may decide to have
regular project team meetings - who needs to attend? What level of information will you be sharing? Who else
needs to be kept informed, at what level of detail, and how often? For example, you may want to keep the
project executive updated at an overview level of detail on a weekly basis, while you keep other managers
appraised at a higher level of detail.

You will also need to spell out the relationship of yourself to the project executive, in terms of the monitoring of
progress. Equally, you need to put down how you will be monitoring progress of the allocated tasks.

There is no one right answer for how this should be done, and indeed it will vary with every project. Make sure
you think about the size and complexity of the project, and also the organisation's ethos and current
management style.

6. Milestones

Here you need to think about how you will break up the project. Unless it is very small, you don't want to have
the entire project as one lump of work, with the only check on progress at the very end. Instead, it makes sense
to break the project up into discrete chunks, where related tasks can be lumped together, with a sensible
milestone at the end of them. For example, in the technology refresh in the example above, you may want to
break the project down into something like:

1. Requirements Gathering
2. Tender Writing
3. Tendering Process
4. Contract Negotiation
5. Deployment
6. Testing

It makes sense to have a defined milestone, so you know when each section is completed. There is also another
benefit of breaking the project into chunks, which I'll come back to.

7. Tolerances

You will have already looked at the resources you need. Now we need to set how far you, or the project
executive, can let the project stray from these targets before needing to sound the alarm. For example, you could
set a tolerance in terms of finance of +/- 5%, and a tolerance in terms of time of +/- 10%. Equally, you may
want to look at tolerances of quality - i.e. how far from the quality criteria are you willing to accept?

It is remarkably unlikely that a project will not deviate from its resource or quality targets. Setting tolerances
allows you to be able to manage the project without continually seeking guidance from the project executive as
to whether you should carry on. This is not to say that you should be happy with these deviations, and you
should try to avoid them, and monitor them closely. That way you can build your understanding of the project
for the future.
8. Dependencies

This is where you look at what needs to happen before something else. For example, in our example above, you
need to complete the requirements gathering before you can finish the tender documentation. You need to start
thinking about the dependencies so you, and the project team, can understand the impact of changes in any part
of the project.

These dependencies should include both those internal to the project (i.e. those under your control), and those
external to it (i.e. those outside of your control). For example, you may need an accurate figure for the number
of staff in the organisation. This needs to come from your HR department, and would be an external
dependency.

9. Risks

Simply, what could go wrong? What could happen that would damage your ability to deliver the project? Are
there things you can do to avoid them, or minimise them?

10. Scheduling

This is the Gantt chart-style information that many people envisage when a project plan is mentioned. In this,
you need to put down what you expect to happen when. It will include your dependencies, milestones, and
probably resources. At this point, it will be a relatively high overview of the whole project.

There is something you need to understand about this schedule, and that is this: it will be wrong.

I know that seems a strong statement, but it is vital that you understand that you cannot make a perfect schedule.
You really would be getting into the realm of prophecy if you think you can sit down now, and accurately and
precisely pinpoint the date the project will end. No, what you need to do here is achieve the possible.

The schedule needs to include the overview, with the project broken down into sensible chunks. This is the
other advantage of breaking the project into chunks we mentioned above. By having the project broken up in
this way, you will be able to start planning the first section in quite some detail, extending out for a few weeks.
But from then on, it will start to be based more and more on blind guesswork and faith. Don't try to be
artificially precise - keep it vague, use rough figures.

As you come to the end of each chunk of the project, you will be able to plan the next one. You can use the
information and experience you have just gained from the previous section, and thus you will be able to be more
confident.

Make sure you explain this to your project stakeholders! Often your project executive may look at a schedule,
and imagine everything is laid out and known. You must get this idea out of their head straight away! Explain
that the early part is firmer than the rest, and make sure they expect changes as the project moves on.

Your executive will crave certainty, and absolute dates for the project, from the very beginning. You must resist
the pressure to name a specific date, and explain why. While there may be a temptation to give an answer (no
doubt of a date plucked, essentially, from the air) you need to instead be realistic about what is and isn't possible
in terms of scheduling. Anything else can only lead to trouble for you, the project, and ultimately your
executive further down the line.
Don't Panic!

Phew! That's a lot to fit into a plan! But don't worry, you won't be doing this alone.

You see, you cannot know everything you need to complete the plan, and you shouldn't expect to. I've
mentioned bringing other people in to decide what success looks like, and it is vital that you bring people in to
help with the scheduling. You will have a project team who will be doing the work, and it is probable, if not
certain, that they will have a better idea than you of how to break down a chunk of work into specific tasks, and
how long those tasks will take. Make use of their knowledge! This has the added benefit of bringing them into
the project, and helping to start the process of turning a group of individuals into a team.
Project Planning: A Roadmap for Project Success
Project planning is the part of project management, which relates to the use of schedules such as Gantt charts to
plan and later report progress within the project environment.

Planning Projects in the IT Helpdesk Environment

In the IT Support domain, Helpdesks frequently have to make preparations to provide support for a new tool,
application, technology or product that is being rolled out to their end-users. Although these types of projects
are typically small and non-complex, all Helpdesk projects require proper planning and need to follow a project
framework, in order to maintain customer satisfaction and to ensure that any changes in the supported
environment do not negatively impact on the service that the Helpdesk is providing.

Project Planning Essentials

Planning a project, in its very simplest terms, requires putting a series of tasks in the correct order and
determining any dependencies between the tasks, in order to reach a desired outcome at the end of the project.
In practice things are never quite so straightforward.

The Project Plan: How to Write a Successful Project Plan

A project plan provides a roadmap for detailing how your project will reach its desired goals. It should be
written in the project planning phase, once the project has been initiated and received preliminary approval and
funding to be scoped out further. It normally follows the business case, and should primarily focus on how the
project will proceed rather than why.

Project Planning A Step by Step Guide

Often project planning is ignored in favour of getting on with the work. However, many people fail to realise
the value of a project plan in saving time, money and many problems. This article looks at the steps for creating
a simple plan at the beginning of a project.

Project Management Checklists

Among all the tools at our disposal for managing projects, checklists are perhaps the simplest and most
productive means of building consistency in work practices. Checklists are useful in almost every field of
human endeavour, and in particular where repeatability and systematic action drive performance. Yet they are
still much underused in the planning and managing of projects.

Are you a Project Management Gantt Chart Slave?

Gantt charts are a fundamental tool in a project manager's toolkit. However, an unseasoned project manager can
find they take over the project and result in reduced control. How so? In this article I will look at the potential
pitfalls and provide some tips and strategies for ensuring successful project management. Gantt charts are, after
all, just one of many ways to present the project plan, and actual data that has been input.

Five Really Useful Tools For Project Management in Social Care

There are a wide range of well established planning tools which can be used to aid the project management
process, and provide the means to monitor and review project plans over time. Here I outline five of the most
useful planning tools for projects in health and social care.

Project Planning in a Nutshell

Improvement happens one project at a time. But often projects fail because they are poorly planned, or even
completely unplanned. This article provides an overview of why it is important to prepare a project plan. It also
shows what elements a good project plan will include.

The "Real" Project Plan

"I need a project plan by tomorrow morning." As project managers, that's what we hear. But we know that what
the boss usually means is that s/he wants a project schedule. There is a problem though, how can you come up
with a schedule without having the "real" project plan first?

Project Plans: 10 Essential Elements

A project plan is more than just a Gantt chart, but do you know what you must have in your plan? This article
takes you through the 10 essential elements your project plan has to have to help you achieve project
management success.

Developing the Project Plan

Whether you call it a Project Plan or a Project Timeline, it is absolutely imperative that you develop and
maintain a document that clearly outlines the project milestones and major activities required to implement your
project.

Planning a Project using a Work Breakdown Structure & Logic Network

Projects don't just happen they need planning. Involve the whole project team in developing the plan, not just
the project manager. This ensures team members experience is considered and each person is fully committed
to, and has ownership of the plan.

How to Create a Gantt Chart Using Microsoft Excel

Since their first introduction, Gantt charts have become an industry standard. They are an important project
management tool used for showing the phases, tasks, milestones and resources needed as part of a project. This
video presentation is a step-by-step guide to creating a Gantt chart using Microsoft Excel 2007.

"Plans are only good intentions unless they immediately degenerate into hard work."