SPM Study Material Unit-2

US05EBCA02 (Software Project Management)
Unit-II
CHARUTAR VIDYA MANDAL’S
SEMCOM
Vallabh Vidyanagar
Faculty Name: Ami D. Trivedi
Class: TYBCA (Semester – V)
Subject: US05EBCA02 (Software Project Management)
UNIT – 2 SOFTWARE PROJECT PLANNING
**PROJECT ACTIVITIES AND WORK BREAKDOWN STRUCTURE (WBS)
*PROJECT ACTIVITY
 Entire project is divided into many interdependent tasks.
 In this set of tasks, the sequence or the order of the tasks is quite important.
 If the sequence is wrong, the end result of the project might not be what the
management expected.
 Some tasks in the projects can safely be performed parallel to other tasks.
PROJECT ACTIVITY DIAGRAM





The sequence of the tasks is simply illustrated in a project activity diagram.
There are many tools that can be used for drawing project activity diagrams.
E.g. Microsoft Project is one of the most popular software for this type of work.
Activity diagrams take the same shape.
Usually there are two main shapes in activity diagrams: boxes and arrows.
 Boxes of the activity diagram indicate the tasks and
 Arrows show the relationships.
Usually the relationships are the sequences that take place in the activities.
ELEMENTS OF ACTIVITY DIAGRAM
Element
Activity
Description
Used to represent a set of actions /
actions to be taken
A Control Flow
Shows the sequence of execution
An Initial Node
Shows beginning of a set of actions
A Final Activity Node
Used to stop all control flows and object
flows in an activity (or action)
Used to represent test condition like IF
statement
Decision Node
SEMCOM
Symbol
Page 1 of 21
US05EBCA02 (Software Project Management)
Unit-II
TYPES OF ACTIVITY DIAGRAM
1. Activity-on-node diagram
2. Activity-on-arrow diagram
1. Activity-on-node diagram
Example of activity diagram with tasks in boxes and relationship represented by
arrows
This type of activity diagram is also known as activity-on-node diagram. Because all
activities (tasks) are shown on the nodes (boxes).
2. Activity-on-arrow diagram
Alternatively, there is another way of presenting an activity diagram. This is called
activity-on-arrow diagram. In this diagram, activities (tasks) are presented by the
arrows.
Compared to activity-on-node diagrams, activity-on-arrow diagrams introduce a little
confusion. Therefore, in most instances, people often use activity-on-nodes diagrams.
Following is an activity-on-arrow diagram.
SEMCOM
Page 2 of 21
US05EBCA02 (Software Project Management)
Unit-II
Main steps involved in creating an activity diagram
Step - 1
 First of all, identify the tasks in the project. You can use WBS (work Breakdown
Structure) for this purpose and there is no need to repeat the same.
 Just use the same tasks breakdown for the activity diagram as well. If you use
software for creating the activity diagram (which is recommended), create a box for
each activity.
 Illustrate all boxes in the same size in order to avoid any confusion. Make sure all
your tasks have the same granularity (level of detail).
Step - 2
 You can add more information to the task boxes, such as who is doing the task and
the time frames.
 You can add this information inside the box or can add it somewhere near the box.
Step - 3
 Now arrange the boxes in the sequence that they are performed during the project
execution.
 The early tasks will be at the left hand side.
 The tasks performed at the latter part of the project execution will be at the right hand
side.
 The tasks that can be performed in parallel should be kept parallel to each other
(vertically).
 You may have to adjust the sequence a number of times until you get it right. This is
why software is an easy tool for creating activity diagrams.
Step - 4
 Now, use arrows to join task boxes. These arrows will show the sequence of the
tasks.
 Sometimes, a 'start' and an 'end' box can be added to clearly present the start and
the end of the project.
To understand what we have done in the above four steps, please refer to the
following activity diagram.
SEMCOM
Page 3 of 21
US05EBCA02 (Software Project Management)
Unit-II
Example-1
Example-2
Draw Activity Diagram for the following table.
Activity
Duration
A
B
C
D
E
F
G
H
2
3
2
4
4
3
5
2
SEMCOM
Precedent
Activity
A
B
C
C
D,E
F,G
Page 4 of 21
US05EBCA02 (Software Project Management)
Unit-II
*WORK BREAKDOWN STRUCTURE (WBS)
Process of dividing complex projects to simpler and manageable tasks is known as
Work Breakdown Structure (WBS).
When creating a WBS, the project manager defines the key objectives first and then
identifies the tasks required to reach those goals.
Usually, the project managers use this method for simplifying the project execution. In
WBS, much larger tasks are broken down to manageable chunks of work. These
chunks can be easily supervised and estimated.
Graphical nature of the WBS can help a project manager to predict outcomes based on
various scenarios, which can ensure that optimum decisions are made about whether or
not to adopt suggested procedures or changes.
WBS is not restricted to a specific field when it comes to application. This methodology
can be used for any type of project management.
A Work Breakdown Structure is a results-oriented family tree that captures all the
work of a project in an organized way. It is often portrayed graphically as a
hierarchical tree.
A WBS takes the form of a tree diagram with the "trunk" at the top and the "branches"
below. The primary requirement or objective is shown at the top, with increasingly
specific details shown as the observer reads down.
WBS DIAGRAM
In a WBS diagram,
 Project scope is graphically expressed.
 Usually the diagram starts with a graphic object or a box at the top, which represents
the entire project.
 Then there are sub components under the box. These boxes represent the
deliverables of the project.
 Under each deliverable, there are sub elements listed. These sub elements are the
activities that should be performed in order to achieve the deliverables.
Although most of the WBS diagrams are designed based on the deliveries, some WBS
is created based on the project phases.
Usually, information technology projects are perfectly fit in to WBS model.
SEMCOM
Page 5 of 21
US05EBCA02 (Software Project Management)
Unit-II
REASONS FOR CREATING WBS IN A PROJECT





Accurate and readable project organization.
Accurate assignment of responsibilities to the project team.
Indicates the project milestones and control points.
Helps to estimate the cost, time, and risk.
Illustrate the project scope, so the stakeholders can have a better understanding of
the same.
 Giving visibility to important work efforts.
 Giving visibility to risky work efforts.
 Illustrate the correlation between the activities and deliverables.
8/80 rule
In the process of breaking down the tasks, one can break them down into different
levels of detail. One can detail a high level task into ten sub tasks while another can
detail the same high level task into 20 sub tasks.
Therefore, there is no hard and fast rule on how you should breakdown a task in WBS.
Rather, the level breakdown is a matter of the project type and the management style
followed for the project.
In general, there are a few "rules" used for determining the smallest task chunk.
8/80 is a rule used when creating a WBS. This rule implies that no task should be
smaller than 8 hours of work and should not be larger than 80 hours of work.
FORMS TO DISPLAY WBS
One can use many forms to display their WBS.
 Tree structure
 Lists
 Tables
 Outlining
Outlining is one of the easiest ways of representing a WBS. Following example is an
outlined WBS.
SEMCOM
Page 6 of 21
US05EBCA02 (Software Project Management)
Unit-II
Why creating WBS is a critical step in the process of project management?
 The efficiency of a work breakdown structure can determine the success of a project.
 WBS provides the foundation for all project management work, including, planning,
cost and effort estimation, resource allocation, and scheduling.
Therefore, one should take creating WBS as a critical step in the process of project
management.
WBS EXAMPLE
SEMCOM
Page 7 of 21
US05EBCA02 (Software Project Management)
Unit-II
NUMBERING THE WBS
In developing a WBS, coding or numbering various elements and levels significantly
improves the functionality of the WBS in various related applications.
The coding can be done by any method. But it is important that it should be consistent.
Most organizations have standard codes. These codes can be used and modified to
contain numeric / alphabetic elements that give a unique identification to each work
activity.
The resulting identification provides a label for scheduling, budgeting, tracking,
replanning, assigning etc. and in general communicating across the project.
There are many possible numbering systems for the elements of the WBS. The purpose
of all numbering systems is to identify the WBS work element readily and where it fits in
the overall project hierarchy.
A decimal numbering system is illustrated in following figure is commonly used. The
decimal numbering system is precise and thorough. It can continue to whatever level is
necessary.
Example: Garage project numbering
SEMCOM
Page 8 of 21
US05EBCA02 (Software Project Management)
Unit-II
CRITERIA FOR COMPLETENESS IN THE WBS




1.
2.
3.
4.
5.
6.
Developing the WBS is the most critical part of the project planning activity.
If this part is done correctly, the rest is comparatively easy.
How do you know that you’ve done this right?
We can know we have done this right if each activity possesses the six
characteristics described as follows:
Status / completion is measurable
Start/end events are clearly defined
Activity has a deliverable
Time and cost are easily estimated
Activity duration is within acceptable limits
Work assignments are independent
 If an activity does not possess all six of these characteristics, decompose the activity
and ask the questions again.
 As soon as an activity possesses the six characteristics, you have no need to further
decompose it. That activity can now be called a task.
 As soon as every activity in the WBS possesses these six characteristics, the WBS is
defined as complete.
6 CHARACTERISTICS OF AN ACTIVITY
1. Start / Completion Is Measurable
 Project manager must be able to ask for the status of an activity at any point in time
during project.
 If the activity has been defined properly, that question is answered easily.
 The answer should consist of
 what has been done,
 how much time was required to complete the work,
 how much remains, and
 how long it will take to complete.
 If that information is not readily available, the activity needs to be further
decomposed.
2. Start / End Events Are Clearly Defined




Each activity should have a clearly defined start and end event.
Once the start event has occurred, work can begin on the activity.
The deliverable is most likely the end event that signals work is closed on the activity.
If those events are not clearly obvious, the activity needs to be further decomposed.
SEMCOM
Page 9 of 21
US05EBCA02 (Software Project Management)
Unit-II
3. Activity Has a Deliverable
 Result of completing the work that makes up the activity is the production of a
deliverable.
 The deliverable is a visible sign that the activity is complete.
 This sign could be an approving manager’s signature, a physical product or
document, the authorization to proceed to the next activity, or some other sign of
completion.
 Deliverable from an activity is an output from that activity which then becomes input
to one / more other activities.
 If the activity does not result in a deliverable, the activity needs to be further
decomposed.
4. Time and Cost Are Easily Estimated
 This is a relative characteristic.
 Each activity should have an estimated time and cost of completion.
 Being able to do this at the lowest level of decomposition in the WBS, allows you to
aggregate to higher levels and estimate the total project cost and the completion
date.
 By successively decomposing activities to finer levels of granularity, you are likely to
encounter primitive activities that you have performed before.
 This experience at lower levels of definition gives you a stronger base on which
to estimate activity cost and duration for similar activities.
5. Activity Duration Is Within Acceptable Limits
 While there is no fixed rule for the duration limitation of an activity, common practice
is to set the limit at 2 weeks.
 Again this is a relative limit. For very long projects some limit greater than 2 weeks
will be appropriate. For a project that will only last a few weeks, a much lower limit is
appropriate.
 There will be exceptions when the activity defines process work, such as will occur in
many manufacturing situations. There will be exceptions, especially for those
activities whose work is repetitive and simple.
 For example, if you are going to build 500 widgets and it takes 10 weeks to complete
this activity, you are not going to decompose the activity into 5 activities with each
one building 100 widgets. There is no need to break the 500-widget activity down
further.
 For example, If you can estimate the time to check one document, it does not make
much difference if the activity requires 2 months to check 400 documents or 4 twoweek periods to check 100 documents per period.
 The danger you avoid is longer duration activities whose delay can create a serious
project-scheduling problem.
SEMCOM
Page 10 of 21
US05EBCA02 (Software Project Management)
Unit-II
6. Work Assignments Are Independent
 At first brush this may seem to be a rather strange criterion, yet it may be the most
important one of all. Here’s why.
 It is important that each activity be independent of other activities in the following
sense.
 Once work has begun on the activity, if it is independent of other activities, the work
can continue without interruption and without the need of additional input or
information until the activity is complete.
 This allows the project manager to schedule the work contiguously, but it can be
scheduled otherwise for a variety of reasons.
 You can choose to schedule it in parts because of resource availability, but you could
have scheduled it as one continuous stream of work.
*ACTIVITY RESOURCE REQUIREMENTS AND COST
 We saw how to sequence the activities based on the requirements and
dependencies.
 Next step would be estimating resource requirements. After all, you need Resources
to work on these activities.
We all know that any activity needs resources in order to be executed and completed.
Resources are sources of supply or support, such as money, people, and materials.
There are two primary types of resources used in information system projects
namely:
1. Human Resources
2. Capital Resources
1. Human resources
Human resources is personnel pool available to an organization. The most important
resources in any organization it’s human resources.
It includes all project stakeholders such as
 customers,
 project team members,
 support staff,
 project suppliers and
 end users.
2. Capital Resources
Capital resources can be defined as the tools and infrastructure used to produce
other goods and services.
SEMCOM
Page 11 of 21
US05EBCA02 (Software Project Management)
Unit-II
ESTIMATE ACTIVITY RESOURCES PROCESS
The resource requirements for an activity are estimated by using the Estimate Activity
Resources process.
Main purpose of this process is to:
1. Estimate the types of resources needed for a given activity
2. Estimate the quantities of each type of resource needed for the activity
Simply put, you identify what kind of resources can do a particular activity and how
many.
For ex: If you want a Java class, you would have to identify a Java Programmer as your
resource for this activity.
Just like all other processes, this process too has inputs, uses some tools & techniques
and generates an output. Look at the image below:
Input to Activity Resource Estimating
1. Activity list and attributes
 Activity list and attributes are the obvious and major input to the activity resource
estimating process.
 The activity list originally developed during the activity definition process identifies
the schedule activities that need the resources.
 The activity attributes provide the details for the activities, which will be helpful in
estimating the resources.
SEMCOM
Page 12 of 21
US05EBCA02 (Software Project Management)
Unit-II
2. Resource calendars
 Resource estimating will require information on the available quantity of resources
of different types, such as human, equipment, and material.
 This information is usually available in the resource calendars, which may also
have detailed information about human resources, such as skill level, experience,
and the geographical location from where the resource will come.
 Typically, the resource calendar contains the following useful information about the
resources:




Days and times of day when a resource is available
Passive time for the resource (Ex: Vacation plans for people)
Quantity of each type of available resource
Capability of each resource
3. Enterprise environmental factors
Information about the infrastructure of the performing organization, such as existing
facilities, will be used in identifying the resources and their availability.
4. Organizational process assets
The organizational process assets useful for activity resource estimating include
 Organizational policies for staffing and purchase of supplies,
 Historical information on what types of resources were used for similar activities
in a previous project, and so on.
Once you understand what activities need to be performed; the next step is to use some
tools and techniques to determine the resources required to perform them.
Tools and Techniques for Activity Resource Estimating
Tools & techniques that can be used for activity resource estimation are:
1.
2.
3.
4.
5.
Alternative analysis
Bottom-up estimating
Expert judgment
Published estimating data
Project management software
SEMCOM
Page 13 of 21
US05EBCA02 (Software Project Management)
Unit-II
1. Alternative analysis
 Alternative analysis is all about exploring alternative solutions to a problem.
 In the case of estimating resource requirements, you will need to consider
alternatives available for resources needed for some schedule activities.
 For example, you might need to decide
 Whether you want to buy or develop a tool needed to perform an activity,
 What types of machines (for example, Windows or Linux) to use,
 Which computers to use to do the development, or
 What level of skills is needed etc.
2. Bottom-up estimating
 You might discover that it is rather complex to estimate resources for a
given schedule activity.
 If the problem is inherent to the activity, it might be helpful in certain cases
 To decompose the activity into smaller components for the purpose of
resource estimating and,
 Then estimate the resource for each component, and
 Then aggregate the resources to get an estimate for the whole activity.
 In aggregation, you must consider the possible relationships (overlaps and other
dependencies) among different components of the activity so you don’t doublecount the resources or consider a seamless summation of the smaller component
estimates.
3. Expert judgment
Expert judgment can be used to assess the input and determine the output of the
resource estimating process.
4. Published estimating data
Information published by various vendors, such as costs for resources, can also be
useful in estimating the resources.
5. Project management software
 Depending upon the sophistication of the resource requirements and the
capabilities of the available features, project management software might be useful
in estimating and managing the resources.
 It can also be used to create resource breakdown structures.
You can use a combination of these tools and techniques to generate the output of the
resource estimating process. But, at the end of the day, it is the project manager and his
capabilities that determine how accurately the resource estimation happens.
SEMCOM
Page 14 of 21
US05EBCA02 (Software Project Management)
Unit-II
Output of Activity Resource Estimating
The resource requirements are the major output of the resource estimating process.
Following overall elements are the output of this process:
1. Activity resource requirements
2. Resource breakdown structure
3. Updates to project documents
1. Activity resource requirements
 The main purpose of the activity resource estimating process is to determine the
resource requirements for each activity, and therefore this is the major output item
from this process.
 You identify the types of resources required to perform each activity and estimate the
required quantity of each identified resource.
 If a work package in the WBS has multiple activities, the resource estimates for those
activities can be aggregated to estimate the resource requirements for the
work package.
 The requirement documents may also include information such as the basis for each
estimate, the assumptions made for the estimate, and the availability of the
resources.
2. Resource breakdown structure
 The resource breakdown structure (RBS) is a hierarchical structure of resource
categories and types required to complete the schedule activities of a project.
 The RBS can be used to identify and analyze the project human resource
assignments.
3. Updates to project documents
 The identified types of required resources for an activity and the estimated quantity
for each identified resource become activity attributes and must be added to the
attribute list for the activity.
 Activity resource estimating might generate modifications to the activity list. It may
also cause you to change the resource calendar.
Once you identify the resource requirements, the next step would be to estimate
the time required to complete each of these activities.
SEMCOM
Page 15 of 21
US05EBCA02 (Software Project Management)
Unit-II
*JPP – JOINT PROJECT PLANNING SESSION
OBJECTIVE OF A JPP
Objective of a JPP session is very simple: Develop a project plan
 that meets the Conditions of Satisfaction (COS) as negotiated between the
requestor and the provider, And
 as described in the Project Overview Statement.
The first document considered in the JPP session is the Project Overview Statement
(POS). One may already exist and therefore will be the starting point for the JPP.
ATTENDEES
 JPP participants are invited from among those who might be affected by or have
input into the project.
 If the project involves deliverables or is a new process or procedure,
1. anyone who has input to the process,
2. receives output from the process, or
3. handles the deliverables
should be invited to participate in the JPP.
 Customer falls into one or more of these categories and must be present at the JPP.
 Any manager of resources that may be required by the project team also will attend
the JPP session.
 In many organizations, the project has a project champion who may wish to
participate at least at the start.
1. Facilitator
 A successful JPP session requires an experienced facilitator.
 This person is responsible for conducting the JPP.
 It is important that the facilitator not have a vested interest or bring biases to the
session, because that would reduce the effectiveness of the plan.
 It must be developed with an open mind, not with a biased mind.
 For this reason, we strongly suggest that the project manager should not facilitate the
session.
 If using an outside consultant is not possible, we recommend a neutral party for
Facilitator, such as another project manager.
2. Project manager
 Project manager must be comfortable with the project plan.
 After all, the project manager is the one who has final responsibility when it comes to
getting the project done on time, within budget, and according to specification.
SEMCOM
Page 16 of 21
US05EBCA02 (Software Project Management)
Unit-II
3. JPP consultant
 Project management consultants will often serve as another source of qualified JPP
facilitators.
 Having an outside consultant facilitate the JPP session is as much a learning
experience as it is an opportunity to get off to a good start with a Successful JPP
session.
4. Technographer
 JPP facilitator is supported by a technographer, a professional who not only knows
project management but also is an expert in the software tools used to support the
project.
5. Customer representative
Represent the customer of the company.
6. Resource managers
These managers control resources that the project will require.
FACILITIES
Planning team may spend as many as three consecutive days in planning. So it is
important that the physical facility is comfortable and away from the daily interruptions.
To minimize distractions, you might be tempted to have the planning Session off-site.
However, while off-site seems preferable, we prefer on-site planning sessions.
On-site planning sessions have both advantages and disadvantages, but with proper
planning, they can be controlled.
Easy access to information has been a major advantage to on-site planning sessions in
our experience; interruptions due to the daily flow of work have been the major
disadvantage.
With easy access to the office made Possible by cell phones and email, the potential for
distraction and interruptions has increased.
This need to be minimized in whatever way makes sense.
SEMCOM
Page 17 of 21
US05EBCA02 (Software Project Management)
Unit-II
DELIVERABLE
1. Work Breakdown Structure
 Work Breakdown Structure (WBS) is a graphical or indented outline list of the work
(expressed as activities) to be done to complete the project.
 It is used as a planning tool, as well as a reporting structure.
2. Activity duration estimates
 The schedule is also a major deliverable. It is developed from estimates of the
duration of each work activity in the project.
 Activity duration estimates may be single-point estimates or three-point estimates.
In three-point estimation, three figures are produced initially for every distribution
that is required, based on prior experience or best-guesses:
 a = the best-case estimate
 m = the most likely estimate
 b = the worst-case estimate.
These values are used to calculate an E value for the estimate
E = (a + 4m + b) / 6
Point estimation involves the use of sample data to calculate a single value
(known as a statistic) which is to serve as a "best guess" or "best estimate".
3. Resource requirements
 For each activity in the project, an estimate of the resources to perform the work is
required.
 In most cases, the resources will be the technical and people skills, although they
can also include such things as physical facilities, equipment, and computer cycles.
4. Project network schedule
 Using the WBS, the planning team will define the sequence in which the project
activities should be performed.
 Initially this sequence is determined only by the technical relationships between
activities, not by management prerogatives.
 That is, the deliverables from one or more activities are needed to begin work on the
next activity. We can understand this sequence most easily by displaying it
graphically.
SEMCOM
Page 18 of 21
US05EBCA02 (Software Project Management)
Unit-II
5. Activity schedule
With the sequence determined the planning team will schedule the start date and end
date for each activity. The availability of resources will largely determine that schedule.
6. Resource assignments
The output of the activity schedule will be the assignment of specific resources (such as
skill sets) to the project activities.
7. Project notebook
Documentation of any type is always a chore to produce. After the project completion
the documents are stored for future reference.
PROJECT PROPOSAL
Conclusion of all the planning is the project proposal.
Project proposal is the deliverable from the JPP session and is forwarded to the senior
management team for approval to do the project.
It states the complete business case for the project. This includes expected business
value, as well as cost and time estimates.
In addition to this information, the proposal details
 what is to be done,
 who is going to do it,
 when it is going to be done, and
 how it is going to be done.
It is the roadmap for the project.
Contents of the Project Proposal
Each organization will have a prescribed format for its project proposal, but
most proposals will have sections similar to the ones in the list that follows.
Project proposal is a restatement of all the planning work that has been done so far.
1. Background
 This brief description details the situation that led to the project proposal.
 It often states the business conditions, opportunities, and any problems giving rise to
the project.
 It sets the stage for later sections and puts the project in the context of the business.
SEMCOM
Page 19 of 21
US05EBCA02 (Software Project Management)
Unit-II
2. Objective
 This section gives a very general statement of what you hope to accomplish through
this project.
 Avoid jargon, because you don’t know who might have reason to read this section.
 Use the language of the business, not the technical language of your department.
 The objective should be clearly stated so that there is no doubt as to what is to be
done and what constitutes attainment of the objective.
3. Overview of approach to be taken
 For those who might not be interested in the details of how you are going to reach
your objective, this section provides a high-level outline of your approach.
 Again, avoid jargon whenever possible.
 Give a brief statement of each step and a few sentences of supporting narrative.
Brevity and clarity are important.
4. Detailed statement of work
 Here is where you give the details of your approach.
 Include
 what will be done,
 when it will be done,
 who will do it,
 how much time will be required of them, and
 what criteria will be used to measure completeness.
 This is the roadmap of all the project work.
 We have found Gantt charts useful for presentations of schedule data. They are
easily understood and generally intuitive even for people who are seeing them for the
first time.
5. Time and cost summary
 It is our practice to include a summary page of time and cost data. This usually works
best if done as a Gantt chart.
 Often the data will have been stated over several pages and is brought together here
for easy review and comment by the customer.
6. Appendices
 We reserve the appendix for all supporting data and details that are not germane to
the body of the proposal.
 Anticipate questions your customer might have, and include answers here.
Remember that this is detail beyond the basic description of the project work.
 Supporting information is generally found here.
SEMCOM
Page 20 of 21
US05EBCA02 (Software Project Management)
Unit-II
PROJECT MANAGEMENT PLAN
A project management plan is a formal, approved document that defines how the
project is executed, monitored and controlled.
It may be summary or detailed and may be composed of one or more subsidiary
management plans and other planning documents.
The objective of a project management plan is to define the approach to be used by the
Project team to deliver the intended project management scope of the project.
The project manager creates the project management plan following input from the
project team and key stakeholders. The plan should be agreed and approved by at least
the project team and its key stakeholders.
The project management plan content will vary depending upon the application area
and complexity of the project.
The project management plan is developed through a series of integrated processes
until project closure.
The project management plan typically covers topics used in the project execution
system and includes the following main aspects:









Scope Management
Schedule Management
Financial Management
Quality Management
Resource Management
Communications management
Project Change Management
Risk Management
Procurement Management
It is good practice and mostly required by large consulting and professional project
management firms, to have a formally agreed and version controlled project
management plan approved in the early stages of the project, and applied throughout
the project.
Project planning is part of project management, which relates to the use of schedules
such as Gantt charts to plan and subsequently report progress within the project
environment.
Disclaimer
The study material is compiled by Ami D. Trivedi. The basic objective of this material is
to supplement teaching and discussion in the classroom in the subject. Students are
required to go for extra reading in the subject through library work.
SEMCOM
Page 21 of 21

Download Report