1.
Chapter Two :-Project Scope
Management & Planning
5/24/2019
1
Information System Project Management

2.
Project planning
• Project integration management involves coordinating all of the other
project management knowledge areas throughout a project’s life
cycle .Six main processes are involved in project integration
management:
• Developing the project charter:-involves working with stakeholders to create the
document that formally authorizes a project
• Developing the project management plan:-involves coordinating all planning efforts to
create a consistent, document
• Directing and managing project work:-involves carrying out the project management
plan
• Monitoring and controlling project work:-involves overseeing activities to meet th
performance objectives of the project.
• Performing integrated change control:- involves identifying, evaluating, and managing
changes throughout the project life
5/24/2019
2

3.
• Closing the project or phase :- involves finalizing all activities to formally close
the project or phase
5/24/2019
3

4.
• Different techniques and tools to implement integration
managements are :-
• Project selection methodologies
• Project management methodologies
• Stakeholder analysis
• Work request
• Project charter
• Project management plan
• Change control board
• Project review methodologies
• Project management software
• Change request
• Lesson learned request
5/24/2019
4

5.
Project selection methods
• Once a project proposal has been received, there are numerous
factors that need to be considered before an organization decides to
take it up
• There are various project selection methods practised by the modern
business organizations. These methods have different features and
characteristics. Therefore, each selection method is best for different
organizations
5/24/2019
5

6.
• Two of such methods are listed
• Benefit Measurement and
• Constrained Optimization methods
• As the value of one project would need to be compared against the
other projects, you could use the benefit measurement methods.
• You and your team could come up with certain criteria that you want your ideal project
objectives to meet
• The mathematical approach is commonly used for larger projects
• The constrained optimization methods require several calculations in
order to decide on whether or not a project should be rejected.
5/24/2019
6

7.
• Questions that you may want to consider asking in the selection
process are:
• Would this decision help me to increase organizational value in the long run?
• How long will the equipment last for?
• Would I be able to cut down on costs as I go along?
5/24/2019
7

8.
project management methodologies
• A methodology is a model, which project managers employ for the
design, planning, implementation and achievement of their project
objectives
• Adaptive Project Framework
• In this methodology, the project scope is a variable. Additionally, the time and the
cost are constants for the project. Therefore, during the project execution, the
project scope is adjusted in order to get the maximum business value from the
project.
• Agile Software Development
• Agile software development methodology is for a project that needs extreme
quickness in requirements. The key features of agile are its short-termed delivery
cycles (sprints), agile requirements, dynamic team culture, less restrictive project
control and emphasis on real-time communication.
5/24/2019
8

9.
• Crystal Methods
• In crystal method, the project processes are given a low priority. Instead of the
processes, this method focuses more on team communication, team member skills,
people and interaction.
• Rapid Application Development (RAD)
• This methodology focuses on developing products faster with higher quality. When it
comes to gathering requirements, it uses the workshop method. Prototyping is used for
getting clear requirements.
• Waterfall (Traditional)
• In this model, development lifecycle has fixed phases and linear timelines. This model is
not capable of addressing the challenges in the modern software development domain.
5/24/2019
9

10.
Project charter
• Project Charter refers to a statement of objectives in a project
• This statement also sets out detailed project goals, roles and
responsibilities, identifies the main stakeholders, and the level of
authority of a project manager.
• The Role of Project Charter
• It documents the reasons for undertaking the project.
• Outlines the objectives and the constraints faced by the project.
• Provides solutions to the problem in hand.
• Identifies the main stakeholders of the project.
5/24/2019
10

11.
Project management plan
• The purpose of project management plane document is to provide a
comprehensive baseline of
• what has to be achieved by the project
• how it is to be achieved
• who will be involved
• how it will be reported and measured
• and how information will be communicated
5/24/2019
11

12.
• PMP is developed as part of the project initiation and definition. But
also it should be a living document that evolves as the project
progresses and is updated with the latest relevant information as
required.
5/24/2019
12

13.
SUGGESTED CONTENTS OF THE PROJECT MANAGEMENT PLAN
• Executive summary :-
• This section should include a few paragraphs describing, at a high level, the key elements
of the project that are detailed throughout the project plan.
• Strategic/ organizational alignment
• It must be determined which organizational objectives will be supported by undertaking
the project. This section should also include the results of the project’s stakeholder
analysis.
• Project scope definition
• The purpose and objectives of the project should be stated in this section
• Feasibility assessment and contingency plans
• this section should evaluate the economic, technical, operational and organisational
feasibility of the project; identify and assess project risks; and prepare risk plan
5/24/2019
13

14.
• Constraints
• a list of any known constraints imposed by the environment or by management e.g. fixed
budget, limited resources etc
• Human resource requirements
• Define the project team organisation, roles and responsibility requirements.
• Training requirements will need to be identified here and the development of a project
training plan should begin.
• Material/equipment requirements
• define space, hardware/software, and other resources needed to complete the project
successfully
• Project schedule and milestones
• define the milestones and activity schedule of the project
5/24/2019
14

15.
• Budget/cost estimate
• Estimates are required for the project duration:-capital items, expense and labor
• Risk Management
• detail the process to be employed on the project in order to manage risk
• Project issues
• issues are the things that have happened which are outside the authority of the project
manager and need to be accelerated in order to achieve a resolve
• Change management
• The change management process to be utilized on the project should be described
• Communication management
• description of the system of communications and the project performance documentation
that will be provided to the various stakeholders.
5/24/2019
15

16.
• Related products and deliverables
• This section should document known project dependencies, with other groups within or
outside of the organisation to ensure the project is not exposed by other business processes
• Approvals
• This section will capture approval signatures from project stakeholders
• Attachments
• Included in this section will be pointers to pertinent documents such as the business case,
notes and related documents.
5/24/2019
16

17.
Project scope management
• Project Scope Management required to ensure that the project
includes all the work required, and only the work required, to
complete the project successfully.
• The term scope can refer to in different perspective :
• Product scope. The features and functions that characterize a product, service, or result;
and/or
• Project scope. The work performed to deliver a product, service, or result with the
specified features and functions.
5/24/2019
17

18.
Project Scope Management processes
• Plan Scope Management:- The process of creating a scope management plan that
documents how the project scope will be defined, validated, and controlled.
• Collect Requirements:- The process of determining, documenting, and managing
stakeholder needs and requirements to meet project objectives.
• Define Scope:- The process of developing a detailed description of the project and
product.
• Create WBS:- The process of subdividing project deliverables and project work into
smaller, more manageable components.
• Validate Scope:- The process of formalizing acceptance of the completed project
deliverables.
• Control Scope:- The process of monitoring the status of the project and product scope
and managing changes to the scope baseline.
5/24/2019
18

19.
• The first step in project scope management is planning how the scope
will be managed throughout the life of the project.
• Plan scope management is a process of creating a scope management
plan that documents how the project scope will be defined, validated,
and controlled.
• After reviewing the project management plan, project charter,
enterprise environmental factors, and organizational process assets,
the project team uses expert judgment and meetings to develop two
important outputs: the scope management plan and the
requirements management plan.
5/24/2019
19

20.
5/24/2019
20

21.
• Small projects may not need a written scope management plan, but
large projects or highly technical projects often benefit from one
• scope management plan includes the following information
• How to prepare a detailed project scope statement
• How to create a WBS
• How to maintain and approve the WBS
• How to obtain formal acceptance of the completed project deliverables
• How to control requests for changes to the project scope
5/24/2019
21

22.
• The requirements management plan documents how project
requirements will be analyzed, documented, and managed. A
requirements management plan can include the follow in information
• How to plan, track, and report requirements activities
• How to perform configuration management activities
• How to prioritize requirements
• How to use product metrics
• How to trace and capture attributes of requirements
5/24/2019
22

23.
Plan Scope Management: Inputs
• Project Management Plan
• The project management plan are used to create the scope management plan and
influence the approach taken for planning scope and managing project scope.
• Project Charter
• provides the high-level project description and product characteristics from the project
statement of work.
• Enterprise Environmental Factors
• The enterprise environmental factors that can influence the Plan Scope Management
process include, but are not limited to:
• Organization’s culture,
• Infrastructure,
• Personnel administration, and
• Marketplace conditions.
5/24/2019
23

24.
• Organizational Process Assets
• The organizational process assets that can influence the Plan Scope Management process
include, but are not limited to:
• Policies and procedures, and
• Historical information and lessons learned knowledge base.
• Plan Scope Management: Tools and Techniques
• Expert Judgment
• Expert judgment refers to input received from knowledgeable and experienced parties.
Expertise may be provided by any group or person with specialized education,
knowledge, skill, experience, or training in developing scope management plans.
• Meetings
• Project teams may attend project meetings to develop the scope management plan.
Attendees at these meetings may include the project manager, the project sponsor,
selected project team members, selected stakeholders, anyone with responsibility for
any of the scope management processes.
5/24/2019
24

25.
Collect Requirements
• Collect Requirements is the process of determining, documenting,
and managing stakeholder needs and requirements to meet project
objectives
5/24/2019
25

26.
• Many organizations categorize requirements into different types
• Business requirements, which describe the higher-level needs of the organization as a
whole, such as the business issues or opportunities, and reasons why a project has been
undertaken.
• Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.
• Solution requirements, which describe features, functions, and characteristics of the
product, service, or result that will meet the business and stakeholder requirements.
Solution requirements are further grouped into functional and nonfunctional
requirements:
• Functional requirements Describe functionality or system services. Functional user
requirements may be high-level statements of what the system should do BUT functional
system requirements should describe the system services in detail
• Nonfunctional requirements Define system properties and constraints e.g. Reliability,
response time and storage requirements. Constraints are I/O device capability system
representations
5/24/2019
26

27.
• Transition requirements describe temporary capabilities, such as data conversion and
training requirements, needed to transition from the current “as-is” state to the future
“to-be” state.
• Project requirements, which describe the actions, processes, or other conditions the
project needs to meet.
• Quality requirements, which capture any condition or criteria needed to validate the
successful completion of a project deliverable or fulfillment of other project
requirements.
• Process requirements may also be specified, mandating a particular CASE system,
programming language or development method
• Product requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, security etc
5/24/2019
27

28.
• Organisational requirements Requirements which are a consequence of
organisational policies and procedures e.g. process standards used,
implementation requirements, etc. (Java as programming language
• External requirements Requirements which arise from factors which are
external to the system and its development process e.g. interoperability
requirements, legislative requirements, etc. (Must conform to FIPS
5/24/2019
28

29.
Metrics for Non-functional Requirements
Features Measures
Speed •Processed transaction/ second
•User/event response time
•Screen refresh rate
Size •Amount of memory (KB)
•Number of RAM chips.
Ease of use •Training time
•Number of help windows
Reliability •Mean time to failure (MTTF)
•Portability of unavailability
•Rate of failure occurrence
Robustness •Time to restart after failure
•Percentage of events causing failure
•Probability of data corruption on failure
Portability •Percentage of target-dependent statements
•Number of target systems
5/24/2019
29

30.
Examples
• All users will access the system using a user id and a password, The system
shall support the following document formats : PDF,RTF, Microsoft Word 2010
and ASCII text Every order shall be allocated a unique identifier (ORDER_ID)
The system have a mechanism to help recover a user’s password
• All encryption should use the Advanced Encryption Standard
• The system should respond to a user’s request for information in less than
0.1 seconds during “peak time” and 0.01 seconds during “normal time”
• The system shall not disclose any personal information about customers
apart from their name and reference number to the operators of the system
5/24/2019
30

31.
Input
• The scope management plan provides clarity as to how project teams will determine
which type of requirements need to be collected for the project.
• The requirements management plan provides the processes that will be used throughout
the Collect Requirements process to define and document the stakeholder needs.
• The stakeholder management plan is used to understand stakeholder communication
requirements.
• The project charter is used to provide the high-level description of the product, service,
or result of the project so that detailed requirements can be developed.
• The stakeholder register is used to identify stakeholders who can provide information on
the requirements. The stakeholder register also captures major requirements and main
expectations stakeholders may have for the project.
5/24/2019
31

32.
Collect Requirements: Tools and Techniques
• Interviews:- by asking prepared and spontaneous questions and
recording the responses
• Focus Groups:-Focus groups bring together prequalified stakeholders
and subject matter experts to learn about their expectations and
attitudes about a proposed product, service, or result
• Facilitated Workshops:- bring key stakeholders together to define
product requirements
• Group Creativity Techniques:-Several group activities can be
organized to identify project and product requirements
5/24/2019
32

33.
• Group Decision-Making Techniques:-is an assessment process having
multiple alternatives with an expected outcome in the form of future actions
• Questionnaires and Surveys :- are written sets of questions designed to
quickly accumulate information from a large number of respondents.
• Observations:-
• Prototypes
• Benchmarking
5/24/2019
33

34.
Output
• Requirements Documentation:- Requirements documentation
describes how individual requirements meet the business need for
the project.
• Business requirements
• Stakeholder requirements
• Project requirements, and…..
• Requirements Traceability Matrix:-is a grid that links product
requirements from their origin to the deliverables that satisfy them
• It provides a means to track requirements throughout the project life
cycle, helping to ensure that requirements approved in the
requirements documentation are delivered at the end of the project
5/24/2019
34

35.
• tracing requirements matrix include for the following but not limited
are :
• Business needs, opportunities, goals, and objectives
• Project objectives
• Project scope/WBS deliverables
• Product design
• Product development;
• Test strategy and test scenarios;
• Attributes associated with each requirement can be recorded in the
requirements traceability matrix.
5/24/2019
35

36.
5/24/2019
36

37.
Define Scope
• Define Scope is the process of developing a detailed description of
the project and product.
• The key benefit of this process is that it describes the project, service,
or result boundaries by defining which of the requirements collected
will be included in and excluded from the project scope
5/24/2019
37

38.
Inputs
• The Define Scope process selects the final project requirements from
the requirements documentation delivered during the Collect
Requirements process
• Scope Management Plan
• Project Charter
• Requirements Documentation
• Organizational Process Assets
• Policies, procedures, and templates for a project scope statement;
• Project files from previous projects; and
• Lessons learned from previous phases or projects.
5/24/2019
38

39.
Tools and Techniques
• Expert Judgment
• Other units within the organization;
• Consultants;
• Stakeholders, including customers or sponsors;
• Professional and technical associations;
• Industry groups; and
• Subject matter experts.
5/24/2019
39

40.
Outputs
• Project Scope Statement
• The project scope statement is the description of the project scope, major deliverables,
assumptions, and constraints.
• The project scope statement documents the entire scope, including project and product
scope
• It also provides a common understanding of the project scope among project stakeholders.
• The detailed project scope statement includes the following:
• Product scope description. Progressively elaborates the characteristics of the product,
service, or result described in the project charter and requirements documentation
• Acceptance criteria, A set of conditions that is required to be met before deliverables are
accepted
• Deliverable.
• Project exclusion. Out of scope
• Constraints
5/24/2019
40

41.
• The project charter contains high-level information, while the project
scope statement contains a detailed description of the scope
elements
5/24/2019
41

42.
• Project Documents Updates
• Project documents that may be updated include, but are not limited
to:
• Stakeholder register,
• Requirements documentation, and
• Requirements traceability matrix
5/24/2019
42

43.
5/24/2019
43

44.
CREATING THE WORK BREAKDOWN STRUCTURE
• work breakdown structure (WBS) is a deliverable-oriented grouping
of the work involved in a project that defines its total scope
• Create WBS is the process of subdividing project deliverables and
project work into smaller, more manageable components.
5/24/2019
44

45.
Decomposition
• Decomposition is a technique used for dividing and subdividing the
project scope and project deliverables into smaller, more manageable
parts
• Decomposition of the total project work into work packages generally
involves the following activities:
• Identifying and analyzing the deliverables and related work;
• Structuring and organizing the WBS;
• Decomposing the upper WBS levels into lower-level detailed components;
• Developing and assigning identification codes to the WBS components; and
• Verifying that the degree of decomposition of the deliverables is appropriate.
5/24/2019
45

46.
Scope Baseline
• The scope baseline is the approved version of a scope statement,
work breakdown structure (WBS), and its associated WBS dictionary
• Components of the scope baseline include
• Project scope statement
• WBS
• WBS dictionary
• WBS dictionary:- The WBS dictionary is a document that provides
detailed deliverable, activity, and scheduling information about each
component in the WBS.
5/24/2019
46

47.
Information in the WBS dictionary may include, but is not limited to
• Code of account identifier,
• Description of work,
• Assumptions and constraints,
• Responsible organization,
• Schedule milestones,
• Associated schedule activities,
• Resources required,
• Cost estimates,
• Quality requirements,
• Acceptance criteria,
• Technical references, and
• Agreement information.
5/24/2019
47

48.
Types of WBS approach
• Using guidelines:- If guidelines exist for developing a WBS, it is very important to follow
them
• The analogy approach:-you use a similar project’s WBS as a starting point .
• The top-down approach:- start with the largest items of the project and break them into
subordinate items. This process involves refining the work into greater and greater levels
of detail.
• The bottom-up approach:-team members first identify as many specific tasks related to
the project as possible. They then aggregate the specific tasks and organize them into
summary activities, or higher levels in the WBS.
• The mind-mapping approach:-to write and even draw pictures of ideas in a nonlinear
format
5/24/2019
48

49.
5/24/2019
49

50.
Example
5/24/2019
50
Sample WBS Decomposed Down Through Work Packages

51.
5/24/2019
51
Sample WBS Organized by Phase

52.
5/24/2019
52
Sample WBS with Major Deliverables

53.
Validate Scope
• Validate Scope is the process of formalizing acceptance of the
completed project deliverables
• The key benefit of this process is that it brings objectivity to the
acceptance process and increases the chance of final product,
5/24/2019
53

54.
Control Scope
• Control Scope is the process of monitoring the status of the project
and product scope and managing changes to the scope baseline.
• The key benefit of this process is that it allows the scope baseline to
be maintained throughout the project.
5/24/2019
54

55.
• Variance :- Variance analysis is a technique for determining the cause
and degree of difference between the baseline and actual
performance.
• Project performance measurements are used to assess the magnitude
of variation from the original scope baseline.
5/24/2019
55

56.
Project time management
• Managers need to be deliver projects on time and one of their
biggest challenges and the main cause of conflict is delivering project
on time
• a project schedule is set, people remember the projected completion
date
• Time is the adjustable that has the least amount of flexibility.
• Time passes no matter what happens on a project.
5/24/2019
56

57.
• Seven main processes involved in project management to ensure
timely completion of a project.
• Planning schedule management involves determining
• policies
• procedures and
• documentation
that will be used for planning, executing, and controlling the project schedule.
The main output of this process is a
• schedule management plan.
• Defining activities involves identifying the specific activities that the project team
members and stakeholders must perform to produce the project deliverables.
• An activity or task is an element of work normally found on the work breakdown structure
(WBS) that has expected duration, cost, and resource requirements.
5/24/2019
57

58.
• The main outputs of this process are an
• activity list
• activity attributes
• a milestone list
• project management plan updates.
• Sequencing activities involves identifying and documenting the relationships between
project activities.
• The main outputs of this process include
• project schedule
• project documents updates.
• Estimating activity resources involves estimating how many resources, people,
equipment, and materials a project team should use to perform project activities.
• The main outputs of this process are
• activity resource requirements
• a resource breakdown structure,
• project documents updates.
5/24/2019
58

59.
• Estimating activity durations involves estimating the number of work periods that are
needed to complete individual activities.
• Outputs include
• activity duration estimates
• project documents updates
• Developing the schedule involves analyzing activity sequences, activity resource
estimates, and activity duration estimates to create the project schedule.
• Outputs include a
• schedule baseline
• project schedule
• schedule data
• project calendars
• project management plan updates
• project documents update
5/24/2019
59

60.
• Controlling the schedule involves controlling and managing changes to the project
schedule.
• Outputs include
• work performance information
• schedule forecasts
• change requests
• project management plan updates
• project documents updates
• organizational process assets updates.
5/24/2019
60

61.
PLANNING SCHEDULE MANAGEMENT
• Project schedule model development:- project activities with estimated durations
• Level of accuracy and units of measure:- time is measured in hours, days, or another unit.
• Control thresholds :- +/- 10%
• Rules of performance measurement:-how to determine the percentages..
• Reporting formats:-schedule reports required for the project
• Process descriptions:-how all of the schedule management processes will be performed.
5/24/2019
61

62.
DEFINING ACTIVITIES
• Defining activities involves identifying the specific actions that will
produce the project deliverables in enough detail to determine
resource and schedule estimates
• The activity list is a tabulation of activities to be included on a project
schedule
• The list should include
• the activity name
• an activity identifier or number
• a brief description of the activity
• The activity attributes:- provide schedule-related information about each
activity, such as predecessors, successors, logical relationships, leads and lags,
resource requirements, constraints, imposed dates, and assumptions related
to the activity
5/24/2019
62

63.
• The activity list and activity attributes should agree with the WBS and
WBS dictionary
• A milestone on a project is a significant event that normally has no duration
• Milestone is a marker to help in identifying necessary activities.
• Milestones are useful tools for setting schedule goals and monitoring progress
• For example
• completion of specific products
• software modules or installation of new hardware;
• completion of important process-related work
• project review meetings and tests.
5/24/2019
63

64.
SEQUENCING ACTIVITIES
• After defining project activities, the next step in project time
management is sequencing them or determining their dependencies
• The sequencing process involves evaluating the reasons for
dependencies and the different types of dependencies.
• A dependency or relationship affects to the sequencing of project
activities or tasks.
• Example does a certain activity have to be finished before another can start?
• Can the project team do several activities in parallel?
• Can some overlap?
• Determining these relationships or dependencies among activities is crucial
for developing and managing a project schedule.
5/24/2019
64

65.
• There are three basic reasons for identifying dependencies among
project activities
• Mandatory dependencies are inherent in the nature of the work being performed on a
project. They are sometimes referred to as hard logic. For example, you cannot test code until
after the code is written.
• Discretionary dependencies are defined by the project team. For example, a project team
might follow good practice and not start the detailed design of a new information system until
the users sign off on all of the analysis work. Discretionary dependencies are sometimes
referred to as soft logic
• External dependencies involve relationships between project and non-project activities. For
example, the installation of a new operating system and other software may depend on
delivery of new hardware from an external supplier.
5/24/2019
65

66.
• Network diagrams are the preferred technique for showing activity
sequencing
• A network diagram is a diagram display of the logical relationships
among project activities and their sequencing. Some people refer to
network diagrams as project schedule network diagrams or PERT
charts.
5/24/2019
66

67.
• The precedence diagramming method (PDM) is a network
diagramming technique in which boxes represent activities. It is
particularly useful for visualizing certain types of time relationships.
5/24/2019
67

68.
Types of dependency
• Finish-to-start dependency: A relationship in which the “from” activity or predecessor
must finish before the “to” activity or successor can start. For example, you cannot
provide user training until after software or a new system has been installed
• Start-to-start dependency: A relationship in which the “from” activity cannot start until
the “to” activity or successor is started. For example, on IT projects, a group of activities
might start simultaneously, such as the many tasks that occur when a new system goes
live.
• Finish-to-finish dependency: A relationship in which the “from” activity must be finished
before the “to” activity can be finished. One task cannot finish before another finishes.
For example, quality control efforts cannot finish before production finishes, although
the two activities can be performed at the same time.
• Start-to-finish dependency: A relationship in which the “from” activity must start before
the “to” activity can be finished. For example, an organization might strive to stock raw
materials just in time for the manufacturing process to begin.
5/24/2019
68

69.
E.g.:- preceding diagram
5/24/2019
69

70.
ESTIMATING ACTIVITY RESOURCES
• questions to answer when estimating activity resources include:
• How difficult will specific activities be on this project?
• Is anything unique in the project’s scope statement that will affect resources?
• What is the organization’s history in doing similar activities?
• Has the organization done similar tasks before?
• What level of personnel did the work?
• Does the organization have people, equipment, and materials that are capable and
available for performing the work?
• Could any organizational policies affect the availability of resources?
• Does the organization need to acquire more resources to accomplish the work?
• Would it make sense to outsource some of the work? Will outsourcing increase or
decrease the amount of resources needed and when they will be available?
5/24/2019
70

71.
ESTIMATING ACTIVITY DURATIONS
• After working with key stakeholders to define activities, determine
their dependencies ,and estimate their resources, the next process in
project time management is to estimate the duration of activities
• It is important to note that duration includes the actual amount of time worked on an
activity plus elapsed time. Example:- 1 week with 5 day .. Estimating duration is 2 weeks
• It is the number of workdays or work hours required to complete a task.
• One of the most important considerations in making activity duration
estimates is the availability of resources, especially human resources.
• What specific skills do people need to do the work?
• What are the skill levels of the people assigned to the project?
• How many people are expected to be available to work on the project at any one time?
5/24/2019
71

72.
DEVELOPING THE SCHEDULE
• Schedule development uses the results of all the preceding project
time management processes to determine the start and end dates of
the project and its activities
• A Gantt chart is a common tool for displaying project schedule
information.
• Gantt charts provide a standard format for displaying project
schedule information by listing project activities and their
corresponding start and finish dates in calendar form
5/24/2019
72

73.
5/24/2019
73

74.
5/24/2019
74

75.
CONTROLLING THE SCHEDULE
• schedule control is a portion of the integrated change control process
in project integration management.
• The goal of schedule control is to know the status of the schedule,
influence the factors that cause schedule changes, determine that the
schedule has changed, and manage changes when they occur.
5/24/2019
75

76.
Project cost management
• Project cost management includes the processes required to ensure
that a project team completes a project within an approved budget
• Project managers must make sure their projects are well defined,
have accurate time and cost estimates, and have a realistic budget
that they were involved in approving
• There are four processes for project cost management
• Planning cost management
• Estimating costs
• Determining the budget
• Controlling costs
5/24/2019
76

77.
Planning cost management
• The first step in project cost management is planning how the costs
will be managed throughout the life of the project
• cost management plan includes the following information
• Level of accuracy፡- Activity cost estimates normally have rounding guidelines amount of
contingency funds to include eg:- +/-10%
• Units of measure:- Each unit used in cost measurements, such as labor hours or days,
should be defined.
• Organizational procedures links:-
• Control thresholds:
• Rules of performance measurement:
• Reporting formats:
• Process descriptions:
5/24/2019
77

78.
ESTIMATING COSTS
• Project managers must take cost estimates seriously if they want to
complete projects within budget constraints
• One of the main outputs of project cost management is a cost
estimate
• Types of Cost Estimates
• A rough order of magnitude (ROM)
• A budgetary
• A definitive
5/24/2019
78

79.
A rough order of magnitude (ROM)
• This type of estimate is done very early in a project or even before a
project is officially started
• Project managers and top management use this estimate to help
make project selection decisions
• ROM estimate’s accuracy is typically -50 percent to +100 percent,
meaning the project’s actual costs could be 50 percent below the
ROM estimate or 100 percent above. For example, the actual cost for
a project with a ROM estimate of $100,000 could range from $50,000
to $200,000.
5/24/2019
79

80.
A budgetary estimate
• It is used to allocate money into an organization’s budget
• Budgetary estimates are made one to two years prior to project
completion
• The accuracy of budgetary estimates is typically -10 percent to +25
percent, meaning the actual costs could be 10 percent less or 25
percent more than the budgetary estimate. For example, the actual
cost for a project with a budgetary estimate of $100,000 could range
from $90,000 to $125,000.
5/24/2019
80

81.
A definitive estimate
• provides an accurate estimate of project costs.
• Definitive estimates are used for making many purchasing decisions
for which accurate estimates are required and for estimating final
project costs
• Definitive estimates are made one year or less prior to project
completion. A definitive estimate should be the most accurate of the
three types of estimates.
• The accuracy of this type of estimate is normally -5 percent to +10
percent, meaning the actual costs could be 5 percent less or 10
percent more than the definitive estimate.
5/24/2019
81

82.
DETERMINING THE BUDGET
• Determining the budget involves allocating the project cost estimate
to individual material resources or work items over time
• These material resources or work items are based on the activities in
the work breakdown structure for the project
• The cost management plan
• scope baseline
• activity cost estimates
• basis of estimates
• project schedule
• Resource calendars
• risk register
• agreements and
• organizational process assets are all inputs for determining the budget
5/24/2019
82

83.
5/24/2019
83

84.
CONTROLLING COSTS
• Controlling project costs includes monitoring cost performance,
ensuring that only appropriate project changes are included in a
revised cost baseline, and informing project stakeholders of
authorized changes to the project that will affect costs
• The project management plan, project funding requirements, work
performance data, and organizational process assets are inputs for
controlling costs
5/24/2019
84

85.
Assignment 3
• Write brief description about COCOMO software cost estimation and
try to work your project with this software cost estimation model
• Submission date December 20/2018 (Tuesday morning )
5/24/2019
85

86.
Project risk management
• Project risk management is the art and science of identifying,
analyzing, and responding to risk throughout the life of a project.
• Risk management can have a positive impact on selecting projects,
determining their scope, and developing realistic schedules and cost
estimates
• It helps project stakeholders understand the nature of the project,
involves team members in defining strengths and weaknesses, and
helps to integrate the other project management knowledge areas
5/24/2019
86

87.
Six major processes are involved in risk
management:
• Planning risk management
• Identifying risks
• Performing qualitative risk analysis
• Performing quantitative risk analysis
• Planning risk responses
• Controlling risk
5/24/2019
87

88.
RISK IDENTIFICATION
• Risk identification consists of determining which risks are likely to
affect the project and documenting the characteristics of each
• It is not a one time event; it should be performed on a regular basis
throughout the project
• Risk identification should address both internal and external risks.
• Internal risks are things that the project team can control or influence, such as staff
assignments and cost estimates.
• External risks are things beyond the control or influence of the project team,
such as market shifts or government action
5/24/2019
88

89.
• risk identification is concerned with opportunities (positive
outcomes) as well as threats (negative outcomes)..SWOT
5/24/2019
89

90.
Product description
• The nature of the product of the project will have a major effect on
the risks identified. Products that involve proven technology will, all
other things being equal, involve less risk than products which require
innovation or invention.
• Risks associated with the product of the project are often described in
terms of their cost and schedule impact.
5/24/2019
90

91.
Other planning outputs
• The outputs of the processes in other knowledge areas should be
reviewed to identify possible risks. For example:
• Work breakdown structure
• Cost estimates and duration estimates
• Staffing plan
• Procurement management plan
• market conditions
5/24/2019
91

92.
Historical information
• Historical information about what actually happened on previous
projects can be especially helpful in identifying potential risks.
Information
• on historical results is often available from the following sources:
• Project files
• Commercial databases
• Project team knowledge
5/24/2019
92

93.
Tools and techniques
• Checklists
• Flowcharting
• Interviewing
5/24/2019
93

94.
Outputs from Risk Identification
• Sources of risk:- Sources of risk are categories of possible risk events
Common sources of risk include:
• Changes in requirements.
• Design errors, omissions, and misunderstandings.
• Poorly defined or understood roles and responsibilities.
• Poor estimates.
• Insufficiently skilled staff.
5/24/2019
94

95.
• Potential risk events:-Potential risk events are isolated occurrences
such as a natural disaster or the departure of a specific team member
that may affect the project.
• risk symptoms:- sometimes called triggers, are indirect displays of
actual risk events
5/24/2019
95

96.
Risk quantification
• Risk quantification involves evaluating risks and risk interactions to
assess the range of possible project outcomes
• It is primarily concerned with determining which risk events deserve
response. It is complicated by a number of factors including, but not
limited to:
• opportunities and threats
• A single risk event can cause multiple effects
• Opportunities for one stakeholder (reduced cost) may be threats to another(reduced profits).
• The mathematical techniques used can create a false impression of precision and reliability.
5/24/2019
96

97.
Inputs to Risk Quantification
• Stakeholder risk tolerances:- Different organizations and different
individuals have different tolerances for risk
5/24/2019
97

98.
Tools and Techniques for Risk Quantification
• Expected monetary value:- Expected monetary value, as a tool for risk
quantification, is the product of two numbers:
• Risk event probability:- an estimate of the probability that a given risk event will occur.
• Risk event value :- an estimate of the gain or loss that will be acquired if the risk event does
occur. The risk event value must reflect both tangibles and intangibles
• Statistical sums:- Statistical sums can be used to calculate a range of total
project costs from the cost estimates for individual work items.
• Simulation :- simulation uses a representation or model of a system to analyze
the behavior or performance of the system.
• Decision trees. A decision tree is a diagram that depicts key interactions
among decisions and associated chance events as they are understood by the
decision maker
5/24/2019
98

99.
Assignment 4
1. Write brief description about Monte Carlo analysis
2. Submission date December 19/2018 (Tuesday
morning )
5/24/2019
99

100.
Outputs from Risk Quantification
• Opportunities to pursue, threats to respond to. The major output
from risk quantification is a list of opportunities that should be
pursued and threats that require attention.
• Opportunities to ignore, threats to accept. The risk quantification
process should also document
• those sources of risk and risk events that the project management team has
consciously decided to accept or ignore and
• who made the decision to do so.
5/24/2019
100

101.
RISK RESPONSE DEVELOPMENT
• It involves defining improvement steps for opportunities and
responses to threats. Responses to threats generally fall into one of
three categories:
• Avoidance:-eliminating a specific threat, usually by eliminating the cause. The project
management team can never eliminate all risk, but specific risk events can often be
eliminated.
• Mitigation:- reducing the expected monetary value of a risk event by reducing the probability
of occurrence (e.g., using proven technology , buying insurance
• Acceptance:- accepting the consequences. Acceptance can be active (e.g., by developing a
contingency plan to execute should the risk event occur)
5/24/2019
101

102.
5/24/2019
102

103.
Risk response control
5/24/2019
103
• Risk response control involves executing the risk management plan in
order to respond to risk events over the course of the project. When
changes occur, the basic cycle of identify, quantify, and respond is
repeated.