Project Management

IT3203 – Managing Software Projects
IT3203:Fundamentals of Software
Engineering
Managing Software Projects
Duration : 3 hours
UCSC - 2007
Instructional Objectives
State the requirement of managerial control of the

development process
Describe the main phases of software project

management
Describe project planning and project scheduling

activities in detail
UCSC - 2007
Detailed Syllabus
10.1. Need for the proper management of software projects
10.2. Management activities

10.2.1. Project planning
10.2.2. Estimating costs
10.2.3. Project scheduling
10.2.4. Risk management
10.2.5. Managing people
UCSC - 2007
10.1. Need for the Proper Management of

Software Projects
UCSC - 2007
Software Project Management
• Concerned with activities involved in ensuring that

software is delivered on time and on schedule and in
accordance with the requirements of the organisations
developing and procuring the software.
• Project management is needed because software

development is always subject to budget and schedule
constraints that are set by the organisation developing
the software.
UCSC - 2007
Software Management Distinctions

• The product is intangible.
• The product is uniquely flexible.
• Software engineering is not recognized as an

engineering discipline
• The software development process is not

standardised.
• Many software projects are 'one-off' projects.

UCSC - 2007
10.2. Management Activities
UCSC - 2007
Management Activities
• Proposal writing.
• Project planning and scheduling.
• Project costing.
• Project monitoring and reviews.
• Personnel selection and evaluation.
• Report writing and presentations.

UCSC - 2007
Project Staffing
• May not be possible to appoint the ideal people to
work on a project
– Project budget may not allow for the use of highly-
paid staff;
– Staff with the appropriate experience may not be
available;
– An organisation may wish to develop employee
skills on a software project.
• Managers have to work within these constraints

especially when there are shortages of trained staff.
UCSC - 2007
Project Planning
• Probably the most time-consuming project
management activity.
• Continuous activity from initial concept through to

system delivery.
• Plans must be regularly revised as new information

becomes available.
• Various different types of plan may be developed to

support the main software project plan that is
concerned with schedule and budget.
UCSC - 2007
Types of Project Plan

• Other than the project plan managers have to draw up
other plans as well
– Quality plan : Describes the quality procedures and standards
that will be used in a project
– Validation plan : Describes the approach, resources and

schedule used for system validation
– Configuration management plan : Describes the configuration

management procedures and structures to be used
– Maintenance plan : predicts the maintenance requirements of

the system, maintenance cost and effort required.
– Staff development plan : describes how the skill and experience

of the project team members will be developed.
UCSC - 2007
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
UCSC - 2007
The Project Plan
• The project plan sets out:

– The resources available to the project;
– The work breakdown;
– A schedule for the work.
UCSC - 2007
Project Plan Structure
• Introduction.
• Project organisation.
• Risk analysis.
• Hardware and software resource requirements.
• Work breakdown.
• Project schedule.
• Monitoring and reporting mechanisms.
UCSC - 2007
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.
• Deliverable are usually milestones but milestones need

not to be deliverables.
UCSC - 2007
Milestones in the RE Process
UCSC - 2007
Fundamental Estimation Questions
• How much effort is required to complete an

activity?
• How much calendar time is needed to complete
an activity?
• What is the total cost of an activity?
Project estimation and scheduling are interleaved

management activities.
UCSC - 2007
Software Cost Components

• Hardware and software costs.
• Travel and training costs.
• Effort costs (the dominant factor in most projects)

– E.g. The salaries of engineers involved in the project,
Social and insurance costs.
– Effort costs must take overheads into account

• Costs of building, heating, lighting.
• Costs of networking and communications.
• Costs of shared facilities (e.g library, staff restaurant, etc.).
UCSC - 2007
Costing and Pricing

• Estimates are made to discover the cost, to the
developer, of producing a software system.
• There is not a simple relationship between the

development cost and the price charged to the
customer.
• Broader organisational, economic, political and

business considerations influence the price
charged.
UCSC - 2007
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.
UCSC - 2007
The Project Scheduling Process
Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts
Software Activity charts

requirements and bar charts
UCSC - 2007
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.
UCSC - 2007
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.
UCSC - 2007
Software Risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a c hange of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the projec t will not be
delivered on schedule.
Requirements change Project and There will be a larger number of changes to the
product requirements than anticipate d.
Specification delays Project and Specifications of essential interfaces are not available on
product schedule
Size underestimate Project and The size of the system has been underestimate d.
product
CASE t ool under- Product CASE t ools w hich support the project do not perform as
performance anticipate d
Tec hnology change Business The u nderlying technology on which the system is b uilt is
superseded by new technology.
Product co mpetition Business A competitive product is marketed before the system is
completed.
UCSC - 2007
The Risk Management Process
UCSC - 2007
The Risk Management Process
• Risk identification
– Identify project, product and business risks;
• Risk analysis
– Assess the likelihood and consequences of these
risks;
• Risk planning
– Draw up plans to avoid or minimise the effects
of the risk;
• Risk monitoring
– Monitor the risks throughout the project;
UCSC - 2007
Risk Identification
• Technology risks.
• People risks.
• Organisational risks.
• Requirements risks.
• Estimation risks.
UCSC - 2007
Risks and Risk Types

Risk type Possible risks
Techno logy The da tabase used in the system cannot process as many transactions per second
as expected.
Software co mponen ts that should be reused contain defects that limit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unava ilable 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 budge t.
Tools The cod e generated by CASE tools is inefficient.
CASE tools canno t be integrated.
Requirements Changes to requirements that require major design rework are proposed .
Customers fail to understand the impact of requirements change s.
Estimation The time required to deve lop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
UCSC - 2007
Risk Analysis
• Assess probability and seriousness of each risk.
• Probability may be
– Very low (<10%),
– Low (10-25%),
– moderate (25-50%),
– high (50-75%), or
– very high (>75%) .
• Risk effects might be
– catastrophic,
– serious,
– tolerable or
– insignificant.
UCSC - 2007
Risk Analysis…
Risk Probability Effects

Organisational financial problems force reductions in Low Catastrophic
the project budget.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain Moderate Serious
defects which limit their functionality.
Changes to requirements that require major design Moderate Serious
rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
UCSC - 2007
Risk Analysis…
Risk Probability Effects

The database used in the system cannot process as Moderate Serious
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
UCSC - 2007
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;
UCSC - 2007
Risk Management Strategies
Risk Strategy
Organisational Prepare a briefing document for senior management
financial problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-
components in components of knownreliability.
UCSC - 2007
Risk Management Strategies…
Risk Strategy
Requirements Derive traceability information to assess requirements
changes change impact, maximise information hiding in the
design.
Organisational Prepare a briefing document for senior management
restructuring showing how the project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate buying in components, investigate use of a
development time program generator
UCSC - 2007
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.
UCSC - 2007
Risk Indicators
Risk type Potential indicators

Technology Late delivery of hardware or support software, many reported
technologyproblems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational Organisational gossip, lack of action bysenior management
Tools Reluctanceby team members to use tools, complaints about
CASE tools, demandsfor higher-powered workstations
Requirements Many requirements changerequests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects
UCSC - 2007
Managing People
UCSC - 2007
People in the Process

• People are an organisation’s most important
assets.
• The tasks of a manager are essentially people-

oriented. Unless there is some understanding of
people, management will be unsuccessful.
• Poor people management is an important

contributor to project failure.
UCSC - 2007
People Management Factors

• Consistency
– Team members should all be treated in a comparable
way without favourites or discrimination.
• Respect
– Different team members have different skills and these
differences should be respected.
• Inclusion
– Involve all team members and make sure that people’s
views are considered.
• Honesty
– You should always be honest about what is going well
and what is going badly in a project.
UCSC - 2007
Selecting Staff
• An important project management task is team

selection.
• Information on selection comes from:
– Information provided by the candidates.
– Information gained by interviewing and talking
with candidates.
– Recommendations and comments from other
people who know or who have worked with the
candidates.
UCSC - 2007
Motivating People
• An important role of a manager is to motivate the

people working on a project.
• Motivation is a complex issue but it appears that

their are different types of motivation based on:
– Basic needs (e.g. food, sleep, etc.);
– Personal needs (e.g. respect, self-esteem);
– Social needs (e.g. to be accepted as part of a
group).
UCSC - 2007
Personality Types
• The needs hierarchy is almost certainly an over-
simplification of motivation in practice.
• Motivation should also take into account different

personality types:
– Task-oriented;
– Self-oriented;
– Interaction-oriented.
UCSC - 2007
Personality Types
• Task-oriented.
– The motivation for doing the work is the work itself;
• Self-oriented.
– The work is a means to an end which is the
achievement of individual goals - e.g. to get rich, to
play tennis, to travel etc.;
• Interaction-oriented
– The principal motivation is the presence and actions
of co-workers. People go to work because they like
to go to work.
UCSC - 2007
Managing Groups
• Most software engineering is a group activity

– The development schedule for most non-trivial
software projects is such that they cannot be
completed by one person working alone.
• Group interaction is a key determinant of group

performance.
• Flexibility in group composition is limited

– Managers must do the best they can with
available people.
UCSC - 2007
Factors Influencing Group Working
• Group composition.
• Group cohesiveness.
• Group communications.
• Group organisation.
UCSC - 2007
Group Composition
• Group composed of members who share the
same motivation can be problematic
– Task-oriented - everyone wants to do their own thing;
– Self-oriented - everyone wants to be the boss;
– Interaction-oriented - too much chatting, not enough work.
• An effective group has a balance of all types.
• This can be difficult to achieve software engineers are

often task-oriented.
• Interaction-oriented people are very important as they

can detect and defuse tensions that arise.
UCSC - 2007
Group Cohesiveness
• In a cohesive group, members consider the group to be
more important than any individual in it.
• The advantages of a cohesive group are:

– Group quality standards can be developed;
– Group members work closely together so inhibitions
caused by ignorance are reduced;
– Team members learn from each other and get to know
each other’s work;
– Egoless programming where members strive to
improve each other’s programs can be practised.
UCSC - 2007
Group Communications
• Good communications are essential for effective

group working.
• Information must be exchanged on the status of

work, design decisions and changes to previous
decisions.
• Good communications also strengthens group

cohesion as it promotes understanding.
UCSC - 2007
Group Organisation
• Small software engineering groups are usually

organised informally without a rigid structure.
• For large projects, there may be a hierarchical

structure where different groups are responsible
for different sub-projects.
UCSC - 2007
Working Environments
• Work place makes an important effect on worker’s
performance and their job satisfaction.
• The most important environmental factors identified:

– Privacy: Programmers require an area where they can
concentrate and work without interruption.
– Outside awareness: People prefer to work in natural light and
with a review of the outside environment.
– Personalisation: Individuals adopt different working practices
and have different opinions on décor. The ability to rearrange
the workplace to suit working practices and to personalise that
environment is important.
UCSC - 2007
People Capability Maturity Model

• P-CMM which is comprised of 5 levels, can be used as a
framework for improving the way in which an organization
manages its human assets.
– Initial : Ad hoc, informal people management practices.
– Repeatable: Establishment of policies for developing the
capability of the staff.
– Defined: Standardisation of best people management
practice across the organisation.
– Managed: Quantitative goals for people management.
– Optimizing: Continuous focus on improving individual
competence and work-force motivation.
UCSC - 2007

Project Management

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Project Management

Загружено:

Авторское право:

Доступные форматы

IT3203 – Managing Software Projects

Managing Software Projects

 State the requirement of managerial control of the

 Describe the main phases of software project

 Describe project planning and project scheduling

10.1. Need for the proper management of software projects

10.2. Management activities

10.1. Need for the Proper Management of

Software Project Management

• Concerned with activities involved in ensuring that

• Project management is needed because software

Software Management Distinctions

• The product is uniquely flexible.

• Software engineering is not recognized as an

• The software development process is not

• Many software projects are 'one-off' projects.

10.2. Management Activities

• Project planning and scheduling.

• Project monitoring and reviews.

• Personnel selection and evaluation.

• Report writing and presentations.

• Managers have to work within these constraints

• Continuous activity from initial concept through to

• Plans must be regularly revised as new information

• Various different types of plan may be developed to

Types of Project Plan

– Validation plan : Describes the approach, resources and

– Configuration management plan : Describes the configuration

– Maintenance plan : predicts the maintenance requirements of

– Staff development plan : describes how the skill and experience

Project Planning Process

The Project Plan

• The project plan sets out:

Project Plan Structure

• Milestones are the end-point of a process activity.

• Deliverables are project results delivered to

• Deliverable are usually milestones but milestones need

Milestones in the RE Process

Fundamental Estimation Questions

• How much effort is required to complete an

Project estimation and scheduling are interleaved

Software Cost Components

• Travel and training costs.

• Effort costs (the dominant factor in most projects)

– Effort costs must take overheads into account

Costing and Pricing

• There is not a simple relationship between the

• Broader organisational, economic, political and

• Organize tasks concurrently to make optimal

• Minimize task dependencies to avoid delays

• Dependent on project managers intuition and

The Project Scheduling Process

Identify Identify activity Estimate resources Allocate people Create project

Software Activity charts

• Productivity is not proportional to the number of people

• Adding people to a late project makes it later because of

• The unexpected always happens. Always allow

• A risk is a probability that some adverse circumstance

The Risk Management Process

The Risk Management Process

Risks and Risk Types

Risk Probability Effects

Risk Probability Effects

State the requirement of managerial control of the

Describe the main phases of software project

Describe project planning and project scheduling