PROJECT MANAGEMENT

PROF.AKILA VICTOR
 AGENDA
• Project Plan Structure
• Activity Organization
• Project Scheduling
• Scheduling Problems
• Risk
• Risk Management
 Management activities
• Proposal writing
• Project planning and scheduling
• Project costing
• Project monitoring and reviews
• Personnel selection and evaluation
• Report writing and presentations
PROJECT PLAN STRUCTURE
• Introduction
• Project Organisation
• Risk Analysis
• Hardware and Software Resource Requirements
• Work breakdown
• Project Schedule
• Monitoring and Reporting Mechanisms
 Project planning process
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise )then
Initiate technical review and possible revision
end if
end loop
 Work Breakdown Structure
• A Work Breakdown Structure (WBS) is a
deliverable-oriented hierarchical decomposition of
the work to be executed by the project team to
accomplish the project objectives and create the
required deliverables.
• All the work contained within the WBS is to be
identified, estimated, scheduled, and budgeted.
Example
 Cont…
A good WBS should exhibit the following
characteristics:
• Definable—can be described and easily understood
by project participants.
• Manageable—a meaningful unit of work where
specific responsibility and authority can be assigned
to a responsible individual.
• Estimate able—duration can be estimated in time
required to complete, and cost can be estimated in
resources required to complete.
 Cont…
• Independent—minimum interface with or dependence on other
ongoing elements (i.e., assignable to a single control account,
and clearly distinguishable from other work packages).
• Integra table—integrates with other project work elements and
with higher level cost estimates and schedules to include the
entire project.
• Measurable—can be used to measure progress; has start and
completion dates and measurable interim milestones.
• Adaptable—sufficiently flexible so the addition/elimination of
work scope can be readily accommodated in the WBS
framework.
 Tips for WBS
• Review the Work Breakdown Structure. Make sure all
deliverables have been fully covered by the works
defined in the Work Breakdown Structure.
• Ensure that testing and training have been taken into
account.
• Ensure that non-IT work packages are also included
such as, documentation and review activities are
included in the structure.
 Cont…
• Ensure that other supporting activities such as,
product/service launch and implementation activities
are planned.
• Ensure that delivery approval cycles are taken into
account.
• Include project management deliverables on the
project as well (e.g. production of Project Plan).
Include any deliverables that must be met or
delivered by the customer or any external parties.
Check the Work Breakdown Structure against the
project approach specified in Project Charter for any
activities that needs to be included in the Work
 Phases of WBS
Phase-based structures
• Define and structure project activities based on the
project phases.
Deliverable-based structures
• Define and structure project activities based on the
deliverables agreed to deliver.
Responsibility-based structure
• Define and structure project activities based on the
organization units that will work on the project.
Phase-based structures
Deliverable-based structures
Responsibility-based structure
Resource Breakdown
Risk Breakdown
Organizational Breakdown
 Activity Organization

• Activities in a project should be organised to produce

tangible outputs for management to judge progress
• Milestones are the end-point of a process activity
• Deliverables are project results delivered to
customers
• The waterfall process allows for the straightforward
definition of progress milestones
 Milestones

ACTIVITIES

Feasibility Requirements Prototype Design Requirement

study analysis development study specification

Feasibility Requirements Evaluation Architectural Requirement

report definition report design specification

MILESTONES
 Project Scheduling
• Split project into tasks and estimate time and
resources required to complete each task
• Organize tasks concurrently to make optimal
use of workforce
• Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete
• Dependent on project managers intuition and
experience
 The Project Scheduling Process
• Identify activities
• Identify activity dependencies
• Estimate resources for activities
• Allocate people to activities
• Create project charts
 Scheduling Problems
• Estimating the difficulty of problems and
hence the cost of developing a solution is hard
• Productivity is not proportional to the number
of people working on a task
• Adding people to a late project makes it later
because of communication overheads
• The unexpected always happens. Always allow
contingency in planning
 Bar Charts and Activity Charts
• Graphical notations used to illustrate the project
schedule
• Show project breakdown into tasks. Tasks should
not be too small. They should take about a week
or two
• Activity charts show task dependencies and the
critical path
– the sequence of stages determining the minimum time
needed for an operation, especially when analyzed on a
computer for a large organization.
• Bar charts show schedule against calendar time
 Problem
TASK DURATION DEPENDENCIES
T1 8 days
T2 15
T3 15 T1(M1)
T4 10
T5 10 T2, T4(M2)
T6 5 T1,T2(M3)
T7 20 T1(M1)
T8 25 T4(M5)
T9 15 T3,T6(M6)
T10 15 T5,T7(M7)
T11 7 T9(M4)
T12 10 T11(M8)
 Activity network
14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99
 Risk Management
• Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
• A risk is a probability that some adverse
circumstance will occur.
– Project risks affect schedule or resources
– Product risks affect the quality or performance of the
software being developed
– Business risks affect the organisation developing or
procuring the software
 Software Risks
Risk Risk Type Description
Staff Turnover Project Experienced staff leaves
before the project is
completed
Management Change Project Priorities change
Hardware Unavailability Project Not delivered on time
Requirements change Project and Product Lot of changes that will
affect
Specification delay Project and Product Not available at the time of
CASE tools under Product CASE tools doesn’t work as
performance anticipated
Technology Change Business Technology changed
Product Competition Business Competitive product is
marketed before the
system is completed
 The Risk Management Process

Risk Risk analysis Risk planning Risk

identification monitoring

List of potential Risk avoidance Risk

Prioritised risk and contingency
risks list assessment
plans
 Risk Identification
• Technology risks
• People risks
• Organisational risks
• Requirements risks
• Estimation risks
 Types of Risk
Risk type Possible risks
Technology The database used in the system cannot process as
many transactions per second as expected.
Software components which should be reused contain
defects which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different
management are responsible for the project.
Organisational financial problems force reductions in the
project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design
rework are proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is
underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
 Risk analysis
• Assess probability and seriousness of each risk
• Probability may be very low, low, moderate,
high or very high
• Risk effects might be catastrophic, serious,
tolerable or insignificant
 Risk Analysis
Risk Probability Effects
Organisational financial problems force Low Catastrophic
reductions in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
required for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
design rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
The database used in the system cannot process Moderate Serious
as many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
 Risk Planning
• Consider each risk and develop a strategy to
manage that risk
• Avoidance strategies
– The probability that the risk will arise is reduced
• Minimisation strategies
– The impact of the risk on the project or product will be
reduced
• Contingency plans
– If the risk arises, contingency plans are plans to deal
with that risk
 Risk Monitoring
• Assess each identified risks regularly to decide
whether or not it is becoming less or more
probable
• Also assess whether the effects of the risk have
changed
• Each key risk should be discussed at
management progress meetings
 Risk factors

Risk type Potential indicators

Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational organisational gossip, lack of action by senior management
Tools reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements many requirements change requests, customer complaints
Estimation failure to meet agreed schedule, failure to clear reported
defects
 Key points
• A project milestone is a predictable state where
some formal report of progress is presented to
management.
• Risks may be project risks, product risks or
business risks
• Risk management is concerned with
identifying risks which may affect the project
and planning to ensure that these risks do not
develop into major threats
 Examples
TASK DURATION DEPENDENCIES
T1 6
T2 10
T3 8 T1
T4 5 T2,T1
T5 8 T3
T6 15 T4,T5
T7 15 T1
T8 10 T6
T9 25 T6,T7
T10 10 T8,T9
T11 8 T10
T12 12 T11
 Solution
• Give an example of a situation that entails uncertainty
but not exposure, and hence no risk.
• Solution
– A spectator watches a man walk unprotected on a
tightrope. The spectator is uncertain whether the
man will fall, but is not personally exposed to a
fall. Uncertain but not exposed, the spectator does
not face risk.
 Cont…
• Give an example of a situation that entails
exposure but not uncertainty, and hence no risk.
• Solution
A farmer’s crops die in the field due to a
prolonged drought. The farmer is exposed to the
drought, but he is not uncertain. The existence of
the drought and its consequences are certainties to
him. Exposed but not uncertain, the farmer does
not face risk.
 Cont…
• In our example of the deaths per passenger-mile risk
metric, for what random variable’s probability
distribution may we interpret it as reflecting a mean?
• Solution
– The random variable is the number of deaths that
occur in a planned passenger-mile. The random
variable can take on the values 0 or 1.
 Reference
• https://www.visual-paradigm.com/guide/project-
management/what-is-work-breakdown-structure/