It8075 SPM Local Author Book

SUBJECT CODE : MG6088
Strictly as per Revised Syllabus of

Anna University
Choice Based Credit System (CBCS)
Semester - VIII (CSE / IT) Elective - V
Semester - VIII (ECE) Elective - VI
Software Project
Management
Vandana Gupta
M.Tech. (CSE), B.Tech. (CSE),
Assistant Professor (CSE Department)
ABES Engineering College.,
Ghaziabad.
® ®
TECHNICAL
PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge
(i)
Software Project Management
Subject Code : MG6088
Semester - VIII (Computer Science & Engineering / Information Technology) Elective - V

Semester - VIII (Electronics & Communication Engineering) Elective - VI
First Edition : January 2017

Second Revised Edition : January 2018
Third Revised Edition : January 2019
Reprint : January 2020
ã Copyright with Author

All publishing rights (printed and ebook version) reserved with Technical Publications. No part of this book
should be reproduced in any form, Electronic, Mechanical, Photocopy or any information storage and
retrieval system without prior permission in writing, from Technical Publications, Pune.
Published by :
® ®
TECHNICAL Amit Residency, Office No.1, 412, Shaniwar Peth, Pune - 411030, M.S. INDIA
P h . : + 9 1 - 0 2 0 - 2 4 4 9 5 4 9 6 / 9 7 , Te l e f a x : + 9 1 - 0 2 0 - 2 4 4 9 5 4 9 7
PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge
Email : sales@technicalpublications.org Website : www.technicalpublications.org
Printer :
Yogiraj Printers & Binders
Sr.No. 10/1A,
Ghule Industrial Estate, Nanded Village Road,
Tal. - Haveli, Dist. - Pune - 411041.
Price : ` 275/-
ISBN 978-93-332-1421-6
9 789333 214216 AU 17
9789333214216 [3] (ii)

Table of Contents
Chapter - 1 Project Evaluation and Project Planning (1 - 1) to (1 - 70)
1.1 Software Project Management......................................................................... 1 - 2
1.1.1 Project ............................................................................................................... 1 - 2
1.1.1.1 Project Characteristics ......................................................................................... 1 - 2
1.1.1.2 Project Life Cycle ................................................................................................. 1 - 2
1.1.1.3 Project Management ........................................................................................... 1 - 3
1.1.2 Software Project ................................................................................................ 1 - 4
1.1.2.1 Objectives Versus Products ................................................................................. 1 - 4
1.1.2.2 Software Projects Versus Other Types of Projects .............................................. 1 - 4
1.1.2.3 Classifications of Software Projects..................................................................... 1 - 5
1.1.2.4 Critical Factors for Project Success and Failure ................................................... 1 - 7
1.1.2.5 Define Project Goal and Objectives ..................................................................... 1 - 7
1.1.2.6 Problems Related to Software Project ................................................................ 1 - 9
1.1.3 Software Project Management ....................................................................... 1 - 12
1.1.3.1 Importance of Software Project Management ................................................. 1 - 13
1.1.3.2 Need of Software Project Management............................................................ 1 - 14
1.1.3.3 The Purpose of Software project Management and Setting Objectives ........... 1 - 14
1.1.3.4 SMART Goal of Project Management ................................................................ 1 - 16
1.1.3.5 Skills Necessary for Software Project Management.......................................... 1 - 16
1.1.3.6 Software Project Management Activities .......................................................... 1 - 17
1.1.3.7 Management Functions and Activities .............................................................. 1 - 19
1.1.3.8 The Management Spectrum .............................................................................. 1 - 23
1.1.4 Software Project Manager............................................................................... 1 - 30
1.1.4.1 Responsibilities of a Software Project Manager................................................ 1 - 30
1.2 Project Portfolio Management ....................................................................... 1 - 31
1.2.1 Introduction ..................................................................................................... 1 - 31
1.2.2 Objectives of Project Portfolio Management .................................................. 1 - 31
1.2.3 Benefits of Project Portfolio Management ..................................................... 1 - 32
1.2.4 Portfolio Management Tools........................................................................... 1 - 32
1.2.5 Techniques used to Measure PPM .................................................................. 1 - 33
1.2.6 Why Project Managers to Focus on PPM ? ..................................................... 1 - 33
1.2.7 The Five Question Model ................................................................................ 1 - 33
1.3 Project Evaluation ........................................................................................... 1 - 34
1.3.1 Strategic Assessment ....................................................................................... 1 - 35
1.3.1.1 SA - Programme Management .......................................................................... 1 - 35
(v)
1.3.1.2 SA - Portfolio Management ............................................................................... 1 - 37
1.3.2 Technical Assessment ...................................................................................... 1 - 38
1.3.3 Economic Assessment ..................................................................................... 1 - 38
1.4 Cost Benefit Evaluation Technology ............................................................... 1 - 38
1.4.1 Cost - Benefit Analysis ..................................................................................... 1 - 38
1.4.2 Cost Estimation ................................................................................................ 1 - 39
1.4.2.1 Category of Cost ................................................................................................ 1 - 39
1.4.2.2 Benefit Estimation ............................................................................................. 1 - 40
1.4.2.3 Category of Benefits .......................................................................................... 1 - 40
1.4.3 Cash Flow Forecasting ..................................................................................... 1 - 40
1.4.3.1 Typical Product Life Cycle Cash Flow ................................................................. 1 - 41
1.4.4 Cost Benefit Evaluation Techniques ................................................................ 1 - 41
1.4.5 Discounted Cash Flow Techniques .................................................................. 1 - 46
1.5 Risk Evaluation ................................................................................................ 1 - 48
1.5.1 Risk Identification and Ranking ....................................................................... 1 - 48
1.5.2 Risk and Net Present Value ............................................................................. 1 - 48
1.5.3 Cost Benefit Analysis ....................................................................................... 1 - 49
1.5.4 Risk Profile Analysis ......................................................................................... 1 - 49
1.5.5 Using Decision Trees........................................................................................ 1 - 51
1.6 Project Planning .............................................................................................. 1 - 51
1.6.1 Types of Project Plan ....................................................................................... 1 - 51
1.6.2 Project Planning Process ................................................................................. 1 - 52
1.6.3 Project Plan Structure...................................................................................... 1 - 52
1.6.4 Project Planning Techniques : Work Breakdown Structure (WBS).................. 1 - 53
1.6.5 Stepwise Project Planning ............................................................................... 1 - 54
1.7 Healthy and Safety Issues in Project Management ........................................ 1 - 60
1.8 Stress ............................................................................................................... 1 - 61
1.8.1 What is Stress ? ............................................................................................... 1 - 62
1.8.2 Signs of Stress .................................................................................................. 1 - 62
1.8.3 A Model of Stress at Work............................................................................... 1 - 63
1.8.4 Causes of Stress at Work ................................................................................. 1 - 64
1.8.5 Involvement in Stress Management................................................................ 1 - 64
1.8.6 The Stress Management .................................................................................. 1 - 66
1.9 University Questions with Answers ................................................................ 1 - 68
Chapter - 2 Project Life Cycle and Effort Estimation (2 - 1) to (2 - 50)

2.1 Software Process .............................................................................................. 2 - 2
2.1.1 Software Process Models .................................................................................. 2 - 2
2.1.2 Agile SDLC’s (Agile Method) ............................................................................ 2 - 11
(vi)
2.1.2.1 Some Agile Methods ......................................................................................... 2 - 12
2.2 Choice of Process Models ............................................................................... 2 - 14
2.2.1 Selecting a Life Cycle Model - Project Characteristic
Category Matrix Requirements ....................................................................... 2 - 14
Category Matrix Project Team......................................................................... 2 - 15
Category Matrix User Community ................................................................... 2 - 15
Category Matrix Project Type and Risk ........................................................... 2 - 15
2.3 Basic of Software Estimation .......................................................................... 2 - 16
2.4 Software Cost Estimation ............................................................................... 2 - 16
2.4.1 Software Size Metrics ...................................................................................... 2 - 17
2.4.1.1 LOC (Lines of Code) ........................................................................................... 2 - 17
2.4.1.2 Function Point Metric ........................................................................................ 2 - 17
2.4.2 Software Cost Estimation Techniques ............................................................. 2 - 18
2.4.2.1 Empirical Size Estimation Techniques ............................................................... 2 - 19
2.4.2.2 Heuristic Estimation Techniques ....................................................................... 2 - 19
2.4.2.3 Analytical Technique ......................................................................................... 2 - 24
2.4.3 Staffing Level Estimation ................................................................................. 2 - 24
2.4.3.1 Rayleigh Curve ................................................................................................... 2 - 25
2.4.3.2 Putnam’s Work .................................................................................................. 2 - 25
2.4.3.3 Jensen Model .................................................................................................... 2 - 27
2.5 Effort Estimation ............................................................................................. 2 - 28
2.5.1 Macro Versus Micro Estimating ...................................................................... 2 - 28
2.5.2 Estimating Projects : Preferred Approach ....................................................... 2 - 28
2.5.3 Estimating Guidelines for Times, Costs, and Resources .................................. 2 - 29
2.5.4 Refining Estimates ........................................................................................... 2 - 29
2.5.5 Methods for Estimating Project Times and Costs ........................................... 2 - 29
2.5.6 Duration vs. Effort vs. Productive Time ........................................................... 2 - 31
2.5.7 Basic Steps in Software Estimation ................................................................. 2 - 32
2.5.7.1 Basic Algorithmic Form...................................................................................... 2 - 32
2.5.7.2 SLOC as an Estimation Tool ............................................................................... 2 - 32
2.5.8 Function Count Systems View : Functionality Types ....................................... 2 - 32
2.5.8.1 Function Points.................................................................................................. 2 - 33
2.5.8.2 Functionality Types ........................................................................................... 2 - 33
2.5.8.3 Processing Complexity Adjustment ................................................................... 2 - 33
2.5.8.4 Function Point Calculation ................................................................................ 2 - 34
2.5.8.5 Detailed Function Point Counting Rules ............................................................ 2 - 34
(vii)
2.5.8.6 Counting EQs - “Medium Cooked” Data .............................................................. 2 - 41
2.5.8.7 Are Function Points a “Silver Bullet”? .................................................................. 2 - 42
2.5.8.8 Software Estimating Rules of Thumb................................................................... 2 - 42
2.6 COCOMO II ...................................................................................................... 2 - 44
2.6.1 COCOMO II models .......................................................................................... 2 - 44
2.6.2 Cost Drivers ..................................................................................................... 2 - 45
2.6.3 Calibration ....................................................................................................... 2 - 46
2.7 Systems Development Life Cycle .................................................................... 2 - 46
Chapter - 3 Activity Planning and Risk Management (3 - 1) to (3 - 66)

3.1 Introduction ...................................................................................................... 3 - 2
3.1.1 Activity Planning ................................................................................................. 3 - 2
3.1.2 Objectives of Activity Planning ........................................................................... 3 - 2
3.1.3 Different Levels of Plans ..................................................................................... 3 - 3
3.2 Project Schedule ............................................................................................... 3 - 3
3.2.1 Building the Project Schedule ............................................................................ 3 - 4
3.3 Various Approaches Towards Identifying Activity ............................................ 3 - 5
3.3.1 Activity-Based Approach .................................................................................... 3 - 5
3.3.2 Product-Based Approach ................................................................................... 3 - 6
3.3.3 Hybrid Approach ................................................................................................ 3 - 6
3.4 Planning, Sequencing and Scheduling the Activities ........................................ 3 - 8
3.4.1 Project Scheduling.............................................................................................. 3 - 9
3.4.2 Basic Principles for Project Scheduling ............................................................ 3 - 10
3.4.3 Relationship between People and Effort......................................................... 3 - 11
3.4.4 Effort Applied vs Delivery Time ....................................................................... 3 - 11
3.4.5 40-20-40 Distribution of Effort ........................................................................ 3 - 11
3.5 Scheduling Techniques ................................................................................... 3 - 12
3.5.1 Simple Sequencing........................................................................................... 3 - 12
3.5.2 Critical Path Method (CPM) ............................................................................. 3 - 12
3.5.3 Significance of Critical Path ............................................................................. 3 - 15
3.6 Network Planning Models .............................................................................. 3 - 15
3.6.1 Constructing Precedence Networks ................................................................ 3 - 15
3.6.2 Network Planning Techniques or Models ....................................................... 3 - 17
3.6.3 Network Diagram ............................................................................................ 3 - 17
3.6.3.1 Activity on Arrow Networks................................................................................. 3 - 17
3.6.3.2 Activity-On-Node (AON) ...................................................................................... 3 - 21
3.6.4 Example by Using Probabilistic Time Estimates (PERT) ................................... 3 - 25
(viii)
3.6.5 Reducing Project Completion Time ................................................................. 3 - 31
3.6.6 The Critical Chain Approach ............................................................................ 3 - 33
3.7 Risk and Risk Management Process................................................................ 3 - 33
3.7.1 Risk .................................................................................................................. 3 - 33
3.7.2 Risk Strategies.................................................................................................. 3 - 34
3.7.3 Risk Factors Fall into Two Categories .............................................................. 3 - 34
3.7.3.1 The Top Ten Software Risk Items......................................................................... 3 - 36
3.7.3.2 Risk Estimation..................................................................................................... 3 - 37
3.7.3.3 Risk Evaluation ..................................................................................................... 3 - 38
3.7.3.4 Risk Reduction Strategies .................................................................................... 3 - 38
3.7.3.5 Risk Handling ....................................................................................................... 3 - 39
3.7.4 Risk Management ............................................................................................ 3 - 39
3.7.4.1 The Risk Management Process ............................................................................ 3 - 40
3.7.5 RMMM (Risk Mitigation, Monitoring and Management) ............................... 3 - 47
3.7.6 Risk Information Sheets................................................................................... 3 - 48
3.7.7 Safety and Hazards .......................................................................................... 3 - 48
3.7.8 Issues Related to Risk Management................................................................ 3 - 49
3.7.9 List of Risks Related to Software Projects ....................................................... 3 - 50
3.8 Monte Carlo Simulation .................................................................................. 3 - 53
3.8.1 Monte Carlo Analysis with Example ................................................................ 3 - 54
3.8.2 Benefits of Using Monte Carlo Analysis........................................................... 3 - 56
3.8.3 Monte Carlo Analysis : Steps ........................................................................... 3 - 56
3.9 Resource Allocation ........................................................................................ 3 - 59
3.9.1 Who Allocates Resources ?.............................................................................. 3 - 59
3.9.2 Result of Resource Allocation .......................................................................... 3 - 59
3.9.3 Resource Categories ........................................................................................ 3 - 59
3.9.4 Resource Organisation .................................................................................... 3 - 60
3.9.5 Resource Requirement Identification – 1........................................................ 3 - 60
3.9.6 Resource Requirement Identification – 2........................................................ 3 - 60
3.9.7 Resource Scheduling........................................................................................ 3 - 60
3.9.7.1 Resource Scheduling Issues ............................................................................... 3 - 61
3.9.8 Resource Histograms ....................................................................................... 3 - 61
3.9.9 External Dependencies .................................................................................... 3 - 61
3.9.10 Parallel, Sequential Tasks ................................................................................ 3 - 61
3.9.10.1 Prioritisation Techniques ................................................................................... 3 - 61
3.9.11 Critical Paths ................................................................................................... 3 - 62
3.9.12 Cost of Resources ........................................................................................... 3 - 62
3.9.13 Resource Allocation Issues ............................................................................. 3 - 62
3.9.14 Use of Gantt Chart in Resource Allocation ..................................................... 3 - 63
(ix)
3.10 Cost Scheduling ............................................................................................... 3 - 63
3.10.1 Scheduling in Practice ..................................................................................... 3 - 64
3.11 A Summary or Hammock Activity .................................................................. 3 - 64
3.12 University Questions with Answers ............................................................... 3 - 65
Chapter - 4 Project Management and Control (4 - 1) to (4 - 46)

4.1 Project Tracking and Monitoring ...................................................................... 4 - 2
4.1.1 What Can Go Wrong in Product ? ..................................................................... 4 - 2
4.1.2 Planning, Tracking and Monitoring ................................................................... 4 - 2
4.1.3 Creating Framework for (Monitoring and Control) ........................................... 4 - 3
4.1.3.1 Creating Framework ............................................................................................ 4 - 3
4.1.3.2 Responsibility ...................................................................................................... 4 - 4
4.1.4 Tracking the Performance ................................................................................. 4 - 5
4.1.4.1 Check Point ............................................................................................................ 4 - 5
4.1.4.2 Collecting Data ...................................................................................................... 4 - 6
4.1.5. Prioritizing Monitoring (Level of Monitoring) .................................................... 4 - 8
4.1.6 Bringing the Project back to Target ................................................................... 4 - 9
4.1.6.1 Shorten the Critical Activities .............................................................................. 4 - 9
4.1.6.2 Reorder the Activities ........................................................................................ 4 - 10
4.1.7 Acceptance ...................................................................................................... 4 - 10
4.2 Monitoring the Progress ................................................................................. 4 - 10
4.2.1 Visualizing Progress ......................................................................................... 4 - 11
4.3 Cost Monitoring .............................................................................................. 4 - 14
4.4 Earned Value Analysis or Earned Value Management
(Cost Monitoring Technique) .......................................................................... 4 - 15
4.5 Change Control ............................................................................................... 4 - 20
4.5.1 Some Basics ..................................................................................................... 4 - 20
4.5.2 Change Control Process ................................................................................... 4 - 20
4.6 Software Configuration Management ............................................................ 4 - 22
4.6.1 What is SCM not ? ........................................................................................... 4 - 22
4.6.2 SCM Terminology ............................................................................................ 4 - 23
4.6.2.1 Configuration Item (CI) ........................................................................................ 4 - 23
4.6.2.2 Version, Variant and Revision ............................................................................. 4 - 23
4.6.2.3 Configuration ...................................................................................................... 4 - 24
4.6.2.4 Baseline ............................................................................................................... 4 - 24
4.6.2.5 Workspace ......................................................................................................... 4 - 25
4.6.3 Version Control Models (1/3) .......................................................................... 4 - 25
4.6.4 SCM Processes ................................................................................................. 4 - 28
4.6.4.1 Change Control Process ...................................................................................... 4 - 28
(x)
4.6.4.2 Status Accounting ............................................................................................... 4 - 28
4.6.4.3 Configuration Audit............................................................................................. 4 - 28
4.6.4.4 Release Management .......................................................................................... 4 - 29
4.6.4.5 Make a CM Plan ................................................................................................... 4 - 29
4.6.5 CM Tools ........................................................................................................... 4 - 29
4.7 Managing Contract and Contract Management ............................................. 4 - 30
4.7.1 Introduction ..................................................................................................... 4 - 30
4.7.2 What is a Software Contract ? ......................................................................... 4 - 30
4.7.2.1 Software Contract Modes ................................................................................. 4 - 31
4.7.3 Types of Software Contracts ........................................................................... 4 - 31
4.7.4 Contact Placement .......................................................................................... 4 - 33
4.7.4.1 Requirements Analysis ...................................................................................... 4 - 33
4.7.4.2 Evaluation Plan .................................................................................................. 4 - 34
4.7.4.3 Invitation to Tender........................................................................................... 4 - 34
4.7.4.4 Evaluation of Proposals ..................................................................................... 4 - 34
4.7.5 Typical Terms of a Contract .............................................................................. 4 - 34
4.7.6 Contract Management .................................................................................... 4 - 38
4.7.6.1 The Fundamentals of Contract Management ................................................... 4 - 38
4.7.6.2 Elements of Successful Contract Management ................................................. 4 - 38
4.7.6.3 Contract Management Process ......................................................................... 4 - 39
4.7.6.4 Activities that Make up Good Contract Management ...................................... 4 - 39
4.7.6.5 Contract Management Software ....................................................................... 4 - 40
4.7.7 Difference between Project Management and Control Management ........... 4 - 40
4.8 Project Monitoring and Controlling Process in Detail .................................... 4 - 40
4.8.1 Techniques for Monitoring and Control .......................................................... 4 - 43
Chapter - 5 Staffing in Software Projects (5 - 1) to (5 - 74)

5.1 Managing People .............................................................................................. 5 - 2
5.1.1 People in the Process ........................................................................................ 5 - 2
5.1.2 People Management Factors............................................................................. 5 - 2
5.1.3 People Management Task ................................................................................. 5 - 2
5.1.3.1 Selecting Staff ...................................................................................................... 5 - 2
5.1.3.2 Motivating People ............................................................................................... 5 - 4
5.1.3.3 Managing Groups ................................................................................................ 5 - 7
5.1.3.4 The People Capability Maturity Model.............................................................. 5 - 13
5.2 Organisation Behaviour .................................................................................. 5 - 13
5.2.1 The Study of Organisational Behaviour Involves ............................................. 5 - 14
5.2.2 Interrelated Dimensions Influencing Behaviour.............................................. 5 - 14
(xi)
5.2.3 Management Theory ....................................................................................... 5 - 14
5.2.4 Division of Labour ............................................................................................ 5 - 14
5.2.4.1 Functions ........................................................................................................... 5 - 15
5.2.4.2 Advantages and Disadvantages ......................................................................... 5 - 15
5.2.4.3 Decisions on Division of Work Should take Account of ..................................... 5 - 15
5.2.5 Mintzberg’s Five Basic Elements of Structure ................................................. 5 - 16
5.2.6 Evolution of Organizational Behaviour ............................................................ 5 - 16
5.2.6.1 Classical Approach ............................................................................................. 5 - 16
5.2.6.2 Human Relations Approach............................................................................... 5 - 17
5.2.6.3 Neo-Human Relations Approach ....................................................................... 5 - 18
5.3 Best Methods of Staff Selection ..................................................................... 5 - 20
5.3.1 Factors that may Influence Selection Procedure............................................. 5 - 20
5.4 Motivation ........................................................................................................ 5 - 22
5.4.1 Need of Motivation in Software Project Management ................................... 5 - 22
5.4.2 Motivation Theories or Models ....................................................................... 5 - 22
5.4.2.1 Maslow’s Hierarchy of Needs ............................................................................ 5 - 23
5.4.2.2 Herzberg’s Motivation-Hygiene Theory or Herzberg’s Two Factor Theory ....... 5 - 25
5.4.2.3 McGregor’s Theory of X and Y ........................................................................... 5 - 27
5.4.2.4 David McClelland’s Achievement Motivation Theory ....................................... 5 - 28
5.4.2.5 Expectancy Theory (Vroom Expectancy Theory) .............................................. 5 – 29
5.5 Job Characteristics Model ............................................................................... 5 - 30
5.5.1 Basic Elements ................................................................................................. 5 - 30
5.5.2 Hackman and Oldham Job Characteristics Model ........................................... 5 - 32
5.6 Ethical and Programmed Concerns .................................................................. 5 - 34
5.6.1 Introduction ..................................................................................................... 5 - 34
5.6.2 Ethical Issues.................................................................................................... 5 - 35
5.6.3 Solving Ethical Problems.................................................................................. 5 - 38
5.7 Working in Groups and Becoming A Team .................................................... 5 - 39
5.7.1 Working in Group ............................................................................................ 5 - 39
5.7.2 Becoming a Team ............................................................................................ 5 - 40
5.7.3 Group Performance ......................................................................................... 5 - 41
5.7.4 Team Strength ................................................................................................. 5 - 41
5.8 Decision Making .............................................................................................. 5 - 42
5.8.1 Approaches to Make Decision ......................................................................... 5 - 43
5.9 Team Structures .............................................................................................. 5 - 44
5.9.1 Software Project Teams................................................................................... 5 - 44
5.10 Virtual Teams ................................................................................................. 5 - 48
5.10.1 Virtual Teams .................................................................................................. 5 - 48
(xii)
5.10.2 Model of Virtual Teams .................................................................................. 5 - 49
5.10.3 Structure of Virtual Team ............................................................................... 5 - 49
5.10.4 Types of Virtual Team .................................................................................... 5 - 53
5.11 Communication Genres (Types of Communication)...................................... 5 - 55
5.11.1 Communication Genres .................................................................................. 5 - 55
5.11.1.1 Synchronous Communications ......................................................................... 5 - 55
5.11.1.2 Asynchronous Communications ....................................................................... 5 - 56
5.12 Communication Plans .................................................................................... 5 - 57
5.12.1 Communications Management Plan .............................................................. 5 - 58
5.12.1.1 Communication Management Plan Template .................................................. 5 - 58
5.12.2 Communications Management Terminology ................................................. 5 - 59
5.12.2.1 Change Control Management ........................................................................... 5 - 59
5.12.2.2 Communications Management Constraints ..................................................... 5 - 59
5.12.2.3 Communication Activities Management........................................................... 5 - 59
5.12.2.4 Roles in Communication Management............................................................. 5 - 60
5.12.3 Communication Methods and Technologies .................................................. 5 - 62
5.12.3.1 Communication Matrix ..................................................................................... 5 - 62
5.12.3.2 Communication Flowchart................................................................................ 5 - 64
5.12.4 Guidelines for Meetings in Communication Management ............................ 5 - 64
5.12.5 Communication Standards ............................................................................. 5 - 65
5.12.6 Communication Escalation Process ................................................................ 5 - 66
5.12.7 Glossary of Communication Terminology ...................................................... 5 - 67
5.13 Organizational Structure ................................................................................ 5 - 67
5.14 Leadership ..................................................................................................... 5 - 71
5.14.1 Function of Leadership in Organizations ........................................................ 5 - 71
5.14.2 A Leader's Role ............................................................................................... 5 - 72
5.14.3 Model of Leadership (MOI) ............................................................................ 5 - 72
5.15 University Questions with Answers .............................................................. 5 - 72
Solved Question Paper of Anna University (S - 1) to (S - 4)

May-2017 ...................................................................................................... (S - 1) to (S - 4)
(xiii)
(xiv)
Project Evaluation and Project Planning
Unit - I
Chapter - 1
PROJECT EVALUATION AND PROJECT PLANNING
Syllabus : Importance of Software Project Management – Activities Methodologies –

Categorization of Software Projects – Setting objectives – Management
Principles – Management Control – Project portfolio Management – Cost-benefit
evaluation technology – Risk evaluation – Strategic program Management –
Stepwise Project Planning.
Section No. Topic Name Page No.

1.1 Software Project Management 1-2
1.2 Project Portfolio Management 1 - 31
1.3 Project Evaluation 1 - 34
1.4 Cost Benefit Evaluation Technology 1 - 38
1.5 Risk Evaluation 1 - 48
1.6 Project Planning 1 - 51
1.7 Healthy and Safety Issues in Project Management 1 - 60
1.8 Stress 1 - 61
1.9 University Questions with Answers 1 - 68
1-1 Software Project Management

1.1 Software Project Management
1.1.1 Project
 A project is defined as a “temporary endeavor with a beginning and an end and it must
be used to create a unique product, service or result”.
 Further, it is progressively elaborated. What this definition of a project means is that
projects are those activities that cannot go on indefinitely and must have a defined
purpose.
 For instance, if your project is less than three months old and has fewer than 20 people
working on it, you may not be working in what is called a project according to the
definition of the term.
 It has to be remembered that the term temporary does not apply to the result or service
that is generated by the project.
 The project may be finite but not the result.
Examples
 Construction of Chennai Airport

 Computerising Apollo Hospital
 Conducting unit test for final B.Tech !
1.1.1.1 Project Characteristics
A project is not normal day to day activity undertaken by organization rather it is

specific, non-routine activity of varying time frame and impact viability of the business in the
long run. A typical project has following characteristics:
 Timeline : A project has a definite timeline with measurable starting and end point.
 Resources : A project has limited resource of capital and manpower.
 Tools : Special type of tools and techniques are used for project management (Gantt
Charts, etc.)
 Team : Project management requires diverse team stretching across departments and
functions.
1.1.1.2 Project Life Cycle
A typical project is divided into following phases. Each phase of the project has its own
importance and impact on overall success of the project.

 Initiation Phase : In this phase of the project, feedback received from customers is
analyzed and brainstorming is done as to develop new product or modify existing
product to meet the new demands.
 Project Definition Phase : In this phase of the project efforts are made to define the
solution for the problem posed by customers.
 Feasibility Study : In this phase, planning of the project is made and definite
milestones are established.
 Project Execution : In this phase all activities and milestones established in the earlier
phase are executed in a timely and orderly manner. This phase utilizes maximum of all
resources.
 Project Conclusion : This is the last phase of the project. In this phase, final product or
service is handed over to the operations team for commercial production.
1.1.1.3 Project Management
A project in any organization is collaboration across departments to achieve a single

well defined objective. The process of planning, organizing and managing resources to
achieve the organizational objective is called project management.
Project management is very important in production of goods and services. Idea
generation to final production of product or service, each step can be categorized as individual
projects. Any project requires a project manager, who leads the project to its logical
conclusion. Project manager is responsible for appointing team members with different
background but essential in completion of the project.
Management Activities
Basically, the management involves the following activities :

 Planning - Deciding what is to be done
 Organizing - Making arrangements
 Staffing - Selecting the right people for the job
 Directing - Giving instructions
 Monitoring - Checking on progress
 Controlling - Taking action to remedy hold-ups
 Innovating - Coming up with new solutions
 Representing - Liaising with users, etc

1.1.2 Software Project
A Software project is an endeavor with a clear definition of what needs to be delivered

and the date when it needs to be delivered.
Characteristics of software projects
 Non-routine tasks are involved

 Planning is required
 Specific objectives are to be met or a specific product is to be created
 The project has a predetermined time span
 Work is carried out for someone other than yourself
 Work involves several specialism
 People are formed into a temporary work group to carry out the task
 Work is carried out in several phases
 The resources that are available for use on the project are constrained
 The project is large or complex
1.1.2.1 Objectives Versus Products
Many Software projects usually have two stages :

First, is an objective driven project : Recommendations (a new software system)
Second, is a product driven project : Create the software product
Product-driven project :
 A project will be to create a product.

 The details of the product is provided by the client.
Objective-driven project :
 A project is to meet an objective.

 The Client may have a problem and asks a specialist to recommend solutions.
1.1.2.2 Software Projects Versus Other Types of Projects
 Invisibility - With physical artifacts, measuring progress is easy as it can be seen/ felt.
However with Software, progress is not immediately visible.
 Complexity - Software products are, generally, more complex than other engineering
artifact of same value.

 Flexibility - It is easier to change/ modify software systems to meet changing

organizational/ product requirement as compared to other engineering artifacts; it may
not be possible to modify a physical artifact at all.
1.1.2.3 Classifications of Software Projects
The projects are basically defined in two aspects or categories : one is defensive project
and other is aggressive project.
Defensive project : Is the project initiated to stabilize and sustain the current business
situation.
Aggressive project : Is the project initiated to enter into new business in a commercial
manner and majorly depends upon the future prospective rather than the current scenario.
There is other classification of projects as well which is based on the need of execution
and the time, these can be categorized as:
Normal project : Where the time limits are set and adequate.
Brash project : Where additional cost are involved to gain time.
Disaster project : Anything is allowed to gain time.
Projects can be further classified into various other classifications like national and
international projects, industrial and non-industrial projects, on the basis of technology, size,
ownership, public or private projects, need, expansion or diversification projects.
Each of these is discussed as follows :
1. National and international projects : This kind of projects is categorized on the basis
of geographical location set as countries. If one country tries to build projects with other
foreign country, such projects are said to be International projects and when it is done in
one’s own country, then it is said to be a domestic or national project.
2. Industrial and non-industrial projects : The projects initiate in one’s own country
with an objective to make money and for commercialization, are called industrial
projects. For example, a car manufacturing is an industrial project. While the project
which are done for the upliftment of the society and majorly done with social welfare
objectives, are called non-industrial projects. For example Building of a canal,
agricultural development comes under non-industrial projects; these are mainly carried
up by the government.
3. Projects based on technology : These are largely high technology projects which
require lots of investment and works on new or non-existent technologies like rocket
launch project, space projects, etc. and some other are those projects which use

technology which are already proven like a software ERP project, automobile
automation project, etc.
4. Projects based on its size : These projects are based on investment size or capacity of
plant to offer goods or services. This can be further classified down to small, medium
and large scale projects. Project above the investment of 100 million dollars is
considered as large projects.
5. Project based on ownership : This can be further classified as public sector project,
private sector project and joint sector project.
i) Public sector projects : Projects which are of the state, center or both forms of
governments, are known as public sector projects.
ii) Private sector projects : Projects with a complete ownership of promoters and
investors is known as private sector projects. Owners may be an individual,
partnership firm or a company. These projects are mostly done with an objective
to earn profit and thus have a commercial nature.
iii) Joint sector projects : In these projects, there exist a partnership between the
entrepreneurs and the government; it may be from state government or the central
government. These types of partnership occur on the grounds of expertise and
laisioning work and government arranges for the fund in large amounts. For
example, Project of Metro Train, Dams, Information technology parks, Electricity
plants and other similar natured projects.
6. Need based projects : Projects are basically driven by certain needs of the organization
and these needs furthers forms the basis of project categorization as Balancing Project,
Modernization Project, Expansion Project, Diversification Project, Rehabilitation
Project and Plant Relocation Project.
i) Balancing project : Augmenting or strengthening the capacity of particular area
within a chain of entire production plant with a purpose of scaling to the capacity
in order to have optimum utilization, is balancing project.
ii) Modernization project : Upgrading the technology to increase the productivity
and inevitable approach of technology is called modernization project.
iii) Expansion project : When the production capacity of goods and services is to be
increased, the project that is undertaken is known as expansion project.
iv) Diversification project : Project undertaken by the organization to completely
divert from its core business is called diversification project. For example, if a
Petroleum company decides to enter into Information Technology business, then
the project will be known as diversification project.

v) Rehabilitation project : When a project is started to revive a loss bearing

company, is known as rehabilitation project.
vi) Plant Relocation project : When an organization decides to shift his plant from
one location to another, the project started will be known as relocation project.
1.1.2.4 Critical Factors for Project Success and Failure
Measures of Project Success
 The resulting information system is acceptable to the customer.

 The system was delivered “on time.”
 The system was delivered “within budget.”
 The system development process had a minimal impact on ongoing business operations.
Causes of Project Failure
 Failure to establish upper-management commitment to the project

 Lack of organization’s commitment to the system development methodology
 Taking shortcuts through or around the system development methodology
 Poor expectations management
 Premature commitment to a fixed budget and schedule
 Poor estimating techniques
 Overoptimism
 The mythical man-month
 Inadequate people management skills
 Failure to adapt to business change
 Insufficient resources
 Failure to “manage to the plan”
1.1.2.5 Define Project Goal and Objectives
The very first step in all projects: business, home, or education, is to define goals and
objectives. This step defines the projects outcome and the steps required to achieve that
outcome. People, including project managers, do not spend sufficient time on this step or
complete it incorrectly thereby ensuring an unsuccessful project completion.
Poorly defined goals and objectives, or goals without objectives, pushes a project into
overruns, territory battles, personality clashes, missed milestones, and unhappy clients.

Goals and objectives must be clear statements of purpose. Each with its own purpose
that drives the end result of the project. Goals and objectives MUST be measurable.
Goals are the "WHAT"
Goals are broad statements applied to a project. Goals are the "what" of the process. In
other words, "what" will the project accomplish? Projects may have more than one goal, but
many objectives per goal. Do not confuse goals with objectives.
Examples :
1. Website development goal : Visitors will be convinced that global warming exists
2. Insurance company : The Medical Insurance department will increase provider
options by 10 %
3. Physicians office : Patients will not wait longer than 1 hour to see a physician
Objectives are the "HOW"
Objectives are specific statements that support the goal. Every goal will have one or
more objectives tied to it. In essence, the objective is the "how" of the process.
Always start an objective with an action verb. This ensures that the objective is
measurable and that the projects end-result is addressed through the action of the objective.
Each objective becomes a measurable milestone as well.
Examples :
1. Goal : Visitors will be convinced that global warming exists.

 Create a table comparing the costs of addressing global warming today verses 100
years from now.
 Illustrate the effects of global warming in a photo gallery.
 Identify and address the "myths" of global warming.
2. Goal : The Medical Insurance department will increase provider options by 10%.
 Identify provider options and costs.
 Survey the customer to find out each options value.
 Compare options to competitors.
3. Goal : Patients will wait less than 1 hour to see a physician.
 Evaluate personnel requirements.
 Purchase new appointment scheduling software.
 Setup appointment confirmation schedule.

Keeping goals and objectives in the forefront of every project ensures that the project
and the team are on the same page throughout the projects life cycle.
Whether in education, business or are running a household, clearly defined goals and
objectives will support the projects successful result.
1.1.2.6 Problems Related to Software Project
Various problems with software projects in detail
 People-related problems
 Process-related problems
 Product-related problems
 Technology-related problems
1. People-related problems :
Low motivation :
 As the project manager it is the responsibility to ensure an optimal level of
motivation within the team.
 Lengthy projects, complex activities and scarce resources often decrease the
motivation level in a software development team.
Problem employees :
 Some members of any team always create a problem. They lower the efficiency
and productivity of other team members and make it difficult to meet the
objectives of the software project within the specified time.
 Thus project manager need to ensure that employees are not allowed to create a
problem for the rest of the team.
Unproductive work environment :
 The work environment is a major factor that affects the productivity of the
development team. For example, a noisy or cramped workspace decreases the
motivation levels of the employees. Similarly, unfriendly organizational policies
also lower the motivation of the team members.
 As the project manager, need to ensure that the team is protected from harmful
external make the workspace friendly to work in.
Inefficient project management style :
 The project manager needs to lead by example. The team members absorb the
work culture, work ethic, and attitude of the project manager and implement it in
their work style.

 If you display a lack of leadership qualities and weak ideals, the motivation level
decrease across software team.
Lack of stakeholder interest :
 For a software project to be a success, each stakeholder needs to take an active
interest in the progress of the project. Al1stakeholders, including the customer, the
management, and the software development team, need to commit to the success
of the project.
 For example, if the software development team is not committed to the project,
then their contribution may not be to the optimum level.
Ineffective project sponsorship by management :
 Lack of commitment of the senior management to a software project lowers the
motivation level of the team members. If the management commits to the progress
of a software project, and takes a keen interest in the progress, the confidence of
the software development team will increase.
2. Process-related problems
Unrealistic schedule :
 Assigning unrealistic deadlines for a software project is a primary reason for, why
software projects are delayed. Often, the marketing or the management team
commit a delivery date to the customer in the hope of getting the project contract.
However, these dates are not decided in consultation with the development team.
Insufficient identification :
 Unidentified, partially identified, and unplanned risks pose a threat to the success
of a software project. Project manager to intensively identify risks and evolve a
risk management plan such that the project is completed successfully, on time.
Unsuitable life cycle model selection :
 Different software projects require different SDLC models. For example, a project
to create banking software is different from software for a satellite where the
concept needs to be researched.
 Selecting the correct life cycle model is critical to the success of a software
project.
Abandoning quality under pressure of deadlines :
 Where a software project faces a shortage of resources, time, and funds, project
managers often push away quality concerns and focus on meeting deadlines and
staying within the budget.
1 - 10 Software Project Management

 Abandoning quality has a ripple effect that actually adds even more time, effort,
and costs to the software projects.
 The cost of doing things right the first time is lower than the cost of inspection
during product delivery. Also, the cost of inspection is lower than the cost of
debugging software after the customer spots errors.
Unstructured and hurried software development :
 When software project progresses with more focus on meeting deadlines and
staying within a budget, the approach to the software development is unstructured
and hurried.
 Project Manager should plan the software project such that all the activities are
identified, sequenced properly, and roles and responsibilities assigned to the
various people on the project.
3. Product-related Problems
Product scope changed toward the end of the project life cycle :
 The project time, effort, and cost estimates for a software project can go up
dramatically when the customer changes the scope of the product toward the end
of the project.
 In such situations, Project manager should verify the criticality of the scope
change.
Research-oriented software development :
 Many software projects digress from the original scope because of the nature of
the software product or technology used. When a totally new kind of software is
developed or a new technology is used, the software development team can lose
focus of the objectives by getting into a research-oriented approach. It becomes a
responsibility as the project manager to maintain the focus on the objective.
Technology-related problem :
 Technology related problem for a software project might be the low degree of
reuse of the software components created. However, for a car-manufacturing firm,
there is no chance of reusing a component such as a front axle.

1.1.3 Software Project Management
Fig. 1.1.1
 Software project management is the art and science of planning and leading Software
projects. It is a sub-discipline of project management in which software projects are
planned, implemented, monitored and controlled.
 It is a process of managing, allocating and time resources to develop computer software
that meets requirements. In software project management, the end users and developers
need to know the length, duration and cost of the project.
 Software project management is aimed to ensure that the software is delivered on time,
within budget and schedule constraints, and satisfies the requirements of the client.
 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.
Reason, why it plays a vital role in the development of efficient Software ?
All software project needs Project Management process. Mostly, they are tailored to
meet the requirements of the project. Some projects need tighter control and more stringent
processes that might have been mandated in the contract, while some need processes sufficient
to self manage and execute the project to meet the deadlines and quality standards. Whatever
be the reasons, if we don’t follow certain processes, it will definitely jeopardize the project.
There are five reasons to follow this process :
1) To meet the deadlines
2) To maintain the right quality
3) To ensure productivity
4) To prevent re-work
5) To avoid blame gaming

1.1.3.1 Importance of Software Project Management
Software Project management is the art of managing the project and its deliverables
with a view to produce finished products or service. There are many ways in which a project
can be carried out and the way in which it is executed is project management.
 Project management includes : Identifying requirements, establishing clear and
achievable objectives, balancing the competing demands from the different
stakeholders and ensuring that a commonality of purpose is achieved. It is clear
that unless there is a structured and scientific approach to the practice of management,
organizations would find themselves adrift in the Ocean called organizational
development and hence would be unable to meet the myriad challenges that the modern
era throws at them. Hence, the importance of project management to organizations
cannot be emphasized more and the succeeding paragraphs provide some reasons why
organizations must take the practice of project management seriously.
 Without a scientific approach to the task of managing the projects and achieving
objectives, it would be very difficult for the organizations to successfully execute the
projects within the constraints of time, scope and quality and deliver the required result.
In other words, there has to be a framework and a defined way of doing things to ensure
that there is a structure to the art of project management.
 Thus, project management is about creating structure and managing the project
commitments and the delivery of agreed upon results. By using the methods of project
management, organizations can seek to achieve control over the project environment
and ensure that the project deliverables are being managed. Managers face what is
known as the “triple constraint”. This is the competing demands of time, scope and
quality upon the project manager’s list of things to do and how well the project
manager manages these constraints goes a long way in determining the success of the
project. Without the use of Project Management, managers and organizations would
find themselves facing an unpredictable and chaotic environment over which they have
little control. Thus, Project Management is both necessary and essential to the success
of the project.
 Project Management is too big an area to be covered in a few pages and the attempt is
to provide concise and lucid definitions of the various terms and terminologies
associated with a project. It is important to note that project management provides a
framework within which subsequent actions by the organization can be taken and in
this way, it is essential for organizations to adopt the framework provided by the
practice of project management.

1.1.3.2 Need of Software Project Management
Software is said to be an intangible product. Software development is a kind of all new

stream in world business and there’s very little experience in building software products. Most
software products are tailor made to fit client’s requirements. The most important is that the
underlying technology changes and advances so frequently and rapidly that experience of one
product may not be applied to the other one. All such business and environmental constraints
bring risk in software development hence it is essential to manage software projects
efficiently.
Fig. 1.1.2
The image above shows triple constraints for software projects. It is an essential part of
software organization to deliver quality product, keeping the cost within client’s budget
constrain and deliver the project as per scheduled. There are several factors, both internal and
external, which may impact this triple constrain triangle. Any of three factor can severely
impact the other two.
Therefore, software project management is essential to incorporate user requirements
along with budget and time constraints.
1.1.3.3 The Purpose of Software Project Management and Setting Objectives
Software Project Management has developed in order to plan, co-ordinate and control
the complex and diverse activities of modern industrial and commercial projects.All projects
share one common characteristic - the projection of ideas and activities into new endeavours.
The purpose of project management is to foresee or predict as many dangers and
problems as possible; and to plan, organise and control activities so that the project is
completed as successfully as possible in spite of all the risks. The ever-present element of risk
and uncertainty means that events and tasks leading to completion can never be foretold with
absolute accuracy. For some complex or advanced projects, even the possibility of successful
completion might be of serious doubt.

Project management can involve the following activities :

Planning - Deciding what is to be done; Organising - Making arrangements; Staffing -
Selecting the right people for the job; Directing - Giving instructions; Monitoring - Checking
on progress; Controlling - Taking action to remedy hold ups; Innovation - Coming up with
new solutions; Representing - Liaising with users.
Setting Objectives
Effective objectives in project management are specific. A specific objective increases

the chances of leading to a specific outcome. Therefore objectives shouldn't be vague, such as
"to improve customer relations," because they are not measurable. Objectives should show
how successful a project has been, for example "to reduce customer complaints by 50 %"
would be a good objective. The measure can be, in some cases, a simple yes or no answer, for
example, "did we reduce the number of customer complaints by 50 %?"
While there may be one major project objective, in pursuing it there may be interim
project objectives. In lots of instances, project teams are tasked with achieving a series of
objectives in pursuit of the final objective. In many cases, teams can only proceed in a stair
step fashion to achieve the desired outcome. If they were to proceed in any other manner, they
may not be able to develop the skills or insights along the way that will enable them to
progress in a productive manner.
Objectives can often be set under three headings :
1. Performance and Quality

The end result of a project must fit the purpose for which it was intended. At one time,
quality was seen as the responsibility of the quality control department. In more recent
years the concept of total quality management has come to the fore, with the
responsibility for quality shared by all staff from top management downwards.
2. Budget
The project must be completed without exceeding the authorised expenditure. Financial
sources are not always inexhaustible and a project might be abandoned altogether if
funds run out before completion. If that was to happen, the money and effort invested in
the project would be forfeited and written off. In extreme cases the project contractor
could face ruin. There are many projects where there is no direct profit motive, however
it is still important to pay proper attention to the cost budgets, and financial
management remains essential.

3. Time to Completion
Actual progress has to match or beat planned progress. All significant stages of the
project must take place no later than their specified dates, to result in total completion
on or before the planned finish date. The timescale objective is extremely important
because late completion of a project is not very likely to please the project purchaser or
the sponsor.
1.1.3.4 SMART Goal of Project Management
 Must follow SMART approach

 SMART means
o Specific
o Measurable
o Achievable (Agreed upon)
o Relevant (Realistic)
o Time bound
Example
 Develop a web based appointment management system for poly clinics deliverable in
March, 2012 as per ISO 9000 standards within the budget of ` 50 Lakhs,
 Here, the objective is
o Specific–with respect to application development
o Measurable–As per ISO 9000 standards, Below ` 50 lakhs
o Achievable / Realistic-do able appointment system using available Web Technology
(Not something very great or not something never done by anyone before)
o Time bound – Before March, 2012
1.1.3.5 Skills Necessary for Software Project Management
 A theoretical knowledge of different project management techniques is certainly

necessary to become a successful project manager.
 Effective software project management frequently calls for good qualitative judgment
and decision taking capabilities.
 In addition to having a good grasp of the latest software project management techniques
such as cost estimation, risk management, configuration management, project managers
need good communication skills and the ability to get work done.

 However, some skills such as tracking and controlling the progress of the project,
customer interaction, managerial presentations, and team building are largely acquired
through experience.
 None the less, the importance of sound knowledge of the prevalent project management
techniques cannot be overemphasized.
1.1.3.6 Software Project Management Activities
Software project management comprises of a number of activities, which contains

planning of project, deciding scope of software product, estimation of cost in various terms,
scheduling of tasks and events, and resource management. Project management activities may
include :
 Project planning
 Scope management
 Project estimation
Project planning
Software project planning is task, which is performed before the production of software
actually starts. It is there for the software production but involves no concrete activity that has
any direction connection with software production; rather it is a set of multiple processes,
which facilitates software production. Project planning may include the following :
Scope management
It defines the scope of project; this includes all the activities, process need to be done in
order to make a deliverable software product. Scope management is essential because it
creates boundaries of the project by clearly defining what would be done in the project and
what would not be done. This makes project to contain limited and quantifiable tasks, which
can easily be documented and in turn avoids cost and time overrun.
During Project Scope management, it is necessary to -
 Define the scope
 Decide its verification and control
 Divide the project into various smaller parts for ease of management.
 Verify the scope
 Control the scope by incorporating changes to the scope

Project estimation
For an effective management accurate estimation of various measures is a must. With
correct estimation managers can manage and control the project more efficiently and
effectively.
Project estimation may involve the following :
 Software size estimation
Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon
coding practices and Function points vary according to the user or software
requirement.
 Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour required
to produce the software. For effort estimation software size should be known. This can
either be derived by managers’ experience, organization’s historical data or software
size can be converted into efforts by using some standard formulae.
 Time estimation
Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks
are divided into smaller tasks, activities or events by Work Breakthrough Structure
(WBS). The tasks are scheduled on day-to-day basis or in calendar months.
The sum of time required to complete all tasks in hours or days is the total time invested
to complete the project.
 Cost estimation
This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required to
consider -
o Size of software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support

1.1.3.7 Management Functions and Activities
 Functions of management
o Planning
o Organizing
o Staffing
o Directing (leading)
o Controlling
 Planning - Predetermining a course of action for accomplishing an objective
 Organizing - Arranging the relationships among work units for accomplishment of
objectives and the granting of responsibility and authority to obtain those objectives
 Staffing - Selecting and training people for positions in the organization. (Also
eliminating positions as necessary)
 Directing - Creating an atmosphere that will assist and motivate people to achieve
desired end results
 Controlling - Establishing, measuring, and evaluating performance of activities toward
planned objectives
 Each management function can be broken down into individual tasks or activities
1. Planning activities
 Set objectives and goals

 Develop strategies
 Develop policies
 Forecast future situations
 Conduct a risk assessment
 Determine possible courses of action
 Make planning decisions
 Set procedures and rules
 Develop project plans
 Prepare budgets
 Document project plans
 Success criteria for objectives and goals should be specified
 Strategies are long-range goals and the methods to obtain those goals.
 Policies are predetermined management decisions

 Forecast future situations-predict the future and plan accordingly

 Risk is the probability of an undesirable event occurring. A problem is a risk that
has occurred. Contingency plans are what will be done in the situation where the
risk becomes a problem.
 In making planning decisions, the manager consults upper management, the
customer and others
 Procedures establish customary methods and provide guidance for project
activities. Process standards can be used to define procedures.
 The project plan will specify the: tasks, the cost, and the schedule
 Budgeting is the process of placing cost figures on the project plan
2. Organizing activities
 Identify and group project function, activities, and tasks

 Select organizational structures
 Create organizational positions
 Define responsibilities and authority
 Establish position qualifications
 Document organizational decisions
Organizing a software engineering project involves developing an effective and
efficient organizational structure. The purpose is to focus the efforts of the many on a selected
goal.
Organizational structure
 Conventional organization structure
o Line organization
o Staff organization
 Project organization structure
o Functional
o Project
o Matrix
 Team Structure
o Egoless : Decisions made by consensus, group leadership rotates
o Chief programmer : Chief programmer is not often used because of the
difficulty in finding someone experienced enough to be a chief programmer.

o Hierarchical : Hierarchical is most commonly used. Project leaders -> Senior

Engineers -> Junior Engineers.
Establish position qualifications
 Project managers
 Software system engineers
 Scientific/engineering programmers, programmer-analysts
 Verification and validation engineer
 Software quality assurance engineer
These are some examples of positions. The project manager must define the requirements to
fill the positions.
3. Issues In staffing
 Lack of project management training

 Greatly varying skills
 Inability to predict productivity of engineers
 Lack of experience
 Turnover
 Not enough software engineers
o Most graduates are theoretical
o Or just coders
Staffing activities
 Fill organizational positions
 Assimilate newly assigned personnel
 Educate or train personnel
 Provide for general development
 Evaluate and appraise personnel
 Compensate
 Terminate assignments
 Document staffing decisions
Filling positions
 Must look for
o Education
o Experience

o Training
o Motivation
o Commitment
o Self-motivation
o Group affinity
o Intelligence
4. Directing activities
 Provide leadership
 Supervise personnel
 Delegate authority
 Motivate personnel
 Build teams
 Coordinate activities
 Facilitate communication
 Resolve conflicts
 Manage changes
 Document directing decisions
Providing leadership
 Positional power
o Power derived from having a leadership position
o Not always effective
 Personal power
o Charisma or personal charm
o Sometimes more effective than positional power
Job motivations
Job attractors Job dissatisfiers
Salary Company mismanagement
Chance to advance Poor work environment
Work environment Little feeling of accomplishment
Location Poor recognition
Benefits Inadequate salary

Facilities/equipment Little chance to advance

Job satisfaction Poor facilities/equipment
Company management Poor benefits
Job responsibility Poor career path definition
5. Controlling activities
 Develop standards of performance

 Establish monitoring and reporting systems
 Measure and analyze results
 Initiate corrective actions
 Reward and discipline
 Document controlling methods
A standard is a documented set of criteria used to specify and determine the
adequacy of an action or object. A software engineering standard is a set of
procedures that defines the process for developing a software product and/or
specifies the quality of a software product.
The most important software quality attribute is reliability
Management Spectrum
1.1.3.8 The Management Spectrum
 Effective software project management focuses on these items (in this order)
o The people
 Deals with the cultivation of motivated, highly skilled people
 Consists of the stakeholders, the team leaders, and the software team
o The product
 Product objectives and scope should be established before a project can be
planned
o The process
 The software process provides the framework from which a comprehensive
plan for software development can be established
o The project
 Planning and controlling a software project is done for one primary reason…it
is the only known way to manage complexity

 In a 1998 survey, 26 % of software projects failed outright, 46 % experienced

cost and schedule overruns
Process
Fig. 1.1.3
1. The people : The stakeholders
 Five categories of stakeholders

o Senior managers - Define business issues that often have significant influence
on the project
o Project (technical) managers - Plan, motivate, organize, and control the
practitioners who do the work
o Practitioners - Deliver the technical skills that are necessary to engineer a
product or application
o Customers - Specify the requirements for the software to be engineered and
other stakeholders who have a peripheral interest in the outcome
o End users - Interact with the software once it is released for production use
The people : Team leaders
 Competent practitioners often fail to make good team leaders; they just don’t have
the right people skills
 Qualities to look for in a team leader
o Motivation - The ability to encourage technical people to produce to their best
ability
o Organization - The ability to mold existing processes (or invent new ones)
that will enable the initial concept to be translated into a final product
o Ideas or innovation - The ability to encourage people to create and feel
creative even when they must work within bounds established for a particular
software product or application

 Team leaders should use a problem-solving management style

o Concentrate on understanding the problem to be solved
o Manage the flow of ideas
o Let everyone on the team know, by words and actions, that quality counts and
that it will not be compromised
 Another set of useful leadership traits
o Problem solving - Diagnose, structure a solution, apply lessons learned,
remain flexible
o Managerial identity - Take charge of the project, have confidence to assume
control, have assurance to allow good people to do their jobs
o Achievement - Reward initiative, demonstrate that controlled risk taking will
not be punished
o Influence and team building - Be able to “read” people, understand verbal
and nonverbal signals, be able to react to signals, remain under control in high-
stress situations
The people : The software team
 Seven project factors to consider when structuring a software development team
o The difficulty of the problem to be solved
o The size of the resultant program(s) in source lines of code
o The time that the team will stay together
o The degree to which the problem can be modularized
o The required quality and reliability of the system to be built
o The rigidity of the delivery date
o The degree of sociability (communication) required for the project
 Four organizational paradigms for software development teams
o Closed paradigm - Traditional hierarchy of authority; works well when
producing software similar to past efforts; members are less likely to be
innovative
o Random paradigm - Depends on individual initiative of team members;
works well for projects requiring innovation or technological breakthrough;
members may struggle when orderly performance is required

o Open paradigm - Hybrid of the closed and random paradigm; works well for
solving complex problems; requires collaboration, communication, and
consensus among members
o Synchronous paradigm - Organizes team members based on the natural
pieces of the problem; members have little communication outside of their
subgroups
 Five factors that cause team toxity (i.e., a toxic team environment)
o A frenzied work atmosphere
o High frustration that causes friction among team members
o A fragmented or poorly coordinated software process
o An unclear definition of roles on the software team
o Continuous and repeated exposure to failure
 How to avoid these problems
o Give the team access to all information required to do the job
o Do not modify major goals and objectives, once they are defined, unless
absolutely necessary
o Give the team as much responsibility for decision making as possible
o Let the team recommend its own process model
o Let the team establish its own mechanisms for accountability (i.e., reviews)
o Establish team-based techniques for feedback and problem solving
The people : co-ordination and communication issues
 Key characteristics of modern software make projects fail
o scale, uncertainty, interoperability
 To better ensure success
o Establish effective methods for coordinating the people who do the work
o Establish methods of formal and information communication among team
members
Group dynamics
 Based on studies published by B. Tuckman in 1965
 Updated later in 1977
 Describes a four-stage model
o Forming
o Storming

o Norming
o Performing
Group dynamics model
 Forming
o Group members rely on safe, patterned behavior and look to the group leader
for guidance and direction
o Impressions are gathered and similarities and differences are noted
o Serious topics and feelings are avoided
o To grow, members must relinquish the comfort of non-threatening topics and
risk the possibility of conflict
 Storming
o As group members organize for the tasks, conflict inevitably results in their
personal relations and cliques start to form
o Individuals have to bend and mold their feelings to fit the group
o Fear of exposure or fear of failure causes an increased desire for structural
clarification and commitment
o Conflicts arise over leadership, structure, power, and authority
o Member behavior may have wide swings based on emerging issues of
competition and hostilities
o Some members remain silent while others attempt to dominate
 Norming
o Members engage in active acknowledgement of all members’ contributions,
community building, and solving of group issues
o Members are willing to change their preconceived ideas or opinions based on
facts presented by the group
o Leadership is shared, active listening occurs, and cliques dissolve
o Members began to identify with one another, which leads to a level of trust in
their personal relations and contributes to cohesion
o Members begin to experience a sense of group belonging
 Performing
o The capacity, range, and depth of personal relations in the group expand to
true interdependence

o Members can work independently, in subgroups, or altogether with equal

ability and success
o The group is most productive, members become self-assuring, and the need for
group approval is past
o Genuine problem solving can occur leading towards optimal solutions.
2. The Product
 The scope of the software development must be established and bounded

o Context - How does the software to be built fit into a larger system, product,
or business context, and what constraints are imposed as a result of the context ?
o Information objectives - What customer-visible data objects are produced as
output from the software ? What data objects are required for input ?
o Function and performance - What functions does the software perform to
transform input data into output ? Are there any special performance
characteristics to be addressed ?
 Software project scope must be unambiguous and understandable at both the
managerial and technical levels
 Problem decomposition
o Also referred to as partitioning or problem elaboration
o Sits at the core of software requirements analysis
 Two major areas of problem decomposition
o The functionality that must be delivered
o The process that will be used to deliver it
3. The Process
 Getting started
o The project manager must decide which process model is most appropriate
based on
 The customers who have requested the product and the people who will
do the work
 The characteristics of the product itself
 The project environment in which the software team works
o Once a process model is selected, a preliminary project plan is established
based on the process framework activities
o Process decomposition then begins

o The result is a complete plan reflecting the work tasks required to populate the
framework activities
 Project planning begins as a melding of the product and the process based on the
various framework activities
4. The project : A common sense approach
 Start on the right foot

o Understand the problem; set realistic objectives and expectations; form a good
team.
 Maintain momentum
o Provide incentives to reduce turnover of people; emphasize quality in every
task; have senior management stay out of the team’s way.
 Track progress
o Track the completion of work products; collect software process and project
measures; assess progress against expected averages.
 Make smart decisions
o Keep it simple; use COTS or existing software before writing new code;
follow standard approaches; identify and avoid risks; always allocate more
time than you think you need to do complex or risky tasks.
 Conduct a post mortem analysis
o Track lessons learned for each project; compare planned and actual schedules;
collect and analyze software project metrics; get feedback from teams
members and customers; record findings in written form.
The project : Signs that it is in Jeopardy
 Software people don't understand their customer's needs
 The product scope is poorly defined
 Changes are managed poorly
 The chosen technology changes
 Business needs change (or are poorly defined)
 Deadlines are unrealistic
 Users are resistant
 Sponsorship is lost (or was never properly obtained)
 The project team lacks people with appropriate skills
 Managers (and practitioners) avoid best practices and lessons learned

5
The project : The W HH principle
A series of questions that lead to a definition of key project characteristics and the
resultant project plan
 Why is the system being developed ?
o Assesses the validity of business reasons and justifications
 What will be done ?
o Establishes the task set required for the project
 When will it be done ?
o Establishes a project schedule
 Who is responsible for a function ?
o Defines the role and responsibility of each team member
 Where are they organizationally located ?
o Notes the organizational location of team members, customers, and other
stakeholders
 How will the job be done technically and managerially ?
o Establishes the management and technical strategy for the project
 How much of each resource is needed ?
o Establishes estimates based on the answers to the previous questions
1.1.4 Software Project Manager
A software project manager is a person who undertakes the responsibility of executing

the software project. Software project manager is thoroughly aware of all the phases of SDLC
that the software would go through. Project manager may never directly involve in producing
the end product but he controls and manages the activities involved in production.
A project manager closely monitors the development process, prepares and executes
various plans, arranges necessary and adequate resources, maintains communication among all
team members in order to address issues of cost, budget, resources, time, quality and customer
satisfaction.
1.1.4.1 Responsibilities of a Software Project Manager
 Software project managers take the overall responsibility of steering a project to

success. It is very difficult to objectively describe the job responsibilities of a project
manager.

 The job responsibility of a project manager ranges from invisible activities like building
up team morale to highly visible customer presentations.
 Most managers take responsibility for project proposal writing, project cost estimation,
scheduling, project staffing, software process tailoring, project monitoring and control,
software configuration management, risk management, interfacing with clients,
managerial report writing and presentations, etc.
 These activities are certainly numerous, varied and difficult to enumerate, but these
activities can be broadly classified into project planning, and project monitoring and
control activities.
 The project planning activity is undertaken before the development starts to plan the
activities to be undertaken during development.
 The project monitoring and control activities are undertaken once the development
activities start with the aim of ensuring that the development proceeds as per plan and
changing the plan whenever required to cope up with the situation.
1.2 Project Portfolio Management
1.2.1 Introduction
When there are many projects run by an organization, it is vital for the organization to
manage their project portfolio. This helps the organization to categorize the projects and align
the projects with their organizational goals.
Project Portfolio Management (PPM) is a management process with the help of
methods aimed at helping the organization to acquire information and sort out projects
according to a set of criteria.
1.2.2 Objectives of Project Portfolio Management
Same as with financial portfolio management, the project portfolio management also
has its own set of objectives. These objectives are designed to bring about expected results
through coherent team players.
When it comes to the objectives, the following factors need to be outlined.
 The need to create a descriptive document, which contains vital information such as
name of project, estimated timeframe, cost and business objectives.
 The project needs to be evaluated on a regular basis to ensure that the project is meeting
its target and stays in its course.
 Selection of the team players, who will work towards achieving the project's objectives.

1.2.3 Benefits of Project Portfolio Management
Project portfolio management ensures that projects have a set of objectives, which when
followed brings about the expected results. Furthermore, PPM can be used to bring out
changes to the organization which will create a flexible structure within the organization in
terms of project execution. In this manner, the change will not be a threat for the organization.
The following benefits can be gained through efficient project portfolio management :
 Greater adaptability towards change.
 Constant review and close monitoring brings about a higher return.
 Management's perspectives with regards to project portfolio management is seen as an
'initiative towards higher return'. Therefore, this will not be considered to be a
detrimental factor to work.
 Identification of dependencies is easier to identify. This will eliminate some
inefficiency from occurring.
 Advantage over other competitors (competitive advantage).
 Helps to concentrate on the strategies, which will help to achieve the targets rather than
focusing on the project itself.
 The responsibilities of IT is focused on part of the business rather than scattering across
several.
 The mix of both IT and business projects are seen as contributors to achieving the
organizational objectives.
1.2.4 Portfolio Management Tools
There are many tools that can be used for project portfolio management. Following are
the essential features of those tools :
 A systematic method of evaluation of projects.
 Resources need to be planned.
 Costs and the benefits need to be kept on track.
 Undertaking cost benefit analysis.
 Progress reports from time to time.
 Access to information as and when its required.
 Communication mechanism, which will take through the information necessary.

1.2.5 Techniques used to Measure PPM
There are various techniques, which are used to measure or support PPM process from
time to time. However, there are three types of techniques, which are widely used:
 Heuristic model.
 Scoring technique.
 Visual or Mapping techniques.
The use of such techniques should be done in consideration of the project and
organizational objectives, resource skills and the infrastructure for project management.
1.2.6 Why Project Managers to Focus on PPM ?
PPM is crucial for a project to be successful as well as to identify any back lags if it
were to occur. Project Managers often face a difficult situation arising from lack of planning
and sometimes this may lead to a project withdrawal.
It's the primary responsibility of project managers to ensure that there are enough
available resources for the projects that an organization undertakes. Proper resources will
ensure that the project is completed within the set timeline and delivered without a
compromise on quality.
Project managers also may wish to work on projects, which are given its utmost priority
and value to an organization. This will enable project managers to deliver and receive support
for quality projects that they have undertaken. PPM ensures that these objectives of the project
management will be met.
1.2.7 The Five Question Model
Fig. 1.2.1

The five question model of project portfolio management illustrates that the project
manager is required to answer five essential questions before the inception as well as during
the project execution.
The answers to these questions will determine the success of the implementation of the
project.
1.3 Project Evaluation
 A high level assessment of the project.

o To see whether it is worthwhile to proceed with the project.
o To see whether the project will fit in the strategic planning of the whole
organization
o Projects must be evaluated based on strategic, technical and economic grounds.
o The success of a project is built on the initial evaluation of organizational and
financial feasibility.
o Project managers must clearly justify the estimation of costs implementation and
approve the project.
o The strategic objectives combined with the outcomes of the project.
Project evaluation - Why
 Want to decide whether a project can proceed before it is too late

 Want to decide which of the several alternative projects has a better success rate, a
higher turnover, a higher ...
 Is it desirable to carry out the development and operation of the software system ?
Project evaluation - Who
 Senior management
 Project manager/coordinator
 Team leader
Project evaluation - When
 Usually at the beginning of the project

o e.g. Step 0 of Step Wise Framework
Project evaluation - What
 Strategic assessment
 Technical assessment

 Economic assessment
Project evaluation - How
 Cost-benefit analysis
 Cash flow forecasting
 Cost-benefit evaluation techniques
 Risk analysis
1.3.1 Strategic Assessment
 A programme management is where a portfolio of projects all contribute common

objective.
 Used to assess whether a project fits in the long-term goal of the organization
 Usually carried out by senior management
 Needs a strategic plan that clearly defines the objectives of the organization
 Evaluates individual projects against the strategic plan or the overall business
objectives
 Example : Maintenance work of clients
o Customer’s experience of the organization might be very variable and inconsistent.
o A business objective might be consistent and uniform.
Strategic assessment types
 Programme management
o suitable for projects developed for use in the organization
 Portfolio management
o suitable for project developed for other companies by software houses
1.3.1.1 SA - Programme Management
 Individual projects as components of a programme within the organization

o Programme as “A group of projects that are managed in a coordinated way to gain
benefits that would not be possible were the projects to be managed independently”
Programmes may be
o Strategic
o Business cycle programmes
o Infrastructure programmes

o Research and development programmes

o Innovative partnerships
 Strategic : Several projects together implement a single strategy. For example, merging
two organizations will involve many different activities e.g. physical re-organization of
offices, redesigning the corporate image etc. Each of these activities could be project
within an overarching programme.
 Business cycle programmes : A portfolio of project that are to take place within a
certain time frame e.g. the next financial year
 Infrastructure programmes : In an organization there may be many different
applications which share the same hardware/software infrastructure
 Research and development programmes : In a very innovative environment where new
products are being developed, a range of products could be developed some of which
are very speculative and high-risk but potentially very profitable and some will have a
lower risk but will return a lower profit. Getting the right balance would be key to the
organization’s long term success
 Innovative partnerships : e.g. pre-competitive co-operation to develop new
technologies that could be exploited by a whole range of companies
1. Strategic programmes
 Based on OGC (UK government’s Office of Government Commerce (OGC))

approach
 Initial planning document is the Programme Mandate describing
o The new services/capabilities that the programme should deliver
o How an organization will be improved
o Fit with existing organizational goals
 A programme director appointed a champion for the scheme
o The programme director should be someone who is in a prominent position in
the organization so that the seriousness and commitment of the organization to
the programme are made clear.
SA - Programme management issues
 Objectives
o How does the project contribute to the long-term goal of the organization ?
o Will the product increase the market share? By how much ?

 IS plan
o Does the product fit into the overall IS plan ?
o How does the product relate to other existing systems ?
 Organization structure
o How does the product affect the existing organizational structure ? the existing
workflow ? the overall business model ?
 MIS
o What information does the product provide ?
o To whom is the information provided ?
o How does the product relate to other existing MISs ?
 Personnel
o What are the staff implications ?
o What are the impacts on the overall policy on staff development ?
 Image
o How does the product affect the image of the organization ?
 Staff implications includes skills and numbers
 Staff development includes trainings, workshops, seminars, conferences, and
magazine subscriptions etc.
1.3.1.2 SA - Portfolio Management
 suitable for product developed by a software company for an organization

 may need to assess the product for the client organization
o Programme management issues apply
 need to carry out strategic assessment for the providing software company
SA - Portfolio management issues
 Long-term goal of the software company

 The effects of the project on the portfolio of the company (synergies and conflicts)
 Any added-value to the overall portfolio of the company
o Long-term goal: need to ensure that the project fits into the long-term goal of the
software company
o Portfolio: Specialization versus Diversification
o Added-value: consider whether the project will have an added-value to the overall
portfolio of the company

1.3.2 Technical Assessment
 Functionality against hardware and software

o Technical Assessment of a proposed system consists of evaluating the required
functionality against the h/w and s/w available.
o A uniform and consistent hardware/software infrastructure is likely to place
limitations on the nature of technical solutions.
o A uniform and consistent infrastructure must be defined by the organizational
policy so that there are no limitations raised.
o The strategic IS plan of the organization
o any constraints imposed by the IS plan will affect the development cost
1.3.3 Economic Assessment
 A common way is to compare the expected costs of development and operation of the
system with the benefits of having it in production
Why ?
 Consider whether the project is the best among other options

 Prioritise the projects so that the resources can be allocated effectively if several
projects are underway
How ?
 Cost-benefit analysis : Cost-benefit analysis is to compare the estimated costs of

development and operation of a system with the estimated benefits of putting the
system in place.
 Cash flow forecasting : It is because the excess of benefits over costs is not sufficient
to justify the implementation of a proposed project.
 Various cost-benefit evaluation techniques
1.4 Cost Benefit Evaluation Technology
1.4.1 Cost - Benefit Analysis
 Economic assessment of a system - Carried out by comparing the expected cost of

development and operation of the system with the benefits of having it in place.
 Assessment based on whether the the estimated cost are exceeded by the estimated
income and other benefits.
 Standard way of evaluating the economic benefits of any project is to carry out a

Cost - benefit analysis which consist of two steps :

1. Identifying and estimating all of the costs and benefits of carrying out the project and
operating the system.
 Includes developmental costs of the system,the operating costs,and the benefits
that are expected to accrue from the operation of the new system.
 Where proposed replaces existing system these estimates should reflect the change
in costs and benefits due to the system.
2. Expressing the costs and benefits in terms of common units
 Need to evaluate the net benefit that is, the difference between the total benefit
accruing from the system.
1.4.2 Cost Estimation
 Estimate Costs to compare with Benefits/other investment options

 Overall Estimation based on
o Estimation of required activities(structure)
o Estimation for each activity
o Estimation of installation/Set-up cost
o Estimation of operational cost
1.4.2.1 Category of Cost
1. Development cost
 Include salaries and other employment cost of the staff involved in the
development project and all associated costs.
2. Setup costs
 Include the cost of putting the system into place (Hardware and Software
Infrastructure).
 Consist of new hardware and ancillary equipment
 Include cost of Installation, file conversion ,recruitment and staff training.
3. Operational costs
 Costs of operating the system once it has been installed.
 Support costs
 Hosting costs
 Licensing costs
 Maintenance costs
 Back-up costs

1.4.2.2 Benefit Estimation
 Estimate Benefit of new system based on

o Estimation of cost saving and money generation when deployed
o Value of information obtained for objective driven project
o Value of intangibles
1.4.2.3 Category of Benefits
1. Direct benefits
 These accrue directly from the oeration of the proposed system. Include the
reduction in salary bills through the introduction of new computerized system.
 Measurable after the system is operational.
 Have to be estimated for cost/benefit analysis.
2. Assessable indirect benefits
 These are secondary benefits such as increased accuracy through the introduction
of a more user - friendly screen.
 Somewhat quantifiable after the system is operational.
 Have to be estimated for cost/benefit analysis.
3. Intangible benefits
 These are longer term or benefits that are considered very difficult to quantify.
 Positive side effects of new system.
 External System (e.g. Increase branding, Entry to new Markets).
 Internal System (Increased Intrest in job for users, enable for other systems).
 Often very specific to a project : not measurable even after a system is operational.
 Part of Strategic decision rather than Cost/Benefit Analysis.
1.4.3 Cash Flow Forecasting
Estimation of the cash flow over time
 Estimating the overall costs and benefits of a project is the forecasting.

 A cash flow forecast will indicate when expenditure and income will take place.
 Need to spend money at first (e.g. staff salary, employment cost, hardware and software
costs) no matter where the money comes from
e.g. resources from company, or money from the bank
 If the money is from bank, you need to calculate the interest as well.

1.4.3.1 Typical Product Life Cycle Cash Flow
 Expenditures occur by means of staff wages during the development stages of the
project.
 At the same instance, unless income is received, expenses cannot be deferred.
 Accurate cash flow forecasting is not easy.
 When estimating future cash flows, it is usual to ignore the effects of inflation.
 Forecasts of inflation rates tend to be uncertain.
 If expenditure is increased due to inflation it is likely that income will increase
proportionately.
 Cash flows take place at the end of each year.
Fig. 1.4.1
1.4.4 Cost Benefit Evaluation Techniques
Example
Year Project 1 Project 2 Project 3 Project 4

(Cash flow) (Cash flow) (Cash flow) (Cash flow)
0  100,000  1,000,000  100,000  120,000
1 10,000 200,000 30,000 30,000
2 10,000 200,000 30,000 30,000
3 20,000 200,000 30,000 30,000
4 20,000 200,000 20,000 25,000
5 100,000 350,000 20,000 50,000

Net Profit 60,000 150,000 30,000 45,000
Payback 5 5 4 4
ROI 12% 4% 10% 11%
Simple example : (where negative values represent net expenses, positive values
represent net incomes)
Assumptions :
1. Cash flow take place at the end of each year.

2. The year 0 figure represents the initial investment made at the start of the project.
 Cost-benefit analysis is a set of practical procedures for guiding public
expenditure decisions.
 Project evaluation usually requires comparing costs and benefits from different
time periods.
 Cash flow forecasting can be compared for different projects based on same
general methods defined,
 Costs and Benefits have to be expressed using the same scale to be comparable
 Usually expressed in payments at certain times
 Payment at different points in time are not comparable based only on the amount
 Time of payment should be considered
Techniques
 Net profit
 Payback reriod
 Return on investment
 Net present value
 Internal rate of return
Net profit
 The net profit of a project is the difference between the total costs and the total income
over the life of the project.
 Net profits do not involve the timing of the cash flows.
 Project incomes are returned only towards the end of the project.
 Net profit = Total income – Total costs

 Pros : Easy to calculate, simple to use

 Cons :
 Does not show profit relative to size investment
 Does not consider timing of Payments
 Not very useful other than for “Back of Envelope” Evaluations
 ignores the timing of the cash flow
Payback period
 Time taken to break even or payback the initial investment.

 The project with the shortest payback period will be chosen on the basis that an
organization will wish to minimize the time that a project is ‘in debt’
 Minimize the time limit.
 The payback period is simple to calculate but sensitive to forecasting errors.
 The limitation of the payback period is that it ignores the overall profitability of the
project.
 Payback period = Time taken to break even
 Pros : Easy to calculate and is not particularly sensitive to small forecasting errors.
o Gives some idea of Cash Flow Impact
 Cons : Ignores Overall Profitability
o Not very useful by itself, but a good measure for Cash Flow Impact
o Ignores any income (or expenditure) after the payback period
Return On Investment (ROI)
 ROI = (Average annual profit/total investment) * 100

 Also known as Accounting Rate of Return (ARR)
 Provides a way of comparing the net profitability to the investment required
Average annual profit
 Return on Investment (ROI) =  100 %
Total investment
 Pros :
o Easy to calculate
o quite popular
 Cons :
o Does not consider the timing of payments
o Misleading: does not consider bank interest rates

o Not very useful other than for “Back of Envelope” Evaluations

o Takes no accounting of the cash flows.
o Compare the rate of return with current interest rates.
Example :
The net profit of a project is ` 30,000 and the total investment is ` 1,00,000. Calculate
the ROI if the total period is taken as 3 years.
ROI = average annual profit/total investment*100
30,000 * 1/3
= *100
1,00,000
= 10 %
Net Present Value (NPV)
 A Project evaluation technique that takes into account the profitability of a project and
the timing of the cash flow rates are produced.
 Sum of all incoming and outgoing payments, discounted using an interest rate, to a
fixed point in time (the present).
 Present value = (value in year t) / (1 + r) ^ t’
o r is the discount rate.
o t is the number of years into the future that the cash flow occurs.
 Net present value can also be calculated by multiplying the cash flow by the
appropriate discount factor.
 NPV for project is obtained by summing the discounted values and discounting
each cash flows.
 The NPV for project is obtained by discounting each cash flow and summing
the discounted values.
 (1 + r) ^ t is known as discount factor
 In the case of 10% rate and one year
o Discount factor = 1/(1 + 0.10) = 0.9091
 In the case of 10% rate two years
o Discount factor = 1 = (1.10  1.10) 0.8294
 Discount rate is the annual rate by which we discount future earning.
o e.g. If discount rate is 10% and the return of an investment in a year is $110, the
present value of the investment is $100.

Example :
Year Cash flow Discount factor (10 %) Discounted cash flow

0 – 100,000 1 – 100, 000
1 10,000 0.9091 9,091
2 10,000 0.8264 8,264
3 10,000 0.7513 7,513
4 20,000 0.683 13,660
5 100,000 0.6209 62,090
NPV 618
 Pros
o Takes into account profitability
o Considers timing of payments
o Considers economic situation through discount rate.
 Cons : Discount rate can be difficult to choose
 Standard measure to compare different options.
Internal Rate of Return (IRR)
 Attempts to provide a profitability measure as a percentage return that is directly
comparable with interest rates.
 The IRR is calculated as that percentage discount rate that would produce an NPV of
zero.
 A spreadsheet or a small computer program can be used to calculate the IRR is a
convenient and useful measure of value of a project.
 The limitation of IRR is that it does not indicate the absolute size of the return value.
 Can be used to compare different investment oppurtunities.
 May be estimated by plotting a series of guessing.
Fig. 1.4.2

 Pros
o Calculates figure which is easily comparable to interest rates
 Cons : Difficult to calculate (irterative)
 Standard way to compare projects
 Given two NPVs, one positive the other negative estimate IRR as :
o IRR = int1 – npv*1 ((int2 – int1) /(npv2 – npv 1))
o Calculate NPV at this rate.
o Use estimated rate as one data point in next iteration.
1.4.5 Discounted Cash Flow Techniques
Discounted Cash Flow (DCF) analysis is a method of valuing a project, company, or

asset using the concepts of the time value of money. Each cash inflow/outflow is discounted
back to its Present Value (PV). Then they are summed to calculate the Net Present Value
(NPV).
NPV is one of the most robust financial evaluation tools to estimate the value of an
investment, a monetary value of the project’s net cash flows after allowing for cost of capital
and risk; not the same as profit, because it’s cash-based.
n
Ct
NPV =  (1 + r)
t  C0
t=1
where :
t is the time of the cash flow
n is the total time of the project
r is the discount rate
C t is the net cash flow at time t, i.e. the Future Value (FV)
C0 is the initial investment at t = 0

The calculation of NPV requires identifying the size and timing of the expected future
cash flows generated by the project or investment and determining the discount rate or the
estimated rate of return for the project. The expected cash flows are then calculated from all
the possible cash flows and their associated probabilities.
NPV as a decision making tool: the higher NPV the higher the investment opportunity.
 If NPV>0, then the project/investment is worth doing (it will add value to the company)
 If NPV<0, then the investment is not worth doing (lost of value)

 If NPV=0, then the investment will contribute to a fair return based on

planned Internal Rate of Return (IRR) – the investment will not add a monetary value
to the company, the decision to go ahead or not will depend on other factors not
explicitly included in the calculation
The IRR is defined as the discount rate that makes the project have NPV=0. It relates to
the Return On Capital Employed ratio (ROCE) which measures surplus (return) earned on
commercial activity. IRR is an alternative method of evaluating software investments without
estimating the discount rate. IRR takes into account the time value of money by considering
the cash flows over the lifetime of a project (N is the last year of the project or investment).
n
Ct
NPV = 0 = Initial investment +  (1 + I RR)
t
t=1
Calculating the IRR is typically done through a trial-and-error process that looks for the
discount rate that makes an NPV equal to zero.
IRR as a decision making tool: the higher IRR the better potential return on investment.
Projects are regarded as economically viable if their IRR exceeds the expected cost of capital
for organizations and projects having a similar risk. However, IRR is not a great indicator as
to the magnitude of investment needed, benefit value or payback, so the returns may be high,
but the investment high, benefits not significant and/or payback (risk) too high.
 If IRR > Cost of capital, then NPV > 0
 If IRR < Cost of capital, then NPV < 0
Despite a strong academic preference for NPV, surveys indicate that executives prefer
IRR over NPV.
Payback period refers to the period of time required for the return on an investment to
recover an initial investment through cash flows generated by the investment.
Payback period = (initial investment)/(cash flow)
It tells about the level of profitability of an investment in relation to time; the shortest
payback period is preferable.
Limitations of the payback period analysis include the fact that it does not address the
time value of money, nor does it go beyond the recovery of the initial investment. But despite
this, payback is in wider use than NPV and even accounting practitioners are sometimes
reluctant to use NPV. Projects with shorter payback periods are sometimes preferred because
they put less strain on liquidity.


1.5 Risk Evaluation
 Risk is associated with almost every project.

 Risk can become an important factor when the project is not able to meet its objectives.
 Every possible risk must be identified, analyzed and minimized during the development
of the software system.
1.5.1 Risk Identification and Ranking
 Every projects evaluation involves risk handling issues.

 The project evaluation are used to identify the risks and quantify their potential effects.
 The importance and likelihood are classified as high, medium, low.
 The project risk matrix may be used as a way of evaluating projects or as a means of
identifying and ranking the risks for a specific project.
1.5.2 Risk and Net Present Value
 A higher discount rate are used to calculate net present value.

 Projects may be categorized as high, medium or low risk using a scoring method and
risk premiums designated for each category.
Risk matrix to determine risk level
Likelihood
Remote Occasional Frequent
Severity
Major Medium risk High risk High risk
Moderate Low risk Medium risk High risk
Minor Low risk Low risk Medium risk
Likelihood
Remote (1) Occasional (2) Frequent (3)
Severity
Minor (1) 1 2 3
Moderate (2) 2 4 6
Major (3) 3 6 9

Acceptability of risk
Risk Risk Acceptability Recommended actions

score level of risk
<3 Los risk Acceptable No additional risk control measures required. To
continue to monitor to ensure risk do not escalate to
higher level.
3-4 Medium Moderately Acceptable to carry out the work activity; however,
risk acceptable task need to be reviewed to bring risk level to as low as
reasonably practicable. Interim control measures such
as administrative controls can be implemented.
Supervisory oversight required.
>4 High Not acceptable Job must not be carried out until risk level is brought to
risk at least medium risk level.
Risk controls should not be overly dependant on
personal protective equipment. Controls measures
should focus on elimination, substitution and
engineering controls.
Immediate management intervention required to ensure
risk being brought down to at least medium level before
work can be commenced.
1.5.3 Cost Benefit Analysis
 The evaluation of risk are considered based on the possible outcome and estimate its
probability.
 The value of the project is then obtained by summing the cost or benefit for each
possible outcome weighted by its corresponding probability.
 It is used in evaluation of large projects.
 It is most appropriate to evaluate a portfolio of projects to determine the overall
profitability.
1.5.4 Risk Profile Analysis
 The construction of risk profiles uses the sensitivity analysis.

 It evaluate the sensitivity of the project to each factor.

 Sensitivity analysis vary each factor one at a

time.
 Sensitivity analysis identifies the factors that
yields a success to the project and decide
about whether to carry on with the project or
lay off.
 The simulation tool is used to find out the
number of possible chances of specific
project. Fig. 1.5.1 A risk analysis profile
 The main activities of the risk paradigm are,

o Identify
o Analyze
o Plan
o Track
o Control
o Communicate
Fig. 1.5.2

1.5.5 Using Decision Trees

 Decision trees is a tool which provides evaluation of project’s expected outcomes and
choosing between the alternative strategies.
 The analysis of a decision tree consists of evaluating the expected benefit of taking each
path from a decision point.
 The expected value of each path is determined by the sum of the value of each possible
outcome multiplied by its probability of occurrence.
Advantage
 It will give a precise idea of modeling and analyzing the problems in the project.
Decision tree
Fig. 1.5.3
1.6 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.
1.6.1 Types of Project Plan
Plan Description
Quality plan Describes the quality producers and standards that will be used in
a project.

Validation plan Describe s approach, resources and schedule used for system
validation.
Configuration Describes the configuration management procedures and
management plan structures to be used.
Maintenance plan Predicts the maintenance requirements of the system, maintenance
costs and effort required.
Staff development Describes how the skill and experience of the project team
plan members will be developed.
1.6.2 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
Revised estimates of project parameters
Update the project schedule
Re-negotiable project constraints and deliverables
If (problem arise) then
Initiate technical review and possible revision
end if
end loop
1.6.3 Project Plan Structure
 Introduction
 Project organisation
 Risk analysis
 Hardware and software resource requirements
 Work breakdown
 Project schedule
 Monitoring and reporting mechanisms

1.6.4 Project Planning Techniques : Work Breakdown Structure (WBS)

 Hierarchical decomposition of a project into subtasks
o Shows how tasks are decomposed into subtasks
o Does not show duration
o Does not show precedence relations (e.g. task A must be finished before task B can
start)
Fig. 1.6.1
Project planning techniques : PERT charts
Fig. 1.6.2
 PERT chart (Program Evaluation and Review Technique)
 A network (graph) where the nodes represent tasks and arrows describe precedence
relations
o Used successfully in management of Polaris missile project in 50’s
o Shows task duration (on the task node)
o Shows precedence relations
o Generally does not show task decomposition
Project planning techniques : Gantt charts
Fig. 1.6.3

 A graphical visualization of a schedule, where the time span for each activity is
depicted by the length of a segment drawn on an adjacent calendar
o Generally does not show task decomposition
o Does not show duration, only the time span over which the task is scheduled
o Does not show precedence relations
o Can show activity of multiple developers in parallel
o Makes it easy to monitor a project’s progress and expenditures
1.6.5 Stepwise Project Planning
Fig. 1.6.4
Step Activities within step

0 Select project
1 Indentify project scope and objectives

1.1 Identify objectives and measures of effevtiness in meeting them

1.2 Establish a project authority
1.3 Indenity stakeholders
1.4 Modify objectivies in the light or stakeholder analysis
1.5 Establish methods of communication with all parties
2 Identify project infrastructure
2.1 Establish relationship between project and strategic planning.
2.2 Identify installation standards and procedures
2.3 Identify project team organization
3 Analyse project characteristics
3.1 Distinguish the project as either objectives or product driven
3.2 Analyse other project charateristics
3.3 Identify high-level project risks
3.4 Take into account user requirements concerning implementation
3.5 Select general life cycle approach
3.6 Review overall resource estimates
4 Identify project products and activities
4.1 Identify and describe project products (including quality criteria)
4.2 Document generic product flows
4.3 Recognize product instances
4.4 Produce ideal activity network
4.5 Modify ideal to take into account need for stages and checkpoints
5 Estimate effort for each activity
5.1 Carry out bottom-up estimates
5.2 Revise plan to create controllable activities
6 Identify activity risks
6.1 Identify and quantify activity-based risks
6.2 Plan risk reduction and contingency measures where appropriate

6.3 Adjust plans and estimates to take account of risks

7 Allocate resources
7.1 Identify and allocate resources
7.2 Revise plans and estimates to take account of resource constraints
8 Review/publicize plan
8.1 Review quality aspects of project plan
8.2 Document plans and obtain agreement
9/10 Execute plan/lower levels of planning
This may require the reiteration of the planning process at a lower level.
Step Wise - An Overview
 Step 0 : Select project

 Step 1 : Identify project scope and objectives
 Step 2 : Identify project infrastructure
 Step 3 : Analyze project characteristics
 Step 4 : Identify project products and activities
 Step 5 : Estimate effort for each activity
 Step 6 : Identify activity risks
 Step 7 : Allocate resources
 Step 8 : Review/publicize plan
 Step 9 : Execute plan
 Step 10 : Execute lower levels of planning
Step 0 : Select project
 This is called Step 0 because in a way it is outside the main project planning process.
Proposed projects do not appear out of thin air – some process must decide to initiate
this project rather than some other. While a feasibility study might suggest that there is
a business case for the project, it would still need to be established that it should have
priority over other projects. This evaluation of the merits of projects could be part of
project portfolio management.

Step 1 : Identify project scope and objectives
 Step 1.1 : Identify objectives and practical measures of the effectiveness in meeting
those objectives
 Step 1.2 : Establish a project authority
o To ensure the unity of purpose among all persons concerned
 Step 1.3 : Identify all stakeholders in the project and their interests: Essentially all the
parties who have an interest in the project need to be identified.
 Step 1.4 : Modify objectives in the light of stakeholder analysis: In order to gain the
full cooperation of all concerned, it might be necessary to modify the project objectives.
This could mean adding new features to the system which give a benefit to some
stakeholders as a means of assuring their commitment to the project. This is potentially
dangerous as the system size may be increased and the original objectives obscured.
Because of these dangers, it is suggested that this process be done consciously and in a
controlled manner.
 Step 1.5 : Establish methods of communication between all parties:For internal staff
this should be fairly straightforward, but a project leader implementing a payroll system
would need to find a contact point with BACS (Bankers Automated Clearing Scheme),
for instance.
Step 2 : Identify project infrastructure
 Step 2.1 : Identify relationship between the project and strategic planning
o To determine the order of related projects (in the organization) being carried out
o To establish a framework within which the system fits
o To ensure the hardware and software standards are followed
 Step 2.2 : Identify installation standards and procedures
o more appropriate name: “Identify standards and procedures related to the software
project”
o software development procedures and standards
o quality procedures and standards
o change control and configuration management standards
o project planning and control standards
 Step 2.3 : Identify project team organization

o Project leaders, especially in the case of large projects, might have some control
over the way that their project team is to be organized. Often, though, the
organizational structure will be dictated to them. For example, a high-level
managerial decision might have been taken that software developers and business
analysts will be in different groups, or that the development of business-to-
consumer web applications will be done within a separate group from that
responsible for ‘traditional’ database applications.
Step 3 : Analyse project characteristics
 Step 3.1 : Distinguish the project as either objective-driven or product-driven

o As system development advances, it tends to become more product-driven,
although the underlying objectives always remain and must be respected.
 Step 3.2 : Analyse other project characteristics (including quality-based ones)
o The nature of the system
o An information system or a process control system? or both?
o A safety-critical system or not?
 Step 3.3 : Identify high level project risks
o Consider those risks that affect the successful outcome of the project
o Where? Possibly the following:
o the operational or development environment,
o the technical nature of the project
o the type of product being developed
 Step 3.4 : Take into account user requirements concerning implementation
o Sometimes, the client's organisation may have their own stadnards and procedures.
o An example may be that departments in government may require the use of
SSADM (Structured System Analysis and Design Methodology).
o Another example may be that DoD (Department of Defense) has their own
standards and procedures
 Step 3.5 : Select general lifecycle approach in the light of the above
o If user requirements are unclear, a prototyping approach might be used.
 Step 3.6 : Review overall resource estimates
Up to this stage,
o the major risks of the project are identified
o the overall approach of the project is decided

So, it is a good place to re-estimate the required effort and other resources for the
project
Step 4 : Identify project products and activities
 Step 4.1 : Identify and describe project products

o Identify all the products related to the project
o Account for the required activities
 Step 4.2 : Document generic product flows
o To document the relative order of the products
 Step 4.3 : Recognize product instances
 Step 4.4 : Produce an ideal activity network
o Activity network shows the tasks that have to be carried out as well as their
sequence of execution for the creation of a product from another
 Step 4.5 : Modify the ideal to take into account need for stages and checkpoints
o To check compatibility of products of previous activities
Step 5 : Estimate effort for each activity
 Step 5.1 : Carry out bottom-up estimates

o need to estimate staff effort, time for each activity, and other resources
o Different estimation methods may be used depending on the type of activity.
o Calculate the overall duration of project based on the estimated time for each
activity in the activity network.
 Step 5.2 : Revise plan to create controllable activities
o need to break a task into a series of manageable sub-tasks
Step 6 : Identify activity risks
 Step 6.1 : Identify and quantify the risks of each activity

 Step 6.2 : Plan risk reduction and contingency measures where appropriate: It may be
possible to avoid or at least reduce some of the identified risks. On the other hand,
contingency plans specify action that is to be taken if a risk materializes. For example, a
contingency plan could be to use contract staff if a member of the project team is
unavailable at a key time because of serious illness.
 Step 6.3 : Adjust overall plans and estimates to take account of risks : We may change
our plans, perhaps by adding new activities which reduce risks. For example, a new

programming language might mean we schedule training courses and time for the
programmers to practise their new programming skills on some non-essential work.
Step 7 : Allocate resources (Staffing)
 Step 7.1 : Identify and allocate resources

o type of staff needed for each activity
o staff availabilities are identified
o staff are provisionally allocated to task
o Staff expertise should be considered.
 Step 7.2 : Revise plans and estimates to take into account resource constraints
o staffing constraints
o staffing issues
Step 8 : Review / Publicize plan
 Step 8.1 : Review quality aspects of the project plan

o To ensure each activity is completed with a quality product
o Each activity should have ‘exit requirements’.
o This ensures the quality of the product on each activity.
 Step 8.2 : Document plans and obtain agreement
o all parties understand and agree to the commitments in the plan
Steps 9 and 10 : Execute plan/lower levels of planning
 Once the project is under way, plans will need to be drawn up in greater detail for each
activity as it becomes due. Detailed planning of the later stages will need to be delayed
because more information will be available nearer the start of the stage. Of course, it is
necessary to make provisional plans for the more distant tasks, because thinking about
what needs to be done can help unearth potential problems, but sight should not be lost
of the fact that these plans are provisional.
1.7 Healthy and Safety Issues in Project Management
These vary between projects :

Safety would deal with more single instance injuries, while health could be more single
and extended usage.

 Situation : someone gets hurt doing the process of completing your project; a worker
hits their finger with a hammer while building.
 Environmental : someone is hurt because of the nature of work location: a person
freezes on an arctic style project or drowns on an undersea one.
 Process : someone gets hurt because of the process you make; can be accidental
(Bhopal, India Union Carbide accident), or chronic (the materials you use for
excavation processes leach into the groundwater and increase cancer rates in the
surrounding community)
 Ergonomic : loud jets at an airport affect hearing for the surrounding neighborhoods,
or light pollution causes a species adapted to darkness on the limits of the property to
die off.
 Even for non-construction style hazards can exist: programmers working on an
application that requires long hours of work may discover their health deteriorates due
to lack of exercise or sleep. An analyst working on a highly visible financial merger
finds that the stress causes them to need blood pressure medication.
A more complete way to determine what are possible issues to deal with could come
from :
 Analysis of Process
 Situational analysis and / or simulations
 Risk analysis during a project planning
 Stakeholder identification and analysis, coupled with one of the items listed above.
1.8 Stress
While some workplace stress can be considered normal, excessive workplace stress can
interfere with employee productivity and it can have a negative impact on the physical and
emotional health of the employee. Although it is evident that not everything in a work
environment can be controlled, the good news is that stress can be managed. It does not
involve making huge changes, rather it focuses on the one factor that can be controlled: the
individual/the employee. Stress management is important to project managers because at this
period competition is keener in many industries and it is important to learn new and better
ways of dealing with the pressure at work as well as managing projects from start to finish.

1.8.1 What is Stress ?

Over the years, stress has been defined as strain within a person and as pressure from
the environment. Today, the generally accepted definition of stress is seen as an interaction
between the situation and the individual. Michie (2002) defines stress as the psychological and
physical state that results when the resources of the individual are not sufficient to cope with
the demands and pressures of the situation. This implies that stress is more likely to occur in
some individuals than others and in some situations than others.
Fig. 1.8.1 the Yerlees-Dodson Curve

Based on the Yerkes-Dodson curve, moderate level of stress improves performance and
when the stress level increases more, the performance decreases. Hence, it is crucial for
project managers to be able to moderate the stress levels for optimal performance.
1.8.2 Signs of Stress
Signs of stress are noticeable in changes in people’s behavior, thinking and feelings.
Feeling (Emotions) Thinking (Cognitions)
Anxiety Poor concentration and memory

Depression/tiredness   Poor organization and decision making
Angry/irritable/frustrated Less creative in problem solving  
Apathetic/bored Hypersensitive to criticism
Behavior Your body
Having accidents/making mistakes

Sweating, dizziness, nausea, breathlessness
Eating/sleeping problems
Aches and pains Frequent infections, Loss
Taking drugs (e.g., tobacco, alcohol)  
of sex drive, Asthma, ulcers, skin
Problematic social behavior (e.g., withdrawal, complaints and cardiac problems
aggression)

1.8.3 A Model of Stress at Work
Fig. 1.8.2

1.8.4 Causes of Stress at Work
Generally, and as it is presented above in the model, causes or sources of stress can be
categorized into five categories.
 Factors that are intrinsic to jobs
 The role of the employee in the organization
 Career development issues
 Employee’s relationship with others at work
 The structure and the climate of the organization
The sources of stress identified above can be further put into two categories :
 Stress that has to do with the content of work
 Stress that is related to the social and organizational context of work
The model also shows that if stress persists, it can lead to mental and physical ill health.
Empirical evidence shows that the common causes of stress at work include :
 Fear of being laid off
 Increased overtime caused by staff cutbacks
 Pressure to meet high expectations but with no increase in job satisfaction
 Pressure to work at optimal levels at all times
Situations that are likely to induce stress are those that are unpredictable or
uncontrollable, unfamiliar or ambiguous, uncertain, loss of performance expectation and
situations involving conflict. Time limited situations such as work deadlines, family demands,
job insecurity and ongoing situations or projects also cause stress.
1.8.5 Involvement in Stress Management
Both employee and the management are responsible for stress management.
1. The Employee
As an employee, it is important to note that emotions are contagious. When we are

stressed as employees, it has an impact on how we relate with others at work. If an employee
is good at managing their own stress, they will affect other employees around them positively.
It is also interesting to note that other employees’ stress will have little or no negative effect
on such employees. Some tips are provided below on how we can manage stress as employees
in the workplace.

 Recognize warning signs of stress at work

The signs and symptoms of stress at work have been provided earlier. It is the duty of
the employee to watch out for these signs.
 Take care of yourself
Managing one’s personal life is an effective way of managing stress. When stress
interferes with the ability of an employee to perform their work, it is perhaps time to
take care of their own needs. This will make the employee stronger and more resilient
to stress. Little changes such as eating healthy, exercising regularly and getting enough
sleep can help relieve some of the stress. It is also wise to get support from close
relationships to help one through times of stress. Simply sharing one’s feelings with
another person can relieve some of the stress.
 Prioritize and Organize
To regain control over oneself and the situation when workplace stress becomes
overwhelming, an employee should consider doing the following:
2. Time management
 Create a balanced schedule : Analyze your schedule, daily tasks and responsibilities.
Work towards finding a balance between work and family life, daily responsibilities,
social activities and downtime.
 Try not to commit yourself into too many things : Try not to fit in too many things into
one day. If there are too many tasks to be accomplished, leave out tasks that are not
necessary till the very end or eliminate them completely.
 Try to start your day earlier : Do not add more stress by running late.
 Take short breaks throughout the day : Try to get away from your desk at some point
while at work. Try to take a walk or just sit back and rest your mind. This will help you
refuel and become more productive.
3. Tasks management
 Prioritize tasks : Make a list of all the tasks that you have to do for that day and arrange
them in order of importance (putting the most important task on top). It is advisable to
do the unpleasant tasks early. The rest of the day will most likely be more pleasant.
 Break large projects into small steps : Rather than taking everything at once, make it a
step-by-step process.

 Delegate responsibility : An employee can let go of unnecessary stress by delegating

responsibilities to other members of staff. Avoid the desire to control every process of
achieving a task.
 Be willing to compromise : When it is necessary, bend a little and try to find a middle
ground that will reduce the stress for everyone.
(a) Improve emotional intelligence
The ability to manage and use one’s emotions positively and constructively is emotional
intelligence. In a work environment where a lot of stress is encountered, employees can
manage stress by communicating in a way that draws people closer, repairs wounded
feelings and resolves tension and stress. There are four major components of emotional
intelligence at work :
Self-awareness - Ability to recognize one’s emotions and the impact of these emotions
on others
Self management - Ability to control one’s emotions and behavior and adapt to
changing circumstances
Social awareness - Ability to sense, understand, and react to other’s emotions and feel
comfortable socially
Relationship management - Ability to inspire, influence, and connect to others and
manage conflict.
(b) Break bad habits
(c) Resist the urge to be perfect. Do not set unrealistic goals. Aim to do your best.
 Think positively
 Work on improving your weak areas. For example, if you come to work late, set
your watches fast. Make a list of all you need to do and stick to it. If your desk is a
mess, clean up and throw away the unnecessary things.
 Do not waste time trying to control the uncontrollable (e.g., the behavior of other
people). Rather, focus your energy on the things you can control such as yourself
and the way you react to stress.
1.8.6 The Stress Management
Historically, the typical response from employers has been to blame the stress victim
rather than the cause of the stress. In recent times, it is increasingly being recognized that
ensuring employee wellbeing is an important management responsibility. It is in the best
interest of the organization to keep stress levels to a minimum for their long-term economic
interest. In the absence of stress at the workplace, there is likely to be low employee turnover,

reduction in sickness absence and early retirement, increased work performance, increased
client satisfaction and reduced accident rate. An organization works to reduce stress through
the strategic activities of project managers, line managers and human resources department.
 Good employment practices will generally include :
 Looking for the causes of stress at work
 Deciding who it might harm
 Deciding whether the organization is doing enough to prevent the harm
Evidently, preventing and managing workplace stress requires organizational level
interventions. Organizational level interventions can be structural (e.g., staffing levels, work
schedule, physical environment). It can also be psychological (e.g., social support, control
over work and participation).
Additionally, other organizational changes that managers and employers can make to
reduce workplace stress include :
1. Improve communication
 Reduce fear and uncertainty by sharing information with employees

 Define the roles and responsibilities of employees clearly
 Communicate in a friendly and efficient manner
2. Consult the employees
 Allow employees to participate in decisions that affect their jobs

 Consult employees about scheduling and work rules
 Do not set realistic deadlines
 Appreciate the work of employees and show that individual workers are valued
 Offer employees rewards and incentives
 Celebrate good performance verbally and officially (e.g., employee of the month
scheme)
 Provide opportunities for career development
3. Cultivate a friendly social climate
 Provide opportunities for social interaction among employees

 Let management actions be consistent with organizational rules
 Have a no-tolerance policy for harassment

1.9 University Questions with Answers
Q.1 Mention the characteristics of Software Projects. (Refer section 1.1.2)

Dec. - 2012, 2013 .
Q.2 Define Software Project Management. (Refer section 1.1.3) May - 2014 .
Q.3 Which Factor decides the success of a project ? (Refer section 1.1.2.4)
Dec. - 2012 .
Q.4 Distinguish between objectives and Products. (Refer section 1.1.2.1)
May - 2013, 2014 .
Q.5 What are the characteristics that makes software project different from other projects.
(Refer section 1.1.2.2) Dec. - 2014 .
Q.6 Explain the activitie of Software Project Management with Example.
(Refer section 1.1.3.6) Dec. - 2012, 2013, 2014 .
Q.7 Illustrate few problems associated with Software Project.
(Refer section 1.1.2.6) Dec. - 2012 .
Q.8 Explain the goals of project Management with Examples.
(Refer section 1.1.3.4) May - 2014 .
Q.9 What is the concept of Strategic Programmes. (Refer section 1.3.1)
Dec. - 2013 .
Q.10 Explain Technical Assessment vs. Strategic Assessment.
(Refer section 1.3) May - 2014 .
Q.11 Discuss the steps involved in Stepwise Project Planning with an Example.
(Refer section 1.6.5) Dec. - 2012, 2013, 2014, May - 2014 .
Q.12 Give the Significance of Cost Benefit Analysis. (Refer section 1.4) Dec. - 2012 .
Q.13 What are called as Discounted Cash Flow Techniques ? (Refer section 1.4.5)
Dec. - 2014 .
Q.14 What are the Steps in Cost Benefit Analysis ? (Refer section 1.4) Dec. - 2013 .
Q.15 Discuss the different Cost Benefit Evaluation Techniques. Give examples.
(Refer section 1.4.4) Dec. - 2013, May - 2014 .
Q.16 Explain the salient features of various Cost Benefit Evaluation Techniques.
(Refer section 1.4.4) Dec. - 2014 .
Q.17 What is meant by Cash Flow Forecasting ? (Refer section 1.4.3) May - 2014 .
Q.18 When Net Present value is calculated for a project. (Refer section 1.4.4)
Dec. - 2012 .
Q.19 Discuss the Cash Flow forecasting with different cost benefit evaluation Techniques.
(Refer sections 1.4.3 and 1.4.4) Dec. - 2012 .
Q.20 What do you understand by Payback Period. (Refer section 1.4.4) Dec. - 2014 .
Q.21 Give the methodology used to evaluate risk in a project. (Refer section 1.5)
Dec. - 2012 .
Q.22 Explain Risk Evaluation. (Refer section 1.5) May - 2014 .

Q.23 Explain the various aspects of Risk Evaluation. (Refer section 1.5)
Dec. - 2014 .
Q.24 Discuss the various activities of Project Evaluation. Give Example.
(Refer section 1.3) Dec. - 2013 .
Q.25 Explain the various Health and Safety issues to be addressed in a project.
Project Evaluation and Project Planning ends....

Notes

Project Life Cycle and Effort Estimation
Syllabus : Software process and Process Models - Choice of Process models - mental
delivery - Rapid Application development - Agile methods - Extreme
Programming - SCRUM - Managing interactive processes - Basics of Software
estimation - Effort and Cost estimation techniques - COSMIC Full function
points - COCOMO II A Parametric Productivity Model - Staffing Pattern.

2.1 Software Process 2-2
2.2 Choice of Process Models 2 - 14
2.3 Basic of Software Estimation 2 - 16
2.4 Software Cost Estimation 2 - 16
2.5 Effort Estimation 2 - 28
2.6 COCOMO II 2 - 44
2.7 Systems Development Life Cycle 2 - 46
2.8 Uniersity Questions with Answers 2 - 49

2.1 Software Process
A software development process, also known as a software development lifecycle, is a

structure imposed on the development of a software product. A software process is
represented as a set of work phases that is applied to design and build a software product.
There is no ideal software process, and many organisations have developed their own
approach to software development. Software development processes should make a maximum
use of the capabilities of the people in an organisation and the specific characteristics of the
systems that are being developed.
There are some fundamental activities that are common to all software processes :
1. Software specification. In this activity the functionality of the software and constraints
on its operation must be defined.
2. Software design and implementation. The software that meets the specification is
produced.
3. Software validation. The software must be validated to ensure that it has all the
functionalities what the customer needs.
4. Software evolution. The software must evolve to meet changing customer needs.
2.1.1 Software Process Models
A software process model is an abstract representation of a software process. and they

are presented from an architectural viewpoint. These models can be used to explain different
approaches to software development. They can be considered as process frameworks that may
be extended and adapted to create more specific software engineering processes.
Types of Software Process Models
Waterfall Model
 The waterfall Model is a linear sequential flow.

 In which progress is seen as flowing steadily downwards (like a waterfall) through the
phases of software implementation. This means that any phase in the development
process begins only if the previous phase is complete.
 The waterfall approach does not define the process to go back to the previous phase to
handle changes in requirement.
 The waterfall approach is the earliest approach that was used for software development.

Fig. 2.1.1
The usage
Projects which not focus on changing the requirements, for example, projects initiated
from request for proposals.
Advantages and Disadvantages
Advantages Disadvantages
 Easy to explain to the user·  Assumes that the requirements of a

 Structures approach. system can be frozen·
 Stages and activities are well defined  Very difficult to go back to any stage after
 Helps to plan and schedule the project it finished.
 Verification at each stage ensures early  Little flexibility and adjusting scope is
detection of errors and misunderstanding difficult and expensive.
 Each phase has specific deliverables  Costly and required more time, in
addition to detailed plan
V-Shaped Model
 It is an extension for waterfall model, Instead of moving down in a linear way, the
process steps are bent upwards after the coding phase, to form the typical V shape.
 The major difference between v-shaped model and waterfall model is the early test
planning in v-shaped model.

Fig. 2.1.2
The usage
 Software requirements clearly defined and known

 Software development technologies and tools is well-known
 Simple and easy to use.  Very inflexible, like the waterfall
 Each phase has specific deliverables. model.
 Higher chance of success over the  Little flexibility and adjusting scope
waterfall model due to the development is difficult and expensive.
of test plans early on during the life  Software is developed during the
cycle. implementation phase, so no early
 Works well for where requirements are prototypes of the software are
easily understood. produced.
 Verification and validation of the  Model doesn’t provide a clear path
product in early stages of product for problems found during testing
development phases.
 Costly and required more time, in
addition to detailed plan
Prototyping Model
 It refers to the activity of creating prototypes of software applications, for example,

incomplete versions of the software program being developed.

 It is an activity that can occur in software development.

 It used to visualize some component of the software to limit the gap of
misunderstanding the customer requirements by the development team.
 This also will reduce the iterations may occur in waterfall approach and hard to be
implemented due to inflexibility of the waterfall approach. So, when the final prototype
is developed, the requirement is considered to be frozen.
It has some types, such as :
 Throwaway prototyping : Prototypes that are eventually discarded rather than
becoming a part of the finally delivered software
Fig. 2.1.3
 Evolutionary prototyping : prototypes that evolve into the final system through
iterative incorporation of user feedback.
Fig. 2.1.4

 Incremental prototyping : The final product is built as separate prototypes. At the end
the separate prototypes are merged in an overall design.
Fig. 2.1.5 Staged/Incremental mode of SDLC
 Extreme prototyping : Used at web applications mainly. Basically, it breaks down

web development into three phases, each one based on the preceding one. The first
phase is a static prototype that consists mainly of HTML pages. In the second phase,
the screens are programmed and fully functional using a simulated services layer. In the
third phase the services are implemented
The usage
 This process can be used with any software developing life cycle model. While this
shall be focused with systems needs more user interactions. So, the system do not have
user interactions, such as, system does some calculations shall not have prototypes.
 Reduced time and costs, but this can be  Insufficient analysis·
disadvantage if the developer loses time in  User confusion of prototype and finished
developing the prototypes· system
 Improved and increased user involvement  Developer misunderstanding of user
objectives
 Excessive development time of the
prototype
 Expense of implementing prototyping

Spiral Method (SDM)

 It is combining elements of both design and prototyping-in-stages, in an effort to
combine advantages of top-down and bottom-up concepts.
 This model of development combines the features of the prototyping model and the
waterfall model.
 The spiral model is favored for large, expensive, and complicated projects.
 This model uses many of the same phases as the waterfall model, in essentially the
same order, separated by planning, risk assessment, and the building of prototypes and
simulations.
Fig. 2.1.6
The usage
It is used in shrink-wrap large applications and systems which built-in small phases or
segments.

 Estimates (i.e. budget, schedule, etc.)  High cost and time to reach the final
become more realistic as work product.
progresses, because important issues  Needs special skills to evaluate the risks
are discovered earlier. and assumptions.
 Early involvement of developers·  Highly customized limiting re-usability
 Manages risks and develops system
into phases
Iterative and Incremental Method
 It is developed to overcome the weaknesses of the waterfall model.
 It starts with an initial planning and ends with deployment with the cyclic interactions
in between.
 The basic idea behind this method is to develop a system through repeated cycles
(iterative) and in smaller portions at a time (incremental), allowing software developers
to take advantage of what was learned during development of earlier parts or versions
of the system.
It consists of mini waterfalls
Fig. 2.1.7
The usage
It is used in shrink-wrap application and large system which built-in small phases or
segments. Also can be used in system has separated components, for example, ERP system.
Which we can start with budget module as first iteration and then we can start with inventory
module and so forth.

 Produces business value early in the  Requires heavy documentation
development life cycle  Follows a defined set of processes
 Better use of scarce resources through  Defines increments based on function and
proper increment definition· feature dependencies
 Can accommodate some change requests  Requires more customer involvement
between increments than the linear approaches
 More focused on customer value than the  Partitioning the functions and features
linear approaches might be problematic
 Problems can be detected earlier  Integration between iteration can be an
issue if this is not considered during the
development.
Rapid Application Development
 The rapid application development model emphasizes on delivering projects in small

pieces. If the project is large, it is divided into a series of smaller projects.
 Each of these smaller projects is planned and delivered individually.
 Thus, with a series of smaller projects, the final project is delivered quickly and in a
less structured manner.
 The major characteristic of the RAD model is that it focuses on the reuse of code,
processes, templates, and tools.
Fig. 2.1.8

The phases of RAD model are listed below
1. Planning : In this phase, the tasks and activities are planned. The derivables produced
from this phase are project definition, project management procedures, and a work
plan. Project definition determines and describes the project to be developed. Project
management procedure describes processes for managing issues, scope, risk,
communication, quality, and so on. Work plan describes the activities required for
completing the project.
2. Analysis : The requirements are gathered at a high level instead of at the precise set of
detailed requirements level. Incase the user changes the requirements, RAD allows
changing these requirements over a period of time. This phase determines plans for
testing, training and implementation processes. Generally, the RAD projects are small
in size, due to which high-level strategy documents are avoided.
3. Prototyping : The requirements defined in the analysis phase are used to develop a
prototype of the application. A final system is then developed with the help of the
prototype. For this, it is essential to make decisions regarding technology and the tools
required to develop the final system.
4. Repeat analysis and prototyping as necessary : When the prototype is developed, it is
sent to the user for evaluating its functioning. After the modified requirements are
available, the prototype is updated according to the new set of requirements and is again
sent to the user for analysis.
5. Conclusion of prototyping : As a prototype is an iterative process, the project manager
and user agree on a fixed number of processes. Ideally, three iterations are considered.
After the third iteration, additional tasks for developing the software are performed and
then tested. Last of all, the tested software is implemented.
6. Implementation : The developed software, which is fully functioning, is deployed at
the user's end.
RAD Strengths
 Reduced cycle time and improved productivity with fewer people means lower costs
 Time-box approach mitigates cost and schedule risk
 Customer involved throughout the complete cycle minimizes risk of not achieving
customer satisfaction and business needs
 Focus moves from documentation to code (WYSIWYG).
 Uses modeling concepts to capture information about business, data, and processes.

RAD Weaknesses
 Accelerated development process must give quick responses to the user

 Risk of never achieving closure
 Hard to use with legacy systems
 Requires a system that can be modularized
 Developers and customers must be committed to rapid-fire activities in an abbreviated
time frame.
When to use RAD
 Reasonably well-known requirements

 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized
2.1.2 Agile SDLC’s (Agile Method)
 Speed up or bypass one or more life cycle phases

 Usually less formal and reduced scope
 Used for time-critical applications
 Used in organizations that employ disciplined methods
 Based on the Manifesto for Agile Software Development
o Individuals and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan
Agile Project Management
Qualities :
 Minimize risk  short iterations

 Real-time communication (prefer face-to-face)  very little written documentation
 Indicated for unpredictable / rapidly changing requirements

2.1.2.1 Some Agile Methods
 Adaptive Software Development (ASD)

 Feature Driven Development (FDD)
 Crystal Clear
 Dynamic Software Development Method (DSDM)
 Rapid Application Development (RAD)
 Scrum
 Extreme Programming (XP)
 Rational Unify Process (RUP)
Extreme programming (Agile development)
 It is based on iterative and incremental development, where requirements and solutions
evolve through collaboration between cross-functional teams.
 For small-to-medium-sized teams developing software with vague or rapidly changing
requirements
 Coding is the key activity throughout a software project
 Communication among teammates is done with code
 Life cycle and behavior of complex objects defined in test cases – again in code
Fig. 2.1.9
The usage
It can be used with any type of the project, but it needs more involvement from
customer and to be interactive. Also, it can be used when the customer needs to have some
functional requirement ready in less than three weeks.

 Decrease the time required to avail some  Scalability
system features.  Skill of the software developers
 Face to face communication and  Ability of customer to express user
continuous inputs from customer needs
representative leaves no space for  Documentation is done at later stages
guesswork.
 Reduce the usability of components.
 The end result is the high quality
 Needs special skills for the team.
software in least possible time duration
and satisfied customer
Scrum
 A scrum is a way to restart the game after an interruption, where the forwards of each
side come together in a tight formation and struggle to gain possession of the ball when
it is tossed in among them.
 SCRUM is an agile, lightweight process for managing and controlling software and
product development in rapidly changing environments.
 Iterative, incremental process
 Team-based approach
 developing systems/ products with rapidly changing requirements
 Controls the chaos of conflicting interest and needs
 Improve communication and maximize cooperation
 Protecting the team form disruptions and impediments
 A way to maximize productivity
Fig. 2.1.10


Advantages
 Completely developed and tested features in short iterations

 Simplicity of the process
 Clearly defined rules
 Increasing productivity
 Self-organizing
 each team member carries a lot of responsibility
 Improved communication
 Combination with Extreme Programming
Drawbacks
 “Undisciplined hacking” (no written documentation)

 Violation of responsibility
 Current mainly carried by the inventors
2.2 Choice of Process Models
2.2.1 Selecting a Life Cycle Model - Project Characteristic Category Matrix

Requirements
Requirements Waterfall Prototype Spiral RAD

Are the requirements easily defined and/or well Yes No No Yes
known ?
Can the requirements be defined early in the Yes No No Yes
cycle ?
Will the requirements change often in the No Yes Yes No
cycle ?
Is there a need to demonstrate the requirements No Yes Yes Yes
to achieve definition ?
Is a proof of concept required to demonstrate No Yes Yes Yes
capability ?


Project Team
Project Team Waterfall Prototype Spiral RAD

Are the majority of team members new to the No Yes Yes No
problem domain for the project ?
Are the majority of team members new to the Yes No Yes No
technology domain for the project ?
Are the majority of team members new to the Yes No Yes No
tools used on the project ?
Are the team members subject to reassignment No Yes Yes No
during the life cycle ?
Is there training available for the project team if No No No Yes
required ?
2.2.3 Selecting a Life Cycle Model - Project Characteristic Category Matrix User
Community
User Community Waterfall Prototype Spiral RAD

Will the availability of the user representatives be Yes No Yes No
restricted, or limited during the life cycle ?
Are the user representatives new to system No Yes Yes No
definition ?
Are the user representatives experts in the problem No Yes No Yes
domain ?
Do the users want to be involved in all phases of No Yes No Yes
the life cycle ?

Project Type and Risk
Project Type and Risk Waterfall Prototype Spiral RAD

Does the project identify a new product direction No Yes Yes No
for the organization ?
Is the project a system integration project ? No Yes Yes Yes

Is the project an enhancement to an existing No No No Yes

system ?
Is the funding for the project expected to be stable Yes Yes No Yes
throughout the life cycle ?
Is the product expected to have a long life in the Yes No Yes No
organization ?
2.3 Basic of Software Estimation
 Software projects are notorius for going past their deadline, going over budget, or both.
 The problem lies in the estimation of the amount of effort required for the development
of a project.
 The cost estimation is usually dependent upon the size estimate of the project, which
may use lines of code or function points as metrics.
 There are several different techniques for performing software cost estimation,
including expert judgement and algorithmic models. Estimation by expert judgement is
a common way of estimating the effort required for a project. Unfortunately, this
method of estimation does not emphasize re-estimation during the project life cycle,
which is an important part of project tracking, because it allows the estimates to be
improved during the project life cycle.
 The quality of a cost estimation model is not so much attributed to the initial estimate,
but rather the speed at which the estimates converges to the actual cost of the project.
 COCOMO is a popular algorithmic model for cost estimation whose cost factors can be
tailored to the individual development environment, which is important for the accuracy
of the cost estimates. More than one method of cost estimation should be done so that
there is some comparison available for the estimates.
 This is especially important for unique projects. Cost estimation must be done more
diligently throughout the project life cycle so that in the future there are fewer surprises
and unforeseen delays in the release of a product.
2.4 Software Cost Estimation
 Determine size of the product.

 From the size estimate,
o Determine the effort needed.

 From the effort estimate,

o Determine project duration, and cost.
Software Cost Estimation
Fig. 2.4.1
2.4.1 Software Size Metrics

2.4.1.1 LOC (Lines of Code)
 LOC (Lines of Code) :

o Simplest and most widely used metric.
o Comments and blank lines should not be counted.
Disadvantages of using LOC
 Size can vary with coding style.

 Focuses on coding activity alone.
 Correlates poorly with quality and efficiency of code.
 Penalizes higher level programming languages, code reuse, etc.
 Measures lexical/textual complexity only.
o Does not address the issues of structural or logical complexity.
 Difficult to estimate LOC from problem description.
o So not useful for project planning
2.4.1.2 Function Point Metric
 Overcomes some of the shortcomings of the LOC metric

 Proposed by Albrecht in early 80's :
o FP = 4 #inputs + 5 #Outputs + 4 #inquiries + 10 #files + 10 #interfaces
 Input :
o A set of related inputs is counted as one input.

Function Point Metric
 Output :
o A set of related outputs is counted as one output.
 Inquiries :
o Each user query type is counted.
 Files :
o Files are logically related data and thus can be data structures or physical files.
 Interface :
o Data transfer to other systems.
 Suffers from a major drawback :
o the size of a function is considered to be independent of its complexity.
 Extend function point metric :
o Feature Point metric :
o Considers an extra parameter :
 Algorithm Complexity.
 Proponents claim :
o FP is language independent.
o Size can be easily derived from problem description
 Opponents claim :
o It is subjective --- Different people can come up with different estimates for the
same problem.
2.4.2 Software Cost Estimation Techniques
 Three main approaches to estimation :

o Empirical
o Heuristic
o Analytical
Software Cost Estimation Techniques
 Empirical techniques :
o An educated guess based on past experience.
 Heuristic techniques :

o Assume that the characteristics to be estimated can be expressed in terms of

some mathematical expression.
 Analytical techniques :
o Derive the required results starting from certain simple assumptions.
2.4.2.1 Empirical Size Estimation Techniques
 Expert Judgement :
o An euphemism for guess made by an expert.
o Suffers from individual bias.
 Delphi Estimation :
o overcomes some of the problems of expert judgement.
1. Expert judgement
 Experts divide a software product into component units :

e.g. GUI, database module, data communication module, billing module, etc.
 Add up the guesses for each of the components.
2. Delphi Estimation
 Team of Experts and a coordinator.

 Experts carry out estimation independently:
o Mention the rationale behind their estimation.
o Coordinator notes down any extraordinary rationale:
 Circulates among experts.
 Experts re-estimate.
 Experts never meet each other to discuss their viewpoints.
2.4.2.2 Heuristic Estimation Techniques
 Single Variable Model :

o Parameter to be Estimated=C1(Estimated Characteristic)d1
 Multivariable Model :
o Assumes that the parameter to be estimated depends on more than one
characteristic.
o Parameter to be Estimated = C1 (Estimated Characteristic) d1 + C2 (Estimated
Characteristic) d2 + …
o Usually more accurate than single variable models.

COCOMO Model
 COCOMO (COnstructive COst MOdel) proposed by Boehm.

 Divides software product developments into 3 categories :
o Organic
o Semidetached
o Embedded
COCOMO Product classes
 Roughly correspond to :
o Application, utility and system programs respectively.
 Data processing and scientific programs are considered to be application
programs.
 Compilers, linkers, editors, etc., are utility programs.
 Operating systems and real-time system programs, etc. are system
programs.
Elaboration of product classes
 Organic :
o Relatively small groups
 Working to develop well-understood applications.
 Semidetached :
o Project team consists of a mixture of experienced and inexperienced staff.
 Embedded :
o The software is strongly coupled to complex hardware, or real-time systems.
 For each of the three product categories :
o From size estimation (in KLOC), Boehm provides equations to predict :
o Project duration in months
o Effort in programmer-months
 Boehm obtained these equations :
o Examined historical data collected from a large number of actual projects.
 Software cost estimation is done through three stages :
o Basic COCOMO,
o Intermediate COCOMO,
o Complete COCOMO.

1. Basic COCOMO Model
 Gives only an approximate estimation :

-Effort = a1 (KLOC)a2
-Tdev = b1 (Effort)b2
 KLOC is the estimated kilo lines of source code,
 a1,a2,b1,b2 are constants for different categories of software products,
 Tdev is the estimated time to develop the software in months,
 Effort estimation is obtained in terms of person months (PMs).
Development Effort Estimation
 Organic :
- Effort = 2.4 (KLOC)1.05 PM
 Semi-detached :
- Effort = 3.0(KLOC)1.12 PM
 Embedded :
-Effort = 3.6 (KLOC)1.20PM
Development Time Estimation
 Organic :
-Tdev = 2.5 (Effort)0.38 Months
 Semi-detached :
 Embedded :
 Effort is somewhat super-linear in problem size.
Fig. 2.4.2

 Development time
- Sublinear function of product size.
Fig. 2.4.3
 When product size increases two times,

- Development time does not double.
 Time taken :
- Almost same for all the three product categories.
 Development time does not increase linearly with product size :
- For larger products more parallel activities can be identified :
 Can be carried out simultaneously by a number of engineers.
 Development time is roughly the same for all the three categories of products :
- For example, a 60 KLOC program can be developed in approximately 18 months
 Regardless of whether it is of organic, semi-detached, or embedded type.
- There is more scope for parallel activities for system and application programs,
 Than utility programs.
Example
 The size of an organic software product has been estimated to be 32,000 lines of source
code.
 Effort = 2.4*(32)1.05 = 91 PM
 Nominal development time = 2.5*(91)0.38 = 14 months
2. Intermediate COCOMO
 Basic COCOMO model assumes

- effort and development time depend on product size alone.

 However, several parameters affect effort and development time:

o Reliability requirements
o Availability of CASE tools and modern facilities to the developers
o Size of data to be handled
 For accurate estimation,
- the effect of all relevant parameters must be considered :
- Intermediate COCOMO model recognizes this fact :
 Refines the initial estimate obtained by the basic COCOMO by using a
set of 15 cost drivers (multipliers).
 If modern programming practices are used,
- initial estimates are scaled downwards.
 If there are stringent reliability requirements on the product :
- initial estimate is scaled upwards.
 Rate different parameters on a scale of one to three :
- Depending on these ratings,
 Multiply cost driver values with the estimate obtained using the basic
COCOMO.
 Cost driver classes :
- Product : Inherent complexity of the product, reliability requirements of the
product, etc.
o Computer : Execution time, storage requirements, etc.
o Personnel : Experience of personnel, etc.
o Development Environment : Sophistication of the tools used for software
development.
Shortcoming of basic and intermediate COCOMO models
 Both models :
- Consider a software product as a single homogeneous entity:
- However, most large systems are made up of several smaller sub-systems.
 Some sub-systems may be considered as organic type, some may be
considered embedded, etc.
 for some the reliability requirements may be high, and so on.

3. Complete COCOMO
 Cost of each sub-system is estimated separately.

 Costs of the sub-systems are added to obtain total cost.
 Reduces the margin of error in the final estimate.
Complete COCOMO Example
 A Management Information System (MIS) for an organization having offices at
several places across the country :
- Database part (semi-detached)
- Graphical User Interface (GUI) part (organic)
- Communication part (embedded)
 Costs of the components are estimated separately :
- summed up to give the overall cost of the system.
2.4.2.3 Analytical Technique
Halstead's Software Science
 An analytical technique to estimate :

- size,
- development effort,
- development time.
 Halstead used a few primitive program parameters
- number of operators and operands
 Derived expressions for :
- over all program length,
- potential minimum volume
- actual volume,
- language level,
- effort, and
- development time.
2.4.3 Staffing Level Estimation
 Number of personnel required during any development project :

- not constant.

 Norden in 1958 analyzed many R&D projects, and observed :

- Rayleigh curve represents the number of full-time personnel required at any time.
2.4.3.1 Rayleigh Curve
 Rayleigh curve is specified by two parameters :
Fig. 2.4.4
o td the time at which the curve reaches its maximum

o K the total area under the curve.
 L = f(K, td)
2.4.3.2 Putnam’s Work
 In 1976, Putnam studied the problem of staffing of software projects :

- observed that the level of effort required in software development efforts has a
similar envelope.
- found that the Rayleigh-Norden curve
 relates the number of delivered lines of code to effort and development time.
 Putnam analyzed a large number of army projects, and derived the expression :
L=CkK1/3td4/3
- K is the effort expended and L is the size in KLOC.
o td is the time to develop the software.
o Ck is the state of technology constant
 reflects factors that affect programmer productivity.
 Ck=2 for poor development environment
- no methodology, poor documentation, and review, etc.

 Ck=8 for good software development environment

- software engineering principles used
 Ck=11 for an excellent environment
Rayleigh Curve
 Very small number of engineers are needed at the beginning of a project

- carry out planning and specification.
 As the project progresses :
- more detailed work is required,
- number of engineers slowly increases and reaches a peak.
 Putnam observed that :
- the time at which the Rayleigh curve reaches its maximum value
 corresponds to system testing and product release.
- After system testing,
 the number of project staff falls till product installation and delivery.
 From the Rayleigh curve observe that :
- approximately 40 % of the area under the Rayleigh curve is to the left of td
- and 60 % to the right.
Effect of Schedule Change on Cost
 Using the Putnam's expression for L,

K=L3/Ck3td4
Or, K=C1/td4
 For the same product size, C1=L3/Ck3 is a constant.
 Or, K1/K2 = td24/td14
 Observe :
- a relatively small compression in delivery schedule
 can result in substantial penalty on human effort.
 Also, observe :
- benefits can be gained by using fewer people over a somewhat longer time span.
Example
 If the estimated development time is 1 year, then in order to develop the product in
6 months,
- the total effort and hence the cost increases 16 times.

o In other words,
 the relationship between effort and the chronological delivery time is
highly nonlinear.
 Putnam model indicates extreme penalty for schedule compression
- and extreme reward for expanding the schedule.
 Putnam estimation model works reasonably well for very large systems,
- but seriously overestimates the effort for medium and small systems.
 Boehm observed :
- “There is a limit beyond which the schedule of a software project cannot be
reduced by buying any more personnel or equipment.”
- This limit occurs roughly at 75% of the nominal time estimate.
 If a project manager accepts a customer demand to compress the development time by
more than 25 %
- very unlikely to succeed.
 every project has only a limited amount of parallel activities
 sequential activities cannot be speeded up by hiring any number of additional
engineers.
 many engineers have to sit idle.
2.4.3.3 Jensen Model
 Jensen model is very similar to Putnam model.

o attempts to soften the effect of schedule compression on effort
o makes it applicable to smaller and medium sized projects.
 Jensen proposed the equation:
o L=CtetdK1/2
o Where,
 Cte is the effective technology constant,
 td is the time to develop the software, and
 K is the effort needed to develop the software.

2.5 Effort Estimation
 Estimating
- The process of forecasting or approximating the time and cost of completing project
deliverables.
- The task of balancing the expectations of stakeholders and the need for control
while the project is implemented
 Types of Estimates
- Top-down (macro) estimates : analogy, group consensus, or mathematical
relationships
- Bottom-up (micro) estimates : estimates of elements of the work breakdown
structure
 Top down/Macro estimates : derived from experience to estimate project duration and
total cost. Could be made by a manager with no direct experience of the processes to
complete the project.
 Bottom Up/Micro estimates : require more effort to develop & rely upon those who
understand the work to estimate specific work activities.
2.5.1 Macro Versus Micro Estimating
Conditions for Preferring Top-Down or Bottom-up Time and Cost Estimates

Condition Macro Estimates Micro Estimates
Strategic decision making 
Cost and time important 
High uncertainty 
Internal, small project 
Fixed-price contract 
Customer wants details 
Unstable scope 
2.5.2 Estimating Projects : Preferred Approach
 Make rough top-down estimates.

 Develop the WBS/OBS.
 Make bottom-up estimates.

 Develop schedules and budgets.

 Reconcile differences between top-down and bottom-up estimates
2.5.3 Estimating Guidelines for Times, Costs, and Resources
1. Have people familiar with the tasks make the estimate.

2. Use several people to make estimates.
3. Base estimates on normal conditions, efficient methods, and a normal level of
resources.
4. Use consistent time units in estimating task times.
5. Treat each task as independent, don’t aggregate.
6. Don’t make allowances for contingencies.
7. Adding a risk assessment helps avoid surprises to stakeholders.
2.5.4 Refining Estimates
 Reasons for Adjusting Estimates

- Interaction costs are hidden in estimates.
- Normal conditions do not apply.
- Things go wrong on projects.
- Changes in project scope and plans.
 Adjusting Estimates
- Time and cost estimates of specific activities are adjusted as the risks, resources,
and situation particulars become more clearly defined.
 Contingency Funds and Time Buffers
- Are created independently to offset uncertainty.
- Reduce the likelihood of cost and completion time overruns for a project.
- Can be added to the overall project or to specific activities or work packages.
- Can be determined from previous similar projects.
 Changing Baseline Schedule and Budget
- Unforeseen events may dictate a reformulation of the budget and schedule.
2.5.5 Methods for Estimating Project Times and Costs
 Macro (Top-down) Approaches

- Consensus methods
- Ratio methods

- Apportion method
- Function point methods for software and system projects
- Learning curves
Apportion Method of Allocating Project Costs Using the Work Breakdown Structure
Fig. 2.5.1
 Micro (Bottom-up) Approaches

- Template method
- Parametric Procedures Applied to Specific Tasks

- Detailed Estimates for the WBS Work Packages

- Phase Estimating : A Hybrid
Fig. 2.5.2
2.5.6 Duration vs. Effort vs. Productive Time
 Duration is the elapsed time in business working days

 Work effort is the labor required to complete an activity. Work effort is typically the
amount of focused and uninterrupted labor time required to complete an activity.
 Productive time considers the percentage of the work day that can be devoted to project
activity work. Estimates in IT range from 66-75 %, recent estimates of about 50-65 %
(same client base). This doesn’t include unexpected interruptions!
Elapsed time vs. work time
Fig. 2.5.3

2.5.7 Basic Steps in Software Estimation
 Identify project objectives and requirements

 Plan the activities
 Estimate product size and complexity
 Estimate effort, cost and resources
 Develop projected schedule
 Compare and iterate estimates
 Follow up
2.5.7.1 Basic Algorithmic Form
Effort = constant + coefficient*(size metric)

+ coefficient*(cost driver 1) + coefficient*(cost driver 2)
+ coefficient*(cost driver 3) + …..
size metric lines of code
‘new’ versus ‘old’ lines of code
function points
2.5.7.2 SLOC as an Estimation Tool
 Why used ?
- early systems emphasis on coding
 Criticisms
- cross-language inconsistencies
- within language counting variations
- change in program structure can affect count
- stimulates programmers to write lots of code
- system-oriented, not user-oriented
2.5.8 Function Count Systems View : Functionality Types

2.5.8.1 Function Points

History
 Non-code oriented size measure

 Developed by IBM (A. Albrecht) in 1979, 1983
 Now in use by more than 500 organizations world-wide
What are they ?
 5 weighted functionality types

 14 complexity factors
2.5.8.2 Functionality Types
Fig. 2.5.4
2.5.8.3 Processing Complexity Adjustment
1) data communications
2) distributed functions Each rated on scales equivalent to the following :
3) performance Not present =0
4) heavily used configuration Incidental Influence =1
5) transaction rate Moderate Influence =2
6) on-line data entry Average Influence =3
7) end user efficiency Significant Influence =4
8) on-line update Strong Influence =5
9) complex processing

10) reusability
11) installation ease
12) operational ease
13) multiple sites
14) facilitates change
2.5.8.4 Function Point Calculation
5 3
Function Counts = FC =   xi wj
i=1j=1
  14 
Function Points = FP = FC .65 + .01   Ck

  
 k=1 
where
xi = function i
wj = weight j
ck = complexity factor k
Example - Employee-Job database
 Need to track employees and their work

- Add, change, delete, queries, and reports
- Two types of employees, salaried and hourly
 Employees can have more than one job assignment
 Standard job descriptions are retained by system
 Employees can have more than one location and locations can have more than one
employee
- Another system stores the location data
2.5.8.5 Detailed Function Point Counting Rules
(1) Internal Logical Files (ILFs) Rules :
- Each major logical group of user data or control information

- Data is generated, used and maintained by the application
In Practice :
- Count at logical (external design) level

- In DB environment generally a relational table = a logical file (before extensive

normalization)
- Ignore multiple views
(2) External Interface Files (EIFs) Rules :
- Files passed or shared between applications

- Reference data only (not transactions)
In Practice :
- Look for “read only” usage
- Count special database extracts
Example - ILFs and EIFs
 Employee - entity type
- Employee name
- SSN
- Number of dependents
- Type (salary or hourly)
- Location name (foreign key)
 Salaried employee - entity subtype
- Supervisory level
 Hourly employee - entity subtype
- Standard Hourly rate
- Collective Bargaining Unit Number
 Job - entity type
- Job name
- Job number
- Pay grade
 Job Assignment - entity type
- Effective Date
- Salary
- Performance Rating
- Job Number (foreign key)
- Employee SSN (foreign key)

 Job Description
- Job Number (foreign key)
- Line number (not known to users)
- Description line
 Location - entity --maintained in another system
- Location Name
- Address
- Employee SSN (foreign key)
 COUNTING STEPS :
- Count number of ILFs and EIFs
- Assign them a complexity weighting
Counting ILFs and EIFs
 Three ILFs :
- Employee
- Job
- Job Assignment
- not Job Description (logically part of Job)
- not Location (an EIF)
- not Salaried Employee (a Record Element Type)
- not Hourly Employee (a Record Element Type)
 One EIF :
- Location
Counting ILFs/EIFs – Complexity
Record element types (RETs) Data Element Types (DETs)
1-19 20-50 51+
<2 Low Low Average
2-5 Low Average High
>5 Average High High
Three ILFs :
 Employee - 8 DETs and 2 RETs
 Job - 4 DETs and 1 RET

 Job Assignment - 5 DETs and 1 RET

One EIF : Location - 3 DETs and 1 RET
ILF and EIF Unadjusted FPs
Low Average High
External
_x3 _x4 _x6
Input
External
_x4 _x5 _x7
Output
Logical
Internal 3_x7 _x10 _x15
File
External
Interface 1_x5 _x10 _x10
File
External
_x3 _x7 _x6
Inquiry
(3) External Inputs (EIs) Rules :
 Each unique user data/control type that enters application

 Adds/Changes/Deletes data in Internal logical file
 Each transaction type is an external input
In Practice :
 Not necessarily equal to screens
 Don’t confuse with inquiries (no change to data)
Counting EIs - Raw Data
 Employee Maintenance
o Add, change, delete Employee
o Employee Inquiry; Employee Report
Job Maintenance
o Add, change, delete Job
o Job Inquiry; Job Report

Job Assignment Maintenance

- Assign Employee to Job
- Job Assignment Inquiry; Job Assignment Report
- Transfer Employee
- Evaluate Employee
- Delete Assignment
 Location Reporting
- Location Inquiry; Location Report
Counting EIs - Complexity
File Types
Referenced Data Element Types (DETs)
(FTRs)
1-4 5-15 +15
<2 Low Low Average
2 Low Average High
Example EIs (3 of 10) :
 Create Employee- 10 DETs, 2FTRs (Employee and Location) => Average
 Delete Employee- 3 DETs and 1 FTR=> Low
 Assign Employee to Job - 6 DETs and 3 FTRs (Employee, Job and Job
Assignment)=> High
External Input (EI) Unadjusted FPs
Low Average High
External x3 x4 x6
–6 –2 –2
Input
External _x4 _x5 _x7
Output
Logical _x7 _x10 _x15
Internal
File


Interface
File
Inquiry
(4) External Outputs (EOs) Rules :
- Each unique user data/control type that exits application

- Unique means different format or processing logic
- Can be sent directly to users as reports/messages, or to other applications as a file
In Practice :
 Processing must be involved (don’t count output response to an inquiry)
 Detail and summary outputs count separately
Counting EOs - Raw Data
- Add, change, delete Employee
- Employee Inquiry; Employee Report - 6-19 DETs
Job Maintenance
- Add, change, delete Job
- Job Inquiry; Job Report- 5 DETs
- Assign Employee to Job
- Job Assignment Inquiry; Job Assignment Report
- Transfer Employee
- Evaluate Employee
- Delete Assignment
- Location Inquiry; Location Report- 6-19DETs

Counting EOs – Complexity

File Types
Referenced Delta Element Types (DETs)
(FTRs)
1-5 6-19 20+
<2 Low Low Average
2-3 Low Average High
Example EOs :
 Employee Report- 6-19 DETs, 2FTRs (Employee and Location) => Average
 Job Report-5 DETs and 1 FTR=> Low
 Job Assignment Report - 6-19 DETs, 3 FTRs (Employee, Job and
Job Assignment)=> Average
External Output Unadjusted FPs
Low Average High
Input
External 1_x4 3_x5 _x7
Output
Internal
File
Interface
File
Inquiry
(5) External Inquiry (EQ) Rules :
 Each unique input/output combination where an input causes and generates an

immediate output

 Unique means different format or processing logic

In Practice :
 No processing involved. If result is calculated or derived field, then it is an input
and an output
 Help systems typically counted as external inquiry
 Rate complexity as the higher of the input/output value
2.5.8.6 Counting EQs - “Medium Cooked” Data
- Employee Inquiry- 2 FTRs and 9 DETs (output)
Job Maintenance
- Job Inquiry - 1 FTR and 4 DETs (output)
- Job Assignment Inquiry- 1 FTR and 5 DETs (output)
- Location Inquiry - 2 FTRs and 5 DETs (output)
RESULT - Use EI and EO matrices => 3 low complexity and 1 average (employee)
EQ Unadjusted FPs
Low Average High

Input
Output
Internal
File
Interface
File
Inquiry

Total Unadjusted Function Points
Low Average High

External 6_x3 2_x4 2_x6
Input
Output
Logical 3_x7 _x10 _x15
Internal
File
External 1_x5 _x7 _x10
Interface
File
Inquiry
Total = 96 Unadjusted FPs
2.5.8.7 Are Function Points a “Silver Bullet”?
“The function-point metric, like LOC, is relatively controversial...Opponents claim that

the method requires some ‘sleight of hand’ in that computation is based on subjective, rather
than objective, data...”
"Variants in FP counting methodologies can result in variances of up to +/– 50%.“
“Within organizations the variation in function point counts about the mean appears to
be within 30 %...”
2.5.8.8 Software Estimating Rules of Thumb
 Rule 1 : One function point = 100 logical source code statements (procedural
languages)
 300 for assembly languages, < 20 for some OO languages
 Rule 2 : Raising the number of function points to the 1.15 power predicts the
approximate page counts for paper documents associated with software projects
 Rule 3 : Creeping user requirements will grow at an average rate of 1 % per months
over the development schedule

o For a 2 year project, functionality at delivery will be 24% larger then when
requirements were collected.
 Rule 4 : Raising the number of function points to 1.2 power predicts the approximate
number of test cases created.
- Assume each test case will be executed about 4 times
 Rule 5 : Raising the number of function points to the 1.25 power predicts the
approximate defect potential for new software projects
- Defect potential is sum of bugs (errors) in requirements, design, coding, user-
documentation + bad fixes or secondary errors introduced fixes prior errors.
- For enhancements: raise to 1.27 power
 Rule 6 : Each software review, inspection, or test step will find and remove 30 % of the
bugs that are present
- Implies 6 - 12 consecutive defect-removal operations to achieve high-quality
software
 Rule 7 : Raising the number of function points to the .4 power predicts the approximate
development schedule in calendar months.
- Longer for military projects; for enhancements applies to size of enhancement (not
base product)
 Rule 8 : Dividing the number of function points by 150 predicts the approximate
number of personnel for the application
- Includes software developers, QA, testers, technical writers, DBAs, project
managers
 Rule 9 : Dividing the number of function points by 500 predicts the approximate
number of maintenance personnel
- Raising function point to .25 power predicts approximate number of years the
application will stay in use
 Rule 10 : Multiply software development schedules by number of personnel to predict
the approximate number of staff months of effort.
- 1000 function points raised to .4 = 16 calendar months
- 1000 function points / 150 = 6.6 full time staff
- 16 * 6.6 = 106 staff months to build project
 Staff month : 22 working days with 6 productive work hours each day
 132 work hours per month

2.6 COCOMO II
COCOMO II was published in 1997 and is an updated model that addresses the
problems with COCOMO 81. The main objectives of COCOMO II were set out when it was
first published. They are :
 To develop a software cost and schedule estimation model tuned to the life cycle
practices of the 1990's and 2000's.
 To develop software cost database and tool support capabilities for continuous model
improvement.
 To provide a quantitative analytic framework, and set of tools and techniques for
evaluating the effects of software technology improvements on software life cycle costs
and schedules.
For the most part estimates are obtained in pretty much the same way as COCOMO
81. The main changes have been in the number and type of cost drivers and the calculation of
equation variables rather than the use of constants. The equations still use lines of code as
their main metric; you can however also using function points and object points to do
estimates. The line of code metric used is now the LOC. There are standards set out by SEI
for proper counting of lines, things like if/then/else statements would be counted as one line
(there are automated tools that will do the counting for you when you want to collect data
from your own code).
2.6.1 COCOMO II Models
COCOMO II again has three models, but they are different from the ones for
COCOMO 81. They are :
 Application Composition Model – this would be used for projects built using rapid
application development tools. Normally you would use object points for size
estimates. It “involves prototyping efforts to resolve potential high-risk issues such as
user interfaces, software/system interaction, performance, or technology maturity.”
 Early Design Model – This model can provide you with estimates early in a projects
design before the entire architecture has been decided on. Normally you would use
function points as a size estimate. It “involves exploration of alternative
software/system architectures and concepts of operation. At this stage, not enough is
generally known to support fine-grain cost estimation.”
 Post-Architecture Model – The most detailed on the three, used after the overall
architecture for the project has been designed. You could use function points or LOC’s

for size estimates. It “involves the actual development and maintenance of a software
product” .
2.6.2 Cost Drivers
In COCOMO II there are 17 cost drivers that are used in the Post-Architecture
model. They are used in the same way as in COCOMO 81 to calculate the EAF. The cost
drivers are not the same ones as in COCOMO 81; they are better suited for the software
development environment on the 1990’s and 2000’s. They are grouped together as shown in
table 3. The cost drivers for COCOMO II are again rated on a scale from Very Low to Extra
High in the same was as in COCOMO 81.
List of COCOMO II’s Cost Drivers.
Product Factors RELY- Required Software Reliability

DATA - Data Base Size
CPLX - Product Complexity
RUSE - Required Reusability
DOCU - Documentation match to life-cycle needs
Platform Factors TIME - Execution Time Constraint
STOR - Main Storage Constraint
PVOL - Platform Volatility
Personnel Factors ACAP - Analyst Capability
PCAP - Programmer Capability
AEXP - Applications Experience
PEXP - Platform Experience
LTEX - Language and Tool Experience
PCON - Personnel Continuity
Project Factors TOOL - Use of Software Tools
SITE - Multisite Development
SCED - Required Development Schedule

2.6.3 Calibration
For a COCOMO model to be accurate it must be calibrated using historical

data. COCOMO 81 was calibrated using 63 data points from past projects. The calibration
process can be done by using a company’s own data, but for the most part it requires more
data than a single company would have. The calibration involves doing a statistical analysis
on the data and then adjusting all cost driver values.
Because of the need of a proper calibration there are standard calibrations
released. COCOMO II has gone through two calibrations, COCOMO II.1997 and COCOMO
II.1998. COCOMO II.1997 was based on 83 data points and was found that it only could
come within 20 % of the actual values 46 % of the time. The COCOMO II.1998 calibration
was found to come within 30% of the actual values 75 % of the time, this calibration was
based on 161 data points . Users can also submit data from their own projects to be used in
future calibrations. When using the release calibrations or your own it is important to
continue collecting historical data so it can be use to further increase the accuracy of your
estimation results in the future.
2.7 Systems Development Life Cycle
 The systems development life cycle (SDLC), also referred to as the application
development life-cycle, is a term used in systems engineering, information
systems and software engineering to describe a process for planning, creating, testing,
and deploying an information system.
 The systems development life-cycle concept applies to a range of hardware and
software configurations, as a system can be composed of hardware only, software only,
or a combination of both.
Fig. 2.7.1
 A systems development life cycle is composed of a number of clearly defined and

distinct work phases which are used by systems engineers and systems developers to
plan for, design, build, test, and deliver information systems.

 Like anything that is manufactured on an assembly line, an SDLC aims to produce

high-quality systems that meet or exceed customer expectations, based on customer
requirements, by delivering systems which move through each clearly defined phase,
within scheduled time frames and cost estimates.
 Computer systems are complex and often (especially with the recent rise of service-
oriented architecture) link multiple traditional systems potentially supplied by different
software vendors.
 To manage this level of complexity, a number of SDLC models or methodologies have
been created, such as "waterfall"; "spiral"; "Agile software development"; "rapid
prototyping"; "incremental"; and "synchronize and stabilize".[4]
 SDLC can be described along a spectrum of agile to iterative to sequential. Agile
methodologies, such as XP and Scrum, focus on lightweight processes which allow for
rapid changes (without necessarily following the pattern of SDLC approach) along the
development cycle.
 Iterative methodologies, such as Rational Unified Process and dynamic systems
development method, focus on limited project scope and expanding or improving
products by multiple iterations.
 Sequential or big-design-up-front (BDUF) models, such as waterfall, focus on complete
and correct planning to guide large projects and risks to successful and predictable
results. Other models, such as anamorphic development, tend to focus on a form of
development that is guided by project scope and adaptive iterations of feature
development.
 In project management a project can be defined both with a project life cycle (PLC) and
an SDLC, during which slightly different activities occur. According to Taylor (2004),
"the project life cycle encompasses all the activities of the project, while the systems
development life cycle focuses on realizing the product requirements".
 SDLC is used during the development of an IT project, it describes the different stages
involved in the project from the drawing board, through the completion of the project.
Phases
 The system development life cycle framework provides a sequence of activities for
system designers and developers to follow.
 It consists of a set of steps or phases in which each phase of the SDLC uses the results
of the previous one.

 The SDLC adheres to important phases that are essential for developers, such
as planning, analysis, design, and implementation, and are explained in the section
below.
 It includes evaluation of present system, information gathering, feasibility study and
request approval. A number of SDLC models have been created : waterfall, fountain,
spiral, build and fix, rapid prototyping, incremental, synchronize and stabilize.
 The oldest of these, and the best known, is the waterfall model: a sequence of stages in
which the output of each stage becomes the input for the next. These stages can be
characterized and divided up in different ways, including the following :
o Preliminary analysis : The objective of phase 1 is to conduct a preliminary
analysis, propose alternative solutions, describe costs and benefits and submit a
preliminary plan with recommendations.
o Systems analysis, requirements definition : Defines project goals into defined
functions and operation of the intended application. It is the process of gathering
and interpreting facts, diagnosing problems and recommending improvements to
the system. Analyzes end-user information needs and also removes any
inconsistencies and incompleteness in these requirements.
A series of steps followed by the developer are :
1. Collection of Facts : End user requirements are obtained through documentation, client
interviews, observation and questionnaires,
2. Scrutiny of the existing system : Identify pros and cons of the current system in-place,
so as to carry forward the pros and avoid the cons in the new system.
3. Analyzing the proposed system : Solutions to the shortcomings in step two are found
and any specific user proposals are used to prepare the specifications.
 Systems design : Describes desired features and operations in detail, including screen
layouts, business rules, process diagrams, pseudo code and other documentation.
 Development : The real code is written here.
 Integration and testing : Brings all the pieces together into a special testing
environment, then checks for errors, bugs and interoperability.
 Acceptance, installation, deployment : The final stage of initial development, where
the software is put into production and runs actual business.
 Maintenance : During the maintenance stage of the SDLC, the system is assessed to
ensure it does not become obsolete. This is also where changes are made to initial
software. It involves continuous evaluation of the system in terms of its performance.

 Evaluation : Some companies do not view this as an official stage of the SDLC, while
others consider it to be an extension of the maintenance stage, and may be referred to in
some circles as post-implementation review. This is where the system that was
developed, as well as the entire process, is evaluated. Some of the questions that need to
be answered include: does the newly implemented system meet the initial business
requirements and objectives ? Is the system reliable and fault-tolerant? Does the system
function according to the approved functional requirements? In addition to evaluating
the software that was released, it is important to assess the effectiveness of the
development process. If there are any aspects of the entire process, or certain stages,
that management is not satisfied with, this is the time to improve. Evaluation and
assessment is a difficult issue. However, the company must reflect on the process and
address weaknesses.
 Disposal : In this phase, plans are developed for discarding system information,
hardware and software in making the transition to a new system. The purpose here is to
properly move, archive, discard or destroy information, hardware and software that is
being replaced, in a manner that prevents any possibility of unauthorized disclosure of
sensitive data. The disposal activities ensure proper migration to a new system.
Particular emphasis is given to proper preservation and archival of data processed by
the previous system. All of this should be done in accordance with the organization's
security requirements. (See Fig. 2.7.2on next page).
Not every project will require that the phases be sequentially executed. However, the
phases are interdependent. Depending upon the size and complexity of the project, phases may
be combined or may overlap.
Q.1 Explain the phases in systems development Life cycle (SDLC) ?

Q.2 Give some units for measuring the size of the software. (Refer section 2.4.1)
May- 2014 .

Fig. 2.7.2 Systems Development Life Cycle (SDLC) Life-Cycle Phases
Project Life Cycle and Effort Estimation ends....

Activity Planning and Risk Management
+
Unit - III
Chapter - 3
ACTIVITY PLANNING AND RISK MANAGEMENT
Syllabus : Objectives of Activity planning - Project schedules - Activities - Sequencing

and scheduling - Network Planning models - Forward Pass & Backward Pass
techniques - Critical path (CRM) method - Risk identification - Assessment -
Monitoring - PERT technique - Monte Carlo simulation - Resource Allocation
- Creation of critical patterns - Cost schedules.

3.1 Introduction 3-2
3.2 Project Schedule 3-3
3.3 Various Approaches Towards Identifying Activity 3-5
3.4 Planning, Sequencing and Scheduling the Activities 3-8
3.5 Scheduling Techniques 3 - 12
3.6 Network Planning Models 3 - 15
3.7 Risk and Risk Management Process 3 - 33
3.8 Monte Carlo Simulation 3 - 53
3.9 Resource Allocation 3 - 59
3.10 Cost Scheduling 3 - 63
3.11 A Summary or Hammock Activity 3 - 64

3.1 Introduction
Project Vs Activity
 A project is composed of a number of related activities.

 A project may start when at least one of its activities is ready to start.
 A project will be completed when all of its activities have been completed.
 An activity must have a clear start and a clear stop.
 An activity should have a duration that can be forecasted.
 Some activities may require that other activities are completed before they can begin.
3.1.1 Activity Planning
 A project plan is a schedule of activities indicating the start and stop for each activity
 Also provide the project and resource schedules
 The start and stop of each activity should be visible and easy to measure
 Each activity should have some ‘deliverables’ for ease of monitoring
 During planning, managers consider :
o Resource available : Make sure the resources are there when needed.
o Resource allocation : Make sure there are no competing resources.
o Staff responsibility : Schedule showing which staff carry out each activity
o Project Monitoring : Measure the actual achievement.
o Cash flow forecasting : Produce a timed cash flow forecast.
o Re-planning of the project towards the pre-defined goal : Re-plan the project so
that it will correct drift from the target.
3.1.2 Objectives of Activity Planning
Once a detailed activity plan is finished, it can be used to achieve the following :
 Feasibility assessment : Can the project be delivered on time and within budget
(constraints) ?
 Resources allocation :
o How to allocate the resources with best results ?
o When should those resources be ready ?
 Detailed costing :
o A detailed estimates on the project cost and the timings.
o A detailed forecast on when the expenditure is likely to take place.

 Motivation :
o Providing targets and being able to monitor the achievement of the targets at the
end of the activity can be a good strategy to motivate staff.
 Co-ordination :
o Help to set the time and requirements of staff from different departments to work
together in the project, if necessary.
o Provide a good way for the project teams to communicate, cooperate and
collaborate among themselves.
3.1.3 Different Levels of Plans
 Project Schedule : A plan that shows

1. the dates when each activity should start and stop
2. when and how much of the resources will be required
 Activity Plan : A plan that describes
1. how each activity will be undertaken
2. the activity plan is done in steps 4 and 5 of step Wise framework.
3.2 Project Schedule

 The project schedule is the core of the project plan.
 It is used by the project manager to commit people to the project and show the
organization how the work will be performed.
 Schedules are used to communicate final deadlines and, in some cases, to determine
resource needs. They are also used as a kind of checklist to make sure that every task
necessary is performed. If a task is on the schedule, the team is committed to doing it.
 In other words, the project schedule is the means by which the project manager brings
the team and the project under control.
 A project schedule designates work to be done and specifies deadlines for completing
tasks and deliverables. The project schedule depicts :
o Time (duration) estimates for all project tasks
o Start and finish dates for the tasks
o Names of staff resources assigned to complete the tasks
o Sequence of tasks
 A major component of a project schedule is a Work Breakdown Structure (WBS). The
project schedule is constructed to reflect the work breakdown structure.

Work Breakdown Structure :
 Work Breakdown Structure (WBS) provides a notation for representing task structure :
o Activities are represented as nodes of a tree.
o The root of the tree is labelled by the problem name.
o Each task is broken down into smaller tasks and represented as children nodes.
 It is not useful to subdivide tasks into units which take less than a week or two to
execute.
o Finer subdivisions mean that a large amount of time must be spent on estimating
and chart revision.
Fig. 3.2.1
3.2.1 Building the Project Schedule
Various steps for building a project schedule :
Step One : Define Activities
 The goal of the activity definition step is to identify all the tasks required to accomplish
the product. This frequently results in identifying all the work products and deliverables
that comprise the project. These deliverables are found as the components of a Work
Breakdown Structure (WBS). The project schedule further decomposes these
deliverables into the actual activities required to complete the work.
Step Two : Sequence Activities
 The next step is to sequence the activities with dependencies. During this step, identify
dependencies of related tasks and document them in the project schedule.
Step Three : Estimate Activity Resources
 The next step is to identify the resources and their availability to the project. Remember
that not all team members will be 100 % available to the project as some team members
will be working on multiple projects. In this step, also assign resources to each of the
tasks.

Step Four : Estimate Activity Durations
 With resources assigned, the next step is to estimate each task's duration. The activity's
duration is the number of working periods required to complete the task.
Step Five : Develop Schedule
 The next step is to analyse the project schedule and examine the sequences, durations,
resources and inevitable scheduling constraints. The goal of this step is to validate the
project schedule correctly models the planned work.
3.3 Various Approaches Towards Identifying Activity
 Activity-based approach
 Product-based approach
 Hybrid approach
3.3.1 Activity-Based Approach
 Creating a list of activities that the project is thought to involve. This includes
brainstorming from team members and analysis of past projects.
 For a large software project, it is good to subdivide the project into the main life cycle
phases and list the activities accordingly.
 Use Work Breakdown Structure (WBS) to generate a task list.
 WBS involves
o identifying the main tasks.
o break each main task down into subtasks.
o the subtasks can further be broken down into lower level tasks.
Fig. 3.3.1 Work breakdown structure (an extract)

Advantages
 More likely to obtain a task catalogue that is complete and is composed of

non-overlapping tasks.
 WBS represents a structure that can be refined as the project proceeds.
 The structure already suggests the dependencies among the activities.
Disadvantage
 Very likely to miss some activities if an unstructured activity list is used

3.3.2 Product-Based Approach
 Product Breakdown Structure (PBS)
o To show how a system can be broken down into different products for
development.
 Product Flow Diagram (PFD)
o To indicate, for each product, which products are required as ‘inputs’.
Advantage
 Less likely to miss a product unexpectedly from a PBS

Example
Fig. 3.3.2 A product breakdown structure (an extract)
3.3.3 Hybrid Approach
 A mix of the activity-based approach and the product-based approach.

 More commonly used approach.

 The WBS consists of
o a list of the products of the project; and
o a list of activities for each product
 The degree to which the structuring is based on the product or the activity largely
depends on the nature of the project and the particular development method.
Fig. 3.3.2
 IBM in its MITP methodology suggests 5 levels
Level 1 : Project
Level 2 : Deliverables (software, manuals etc.)
Level 3 : Components
Level 4 : Work-packages
Level 5 : Tasks (individual responsibility)
 MITP : Managing the Implementation of Total Project
 Components : Key work items lead to the production of the deliverables
 Work-packages : Major work items or collection of related tasks to produce a
component

3.4 Planning, Sequencing and Scheduling the Activities
 Once we have a project plan (or, project schedule), we need to schedule the activities in
a project taking into account the resource constraints.
Sequencing and Scheduling Activities
 A scheduling is required for every activity that is planned along with the resources and
can be represented using a bar chart.
 A scheduling clearly indicates when each of the project’s activities is planned to occur
and what resources it will need.
 The scheduling has taken an account of the availability of staff and the ways in which
the activities have been allocated to them.
 The chart defines two factors,
o Sequencing of tasks
o Schedule of task
 The logical relationship between the activities are grouped together and then scheduled
for resources.
Weeks 1 2 3 4 5 6 7 8 9
Person
Requirements
Design
Module 1
Design
Module 2
Code
Module 1
Code
Module 2
Integration
System
Acceptance
Fig. 3.4.1 Bar cart representing scheduling

Two activities
 To sequence the tasks according to their logical relationships.

 To schedule them taking into account resources and other factors.
 Combining sequencing - scheduling approach is suitable only for smaller projects and
needs to be separated for complex projects as individual process.
Approaches
 Separation between the logical and the physical use networks to model the project.
3.4.1 Project Scheduling
 On large projects, hundreds of small tasks must occur to accomplish a larger goal.
o Some of these tasks lie outside the mainstream and may be completed without
worry of impacting on the project completion date.
o Other tasks lie on the critical path; if these tasks fall behind schedule, the
completion date of the entire project is put into jeopardy.
 Project manager's objectives :
o Define all project tasks.
o Build an activity network that depicts their interdependencies.
o Identify the tasks that are critical within the activity network.
o Build a timeline depicting the planned and actual progress of each task.
o Track task progress to ensure that delay is recognized "one day at a time".
o To do this, the schedule should allow progress to be monitored and the project to be
controlled.
 Software project scheduling distributes estimated effort across the planned project
duration by allocating the effort to specific tasks.
 During early stages of project planning, a macroscopic schedule is developed
identifying all major process framework activities and the product functions to which
they apply.
 Later, each task is refined into a detailed schedule where specific software tasks are
identified and scheduled.
 Scheduling for projects can be viewed from two different perspectives.
o In the first view, an end-date for release of a computer-based system has already
been established and fixed
o The software organization is constrained to distribute effort within the prescribed
time frame

o In the second view, assume that rough chronological bounds have been discussed
but that the end-date is set by the software engineering organization
o Effort is distributed to make best use of resources and an end-date is defined after
careful analysis of the software
o The first view is encountered far more often that the second
3.4.2 Basic Principles for Project Scheduling
 Compartmentalization
o The project must be compartmentalized into a number of manageable activities,
actions, and tasks; both the product and the process are decomposed.
 Interdependency
o The interdependency of each compartmentalized activity, action, or task must be
determined.
o Some tasks must occur in sequence while others can occur in parallel.
o Some actions or activities cannot commence until the work product produced by
another is available.
 Time allocation
o Each task to be scheduled must be allocated some number of work units.
o In addition, each task must be assigned a start date and a completion date that are a
function of the interdependencies.
o Start and stop dates are also established based on whether work will be conducted
on a full-time or part-time basis.
 Effort validation
o Every project has a defined number of people on the team.
o As time allocation occurs, the project manager must ensure that no more than the
allocated number of people have been scheduled at any given time.
 Defined responsibilities
o Every task that is scheduled should be assigned to a specific team member.
 Defined outcomes
o Every task that is scheduled should have a defined outcome for software projects
such as a work product or part of a work product.
o Work products are often combined in deliverables.
 Defined milestones
o Every task or group of tasks should be associated with a project milestone.
o A milestone is accomplished when one or more work products has been reviewed
for quality and has been approved.

3.4.3 Relationship between People and Effort
 Common management myth : If we fall behind schedule, we can always add more
programmers and catch up later in the project.
o This practice actually has a disruptive effect and causes the schedule to slip even
further.
o The added people must learn the system.
o The people who teach them are the same people who were earlier doing the work
o During teaching, no work is being accomplished.
o Lines of communication (and the inherent delays) increase for each new person
added
3.4.4 Effort Applied vs Delivery Time
 There is a nonlinear relationship between effort applied and delivery time (Ref:
Putnam-Norden-Rayleigh Curve).
o Effort increases rapidly as the delivery time is reduced.
 Also, delaying project delivery can reduce costs significantly as shown in the equation
E = L3/(P3t4) and in the curve below
E = Development effort in person-months
L = Source lines of code delivered
P = Productivity parameter (ranging from 2000 to 12000)
t = Project duration in calendar months
Fig. 3.4.2
3.4.5 40-20-40 Distribution of Effort
 A recommended distribution of effort across the software process is 40 % (analysis and

design), 20 % (coding), and 40 % (testing).

 Work expended on project planning rarely accounts for more than 2 - 3 % of the total
effort.
 Requirements analysis may comprise 10 - 25 %.
o Effort spent on prototyping and project complexity may increase this
 Software design normally needs 20 – 25 %
 Coding should need only 15 - 20 % based on the effort applied to software design
 Testing and subsequent debugging can account for 30 - 40 %
o Safety or security-related software requires more time for testing
3.5 Scheduling Techniques
 Simple sequencing
o Suitable for small projects
 Critical Path Method (CPM)
o Suitable for large software projects
o The most commonly used “networking” technique
 Besides the simple sequencing technique, various networking techniques are proposed.
 Other networking techniques are very similar to CPM.
3.5.1 Simple Sequencing
 A simple sequencing of the tasks and the responsible personnel taken into account of
the resources.
 Easily presented in a simple bar chart.
 Suitable for allocating individuals to particular tasks at an early stage.
3.5.2 Critical Path Method (CPM)
 Primary objectives :
o Planning the project so that it can be completed as quickly as possible.
o Identifying those activities where their delays is likely to affect the overall project
completion date
 Developed by Du Pont Chemical Company and published in 1958.
 Capture the activities and their inter-relationships using a graph.
o Lines are used to represent the activities.
o Nodes are used to represent the start and stop of activities.

 Dummy activities (dotted lines) can be used to :

o Avoid logical errors to paths.
o Document related activities that can be done in parallel and have a time lag
 In CPM, each activity has a time estimate.
 Adding time dimension
o The forward pass
1. calculate the earliest start dates of the activities
2. to calculate the project completion date
o The backward pass
1. calculate the latest start dates for activities
2. identify the critical path from the graph
 Identifying critical path and critical event
o Critical event : an event that has zero slack
o Critical path : a path joining those critical events
 Slack : measures how late an event may be without affecting the overall target date of
the project
o slack = latest start date – earliest start date (for an event)
 Any delay of the critical events will delay the project
 There is always at least one critical path in the CPM network.
Example to construct a CPM
Id. Activity Name Duration (weeks) Precedents
A Hardware selection 7
B Software design 4
C Hardware Installation 6 A
D Coding 4 B
E Data Preparation 5 B
F User Documentation 9

G User Training 5 E,F
H System Installation 3 C,D
Fig. 3.5.1
Fig. 3.5.2
Activity Float
 Time allowed for an activity to delay

 Three different types :
o Total float (without affecting the completion of the project)
= latest start date – earliest start date
o Free float (without affecting the next activity)
= earliest start date of next activity – latest end date of previous activity
o Interfering float = total float – free float
 Total float can be used up once.
 Free float can be used up separately.

 However, whenever any float is used, the overall timing of the project is changed.
 The overall timing of a project should includes the activities and the duration of each
activities.
 A recalculation of the CPM is need.
3.5.3 Significance of Critical Path
 During planning stage

o Shortening the critical path will reduce the overall project duration.
 During management stage
o Pay more attention to those activities which fall in the critical path.
 Actually, it is the shortening of the critical activity by putting more resources in it.
 The CPM allows to identify what to shorten? However, it does not tell, how to.
3.6 Network Planning Models
 The project scheduling techniques model the project’s activities and their relationships
as a network.
 In network, the time flows from left to right.
 An activity on arrow approach can be used to visualize the project as a network in
which activities are shown as arrows joining the circles.
 Each node represents either the start or the end of an activity or a set of activities, this
network can also be called as precedence network.
 The techniques were originally developed in the 1950.
 Two best techniques used are,
o CPM – Critical Path Method
o PERT – Program Evaluation Review Technique
 Both of these techniques uses an activity-on-arrow approach.
 The variation on these techniques called precedence networks.
 In activity-on-node networks where activities are represented as nodes and the links
between nodes represent precedence requirements.
3.6.1 Constructing Precedence Networks
 There are some conventions used in the construction of precedence networks.

o Only one start node and one end node must be defined for a project network.
o Every node must have duration.

o Links do not have duration.

o Subsequent preceding activities are precedents.
o Flow of activities.
o Loop free network.
o Dangle free network.
Fig. 3.6.1 Precedence network
Fig. 3.6.2 Loop representing impossible sequence
Fig. 3.6.3 Activity network representing a dangle

3.6.2 Network Planning Techniques or Models
 There are Two types of Models which are given below :

 Program Evaluation and Review Technique (PERT) :
o Developed to manage the Polaris missile project.
o Many tasks pushed the boundaries of science and engineering (tasks’ duration =
probabilistic).
 Critical Path Method (CPM) :
o Developed to co-ordinate maintenance projects in the chemical industry.
o A complex undertaking, but individual tasks are routine (tasks’ duration =
deterministic)
Both PERT and CPM :
 Graphically display the precedence relationships and sequence of activities.

 Estimate the project’s duration.
 Identify critical activities that cannot be delayed without delaying the project.
 Estimate the amount of slack associated with non-critical activities.
3.6.3 Network Diagram
3.6.3.1 Activity on Arrow Networks
 The CPM and PERT methods both originally used activity-on-arrow networks.
 In activity-on-arrow networks activities are represented by links and the nodes
represent events of activities.
Fig. 3.6.4

1. Activity-on-arrow network rules and conventions

 A project network may have only one start node.
 A project network may have only one end node.
 A link has duration.
 Nodes have no duration.
 Time moves from left to right.
 Nodes are numbered sequentially.
 A network may not contain loops.
 A network may not contain dangles.
Fig. 3.6.5 A loop represents an impossible sequence
Fig. 3.6.6 A dangle
Fig. 3.6.7 Activity network

2. Using dummy activities
 Two paths within a network have a common event.

 The problems can be resolve by separating the two independent paths by introducing a
dummy activity.
 Dummy activities, shown ad dotted lines on the network diagram, have a zero duration
and use no resources.
Use : Two activities share the same start and end nodes makes it easier to distinguish the
activity end points.
Fig. 3.6.8 Two paths linked by a dummy activity

3. Representing lagged activities
 Activity-on-arrow networks are less elegant when it comes to represent lagged parallel
activities.
Fig. 3.6.9 Using the ladder technique to indicate lags

4. Activity labelling
 The diagram is used to record information about the events rather than the activities.
 Divide the node circle into quadrants and use those quadrants to show the event
number, the latest and earliest dates by which the event should occur, and the event
slack.

Fig. 3.6.10
5. Network analysis
(a) The forward pass

 Calculate the earliest date on which each event may be achieved and the earliest dates
on which each activity may be started and completed.
 Steps involved in forward pass are,
o Start at the start node.
o Compute the top pair of numbers.
o Add the duration to the connecting node’s earliest finish time.
Fig. 3.6.11 A CPM network after the forward pass

(b) The backward pass
 Calculate the latest date at which each event may be achieved and each activity started
and finished, without delaying the end date of the project.
 The steps involved in backward pass are,
o Start at the end node
o Compute the bottom pair of numbers
o Subtract the duration from the connecting node’s earliest start time.

Fig. 3.6.12 CPM network after the backward pass

6. Identifying the critical path
 The critical path is identified by using the activity-on-node networks.
 Slack is used to identify the path.
 Slack is the difference between the earliest date and the latest date of an event.
A – B – G – H is the critical path.
3.6.3.2 Activity-On-Node (AON)
 Uses nodes to represent the activity
 Uses arrows to represent precedence relationships

Fig. 3.6.13
Example : Step 1-Develop an AON for the project.
Activity Description Immediate Duration (Weeks)

Predecessor
A Development product None 4

specifications
B Design manufacturing A 6
process
C Source and purchase A 3

materials
D Source and purchase B 6

tooling and equipment
E Receive and install D 14

F Receive materials C 5
G Pilot production run E and F 2
H Evaluate product design G 2
I Evaluate process G 3
performance

J Write documentation H and I 4

report
K Transmission to J 2
manufacturing
Step 2 : Diagram the network for project (CPM)
Fig. 3.6.14
Step 3(a) : Add deterministic time estimates and connected paths
Fig. 3.6.15
Calculate the Project Completion Times
Paths Path duration
ABDEGHJK 40
ABDEGIJK 41
ACFGHJK 22
ACFGIJK 23
 The longest path (ABDEGIJK) limits the project’s duration (project cannot finish in
less time than its longest path).
 ABDEGIJK is the project’s critical path.

Some network definitions

 All activities on the critical path have zero slack.
 Slack defines how long non-critical activities can be delayed without delaying the
project.
 Slack = the activity’s late finish minus its early finish (or its late start minus its early
start).
 Earliest Start (ES) = the earliest finish of the immediately preceding activity.
 Earliest Finish (EF) = is the ES plus the activity time.
 Latest Start (LS) and Latest Finish (LF) = the latest an activity can start (LS) or finish
(LF) without delaying the project completion.
ES, EF Network
Fig. 3.6.16
LS, LF Network
Fig. 3.6.17

Calculating slack
Activity Late Early Slack
Finish Finish (weeks)
A 4 4 0
B 10 10 0
C 25 7 18
D 16 16 0
E 30 30 0
F 30 12 18
G 32 32 0
H 35 34 1
I 35 35 0
J 39 39 0
K 41 41 0
3.6.4 Example by Using Probabilistic Time Estimates (PERT)
Activity Description Optimistic time Most likely Pessimistic

time time
A Develop product 2 4 6
specifications
B Design manufacturing 3 7 10
process
C Source and purchase 2 3 5
materials
D Source and purchase 4 7 9
E Receive and install 12 16 20
F Receive materials 2 5 8
G Pilot production run 2 2 2
H Evaluate product design 2 3 4
I Evaluate process 2 3 5
performance
J Write documentation 2 4 6
report
K Transition to 2 2 2
manufacturing

Using beta probability distribution to calculate expected time durations
 A typical beta distribution is shown below, note that it has definite end points.
 The expected time for finishing each activity is a weighted average.
Fig. 3.6.18
Optimistic + 4(most likely) + pessimistic
Exp. time = 6
Calculating Expected Task Times

Optimistic + 4(mos likely) + pessimistic
Exp. time = 6
Activity Optimistic time Most likely time Pessimistic time Expected time
A 2 4 6 4
B 3 7 10 6.83
C 2 3 5 3.17
D 4 7 9 6.83
E 12 16 20 16
F 2 5 8 5
G 2 2 2 2
H 2 3 4 3
I 2 3 5 3.17
J 2 4 6 4
K 2 2 2 2

Network diagram with expected activity times
Fig. 3.6.19
Estimated path durations through the network
Activities on paths Expected duration

ABDEGHJK 44.66
ABDEGIJK 44.83
ACFGHJK 23.17
ACFGIJK 23.34
 ABDEGIJK is the expected critical path and the project has an expected duration of
44.83 weeks
Adding ES and EF to Network
Fig. 3.6.20

Gannt chart showing each activity finished at the earliest possible start date
Adding LS and LF to network
Fig. 3.6.21

Gantt chart showing the latest possible start times if the project is to be completed
in 44.83 weeks
Estimating the probability of completion dates
 Using probabilistic time estimates offers the advantage of predicting the probability of
project completion dates.
 We have already calculated the expected time for each activity by making three time
estimates.
 Now we need to calculate the variance for each activity.
 The variance of the beta probability distribution is :
2
p – o
2 = 
 6 
where p = Pessimistic activity time estimate
o = Optimistic activity time estimate
Project activity variance
Activity Optimistic Most Likely Pessimistic Variance

A 2 4 6 0.44
B 3 7 10 1.36

C 2 3 5 0.25
D 4 7 9 0.69
E 12 16 20 1.78
F 2 5 8 1.00
G 2 2 2 0.00
H 2 3 4 0.11
I 2 3 5 0.25
J 2 4 6 0.44
K 2 2 2 0.00
Variances of each path through the network
Path Number Activities on Path Path Variance (weeks)

1 A,B,D,E,G,H,J,k 4.82
2 A,B,D,E,G,I,J,K 4.96
3 A,C,F,G,H,J,K 2.24
4 A,C,F,G,I,J,K 2.38
Calculating the probability of completing the project in less than a specified time
 When you know :

o The expected completion time
o Its variance
o You can calculate the probability of completing the project in “X” weeks with the
following formula :
specified time – path expected time DT – EFp
z = path standard time = 2 
 p 
Where, DT = The specified completion date
EFpath = The expected completion time of the path
2
path = Variance of path
Example : Calculating the probability of finishing the project in 48 weeks.

 Calculate values of z to determine probabilities.

48 weeks – 44.66 weeks

 e.g. probability for path 1 is z =   = 1.52
 4.82 
Path Activities on Path Variance z-value Probability of
Number Path (weeks) Completion
1 A,B,D,E,G,H,J,K 4.82 1.5216 0.9357
2 A,B,D,E,G,I,J,K 4.96 1.4215 0.9222
3 A,C,F,G,H,J,K 2.24 16.5898 1.000
4 A,C,F,G,I,J,K 2.38 15.9847 1.000
3.6.5 Reducing Project Completion Time
 Project completion times may need to be shortened because :

o Different deadlines
o Penalty clauses
o Need to put resources on a new project
o Promised completion dates
 Reduced project completion time is “crashing”
Reduced Project Completion Time-Con’t
 Crashing a project needs to balance

o Shorten a project duration
o Cost to shorten the project duration
 Crashing a project requires you to know
o Crash time of each activity
o Crash cost of each activity
Crash cost/Duration = (Crash cost – Normal cost)/(Normal time – Crash time)
Reducing the Time of a Project (Crashing)
Activity Normal Normal Crash Crash Max. weeks of Reduce cost

Time (wk) Cost ($) Time Cost ($) reduction per week
A 4 8,000 3 11,000 1 3,000
B 6 30,000 5 35,000 1 5,000
C 3 6,000 3 6,000 0 0
D 6 24,000 4 28,000 2 2,000

E 14 60,000 12 72,000 2 6,000

F 5 5,000 4 6,500 1 1500
G 2 6,000 2 6,000 0 0
H 2 4,000 2 4,000 0 0
I 3 4,000 2 5,000 1 1,000
J 4 4,000 2 6,400 2 1,200
K 2 5,000 2 5,000 0 0
Crashing example : Suppose the project manager wants to reduce the new product project
from 41 to 36 weeks.
 Crashing costs are considered to be linear
 Look to crash activities on the critical path
 Crash the least expensive activities on the critical path first (based on cost per week)
o Crash activity I from 3 weeks to 2 weeks $1000
o Crash activity J from 4 weeks to 2 weeks $2400
o Crash activity D from 6 weeks to 4 weeks $4000
o Recommend Crash Cost $7400
 Question : Will crashing 5 weeks return more in benefits than it costs?
Crashed network diagram
Fig. 3.6.22

3.6.6 The Critical Chain Approach
 The Critical Chain Approach focuses on project due dates rather than on individual
activities and the following realities:
o Project time estimates are uncertain so we add safety time
o Multi-levels of organization may add additional time to be “safe”
o Individual activity buffers may be wasted on lower-priority activities
o A better approach is to place the project safety buffer at the end
Original critical path
Activity A Activity B Activity C Activity D Activity E
Critical path with project buffer
Activity A Activity B Activity C Activity D Activity E Project Buffer
Adding Feeder Buffers to Critical Chains
 The theory of constraints, the basis for critical chains, focuses on keeping bottlenecks
busy.
 Time buffers can be put between bottlenecks in the critical path
 These feeder buffers protect the critical path from delays in non-critical paths
Fig. 3.6.23 Example with feeder buffers
3.7 Risk and Risk Management Process
3.7.1 Risk
 Risks are potential problems that may affect successful completion of a software
project.
 Risks involve uncertainty and potential losses.
 Risk analysis and management are intended to help a software team understand and
manage uncertainty during the development process.

3.7.2 Risk Strategies
 Reactive strategies
o very common, also known as fire fighting.
o project team sets resources aside to deal with problems.
o team does nothing until a risk becomes a problem.
 Proactive strategies
o risk management begins long before technical work starts, risks are identified and
prioritized by importance.
o team builds a plan to avoid risks if they can or to minimize risks if they turn into
problems.
3.7.3 Risk Factors Fall into Two Categories
 Generic risks, common to all software projects, then we tray to improve the
organization to overcome this risks or we have a check list.
 Project specific risks.
 This are complementary points of view we must act on both.
Generic Risks : Most Common Software Risks
 Ambiguous improvement targets.

 Creeping users requirements.
 Crowded office conditions.
 Excessive schedule pressure.
 Excessive time to market.
 Inaccurate cost estimating.
 Friction between :
o Client and software contractors.
o Software management and senior executives.
 Inadequate compensation plans.
 Inadequate configuration control and project repositories.
 Inadequate curricula
 Inadequate package acquisition methods.
 Inadequate software policies and standars.

 Inadequate tolls and methods (project management, Quality assurance, software

engineering, technical documentation…).
 Lack of reusable code, data, test, human interfaces.
 Lack of specialization
 Low user satisfaction
 Low productivity.
 High maintenance costs.
 Partial live cycle definitions.
 poor technology investments.
 Silver bullet syndrome.
Software Risks Type - 1
 Project risks
o Threaten the project plan
 Technical risks
o Threaten product quality and the timeliness of the schedule
 Business risks
o Threaten the viability of the software to be built(market risks, strategic risks,
management risks, budget risks)
Software Risks Type - 2
 Known risks
o Predictable from careful evaluation of current project plan and those extrapolated
from past project experience
 Unknown risks
o Some problems will simply occur without warning.
Risk Risk Type Description
Staff turnover Project Experienced staff will leave the project
before it is finished.
Management change Project There will be a hange of organisational
management with different priorities.
Hardware unavailability Project Hardware which is essential for the
project will not be delivered on
schedule.
Requirements change Project and product There will be a large number of
changes to the requirements than
anticipated.
Specification days Project and product Specifications of essential interfaces
are not available on schedule.

Size under estimate Project and product The size of the system has been under
estimated.
Case tool under Product CASE tools which support the project
performance do not perform as anticipated.
Technology change Business The underlying technology on which
the system is built is supreseded by
new technology.
Product competition Business A competitive product is marketed
before the system is completed.
3.7.3.1 The Top Ten Software Risk Items
Sr. Risk Item Risk Management Techniques

No
1. Personnel Shortfalls Staffing with top talent; key personnel agreements;
incentives; team-building; training; tailoring process to
skill mix; peer reviews.
2. Unrealistic schedules and Business case analysis; design to cost; incremental
budgets development; software reuse; requirements descoping;
adding more budget and schedule.
3. COTS; external components Qualification testing; benchmarking; prototyping;
reference checking; compatibility analysis; vendor
analysis; evolution support analysis.
4. Requirements mismatch; Stakeholder win-win negotiation; business case
gold plating analysis; mission analysis; ops-concept formulation;
user surveys; prototyping; early users’ manual;
design/develop to cost.
5. User interface mismatch Prototyping; scenarios; user characterization
(functionality, style, workload).
6. Architecture, performance, Architecture tradeoff analysis and review boards;
quality simulation; benchmarking; modeling; prototyping;
instrumentation; tuning.
7. Requirements changes High change threshold; information hiding; incremental
development (defer changes to later increments).
8. Legacy software Design recovery; phase out options analysis;
wrappers/mediators; restructuring.
9. Externally-performed tasks Reference checking; pre-award audits; award-fee
contracts; competitive design or prototyping; team-
building.

10. Straining Computer Science Technical analysis; cost-benefit analysis; prototyping;

capabilities reference checking.
3.7.3.2 Risk Estimation
 Recall that
Hazard  Problem  Risk
 Risk estimation is to assess the likelihood and impact of each hazard.
 Risk exposure (risk value)
o It is the importance of the risk
Risk exposure = risk likelihood × risk impact
 Risk likelihood
o The probability that a hazard is going to occur
 Risk impact
o The effect of the problem caused by the hazard
 Risk likelihood : how likely a hazard is going to occur?
 Risk impact :
o Ideally, it should be estimated in monetary terms. However, the estimated value is
normally used as a guideline on the order of importance of the items rather than the
actual dollar need to rectify the problem unless you are a real good estimator.
 What is the cost of the problem? This may include the following :
o The cost of delays to scheduled dates for deliverables.
o The cost overruns caused by using additional or more expensive resources.
o The costs incurred or implicit in any compromise to the quality or functionality of
the system.
Advantages :
 To be consistent with the measures in the cost-benefit analysis.
 Easy to compare the relative importance of risk exposure of various risk.
 Can be directly compared with the costs and likelihoods of success of various
contingency plans.
 The only way to compare or rank the risks.
 To have a good quantitative estimate, the extra effort can provide a better understanding
of the problem.
Disadvantages
 Estimation is difficult, subjective, time-consuming and costly.

Risk Estimation Techniques

 Risk likelihood
o Rank from Low, Medium to High
o Rank from 1 (least likely) to 10 (most likely)
 Risk impact
o Rank from 1 to 10
3.7.3.3 Risk Evaluation
 Ranking the risks.
 Determining the corresponding risk reduction strategies.
 Ranking only shows the order of importance of the risks not their relative sizes.
Ranking Risks
 Ranking the risks based on their risk exposures.
 Ranking shows the order of importance.
 In practice, also consider factors like.
o Confidence of the risk assessment
o Compound risk
o The number of risks
o Cost of action
Risk Reduction Leverage (RRL)
 RRL is used to determine whether it is worthwhile to carry out the risk reduction plan.
 The higher is the RRL value, the more worthwhile is to carry out the risk reduction
plan.
REbefore – REafter
RLL = Risk reduction cost
3.7.3.4 Risk Reduction Strategies
 Five different types in a generic sense
o Hazard prevention
o Likelihood reduction
o Risk avoidance
o Risk transfer
o Contingency planning
 Distinctions among them are fuzzy
Hazard prevention
 Prevent a hazard from occurring or reduce its likelihood to an insignificant level
o Lack of skilled staff can be prevented by employing staff with appropriate skills
o Unclear requirements specification can be prevented by using formal specification
techniques

Likelihood reduction
 Reduce the likelihood of an unavoidable risk by prior planning.

o Late change to the requirements specification can be reduced by using prototyping.
Risk avoidance
 Some hazards cannot be avoided but their risks may

o A project can be protected from the risk of overrunning the schedule by increasing
duration estimates.
Risk transfer
 The impact of the risk can be transferred away from the project by contracting out or
taking out insurance
o The risk of shortfalls in external supplied components can be transferred away by
quality assurance procedures and certification, and contractual agreements.
Contingency planning
 Contingency plans are needed to reduce the impact of those risks that cannot be avoided
o The impact of any unplanned absence of programming staff can be minimized by
using agency programmers
3.7.3.5 Risk Handling
Three main strategies for risk handling :

 Avoid the risk : e.g. change the requirements for performance or functionality.
 Transfer the risk : allocate risks to third party or by insurance to cover any financial
loss should the risk become a reality.
 Contingency planning : Prepare contingency pans to minimize the impact of the risk.
3.7.4 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.
o Project risks affect schedule or resources
o Product risks affect the quality or performance of the software being developed
o Business risks affect the organisation developing or procuring the software

3.7.4.1 The Risk Management Process
 Risk identification
o Identify project, product and business risks
 Risk analysis
o Assess the likelihood and consequences of these risks
 Risk planning
o Draw up plans to avoid or minimise the effects of the risk
 Risk monitoring
o Monitor the risks throughout the project
The risk management process
Fig. 3.7.1
1. Risk identification
 Identify the hazards that might affect the duration or resource costs of the project
Hazard  Problem  Risk
 A hazard is an event that might occur and will create a problem for the successful
completion of the project, if it does occur
 Examples of hazard : a team member is ill; late delivery of a hardware component;
system down
Hazard, Problem, and Risk
 Hazard : Mary’s baby may be born early
 Problem : Modules P and Q will have no coder
 Risk : Milestone 7 will be delayed, or extra budget will be needed to hire another coder
Type of Risk-1
 Type of risks
o Generic risk (common to all projects)

 Standard checklist can be modified based on the risk analysis of previous projects
o Specific risk (only applies to individual projects)
 More difficult to find
 Need to involve project team members
 Need an environment that encourages risk assessment
 Generic risks are those risks relevant to all software projects.
o Examples are misunderstanding of the requirements and key staff being ill.
 Specific risks are those risks relevant to an individual project only.
o Team members of the project are the frontline of identifying these potential risks.
o Need to set up an encouraging risk-identification environment so that team
members are willing to share their findings.
o “Assuming that the problems will not occur does not prevent their occurrence.”
 Guideline
o Use checklist that lists the potential hazards and their corresponding factors
o Maintain an updated checklist for future projects
Type of Risk-2
 Technology risks
 People risks
 Organisational risks
 Requirements risks
 Estimation risks
Risks and risk types
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.
Common risk factors to identify the risk
 Application factors  Staff factors

 Project factors  Hardware and software factors
 Changeover factors  Supplier factors
 Environment factors  Health and safety factors
Application Factors
 Nature of the application

o A data processing application or a life-critical system (e.g. X-ray emission system)
 Expected size of the application
o The larger is the size, the higher is the chance of errors, communication problems
and management problems
Staff Factors
 Experience and skills

 Appropriateness of experience
 Staff satisfaction
 Staff turn-over rates
Project Factors
 Project objectives :
o Ill defined
o Unclear to every team member and user
 Project methods :
o Ill specified methods
o Unstructured methods

Hardware and Software Factors
 New hardware
o Stability of the new hardware system
 Cross platform development
o Development platform is not the operation platform
o Does the language used support cross platform development?
Changeover Factors
 ‘All-in-one’ changeover
o The new system is put into operation
 Incremental or gradual changeover
o Adding new components to the system by phases
 Parallel changeover
o Both the existing system and the new system are used in parallel
Supplier Factors
 Late delivery of hardware

 Instability of hardware
 Late completion of building sites
Environment Factors
 Changes in environment such as hardware platforms

 Changes in government policies
 Changes in business rules
 Restructuring of organizations
Health and Safety Factors
 Health and safety of staff and environment

o Staff sickness, death, pregnancy etc.
o Any tragic accident to staff
Tools and Techniques to identify the risk
 Brainstorming : Brainstorm is employed as a general data-gathering and creativity

technique which identifies risks, ideas, or solutions to issues. Brainstorming uses a
group of team members or subject-matter experts spring boarding off each others’
ideas, to generate new ideas.

 Delphi technique : The Delphi technique gains information from experts,

anonymously, about the likelihood of future events (risks) occurring. The technique
eliminates bias and prevents any one expert from having undue influence on the others.
 Interviewing : Interviewing in a face-to-face meeting comprised of project participants,
stakeholders, subject-matter experts, and individuals who may have participated in
similar, past projects is a technique for gaining first-hand information about and benefit
of others’ experience and knowledge.
 Root cause identification : Root cause identification is a technique for identifying
essential causes of risk. Using data from an actual risk event, the technique enables you
to find out what happened and how it happened, and understand why it happened, so
that you can devise responses to prevent recurrences.
 Strengths, weaknesses, opportunities, and threats (SWOT) analysis : A SWOT
analysis examines the project from the perspective of each project’s strengths,
weaknesses, opportunities, and threats to increase the breadth of the risks considered by
risk management.
 Checklist analysis : Checklists list all identified or potential risks in one place.
Checklists are commonly developed from historical information or lessons learned. The
Risk Breakdown Structure (RBS) can also be used as a checklist. Just keep in mind that
checklists are never comprehensive, so using another technique is still necessary.
 Assumptions analysis : All projects are initially planned on a set of assumptions and
what if scenarios. These assumptions are documented in the Project Scope Document.
During Risk Identification, assumptions are analyzed to determine the amount of
inaccuracy, inconsistency, or incompleteness associated with them.
 Diagramming techniques : Diagramming techniques, such as system flow charts,
cause-and-effect diagrams, and influence diagrams are used to uncover risks that aren’t
readily apparent in verbal descriptions.
 Cause and effect diagrams : Cause and effect diagrams or fishbone diagrams are used
for identifying causes of risk
 System or process flow charts : Flow charts illustrate how elements and processes
interrelate.
 Influence diagrams : Influence diagrams depict causal influences, time ordering of
events and other relationships between input variables and output variables.
2. 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 Low Catastrophic
force reductions in the project budget.
It is impossible to recruit staff with the High Catastrophic
skills required for the project.
Key staff are ill at critical times in the Moderate Serious
project.
Software components which should be Moderate Serious
reused contain defects which limit
their functionality.
Changes to requirements which Moderate Serious
require major design rework are
proposed.
The organization is restructured so High Serious
that different management are
responsible for the project.
The database used in the system Moderate Serious
cannot process as many transactions
per second as expected.
The time required to develop the High Serious
software is underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the Moderate Tolerable
impact of requirements changes.
Required training for staff is not Moderate Tolerable
available.
The rate of defect repair is Moderate Tolerable
underestimated.
The size of the software is High Tolerable
underestimated.
The code generated by CASE tools is Moderate Insignificant
inefficient.

3 Risk planning
Consider each risk and develop a strategy to manage that risk

 Avoidance strategies
o The probability that the risk will arise is reduced
 Minimisation strategies
o The impact of the risk on the project or product will be reduced
 Contingency plans
o If the risk arises, contingency plans are plans to deal with that risk
Risk management strategies
Risk Strategy
Organisational Prepare a briefing document for senior management showing how
financial problems the project is making a very important contribution to the goals of
the business.
Recruitment problems Alert customer of potential difficulties and the 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 components Replace potentially defective components with bought-in
components of known reliability.
Requirements changes Derive traceability information to assess requirements change
impact, maximise information hiding in the design.
Organisational Prepare a briefing document for senior management showing how
restructuring the project is making a very important contribution to the goals of
the business.
Database performance Investigate the possibility of buying a higher-performance database.
Underestimated Investigate buying in components, investigate use of a program
development time generator.
4. 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
Assessing risk impact
 Three factors affect the consequences that are likely if a risk does occur
o Its nature – This indicates the problems that are likely if the risk occurs
o Its scope – This combines the severity of the risk (how serious was it) with its
overall distribution (how much was affected)
o Its timing – This considers when and for how long the impact will be felt
 The overall risk exposure formula is RE = P  C
o P = the probability of occurrence for a risk
o C = the cost to the project should the risk actually occur
 Example
o P = 80% probability that 18 of 60 software components will have to be developed
o C = Total cost of developing 18 components is $25,000
o RE = .80 x $25,000 = $20,000
3.7.5 RMMM (Risk Mitigation, Monitoring and Management)
 Risk mitigation
o proactive planning for risk avoidance
 Risk monitoring
o assessing whether predicted risks occur or not

o ensuring risk aversion steps are being properly applied

o collect information for future risk analysis
o determining which risks caused which problems
 Risk management
o Contingency planning
o Actions to be taken in the event that mitigation steps have failed and the risk has
become a live problem
Risk mitigation example
Risk : loss of key team members

 Determine causes of job turnover.
 Eliminate causes before project starts.
 After project starts, assume turnover is going to occur and work to ensure continuity.
 Make sure teams are organized and distribute information widely.
 Define documentation standards and be sure documents are produced in a timely
manner.
 Conduct peer review of all work.
 Define backup staff.
3.7.6 Risk Information Sheets
 Alternative to RMMM plan in which each risk is documented individually.

 Often Risk Information Sheets (RIS) are maintained using a database system.
 RIS components
o risk id, date, probability, impact, description
o refinement, mitigation/monitoring
o management/contingency/trigger
o status
o originator, assigned staff member
3.7.7 Safety and Hazards
 Risks are also associated with software failures that occur in the field after the
development project has ended.
 Computers control many mission critical applications today (weapons systems, flight
control, industrial processes, etc.).

 Software safety and hazard analysis are quality assurance activities that are of particular
concern for these types of applications
3.7.8 Issues Related to Risk Management
 Operational risk has recently come forcefully to the forefront. With the increasing
complexity of transactions, the global nature of the markets and the risks they represent,
it's no longer uncommon for firms to have chief operational risk officers. Only a few
years ago, the position did not exist.
 Models and their role have become a focus, leading to a number of questions with no
easy answers. For example, given the capital issues that resulted from the crisis, should
we really continue to rely on a firm's proprietary models? Do we need public sector
models, especially since it's been shown that in the event of a failure – especially that of
a systemically important financial institution – the public sector may be asked to pick
up the pieces ?
 Systemic risk issues are dominating the regulatory discussion globally, take up a
considerable amount of the risk manager’s time, and raise very complex risk-related
questions. For example, should the balance sheet size of a systemically important
institution, or environmental issues such as sovereign risks, be included in a firm’s
modeling scenarios not only to specifically measure the effect of each on the firm, but
also how each may affect systemic risk ?
 Capital charges and efficient use of capital have been and will be a major area of focus
for risk managers well into the future.
 Corporate governance is also of growing interest to risk managers. Risk managers are
now being involved in corporate discussions about compensation, and in some cases
actually being asked to opine on compensation packages and whether the incentives
built into the packages may increase the firm's risk profile.
 The Board of directors' role has changed dramatically over the last few years, with
risk-related issues becoming more important to directors. This is not only because
directors are being held to a higher standard of conduct, but also because they now want
to objectively show and ensure they are carrying out their duties to their companies and
shareholders properly. Directors are also demanding that a culture of risk awareness
exists throughout the organization, and that risk awareness becomes and remains an
integral part of the company.

3.7.9 List of Risks Related to Software Projects

Product size risks
 Estimated size of the product in LOC or FP ?

 Degree of confidence in estimated size estimate ?
 Estimated size of product in number of programs, files, transactions ?
 Percentage deviation in size of product from average for previous products ?
 Size of database created or used by the product ?
 Number of users of the product ?
 Number of projected changes to the requirements for the product ? Before delivery ?
After delivery ?
 Amount of reused software ?
Business impact risks
 Affect of this product on company revenue ?

 Visibility of this product by senior management ?
 Reasonableness of delivery deadlines ?
 Number of customers who will use this product and the consistency of their needs
relative to the product ?
 Number of other products/systems with which this product must be interoperable ?
 Sophistication of end users ?
 Amount and quality of product documentation that must be produced and delivered to
the customer ?
 Governmental constraints on the construction of the product ?
 Costs associated with late delivery ?
 Costs associated with a defective product ?
Customer related risks
 Have you worked with the customer in the past ?

 Does the customer have a solid idea of what is required ?
 Has the customer taken the time to write this down ?
 Will the customer agree to spend time in formal requirements gathering meetings to
identify project scope ?
 Is the customer willing to establish rapid communication links with the developer ?

 Is the customer willing to participate in reviews ?

 Is the customer technically sophisticated in the product area ?
 Is the customer willing to let your people do their job that is, will the customer resists
looking over your shoulder during technically detailed work ?
 Does the customer understand the software engineering process ?
Development environment risks
 Is a software project management tool available ?

 Is a software process management tool available ?
 Are tools for analysis and design available ?
 Do analysis and design tools deliver methods that are appropriate for the product to be
built ?
 Are compilers or code generators available and appropriate for the product to be built ?
 Are testing tools available and appropriate for the product to be built ?
 Are software configuration management tools available ?
 Does the environment make use of a database or repository ?
 Are all the software tools integrated with one another ?
 Have members of the project teams received training in each of the tools ?
 Are local experts available to answer questions about the tools ?
 Is on-line help and documentation for the tools adequate ?
Process issue risks
 Does your senior management support a written policy statement that emphasizes the
importance of a standard process for software development ?
 Has your organization developed a written description of the software process to be
used on this project ?
 Are staff members signed-up to the software process as it is documented and willing to
use it ?
 Is the software process used for other projects ?
 Has your organization developed or acquired a series of software engineering training
courses for managers and technical staff ?
 Are published software engineering standards provided for every software developer
and software manager ?
 Have document outlines and examples been developed for all deliverables defined as
part of the software process ?

 Are formal technical reviews of the requirements specification, design, and code
conducted regularly ?
 Are formal technical reviews of test procedures and test cases conducted regularly ?
 Are the results of each formal technical review documented, including defects found
and resources used ?
 Is there some mechanism for ensuring that work conducted on a project conforms with
software engineering standards ?
 Is configuration management used to maintain consistency among system/software
requirements, design, code, and test cases
 Is a mechanism used for controlling changes to customer requirements that impact the
software ?
 Is there a documented statement of work, software requirements specification, and
software development plan for each subcontract ?
 Is a procedure followed for tracking and reviewing the performance of subcontractors
Staff size and experience
 Are the best people available ?

 Do the people have the right combination of skills ?
 Are enough people available ?
 Are staff committed for entire duration of the project ?
 Will some staff be working only part time on this project ?
 Do staff have the right expectations about the job at hand ?
 Have staff received necessary training ?
 Will turnover among staff be low enough to allow continuity ?
Technical issue risks
 Are facilitated application specification techniques used to aid in communication

between the customer and developer ?
 Are specific methods used for software analysis ?
 Do you use a specific method for data and architecture designs ?
 Is more then 90 % of your code written in a high order language ?
 Are specific conventions for code documentation defined and used ?
 Do you use a specific method for test case design ?
 Are software tools used to support software planning and tracking activities ?

 Are configuration management software tools used to control and track change activity
throughout the software process ?
 Are software tools used to support the software analysis and design process ?
 Are tools used to create software prototypes ?
 Are software tools used to support the testing process ?
 Are software tools used to support the production and management of documentation ?
 Are quality metrics collected for all software projects ?
 Are productivity metrics collected for all software projects ?
Technology risks
 Is the technology to be built new to your company ?
 Do the customer requirements demand the creation of new algorithms, input or output
technology ?
 Does the software interface with new or unproven hardware ?
 Does the software to be built interface with a database system whose function and
performance have not been proven in this application area ?
 Does the software to be built interface with vendor supplied software products that are
unproven ?
 Is a specialized user interface demanded by product requirements ?
 Do requirements for the product demand the creation of program components that are
unlike any previously developed by your organization ?
 Do requirements demand the use of new analysis, design, or testing methods ?
 Do requirements demand the use of unconventional software development methods,
such as formal methods, AI-based approaches, artificial neural networks?
 Do requirements put excessive performance constraints on the product?
 Is the customer uncertain that the functionality requested is "do-able"?
 Other potential risks
3.8 Monte Carlo Simulation
To ensure the successful completion of a project, it is of utmost importance for the

project manager to find ways to handle uncertainties that can pose potential risks for a project.
Risk management is an iterative process. Risks can relate to any aspect of the project – be it
the cost, schedule, or quality. The key to managing risks is to identify them early on in the
project and develop an appropriate risk response plan.

To develop a Risk Response Plan, need to quantify the impact of risks on the project.
This process is known as quantitative risk analysis wherein risks are categorized as high or
low priority risks depending on the quantum of their impact on the project. Monte Carlo
analysis is used for performing quantitative risk analysis.
3.8.1 Monte Carlo Analysis with Example
Monte Carlo analysis involves determining the impact of the identified risks by running
simulations to identify the range of possible outcomes for a number of scenarios. A random
sampling is performed by using uncertain risk variable inputs to generate the range of
outcomes with a confidence measure for each outcome. This is typically done by establishing
a mathematical model and then running simulations using this model to estimate the impact of
project risks. This technique helps in forecasting the likely outcome of an event and thereby
helps in making informed project decisions.
While managing a project, you would have faced numerous situations where you have a
list of potential risks for the project, but you have no clue of their possible impact on the
project. To solve this problem, you can consider the worst-case scenario by summing up the
maximum expected values for all the variables. Similarly, you can calculate the best-case
scenario. You can now use the Monte Carlo analysis and run simulations to generate the most
likely outcome for the event. In most situations, you will come across a bell-shaped normal
distribution pattern for the possible outcomes.
Let take an example. Suppose you are managing a project involving creation of an
eLearning module. The creation of the eLearning module comprises of three tasks: writing
content, creating graphics, and integrating the multimedia elements. Based on prior experience
or other expert knowledge, you determine the best case, most-likely, and worst-case estimates
for each of these activities as given below :
Tasks Best-case estimate Most likely estimate Worst-case estimate
Writing content 4 days 6 days 8 days
Creating graphics 5 days 7 days 9 days
Multimedia integration 2 days 4 days 6 days
Total duration 11 days 17 days 23 days
The Monte Carlo simulation randomly selects the input values for the different tasks to
generate the possible outcomes. Let us assume that the simulation is run 500 times. From the
above table, we can see that the project can be completed anywhere between 11 to 23 days.
When the Monte Carlo simulation runs are performed, we can analyse the percentage of times
each duration outcome between 11 and 23 is obtained.

The following table depicts the outcome of a possible Monte Carlo simulation :
Total Project Number of times the simulation Percentage of simulation runs where
Duration result was less than or equal to the result was less than or equal to
the Total Project Duration the Total Project Duration
11 5 1%
12 20 4%
13 75 15 %
14 90 18 %
15 125 25 %
16 140 28 %
17 165 33 %
18 275 55 %
19 440 88 %
20 475 95 %
21 490 98 %
22 495 99 %
23 500 100 %
This can be shown graphically in the following manner :
Fig. 3.8.1

What the above table and chart suggest is, for example, that the likelihood of
completing the project in 17 days or less is 33%. Similarly, the likelihood of completing the
project in 19 days or less is 88%, etc. Note the importance of verifying the possibility of
completing the project in 17 days, as this, according to the Most Likely estimates, was the
time you would expect the project to take. Given the above analysis, it looks much more likely
that the project will end up taking anywhere between 19 – 20 days.
3.8.2 Benefits of Using Monte Carlo Analysis
It is very effective as it is based on evaluation of data numerically and there is no

guesswork involved. The key benefits of using the Monte Carlo analysis are listed below :
 It is an easy method for arriving at the likely outcome for an uncertain event and an
associated confidence limit for the outcome. The only pre-requisites are that you should
identify the range limits and the correlation with other variables.
 It is a useful technique for easing decision-making based on numerical data to back
your decision.
 Monte Carlo simulations are typically useful while analyzing cost and schedule. With
the help of the Monte Carlo analysis, you can add the cost and schedule risk event to
your forecasting model with a greater level of confidence.
 You can also use the Monte Carlo analysis to find the likelihood of meeting your
project milestones and intermediate goals.
3.8.3 Monte Carlo Analysis : Steps
The series of steps followed in the Monte Carlo analysis are listed below :
1. Identify the key project risk variables.
2. Identify the range limits for these project variables.
3. Specify probability weights for this range of values.
4. Establish the relationships for the correlated variables.
5. Perform simulation runs based on the identified variables and the correlations.
6. Statistically analyze the results of the simulation run.
Each of the above listed steps of the Monte Carlo simulation is detailed below :
1. Identification of the key project risk variables : A risk variable is a parameter which
is critical to the success of the project and a slight variation in its outcome might have a
negative impact on the project. The project risk variables are typically isolated using the
sensitivity and uncertainty analysis.

Sensitivity analysis is used for determining the most critical variables in a project. To
identify the most critical variables in the project, all the variables are subjected to a
fixed deviation and the outcome is analysed. The variables that have the greatest impact
on the outcome of the project are isolated as the key project risk variables. However,
sensitivity analysis in itself might give some misleading results as it does not take into
consideration the realistic nature of the projected change on a specific variable.
Therefore it is important to perform uncertainty analysis in conjunction with the
sensitivity analysis.
Uncertainty analysis involves establishing the suitability of a result and it helps in
verifying the fitness or validity of a particular variable. A project variable causing high
impact on the overall project might be insignificant if the probability of its occurrence is
extremely low. Therefore it is important to perform uncertainty analysis.
2. Identification of the range limits for the project variables : This process involves
defining the maximum and minimum values for each identified project risk variable. If
you have historical data available with you, this can be an easier task. You simply need
to organize the available data in the form of a frequency distribution by grouping the
number of occurrences at consecutive value intervals. In situations where you do not
have exhaustive historical data, you need to rely on expert judgement to determine the
most likely values.
3. Specification of probability weights for the established range of values : The next
step involves allocating the probability of occurrence for the project risk variable. To do
so, multi-value probability distributions are deployed. Some commonly used probability
distributions for analyzing risks are normal distribution, uniform distribution, triangular
distribution, and step distribution. The normal, uniform, and triangular distributions are
even distributions and establish the probability symmetrically within the defined range
with varying concentration towards the centre. Various types of commonly used
probability distributions are depicted in the diagrams below :
Fig. 3.8.2

Fig. 3.8.3
4. Establishing the relationships for the correlated variables : The next step involves
defining the correlation between the project risk variables. Correlation is the
relationship between two or more variables wherein a change in one variable induces a
simultaneous change in the other. In the Monte Carlo simulation, input values for the
project risk variables are randomly selected to execute the simulation runs. Therefore, if
certain risk variable inputs are generated that violate the correlation between the
variables, the output is likely to be off the expected value. It is therefore very important
to establish the correlation between variables and then accordingly apply constraints to
the simulation runs to ensure that the random selection of the inputs does not violate the
defined correlation. This is done by specifying a correlation coefficient that defines the
relationship between two or more variables. When the simulation rounds are performed
by the computer, the specification of a correlation coefficient ensures that the
relationship specified is adhered to without any violations.
5. Performing Simulation Runs : The next step involves performing simulation runs.
This is typically done using a simulation software and ideally 500 – 1000 simulation
runs constitute a good sample size. While executing the simulation runs, random values
of risk variables are selected with the specified probability distribution and correlations.
6. Statistical Analysis of the Simulation Results : Each simulation run represents the
probability of occurrence of a risk event. A cumulative probability distribution of all the
simulation runs is plotted and it can be used to interpret the probability for the result of
the project being above or below a specific value. This cumulative probability
distribution can be used to assess the overall project risk.

Resource Allocation and Cost Schedules
3.9 Resource Allocation
After the activities have been identified using various techniques and tabulated into a
Work-Break-Down the resources need to be allocated to complete the identified tasks. This
process is considered resource allocation.
3.9.1 Who Allocates Resources ?
Project Manager
 Concentrate on resources where there is a possibility that, without planning, they might
not be sufficiently available when required.
 Senior Software Developers are the hardest to find – these need to be very carefully
planned for in advance.
 Developers do not like to wait for work, they prefer to be busy with activities and tasks
that show clear progress.
3.9.2 Result of Resource Allocation
Reflected in many schedules
 Activity Schedule.
 Resource Schedule.
 Cost Schedule.
 Activity : Indicating the planned start and end dates for completion of each activity.
 Resource : Showing dates on which each resource will be required and level of that
requirement.
 Cost : Showing the planned cumulative expenditure incurred by the use of resources
over time.
 Changes to these schedules are very much interrelated and require domain experience
to “get it right”.
3.9.3 Resource Categories
 Labour (Even the project manager).
 Equipment (Coffee Machine?).
 Materials (Consumed items – floppy disks).
 Space (Rooms, Cubicles).

 Services (Telecomm, Cleaning services).

 Time (The most rigid item of all).
 Money (Secondary resource) : Money is secondary in the sense that it is calculated
from the others.
Note : These are broad categories only.
3.9.4 Resource Organisation

 A program organization chart is essential to allocate staff effectively,
o Develop the hierarchical program organization.
o Identify Roles and Responsibilities.
o Plan for number of staff in each role (at a high level).
o Establish Teams.
3.9.5 Resource Requirement Identification – 1
 For each activity identify,
o Work amount required (in work units)
o Basic skill or experience level required (to even undertake the task)
o Complexity of the task (this will help to determine the experience required)
o Task Category (Unskilled, skilled, leadership, expert, management)
3.9.6 Resource Requirement Identification – 2
 Example.
o Activity : Install Network Hardware for 20 computers.
o Work units : 20.
o Basic Skill : Bachelors Degree in related field.
o Task Complexity: 5.
o Task Category: Skilled (other categories may be Management, Leadership, Expert)
Note : 20 units can be any thing as defined by the domain experts and project manager
 10 again is on a scale that is project specific.

3.9.7 Resource Scheduling
 After all the required resources have been identified, they need to be scheduled
effectively.

 The earliest start dates, last start dates will need to be taken into account to schedule
resources efficiently.
 Resources should be balanced throughout the project.
3.9.7.1 Resource Scheduling Issues
 Human resource scheduling issues,

o Planned Leave, Public Holidays.
o Possible sick leave (random, subjective at best and hard to predict).
o General motivation and enthusiasm for the task allocated (If they dislike the task, it
will flow through into the output).
o Work load and stress in project.
o Stress outside work.
3.9.8 Resource Histograms
 Commonly used during planning to indicate possible problem areas,

o People (by category) Vs Week Number
o For each individual – estimated number of tasks (including complexity) over weeks
o This helps in reducing work load some times to help the individual recover from
any heavy load.
 Category Vs Week
3.9.9 External Dependencies
When planning any resources that rely on external factors, these need to be planned
with the associated risks involved.
3.9.10 Parallel, Sequential Tasks
 Tasks run both in parallel and sequentially.

 Depending on the activity network and critical path, resource allocation needs to be
planned effectively.
 Competing tasks need to be prioritised with risk before resource allocation.
3.9.10.1 Prioritisation Techniques
 Total Float Priority

 Ordered List Priority
 There are many others that refine on top of these, but broadly these cover the general
cases well.

Total Float Priority
 Ordered according to their total float.

 Smallest total float has highest priority.
 Activities are allocated resources in ascending order of total float.
 Changes to plan will require re-calculation.
Ordered List Priority
 Activities that can proceed at the same time are ordered according to a set of simple
criteria.
 Burman’s priority list takes into account activity duration as well as total float:
1. Shortest critical activity. 2. Critical activities.
3. Shortest non-critical activity. 4. Non-critical activity with least float.
5. Non-critical activities.
Note : Other ways of ordering are also possible.
3.9.11 Critical Paths
 Resource scheduling will almost always change the activity network.

 The changes often result in changes to the critical path.
o Delaying an activity due to lack of correct resources will cause that activity to
become critical after it uses up all its slack time.
 These changes are often experienced after the project has started which will require
adapting during the project (this is normally much harder in practice).
3.9.12 Cost of Resources
 All projects concentrate on completion in the shortest time span with minimum
resources (in planning stage).
 However, once the project starts – all un-planned for issues and any risks will cause
some strain on the cost.
3.9.13 Resource Allocation Issues
 Availability
 Criticality
 Risk
 Training
 Team Building

3.9.14 Use of Gantt Chart in Resource Allocation
Fig. 3.9.1
 Users can clearly discern where resources need to be anticipated, allocated or shared to
maximize the use of those resources. The more closely the chart is followed, the better
chance there is of keeping project costs within budget while also better assuring on-
time completion.
3.10 Cost Scheduling
 Broad Categories
o Staff.
o Overheads (Office Space, Interest charges, Travel Costs, Insurance and so on).
o Usage charges (for external resources or contractors, leased/rental equipment).

Cost profile
Fig. 3.10.1
3.10.1 Scheduling in Practice

 It should always be in the project planner’s mind, right from the start of the project.
 During the resource scheduling and allocation phase of the planning activity a lot of the
plan will change.
 Most of the issues with respect to resource allocation and scheduling arise after the
project starts (normally after about 30% of the activities are complete).
3.11 A Summary or Hammock Activity
 A summary or hammock activity, shown in Fig. 3.11.1, is used to represent groups of
activities in a project schedule. It is used to summarize the schedule information for a
group of activities and to allow the entire project to be summarized as a relatively few
summary activities. The summary activity shows the start and finish for a group of
activities as one Gantt bar. If the early starts and early finishes are being used for the
schedule, the bar will show the earliest early start and the latest early finish for any of
the activities in the group.
Fig. 3.11.1 Activity chart

 The summary activity has come into use since the development of project management
software. The advantage of summary activities over milestones is that it is not
necessary to set up elaborate logical relationships to make sure that the milestone is
rescheduled when activities in the group represented by the milestone are moved.
 The milestone shows only a single date. This can be the start or finish of a group of
activities, or it can be some major event or commitment date. The summary activity
shows the start and finish for a group of activities. The computer will search through
the group of activities and find the earliest early start date and the latest early finish date
if the project is being scheduled according to the early schedule. If the project is being
scheduled by the late schedule or a combination of the two, the computer will search for
the earliest and the latest scheduled dates in the group of activities.
 On the Gantt chart the milestones will have a duration of zero and are generally shown
as triangles. Summary activities are shown on the Gantt chart as schedule activity bars
and usually have a graphic to distinguish them from the normal scheduled activities. In
Microsoft Project the summary bars have small triangles below the bar at each end of
the bar. The summary activities are created by selecting the activities to be summarized
and clicking on the right arrow on the tool bar above them.
 The work breakdown structure is entered the same way. The WBS will make a
convenient set of summary activities and may be sufficient for your reporting system. If
not, other summary activities may be entered as needed.
Q.1 Explain the different network planning models. Give example for precedence
construction. (Refer section 3.6) Dec. - 2012 .
Q.2 Illustrate a network model? Explain rules for constructing precedence networks.
(Refer sections 3.6 and 3.6.1) Dec. - 2013 .
Q.3 Explain the various steps involved in activity planning with its objectives.
(Refer sections 3.1.1 and 3.1.2 ) Dec. - 2013 .
Q.4 Define the objectives of activity planning. (Refer section 3.1.2) Dec. - 2012 .
Q.5 List the factors used to identify the risk. (Refer 3.7.4) Dec. - 2012 .
Q.6 Define the term Risk. Discuss the issues related to managing the risk. Give example.
(Refer section 3.7.1 and 3.7.8) Dec. - 2013 .
Q.7 Discuss the impact of risk in a project. How is risk monitoring achieved to avoid failure
in the project. (Refer section 3.7.4) May - 2014 .
Q.8 What is hazard. List out the generic risks.( Refer sections 3.7.3 and 3.7.4)
Dec. - 2014 .

Q.9 Describe the steps involved in sequencing and scheduling activities in a planning
Model. Give examples.(Refer section 3.4) May - 2014 .
Q.10 State Activity On Arrow (AOA). (Refer section 3.6.3) May - 2014 .
Q.11 Explain the importance of forward pass with an example. (Refer section 3.6.3)
Dec. - 2014 .
Q.12 List the top 10 software project risks and briefly outline the strategies for reducing
each of the risks. (Refer sections 3.7.3 and 3.7.3.4) Dec. - 2014 .
Q.13 Explain the activity based approach used for identifying project activities.
Q.14 Explain the use of checklists and brainstorming in identification of risks.
Q.15 Explain the use of Gantt charts in allocation of resources.
Q.16 What is the significance of a critical path. (Refer section 3.5.3) Dec. - 2014 .
Q.17 What are the risks to business impact ? (Refer section 3.7.9) Dec. - 2013 .
Q.18 Discuss the steps involved in risk planning. (Refer section 3.7.4) Dec. - 2012 .
Q.19 Explain how risks are handled in a project. Give example.
Q.20 What do you understand by work breakdown structure. (Refer section 3.2)
Dec. - 2014 .
Activity Planning and Risk Management ends....

Project Management and Control
Syllabus : Framework for Management and control – Collection of data Project

termination – Visualizing progress – Cost monitoring – Earned Value Analysis-
Project tracking – Change control- Software Configuration Management –
Managing contracts – Contract Management.

4.1 Project Tracking and Monitoring 4-2
4.2 Monitoring the Progress 4 - 10
4.3 Cost Monitoring 4 - 14
4.4 Earned Value Analysis or Earned Value Management 4 - 15
(Cost Monitoring Technique)
4.5 Change Control 4 - 20
4.6 Software Configuration Management 4 - 22
4.7 Managing Contract and Contract Management 4 - 30
4.8 Project Monitoring and Controlling Process in Detail 4 - 40

4.1 Project Tracking and Monitoring
 Make sure the project

o Can be delivered on time and within budget
o Is of good quality
o Meets client’s needs
In fact, the project manager has to make sure everything goes well in the project.
4.1.1 What Can Go Wrong in Product ?
 Inadequate functionality of a product.

o Related to software requirements specification
 Poor quality of a product.
o Related to quality management
 Late delivery of the product.
 Overly exceeding the budget.
 SRS : Software Requirements Specification.
 In fact, many things can go wrong. Normally, these are the major things. The ordering
does not indicate their relative order of importance.
 Inadequate functionality is related to SRS.
 Poor quality is related to quality management.
 These two are discussed in previous lectures.
 Our concentration is on the latter two.
4.1.2 Planning, Tracking and Monitoring
 Planning
o Know where we want to go
 Tracking
o Know where we are
 Monitoring
o How to go from where we are to where we want to go

Tracking
 Finding out what is happening

 Need a plan and schedule
 To collect data
 Ideally, the plan and schedule should be absolutely clear and highly visible to every
personnel involved in the project.
Monitoring
 Comparing the current status with the targets

 Need a plan, a schedule, collected data
 To exercise control over the project
 To ensure the targets are met
 To devise contingency plans
4.1.3 Creating Framework for (Monitoring and Control)
4.1.3.1 Creating Framework
 Exercising control over a project and ensuring that targets are met is a matter of regular
monitoring.
 Finding out what is happening and comparing it with current targets.
 The projects starts its execution, the project must be carefully monitored to ensure the
project’s progress.
 Expected outcomes are compared with the actual ones.
 Project control is a continuous process of monitoring the progress of the project plan
and is also includes re-planning of activities.
Revising the planning strategy is due to,
 Delay in completion of the project within the target time

 Quality factors
 Inadequate functionality in adopting newer techniques
 Actual estimation

Fig. 4.1.1 The project control cycle

4.1.3.2 Responsibility
 The overall responsibility for ensuring satisfactory progress on a project is often the
role of the project steering committee or project board.
 Categories of reporting are classified as,
Formal and Informal.
 Formal regular types can be oral or written.
 Standard oral communication of minutes are kept where as written type gets the
reporting issues in a separate written format.
 Formal ad hoc are mostly received information of different levels towards the end of
the project and generate written reports.
 Informal, oral and ad hoc provides early warning to the system and must be backed up
by formal reporting procedures.

Fig. 4.1.2 Project reporting structures

 Single activity will not yield a deliverable work product but a group of activities can
achieve the specified tangible product.
 The development of the project measures the progress assessment.
 It is carried out by the team members who are associated with the project activities.
4.1.4 Tracking the Performance
 Tracking performance means assessing the progress

o Need to trust your personnel to give an objective assessment of their work and their
estimation on completion of their work
 Setting check points
 Collecting data
4.1.4.1 Check Point
 Based on regular time intervals

o Can be weekly or monthly or quarterly
o Depend on what to check and how to
 Based on a particular event
o At the end of each activity
o In the middle of a critical activity
Time interval : Duration actually depends on who to check, what to check, the degree
of risk of the project; how familiar the new employee is to the process of the
organization.

Critical activity : The number of check points depends on how critical the event is.
 Tied to specific events such as the production of a report.
 Should be set before the plan was published
o Make sure everyone knows when and what the check points are
4.1.4.2 Collecting Data
 Need to collect data to review the progress of a project.

 It is crucial to know what to collect and how.
 As a manager, it is wise to break down activities that can be completed in one or two
weeks time.
 These reports are filled on a weekly basis.
 Collect Partial completion report.
 Collect Risk report.
1. Partial completion report
 Indicate the work done by the personnel and the time spent on the work
 Optional items
o likelihood of failing to complete the task by the scheduled date
o Estimated time of completion
 For the optional items, there are advantages and disadvantages.
 Advantages :
o Staff involvement
o Get the latest first hand information from the staff
o Have a better picture on what is going on
 Disadvantages :
o Make the personnel have wrong feelings that
 the original schedule not so important; and
 it is OK for the task to be delayed.
 Background information on time-sheet for accounting system :
o The time spent is used by the accounting system to charge the project account.
o A way to keep track of the cost on the project.

Partial completion report – Example

Time Sheet
Staff : Paul Week ending : 14/5/99
Rechargeable hours
Project Act. code Description Hours % done Sch. Date Est. date
P20 A267 Code mod A7 24 90 01/06/99 20/05/99
P35 B397 Testing mod B8 12 30 24/06/99 24/06/99
Total 36
Non-rechargeable hours
Code Description Hours Comments and Authorization
L90 hours in Lieu 4 Authorized by Peter
Total 4
2. Risk reporting
 Indicate the likelihood of meeting the scheduled target date

o Instead of asking the estimated completion date
 Use the traffic-light method
o Steps are,
 Identify the first level elements for assessment.
 Break the first level elements in to second level elements.
 Asses the second level elements and mark the colors.
The traffic-light method
For assessing a product
 Identify the key (first-level) elements
 Break them into smaller components
 Assess each component by
o Green as ‘on target’
o Amber as ‘not on target but recoverable’
o Red as ‘not on target and recoverable only with difficulty’
 Assess the key-level element based on the assessments of their components
 Assess the overall product based on all the assessments (key elements and their
components)

 Review all second level elements to reach the first level assessments.
 Review both first and the second level assessments to produce an overall
assessments.
 Focus on non achievement factors.
 Assessment forms can be used to evaluate the overall status of the project.
 Critical activities denoted by red color.
 Critical activity : activity that cannot be delayed.
 Float : time allowed for an activity to be delay.
 Managers should play attention to the following events :
1. Critical activities classified as Amber or Red
2. Non-Critical activities classified as Red, especially when all their float is
likely to be consumed.
The traffic-light method - Example
Activity Assessment Sheet

Staff : Zobel
Ref : IoE/P/100 Activity : Code and test module A
Week number 13 14 15 16
Activity summary G A R
Component Comments
Screen handling procedures G G A
File updating G A R
Compilation G G A
Run test data G A A
4.1.5. Prioritizing Monitoring (Level of Monitoring)
 Priority list of activity to monitor

o Critical activities
o Non-critical activities with no free float
o Non-critical activities with less than a specified float
o High risk activities
o Activities with critical resources

 Need to spend your energy wisely.

o Free float : The time allowed for an activity to delay without affecting any
subsequent activity
o Total float : The time allowed for an activity to delay without affecting the overall
project
 High risk activities : Activities having a high estimated duration variance (PERT)
o They are most likely to overrun or overspend.
 Activities with critical resources : activities that require a huge amount of resources
require much more attention.
o The reason is obvious. MONEY.
4.1.6 Bringing the Project back to Target
 You are now behind the schedule

 Possible actions :
o Reschedule the target date
o Reschedule other activities with shorter duration
o Reorder the activities
 Reschedule the target date :
o Re-estimate the rest of the project and get a proper target date
o This means delaying the delivery date
o This is, in general, a bad choice.
o It is because this costs money and your company loses the customers (unless your
product is too poor to delivery).
 Reschedule other activities with shorter duration :
o Non-critical activity has float.
o Effectively it means shorter time for the critical activity.
 Reorder the activities
o Sometimes, it is possible to reorder the activities so that the overall duration for the
activities to complete can be shorten.
o This involves the consideration of the precedence requirements for the activities.
4.1.6.1 Shorten the Critical Activities
 Putting pressure on the personnel

 Increasing the resources

o Personnel work longer hours.

o Additional analysts to interview users.
o Competent programmer to code modules in the critical activity.
 Pressure :
o May work for some time.
o People work under high pressure may cost more error.
 Resources :
o Employing new personnel in the team (?) Arguable.
 Shortening a critical path may result in a new critical path.
 Better to check the newly revised schedule again.
4.1.6.2 Reorder the Activities
 Relax the constraints on the start of an activity before the completion of the previous
one.
 Subdivide the components of an activity so that they can be done in parallel.
 The most important of all is to check that the quality of the product is not sacrificed.
 It is because the ‘normal’ practice is disturbed by the changes.
 Relaxing constraints : Example
o Ideal to start user training after acceptance testing.
o In order to avoid late delivery, it might be possible to let the two activities have
some overlap.
o For example, you may want to start the training of a particular feature once its
system testing is completed.
 Subdivide activity :
o Documentation of user manual and training manual.
4.1.7 Acceptance
 Customer has to undergo acceptance testing towards the end of the process.
 Every contract would have defined a time limit for the acceptance testing and the result
has to be produced before the time expires.
 All the payment to the supplier depends on the acceptance testing.
 Every bug that is raised must be fixed within the period of warranty.
4.2 Monitoring the Progress
 Need to monitor time : Visualizing the progress

 Need to monitor cost : Earned Value Analysis

4.2.1 Visualizing Progress
 A manager needs some way of presenting that data to greatest effect.

 Presenting the collected data in a way that is easy to understand.
 Help to easily identify the problem activities or areas that need to be taken care of
 Some methods of presenting picture are,
1. Gantt chart – tracking project progress.
 A static picture showing the current progress of the project.
 It is the simple and the oldest form of representing the progress of the project.
 It consists of activity bar that indicates the scheduled activity dates and the
duration along with the activity floats.
 The reported progress is normally shaded.
 The ‘today cursor’ is used to show which activities are ahead or behind the
schedule.
Advantage : Simple and easy to use.
Disadvantage : Difficult to update manually
 It is because the chart needs to be redrawn once the schedule has been revised.
Fig. 4.2.1

2. Slip chart –Add a slip line on the Gantt chart.

 An alternative view of Gantt chart by providing a visual indication of those
activities which are not on schedule.
 The slip line indicates those activities that are either ahead or behind the schedule
 The more bending is on the slip line, the greater is the variation of the plan.
 Too much bending indicates a need for rescheduling of the overall plan
 If the slip line deviates more towards the non achievement of project objectives
then it has to be reconsidered.
 Additional slip lines can be included at regular intervals.
Fig. 4.2.2
3. Ball charts – way of showing or not targets have been met or not.
 It is represented in the form of circles that indicate the start and the end point
completion of activities.
 Circles of the ball chart mostly contain only two dates the original and the revised
one.
 An activity is denoted by a red circle and green color denotes that the activity is
ahead of its schedule.
 Slippage in the project completion date but it is overcome by the timeline charts.

Fig. 4.2.3 Ball chart provides an incentive for meeting targets
4. The Timeline
 A dynamic picture showing the progress of the project and how the project has
changed through time
 A plot of the elapsed time against the planned time of the activities indicating
o the actual progress of the activities; and
o the rescheduled activities by the end of each week
 Show where and when the targets have changed through the life of a project.
 A perfect straight line down to the diagonal line indicates the activity is on the
schedule.
o Need to be selective.
o Do not put too many activities in the same Timeline.
o Otherwise it will be difficult to trace.
 Recommendation :
1. Put only those critical activities on the Timeline.
2. Put those non-critical activities that have a very short float.

Fig. 4.2.4 Timeline chart at week 7
 Can show the slippage of the activities through the life of the project
o The Gantt chart cannot
 Help to analyze and understand the trends and reason for changes
o to avoid slippage in future projects
 Analyzing the timeline and the reason for changes may help to identify failures in
estimations.
 The Timeline cannot show when an activity starts
4.3 Cost Monitoring
 It is an important component of project control. Not only in itself, but also because it
provides an indication of the effort that has gone into (or at least been charged to) a
project.
 It provides a simple method of comparing actual and planned expenditure.
 The more cost is incurred to complete the activities to keep the project on
schedule.
 The chart does a comparison between the actual and the planned expenditure.
 Cost charts become much more useful if we add projected future costs calculated by
adding the estimated costs of uncompleted work to the costs already incurred.

 Where a computer-based planning tool is used, revision of cost schedules is generally

provided automatically once actual expenditure has been recorded.
Fig. 4.3.1 Cumulative cost chart
4.4 Earned Value Analysis or Earned Value Management

(Cost Monitoring Technique)
 Simply, it is a project monitoring and measurement system that :

1. Establishes a clear relationship between planned accomplishments and actual
accomplishments
2. Reinforces and rewards good planning practices
 Basic concepts of Earned Value Management (EVM)
1. Each task in a project earns value as planned work is completed
2. Earned value can be compared to actual cost and budgeted cost to determine
variance and predict future performance
 The budgeted cost (e.g., dollars, person-hours, person-days, etc.) in terms of your
baseline plan/budget of the work performed up to a specified point in time
1. Also known as Budgeted Cost of Work Performed (BCWP)
 Each task in the Work Breakdown Structure (WBS) is assigned a BCWP based on its
individual cost.
1. Project BCWP is total of BCWP for all tasks required to complete the project

Earned Value Chart
Fig. 4.4.1
Earned Value Indicators
 Planned Value (a.k.a. BCWS)

1. How much work (person-hours) you planned to have accomplished at a given
point in time (this is from the WBS in your plan)
 Actual Cost (a.k.a. ACWP)
1. How much work (person-hours) you have actually spent at a given point in time
 Earned Value (a.k.a. BCWP)
1. The value (person-hours) in terms of your base budget of what you have
accomplished at a given point in time (or, % complete X Planned Value)
ACRONYM TERM / MEANING
FORMULA
AC Actual Cost What did it actually cost us to do the work/complete
the work ?

BAC Budget at How much did we budget to do the work for the
Completion entire/total project ?
CPI Cost Performance The amount of money we are getting back for each
Index $ 1.00 we spent on the project. A measure of
EV/AC efficiency. (Good = > $ 1.00; Bad = $ 1.00)
CV Cost Variance When we check the costs, are we under budget or
EV-AC = over budget ? [Positive = under budget; negative =
over budget] (Good = + Bad = -)
EAC Estimate at Today, what do we anticipate/expect/estimate it will

Completion have cost us to have completed the total or entire
project ?
ETC Estimate to complete From today, what do we think it will cost us to
BAC/CPI = complete the total or entire project ? [We know how
or AC + ETC = or much we spent already up to today, so how much
more will we need to spend to complete all the rest
AC + (BAC-EV) =
of the work to complete the entire/total project ?]
or
AC + (BAC-
EV)/CPI] =
EV Earned Value What is the expected or estimated cost of the work
we have actually completed ?
PV Planned Value What is the expected or estimated cost of the work
we planned to complete or get done ?
SPI Schedule When we check the schedule, we are only
Performance progressing at ____% of the rate we planned to
Index progress at. This is a measure of efficiency.
EV/PV = (Good = > 100%; Bad = < 100%)
SV Schedule Variance When we check the schedule are we ahead of

EV-PV = schedule or behind schedule. [Positive = ahead of
schedule; negative = behind schedule] (Good = +
Bad = -)
VAC Variance at At the end of the project, how much under or over
Completion budget do we expect to be ?
BAC – EAC =

Earned Value Formulas
Earned Value EV = BAC * % Comp

Cost Variance CV = EV - AC
Schedule SV = EV - PV
Variance
Cost Perf CPI = EV / AC
Index
Schedule SPI = EV / PV
Perf Index
Est at EAC = AC / % Comp
Completion
Est to ETC = EAC - AC
Complete
Variance at VAC = BAC - EAC
Completion
New with 4th TCPI = BAC-EV / BAC-AC
Edition
 Analysis
o CPI > 1.0  exceptional performance
o CPI < 1.0  poor performance
o Similar for SPI
Example 4.4.1 : Planned $1500 to complete work package. Scheduled to have been finished today.
Actual expenditure to date is $1350. Estimate work is 2/3 complete.
What are cost and schedule variances ?
Solution :
Cost variance = EV – AC
= $1500(2/3)  $1350
= $1000  $1350
= $350
Schedule variance = EV – PV

= $1500(2/3)  $1500
=  $500
CPI = EV/AC
= ($1500/(2/3) / $1350)
= 1000/1350
= 0.74
SPI = EV/PV
= ($1500(2/3))/$1500
= $1000/$1500
= 0.67
ETC and EAC
Estimate to complete = (BAC  EV)/CPI

= (1500  1000)/0.74
= $676
Estimate at completion = ETC + AC
= $676 + $1350
= $2026
Analysis : In this project both CPI and SPI are less than one so this project is behind
schedule and over budget.
Example 4.4.2 : What do you understand by EVA ? Given the following information for a one year
project :
(i) BCWS = ` 230000/-

(ii) BCWP =` 200000/-
(iii) ACWP = ` 250000/-
Find out
1. Cost Variance (CV)
2. Schedule Variance (SV)
3. Cost performance Index (CPI)
4. Schedule performance index (SPI)
Solution :
1. Cost Variance (CV) = EV  AC = BCWP  ACWP = 200000  250000 =  50000
2. Schedule Variance (SV) = EV  PV = BCWP  BCWS = 200000  230000=  30000

3. Cost performance Index (CPI) = EV/AC = BCWP/ACWP = 200000/250000 = 0.8

4. Schedule performance index (SPI) = EV/PV = BCWP/BCWS = 200000/230000 = 0.87
4.5 Change Control
4.5.1 Some Basics
“Change Control” is a formal process. It is set up to enable project teams to modify the
scope of the project using specified controls and policies. Change can include anything that
would impact the project time, budget, scope, all of which can impact quality. Most of the
time, it’s scope that impacts the other items.
4.5.2 Change Control Process
1. Define the Change Request
Change Control is the process. A Change Request is the documentation used to request
the actual change. Whoever owns the actual request needs to explain it in such a way that the
team understands it well enough to define it. This should be done through appropriate
documentation (whatever the project team or company expects). It can be as simple as an
email or as complex as a formal document.
When defining the change, it’s necessary to have in hand the actual request with all
supporting statements. This should include :
 Actual Request : Statement of the need. This should outline clearly the change item for
the project team to analyze.
 Reason for the Request : Customer impacts if the request cannot be completed or if
considerable time passes before the request can be completed
 Conditions of Success : Customers must be able to define what they expect from the
change.
 Expected Completion : The requester should provide an expected due date for the
item. This doesn’t mean the change will be completed by this date. It’s simply meant to
provide more details for the team to analyze when defining options.
 Expected Value : This should explain why the request is needed. It can either be
something as simple as “better customer experience” or “revised calculation provides
more accurate data” in relation to a report.
2. Submit and Review the Change Request
Once the Change Request is documented, it’s submitted to the project team. Here again,
the process varies from the simple (a phone call or email) to the formal (a memo or meeting).

Unless the request is very simple, It is preferable to review the change with the full team. That
meeting provides the proper venue for the request to be reviewed, and all members have a
chance to ask questions and help make decisions.
There should be two portions to reviewing the Change Request: the formal presentation
or meeting and the project team’s review and discussion of impacts. Within the change control
process there should be an expected turnaround time for these. Discussions with the customer
should include setting expectations regarding response time, or at least when the team will
provide feedback.
3. Define Options and Create Response Document
Once the team has reviewed the Change Request, options should be defined. There
should be a minimum of two. When providing the document response, always provide each
option with some of the data points below as well as a team recommendation, which
represents its view of the best choice. The customer may not always go along, but it can help
them make a decision.
The response should include :
 Option Number and Name
 Proposed Solution : This should include how to respond to the change request. It can
be anything from a technical direction and justification as to why this particular
approach is being put forward.
 Proposed Timeline : The customer always needs to know how long something is going
to take. The estimated timeline is a piece of information they will leverage when
making a choice based on the options the team presents.
 Impacts to the Project : This is an essential part of the response. If changes are small,
there may be no impacts - for instance, if you’re changing a series of messages or
buttons. But most changes will have some sort of impact. The scope change can impact
the timeline, the budget and therefore the quality of the product. This area should
minimally explain the cost of the changes, the impact on the timeline and potential
quality results. There may also be resource impacts. The team may either have to get
additional people or may define a need for existing resources to add or remove time on
the project. All of these items should be defined clearly to enable the customer’s
decision making.
 Expiration Date for Proposed Changes : This sets a timeframe for the client to
respond to the proposed solution and cost/time impacts. If the client goes outside of the
set window, there could be additional impacts to the project. That aside, setting an
expiration date provides urgency to the process.

4. Final Decision and Approval
The customer should provide a timely response. If the Change Control Response
document expires, it should be re-evaluated once the customer provides feedback. If too much
development has occurred to sustain the change, then that needs to be stated. If the delayed
response has resulted in other impacts, they need to be communicated as soon as possible. It’s
also possible that an expired response could lead to an additional review and proposal.
Whatever decision results from all this needs to be officially approved. When you
define the Change Control process, be sure to include a list of sponsors, stakeholders and key
decision makers who can OK both the process and the decision.
Every change control request should follow this process. This isn’t to simply cover the
team. It provides consistency and manages expectations.
4.6 Software Configuration Management
 “SCM is the control of the evolution of complex systems,…, for the purpose to
contribute to satisfying quality and delay constraints.”
 “SCM provides the capabilities of identification, control, status accounting, audit and
review, manufacture, process management, and teamwork.”
 SCM is a key process in Capability Maturity Model (recently updated to CMMI)
o Level 1-Initial : ad hoc/chaotic
o Level 2-Repeatable : basic project management and documentation
o Level 3-Defined : standard and complete process control and procedures
o Level 4-Managed : predictable process performance and precise measurements
o Level 5-Optimizing : continuous and recursive improvement to performance
 SCM operates through the software life cycle.
4.6.1 What is SCM not ?
 Not just version control

 Not just for source code management
 Not only for development phase
 Selecting and using tools are important, but design and management of SCM process
are more crucial for project success

Some Simple SCM Scenarios
 A lives in New Dehli, India and B lives in Boston, US, they want to work on
HelloWorld.java together
 In the latest release, a serious bug is found and manager C wants to track what changes
caused the bug, who made those changes and when
 C wants to get reports about current project progress to decide if she needs to hire more
programmers and delay the alpha release
4.6.2 SCM Terminology
 Configuration Item (CI)

 Version, Variant, and Revision
 Configuration
 Baseline
 Workspace
4.6.2.1 Configuration Item (CI)
 An approved and accepted deliverable, changes have to be made through formal

procedure
 Examples :
o Management plan
o Requirement
o Design specification
o Source code and executable code
o Test specification, data, and records
o Log information
o User documentation
o Library and supporting software
o Bug reports, etc.
4.6.2.2 Version, Variant and Revision
 Version : A CI at one point in its development, includes revision and variant

 Revision : A CI linked to another via revision-of relationship, and ordered in time

 Variant : Functionally equivalent versions, but designed for different settings, e.g.
hardware and software
 Branch : A sequence of versions in the time line
How Versions are Stored
 Full copy of each version

 Delta (differences between two versions)
 Forward delta
 Reverse delta
 Mixed delta
4.6.2.3 Configuration
 An arrangement of functional CIs according to their nature, version and other

characteristics
 Guaranteed to recreate configurations with quality and functional assurance
 Sometimes, configuration needs to record environment details, e.g. compiler version,
library version, hardware platform, etc.
 Simple examples
o Ant buildfile, Makefile
4.6.2.4 Baseline
 A collection of item versions that have been formally reviewed and agreed on, a version
of configuration
 Marks milestones and serves as basis for further development
 Can only be changed via formal change management process
 Baseline + change sets to create new baselines

4.6.2.5 Workspace
 An isolated environment where a developer can work (edit, change, compile, test)
without interfering other developers
 Examples
o Local directory under version control
o Private workspace on the server
 Common Operations
o Import : put resources into version control in repository
o Update : get latest version on the default branch
o Checkout : get a version into workspace
o Checkin : commit changes to the repository
4.6.3 Version Control Models (1/3)
 Basic problem of collaborative work
Fig. 4.6.1

Version Control Models (2/3)
 Model 1-Pessimistic : lock-modify-unlock
Fig. 4.6.2
Problems :
 Forget to unlock
 Parallel work not possible
 Deadlock
Version Control Models (3/3)
Model 2-Optimistic : copy-modify-merge

Fig. 4.6.3

4.6.4 SCM Processes
 Change control process

 Status accounting
 Configuration audit
 Release management
 CM planning
4.6.4.1 Change Control Process
 Submission of Change Request (CR)

 Technical and business evaluation and impact analysis
 Approval by Change Control Board (CCB)
 Engineering Change Order (ECO) is generated stating
o changes to be made
o criteria for reviewing the changed CI
 CI’s checked out
 Changes made and reviewed
 CI’s checked in
4.6.4.2 Status Accounting
 Administrative tracking and reporting of CIs in CM system.

 Examples
o Status of proposed changes.
o Status of approved changes.
o Progress of current version, on or behind schedule.
o Estimate of resources to finish one task.
o Bugs identified by configuration audit.
4.6.4.3 Configuration Audit
 Independent review or examination to assess if a product or process is in compliance

with specification, standards, contractual agreement, or other criteria
 Examples
o Verifies that CIs are tested to satisfy functional requirements.
o Verifies that baseline contains necessary and correct CI versions.

o Ensures that changes made to a baseline comply with the configuration status
reports
4.6.4.4 Release Management
 Creation and availability of a new version of software to the public

 Release format
o Source code + build script + instructions
o Executables packaged for specific platforms
o Other portable formats: Java Web Start, plugins
o Patches and updates: automatic, manual
 Release content
o Source and/or binary, data files, installation scripts, libraries, user and/or developer
documentation, feedback programs, etc.
4.6.4.5 Make a CM Plan
 Standards
o IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042 (SCM), etc.
 CM plan components
o What will be managed (list and organize CIs)
o Who will be responsible for what activities (roles and tasks)
o How to make it happen (design processes for change requests, task dispatching,
monitoring, testing, release, etc.)
o What records to keep (logs, notes, configurations, changes, etc.)
o What resources and how many (tools, money, manpower, etc.)
o What metrics to measure progress and success
4.6.5 CM Tools
 Version control
o RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase
 Bug tracking
o Bugzilla, Mantis Bugtracker, Rational ClearQuest
 Build
o GNU Make and many variants, Ant

 Project management
o Sourceforge.net, freshmeat.net, GForge, DForge
4.7 Managing Contract and Contract Management
4.7.1 Introduction
Usually, there are two or more different legal entities or parties involved in the project,
normally in customer / contractor or contractor / sub-supplier relationships. These different
parties need to sign a contract before starting implementation phase of a project.
In larger projects with a customer / contractor relationship, on the side of the contractor,
a proposal team will own the project management process in definition and planning phase
until the contract is signed. Then, they will hand over to an implementation team. So, in the
first two phases, a proposal manager is in charge who transfers the project responsibility to a
project manager for implementation and closure phase.
4.7.2 What is a Software Contract ?
A Software contract is any agreement between two or more parties where one party
agrees to provide certain deliveries or services, and the other party agrees to pay for those
deliveries or services.
How do we get a contract between two parties ?
sometimes, It is too easy.
Fig. 4.7.1
In extreme cases, it just takes an offer by a company and the simple acceptance of that
offer by the customer, and we have a contract. Typically, we will see some negotiation going
on between the two parties before one of them accepts the last offer of the other party.
However, since it is so easy to end up in a legally binding contract situation, the first step,
generally the offer by the company has to be prepared very carefully. Even for smaller
projects we usually need more than two parties to contribute.

4.7.2.1 Software Contract Modes
 Bespoke development : Kind of system is developed for an individual that is created

from scratch.
o In house development
o Contracted (outsourced)
o exactly meets the need of the customer
o requires a dedicated, well balanced knowledgeable team of people with resources.
o Takes time ( resources may not remain)
 Off the shelf : Denotes what the user buys as it as and called as shrink wrapped
software
o Packages - Ms Word, Ms Excel, Tally etc.
o To be bought and used as it is.
o No functionality and/or interface is modifiable.
o functions available, they are well tested and proven at multiple customer sites ( SW
quality high)
o Best Int’l standards followed
o No time loss
o Specific needs of a customer cannot be met
 COTS – customized off-the-shelf : Represents a basic core system that is modified
based on the requirements of the client.
o Combination of the above
o Better than ‘off the shelf’ and falls short of ‘Bespoke’ development.
4.7.3 Types of Software Contracts
There are three basic types of contracts :

1. Fixed Price Contracts :
 These are also known as Lump Sum contracts.

 The seller and the buyer agree on a fixed price for the project.
 The seller is bound to accept high risk in this type of contract. The buyer is in the least
risk category as the price is already fixed and the seller has agreed to this.
 There must be fully detailed specifications, checklists, project scope statements from
the seller side which the buyer will use.

 Often, sellers may try to cut the scope to deliver the projects on time and within budget.
If the project is finished on time with the desired quality, the project is over for that
contract. However, if the project is delayed and there are cost overruns, then the seller
will absorb all the extra costs.
 Fixed price contracts are typically used in government based projects.
 Advantages of fixed price contracts include :
o Minimizing risk for buyers.
o Known customer expenditure
o Supplier motivation
 The major disadvantage of Fixed Price Contracts is that
o The seller starts cutting scope in order to finish on time and within budget.
o Higher prices to allow for contingency
o Difficulties in modifying requirements
o Upward pressure on the cost of changes
o Threat to system quality
Below are a few types of fixed contracts :
 Fixed Price Incentive Fee (FPIF) – If project ends sooner, an additional amount is
paid to the seller.
 Fixed Price Award Fee (FPAF) – If the performance of the seller exceeds
expectations, an additional amount (say 10% of the total price) will be paid to the
seller.
 Fixed Price Economic Price Adjustment (FPEPA) – The fixed price can be re-
determined depending on the market pricing rate.
2. Cost Reimbursable Contracts :
 What you will do when the scope of the work is not clear? Fixed price contracts
would be out of the question since you are not sure what you need out of the project. In
such cases, ideally you would need to opt for cost reimbursable contracts.
 Under a cost reimbursable contract, the seller will work for a fixed time period, and will
raise the bill after finishing work.
 A major drawback of this type of contract is that the seller can raise an unlimited or
unknown amount which the buyer is compelled to pay. This is why cost reimbursable
contracts are rarely used.

Below are a few types of cost reimbursable contracts :

 Cost Plus Fee (CPF) or Cost Plus Percentage of Costs (CPPC) – The seller will get
the total cost they incurred on the projects plus a percentage of fee over cost. Always
beneficial for the seller.
 Cost Plus Fixed Fee (CPFF) – A fixed amount (for seller) is agreed upon before work
commences. Cost incurred on the project is reimbursed on top of this.
 Cost Plus Incentive Fee (CPIF) – A performance-based extra amount will be paid to
the seller over and above the actual cost they have incurred on the projects.
 Cost Plus Award Fee (CPAF) – The seller will get a bonus amount plus the actual cost
incurred on the projects. Very similar to a CPIF contract.
3. Time and Material Contracts or Unit Price Contracts :
 Unit price contracts are what we call an hourly rate.

 For example, if the seller spends 1,200 hours on a project, and his or her charges are
$100 an hour, the seller will be paid for $120,000 by the buyer.
 This type of contract is typical in freelance work.
 The main advantage of this type of contract is that the seller will make money for
every hour he spends on the project.
4.7.4 Contact Placement
Fig. 4.7.2 Stages in contract placement

4.7.4.1 Requirements Analysis
 Preparation of an requirement document

 Introduction
 Description of the existing system
 Current environment of the system

 Customer’s future plans

 System requirements based on either mandatory or desirable
 Deadlines have to be defined
 Additional information requires from the potential suppliers.
4.7.4.2 Evaluation Plan
 Preparing a plan to evaluate the submitted proposals.

 Evaluating the desirable requirements
 Validating the quality of the software system
 Cost incurred for the life time of the proposed system.
4.7.4.3 Invitation to Tender
 Invitation to tender is not an offer itself but an invitation for prospective suppliers to
make an offer.
 System requirements
 Defining the scope of the system
 Instruction to the bidders
o Instruction to the bidders
o List of the software products
o Technical constraints
4.7.4.4 Evaluation of Proposals
 Evaluation has to be done in a planned manner

 Questioning supplier representatives
 Visiting the site of the development process
 Conducting practical tests
 Reduces risk of requirements.
4.7.5 Typical Terms of a Contract
Definitions
The terminology used in the contract document may need to be defined, for example,
who is meant by the words 'client' and 'supplier'.

Form of agreement
For example, is it a contact of sale, a lease, or a licence ? Also, can the subject of the
contract, such as a licence to use a software application, be transferred to another party ?
Goods and services to be supplied
Equipment and software to be supplied This includes an actual list of the individual
pieces of equipment to be delivered, complete with the specific model numbers.
Services to be provided This covers such things as :
 documentation;
 installation;
 conversion of existing files;
 maintenance agreements;
 transitional insurance arrangements.
Ownership of the software
Who has ownership of the software? There are two key issues here: firstly, whether the
customer can sell the software to others and, secondly, whether the supplier can sell the
software to others. Where off-the-shelf software is concerned, the supplier often simply grants
a license for you to use the software. Where the software is being written specially for a
customer, then that customer will normally wish to ensure exclusive use of the software - they
may object to software which they hoped would give them a competitive edge being sold to
their rivals. They could do this by acquiring the copyright to the software outright or by
specifying that they should have exclusive use of the software. This would need to be written
into the contract. Where a core system has been customized by a supplier, then there is less
scope for the customer to insist on exclusive use.
Where software is written by an employee as part of a contract of employment, it is
assumed that the copyright belongs to the employer. Where the customer organization has
contracted an external supplier to write software, the contract needs to make clear who is
going to retain the copyright - it cannot, in this case, be automatically assumed it is the
customer. The customer might have decided to take over responsibility for maintenance and
further development once the software is delivered and in this case will need access to the
source code. In other cases, where the customer does not have an adequate in-house
maintenance function, the supplier can retain the source code, and the customer will have to
approach the supplier for any further changes. There are many potential dangers with this, not
the least being that the supplier could go out of business. An escrow agreement can be

included in the contract so that up-to-date copies of the source code are deposited with a third
party. In the United Kingdom, the National Computing Centre provide an escrow service.
Environment
Where physical equipment is to be installed, the demarcation line between the supplier's
and customer's responsibilities with regard to such matters as accommodation and electrical
supply needs to be specified. Where software is being supplied, the compatibility of the
software with the existing hardware and operating system platforms would need to be
confirmed.
Customer commitments
Even when work is carried out by external contractors, a development project still needs
the participation of the customer. The customer will have to provide accommodation for the
suppliers and perhaps other facilities such as telephone lines.
Acceptance procedures
Good practice would be to accept a delivered system only after it has undergone user
acceptance tests. This part of the contract would specify such details as the time that the
customer will have to conduct the tests, deliverables upon which the acceptance tests depend
and the procedure for signing off the testing as completed.
Standards
This covers the standards with which the goods and services should comply. For
example, a customer can require the supplier to conform to the ISO 12207 standard relating to
the software life cycle and its documentation (or, more likely, a customized sub-set of the
standard). Within the European Union, government customers with contracts for projects
above a certain threshold value must, by law, ensure that the work conforms to certain
standards.
Some customers find that specially written or modified software is not thoroughly
tested by the supplier before delivery. Some suppliers seem to think that it is cheaper to get the
customer to do the testing for them!
Project and quality management
The arrangements for the management of the project must be agreed. Among these
would be frequency and nature of progress meetings and the progress information to be
supplied to the customer. The contract could require that appropriate ISO 9000-series
standards be followed. The ISO 12207 standard provides for the customer to have access to

quality documentation generated internally by the supplier, so that the customer can ensure
that there is adherence to standards.
Timetable
This provides a schedule of when the key parts of the project should be completed. This
timetable will commit both the supplier and the customer. For example, the supplier might be
able to install the software on the agreed date only if the customer makes the hardware
platform available at that point.
Price and payment method
Obviously the price is very important! What also needs to be agreed is when the
payments are to be made. The supplier's desire to be able to meet costs as they are incurred
needs to be balanced by the customer's requirement to ensure that goods and services are
satisfactory before parting with their money.
Miscellaneous legal requirements
This is the legal small print. Contracts often have clauses that deal with such matters the
legal jurisdiction that will apply to the contract, what conditions would apply to the sub-
contracting of the work, liability for damage to third parties, and liquidated damages.
Liquidated damages are estimates of the financial losses that the customer would suffer if the
supplier were to fall short of their obligations. It is worth noting that under English law, the
penalties laid down in penalty clauses must reflect the actual losses the customer would suffer
and cannot be unrealistic and merely punitive. Even this limitation will not be enough in some
cases as far as the supplier is concerned. As computer systems assume increasingly critical
roles in many organizations and in safety-critical systems can even be life-threatening in the
case of malfunction, the possible consequential damage could be very great. Suppliers will not
unnaturally try to limit this kind of liability. The courts (in England and Wales) have tended to
look critically at such attempts at limiting liability, so that suppliers will, in the case of major
contracts, take out insurance to cover such liabilities.
If there is a dispute, resorting to litigation, while being lucrative to the lawyers
involved, is both time-consuming and expensive. An alternative is to agree that disputes be
settled by arbitration. This requires that any dispute be referred to an expert third party whose
decision as to the facts of the case is binding. Even this procedure is seldom quick and
inexpensive and another option is alternative dispute resolution where a third party acts as a
mediator who has only an advisory capacity and attempts to broker an agreement between the
two sides.

4.7.6 Contract Management
 Contract management is a continuous process, starting with analysis and evaluation of

the customer’s inquiry, and carrying on until contract closure, upon fulfillment of all
contractual obligations.
Fig. 4.7.3
 It is the process of managing contract creation, execution and analysis to maximize

operational and financial performance at an organization, all while reducing financial
risk. Organizations encounter an ever-increasing amount of pressure to reduce costs and
improve company performance. Contract management proves to be a very time-
consuming element of business, which facilitates the need for effective and automated
contract management system.
4.7.6.1 The Fundamentals of Contract Management
When two companies wish to do business with each other, a contract specifies the
activities entered into by both organizations and the terms through which they will each fulfill
their parts of the agreement. Contracts affect business profitability in a very large way due to
the emphasis on revenue and expenses. When a contract is phrased poorly, one organization
might lose countless thousands of dollars over a simple technicality they lacked the resources
to identify. Effective contract management can ultimately create a powerful business
relationship and pave the road to greater profitability over the long-term, but only when
managed correctly.
4.7.6.2 Elements of Successful Contract Management
It isn’t enough that an organization has professionals in place to handle contract

management. Employees must be augmented with the presence of processes and software
companions to satisfy increasing compliance and analytical needs. When a contract
management strategy is successfully implemented, organizations can expect to see :
 The expected business benefits and financial returns are being realized.
 The supplier is cooperative and responsive to the organization’s needs.
 The organization encounters no contract disputes or surprises.
 The delivery of services is satisfactory to both parties.

4.7.6.3 Contract Management Process
Contracts play a significant role in the end-of-quarter crunch and are broken up into
stages to organize efforts and structure the typical contract process. When done manually,
creating a contract can prove quite time consuming. The process includes the following steps :
1. Initial requests : The contract management process begins by identifying contracts and
pertinent documents to support the contract’s purpose.
2. Authoring contracts : Writing a contract by hand is a time-consuming activity, but
through the use of automated contract management systems the process can become
quite streamlined.
3. Negotiating the contract : Upon completion of drafting the contract, employees should
be able to compare versions of the contract and note any discrepancies to reduce
negotiation time.
4. Approving the contract : The instance in which most bottlenecks occur is getting
management approval. Users can preemptively combat this by creating tailored
approval workflows, including parallel and serial approvals to keep decisions moving at
a rapid pace.
5. Execution of the contract : Executing the contract allows users to control and shorten
the signature process through the use of eSignature and fax support.
6. Obligation management : This requires a great deal of project management to ensure
deliverables are being met by key stakeholders and the value of the contract isn’t
deteriorating throughout its early phases of growth.
7. Revisions and amendments : Gathering all documents pertinent to the contract’s
initial drafting is a difficult task. When overlooked items are found, systems must be in
place to amend the original contract.
8. Auditing and reporting : Contract management does not simply entail drafting a
contract and then pushing it into the filing cabinet without another thought. Contract
audits are important in determining both organizations’ compliance to the terms of the
agreement and any possible problems that might arise.
9. Renewal : Using manual contract management methods can often result in missed
renewal opportunities and business revenue lost. Automating the process allows an
organization to identify renewal opportunities and create new contracts.
4.7.6.4 Activities that Make up Good Contract Management
The foundation for contract management relies on the implementation of successful

post-award and upstream activities. During the pre-award stage, employees should focus on

the reason for establishing the contract and if the supplier can fulfill the terms of the
agreement. Additional consideration is needed to understand how the contract will work once
awarded. Avoiding unwanted surprises require careful research and clarity of purpose in the
actual contract.
Contract management requires a level of flexibility for both parties involved and a
willingness to adapt contract terms to reflect any changing circumstances. Problems are
inevitable, which means organizations must be prepared for the unexpected and be able to
adjust contract terms when needed.
4.7.6.5 Contract Management Software
While the tradition is normally to manage contracts manually through folder and file
cabinet storage, the practice is riddled with inefficiencies that can only detract from an
organization’s overall efficiency. Integrating with an automated contract management service
will help free up countless man hours and automate countless processes associated with
managing a contract, thus creating more value for a company.
4.7.7 Difference between Project Management and Control Management
PM is all about managing all aspects of the project to ensure that it is completed and to
deliver the result within the main project constraints ( Scope, Time, Cost & Quality) which are
basically in accordance to the contract
Contract Management is part of procurement function where to it is to ensure that terms
and commitments agreed in the contract are adhered to. Contract Managers are also generally
responsible for ensuring that projects are delivered on budget or delivered profitably. and
sometimes looking after the economics of project and to manage claims and disputes against
the contract.
4.8 Project Monitoring and Controlling Process in Detail
 The Monitoring and Control Process Group consists of those processes performed to
observe project execution so that potential problems can be identified in a timely
manner and corrective action can be taken, when necessary, to control the execution of
the project.
 Project Monitoring and Control activities take place in parallel with Project Execution
Process Group activities so that, while the project work is being executed, the project is
being monitored and controlled by implementing the appropriate level of oversight and
corrective action.

 The project is observed and measured regularly against the project plan to ensure that
the project is within acceptable variances of cost, schedule and scope, and that risks and
issues are continually monitored and corrected as needed
 The executing, monitoring, and controlling phases of the project management lifecycle
consists of completing and managing the work required to meet the project objectives.
This phase also ensures that the project performance is monitored and adjustments to
the project schedule are made as needed.
Fig. 4.8.1
Notes and
Activity Description Inputs Outputs Owner
Resources
The Project Manager is

responsible for ensuring that
decisions that need to be
Maintaining a
made are made before they Project
decision tracking log
impact the project and that Discussion decision
Manage and Project is an optional
the decisions are placed in from project tracking log
track decisions Manager activity. A sample
the repository of record for team
decision log is
future reference. This is Decision
available.
especially important for
projects that have a long
duration or high turnover as

this mitigates the likelihood

of rehashing decisions that
were made early in the
project. When a decision is
recorded the following
information is recommended:
Date of decision, description
of trigger and final decision
made by the project team.
The project charter defines

the project change
management process that will Project
Project
be used to manage significant Manager A sample change
Project change change Project
changes to the project scope, and request form and log
management request form change
budget, or schedule. During Project are available.
and log
the monitoring and Sponsor
controlling phase, this
process must be executed.
The Project Manager is Updated

A sample action
Manage and responsible for ensuring that action items
Project Project items tracking
track action tasks too small to appear in list and
action items Manager workbook is
items the project schedule are completed
available.
recorded and completed. task
The various forums and

communication mechanisms
identified in the
Project
communication plan continue
communicati
to be performed as the
on log Project
project progresses. As the
Execute and (optional) Manager
project moves into new Project
revise and
phases, additional types of communicat
communication Resulting Communi
communication activities ion plan
plan project cations
may become necessary and
communicati Lead
activities previously done
on plan
may need to evolve or be
changes
eliminated as participants
change or the project focus
shifts
Keep the project schedule Task status Discuss and

Execute and Updated
updated by obtaining status Issues Project communicate any
revise project project
on project tasks and updating Approved Manager changes to the project
schedule schedule
those tasks in the project change schedule with the

schedule. The project requests team. If the changes

schedule should be Decisions result in delay, or
monitored and updated new risks to the
regularly. project, notify the
project sponsor and
stakeholders as early
as possible.
An initial list of risks and

management approaches are
identified in the project
charter. The project manager Project
Monitor and Implemented A risk register and
must monitor the risk list, charter Project
manage risks contingency issue log templates
identify any that have (risks Manager
and issues plan are available.
become issues, and section)
implement the contingency
plan identified in the project
charter.
Need of project monitoring and controlling
 Simply because we know that things don’t always go according to plan (no matter how
much we prepare).
 To detect and react appropriately to deviations and changes to plans.
 To be proactive in finding issues ahead of time and taking corrective action.
4.8.1 Techniques for Monitoring and Control
 Earned Value Analysis

o A way of measuring overall performance (not individual task) is using an aggregate
performance measure - Earned Value.
o Earned value of work performed (value completed) for those tasks in progress
found by multiplying the estimated percent physical completion of work for each
task by the planned cost for those tasks. The result is amount that should be spent
on the task so far. This can be compared with actual amount spent.
 Critical Ratio
o Sometimes, especially large projects, it may be worthwhile calculating a set of
critical ratios for all project activities.
o The critical ratio is

Actual process Budgeted cost

Scheduled progress  Actual cost
o If ratio is 1 everything is probably on target
o The further away form 1 the ratio is, the more we may need to investigate
How these processes affect the project schedule
1. Updates to the schedule model data and baseline

2. Performance measurements
3. Requested changes
4. Recommended corrective actions
5. Updates to organizational process assets
6. Activity list and activity attribute updates
7. Updates to the Project Management Plan
Q.1 What is the use of Checkpoints in Monitoring ? (Refer section 4.1.4.1)

Dec. - 2012 .
Q.2 Describe the various ways in visualizing the progress of the project.
(Refer section 4.2) Dec. - 2012 ..
Q.3 Discuss the Contract Management in detail. (Refer section 4.7.6)
Dec. - 2013 .
Q.4 Give the formula for Earned value analysis. (Refer section 4.4) Dec. - 2013 ..
Q.5 State Earned Value Analysis. (Refer section 4.4) May - 2014 ..
Q.6 Explain the “Earned Value” Analysis Method in detail. (Refer section 4.4)
Dec. - 2014 ..
Q.7 Mention the advantages and disadvantages of Fixed Price Contracts.
(Refer section 4.7.3) Dec. - 2013 ..
Q.8 Define Contract. Explain the stages in contract placement with its typical terms.
Q.9 List down the typical terms in a contract and Explain them in detail.
Q.10 Define Contract. Explain the typical terms of a Contract. Give Examples.
(Refer section 4.7) May- 2014 ..
Q.11 Discuss the types of Contracts with Example. (Refer section 4.7.3)
Dec. - 2012 .
Q.12 What is Time and Material Contract. (Refer section 4.7.3) Dec. - 2014 ..

Q.13 Distinguish between Contract Management and Technical Project Management.

Q.14 Explain the formal models for cost monitoring with its metrics.
Q.15 Outline the various steps involved in a Change Control Procedure.
Q.16 Explain the level of Monitoring with examples. (Refer section 4.1.5)
Dec. - 2013 .
Q.17 Describe the steps in project Control. (Refer section 4.8) Dec. - 2013 .
Q.18 What is a Slip Chart? Mention its use. (Refer section 4.2) Dec. - 2014 .
Q.19 Explain the process of Prioritizing Monitoring. Give Example.
(Refer section 4.1.5) Dec. - 2012, May - 2014 .
Q.20 Define Acceptance. (Refer section 4.1.7) Dec. - 2013, May - 2014 .
Q.21 What is Bespoke System. (Refer section 4.7.2) Dec. - 2012 .
Project Management and Control ends....

Notes

Staffing in Software Projects
Unit - IV
Chapter - 5
STAFFING IN SOFTWARE PROJECTS
Syllabus : Managing people - Organizational behavior - Best methods of staff selection -

Motivation - The Oldham-Hackman job characteristic model - Ethical and
Programmed concerns - Working in teams - Decision making - Team structures -
Virtual teams - Communications genres - Communication plans.

5.1 Managing People 5-2
5.2 Organisation Behaviour 5 - 13
5.3 Best Methods of Staff Selection 5 - 20
5.4 Motivation 5 - 22
5.5 Job Characteristics Model 5 - 30
5.6 Ethical and Programmed Concerns 5 - 34
5.7 Working in Groups and Becoming A Team 5 - 39
5.8 Decision Making 5 - 42
5.9 Team Structures 5 - 44
5.10 Virtual Teams 5 - 48
5.11 Communication Genres (Types of Communication) 5 - 55
5.12 Communication Plans 5 - 57
5.13 Organizational Structure 5 - 67
5.14 Leadership 5 - 71

5.1 Managing People
 Managing people working as individuals and in groups

5.1.1 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.
 Software engineering is primarily a cognitive activity. Cognitive limitations effectively
limit the software process.
5.1.2 People Management Factors
 Consistency
o Team members should all be treated in a comparable way without favourites or
discrimination.
 Respect
o Different team members have different skills and these differences should be
respected.
 Inclusion
o Involve all team members and make sure that people’s views are considered.
 Honesty
o You should always be honest about what is going well and what is going badly in a
project.
5.1.3 People Management Task
 Selecting staff
 Motivating people
 Managing groups
 The people capability maturity model
5.1.3.1 Selecting Staff
 An important project management task is team selection.
 Information on selection comes from :
o Information provided by the candidates.

o Information gained by interviewing and talking with candidates.

o Recommendations and comments from other people who know or who have
worked with the candidates.
Staff selection case study 1
Alice is a software project manager working in a company that develops alarm systems.
This company wishes to enter the growing market of assistive technology to help elderly and
disabled people live independently. Alice has been asked to lead a team of 6 developers than
can develop new products based around the company’s alarm technology. Her first role is to
select team members either from software engineers already in the company or from outside.
To help select a team, Alice first assesses the skills that she will need : These are :
 Experience with existing alarm technology as it is reused.
 User interface design experience because the users are untrained and may be disabled
and hence need facilities such as variable font sizes, etc.
 Ideally, someone who has experience of designing assistive technology systems.
Otherwise, someone with experience of interfacing to hardware units as all systems
being developed involve some hardware control.
General purpose development skills.
Staff selection case study 2
The next stage is to try and find people from within the company with the necessary
skills. However, the company has expanded significantly and has few staff available. The best
that Alice can negotiate is to have help from an alarm expert (Fred) for 2 days/week. She
therefore decides to advertise for new project staff, listing the attributes that she’d like :
 Programming experience in C. She has decided to develop all the assistive technology
control software in C.
 Experience in user interface design. A UI designer is essential but there may not be a
need for a full-time appointment.
 Experience in hardware interfacing with C and using remote development systems. All
the devices used have complex hardware interfaces.
 Experience of working with hardware engineers. At times, it will be necessary to build
completely new hardware.
A sympathetic personality so that they can relate to and work with elderly people who
are providing requirements for and are testing the system.

Staff selection factors 1
Application domain For a project to develop a successful system, the developers must
experience understand the application domain. It is essential that some members
of a development team have some domain experience.
Platform experience This may be significant if low-level programming is involved.
Staff selection Otherwise, not usually a critical attribute.
factors 2
Programming This is normally only significant for short duration projects where
language experience there is not enough time to learn a new language. While learning a
language itself is not difficult, it takes several months to become
proficient in using the associated libraries and components.
Problem solving This is very important for software engineers who constantly have to
ability solve technical problems. However, it is almost impossible to judge
without knowing the work of the potential team member.
Educational This may provide an indicator of the basic fundamentals that the
background candidate should know and of their ability to learn. This factor
becomes increasingly irrelevant as engineers gain experience across a
range of projects.
Communication This is important because of the need for project staff to communicate
ability orally and in writing with other engineers, managers and customers.
Adaptability Adaptability may be judged by looking at the different types of
experience that candidates have had. This is an important attribute as
it indicates an ability to learn.
Attitude Project should have a positive attitude to their work and should be
willing to learn new skills. This is an important attribute but often
very difficult to assess.
Personality This is an important attribute but difficult to assess. Candidates must
be reasonably compatible with other team members. No particular
type of personality is more or less suited to software engineering.
5.1.3.2 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 there are different types of motivation
based on :
o Basic needs (e.g. food, sleep, etc.);

o Personal needs (e.g. respect, self-esteem);

o Social needs (e.g. to be accepted as part of a group).
Human needs hierarchy
Motivating people
 Motivations depend on satisfying needs

 It can be assumed that physiological and safety needs are satisfied
 Social, esteem and self-realization needs are most significant from a managerial
viewpoint
Need satisfaction
 Social
o Provide communal facilities;
o Allow informal communications.
 Esteem
o Recognition of achievements;
o Appropriate rewards.
 Self-realization
o Training - people want to learn more;
o Responsibility.
Individual motivation
Alice’s assistive technology project starts well. Good working relationships develop
within the team and creative new ideas are developed. However, some months into the project,
Alice notices that Dorothy, the hardware design expert starts coming into work late, the
quality of her work deteriorates and, increasingly, she does not appear to be communicating
with other members of the team. Alice talks about the problem with other team members to try

to find out if Dorothy’s personal circumstances have changed and if this might be affecting
her work. They don’t know of anything so Alice decides to talk with Dorothy to try to
understand the problem.
After denying that there is a problem, Dorothy admits that she seems to have lost
interest in the job. She expected a job where she would develop and use her hardware
interfacing skills. However, she is basically working as a C programmer with other team
members and she is concerned that she is not developing her interfacing skills. She is worried
that she will find it difficult to find a job after this project that involves hardware interfacing.
Because she does not want to upset the team by revealing that she is thinking about the next
project, she has decided that it is best to minimise conversation with them.
Personality types
 The needs hierarchy is almost certainly an over-simplification of motivation in practice.

 Motivation should also take into account different personality types :
o Task-oriented;
o Self-oriented;
o Interaction-oriented.
 Task-oriented.
o The motivation for doing the work is the work itself;
 Self-oriented.
o 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
o The principal motivation is the presence and actions of co-workers. People go to
work because they like to go to work.
Motivation balance
 Individual motivations are made up of elements of each class.

 The balance can change depending on personal circumstances and external events.
 However, people are not just motivated by personal factors but also by being part of a
group and culture.
 People go to work because they are motivated by the people that they work with.

5.1.3.3 Managing Groups

 Most software engineering is a group activity
o 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
o Managers must do the best they can with available people.
Time distribution
Factors influencing group working
1. Group composition.
2. Group cohesiveness.
3. Group communications.
4. Group organisation.
5. Working environments
1. Group composition
 Group composed of members who share the same motivation can be problematic
o Task-oriented - everyone wants to do their own thing;
o Self-oriented - everyone wants to be the boss;
o 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.

In creating a group for assistive technology development, Alice is aware of the

importance of selecting members with complementary personalities. When interviewing
people, she tried to assess whether they were task oriented, self-oriented and interaction
oriented. She felt that she was primarily a self-oriented type as she felt that this project was a
way in which she would be noticed by senior management and promoted. She therefore
looked for 1 or perhaps 2 interaction-oriented personalities with the remainder task oriented.
The final assessment that she arrived at was :
Alice – self-oriented
Brian – task-oriented
Bob – task-oriented
Carol – interaction-oriented
Dorothy – self-oriented
Ed – interaction-oriented
Fred – task-oriented
Group leadership
 Leadership depends on respect not titular status.

 There may be both a technical and an administrative leader.
 Democratic leadership is more effective that autocratic leadership.
2. 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 :
o Group quality standards can be developed;
o Group members work closely together so inhibitions caused by ignorance are
reduced;
o Team members learn from each other and get to know each other’s work;
o Egoless programming where members strive to improve each other’s programs can
be practised.
Team spirit
Alice is an experienced project manager and understands the importance of creating a
cohesive group. As the product development is new, she takes the opportunity of involving all
group members in the product specification and design by getting them to discuss possible
technology with elderly members of their families and to bring these to the weekly group
lunch. The group lunch is an opportunity for all team members to meet informally, talk around
issues of concern and, generally, get to know each other.

The lunch is organised as an information session where Alice tells the group members
what she knows about organisational news, policies, strategies, etc. Each team member then
briefly summarises what they have been doing and the group then discusses some general
topic such as new product ideas from elderly relatives.
Every few months, Alice organises an ‘away day’ for the group where the team spend
two days on ‘technology updating’. Each team members prepares an update on some relevant
technology and presents it to the group. This is an off-site meeting in a good hotel and plenty
time is scheduled for discussion and social interaction.
Developing cohesiveness
 Cohesiveness is influenced by factors such as the organisational culture and the

personalities in the group.
 Cohesiveness can be encouraged through
o Social events;
o Developing a group identity and territory;
o Explicit team-building activities.
 Openness with information is a simple way of ensuring all group members feel part of
the group.
Group loyalties
 Group members tend to be loyal to cohesive groups.

 Groupthink' is preservation of group irrespective of technical or organizational
considerations.
 Management should act positively to avoid groupthink by forcing external involvement
with each group.
3. 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.
 Group size
o The larger the group, the harder it is for people to communicate with other group
members.

 Group structure
o Communication is better in informally structured groups than in hierarchically
structured groups.
 Group composition
o Communication is better when there are different personality types in a group and
when groups are mixed rather than single sex.
 The physical work environment
o Good workplace organisation can help encourage communications.
4. 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.
Informal groups
 The group acts as a whole and comes to a consensus on decisions affecting the system.
 The group leader serves as the external interface of the group but does not allocate
specific work items.
 Rather, work is discussed by the group as a whole and tasks are allocated according to
ability and experience.
 This approach is successful for groups where all members are experienced and
competent.
Extreme programming groups
 Extreme programming groups are variants of an informal, democratic organisation.
 In extreme programming groups, some ‘management’ decisions are devolved to group
members.
 Programmers work in pairs and take a collective responsibility for code that is
developed.
Chief programmer teams
 Consist of a kernel of specialists helped by others added to the project as required.

 The motivation behind their development is the wide difference in ability in different
programmers.
 Chief programmer teams provide a supporting environment for very able programmers
to be responsible for most of the system development.

Problems
 This chief programmer approach, in different forms, has been successful in some
settings.
 However, it suffers from a number of problems
o Talented designers and programmers are hard to find. Without exceptional people
in these roles, the approach will fail;
o Other group members may resent the chief programmer taking the credit for
success so may deliberately undermine his/her role;
o There is a high project risk as the project will fail if both the chief and deputy
programmer are unavailable.
o The organisational structures and grades in a company may be unable to
accommodate this type of group.
5. Working environments
 The physical workplace provision has an important effect on individual productivity

and satisfaction
o Comfort;
o Privacy;
o Facilities.
 Health and safety considerations must be taken into account
o Lighting;
o Heating;
o Furniture.
Environmental factors
 Privacy - each engineer requires an area for uninterrupted work.

 Outside awareness - people prefer to work in natural light.

 Personalization - individuals adopt different working practices and like to organize their
environment in different ways.
Workspace organisation
 Workspaces should provide private spaces where people can work without interruption
o Providing individual offices for staff has been shown to increase productivity.
 However, teams working together also require spaces where formal and informal
meetings can be held.
Office layout
 Managed. Quantitative goals for people management in place

 Optimizing. Continuous focus on improving individual competence and workforce
motivation

5.1.3.4 The People Capability Maturity Model

 Intended as a framework for managing the development of people involved in software
development.
P-CMM Objectives
 To improve organisational capability by improving workforce capability.

 To ensure that software development capability is not reliant on a small number of
individuals.
 To align the motivation of individuals with that of the organisation.
 To help retain people with critical knowledge and skills.
P-CMM levels
 Five stage model

o Initial. Ad-hoc people management
o Repeatable. Policies developed for capability improvement
o Defined. Standardised people management across the organisation
5.2 Organisation Behaviour
 Organisation behaviour is concerned with the study of what people do in an

organisation and how that behaviour affects the performance of the organisation.”
 Organizational behaviour also deals heavily in culture. Company or corporate culture is
difficult to define but is extremely relevant to how organizations behave. A Wall Street
stock-trading company, for example, will have a dramatically different work culture
than an academic department at a university.

Three basic objectives are,
i) To select the best people for the job.

ii) To instruct them in the best methods.
iii) To give incentives in the form of higher wages to the best workers.
 The encouragement to the staff will help the project group to work together in
achieving their goals which ultimately increases thee productivity.
5.2.1 The Study of Organisational Behaviour Involves
 Consideration of the interaction among the formal structure (organisational context in
which the process of management takes place)
 The tasks to be undertaken
 The technology employed and the methods of carrying out work
 The behaviour of people
 The process of management
 The external environment
5.2.2 Interrelated Dimensions Influencing Behaviour
 The Individual - Working environment should satisfy individual needs as well as
attainment of organisational goals.
 The Group - Formal and informal. Understanding of groups complements a
knowledge of individual behaviour.
 The Organisation - Impact of organisation structure and design, and patterns of
management, on behaviour.
 The Environment - Technological and scientific development, economic activity,
governmental actions.
5.2.3 Management Theory
 Theory provides a sound basis for action BUT if the action is to be effective the theory
must be adequate and appropriate to the task and to improved organisational
performance.
 In theory, theory and practice are the same.
 In practice, theory and practice are different.
5.2.4 Division of Labour
Definition :
“The extent to which the organisation’s work is separated into different jobs to be done
by different people.”

5.2.4.1 Functions
 Major purpose or function
 Product or service
 Location
 Nature of the work performed
 Common time scales
 Common processes
 Staff employed
 Customer or people to be served
5.2.4.2 Advantages and Disadvantages
Advantages
 Efficient use of labour

 Reduced training costs
 Increased standardisation and uniformity of output
 Increased expertise from repetition of tasks
Disadvantages
 Routine, repetitive jobs

 Reduced job satisfaction
 Decreased worker involvement and commitment
 Increased worker alienation
 Possible incompatibility with computerised manufacturing technologies
5.2.4.3 Decisions on Division of Work Should take Account of
 The need for co-ordination
 The identification of clearly defined divisions of work
 Economy
 The process of managing the activities
 Avoiding conflict
 The design of work organisation should take account of the nature and interests of staff
and job satisfaction.

5.2.5 Mintzberg’s Five Basic Elements of Structure

Mintzberg’s five basic elements of structure which serve as co-ordinating mechanisms
for the work of the organisation.
1. Mutual adjustment
2. Direct supervision
3. Standardisation of work processes
4. Standardisation of work output
5. Standardisation of worker skills
5.2.6 Evolution of Organizational Behaviour
5.2.6.1 Classical Approach
 Emphasis on purpose, formal structure, hierarchy of management, technical
requirements and common principles of organisation.
 This perspective was concerned with structuring organisations effectively.
 Two major sub-groupings of this approach are :
o Bureaucracy
o Scientific management (sometimes categorised as an approach in its own right)
Major Contributors :
i) Henri Fayol
ii) Linda Urwick
iii) Max Weber – most prominent of the three.
 Weber proposed a bureaucratic form of structure that he believed would work for all
organisations.
 Embraced logic, rationality, efficiency.
1. Bureaucracy
Weber’s Ideal Bureaucracy
 Job specialisation
 Authority hierarchy
 Formal selection
 Formal rules and regulations
 Impersonality
 Career orientation

Criticisms of Bureaucracy
 Lack of attention to the informal organisation.

 Restriction of psychological growth
 Bureaucratic dysfunction
2. Scientific Management
 Emphasis on obtaining increased productivity from individual workers through the

technical structuring of the work organisation and the provision of monetary incentives
as the motivator for higher levels of output.
 Major contributor - FW Taylor (1856 - 1917) - held the view that there was a best
working method by which people should undertake their jobs
Taylor’s principles
 The development of a true science for each person’s work

 The scientific selection, training and development of the workers
 Co-operation with the workers to ensure work is carried out in the prescribed way
 The division of work and responsibility between management and the workers.
Reactions against scientific management
 Opposition because its specific goal was to get more output from the workers
 Argument that his incentive system would dehumanise the workplace
 Inadequate views of employee motivation
 Allegations that he falsified some of his research findings and paid someone to do his
writing for him.
5.2.6.2 Human Relations Approach
 During the 1920s, attention began to focus on social factors at work, groups, leadership,
the informal organisation and behaviour of people.
 ‘Behavioural’ and ‘informal’ are alternative headings sometimes given to this approach.
 Turning point came with the famous Hawthorne experiments at the Western Electric
Company in America (1924-32)
 One of the researchers (leader) was Elton Mayo (1880-1949)
Four main phases to the Hawthorne experiments
 The illumination experiments - Level of production was influenced by factors other

than changes in physical conditions of work.

 The relay assembly test room - Attention and interest by management reason for
higher productivity.
 The interviewing programme -20,000 interviews. Gave impetus to present-day
personnel management and use of counselling interviews. Highlighted the need for
management to listen to workers.
 The bank wiring observation room - Piecework incentive scheme. Group pressures
stronger than financial incentives offered by management.
5.2.6.3 Neo-Human Relations Approach
 Writers in the 1950s and 1960s who adopted a more psychological orientation.
 Major focus was the personal adjustment of the individual within the work organisation
and the effects of group relationships and leadership styles.
 Main contributors : Maslow, Herzberg and Mcgregor.
1. Maslow’s Hierarchy of Human Needs
General Examples Needs Organisational Examples
Achievement Self-Actualisation Challenging job

Status Esteem Job title
Friendship Belongingness Friends in the work group
Stability Security Pension plan

Sustenance Physiological Base salary
2. Herzberg Theory
 Herzberg isolated two different sets of factors affecting motivation and satisfaction at
work.
1. Hygiene or Maintenance Factors - Concerned basically with job environment.
Extrinsic to the work itself.
2. Motivators or Growth Factors - Concerned with job content. Intrinsic to the
work itself.
Goal of managers is to achieve a state of no dissatisfaction by addressing hygiene
factors. Task of improving motivation is then by addressing the Motivators.

3. Mcgregor Theory
Mcgregor argued that the style of management adopted is a function of the manager’s
attitudes towards human nature and behaviour at work.
He put forward two suppositions called Theory X and Theory Y which are based on
popular assumptions about work and people.
Theory x Assumptions
 People do not like work and try to avoid it.

 People do not like work, so managers have to control, direct, coerce, and threaten
employees to get them to work toward organisational goals.
 People prefer to be directed, to avoid responsibility, to want security, and have little
ambition.
Theory Y Assumptions
 People do not naturally dislike work; work is a natural part of their lives.
 People are internally motivated to reach goals to which they are committed.
 People are committed to goals to the degree that they receive personal rewards when
they reach their objectives.
 People will seek and accept responsibility under favourable conditions.
 People have the capacity to be innovative in solving organisational problems.
 People are bright, but generally their potentials are under-utilised.
4. Systems Approach
 Integration of the classical and human relations approaches. Attempts to reconcile the
work of the formal and the informal writers.
 Importance of the socio-technical system.
 Attention is focused on the total work organisation and the interrelationships of
structure and behaviour, and the range of variables within the organisation.
 The systems approach encourages managers to view the organisation both as a whole
and as part of a larger environment.
5. Contingency Approach
 Best viewed as an extension of the systems approach.

 Highlights possible means of differentiating between alternative forms of organisation
structure and systems of management.
 There is no one best design of organisation.

 Most appropriate structure and system of management is dependent upon the

contingencies of the situation for the particular organisation.
5.3 Best Methods of Staff Selection
Employee selection is the process of putting right men on right job. It is a procedure of
matching organizational requirements with the skills and qualifications of people. Effective
selection can be done only when there is effective matching. By selecting best candidate for
the required job, the organization will get quality performance of employees. Moreover,
organization will face less of absenteeism and employee turnover problems. By selecting right
candidate for the required job, organization will also save time and money. Proper screening
of candidates takes place during selection procedure. All the potential candidates who apply
for the given job are tested.
But selection must be differentiated from recruitment, though these are two phases of
employment process. Recruitment is considered to be a positive process as it motivates more
of candidates to apply for the job. It creates a pool of applicants. It is just sourcing of data.
While selection is a negative process as the inappropriate candidates are rejected here.
Recruitment precedes selection in staffing process. Selection involves choosing the best
candidate with best abilities, skills and knowledge for the required job.
5.3.1 Factors that may Influence Selection Procedure
The factors that may influence selection procedure are listed below. Generally factors
vary depending on the application domain, the type of project and the skills of other members
of the project team.
1. Application domain experience : For a project to develop a successful system, the
developers must understand the application domain. It is essential that some members
of a development team have some domain experience.
2. Platform experience : This may be significant if low-level programming is involved.
Otherwise, this is not usually a critical attribute.
3. Programming language experience : This is normally only significant for short-
duration projects where there is not enough time to learn a new language. While
learning a language itself is not difficult, it takes several months to become proficient in
using the associated libraries and components.
4. Problem solving ability : This is very important for software engineers who constantly
have to solve technical problems. However, it is almost impossible to judge without
knowing the work of the potential team member.
5. Educational background : This may provide an indicator of what the candidate knows
and his or her ability to learn. This factor becomes increasingly irrelevant as engineers
gain experience across a range of projects.

6. Communication ability : Project staff must be able to communicate orally and in

writing with other engineers, managers and customers.
7. Adaptability : Adaptability may be judged by looking at the experience that candidates
have had. This is an important attribute, as it indicates an ability to learn. Attitude
Project staff should have a positive attitude toward their work and should be willing to
learn new skills. This is an important attribute but often very difficult to assess.
8. Personality : This is an important attribute but difficult to assess. Candidates must be
reasonably compatible with other team members. No particular type of personality is
more or less suited to software engineering.
Factor Explanation
Application domain experience For a project to develop a successful system, the
developers must understand the application domain.
Platform experience May be significant if low-level programming is
involved. Otherwise, not usually a critical attribute.
Programming language experience Normally only significant for short duration
projects where there is insufficient time to learn a
new language.
Educational background May provide an indicator of the basic fundamentals
which the candidate should know and of their
ability to learn. This factor becomes increasingly
irrelevant as engineers gain experience across a
range of projects.
Communication ability Very important because of the need for project staff
to communicate orally and in writing with other
engineers, managers and customers.
Adaptability Adaptability may be judged by looking at the
different types of experience which candidates have
had. This is an important attribute as it indicates an
ability to learn.
Attitude Project staff should have a positive attitude to their
work and should be willing to learn new skills. This
is an important attribute but often very difficult to
assess.
Personality Again, an important attribute but difficult to assess.
Candidates must be reasonably compatible with
other team members. No particular type of
personality is more or less suited to software
engineering.

5.4 Motivation
Motivation is a theoretical construct used to explain behavior. Motivation depends on

people need or demand. It is the scientific word used to represent the reason for our actions ,
our desires, and our needs . For example , We are studying software engineering to become a
software engineer .
The Sentence is – “Motivation keeps us on track . ”
It means , for spending a valuable life when you are down , motivation keeps you on
track , motivation keeps you on life track .
5.4.1 Need of Motivation in Software Project Management
 Make staff or project member convenience.

 Understanding the value of work they are doing. Example : If you are working in a
office which never gives you bonus on holiday .But when some serious project or large
scale project are going to develop on your code , then they will probably want to
convince you by surprise gift or promotion of position .It’s will make you more
motivate than other project and you can realize the value of it .
 Reward for good effort, Reward for hard work, which makes project members
work satisfaction . Example : Your company gives you a gift on every success project,
it makes you more motivated for the company .
 Believe that they are treated fairly.
 Make believe them the project goal are realistic. Example : When unique project is
going to take place on your company it will seems like impossible by other people but
for your strong motivation , you can think that , “You can do it ” it possible it realistic .
5.4.2 Motivation Theories or Models
In simple words, motivation is the psychological feature that arouses an individual to

action toward a desired goal. In other words, motivation is an incentive that generates goal-
directed behaviors.
The phrase motivation theory is concerned with the processes that depict why and how
human behavior is activated and directed. It is regarded as one of the most important areas of
study in the field of organizational behavior. There are several motivation theories; however
none of them are universally accepted. No single theory can account for all aspects of
motivation, but each of the major approaches contributes something to our understanding of
motivation.

5.4.2.1 Maslow’s Hierarchy of Needs

Abraham Maslow’s message is that people do not work for security or money. They
work to contribute and to use their skills. Maslow calls this ‘self-actualization’. He created a
pyramid to show how people are motivated and said that one cannot ascend to the next level
until the levels below are fulfilled.
One of the most widely mentioned theories of motivation is the hierarchy of needs
theory by psychologist Abraham Maslow. Maslow saw human needs in the form of a
hierarchy, ascending from the lowest to the highest, and he concluded that when one set of
needs is satisfied, this kind of need ceases to be a motivator. Needs can be categorized as :
Fig. 5.4.1 Maslow’s hierarchy of needs
Physiological : These are important needs for sustaining the human life. Food, water,
warmth, shelter, sleep, medicine and education are the basic physiological needs which fall in
the primary list of need satisfaction. Maslow believed that until these needs were satisfied to a
degree to maintain life, no other motivating factors can work.
Security or Safety : These are the needs to be free of physical danger and of the fear of
losing a job, property, food or shelter. It also includes protection against any emotional harm.

Social : Since people are social beings, they need to belong and be accepted by others.
People try to satisfy their need for affection, acceptance and friendship.
Esteem : According to Maslow, once people begin to satisfy their need to belong, they
tend to want to be held in esteem both by themselves and by others. This kind of need
produces such satisfaction as power, prestige status and self-confidence. It includes both
internal esteem factors like self-respect, autonomy and achievements and external esteem
factors such as states, recognition and attention.
Self-Actualization : Maslow regards this as the highest need in his hierarchy. It is the
drive to become what one is capable of becoming; it includes growth, achieving one’s
potential and self-fulfillment. It is to maximize one’s potential and to accomplish something.
Example
Employee Motivation Techniques using the Maslow Pyramid
Now that you are aware of the theory, the way to apply it is to try to have the members
of your team working at the highest level. Knowing your team members as individuals and
working to understand their specific needs will help you identify what actions are needed on
your part to keep them motivated.
When building your team, try to make sure that lower level needs are met. When you
encounter a motivational issue, try to find out if there are lower level needs that are not being
met, and take steps to meet them if possible.
Here are some employee motivation techniques for you to try that use Maslow's
hierarchy of needs as a framework...
Physiological Needs
 Provide input for employee salaries and bonuses.

Safety Needs
 Ensure the correct tools for the job are available.

 Create an environment where individuals are comfortable challenging requests that are
dangerous.
Social Needs
 Schedule weekly project team meetings.

 Get the team together to celebrate project milestones.

Esteem Needs
 Recognize team members for excellent contributions to the project.

 Ensure each team member understands how important they are to the project.
Self-Actualization Needs
 Take into account each team members professional goals when assigning tasks.
 Empower team members so that they can develop and grow.
A person's behavior can focus on more than one need. For example, one of your team
members may be actively seeking promotion because it will lead to a higher salary
(physiological need). But the promotion can also satisfy esteem and self-actualization needs.
Even though the needs are described as hierarchical, application of the theory isn't as rigid.
The maslow theory of motivation is a great tool for project managers to understand and
use. It can help you keep your team motivated as well as correct motivational issues.
5.4.2.2 Herzberg’s Motivation-Hygiene Theory or Herzberg’s Two Factor Theory
In 1959, Frederick Herzberg, a behavioural scientist proposed a two-factor theory or the
motivator-hygiene theory. According to Herzberg, there are some job factors that result in
satisfaction while there are other job factors that prevent dissatisfaction. According to
Herzberg, the opposite of “Satisfaction” is “No satisfaction” and the opposite of
“Dissatisfaction” is “No Dissatisfaction”.
Fig. 5.4.2 Herzberg’s view of satisfaction and dissatisfaction
Hygiene Factors :
Poor hygiene factors may destroy motivation, but improving them, under most
circumstances, will not improve motivation. In other words the factors that help prevent
dissatisfaction. They do not lead to higher levels of motivation but dissatisfaction exists
without them. Hygiene factors are not sufficient to motivate people. Examples of this are-
 Working conditions
 Salary

 Personal life
 Relationship at work
 Security
 Status
 Company's policies and administration
 Job security
Motivating Agents :
What motivates people is the working itself, including such things as :

 Responsibility
 Self-actualization
 Professional growth
 Recognition
Preferably, the two approaches, hygiene and motivation, must be carried out
simultaneously. Treat people so they obtain a minimum of dissatisfaction. Use people so they
achieve, get recognition, grow and advance in their careers. Based on Maslow's Hierarchy,
Herzberg theorized that the factors that motivate the worker or are likely to satisfy their needs,
lead to positive job attitudes.
Limitations of Two-Factor Theory
The two factor theory is not free from limitations :

1. The two-factor theory overlooks situational variables.
2. Herzberg assumed a correlation between satisfaction and productivity. But the research
conducted by Herzberg stressed upon satisfaction and ignored productivity.
3. The theory’s reliability is uncertain. Analysis has to be made by the raters. The raters
may spoil the findings by analyzing same response in different manner.
4. No comprehensive measure of satisfaction was used. An employee may find his job
acceptable despite the fact that he may hate/object part of his job.
5. The two factor theory is not free from bias as it is based on the natural reaction of
employees when they are enquired the sources of satisfaction and dissatisfaction at
work. They will blame dissatisfaction on the external factors such as salary structure,
company policies and peer relationship. Also, the employees will give credit to
themselves for the satisfaction factor at work.
6. The theory ignores blue-collar workers. Despite these limitations, Herzberg’s Two-
Factor theory is acceptable broadly.

Implications of Two-Factor Theory
The Two-Factor theory implies that the managers must stress upon guaranteeing the
adequacy of the hygiene factors to avoid employee dissatisfaction. Also, the managers must
make sure that the work is stimulating and rewarding so that the employees are motivated to
work and perform harder and better. This theory emphasize upon job-enrichment so as to
motivate the employees. The job must utilize the employee’s skills and competencies to the
maximum. Focusing on the motivational factors can improve work-quality.
5.4.2.3 McGregor’s Theory of X and Y
Douglas McGregor states that people inside an organization can be managed in two
ways. The first is which falls under the category negative : :X and the other one is positive : Y.
Under the assumptions of theory X
 Employees inherently do not like work and whenever possible,

will attempt to avoid it.
 Because employees dislike work, they have to be forced,
coerced or threatened with punishment to achieve goals.
 Employees avoid responsibilities and do not work until formal
directions are issued.
 Most workers place a greater importance on security over all other factors and display
little ambition.
Under the assumptions of theory Y
 Physical and mental effort at work is as natural as rest or play.

 People do exercise self-control and self-direction and if they are
committed to those goals.
 Average human beings are willing to take responsibility and
exercise imagination, ingenuity and creativity in solving the
problems of the organization.
 People have potential.
Theory X assumes that lower-order needs dominate individuals and Theory Y assumes
that higher-order needs dominate individuals. An organization that is run on Theory X lines
tends to be authoritarian in nature. In contrast, Theory Y organizations can be described as
participative, where the aims of the organization and of the individuals in it are integrated;
individuals can achieve their own goals best by directing their efforts towards the success of
the organization.

5.4.2.4 David McClelland’s Achievement Motivation Theory

David McClelland’s achievement motivation theory states that a person has need for
three things but people differ in degree in which the various needs influence their behavior
Need for Power
 People whose need for power is socially oriented are effective leaders and should be
allowed to manage others.
 These people like to organize and influence others.
Need for Affiliation
 These people work best when cooperating with others.

 They seek approval rather than recognition.
Need for Achievement
 These people should be given projects that are challenging but are reachable.
 They like recognition
People who have a high need for power are inclined towards influence and control.
Power seekers want power either to control other people (for their own goals) or to achieve
higher goals (for the greater good). They seek neither recognition nor approval from others,
only agreement and compliance.
In the second category are the people who are social in nature. Affiliation seekers look
for harmonious relationships with other people. They will thus tend to conform and shy away
from standing out. The seek approval rather than recognition. They are driven by love and
faith. They like to build a friendly environment around themselves. Social recognition and
affiliation with others provides them motivation.
People in the third area are driven by the challenge of success and the fear of failure.
Their need for achievement is moderate and they set for themselves moderately difficult tasks.
They are analytical in nature and take calculated risks. Such people are motivated to perform
when they see at least some chances of success. Achievers seek to excel and appreciate
frequent recognition of how well they are doing. They will avoid low risk activities that have
no chance of gain. They also will avoid high risks where there is a significant chance of
failure.
McClelland observed that with the advancement in hierarchy the need for power and
achievement increased rather than affiliation. He also observed that people who were at the
top, later ceased to be motivated by this drives.

5.4.2.5 Expectancy Theory (Vroom Expectancy Theory)

The expectancy theory was proposed by Victor Vroom of Yale School of Management
in 1964. Vroom stresses and focuses on outcomes, and not on needs unlike Maslow and
Herzberg. The theory states that the intensity of a tendency to perform in a particular manner
is dependent on the intensity of an expectation that the performance will be followed by a
definite outcome and on the appeal of the outcome to the individual.
The Expectancy theory states that employee’s motivation is an outcome of how much
an individual wants a reward (Valence), the assessment that the likelihood that the effort will
lead to expected performance (Expectancy) and the belief that the performance will lead to
reward (Instrumentality). In short, Valence is the significance associated by an individual
about the expected outcome. It is an expected and not the actual satisfaction that an employee
expects to receive after achieving the goals. Expectancy is the faith that better efforts will
result in better performance. Expectancy is influenced by factors such as possession of
appropriate skills for performing the job, availability of right resources, availability of crucial
information and getting the required support for completing the job.
Instrumentality is the faith that if you perform well, then a valid outcome will be there.
Instrumentality is affected by factors such as believe in the people who decide who receives
what outcome, the simplicity of the process deciding who gets what outcome, and clarity of
relationship between performance and outcomes. Thus, the expectancy theory concentrates on
the following three relationships :
 Effort-performance relationship : What is the likelihood that the individual’s effort
be recognized in his performance appraisal ?
 Performance-reward relationship : It talks about the extent to which the employee
believes that getting a good performance appraisal leads to organizational rewards.
 Rewards-personal goals relationship : It is all about the attractiveness or appeal of
the potential reward to the individual.
Vroom was of view that employees consciously decide whether to perform or not at the
job. This decision solely depended on the employee’s motivation level which in turn depends
on three factors of expectancy, valence and instrumentality.
Advantages of the Expectancy Theory
 It is based on self-interest individual who want to achieve maximum satisfaction and

who wants to minimize dissatisfaction.
 This theory stresses upon the expectations and perception; what is real and actual is
immaterial.
 It emphasizes on rewards or pay-offs.

 It focuses on psychological extravagance where final objective of individual is to attain

maximum pleasure and least pain.
Limitations of the Expectancy Theory
 The expectancy theory seems to be idealistic because quite a few individuals perceive
high degree correlation between performance and rewards.
 The application of this theory is limited as reward is not directly correlated with
performance in many organizations. It is related to other parameters also such as
position, effort, responsibility, education, etc.
Implications of the Expectancy Theory
 The managers can correlate the preferred outcomes to the aimed performance levels.
 The managers must ensure that the employees can achieve the aimed performance
levels.
 The deserving employees must be rewarded for their exceptional performance.
 The reward system must be fair and just in an organization.
 Organizations must design interesting, dynamic and challenging jobs.
 The employee’s motivation level should be continually assessed through various
techniques such as questionnaire, personal interviews, etc.
5.5 Job Characteristics Model
5.5.1 Basic Elements
Moderating Variables for the Job Characteristics Model
 Growth need strength
o job is a vehicle for personal growth, sense of achievement, avenue for feeling
success
 Knowledge and skills
 Satisfaction with extrinsic aspects of work
Motivating Potential Score
Implementing Concepts for the Job Characteristics Model

 Combine tasks : Effects skill variety, task identity, and task significance

 Group tasks into natural work units : Effects task significance and task identity
 Give workers contact with customers : Effects skill variety, autonomy, feedback
 Vertically load jobs : Effects autonomy
 Open feedback channels : Effects feedback
Designing Jobs for Teams
 Team has to be an identifiable group, doing a specified piece of work, and be
self-managing
 Key behaviors : Ask for ideas, give suggestions,. listen to others, share information,
help others
 Manager’s role : Make alterations needed for effective group performance, consult
Goals That Motivate
 Specific goals
 Difficult goals
 Goal acceptance
 Goal feedback
Why Goals Motivate
 Mobilize energy in relation to goal

 Focus attention towards goals attainment
 Encourages setting of action plans or strategies for goal attainment
 Encourages persistence until goal is attained
Enhancing Goal Acceptance
 Participation
 Rewards
 Supportiveness
Incentives for Individuals
 For Executives
o Compensation tied to achieving strategic goals
 For Lower Level Employees
o Tied to performance : bonuses, commissions, piecework
Incentives for Groups
 Team incentives
 Profit sharing

 Gain sharing
 Stock options
Where Pay Fails to Motivate
 Bonuses or merit pay is too small
 Non-existent link between pay and performance
 Performance appraisal is done poorly
 Effect of unions
 Adaptation problems
Effective Reward Systems
 Set high goals for performance

 Develop accurate ways to measure performance
 Train supervisors in performance appraisal
 Link pay to performance
 Make increases noticeable and meaningful
Backwards and Forwards
 Summing up : Examined how Hackman’s and Oldhams job characteristics model can
be used to redesign jobs to engage motivation; studied how and why goals setting
works and looked at ways to use pay as a motivator
 Next time we begin our study of groups in the organization looking at how they
function and the role of cohesiveness
5.5.2 Hackman and Oldham Job Characteristics Model
The job characteristics model, designed by Hackman and Oldham, is based on the idea
that the task itself is key to employee motivation. Specifically, a boring and monotonous job
stifles motivation to perform well, whereas a challenging job enhances motivation. Variety,
autonomy and decision authority are three ways of adding challenge to a job. Job enrichment
and job rotation are the two ways of adding variety and challenge.
It states that there are five core job characteristics (skill variety, task identity, task
significance, autonomy, and feedback) which impact three critical psychological states
(experienced meaningfulness, experienced responsibility for outcomes, and knowledge of the
actual results), in turn influencing work outcomes (job satisfaction, absenteeism, work
motivation, etc.). The five core job characteristics can be combined to form a Motivating
Potential Score (MPS) for a job, which can be used as an index of how likely a job is to affect
an employee's attitudes and behaviors.

Hackman and Oldham’s job characteristics theory proposes that high motivation is
related to experiencing three psychological states whilst working :
Fig. 5.5.1 Hackman and oldham’s job characteristics model
1. Meaningfulness of work
That labour has meaning to you, something that you can relate to, and does not occur
just as a set of movements to be repeated. This is fundamental to intrinsic motivation, i.e. that
work is motivating in an of itself (as opposed to motivating only as a means to an end).
2. Responsibility
That you have been given the opportunity to be a success or failure at your job because
sufficient freedom of action has given you. This would include the ability to make changes
and incorporate the learning you gain whilst doing the job.
3. Knowledge of outcomes
This is important for two reasons. Firstly to provide the person knowledge on how
successful their work has been, which in turn enables them to learn from mistakes. The second
is to connect them emotionally to the customer of their outputs, thus giving further purpose to
the work .
In turn, each of these critical states are derived from certain characteristics of the job :
1. Meaningfulness of work
The work must be experienced as meaningful (his/her contribution significantly affects

the overall effectiveness of the organization). This is derived from :
o Skill variety
Using an appropriate variety of your skills and talents : too many might be
overwhelming, too few, boring.
o Task identity
Being able to identify with the work at hand as more whole and complete, and hence
enabling more pride to be taken in the outcome of that work (e.g. if you just add one nut

to one bolt in the same spot every time a washing machine goes past it is much less
motivating than being the person responsible for the drum attachment and associated
work area (even as part of a group).
o Task significance
Being able to identify the task as contributing to something wider, to society or a group
over and beyond the self. For example, the theory suggests that I will be more
motivated if I am contributing to the whole firm’s bonus this year, looking after
someone or making something that will benefit someone else. Conversely I will be less
motivated if I am only making a faceless owner wealthier, or am making some pointless
item (e.g. corporate give-away gifts).
2. Responsibility
Responsibility is derived from autonomy, as in the job provides substantial freedom,

independence and discretion to the individual in scheduling the work and in
determining the procedures to be used in carrying it out)
3. Knowledge of outcomes
This comes from feedback. It implies an employee awareness of how effective he/she is
converting his/her effort into performance. This can be anything from production
figures through to customer satisfaction scores. The point is that the feedback offers
information that once you know, you can use to do things differently if you wish.
Feedback can come from other people or the job itself.
Knowing these critical job characteristics, the theory goes, it is then possible to
derive the key components of the design of a job and redesign it :
1. Varying work to enable skill variety
2. Assigning work to groups to increase the wholeness of the product produced and give a
group to enhance significance
3. Delegate tasks to their lowest possible level to create autonomy and hence
responsibility
4. Connect people to the outcomes of their work and the customers that receive them so as
to provide feedback for learning
5.6 Ethical and Programmed Concerns
5.6.1 Introduction
The process of developing a new software application takes time and effort. It takes
time to design, develop and release the final product. Unfortunately for many software

companies and developers, they are given a small window of time and a small budget to
release a software package. Software companies mainly its developers are under pressure to
release a virtually bug-free product on time at the lowest possible cost. However, they face a
lot of obstacles that hinders this goal.
Mostly, the top reasons for software project failure were :
 Project objectives not fully specified

 Bad planning and estimating
 Technology new to the organization
 Inadequate or no project management methodology
 Insufficient senior staff on the team
 Poor performance by suppliers of hardware and/or software
Because of the time and money constraints, as well as the obstacles that they face to
make a quality product, software companies and developers are often tempted to perform
unethical and illegal acts to make their goal.
There are five ethical issues that software companies and developers face. They are :
 Using open-source code in their own code without properly crediting the source
 Using illegal software to perform their tasks
 Reverse engineering code to find out how a process works
 Not addressing known bugs
 Taking talent from the competition
5.6.2 Ethical Issues
1. Using Open Source Code : According to the definition on the Open Source
Initiative’s web site, open source is source code that is readily available to the user. In
other words, the application contains the source code that was used to create the
product. There are three particular types of open source code :
 Licensed Source Code : The source code may contain a GPL (General Public
License) or an LGPL (Library General Public License) that details how the
software and the source code is to be distributed, copied and modified.
 Copyrighted or Credited Source Code : The source code may be freely
published on a web site with the author’s consent for the programmer to use the
source code as long as the author is credited in the code.
 Public Domain : The source code may be in public domain, which means that the
author explicitly relinquishes all rights to the software. In other words, the codes

are free to use without consequence. While the third type of source code does not
cause any ethical issues because there is no obligation to provide credit for use, the
first two types do pose ethical issues to the programmer. In the case where the
open source code contains a GPL or LGPL, the programmer must follow the rules
as specified in the GPL or LGPL. Some companies do follow the license. For
example, IBM’s Web sphere product is based on the Apache Web Server, and up
until the latest re-write that no longer uses Apache code, IBM included the GPL
for Apache Web Server in their literature about the software. However, some
companies do not follow the GPL. In some cases, the companies claim the code as
their own. In the case where the open source code has no license, but the author
explicitly requests that she/he is referenced in the developer’s code, some
programmers do not do this, mainly because the author is not a corporate entity. In
most cases, it was difficult for the programmer to prove that a developer
plagiarized his/her code. With the passing of the Digital Media Copyright Act
(DMCA), this can become a major issue for developers who frequently use code
without crediting the original author. According to the DMCA, if someone
publishes information on the Internet, that information is automatically
copyrighted as long as the author says so.
2. Using Illegal Software : Due to time and money crunches, it is tempting for a company
to use a pirated copy of software or violate the software license. In fact, some of the
largest companies have used pirated copies of software or violate the software licensing
rules in the past. Some companies continue to illegally use software, despite the fact
that software companies lose $12 billion in revenues due to software piracy and license
violations. There are some published ethics guides on how employees are supposed to
use software. These guides cover points such as :
 The definitions of software licenses
 Penalties those companies and employees will face if they violate copyright laws
 Answers to frequently asked questions about software use
3. Reverse Engineering Code : Reverse engineering is a controversial and a confusing
subject in the software development world. Out of all the issues mentioned, this issue
frequently creates dilemmas for software engineers and companies. Reverse
engineering is the process of decompiling an application in order to reveal the source
code. In the early days of software development, many software engineers engaged in
the practice of reverse engineering to find out how a particular program performed an
action. With the passing of the DMCA, reverse engineering has legal implications.

There are issues with reverse engineering that could cause confusion with how to use it.
For example :
 If the software is considered public domain, then the programmer is allowed to
reverse-engineer it.
 The DMCA prohibits the act of circumventing a technological measure used by
copyright owners to control access to their works. Acts of circumventing include :
copying media, decrypting encryption tools, and reverse-engineering software.
4. Non-compete Agreement : A document signed by an employee that promises that the
said employee will not work for a direct competitor for a specific amount of time after
s/he leaves the company try to prevent talent from going to competitive firms by
having its employees sign non-compete agreements. However, even with a signed non-
compete agreement, companies can still face a legal battle over the wording of the
document, including whether the document is impeding an employee’s “right to work”.
If the company did not require its employees to sign non-compete agreements, a
competing company can easily take its talent pool from another company. However,
even without the non-compete clause, the company can face civil action from the
competitor. There are two examples that highlight civil actions taken by companies due
to talent raiding. The first example highlights the legal issues of talent raiding.
The second example highlights the questioning of the non-compete agreement. In 2005,
the case of Yahoo v. Nuance Technologies appeared in the California court. This case
addressed the issue of whether “talent raiding” was causing a misappropriation of trade
secrets and unfair competition. According to the article by Elinor Mills on C-Net News
(“Yahoo”, 2005) :Nuance Technologies was working on voice-activated search engines.
Yahoo hired all but one of the research people on the project.
Nuance filed a lawsuit with the California courts to temporarily bar the workers from
working at Yahoo. The judge ruled that the speech engineers hired by Yahoo were
allowed to continue working for Yahoo because the courts could not properly assess
whether any wrong doing has occurred. In 2006, the case of Microsoft v. Google
appeared in the Washington court.
This case addressed whether a non-compete agreement was violated. According to the
article by Elinor Mills on C-Net News (“Microsoft”, 2006) : Google hired Kai-Fu Lee,
a former Microsoft executive from China, to run the Chinese branch of Google.
However, Microsoft contends that the role that Mr. Lee would per format Google
(recruiting staff for the developer center in China) was a direct violation of the non-
compete agreement that Mr. Lee signed at Microsoft. The court ruled that recruiting
workers in China was not a violation of the non-compete agreement, but he was not

allowed to work on technologies, set budgets or salaries, or decide on what research

Google can do in China.
5.6.3 Solving Ethical Problems
Ethical problems in the software industry can cause legal ramifications, such as civil
suits and fines, and it can cause business ramifications, such as a ruined reputation that will
cost the company sales. What can software developers and companies do to help prevent
problems? While these suggestions may help prevent problems caused by unethical behavior,
it is not a guarantee that they will solve all the problems.
 Assign task to a compliance officer to make sure that the licenses are being used
properly
By assigning a compliance officer (preferably from the IT department) to ensure that
software is being used as it is licensed, companies can reduce illegal software use.
 Perfect quality assurance
Since there are very little legal ramifications for bugs and security flaws causing system
problems, companies will easily spend little time on testing problems and addressing
known bugs. However, the ethical issue is the cost of business. Businesses lose millions
of dollars in lost productivity due to bugs and security flaws. A software developer and
the software company can lose business and future revenues because of a ruined
reputation. The best thing that a company can do is invest time and money in quality
assurance. While quality assurance is not going to catch every bug imaginable, it will
catch a high percentage of the bugs and flaws.
 Consult with legal department about non-compete agreements and fair use with
reverse engineering
Non-compete agreements, which are helpful with preventing talent raiding, and the fair
use of reverse engineering has numerous legal implications. Before beginning a project
where reverse engineering is necessary, or before devising a non-compete agreement,
companies and developers should consult with an attorney who is familiar with these
subjects. The attorney can guide the developers and companies with the correct way to
perform these actions.
 Let public know about flaws or delay the software release
Despite the fact that Microsoft is well known for releasing bug-laden software.
Microsoft is very good about releasing information about bugs and flaws to the public
as soon as they are discovered. Microsoft has also been known to delay the release of
software if there are too many problems with the software. By doing this, Microsoft has

helped its reputation as a leading software provider. Although a customer may not be
happy about a delay or a flaw, the customer will accept the answer if s/he is given
ample warning about the problem.
 Publish ethical guidelines on software development and use
Publishing a guideline about software development and use can leave little room for
interpretation, which could help reduce unethical and potentially illegal behavior.
When developing a guideline, companies and developers should consult with an
attorney who is familiar with the legal issues of software development.
5.7 Working in Groups and Becoming A Team
5.7.1 Working in Group
 Software based systems will be huge, also software tool contains five million lines of
code.
 So that the work is shared between individual software developers within teams and
between group of developers.
 Team working will enhance the communication between individual developers and
within teams and across teams.
 Team - Group of people who are working together.
- Small group environment
 The term Project Team refers all the people working on a project.
 The people who are working in project team may sit in different workgroups at some
distance from each other.
 These groups can also change over time.
 Thus individual developers are transfer between teams during the period of project start
and finish.
 Team is created to do joint assignment
 To perform the work assignments which are allocated to the staff, the organization
needs one form of coordination between groups and individuals within a project.
 Communication genres
- Refers method of communication
- It is selected and developed to deal with particular need for project coordination.
- The arrangements for communication between stakeholders are documented in
communication plan

 This team work has an influence on all stages of step wise project planning framework.
1. Identify project scope and objectives
2. Identify project infrastructure
3. Analyze project characteristics
4. Estimate effort for each activity
5. Identify activity risks
6. Allocate resources
7. Review/publicize plan
 Forming :
o Members of the group get to know each other
o Try to set up some rules about behavior
 Storming
o Conflicts arise to get leadership
o Group’s methods of operation are established
5.7.2 Becoming a Team
 The organization first analyzes how the small work groups are formed.
 While forming a team it has five basic stages of development :
Norming
o Conflicts are largely settled
o Group identity emerges
Performing - Now tasks are at the hand
Adjourning (Suspend or Stop) - Group disperse
 Some training activities such as management games are needed to promote team
building and to people in the team work together.
 The team may consists of different types of people such as
The chair - Good at running meetings
- Strong but tolerant
The plant - Good at generating ideas and solutions to the problems
The monitor-evaluator - Good at evaluating ideas and solutions
- Think well at selecting best one
The shaper - Who helps to direct team’s attention to the important issues
The team worker - Good at creating a good working environment

The resource investigator - Skilled person to find resources ie) both physical
resources and information
The completer-finisher - Anxious (Worried) with completing task
The company worker - Should be a good team player
- Willing to take tasks for team success
 Problems occur when there is an imbalance between the role types of people in a
group.
5.7.3 Group Performance
 In many projects, some solutions are needed about which tasks are carried out
collectively as a team and which are allotted to individuals.
 It is defined by “Some work yields better results if carried out as a team while some
things are slowed down if the work is not partitioned on an individual basis”.
 The group tasks are categorized into :
Additive Tasks - Effects of each participant are added to get final result
- People involved are interchangeable
Compensatory Tasks - Solutions of individual group members are pooled
- Errors of some are compensated by the inputs from others
Disjunctive Tasks - Means there is only one correct answer.
- It depends on someone coming up with one right
answer and others recognizing it as being correct
Conjunctive Tasks - Means joining the tasks
- Progress is governed by the rate of slowest performer
- The overall task is not completed until all participants have
completed.
5.7.4 Team Strength
 Regular team meetings that are effective  Clear communication among all
and inclusive members
 Timely hand off from team members to  Regular brainstorming sessions with
others to ensure the project keeps moving all members participating
in the right direction  Consensus among team members
 Positive, supportive working relationships  Problem solving done by the group
among all team members  Commitment to the project and the
other team members

5.8 Decision Making
 Decision can be categorized as

Structured
o Simple
o Routine
o Straightforward rules
Unstructured
o More complex
o Requires degree of creativity
Mental obstacles to good decision making
 Many decisions are made under pressure

 With incomplete information
o Faulty Heuristics (Rule of thumb) – dangers are there
o Information in hand-misleading
o Stereotypes (well-known fact)
o Escalation of commitment(difficult to alter once made a commitment)
- Information Overload
Group decision making
 Decisions made by the team as a whole are more likely to be accepted that those that
are imposed
 Complementary skills and expertise
 Communicate freely/get ideas
 Brainstorming techniques
 Aim is to have involvement of end users?
- Prototyping and participatory approaches
- JAD (Joint Application Development)
Barriers to good team decisions
 Inter-personal conflicts –team formation

 Conflicts tend to be a dampened by emergence of group norms – shared group opinions
and attitudes

 Risky shift – people in groups are more likely to make risky decisions than they would
as individuals
5.8.1 Approaches to Make Decision
(a) Delphi approach
To avoid dominant personalities intruding the following approach is adopted

1. Enlist co-operation of experts
2. Moderator presents experts with problem
3. Experts send in their recommendations to the moderator
4. Recommendations are collated and circulated to all experts
5. Experts comment on ideas of others and modify their own recommendation
if so moved
6. If moderator detects a consensus, stop; else back to 4
(b) Team ‘heedfulness’
 As a football team.
 Where group members are aware of the activities of other members that contribute
to overall group success
 Impression of a ‘collective mind’
 Some attempts to promote this :
- Egoless programming
- Chief programmer teams
- XP
- Scrum
Egoless programming
 Gerry Weinberg noted a tendency for programmers to be protective of their code and to
resist perceived criticisms by others of the code
 Encouraged programmers to read each others code
 Argued that software should become communal, not personal – hence ‘egoless
programming’
Chief programmer teams
 Fred Brooks was concerned about the need to maintain ‘design consistency’ in large
software systems
 Appointment of key programmers, chief programmers, with responsibilities for
defining requirements, designing, writing and test software code

 Assisted by a support team : co-pilot – shared coding, editor who typed in new or
changed code, program clerk who write and maintain documentation and tester
 Problem – finding staff capable of the chief programmer role
Extreme programming (XP)
XP can be seen as an attempt to improve team heedfulness and reduce the length of
communication paths (the time between something being recorded and it being used)
 Software code enhanced to be self-documenting
 Software regularly refactored to clarify its structure
 Test cases/expected results created before coding – acts as a supplementary
specification
 Pair programming – a development of the co-pilot concept
Scrum
 Named as an analogy to a rugby scrum – all pushing together
 Originally designed for new product development where ‘time-to-market’ is important
 ‘Sprints’ increments of typically one to four weeks
 Daily ‘scrums’ – daily stand-up meetings of about 15 minutes
 Unlike XP, requirements are frozen during a sprint
 At the beginning of the sprint there is a sprint planning meeting where requirements are
prioritized, At end of sprint, review meeting where work is reviewed and requirements
may be changed or added to.
5.9 Team Structures
5.9.1 Software Project Teams
There are three main types of software project teams :

1. The Egoless Programming Team (the democratic team or Open structured teams)
o A “grass roots” anti-elitist style of team organization
o Egoless : group owns the documents and code (not individuals)
o Consists of 10 to 12 members
o All decisions are based on team consensus
o Depends on total cooperation of its members
o Requires clear structure for the way the team interacts
o Functional roles (e.g. moderator, recorder) rotate among team members

o A technical leader has external responsibility and resolves issues when team
doesn’t reach consensus
o No permanent central authority
o Rarely found today, however, sometimes used in research organizations.
o Provides
- Higher morale and job satisfaction to the engineers
- Therefore leads to less employee turnover.
o Suitable for less understood problems,
- A group of engineers can invent better solutions than a single individual.
o A manager provides administrative leadership :
- At different times different members of the group provide technical leadership.
Disadvantage :
o Team members may waste a lot time arguing about trivial points :
o Absence of any authority in the team.
Democratic team
2. The Chief Programming Team

o Consists of 3 or 4 permanent team members : chief programmer, backup
programmer, and librarian.
o Other programmers or analysts are assigned as needed.
o Chief programmer makes all technical and managerial decisions.
o Rarely used today, because of difficulty in recruiting and training chief
programmers.
o A senior engineer provides technical leadership :

- Partitions the task among the team members.

- Verifies and integrates the products developed by the members.
o Works well when
- The task is well understood
- Also within the intellectual grasp of a single individual,
o importance of early completion outweighs other factors
- Team morale, personal development, etc.
Disadvantage
o Chief programmer team is subject to single point failure.
o too much responsibility and authority is assigned to the chief programmer.
Chief programmer team
What do the graphics imply about this team structure?

o Chief programmer makes all important decisions
o Must be an expert analyst and architect, and a strong leader
o Assistant chief programmer can stand in for chief, if needed
o Librarian takes care of administration and documentation
o Additional developers have specialized roles
3. The Hierarchical Team (the controlled decentralized team, and project team) :
o Has a top-down flow of authority
o Project leaders manage senior engineers (senior programmers).
o Senior engineers manage junior engineers (junior programmers).
o Most commonly used team structure today.

Project members
Large projects often distinguish levels of management :

o Leaf nodes is where most development gets done; rest of tree is management
o Different levels do different kinds of work—a good programmer may not be a good
manager
o Status and rewards depend on your level in the organization
o Works well when projects have high degree of certainty, stability and repetition
o But tends to produce overly positive reports on project progress, e.g. :
- Bottom level : “We are having severe trouble implementing module X.”
- Level 1 : “There are some problems with module X.”
- Level 2 : “Progress is steady; I do not foresee any real problems.”
- Top : “Everything is proceeding according to our plan.”
4. Mixed Control Team Organization
 Draws upon ideas from both :
o democratic organization and
o chief-programmer team organization.
 Communication is limited
o to a small group that is most likely to benefit from it.
 Suitable for large organizations.

5. Matrix Organization
Real-time programming Graphics Databases QA Testing
project C X X X
project B X X X X
project A X X X X
 Organize people in terms of specialties
o Matrix of projects and specialist groups
o People from different departments allocated to software development, possibly
part-time
 Disadvantage
o Project structure may not match organizational structure
o Individuals have multiple bosses
o Difficult to control a project’s progress
5.10 Virtual Teams
5.10.1 Virtual Teams
 A virtual team (also known as a geographically dispersed team, distributed team, or

remote team) usually refers to a group of individuals who work together from different
geographic locations and rely on communication technology such as email, FAX, and
video or voice conferencing services in order to collaborate.
 Or, The term can also refer to groups or teams that work together asynchronously or
across organizational levels.
 Or, The expanded definition is that virtual teams are usually small, temporary groups
consisting of knowledge workers.
Members of virtual teams communicate electronically and may never meet face-to-face.
Virtual teams are made possible by a proliferation of fiber optic technology that has
significantly increased the scope of off-site communication. Virtual teams allow companies to
procure the best talent without geographical restrictions. Virtual teams require new ways of
working across boundaries through systems, processes, technology, and people, which require
effective leadership despite the widespread increase in virtual teamwork, there has been
relatively little focus on the role of virtual team leaders.

5.10.2 Model of Virtual Teams
 There are three main aspects to a virtual team - purpose, people and links. While
purpose is an important aspect for all organizations, it's the most critical aspect for
virtual teams; purpose is what holds a virtual team together.
 Virtual teams do not have hierarchy or any other common structures because they may
not be from the same organization, and purpose here brings and holds the team
together.
 Purpose is generally translated into certain action steps for people to work on with a
defined structure consisting of common goals, individual tasks and results.
 A number of factors may affect the performance of members of a virtual team. For
example, team members with a higher degree of focused attention and aggregate lower
levels of temporal dissociation (or flow ) may have higher performance.
 Further, members with higher degrees of attention focus may prefer asynchronous
communication channels, while those with low levels of flow may prefer synchronous
communication channels.
5.10.3 Structure of Virtual Team
Inputs
Design of a virtual team means simply that forming a virtual team should be planned.
This means structuring the interactions; what kind of communication tools are used, how
much face-to-face time will be possible, etc. Mostly more face-to-face meetings improved the
empowerment of virtual teams, which leads to better learning. Numerous communication
problems can be diverted by creating shared knowledge databases in order to allow all the
team members to have the same information and to know that others have it, too. As an added
bonus, shared knowledge databases also share the same language and mental models, which
are substitutes for the all important face-to-face time. Furthermore, shared mental models can
be focused through designing, requiring the teams to create goals and strategies.

With cultural differences also coordination problems and obstacles to effective

communication can be involved. These problems may be solved by actively understanding
and accepting differences in cultures.
The technical expertise of a team seems to have a positive effect on the team's
performance and the satisfaction of belonging to the team. At the same time, high trust is
found to develop. On the other hand, "the relationship between technology and task
performance is found to be more dependent on experience with technology and with group
membership than the type of task on which the group was working".
Diverse technological skills can create conflict among the team. This is why teams
should have consistent training to improve team performance. For instance, mentoring is a
good way to make personal ties to more experienced virtual team professionals.Consistent
training fosters cohesiveness, trust, teamwork, commitment to team goals, individual
satisfaction and higher perceived decision quality.
 Virtualness has a different effect on teams depending on the length of team duration.
For short-term teams, leaner media, misattributions, and subgroups all potentially
contribute to less effective teams.
 In longer-term teams, members make fewer misattributions to a person as they interact
with each other over a longer time frame and develop relationships.
 Also, over longer time spans teammates build a group identity that helps them to
overcome differences. There aren't any negative effects on team performance or
satisfaction, and team conflict actually decreased as the degree of virtualness increased.
 Although there was a negative effect on communication frequency and knowledge
sharing, the effect was much less in long-term teams compared to short-term teams.
 Virtualness also has varying influence on teams depending on how the virtualness is
measured as well as the length of time that a team is working together. The negative
effects that effect short-term teams disappeared for longer term teams.
Socio-emotional processes
It introduces the emotional problems involved and mitigation tactics needed to achieve
cohesion and trust among team members. According to research, results in weaker social links
between team-mates and leads the team to be more task-focused than socially focused. If
face-to-face meetings are feasible, meetings should be held as much as possible at the
beginning of the team formation in order to bring team-mates closer and form interpersonal
bonds. These meetings should focus more on relationship building than on actual business.

However, with socializing different cultural preferences have to be remembered. If

face-to-face meetings are not possible or feasible to the desired extent, other approaches can
be applied. Social-bonding can be done partially via electronic communication tools. Study
found that if teams communicate more socially they achieve higher trust and better social and
emotional relationships. Leaders can help foster relationship building and general team
building in many ways, e.g. by providing continuous feedback, listening to team members‟
opinions and suggestions, clearly stating the team member roles and having consistency in
their leadership style.
Cohesion means the sense of unity in a team. Cohesion is important to virtual teams,
and is associated with better performance and greater satisfaction. It has been found that
collaborative technologies take away from the development of cohesion within virtual teams
and that traditional teams have higher level of team cohesiveness. Although virtual teams may
start with low cohesion, over time they exchange enough social information to develop strong
cohesion. In comparing men and women’s perception of cohesion in virtual teams, It is found
that both women in virtual teams and men in traditional teams perceived greater team
cohesiveness than men in virtual teams. However, virtual teams have difficulty attaining
cohesion. Relationship building deals with interactions that increase inclusiveness.
Trust is particularly problematic subject with virtual teams, because it is arguable
whether people can be expected to trust each other if they have never met face–to-face.
Furthermore, trust is noted to be crucial in successful teams, but usually there is not much time
to build it little by little because often the teams are short-lived in projects. To achieve high
trust early in the group's life, the team had social and enthusiastic communication and they
coped well with technical uncertainty and took individual initiatives. The groups that enjoyed
trust later had predictable communication, timely responses, positive leadership and the ability
to move from social communication to task-focused communication. The integrity of other
team members is important in the development of trust, and perceptions of other members’
benevolence supports the maintenance of trust over time. Face-to-face meetings during the
beginning stages for a team, before they become virtual, helps to develops strong trust.
Task processes
Task processes are actions that team members carry out in order to accomplish their
goal and complete their project. The three main parts to task processes are communication,
coordination and task-technology-structure fit.
Communication is vital to the success of the virtual team and it is crucial that the team
is a group of excellent communicators with the proper technology for the best levels of
communication. It starts from selecting excellent communicators for the team members and

the right technology for them to use. Virtual communication technologies cause many
difficulties in effective team communication, such as time delays, common reference frames,
differences of interpretation, and assurance of participation for remote team members.
Some empirically found challenges in successful communication in virtual teams are
failure to communicate due to wrong or lacking contextual information, unevenly distributed
information, interpretation of the meaning of silence and technical problems. Nonverbal
communication, which is vital for team communication, is also missing in virtual teams.
Traditional teams communicate more effectively than virtual teams.
Difficulties often arise when some team members are co-located while others are
geographically distant. There is an assumption that co-located team members communicate
with each other about information that is not communicated to the distant member, which can
cause friction between members. Leadership and cultural differences also substantially affect
the effectiveness of communication. The frequency and predictability of communication and
how much feedback is provided regularly improves the effectiveness of communication,
which leads to greater team trust and improves team performance. On the other hand,
inconsistent and infrequent communication reduces the coordination and success of virtual
teams. One common reason is that some team members leave for a short amount of time
without communicating their absence to other members. However, virtual teams are found to
communicate more frequently than normal teams and female-only virtual teams have higher
communication than male-only or combined gender virtual teams. Higher effective
communication is shown to improve cultural understanding.
Coordination is how much combined effort exists between various parts of an
organization and how consistent and coherent they are. Coordination is positively associated
with virtual team performance. However, it is difficult for virtual teams to coordinate across
time zones, cultural divides and divergent mental model.
The development of a type of collaboration norms within the team is necessary for a
team to meld team members’ contributions. Face-to-face meetings are especially helping in
leading a successful project. If face-to-face meetings are not possible, a formal protocol for
communication training improves both coordination and collaboration activities. Minimizing
cultural barriers also improves coordination between team members. Collaboration norms
have to develop for the team to function well.
As mentioned before, periodical face-to-face meetings are a good way to form
relationships and also a good vehicle to coordinate activities and to drive the project forward.
When face-to-face meetings are not feasible, one alternative is to develop coordination
protocols with communication training.

The task-technology-structure fit examines "the possible fit between various

technologies available...". The technology used is dependent on personal preference, previous
experience with the technology, ease of use, need for documenting project activities, and how
urgent the task is. It is found that face-to-face meetings or phone calls are suitable for
ambiguous tasks, managing conflicts, managing external resources, brainstorming and
strategic talks. Electronic communication is more suitable for more structured tasks such as
routine analysis, examining design tradeoffs and monitoring project status.
Outputs
Output in virtual teams means all the things that come out of the work processes of the
team.
"Decision quality" is one of the outputs of virtual teams. Virtual teams generate more
ideas compared to traditional teams. As there are many constraints with working virtually,
virtual teams require a longer time to reach a decision.
When comparing "the performance" of traditional and virtual teams, the results are
mixed. Some studies find traditional teams and some virtual teams to be better. The majority
of studies have found the teams to be about at the same level. There is a list of many studies
that have found different factors, which make virtual teams successful. The found factors are :
 Training
 Strategy/goal setting
 Developing shared language
 Team building
 Team cohesiveness
 Communication
 Coordination and commitment of the teams
 The appropriate task-technology fit
 Competitive and collaborative conflict behaviors
The results from different student studies are mixed concerning working in a virtual
team. It is found that teams which used their dialogue technique were more satisfied with
decisions made in the team. Team members that are more satisfied were more likely to have
had training and used more communication methods compared to unsatisfied team members.
5.10.4 Types of Virtual Team
Below are the most common types of virtual teams.

1. Networked teams
2. Parallel teams

3. Project development teams

4. Work, production or functional teams
5. Service teams
6. Offshore ISD teams
Networked teams
Generally, networked teams are geographically distributed and not necessarily from the
same organization. These teams are frequently created and just as frequently dissolved; they
are usually formed to discuss specific topics where members from the area of expertise,
possibly from different organizations, pitch their ideas in the same discussion. Depending on
the complexity of the issue, additional members to the team may be added at any time. The
duration these teams last may vary significantly depending on how fast or slow the issue is
resolved.
Parallel teams
Parallel teams are highly task oriented teams that usually consist of specialized
professionals. While they are generally only required for very short span of time, unlike
networked teams, they are not dissolved after completion of the tasks. The team may be either
internal or external to the organization.
Project development teams
Similar to parallel teams, these teams are geographically distributed and may operate
from different timezones. Project development teams are mainly focused on creating new
products, information systems or organizational processes for users and/or customers. These
teams exist longer than parallel teams and have the added ability to make decisions rather than
just make recommendations. Similar to networked teams, project development teams may also
add or remove members of their team at any given time, as needed for their area of expertise.
Work, production or functional teams
These teams are totally function specific where they only work on a particular area
within an organization (i.e. finance, training, research, etc.). Operating virtually from different
geographical locations, these teams exist to perform regular or ongoing tasks.
Service teams
Service teams are geographically located in different time-zones and are assigned to a
particular service such as customer support, network upgrades, data maintenance, etc. Each
team works on providing the particular service in their daylight hours and at the end of day,
work is delegated to the next team which operates in a different timezone so that there is
someone handling the service 24 hours a day.

Offshore ISD teams
Offshore ISD outsourcing teams are independent service provider teams that a company
can subcontract portions of work to. These teams usually work in conjunction with an onshore
team. Offshore ISD is commonly used for software development as well as international R&D
projects.
5.11 Communication Genres (Types of Communication)
5.11.1 Communication Genres
Completing a complex project successfully requires good communication among team

members. If those team members work in the same building, they can arrange regular
meetings, simply stop by each other’s office space to get a quick answer, or even discuss a
project informally at other office functions. Many projects are performed by teams that
interact primarily through electronic communication and are, therefore, called virtual teams.
To avoid miscommunication that can harm trust and to include team members in a project
culture, the project team needs a plan for communicating reliably and in a timely manner.
This planning begins with understanding two major categories of communication.
5.11.1.1 Synchronous Communications
If all the parties to the communication are taking part in the exchange at the same time,
the communication is synchronous. A telephone or Skype conference call is an example of
synchronous communication. The following are examples of synchronous communications :
 Live meeting. Gathering of team members at the same location.
 Conference call. A telephone call between two or more individuals where several
people participate.
 Audio conference. Like a conference call, but conducted online using software like
Skype.
 Computer-assisted conference. Audio conference with a connection between
computers that can display a document or spreadsheet that can be edited by both
parties.
 Video conference. Similar to an audio conference but with live video of the
participants. Some laptop computers have built-in cameras to facilitate video
conferencing.
 IM (Instant Messaging). Exchange of text or voice messages using pop-up windows
on the participants’ computer screens.

 Texting. Exchange of text messages between mobile phones, pagers, or personal digital
assistants (PDAs)—devices that hold a calendar, a contact list, a task list, and other
support programs
Modern communication technologies make it possible to assemble project teams from
anywhere in the world. Most people work during daylight hours, which can make synchronous
meetings difficult if the participants are in different time zones. However, it can be an
advantage in some circumstances. For example, if something must be done by the start of
business tomorrow, team members in Asia can work on the problem during their normal work
hours while team members in North America get some sleep.
Remember Time Zones
It is important to remember time zones and calculate the difference between yours and
your associates’ correctly so as to not miss important meetings or deadlines. Cities and
countries to the north or south of each other all observe the same local time. Be aware that
many well-educated people in the United States think of South America as directly south of
North America. While most of South America is one or two time zones east of the United
States.
5.11.1.2 Asynchronous Communications
Getting a team together at the same time can be a challenge—especially if they are
spread out across time zones. Many types of communication do not require that the parties are
present at the same time. This type of communication is asynchronous.
There are several choices of asynchronous communications.
Mail and Package Delivery
Many companies prefer that final contracts are personally signed by an authorized
representative of each party to the agreement. If several signatures are required, this can take
weeks to get all the signatures if the contracts are transferred by a postal service. If this
process is holding up the start of the project, you can use an overnight delivery service to
minimize the time spent transferring the documents.
Fax
Fax machines have been around a long time and enjoy a high level of trust for
transmitting documents accurately. Although it might seem archaic to still use fax
transmissions, in many countries a fax of a signed contract is legal, but a computer-scanned
image is not.

E-Mail
Electronic mail (e-mail) is widely used to coordinate projects and to communicate

between team members. It has several valuable characteristics for project management :
 Information can be sent to a list of team members.
 Messages can be saved to document the process in case of a misunderstanding or
miscommunication.
 Files can be attached and distributed.
Project Blog
A blog is an online journal that can be private, shared by invitation, or made available
to the world. Some project managers keep a journal in which they summarize the day’s
challenges and triumphs and the decisions they made. They return to this journal at a later date
to review their decision-making process after the results of those decisions are known to see if
they can learn from their mistakes. Many decisions in project management are made with
incomplete knowledge, and reflecting on previous decisions to develop this decision-making
skill is important to growth as a project manager.
Really Simple Syndication (RSS)
Some projects are directly affected by external factors such as political elections,
economic trends, corporate mergers, technological or scientific breakthroughs, or weather. To
keep informed about these factors, you can subscribe to online news sources. A technology
that facilitates this process is Really Simple Syndication (RSS). Web pages with RSS news
feeds have labeled links.
If the user clicks on the RSS feed, news from the website is automatically sent to the
user’s news reader, such as Google Reader. The news reader can be set to filter the news for
key words to limit the stories to those that are relevant to the project.
5.12 Communication Plans
 A communications plan, in project management, is a policy-driven approach to

providing stakeholders with information about a project.
 The plan formally defines who should be given specific information, when that
information should be delivered and what communication channels will be used to
deliver the information.
 An effective communications management plan anticipates what information will need
to be communicated to specific audience segments. The plan should also address who
has the authority to communicate confidential or sensitive information and how
information should be disseminated (email, web sites, printed reports, and/or
presentations).

In some organizations the communications management plan may also include a

glossary of common project terminology that will be used within the project. This glossary
may define and include samples of templates, reports and forms that the project manager will
use to communicate information.
5.12.1 Communications Management Plan
A good project Communications Management Plan ensures that you have effective
communications throughout the life of your project. Everyone knows that 80% of a Project
Manager's time is spent communicating; therefore, to be an effective Project Manager you
must have good communications skills.
This Communications Management Plan sets the communications framework for this
project. It will serve as a guide for communications throughout the life of the project and will
be updated as communication needs change. This plan identifies and defines the roles of
persons involved in this project. It also includes a communications matrix which maps the
communication requirements of this project. An in-depth guide for conducting meetings
details the communications rules and how the meetings will be conducted, ensuring successful
meetings. A project team directory is included to provide contact information for all
stakeholders directly involved in the project.
5.12.1.1 Communication Management Plan Template
Communications Management Plan template helps to think through the communication
requirements for the project and plan for the most effective communications. This template is
based on the predefined communications guidelines.
Template structure
Introduction
The purpose of the Communications Management Plan is to define the communication

requirements for the project and how information will be distributed.
The Communications Management Plan defines the following :
 What information will be communicated—to include the level of detail and format
 How the information will be communicated—in meetings, email, telephone, web portal,
etc.
 When information will be distributed—the frequency of project communications both
formal and informal
 Who is responsible for communicating project information
 Communication requirements for all project stakeholders
 What resources the project allocates for communication

 How any sensitive or confidential information is communicated and who must

authorize this
 How changes in communication or the communication process are managed
 The flow of project communications
 Any constraints, internal or external, which affect project communications
 Any standard templates, formats, or documents the project must use for communicating
 An escalation process for resolving any communication-based conflicts or issues
5.12.2 Communications Management Terminology
5.12.2.1 Change Control Management
 As with most project plans, updates or changes may be required as the project
progresses or changes are approved. Changes or updates may be required due to
changes in personnel, scope, budget, or other reasons. Additionally, updates may be
required as the project matures and additional requirements are needed. The project
manager is responsible for managing all proposed and approved changes to the
communications management plan. Once the change is approved, the project manager
will update the plan and supporting documentation and will distribute the updates to the
project team and all stakeholders. This methodology is consistent with the project’s
Change Management Plan and ensures that all project stakeholders remain aware and
informed of any changes to communications management.
5.12.2.2 Communications Management Constraints
 All projects are subject to limitations and constraints as they must be within scope and
adhere to budget, scheduling and resource requirements.
 Project planning and documentation are no exception to this rule. There may also be
legislative, regulatory, technology, or organizational policy requirements which must be
followed as part of communications management.
 These constraints must be clearly understood and communicated to all stakeholders.
While communications management is arguably one of the most important aspects of
project management, it must be done in an effective manner and within the constraints
of the allocated budget, time, and resources.
5.12.2.3 Communication Activities Management
 All project communication activities will occur within the project’s approved budget,
schedule, and resource allocations. The project manager is responsible for ensuring that
communication activities are performed by the project team and without external
resources which will result in exceeding the authorized budget.

 Communication activities will occur in accordance with the frequencies detailed in the
communication matrix in order to ensure the project adheres to schedule constraints.
Any deviation of these timelines may result in excessive costs or schedule delays and
must be approved by the project sponsor.
 Most projects consist of a broad range of stakeholders all of whom may have differing
interests and influence on the project. As such, it is important for project teams to
determine the communication requirements of these stakeholders in order to more
effectively communicate project information. There are a number of methods for
determining stakeholder communication requirements; however, it is imperative that
they are completely understood in order to effectively manage their interest,
expectations, and influence and ensure a successful project.
 As part of identifying all project stakeholders, the project manager will communicate
with each stakeholder in order to determine their preferred frequency and method of
communication. This feedback will be maintained by the project manager in the
project’s stakeholder register.
 Standard project communications will occur in accordance with the communication
matrix; however, depending on the identified stakeholder communication requirements,
individual communication is acceptable and within the constraints outlined for this
project.
 In addition to identifying communication preferences, stakeholder communication
requirements must identify the project’s communication channels and ensure that
stakeholders have access to these channels. If project information is communicated via
secure means or through internal company resources, all stakeholders, internal and
external, must have the necessary access to receive project communications.
 Once all stakeholders have been identified and communication requirements are
established, the project team will maintain this information in the project’s stakeholder
register and use this, along with the project communication matrix as the basis for all
communications.
5.12.2.4 Roles in Communication Management
Project Sponsor : The Project Sponsor is the champion of the project and has
authorized the project by signing the project charter. This person is responsible for the funding
of the project and is ultimately responsible for its success. Since the Project Sponsor is at the
executive level communications should be presented in summary format unless the Project
Sponsor requests more detailed communications.

Program Manager : The Program Manager oversees the project at the portfolio level
and owns most of the resources assigned to the project. The Program Manager is responsible
for overall program costs and profitability as such they require more detailed communications
than the Project Sponsor.
Key Stakeholders : Normally Stakeholders includes all individuals and organizations
who are impacted by the project. The Key Stakeholders includes executive management with
an interest in the project and key users identified for participation in the project.
Change Control Board : The Change Control Board is a designated group which is
reviews technical specifications and authorizes changes within the organizations
infrastructure. Technical design documents, user impact analysis and implementation
strategies are typical of the types of communication this group requires.
Customer : You should identify the customer if the project is the result of a
solicitation. Generally the customer will be involved in reviewing prototypes, approval of
designs and implementation stages and acceptance of the final project the project generates.
As the customer who will be accepting the final deliverable of this project they will be
informed of the project status including potential impacts to the schedule for the final
deliverable or the product itself.
Project Manager : The Project Manager has overall responsibility for the execution of
the project. The Project Manager manages day to day resources, provides project guidance and
monitors and reports on the projects metrics as defined in the Project Management Plan. As
the person responsible for the execution of the project, the Project Manager is the primary
communicator for the project distributing information according to this Communications
Management Plan.
Project Team : The Project Team is comprised of all persons who have a role
performing work on the project. The project team needs to have a clear understanding of the
work to be completed and the framework in which the project is to be executed. Since the
Project Team is responsible for completing the work for the project they played a key role in
creating the Project Plan including defining its schedule and work packages. The Project Team
requires a detailed level of communications which is achieved through day to day interactions
with the Project Manager and other team members along with weekly team meetings.
Steering Committee : The Steering Committee includes management representing the
departments which make up the organization. The Steering Committee provides strategic
oversight for changes which impact the overall organization. The purpose of the Steering
Committee is to ensure that changes within the organization are effected in such a way that it
benefits the organization as a whole. The Steering Committee requires communication on
matters which will change the scope of the project and its deliverables.

Technical Lead : The Technical Lead is a person on the Project Team who is
designated to be responsible for ensuring that all technical aspects of the project are addressed
and that the project is implemented in a technically sound manner. The Technical Lead is
responsible for all technical designs, overseeing the implementation of the designs and
developing as-build documentation. The Technical Lead requires close communications with
the Project Manager and the Project Team.
5.12.3 Communication Methods and Technologies
Many times, the methods and technologies used to communicate are just as important of
a consideration as the information being communicated. Imagine a large project with many
stakeholders who all have different technological capabilities. Some may have access to a
share drive while others do not. Some may have access to video teleconferencing and others
only have telephone and email capabilities. In order to be effective, project information must
be communicated to everyone involved by some method using available technology.
Determining communication methods and what technologies are available should be part of
determining stakeholder communication requirements.
5.12.3.1 Communication Matrix
 The Project Manager will take a proactive role in ensuring effective communications on
this project. The communications requirements are documented in the Communications
Matrix. The Communications Matrix will be used as the guide for what information to
communicate, who is to do the communicating, when to communicate it and to whom
to communicate.
Communications Matrix Example
Communication Objective of Medium Frequency Audience Owner Deliverable Format
Type Communication
Kickoff Introduce the  Face to Once  Project Project  Agenda  Soft

Meeting project team Face Sponsor Manager Meeting copy
and the  Project Minutes archived
project. Team on
Review Stakeholders SharePoint
project site and
objectives and project
management website.
approach.

Project Team Review status  Face to Weekly  Project Project  Agenda  Soft
Meetings of the project Face Team Manager  Meeting copy
with the team. Conference Minutes archived
Call  Project on
Schedule SharePoint
site and
project
website.
Technical Discuss and  Face to As  Project Technical  Agenda  Soft

Design develop Face Needed Technical Lead  Meeting copy
Meetings technical Staff Minutes archived
design on
solutions for SharePoint
the project. site and
project
website.
Monthly Report on the  Face to Monthly - PMO Project  Slide  Soft

Project Status status of the Face Manager Updates – copy
Meetings project to Conference  Project archived
management. Call Schedule on
SharePoint
site and
project
website.
Project Status Report the  Email Monthly  Project Project  Project  Soft
Reports status of the Sponsor Manager Status copy
project  Project Report archived
including Team  Project on
activities, Stakeholders Schedule SharePoint
progress, costs  PMO site and
and issues. project
website.

5.12.3.2 Communication Flowchart

 Flowcharts provide a visual representation of a process or processes which often allow
a better understanding of how the process is intended to work. Project communications
may be extremely complex depending on the size and scope of the project and the
number of stakeholders. A flowchart provides all stakeholders with a better
understanding of the steps involved with the distribution of all project communications.
 The communication flowchart below was created to aid in project communication. This
flowchart provides a framework for the project team to follow for this project.
 However, there may be occasions or situations which fall outside of the communication
flowchart where additional clarification is necessary. In these situations the Project
Manager is responsible for discussing the communication with the Project Sponsor and
making a determination on how to proceed.
5.12.4 Guidelines for Meetings in Communication Management
Meeting Agenda : Meeting Agenda will be distributed 5 business days in advance of

the meeting. The Agenda should identify the presenter for each topic along with a time limit
for that topic. The first item in the agenda should be a review of action items from the
previous meeting.
Meeting Minutes : Meeting minutes will be distributed within 2 business days
following the meeting. Meeting minutes will include the status of all items from the agenda
along with new action items and the Parking Lot list.
Action Items : Action Items are recorded in both the meeting agenda and minutes.
Action items will include both the action item along with the owner of the action item.

Meetings will start with a review of the status of all action items from previous meetings and
end with a review of all new action items resulting from the meeting. The review of the new
action items will include identifying the owner for each action item.
Meeting Chair Person : The Chair Person is responsible for distributing the meeting
agenda, facilitating the meeting and distributing the meeting minutes. The Chair Person will
ensure that the meeting starts and ends on time and that all presenters adhere to their allocated
time frames.
Note Taker : The Note Taker is responsible for documenting the status of all meeting
items, maintaining a Parking Lot item list and taking notes of anything else of importance
during the meeting. The Note Taker will give a copy of their notes to the Chair Person at the
end of the meeting as the Chair Person will use the notes to create the Meeting Minutes.
Time Keeper : The Time Keeper is responsible for helping the facilitator adhere to the
time limits set in the meeting agenda. The Time Keeper will let the presenter know when they
are approaching the end of their allocated time. Typically a quick hand signal to the presenter
indicating how many minutes remain for the topic is sufficient.
Parking Lot : The Parking Lot is a tool used by the facilitator to record and defer items
which aren’t on the meeting agenda; however, merit further discussion at a later time or
through another forum.
A parking lot record should identify an owner for the item as that person will be
responsible for ensuring follow-up. The Parking Lot list is to be included in the meeting
minutes.
5.12.5 Communication Standards
 Standardization is a proven way to simplify the complexities of project management
communications. Many organizations develop and use standard templates or formats for
the various communication tools used throughout projects.
 Standard templates and formats may be applied to certain types of project meetings or
specific types of communication (i.e. emails, status reports, etc.). By using
standardization, organizations can help ensure that its project teams and stakeholders
have a thorough understanding of what is expected and achieve consistent and effective
communications.
 In addition to standard templates and/or formats, organizations may standardize file
naming or sharing conventions. An organization may use SharePoint or some other type
of Web Portal/Network tool (blogs, message boards, etc.) as a standard platform from
which to share information and communicate.

 Additionally, an organization may have standard file naming conventions for their
stored data on their internal share drives. Many of these tools and new technologies are
used in today’s projects with team members and stakeholders often spread over wide
geographic areas.
 Standardization provides a level of simplicity to an organization’s communication
platforms and improves effectiveness and efficiency.
 Informal project communications should be professional and effective but there is no
standard template or format that must be used.
5.12.6 Communication Escalation Process
 As issues or complications arise with regards to project communications it may become

necessary to escalate the issue if a resolution cannot be achieved within the project
team. Project stakeholders may have many different conflicting interests in a given
project. While escalations are a normal part of project management, there must be a
documented process that defines how those escalations will take place.
 Efficient and timely communication is the key to successful project completion. As
such, it is imperative that any disputes, conflicts, or discrepancies regarding project
communications are resolved in a way that is conducive to maintaining the project
schedule, ensuring the correct communications are distributed, and preventing any
ongoing difficulties. In order to ensure projects stay on schedule and issues are resolved
there is a standard escalation model to provide a framework for escalating
communication issues.
Example :
The following table defines the priority levels, decision authorities and time frames for
reduction.
Priority Definition Decision Timeframe for Resolution
Authority
Priority 1 Major impact to project or business Vice Within 4 hours

operations. If not resolved quickly President or
there will be a significant adverse higher
impact to revenue and/or schedule.
Priority 2 Medium impact to project or Project Within one business day

business operations which may result Sponsor
in some adverse impact to revenue

and/or schedule.
Priority 3 Slight impact which may cause some Project Within two business days
minor scheduling difficulties with the Manager
project but no impact to business
operations or revenue.
Priority 4 Insignificant impact to project but Project Work continues and any
there may be a better solution. Manager recommendations are
submitted via the project
change control process
Any communication including sensitive and/or confidential information will require

escalation to VP level or higher for approval prior to external distribution.
5.12.7 Glossary of Communication Terminology
Term Definition
Communication The effective sending and receiving of information. Ideally, the

information received should match the information sent. It is the
responsibility of the sender to ensure this takes place.
Stakeholder Individuals or groups involved in the project or whose interests may be

affected by the project’s execution or outcome.
Communications Portion of the overall Project Management Plan which details how
Management Plan project communications will be conducted, who will participate in
communications, frequency of communications and methods of
communications.
Escalation The process which details how conflicts and issues will be passed up
the management chain for resolution as well as the timeframe to
achieve resolution.
5.13 Organizational Structure
The current types of organizational structure of project management are: functional

organizational structure, project-based organizational structure and matrix organizational
structure.

1. Functional organizational structure
Functional organizational structure is to be managed in the current organization

hierarchical structure, once the project begins operation, the various components of the
project are taken by the functional units, each unit is responsible for its charged
component. If the the project established, a functional area play a dominant role,
functional areas on completion of the project, senior managers will be responsible for
project coordination.
Advantages of this structure : First, the use of personnel with greater flexibility, as
long as the choice of a suitable functional departments as the project supervisor, the
department will be able to provide professional and technical personnel required by the
project, and technology experts can also be used by different projects and after completion of
the work can go back to his original work; Second, when the project team members leave or
leave the company, the functions can be used as the basis for maintaining the continuity of the
project; third, functional department can provide a normal career path for professionals.
The disadvantage of this structure is : First, projects often lack of focus, each unit
has its own core functions of general business, sometimes in order to meet their basic needs,
responsibility for the project will be ignored, especially when the interest taken in the project
brought to the unit not the same interest; Second, such organization has certain difficulties in
the inter-departmental cooperation and exchanges; Third motivation is not strong enough for
project participants, they think the project is an additional burden, and not directly related to
their career development and upgrading; Fourth, in such organizational structure, sometimes
no one should assume full responsibility for the project, often the project manager is only
responsible for part of the project, others are responsible for the other parts of the project,
which leads to difficulties in coordination situation.

2. Project-based organizational structure
Project organizational structure refers to the creation of an independent project team,

the team’s management is separated from the parent organization’s other units, have
their own technical staff and management, enterprise assigns certain resources to
project team, and grant project manager of the largest free implementation of the
project.
The advantages of this structure : First, focus on this project team, project manager
is solely responsible for the project, the only task for project members is to complete the
project, and they only report to the project manager, avoiding the multiple leadership; Second,
the project team’s decision is developed within the project, the reaction time is short; Third,
in this project, members work with strong power, high cohesion, participants shared the
common goal of the project, and individual has clear responsibilities.
The disadvantage of this organizational structure : First, when a company has
several projects, each project has its own separate team, which will lead to duplication of
efforts and the loss of scalable economies; Second, the project team itself is an independent
entity, prone to a condition known as “Project inflammatory” disease, that is, there is a clear
dividing line between the project team and the parent organization, weakening the effective
integration between project team and the parent organization; Third, the project team
members lack of a business continuity and security, once the project ended, return to their
original functions may be more difficult.
3. Matrix organizational structure
Matrix organizational structure is a hybrid form, it loads a level of project management

structure on the functional hierarchical structure. According to the relative power of project
managers and functional managers, in practice there are different types of matrix systems,
respectively,Functional Matrix : in this matrix, functional managers have greater powers

than project managers); Project Matrix : in this matrix, project managers have greater powers
than functional managers); Balance Matrix : in this matrix, functional managers and project
managers have the equal powers.
The advantages of this organizational structure : First, it is the same as functional

structure that resources can be shared in multiple projects, which can significantly reduces the
problem of redundant staff; Second, project is the focus of work, with a formal designated
project manager will make him give more attention to the project, and responsible for the
coordination and integration work between different units; Third, when there are multiple
projects simultaneously, the company can balance the resources to ensure that all the projects
can progress to complete their respective costs and quality requirements; Fourth, the anxiety
of project members is reduced greatly after the end of the project, while they are strongly
associated with the project, on the other hand, they have a “home” feeling about their
functions.
The disadvantage is that this organizational structure : First, the matrix structure
has exacerbated the tensions between functional manager and project manager; Second, under
any circumstances, sharing equipment, resources and personnel among different projects will
lead to conflict and competition for scarce resources; Third, in the process of project
implementation, the project manager must negotiate and consult with the department
managers on various issues, which leads to the delay in decision making; Fourth, matrix
management is not according to the principles of unified management, project members have

two bosses, the project manager and functional managers, when their commands are divided,
it will make members at a loss.
Three different forms of the matrix organizational structure does not necessarily have
the advantages and disadvantages described above: Project Matrix can increase the project’s
integration, reduce internal power struggle, its weakness is poor control of their functional
areas and prone to “project inflammation”; Functional Matrix can provide a better system for
managing the conflict between different projects, but maintaining the control of functions is at
the cost of inefficient integration of projects; Balanced Matrix can achieve the balance
between technology and project requirements better, but its establishment and management is
very subtle, is likely to encounter many problems related to matrix organization.
5.14 Leadership
Leadership is the action of leading people in an organization towards achieving goals.

Leaders do this by influencing employee behaviors in several ways. A leader sets a clear
vision for the organization, motivates employees, guides employees through the work process
and builds morale.
5.14.1 Function of Leadership in Organizations
Setting a clear vision means influencing employees to understand and accept the future
state of the organization. A unit of young soldiers may not believe in a particular mission
ordered by their commanding officer. A good leader will influence the soldiers to perform
their duties by explaining the vision and the importance of their role in the outcome. The
soldiers will be more apt to follow.
Motivating employees means to find out enough about the needs and wants of
employees, giving them what they need and providing praise for a job well done. Being far
from home is lonely for a young soldier. A good leader knows this and will communicate with
his unit to learn more about their needs and wants. It may be as simple as giving the soldiers a
sweet treat for their efforts.
When guiding employees, it is important to define their role in the work process and
provide them with tools needed to perform and participate in their efforts along the way. Some
military maneuvers are difficult. Often, orders are to perform tasks that involve intricate
details, like explaining how to dig a tunnel past enemy lines. A good leader will explain the
tasks, provide the digging tools, direct the work and be available to assist the soldiers if they
run into a problem.
Building morale involves pulling everyone together to work towards a common goal.
Let's face it - fighting in a war is stressful. Soldiers are often placed in high-stress situations.
This can cause the unit to lose their focus or, worse yet, shut down emotionally. A good leader

will let the soldiers know how much their work is appreciated. A simple gesture like throwing
an impromptu party to recognize the unit's small victories can reignite the soldiers' spirits.
5.14.2 A Leader's Role
A leader's role in an organization can be formally assigned by his or her position, like
manager or department head, and it can also be informally assumed by an employee who
possesses a certain charisma that attracts others to follow.
A formal leadership role is an officially assigned position given to someone based on
his or her ability to perform the job. It generally involves organizing and directing people to
perform tasks, like the job of Commanding Officer (CO) in the military. The CO holds the
highest level of authority over his unit. He is in charge of everything, from deciding how to
fight the enemy to overseeing the day-to-day tasks of his soldiers.
5.14.3 Model of Leadership (MOI)
Motivation : The ability to encourage (by "push or pull") technical people to produce to
their best ability.
Organization : The ability to mold existing processes (or invent new ones) that will
enable the initial concept to be translated into a final product.
Ideas or innovation : The ability to encourage people to create and feel creative even
when they must work within bounds established for a particular software product or
application.
Q.1 List the steps involved in selecting the right person for the job.
Q.2 Give an example for becoming a team and explain working within groups with
example. (Refer section 5.7) Dec. - 2012 .
Q.3 Explain the different ways of decision making. (Refer section 5.8) Dec. - 2012 .
Q.4 Discuss the organizational behavior with Example. (Refer section 5.2)
Dec. - 2012 .
Q.5 Discuss leadership models. Explain the function of a leader with an example.
Q.6 Explain the factors to be considered in the Oldman Hackman job Characteristic
model? Give the Vroom’s expectancy theory.
(Refer section 5.5 (For job characteristic model)) .
(Refer section 5.4.2.5(For Vroom expectancy theory)) Dec. - 2013 .

Q.7 Describe the metrics and issues involved in selecting the right person for the job.
Q.8 Explain the Maslow’s hierarchy of needs with an example.
(Refer section 5.4.2.1) May- 2014 .
Q.9 Discuss in detail the term “decision making” in the process of managing people and
organizing teams. With an example explain the strength of a team.
(Refer section 5.8 (Decision making))
(Refer section 5.7.4 (Strength of a team) May - 2014 .
Q.10 What are the three basic objectives of organizational Behaviour.
Q.11 State Herzberg’s two factor theory. (Refer section 5.4.2.2) Dec. - 2014 .
Q.12 What do you understand by virtual teams. (Refer section 5.10) Dec. - 2014 .
Q.13 Explain the Oldham-Hackman job characterstics model. (Refer section 5.5)
Dec. - 2014 .
Q.14 Give a brief description of the various organizational structures.
Q.15 Explain the various model of motivation in detail. (Refer section 5.4.2)
Dec. - 2014 .
Staffing in Software Projects ends....

Notes

Solved Paper May - 2017
May - 2017
Software Project Management AU
Semester - VIII (CSE/IT) Elective - V
Solved Paper
[72202]
Regulation - 2013
Time : Three Hours] [Maximum Marks : 100

Answer ALL Questions
PART A - (10  2 = 20 Marks)
Q.1 Define software project management. (Refer section 1.1.3)
Q.2 What is software project planning ? (Refer section 1.6)
Q3 What is the function of spiral model. (Refer Page no. 2 - 7)
Q.4 What is activity model ? (Refer section 3.3)
Q.5 Name the any two levels of COSMIC model. (Refer section 2.4)
Q.6 Differentiate between CPM and PERT.
Ans. : Difference between CPM and PERT :
Basic PERT CPM
Stands for PERT stands for “Program CPM stands for “Critical Path
Evaluation and Review Method”.
Technique”.
Model It is a probabilistic model under It is a deterministic model under
which the result estimated in a which the result is ascertained in a
manner of probability. manner of certainty.
Time It deals with the activities of It deals with the activities of
uncertain time. precise well known time.
Jobs It is used for onetime projects that It is used for completing of
involve activities of non-repetitive projects that involve activities of
nature. repetitive nature.
Orientation It is activity oriented in as much as It is even oriented, in as much as
its result is calculated on the basis of its results are calculated on the
the activities. basis of the events.
Dummy It does not make use of dummy It makes use of dummy activities
Activities activities. to represent the proper sequencing
of the activities.
Cost It has nothing to do with cost of a It deals with the cost of a project
project. schedules and their minimization.
S-1 Software Project Management

Estimation It finds out expected time of each Its calculation is based on one type
activity on the basis of three types of time estimation that is precisely
of estimates. known.
Time PERT is restricted to time variable. CPM includes time-cost trade off.
Q.7 Define configuration management. (Refer section 4.6)
Q.8 Define change control. (Refer section 4.5)
Q.9 Write significance of Oldham-Hackman job characteristic model.
(Refer section 5.5.2)
Q.10 Define software reliability.
Ans. :
 Software reliability is the probability of failure-free software operation for a specified
period of time in a specified environment.
 Software reliability is also an important factor affecting system reliability.
 It differs from hardware reliability in that it reflects the “design perfection ”, rather than
manufacturing perfection.
 The high complexity of software is the major contributing factor of software reliability
problems.
Traditional Methods For Improving Software Reliability
 Three main techniques are used in industrial and open source projects to improve software
reliability :
Manual Testing
Code Reviews :
 Modifications are reviewed by experienced developers before being committed to the code
base.
Coding Standards :
 Required that all developers adhere to a set of rules when writing or maintaining code.
 Coding standards can improve source code readability, making it easier to spot defects,
and
 Ban the use of programming idioms that are arguably dangerous.
PART B - (5 × 16 = 80 Marks)
Q.11 a) Narrate the phases of software project management. (Refer section 1.1.3)
OR
b) Briefly explain about cost benefit evaluation technology. (Refer section 1.4)
Q.12 a) Explain COCOMO-II model. (Refer section 2.6)

OR
b) Discuss extended function point with an example. (Refer section 2.4)
Q.13 a) Narrate the various network models and calculations used in the moel and
differentiate between them. (Refer section 3.6)
OR
b) Discuss the risk identification process and the mitigation steps involved in the
project management. (Refer section 3.7)
Q.14 a) Explain with examples software configuration management. (Refer section 4.6)
OR
b) Discuss the framework for project management and control.
(Refer sections 4.1 and 4.2)
Q.15 a) Explain different types of team structures used in the project management.
(Refer section 5.9)
OR
b) Describe the best methods of staff selection and its merits and demerits.
(Refer section 5.3)


Notes

Solved Paper Dec. - 2017
December - 2017
Solved Paper
[50922]
Regulation - 2013

PART A - (10  2 = 20 Marks)
Q.1 What is cost benefit analysis ? (Refer section 1.4)
Q.2 Outline the need for risk evaluation. (Refer section 1.5)
Q3 What is rapid application development ? (Refer section 2.1)
Q.4 Outline the advantages of agile unified process.
Ans.. : Advantage of agile unified process :
The most important of the advantages of agile model is the ability to respond to the
changing requirements of the project. This ensures that the efforts of the development
team are not wasted, which is often the case with the other methodologies. The
changes are integrated immediately, which saves trouble later. There is no guesswork
between the development team and the customer, as there is face to face
communication and continuous inputs from the client. The documents are to the point,
which no leaves no space for ambiguity. The culmination of this is that a high quality
software is delivered to the client in the shortest period of time and leaves the customer
satisfied.
Q.5 Appraise the need for modeling precedence networks. (Refer section 3.6)
Q.6 Name the three time estimates in PERT. (Refer section 3.6.2)
Q.7 What is change control ? (Refer section 4.5)
Q.8 Define outsourcing.
Ans. : Outsourcing :
Outsourcing is a business practice in which a company hires another company or an individual
to perform tasks, handle operations or provide services that are either usually executed or had
previously been done by the company's own employees.
The outside company, which is known as the service provider or a third-party provider,
arranges for its own workers or computer systems to perform the tasks or services either on
site at the hiring company's own facilities or at external locations.

Companies today can outsource a number of tasks or services. They often outsource
information technology services, including programming and application development as well
as technical support. They frequently outsource customer service and call service functions.
They can outsource other types of work as well, including manufacturing processes, human
resources tasks and financial functions such as bookkeeping and payroll. Companies can
outsource entire divisions, such as its entire IT department, or just parts of a particular
department.
Outsourcing business functions is sometimes called contracting out or business process
outsourcing.
Outsourcing can involve using a large third-party provider, such as a company like IBM to
manage IT services or FedEx Supply Chain for third-party logistics services, but it can also
involve hiring individual independent contractors and temporary office workers.
Q.9 What is Motivation ? (Refer section 5.4)
Q.10 Outline strategies for risk reduction can be adopted for the following software project.
risk : Personnel (staffing) shortfalls
Ans. : Risk reduction is an investment of funds to reduce the risk on a project. On
international projects, companies will often purchase the guarantee of a currency rate
to reduce the risk associated with fluctuations in the currency exchange rate. A project
manager may hire an expert to review the technical plans or the cost estimate on a
project to increase the confidence in that plan and reduce the project risk. Assigning
highly skilled project personnel to manage the high-risk activities is another risk-
reduction method. Experts managing a high-risk activity can often predict problems
and find solutions that prevent the activities from having a negative impact on the
project. Some companies reduce risk by forbidding key executives or technology
experts to ride on the same airplane.
PART B - (5 × 16 = 80 Marks)
Q.11 a) i) What is a project ? Outline the characteristics of project. [5]
ii) How are infrastructure projects different from software projects ? Discuss. [5]
iii) Outline the activities involved in management. [6]
Ans. : i) Project :
A project is well-defined task, which is a collection of several operations done in order to
achieve a goal (for example, software development and delivery). A Project can be
characterized as:
 Every project may has a unique and distinct goal.
 Project is not routine activity or day-to-day operations.
 Project comes with a start time and end time.

 Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an
organization.
 Project needs adequate resources in terms of time, manpower, finance, material and
knowledge-bank.
Software projects have several characteristics that make them very different to other kinds of
engineering project.
 The product is intangible. Its hard to claim a bridge is 90% complete if there is not 90% of
the bridge there. It is easy to claim that a software project is 90% complete, even if there
are no visible outcomes.
 We don’t have much experience. Software engineering is a new discipline, and so we
simply don’t have much understanding of how to engineer large scale software projects.
 Large software projects are often “bespoke”. Most large software systems are one-off, with
experience gained in one project being of little help in another.
The technology changes very quickly. Most large software projects employ new technology;
for many projects, this is the raison deter.
ii) Infrastructure project :
The word Infrastructure refers to the fundamental facilities and systems serving a country,
city, or other area,[1] including the services and facilities necessary for its economy to
function.[2] Infrastructure is composed of public and private physical improvements such
as roads, bridges, tunnels, water supply, sewers, electrical grids, and telecommunications
(including Internet connectivity and broadband speeds). In general, it has also been defined as
"the physical components of interrelated systems providing commodities and services essential
to enable, sustain, or enhance societal living conditions."[3]
There are two general types of ways to view infrastructure, hard or soft. Hard
infrastructure refers to the physical networks necessary for the functioning of a modern
industry.[4] This includes roads, bridges, railways, etc. Soft infrastructure refers to all the
institutions that maintain the economic, health, social, and cultural standards of a country.This
includes educational programs, parks and recreational facilities, law enforcement agencies, and
emergency services.
Software project : A Software Project is the complete procedure of software development
from requirement gathering to testing and maintenance, carried out according to the execution
methodologies, in a specified period of time to achieve intended software product.
iii) A software project is not only concerned with the actual writing of software. Infact, where
a software application is bought "off the shelf " , there may be no software writing as such, but
this is still fundamentally a software project because so many of the other activities associated
with software will still be present.

The feasibility Study : Assesses whether a project is worth starting-that it has a valid
' business case '. Information is gathered about the requirements of the proposed application.
Requirements elicitation can, at least initially, be complex and difficult. The stakeholders may
know the aim they wish to pursue, but not be sure about the means of achievement. The
developmental and the operational costs, and the value of the benefits of the new system, will
also have to be estimated.
Planning : If the feasibility study indicates that the prospective project appears viable, then
project planning can start. We create an outline plan for the whole project and a detailed one
for the first stage. Because we will have more detailed and accurate project information after
the earlier stages of the project have been completed, planning of the later stages is left to
nearer their start.
Project execution : The project can now be executed. The execution of a project often
contains design and implementation sub-phases. Design is making decision about the form of
the products to be created. This could relate to the external appearance of the software, that is,
the user interface, or the internal architecture. The plan details the activities to be carried out to
create these products. Planning and design can be confused because at the most detailed level
planning decisions are influenced by design decisions.
OR
b) What is project planning ? Explain with diagrammatic illustration the stepwise
project planning activities. (Refer section 1.6) [16]
Q.12 a) Discuss the spiral software development life cycle model with diagrammatic
illustration. What are the spiral model strengths ? What are the spiral model
deficiencies ? When to use the spiral model ? Discuss. (Refer section 2.1.1) [16]
OR
b) Explain the steps in the COCOMO II effort estimation technique.
(Refer section 2.6) [16]
Q.13 a) i) Draw a network diagram representing the following logic.
As the project starts, activities A and B can be performed concurrently. When A is
finished, activities C and D can start. When B is finished, activities E and F can start.
When activities D and E are finished, activity G can start. The project is complete
when activities C, F and G are finished. (Refer section 3.6) [8]
ii) Appraise with an example Monte Carlo simulation. (Refer section 3.8) [8]

OR
b) Explain with an example the use of network techniques PERT and CPM in software
project management. (Refer section 3.6) [16]
Q.14 a) i) Scope and deliverables of software projects are changed frequently. This has
severe implications on the projects. How can a project manager minimize their impact
on the project. [8]
Ans. : i) Simply stated, scope creep refers to the change in a project's scope (time, cost, and
deliverables) after the project work has started. Changes in scope often come from small,
seemingly insignificant change requests that the project team accepts to keep the project
sponsor happy. Eventually, the change requests become numerous enough that they are
significant or one of the requests turns out to require much more work than expected.
Ways to Tackle Scope Creep
1. Set clear expectations
From the beginning of your project set clear expectations on your deliverables, the time
required, and the costs. Clearly identify what is IN and what is OUT of your project. Then
continually manage those expectations throughout the project.
2. Mention the monster
Acknowledge that scope creep is possible and that the team needs to be aware of how creep
happens.
3. Keep track of changes
Change is inevitable on any project. The trick is to keep track of those changes and ensure
your sponsor understands the impact of each change on the overall project.
4. Speak up sooner
As soon as you sense that your scope is beginning to creep…speak up and identify the
potential change and its impact. Don’t wait to see if it just melds into your project quietly.
5. Put it in writing
Document, document, document. Then communicate, communicate, communicate. Ensure
that all key stakeholders understand the impact of the creep.
6. Get approval and readjust
If scope creep creates new deliverables, expands your time, and/or costs more than the original
scope for your project – make sure your sponsor signs off on the change. Then readjust your
planning and continue your project.
ii) Appraise the activities involved in software configuration management.

OR
b) Explain with an example how the earned value chart depicts scheduled progress,
actual cost and actual progress (earned value) to allow the determination of spending,
schedule and time variances. (Refer section 4.4) [16]
Q.15 a) Explain the Oldham-Hackman job characteristics model.
OR
b) What is a team ? Discuss the types of team structures.
(Refer sections 5.7 and 5.9) [16]

S - 10 Software Project Management

May - 2018
Solved Paper
[41453]
Regulation - 2013

PART A - (10  2 = 20 Marks)
Q.1 What is the need of Software Project Management ?
Q.2 Define software quality metrics.
Q3 What is SCRUM ?
Q.4 Brief about two ways of setting objectives.
Q.5 Define Monitoring.
Q.6 What is Monte Carlo simulation method ?
Q.7 How to Visualize Progress ?
Q.8 Distinguish between Earned Value Analysis and Earned Value Management.
Q.9 Define virtual team.
Q.10 What is the role of Ethics in Project Management ?
PART B - (5 × 16 = 80 Marks)
Q.11 a) Outline on Management Objectives and Priorities.
OR
b) i) What is Risk ? Discuss about risk management process.
ii) List out various paradigms, principles to manage the risks in project.
Q.12 a) i) Explain the steps involved for Extreme Programming.
ii) List all its advantages and disadvantages.
OR
b) What are the Components of Staffing ? Explain the methods of Staffing level
estimation.
Q.13 a) What is a critical path method ? Discuss CPM with activity bar chart.
OR
b) In what way project evaluation and review technique can be represented through
activity network ? Explain.

Q.14 a) Who is responsible for Project Tracking ? Brief the different ways to track a
project.
OR
b) Discuss in detail the types of contracts with its checklist.
Q.15 a) Explain Hackman and Oldham job characteristics model.
OR
b) How to deal with Ethical and programming Concerns in software project
Management ?


It8075 SPM Local Author Book

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

It8075 SPM Local Author Book

Uploaded by

Copyright:

Available Formats

SUBJECT CODE : MG6088

Strictly as per Revised Syllabus of

Semester - VIII (Computer Science & Engineering / Information Technology) Elective - V

First Edition : January 2017

ã Copyright with Author

9789333214216 [3] (ii)

Chapter - 2 Project Life Cycle and Effort Estimation (2 - 1) to (2 - 50)

Chapter - 3 Activity Planning and Risk Management (3 - 1) to (3 - 66)

Chapter - 4 Project Management and Control (4 - 1) to (4 - 46)

Chapter - 5 Staffing in Software Projects (5 - 1) to (5 - 74)

Solved Question Paper of Anna University (S - 1) to (S - 4)

Syllabus : Importance of Software Project Management – Activities Methodologies –

Section No. Topic Name Page No.

1-1 Software Project Management

1.1 Software Project Management

 Construction of Chennai Airport

A project is not normal day to day activity undertaken by organization rather it is

1-2 Software Project Management

A project in any organization is collaboration across departments to achieve a single

Basically, the management involves the following activities :

1-3 Software Project Management

1.1.2 Software Project

A Software project is an endeavor with a clear definition of what needs to be delivered

 Non-routine tasks are involved

Many Software projects usually have two stages :

 A project will be to create a product.

 A project is to meet an objective.

1-4 Software Project Management

 Flexibility - It is easier to change/ modify software systems to meet changing

1-5 Software Project Management

1-6 Software Project Management

v) Rehabilitation project : When a project is started to revive a loss bearing

 The resulting information system is acceptable to the customer.

 Failure to establish upper-management commitment to the project

1-7 Software Project Management

1. Goal : Visitors will be convinced that global warming exists.

1-8 Software Project Management

1-9 Software Project Management

1 - 10 Software Project Management

1 - 11 Software Project Management

1.1.3 Software Project Management

1 - 12 Software Project Management

1.1.3.1 Importance of Software Project Management

1 - 13 Software Project Management

1.1.3.2 Need of Software Project Management

Software is said to be an intangible product. Software development is a kind of all new

1 - 14 Software Project Management

Project management can involve the following activities :

Effective objectives in project management are specific. A specific objective increases

1. Performance and Quality

1 - 15 Software Project Management

 Must follow SMART approach

 A theoretical knowledge of different project management techniques is certainly

1 - 16 Software Project Management

Software project management comprises of a number of activities, which contains

1 - 17 Software Project Management

1 - 18 Software Project Management

1.1.3.7 Management Functions and Activities

 Set objectives and goals

1 - 19 Software Project Management

 Forecast future situations-predict the future and plan accordingly

 Identify and group project function, activities, and tasks

1 - 20 Software Project Management