Professional Documents
Culture Documents
IT8075 - Software Project Management (Ripped From Amazon Kindle Ebooks by Sai Seena)
IT8075 - Software Project Management (Ripped From Amazon Kindle Ebooks by Sai Seena)
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
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
(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
(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
2.8 University Questions with Answers ................................................................ 2 - 49
(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
(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
4.9 University Questions with Answers ................................................................ 4 - 44
(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
(xiii)
(xiv)
Project Evaluation and Project Planning
Unit - I
Chapter - 1
PROJECT EVALUATION AND PROJECT PLANNING
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
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
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.
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.
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 :
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.
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.
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
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.
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.
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
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
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 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
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
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
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
Fig. 1.1.3
1. The people : The stakeholders
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
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
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
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.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.
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.
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.
Senior management
Project manager/coordinator
Team leader
Project evaluation - When
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
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
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
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 ?
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
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
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
Payback 5 5 4 4
Simple example : (where negative values represent net expenses, positive values
represent net incomes)
Assumptions :
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
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 :
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
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
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
Fig. 1.5.2
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.
Introduction
Project organisation
Risk analysis
Hardware and software resource requirements
Work breakdown
Project schedule
Monitoring and reporting mechanisms
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
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.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
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
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)
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.
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.
Fig. 1.8.2
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
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.
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
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.
(Refer section 1.7) Dec. - 2014 .
Notes
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.
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
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
Advantages Disadvantages
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
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.
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.
Advantages and Disadvantages
Advantages Disadvantages
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
Fig. 2.1.6
The usage
It is used in shrink-wrap large applications and systems which built-in small phases or
segments.
Advantages Disadvantages
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.
Advantages Disadvantages
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
Fig. 2.1.8
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
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.
Advantages Disadvantages
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
2.2.3 Selecting a Life Cycle Model - Project Characteristic Category Matrix User
Community
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.
Fig. 2.4.1
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
Empirical techniques :
o An educated guess based on past experience.
Heuristic 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
COCOMO Model
Fig. 2.4.2
Development time
- Sublinear function of product size.
Fig. 2.4.3
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
3. Complete COCOMO
Fig. 2.4.4
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
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
- 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
Fig. 2.5.2
Fig. 2.5.3
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
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
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
Employee Maintenance
- Employee Inquiry- 2 FTRs and 9 DETs (output)
Job Maintenance
- Job Inquiry - 1 FTR and 4 DETs (output)
Job Assignment Maintenance
- Job Assignment Inquiry- 1 FTR and 5 DETs (output)
Location Reporting
- Location Inquiry - 2 FTRs and 5 DETs (output)
RESULT - Use EI and EO matrices => 3 low complexity and 1 average (employee)
EQ Unadjusted FPs
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.
2.6.3 Calibration
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
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.
+
Unit - III
Chapter - 3
ACTIVITY PLANNING AND RISK MANAGEMENT
3.1 Introduction
Project Vs Activity
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
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.
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.
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.
Advantages
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
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
Two activities
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.
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
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
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.
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
Fig. 3.5.1
Fig. 3.5.2
Activity Float
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
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
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
Activity-on-arrow networks are less elegant when it comes to represent lagged parallel
activities.
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
Fig. 3.6.13
B Design manufacturing A 6
process
F Receive materials C 5
I Evaluate process G 3
performance
Fig. 3.6.14
Step 3(a) : Add deterministic time estimates and connected paths
Fig. 3.6.15
Calculate the Project Completion Times
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.
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
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
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
Fig. 3.6.19
Estimated path durations through the network
Fig. 3.6.20
Gannt chart showing each activity finished at the earliest possible start date
Fig. 3.6.21
Gantt chart showing the latest possible start times if the project is to be completed
in 44.83 weeks
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
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
Calculating the probability of completing the project in less than a specified time
Fig. 3.6.22
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
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.
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
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.
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.
Likelihood reduction
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
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
Project objectives :
o Ill defined
o Unclear to every team member and user
Project methods :
o Ill specified methods
o Unstructured methods
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
3 Risk planning
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
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
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.
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 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
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
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.
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).
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
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
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
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.
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
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.
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
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.
(Refer section 3.3.1) Dec. - 2014 .
Q.14 Explain the use of checklists and brainstorming in identification of risks.
(Refer section 3.7.4) Dec. - 2014 .
Q.15 Explain the use of Gantt charts in allocation of resources.
(Refer section 3.9.14) Dec. - 2014 .
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.
(Refer section 3.7.3) Dec. - 2012 .
Q.20 What do you understand by work breakdown structure. (Refer section 3.2)
Dec. - 2014 .
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
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,
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.
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
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.
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
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.
Fig. 4.2.1
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.
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.
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
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.
Fig. 4.4.1
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 = -)
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.
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
Example 4.4.2 : What do you understand by EVA ? Given the following information for a one year
project :
Solution :
1. Cost Variance (CV) = EV AC = BCWP ACWP = 200000 250000 = 50000
2. Schedule Variance (SV) = EV PV = BCWP BCWS = 200000 230000= 30000
“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.
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.
“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 ?
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
Variant : Functionally equivalent versions, but designed for different settings, e.g.
hardware and software
Branch : A sequence of versions in the time line
Reverse delta
Mixed delta
4.6.2.3 Configuration
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)
Fig. 4.6.1
Fig. 4.6.2
Problems :
Forget to unlock
Parallel work not possible
Deadlock
Version Control Models (3/3)
Fig. 4.6.3
o Ensures that changes made to a baseline comply with the configuration status
reports
4.6.4.4 Release Management
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.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 ?
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.
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.
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
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.
Fig. 4.7.3
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
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 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.
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
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
Q.14 Explain the formal models for cost monitoring with its metrics.
(Refer section 4.3) May - 2014 .
Q.15 Outline the various steps involved in a Change Control Procedure.
(Refer section 4.5) Dec. - 2014 .
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 .
Notes
Unit - IV
Chapter - 5
STAFFING IN SOFTWARE PROJECTS
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.
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.
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.
Motivating people
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
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 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
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
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
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
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
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
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 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
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
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.
5.4 Motivation
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
Esteem 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”.
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 :
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
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 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.
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
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
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
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 :
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
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
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.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 :
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
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.
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
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
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
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.
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
Project members
5. Matrix Organization
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
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.
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.
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.
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
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 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.
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.
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
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
Type Communication
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.
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.
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
The following table defines the priority levels, decision authorities and time frames for
reduction.
Priority Definition Decision Timeframe for Resolution
Authority
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
Term Definition
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.
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.
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
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.
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
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.
(Refer section 5.3) Dec. - 2012 .
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.
(Refer section 5.14) Dec. - 2013 .
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.
(Refer section 5.3) Dec. - 2014 .
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.
(Refer section 5.2) May - 2014 .
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.
(Refer section 5.13) Dec. - 2014 .
Q.15 Explain the various model of motivation in detail. (Refer section 5.4.2)
Dec. - 2014 .
Notes
May - 2017
Software Project Management AU
Semester - VIII (CSE/IT) Elective - V
Semester - VIII (ECE) Elective - VI
Solved Paper
[72202]
Regulation - 2013
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
December - 2017
Software Project Management AU
Semester - VIII (CSE/IT) Elective - V
Semester - VIII (ECE) Elective - VI
Solved Paper
[50922]
Regulation - 2013
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.
(Refer section 4.6) [8]
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.
(Refer section 5.5) [16]
OR
b) What is a team ? Discuss the types of team structures.
(Refer sections 5.7 and 5.9) [16]
May - 2018
Software Project Management AU
Semester - VIII (CSE/IT) Elective - V
Semester - VIII (ECE) Elective - VI
Solved Paper
[41453]
Regulation - 2013
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 ?