Assignment 1- Project Planning

Sir.Pravin S.Eazhawa OSM

PM Batch -07
 Synopsis to the Assignment

What is a Project Management

Module 8 :Project Planning

The Elements of a Project Plan

The Planning Process

TOPICS
The Statement of Work (SOW)

The Work Breakdown Structure (WBS)

RACI Chart /LRC

Thank You
 Synopsis of the Assignment

Project Management has already moved beyond the realms of an

"order- winning"-criteria to a "necessary-to-survive"-criteria.
Increasingly people are drawn into project management without the
correct qualifications or sufficient education in project management,
especially in the area of project risk management.
This assignment details the module of a Project Planning
facilitating my understanding of this module.
 What is a Project Management
A project is a series of related jobs directed toward some major output, which could require a large
amount of time

• Projects are also unique and specific, with a specific need or purpose that has to be fulfilled by
the specific deliverable
• Moreover, a project typically has the following characteristics
 A project has a single, definable outcome or result, which is usually specified in terms of cost,
duration or schedule, and performance requirements.

 Every project is unique, in that it requires that something different be done in this project than in
previous activities. A project is therefore a once-off activity that will never be repeated in exactly
the same manner.

 Projects are of a temporary nature. Once the desired result has been achieved, the organisation is
disbanded or reconfigured to begin work on a new project.

 Projects usually require skills and expertise from a wide variety of professions and organisations.
A project therefore cuts across organisational boundaries and lines.
  There is always a certain amount of unfamiliarity, given that projects differ significantly from what was done
previously. This also leads to the fact that there is a definite element of uncertainty and risk in every project.

 There is usually something at stake when a company starts a project. Otherwise there would be no point to the
project.

 A project is the process of working to achieve a specific goal. During this process, the project goes through distinct
phases, or a project life cycle. As the project advances from one stage to the next, the people, tasks, organisations
and resources change. The resource and expenditure builds slowly with each progressive phase, and peaks and
declines as the project is completed. This concept will be discussed further in the following paragraph.

After the completion of all projects, the project team is disbanded, or move on to something else. With
repetitive tasks, there is merely a change in the scheduling of the operations; the staff used is usually
permanent. Seeing as there is a significant difference between a project and repetitive jobs, these two forms of
tasks have to be managed differently.

Further distinction must be made between the following terms: Project, Program, Task and Work Packages.
The term program is usually used to refer to an exceptionally large, long-range objective, which is broken
down into certain projects. These projects are usually further broken down into tasks, and these are in turn
divided into work packages. These work packages then further consist of work units.
 MODULE 8 :PROJECT PLANNING
The Need for Project Planning

Before we start to delve into what project planning is all about, let us first look at why we need to plan projects.
Certainly, one would be justified in asking: "What about the plan that was set out in the Project Definition phase? Is
it not adequate?" The answer to that would be a resounding "No" .
The plans that were generated in that phase of the project are usually not detailed enough to manage the project
with. There are mainly four reasons why projects need to be planned in detail.

• Coordination and Communication: The project plan informs everyone involved of their, and others',
specific duties. It is a way of discussing each person's responsibilities and this in turn helps to direct and
control the work involved in the project. It is imperative to get the people who have to perform the tasks to
plan their own tasks. They should know more about it than you do, and ultimately they have to complete it.
Plans further show us how all the parts of the project fit together, which is essential for proper coordination of
the project.
• Basis for Monitoring: Projects usually do not go according to plan. Deviations from the plan can be
detected by monitoring processes and is the project manager's early warning system that there are
problems that need to be resolved.

• Requirement Satisfaction: It is sometimes necessary to create plans just in order to satisfy the client.
These plans are usually a waste of time, seeing as they are very seldom followed, and are merely drawn
up to satisfy some stated requirement. Plans are also used as a point of reference for any changes, which
in turn helps the project manager to deal with the client. The project plan will also help everyone to know
when the objectives have been completed, and therefore when to stop.

• Problem Avoidance: A good plan will help avoid problems later in the project's life, especially when the
project is being executed. Plans can, however, not avoid problems altogether. Plans are a simulation of
prospective work, and they allow flaws to be identified in order for it to be corrected in time.
 The Elements of a Project Plan
There are mainly seven elements in a project plan. These elements are interrelated, as can be seen in figure below .
The first of these elements entails a detailed and complete Statement of Work (SOW). The next element is a
statement of specific, measurable acceptance criteria for all deliverables. These are based on the SOW and
performance specifications. It provides a clearly defined goal for all the project team members. The third element of
importance in a project plan is the compilation of Performance criteria that are not related to the deliverables. This
could form part of the project when a company wants to comply with some standard, or have other governmental
regulations to comply with

Relationship between 7 Project Plan Elements

 The Elements of a Project Plan
The fourth element is the Work Breakdown Structure, or WBS. This document identifies every single task in the
project that needs to be completed in order for the project to be completed satisfactorily. This documented
breakdown is based on the SOW and the performance criteria, whether they are deliverable or not. The next
required element is a Critical Path Network, which comprises of all the elements in the WBS. From this we can
derive further charts and graphs like the Gantt chart, milestones and network diagram schedules.

The sixth element a project plan should include is a Resource Plan. This should accompany the WBS and should
state how the WBS will be accomplished. This plan should include both human and physical resources. The
schedule will, to a large extent, depend on these resources. It is essential to determine the commitment levels of the
resources, in order to ensure that the resources are not over-committed but can actually do all the work in the
allotted time frame.

The seventh and final element required in a project plan is the Budget. It is necessary to create a budget for each
task, based on the resources allocated to that task. The budget is further utilised when the project manager wants to
calculate the viability of the project by means of a discounted cash flow analysis.
 The Planning Process
Literature describes numerous different planning strategies for different activities. According to Mantel, all these
concepts and different planning processes can be captured in a single "generic" planning process. This is due to the
fact that most of the planning processes only differ in nomenclature and not necessarily substance. Therefore, the
planning process can be divided into 8 steps, or stages, as described below:
• Develop the project concept and evaluate the concept.
• Carefully determine and describe the project's deliverables and requirements.
• Develop a prototype deliverable
• Test the prototype, in order to ensure that it complies with all the requirements. If necessary, the prototype
can now be remodelled and retested, depending on the need and results of the tests.
• Integrate the prototype into the system for which it was designed.
• Validate the deliverable (Does the deliverable work correctly?
• After Validation allow the client to test the deliverable
• Assuming the client is sufficiently satisfied with the deliverable, and knows how to operate it, the project is
completed and the closure documentation can be prepared and delivered.
The above process is a generic planning process and can be applied to any field where planning is required.
 The Statement of Work (SOW)

This document entails a verbal (narrative) description of the work requirements in order to complete the
project . This document is usually written by the secretarial staff on the project team, and then submitted
to the various departments for verification and approval. It is, however, not uncommon for the customer
to write it, even though the project manager then usually has to rewrite the SOW. The reason the project
manager rewrites this SOW is to ensure that the project's line managers understand exactly what is
required from them and can give cost estimates and resource requirement estimates for their specific
task(s).

Numerous governmental agencies as well as private industries, have established documents that act as
guidelines to the writing of SOW's. One such an example is the Statement of Work Handbook
NHB5600.2, published by the National Aeronautics and Space Administration, or NASA, in February
1975.
 The Work Breakdown Structure (WBS)

As soon as the project requirements have been defined and the Statement of Work has been compiled, we move on
to create the Work Breakdown Structure, or WBS. The WBS is a breakdown of all the tasks into their subtasks, and
further, until a desired level of detail is reached, and therefore defines the hierarchy of project tasks, subtasks and
work packages. This document is useful in planning and scheduling exercises, as well as the allocation of
responsibilities and the compilation of a project budget.
The WBS forms an integral part of the project, seeing as it provides a common framework from which the
following can be achieved :

1. A total project description can be compiled as a summation of the smaller elements.

2. The project manager, along with the other parties involved in the project, can plan the project.
3. The project manager can establish costs and budgets.
4. It enables the parties involved to keep track of the time, cost and performance of the project.
5. The company resources can be logically linked to the objectives.
6. Procedures for reporting the project status as well as the schedules can be established logically.
7. The planning of project control and network construction can be started. 8. Each element's responsibility
assignment can be established.
The main reasons for compiling a WBS are, firstly, to make the control of the project easier, secondly, to facilitate
the scheduling process, and thirdly, to aid in the estimation of the gross requirements regarding people, equipment
and supplies .
 The Work Breakdown Structure (WBS)
A WBS can be compiled by following the general guidelines below, as suggested
by Meredith,:
1. List all tasks and their components in successively finer detail, with information from the SOW. The number of
levels and the level of detail required in a specific WBS usually depends on the following :
• The level at which a single individual or business entity can be assigned responsibility and accountability to
accomplish the task.
• The level at which the budget and cost data is collected during the project execution.

Decomposition of a task should stop when the subtask portrays the following properties :
• The task is clearly and comprehensively defined, in such a manner that the performing parties know exactly what
they need to do.
• All resources, including labour, skills, equipment, facilities and materials, have been clearly identified.
• The task duration is accurately estimated.
• All related expenses for the task have been estimated.
• All parties responsible for executing the task have been identified.
• All deliverables, end items and outcomes as well as the requirements and specifications associated with the task
are identified.
• All predecessors and pre-conditions have been defined and are identified.
• The required level of quality for the entry, process and exit conditions has been specified in the quality plan.
• All additional information is specified completely.
 The Work Breakdown Structure (WBS)
When all the abovementioned qualities are not met, the task is still too broad, and must be decomposed further.
However, the breakdown should also not go so far that it makes the system unnecessarily cumbersome. If the tasks are
broken down too finely, it could lengthen the project and increase the costs unnecessarily.
A task is generally sufficiently broken down when it displays the following characteristics :
• Manageable - specific authority and responsibility must be assigned
• Independent - work must not depend on other tasks as far as possible
• Integratable - The entire package must be seen
• Measurable - Progress must be determined
•Rosenau presents a useful guide to factors that affect the size of a task. These include management effort, the number
of tasks, financial and resource spending authorisation, task duration, monitoring accuracy, the company's experience
with similar work and the task manager's skill. See Table 4.1 in the following slide for a clarification on how these
factors affect the task size.

A project manager therefore has to conceptually decompose the project into smaller pieces, and these smaller pieces
are then further broken down into even smaller pieces. This process continues until the pieces of the project are
sufficiently realisable . These smallest pieces of the project are then physically aggregated (actual work is completed)
to progressively form larger pieces until the project deliverables are completed.
 The Work Breakdown Structure (WBS)

Factors that affect task

size
 The Work Breakdown Structure (WBS)
2.Next, all the relevant WBS data for each specific work package has to be identified. This data typically includes
vendors, equipment, duration, materials, special specifications, and the like. The persons responsible for each work
package must also be listed. It is useful to construct a Linear Responsibility Chart (LRC). (Table LRC to follow ).
This chart is useful when the project team is quite large and makes it very clear who is responsible for what. The
chart also highlights the critical interfaces between units that may require special attention from management. This
chart will also allow the project manager to keep track of who has to report to whom, and the persons responsible for
approving certain aspects of the project.

3. The third step in creating a WBS is to ensure that all work packages are reviewed with the people responsible for
executing the specific work package. This is done in order to verify the accuracy of the WBS. The resource
requirements, schedules and subtask relationships can now be aggregated in order to form the next higher level of the
WBS. This continues, until the uppermost level is reached, which should have a project summary, a budget and the
project schedule.

4. When compiling a budget for the purpose of developing a price for a proposal, the following four elements have to
be included in the budget:
• Direct budgets from each task
• An indirect cost budget for the entire project (general and administrative costs, marketing costs, potential
penalty charges, to name a few)
• A contingency reserve for unexpected emergencies
 The Work Breakdown Structure (WBS)
5. In a similar manner as described in the previous point with the budget, the milestones and schedule information
can be aggregated into a Project Master Schedule. This schedule integrates all the schedules that are relevant to the
project. It should be comprehensive, in that it should include contractual commitments, key interfaces and
sequencing, milestone events and progress reports. A time contingency plan could also be included in case of
emergencies. This master schedule is usually displayed in the form of a Gantt chart and can easily be constructed in a
program such as Microsoft" Project 2000®.

The last two steps illustrate how the WBS can be used as a project monitoring and control tool.

6. The project manager is able to continually examine actual resource use by work package, subtask or task, with the
aid of the WBS. It further facilitates problem identification, due to the fact that the project manager can compare
actual to budgeted use of resources, finances and time. It is further possible for the project manager to make more
accurate final cost estimates. It is important to examine resource usage in relation to performance, or achieved
results, seeing as the budget might be exceeded, but the results might also be further along than expected. The
scenario where the budget is on par but the results are below par can also be detected and corrective action taken.

7. The project schedule may also be subjected to the same comparisons as the ones made to the budget in the
previous point. It might be necessary to assign additional resources to tasks that are falling behind in order to
expedite them.
 The Work Breakdown Structure (WBS)
The WBS is usually presented as a list containing the tasks, subtasks and activities; each indented accordingly. See
Figure below for an excerpt from an example .

The WBS document is usually structured in the same manner as the work will be performed. It therefore also reflects
the manner in which project costs and data will be summarised, and later reported.
 Linear Responsibility Chart /RACI)
The Linear Responsibility Chart (LRC), or sometimes called the Responsibility Matrix, is a tool which is used to
effectively assign and keep track of all the relationships between the work packages as set out in the WBS and the
people responsible for those work packages. As mentioned earlier, it highlights the critical interfaces between units
that might need further attention from management .

This chart identifies the participants, and to what degree that person will perform an activity or make a decision. It is
an attempt at clarifying the authority relationships that usually exist when functional units share common work .

A RACI chart should contain the following elements:

• General management responsibility
• Operations management responsibility
• Specialised responsibility
• Who must be consulted
• Who may be consulted
• Who must be notified
• Who must approve

The RACI is typically in the form of a matrix, with the tasks and subtasks on the vertical axis and the responsible
person on the horizontal axis [(see Figure next slide As many links and dependencies on a RACI as seem relevant to
the specific project can be created. For example, a specific department might have to be notified of every task that is
 Linear Responsibility Chart /RACI)
Shapes are often used to indicate the nature of the responsibility, but it is not uncommon to use numbers or letters.
Departments, people or job titles can also be referenced with the symbols used.

RACI CHART
Thank you