PROJECT MANAGEMENT
Ioan Despi
1
Reading:
1. Project Management Institute - “Guide to the Project Management
Body of Knowledge”, 1996 http://www.pmi.org
2. Burrill, Claude W., and Ellsworth, Leon W. - Modern Project
Management, Burrill and Ellsworth Associates, 1980.
3. De Marco, T.- Controlling Software Projects: Management,
Measurement and Estimates, Yourdon Press, 1982.
4. Londeix, Bernard - Cost Estimation for Software Development,
Addison-Wesley, 1987.
5. Charette, Robert N.- Software Engineering Risk Anaysis and
Management, McGraw-Hill, 1989.
6. Cotterell, M. and Hughes, B. - Software Project Management,
Thompson Publishing, 1995
2
World Wide Web Resources:
1. Software Program Managers’ Network
http://www.spmn.com
2. Software Productivity Research
http://www.spr.com
3. Software Engineering Institute
http://www.sei.cmu.edu
4. Quantitative Software Measurement
http://www.qsm.com
5. Atlantic Systems Guild
http://www.atlsysguild.com/
6. PostMortem Process
http://www.wildfire.com/research/postmortems.html
3
What is a Project?
A project is a temporary endeavor undertaken to create a
unique product or service.
Distinguish between projects and operations:
•
operations are ongoing and repetitive
•
projects are temporary and unique
What is Project Management?
Project management is the application of knowledge, skills,
tools, and techniques to project activities in order to meet or
exceed stakeholder needs and expectations from a project
4
The Context for Project Management
A.The Project Management Environment
The Project Life Cycle
Project Stakeholders
Organizational Influences
Key General Management Skills
B. The Project Management Process
C. Knowledge areas for project management
5
A1. The Project Life Cycle
The project life cycle serves to define the beginning and the
end of a project
The life cycle is normally divided into a number of phases
(initial phase, intermediate phases, final phase)
Each project phase is marked by completion of one or more
deliverables (a feasibility study, a detail design, or a working
prototype)
6
A2. Project stakeholders
1. Project manager =
the individual responsible for managing the project.
2. Customer =
the individual or organization who will use the project
product
3. Performing organization =
the enterprise whose employees are most directly
involved in doing the work of the project.
4. Sponsor =
the individual or group within the performing organization
who provides the financial resources, in cash or in kind,
for the project.
7
A3. Organizational Influences
Conduct of Projects is influenced by:
1. Organizational Structure
range from fully functional to totally project oriented
2. Organizational Culture
Conservative or Aggressive
Participative or Authoritarian
3. Organizational Systems
Suitability of support functions such as finance, human
resource management or strategic planning for project
work
8
A4. Key General Management Skills
General management encompasses
planning, organizing, staffing, executing, and controlling
the operations of an ongoing enterprise.
Also includes supporting disciplines:
computer programming, law, statistics and probability
theory, logistics, and personnel.
General management skills:
Leading, Communicating, Negotiating, Problem Solving
Influencing the Organization
9
B. Project Management Process
The purpose of the project management process is to identify,
establish, and coordinate and monitor activities, tasks, and
resources necessary for a project to produce a product and/or
service meeting the agreed requirements.
Outcomes of Project Management
As a result of successful implementation of the process:
1. the scope of the work for the project will be defined;
2. the feasibility of achieving the goals of the project with
available resources and constraints will be evaluated;
10
3. the tasks and resources necessary to complete the work
will be sized and estimated;
4. interfaces between elements in the project, and with other
projects and organizational units, will be identified and
monitored;
5. plans for execution of the project will be developed and
implemented;
6. progress of the project will be monitored and reported;
7. actions to correct deviations from the plan and to prevent
recurrence of problems identified in the project, will be taken
when project targets are not achieved.
11
C. Knowledge Areas for Project Management
• Project Integration Management
• Project Scope management
• Project Time Management
• Project Cost Management
• Project Quality Management
• Project Human Resource Management
• Project Communications Management
• Project Risk Management
• Project Procurement Management
12
The Software Life Cycle
The period of time between the initial concept and the
retirement of a software product or software based system
Different models of the software life cycle can be developed
and used as the basis for managing software development
All of the models involve one or other form of phased
development
Life Cycle Models: Waterfall Model, “V” Model
Rapid Prototyping Model,
Spiral Life Cycle Model
Incremental Development Model
13
The Waterfall Model
•First formulated by Royce in the early 70’s
•Further developed by Boehm (Software Engineering
Economics)
•Based upon a series of discrete phases, with clear phase
termination events and limited feedback between phases
•Dependent on a clear understanding of the initial
requirements for the system
Concept
Analysis
Design
Construction
Testing
Operation
14
Typical Phases
1. Concept
The initial requirements for the system are defined
and the feasibility of development is demonstrated
2. Analysis
The requirements are analysed to identify the
parameters of the system
3. Design
A detailed specification of the design of individual
modules is developed
4. Construction
The design is implemented in executable code
5. Testing
The built modules are integrated and tested
6. Operation
The software system becomes operational
15
The “V” Model
•Developed in the UK
•An extension of the Waterfall Model making the relationship
between analysis and synthesis clear
•Verification and validation oncepts are built in to the model
V Process Model
Feasibility Study
User Acceptance
Systems Analysis
System Testing
ProgramDesign
Program Testing
Construction
16
Prototyping
•Basic phased models require a degree of certainty about
the initial requirements for the product to be developed
•In software this certainty is rarely present: Prototyping is
one means for addressing uncertainty
A prototype is a working model of one or more aspects of a
projected system
It is constructed and tested quickly and inexpensively in order to test our
assumptions
Different classes of prototypes can be distinguished:
Throw-away prototypes
Evolutionary prototypes
Different aspects of the system can be prototyped
Human Computer Interface
System Functionality
Iteration is the essential characteristic of prototyping approaches
17
Evolutionary Prototyping
• The prototype is designed to form the basis for development
of the final system
NOT a Throw-away
• Prototyping is performed in a defined time constraint
Limit on the number of prototype reviews
• Prototyping replaces the conventional phases of analysis
and design
The final prototype defines the agreed requirements
and design
• A new “tuning” phase follows the completion of prototyping
NEVER deliver the prototype
18
Evolutionary Rapid Prototyping
Design derivation
Prototype iteration
Rapid
Analysis
User
Approval
Functions
Project
Plan
Database
Tuning
Creation
Menus
Operation & Maintenance
19
Spiral Model
• Developed by Barry Boehm
• Designed to address the risks associated with developing
large systems
• Makes extensive use of prototyping
• Development proceeds in a spiral manner
• Risk assessment is a formal phase in each stage of the
spiral
20
1. Business Requirements
5. System Requirements
2. Conceptual Design
6. Logical Design
3. Proof of Concept
7. First Build
4. Risk Analysis
8. Evaluation
13. Unit Requirements
9. Subsystem Requirements
14. Final Design
10. Physical Design
15. Final Build
11. Second Build
16. Test
12. Evaluation
17. Deploy
18. Operation & Production
Support
21
Incremental Development
• Identify separate elements of functionality in the initial
requirements
• Prioritise and develop a plan for progressive development
• Different life cycle models may be used for different
increments
•Benefits of Incremental Development
Feedback from operation of early delivery can help to refine the
requirements for later stages
Possibility of major changes in requirements is lower
Users get benefits from early implementation
Return on investment comes earlier, improving cash flow
Smaller projects are easier to manage
“Gold plating” is reduced
Developers get greater satisfaction from visible results
22
Summary
•Software development follows a life cycle from initial
concept to operation and eventual retirement
•The life cycle can be broken down into a series of phases
•Different models can be employed to define different types
of life cycle
•The choice of life cycle model will depend on:
the nature of the system
the risks for the organization
the current understanding of the requirements
23
Software Lifecycle PROCESSES
Projects are composed of processes = A set of interrelated
activities, which transform inputs into outputs( ISO 12207)
ISO 12207: Software Life Cycle Processes
•Establishes a common framework for software life cycle
processes that can be referenced by the software industry
•Lists processes that can be applied
• Project processes are performed by people and generally
fall into one of two major categories:
1.Project management processes are concerned with
describing and organizing the work of the project
2. Product-oriented processes are concerned with
specifying and creating the project product
24
Software Life Cycle Processes
PRIMARY PROCESSES
SUPPORTING PROCESSES
Aquisition
Documentation
Supply
Configuration Management
Operation
Development
Maintenance
Quality Assurance
Verification
Validation
Joint Review
Audit
Problem Resolution
Organisational Processes
Management
Improvement Infrastructure
Training
25
How Processes are Defined
The Structure of a Process:
A Process is made up of Activities
An Activity is made up of Tasks
Process
Activity
task
...
task
Activity
...
task
...
task
26
The Nature of a Task
An Action with Inputs and Outputs
Inputs
a requirement (shall)
a recommendation (should)
a permissible action (may)
TASK
Outputs
a self-declaration (will)
no mandatory (must)
WHAT to do NOT HOW to do
27
Success Factors
The root causes of software success and failure included
1. technicalfactors,
2. social and cultural factors, and
3. management factors.
The study found that there is an almost infinite number of ways to
fail in building software applications and only a few ways to succe
The attributes most strongly associated with successful software
projects included the usage of
1. automated software cost estimating tools,
2. automated software project management tools,
3. effective quality control, and
4. effective tracking of software development milestone
28
Shewhart cycle: (basics of Process Improvement)
Do
Plan
Check
Act
29
Applying the Process Model
Start Solicit
Start
inputs
Select
processes,
Identify project environment & characteristics
activities
and tasks
Solicit Inputs
Select Processes, Activities & Tasks
Document Decisions & Rationale
End
30
Review
A project is a temporary endeavor undertaken to create a
unique product or service.
Projects follow a life cycle from concept to completion
Different models have been developed for the software life
cycle (Waterfall / V-Process, Prototyping, Spiral, Incremental)
A defined set of processes comprise and support the software
life cycle (Primary, Supporting and Organizational)
31
Project Scope Management
Project Scope Management includes the processes required
to ensure that the project includes all the work required, and
only the work required, to complete the project successfully.
It is primarily concerned with defining and controlling what is
or is not included in the project.
32
Managing Project Scope
Initiation
Scope Planning
Scope Definition
Scope Verification
Scope Change Control
33
Initiation
Product Description
Strategic Plan
Selection Criteria
Historical Information
The project charter is a document that
formally recognizes the existence of a
project.
Initiation
Initiation is the process of formally
recognizing that a new project exists or
that an existing project should continue
into its next phase
Project Charter
Project Manager
Constraints
Assumptions
34
Scope Planning
Product description
Project charter
Constraints
Assumptions
The scope statement include:
Project justification,
Project product,
Project deliverables,
Project objectives:
cost,
schedule,
quality measures.
Scope
Planning
Scope planning is the process of developing
a written scope statement as the basis for
future project decisions including, in
particular, the criteria used to determine if the
project or phase has been completed
successfully.
Scope statement
Supporting detail
Scope management
plan
35
Scope statement
Constraints
Assumptions
Other planning outputs
Historical information
Scope Definition
Scope
Definition
Scope definition involves subdividing the
major project deliverables (as identified
in the scope statement) into smaller,
more manageable components
Work Breakdown
Structure
36
Work Breakdown Structure
• Is a deliverable-oriented grouping of project elements that
organizes and defines the total scope of the project:
work not in the WBS is outside the scope of the project.
•As with the scope statement, the WBS is often used to
develop or confirm a common understanding of project scope.
•Each descending level represents an increasingly detailed
description of the project elements.
37
Model Work Breakdown Structure
Project
Phase 1
Activity 1.1
Activity 1.2
Task2.1.1
Phase 2
Activity 2.1
Task2.1.2
Phase 3
Activity 2.2
Activity 3.1
Activity 3.2
Task2.1.3
38
Scope Verification
Work results
Product documentation
Scope
Verification
Scope verification is the process of
formalizing acceptance of the project
scope by the stakeholders (sponsor,
client, customer, etc.).
Formal acceptance
39
Scope Change Control
Work breakdown structure
Performance reports
Change requests
Scope management plan
Scope
Change Control
Scope change control is concerned with
(a) influencing the factors which create scope
changes to ensure that changes are beneficial,
(b) determining that a scope change has
occurred, and
(c) managing the actual changes when and if
they occur.
Scope changes
Corrective action
Lessons learned
40
Summary
•
Scope management is concerned with defining and
controlling the scope of the project
•
The project scope includes the product description,
together with any known constraints or assumptions
•
Project Scope is defined in the Project Charter
•
The project scope is the basis for development of the
Work Breakdown Structure for the project
•
Project scope must be verified and controlled
throughout the life of the project
41
Developing a Work Breakdown
Structure
Review
The project scope includes the product description, together
with any known constraints or assumptions
The project scope is the basis for development of the Work
Breakdown Structure (WBS) for the project
A work breakdown structure is a deliverable-oriented grouping
of project elements that organizes and defines the total scope
of the project:
work not in the WBS is outside the scope of the project.
42
The WBS in the Project
•The WBS is central to the development of a realistic schedule
for the project
•The WBS consists of an ordered set of activities and tasks,
based upon a hierarchical decomposition of the phases of
the Project Life Cycle
•The starting point for the WBS is thus the chosen life cycle
model
•A work breakdown structure from a previous project can
often be used as a template for a new project but need to
be tailored for use in an individual project
43
Functional Decomposition
Decomposition involves subdividing the major project
deliverables into smaller, more manageable components until
the deliverables are defined in sufficient detail to support future
project activities (planning, executing, controlling, and closing).
Decomposition
•Identify the major elements of the project.
•Decide if adequate cost and duration estimates can be
developed at this level of detail for each element.
•Identify constituent elements of the deliverable.
•Verify the correctness of the decomposition
44
Unit Tasks
Interfaces with
other tasks
Quantifiable
Inputs
Finite known
duration task
Quantifiable
Outputs
Needs
Task
precedences
45
Principles for Decomposition
Basic Purpose
Clear Deliverables
Feasible Tasks
Minimum Interface
Related Skills
Levels of Control
Relation to other Management Systems
Traditional Tasks
Employee Satisfaction
46
Proofing the Breakdown
For each of the lowest level elements:
inputs are among the inputs for the parent element;
OR
inputs are outputs of a previous element at the same level
outputs are among the outputs of the parent element
OR
outputs are inputs of a subsequent element at the
same level
47
Ordering Tasks
T
T1
WBS
T2
Input
T3
T4
T5
Sequential Ordering
Output
Element
Task T
A
B
SubTask T1 A
W
SubTask T2 W
X
Subtask T3
X
Y
SubTask T4 W
Z
SubTask T5 Y, Z
B
B
A
T1
T2
T3
T4
T5
Unsequential Ordering
T3
T2
B
A
T1
T4
T5
48
Representing an Activity Network
1. Precedence diagramming method
Nodes represent the Activities
Connections show the dependencies
A
B
C
D
E
F
49
2. Arrow diagramming method
Arrows represent the activities
Connections at the nodes show dependencies
B
A
C
Start
D
F
Finish
E
3. Conditional diagramming methods
Allow for non-sequential activities (such as loops)
50
The Activity Network Diagram
•The Activity Network Diagram is the end-product of the
task decomposition process
It should be accompanied by narrative to
explain any dependencies
•It shows the relationships between the tasks that have to
be performed, but says nothing about how long it will take
to perform them
To go further we need to be able to estimate
the effort, cost and elapsed time
for each task or activity
51
Summary
A Work Breakdown Structure contains the tasks and activities
needed to perform the project
The WBS is based upon the life cycle model selected for the
project
Standard WBS templates are commonly used for tailoring to
develop a suitable list of activities for individual projects
The lowest level components of the WBS comprise activities or
tasks with clearly defined inputs and outputs
From examining the inputs and outputs a sequence or ordering
of tasks can be determined
This sequence can be represented in an Activity Network
Diagram
52