Вы находитесь на странице: 1из 253

Project Management

1.1 INTRODUCTION
- - - - --- - -- - - - -
The concept of project management is being practiced in various fields like civil
and other engineering streams. But, because software development as well as the
artifacts such as design and code is abstract, project management was rarely practiced
in this field. Recently. the software development processes got stabilized and matured
to such an extent that applying scientific management technique to this process has
become possible. In this unit, we will be exploring various concepts of software
project management & their importance. You are already familiar with software
engineering concepts. Software engineering talks about the software development
process like analysis. design, coding and testing, while prime focus of project
management is to manage the software engineering processes effectively and
efficiently. Managing process means choosing appropriate process model, allocating
resources, estimating the time and cost and continuous monitoring of process. Project
Management is critical and is treated as a supporting discipline in software
development. Project management spans over all the processes in software
engmcenng.

Technical knowledge, e.g. designing & coding is essential but not enough to
efficiently deliver projects. Project management is more concerned about the
planning, controlling, performing, and coordination of the resources in an efficient
manner so as to deliver outcome of project in time, within the cost and as per
expectation of the customer.

Imagine that you arc asked to sit in the cockpit of an airplane and asked to navigate
the airplane. You will not know which instrument is doing what and how you should
operate the instruments in order to make the journey successful. Similarly, we feel
less comfortable in a new environment. We waste most of the time here & there to
acquaint ourselves with the environment. Understanding of environment makes us
comfortable. We will discuss the clements of software project environment that will
make you familiar & confident enough to work in the project environment.

We will discuss why projects are important and various challenges in managing the
projects in the modern software industry. This will give insight about challenges &
how to tackle them in advance.

In this unit, we will also discuss the essential skills of an effective project manager
so that one can practice & enhance it. Software project management is a subject of
practice & application of knowledge & skills. At the end of this session, there are
few questions given to review your understanding.

2
Unit 1 Time for Basics: Software Project ~anagement Concepts

1.2 ECONOMIC IMPACT OI1' SOI'T\VARE PROJECT MANAGEI\D=NT

We are living in information age. Almost everything around us is computerized.


Information Technology advancement is accelerating our economy. It is predicted
that IT literacy, number of information consumers and use of software will grow
rapidly. Statistics show that various countries are annually spending billions of dollars
in thousands of software projects. Unfortunately, there is a gap between demand
and supply. As compared to huge investment in software projects, the rate of project
success is very low. Let's sec the statistics given by Standish group.

The new Standish "Chaos" study shows a backward trend in software success:

32% Successful (On Time, On Budget, Fully Functional)

44% Challenged (Late, Over Budget, And/Or Less than Promised Functionality)

24% Failed (Cancelled or never used)

Source: Standish Group Survey "CHAOS Summary 2009"

We are loosing thousands of dollars due to project failures and cost ovcmms. Most
of the project failures arc attributed to weak project management and hence project
management has a considerable impact on economy.

Taking this as a challenge, various innovative project management methodologies


arc being practiced and claim their success rate. Even Lean principles of
manufacturing are being implemented in software project management. Due to high
demand of software worldwide & scarcity of trained software professionals, project
management will bear a phenomenal economic impact on knowledge-based economy.
Software Industry is treated like any other industry. Software becomes central
intermediate good in the new digital economy and it thus occupies a similar sort of
role as the capital goods sector did in the old economy.

If we agree with high rate of project failures due to weak project management and
hence high demand of competent software project management professionals, it is
imperative for them to deliver software projects in time, with high quality & within
a given budget. We can strengthen our economy by continuous delivery of successful
projects. It is essential that we should hone the skills, knowledge & integrate our
experience in handling global as well as domestic software projects.

3
Project Management

ie5 Activity A:
1. Find out: annual IT budget of 5 medium to large scale companies.

2. Find out five industrial sectors which cannot be computerized.

1.3 PROJECT MANAGEMENT CHALLENGJi:S IN MODERN SOFTWARE


INDUSTRY
Software industry is facing multifold challenges today. Broadly, there arc two types
of challenges, technical and non-technical challenges. A project manager has to
face both types of challenges.

Technical Challenges
Every project is different and needs to be managed differently. The methodologies
used in software development, expectations of stakeholders, the type of project
(Product/Service), ever changing technologies introduce a lot of heterogeneity. Large
projects need to support this inherent heterogeneity. Different compliances exist in
different parts of the globe which need to be considered in executing the projects in
such environments.

Non-Technical Challenges
In today's world, projects arc managed in a global environment. Managing and
motivating tcchies from different countries is also a challenge. The time differences
become significant in globally managed projects. Most of the non-technical

4
Unit 1 Time for Basics: Software Project Management Concepts

challenges are directly related to project management and have considerable impact
on project cost, scope. quality and overall performance.

Managing Global Project"


Due to advancement in intemet technology, large projects are being managed globally
where the software project team and other stakeholders of the project are dispersed
across the globe. The native language, culture, time differences, local government
rules and policies, business & process priorities and preference arc different among
countries because of socio-economic difference. These factors add complexity in
managing projects.

Measurement & Estimation


Unlike other commodities, measurement of software is not an easy task. Quantifying
amount of work done or to he done is a challenging task. Though various estimation
techniques arc available, their usage and adaptability is considerably less in software
industry. Correct estimation needs past estimation and project data, experience and
judgment. Still adjustment to the adapted estimation standard is inevitable.

Another challenge is cost estimation. As Software is an intellectual commodity,


cost estimation is not a straightforward task.

With rapid spending on IT project, top management have become more cautious &
they want to know the worth of every single penny they are investing in IT project.
Like other project~, customers are asking for return on investment. Inspite of having
various tools available to measure the return on investment and payback period, it is
still a challenge to measure and present return on investment (ROD satisfactorily to
the customers.

HR Management
People in software industry arc knowledge workers. Due to high education, global
exposure, highest pay package and global demand, the attrition rate is very high as
compared to other industries. Hiring and retaining good people becomes a challenging
task.

Emerging domains as bio technology and emerging needs of business such as


knowledge management, business intelligence, information security, etc. are posing
challenges in recruiting right people with the right skills.

5
Project Management

R5 Activity B:
1. What do you think are the technical challenges in software project management
apart from the ones discussed above?

2. find out the non-technical challenges in software project management other


than discussed above.

3. List the factors that affect the global management software.

1.4 WHAT IS A SOFI'WARE PROJECT'!

A 'project' is a sequence of unique, complex and connected activities having one


goal or purpose and that must be completed by a specific time, within budget and
according to specification.

Before understanding project and its management, we must know the organizational
environment & the activities performed differently in different organizations.
Organizations can be classified into three categories based on the major activities
they perform such as product development organization, manufacturing organization

6
Unit l Time for Rasics: Software Project Management Concepts

and service organization. However, you may also see combination of all the three
categories in a single organization. The classification helps us to identify the
differences and similarities of activities they perform, for example product
development organizations are into development of new products or new versions
of products which do not exist before, wrulc manufacturing organizations are engaged
into production of same products.

Every organization performs these activities to make profit by providing services or


selling products. Hence making profit is a unique characteristic among all of them.

Product Vs Services
Products are commodities which the customer purcha<;es with total ownership of
that product and he can usc the product for specific purpose, e.g. Microsoft Windows
is a product we purchase to run the computer system. In services, customer pays
value for the service he is getting from the service provider. Ownership of the product
and infrastructure remains with service provider, e.g. internet service, telephone
service, software as a service.

Project Vs Production
Projects are catTied out to develop unique product, service of result. However, the
production activities arc carried out to produce large number of products so that
more customers can avail them. Project is a one time activity for single products,
that means for different products, different projects can be initiated simultaneously
or at different times and once the product is developed, that project is closed and the
next may start. While production is an ongoing activity, it produces the same product
repeatedly till the demand is satisfied. It. clears every bug in the project as per
customer's satisfaction. For example, installation & configuration of software
products, taking backups, generating reports, etc. are ongoing operations.

Service

Projects Products/S
ervice
Production

7
Project Management

From tl1e above discussion, \\'e can say that product is a common thing in aJl the
three types of organization and to develop each unique product, project must be
initiated. The outcome of the project is unique product and the product can be further
produced in volume or given as a service. Thus every product must have atleast two
phases namely Project Phase and Production Phase.

Uniqueness of Software
The model shown above is a generic model. However, due to unique characteristics
of software, the production of software is a less complicated process in which you
simply need to create copies of software. Software can be further classified as software
product. customizable product and software as a service. For example, Microsoft
Windows is a unique Microsoft product that we can usc to operate our computers.
Enterprise Resource Planning (ERP) is a customizable product that different business
communities can use to atomize their process and recently new concept of Software
all a service arc being introduced in which you need to have to buy & install the
software and can only buy the services provided by that software. The bac:;ic software,
server:~, heavy configuration of hardware and backup remain with the service provider.

Definition of Software Project


Software project is time bound undertaking, which delivers unique product or
service.
For example: development of banking software, development of insurance software,
etc.

Characteristics of Software Project


There arc three important characteristics of project with which you can easily identify
whether given undertaking is Project or ongoing operation.

Uniqueness: The activities in a project must be unique. Each software product is


unique in some aspect such as features, services, processes or environment, for
example, development of a new compiler for C language. In this example, the
compiler of C lan!:.ruage aJready exists. That does mean that new version of C compiler
is production or ongoing activity because the internal logical structure of the new
version, the output generated by new version, even the development team may be
different.

Another popular example can be development of a new website. Although, website


is developed using existing languages and web technologies, and the development

8
Cnit 1 Time for Basics: Software Project Management Concepts

team knows how to develop a website, every new website development is treated as
a new project since the features & customers are different for different websitcs.
Similarly, same ERP product implemented in different companies arc treated as a
separate project since the business processes, rules & policies, the end user are
different.
On the contrary, if you install MS Windows or any Antivims software in the same
company on different computers or reinstall the software. it may not be considered
as a project because the operation is repeated & not unique.
Time bound: Projects arc time bound, means they must have definite beginning &
end date. This date can be self-imposed by management or specified by a customer.
It indicates a finite tenure for the project which is flexible. Project tenure is finite;
however the usc of software need not be finite. Once the product is developed,
project is closed and user can use product for longer time unless & until the product
& services arc matching with business goals. For example, developing products
like MS Office or MS Windows arc time bound projects, but you can use these
products for longer time and there is no time limit on its use.

Progressive elaboration: All software projects are progressively elaborated.


Progressive elaboration means more details are available when we progress further.
This is a very important characteristic & needs to be understood properly. Due to
unique nature of the product, we do know every minute detail such as exact
requirements of customers, the way the team can approach for a solution. Por
example. product training is generally provided to end user & if the end users arc
dispersed across the globe and you need to make a training plan, you cannot just
proceed on the training requirement. Initially, you are unaware of the user
characteristics such as expertise, number of users, user location. training language,
etc. In such situations, instead of investing more time in detailing, you can start with
the initial phases and eventually get a clearer idea about the user characteristics
when stakeholder analysis or functional analysis begins. In most of the projects,
there will be progressive elaboration of varying degrees that you will have to face.

We are studying these characteristics because it has considerable impact on the


overall project management processes. If projects are not unique, then there is no
need of detailed planning since you have done a similar project or if project does not
have time limitation, you have flexibility of time & schedule. Though these terms
arc simple to understand. sometimes they create confusion. For example, progressive
elaboration is confused with scope creep. If you have not properly understood the
minute difference, then project may get different direction & crisis thereby.

9
Project. Ylanagemcnt

Scope creep means addition in requirements while progressive elaboration means


detailjng of the given scope as you proceed. For example, a customer wants to add
new information (field) in the report since it was not captured in the requirement
gathering as initially you do not have all field level information at hand. This can be
considered as progressive elaboration while if the customer wants to add new report
to the initial scope, it has considerable impact on cost and schedule, hence it is
treated a<; scope creep and not progressive elaboration.

J6 Activity C:
1. Give five examples of progressive elaboration.

2. Give five examples of projects & ongoing operations.

3. Find out three common things in project and ongoing operation.

- - - - - - -- - - - -
- - - --- -
-----------------------------·· --- ---

4. I jst the three unique characteristics of project.

10
Unit l Time for Basics: Software Project Yfanagement Concepts

1.5 WHAT IS SOFTWARE PROJECT MANAGEMENT'?


Software project management is a supporting discipline in software development
projects. The software development is an intensely people & process driven activity.
lienee software project management deals with the efficient use of people & processes
that they follow. There arc two types of processes viz. software engineering process
models like waterfall, spiral. component based, etc. which are highly technical in
nature and management processes like planning, team management, communication,
risk, outsourcing, requirement management & estimation, etc. Technical &
management processes arc integTatcd with each other.

Software project management deals with lots of managerial activities such as


appropriate selection of above mentioned process models, selection of team and
planning & monit01ing. As each project is unique in it<;; gravity of complexity, it is
the sole discretion of the project management team to decide what processes &
methodologies to choose. Project management is the sole responsibility of the project
manager and he is accountable for success or failure of the project. .

Further, project management is an act of balancing the resources & their constraints.
Various resources arc human resources, their ski lls and knowledge, processes
followed in managing the project, templates or documents used during the project,
etc. Every project has constraints that act as a limit of pmticular resource, for example
scope, time, and cost.

Previously, software development was considered as a highly technical activity that


deals with software engineering processes such as design, coding & testing but now
other disciplines like stakeholder management, communication management and
estimations have become equally important. Project management is giving more
emphasis on efficient management of process. Various project management
methodologies are available. These methodologies provide framework. Two popular
methodologies are Project Management Methodology developed by PMI (Project
Management Institute USA) and Princc2 :Methodology.

Software project management is a combination of general management knowledge


and skills and the unique processes that arc applicable to software development
such as estimation, configuration, and communication. As software is a human driven
activity. more emphasis is given on management of human resources.

11
Projecl Managemenl

In software project management, we will learn the basics of project management &
the skills required for managing the project.

Software Project Management is a method and set of techniques based on the accepted
principles of management used for planning, estimating and controlling work
activities to reach a desired end result on time with the budget.

~Jlctivity I>:

1. Name two popular project management frameworks.

2. Name five software engineering processes.

3. Name five project management processes.

4. What is software project management?

12
Unit 1 Time for Basics: Software Project Management Concepts

5. Give examples of various resources used in a project.

6. Give examples of constraints.

1.6 ORGANIZATIONALSTRUCTURE

Organization structure represents the organization as a whole describing stafTing


level, communication and reporting system, staff hierarchy, etc. Organization
structure gives you an idea about the people & their authority level. The first important
step you must take before accepting the project is to understand the organization
structure and culture of your own organization as well as your customer's
organization.

Organizations arc unique in their working styles, culture, hierarchies, hire & fire
policies, work ethics, etc. Why do you need to understand organization structure?
Managing software project involves heavy management of human resources and
their communication & reporting requirement. While doing communication planning
and IIR planning, you need to know the characteristics of the organization and
accordingly you can plan a team and reporting structure. Every ingredient of the
organization structure such as culture, authority will have considerable impact on
overall project organization, for example if organization is fully projectized, then
the project manager has full authority to reward or punish the team members that
can have effect on project execution.

13
Project Management

I President
I
1 1
Research and
Development I Engineering
I I :Manufacturing
I
If you know your stakeholders, either internal or external. you can manage the project
effectively since you would know whom to communicate and how to communicate.
You must therefore understand various organization types and structures.

Organization Types
Broadly, software industry is divided into two categories, product development
companies and service provider companies. Product companies develop solutions
for different domains and business entities while service companies provide services
such as implementation of third party software or knowledge outsourcing or data
management services. One more category in relation to software development which
we can find is in-house software development where the organization develops
software for their internal requirement and they don't sale out

Projectized Organizations
Most of the IT companies arc project based organizations. Projectized organizations
are basically engaged in development of new software product or services. As
characteristics of software perfectly apply to the definition of a project, the
organization structure is made suitable to carry out project work. Unlike other
industry, there is no ongoing activity performed. In projectized organization, the
project manager is solely responsible for the project and is the highest level of
authority in the organization. Various other departments such as Accounts and Human
Resources report to the project manager. The project manager is usually responsible
for managing one project and if the organization is petforming many projects, they
can have separate project managers for each project. Depending on the size of the
organization, there can be a single team responsible for carrying various tasks such
as coding, testing or there can he separate teams responsible for carrying specific
tasks such as Quality and Testing Team, Design Tean1, Implementation and Support
Team, etc. Team structure generally includes Team I ,eaders, Analyst, Consultants,
Subject :Matter Experts, Programmers. etc. Tcmns arc not permanent and exist till

14
Unit I Time for Basics: Software Project :Vlanagcmcnt Concepts

the project exist<>. Once the project is over, the team members arc released. Project
Managers in these types of organizations are responsible for planning, organizing,
and motivation & controlling of the project team. Team leaders and project leaders
are responsible for day to day technical issues and team handling. In projcctized
organization, the project manager decides the structure of the team. Scope, time and
budget are the main constraints for this type of organization.

Functional Organization
The main focus of the functional organization is to produce or serve something
related to their domain. You may know that most of the organizations are functional
organizations such as Automobile, Electronics, Engineering, Insurance, IIealthcarc,
etc. These organizations arc generally engaged in ongoing & repetitive task. Though
they arc engaged in production activities due to various business needs, market
demands, technology advancement, they initiate various prqjects in their organization,
e.g. designing of new car, bike, etc. Few of the functional organizations have their
own software development team and develop new software for their functional
departments like customer relationship management (CRM), production and
planning.

In functional organizations, usually the role of the project manager is played by the
IT manager. As compared to projectized organization, an IT manager in functional
organization has limited authority. The team is small as compared to the core IT
organizations. If a new project is not there, then the team is engaged with software
maintenance & support activities. Some organizations prefer to purchase customized
software while others prefer to develop in-house software as per the requirement of
the organization. The main constraints of functional organization arc time and quality
while there is no specific cost budget for software. The IT manager has to manage
the given project with available staff in IT department. There is limit on staff hiring
because additional resources may remain idle till next project. Instead of adding
resources, such organizations may think of outsourcing few development activities.

Matrix Organization
Matrix organizations arc a combination of functional & projectized organizations.
It maintains the hierarchical structure of functional organization and techniques of
good project management. Employees in this type of organizations report to both
functional as we11 as project managers. Depending on the authority level matrix, an
organization can be further be classified into strong matrix which is similar to
projectized organization and weak matrix which is similar to functional organization
& balance matrix.

15
Project \'lanagemcnt

J6 Activity .E:

1. Describe various types of organization structure.

- - -- -- - - -- - - - --·- -- - -- - --- - -- - - - -- -
2. Identify & access the organization structure of your organization. (If you arc
not employed, discuss the same with a friend who is employed.)

3. Name the five things that you can access from organization stmcture.

4. What organization structure do you think is appropriate for the follmving:

a) Manufacturing Industry

h) IT/Software Development Company

c) IT enabled companies such BPO/KPO

d) Construction Industry

e) Manufacturing industry involved in new product development

16
Lnit l Time for Basics: Software Project Management Concepts

5. Describe the team structure of an IT organization.

1.7 PROJECTLIFECYCLE&PHASES
Each project has a certain life, that means it has a certain beginning and as it achieves its
objective, life of a project reaches to an end. Project existc; till the release of the product or
service. Once product is relea..<.;ed, project wi II be closed. Dming the life of the project, it
goes through various developmental stages called as project phases. Collection of the
phase together is called a..c;; project life cycle. For e.g. Initiation phase, requirement phase,
design phase, coding phase, testing phase. These are the phases of system development
life cycle. TYpical project management phases are initiation, intermediate (planning, execution
and control) and closure. However, the project manager decides the phases of project
depending upon the complexity and managcahility of the project.

lnitiationFig;_[ ypical projcc~management phases

Intermediate
-~l'---..
Closure

Phase is nothing but collection of logically related activities. For example, initiation phase
includes activities such as project scope definition, charter development, project selection,
etc. These phases are usually sequential, meaning if once previous phase is over, the next
phase may start. The decision to transit from one phase to another is usually taken at the
end of each phase. Project phasing helps in managing large project into smaller logically
related activities.

17
Project Man agcm~nt

Project manager decides the pha<>es of project life cycle. He decides what is to be delivered
in each phase. who is involved. how the control is established & finally how each delivemhlc
is verified and reviewed. At the beginning of the project, the project m'mager decides the
life cycle model of the project. There arc various software development lifecyclc models
available such as Rapid Application Development Model, Incremental Model, Waterfall
Model and Spiral ~odel. The phases are also dependent on software development life
cycle model and project management methodology which you arc going to adopt.

At the end of each phase. dclivcrahlcs arc reviewed £md technical outputs arc passed on
to the next phase. Phase review also determines whether the project can transit into next
phase or terminate there itself.

As projects are progressively elaborated and Jess details are at hand in the beginning
of each phase. cost, staffing level & risks are high. As we move ahead in the project,
more details arc available and cost, staffing level and risk may get reduced.

f6 Activity }':
1. Write down stages of software development life cycle.

- - - --------

2. Who decides the phases of project life cycle?

- - - - - - - - - - - - - - - - - - - - - - - - - - -- --

· -- - - -- - - -- - - -

3. Write down stages of proj ect life cycle.

18
Unit 1 Time fo; Basics: Software Project Management Concepts

4. Identify various models of software development.

1.8 STAKEHOLDERS & THEIR INFLUE~CE 0~ PROJECT


Human resource is one of the most critical & important resource in software project
development. All human resources are called as stakeholders of the project.
Stakeholders can he individuals or organizations who participate in the project.
Stakeholders can he internal stakeholders or external stakeholders. Internal
stakeholders are usually internal staff of performing organization such as project
manager. team lead, progrmmncrs, analyst. etc. while external stakeholders comprise
of project sponsors, customers, end users, etc. Project management must take care
of both of these stakeholders.

Stakeholders arc important in project because they can influence proj ect positively
or negatively. Different stakeholders may have different views towards the same
project, for example top management may decide to implement software in their
factory to speed up the process while the end user who may perceive that new software
may degrade their importance. These are individual perceptions and may have
influence on project execution.

Without stakeholder's cooperation, you will not be able to understand the system
requirement. If the requirements arc not clear, the project may fail. For example.
your organization has got project from an old manufacturing company. The
company's top management is confident that new software will improve the existing
manual process. On the contrary, the end users of lower management think that the
new computer system will replace their joh. Few of them arc reluctant to change.
They perceive that if the new system fails, they will have to operate manually and it
would be an over burden on them. Such kind of negative perception may create
problems in implementation and need to be carefully handled.

19
Project Management

Project
Manager

Project
Team

Support
Staff

Fig. Basic stakeholders in a project


Let us understand the various stakeholders and their roles and responsibilities.

Project Sponsors: A project sponsor can be an individual or an organization who


provides the financial resources to the project.

Project Manager: The project manager is responsible for the overall success of the
project. An individual who is ultimately responsible for project delivery. Project
managers arc responsible for project planning, organizing, monitoring & controlling.
They need not be necessarily technical experts but having technical competency is
an added advantage.

Team Members: Team members must have trust in one another. These are actual
performers of planned task, for example. Programmers, testers, etc. They apply their
technical skills to deliver the product.

Customers: Customers are the ultimate beneficiaries of the project. Customers


provide requirements for the project undertaken.

20
Unit 1 Time for Basics: Software Project Management Concepts

End Users: They are actual users of the product delivered by the project.

Consultants, S.Ml~: They are individuals who are expert in handling business issues.
They arc subject matter experts in their domain. They provide technical or domain
specific guidance to the project team.

Support Staff: The role of support staff is generally activated after release of product.
They help customers in solving their technical as well as non-technical queries,
installation of new software.

~Jlctivity (i:

1. Group following stakeholders into internal and external stakeholders:


Project manager, customer, team lead, end user, government agency, consultants

2. Identify the factors that build negative perception of software.

3. Identify & list down the roles of stakeholders in a tabular format.

21
Project Management

4. Explain the importance of stakeholder management in a project.

1.9 KNOWLEDGE & SKILLS 0}' A I)ROJECT MA..~AGER


Software project management is the application of knowledge and skills. Every
project manager must possess some of these skills and try to acquire the knowledge
in his respective domain. As a main stakeholder, he plays various roles during project
execution.

Project
Manager

Fig. Role of a Project Manager

22
Unit 1 Time for Basics: Software Project Management Concepts

Role of a Project Manager


You are studying project management with the objective of becoming a good project
manager some day. In the last two sessions of this unit, we tried to understand the
roles played hy project managers and essential skills they must possess to he
successful in the project management career. In order to coordinate and complete a
project successfully, a project manager assumes the following roles in the various
phases of the project.

Roles are important in our career as they guide us and are the road maps for our
career path. This is a very introspective session and while learning various skills &
roles, try to map your own qualities & skills with the ideal project managers.

Project manager must rely on people management. good judgement, interpersonal


skills and personal institution.

Manager
This is the main role of the project manager. Project Manager's prime responsibility
includes planning, organizing, motivating & controlling. For each of the managerial
activity like planning, organizing, motivating, he should have necessary skills in
that field, for example planning skill, organizing skills, motivation skills.

As a manager, he should ensure that all processes arc properly defined & followed.
PM is also responsible for performance monitoring & status reporting to project
sponsors. A project manager should have a great command & control over the team.
He should establish strong self & group discipline. As a manager, his main focus is
to get the work done with optimum utilization of resources. Being a manager, he
should conform & comply with various standards, rules & regulations. He should
maintain the integrity & work ethics in a team.

l,eader
Leader's role is different than managers. Leaders have responsibility for part of the
project. They arc often confused with each other. Manager's job is to plan & assign
task to the people, while leadership deals with influencing and persuading people to
do what you want them to do. People in the software industry are creative knowledge
workers and they don't like detailing of task & they want work freedom,
empowerment, but doing so may be sometimes risky for the project. Here project
manager has to act like a leader. With influencing skills & persuasion strategy, he
makes the people to do the thing which arc right for the project. To get the maximum

23
Project Management

creative work from his people. he should empower the people without loosing control. He
builds continuous rapport and trust with team members since people always follow the
leader whom they trust. It is essential for a leader to read the trend and understand his
followers. By knowing this, he can motivate and direct his team for achieving the objectives
of the project.

Coach and Mentor


Each project is a new learning activity for a team member. As an experienced Project
Manager. you have to transfer the knowledge to your team members. Team members
always seck guidance and support of their project manager. Here project manager
acts like a good coach, trainer. He should continuously understand the knowledge
requirement<> of individuals. As a team player, he should know what arc the skills
required and accordingly arrange formal trainings, workshops or conduct informal
training activities. He must motivate the team to learn & practice new technologies.
He should also provoke group learning.

Problem Solver
During project execution, technical as well as non-technical issues may arise and
need to be attended immediately. Clear understanding of the problem is very much
essential. After defining a problem, the project manager finds out alternative ways
and provides solution to the problem. Sometimes people need support to solve critical
problems. In that case, the project manager has to give moral support to his team.
The project manager need not pressurize the team in critical case. He has to tackle
the situation tactfully. He should be flexible in approach & needs to remain under
control in highly stressful situations.

Coordinator
Project managers spend most of their time in communicating & coordinating with
the stakeholder. As team size increases, number of communication channels increase
that leads to more confusion & chaos. In order to deal with such a situation, project
managers must efficiently coordinate the resources of the project.

Project managers must continuously analyze the gaps in communication & fill the
gaps by effective coordination. They will often manage project managers on very
complex or multi-project undertaking. People in a team need time to time, proper
information either written or in oral form. It is the job of the manager to see that all
stakeholders' information requirements arc satisfactorily fulfilled and there arc no
conflicts or communication issues across the team.

24
l ;nit 1 Time for Basics: Software Project Management Concepts

Essentials Skills
Successful project managers arc a blend of knowledge & skills. We know that Project
management is nothing but the application of knowledge & skills. Therefore you
must try to understand the various skill sets of an effective project manager.

Before we actually delve into the discussion of knowledge and skills, let us first try
to understand the difference between knowledge and skill. Knowledge is a collection
of experiences. If the experiences repeatedly occur, we may formulate them as theory.
For example, in this session we discussed various organization structures. these are
theoretical things. You can get the knowledge from your past experience or the
experiences of others. By practicing & applying knowledge, you can develop the
skills. Mere knowledge is not enough, you may read & have knowledge of swimming
but unless and until you throw yourself in water, you cannot swim.

Project management is a subject of practice. The knowledge and skills we discuss


here arc just guidelines. However, on-field situation may be different for different
projects and you need to handle them creatively and tactfully. Actual skill will help
you in managing projects. Let us see the different skills which every project manager
must possess.

General Management Skills


General management skills define the ability with which you can perform various
project management activities such as planning, organizing. controlling. monitoring,
etc. Along with these skills, the general knowledge of finance and accounting, human
resource and legal compliance is essential.

Communication
Can we execute a project without communication? :r\ot possible. Communication is
the most conunon and widely used skill in project management. There are various
means of communication. Communication atlcast needs two persons (sender-
receiver) and medium for communication. Effective communication ensures that
message communicated by sender is properly understood by the message receiver.
Communication becomes more complex in large, complex projects where team is
dispersed across the globe. One must understand the barriers of communication &
try to break those barriers. Some of the communication barriers are language, culture,
education, gender. hierarchical level in an organization.

25
Projecl Managemenl

Planning & Organizing


Planning is deciding future course of action to achieve the set target. Without planning,
you cannot direct & control your team. Plan keeps your focus on the target. Plans
are always progressively elaborated. Thus planning becomes continuous & repetitive
activity. Planning needs vision & deep understanding of environment i.e. people &
processes. A good plan is actionable & will be implemented effectively. If our vision
is limited, we cannot think much beyond. Thus vision is a very crucial thing in
project planning. Planning is not an isolated activity. It goes hand in hand with other
activities like organizing & controlling.

Organizing means integrating & coordinating the resources as per the plan. Two
main aspects of organizations arc how you organize available human resources and
the documents. Organization means an·anging things in a manner to improve the
effect & efficiency of the team. A good time management sense is essential for
better organization. Planning decides what to do while organizing decides who can
do the specified task better. During the project, loLc;; of information & documents
such as reports, memos, quotations & contracts are generated and you need to organize
them properly so that you access the right information at the right time.

Influencing & Negotiating


Influencing is the ability of a person to convince his idea to others in an effective
manner. People in the team (internal as well as external stakeholders) generally
follow their own instinct and quite often they are disagreeing with project
management decision and opinions. Appropriate application of influencing skill will
help in managing conflicts & compel your decision. If stakeholders do not agree
with each other, the project manager can usc his power either positively or negatively
to influence them. Influencing skills can be used to motivate people. Naturally, team
members are influenced by personality and character of the project manager. They
follow the leader who has impact on them.

Negotiating is a process of reaching to mutual agreement. Negotiation may happen


with groups or individuals inside or outside the organization. Many a times during
the project execution, the project manager needs to apply the skills. For example,
when customer adds new requirements which may not be in scope, it may affect the
schedule & budget. With negotiation skill, he can fruitfully make the customer agree
to pay extra for additional requirement or with negotiation skills he can convince
the customer how schedule & budget will be affected by new requirement & make
the customer agree with the existing scope. Sometimes team members do not agree

26
Unit 1 Time for Basics: Software Project Management Concepts

with the time frame or specific approach or documentation they have to prepare. With
negotiation skill, the project manager can convince his team about the importance of his
decision.

Estimation & Budgeting


Estimation attempts to determine how much money, how much effort, how many
resources and how much time it will take to build a specific software-based system
or product. Effort & cost estimation arc challenging activities in project management.
Due to unique nature of projects and human based activity, it becomes difficult to
estimate how much time and cost will be taken to accomplish the project. Estimation
and budgeting is a skill and can be developed with experience and application of
various methods, tools & techniques. Knowledge of accounts and fmance will be an
added advantage & will support in taking accurate financial decisions.

Problem Solving Skills


Projects exist because problems exist. problem is an opportunity that initiate project.
Problems could be business related or technology related or may be related to the
m<magement of process. The prime objective of any project is to give a solution to
the business problem. Apart from this problem, there could be problems related to
project execution such as scope creep, wrong estimation, incomplete requirements,
stakeholder communication, schedule and budget of the project which must be
resolved.

Problem solving uses decomposition technique in which the first problem is defined.
Symptoms & causes are separated out and alternative solutions are suggested.
Problem solving needs expetience, good understanding of business and technical
know-how. There are various problem solving techniques available, for example
Cause-Effect Diagram, Strength-Weakness-Opportunity-Threat (SWOT) Analysis,
How Chatts, etc.

Leadership
Leadership means ability of a leader to influence the thinking or action or both of a
team. By influencing, he can motivate the team and get desired performance of his
team and achieve the project objective. Leadership is a combination of various skills.
A good leader must possess certain qualities such as motivation, energy, knowledge,
social skills, communication & influencing skills. decisiveness, courage & ability
to relax in highly stressful situation. Some of the qualities of the leader may be
inherited such as personality, energy, inte1ligence while he can learn other qualities

27
Project Management

such as communication skills, motivation skills, etc. Good leaders arc always energetic &
very positive in attitude. His presence encomages others. Social skills help him to underst:<md
the behaviour of the people and c<m build a good team. A leader must be decisive & flrm
in his decision. Good leaders have good judgment about the people and situation & they
can resolve the conflict smoothly. I ..cader need not be technically competent but must
possess motivating & influencing skills with which they can direct their project team.

There arc various styles ofleadership; usually leaders are either autocratic or democratic.

Autocratic style: Autocratic leaders compel their self decisions on the team . Autocratic
leaders arc only concerned about the task and not the people who arc performing that
task.

Democratic style: Democratic leaders understand the opinion of each team member
& have shared vision. Under this style, decision making is consultative and
participative. Team member can openly express his views and understand why his
view is not accepted by a group.

~Activit:y II:

1. Describe the role of a project manager.

2. Explain various skills that every project manager should possess.

28
Unit I Time for Basics: Software Project Management Concepts

1.10 SUMMARY

Software project management is one of the challenging disciplines in the knowledge based
digital economy. Software has become a commodity and its usage is rapidly growing.
Unlike other commodities, software project management is facing lots of challenges in
areas like measurement and productivity. Delivering software in time, cost and quality is
still a challenge and it is found that weak project management is the root cause. Project
failures arc attributed to weak project management than to technical improvement<>.

Understanding of project management environment & the concepts used in project


management are essential. Software project management is a highly human intcnsi ve
knowledge activity. Knowledge of organi:r.ation culture, policies and hierarchy guide
us in choosing the right approach for better management of projects.

Projects are unique, time bound and have prohrressively elaborating endeavours and
deliver unique product or services. The project manager is responsible for
management and execution of the project. He selects appropriate management
processes for execution of a project. Basic function of any project manager is to
plan, organize, execute & control project related activities.

At the end of this unit, we saw the multifaceted role of a project manager. Project
management is a discipline of practice and application of knowledge and skills.
Project managers are not only good managers but they arc supposed to be creative
leaders. They play various roles and have their unique style. Knowledge can be
learned from past experience while skills need continuous practice. A good project
manager possesses various skills like communication, influencing, problem solving,
organizing, leadership and team building.

1.11 SELF-ASSESSMENT QUESTIONS

l. What will happen if the project manager does not possess one or more of the
required skills?

2. What according to you is the importance of knowing the organization structure?

3. Explain the importance of 'Leader' as a role the project manager has to play.

4. What according to you is the influence of the stakeholders on any project?

5. How is software project management different than other project management


disciplines?

29
Project Management

2.1 INTRODUCTION
Software project management is "the application of knowledge, skills, tools and
techniques to project activities in order to meet project requirements". Software
project management begins with project initiation and ends at project closure. In
between project initiation and project closure there are various technical and
managerial processes. These processes are logical processes and arc not isolated
from each other. Every process is integrated with each other. Some process are
sequential, means after completion of first you can start next one for example without
completion of project initiation you cannot start project planning and execution.
However, due to progressive elaborated nature of project, processes may not be
executed 100 percent sequentially. In sequential process execution, the next process
totally depends on previous one and without completion of previous process, we
cannot start next process. In project planning, details arc not available and you crumot
ask your team to wait till all details arc available. Only option remains is to prepare
the first version of plan and start less critical activities. As you move ahead, you will
have more information at hand and can plan accurately. Tllis nature implies that
after execution. there are chances that you may revise the plan. Due to this interactive
nature, effective integration of all process is required.

You arc familiar with software engineering processes. Similarly, there arc various
management processes such as preliminary scope and charter development,
estimation and plruming. monitoring and controlling project execution, controlling
changes and finally project closure. These processes again comprise of various
activities. For example, in planning, you may need to prepare various plans such as
risk plan, finance & budgetary plan. quality plan and human resource plan. For the
sake of understanding, these individual processes are grouped into four process
groups such as initiating processes. planning processes, execution processes,
monit01ing and control processes and closure processes. Project is nothing but the
collection of all these processes and effective project management means putting
all these individual process in synchronization to achieve the common objective of
the project.

In this unit, we also study how project initiates and how projects are authorized. We
also study the importance of project planning. Project integration includes seven
main processes such as develop project charter, develop preliminary project statement,
develop project management plan. direct and manage project execution, monitor
and control project work, integrate change control and project closer.

34
Unit 2 Lel ·s Begin: Initiating

2.2 PROJECT JNTEGRATION

Project comprises of various processes. stakchoiJers and theirs skills, knowledge


and experience. These individual parts are interacting with each other. Project
intef:,rrat.ion insures that all individual parts are working with each other and maintain
the coordination and balance of each part. If any part is imbalanced, the project may
fail no matter how perfectly well each part is doing. For example, your planning
process is complete but execution is not as per plan or execution docs not have
control on other parts, then all efforts may be waste. Hence it is the job of a project
manager to keep all these parts together. Following figure illustrates the interaction
of various parts of the project.

Planning

Skills &
St.."l.kc
Knowlc
holders
dgc

Control

Now it is worth understanding how projects get executed. First customer or sponsor
initiates the project, then project team prepares plan and gets the management
approvaL After getting management approval project execution starts (all software
engineering activities such as analysis, design, coding, testing and documentation),
during execution whether team is performing as per plan is monitored and deviation
is controlled. Once the product is ready, it is released to the customer and project is
officially closed. This is the basic sequence that every project follows, however as
project size and complexity increases, management of these processes becomes
crucial.

35
Project Management

For a large and complex project. the basic project execution model needs to be
elaborated. As a first step, project manager has to identify what process model he is
going to adopt for the project. For example, for a small project, exhaustive planning
is not required and with rough cut plan, he can manage project. However, if project
is large consisting of hundreds of employees, he may need to make various plans
such as cost plan, risk plan, quality plan and HR plan and need to develop schedule.
Now these plans are not isolated, for example schedule plan wi11 have impact on
cost plan and risk plan will also have impact on cost. Here project manager has to
make balance of each plan so that no two plans arc out of synch.
After planning, actuaL execution starts, means project team is formed and they can
start actual execution such as requirement analysis and elicitation, high level designs,
program specification, actual coding and testing. etc. for each process, the effort
estimation and quality expectations arc given in plan. During project execution,
project manager monitors that defined process are being followed, he also checks
the status of the project and controls any deviation that occurs. During execution,
customer may change his requirements that affect the schedule and cost, hence all
these changes need to be incorporated into all corresponding plan, for example due
to changes your original scope document changes that will change the WBS and
schedule. It will also trigger risk management process. At this point, you may not
completely understand the process such as risk planning, WBS creation, etc. Here
you have to just understand how each process affects and integrates with another.
We will study different processes in other units of tllis book.

2.3 PROJECT INITIATION


Project initiation is the starting point of every project. In this step we document the
assumptions, constraints, user expectations, business requirements, technical
requirements, project delivcrables, project objectives and everything that defines
the fmal product requirements. Various activities take place in imitation phase before
actual execution of project. We know that "Well Begun is half done" similarly, if
project initiation process starts well, chances of project success will be high. Initiation
activity provides lots of inputs to various project processes. Due to this integration
point of view, initiation becomes important.

Most of the projects fail not because of lack of technical competency but due to lack
of knowledge of why the project is initiated, what is the motive behind the project.
If project objectives and underlying problem is not clear, all further efforts may go
in different directions that means providing right solution to wrong problem. To
avoid this, we must understand why the project initiated before accepting any project.

36
Unit 2 Let's Begin: Initiating

Every project initiates due to some underlying problem or need. If there is no need
or no problem, no project exists, the project takes various forms. To solve the business
problems, various business solution projects can be initiated. For large corporate
like government, various e-govcrnancc project can be initiated. In all scenarios,
business head or the top authority in that organization decides whether to initiate the
project. Every organization operates in a socio-economic environment. Every change
in external environment has effect on the functioning of the organization & the top
management reacts proactively to such changes. If top management does not react
appropriately. they have to bare the consequence or in extreme cases they have to
shut down their unit. Hence every project need is intense and needs to be addressed
carefully. To resolve the issues, management decides to initiate project. Once project
decision is taken, the management decides whether the project is to be executed
within organization or given to some external agency.

Depending on the organization culture, need and complexity, projects arc either
formally or informally initiated. usually project<; are disclosed in the meeting called
as project kick-off meeting. Before initiating any project, top management carries
out cost benefit analysis of the project. If management is confident that the expected
benefits of project arc more than the costs of the project, they give green signal to
project.

During the project kick off meeting, the project needs are discussed and further
elaborated in to preliminary scope document. To summarize initiation process. the
projects are initiated to resolve underlying problem or satisfy the need of the
organization. Based on availability of funds and priorities, projects arc selected and
an official document called as Project Charter is released that announces the official
selection of project and project manager.

We know that projects exist due to problems or needs. It is worth to know the sources
of these problems and needs. It will give a better understanding of the project.

Sources of Needs and Problems


Every business entity operates in a very dynamic & continuously changing
environment. These external environmental factors continuously affect the business
operations. To stay competent in business, each organization has to satisfy needs &
demands posed hy these factors. It is the duty of the management to sec that the
organization meets the needs of its customer and the business which can be influenced
by other factors such as technology advancement, government policies, etc.

37
Project :vlanagcmcnt

Now let us understand different types of needs that initiate projects. There arc basic
six types of needs that trigger project initiation.

Business Need
To sustain business or to expand the business and to stay competent in market,
organizations always enhance their existing processes. Most of the IT project initiates
due to business need, for example automation of existing manual processes.
Improvement in Productivity and quality and reduction in cost arc other major
demanding needs of business. These arc internal needs of the business.

Market Demand
.Market refers to a group of consumers or organizations interested in the product.
These consumers enforce demand & these demands need to be addressed hy the
performing organizations. Business needs are internal to the business while market
demands arc external demands. Internet banking is the example of market demand.
Through internet, customers can do various banking transactions. for example paying
utility hills, fund transfer, etc.

Customer Reqtwsts
These requests come from the internal as well as external customers, for example
individual department's needs or external customers. Planning department (Internal
customer) may request for planning & productivity optimization software, HR
department may ask for Pay Processing Software. Difference between market demand
and customer request is that market demand is collective request of hundreds of
customers, while customer request is specific to a single customer.

Technology Advancement
Rapid changes in technology driven projects. In IT industry, both hardware and
software technologies are changing rapidly. These changes have considerable impact
on the organization. The change in technology gives more features with improved
speed with high & remote processing capabilities. Though organizations have existing
software, after certain period they may ask for new versions with advanced
capabilities, for example due to advancement in internet technology, most of the
organizations replaced their old client server application with the latest multi-tier
internet applications.

38

L
Unit 2 Lcfs Begin: Initiating

Legal Requirement
Every organization operates in a big environment in which government agencies
cmd legislative authorities force new rules and policies. Organizations need to comply
with such rules. standard procedures enforced by legislative authorities; such a change
initiates new project. For example, the change in Tax structure & various duties
paid to the government need changes to be incorporated in many modules. If the
organizations arc multi-located across the various states, local government policy
may differ.

Social Need
Each organi:~.ation operates in social environment & need to address the demands of
society & community. E-governance projects are initiated due to such needs of society
with which government can provide faster & transparent service to the citizens.

RS Activity_~_;_
1. Explain the basic model of project execution.

2. Explain various types of needs with appropriate example.

3. Explain importance of project integration.

39
Project Management

4. Explain who initiates the project and why projects arc initiated.

- - - - -- - - -- -- - - -·- - - - - - - - --- - -- -- -

2.4 PRO.J}:CT CHARTER DEVELOPMENT

A project charter is a document that formally reorganizes the existence of a project


and provides direction on the project's objectives and management. Project charter
is a document that officially announces the commencement of a new project. Many
organizations follow formal chartering process in which formal charter document is
released while few organizations informally announce project without any charter
document. Usually, small projects arc executed without formal chartering. Chartering
is not merely a project announcement process. Chcutcr briefly gives the high level
requirement and tentative budget of the project. Charter is the outcome of lots of
exercises that every organization performs before project announcement such as
cost benefit analysis, organization strategic policy and viability of the project, etc.
The formatting of charter document varies with organizations and the complexity
and size of the project.

Though the outcome of charter development process is a single document, the


organization performs various activities to arrive at a project decision. We know
that project exists due to some need or problems and these needs can be internal or
external to the organization. These needs and problems come from the various sources
and compel management to take action. This is the point where actual project initiation
process begins. Many software organizations initiate project to solve the business
problems of their customer and hence they need some information from customers
such as problem or need, objective of the project, major deliverables, major
constraints and assumptions cu1d budget. Many a times it happens that a customer
may have many demands that can initiate different projects and the top management
of the customer wants to prioritize & select out of them. For project selection, various
activities need to be performed which addresses where to utilize fund and how much
fund to be released. Once the project selection is over, the performing organization
identifies the project manager who can successfully deliver the project. During the
process, top management assesses technical and financial viability of the project.

40
Unit 2 Lct"s Begin: Initiating

During technical feasibility, it checks whether existing team with existing technology
and infrastructure can solve customer problems or new technology needs to be
purchased. After technical and operational feasibility, the project is discussed with
all key stakeholders which include project sponsors, project manager, customer
project manager, etc. Once all stake holders agree with the project budget and other
contents, the project sponsor officially releases the project charter.

Quite often there are demands of many projects and shortage of funds to execute all
projects at a time. Hence the project sponsor has to select the right project which
aligns with the strategic goals of the organization. Projects arc selected based on
cost/benefit analysis and the priorities. Once the project is selected, funds can be
released to the project. Project charter is also used as a basis for project selection.

Project Charter Contents


The contents of the charter vary with organization and the levels of details required
by stake holders. The following template shows the generic project charter.

Project Charter

Project Title: Planned Start Date:

Project Sponsor Name: Planned Project Delivery Date:


Project Mission/Objective: Tentative Budget

1. - - - -- - - - - - - - - --- - -- -- -
2. - -- -- - - - - - - - -- - - - -- -- - - -
3. _ _ _ _ __
Need:

Assumptions:
Constraints:
Major Deliverables:
}. _ _ ______ ___ _ _ ______ _ ____ _ ___
2. _ __
3. _ __ _

41
Project Y!anag~mcnt

Many organizations club the preliminary scope document along with charter. This
document gives authority & official responsibility to deploy and utilize project
resources. This document acts as scope baseline for an entire project and even can
be used as a legal document between the customer and the pedorming organization.

Project Title: A name given to a project which uniquely identifies the project.

Project Sponsor Name: The name of sponsor. It can be the name of an individual
or funding organization.

Project Mission/Objective: Brief description of desired outcome of the project.


For example. after implementation of CR..\1, sales should increase by 20%. Increase
in customer service level by 10%, etc.

Need: Brief description of why the project is initiated.

Assumption: Assumptions are source of risk, hence carefully identified and must
be written in all corresponding documents. For example, assumption could be all
end users arc computer literate and know how to operate basic functions of a
computer.

Constraintc;: Any limitation imposed, for example project must go live in the next
financial year.

Major Deliverables: Exhaustive list of various functional modules to be considered


in project. List of documents & training provided.

This document is generally prepared by the project sponsor or the agency which are
external to the project.

PS Activity B:
I. What is the output of project charter development process?

42
Unit 2 Let"s Begin: lnitiating

2. Name the basic document required for developing charter?

--------- -------------

- - - ----------------

----- - - - - - - --------- ----------------------------------


3. Who is responsible for developing project charter?

---- - - - - - - -- - - - - - - - - - - - - -------- - - - - - - - - - -

- - - - - - -----

--------- -- - - -- - - - - - - - - - - - --

4. Explain the importance of a project charter.

----- - - - - - - - ----- -- - --- - --- ---- - -·

-----------

5. Give three examples of project constraints and assumptions.

------------- - - - - - - - - - --

---- --- ----- - - - - - -------- ---------------

2.5 PROJECT SELECTION TOOLS & TECIL~IQUES

Every management is concerned about the financial success: hence the management
takes cautiously took decision to fund any project. Sometimes there arc demands
for multiple projects and due to unavailability of sufficient fund, projecL.;; need to be
prioritized. Project selection is the process which weighs projects based on certain

43
Project Management

tools and techniql)es. This process helps management in selection of the project
with less cost & high return on investment<;.

There arc various models and techniques available for financial analysis of the
projects. Some of them are benefit measurement system which compares projects
based on cost and benefits, scoring models, cash flow techniques and economic
models. To plan the activities in a project, we can usc network-scheduling techniques.
These models are generally used in comparatively less complex projects. If projects
arc highly complex in nature, then they arc analyzed with mathematical models
such as linear, dynamic, integer or multi objective programming. These models use
mathematical and statistical algorithms and techniques. Now let us understand few
of them.

Cash Flow Analysis Techniques:


There are varieties of cash flow techniques which include payback period. cash
flows, internal rate of return, net present values, etc.

1. Pay Back Period


The pay back period also called as break even point. The point at which the benefits
provided by product or service exactly pays off the cost of development and operation
of the product. For example, if the initial cost of development is Rs. 3.00,000 and
each quarter product returns cash flow of Rs. 15,000 then the break even point will
reach at 5'h year. The pay back period is calculated as.

Initial investment = 3,00,000

Cash inflows = 15,000 x 4 (Since 4 quarters in a year)= 60000 per year

Pay back period = Initial investment/Cash flow per year = 3,00,000/60,000 = 5 year

That means by the 5m year your initial cost will be recovered through the benefit
offered by the product, i.e. Rs. 60,000 per year.

2. Discounted Cash Flows


The value of money changes with respect to time, the value of Rs. 5000 you invested
today does not remain same after five years. The interest rates arc fluctuating and
thus the value of your money. Hence it is very important to know the future value,
present value and net present values of your investment in any project. Discounted
cash flow techniques compare the future cash flow with investment made today.

44
Unit 2 Let's Begin: Initiating

Future Value: Future value of money is calculated as,

FV = PV (l+i) II

Where FV is future value, PV is the present value, 1 is the rate of interest and n is the
no. of investment years. Now suppose you invested Rs. 1000 (i.e. your present values)
for 3 years and the rate of interest is 8% per year then the future value will he
calculated as,

FV = 1000(1+.08)3
FV = 1000(1.25971) =1259.71

That means the value of Rs.lOOO after three years will he Rs.1259.71

Present Value: Sometimes the projected return on the investments are given and you
need to calculate the present value of that investment. Present value can be derived
from the future value formula as,

PV = FV 7 (l+i)"

Now consider after three years from today the projected future value is Rs. 1259.71
(FV) and interest rate 8% per year, then its present value (PV) is calculated as,

PV = L259.71 7 (1+.08)3

PV = 1000
Now let's consider how to select the project when the Future value of the project is
given, for example,

Project X will provide future value of Rs. 10,000 in two years and

Project Y will provide future value of Rs. 15,000 in three years.

Here assume rate of interest is fix and 8% per year. Let's compare and find out
which project is more beneficial. For comparison you need to know the present
value of both the project. By applying previous formula,

PV(X) = 10000 7 (1+.08)2 = 10000 7 (1.1664) = 8573


PV(Y) = 15000 7 (1+.08)3 = 15000 7 (1.2597) = 11907

45
Project :\1anag:emcnt

The present value of project Y is higher than project X, hence project Y is to be


selected.

Net Present Value (NPV)


NPV analysis is sensitive to the reliability of future cash inflows that an investment
or project will yield. In the above example, the petiod of return is different. If the
rerun is given year wise, then how to compare? The solution is to calculate the NPV.
Net present value is again based on discounted cash technique and it gives you the
net present value of your money. In ~PV, you have to calculate the present value for
each year and take the summation of PV for all successive years. After summation.
deduct the total sum from total investment. If balance is greater than one (i.e. positive
number) then it indicates the NPV is high and delivering higher rate of return. Now
consider the returns (FV) given for three years with 8* interest per year and the
total investment in both the projects (X andY) is same i.e. Rs. 24.000.

For project X, future values are 5000. 10000, 12000 and future values of project Y
arc 7000, 5000, 15000 respectively. Now calculate the PV (Present Values) as per
the previously discussed formula.
PV = PV + (l+i)n
Project X
I 1
Jvear

~
·2
------I Re-tu-r-ns - -

15_(_)()-0~ -
oooo
- ---t-1
--PV~~~----_-j1

13888 - -
8573
j
1

~-- -~
- 200_0_ __ _ , 15-87- - - ,

f tal _ _ _ T 27000 _2_40_48 _--~


~ --- ~ - --
l ~v - - _ j__ (24048- 24000) 48

46
Unit 2 Let's B\!gin: Initiating

Project Y

~ar Returns
------------4-----
PV
I
I
1 7000 6481
12 5000 4286
3 15000 11907
Total 27000 22674
I
lnitial investment I 24000

~PV -I (22674-24000) - 1326


From this tabJc, it is clear that the NPV of project X is greater than 1, hence project
X will provide higher returns over project Y. In the above table, you observe that the
total return for both the project is same. We can also conclude that if the project
returns arc hlgh in initial years, then the NPV is high as compared to the projects
return high values in later years.

3. Other Factors
We have seen three cash flow techniques out of which ~PV technique calculates
more precise value of investment. These techniques can be applied on single or
multiple projects. These and other models like benefit measurement system,
mathematical models arc called as decision models. They give you an idea about
where you will get more returns. Apart from this, a model project manager has to
consider other factors like priorities, strategic goals, market conditions, etc. while
selecting project. Some projects give higher return but they are not on priority of the
management, hence possibly cannot get selected. While presenting before the
management, project manager must give his attention to all such factors.

£SActivity C:
l. 1\ame five project selection techniques.

47
Unit 2 I ,et's lkgi n: Initiating

2.6 DEVELOP PREIJL\1L~ARY SCOPE STATEMENT

Preliminary scope statement is a document generally prepared by a customer and it


is a handover to the project sponsor before the release of the project charter. As this
is a preliminary document, only high level requirements are described in this
document. This document is elaborated further in scope statement in requirement
gathering phase.

Content'i of Preliminary Scope Document


Goal-Objective
The goal defines the outcome or an end result of your project. Project management
is the discipline of defining and achieving a set of goals while optimizing the use of
allocated resources (time, money, people. space, etc.) Defining a proper goal is a
very important activity and responsibility of the project manager. Quite often, projects
may have multiple goals and may contradict with each other. Different stakeholders
have different views on the objectives of the project and need to be addressed. Goals
should address the needs/problems defined in the project charter. Goals give direction
to the project. Goals should be measurable. specific, unambiguous and achievable.
Let's consider the following statement describing the goal of the project "Build
library system for a university and successfully implement before the starting of the
next academic year which will provide online access to its subscriber".
This statement does not describe explicitly the motive behind implementation of
library statement. The motive could be to improve library service, provide remote
access, etc. The goals need to be carefully written since they give direction to the
future execution of the project. If goals are not clear, team may develop solutions
that may not meet customer expectations.

Scope
Scope defines the boundary of the project. Every project operates in a broad
environment, however every project may or may not consider interaction with other
system. Hence it must be a necessity to explicitly define what parts of the system
the project is going to consider and the parts which project will not consider. Por
example. consider a company decided to replace the existing legacy system into a
new ERP system. Most of the time, customer assumes that project will transfer
existing data from legal system into new system. However. it is not practically
possible to transfer data. If data migration is explicitly defined in project scope,
technical team can take care while designing new software. However, if it is not on
the scope and customer is demanding. it may create conflicts.

49
Project Management

Constraints
Every project management resource such as man, machine, material, money has its
own capacity. We cannot usc them beyond their limit. This limiting factor is called
as constraint. For example, if a project sponsor asks to develop a project in one
million dollar and within six months, then the project constraints are Project Budget
and Duration. These constraints need to he identified and quantified. Constraints
help in making schedule, budget and risk planning.

Assumptions
\Ve have certain assumptions in our mind. We expect that these assumptions should
he true & we take certain decisions based on these assumptions. However, in reality
your assumptionlHnay fail and accordingly decision based on them will also fail.
Hence assumptions are treated as a great source of risk. Assumptions are based on
guess work. Wrong assumptions lead to project risk; hence assumptions need to be
properly documented. For example, the common assumptions arc, all customers'
end users arc computer literate or the key person will not leave the organization till
the project is over. One more assumption people will generally have is that legacy
data will be migrated into new ERP system during project implementation. There is
no harm in assuming but it should he noted clown in the scope document so that
others can sec and analyze their impact on project.

Project Requirements
These requirements pertain to & arc applicable to project activities. For example,
customers may have specific communication and reporting requirements. He may
ask you to present information in a specific format. Project requirement generally
considers the delivcrables of the project and not the product. Project delivcrables
could be various plans, work break clown structures, schedules, etc.

Product Requirement~!
Product requirements arc nothing but the expectation, needs and desires of stakeholder
from the product. Broadly. requirements can be classified into functional and non-
functional requirements. Functional requirements include actual functions expected
from the product for example pay process module should process the pay data
every month, etc. While non-functional requirements include quality aspects such
as data security, performance, user friendliness, documentation needs, etc.

We have discussed some of the major contents of preliminmy project scope statement.
However, contenl~ may vmy as per organization & project needs. Some of the other

50
Vnit 2 Let's Begin: Initiating

contents that can be included in scope statements are major milestones, potential
risks, tentative cost and effort estimates.

RSActivity D:
1. State three goals that you may think about library management system.

2. Why scope needs to be defined? Explain with an example.

3. Define constraints and assumption with appropriate example.

-t.. Explain difference between project and product requirements.

51
Project Management

2.7 PRO.JECTMANAGEMENTPJ,AN

In large and complex project, hundreds of human resources perform variety of tasks.
They are sharing information with each other. It is not practically possible to closely
monitor each resource and guide them. Handling such projects without proper
documentation and guidelines can be a major risk. Hence every activity is planned
in advance before execution.

Planning is simply putting your actionable thoughts into document, one such
document you are preparing now is project management plan. This plan is a
comprehensive document and provides guidelines for management of other project
activities such as scope management, communication management. cost and schedule
management, human resource management, quality and risk management, etc.

This document defines what activity needs to be performed and how each activity
will be performed. This document acts like a control tool. The contents and level of
details vary as per the organization & project need and the style and personality of
the planner. Some plans arc exhaustive and some just contain need to know details.

Due to progressive elaborative nature of the project, the project management plan
evolves over the time and may get revised many times during execution. The changes
to the project management plan are updated through proper change control
mechanism.

Project Management Plan is a great tool for control. It is a general tendency that
team may loose track while performing. A well documented plan gives control over
such deviations. Deviation of plan attributes to the two factors. First there arc always
unforeseen situations and second, lack of adherence by team members to whatever
planned. A good project manager thinks in advance and controls the variations in
plan.

Project management planning is an exhaustive and time consuming task. You can
improve project management planning only through practice and learning experience
of others. Main challenge is to decide the contents of the document since you can
write a plan for every activity and you need to choose those activities which have
considerable impact on a project. You can also study project plans of similar projects
or get the expert advice. There are various guidelines and templates available for
writing project management plan.

52
Unit 2 I .ct's Begin: lnitiating

The Contents of Software Project Management Plan (Sl'MP)


The contents of project management plan vary with the organizations. Project
management plan can be made as per the requirement of a project and stakeholders.
Following template describes the contents of sample project management plan
derived from IEEE Std.l058-1998.

Sample Project Management Plan


1. Introduction
You can write here the overview of the project.

1.1 Project Overview

Here you can write summary of projective objectives, major activities and
milestones, required man power and budget.

1.2 Project Deliverables

List of primary deliverable to the customer, for example list of modules,


reports, features and functionality, etc. to he delivered.

1.3 SPMP Evolution.

Describe how this plan will be executed and how the changes to plan are
controlled.

1.4 Reference Materials

Here you can provide complete list of all documents and other sources of
information referenced in this plan. For easy access, other details can be
provided such as report or document title, version no .. release date. name
of author and publishing organization.

1.5 Definition and acronyms

All new terms and terminology arc defined in this section so as to avoid
confusion.

53
Project Management

2. Project Organization

This section specifies the process model for the project and its organization
structure.

2.1 Process Model


Which process model, project is going to adopt such as waterfall model,
prototype, rapid application development, spiral, etc. Process model must
include roles & responsibility. activities, entry and exit criteria for project
initiation, product development. product release and project termination.

2.2 Organization Structure


Describe the internal management structure of the project. This can be
effectively shown by using line of authority chart.

2.3 Organization Interfaces


Here you can show the administrative and managerial entities.

2.4 Project Responsibilities


Here you can write the major activities and the person responsible for
carrying this task.

3. Managerial Process

This section describes the management process for the project.

3.1 Management Objectives and Priorities


Describe the philosophy, goals and priorities for managing this project.

3.2 Assumptions. Dependencies and Constraints


We already discussed the terms constraints and assumptions. Dependency
checking means checking whether the activity depends on any other activity.

3.3 Risk Management

Here you can describe the identified risk and how the risk can be mitigated.
The risk can be contractual, technological, size and complexity. human
resource, etc. and for each such risk. contingency plan needs to be
documented.

54
Unit 2 Let's Begin: Initiating

3.4 Monitoring and controlling mechanism


Here you can describe various reports, formats, audits and review
procedures.

3.5 Staffing approach


Here you can describe the required skill set, recruitment guidelines, training,
etc.

4. Technical J>roccss
How the technical process such as design. coding, testing, etc. will be executed
is described in this section.

4.1 Tools and techniques


Various tools and techniques that can be used in a project are explicitly
written in this section, for example you can use MS Visio for designing
and Win runner for testing purpose. Along with these tools, you can include
various methods such as coding templates, use of unified modeling
language, etc.

4.2 Software Documentation


This is one of the most important sections of the SPMP. It describes how
the documentation for different process will be maintained. Some of the
main documents are Software Requirement Specification (SRS), Software
Design Description (SDD), Software Test Plan, etc.

4.3 User Documentation


User documentation includes user manual, user guides, installation and
setup procedures. Here the plan and format of each document is described
in detail.

5. Training & Support


Training & support needs of end user will be described in this section which
includes training schedule.

6. Budget, resource requirement{,), schedules are also included in the project


management plan.

55
Project Management

f!6 Activity E:
1. Explain the impmtancc of project management plan.

- --- - -----

2. Name five project activities included in a project management plan?

3. Try to understand the SPMP and apply to your academic project and sec at
what extent this is appJkabJc to your project.

2.8 SUMMARY

In between project initiation and project closure, various activities arc being
performed. These activities highly interact with each other, that means we cannot
execute some of the activities in 100 percent isolation. The success of a project
depends on how effectively activities arc integrated with each other & smooth
coordination between them. It is the responsibility of the project manager to keep
all individual people & processes together and to keep the balance.

Project initiates to resolve underlying problems or to satisfy the needs. The needs
and problems can be imposed by internal or external factors . There arc basic six

56
Unit 1 Let's Begin: Initiating

types of needs such as business need, market need, customer's request, technology
advancement, legal & social requirement.

Project Charter document officially announces the commencement of a new project


and gives authority to a project to utilize the project resources for project work.
Software industry is an external agency that provides solution to various customers.
Project initiation activity begins with the official request from customers; generally
it is included in the contract document. Various financial analysis tools such as
benefit measurement tools, NPV, pay back period, etc. arc used for selection of the
project.

We also studied the contents of the preliminary scope document and project
management plan. Preliminary scope document contains high level requirements of
the project. Project management plan defines how the project is to be executed and
what is going to be produced. Project management plan also provides guidelines for
scope, quality, risk, cost and communication management.

2.9 SELF-ASSESSMENT QUESTIONS


-- - - - -
1. Explain various tools and techniques used in project selection.

2. Explain briefly the project chatter development process.

3. Explain the importance of process integration in project management.

4. List various software engineering process models.

5. Explain why a project initiates.

6. Prepare project management plan for library management system.

7. Identify scope, constraints and assumptions of library m~magement system.

57
Project Management

3.1 L~TRODUCTION

In the last unit, we studied how project initiates and the contents of project
management plan and preliminary scope statement. Once the project management
plan & preliminary scope statement is ready, we can start other activities such as
planning, estimation, budgeting, schedule development and task assignment. Scope
document is the base document for all such project management activities. Many
activities depend on scope, for example without scope we cmmot estimate effort,
without estimate we cannot schedule and prepare budget and without budget and
schedule we cannot execute the project.

Scope not only needs to be defined but also requires to be controlled because a
single change in the scope may change the budget and schedule of the project. The
objective of every organization is to make the project successful and earn profit. lf
the scope is not controlled properly, it may reduce the profit of the organization.
Continuous changes in the scope may imbalance project and ultimately may fail.
Hence scope management becomes a very important activity.

In this unit, we will study how to manage the scope of software. Scope management
includes requirement gathering, analysis & elicitation of requirement. controlling
changes to scope and verification of scope when product is ready.

3.2 WHAT IS SCOPE'?


Scope refers to all the work involved in creating the products of the project and the
processes used to create them. We know that in order to begin some work, we need
some information; whether the work may be a construction of new building or
construction of software. To construct a building or construct ERP software arc high
level requirements. They only initiate further thinking process. We cannot build a
software on such small requirement. Hence we further drill down the requirement to
a sufficient level with which we start building software. However, the detailing
process becomes overwhelming because not a single system completely works in
isolation. It interacts with other parts of the system, hence we must define what part
this project will cover and exclude. To reduce overwhelming requirements what we
do is we put boundary and confine our requirements within that boundary. For
example, to construct a building we first defme the square footage area of the building;
similarly in software development the scope is defined first. There is slight difference
in scope and requirement. Scope defines the boundary while requirement defines
the detailed specification of the product or project. The scope clearly defines what
is to be delivered and not delivered as a deliverable of the project.

60
Unit 3 Know the Boundaries: ~1an aging Scope of tbc Project

We are studying project management, hence our main concern is how to manage
various process such as planning, estimation and budgeting. But for technical
management, only scope is not enough, hence they require detailed requirement
document called Software Requirement Specification document (SRS).

Type of scope:
Scope can be defined for project as well as product.

Project Scope:
Project scope defines the work to be performed to deliver the software. In order to
develop a software, we perform various activities such as planning, monitoring and
control, budgeting, scheduling, communicating, reporting and documentation. Each
such activity is clearly defined in the project scope. As each project is unique, project
requirement varies in detailing, for example communication and reporting
requirement may vary with customer.

Product Scope:
Product scope defines expectation of customer from the product. Product scope
broadly consists of functional and non-functional requirements of the software.
Functional requirement includes various application specific functionalities such as
payroll processing, I .edger posting, stock update, etc. Non-functional requirements
describe the quality and security requirements such as user authorization, backup &
restore, processing speed and response time, etc. Product scope document acts as a
base document for managing software development activities such as requirement
gathering. analysis and design, coding and testing, etc. Product scope generally further
elaborated into comprehensive software requirement specification (SRS) document.
SRS document is generally prepared after preliminary scope definition.

PSActivity A:
1. What deliverables do you thing to be added in project scope?

---------------------- ------

61
Project Management

2. Write down I 0 functional requirements of library application software.

------ ---- ---- --

·- - - -- - - - - - -· - - - - - - -- - ·- - - - - -

3. Write down 10 non-functional requirements of banking software.

- - - ----- - - - - - - - - ---- -------


·- - - - - - - - - -·- - - - - - - - - --

·- - - - - - --- - - - - - - - - - - - - - - ---
---- ---- - - - - ----------- -- ---
4. Give three reasons why scope document is essential in software projecLI).

----- - --- --- - - --

5. Find out difference between scope document and SRS.

3.3 SOFTWARE SCOPE MA~AGEMENT PLAN

In the initial stage, during scope defmition phase, customer has influence on the
project and the project team may not have clear vision about the scope of the product;
many .a times customer is not sure what to be documented in the scope. The result is

62
Unit 3 Know the 11oundaries: Managing Scope of the Project

incomplete scope document. Incomplete scope in initial stage adds requirements in


later stages of development. Poorly managed scope leads to cost and schedule
overruns. In order to avoid this, we must plan how we are going to manage the
scope. An output of initiation processes is a project charter, which is a key document
for formally recognizing the existence and providing a broad overview of a project.

Scope management plan is a detailed document which describes how we are going
to define the scope, what tools we are using to manage the scope, how we are going
to control the scope and how we are going to verify the scope.

Scope management plan and scope statement provides common understanding among
the team. This plan provides guidelines to document the project scope. The scope
management plan further guides how the work break down structure will be
developed.

How you document the scope is important since your team is a discrete combination
of techno-functional stakeholders. Inherently documentation cannot provide each
and every detail about the project and solve the queries of the stakeholders. Scope
management plan provides guidelines on how the scope document is maintained
which includes the outline of document and description of each content, etc.
Generally, scope management plan contains descriptive language and decomposed
into manageable activities.

This decomposition is presented in a hierarchical structure called as work breakdown


structure. Scope management plan provides guideline about how the WBS is
developed and maintained. Developing scope management plan from scratch is a
time consuming activity. You need some information at hand to develop such a
plan. An easy way to find such information is to refer to the previous project scope
management plan or use templates. Asking the experts who have developed similar
project helps to understand critical points in the current project.

Scope management plan is generally created as subsidiary plan of project


management plan. If detailed guidelines are provided in project management plan,
then there is no need to again rewrite the same. You can directly refer these guidelines
from project management plan. Other relevant information essential for developing
scope management plan can be accessed from the project charter, preliminary scope
statement. While developing scope management plan, you must take into
consideration the existing infrastructure and human resources. Your existing
infrastructure or your team may not be capable to deliver everything asked by
customer. For example, customer may ask you to use embedded technology to provide

63
Project Management

mobile computing but your team may not have sufficient hands-on experience in
this technology. The scope that cannot be delivered through available infrastructure
and resources need not be accepted as a part of the scope and clearly excluded from
the project scope.

Controlling scope is another important activity. The scope management plan provides
guidelines on how the scope is controlled. Someone rightly said "If project is allowed
to change freely, the rate of change will exceed the rate of progress". Despite your
careful and detailed planning, your scope is likely to change. These changes need to
be properly managed and controlled. Request for change directly affects project
schedule and cost. Well defined change control process can smoothly handle such
changes.

Ultimate aim of any project is to deliver the product or service that satisfies the
expectations and need of the customer. To ensure that the delivered product is
acceptable to customer, the project scope plan must provide the guidelines which
describe how the product deliverables arc verified. Verification process evaluates a
product or service & involves processes like review meetings, checklists, standards
and organizational conventions, requirements and specifications. The guidelines for
verification process arc described in scope management plan.

3.4 HOW TO DEFINE SCOPE


- ------------------------
It involves subdividing the major project deliverables into smaller, more manageable
components (WBS). Defining scope is the process in which all high level requirement
defined in preliminary scope statement arc further elaborated to sufficient details so
that the team can easily understand and execute requirement. You can refer the
guidelines on how to define and control scope as defined in the scope management
plan. In practice, request for change always occurs during execution. these change
requests need to be properly updated into the scope statement.

Scope definition process begins after the scope planning process and requirements
gathering. A customer may give ample requirement but all may or may not match
with the stated objective of the project. Defining scope means filtering out those
requirements which are extra and cannot fit in the approved budget and time.
Sometimes a customer may insist to include specific requirements. In that case, the
project manager has to negotiate with the customer and make him agree with the scope.

Scope definition is an interactive process and while defining scope, original plan
may revise. While making scope definition, two documents are mainly used namely

64
Unit 3 Know the Boundaries: Managing Scope of the Project

the Project Charter and preliminary scope statement documents as input to the scope
definition process. All detailed requirements are checked with the budget, time and
quality requirements described in project charter and preliminary scope statement.
What is mentioned in charter and preliminary scope is not sufficient. You have to
check whether the project can be executed with the available team and infrastructure.
For example, the customer may ask to provide Rl 'ID technology to track the material
in logistics or may ask for image processing for specific application; however you
may not have technical expertise on this technology or necessary software to
implement; in that case you will have to negotiate with the customer.

While defining scope, you should keep in mind that you are providing only required
things to the customer to achieve the objective of the project. Anything extra than
required is called as gold plating. Good project manager and his team should always
avoid such gold plating. Work excluded from the project scope need to be clearly
defined. Various tools & techniques like product analysis, stake holder analysis and
alternative identification are used in this process.

The output of scope definition process is project scope statement. This document
contains more details than preliminary scope statement. Once the scope is defined,
it is further detailed into software requirement specification document. SRS describes
requirements in detail while scope statement just provides requirements in term~ of
deliverahles. The scope document becomes an input to SRS development for detailing
requirement.

Generally, project scope document includes

Project Objective: Objective of project is the definite purpose behind the initiation
of the project. The objective gives direction to the project. A project can have multiple
objectives. Few of the organizations specifically define the objective of the project
and most of the time objectives arc ignored. A project manager must define the
objective of the project. Defining project objectives needs skill and clarity about the
purpose. Ability to visualize the work undertaken with possible gains and losses
improves the quality of the work. Quite often the objectives are stated as a formality.
Such objectives never help the project team. A well stated objective can decide
whether the project is successful or a failure.

Technique for setting GoaVObjective


Setting goal or objective means writing desired outcome of the project. Our tendency
to think in general terms adds vagueness to the objective. Vague objectives neither
Project Management

support any direction nor help in planning the activities to achieve the desired purpose. To
set clear and precise objective, SMART technique can be used. Let's understand meaning
of the word SMART in defining objective.

'S' stands for Specific. Specificity helps you to visualize your objective. Por example I
want to reduce my weight by 10 Kg in two months is a specific objective. Here you are
specifying the desired result; instead if you write just I want to reduce my weight, it does
not help you to plan your activities.

'M' stands for measurable. Your objective should be measurable. In the above example
you can measure your objective. You cannot measure objectives just by stating "I want to
reduce my weighf'. You need to quantify the objectives. It is well known that a person
who can talk in terms of quantity knows more. When you talk in terms of quantity you can
think how much effort you have to put to achieve that objective and measure.

'A' stands for Ach ievahle. Your capacity detennines how much you c<m achieve in a given
time frame. You should always take into consideration your (in case of Project-Project
Team) core strength. In the above example, if you state your objective to reduce weight 1
kg per day. then it may not be achievable and it doesn't make any sense. However. you
can stretch you goal little further since you may not exactly know your capacity.

'R' stands for realistic. Can you achieve unreal goal? Reducing weight to zero kg is an
unrealistic objective.

'T' stands for time bound. While setting your goal, you should define the target date
at which you want to achieve desired result. In the above example, it is well defmed
that the said objective is to be achieved in one month. Further to this, I would suggest
you to state the start and end date in your objective.

Product Scope Description


Let's quickly overview the contents of product scope description.

Project Requirement
This section describes the project level requirement and not product requirements.
Project level requirements could be related to project planning, budgeting, schedule
and estimation and communication. For example, use of automated tools such as
MS Project or any other project management software could be project level
requirement.

66
Unit 3 Know the Boundaries: Managing Scope of the Projt:cl

Project Deliverables
Once we understand project and product requirement, we have to convert these
requirement<; into deliverables. Deliverable is the actual output or end result delivered
to the customer. We must understand the difference between deliverables and
requirement<;. For example you arc assigned as a PM to deliver the word editing
softw·arc, then main deliverable of the project is word editing software. However,
providing facility such as spell checking, Printing, :Mail connectivity in your editing
software arc the requirements of the product. Delivcrablcs are nothing but collective
requirements. Deliverable comprises of requirements.

Project Boundary
Project boundary explicitly states what is included and excluded from the project.
For example. in ERP implementation project you can explicitly state that historic
legacy data migration is excluded from the scope of the project work. since many a
times the migration becomes separate projects and it heavily consumes your time
and cost. If you do not explicitly define what is excluded from the project, your
stakeholders may assume that you are supposed to deliver.

Product acceptance criteria


Product acceptance criteria defines how the delivered product is accepted by the
customer. It defines various processes and procedures, guidelines for accepting
criteria. Once your product is ready. it needs to be formally accepted by the customer
for releasing the payment. Before accepting product. customer may want to check
quality. fitness for use, features of the product as per scope.

Project constraints
In order to deliver a product, we arc utilizing various resources. These resources
directly or indirectly affect the performance of the project. The main constraints are
scope, budget. schedule, human resources. technology. Each of these resources have
a limit with respect to the project. We cannot exploit these constraints beyond their
limitation.

Time constraint
When projects are limited by specific time fran1e, then you cannot delay or exceed
that time limit. For example some projects need to be finished in specific time after
that time there is no importance for that project for example implementation of
electoral voting system to be finished before the declared date of election.

67
Project Management

Budget constraint
Budget constraint defines total budget sanctioned to the project. Ifproject exceeds beyond
budget, customer may not be liable for paying extra amount hence enough care should be
taken while defining scope of the project so that only required things are delivered to the
customer within given budget.

Schedule constraint
A constraint that affects or delays your project activities called as scheduled
constraints. For example, organizations have only one software architect and assigned
early on some project and he is not available for the project next two months. The
availability of software architect can delay your project schedule by two months.
Here the architect is the source of schedule constraint.

Technology Constraint
In IT industry, new technologies arc always emerging and project team may not
have hands on experience in the technology. You cannot afford to have team expertise
in every technology and you need to manage the project with available technology.
Many a times the technology itself has limitation, for example the capacity of database
to store huge data, support for new features such as object oriented techJlology.
These constraints are called as technology constraints and arc written explicitly.

Project Assumptions
Assumptions are the things that you believe to be true. With your prior experience
you assume that something will go in a particular way but in reality it may not be
true. In a project you assume that the key resource is available till the project
completion but in reality he may leave the project prior to completion. Another
most common assumption could be, the team will grasp new technology in shorter
time. These assumptions are possible sources of risk and need to be mitigated to
avoid project failure.

~Activity B:
1. Use SMART technique and define objective of library system.

68
Unit 3 Know the Boundaries: Managing Scope of the Project

2. Explain the difference between deliverables and requirements and scope.

3. Explain and identify various constraints in your current academic project.

4. Do you think writing constraint, asswnptions are essential? Explain.

5. Prepare a scope document for your library management system.

3.5 WORK BREAKDOWN STRUCTURE (WBS)

WBS is the hierarchical breakup of work to be executed either in team or by a


single person.

69
Project Management

Work break down structure is the center of many project management activities. It is a
bridge between project scope statement and project execution. It is a map that guides us
how to reach to the destination of project. WBS is the hierarchical structure that describes
the breakup of various activities that we need to perform to achieve the objective of the
project. A WBS is an outcome-oriented analysis of work involved in a project that defines
total scope of the project.

WBS is heart of the planning process and interacts with other processes such a<;
estimation, scheduling. budgeting, verification and controlling as shown in the
following figure. Can we plan the project if we don't know what different activities
need to be performed? Surely not. WBS defines all the work that needs to he
performed to complete the project.

Veri !\cation&
Controlling

Estimating
I~ I ~I Budgeting

I WBS
I
I~ ~I
Scope
I Planning

I Scheduling I
Fig: 3.1
Let us assume that you are developing word editing software. In the scope statement of
word editing software project, it only mentions the main functionalities of the word editing
software such as file editing facility. printing & formatting facility, etc. However, in order to
deliver word editing software you need to perform various processes such as further
requirement detailing. preparing data flow diagram, designing architecture of the product,
coding, testing, preparation of online documentation, etc. We cannot manage the entire
project as whole or single activities. We need to break down the project further into
manageable activity. This decomposition pre..<;ents the project work in hierarchic.:'ll tree like
structure hence called as Work Breakdown Structure or WBS in short.

WBS is usually prepared before the planning, however it may get revised as WBS serves

70
Unit 3 Know the Boundaries: Managing Scope of the Project

many purposes to many people of the team. It can be used as input to planning, estimation,
scheduling, scope verification, status reporting. It acts as a communication tool <md ensures
the common understanding of project scope between all stakeholders.

We can manage small projects without WBS because we know what work needs to
be done and who will do what since the team is small. You can simply keep all
relevant data in your memory or diary and manage the project, however in large &
complex projects, hundreds of employees are working on thousands of tasks . In that
case, you need diagrammatically presented work decomposition so that you can
share work activities information across the team.

WBS can be created separately for product scope or project scope or combination of
both. Products WBS generally decompose the product related activity and project
WBS decompose project activities. Generally WBS is shown in hierarchy as depicted
in the following diagram.

Project delivcrablcs

Work Packages WBS dictionary

IActivities

Fig. 3.2
Let's understand various components of sample \VBS structure. The following iigure shows
the WBS ofERPproject.

71
Project Management

I)roject Deliverable

D.::sign
1
Design
Screens Reports

Activities

! l Design Login
Screen
Create Normalize
Structure Structure
Design Master
Screen

~~ig. 3.3

Milestones
Milestones arc shown in the tirst level ofWBS diagram and top node in the hierarchy.
Diagram shows typical milestones of software engineering activity such as analysis,
design, coding and testing. However, you may add project management activity
such as planning, scheduling, and budgeting in the same diagram or prepare separate
WBS if the diagram is too much crowded. Milestone is a significant event in a
project. Milestone is not an activity to be performed; rather it is an outcome of many
activities. Hence milestones are also called as zero duration activities. When the
project progresses ahead, we will reach many milestones. For example, requirements
gathered, prototype finished arc the major milestones. To reach to the milestones,
you may have to perform many individual activities. Milestone helps to identify
whether the project is leading in the right direction. After each milestone is reached,
the project manager can take a review meeting with his team members.

Work Package
Next to milestone, work packages are shown in the second level of WBS diagram.
Here design Milestone is decomposed into three work packages such as database
design, screen design and report design. These work packages may be further divided

72
Unit 3 Know the Boundaries: .Managing Scope of the Project

into small activities. For example, work package could be to gather requirement, design
screens that can be further decomposed to activity level such as designing screen for login,
design screen for master, etc. Activities arc at the lowest level in the WBS and need not be
decomposed further.

WBS dictionary
WBS dictionary is a supporting document for WBS. WBS dictionary contains the
details of work package and is generally made for each work package. As WBS is a
graphical presentation, we cannot show detailed information in the diagram. Just a
brief description of work package such as "Design logon screen" is not sufficient
for the team member to execute the task. Hence further details such as work
description, deliverahles, acceptance criteria, assumptions, expected date of delivery,
duration of task are added in WBS dictionary as shown in the following WBS
dictionary template. You may add any further information that you think relevant to
package. WBS dictionary is linked with WBS hy Work package no. Related work
packages arc grouped together and given control no. That control no. will he helpful
in controlling the cost of the project.

WBS Dictionary

Project# Project Title

Work package No Control Account No

Date of creation Date of revision

Work package description

Deliverahles

Acceptance Criteria

Assumptions

Duration Expected date of delivery

Resource assigned Resource responsible

Approved hy: Project Manager

73
Project Management

How to create \-VBS?

The main purpose of creating WBS is to ensure that all activities required for
delivering projects arc captured and nothing is missed out. During a project, your
team may be executing hundreds of technical and managerial activities. With the
help of hierarchical WBS diagram, you can show major activities so that you can
check with your team if anything is missing. WBS only describes major tasks and it
is not a "to do" list which provides every minute detail.

Creating WBS is a team activity in which the Project manager along with the team
defines major activities or deliverables of the project and decomposes them in small
manageable activities called as work packages. The decomposition technique helps
you to identify the various activities of the project.

Now you may ask why to create WBS every time if the project executes similar
task? You are true, usually many of the technical tasks such as coding. testing,
designing are there in every project though projects are unique. However, work
packages may differ hence you need to create WBS and WBS dictionary for every
project. If projects are similar, you can use WBS templates of previous projects &
make necessary changes instead of recreating entire WBS. However, you should
not lose out the basic purpose of the WBS while using templates. WBS can be
created in various ways and there is no any unique method for creating WBS . WBS
is generally represented in Tree like hierarchical structure where top node of WBS
represents main deliverable of the project and the last leaf in the tree is called work
package. Sometimes, work clements arc so huge in number that you cannot easily
draw in tree like fonnat. In that case, WBS will be represented as an indented text in
the Excel sheet.

WBS can be presented in m::my forms. You may choose what's appropriate that suits
the project and can be understood by everyone in the team. Before creating WBS,
you must first decide the approach of creating WBS that means the way you are
defining hierarchies. Second, decide the depth of the tree. For better control, the
level in WBS should not exceed 5111 level. If it goes beyond 5111 level, it becomes
complex to manage and control. Third thing is to decide which activities should be
shown on the WBS. It is advisable that show the activities which require minimum
one week of duration to complete which will automatically exclude all your day to
day activities.

Another advantage of showing week duration activity is that you can monitor and
update the weekly status of the project easily. With WBS you can ask your team to
submit the status in numbers of activities completed.

74
Unit 3 Know the Boundaries: Managing Scope of the Project

WBS Tcchnique.4ol:

There is no specific way of creating WBS. Same project scope may be decomposed
in many different ways. To have more clarity, we will discuss the two different ways
in which you can create WBS.

The following diagram describes the sample WBS for Word editing software

Word Editor Word Editor

File utility Printing Graphics

Figure 1 Figure 2

Fig. 3.4
Generally, activities are arranged in top down manner. The 0 level of the activity is
the highest node in hierarchy. It describes the name of the project or the main
deliverable of the project written in short and meaningful way. First level in hierarchy
usually represents the milestones, means this activity is the outcome of other activity.
Here you can show two approaches, either you can show the major dcliverables or
modules of the project such as in this case File Utility, Printing, Graphics in first
level as shown in figure 1 or you can show software engineering tasks such as
requirements gathering, design, coding in first level as shown in figure 2. For each
module, say for example, file uti1ity module. you need to perform three activities
such as collect the requirements for file utility module, design that module and code
that module. You can show these software engineering activities in 2nd level as shown
in figure 1. In the second approach, you can decompose software engineering
activities in various modules as shown in figure two. Both the approaches are one
and the same and docs not make any practical difference in how you execute tasks.
It is your personal way of looking & managing how to organize work. Another
question which may come to your mind is how to sequence the activities? Here you
should note that WBS does not signify any sequence. We will learn the sequencing
of activities in time management section of this book.

75
Unit 3 Know the Boundaries: Ylanaging Scope of the Project

3.6 CONTROLLING Till: SCOPE


Scope controlling is an impmtant activity and needs to be performed throughout the
project. The process ensures that scope is within budget and schedule. Scope
controlling process is generally performed after the execution process. In this process.
the deliverable generated in execution process are measured against the scope
baseline. Scope baseline consists of project scope statement, WBS and WBS
dictionary.

Controlling scope means preventing unnecessary changes. In order to control the


changes one must know how & why changes occur during the project and how to
control them. There arc various reasons behind change request, one could be your
requirements are not properly captured. end user has not completely transferred
knowledge to you or the delivcrables arc not matching with the expectation of the
customer. Once you know the possible causes behind the change, you can take
corrective actions. For example, you can usc techniques such as use case diagrams
for capturing requirements; you can freeze requirements by signing of SRS, etc.

Another thing you need to control is scope creep. It may he either due to additional
requirements of customer or sometimes your team players may add extra features
which arc initially not in scope. For example, many times programmers want to
experiment new things that they recently learnt. Accordingly they keep on adding
new features to the project However these features arc not in the project scope. lt
may add problems in later stages of implementation. lienee such changes need to be
controlled tactfully. You need to maintain balance between the creativity and
experimentation of a programmer and the scope and schedule of the project.

Various techniques such as change control system, variance analysis, re-planning


and configuration management system, etc. can be used for controlling scope.

Change control system is one of such tools in which every requested change should
be executed through change control system. You can ask your team to implement
only approved changes. The change control system will continuously monitor and
control through feedback loop. The feedback loop provides facility to correct the
deviation from standard.

Variance Analysis: This tool measures the difference hetween what wall defined in
the scope baseline and what was actually created. It also determines the cause of
variance and accordingly corrective action can be taken.

77
Project Management

Replanning:
Change does not come alone. Only correcting changes in source code is not enough.
You need to check the impact of changes on schedule and budget. Re-planning tool
is used to evaluate the impact of change on cost, quality, schedule and risk. After
evaluation, the changes arc updated into WBS and WBS dictionary. This further
changes the estimation and needs to be re-planned.

Configuration management system:


Every change needs to be reflected in various components of the project such as
source code files, design documents, testing documents, planning documents, etc.
Configuration management system is a methodic way to keep track of various changes
to documents and source codes. Various software tools are available to manage
configuration of project. Also you can manually track changes in excel sheet. Most
of the technologies today provide inbuilt configuration management system, for
example Microsoft provides Visual Source Safe (VSS) for controlling versions of
source code.

16Activity D:
1. Explain the scope control process.

2. Explain vruious tools used to control scope.

78
Cnil 3 Know the Boundaries: Managing Scope of the Project

3. Why scope needs to be controlled? Give an example of scope creep.

3.7 SCOPE VERIFICATION

Scope verification involves formal acceptance of the project scope by the


stakeholders. Scope verification process verifies that software product meets the
objectives of project defined in scope statement. It verifies that each deliverable of
the product is as per the acceptance criteria defined in the scope management plan.
If all the deliverable meeL"> the acceptance criteria, customer formally accepts the
product.

Scope verification and quality control are two different processes. Quality control
checks whether project meets the quality requirement of the product described in
quality plan or specifically mentioned as quality requirement while the scope
verification finds out how much work is completed as per requirements. Scope
verification is generally performed after quality control process. Before scope
verification, it is ensured that deliverables meet the quality requirements.

Scope vetification process begins when the execution is over and deliverables are
ready for final acceptance testing. Scope verification process checks each deliverable
at work package level. Scope verification process refers project management plan,
WBS and WBS dictionary. Project scope management plan contains the details about
how the scope is verified, at what level scope should be verified, how customer is
going to accept the scope, etc. You can get the details of work package and deliverable
in work breakdown structure and project scope statement.

The outputs of the scope verification process arc accepted deliverables, requested
changes and recommended conective action. During inspection, the stake holders
suggest some changes or corrective actions and these changes need to be handled
with integrated change control system.

The main tools that can be used to verify the scope are reviews, inspections and
walkthroughs.

79
Project Management

Reviews:
Reviews also ca1led as walkthroughs is the manual process in which problems are
uncovered through the direct examination of each component of the product. There
is a team of reviewers. Each member plays specific role. All team members are
formally trained and know how to conduct reviews. Reviews can be conducted in
various ways and fonuatted as per the organization policy and nature of the project.
Reviews could be formal reviews or informal. One more type of review is Peer
Review.

Peer review is a defined key process area for CMM (capability maturity model)
level3. As per CMM. the activities of peer review should be well planned in advance
and that the defects in software dcliverablcs are identified and removed. Peer review
involves methodical examination of deliverables. A properly managed review ensures
early detection of problems which further minimizes overall project cost.

RS Activity E:

I. Differentiate Scope Verification and Quality Control.

2. ·which tools are used in scope verification process?

3.8 SUMMARY
- - - - - --
In this unit, we studied the four scope management processes. Scope is nothing hut
the description of the work to be delivered to the customer. Scopes arc divided into
two types such as Product Scope and Project Scope. Project scope defines the

80
Unit 3 Know the Boundaries: Managing Scope of the Project

deliverables/activities of the project while product scope defines detailed description


of product features and functionality. Scope management plan is the document that
describes how the scope of the project is defined, managed and controlled. Scope
defines the boundary of the project that describes what is included in the project and
what is excluded from the project. Scope is one of the important documents since all
project activities such as planning, estimation, costing, etc. arc based on the scope.
Change is inevitable and has considerable impact on the triple constraint of the
project such as scope, budget and schedule. Change cannot be avoided and hence
needs to be properly controlled during scope control process. Anything extra given
to the customer which is not part of the scope is called as gold plating. After
completion of scope statement, work breakdown structure is created. WBS is a
hierarchical structure that describes the breakup of project into dclivcrables and
manageable activities. The smallest unit in WBS is called as work package. We also
studied the difference between deliverable, requirements and milestones. Deliverables
are nothing but collective requirement. Deliverables can be further decomposed
into small manageable activities. Scope documents generally consist of deliverables
and for detailed requirements Software Requirement Specification (SRS) document
can be maintained. Milestones are zero duration activities and indicate the occurrence
of significant event during project life cycle. Project can be reviewed at each
milestone. There are various approaches for creating WBS and most of the
organizations follow WBS template. Each activity defined in WBS is further used
in scheduling process and hence creating WBS is one of the most important activities.
WBS dictionary is another document maintained along with WBS which describes
the details of activity such as work description, person responsible, estimated durat.ion.
quality requirement, etc. Scope statement along with WBS and WBS dictionary is
called as scope baseline. This scope baseline is used for measuring the performance
of the project. After planning, controlling, managing and executing the scope,
deliverables are ready for deployment. The completeness of all deliverables is
checked in scope verification process. Project is successful when all stakeholders
formally accept the deliverables; hence scope verification is one of the most important
activities. Various tools such as inspection, reviews, etc. are used in scope verification
process.

3.9 SELF-ASSESSMENT Ql.J'Ji:STIONS


1. What is WBS and how is it created?

2. Explain various scope management processes.

81
Project Management

4.1 INTRODlJCTIO~

In the last unit, we understood what scope is and how it is defined and managed. We
also learned how to create WBS , i.e. how to decompose the given scope into
manageable activities. ~ow these manageable activities are used as basis for schedule
development. Once schedule is developed, activities can be assigned to resources
and mapped with the available time frame. The process of sequencing the activities
in a given time frame is called as scheduling. Scheduling process is one of the
important components of time management process. Schedule ensures the effective
management of the time constraint.

Time is one of the most important and crucial resource in project management. We
must therefore understand the impact of time management on the other two constraints
of the project. The following diagram represents triple constraint of the project.

We might find that we can meet one of these at the expense of the others.

We might find that we


can meet one of these at
the expense of the
others.
Scope

.'ig 4.1
The edges of the triangle represent the constraints; time, cost and scope. The above
figure illustrates that if we change one edge of the triangle, then we need to change
other two sides of the uiangle to keep the triangle in shape. Simply, we can say if
there is change in scope, then it will change the time and cost or if we change time,
then it will change cost & scope. For example, if you add any extra feature of module
to the scope of the project. it will take more time and accordingly more cost.

Projects are dynamic systems that must he kept in equilibrium. Project time
management deals with efficient utilization of time and involves halancing of the
triple constraint. Most of the software projects failure. cost overruns and delays fail
are attributed to effective time management. To ensure the completion of the project
in given time, we need to focus on two aspects of time management- developing
accurate schedule and adherence of team to project schedule.

86
Cnit 4 Count your Steps: Estimating and Schcdttling

Developing accurate schedule & increasing productivity arc the primary concerns
of time management. The basis for scheduling and productivity is sizing and
estimation of the software. Unlike other industries, software industry is not matured
enough in measurement and estimation of software. Thus it is in1perativc for us to
understand the basic concept<> of software sizing and estimation.

ln this unit, you will learn the basics such as software measurement, estimation and
schedule development. As scheduling is based on mathematics, we will come across
various formulas. Scheduling can be as simple as listing activities with start and end
date and resource assigned and may get complicated by considering the precedence
of the activities and their interdependence etc. Now-a-days various scheduling
software arc ava11able and one can usc that if he is not comfortable in using the
mathematical formulas. Even if you arc not an expert in handling mathematical
calculations, you can use vruious tools such as MS project, which docs all complex
calculations for you. However in tllis unit, we will study only manual schedule
development process.

4.2 SOYfWARE MEASUREME~T

Imagine that you go to a big city mall to buy a perfume. There arc several brands
available and you have to choose the best one to fit in your budget. So you start
comparing the net quantity and quality verses the price. These two are the measurable
properties of perfume. Can you go to a software consulting firm and ask for software
which can be specified quantitatively as in the above example? Certainly not!

Software cru1 be measured in different ways unlike other commodities. Software


can be measured in terms of units such as lines of code, no. of function points etc. ln
real life, software project<; demand a quantitative specification which cru1 he measured
in terms of time and efforts. Software mea<:>uremcnt helps in size & effmt estimation,
productivity analysis and improvement, quality control and overall project
management.

Importance of software measurement


In order to understand the importance of software size, let us relate to our day to day
experience. Assume that you are host of a program and invited twenty guests for
lunch, accordingly you placed order of twenty dishes to the hotel manager. As a
sponsor. you arc interested in the quality of food and fast service. However, the
hotel manager is concerned with fast delivery (Productivity), Quality and size of the
order. You may understand from the scenario that the size of the order is critical for

87
Project ~anag<!mcnt

the hotel manager whereas you as a sponsor are looking at the time and the cost
only!

Simulate the same example to software development and you will be able to
appreciate the importance of software size estimation to you as a project manager.
Software size is very important in many project management areas such as planning.
estimation. budgeting, quality, risk, etc. Your customer may not be much interested
in software size but you as a project manager must know the size of the project.

Software Size

Software size determines how much coding will be required to fulfil the requirement.
Size is a physical measure and we can determine size of a thing based on observable
dimensions. Similarly, to measure software size. the observable dimension could be
no. of lines of code, total functions. modules, no. of database files used, etc. which
can be measured physically.

Since software is a logical commodity unlike other physical commodity. we cannot


totally rely only on the physical dimensions of software. Only physical dimensions
such as lines of code will not be able to tell how complex the project is. For that
matter, we need to consider the other intangible aspects such as tl1e complexity,
execution speed, memory requirement and functionality of the software. Functionality
of software can be measured with no. of input variable required, no. of control
structures required (if-then etc), no. of database files required, no. of outputs
generated, etc.

There arc various tools and techniques with which we can measure the size of the
software. While determining size. we must consider other factors such as the
language. experience of the programmer, etc.

The lines of code depend on language used for development. For example, a function
to add two numbers requires few lines of code in vb.net while same function may
require hundred lines of code in COBOL. Another point that is to be considered in
software sizing is the style of prognm1mer and his intellectual capacity. The same
function written by two programmers in two different programs are never same
unless they arc copied. Similarly, intellectual capacity of two programmers may not
be same. For example. one programmer can write a complex program in few lines
of code while other one may take many lines.

88
Unit 4 Count your Steps: Estimating and Scheduling

f6 Activity A:

L. Explain the difficulties in software estimation compared to other disciplines


considering a real life example.

2. State any important feature that should be considered as a unit of software size
apart from the ones discussed in this book. Justify yow- answer.

4.3 SOFfWARE ESTIMATION

Software estimation is the process in which the size of the software is determined in
terms of measurable quantity such as LOC. function points. etc. The estimations are
generally given by programmers. Project manager analyzes the estimates with the
budget and scope. If he finds any variation he negotiates with programmers and
reduces the estimate. There arc various ways of estimation. Each organization follows
their own standard for estimation. Estimation is more of skill and judgment. Most of
the estimat~ons arc based on the past experience.

Let's quickly review some of the most common estimation technique available.

1. Software size estimation techniques


LOC based estimation
The LOC based estimation is a commonly used and widely accepted technique of
size estimation. This type of estimate determines how many lines of code are required
to fulfil the requirement. It is very clear that we cannot accurately predict LOC

89
Project Management

estimate of the software which is not developed yet. However, as estimation is given
prior to execution (writing source code), we need to take the help of experts and the
historical data of similar project-;. This is called as estimation by analogy in which
estimation data for each component is taken from similar projects done in past. This
is a rough cut estimate and no one can exactly tell you how many lines of code will
be required since in software development no two projects are exactly alike.

The LOC estimate can be derived for each work package ofWBS. For determining
size, we have to consider the WBS. WBS gives us the breakup of main software
application into various modules and components. For example, consider the WBS
of login module - Login module is an interface which takes user ID and password
from the user and validates. Upon successful validation, the user is authenticated.
For login. you need a formatted screen to capture data, code to transfer & validate
data from the screen and send it to the database table to store the user data. With this
breakup of activity of login module, you can guess and roughly estimate lines of
code required for developing the module. By summation of all the individual modules'
lines of code. you can derive the total LOC estimate for the main project. This type
of estimation is called as bottom up estimate.

For estimation, you can refer to the historical record of similar projects. From the
historical data you can find out how many lines of code are required for developing
similar functionality and add to them extra lines for additional functionality.

The popuhu· units used to express lines of code are:

I. SLOC - Source lines of code - the actual lines of code written by the programmer
before compiling is counted and called as SLOC.

2. KLOC - Kilo lines of code - used on a larger scale when code exceeds thousand
lines

lKOLC = 1OOOLOC.

Three point estimate


For better accuracy, three point estimation formula is used. In three point estimation
technique the pessimistic (P), optimistic (0) and most likely (M) estimates are taken
from the programmers and values are substituted in the following formula.

Estimate = P+4M+0/6

90
Unit 4 Count your Steps: Estimating and Scheduling

Consider that the values of pessimistic, optimistic and most likely estimates arc
200, 400, 300 respectively.

200 + (300 x 4) + 400/6 = 300 LOC

General Guidelines
Although there is no standard method to count the no. of lines, following guidelines
can help in better estimation:

1. Only executable statements (lines) are counted and comments arc ignored.

2. All executable statements separated by semicolon on single line arc counted as


separate line of code.

3. All data definitions arc counted once.

4. Do not count the temporary code written for testing purpose.

5. Do not count code used for reused functions.

6. Assembly language equivalent can he used to compare estimation of different


languages.

Drawback of LOC based estimation:


The LOC based estimates arc simple to derive and widely accepted but has a few
drawbacks:

1. LOC based estimates cannot measure the complexity of the functions.

2. Productivity measured in terms of LOC may encourage programmer to produce


more lines of code, however software should ideally be having thin code with
minimum defects.

To overcome these drawbacks, other estimation techniques emerged such as function


point, Model Blitz, Feature Point and Delphi Technique. Though there are various
techniques available and each one with pros & cons. you need to select the appropriate
techniques that suits your organization policy and project needs.

Let's study another important & most widely used technique:

91
Project Management

Function point estimate


Function point estimate measures size of the software based on the functionality &
complexity of the software rather than just lines of code. The function point estimate
was first published by AJ. Albrecht at IBM for transaction oriented system in 1970.
!<unction points technique measures systems from a functional perspective- Function
points are independent of any underlying technology. Regardless of language,
development method, or hardware platform used, the number of function points for
a system will remain constant. The only variable is the amount of effort needed to
deliver a given set of function points. FPA is useful in estimating projects, managing
change of scope, measuring productivity and communicating functional requirements.

To understand the Function point, let's understand the example given below:

Suppose you want to purchase a software engineering book from the book store,
what do you look for? Are you interested just in the size of the book or the contents?
Some might be interested in size but not many. We look for the contents, the case
studies given, the style and language, etc.

·Ibis analogy depicts the size vs. functional aspect of the software. Here. size of the
book resembles LOC while the contents resemble the functional aspects.

The function point estimate counts the no. of functional points such as inputs, outputs,
file structure, interfaces to capture data and interfaces to display results. Each
functional part further analyzed with the complexity such as simple, average or
complex.

How to estimate using function point"


1. Count the occurrences of each category:
No. of inputs: Inputs are the number of forms that we usc to pass the external
data into system. For example. data entry forms for customer information, data
entry form for product information. How many such input forms are required is
calculated.

No. of user outputs: Output means processed data that can be in the form of
reports, screens, error messages etc. For example: salary report, ledger, etc.

No. of inquiries: Inquiries are usually smaller reports and the output of inquiry
is generally processed online and shown immediately to user on the screen. For
example, no. of orders processed in the specified period.

92
linit 4 Count your Steps: Estimating and Scheduling

No. of files: The data generated during processing need to be stored for future
usc. This data is generally stored in a logical structure called as flie/tables.

No. of external interfaces: Sometimes data needs to be fetched from other media.
For example, disk, tape, CDs, etc. External interface provides facility to capture
data from external resources.

2. Calculate the complexity of each category: The complexity of each category


can be simple, average, complex. For example. the input form for customer
information is relatively simple. While the input form for Bill of material entry
is comparatively complex.

3. Decide the weighting factor for each category in each complexity.

4. For each category. multiply the count of function points by the corresponding
weighting factor of complexity. Then for each category, add the products of
simple, average and complex as shown in column, total function points in the
following table.

5. Finally, add all function points in the last column that will give you total function
points.

!'unction Simple Simple Average Average Complex Complex Total


Category function
po inL~;

Count WI' Count WF Count WF


No. of I/P 1 3 I 4 I 6 13
~o. ofO/P 1 4 I 5 1 7 16
);'o. of Inq. I/P 1 3 1 4 l 6 13
~o. of Inq. 0/P 1 4 l 5 1 7 16
No. of fi les 1 7 1 10 1 15 32
No. of interfaces 1 5 1 7 1 10 22
Total 112

The above table shows the sample calculation of function point. In the above table,
WF stands for Weighting Factor, I/P =Inputs, 0/P =Outputs. Here for simplicity of
calculation. each functional category is counted as one. Thus total function points in
the above example are 112.

93
Project Management

The function point estimation was initially developed for business information system
applications. This model is further extended to estimate a more complex system.

Feature point estimation


Feature point estimation is the extension of function point estimation. Feature point
is a superset of the function point measure that can be more advanced applications
such as systems and engineering software applications. The feature point measure
accommodates application in which algorithmic complexity is high such as Real
time systems, Process control and embedded software. In feature point estimation,
the algorithmic characteristics of software is counted and the rest of the process is
same as that of function point estimate.

Object Point
This estimation model is useful in estimating size of the software which is developed
using object oriented technology. In this estimate, object point is assigned to each
unique class or object. The rest of the process is same as function point as described
above.

Delphi technique
Delphi technique is a group forecasting techniques, generally used for future events
such as technological developments projects. This is a disciplined method of using
the experience of several people to reach an estimate. This is very popular and
simple to implement. This technique does not require historical data and can be
used for high level and detailed estimation. The results obtained from these techniques .
are more accurate as compared to I .OC.

2. Effort estimation

Once the size of software is known we can estimate the effort required to accomplish
the task. Effort estimation is an important activity because it tells us how much
resources are required and the duration they will take to complete the project. Effort
estimates are mainly used for planning, scheduling and budgeting purpose. The cost
of software mainly depends on the effort estimate. We can directly relate the cost of
human resource to effort and prepare the cost estimate for budget purpose.

What is Effort?
The main resource in software development is human resource. The amount of time
a person invests to perform a task is called as effort. The effort can be measured in

94
Lnit 4 Count your Steps: Estimating and Scheduling

various units such as person-years, person-months, person-weeks, person-days and


person-hours. One person-year means one person working for one year to complete
a task. Two person-year means either two persons can complete the task in one year
or one person works for two years to complete the task.

COCOMO Model
The COCOMO stands for Constructive Cost Model. This model is based on the
regression analysis. Regression analysis is a tool that statistically interprets the
historical data and describes the mean and other statistical relationship between
other variables. This model was developed by Dr. BaiTy W. Boehm in 1970. He
analyzed data of 63 projects of vmious types and sizes. The project<; were observed
for actual size (LOC), actual effort and actual duration of the project. Boehm used
scatter diagram to plot the equation.
100 . . - - -- - -- ------------
80 +-------------------
60 +-------------------~~---~--------­

20
0 ~
._____.
~ +-----------~~~~
~-------.------
+---~~--~------~~---
.
0 1 2 3 4 5
Fig 4.2 Scatter Diagram

Scatter diagram such as shown above is used for deriving the equation. From this
diagram, a linear equation can be derived which takes the form a + b x where a and
b arc constants. This equation is the basis for predicting the effort.

Based on the complexity of projects, COCOMO model is further classified into


organic mode, semi organic mode and embedded mode.

Organic Mode
This category considers project of small size and simple to develop such as payroll,
store management system. etc. The team working on the project is small in size. The
projects under this category are general purpose projects and don ' t have tight
constraints such as time. budget.

Semi-detached mode
This category considers projects that are higher in size & complexity than Organic
mode projects. Team size is medium and constraint<; arc moderate. The project that

95
Project Management

requires high innovation pertains to this category. For example, projects such as
data ba<>e systems, compilers.

Embedded mode
This category considers the projects which are largest in size & complexity as
compared to the previous two modes. The projects need high level of innovation.
Project must be developed within a set of tight hardware, software and operational
constraints. Examples of the projects are air traffic control system, automated banking
system, nuclear control system, etc. All real time projects fall in this category.

fn addition to the above mode, Boclun defined three hierarchical levels of COCOMO
model as described below:

Basic Level
Basic level computes effort of software development as a function of program size
expressed in estimated lines of code. It is useful for rough cut estimate of small to
medium size project. The basic level is used when fast estimation of effort is required.

Intermediate Level
Intermediate level computes software development effort as a function of program
size and a set of fifteen cost drivers that include subjective assessments of personnel,
project attributes, product and hardware.

Advanced Level
This is an extended version of intermediate level. It considers the impact of cost
drivers on each software engineeting steps (analysis, design, coding).

Example of Basic J,cvel Estimation


Let's understm1d how to calculate effort, duration, persons and productivity of project
when the size of the project is given.

Effort (E) = a x (Size) h

Duration (D) = 2.5 x (Effort) ~

Person required (N) = E/D

Productivity (P) =Size/Effort

96
Unit 4 Count your Steps: Estimating and Scheduling

Where a, b and c arc the constants derived from regression analysis and depends on
the project. Size is measured in thousand lines of code (KLOC) and E is effort
applied in person-months. As most of the organizations do not have enough data to
perform regression analysis. they can usc the following table that describes the values
of a, b and c for three modes of basic COCOMO model.

Mode Value of A Value ofB Value ofC


Organic Mode 2.4 l.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.20 0.32

In order to calculate effort, duration, no. of person, productivity of a project simply


put the value of size in the above equations. Let's say project is simple and project
size is 100 KLOC.

As the project is simple, you usc values of a, b given for organic mode in the above
table and substitute these values in the formulaE = ax (size) b

Thus Effort (E) = 2.4 x ( 100) 105

E =2.4 X 125.8925
E = 302.1421 Person-months

Duration of project (D) calculated by using the formula D: 2.5 X (E) c

D =2.5 X (302.1421) 0 ·38


D = 2.5 X 8.7595
D =21.89 Months
No. of person (N) required can be calculated as,
N=EID
N = 302/21
N = 14 person required

97
Project Management

Productivity P = Size/Effort
Pirst Convert KLOC to LOC thus lOOKLOC=lOOOOO LOC
p = 100000/302
P = 331 LOC/Person-month

You can calculate the effort, duration, person required for various projects using the
formula mentioned above and the corresponding values of a, b, c from the above
table.

~Activity B:
1. LOC based estimation is called as the basic estimation tcclmiquc. Explain why?

2. When will you use COCOMO estimation technique?

4.4 SOFTWARE PROJECT SCHEDULING

The next step after estimation is schedule development. Software Project


Management is an activity that distributes estimated effort across the planned project
duration by allocating the effort to specific software engineering tasks. Schedule
tells us how we arc going to execute the plan in terms of days and activity. Schedule
is an elaboration of your plan with respect to time frame & resources used. Plan tells
what to be done while schedule defines what activities are performed when and by
whom. Schedule is usually shown in a tabular or in a graphical chart called as Gantt
chart.

98
L:nit 4 Count your Steps: Estimating and Scheduling

For effective utilization of time, we must know how much time each activity requires
and the dependency of each activity on other activity. For example, coding activity
can be started after completion of design activity, i.e. coding depends on design.

In order to develop a schedule. we must know the various activities that need to be
performed to complete the project. the sequence of each activity, duration of each
activity and resources needed as per the skill set required to complete the activity.
Here resources are usually human resources such as architect. programmers. testers,
quality persons. etc. Scheduling process takes into consideration the company
calendar which describes the actual days and hours available to carry out the tasks.
Scheduling is not a one lime process, for effective time management, schedule needs
to be updated to control and track the changes that occur during execution. Developing
schedule is a technique. It needs experience as well as knowledge of mathematics.
Sometimes complex algorithms can be used for time optimization.

Now let"s understand various processes and terms associated with scheduling.

Define Activity:

This process decomposes the work packages defined in WBS to manageable activity.
An activity is the smallest task that can be estimated, managed and performed by
one person. Por example, the work package could be to develop payroll module that
can be further decomposed to activity level such as table creation, screen
development, etc.

For each activity, attributes arc assigned. Activity attribute gives additional
information about the activity. For example, attributes could be person perfonning
the activity, instruction that need to be followed for the activity, etc.

Network Diagram:
All defined activities arc further shown in the Network diagram. Network diagram
is a graphical representation of activities. This diagram represents the sequence of
the activities as per their order of execution. Sequencing helps us to understand the
logical relationship between the activities. Network diagram also shows the activity
name, duration and precedence. The following diagram represents network diagram
consisting of five different activities along with their sequence.

99
4.3
})g
Network diagram can be drawn with different techniques. Most popular diagramming
techniques are Precedence Diagramming Method (PDM) and Arrow Diagramming
Method (ADM) and GERT method.

Precedence Diagramming Method (PDM):


This method graphically represents the scheduling activities. Activities are
represented by node (rectangles) and arrow represents the dependence that exists
between the activities. Usually activities arc presented by alphabets and are shown inside
the rectangle and the duration is shown above the rectangle as shown in the f'if:,rure.
5 3

}'ig 4.4
In the above networking diagram, Activity A takes 5 days, B takes 2 days and so on.

Arrow Diagramming Method (ADM)


This is another method to represent the scheduling activities. Unlike PDM, here
activities are represented by arrows, and nodes represent connecting points. Instead
of rectangles, here nodes arc represented by circles in order to differentiate with
PDM. The method is also called as activity on aiTow. The illustration below represents
a network diagram for activity on arrow.

Fig 4.5

100
Unit 4 Count your Steps: Estimating and Scheduling

With ADM we can show zero duration activity. Zero duration activities are called as
dummy activities and are usually represented by dashed lines. In the above figm e,
AD is a dummy activity. For example, to take sign of customer on requirement
document (SRS) is a dummy activity. This activity does not take much time or docs
not require any resource. It shows the dependency of other activities on dummy
activity. You cannot start design activity unless customer signs off SRS.

GERT Method:
GERT stands for Graphical Evaluative Review Technique. Sometimes schedules
need to be technically presented. Technical presentation shows loops and branches
between activities. You can show repeat process and if-then conditions with this
diagramming technique that is not possible with ADM and PDM.

The following figure illustrates that activity A can be repeated after completing
Activity B,

[jL.. _ A ,_A
_c_tt_.'"_ih__ _...J--- -•·1 Activity B

Fig 4.6
Types of logical relationships
The activities defined in schedule arc not totally independent. They arc integrated
with each other. For example, we cannot perform designing and coding in isolation,
we cannot start coding before the design completes. Such logical relationship helps
in sequencing the activity dependence. There arc four basic types of logical
relationships between activities described ac;; hclow:

Finish to Start (FS)


This relationship represents that predecessor activity must finish before the successor
can start. This is the most common relationship found across all projects. For example,
gather requirements activity need to he performed before design activity. This can
be shown as below.

DesignGather Requirements

}'ig 4.7

101
Project ~anagemcn t

Start to Start (SS)


Let's consider that you arc developing an ERP software and your team has only two
designers and 6 programmers. two designers cannot give their design at a time so
that six programmers can start coding. Till entire design is complete, do you allow
other programmers to wait? Not affordable. What you generally do is first complete
the design of an independent module and assign to the first pair of programmer who
can start coding and give the next design to remaining pairs. In the above scenario,
predecessor activity can be started before the successor activity.
Design

Coacting
Fig 4.8
Finish to }'inish (F}')
This type of relationship represents that predecessor activity finishes before
completion of successor activity. For example, user acceptance testing activity should
be finished before the completion of documentation. Once the documentation is
finished, you cannot again test.

Testing

1
IDocumentation I
Fig 4.9
Start to Finish (SF)
This rarely found relationship represents that an activity must stmt before successor
can finish.

Types of dependency:
We have seen various cases of logical dependence which tell us which activity
depends on the other. However, in real life to adjust the schedule, we need to consider
which activities arc really dependent and which activities cm1 be executed parallel.
This can be well understood by determining the type of dependencies. There are
three types of dependencies, let's understand them.

102
Unit 4 Count your Steps: Estimating and Schcdulin!!

Mandatory Dependency:
This is sort of compulsory dependency. For example you must dig before you plant
a tree. We cannot skip the first activity and proceed with second activity. This is also
called as hard logic dependency.

Discretionary Dependency:
In this type of dependency, team can decide the sequence of activity. At the discretion
of the team, sequence of activity can be changed. This type of dependency is used in
fast tracking to shorten the duration of the project. I 'or example in construction
project we can start furniture and electrical work simultaneously. The sequence of
activities based on priorities. The activities in this type of relationships arc
independent of each other. This type of dependency is also called as preferred logic
or soft logic.
External dependency:
These types of dependencies are influenced by factors outside the project, for example
if testing activity is outsourced, then debugging activity becomes dependent on
activities of outsourcing party. If outsourcing gets delayed, debugging activity gets
delayed.

Lead and Lags


Quite often we have to start certain activities earlier in the project, provided there is
no mandatory dependence. For example we can start the coding activity few days
earlier prior to the completion of the design activity. Lead represents the time between
the start of successor activity and start of precedence activity. 1-'or example. if design
activity starts on 1>l and finishes on lOth and if we start coding on 7m in the same
month, then lead is 7 days.

Lag is the waiting time gap between two activities that represent the amount of time
the successor activity can be delayed. For example after completion of SRS
preparation, we need to wait for SRS sign off and then only we can start design activity.
Here the time gap between SRS preparation and design activity is called as lag.

Developing Schedule
We understood what is network diagram and various terms associated with network
diagram. Network diagramming is the first step in scheduling; in scheduling network
diagrams are analyzed further. Network diagram only shows the sequence and
duration of the activity; however to assign and keep track of schedule. We need to
identify the start and finish date of each activity and total project duration.

103
Project Management

The next step after creation of network diagram is to analyze and determine the
planned start and finish date of activities. During analysis, we study whether activities
can be finished in a given time constraint. Schedule analysis based on mathematics.
The most widely used analysis tools arc critical path method, critical chain method,
what if analysis and resource levelling.

Critical Path Method


The critical path method is a mathematical tool used for schedule analysis. Schedule
analysis determines the duration of the project by analyzing the precedence of the
activities. This method determines the critical path. The critical path is the longest
duration path that ultimately determines the duration of the project. This method
identifjcs the sequence of activities that has the least amount of schedule flexibility.
Critical path method is activity oriented method that means it focuses only on the
activities and not on the availability of the resource. This method uses Porward Pass
and Backward Pass technique to calculate the float earliest start and finish time,
latest start and finish time.

Let's understand the basic concepts used in critical path method.

Path:
Path represents the sequence or route each activity follows from starting activity to
ending activity.

The following network diagran1 shows two paths as,


Path 1 - >Start-A-B-D-E-Pinish and
Path 2 - >Start-A-C-E-Finish

Forward Pass

.__________ _ __________ Backward Pass

Fig. 4.10

104
Unit 4 Count your Steps: Estimating: and Scheduling

Duration of Path:
Duration of path is the amount of time each activity on the path takes to complete.
Path is calculated by adding duration of each activity on that path. Generally Durations
are shown above rectangles. Thus duration of path 1 is 14 (2+3+2+7= 14) and duration
of second path is 17 (2+8+7). From comparing the duration of two paths, we can say
that path 2 is longest path.

Critical path
The longest duration path is called as critical path. In the above figure, path 2 (Start-
A -C-E-Finish) is the critical path. The activities on critical path arc not flexible,
hence path with zero flexibility is also called as critical path. This pat.h is important
because if everything goes according to schedule, its length gives the shortest possible
completion time of the overall project. The critical path determines completion of
the project in a given time. The total time project will take depends on the critical
path. If critical path activities get delayed. project gets delayed; however project
duration will not be affected if any activity gets delayed on non-critical path. Hence
while scheduling, critical path becomes important and the activities on critical path
need to be managed properly. If you are able to manage activities on critical path
and complete within estimated time, your project will finish in given time.

:Float (Slack)
Float is the amount of time an activity can be delayed without delaying the project
end date. Float is also called as slack. Activities on the critical path always have
zero t1oat because as the duration of critical path decides the total duration of the
project, delaying a single activity on critical path will delay the project. In any project
certain activities are critical and certain activities arc flexible. ·w ith float, we can
determine the activities that can be delayed without delaying schedule. Identification
of non-critical activity will help you in assigning resources. For example, your team
may not always have experienced resources. Sometimes you need to usc less
experienced available resource. In this case, if you know critical and non-critical
activity, you can assign less critical activity to less experienced resource so that
your project schedule will not get delayed.

Float is calculated as Float = Late Start - Early Start or }'loat = Late :Finish -
Early Finish

Early Start (ES)


Early start determines how early an activity can start. Forward pass technique is
used to calculate the early start of each activity on schedule. In forward pass, the

105
Project Managc:ment

duration of activity counted from the start activity, for example in the above figure
the early start of activity Dis calculated as (Start-A-B = 0+2+3=5) means activity D
can start in the 5l" week.

Early Finish (EF)


Early Finish determines how early an activity can he finished. The same forward
pass technique is used for calculation of early finish. Early finish is calculated as
early start + duration of that activity, for example duration of activity D shown in
the above figure is 5+2=7 since activity D can start on Y" and it takes 2 weeks to
complete the activity.

For better understanding, result of calculation can be written above each activity.
Duration

ES I
Activity
Float

Fig 4.11
Late Finish (LF)
1,ate Finish determines how late an activity can be finished. The method to calculate
late start is opposite to forward pass and is called as backward pass. The backward
pass uses the duration of the critical path as the late finish oflast activity or activities
(There can he more than one activity at the end of the network diagram). In fig 4.10,
E is the last activity and as the duration of critical path is 17 activity E, can finish as
late as on 17.

Late Start (LS)


Late start determines how late an activity can be started. This is calculated as latest
finish time minus the duration of activity. For example, in fig 4.10, the last finish of
activity E is 17 and duration is 7, thus the late start of activity is calculated as 17-
7=10.

106
{;nit 4 Count your Steps: Estjmating and Scheduling

Float Calculation

Float of activity C can he calculated as:


First calculate the early start and late start of Activity C,
Early start = 2
Late start = 2
Float = I .ate Start - Early Start Substituting values we get,
Float= 2-2 = 0
Float of activity D can be calculated as,
First calculate the early start and late start of Activity D
Early start = 5
Late start = 8
Float = Late start - Early Start Substituting values we get
Float= 8-5 = 3

4.5 SUMMARY

In this unit, we discussed overall time management process, the importance of time
constraint in project management. We also understood the meaning of the terms
software size, effort and its measurement. Now we understood why it is challenging
to find out the unit of measurement for software. Even if we find out the units of
measurement, it is difficult to generalize them for measuring the software size or
effort.

We also discussed several size estimation techniques such as LOC, which is the
basic estimation technique but has several drawbacks, Function Point which considers
the functional complexity of the software and independent of language. We also
discussed effort estimation technique COCOMO in detail. Based on complexity,
COCOMO model is further classified as organic, semidetached and embedded.

In the schedule development, we understood various network diagramming


techniques such as Arrow Diagramming and Precedence Diagramming. We have
also seen how the activities arc dependent on each other and their type such as start
to start, start to finish , etc. Scheduling analysis is one of the important tools which

107
Project Management

mathematically determines the critical path which has considerable impact on the
schedule of the project. In the Critical path method, we studied how to calculate
early & late start and finish dates, float and critical path of the schedule.

You should also understand the importance of scheduling, tracking the schedule
deviations and taking appropriate measures to take care of the deviations. Time
management should not be misunderstood as merely making the estimations and
schedules. It is a continuous activity of monitoring the activities on hourly basis,
motivating the team members to follow the schedules and changing the path if
required to meet the deadlines.

4.6 SELF-ASSESSMENT QUESTIONS


1. Explain the importance of Software size.

2. Explain various techniques used to measure software size.

3. Discuss the advantage of function point over LOC.

4. Compute the function point value for a project with the following information:

Number of user inputs: 32

Number of user output<>: 60

Number of user inquiries: 24

Number of files: 8

Number of external interfaces: 2

Assume that the complexity adjustment values are average.

5. Using COCOMO model, calculate the effort, duration, no. of persons,


productivity of a project. Consider the project is simple and of size 250 KLOC.

6. The programmer has given pessimistic (P) estimate as 8600, optimistic (0)
estimate as 4600 and most likely (M) estimate as 6900 to complete the given
programming assignment. Calculate the average estimate using 3-point estimate
technique.

108
Project Management

5.1 INTRODUCTION
fn software project time management unit we studied how to measure the size of the
software and now we arc able to estimate the effort required to deliver the project.
You arc now familiar with the time management concepts such as activity, duration,
WBS and schedule. Understanding of these conceptc; is prerequisite for managing
cost. Cost is one of the other important constraints that each project manager has to
control. It is the prime responsibility of the project manager to manage the project in
the given budget. Project sponsor/customer approves the tentative budget in initiation
stage; however the detailed scope may not be available at the time of approval of
tentative budget. While project scope detailing, some changes may occur in scope
and will have impact on the initial budget.

Most of the disputes and conflicts may arise due to weak management of cost. To
avoid the cost related conflict-; in future one must analyze whether he can execute
the project within given scope and cost budget. Accordingly project manager informs
the project sponsor/customer whether he can carry out the project in the given budget
or may require more funds .

You might think that cost management is a one time activity, but in reality due to
dynamic behaviour of software various changes may occur in different stages of
development. These changes will affect all the plans, schedules and budget; hence
cost management becomes an ongoing activity and need to be performed throughout
the project.

In software development projects, major costs arc the cost of resources, training
cost, travelling cost, hardware upgradation and software licensing cost. As the project
size increases, cost management becomes more rigorous.

Software professionals are expert in technology than to financial aspect of a project


management. Lack of financial knowledge may result in misinterpretation of the
cost estimates causing cost conflicts. Thus it is imperative for us to understand the
basics of cost management. In this unit, you will learn various financial aspects of
the project management. This unit covers the basics of cost management & will
generate the cost awareness and understanding of fundamentals essential for effective
project cost management.

In most of the software industries, there arc specific costing and financial
professionals who look after the cost management aspect of the project. Still
understanding of cost management is not an exception for software project managers
and you must have a clear understanding of the process of cost estimation.

112
Unit 5 Time to Spend: Managing Quality

5.2 COST MANAGEMENT OVERVIEW


In software projects, cost is inherent, non-negotiable, and depends on the scope.
However, since work-time estimates can be negotiated, we do not get an accurate
picture of the cost. When the worker knows that the work-hours will be negotiated
by the boss, slhe pads the estimate to cover up unforeseen delays. (Padding means
adding extra time in estimation). Knowing that the estimate is padded, project
managers try to reduce time estimation as low as possible. Here, both (PM and his/
her team) miss out on the point- that estimates have to be based on facts, not on the
negotiation skills of two parties. Both need to understand that costs cannot be
negotiated; they are the expenses necessary to get the work done.

Most of the concepts used in cost management are based on the financial accounting
and cost accounting.

Basics of costing

Before proceeding into cost management, we must understand various financial


terms such as cost, price, estimate, budget etc.

What is price?

In general terms, price is the result of an exchange or transaction that takes place
between two parties and refers to what must be given up by one party (i.e., buyer) in
order to obtain something offered by another party (i.e .. seller).

Yet this view of price provides a somewhat limited explanation of what price means
to participants in the transaction. In fact, price means different things to different
participants in an exchange For example, price is commonly confused with the notion
of cost as in "I paid a high cost for buying my new mobile handset". Technically,
though, these are different concepts, price is what a buyer pays to acquire products
from a seller. Cost concerns the seller's investment (e.g., development expenses,
manufacturing expense) if the product is being exchanged with a buyer. For marketing
organizations seeking to make a profit, the hope is that price will exceed cost so the
organization can see financial gain from the transaction. In this unit we are mainly
focusing on the cost management of the project and not the price.

What is cost'?

A cost is a resource sacrificed or forgone to achieve a specific objective. A cost is


the value of money that has been used up to produce something or simply we can

113
Projl!ct Management

say that expenses incurred to carry out the task. Por example, the amount paid to the
programmer for coding, amount invested in hardware and software setups, amount
paid for documentation, amount paid for implementation and training, etc.

In a project we perform various tasks and the cost is associated with each task.
There is no any task having zero cost. Few tasks & cost we can share among multiple
projects. Cost takes various forms and hence is further classified into various types.

Classification of costs:
Costs arc classified into various types such as fixed cost, variable cost direct cost
and indirect cost.

Let's understand various types of cost.

Fixed Cost: Fixed costs are expenses that arc not directly dependent on the activities
of the project. They tend to be time-related, such as office rents being paid per
month. Fixed costs defined as expenses that do not change in proportion to the
activity of a project. That means you have to pay full rent irrespective of the no. of
hours you utilized the office. Other example could be the cost of hardware and
software setup. While costing, some % of the total fixed cost is applied to total cost
of the activity. Policy to apply proportionate fixed cost varies with organization.

Variable Cost:

In contrast to fixed cost, this cost varies in proportion to the activities of the project.
Duration and type of the activity decides the cost. for example hours spent on coding,
hours spent on testing. In this example, the hourly rate varies with the types of
activity and the rate of resource performing the activity.

Direct Cost:

Quite often project incur direct expenses such as fees paid to external consultant or
bought special equipment for the projects, etc. are billed directly to the project.

Indirect Cost:

lndirect costs are expenses that can be shared and allocated across all projects. For
example salary of senior project manager who is managing multiple projects. The
total cost of the project can be calculated by adding all the above costs. However,
the proportion of each cost type is decided by the management. As a software project
manager, you must be able to identify and estimate various costs. Before presenting

!!4
Unit 5 Time to Spend: Managing Quality

final cost estimate, project manager should consult with financial expert & the project
to ensure the accuracy of his estimate.

\Vhat is project cost management?

Cost management deals with the controlling project resources to perform within
agreed budget. Cost management is a three step process. In step one cost of each
scheduled activity is estimated, in step two the aggregate budget for overall project
is prepared. These two steps arc performed in project planning stage while the third
step is cost controlling which is performed throughout the project. Project cost
management includes the processes required to ensure that the project is completed
within an approved budget.

Each organization has its own cost management policy that deals with specification
of estimation methods, level of accuracy of the estimate, rules for measuring cost
performance, etc. Project manager must know & very well understand the cost
management policy before proceeding further. As projects are unique in nature, no
one can accurately estimate the total final cost of the project at the beginning of the
project. Software project budgets are the integral part of business strategy and top
management need to know the funding requirement of the project well in advance.

Depending on the needs of the organization, the project manager has to estimate the
cost for various purposes. He has to select the appropriate estimate type.

One of the widely used estimation type is order of magnitude which is usuaJly
prepared during project initiation phase. Order of magnitude estimation may vary
from -50% to+ 100% that means if your order of magnitude estimate is 100 USD,
then actually it can vary from 50 to 200 USD.

Conceptual estimates range from -30% to +50%. Preliminary estimates may range
from -20% to +30%, definitive estimates range from -15% to +20% and control
estimates range from -10% to +15%. These arc basic five estimation types based on
the accuracy of the range.

Project cost estimating is usually performed by summing estimates for individual


project elements into a project total. The pieces can vary in size and number from a
few large chunks of a project with known costs to hundreds or thousands of discrete
tasks or individual work packages. The main outputs of the cost estimating process
arc cost estimates, supporting details and cost management plan.

115
Project Management

The best way to estimate project cost is to prepare a detailed project schedule using
Microsoft Project (or a similar tool), and to use the resource management features
of that software to identify the types, quantities, and phasing of different types of
labour.
If you estimate only the requirements you are sure of, your estimate will usually he
low. If your estimate for the number of source lines of software is uncertain, you
may want to add an uncertainty factor to the estimate (15-35%). It is wise to add a
contingency factor to compensate expected changes, or to allocate management
reserves to deal with unforeseen event.
Cost estimates are done for different reasons, and the purpose of the estimate usually
imparts a basis to the numbers. ''Marketing estimates'' arc likely to be low, while
good "budget estimates·· are likely to be high. When judging the accuracy of an
estimate, you need to know the source of the estimate and the purpose for which it
was derived. Cost estimates that hinge on assumptions about staff or asset
availabilities or schedule dependencies outside the manager's control should be
considered areas of cost risk and managed accordingly.
As a project manager, you need to understand if your cost estimates are sound or if
you arc buying into an inevitable cost overrun due to under-estimating. The adverse
consequence of a cost estimate that is too conservative is that it can kill an otherwise
viable project by making it look unaffordable.
Good cost estimating requires a supportive environment in the organization. One
way to help this is to develop projects using standard work breakdown structure
categories, and then collect actual costs in a historical cost database. A cost database
for software, for instance, could be used to collect data related to cost per line of
code, software sizing algorithms, costs for function points, or cost data from bottom-
up functional descriptions and tasks.
A well-structured cost estimate can become unmanageable after the third or fourth
"what-if' iteration unless each change is meticulously documented. Even after
knowing this fact well. experienced cost estimators arc constantly reminded of it
when trying to reconstruct or explain cost estimates that were prepared some months
or years back. It seems that one can never document a cost estimate too well or
record assumptions too thoroughly. An aid to this process is using a PC spreadsheet
to prepare your estimate, and then keeping all the important data and adjustment
factors visible in cells, rather than hidden in formulas. If the assumptions, risk factors,
and data sources arc not obvious in your cost estimate documentation, then it is not
done yet.

116
unit 5 Time to Spend: Managing Quality

lypes of costing
You should also know two more concepts namely Life Cycle Costing and Value
Analysis. These two concepts are related to cost management and understanding of
them will help you in taking cost related decision.

Life Cycle Costing


Product life cycle and project life cycle arc two different things. Every product goes
through various stages during its life. These stages arc called as life cycle phases.
Product life cycle begins with concept exploration & goes through various stages
such as requirement. design, implementation, installation, operations & support,
maintenance and finally product becomes obsolete called as retirement stage. In life
cycle costing. the cost of whole life of the product wi11 be taken into consideration.
For example, you can estimate project without considering more time for design
reviews, here you may cut down design review cost but during maintenance you
may have to pay extra cost due to poor design. Ultimately the whole cost of the
product remains same. As a project manager, you need to focus on all aspects before
giving final cost estimation.

Value Analysis
Value analysis is sometimes refened to as value engineering. It involves finding a
less costly way to do the same work. Value analysis requires the systematic use of
techniques to identify the required project functions, assign values to these functions
and provide functions at the lowest overall cost without loss of performance. If a
team is looking at decreasing project cost but maintaining the same scope, they are
performing value analysis.

Value engineering is the practice of trying to get more out of the project in every
possible way. Value analysis improves the "value" of goods or products and services
by using an examination of function. Value, as defined, is the ratio of function to
cost. Value can therefore be increased by either improving the function or reducing
the cost. In value engineering, the basic functions be preserved and not be reduced
as a consequence of pursuing value improvements. In most cases, this practice
identifies and removes unnecessary expenditures, thereby increasing the value to its
customers.

117
Unit 5 Time to Spend: Managing Quality

6. Explain the concept of value engineering.

7. Explain the concept product life cycle management.

Estimating cost:
It involves developing an approximation or estimate of the costs of the resources
needed to complete a project. Project cost is the total cost of the project. The project
cost is calculated by aggregating cost of all individual activities performed in a
project. For estimating cost of the project, we need to breakdown the projects into
smaller manageable activities. We studied how to decompose project activities using
WBS (Work Break Down Structure). Once you create WBS, you need further details
of each activity & duration of activity so that you can calculate the effort required to
accomplish that activity. For example, to design a payroll module, you need 120
hours of java programmer. Here you can calculate the cost of the activity by
multiplying effort to hourly rate of java programmer.

Effort estimation is a prerequisite to the cost estimation. In software projects, major


portion of cost is consumed by the effort a human resource puts to deliver that task.
Accuracy of the effort determines the accuracy of the cost estimate; hence more
emphasis is given on the effort estimation. To ensure the correctness in effort
estimation, we studied various empirical models such as coco~o in time
management unit.

119
Project Management

Estimating cost for an activity is relatively simpler than effort estimation and
calculated as multiplying effort in hours by hourly rate of the human resource
performing the activity. Every organization follows different practices for rate
determination, for example some organization may take actual rate (is the rate of
the current salary rate of specific resource of that organization) of the human resource
and others may take standard rate (based on market conditions and salary surveys).
You may think what the great deal in estimating cost is; however in reality you need
to take into consideration lots of other factors such as constraints and assumptions,
potential unknown risks, etc.
For accurate estimation you need to think in advance about every aspect of the
project. Since estimations arc given prior to project execution, you may not have
complete information at hand at the time of estimation. As the project progressively
elaborates. you will have more confidence about the estimate.
Few documents such as project scope statement, work breakdown structure, WBS
dictionary, cost management plan, etc. need to be considered while doing cost
estimation.
Knowing how to estimate cost is not just enough. Depending on type of the project,
you need to select methodic approach to estimate cost of an activity. For large projects
where thousands of activities are pcrlormed by hundreds of human resource, you
can usc project management software such as Microsoft Project where you can
easily record WBS, Resource information. These tools provide you ample utilities
such as resource calendar where you can check the availability of resource, various
rate options such as hourly rates, monthly rates. one time consulting charges, etc. In
large projects, costs arc being managed at the control account level and not on small
individual activity level. For simplicity of understanding, we can say that control
account is the main group activity and all other related sub activities are grouped
under that control activity. For example you can have coding as control account
which can consolidate the individual coding activities.
Cost of Quality is one of the other important factors that need to be considered
while estimating. We will study more about cost of quality in the Quality Management
unit. Cost of the quality is the cost that will be released in order to achieve quality.
In contrast to this, the cost of the items that are not conformant to quality standards
are known as "Cost of poor quality".
Tools & Techniques for estimating costs
Tools arc the methods or procedures that you can use for simplifying your jobs. Few
commonly used estimation tools arc analogous estimation, bottom up estimation &
parametric estimation and reserve analysis.

120
Unit 5 Time to Spend: Managing Quality

Bottom up estimation
Bottom-up estimating involves estimating individual work items and summing them
to get a project total. Bottom up estimation is an extremely useful & widely used
technique for cost estimation. The technique works on the individual activity level
and thus provides more refined estimate of the particular component of the project.
In this tcclmique, each activity is broken down into smaller tasks and then each
individual task estimates are developed to determine what specifically is needed to
meet the requirements of each of these smaller components of the work. The estimates
for the smaller individual components arc then aggregated to develop a larger estimate
for the entire task as a whole. In doing this, the estimate for the task as a whole is
typically far more accurate, as it allows for careful consideration of each of the
smaller parts of the ta-;k and then combining these carefully considered estimates
rather than merely making one large estimate which typically will not as thoroughly
consider all of the individual components of a ta-;k.

Bottom up estimate provides more accuracy and involves the team who is performing
the actual task. It has few disadvantages such as it takes more time since it works on
the detailed analysis of individual task. Involvement of team can cause overestimation
since team members usually add extra time to their estimates.

Analogous estimation
Analogous estimation, also called as top-down estimates, is a technique for estimating
a variety of project parameters and measures of scale. The project parameters that
can be measured include those of project cost, project budget, scope of the project,
and expected project duration. The project measures that can be estimated using this
technique can range from the size of the project, to the project weight, to the
complexity. The estimates arc made by comparing the current activity to that of a
smaller activity that took place previously and drawing comparisons in proportion
to that. lt is frequently used to estimate the size of a particular parameter when
information as to that particular parameter within the current project is limited or
unavailable until a later date. Analogous estimation is typically a form of expert
judgment that is most reliable, not only when the previous activities are similar to
the current activity not just in appearance, but also is traditionally most effective
when the team members preparing the estimate have the expertise necessary to
accurately do so. Analogous estimates technique uses the actual data of previously
done projects of similar nature. Analogous estimates arc typically easier to use and
the accuracy of the estimate depends on how similar the two projects actually are.

121
Project Management

These estimates arc more reliable when the previous projects arc similar in fact and
not just in appearance. Analogous estimates are less costly to create since you have
most of the data from the previous project in hand, only you need to properly compare
the task of the current project with similar task of previous projects. It needs good
understanding and experience to relate the task. Disadvantage of analogous estimate
is that, as two projects are not exactly similar, it becomes difficult to compare.

Parametric estimation
Parametric estimation is a technique that is essential for any project management
team and/or project management team leader to become comfortable with using, as
the use of parametric estimating provides an invaluable service in the course of the
project. A parameuic modelling provides an estimate of per line of code for a software
development project based on the programming language of the projects using the
level of expe1tisc of the programmers, the size and complexity of the data involved.
Parametric estimating refers, primarily, to an estimation technique which utilizes
the statistical relationship that exists between a series of historical data and a particular
delineated list of other variables. Some examples of tl1ese variables are the number
of lines or code that exists in a software application, and other similar variables.
This information is then implemented for the purposes of calculati ng and
demonstrating an estimate for the entity of activity parameters. One valuable aspect
of parametric estimation is the higher levels of accuracy that can be built into it,
depending on how sophisticated the original data is. Parametric estimates work best
when the project being undertaken is highly similar to previous projects and there is
significant historical information available within your organization.

~Activity B:

I. Explain the cost estimation process.

2. What information do you require to estimate cost?

122
Unit 5 Time to Spend: Managing Quality

3. Explain various tools & techniques that you can apply to derive the cost of the
project.

4. Explain the advantages of bottom-up estimation.

5. What factors do you need to consider while doing cost estimation?

5.3 PREPAREBlJDGETOFTHEPROJECT
As a project manager, it is your prime responsibility to prepare project budget and justify
the same to the top management in case of budget conflicts. PM is also responsible for
managing project in the given budget. Hence you must thoroughly understand the basic
concepts of budgeting.

What is Project Budget?


Budget is nothing but a list of all planned expenses. It is a plan desctibing how you are
going to spend money over time. We can also say that budget is time-phased allocation of

123
Project Management

money. In other terms, a budget is an organizational plan stated in monetary terms. The
purpose of budgeting is to provide a forecast of expenditures, i.e. construct a model of
how the project will perform financially and how certain activities of the project and plans
are carried out. Budget also enables top management to measure the actual financial
performance of the project against the forecast.

Budgets arc generally prepared in the planning stage of the projects. Certain information
needs to be at hand before preparing the budget. For example, cost estimates and project
schedule & risk management plan. Budget is not just the total cost of the project. I 'unds
arc usually relea~;ed in time pha<>es. For example, your projects need to setup high capacity
hardware at the time of implementation, then while budgeting the amount of hardware
setup cost is shown along with when that cost is required. Funds to procure new hardware
are only released prior to the actual procurement of new hardware.

Cost Budget

I Management reserve I
Cost Baseline

I Contingency reserve I
Project Estimate

Control account
estimate

Work package
estimate

Activity Estimate

}'ig. 5.1

124
l:nit 5 Time to Spend: Managing Quality

How cost aggregation is used to prepare budget is shown in the above figure. First, all
activity level estimates arc calculated. These activities are further grouped to work at
package level, for example, your work package could be to develop payroll modules
which include three activities such a<> analysis. design & coding. You can have no. of work
packages in a project. However, to manage cost at individual level is difficult, hence control
accounL<> are created. These control accounts further control individual work packages.
You can define coding, design, testing as control accounts. The summation of all control
accounts will give you the total cost of the project. After tllis, contingency reserves arc
added to the cost of the project (Please see below for the detailed explanation of reserve
analysis), that will give you the cost baseline of the project. The term, ba-;eline used here is
a tool to measure how the performance of the project deviates from original plan. All
known risks are generally covered in cost baseline however to handle unknown risk,
some management reserves arc set aside to mitigate unknown risk. Adding management
reserve to cost baseline will give you the total budget of the project. In budget, along with
the cost, the expected date on which fund will be utilized is also shown.

Reserve Analysis
Reserve analysis is a tool used in budgeting for managing the risk. Almost all projects
maintain a financial reserve to protect them against cost overrun. In real life, project
budget may exceed. There could be various reasons for budget ovenuns such as a
key person leaving the project, new teclmology is not completely understood which
can delay your project. Hence while budgeting you should take enough care of the
potential risk and make necessary arrangernent of managing that risk. You cannot
mitigate risk if you don't have sufficient fund in hand. To avoid such circumstances,
it is wise to make arrangement of reserve funds. Two types of funds can be added
such as contingency reserve and management reserve.

Contingency Reserve
The term contingency reserve refers primarily to the amount of quantity of funds or
other financial resources that is required to be allocated at and above the previously
designated estimate amount to reduce the risk of overruns to an acceptable level for
the financially responsible organization. However, contingency reserve need not
refer exclusively to monetary terms. It can also refer to a specific quantity of time in
man hours that must be allocated above and beyond the previously determined
quantity of hours required to assure that any overtime or other unexpected hours of
work required, can be properly compensated for. Typically the contingency reserves,
in terms of both finance and time, are determined at the outset of a project. However,
as a project is ongoing, if it appears tl1at the project will require additional funds or time

125
Project Management

allocation to complete, contingency reserves can be instituted or modified at any time to


better prepare the organi7.ation for the possibility of their usage at some point in a projects
life.

Management Reserve
Management reserves arc any extra funds to he set aside to cover unforeseen risks or
changes to the project. The difference between contingency reserve and management
reserve is that, contingency reserve will take care of any known risk that arises for example
suppose one of your key person leavcs job then you can arrange another person for that
you may have to pay extra time & cost However in real life certain things about which we
can not predict that it will happen also called as unknown risk. Such unknown risks have
considerable impact on the project. For example, you cannot predict that flood or
earthquake will destroy your hardware or attack of unknown virus that can potentially
damage your source data. Nowadays floods, earthquakes are considered as known risks
and most of the organization keep contingency plan ready.

How to prepare a budget


The most basic cost control technique is to develop a project budget and then track
spending against it. On a small project, this can be as simple as having a target cost
goal for the total project. You could monitor project costs and sound the alarm if the
percent of dollars spent exceeds the percent completion estimated for the project.
You could also prepare a time-phased budget, as shown in the figure below, breaking
the overall budget goal into intervals of weeks, months, qua1ters or years. This can
provide a budget baseline for tracking actual costs against periodic budget targets.
When the cumulative budget of estimated project costs are plotted graphically over
time, they usually result in the shape illustrated, which is sometimes called an "S"
curve, since it looks like an inclined "S.''

Budget Spend Plan Tracking:


A simple technique for tracking project costs is to develop a weekly or monthly
cumulative budget spend plan and then track actual costs against the plan. The slope
of the spend plan indicates the project expenditure rate, sometimes called the ''bum
rate.'' By plotting actual costs against the budget spend plan, you can see differences
between actual spending and the spend plan. This technique provides a simple, top-
level view of project financial performance that can he useful ror executive briefings,
especially where you want to match expenditures to a funding stream.

126
Cnit 5 Time to Spend: Ylanaging Quality

l Management
Budget
Ceiling
i RCSI.lfVC

;
;
/, '-.__ Spend
/ Plan
/.
Dollars
/
/
/
/
/
/ ..___ Actuals
;
;
;
;
~~"
~~~

Months
Fig. 5.2
The spend plan can be generated using a project management software tool. This can also
be used to establish a performance measurement baseline of the budgeted cost of work
scheduled. If the project is on schedule, the spend plan method provides the needed
budget status information. If the project shown were behind the schedule. the project
manager would no longer be able to understand project status from this graph. The budget
picture would be worse than it looks. but it would be impossible to quantify.

When a project is sufficiently large or complex tl1at it is unclear which project clements arc
contributing to deviations from the budget plan, a more rigorous approach to cost and
schedule tracking should be employed. This following method links cost and schedule
performance together and presents them in a form tl1at facilitates management analysis and
presentation.

~Activity C:

l. Explain the importance of reserve analysis.

127
Project Management

2. Explain the importance of budget.

3. What information do you need to prepare the budget?

4. In which situation will you utilize contingency reserve? Explain with example.

5. Explain how cost aggregation process works.

5.4 CONTROLLING COST OF SOFTWARE PRO.JRCTS

Once the estimation & budgeting task is over, your project can start actual execution
& utilizing the fund allocated. The main objective of any successful project is to
complete the project in the given budget. In reality, cost tends to deviate from the
budget & you need to control the cost of the project. Controlling cost of the project

128
Cnit 5 Time to Spend: Managing Quality

is not a one time activity; you have to frequently check whether your project is on
the track. The frequency of checking usually depends on complexity & size of the
project, however usually during the planning phase, cost controlling takes place
monthly & in the execution phase, it can be performed weekly. As a general rule,
cost controlling process is performed when maximum portion of the project budget
is being utilized. Controlling processes measure what was executed against what
was planned. If the results arc deviating from the cost baseline. then appropriate
action needs to be taken to bring back the project on track.

Controlling is one of the measure functions of project management. Project cost


control includes monitoring cost performance, ensuring that only appropriate project
changes arc included in a revised cost baseline and informing the project stakeholders
of authorized changes to the project that will affect costs. In a project cost
management, focus is on cost controlling. Controlling is an integrated activity, for
example one of your team members is not performing well on the given task, then
cost controlling point of view you have to take corrective actions, you need to analyze
why this team member is not performing well. There could he various reasons such
as lack of interest & motivation, lack of understanding, lack of communication,
other HR related problems. The controlling process in such scenario interacts with
the HR & communication management. Control can be established by using various
tools such as progress reporting, performance measurement analysis, performance
reviews, forecasting, variance management, meetings, etc.

Cost controlling techniques:


We will study two most commonly used cost controlling techniques such as progress
reporting and earn value management.

Progres..~ Reporting:
The progress reporting tool is usually used for controlling time & cost of the projects.
The progress report is a very comprchensive document that describes what was the
original plan, what is the current status of the project & the direction & corrective
actions for future activities. It helps to track the rate at which work is being completed
(productivity) and the quality of work being done.

Many project managers determine how much work has been accomplished by asking
team members for an estimate of% completed for each activity they are performing,
however % will not give the exact status of the work being performed. The process
is also time consuming. If your project is p1anned as per WBS, then instead of
percentage you can use some thumb rules as below.

129
Project Management

Activity Completion Rule: By crediting different figures for activity beginning and
completion you can measure the progress of project activities. Usually 50/50, 20/80
or 0/100 figures arc taken for measuring the progress. For instance, as soon as an
activity begins. activity gets credit of 50 & only after completion, activity will get
full credit of balance 50. There is no credit in between the percent. Either you can
say that an activity was started and fully completed. Depending on the project, you
can decide what Of needs to be given to begin an activity and complete an activity.
Instead of just relying on the percentage & guess work, you can usc one more effective
tool to control the cost of the project. The technique is known as Earn Value
Management technique (EVM). This technique uses various formulas. Earned value
management is a project pcrformmtce measurement technique that integrates scope,
time and cost data.

Earn Value Management:


If your budget spend plan shows you are over spending and your schedule shows
milestones slipping. you can know that you may be in trouble, but you will have no
way to make a quantitative assessment of how bad the trouble is. EVMS solves this
problem by providing an accurate picture of spending and accomplishments related
to a baseline plan. This enables you to quickly form conclusions about the project
team's staffing levels and productivity, as well as giving an insight into areas of the
WBS where the problems arc occurring. Earned Value Mm1agement provides an
integrated view of cost and schedule performance.

Budget at Completion (BAC):


This defines the original total cost of the project. for example, your original budget
for developing an application could be $130 which includes activities such as dataset
design, interface design, coding and testing.

Planned Value (PV):


How much work you planned to have accomplished by now (in dollars or hours) is
called the Planned Value. It is the total direct and indirect cost incurred in
accomplishing work on activity during a given period. For example. to complete
one module as on today cost<> you 100$ which includes activities such as database
design. interface design & coding to be finished by today. For each activity you
allotted. some value lets say 30$ for database design, 20$ for interface design and
50$ for coding then your planned value is 100$. That means if you complete all
three activities today. you will earn 100$. Ofcourse this is a plan & it may or may
not happen.

130
Unit 5 Time to Spend: :vtanaging Quality

Earned Value (EV):


You planned that by today your team wJII finish all of the three activities of the
project but in reality your team only finished database design activity. That means
from th~ planned value example, we can say that the project only earned 30$ value
from database design activity. Earn value describes the value of the work actually
accomplished.

Actual Cost (AC):


Actual cost is nothing but the actual $ you spent on performing the activity. Though
ideally planned value and actual cost should be the same. in reality they are not
same. Sometimes you may spend extra or less. Suppose that your team takes 10%
extra time than planned, then your actual cost will exceed by l 0% for that activity.

Cost Variance (CV):


Cost variance is the difference between what we expected to spend and what was
actually spent and calculated as CV = EV- AC, for example, you expected that cost
of database design is 30$ but you actual spend 40$ so the cost variance will be 30 -
40 = -10. Negative variance indicates that your project is not performing well on the
cost (i.e. project is running over budget) while positive variance indicates that the
project is under budget.

Schedule Variance (SV):


Schedule variance is the difference between where we planned to be in schedule
and where we arc actually in schedule. SV is calculated as SV = EV - PV. In the
above example, you planned that the team will finish all three activities (database
design, interface design, coding) but as on date, team only performed database design
activity. From the database design activity. the project earned 30$ value hut planned
value was 100$ thus your schedule variance is SV = 30 - 100 = -70. Here negative
value indicates that project is not performing well on the schedule. Project is lagging
behind the schedule. It may happen that cost performance is not performing well on
cost but perfonning well on the schedule. By increasing resources, you may finish
all activities as per the plan but it will increase the cost due to extra resources.

Cost Performance Index (CPI)


It is the ratio of earned value to actual cost. The cost performance index indicates
the rate at which the project performance is meeting the cost expectations during a
given period of time. This is calculated as CPI = EVI AC . In the above example, EV
is 30$ andAC is 40$, thus by substituting values we can calculate CPI as 30/40=0.75.

131
Project .'vlanag..:mcnt

Schedule Performance Index (SPI)


It is the ratio of earned value to planned value.
SPI indicates the rate at which your project is perfom'ling on schedule and calculated as
SPI=EV/PV, the SPI of the project desctibed in the above example is,
SPI=30/100=0.3.
Estimate at Completion (EAC):

It is an estimate of what it will cost to complete the project based on peJformance to


date. This estimate should not be confused with BAC since this estimation takes
place during project execution while the BAC is estimated before execution. Based
on the performance of the project on current date, the EAC need to be re-estimated.
EAC will tell you how much estimate do you require from current day onwards to
complete the pending activities of the project

This can be calculated as EAC = AC + (BAC - EV)


In the above example, BAC is 130$ out of which only database design activity was
over. Hence we earned only 30$ value while we spent actually 40$ to complete the
activity. Hence the new estimate to complete the project will be RAC = 40 + ( 130 -
30) = 140$. Here the new estimate increased due to more time taken by team in
database design activity.

Estimate to Complete (ETC):

This will tell us how much more we wi1l spend on the project. This is the difference
between new estimate and actual spend. Putting values, we will get figure ETC=EAC-
AC= 140-40= I 00$.

Analysis of Earn Value:

All the EVM basic calculations involve differences or ratios with respect to Earned
Value.

You can figure out what is subtracted from what by remembering that positive
variance is favourable (good) and negative is unfavourable (had).

You can figure out what is on top of an EVM ratio, by remembering that > 1 is
favourable and <1 is unfavourable.

If you have good productivity and slow progress, then you arc understaffed.

132
Cnit 5 Time to Spend: Managing Quality

lf you have low productivity, then either you have too much unplanned work or you
have estimated poorly and the project has more work content than you thought.

Earned Value Implementation (Informal Approach)

To determine earned-value performance measurements for your project, you need


to accomplish four steps:

1. Establish a performance measurement baseline in dollars (or hours) (this will


determine the "budgeted cost of work scheduled" for the life of the project);

2. Determine "earned value" for work accomplished to date (earned value is the
''budgeted cost of the work performed");

3. Relate earned value to the budgeted cost of work scheduled; and

4. Relate ·'actual cost of work petformed" to earned value.

These four steps provide data to present a comprehensive picture of project cost and
schedule performance.

Implementation of such a process can be scaled to fit projects of varied size and
complexity. One should select the appropriate level of the WBS for data gathering
and appropriate means for determining earned value. This can range from a few top-
level categories where earned-value is determined from percent completion estimates
to projects where earned value determination is pre-planned based on the assignment
of dollar values to completion of specific milestones or subtasks within tasks.

After the performance measurement baseline is determined. project status should


be evaluated to assess earned value for tasks in progress and completed. Rules for
determining earned value for each work package may be established during initial
costlscheclule control system implementation.

Earned Value Management Example:

Consider that you are the project manager and working on a software project
comprises of major four activities such as Analysis, Design, Coding & Testing. The
budgeted cost of completion is 100$. The following figure illustrates the various
tasks & % of their completion. The highlighted dark vertical line shows the date on
which project progress is measured.

133
Project Management

Total duration ofthe progress

(D)ay on which progress is measured


,/
Analysis----······-·-··•

lOS

Fig. 5.3
The percentage of task completion is shown inside the box of each activity. Let's
say budgeted cost of activity Analysis=3 0$, Design=40S, coding=20S and
testing= lO$. From the figure we can understand that activity analysis & design should
be completely finished on date D. (Dis the date on which the progress was measured).
While 80% of coding and 15% of testing activity was expected to be finished on
date D. However at the time of project reporting, activity analysis was 100%
complete, 80% design activity complete, 70% coding activity complete and testing
was not yet started.

Planned value can he calculated by summing values of all activities to be completed


till the date D. Hence looking at the figure. we can straight away say that planned
value of analysis and design is to he taken as 30 & 40 respectively since they expected
to be finished before date D. 80% of coding activity is expected to be fmished hence
plam1ed value of coding is 80% of $20 i.e. 16 :mel 15% of testing activity was planned
to complete on dateD, thus planned value of testing activity is 15% of $10 i.e. 1.5.

Hence total planned value of the project is PV=30+40+ 16+ 1.5=5>87 .5 by rounding
we get $88.

(Here for simplicity we rounded but in practice how much to round, at what level to
round, etc. will be decided as per the cost management plan)

As Analysis activity was 100% complete, project earned value is $30.

As design activity was only 80% complete, we earned only 80% of $40 that is $32.

As coding activity was only 70% complete & as the 80% was expected to be finished,

134
Unit 5 Time to Spend: Managing Quality

we earned value of $14 and as testing is not yet started we earned 0 value from testing
activity.

Thus by adding all the earned values, we get total earn value= EV=30+32+ 14+0=$76.

Actual cost is taken from the actual money spent on the project till date. Let's say project
actual cost was $85

Prom all the above figures we can calculate further SV, SPI, CV & CPl. ETC. EAC

Schedule variance SV=EV-PV=76-88 = -12

Schedule performance index= SPI=EV/PV=76/88=0.86

Cost variance= CV=EV-AC=76-85=-9

Cost perform<:mcc index= CPI=EVI AC=76/85=0.89

Estimate at completion= EAC=AC+(BAC-EV)=85+(1CX)-76)=109

J~stirnate to Complete= ETC=EAC-AC= l09-85=24

RSActivity D:
1. As a project manager, what actions will you perform to control the cost of the
project?

2. Explain the tools & techniques used in controlling cost of the project

135
Project Management

3. Interpret the EVM values of above illustrated example & comment on the project
progress.

4. For a project earned value=350, actual cost=400 and planned value=325,


calculate the cost variance, schedule variance & cost & schedule performance
index. Interpret how the project is performing on cost & schedule.

5. What measures should you take to manage the cost of the project?

5.5 SUM..l\1ARY
In this unit we learned about what is cost, its importance in project management &
how to control cost. Managing project in the given budget is the responsibility of
the project manager. In the planning stage, the estimation & budgeting part of the
project is performed while cost controlling activity is usually performed throughout
the project. We have studied various cost estimation tools and techniques such as
bottom up estimation, analogous estimation & parametric estimation. An appropriate
application of tool is the responsibility of the PM and based on the project size,
complexity and available date, he can choose the right tool. It is imperative for good
project manager to think in advance. His ability to think in advance will ensure the

136
Unit 5 Time to Spend: Managing Quality

success of the project since so many risks may arise during project execution and need to
be mitigated. Cost management is not a standalone process; it interacts with other activities
such as communication & time management.

We understood what is budget & how it is prepared. Budget is time phased allocation of
funds that we spent on project. Budgets are prepared by aggregating cost of individual
activities of the WBS. To mitigate known & unforeseen risk, some reserves arc kept aside
for managing the consequences of the risk. Two types of reserves arc kept aside such as
management reserve and contingency reserve.

We studied how to control the cost of the project. Cost can be controlled by taking
reviews, meetings. performing performance analysis and progress reporting. We
discussed EVM tool for performance analysis.

5.6 SELF-ASSESSMENT QUESTIONS


-------------------
l. Comment on the need of reserve analysis.

2. Compare the advantages and disadvantages of each estimation type.

3. What information do you require to prepare the budget?

4. Discuss the factors to be considered while preparing budget.

5. Briefly explain the EVM technique along with the interpretation ofEVM results.

137
Project Mmmgemcnt

6.1 INTRODl!CTION
In this unit we will explore the concepts of software quality management and learn
various tools and techniques to manage the quality of software.

Why quality is so important? Can you imagine the frustration of a customer when
his application software does not work in an important meeting; he is not able to
connect to the internet when he desperately needs it. Many a times we come across
such situations. The root cause of this entire problem is lack of quality. Due to
advancement in technology day by day. we are totally relying upon the usc of
computers. Everything from buying pizza to booking online tickets (Travel/Movie
& so on ...), internet banking etc. can be done by the single click of button. We
cannot afford delays. erroneous results due to poor quality. It wastes our valuable
time as well as money.

As a working software professional (ignore if you are a fresh student) and future
project manager, how many times did your program run as per expectation? Without
proper quality management, giving high quality product is a nightmarish job. If you
are developing a small application, you need not bother about quality management,
you can give quality anyhow; however in large project<; hundreds of programmers
arc working together & developing thousands of objects and classes, you need to
properly manage the quality of software as well as project.

Why qualities deteriorate? How defects originate? How to control defects? Can we
get high quality product in less amount, etc. are the basic concerns of quality
management. These problems need to be addressed in quality management. Quality
deteriorates basically due to variation in parameters, process, etc. Vruiations mean
no two things arc exactly alike. Variation is inherent in every human creation. For
instance a program written for adding two numbers developed by two programmers
is not alike unless and until it is copy pasted (still they resided on different location
on hard disk- as locations arc different, access time can be different - this is an
example of micro vru·iation). Though their output is same, we can find variation in
their execution speed. These variations become more apparent when we perform
large & complex calculations. A small defect in applications like internet banking
will cause loss of thousand million dollars. Similarly in applications like nuclear
control, life saving equipments, air traffic control, etc. quality cannot be compensated
for any other benefits.

Quality is integral to every product we make or buy. Software products are not

140
I:nit 6 Meeting Expectation: Managing Quality

exception to this. Our customers always expect the best quality of the product. For
him Quality is the satisfactio~ comfort and, reliability. Better quality can be achieved
by proper quality planning, quality controlling and quality assurance.

Due to competitive advantage, importance of quality is recognized by every industry.


Various quality theories arc already developed by Joseph Juran, W. Edwards Deming,
Philip Crossby. Quality management is continuous improvement proceSs hence new
theories, standards, tools & techniques arc always emerging in software industry to
manage the quality of software. In this unit, we will study the basic process of
quality management such as quality planning, quality controlling and quality
a')surance along with various tools.

6.2 QUALITY CONCEI~Ts


- - - --
1. Definition of Quality

Quality means the characteristics or attributes of a software. As a user we have


certain specific expectations about the software product we are using. These
expectations arc usually expressed in terms of explicit requirement, for example we
expect that a "calculator" application written in visual basic should perform all
computation. If your calculator application does all computations accurately, we
can say that the application meets the quality. Here for sake of example, I have
mentioned only one requirement; however in reality there could be lot of implicit &
explicit requirements for example the precision and the length & size of input data,
features such as scientific & engineering calculations. lf the customer has concrete
ideas, he can explicitly mention; however certain expectations he cannot explicitly
express for which he is not sure such as how the inteiface (graphical user interface)
should be, what buttons it should have, etc.

The totality features of a product, process or service that bears on its ability to
satisfy the stated or implied needs.

Unlike physical entity, measurement of software characteristic is somewhat


challenging. Software being an intellectual entity, it becomes difficult to identify
the characteristics of the software. For example, we can easily identify the
characteristics of physical entity such as length, width, height, grade of material,
colour, etc.

As software technology will grow mature, we will have more concrete methods to

141
Project Y!anagemcnt

identity & measure the characteristics of software. Many researchers in this field
developed theories & provided guidelines in software quality management with
which we can measure the quality of the software.

Quality principles:
Perception on principles of quality varies with organization to organization and hence
becomes difficult to uniquely define the quality principle of software; however we
can apply certain guidelines that are generally accepted & can help us in better
management of software quality.

• All software must meet the explicit & implicit requirements of the customer.

Prevention over Inspection: The approach should he taken to avoid quality defects
than to inspect & correct defects. Correcting changes later on in software will have
considerable impact on the project.

• Maintain the quality of product as well as the project.

Avoid gold plating: Gold plating means giving extra to customer than required.
Gold plating should not be confused with the quality. Giving extra things docs not
mean you are giving extra quality. You should give only what is required hut defect-
free software.

• Quality principle should align with the principles of the organization.

Involvement of stakeholders from top to bottom management & at certain extent


your customers.

Software Quality Factors

We arc learning software quality management in view that we are responsible for
managing the quality of software. Before you start planning quality, you must know
what different factors can affect the quality. Every product. physical or software,
comes with basic two types of characteristics, intrinsic and extrinsic. For example
in case of physical entity such as wooden furniture, intrinsic characteristic could be
the strength of the material and extrinsic characteristics could be shape, design,
aesthetics, etc. However, you can measure both of these characteristics with tools.
In case of software, well presented graphical user interface could be extrins ic
characteristic and execution speed could he intrinsic characteiistic.

142
Unit 6 Meeting Expectation: Mana11-ing Quality

Further to this, McCall and his colleagues proposed a useful categorization of factors
that affect software quality. These factors are broadly classified into two groups:

I. Factors that can be directly measured for example defects per function point,
and

2. Factors that can be indirectly measured such as usability and maintainability of


software.

Some other factors that can affect quality are:

Correctness: The extent to which software satisfies iL<> specifications and fulfils the
customer mission objectives.

Reliability: The extent to which a program can be expected to perform iL<> intended
function with required precision. A simple example could be mathematical operation
of two numbers should give accurate result with range of input data types such as
float, single, double, integer, etc. with range of values. These applications are reliable
up to a certain extent. Their performance is not consistent. Sometimes they work
well, some times not.

Efficiency: How fast the software can run the application with available resources
such as memory. processor, disk, etc. We know that processing speed of the
application can be increased to a certain extent with the speed of processor & memory;
however efficient programs will give equal speed with available resources.

Integrity: Integrity defines the extent at which each module or process is interlinked
with each other. There can be various integrity checks. For example ERP software
processes such as inventory and accounts arc tightly integrated. That means if you
make any changes in inventory transaction, it will post corresponding entries in
accounting transaction. If you purchase any goods and post goods receipt note (GRN),
ERP application will automatically update stock register and increase value of stock
in accounts.

Usability: It is the effort required to learn, operate, prepare input, and interpret
output of a program. Most of the application demands lot of inputs to proceed with
one transaction. One must know the flow of process i.e. what inputs need to be
entered first, etc. otherwise he could not operate that application. Higher the usability
of the software, lesser is the operational complexity. This factor has more concern
with the end user than the technical person who is developing the software.

143
Project Management

Maintainability: It is the effort required to locate and fix an error in a program.


Maintainability is the immediate concern of the organization that is developing
software. Over the period software undergoes changes due to change in business
logic or changes in customer process or customer may need extra feature. In all
cases, previously written program needs to be re-written. If the program is not
properly written or not well documented, it becomes difficult for the same
programmer or other programmers to remember the logic and implement changes.
Highly maintainable program are well documented and structured.

Flexibility: It is the effort required to modify an existing program. Tightly integrated


modules restrict flexibility. To make change in one place, you have to make changes
in so many other places which are integrated with that process. Suppose you want to
modify customer name field from 20 digit to 40 digit, it will affect other logic.

Testability: The effort required to test a program to ensure that it performs its intended
function.

Portability: The effort required to transfer the program from one hardware/software
environment to another system.

Reusability: The extent to which a program can be reused in other application. For
example customer class is required in most of the transaction. Your program should
allow you to reuse the same code in other modules.

2. Quality Planning

Quality planning is an essential process in quality management. Quality planning


process ensures that the resulting product is of acceptable quality. for an IT project,
quality standards include allowing for system growth, planning a reasonable response
time for a system, or ensuring that consistent and accurate information is produced.
Without proper plan, you cannot establish control and measure the progress of the
project. Most of the software professionals realize the importance of quality planning
because of the perception that planning means just writing the things that any way
they arc going to perform and writing down the things that you already know is just
mere time wastage. In fact it is not the same. In plarming, you have to take various
decisions such as what should be the quality norms of this project, how can I improve
my existing process so that I can deliver more quality product in less cost, etc. In
planning we are not supposed to make plan for day-to-day activities. On the contrary
we are planning the activities which are not yet done. Written plan gives clear direction
to the project and you will have more visibility towards your objective.

144
Vnit 6 Meeting Expectation: Managing Quality

Planning is a process that addresses two questions. what is quality objective of the
project and how I 'm going to achieve that objective? For example one of your
quality objective could be all source code should be maintainable. To maintain the
source code you need to perform various activities such as detailed specification
about how you can maintain source code. For example you can ask your team to use
standard source code template and use standard program structure such as convention
for writing variables, comments, etc. Designing standards template, conducting
source code reviews, checking whether program written by one team could be
modifiable by other team, etc. can be decided in quality planning.

Now when should you perform the quality planning process? To answer the questions,
you need to know what information you require to perform quality planning. Most
important information that you need to define quality plan is the requirement
specification, customer's quality expectations, quality policy of your organization,
etc. You can get customer functional as well as quality requirements, acceptance
criteria, etc. in the project preliminary scope statement. Hence the quality planning
process generally starts after requirement gathering phase & before execution.

\Vhat is standard?
Standards are basically guidelines or procedures. A standard is based on the
experience. By applying the standards, we can assure that quality can be achieved.
These standards do not provide you what should be quality of your project. However
standards provide you how to standardize the process so that you can achieve desired
quality. You can adopt standards such as ISO or develop your own standards. For
example, you can set standards like following standard templates for documenting
the project, you can set no. of defect per lines of code, well defined change
management process. Once the standards have been identified or created, you must
define how you will meet those standards. You can write the detailed procedure to
maintain the standard. You can provide templates along with the description how to
use those templates.

Outputs of Quality Planning


Following information will be generated as the output of quality planning:

Quality Management Plan (QMP):

QMP describes how the project management team will implement the quality policy
defined in planning process. As per organization and project needs, this plan can be
broadly defined.

145
Project :vlanagement

Quality Metric:
Quality metrics specifically defines how quality will be measured. For example,
Instead of just saying that system should give quick response to end user queries,
quality metric might specify that a system must respond within two seconds to 99%
of all requests up to I 00 concunent users.

Quality Checklist:
A checklist is a quality planning output created to ensure that all steps were performed
in proper sequence and no step skipped, etc. In quality plan, only checklists are
defined, however actual processes are checked in quality control process.

Quality Baseline:
The quality baseline includes the quality objectives and plan for achieving those
objectives.
Let's discuss various tools & techniques that you can in quality planning process:

Cost-Benefit Analysis:
You can do cost-benefit analysis to decide the norms of the quality. Quality never
comes freely; you need to pay extra cost on achieving the quality. The cost applied
to achieve quality should be less than benefits of quality. For example the ideal
products provide a benefit of say thousand dollars per month & to achieve the quality
you need to spend extra 10000 dollars, then here the cost of quality is more than
benefits of quality. Such comparison needs to be done in quality planning process.

Benchmarking:
Benchmarking can be used to generate ideas for quality improvement by comparing
specific project practices or project characteristics to those of other projects or
products within or outside the performing organization.

Benchmarking is the process of comparing the business processes and performance


metrics including cost, cycle time, productivity, or quality to another that is widely
considered to be an industry standard benchmark or best practice. Benchmarking
provides a snapshot of the performance of your business and helps you understand
where you are in relation to a particular standard.

The term benchmarking was first used by cobblers to measure one's feet for shoes.
They would place the foot on a ''bench" and mark it out to make the pattern for the
shoes. Benchmarking is most used to measure performance using a specific indicator

146
Unit 6 Meeting Expt~clation: Managing Quality

(cost per unit of measure, productivity per unit of measure, cycle time of x per unit
of measure or defects per unit of measure) resulting in a metric of performance that
is then compared to others.
Over the years, many organizations with significant development experience and
mature processes have collected metrics on the various software development
projects. These include the time, effort required to develop applications on various
platforms and in various Business Domains. Based on this data, benchmarks are
created. There is no single methodology available for benchmarking. The wide appeal
and acceptance of benchmarking has led to various benchmarking methodologies
emergmg.

Usually, following benchmarking processes are followed:


1. Select the parameters for benchmarking. For example you can say that no. of
defects per thousand line of code
2. Identify partners or projects with whom you want to compare your standards.
3. Get the data relevant to the parameters.
4. Communicate new benchmarking goals with team.
5. Review & adjust.
6. Implement new standards in your organization.

Design of Experiment":
Design of experiment is a statistical method that helps in identifying factors that
influence specific variables of a product or process under development. The most
important aspect of this teclmique is that it provides statistical framework for
systematically changing all of the important factors instead of changing the factors
one at a time

PS Activity A:
1. Find out various characteristics that can be checked for quality.

147
Unit 6 Meeting Expectation: Managing Quality

3. Quality Assurance

We have seen that Quality plan defines how each process in the software development
life cycle is executed, what standards are to be applied to the process, etc. For example
you may decide that requirement gathering team should follow standard template
for collecting requirement in proper format, coding team should follow standard
programming template where variable declaration and naming standards, etc. are
mentioned. These and other standards are defined in the quality plan. However, in
reality one needs to see whether these standards arc giving desired quality results; if
not, there is need for process improvement.

Only planning is not sufficient to ensure that the project under development will
achieve desired quality. There is need to check whether the team is following
standards. Many a times it happens that the team may not properly understand how
to use those templates. It involves taking responsibility for quality during the project
as well as the end of the project.

Quality assurance ensures that defined standards are being followed. Sometimes
process needs to be revised. Thus quality assurance is a continuous process executed
throughout the life cycle of the project. QA is an application of planned systematic
quality activities to ensure that the project will employ all process needed to meet
desired quality.

Quality assurance performs quality audits and process analysis techniques to ensure
quality.
Quality Audit:

Quality audit is the process of conducting structured and independent technical


reviews. Review is a way of using the diversity of a group of people to point out
needed improvements in the product of a single person or team. Confirm those parts
of products in which improvement is either not desired or not needed. There are
many different types of reviews that can be conducted. For example, an informal
meeting with your team members to discuss technical problems. A formal presentation
of software design to an audience of customers, management and technical staff is
also a form of review. Formal review is sometimes called as Technical Walkthrough.

Process Analysis:

Process analysis is a part of contentious process improvement. In this process, each


process is analyzed as per process improvement plan & suggestions are given for

149
Project Management

further improvement. This analysis also examines problems experienced. Process


analysis uses root cause technique to determine the underlying cause that leads to
poor quality.

4. Quality Control

We know that quality deteriorates due to variation. Controlling variation is the main
objective of quality control. Thus quality control is the series of inspections, reviews
and tests. These activities are performed throughout the life cycle of the project. For
example during project planning quality control might measure how long it takes to
plan the project or measure other areas of planning performance. However much of
the quality conu·ol occurs in the monitoring during execution. Quality control includes
a feedback loop to the process that created the work product. The feedback loop is
essential to minimize the defect produced.

During quality control, all actual specifications arc measured against standard
specification through inspection. Quality control activities may be fully automated,
entirely manual or a combination of automated tools and human interaction.

A QC system is designed for the following:

• To provide regular check so as to ensure the data correctness, completeness


and integrity.

• To distinguish the errors and to address them.

• To document and record all the quality control processes.

The Quality Control Processes use various tools to study the \Vork clone. If the
Work done is found unsatisfactory, it may be sent back to the development team for
fixes. Changes to the Development process may he clone if necessary.

If the work clone meets the standards defined, then the work done is accepted and
released to the clients.

5. Cost of Quality

You must know the concept of quality. Customer is never ready to pay extra cost for
high quality and it is your responsibility to manage the project in given budget &
deliver high quality. During the project, you need to balance the additional cost of
quality. Quality doesn't come free of cost. Initially quality wac; thought as an integral

150
Unit 6 .\1eeting Expectation: Managing Quality

responsibility of the development team. No additional activities were canied out for
maintaining quality. Due to lack of quality procedures, project cost considerably
increased to remove the defect in later stages. Over the period, software industry
realized that there is a need to maintain separate quality activities to ensure the
quality and minimize defects. Quality helps in increasing customer satisfaction as
well as reducing cost of project due to less rework. Quality costs may be divided
into costs associated with prevention, appraisal, and failure.

These additional quality activities such as quality training, technical reviews, etc.
need more resources that lead to additional cost burden on the project. lienee it
becomes important to know the cost of quality. Cost of quality is broadly divided
into two types 1. Cost of conformance and 2. Cost of non-conformance.

1. Cost of conformance: In order to meet the quality standard, additional activities


such as quality training, quality planning, conducting formal teclmical reviews,
maintaining documentation need to be carried out. These activities need extra
resources & incur cost; that cost is called as cost of conformance. These costs
primarily go to preventing defects that can be found in later stages of projects.
This preventive cost may reduce your cost of reworks and repairs in later stages.

2. Cost of Non-conformance: This is sometimes also called as failure cost. That


means if we not able to prevent defect.:;, we have to pay extra cost on fixing the
defects. This cost is further divided into two parts as internal failure cost and
external failure cost. Internal failure cost<; arc incurred when we detect an error
in our product prior to shipment. such cost includes cost of rework, repair.
External failure costs are the costs associated with defect.:; found after the product
has been shipped to the customer. Example of external failure costs are complaint
resolution, product return and replacement, support, etc.

Based on the data collected by Boehm, he observed that the relative cost to find and
repair a defect increases dramatically as we go from prevention to detection and
from internal failure to external failure.

As a general rule, we must know that the cost of conformnance should be less than
cost of non-conformance.We cannot afford to pay 1000 dollars to prevent defect of
100 dollars.

151
Unit 6 :Y!eeting Expectation: :Y!anaging Quality

5. Explain the tools used in quality assurance process.

6.2 QUAlJTY MA~AGEMENT TOOLS & TECHNIQUES


------
There arc around seven basic tools that you can usc in your project to control the
quality.
We will discuss each one in brief.

1. Cause and Effect Diagram:


Cause and effect diagrams were proposed by Kaoru Ishikawa in the 1960s, who
pioneered quality management process in the Kawasaki shipyards, and in the process
became one of the founding fathers of modern quality management. Due to his
work, these diagrams arc also known as Ishikawa diagrams. It is also known as
fishbonc diagram because of its fishbonc like shape. These diagrams show how
different factors relate together and might be tied to potential problems. In quality
controL cause and effect diagrams arc used as a part of an approach to improve
quality by identifying quality problems and trying to uncover the underlying cause.
The following diagram illustrates how a fishbone diagram helps in identifying
potential defects in system installation.

Coni1ictinr, System Software

I.cgacy Systcm -+

liW Installation-+ /
SW Installation / -+-- Less Primary & Secondary Memory

Lack of Training Hardware


Fig 6.1

!53
Project Management

Some of the root causes that make software installation fail are conflicting system
such as your new software does not establish connectivity with existing legacy system
due to data incompatibility, lack of training causing incon-ect hardware and software
installation, sometimes the new version of the application software is not supported
by existing operating system. Also due to insufficient memory and hard disk capacity,
new system may not get installed.
Once you identify the root causes, you can easily remove it. Pictorial representation
will help the team in organizing thoughts & helps in stimulating thinking and can be
understood by everyone during discussion.
2. Control Charts:
Control Charts arc mainly used in statistical quality control. This chart helps in
deciding whether process needs to be controlled or not. If process is in the statistical
limit, then it need not be con-ected. Control charts depict whether process is in the
limit or out of control. In this technique sample data is taken and plotted on the
graph as shown in figure.

t
50
Upper control limit

40

30 Lower control limit

10 ;-----...J Specification limit


Assignable cause
0 '-------J

10 20 30 40 50 60 70

Fig 6.2
Let's now quickly look at the different parts of the diagram.

Upper and lower control limits:


These limits indicate the acceptable range of variation of process. These limits arc
generally shown in dotted lines on a control chart. The acceptable range of

154
Unit 6 Meeting Expectation: Managing Quality

measurement between upper and lower control limit is usually set by the project
manager or the stake holders based on the organization quality standard. Data points
within this range indicate quality is within control. Data range outside this range
means process is out of control and need to be corrected.
Mean:
The middle bold line in control chart indicates mean. Mean indicates acceptable
range of variation.
Specification Limits:
Every organization has their own standards that define the limits of quality variation.
However, sometimes customer also explicitly mentions defect tolerance limits for
example customer may mention that only two rninor errors arc allowed per module.
As these limits arc provided by customer, they may appear inside or outside the
upper and lower limit your organization has set for the project.
Out of control:
The basic purpose of the control chart is to understand which process is out of
control and this can be analyzed from the control chart. In two types of circumstances,
process is said to be out of control when all data points fall outside the upper and
lower control limit.
Rule of seven: The rule of seven is a rule of thumb or heuristic. If seven non random
data point appear in series on one side of mean, then process may be out of control
smcc.
[ Seven pointj

~~---------------------

~------

Fig 6.3
Above figure shows total seven points appear in series. These points arc not random
& though they appear within upper control limit, still the process may be out of
control and need to be conected from deviation.

155
Project Management

3. Flow charting:
While planning quality, you need to know what the process arc, how they are
interlinked with each other, what are inputs & output.;; of the process. All these
information can be pictorially shown by using flowcharting. A flow chart graphically
represents a process. You might be familiar with flowcharting technique.
Flowcharting technique can be used in many places in software development. With
this you show the logical flow of the system. With proper flow chart we can determine
where potential quality defect may appear.
4. Histogram:
Histogram is another statistical tool used in quality control. It shows data such as
no. of severe defects, minor defects in bar charts. Each bar represents an attribute or
characteristic of a problem or situation. The height of a bar represent.;; the relative
frequency of the characteristics. Based on height and width of the bar, we can identify
root causes of the problem. When measuring a process. it often occurs that the
measurements vary within a range of values. By understanding how these
measurements vary, the effect.;; of the process and changes made to it can be better
understood. The Histogram shows the frequency distribution across a set of
measurements as a set of physical bars. The width of each bar is constant and
represents a fixed range of measurements (called a cell, bin or class). The height of
each bar is proportional to the number of measurements within that cell. Each bar
gives a visual impression of the number of measurements in it and together the bars
show the distribution across the measurement range. Figure shows how the
distribution of measurements can be seen far more clearly in the Histogram than in
a table of numbers.

Set of measurements

21.2 20.5 19.9


Frcquenc~

30 /q
/'?- All bars arc of
'q"ol widtb

23 .1 21.4 18.1 Overall shape


14.2 23.9 12.2 shows
25.1 29.2 26.6 distribution
16.1 23.1 23.8
23 .6 22.5 22.0
20.7 ?. 1.1 15.6 10
19.5 20.4 21.1
etc

7.8 30
This cell indicat..:s that there
arc about 10 m..:asur..:mcnts
between 16 and 18

Fig. 6.4

156

......
Unit 6 :vlceting Expectation: Managing Quality

In drawing the Histogram, there must be sufficient number of measurements to be


able to give a usable shape to the distribution. The number and width of the bars are
also important; if the bars are too narrow, then insufficient measurements will fall
into each bar to give it significant height. Similarly. if the bars are too wide, there
will be too few bars to give a useful shape to the distribution.
Problems may he indicated by the distribution being naturally non-bell-shaped or
by problems with the measurement. When a distribution differs from the expected
shape, the underlying process should be examined to find real causes of this.
5. Pareto Chart:
Vilfredo Pareto developed Pareto chart to analyze the problem. This chart is similar
to histogram, in addition it contains line graph. The bar display the values in
descending order from left to right and the line graph shows the cumulative total of
each category. The left vertical axis represent~ the frequency of occurrences and
right vertical axis represents the cumulative total of occurrences.
The Pareto diagrams arc conceptually related to Pareto's Law which holds that a
relatively small number of causes will typically produce a large majority of defects
or problems. This is also referred as the 80/20 principle, where 80 percent of the
problems arc due to 20 percent of the causes. The following diagram shows typical
Pareto chart.
Given a set of recurring problems, it is unlikely that each problem will occur the
same number of times in any one period. In fact, it is common that a few problems
will occur far more often than the rest put together. This unequal distribution occurs
in many situations and can he used to single out the 'vital few' from the 'trivial
many'.
The Pareto Chart is simply a Bar Chart in which the bars arc sorted into size order,
with the highest bar on the left, as below.
Item Measure Items are measured
measured or count 30 ! ( : a n d sorted ;nto onle'
Item 1 12
Item 2
Item 3
2
32 --\20
Item 4 4
Item 5
Item 6
19
9
---110
Item 7 l

Item Item Item Item Item Item


3 5 I 4 2 7

Fig. 6.5

157
Project Management

This not only shows the absolute priority of each bar, through its position in the
chart, but also its relative primity, through its height as compared with the other
bars.

As the Pareto Chart is often used for decision making, it is an important part of
building a Pareto Chart to identify the right item to measure and show on the chart,
as different measures may well result in the bars to be ordered quite differently. The
purpose of the Pareto chart is to highlight the most important among a (typically
large) set of factors. In quality control, it often represents the most common sources
of defects, the highest occuning type of defect, or the most frequent rea<;ons for
customer complaints, and so on.

In a stable process, the order of the bars may be expected to remain constant. Thus,
if the order of the bars changes with successive measurements, this may indicate an
unstable process (or an insufficient number of measurement.,). Improvements (i.e.
changes in the process) will often result in the order of the bars changing. If the
improvements are maintained. the new bar order will remain stable.

Pareto Chart<> may have different overall 'shapes'. The 'spiky' Pareto Chrut is the
most useful, as it enables an easy selection of items to carry forward for further
action.

6. Run Chart:
A run chart, also known as a run-sequence plot is a graph that displays observed
data in a time sequenc~. Often. the data displayed represent some aspect of the
output or performance of a manufacturing or other business process.

If you want to look at the history and pattern of variation. you can use run chart. A
run chart is a line graph that shows data point<; plotted in the order in which they
occur. Over the period, process undergoes some changes. some processes get further
improved and some need to be improved. These trends can be shown and analyzed
with the help of run chrut. Trend analysis involves mathematical treatment to data to
forecast future outcomes based on historical results. Trend analysis can be used to
monitor the cost. schedule and technical performance.

7. Scatter diagram:
When investigating problems. typically when searching for their causes. it may be
suspected that two items are related in some way. For example, it may be suspected
that the number of defects in software is related to the amount of overtime that
people are working.

!58
Unit 6 Meeting Expectation: Managing Quality

The Scatter Diagram helps to identify the existence of a measurable relationship


between two such items by measuring them in pairs and plotting them on a graph. as
below. This visually shows the correlation between the two sets of measurements.
for each first item measurement,
there may be a range of possible
• second item measurements,
Second item
measurement



• .. and vice versa

. . . .. . ~
·.. ·
---------------- • • ¥"'
~~

.. Each time the first item is measured,

.. ••. .. . •
• •
the second item is also measured, and
this pair of measurements is plotted
on the Scatter Diagram

First item measurement

}'ig. 6.6

If the points plotted on the Scatter Diagram arc randomly scattered, with no
discernible pattern, then this indicates that the two sets of measurements have no
correlation and cannot be said to be related in any way. If. however, the points form
a pattern of some kind, then this shows the type of relationship between the two
measurement set<;.

A Scatter Diagram shows correlation between two items for three reasons:
a. There is a cause and effect relationship between the two measured items, where
one is causing the other (atleast in part).
b. The two measured items are both caused by a third item. For example, a Scatter
Diagram which shows a correlation between requirements and coding of
software because changes in both are caused by how each process is documented.
c. Complete coincidence. It is possible to find high correlation of unrelated items,
such as the change in requirements and new technology adopted.
Scatter Diagrams may thus be used to give evidence for a cause and effect
relationship, but they alone do not prove it. Usually. it also requires a good
understanding of the system being measured, and may require additional experiments.
'Cause' and 'effect' arc thus quoted in this unit to indicate that although they may be

159
Project Management

suspected of having this relationship, it is not certah1. When evaluating a Scatter


Diagram, both the degree and type of correlation should be considered.
• The proximity of the cause and effect: There is better chance of a high correlation if
the cause is direct!y connected to the effect than if it is at the end of a chain of causes.
Thus a root cause may not have a clear relationship with the end effect.
• Multiple causes of the effect: When measuring one cause, other causes arc making
the effect vary in an unrelated way. Other causes may also be having a greater effect.
swamping the actual effect of the cause in question.
• Natural variation in the system: The effect may not react in the same way each
time, even to a close major cause.

8. Statistical sampling:

In a large project made up of thousands of objects & classes, it is not practically


possible to check the quality of every piece of software. Hundred percent checking
require more time & more resources and even not required. Depending upon the
complexity of the project few modules can be randomly selected for testing. However
the strategy to select no. of samples varies with the organization. If the new project
uses some utilities or object library which arc previously used in some project, it
need not he tested again individually.

9. Inspection:

An inspection is nothing but the thorough examination of software. An inspection


includes peer reviews, technical reviews, audits and walkthroughs. Quality inspection
is performed throughout the software development life cycle. The objective of
inspection is to determine whether software conforms to the standards and
specifications. During inspection, the actual specification of software measured
against the standard specification and any defects that appear during process arc
reported for rectification. Once defects arc removed, they arc again checked to see
whether all defects are repaired and brought into compliance with requirements or
specification.

6.4 QUALITY STANDARDS & MODELS

The quality movement began in 1940, since then various theories are continuously evolved.
The major contribution of quality movement belongs to quality theorists namely Joseph
Juran, W. Edwards Deming who developed 14 steps to total quality management and
Philip Crossby.

160
Unit 6 \.1eeting Expectation: Managing Quality

Various quality standards and models help in defining the basic task an organization must
do in order to join the quality ladder. Knowing these st.1.ndards is essential; however the
organization quality policy decides which standard has to be adopted. You must .know
various standards and methodologies that are used in quality management such as total
quality management, Six Sigma, failure mode and effect analysis, cost of quality and
continuous improvement. capability maturity model, etc. The standards arc available for
specific area<> such as Process Standard, Safety standard, Quality Assurance Standards,
etc.

Let's underst:md some of the bac;ic popular standards:

1. ISO 9000:
The International Organization for Standardization (ISO) developed the family of standards
for software. The family ofiSO 9000 includes standards such as ISO 9001,9002 and
9003. These standards arc continuously being evolved and applicable to various disciplines.
ISO provides only fnunework and every organization has to prepare vruious document'\
as per the guidelines of the sclcctccl standard. Organization needs to apply for the
certification. Once applied, third party auditors scrutinize the company's quality system
and operations for compliance to the stru1dards. Upon successful completion of scrutiny,
registration body represented by auditors can issue certificate to performing organization.

ISO 9000 quality assurance model emphasizes on the network of interconnected process
such as requirement gathering, design, coding and testing. For a quality system to be !SO-
compliant, each process must be well documented and followed as described. Process
documentation helps an organization in many ways such as improvccl understanding and
control. \Vell defined processes make the process person independent. ISO enables a
consensus to be reached on solutions that meet both the requirements of business and
the broader needs of society.

The ISO 9000 framework describes quality assurance elements which includes
organizational stmcture, procedures, processes and resources needed to implement
quality planning, quality assurance and quality control.

Some of the clements covered in ISO 9000-3 are Management responsibility, quality
system, design control, document and data control, process control, inspection and
testing, corrective and preventive action, control of quality records, internal quality
audits, training and statistical techniques.

To become registered to ISO 9000 organization. a company must establish policies

161
Project Management

and procedures to address each of the requirements stated in the above paragraph and
then be able to demonstrate that the policies and procedures arc being followed.

2. Six Sigma:
Six sigma is a methodology of quality management. Six sigma focuses on achieving high
levels of quality by controlling the process and reducing defects. The six sigma derived its
name from the statistical term 'standard deviation' and is denoted by letter 6 sigma (A
Greek notation) that defines the degree of variance. A sigma or standard deviation is
defined as 1 standard deviation from mean. Now let's quickly recall the term standard
deviation.

Standard Deviation:
Standard deviation is a statistical calculation used to measure and describe how data is
organized. The following figure illustrates the bell shaped standard deviation.

99.7% between :!..3 s.d.

95.4% between ±2 s.d.

Only 3 points in 1000


will fall outside U1e area
3 standard deviations s.d. = standard deviation
either side of the center line.

3-U% 3-U%

~
-.) -2 -I Mean !l +2 +3
S.d. S.d. S.d. S.d . S.d. S.d.

}'ig. 6.7

162
Cnit 6 Met:ting Expectation: :'vlanaging Quality

To calculate SD, first mean is calculated by averaging all data points. Then difference is
calculated between each data point and mean. Then each difference is squared and total
sum of squares of all differences arc calculated and divided by no. of data points minus
one. Finally this number's square root is taken & you w111 get the standard deviation.

\Ve know from our previous discussion that quality deteriorates due to variation. lienee
six sigma puts a primary focus on quantifying, mea.c;uring and controlling quality of the
product. There are six levels defined in six sigma methodology. To understand the six
sigma in terms of numbers, we can say that 1 sigma means 317,500 defects can be found
per 10,00,000 outputs and six sigma means only 3.4 defects per 10,00,000. Hence six
sigma ensures the highe..c;t quality.

3. Capability Maturity Model (CMM):

'The CMM is a framework developed by Software Engineering Institute (SEl) at Carnegie


Mellon University. The framework is based on the best practices in software and other
organizations. Thus CMM reflects the collective process experience of many companies.
The CMM is used to evaluate the software processes and identify deficiencies. CMM
framework provides 5levels of the process as per the level of maturity. These Five levels
are 1. Initial2. Repeatable 3. Defined4. Managed and 5. Optimizing. In the initial stage,
processes arc immature or ad hoc means these process are not clearly defined and outcome
of these processes large! y depends on the capability of the team and project leader. From
level 2 to 5, proce.c;scs arc more refined and as we go up one scale, processes become
more matured. In mature processes, each process is well defined and outcome of the
process docs not depend on team but on the process. More mature the process. more
quality we can expect.

6.5 SUMMARY

In this unit we discussed various concepts related to quality management. Quality has
utmost importance in software industry. The main objective of software quality management
is to reduce the no. of defects and increase the customer satisfaction. To ensure quality.
we need to carefully plan the quality goals and set the standards. Quality assurance is an
umbrella activity that ensures that all processes being executed follow the norms defined in
quality plan and adhere to the standards. Quality need to be monitored and controlled
throughout the software development life cycle. We also studied which tools can be used
in controlling the quality of software. At the end we overviewcd the various standards such
as ISO, Six Sigma and Capability Maturity Model. At the end we can summarize that
quality comes from continuous improvement, learning and by experience. Quality is the
prime responsibility of the team and customer expects quality free of cost.

163
Project Management

7.1 INTRODUCTION
In this unit we will discuss and try to understand one of the impmtant resources in
software development and that is human resource. The management of the human
resources on a project has a major impact on the project's success or failure. Human
resources are strongly influenced by the human resource policies and procedures of
the performing organization. Broadly, human resource management deals recruiting.
leading, communicating. delegating, motivating, team building, appraising, etc.
Project team size varies with the size and complexity of the project. The large team
needs careful application of right human resource development strategy. The needs
of human resources in terms of set of their skills and expetience varies with stages
of project life cycle. In the initial stage, less number of people are sufficient to carry
out task, however as project progresses into execution, more team members arc
needed. Human resource management processes must recognize and address these
changing needs.

In this unit we introduce you to various Behavioural and motivation theories such
as McGregor's X & Y theory, Maslow's Hierarchy of needs. This unit also introduces
how to build teams. how to motivate and achieve peak performance & how to resolve
conflicts.

7.2 TEAM
Meaning and importance of team is hidden in the word 'TEAM" itself. The first
letter "'T' explains us Togetherness, E stands for Each, A stands for Achieve and M
stands for More. That means Together Each Achieve More. Software development
is a team effort. If team is highly motivated and properly coordinated it gives high
quality and productivity. Software Project team includes project sponsors, project
managers, programmers, architects, testing and quality personnel, documentation
team, customer representatives, etc. Each team member plays a unique role such as
coding, testing, documenting, etc. Every human being is complex and unique in
nature. Every individual possesses different skills, knowledge. experience and many
other factors such as attitudes, personality types, beliefs, etc. Managing team involves
consideration of all aspects of human nature. Team development is a continuous
process. To keep all team members together is one of the main objectives of the
project manager. As we know that every team player pe1forms different task, his
involvement & performance may affect the performance of other team members.
For example, if one of the programmer delays his job, all other modules and processes
that depend on his module get delayed. As a leader, the project manager has to

168
Unit 7 Togetherness: Managing Team

compensate the weakness of such a team player and keep entire team on track.
Without knowledge of team dynamics and various skills such as motivation,
communication, negotiation, influence and conflict management, one cannot lead
the team effectively. It must therefore be essential to understand the basics of teaming.

Pillars of Team

Great teams arc building upon the four strong pillars of Mutual Trust. Honesty,
Transparency & Coordination. If anything is missing, no one can build a proper
team.

Trust: Trust is the most important factor in team development. For effective team
management, one must try to gain the confidence of other team members. Building
trust is an ongoing process and cannot be done in a single day. Trust is a vital force
behind any motivation. People do work to satisfy their needs. They assume that
working in a team will fulfil their needs and give them essential security. If that part
is missing, no one can work together. People build their trust by watching the
behaviours in various occasions and hence it is the responsibility of the team leader
to keep to the words and commitments given. He should build confidence in his
team that they will get appropriate rewards for their work.

Honesty: Honesty helps in building mutual trust. During the project, lots of
information is being generated and conmmnicated to the stakeholders and it is not
always practically possible to check the sanctity of the information. It is assumed
that people are reporting actual facts and not dummy data to save their face. Honesty
and sincerity improves the quality and productivity of the work. Honest people get
respect from others. Honesty helps them to climb up the success ladder. Honest
people can objectively criticize their performance and improve further.

Transparency: Transparency means openness in communication and overall


behaviour. It is ba'ied on the principle that no one is superior in everything. People
seek guidance and information from others. If they cannot openly talk to each other
due to fear of criticism or fear of risk, their progress gets stagnant. Good leaders
always try to make the environment as open as possible where people can share
their thoughts and opinions freely. Transparent environment encourages them to
take more risks. Transparency does not mean access to every information. Leader
should share only relevant information and not the sensitive information. One must
be very careful in implementing such a strategy since there arc few people who can
get undue advantages of such environment.

169
Project Management

Coordination: Though teams are performing individually, they are integrated with
each other and they have a common objective. The petformance of one may affect
the performance of others; hence by proper coordination the team leader maintains
the balance of the speed. During execution, people get struck due to lack of
information or incompletion of previous activity, hence it is the prime responsibility
of the team leader to see that all resources are having proper information at hand to
proceed further. He needs to organize the team a~ per the skills and roles. Coordination
is also a continuous activity. Coordination is an activity in which team leader closely
interacts with team members to find any gaps & fill the gaps.

7.3 BUILDING TEAM


Building team is an important activity in software project management. Right people
with matching skills arc crucial for project success. Right people with right skills
arc not easily available to a project. In software industry, the human resources arc
shared resources. When new project begins, free resources arc taken up on project
and may he released after their work is over or they arc not pcrfonning well. Due to
the temporary nature, software teams arc not permanent teams. Team size keeps on
changing. Some people form different teams for different projects at different times.
Hence team building activity needs to be performed for every project. In small
companies or small teams this activity may not have any importance. But for large
project managing thousa.11ds of people is really a challenge. We have seen in
communication management how a single addition of resource adds new
communication paths. Similarly, if team size increases, HR management becomes
more complex.

It is worth to know how a team forms. Most of the time, the team forms through
informal ways. Equal minded people get together, however in projects, team forms
as per the roles in the organization structure. Let's understand the basis of team
building activity.

The model of group development was first suggested by Bruce Tuckman in 1965.
This model depicts how a team gets formed with four stages namely Forming-
Storming-Norming and Performing. He believed that all these four stages arc
inevitable for team growth, facing challenges, tackling problems, finding solutions
and in planning and delivering results. This model has become the basis for
subsequent models.

L70
Unit 7 Togetherness: Managing Team

Forming
Forming is the first stage in team builcting in which forming of the team takes place.
The team meets and learns about what they arc supposed to do, i.e. their roles and
responsibility and challenges, and then agrees on roles and begins to tackle the
tasks. Team members tend to behave quite independently. They may be motivated
but arc usually relatively uninformed of the issues and objectives of the team. Team
members arc usually on their best behaviour but very focused on themselves. Mature
team members begin to model appropriate behaviour even at this early phase. Sharing
the know ledge of the concept of "learns - Forming. Storming, Norming, Performing"
is extremely helpful to the team.

As initially, team is not f11lly aware of its role. Leaders should provide necessary
guidance in this phase.

During formation, players of the team get to know each other, share their experiences,
likes and dislikes and make friends . This is also a good opportunity to sec how each
member of the team works as an individual and how they respond to pressure.

Storming
This is a bit tensed stage. There is no consensus on goals and how to achieve the
goals or tackle the problems at hand. The team addresses issues such as what problems
they are really supposed to solve, how they will function independently and together
and what leadership model they will accept. Team members open up to each other
and confront each other's ideas and perspectives. In some cases, storming can be
resolved quickly. [n others, the team never leaves this stage. The maturity of some
team members usually determines whether the team will ever move out of this stage.
Some team members will focus on ins and outs to avoid real issues.

The storming stage is necessary for the growth of the team. It can be debatable,
unpleasant and even painful to members of the team who want to avoid conflict.
Tolerance of each team member and their ctifferences need to be emphasized. Without
tolerance and patience, the team will faiL This phase can become destructive to the
team and will lower motivation if allowed to get out of control.

Team Leaders of the team during this phase may be more accessible but still need to
be directive in their guidance of decision-making and professional behaviour. The
groups will therefore resolve their differences and group members will be able to
participate with one another more comfortably and they won't feel that they arc
being judged in any way and will therefore share their own opinions and views.

171
Project Management

Norming
After Storming, the team may enter into the norming stage. Team members adjust
their behaviour to each other as they develop work habits that make teamwork seem
more natural and fluid. Team members often work through this stage by agreeing on
rules, values, professional behaviour. shared methods, working tools. During this
phase, team members begin to trust each other. Motivation increases as the team
gets more acquainted with the project.

Team leaders of the team during this phase tend to be participative more than in the
earlier stages. The team members can be expected to take more responsibility for
making decisions and for their professional behaviour.

As team members get to know each other better, their views of each other begin to
change. The team feels a sense of achievement for getting so far; however some
members can begin to feel threatened by the amount of responsibility they have
been given. They would try to resist the pressure and revert to storming again.

Performing
In performing stage, the group is ready to focus attention on task accomplishment.
Issues of interpersonal relations, roles and responsibilities are settled. These high-
performing teams are able to function as a unit as they find ways to get the job done
smoothly and effectively without inappropriate conflict or the need for external
supervision. Team members have become interdependent. By this time, they are
motivated and knowledgeable. The team members are now competent, autonomous
and able to handle the decision-making process without supervision. Team Leaders
of the team during this phase are almost always participative. The team will make
most of the necessary decisions. Even the most high-performing teams will revert
to earlier stages in certain circumstances. Many long-standing teams will go through
these cycles many times as they react to changing circumstances. For example, a
change in leadership may cause the team to revert to storming as the new people
challenge the existing norms and dynamics of the team.

You have now understood how teams form & perform. However, it is the
responsibility of a team leader to keep the team highly motivated, he must give the
direction and analyze the performance of every team member. Like an individual, a
Team also has personality which is a composite mixture of individual personalities.
A good team leader knows the personality of team players as well as the collective
personality of a team. Management theories explain several personality models such
as Myers-Briggs Type Indicator, Keirsey Temperament Sorter, Fundamental

172
Unit 7 Togetherness: Mruntging Team

Interpersonal Relation Orientation Behaviour, Kahler Process Communication


Model. The list doc~ not stop here; hundreds of such models exist. These personality
models help in controlling and managing team. We will overview some of them.

7.4 ACCESSING PERSONALITY

Myers-Briggs Type Indicator


This is also called as MBTI personality model and is widely used to assess the
personality of an individual. With this model, personality of an individual can be
accessed by asking questions. The test is generally conducted by professional formally
trained in its use. This model is based on the theory of psychological types described
by C.G. Jung. The basic principle of the theory is that the variation in human behaviour
is actually quite orderly and consistent and predominated by how the individual
uses his perception and judgment. The model works on four dimensions of human
behaviour as described below.

1. Introvert - Extrovert (1, E)


With this type, we can identify the source and direction of motivation of
individual. Introvert persons are generally isolated from crowds. They can
perform well individually while extrovert person enjoy working with others.
Introvert persons arc self directed and their source of energy depends on their
internal word and not on the external things while extrovert persons get
motivation from the external things.

2. Sensing - Intuitive (S, N)


This type defines how an individual accesses the information. Sensing
personalities access data based on empirical and sensory data. Sen.c;;ing persons
pay attention to physical reality that they receive through five senses such as
see, hear, touch, taste and smell. Sensing persons like to see the practical usc of
things and learn best when they sec how to use what they learn. Intuitive person
pay attention to meaningful patterns and abstractions. For example, thinking a
problem through than actual experiment.

3. Thinking - Feeling (T, F)


This type defines how an individual processes information and takes decisions.
Thinkers make decisions based on objective and impersonal facts. They like to
analyze pros and cons and are not influenced by emotions. While Feeler take
decisions based on their personal values, opinions of others involved in decision

173
Project :Management

making. These people are caring, warm and tactful. They maintain good
relationship and harmony with others.

4. Judging- Perceiving (J, Jl)


This type describes how an individual likes to live and show the behaviour.
Judgers organize all life events and act strictly according to their plan. They are
well organized and feel comfortable when decisions arc made. They want to
bring everything in life under their control. Perceivers arc open to seck different
alternatives. They prefer flexible and spontaneous way of life. They like to
understand and adapt the world as it is rather than organize to their comfort.

Keirsey Temperament Sorter

Keirsey temperament sorter is a tool that can be used to a<;sess an individual, team
work and in organizational analysis. This is closely related to MBTI and derived
from the work of David Keirsey in his book "Please understand me".

Keirsey identified the four temperaments described below. These arc further broken
down into eight roles and sixteen role variants.

1. Artisans: They are observant and pragmatic. Seeking stimulation and virtuosity,
they are concerned with making an impact. Their greatest strength is tactics.
They excel at troubleshooting, agility, and the manipulation of tools, instruments,
and equipment.

The two roles are as follows:

• Operators are the directive Artisans. Their most developed intelligence


operation is expediting. The attentive Craftcrs and the expressive Promoters
are the two role variants.

• Entertainers are the informative Artisans. Their most developed


intelligence operation is improvising. The attentive Composers and the
expressive Performers arc the two role variants.

2. Guardians: They are observant and cooperative. Seeking security and


belonging. .they arc concerned with responsibility and duty. Their greatest
strength is logistics. They excel at organizing, fadlitating, checking, and
supporting. The two roles are as follows:

174
Un'tt l '\'ogc\hcrncss: Managing 'Icam

• Administrators arc the directive Guardians. Their most developed


intelligence operation is regulating. The attentive Inspectors and the
expressive Supervisors are the two role variants.

• Conservators arc the informative Guardians. Their most developed


intelligence operation is supporting. The attentive Protectors and the
expressive Providers are the two role variants.
3. Idealists: They are introspective and cooperative. Seeking meaning and
significance, they are concerned with personal growth and finding their own
unique identity. Their greatest strength is diplomacy. They excel at clarifying,
individualizing, unifying, and inspiring.
The two roles are as follows:
• Mentors arc the directive Idealists. Their most developed intelligence
operation is developing. The attentive Counsellors and the expressive
Teachers arc the two role variants.

• Advocates are the informative Idealists. Their most developed intelligence


operation is mediating. The attentive Healers and the expressive Champions
arc the two role variants.

4. Rationals: They are introspective and pragmatic. Seeking mastery and self-
control, they are concerned with their own knowledge and competence. Their
greatest strength is strategy. They excel in any kind of logical investigation
such as engineering, conceptualizing, theorizing, and coordinating.

The two roles are as follows:


• Coordinators are the directive Rationals. Their most developed intelligence
operation is arranging. The attentive masterminds and the expressive field
marshals are the two role variants.

• Engineers are the informative Rationals. Their most developed intelligence


operation is constructing. The attentive Architects and the expressive
Inventors are the two role variants.

FIRO-R:

The FIRO-B tool measures your interpersonal needs in three areas. This is a multiple
choice questionnaire developed by W.C. Schutz. According to Schutz, all human
possess three basic needs as Inclusion, Control and affection.

175
Project Management

1. INCLUSION

The need for Inclusion relates to forming new relationships and associating
with others. It determines the extent of contact and prominence that a person
seeks. Descriptors include: belonging, involvement, participation, recognition,
distinction.

2. CONTROL

The need for Control relates to decision making, influence, and persuasion
between people; it determines the extent of power or dominance that a person
seeks. Descriptors include: power, authority, influence, responsibility,
consistency.

3. AFFECTION

The need for affection relates to emotional tics and warm connections between
people;

It determines the extent of closeness that a person seeks.

Descriptors include:

Personal tics, consensus, sensitivity, support, openness,

For each of the three interpersonal needs - Inclusion, Control, and Affection -
the FIRO-B instrument also provides a measure of how much each need is
expressed or Wanted by you.

These are some sample personality models we discussed. These test needs in
depth knowledge in respective area. We cannot rely on a single test and define
the personality of a person; however it gives some information about the
motivation factors of an individual.

7.5 MOTIVATINGTEAM
Motivation plays a very important role, it is essential for personal achievement or success
of a project. To perform is the responsibility of a team player; however to keep the team
highly motivated is the responsibility of a project manager. Motivation keeps people moving.
Without execution, greater plans arc meaningless. It docs not matter how well you planned,

176
Unit 7 Togetherness: Managing Team

how accurate your schedule and budget is less and until your team does not start working,
you will not reach the project goal. Hence one must possess the motivation skills as it
helps in personal growth as well as team growth.

It is interesting to know what motivation is and understand various theories and techniques
that can be used in motivation.

What is motivation?

Motivation means removing inertia and putting one into action. Actions accelerate because
we want to gain something or we want to avoid something. For example, if you want to get
up early & do exercise, the motivation either works in towards direction or away from
direction; means if yon do the exercise, you will be looking smart, the feeling ofbeing
smart makes you motivated, this is called as towards motivation and if you do not exercise,
you will feel dull and face lack of energy, here you are motivated to do exercise because
you want to avoid dullness. You will understand the importance of motivation when you
ask your team to maintain documentation. ProgrJrnmcrs arc generally lazy in documentation
& you need to motivate them.

We will overview some of the motivation theories:

l\llaslow's Hierarchy of Needs

In 1960, psychologist Maslow had developed theory of human needs. According to him,
human needs are hierarchical in nature, that means people get motivated to satisfy their
basic needs first and once these needs arc satisfied, they strive for satisfying next higher
need and that keeps them continuously motivated till they satisfy the top need in hierarchy
that is self actuali:t.ation need.

Maslow's hierarchical needs include 5levels as shown in Figure.

1. Physiological need:

Physiological need is the basic need. This is the strongest need for which every
human being strives. They are the literal requirements for human survival. If
these requirements are not met (with the exception of clothing and shelter), the
human body simply cannot continue to function. Hence this need comes first in
hierarchy. Some of the physiological needs include:

Breathing, Water, Food, clothes and shelter.

177
Project Management

Fig. 7.1: Maslow's Hierarchy of Needs

2. Safety needs
Once all the physiological needs are satisfied, the individual's safety needs
take over and dominate their behaviour. These needs have to do with people's
thirst for a secure and orderly life in which injustice and inconsistency are
under control. In the world of work, the safety m~eds manifest themselves in
such things as preference for job security, personal security, financial security,
health and well being, insurance against accidents, protection from threats such
as storm, riots, etc.

3. Social needs
After physiological and safety needs arc fulfilled, the third layer of human
needs is social. This psychological aspect of Maslow's hierarchy involves
emotionally-based relationships in general, such as: Priendship, togetherness,
family support, etc.

Humans need to feel a sense of belonging and acceptance, whether it comes


from a large social group, such as clubs, office culture, religious groups,
professional organizations, sports teams, or small social connections such as
family members, intimate partners, mentors, close colleagues. They need to
love and be loved by others. In the absence of these elements, many people
become susceptible to loneliness, social anxiety. This need for belonging can
often overcome the physiological and security needs, depending on the strength

178
l:nit 7 Togetherness: Managing Team

of the peer pressure. lt has more importance in team because first two needs are
not directly concerned with team behaviour; however a person isolated may not
work well with other.

4. .Esteem Need
Do you think that people get striving once all their basic, safety and social
needs are satisfied? Answer is partially yes and no since not necessarily all
human beings strive further for achieving more. Esteem need is a higher
psychological need. All humans have a need to be respected, to have self-esteem,
self-respect. People need to engage themselves to gain recognition and have an
activity or activities that give the person a sense of contribution, to feel accepted
and self-valued, be it in a profession or hobby. Imbalances at this level can
result in low self-esteem or an inferiority complex. People with low self-esteem
need respect from others. They may seck fame or glory, which again depends
on others. It may be noted, however, that many people with low self-esteem
will not be able to improve their view of themselves simply by receiving fame,
respect, and glory externally, but must ftrst accept themselves internally.

Most people have a need for stable self-respect and self-esteem. Maslow noted
two versions of esteem needs, a lower one and a higher one. The lower one is
the need for the respect of others, the need for status, recognition, fame, prestige,
and attention. The higher one is the need for self-esteem, strength, competence,
mastery, self-confidence, independence and freedom. The last one is higher
because it rest~ more on inner competence won through experience.

5. Self-actualization
This is the top most need in Maslow's hierarchy of needs. Very few people
reach to this stage. People will strive for self actualization needs when and only
when all previous needs arc fully satisfied. Self actualization need is more of a
philosophical need and the realization of one's potential to do that which a
person was "Born to do''. Consider the example of Microsoft owner Bill Gates.
He achieved everything that does not mean he cannot be motivated further. He
is still motivated for achieving more; he is doing more for society.

Herzberg's Motivation-Hygiene Theory:


Fredrick Herzberg conducted studies to quantify what factors inf1uence satisfaction
at work and he recognized two factors that affect the attitudes of employee towards
the work. These two factors are Motivation and Hygiene. If these two factors are

179
Project Management

properly managed, team can achieve high level of performance. He stated that these two
factors conuibute to employee's behaviour at work. He found that presence of certain
factors does not motivate but the absence of these factors can de-motivate employees.
This factor is called as Hygiene factor or "dissatisfiers".

Motivators:
Motivators influence satisfactions based on fulfilment of higher level needs. The higher
level needs could be achievement, recognition, the work it<>elf, responsibility, advancement
and growth. These factors have long lasting impact on the performance of an employee.

Hygiene }'actors:
These factors are related to work condition and environment in which employee is working.
In good working environment, people work even better. Some of the factors that affect
the performance are company policy, supervision, interpersonal relations, working
conditions, salary, status, security, personal life. According to the theory, absence ofjob
can create job dissatisfaction; however presence does not motivate or create satisfaction.
The effect<; of Hygiene factors arc temporary. For example, salary rise will have its impact
for a short period while if you provide growth and recognition, its impact will be longer on
employee's performance.

Douglas McGregor, an American social psychologist, proposed his famous X-Y theory in
his 1960 book 'The Human Side of Enterprise'. Theory X and theory Yare still referred
to commonly in the field of management and motivation, and whilst more recent studies
have questioned the rigidity of the model, McGregor's X-Y Theory remains a valid basic
principle from which to develop positive management style and techniques. McGregor's
XY 'Theory remains central to organi7,ational development. and to improving organizational
culture.

X-Y-Z of Motivation
McGregor suggested two theories, nan1ely X and Y; in the theory he describes two
fundamental approaches to managing people. Many managers tend towards theory
X, and generally get poor results while other managers use theory Y, which produces
better performance and results, and allows people to grow and develop.

Theory X ('Authoritarian Management' Style)


The theory states that average people dislike work and will try to avoid work if he/
she can. Theory assumes that people are inherently lazy and follow the path of Iea11t
resistance. Therefore people must be forced to work with the threat of punishment and

180
Unit 7 Togetherness: Managing Team

need to be motivated by money and positions to do work towards organizational objectives.


These people need to be directed and controlled. The Authmitarian style of management
works well with lazy people.

Theory Y ('Participative Management' Style)


The theory states that people will put their effort in work as natural as they play. People
will apply self-control and self-direction in the pursuit of organizational objccti vcs, without
external control or the threat of punishment. Commitment to objectives is a function of
rewards associated with their achievement. People usually accept and often seek
responsibility. The capacity to use a high degree of imagination, ingenuity and creativity in
solving organizational problems is widely, not narrowly. distributed in the population. In
industry, the intellectual potential of the average person is only partly utili;.red.

Theory Z - William Ouchi


This theory is developed by William Ouchi in 1981. Theory Z is more popular in Japan
and hence often referred to as the 'Japanese' management style. Theory Z essentially
advocates a combination of all that's best about theory Y and modern Japanese
management, which places a large amount of freedom and trust with workers, and assumes
that workers have a strong loyalty and interest in team-working and the organization.
According to this theory, workers want to usc their productive time in obtaining more
rewarding experience. They would like to be a part of the enterprise goal and contribute
their efforts. If the organization culture is aligned accordingly, they will be able to achieve
goals. Some of the key characteristics of Japanese organizations are life time employment
that gives them job security, slow promotions and infrequent evaluations, non-specialized
career paths and collective decision making & responsibility. By implementing the Z theory,
Japanese led their high quality products in the world.

The Equity Theory:


We are learning various motivation & behaviour theories with the objective ofleaming
how to build a team, how to motivate and retain team. Motivating and retaining team
becomes a challenge. Employee turn over is quite high in IT industry except during recession.
Why people move? The basic reason is that for more monetary gains and higher work
opportunity.lb retain good employees we must understand the equity principle. We studied
Maslow 's hierarchy of needs and other factors but there is one more factor that can
influence behaviour of an employee. The factor is feeling of equity that means every one
expect~ that he/she should be treated equally and fairly. It is a very common behaviour that
employees discuss an1ong each other & compare their salaries. If they feel that their salary
is less than the co-worker, their morale & performance can seriously affect and in extreme

181
Project Management

cases employee may leave the job. To retain the employee, management should treat
everyone in a fairly manner & the rewards should be based on their performance and not
on individual relationship.

Employees compare their work and the pay with the following:

• Compare salary of co-worker holding same position.

• Compare salary of other companies paying for same position.

• Compare their salary with the rewards they get in different times.

• Compare their pay to other individuals holding different positions.

In reality, the performance, responsibility, skills and experience are unique


characteristics and due to this, it is not possible to decide the standard pay rate for
different positions. However, certain factors can be considered while fixing the salary
of a person such as deciding the level of performance expected from employee,
access the actual performance of employee, linking pay rate proportional to desired
pedormance, analyzing conflicting situations. Overall the project manager or HR
manager should see that everyone is treated equally and fairly.

7.6 HUMAN llliSOlJRCE PLAc~NING

In large software projects, different resources of different skill sets are required. HR
planning is the responsibility of the project manager. Generally, HR plan includes
no. of resources required along with the skill set. Also, PM defines the tean1 structure
and defines formal channels of communication and reporting.

Roles & Responsibility:

Roles and responsibility give clarity to individual. Example of roles could be


Programmer, Analyst, DBA, Quality auditor, etc. Role is a way of classifying skills
that is useful in matching resource requirements to particular people when developing
the human resource plan for a project.

The Human resource plan contains

• Total no. of resource required role wise

• Costing information and assumptions including Perks, Allowance.

182
L'nit 7 Top:cthcmcss: Managing Team

• When the resource is needed and for how long.

• Any special skills required over and above those that people in the specified
role would normally be expected to have, as well as the required level of
proficiency and the relative importance of these skills.

• Training requirements needed specifically for the project, for example in a new
technology such as UML.

• Office and Hardware requirements

• Plans for team-building activities

The Human resource plan supports resource planning, resource acquisition and
supervising project specific training activities. A summary of the human resource
plan is created for the entire project and managed by the project manager.

The formality with which the human resource plan is created and documented is a
reflection of the size and complexity of the project. Typically. small projects do not
require a formal plan. On the other hand, large, multiyear, multilevel projects with
many participants may require multiple formal plans. The HRM plan is based on
the project schedule.

The Project management schedule includes a summary of the effort by human


resource category (expressed in person hours, person days, etc.) that will be required
to perform defined work units, as well as the time frames during which the work
units will be performed. For example, the project management schedule might
indicate that 1000 hours of Java programmers are needed for three months from Jan
to Mar.

The human resource plan uses the requirement for human resources to develop a
plan for staff acquisition. There is usually iteration between the development of the
project management schedule and the human resource plan as "reality'' is applied
during development of the human resource plan during the different phases of the
project. For example, for a very large project, it may be known that it is impossible
to obtain the 100 programmers specified in the project management schedule during a
particular time pcricxl. Therefore, the project management schedule will need to be changed
to reflect this.

111e human resource plan may be revised when changes in the Project management schedule

183
Project Management

for a project organizational unit result in a change in staffing requirements. Also, the results
of recruiting activities could impact the human resource plan.

7.7 TEAMSTRUCTURE

The team structure defines the roles, responsibilities and reporting relationships of the
people managing and working within a project organizational unit. Well organized team
structure will help to optimize the efforts of the team and the success of the project. An
inappropriate one can undercut the efforts of a hard working group of people and impede
their success. This process is performed during planning phase. Often, it is carried out by
the functional managers/senior management responsible for the people who will staff the
project. The project manager should influence the functional managers to ensure that the
team structure meets the requirements of the project. The first consideration in organizing
a team is the objective of the team. Has the team been asked to explore possibilities and
alternatives? Is the team charged with solving a complex, poorly defined problem? This is
often the case with study projects or when implementing a new technology. Broadly, there
arc two different organizational approaches: In the normal approach, each team is
responsible for a specific set of activities and the work products move between the teams
according to a predefined work flow. 'Inc team members all have similar skills.

In the multidisciplinary approach, each team is responsible for completing some of the
work productll. The team members have different skills and possibly arc multi-skilled.

Certain project approaches favour certain team structures. For example, mpid application
development (RAD) works best with multidisciplinary teams.lt is necessary to have a
team structure so that all the members of the project understand their roles and their
working and reporting relationships. However, all team structures introduce some mea<;ure
of inflexibility. It is important to understand that there is no "right" team structure for a
project and that usually it depends on the organizational requirements and needs of the
project.

Roles & Responsibilities

Let's discuss some of the roles & their responsibilities:

Sponsor:

Sponsor can be an individual or organization who provides funds to the project. If the

184
Unit 7 Togetherness: Managing Team

organization is developing project for external customer, then external customer may fulfil
the role of customer ac; well as sponsor, otherwise senior management of performing
organization acto; ac; a sponsor if project is initiated for performing organization. Sponsor is
a prime stake holder of the project; hence he can interact and intervene in all phases of
projects from initiating to closing. Sponsor's prime responsibility includes funding, providing
initial information regarding the initial scope of the project, determines priorities and
constraints, act~ as spokesperson of the project, approving final project plan, guides team
on risk and provides expert opinion, defines the reporting and communication requirement
of senior management. During monitoring and controlling phase, he may enforce quality
policy, resolve conflicts that are beyond the control of the project manager.

Project Manager:

Project manager is responsible for the overall management of the project. He is accountable
for project failure as well as project success. We have seen various organization structure
and the levels of authority the PM can enjoy in that structure. His main responsibility
includes project planning, direct execution, monitoring & control, and formal closure.

Team:

Here team means group of people who arc responsible for actual execution of the project.
The team may include Architects, Progran1mers, Testing and Quality Personnel. The
responsibility of the team includes identifying stakeholders, gathering requirements,
identifying constraints and assumptions, providing effort estimates, attending review meetings,
perfonning actual task such as designing, coding, testing, documentation, etc.

Stakeholders

Stakeholders are the individuals who are directly or indirectly ac;sociated with project and
who can negatively or positively influence the projects. The stakeholder's role is generally
defined by the respective organization, that means customer's user roles are generally
defined by their project managers. Stake holders are responsible for preparing initial scope,
requirement elicitation, change management, risk management, etc.

7.8 MANAGING CONl'LICTS


Every team member is performing ac; per the plan, customer is delightful and senior
management is happy about the project performance is a very rare and ideal situation
in software development projects. Disagreement and conflict management becomes
regular for a project manager. No one wants conflicts and tries to avoid it; however

185
Projt.:ct Management

conflicts are good for improvement and are inevitable consequences of organizational
interactions. Most of the common sources of conflicts are schedules, priorities,
resources, technical opinions, administrative procedures, budget and personality of
a team member. For example, in global implementation of product, there arc always
conflicts between priorities of different countries. Due to cultural difference and
local government policy, there is always conflict of prioritization. Managing conflicts
is the responsibility of the project manager, therefore he must possess better
communication and negotiation skills and techniques to resolve conflicts between
either internal stakeholders or external stakeholders.

There are various ways to manage conflict<;; let's overview some of them:

• Confronting:

Confrontation is same as problem solving. In problem solving we go to the root


cause of the problem and resolve conflict at the root level. This type of conflict
resolution is highly favoured due to its proactive nature as it deals with the root
cause of the problem and not the person.

• Compromise

When two parties sacrifice something for the sake of reaching an agreement, it
is called as compromise. The technique involves finding solutions that bring
some degree of satisfaction to both parties. This is a Lose-Lose situation since
no party gets everything. For example customer may add one important change
few days before the final implementation; this can delay the schedule, increase
risk and cost of the project. As a PM you do not agree because it was not
mentioned in the initial scope statement; however after negotiation, customer
agrees to pay extra cost and accept postponed schedule.

• Forcing:
As the name implies, people are forced to abide by the decision. There arc
some compelling situations in which the manager docs not have any options.
This technique is generally applied when other techniques fail. Forcing is
considered to be the worst way to resolve conflicts. Forcing does not help resolve
the underlying problems; it reduces the morale of the team.

• Accommodating:
This style indicates a willingness to meet the needs of others at the expense of

186
Unit 7 Togetherness: Managing Team

the person's own needs. The accommodator often knows when to give in to others,
but can be persuaded to surrender a position even when it is not warranted. This
person is not assertive but is highly cooperative. Accommodation is appropriate when
the issues matter more to the other party, when peace is more valuable than winning,
or when you want to be in a position to collect on this "favour" you gave. However,
people may not return favours, and overall this approach is unlikely to give the best
outcome.

• Withdrawal (Avoidance)
This is not a special technique, rather it's a phenomenon. Most of the time
people try to avoid conflicts and hope that problem will go away itc;clf.

7.9 INFLUENCING
Influencing is a skill. It determines the impact of the project manager on his/her
team. This is one of the important skills that we are discussing. You cannot become
a leader just by reading and understanding various motivation theories and techniques
of people management. All these skills arc important when you have sufficient power
and authority. Influencing determine why people obey their leader and why the
orders or even genuine suggestions of other leaders arc just rejected by team members.
Influence determines the impact of an individual on his followers. The impact may
be clue to formal position, authority and power or the personality of the individual.
Now we will discuss various powers that a leader is required to exercise in managing
people.

Reward Power
The reward power refers to the authority and capacity of a leader to reward his
subordinates. If leader has more reward power, more people will obey him and his
influence on team will likely increase. The rewards can be praise, recognition, support;
these arc mostly attributed to the personality of the leader and other rewards such as pay
rises, promotions and other facilities that every organization authorizes leader to use at his
capacity.

Coercive Power
Leaders can exercise this power by punishing their subordinates. This is the negative side
of the authority. Leader influence their subordinates positively by giving rewards or
negatively by punishing. The degree ofpunishment a leader can exercise varies with authority,
position given by organization and mostly depend on the situation and organization culture.

187
Project Management

Some of the examples of coercive power are no praise & credit of work, holding promotion
and pay rise, insult and in extreme circumstances termination. Most of the people get
generally influenced by the fear of negative power of their leaders.

Legitimate Power
This power is legal power a leader can exercise to influence subordinates. The legitimate
power generally determined by the position and role of a leader in the organization.
Organization gives such power to various positions to maintain the organization policies,
norms and procedures. Subordinates are obligated to comply with such requests because
of the norms accepted as a legitimate by all members of the organization. This power is
independent of the personal characteristics of the leader and he has to exercise this power
in legal framework.

Expert Power:
This power is purely the characteristics of a leader. The power belongs to the knowledge,
and the level of experience leader possesses in his domain. For example a leader with vast
hands on experience in latest tcchnolot,'Y can enjoy this power to influence his subordinates.
Subordinates expect guidance and expert advice many tines during execution. Subordinate
follows their leaders and perform well if they find that their leader is competent and
knowledgeable than themselves. In IT industry, due to intellectual nature of the work, this
power is in high demand.

Referent Power:
Referent power is a form of power that is based on respect or the charismatic personality
of the manager. It is the ability of leader to persuade his subordinate. This power can be
used by aligning the less powerful leader with more powerful leader. For instance, if the
project manager is very close to the CEO of the company, subordinates will follow him
due to his close aligns with CEO. 'This power is generally used in social & political campaign.
For example, company uses referent power of the famous movie actor or famous sportsmen
in their advertisement. ft is believed that due to charismatic power of a leader, their sale
will go up. This power is generally used by political parties to resolve the conflicts. This
power has very less application in IT industry.

7.10 SUMMARY

In this unit, we started our discussion with the meaning of the word team. Mutual Trust,
Openness, Honesty and Coordination are essential factors in team formation. We discussed
the basic team formation model which describes the four stages of team building such as

188
Cnit 7 Togcthcmcss: Managing Team

forming, storming, norm ··1g and performing. If a leader knows the motivation drive for
each team member, he can better lead his team. We discussed various theories with which
we can access the type of personality such as 'Myers-Briggs Type Indicator, Keirsey
Temperament Sorter and FIRO-B. Motivating team members is the prime responsibility
of the team leader; hence we discussed various motivation theories and techniques such as
Maslow's Hierarchy of Needs. Maslow arranged the needs in hierarchical format that
indicates an individual will strive to satisfy the next higher need once his lower need is
satisfied. The needs are physiological need, safety need, belonging and love, esteem needs
and self actualization where physiological is lowest & inevitable need without which one
cannot survive and self actualization is top most need in hierarchy. According to Herzberg's
Motivation-Hygiene Theory absence of certain factors such as working conditions may
demotivate and reduce the performance of an individual or team; however its presence
will considerably incrca-;e the perfom1ance. McGregor suggested two theories X & Y and
according to theory X, people arc inherently lazy, do not want to work unless and until
they are forced and motivated while theory Y suggests that people are naturally motivated.
Theory Z is the combination of Japanese style and theory YAccording to equity theory,
every individual expects fairness and equality in the rewards. We overviewed the contents
of human resource plan. team structure and the roles and responsibility. Managing conflicts
within team or outside team is the responsibility of a project manager. We studied various
conflict management techniques such as Smoothing, Confrontation, Withdrawal and
Compromise. Influence of a leader in HR management plays a very important role in HR
management; hence we studied various powers such as expert, legitimate, coercive, reward
and referent powers that leader can exercise to influence his team.

7.11 SELF-ASSESSMENT QL'ESTIONS


1. Explain the basic model of team building.

2. Explain Maslow's Hierarchy of needs.

3. List various roles &responsibilities.

4. Name various models that can be used to access the personality of an individual.

5. According to you, what should be the characteristics of a great team?

6. Identify 10 hygiene factors that can decrease the performance of a team member.

189
Project Management

8.1 L~TRODUCTION
- - - -- - - - - - - - - - - - - - - -
In the first unit, we sn1dicd what project management is and the skills we must
possess to be effective in software project management. Project management is an
application of knowledge and skills. In previous units we studied various knowledge
areas. This unit covers the most important skill that is communication that everyone
must possess to be successful in every walk of life and in particular knowledge
based industry like information technology.

We arc fan1iliar with word communication and from our childhood we arc using it
for different possible ways for different purposes. Generally, we acquire the
knowledge first and then apply that knowledge and improve our skills to solve the
problems. But since our childhood we have practiced ample communication skill,
we still do not have the basic knowledge of communication process. Our existing
communication skills are limited only to convey our meaning either by spoken or
written words. To be effective in your role, you must possess these skills. It becomes
mandatory and if you are weak in communication you will have very limited chances
of making your project as well as your career successful, hence as a first step
understand the basics of conmmnication and then practice and sharpen. Although
here we discuss about the basics of communication, its application varies with the
person, society, culture. Communication is a dynamic activity and one can
communicate inn number of ways to nmnbcr of people with the style appropriate to
his personality and need of the audience.

In software development, we usc communication most frequently unlike other


activities such as planning, scheduling, risk management, etc. Software development
being an intellectual activity unlike other products, the inputs and outputs to software
are presented in terms of information. Without the aid of communication, we cannot
give input to the software process. The main role of communication in software
project is to exchange information. In other words, we can say communication is a
tool or an instrument that carries the raw material (Information) to the software
development process. ff anything is defective, either instrument (communication
process) or raw material (Information/requirements), that affects the quality of
software and thus leads projects to failure.

In this unit, we will specifically discuss the basics of communication process, various
baniers of communications and theories associated with communication process.
As the theoretical part discussed here is general in nature. You can apply in your day
to day life and improve further.

194
Cnit 8 Be Effective: :\fanaging Communication

8.2 IMI)ORTANCE OF EJ?FECTIVE COM..'\1lJNICATION

To understand the importance of communication, we must pay attention to what the


famous management guru Peter Ducker quoted '"One's effectiveness is determined
by once ability to reach others through the spoken or written word. Thus
communication is perhaps the most important skill.'' Through extensive research in
many projects, it is found that projects can substantially fail due to poor
conmmnication despite of technical competence. It is estimated that an effective
project manager spends about 90% of his time on communication out of which 50%
of the time is spent on communication with the project team. That means every
temn member sue~ as external stakeholders, project leads. quality persons, testing
temn, development team, analysts spend most of their time in exchanging information
with one other. Broadly we can say that project team activities are divided into two
parts; one is communicating and the other is doing actual work like programming,
testing, etc. As major portion of your project's duration is utilized in cmmnunication
process, the communication process itself becomes risky and critical. If you cannot
manage communication properly. the major portion of project duration will be mere
waste.

Usually, communication happens with two or more persons. Due to complex &
unique nature of human beings one standard formula of communication will not fit
and become a more dynamic activity. Thus communication becomes more of a
psychological activity than logical activity. As your team grows in size and is
dispersed across countries of different culture, language. etc. the activity becomes
more complicated.

Communication is the circulating blood of the projects. It is not just merely limited
to exchange of information and reporting, it can further be used for forming and
motivating team, negotiating with stakeholders, maintaining documentation. It is
proved that people (Project Team) follow the leader (Project Manager). As a leader
he must clearly communicate with his team, provide guidance. listen to their problems
and all these c<mnot be achieved without the proper combination of personality and
communication skills.

If we treat communication as a general activity and not give much importance, due
to this no one could easily relate it to problems. You take any problem and you will
find that some portion of it is attributed to communication. We take conmmnication
activity casually and do not know how much time we are spending on such activity
and how much worth it is.

195
Project .Management

In software projects, we usc communication to gather requirement, present the project


proposal, maintain document, monitor & report status and manage stakeholders.
Communication skills help project manager in resolving the conflicts & negotiating.
The communication may occur with two persons situating in one place or with
hundreds of other team members locating at different parts in collaborative
environment. Software industry realized its importance and various theories and
communication models are being continuously evolved to manage communication
effectively.

In the nutshell, we can say that communication is an important skill in software


project management because of its wide scope, integral and complex nature, impact
on time & budget, impact on team motivation & formation, importance in negotiation.

1. Find out how much time you spend on talking, writing?

2. How much time usually does a Project Manager spend on communication?

3. Explain the importance of communication in project management.

196
Unit 8 Be Effective: Managing Communication

4. rind out the difference between communication & effective communication.

5. What factors add complexity to communication process?

6. Why is communication called as a dynamic activity?

8.3 WHAT IS COMMUNICATION'!

In our day to day life, m<my times we share our expressions, feelings, thoughts with
others with some intention. At the same time, we also provide feedback to others.
The process of exchanging thoughts or information with others is called as
communication. The communication takes various forms as per the situation. For
example, if your project manager is presenting information about the project, then it
is official and formal communication while if you are sharing a movie story with
your friend, it is informal & personal communication. Generally, all communication
has some specific intent behind it. In the above example, your project manager
wants to share how the project is going to be executed so that team members align
themselves with the project. There are various reasons why communication triggers;
most of them are specific intents, feelings, access information, convey message,
share information, give direction, etc. In the communication process, we presume

197
Project ~anagcmcn l

that the other person with whom we are sharing the information is not aware of the
information; however in exceptional cases such as reminder notices we may exchange
same information repeatedly. We can convey our message or information through
spoken word or through written words or through proper body languages. The
communication involves an our five senses & their proper coordination is important
for effective communication.

8.4 COMMUNICATION l)ROCESS

Communication is a two way process. It needs atleast two persons present without
which communication is not complete and meaningful. For the sake of simplicity,
we may call the persons as sender and receiver.

For example, if two persons are communicating with each other, then one of them is
sender of the information and other is the receiver of the information. Sender and
receivers are roles played by two persons and these roles can be interchanged
interactively, that means second person becomes sender of information and so on.

The communication process is illustrated in the following figure:

Sender I Rec-eiver

Encode Encoding~ Message Decoding:) Decode

Write f Read
I
Feedback
Speak I
Listen

~'ig. 8.1

In the process. sender first encodes the message in a proper format that is readable
to receiver and transmits over some media. Then receiver receives the message and
decodes it. Receiver can send feedback to sender and complete the communication
process. Feedback is important in any communication. In figure three lines are shown
for feedback. first line indicates receiver only received message, second line indicates
the receiver understood the message and the third line indicates receiver acted upon
the message. An effective communication must possess all the processes depicted

198
Unit 8 Be Effective: Managing Communication

in the figure. These all processes arc interactive in nature and involve many other
things that cannot be shown in the figure such as the level of understanding of both
persons, style and form of communication, personal beliefs and attih1des. etc.
However, all such other parameters arc important in effective communication. For
example, I'm communicating with all of you about the knowledge and practices
used in software project management. Here I assume that you have some basic
knowledge & prior experience in software technology. Instead if I teach you some
concepts of medical science, then you may not be able to understand or relate with
your experience and the purpose of communication may be a total failure. Hence
before communicating we must know that the receiver holds some relative
knowledge.

The two main functions of the communication process arc encoding and decoding.

Encoding: In communication, the sender has to first create the message for this, he
must know what he wants to convey. Consolidating or grouping of idea or thought
or emotion into an understandable format is called as encoding. We can encode &
express our thoughts, ideas, expressions in written words, spoken words or any
form of body language. While encoding, the sender must ensure that the level of
understanding of the receiver and the encoded message is complete in all respect.
For example. you just say "Today is my birthday", what should the receiver
understand from it? Whether you expect a greeting from him. or you want to invite
him for a party, etc. In the above example, message is not completely encoded and
may create confusion. On the other hand receiver interprets the messages received
with prior experience, knowledge or relation with the sender. In the above example
assume that you are a good friend of the sender; with this relationship, you may
interpret the above message as if you forgot your friend's birthday and need to
immediately greet him. Likewise, you can have many interpretations of the same
statement. The language that we use in communication does not carry the full meaning
& docs not have full control on what others may interpret, hence encoding & decoding
plays a very important role in effective communication.

To understand the communication process, macro activities of sender and receiver


are described below; however as these activities are very micro in nature. you cannot
separate out from each other with every communication. Our brain is habituated
with all these activities, hence we cannot able to visualize or sense in our day to day
communication. You can use these activities to do the analysis of your communication
and improve any gaps to avoid miscommunication.

199
Project Management

Activities of the sender

The sender perfom1s the following activities:

1. Decides what he wants to convey

2. Encodes the message

3. Decides the media to be used, for example written words or spoken words of
body language

4. Send the message to the receiver

5. Wait for feedback & reopen the communication or close the communication

Activities of the receiver

l. Decides whether he wants to receive the communication

2. Decodes the received message

3. Prepares the feedback response

The other processes are same as sender since he is now communicating, hence he
becomes the sender and the other person becomes the receiver. The same
communication loop may occur repeatedly till the objective of the communication
is achieved.

~Activity B:

l. Explain the two main functions of communication process.

200
unit 8 Be Effective: Managing Communication

2. Identify the activities of sender and receiver.

3. Explain briefly the communication process.

4. Explain the term encoding & decoding.

5. Explain the importance of feedback in effective communication.

State True or False

1. Sometimes we talk to ourselves is an example of communication.

2. Communication needs atleast two persons.

201
Project :Vlanagcmcnt

3. While communicating, we usc only spoken or written words.

4. Communication is a one way process.

5. Feedback is mandatory for receiver.

8.5 COMPONENTS OF COMMUNICATION

Understanding of clements of communication process will help us to understand ·


the process better.

1. Encode: Translates thoughts or ideas into a language that is understood by others.

2. Channel: Two or more persons without their present communication do not


take place.

3. Message: The output of encoding in the form of idea, thought, information,


feelings, etc

4. Medium: Communication needs some form of media to pass on the message,


for example spoken words over voice, written words on paper, electronic mail
through internet, etc.

5. The code: The language used to convey message for example, English, French,
Hindi or the body language.

6. Relation: There is always some sort of logical relationship between the sender
and the receiver, for example two friends can communicate with each other,
project manager and his team, boss & subordinate, parents and their child, teacher
and students, speaker and audience, etc.

7. Noise: Anything that interferes with transmission and understanding of message.

8. Decode: Translates the message into meaningful thoughts or ideas.

Ingredient of Communication:

Communication is not just sending & receiving messages or reading & writing
processes or speaking & listening in an activity. Communication process involves
some other visible and invisible factors and we must know them to be effective
communicators.

202
Unit 8 Be E1Iective: Managing Communication

Visible factors: Visible means we can sense, hear or sec such as voice, words,
actions, physical appearance, etc.

Invisible factors : These arc micro factors that we cannot see, hear or sense and
they arc the self image, beliefs and values, emotions and thought processes.

8.6 BARRIERS OF COMMUNICATION

Most of the time, we experience that the message that we want to convey is not
completely understood or interpreted by the receiver or we may not get appropriate
response from the receiver through feedback. Such kinds of scenario are symptoms
of miscommunication. We must know what factors can affect the communication
process. The factors that create obstacle in smooth communication arc called as
barriers of communication. Once we know the barriers, we can practice to reduce
these barriers. Barriers keep us away from understanding other ideas and thoughts.
Barriers can appear at any time during the communication process. Broadly, we can
classify the barriers into two parts. internal and external.

Internal barriers: Examples of internal barriers arc lack of interest in the message,
poor listening skills, attitude towards the sender or information, fear, mistrust.
negative attitude, past experience, lack of common experience and emotions.

External barriers: Examples of external barriers include noise, distractions, internet


problems, telephone line problems and disconnections, etc.
The most common barriers observed are:
The language: Language is the main barrier of communication. Language of both
persons should be same; otherwise receiver cannot understand the message. For
example, imagine what will happen if I write the text book in Chinese language and
assume that you do not know Chinese language

Vocabulary: We generally use some technical jargons or specific words. If the sender
and receiver do not have common vocabulary, then that may lead to
miscommunication. Suppose I asked what is !\TV or BCWS which stands for Net
Present Value and Budget Cost of Work Scheduled, the receiver may not be able to
interpret it because he may not be familiar with the project management concept<>.
This may quite often happen with new strange words, hence need to be avoided.

Culture: Every country is having their own cultural codes and symbols that have
special meaning. For example, when two Indian meet with each other, they say
''Namaskar''. If an Indian person says Namaskar to a person in America, he may not

203
Project ~anagcmcnt

be able to interpret it. To avoid such problems when the team is dispersed across the
nations, usually cultural awareness programs arc conducted which explain the
participant-; the code of conduct, etiquettes of other countries.

Context: The context about which you are communicating must be familiar to the
receiver. For example, the receiver may not be familiar with software development
project management and you are communicating with him about various terms used
in schedule development. The receiver must be familiar with the current context
and need to have some relative prior experience, then and then only can the receiver
can decode the message completely and give you appropriate feedback.

Voice: The quality of voice, pronunciation, accents, etc. play a very important role
in effective communication. For example, the person in US/UK generally speaks
faster and their accents and pronunciation may not be clear to other people outside
these country.

£5 Activity C:

1. Identify various harriers of communication.

2. Discuss how these baniers of communications can be removed.

3. List various mediums that can be used in communication.

204
Cnit 8 Be Effective: Managing Communication

4. To improve your vocabulary, identify new words and understand their meaning
and try to use them.

8.7 TYPES OF COMMUNICATION

There are various ways, forms and styles of communication that we use in our day
to day life as per the needs of the situation. For example, the formal communication
used when the senior members or stakeholders are called for a presentation on new
project. Informal communication is generally used when the team is sma11 in size
and the team members are very well known to each other. Similarly, you can usc
different modes of communication, for example mobile for urgent call or SMS, e-
mail for written communication, etc . You must know various modes of
communication and acquire skills in that particular type of communication. Some
of you may he good at written communication but may or may not be effective at
oral communication or vice versa. During software development, most of the project
manager's time is spent on reporting and communicating and needs other skills
such as listening, writing, presentation, soft skills, negotiation and influencing. All
these skills are needed for effective communication.

These skills are the key to executing good management skills. With good management
skills, you can have a team of members who together create an ambience of open
communication, concise messages, probe for clarifications, recognize non-verbal
signals, and mutual understanding. Good communication involves a set of complex
skills.

There are mainly three types of communication skills; expressive skills, listening
skills and skills for managing the overall process of communication. The basic
fundamental of all these types of communication is emotional skills.
Expressive skills arc required to convey messages to others through words, facial
expressions and body language. We cannot necessarily use the same language for

205
Project Management

writing as well as speaking. There are various tribal languages which do not have
any script, they arc only used for verbal communication. Gesture can also be used
for effective communication; rather gesture can increase the effectiveness of
communication. Gesture uses various parts of the body such as face, hands, neck,
eyes, lips, etc to express various emotions and non-verbal signals, for example most
of the people nod their heads while listening or speaking. This type of communication
is mostly used by the parents to control their naughty child in front of others. Also,
gestures are used by deaf & dumb persons to express their feeling. Gestures are
based on commonly accepted and understood protocols such as cupping your hand
ncar your mouth for asking water or you can usc figure and thumb to show that there
is a phone call. However, we cannot usc gesture in every communication due to
limitation of body language. We cannot teach subject to masses for longer duration
with just mere gestures.

Listening skills are skills that are used to obtain messages or information from others.
These help to clearly understand what a person feels and thinks about you or
understand the other person closely.

Skills for managing the overall process of communication help to recognize the
required information and develop a strong hold on the existing rules of
communication and interaction.

Hierarchical Communication:

Every organization has its own organization structure that defines the hierarchy of
their persmmel. For example, who will report to whom, e.g. lower management
staff or the subordinates should report to their bosses. The communication that flows
from lower management to the middle management or middle management to top
management is called as upward communication. Generally, orders or instructions
arc given by top management to middle and middle to lower management who are
actually executing. The flow of communication is from top to bottom, hence called
as downward communication. Many a times you observe that employees seek
information or share their information, opinions across their co-workers of the same
rank, such type of communication is called as lateral or horizontal communication.
In all of the communication, hierarchy acts as a barrier. Generally, subordinates are
not open to their bosses and as a project manager you need to establish proper rapport.
Unlike other industry, there is no much hierarchy in software industry. Usually, all
team members express their opinions, suggestions freely.

206
Unit 8 Be Effective: Managing Communication

Formal & Informal Communication

In software project management, many a times you have to access the information
from your co-workers and put them in proper format and report to customer or top
management. Though accessing information and presenting information arc part of
communication, they differ on the approach adopted to perform such activity.

Formal communication: Formal communication is structured and pre-planned.


That means what to communicate, whom to communicate, when to communicate.
etc. is already pre-defined. It includes standard language, reporting templates and
maintains the hierarchy. For example various status & progress reports, etc. are
usually communicated through formal methods. Formal communication executes
in controlled environment. Most of the time, decisions are based on the facts received
from the formal communication. Formal communication increases the reliability of
the information.

Informal communication: It is not always possible to access the information through


formal channels. For example, to access the employee morale you need to discuss
with them openly. You cannot ask direct questions, you need to be more informal,
then and then only employees share sensitive information. As compare to formal
communication, informal communication is less formal, less controlled and more
open. Generally, this type of communication is used to access the preliminary
information. Informal communication does not follow hierarchy of information.
The organization culture is so open that any subordinate can discuss with any senior.
It is found that informal channel gives more information & because of open
environment, employees can share their information freely without any barriers.

Oral vs. Written Communication

Oral communication is direct face to face communication between two or more


persons. In oral communication, the sender and receiver exchange their thoughts or
ideas verbally either in face-to-face discussion or through any mechanical or electrical
device like telephone, etc.

When it is face to face, the person conveying can ask questions or sometimes when
the communication is not understandable in a proper manner. he can elucidate its
meaning. He can use different gestures and postures to convey meaning. Oral
communication is generally possible where there can be either a direct contact or
message to be conveyed of impermanent nature. Meetings and conferences, lectures
and interviews are some examples of oral communication.

207
Project Management

Advantages of Oral Communication

• It has the distinct advantage of being quick and prompt. It provides the
opportunity to both the sender and receiver of the message to respond directly.

• Oral communication facilitates close contact and thus promotes mutual exchange
of thoughts, information, understanding and support.

• Oral communication through direct contact undeniably inculcates a sense of


self-importance in the subordinates, which successively acts as an inspiring
element.

• It also helps in bringing a responsive and supportive morale among employees


of an organization.

• Oral communication further allows the superior to make a rapid evaluation of


subordinate's action as well as reaction to any message transmitted.

Disadvantage of Oral Communication

• Due to dynamic nature of oral communication, there could be possibility of


variety in the language used. Variation could be from geographical or social
and cultural differences. As compared to written communication, it is less
organized & less controlled.

• As it is an ongoing process, receiver needs to comprehend it fast otherwise


receiver may miss some part of the speech that can create confusion.

• We cannot use oral communication as evidence in case of conflicts unless and


until every speech is recorded and it is not practically possible to record every
oral communication.

• Oral communication is not possible to convey message to widely dispersed


team with different languages and cultures.

Written Communication

Communication through words may be in writing or oral. Written communication


entails transmission of message in black and white. It mainly consists of diagrams,
pictures, graphs, etc. Reports, policies, rules, orders, instructions, agreements, etc.
have to be conveyed in written form for proper functioning of the organization.

208
Unit 8 Be Effective: Managing Communication

Written communication guarantees that everyone concerned has the same


information. It provides a long-lasting record of communication for future. Written
instructions are essential when the action called for is crucial and complex. To be
effective, written communication should be understandable, brief, truthful and
comprehensive.

Advantages of Written Communication

• There is no fear of interruption from the audience & you can take your own
time.

• It ensures transmission of information in a uniform manner.

• It provides a permanent record of communication for future reference.

• It is an idealistic way of conveying long messages.

• It ensures little risk of unauthorized alteration in the message.

• It tends to be comprehensive, obvious and accurate.

• It is well suited to express messages to a large number of persons at the same


time.

• It can be quoted as legal evidence in case of any disputes.

• It allows use of graphics such as diagrams, pictures, graphs

Disadvantages of Written Communication

• Immediate feedback is absent in oral communication.

• Non-reciprocal nature of written communication makes it more difficult to learn.

• Writer cannot judge the reactions of audience and change the contents instantly.

• Written communication is costly and time consuming.

• It becomes difficult to maintain privacy about written communication.

• Written communication is very formal and lacks personal touch.

209
Project Management

• It may be represented in a different way by different people.

• 'Ve can express thoughts or convey ideas in a more organized way and there is
less chance of omission.

• You can reread & rewrite the contents which is not possible in oral
communication.

£)Activity D:

1. Explain various types of communication.

2. Explain the merits and demerits of Oral V s Written Communication.

3. Discuss the merits and demerits of informal communication.

4. What skills contribute to effective communication?

210
Unit 8 Be Effective: Managing Communication

5. rind out the languages which do not have scripts.

6. You are the project manager and you want to hire programmers. Which form of
communication would you usc to communicate your resource requirement to
the HR manager?

7. Which mode of communication would you adopt in the following cases?

a) You want to convey status of the project to stakeholders.

b) You are in design phase and you want to brainstorm ideas.

c) You want to call an urgent meeting.

d) You want to resolve the conflict among two programmers.

Managing Communication in Software Projects:

By now you arc familiar with what is communication and the parts of communication
process. You arc also familiar with the various types of communication and the
barriers of communication. In this section. we will discuss how to manage the
communication in large projects.

Imagine the difference when you talk to a known person or your team and when you
talk to a stakeholder which includes customers, team members from various countries.

2 11
Project Management

As the team size grows, number of channels increase and that adds complexity to
your communication. During project execution, you have to select & apply
combinations of skills that we've discussed in the first part of this unit.
Collectively communication management is a process of communication planning,
information gathering & distribution, information storage and retrieval & reporting.

8.8 COMMUNICATION PLANNING


Communication planning might be a totally new concept for you. We indulge in day
to day communication that may not require a detailed communication plan. To avoid
conflicts and misunderstanding effective communication insists on making the plan
before you communicate.
The main objective of communication management process is to provide only
required information and with the right format at the right time. Every stakeholder
has various information requirement from the project, for example customer is
interested in knowing the status of the project, whether change request is properly
incorporated, whether documentation is self-explanatory, etc. and your team may
have information requirements such as software requirement specification, design
documents, etc. and the project sponsor needs to know the progress of the project,
how funds arc being utilized, whether project can finish in time and given budget,
etc. Sometimes you may need to pass on the information to an outside agency who
is outsourcing and some information to government authorities and auditors, etc.
Above all, the project manager is not only responsible for communicating with every
stakeholder, but with the entire team involved in the communication process; however
the overall responsibility remains with the project manager.
Imagine a team of 200 people spread throughout the world, speaking many different
languages with many different cultural ways of communicating and you will realize
how planning is worth doing and the time that you require to communicate across
such a huge team. As the team and its information requirement grow in size, it
becomes necessary to define,
• Who will communicate with whom?
• What information will be included in project communication?
• Which project stakeholders will receive the information?
• How often the information is distributed & updated?
• What technology is used to transfer the information broadly defined in the
project communication plan?

212
Unit 8 Be Effective: Managing Communication

Communication Channels

First thing you need to do in communication planning is to identify the number of


channels that exist. The communication channel defines the possible paths of
communication across the project team. Communication channel determines the
complexity of communication. By adding just a single resource in the existing team
increases the number of communication paths, hence you must know how to calculate
the number of channels.
The number of channels are calculated as:
Channels = n(n-1 )/2
Where n is the number of people on the project.
Now let's calculate the number of channels that exist in a team of 200 people. By
substituting value of n = 200 we will get,
Channels = 200(200-1 )/2 = 19900
If your team size is 200, then you have totall9,900 channels open for communication.
This is quite a big figure for imagination, but in reality it is there for large project<>.
All channels may not be necessarily active at a time. Some of them arc official
channel and you need to formally respond to them. It is not practically possible to
control all paths, however with proper communication management plan you can
control any large team infom1ation. The figure below illustrates the communication
paths that exist in team of four resources.

Fig. 8.2

213
Project Management

As per the formula. the number of channels that exist in team of four people =4(4-
1)12=6. Total six channels exist and are shown by lines.

The next thing you need to do is analyze the communication requirements of the
stakeholders, for example your customer may ask you to provide status reports.
Here you will have to analyze what information should be included in status format
and the frequency, for example initially weekly status report can be generated. As
reporting is a tin1e consuming process, you cannot generate. decide in what format
status is reported and you have to make sure that every week customer will get the
status report. Once stakeholders information requirements are frozen, the next you
will have to do is decide the appropriate communication technology used as a means
for conununication. Some of the questions described below wi 11 help you to determine
the appropriate selection of technology.

• Would it be better to communicate the information through an e-mail or


telephone call?

• What technology is the team familiar and comfortable with, for example video
conferencing, chatting, etc?

• Should I send a letter through mail? Since most of the time people ignore emails
and do not respond to emails, however it becomes compulsory for them to
respond to receipt of conventional mail through post.

• How quickly do I need to communicate the information?

After doing communication requirement analysis, all the gathered information is


presented in tabular format called as communication management plan. The sample
communication form is shown below:

What needs to Purpose To whom Method of Frequency By


be communicated Communication Whom

2 14
lin it 8 Be Effective: Managing Communication

The communication plan can be more exhaustive. You can even add templates or
formats that you want to communicate. In frequency, you can write if it is weekly,
monthly, etc. or you may write specific due date of the document. To whom describes
the name of the person who is going to usc the information and by whom is the
person responsible for sending the information. In the first column, you can write
the brief contents of the report or name of the standard rcpmt. Inclusion of purpose
will add quality. Most of the time people generate lots of redundant information.
The redundancy can be avoided if you mention purpose. Redundancy is a time wasting
activity for sender as well as receiver of the information .

.£6Activity E:

1. Explain the importance of communication management in software projects.

2. Assume that 5 new resources are added to your existing team of 5 re..<;ources
calculate total number of communication path or channels.

3. Find out more information on Video conferencing and Web Meetings.

215
Project Management

4. Do you think that time is an important factor in effective communication?

5. What do you think & suggest to avoid redundancy in communication?

6. Explain briefly the contents of the communication management plan.

7. What other information do you require to prepare communication management


plan?

8.9 MANAGING MEETINGS


Meetings are one of the important and essential activities in project management.
Project starts with a kick-off Meeting and during project execution, many a times
team members and customer representatives are called for meetings. It is found that

216
Unit 8 Be Effective: Managing Communication

on an average 25% to 75% time is spent on attending meetings. Managing meeting


is one of the important skills that every manager must possess. Communication
skills play a very important role in managing meetings. In large software projects,
these meetings are planned during communication management planning.

Meetings arc generally called to officially convey some messages or exchange


information, to discuss some important issues, to take unanimous decisions. Meetings
are conducted many a times during project execution. Meetings are generally held
before the beginning and ending of each phase and major milestones achieved.
Meetings help in planning, and evaluation can be used to make all the stakeholders
aware of how the project is progressing. Each meeting has a specific purpose and
various meetings such as status meeting, review meetings, group meetings can be
called during project execution.

Type of meetings
Broadly, meetings arc classified into two groups as one to one meetings and group
meetings.

Group meetings: In formal meetings, generally more than one person is involved.
As group is involved, more communication paths are open, hence group or formal
meetings are more structured, planned and generally last longer. There is a chairperson
or facilitator required to control the group meetings.

One to one meetings: These meetings are more informal and the project leader can
meet the team member individually. These arc short meetings and arc called when
individual opinions are important. These meetings are generally held to convey
confidential or sensitive information. Many a times, it is conducted to gather
individual opinions because people generally do not share their opinions in public.

Role of a Facilitator:
The facilitator is responsible for the overall success of meetings. His main job is to
control the meeting and keep people on track when they deviate from the main
objective. His main tasks include selecting and inviting pru.1icipant for meetings,
deciding the agenda, recoding opinions of participant on paper, concluding the
meetings and closing meeting in a fruitful manner. Depending upon the situation, he
can get an assistant to help him in showing slides, taking notes, writing on the white
board, etc.

217
Project :vtanagcmcnt

Role of Participant:
Meeting participants are generally expert or executors, who can offer suggestions,
share their views, help in generating alternatives. Generally. participants arc related
to the subject of the meeting. For example, in design review meetings participants
could be chief architects, database designer, subject matter experts, etc. They play
an active and responsible role needed in information sharing, problem solving and
decision making.

Coach:
Coach is a role and usually can be played by the facilitator of the meeting. The role
of coach is optional. Depending on the needs and maturity of participants, separate
coach is invited to guide the meeting. The role of mentor is to improve the quality of
meeting. He provides unbiased views and notes the behaviours of the participants
that made the meeting go wc11 or totally fail.

Tips for conducting effective meetings:


Provide an agenda ahead of time
Before calling a meeting, decide the purpose of the meeting and agenda of the meeting
and send it to participants before the actual meeting so that participant can prepare
well and present actual necessary facts in the meeting. · Most of the time, meetings
are called all of a sudden and purpose of the meeting cannot be mitigated. Thumb
rule is that people get fmstrated with such unmanaged meetings and tend to avoid if
such meetings become a routine of their work.

Set a time limit and keep to it


As per the need and purpose, fix the duration & time for the meeting. One hour is
usually sufficient for routine meetings; however for brainstorming and problem
solving session, meetings may last longer than hours. Time of meeting is also
important. It is observed that energy levels of team members arc not constant
throughout the day. Esually performance is slow after lunch hours and mid afternoon.
If you call a meeting in this span for 3 hours, most of the participants may not be
hundred percent attentive.

Bring the right people together


Before meeting decide who is needed to be invited, who can make the meeting
fruitful, does the participant have enough expertise in the related field. Many a
times it is found that the meeting room becomes a war room due to unexpected

21&
Unit 8 Be Effective: Managing Communication

behaviour of the participants. Not all the participants possess right communication
skill to express their views and draw conclusions.

Stick to agenda
Most of the time during discussion. people surf from one point to another and lead
meeting in different directions. It is the responsibility of all participants to express
only relevant views and should not divert the discussion. In case such a situation
arises, facilitator must intervene and get back to the main agenda.

Let people know their responsibility in advance


People are generally not aware why they are called for a meeting. Roles and
responsibility make their thinking clear about what is to be done. Once they know
their roles, accordingly they can share their views. For example. suppose you called
a meeting to decide the budget of the project and the participants arc not aware that
they arc supposed to share their views on budget they could not even speak a single
word & your meeting will serve without purpose.

nocument meetings
Document every minute of the discussion. decisions and deliverables. Include list
of participants along with their roles and responsibility, venue of the meeting, date
and time of the meeting. Take the signature of participant on minute of the meeting.
This documentation can be used for future reference in case of disagreement among
the participant.

Defme rules of the meeting and lead accordingly


Formal meetings arc well planned ru1d structured. Before calling a meeting, decide
rule of meetings such as purpose of the meeting, expected duration of the meeting.
expected deliverables, roles and responsibilities of the participants, the level of
freedom given to participant to share their views, etc.

Assign deliverable to participant


Once the discussion is over, write down actions to be taken and delivcrablcs preferably
with time frames. At the end conclude meeting with positive outcomes and objectives
achieved.

2 19
Project Management

8.10 COMPLEMENTARY SKILLS FOR EF'FECTIVE COMMUNICATION


Basic communication skill includes one's ability to speak, read, write and listen. Usually
we possess these four skills for one or more languages.} Iowever, to be effective you need
to optimize those skills. Some important skills that are complementary to communication
skills are presentation skills, listening skilL<>. We will quickly overview each of them.

Presentation Skills
The presentation skills deal with how you present your ideas to the audience. The
presentation skills can be used to present your product feature to customer or project
presentation to the sponsor. There are so many occasions where you need to present
your ideas. Presentation carries the impression of your product and organization
and builds the perception of the product. Quality of presentation boosL<; the confidence
of customer in your product. People are more inclined towards the perception than
actual facts. A good presentation helps in better comprehension of the idea conveyed.
Unlike meetings, here the presenter presents the idea first and if required, question
and answer session can be kept at the end of the presentation.

A good presenter must possess certain qualities & abilities such as proper use of
body language, confidence, controlled use of humour, usc of graphics, voice
modulation.

Tips on Effectual Presenting

To be effective at presentation you need to have combination of skills. Some skills


arc inherent, however few of them you can learn. After all keep in mind '"Practice
makes a man perfect.

1. Positive attitude and confidence is a must for effective presentation. If you arc
not confident about what you are saying and carry negative feeling, you will
not be able to generate interest of audience in what you arc talking.

2. Keep presentation time short. 20 to 40 minutes are sufficient for conveying


ideas.

3. Make yourself acquainted with the infrastructure in the conference room. Check
whether the microphone and over head projector is working well.

4. If you arc using PowerPoint, keep all slides organized and do not exceed bullets.
Average 5 points per slide are reasonable.

222
I:nit 8 Be Effective: Managing Communication

5. Adjust & modulate your voice. Monotonous speech makes the audience bore; to
avoid this change the pitch of sound.

6. Logically organize the structure of your presentation.

7. Assess the knowledge & expelience level of your audience before the presentation
and try to map their knowledge level & give appropriate example if required.

8. Get feedback from the audience and make sure that everything discussed is clear to
them.

Listening skills:

We know that effective communication requires that the communication loop is completed.
That means the receiver has understood what the sender is talking about. There is difference
between hearing and listening. While studying you may be hearing valious sounds or may
be hearing some music but your attention is concentrated on study. Effective listening
means paying attention or concentrating on what we are hearing. Only hearing words docs
not guaranty that you have understood the message. People are generally preoccupied
with their thoughts and they may not be actively listening. Active listening involves our
mind, all senses and our attitudes and belief system. Active listening process entail hearing,
focusing on message, comprehension and interpretation, analysis and response.

8.11 SUMMARY

In this unit, we discussed the communication process and its importance in software
development. The basic communication model comprises of sender. receiver and
encoding and decoding of message. Communication is said to be complete and
effective when the receiver has completely understood the message. We also saw
the barriers and visible, non-visible ingredients of communication. We discussed
hierarchical communication, formal vs. informal and written vs. ora] communication
and their merits and demerits. In large projects, communication requirements of
stakeholder are gathered and accordingly communication plan is prepared which
describes what is to be communicated, frequency, purpose. responsibility, etc. In
large teams. number of communication path increases as team size increases and
that further adds to the complexity. We have also seen how meetings are to be
conducted and discussed, various roles and rules of the meeting. At the end of this
unit, we overviewed complementary skills.

223
Project Management

9.1 INTRODUCTION
In this unit, we will discuss about the risks that can occur during project execution
and how to manage them. We will explore various risk management tools and
techniques. Risks are directly related to cost and time. Risk has substantial impact
on these two important constraints. An effective risk management strategy will save
your time & money. How many of you are aware about the risks that we take
everyday? Life is full of uncertainties; we don't know what will happen next and
each such happening has either negative or positive impact on our life and the things
we do. All such future events are probabilistic, unforeseen and beyond our control.
In a life, we don't have control on the things such as theft, illness, accidents, loss of
job, etc. We can call them as risks. These risks threaten our future life with loss of
money, loss of career, etc. When such events actually happen, we immediately need
to mitigate those risks. One of the risk mitigation strategies could be to get the
insurance cover with the help of insurance companies. These insurance companies
will help us in the mitigating the fmancialloss. To get the insurance cover, we need
to identify, analyze the probable loss and pay necessary premium. We can do these
activities with the insurance advisor who can provide us various risk management
policies. By insurance cover we can manage and cope with the day to day life risk.
Similarly, software projects are also prone to risks and need to be managed to avoid
huge monetary loss.

By the definition of projects, we know that projects are unique in nature and
progressively elaborated, that means unlike day to day ongoing activities, we arc
not sure about the future outcome of the projects. As we don't have knowledge of
future, problems may occur. Risk management deals with avoiding such problems
by careful planning. As we move ahead in the project, we will have more knowledge;
more knowledge about future will help us in reducing uncertainty. Though uncertainty
reduces as we move ahead, we cannot say risks arc over now. In the initial stage of
software development, risk is high because uncertainty is high.

Unforeseen events may have adverse impact on project cost, schedule and quality.
If risk is not carefully planned and mitigated, project may fail . Although we cannot
predict the future we can still minimize the impact of risk by careful risk management.
We can reserve some budget to handle such a situation. As software projects arc
large and complex in nature and the loss may be many million dollars more, emphasis
is given to formal approach to risk management. Risk varies with project to project
and organization to organization. The formal approach provides guidelines, with
which we can systematically identify, analyze and mitigate the risk. Risk management

228
Unit 9 Be Proactive: Managing Risks

is integral to project and needs to be managed from project initiation till closure.
The capability, experience and judgment of the project team and the project manager
are crucial for managing the risks.

In this unit, we will discuss about what risk is & how to manage, how to identify and
assess risks, we will also discuss the various risk models available.

9.2 WHAT IS RISK'?

Risks are future unforeseen and uncertain events. Risks are probabilistic in nature
means such event may or may not occur and in case it occurs, has a harmful or
negative impact on a project. Every risk has two common characteristics such as
uncertainty and loss or impact. For example, unknown virus wipes out the entire
data of the project. In this example, we don't exactly know the kind of virus that will
attack and when it will attack. However, it is oblivious that due to such attack you
will have to loose your valuable data. Other example could be your project need to
be integrated with third party software. If the third party docs not provide their
modules & necessary support in time, your project may get delayed. With this
definition, you can find ample risk examples in your projects.

All risks will not have always negative impact on the project. Such risks are called
as opportunity risks. If we take that risk, we gain the benefits either in monetary
terms or improvement in process and perfmmance. In project management, we need
to take such tisks, for example hiring experienced and costly resources. Though we
arc paying high cost, experienced resources can fmish the task 10 times early than
non-experienced resource. Here we are paying extra cost than usual as a premium to
avoid the schedule failure. On the contrary, the risk having negative impact will be
called as threats.

Characteristics of Risk

Risk characteristics arc the attiibutes of the risk and these characteristics play an
important role in risk management. It is not enough to just know what risk is. To
analyze, plan and mitigate the risks, we must know the details of the risks. These
details can be expressed as characteristics of the risk. Few of the characteristics
have already been discussed such as risks are probabilistic in nature and are uncertain.
These two characteristics will help us in the identification of risk. For example, you
can list down those activities which are uncertain. For example, though you know
that virus attack will corrupt important data, you are not sure whether it will affect

229
Project :Ylanagcmcnt

your system. Once you list those uncertain activities, you can find the probability of
their occurrence. Other things you need to know about the risk are impact of risk,
the timing of risk, frequency of risk. As risks arc unforeseen and uncertain, we may
not get every detail such as time. frequency for every risk. However, one should try
to get the details. The main focus of risk management is to minimize the knowledge
gap of the future event and minimize the impacts.

Impact: Impact of risk can be financial loss, for example, due to delay the customer
rnay charge penalty or even in extreme cases he may terminate the project. Sometimes
reputation of business will be at stake due to mismanagement of the project.

Time: The timing defines at what stage and when the risk will occur. The impact of
risk may vary with respect to time.

·Frequency: The frequency of risk determines how frequently risk can occur. Though
the chances arc less. the same risk may appear many times.

Ri~k tolerances: Every organization has certain capacity to withstand the impacts
of risk, for example. management may tolerate 5 to 10% increase in the initial
schedule and budget. This capacity defines the tolerance limit of the risk. If the
impact of the risk crosses this limit it becomes unacceptable. This extreme limit is
called as threshold of the risk.

Another important nature of risk is that, it may induce another risk, for example, if
your estimation fails, it will further fail your schedule and budget.

/6 Activity A:
1. Identify the risks in library management system.

2. Find out the characteristics of identified risks and present them in a tabular
format.

230
Unit 9 Be Proactive: Mana_ging Risks

3. What skills do you need to manage the risks?

- - - - - - - - - - - - -- - -- - -- - - - - -

- - - - - - - -· - - - - -- -- -

9.3 RISKS IN SOFTWARE PROJECTS


- - - - --
Risk can occur any time during the project. There can be few risks or a large number
of risks. Fmther the risk can occur in any software development process. Occurrence
of risk can affect the schedule, budget, quality of the project; hence it must be
important for us to understand the types of risks and the potential sources of risk.
While understanding software project risk, we need to look at the various sources of
potential risk and sources of risk could be project risk. technical risk and business
risk.

Project Risk: Potential source of project risk could be from various project processes
such as project planning, execution. controlling. etc. Projects are complex
undertakings and due to their unique nature. project plan may itself be a risk (ff not
carefully planned or if plan is made by non-experienced person). Some of the other
potential project risks arc project estimation, budget and schedule.

Technical Risk: The great source of technical risk is technology itself. Technical
risk has serious impact on the quality and schedule of the project. For example,
project team working with new technology such as object oriented programming.
may delay the project schedule due to not having enough hands-on experience with
new technology. Technical risk could arise due to over-optimistic attitude of the
team. Many of the times, the novice programmers working on new technology
experiment with new features. These features may not be fully supported by the
software vendor that can cause bugs in software.

Business Riiik: Business 1isk considerably affects the revenue of the business. New
developed software not fitting with the core strategies of the business, newly launched
software product not appreciated by the customer or product failure due to weak
marketing are the examples of business tisk.

231
Project Management

Unlike the hazards of daily living, the risks in software projects must often be learned
without the benefit of lifelong exposure. A more deliberate approach is required.
Such an approach involves studying the experiences of successful project managers
as well as keeping up with the leading writers and thinkers in the field. One such
writer in the area of risk is Dr. Barry W. Boehm. In his article "Software Risk
Management: Principles and Practices" he lists the following top 10 software risk
items:

1. Personnel shortfalls

2. Unrealistic schedules and budgets

3. Developing the wrong functions and properties

4. Developing the wrong user interface

5. Gold-plating - giving extra than required

6. Continuing stream of requirements changes

7. Shortfalls in externally furnished components

8. Shortfalls in externally performed tasks

9. Real time performance shortfalls

10. Straining computer-science capabilities

16Activity 8 :
1. List down the potential sources of the risk.

232
Unit 9 Be Proactive: Managing Risks

2. Categorize each potential source of risk in to project risk, technical risk and business
risk.

3. Compare life risks with project risk.

9.4 RISK MANAGEMENT


Why do we have risk? The answer could be two-fold one reason is that no one could
possess complete knowledge of future events, specifically about when an event will
occur, the other reason could be our past or present mistake that may be a risk for
tomorrow.

Over the period, software industry is mature enough and is able to identify potential
risk. Many common sources of risks arc known, such as virus threats, hardware
failure, power outage, etc. However, we cannot predict when that event will occur.
For example, we cannot predict when power will go off or predict when the hard
disk will crash. Both of these events arc risks since they can cause huge potential
loss. If one could posses complete knowledge, we need not bother about risks as we
would know certainly what is going to happen in the future and accordingly we
could plan and try to minimize the impact of consequences.

Now let us understand how our past and present mistakes or indecisiveness can
trigger risk in future. Assume that despite issuing many warnings, if one of your
programmers could not perform well, then you need to replace him with another
efficient programmer. If you don't take appropriate action, your project schedule
may get delayed. Here your project schedule is at risk. Another most common scenario
is, if requirements arc not properly taken, your project may have potential risk of

233
Project Management

project failure. In both the examples, if you control the present situation, you could probably
minimize impact of the risk.

The main objective of risk management is to minimize the potential impact of risk
when it materializes. Usually, risks can be dealt with proactive as well reactive
strategy.

Reactive Strategy:

Most of the projects fail because they do not have risk management plan. Project
teams adopt wait and watch approach. If anything bad happens, they start working
around with trials and errors. Reactive strategy is not advisable. Imagine that you
are handling one of the very large and complex projects. Your team leader assumes
that as a hardware system is recently installed and there won't be any hardware
failures. He/she docs not bother to take the backup of the source and the
documentation, and unfortunately a new virus attack corrupts the entire data.

Proactive Strategy:

Plan Analyze Mitigate

Fig. 9.1

But to professionally manage the project, one should adopt the formal proactive approach
to risk management in which risks are well ahead planned. The lisk can be proactively
managed by risk planning, lisk assessment and risk mitigation.

Let's take an example and explore how the Risk can be managed. Ac;sume that you
are the project manager of a small software strut-up company and you are developing
software for the client who is residing outside your city. As a part of the end user
training, you invited all customers' key employees for attending the entire day training
program. Now what risk do you think will occur and cause potential loss to carry the
training activity? Let's think what may go wrong. For that, what you need to do first
is make a list of the basic things that you need to carry out for a successful training
program. The list items could be activities, constraints or assumptions. For example,

234
Cnil 9 Be Proactive: Managing Risks

you need to have one conference hall. computer. software and projector (if required) and
most importantly the trainer and customer's end user. If anything fails, your activity may
totally fail and your position will be at stake. UsuaJly we organize and coordinate the
components of the activity. But imagine what will happen if a11 of a sudden power goes off
or the trainer could not reach in time due to traffic or in extreme cases if the trainer could
not come due to illness. Imagine the frustration of the customer and loss of his employee's
time. Most of the end users are top management executives and they cannot afford loss
even of one day, just because of power failure. In this case, risk is power failure and loss
could be customer's valuable time and probably you may not get into future, repeat orders
from the same customer. As a good project manager. you should behave like a good risk
taker and not as a fire fighter. It is our tendency to assume that such an event will happen
rarely and we take it casually. If you have a proper risk management strategy. you can
save customer's time if such an event occurs. The simple strategy is to identify all potential
risks such as power failure, trainer could not reach, software crashed during training, etc.
Once all such risk-; are listed out, you can analyze and prioritize. Because there could be
n number of risk<> and you cannot plan them with equal primity. ln the above case, power
failure is the highest risk and needs to be planned in top priority. (Please note that the
example we have taken is of a small company and assume that there is no well equipped
conference hall with battery backup, however in most of t11e large organizations a common
risk management plan is already in place and you need not consider all such risks). Once
risks arc prioritized, what next you can do next is develop a risk mitigation plan. For
example, to mitigate power failure risk; you need to identify and analyze the altematives
such as arranging generator backup on rent or search for conference hall equipped with
battery backup. You can also think ofpurcha-;ing UPS/inverter for your company. Likewise
you can keep other trainers ready and ask them to carry out training without computer aid.
Each such altemative is further analyzed for cost. The purpose of the analysis is that you
should not spend much cost on risk mitigation. The risk mitigation cost should always be
less than the cost ofrisk due to losses, otherwise what is the point in doing risk management.

By now we have enough idea about what risks are <md how they occur. We also overviewcd
how to manage such risks. Now you can also identify various risks, however identifying
risk of a larger project is an overwhelming expelience. You may get confused with which
risks are to be included in the project and which ones are to be excluded. To avoid such
confusion, risks are f wther classified into three types such a.':> known-known risks. known-
unknown risk and unknown-unknown risk. I -et's try to understand each one.

235
Project Management

£5Activity C:
1. List down the activitics of risk management.

2. Find out various alternatives to mitigate the risks illustrated in the above example
and suggest the most cost effective alternative with sufficient justification.

3. Compare proactive risk strategy with reactive strategy.

9.5 TYPES 0}' RISKS


We discussed that risk occurs due to incomplete knowledge of the future and due to
our past deeds or wrong actions. We cannot exactly predict about the future event,
however we can statistically determine the chances of such event happenings such
risk are usually beyond our control and are classified as external risks. Examples of
external risks are, delays caused by third party vendor, natural calamities like
earthquake, cyclones, heavy rain and floods, diseases like swine flue, etc. These
risks can cause heavy monetary loss, time loss and may result into decreased
employee morale.

236
Unit 9 Be Proactive: Managing Risks

Another category of risk is usually within our control. These risks are predictable.
These risks are mostly concerned with what we have done in the past and its future
consequences. We can minimize the impact of such risks by effective controlling of
the processes. For example, huge employee turnover, increase in number of defects,
etc. By applying proper motivation strategy, we can reduce employee turnover, hy applying
proper quality management techniques we can improve quality by reducing defect<>.

Over the period and with sufficient past project experience, we can imagine where and
what may go wrong but we are not sure whether all such events will be released or not,
and therefore risks arc further classified as Known-Known, Known-Unknown and
Unknown-Unknown risk. The following diagram depicts these three risks along with the
level of uncertainty and the funds used to mitigate them.

,11 'I
Project I
Contingency Management l
Estimate
I

Reserve Reserves It
II - - I
I' ['

.I ~
II
I
I<

\~ ~~
1/ ,;
\'
v

Known-Known Known-Unknown Unkno\\rn-Unkno\v1l

Uncertainty

Fig. 9.2: Risk 1)rpes


Known-Known Risks
Most of the time we know what will generally happen and about its probability to
happen in the current project. In other words, we know the types of risk as well as the
impact of the risk. Here both the parts are known hence called as known-known types of
risks. We can get the knowledge about such events from our experience or others' past
experience.

As we know well in advance, the occurrences of such events and we have complete
information about what may go wrong, we can mention such information in the

237
Project Management

project management plan and keep ready the risk mitigation plan to minimize the negative
impact of such events. Most of such risks are constraints themselves. For exmnple, in
developing countries there is no guarantee of continuous power supply and accordingly
we can plan for necessary power backup like generator set. Ilerc power is the main
constraint that imposes limit on the execution, hence could be the source of the risk.
Another example of known-known risk could be improper documentation and incorrect
requirement'> that could delay the project schedule. Once you know that similar risk may
likely exist in your current project, you can prepare a project management plan and make
it compulsory to your team to adhere to standard templates, conduct timely reviews and
get customer signature on requirement specifications.

Known-Unknown Risks
Many a times we do not have complete access to the full information about any particular
event. We know only a little part of such an event based on our prior knowledge. For
exan1ple, we know certain events such as a key employee may leave the job prior to
project completion, know that increa'>e in number of defect'> can delay the project schedule
and cause cost ovenun, system may crash due to hardware failure or virus threat. However,
in all of the above examples we know what type of risks could occur hut the possibility,
frequency and volume of the risk is unknown to us. J-<or example, how many employees
will leave the job and when or no. of defects that can be found, etc. We know the type of
risk butdon'tknow about the probability & volume ofloss. Hence such types of risks are
called as Known-Unknown risk. Such types of risk are generally taken into consideration
in risk management planning and are clearly described in the risk management plan. Most
of the risks arc assumptions and need to be noted. The unknown part adds complexity to
the management of such tisks. For instance, how can one exactly predict the number of
defects that can he found in the present project'? In such cases we can rely only on the
experience, judgment and confidence of the project management team and the project
manager.

l.Jnknown-Unknown Risks
Can we predict about anything that we do not know? Obviously not possible. A'> a human
being, we have linlitation to our knowledge. In known-known and known-unknown risk
atleast we have some information and data at hand but in unknown-unknown risk, we are
completely unaware of anything that can happen. We cannot identify such risk in advance
since we do not know what kind of risk will appear and the probability of its occurrence.
Managing such risk is really a challenge. These risks can cause severe to less severe
dmnage to the project. A person with sixth sense active can only predict such risks m1d for
rest of us we need to rely on God to tackle such a situation. l Iowevcr, there is one way to
cope up with such an event and it is the contingency budget that we learnt in cost
management. TI1is budget will help us in managing such risk. We cannot avoid such risk

:!38
Unit 9 Be Proactive: :'vianaging Risks

but we can cope with the losses with the contingency plan. Once such an event happens.
then it become known-known or known-unknown and usually recorded in lessons learned
document for future reference.

RS Activity D:
1. Identify two factors with which risks can be bifurcated into three types.

2. Differentiate the risk within our control and risks outc;;ide our control.

3. Explain each risk type with appropriate example.

4. Identify specific plans that can be used to manage each risk type.

239
Project Management

5. Find out the sources of knowledge that can be used to identify risks.

How to Manage Risk

The risks are managed with formal risk management processes. Every organization
follows different strategies to manage risks. The Project Management Institute and
the Software Engineering Institute and Dr. B. Boehm suggested a model for risk
management and is popular among global practices. Let's discuss each of these
models. The following diagram illustrates the basic risk model derived from the
Project Management Institute risk model.

9.6 RISK MANAGEMENT MODELS

I Project Risk Management


I
I
I I I I
Risk Risk Response Monitoring &
Identification Analysis Planning Control
I
I I
Qualitative Qualitative
Analysis Analysis

Fig. 9.3
Project Management institute' s Risk Model consists of six processes namely risk
management planning, risk identification, quantitative and qualltative analysis,
response planning and risk monitoring and control.

Risk management planning process decides how to approach and conduct the risk
management activities of a project. Planning process is comprehensive and also de.<>cribes
other remaining processes.

240
Unit 9 Be Proactive: Managing Risks

Ri~k Identification:

The process identifies the sources of risk, potential risk eventc; and symptoms of risk.
Risk Quantification: Subjective risk information is not enough and need to be further
quantified. By applying qualitative and quantitative techniques, value of risk mitigation
verses value of loss is calculated. That means. how much value of the opportunities is to be
pursued by avoiding potential threats.
Response Planning: The process determines how to mitigate the risk by identifying the
reserves required in both dollars and in terms of efforts.
Monitoring & Control: Once planning is over, project execution begins. During
execution, the planned risk may or may not occur. All these changes arc contentiously
monitored and controlled in this process.
Barry Boehm's Risk Management Model:
Dr. Barry Boehm presented his first tutorial on risk management in IEEE computer
society press in 1989. The following figure describes the basic process discussed in
the Boehm's Risk Management Model.

Risk Identification
Risk Assessment
Risk Analysis

Risk Prioritization

Risk Management
Risk Management Planning

Risk Resolution
Risk Control
Risk Monitoring

Fig. 9.4
Boehm's risk model comprises of two main activities namely risk assessment and risk
control. Risk assessment is further divided into activities such as risk identification, risk
analysis and risk prioritization. Risk control activity is further sub-divided into activities
such as risk management planning, risk resolution and risk monitoring.

Risk Assessment: The first thing you have to do in risk assessment is to identify the
potential risks. Risk identification can be accomplished with various information gathering
tools such as checklist analysis, decision driver analysis and problem decomposition. If

241
Project Management

the project team is having experience in executing similar projects, then known-known
risks can be identified with a checklist. If project domain is totally a new decision, driver
analysis and problem decomposition can be used. Identified risks arc further analyzed for
qualitative and quantitative factors. After risk analysis, the risk priority is decided hased on
the relative potential for occurrence and impact of identified risk on project.
Ri'ik Control: Risk control proces..<:> comprises of risk management planning, risk rc..<.Jolution
and ri'>k monitoring. Risk management can he accomplished with the help of tools such as
consulting risk experts, risk avoidance, risk transfer, etc. Risk avoidance is a means of
finding way to avoid the risk and risk transfer means transfening part of the risk to insurance
agency by paying the premium. Risk resolution is accomplished through prototypes,
simulations, benchmarking, etc. During the risk monitoring process, all risks are tracked
and corrective actions can be taken.
Software Engineering Institute's Risk Management Model
The Carnegie Mellon University's Software Engineering Institute developed a
software risk model. The model is based on Shewhart-Dcming Plan-Do-Check-Act
Cycle. The model provides information and feedback on the risk activities, cuncnt
risk and emerging tisks. SEI risk model comprises of five proces~cs as described
helow.

Fig. 9.5: Software Engineering Institute's Risk Management Model

Identify: Advance searching of risk before it gets materialized.

242
Unit 9 Be Proactive: Managing Risks

Analyze: Transfer risk data into decision making information and evaluate impact,
probability, timeframe and classification and prioritization of risk done in risk analysis process.

Plan: Pl<m describes the risk infonnation data along with mitigation plan & how to implement
those action pl<:ms.

Track: In this process, risk indicators and mitigation actions arc continuously
monitored.

Control: During project execution, if anything deviates from risk management plan
it is to be corrected during control process.

£$'Activity E:

1. Name three risk management models .

2. Which model is based on Shewhart-Deming Plan-Do-Check-Act Cycle?

3. Find out more information on Shewhart-Deming Plan-Do-Check-Act Cycle


and write short note.

243
Project Management

9.7 RISKIDENTIFICATION
Risk identification means identifying what may go wrong during the project. The methods
that can be followed to identify the risk are checklist of potential risk, project survey,
brainstorming and problem decomposition. Checklist is a document that describes what
were the risks on the past projects that have occmTed & what to check during the project
execution. For example, checklist may contain checkpoints such as check for hardware
configmation, sufficient power backup, whether data is archived, whether proper document
is maintained. From these check points, you can identify most common risks that can
occur in the project. Historical records from past projects can help to identify the risks.
Every organization prepares one document called as lesson-learned-document which is
prepared after completion of the project. It broadly describes learning from experience.
Experience may be good or bad. It also explains how the project team tackled any risk.
You can refer to this document to identify the risk. Brainstorming and review of project
survey also helps if the project domain is new to the project team. During risk identification
process, you must understand the company culture and the risk tolerance limit of the
organization. We may not believe but the company culture can be a source of risk, for
example, many organizations do not follow documentation and communication standards,
they do not have well defined roles and responsibilities. This may create chaos and blame
game takes over. Knowing the project background and project scope statement and
charter arc prerequisite for accurate risk identification. The list is endless. Depending on
the complcxity of the project, you can add or eliminate the potential sources of risk. Most
of the project managers tend to identify risk themselves; instead they should involve their
team members in risk identification process. As the team is a discrete composition, team
members can come with risk related to their task, for example, programmers can share
technical risk more effectively than a separate source for identifying all such risks.

We will look at some common sources of risks such as Product size, business impact,
customer characteristics, process definition, development environment, technology
and human resource. With the help of these categories, you can find out sources of
risk by asking relevant questions in that category, for example, if your projects arc
using rational unified framework, you can check whether your team is having
sufficient hands-on experience, otherwise it becomes a technological risk.

Business Impact Risk:

Impact of risk on business can be identified with the following checklist:

1. Effect of product on company revenue

244
Unit 9 Be Proactive: Managing Risks

2. Govemment constraints specific to the product

3. Cost oflateness

4. Whether product aligns with customer needs & the level of sophistication

5. Compatibility of the product with other software

These are some of the checkpoints with which you can find out the business risk.

Customer Risk:
As each customer is unique, they have different sets of needs. The organization
culture, the domain of the customer, their needs for the product can be different for
different customers hence you need to carefully consider all such aspects while
identifying the risk since they can be potential risk to your project. Some of the
common risks associated with the customer arc the past experiences with the
customer. If the customer is new, the tisk is comparatively high than the existing
customer.

Customer's knowledge about the product and the ability to explicitly define the
product requirement is needed. If customer is not clear with the requirements, your
project may be at high risk. Availability of customer time and his willingness to
share the knowledge, etc. are some of the areas that need to be given attention during
risk identification.

Process Risk:
Major percentage of risk is related to the processes that are followed for software
development. If processes are not wcll-defrned and cannot be controlled, they can
be a great source of project risk. To assess process related risks, you can check up
whether your organization has a written policy statement that emphasizes the
importance of standard processes for software development. Is their a written
description of the process that explains how to execute the process and measure the
process? Does your organization provide formal training on process standards and
teams' compliance with the standards? L'> there any process for tracking and reviewing
the performance of third party vendors? Is there any configuration management system
followed to maintain consistency among software processes? Does your organi7.ation follow
regular formal technical reviews to improve the process further and remove deficiency if
any? All such arc process related concems. The answers to the questions, will tell you the
maturity level of the process. Immature processes are big source of potential risk.

245
Project :vtanagcmcnt

Human Resource Related Risk:


Let's quickly look at the questions suggested by Boehm to assess the risk associated with
staff expetience and size.

• Arc the best people available to execute the project?


• Do the people have right combination of skills?
• Arc enough people available?
• Is staff committed for entire duration of the project?
• Docs staff have the right expectations about the job at hand?
• Hac; staff received necessary training?
• Will turnover among staff be low enough to allow continuity?

If the answer to any of these questions is "no", further investigation should be


undertaken to assess the risk potential.

Risk identification tools:

ln the previous section, we discussed how to identify the risk using the checklist
approach. Now we will discuss other tools that can be used in risk identification.

Broadly, risk can be identified with documentation reviews, information gathering


techniques, diagramming techniques, checklists and assumption analysis. We will
take a brief overview of two techniques namely Delphi Technique and SWOT
Analysis. These tools arc generally used for information gathering.

Delphi Technique:
Quite often during risk management there is no consensus about the identified risk
across the project stakeholders and dispute on what to be included as a risk. To help
resolve this issue, Delphi technique can be used. Delphi technique is used to build
consensus of experts who participate anonymously. The technique is based on the
principle that the opinion of structured group is more accurate than those of
unstructured group. Delphi technique is a method for structuring a group
communication process so that the process is effective in allowing a group of
individuals as a whole to deal with a complex problem. In this technique, a request
for information is sent to the expert's. Then the experts answer the questionnaires in
two or more rounds. After each round, a facilitator provides an anonymous summary

246
Unit 9 Be Proactive: Managing Risks

of the experts including forecast from previous round as well as reasons they provided for
their judgments. Thus experts are encouraged to revise their earlier answers in light of the
replies of the other members of their panel. It is believed that during the process, the range
of the answers will decrease and the group will converge towards the correct answer. The
process is stopped after the predefined criteria such as number of rounds, achievements
of consensus, stability of results, etc. Delphi technique helps to reduce bias in the data and
keep any one person from having undue influence on the outcome.

SWOT Analysis
SWOT analysis is the most common and widely accepted tool developed by Albert
S. Humphrey. This tool is mainly used in decision making and planning. It can be
presented in many ways as in 4 Quadrant diagram. SWOT analysis tool is generally
used to analyze the Strength, Weakness, Oppmtunity and Threats of a particular
risk. SWOT analysis is a flexible concept that can be used in various scenarios from
assessing projects or business ventures, making decisions, solving problems,
evaluating candidates for a position to marketing strategy formulation and in our
project management for risk planning. In the SWOT analysis technique each risk is
plotted in the 4 quadrants namely Strength, Weakness, Opportunity and Threats.
The Quadrants where the weakness and threats are the highest and the quadrants
where strength and opportunities arc the lowest will represent the highest risk on
project.

Carrying out a SWOT analysis involves idcntifying internal strengths and weaknesses
as well as examining external opportunities and threat<;, and then seeing how they
relate to each other. This interesting insight alerts you to your weaknesses so that no
threat can catch you unaware any longer. With little thought you can understand
your strengths and uncover the greatest opportunities. that you are we11 placed to
take advantage of and thus achieve your goals.

Let's understand how to take an inventory of the four component<;:

Strengths
These are the internal attributes that add value and give you a competitive edge over
others. If you have enough strength you can easily cope with risk. For example, if
your team is technically competent, you can manage technical risk easily.ln order to
identify the strength of the team, you can explore the questions like where does your team
do well? What advantages you have over others? What relevant resources you have

247
Project Management

access to?
Weaknesses
Weakness is generally a gap or lack of capacity <md capability. In order to cope with risk,
you need to reduce your weakness and increase the strength. You can identify weak areas
by probing questions such as what arc you not doing well? What should you improve?
What should you avoid? Usually the weakness of one tcmn member can be compensated
by other. Examples of weakness could be poorly defined process model, inability to achieve
results, lack of experience, inferior service, damaged company reputation or poor
communication.
Opportunities
Opportunities arc external factors. Sometimes it is risky to handle a technically complex
project but it opens an opportunity for future projects. Your team will have an opportunity
to learn on new technology that they can use in other projects.
Threats
Threats are external obstacles in your path that arc largely beyond your control. They arc
characterized by unfavourable trends like employee turnover, system crash, and
obsolescence, competitors with superior skills/products, changing requirements and
changing technology. Yet, what constitutes opportunities m1d threats is largely subjective,
as a situation like ·an unfulfilled consumer need' can be an opportunity for a company that
can meet that need while a threat to those that cannot!
On the whole, a formal SWOT analysis not only increases your awm·eness of the unique
situation you or your firm is in (both in tenns of pointing out what needs to be done and in
putting problems into perspective). But it will also provide you a roadmap to maintain,
build and leverage your strengths as well as deter or eliminate weaknesses so as to pursue,
exploit and capitalize on the opportunities even while avoiding, countering or atlcast
defending against potentially deva<;tating threat<;.
In the words of a top consultant: "It gives a comprehensive concept of internal and external
factors and bow to creatively and innovativcly develop a strategy that is directional, cost-
effective and of course executable."

248
Proje-ct Management

9.8 RISKANALYSIS
We are now able to identify the risks and I'm sure you can prepare a huge list of
risks in your next project assignment. Now I have some questions for you. Is the risk list
(risk register) just enough? Can you manage every identified risk in available time & budget?
In reality, project has time & budget constraints. Practically, you cannot mitigate every
identified risk within these constraints. 1o manage the available budget effectively, you
need to set the priority of the risk such as high priority, moderate, critical, low risk, etc.
Top management generally set<> the criterion for priority. Risk analysis process helps us to
set the priority of all identified risks. In risk analysis, all identified risk<> are further <malyzcd
for their qualitative and quantitative aspects.

Qualitative analysis:
The main objective of qualitative analysis is to set the priority of all identified risks
so that you can filter out top priority risk to a manageable level. Qualitative analysis
process comprises activities such as identification of risk characteristics, qualitative
analysis of data, categorization of risk and prioritization based on available data.
Qualitative analysis is an iterative process and may occur many times during project
execution.

Identification of risk characteristics: We know that to measure qualitative aspect,


we should know the characteristics of that object. Hence in order to perform
qualitative analysis, we must identify the characteristics of the tisk. The characteristics
of the risk will help us to distinguish one risk from other. Once we distinguish risk
based on their characteristics, we can analyze and set the priority. The characteristics
of a risk are generally decided by the organization. Some of the examples of
charactelistics are probability of a risk, impact of a risk on project objective, category
of the risk, time frames, risk tolerance, etc.

Qualitative analysis of data: Once characteristics of risks arc identified. qualitative


data for each risk is collected through interview, reference data of past projects.
Once data is collected, every risk is assessed for its probability <md impact on the
project. While collecting data, enough precaution needs to be taken to protect data
from the bias of individual.

Risk prioritization: Risk priority can be defined as the degree of risk exposure of
the risk on project. The risk exposure can be calculated as product of probability of
risk and the loss or impact of the tisk, Risk Exposure = Probability x Impact.

250
Unit 9 Be Proactive: Managing Risks

Assume that probability of power failure is one and the loss (here major loss is time loss)
is 1OO(X) dollars due to power failure, thus by substituting values, we can calculate the risk
exposure for power failure risk a<> RE =1x l()(XX) =1()(XX) dollars. You can calculate risk
exposure for each identified risk and give priority as per the degree of risk exposure.

Categorization of risk: We have seen various categories or sources of risk in risk


identification process. Dming risk categorization process, all risks along with the priority
are grouped as per their categories and further analyzed. Categorization helps in relative
study of the risk that leads to the better understanding of possibility and magnitude of risk
in similar categories.

Quantitative Risk Analysis:


The main objective of quantitative analysis is to provide the overall risk estimation
of the project to the management. In qualitative analysis, we only focused on
individual risk. However, these qualitative details need to be compiled & given to
the management. Management basically needs to know whether the project can
meet the specified objective or not, how much contingency reserves are required to
provide the level of certainty based on risk tolerance, what risk areas threaten
maximum loss, etc. This kind of information can be generated after the quantitative
analysis of qualitative data. Quantitative risk analysis covers all the risks . Quantitative
analysis is generally performed after qualitative analysis. However in a small project,
both qualitative and quantitative analysis are done simultaneously after risk
identification.

Tools & Techniques


For quantitative analysis, two types of techniques are used. For quantitative analysis,
data is first gathered and represented. Once data is gathered, it can be further modelled
and analyzed. Por analysis and modelling, teclmiques such as sensitivity analysis,
expected monetary value analysis, decision tree analysis and Monte-Carlo analysis
can be used. All these techniques are based on mathematical and statistical methods.
Prior knowledge of statistics will help you to understand the techniques in more
detail. Few of the techniques such as Monte-Carlo are rarely used in software project
management. The knowledge of these tools becomes essential when the project is
quite complex and large. The tools mentioned here are for just knowledge purpose
and do not imply that you should usc all these tools in all projects.

251
Project Management

9.9 RISK RESOLUTION

The main purpose of overall project risk management is to effectively cope up with risk
with minimum loss to the project. With proper risk resolution strategy, we can mitigate the
risk. Once you have identified all risks and analyzed the impact of risk qualitatively and
quantitatively, you can plan what you are going to do to mitigate that risk. Thi s plan is
called as 'risk response plan' or 'risk mitigation plan'.

Risk Resolution Strategy


Risk resolution is defined as the action taken to transfer, reduce, or eliminate risks in a
project. This is done by reducing the scope and quality without having any substantial
impact on the objectives of the project. This is done to reduce the impact of any uncertainty
on a project caused by circumstances that have not been foreseen during its planning. A
risk resolution strategy is a plan which takes the overall view to mitigate the risks and
safeguard investment activities. The plan will detail the specific risks that will have to be
dealt with and the action that has to be taken to carry out this risk resolution strategy. We
will discuss most commonly used risk resolution strategies.

Proactive Prevention
Risk mitigation is a proactive strategy in which the actions are taken to reduce the impact
of risk and minimize the probability of risk. For example, you can hire or assign an
experienced resource to handle the complex activities of the project. Though it will not
avoid the risk, the impact can be substantially reduced. If project is too large and the team
is dispersed across the globe, you can use automated tools to support software engineedng
and project management tasks.

Keep complex risk outside the scope


Sometimes your team is not competent enough to handle technically complex project
and outsourcing is a risk. In that case, the only option that remains is to avoid that
risk. You can negotiate with the customer and eliminate the complex portion of the
scope.

Outsource the risk


If the above two options do not work and the customer insist<> to keep the critical
requirements in the scope, the only option remains is to transfer the risk to some
expert agency and get the work done from them. It is similar to the life insurance
cover we get from insurance agency by paying premium. In outsourcing you generally
share some potion of profit of the project like a premium. At the same time, the

252
Unit 9 De Proactive: Managing Risks

expert agency (other organizations who carry out the risky area of the project) bares the
loss due to risk
As we discussed that sometimes we need to take risks which are beneficial. It is like
investing in share market. You must know various strategies to deal with positive risk or
opp01tw1ities.
Invest More
In order to handle more complex project and take the competitive advantage, you can
hire more experience personnel by paying them best of the industry pay package. You can
keep reserve staff to handle more projects at a time. As you invest more in technology and
resources or anything else, for example, maintain various standards such as CMM, initially
you have to invest but as you invest you will reap more benefits than your competitors.
Co-Creation
We have discussed that some of the risk.<; arc basically constraints. For example your
organization's core area is to provide business solutions like ERP. However, certain projects
require system level programming which your organization does not support; in that case
you can venture with other partners who are expert in system programming.

k'S Activity G:
1. Explain the risk analysis process

2. Explain various risk resolution strategies.

253
Project Management

3. What type of data is gathered during qualitative risk <malysis?

4. Name three tools that can be used in risk analysis process.

--------------------

9.10 RISK RESPONSE PLANNING


Various plans are generated in risk management process such as contingency plans,
fallback plans. One of such plans is risk response plan which describes the identified
risks, their exposure, priority and resolution as shown in the following template.
You can add further elements such as the date of occurrence, the person responsible
for risk mitigation, etc.

Risk Id Risk Impact Probability Loss Risk Priority Resolution


Description Area Exposure
1. Very few Schedule 60 8 480 High Hire more
technical technical
experts staff

2. Complex Design/ 50 3 150 Low Review


user Coding with
interface customer

3. New Coding 20 10 200 High Review


technology with
risk technical
expert

Fig. 9.6: Risk Response Table

254
Unit 9 Be Proactive: Managing Risks

9.11 SL'MMARY

Software risk management is an essential and important activity in software project


management. As software development is complex in nature, they impose various
risks such as cost and schedule overrun, technological and business risks.

Risks arc nothing but unforeseen event<; which are probabilistic in nature. Risk may or may
not occur but we need to make a risk contingency plan to mitigate that risk. Risks are
imporumt because risks have negative impact on projects in terms of direct monetary loss
or loss of reputation. project failure. etc. Risks occur because of various constraints such
as knowledge of future, technical competency, resources and budgets, etc. Risk should be
treated negatively but sometimes risks reap benefit<>, such risks are called as positive risk
or opp01tunity and negative risk are called as threats. For example, viral threat can damage
valuable data; a key person may leave the job. This can cause schedule delay. etc.

Based on the level of unce1tainty, risks are classified as known-known risk, known-unknown
risk and unknown-unknown risk. In known-known risk, the type of risk and probability of
risk is known. For example, fix budget of the project is a known risk because due to
project constraint, we may not deliver everything defined in scope; here we know the
consequence of the risk. In known unknown risk, we know what could go wrong but we
do not know the probability and when the risk will occur. Unknown-unknown risks are
beyond our vision and we do not have any control on such risks.

We studied three risk management models which insist on proactive strategy such as risk
identification. risk planning and risk mitigation.

We also studied different types of risks and how to identify them. After risk
identification, risks are qualitatively and quantitatively analyzed and we discussed
how to calculate risk exposure and other risk charactctistics such a<; tolerance, priority.
etc. At the end of the unit, we discussed various risk resolution strategies and risk
response plan.

9.12 SELF-ASSESSMENT QUESTIONS


-------------------
1. Discuss the importance of risk management in software development.

2. Describe tllC difference between known-known and known-unknown risks.

3. List down ten examples of known-known risks.

255
Project Management

10.1 INTRODUCTION
After having seen the various technical aspects of software development, we now tum to
some techno-managerial issues related to version control in this unit. We start out with a
brief enquiry into the scenario of the umpteen versions of one and the same software to
find out why all those versions arc needed at all. We will then move to the central concept
of Software Configuration Management (SCM) and learn how it is mission critical for the
existence of the software development unit You will find that the capability to build any of
the past versions is at the heart of SCM and that in turn it boils down to the age-old
concept of traceability. This phenomenon has been borrowed from the world of
manufacturers who take up a customer complaint about the product as a whole and then
gradually isolate the problematic sub-assembly, finally to pinpoint the exact part where the
error lies. Toward this traceability the software companies designate a person as a librarian
who keeps track of all the relevant details, obviously with an automated tool for the same.

10.2 TOO MANY VERSIONS OF SOFfWARE


If you look at any software that has been reasonably stable in the market for a few years,
you will quickly infer that it must have been a successful and popular product well received
by the customers at large. Probably what cannot be easily appreciated is the fact that there
are multiple versions of the same software product available with the same nucleus of
functionality but with several variations in the peripheral features. It may perhaps be a little
hard to digest that in some extreme cases, the version count may run into several dozens
for one and the same software product. Let us try to get to the roots of this apparently
incomprehensible scenario.

There are two major reasons behind the multiple versions of a software product and they
arc as under:

a) Increasing Customer Base

As the software gets more and more popular among a growing clientele, there arc
certain factors that fuel the need for multiple versions. These factors could he quickly
summed up:

1. Functional I Scaling Flavours


Some jumbo software products come in different varieties to appeal to different
market segments. Multi-firm accounting software may offer capabilities to record
financial entries of multiple firms in the corpomtc group, whereas a simple version

260
Unit 10 Software Configuration Management (SCM)

may confine itself to just one single unit.

2. Statutory Needs
Laws ofnations I state.<; do differ substantially and hence require some functionality
that is specific to that state. For digital signatures, our Indian law recognizes
MD-5 and SHA-1 only as hashing solutions and others won'thave a valid legal
backing.

3. Work Culture
Due to large geographical difference..;;, there are quite a few distinct requirements
to suit the work culture of every country or region. As the lunar calendar is still
followed in countries like Nepal, software churning out date arithmetic like interest
calculations based on the typical solar calendar definitely won't fit well there.

4. Domain Specific Issues


Based on the functional area, the requirements might undergo some change
making customization a must. A pair of scissors denoting the 'cut' operation
in windows parlance has got an altogether different significance in the
medical field where it may be interpreted as 'surgery'.

5. Accounting Practices
There is a vast variety in accounting principles and practices that may give
birth to multiple versions of software. Software may have a version that is
GAAP compliant on the international scenario.

6. Language Varieties
As the world is rapidly turning to be a global village, the software products
reaching out to far off places do offer distinct versions in the respective
regional languages. MS-Office is now available in Tamil, for example.

7. Accessibility Options
Towards making operations easier for physically challenged persons, some
software versions are produced with specific provisions. For persons
suffering from a hearing impairment, the software would produce a visual
signal on the monitor rather than simply give an audio beep.

261
ProjC'Ct ~anagement

8. Operational Platforms
Some software products are offered with a heterogeneous hardware and software
platform to run on. Obviously, there are then different versions in such cases.
Text processor software comes in two versions: one for Windows and another
for Macintosh.
9. Customer Needs
Lastly, for some customers some peculiar needs are almost inevitable and hence
have to he incorporated in the software. A hank having a unique deposit scheme
may request its software solution provider to customize it.
b) Progressing Time Line
Apart from the above mentioned factors contributing to a plethora of versions, now
we will look into one more aspect of advancing time line. As time passes by, there are
newer and newer versions frequently rolled out by the developer, due to:
1. Debugging
As you might have recognized by this time, a software product without a single
error or bug is an Utopian idea that does not exist in reality. Coming to the large
software products, there are quite a few bugs practically making it necessary
that they are removed and a new rectified version is brought out. This corrective
maintenance adds more versions to the software.
2. Enhancements
Another reason behind the multi-versions is that with changing time, changing
business enviromnent forces more functionality changes that have to be
incorporated in the software on a regular basis. This adaptive maintenance also
gives 1ise to the version count in a big way.
~ ActivityA:

Make a list of some business environmental changes that you feel arc likely to lead to a
need for enhancements.

262
Unit lO Software Configuration Managcmenl (SCM)

Due to all these factors, there could be several versions for a single software product. The
author has witnessed banking software having an installation base of over 500 that had ac;;
many as fifty different versions!

There are at least four different versions for any software product that is a successful
business:

1. Version 1
This is the oldest version that has been deployed and running very well at the
customer's site for live operations. Due to corrective or adaptive maintenance,
the next few versions appear on the scene as follows.

2. Version 2
This next one is already delivered t.o the client after version 1. The customer
typically goes ahead with a thorough testing (User Acceptance Test or UAT) of
this v2 before it could be put to use.

3. Version 3
This one is developed after Version 2 on time line and is not yet delivered to the
customer, as it is undergoing systems testing at the developer's site. Afterwards,
it may be reworked and retested, if necessary, and would then finally he rolled
out in the market for customers.

4. Version 4
This is the most happening version, which is right at the workbench of the developer's
team. This Version 4 is in a half-cooked status, with some modules fully developed
and other modules under development. It is interesting to note that even before its
birth, this version has to be named and tracked for all its componentc;; as explained
in the next section.

Having seen a vast array of versions for a software product, we will now turn to
another stupendous issue of traceability.

10.3 TRACEABILITY AS THE CENTRAL ISSUE IN SCM


When your vehicle starts giving some problem like say misfi1ing or some unfamiliar behaviour.
you take it to a garage. As a user of the vehicle all you do is just describe the symptoms of
the malfunctioning as perceived by you. Before actually fixing the problem, the first job of

26.~
Project Management

the mechanic is to isolate the faulty part in the automobile. He may take a trial drive and
figure out that something is wrong in the fuel injection system. Next he may conduct some
tests and ultimately zero in to say that it is the carburetor that is the real culprit. Then he
may dismantle the various gantries to reach out to that part, isolate it and test it to decide
whether a rework is good enough or a complete part replacement is essential.

This process- described in management parlance as isolating the troubling element in


the system- mns quite parallel to the debugging procedure in software maintenance.

Obviously, like a mechanic possesses the competence to logically (and physically, too)
dismantle the automobile to get through to the faulty part, the software engineer too needs
the capability to logically (though not physically) decompose the complete software with a
guiding light of the symptoms of the bug. This decomposition is a gradual and iterative
process that turn by turn descends down to sub-systems, modules, programs and finally
the defective line of code in the program.

A software development firm without such traceability skills would hardly survive in this
competitive world any longer than an auto-mechanic lacking the knack of pinpointing and
fixing the vehicle problem. This capability is therefore quoted ac; one ofthe prime proficiencies
of a software organization. Well-known author Derel lnce reckons traceability, as the
numero uno skill a developer should have.

Such a traceability starts out with the end-product of the software as rolled out to customers
ands then gradually tracks back through the various SDLC phases of programming,
designing, analysis and user requirements until the defect is neatly located. Again, it will be
worth noting that this process is to be followed not only for debugging or corrective
maintenance, but also for enhancements or adaptive maintenance, too. This point may
look odd, but it would be clear once we see the proposed enhancement in the functionality
as an error in the software, as if it was the left out point while developing the earlier
version. With that standpoint, it will be instantaneously appreciated that whether you want
to remove a bug or to insert a new functionality, the traceability is the common starting
point

10.4 IMPACT ANALYSIS

It is interesting to note that merely identifying the exact problem area is just a starting point.
You may feel that once the defect isolated, it could be fixed right away. Unfortunately, the
fact is that there is one more laborious job called 'Impact Analysis' to be done before
actually patching up the program. Such an impact analysis is required due to the inter-

264
Unit 10 Sofl\varc Configuration Management (SCM)

relations among various programs or modules in the software, which we have already
studied earlier in Unit 9 on 'Process Logic and Programming Standards'.

During impact analysis, the software developers go ahead to systematically enlist all the
possible artifacts of the software that would be influenced with the proposed modification.
Such artifacts are twofold:

a) Software Items

These cover the various work products of software which are:


1. Source programs & Process specifications.
2. Flow Charts & DFDs.
3. Table design & ERDs.
4. Ccx:lification Schemes.
5. Input & Output Formats.

b) Allied Items

These include the related items such a<;:


1. Complete Documentation.
2. User I Operations Manuals.
3. Training Material, if any.
4. Project Implications on Time & Cost.

All the above points are minutely studied, not just to enlist those getting affected by the
proposed change, but also to fmd out what is the exact change that each artifact needs to
undergo to ensure a holistic and coherent working in the functionality of the software as a
whole. It goes without saying that if these points are not thoughtfully tackled, the ripple
effect<; of one mcx:lification may result into a cascading effect of disturbing the software at
more than one points in an unexpected manner, thus inviting the unwarranted trouble of
setting right all those undesired changes. The point has been briefly discussed in Unit 13 on
'Software Testing' under the section on regression testing.

265
Project .Management

10.5 CAPABIIXI'Y TO BUIT~I> AAI' PAST VERSION

Software developers need to exhibit a capability to build any of the past versions of their
software product. This is quite crucial for their own credibility and their organization's
reputation for the following reasons:

1) Customer Request

It may be possible that a customer needs a relatively older version for reasons like
platform compatibility, ease and convenience of use, need for processing the older
data records. and so on. To maintain their customer's satisfaction, the organization
may need to build one of the previous versions that are no longer much used.
2) Litigation

As the software is utilized for some commercial application, there are high stakes and
a heavy reliance on the software product. At times, the customer and developer may
not keep their rapport intact; in extreme cases, litigation is also not ruled out. For
such exigencies, the software developer needs to demonstrate a competence to build
up that disputed version so that its functionality could be assessed.
The rationale behind the capability to build any past version is now pretty clear, but a
question that may arise in your mind is. "Why is there so much ado about it?" Well, the
reason is simple; It is a Herculean task to maintain a neat track of past versions of software,
particularly its component~\ and theirrespective version numbers, as explained in the next
section. Complexities in real life are much more than what they appear to be in theoretical
discussions. Read on for details.

£5 Activity B:

By surfing the Internet, try and find out the different versions of software that arc available
for any software of your choice.

266
Unit 10 Software Configuration Management (SCM)

10.6 SOFTWARE COl\'l'IGURATION MA..~AGEMENT (SCM)

Now that you know the triad I tiipod(need for multifarious versions, the central issue of
traceability and impact analysis), it would be logical to deliberate on the software
configuration management (SCM).

An example will help you further gra<>p the exact scope and complexity involved in handling
multiple versions of software. Let us think of a banking software product that helps banks
to maintain their customer database comprising all types of accounts and to put through a
variety of transactions across all branches of that bank. As we know by this time, there
would be many versions of this software. Now if we try to build up a matrix having version
numbers to be put in columns and components in the rows, it may look somewhat like the
two-dimensional Table 10.1 , where all the cells show a version number of the respective
component (in the row) that goes into the final software product (marked as the column
header).

Table 10.1
i
I Software Product l Version 1 Version2 .... l VersionN
I
II. DFDs
·- --
: 2. ERDs I
- -
3. FlowChmts I
4. Tables/Files
- I

5. Codification l'
- - ___J

- -
6. Input Formal<> I I
I

7. Output Format I I
I l
I l
8. Process S pee's I
I
I

==l
I I
.....
1---- -
..... I
I
You will also appreciate that each of the items in the rows -· DFD's, ERD's, Flow Charts,
Table/ File design, etc.- has been indicated just as a category; in a real life scenario each
of them gets expanded into several rows, few dozens of tables, and scores of report
layouts. and so on. Thus, the actual size of such a table would easily run into several
hundred rows (one each for a component going in to the software) and many dozens of
columns (one each representing a specific version of the software).

267
Project Management

The software developers right from the beginning neatly and meticulously manage this
complete table. Initially, all the components (and tl1e deliverable end-product, too) will
bear the version number 1. Later on, as and when a new component in the software is
added, a line would be added for the same and cells of that row on past colunms will be
marked as 'Not applicable' indicating that the particular component was not on the scene
for earlier versions of software. Likewise, whenever a new version of software is getting
ready, a new column would be added to the table with the column header bearing th~ new
version number for that software product. All the values in the immediately preceding
column would be copied onto this new column and the version number of only those
components (in this newly added column) would be incremented, where some modifications
arc done to the componenlc;; the remaining components would retain their individual version
numbers as per the preceding column.

All these botherations arc to be scrupulously tackled as the version numbers ofthe end
product and components do not advance uniformly. On advancement of any version of
the software product, only those components that have undergone some change will
simultaneously increment their respective version numbers, while the other components,
which have not been altered, will carry their earlier version number as in the past.

This is the crux of the SCM and obviously the software development organization needs
to plan out the SCM process, devote certain resources to it and regularly monitor this
critical factor.

10.7 ROLE OIT LIBRARIAN & AUTOMATED TOOI~S

In the modem world with large software projects, the specialized task of SCM has to be
assigned to a skilled expert often called the 'Librarian'. He is the person who has authmity
over custody of all the software component<; that are tantamount to work-in-progress and
finished goods and hac; an accountability to build any of the past versions of the software
productc;.

A quick look at the librarian's task list runs thus:

1) Custody of all software artifacts


The librmian has complete possession of all the intermediate software product<; (often
referred to as work product<;) like:
a) Source code for all the software products.
b) Test Suit consisting of various test transactions.

268
Unit 10 Software Configumtion Ylanagemcnt (SC:.\1)

c) Design Items, like:


1. Tables/ File Layouts & ERD's
ii Process Specifications, Flow Charts, etc.
IlL Input & Output layouts
1v. Codification Schemes
d) Document related to Analysis done for User requirements.
e) Requirements collected from and signed off by users.

At any point in time the librarian must have a full access and control over all these
artifacts across all versions of all software products. These articles in his custody are
called configuration items.

2) Check In I Out of Configuration Items

Each member of the software development team is expected to work on some


software component and accordingly bon·ows that item from the librarian and
returns it back once the work is completed. Thus a programmer may get design
specifications issued from the librarian (just a read access, as he is not expected
to modify it) and the latest version of the program (with write access as he is
expected to modify the program to take it to the next version). A designer may
request the librarian to issue the latest version of some specific item like say, a
particular data file I table design.

3) Tracking the Lent out Items

The librarian has to maintain a complete inventory assigned to him for each
software product. He also keeps a neat track of all the items lent out to various
colleagues. This tracking includes:
a) Work product item along with ID, Name and Version No.
b) Nan1e of the borrowing member.
c) Purpose of Lending- Read, Review, Rework, Enhance.
d) Issue mode Read I Modify mode.
e) Date oflssue.
f) Expected date of Return.

269
Project Management

g) Actual Date of Return.


h) New Version :"Jo. Assigned (If returned, duly modified).

4) Inter-Relations among All Configuration Items

From the earlier discussions, it would now be clear to you that the librarian needs to
maintain inter-relations among the configuration items for each software product.
This is essential to avoid cases where two members simultaneously handle an item
disturbing the dependencies. Consider a scenario where a designer modifies a specific
data file layout, and at the same time, a programmer writes a program handling the
older data file layout.

5) Building up a version of the software product

As a paramount function, the librarian builds up a specific version of a particular


software product as per the directions of the concerned project head. Obviously,
at this point there are no lent out items for that software product, as that may
lead to internal inconsistencies in the software. Once software 'build' takes
place and is tested, the version number is frozen. All subsequent modifications
to any components would relate to the next version, not the frozen one.

6) Drawing up a Status Report of Configuration Items

It is also one of the duties of the librarian to provide a current position of various
library items to the concerned project head to enable him to review and monitor
the progress of the project and take any necessary actions of modifying the
schedules, etc. that may get reflected in the librarian's due date wherever
necessary.

From all these discussions and also in view of the tremendous expanse of the various
software products and their umpteen work products, the librarian's job cannot be
performed without automated tools at his disposal.

Such software utility tools provide a handy way for the following tasks:

I. Maintenance of list of all the software development team members.

2. Record keeping of all the software artifacts in soft copy form.

3. Maintaining actual copies of each software artifact across all versions.

4. Tracking the inter-dependencies of software artifacts.

270
Unit 10 Software Configuration Management (SC'MJ

5. Validating an Issue of software artifact for consistency I dependency.

6. Recording the Issues with details of members, artifact and work mode.

7. Recording returns of such software artifacts from members.

8. Providing a status report (date-wise, version-wise, member-wise, . ..)

9. Assembling the desired components for software build.

10.8 SUMMARY

An abundance of versions is very common for noted software products due to several
reasons (like functional I scaling flavours, statutory needs, work culture, domain
specific issues, accounting practices, language varieties. accessibility options,
operational platforms, customer needs, etc.) that make it essential to have multiple
versions of the same software. Owing to customer requests for supply or the court
directives in case of contingency of any litigation, version control is a critical issue
for any software developer who has to be able to build any version of the software
products he offers.

It then follows as a corollary that the software development team must meticulously
maintain a systematic and elaborate record of all the intermediate products (also
called software artifacts or software work products) across all the versions. This
version control is possible with a dedicated expert called librarian who should be
provided with the necessary software tools for automation of the task.

10.9 SELF-ASSESSMENTQUESTIONS

Q1. Explain the following briefly:


a) Traceability

b) Role of Librarian

c) ImpactAnalysis

d) Need of automated tools

Q2. Write a short note on 'Version control as a central theme of SCM' .

271
Proje-ct Management

11.1 INTRODUCTIOl\
So far we have understood what software projects arc and what processes are used
for managing them. This gives the insider view of project management. But project
management cannot be misunderstood as a static process. It also has influence on
the external world and get-; in turn influenced by the changes in the external world.

Earlier software projects consisted of software development which required design


and coding as the main activities. Soon the clients started demanding testing and
analysis also from the development team. So consultancics as well as software
development companies started supporting entire SDLC and all the activities carne
under software project management umbrella. Recently software projects consist of
end-to-end processes starting from problem identification till the maintenance/
governance.

It is a common scene now-a-days that a software project may need contribution


hom people across the globe. The embedded software may be developed in Illinois,
client specific software in UK Prototype software and hardware in Texas and
application software in India. Because of this, the way the software projects were
handled changed significantly over the years. In this unit, we are going to discuss
processes and its impact on software project management.

11.2 GLOBAL :XATURE O:F SOI•TWARE PROJECTS \VITH RESPECT TO


INDIA
By the late 1980s, India was graduating approximately 1,50,000 English-speaking
engineers and science graduates, with only a limited demand for their services from
the rest of the economy. By the late 1980s as well, India's economic liberalization
was also well under way. Around this time, the information technology revolution
in the developed world had begun to take root and shortage of skilled programmers
and IT professionals were beginning to develop. By this time, a number of Indians
were working in very substantial numbers in US firms. Some of them played an
important, although as yet undocumented role, in bridging the gap <.md matching the
buyers in the US with the suppliers in India. Responding quickly to the growing
demand, a number of Indian firms arose in quick time. Contrary to it-; normal practice,
the State encouraged this growth by considerably simplifying the process for
obtaining the numerous clearances and permits that any firm in the organized sector
in India typically needs. Finally, given the many weaknesses in the Indian financial
system, Indian entrepreneurs greatly benefited from the low levels of initial

274
Unit II Update Yourself: Current Trends

investment required to start a software service firm.

Prom very humble beginnings, the Indian IT Industry has grown at an exponential
rate over the past 10 years doing Rs . 10,000 crore of export, fetching for India
valuable foreign exchange. propping up the Indian Stock Market with its share prices
reaching dizzying height-; before the scam. and employing over 2 Jakh professionals
with this number poised to rise to around 20 lakh in another 3 years. India missed
the Agrarian. Industrial and the early Computer Revolutions but became a global
player in the IT revolution because of two main factors - opening up of the markets
and India's cheap and vast manpower with knowledge of English. Right from 199 I
to 2000, Indian companies grew at a mind-boggling rate of 200-500% attracting
lucrative projects from companies all over the world, especially the US.

Growth in India's IT Sector


ill ~r=============~~ - - - - - - ·.,-6
c::::J Tum-over in billion USD
50 ~------------~~~--+5
--.-Share in GOP in %
4

~+-----------------~~=-=-------~~ 3
20+----------r'-------------~~~ 2

1997-98 1999-00 2001-02 2003-04 2005-06


Sources: 1997 -98!2005-06: Reserve 8 ank of India, 2006--07 e: NASSCOM estimates

Fig. 11.1: Growth of India's IT Sector and its Contribution to GDP in a


Fiscal Year
As a natural consequence of the growth in software development and in globalization,
there has been a significant growth over recent years in global software development
projects. These arc projects that disperse software development processes across
national boundaries.

The driving force behind the globalization of software projects is largely economic.
Global dispersal of activities can take advantage of the cost savings and labour
availability offered by developing countries. It also reflects the globalization of
businesses, which find themselves with software requirements and software personnel

275
Project Management

spread around the globe. All this has been enabled by the global diffusion of
information and communication technologies (ICTs). Globalization of software
projects therefore brings benefits compared with one-country projects.

The Indian labour is not only cheap but is technically skilled too to the world class
level. It is due to the Indian Education System that includes in its course curriculum
the practical knowledge of the latest technology that is developed in the world along
with the fluency in English Language that imparts compatibility in an Indian
technician to communicate and work throughout the world.

Further, the geographical location of India serves it the advantage of being exactly
halfway round the world from the US west coast, which is another reason why India
is a preferred destination of many big brands. Also, the presence of a large number
of Indians, especially engineers, in the US gave India an easy entry into the US
software market.
-
£S Activity_~_;_

A. Find out the data for the current year in extension to the values shown in fig.l.

B. State the advantages of software projects going global.

C. What are the drivers for global software projects?

276
Unit 11 Update Yourself: Current Trends

11.3 TOOLS USED IN MANAGING GLOBAL PROJECTS

As the project infrastructure and team is distributed across the globe, it becomes
more challenging to manage such projects successfully. The tools used in project
management in such situations should be standardized, internationalized and
compliant with the various policies specific to that country.

1. Communication tools

E-mail, teleconferencing. video confcrcncing arc some of the tools used now-
a-days for facilitating the communication among the global teams. A frequency
- may be once a week - is used for such a communication. There are messengers
and tools like SKYPE which are used for text, audio as well as video
conferencing simultaneously.

2. Project management tools

Generally, in a typical global software project, the core technical team will be
responsible for assigning high-level tasks to team leads, and team leads create
and assign individual ta<;ks to their team members. Organizations must have
tools to create, assign and manage tasks to the global team leads and to individual
developers. Often, when requirement. responsibilities, and priorities need
changes in a project, the core team responsible for managing the project must
have capabilities to reassign and move the tasks among the team members to
achieve the project milestones. At any given time, it should be possible for the
project management to get the real-time status of the project's progress.

3. Documentation tools

The distributed documentation servers are employed for maintaining all


documentation related to the project in a common repository which is accessible
to the entire team situated anywhere in the globe. The content management
systems and knowledge management portals even help in this aspect to provide
a convenient support. Some such systems are developed by software companies
for their internal usc.

277
Project Management

4. Development tools

Developers working in global teams often communicate with each other to


perform tasks like share source code snippet, conduct code review, perform
test. cases, design diagrams, share exception stack traces, etc, on real-time. They
may also remotely debug to solve a specific issue. Organizations must have
tools to support this feature to achieve the full benefits of global team
development. UML modelling tools and IDE tools should be appropriately
selected to suit the project environment.

.£$'Activity B:
A. Explain the significance of project management tools in a global scenario.

B. List the various development tools used in global software projects.

C. Explain the difficulties that will arise due to the lack of appropriate
communication tools in managing global software projects.

278
Unit ll Update Yourself: Current Trends

11.4 CHALLENGES IN l\1ANAGI:\"G GLOBAL PROJECTS


There arc numerous challenges in managing global projects ranging from
infrastructure to people management. Le t us consider each one of them on the
following parameters.

l. Distributed working environment


Inconsistent software development environment is a big issue in global software
development, here environment includes IDE. source code repository, database
tools. application server, build and deploy tools, testing tools, etc. Every
developer working in the global team must have same version and release of
software environment. The plug-in used by one developer may not be usable
by other developers or it may be of different version. Often times, these plug-in
create "marker code"' when checked into the source code control and if retrieved
by other developers may corrupt their IDEs. Individual software team members
dealing with these types of issues will significantly reduce their productivity
and thereby increase the overall project budget.

Generally, in a typical global software project, the core technical team will be
responsible for assigning high-level tasks to team leads. and team leads create
and assign individual tasks to their team members. Organizations must have
tools to create, assign and manage tasks to the global team leads and to individual
developers. Often, requirement, responsibilities. and priorities change in a
project; the core team responsible for managing the project must have capabilities
to reassign and move the tasks among the team members to achieve the project
milestones. At any given time, it should be possible for the project management
to get the real-time status of the project's progress.

2. Time differences
Time difference is one of the factors in offshore software development projects
which can become a pro or a con depending on how it is managed. It is imperative
that a '·common" time zone is mutually agreed on by you and the offshore
vendor. This time should be used for communication and ironing out issues
faced by the development team. Though it might take some time to get used to
getting into the office at 7 A.\1, it pays good dividends in the long run. While
working on different time zones, it becomes really imp01tant for offshore team
to understand time zone differences and plan the activities accordingly. In most
of the cases it had been seen that the onsite team expects at least 2-3 hour time
zone lap so that both onsite and offshore team can participate in the meeting.

279
Project Management

3. Language barriers

Although in India English is used for most of the official communication and
people arc comfortable using it, the same is not true when it comes to eastern
countries. Still various languages are used by them and even a translator has
limitations in making you comfortable to communicate with them. The potential
for business exists in such countries. 'They also have skilled people to support
the operations but in such a case to connect to the people in that country, language
might prove as a banier.

To overcome this problem, there arc two way efforts required. There is an
initiative seen in the non-English speaking countries for awareness and skills
in English language. Also, you can find several foreign language classes in
India.

4. Cultural differences

If your project team is spread all over the globe, you will sometimes scare
yourself with the amount of prejudice you have when dealing with people from
different cultures. Humans have a tendency to categorize everything, including
people. Different cultures result in different behaviours of people. But before
you try to draw conclusions about an entire continent, why not just start with
the individual project team member instead. There are following assumptions
which I present here as representative once.

i) Future - present - past orientation

For some cultures history will determine the future, so the past is very
important. Others, mainly South-American cultures, believe the past cannot
be changed. the future cannot be predicted. and only the present can be
influenced. And then there are the Western cultures who believe that with
hard planning, proper preparation and thorough analysis, the future can be
captured.

ii) Time-plentiful versus time-is-money

There is a huge difference in life if you believe that time is an unlimited


resource; the sun sets and will rise again, always, over and over again.
Time is plentiful. Tomorrow the same amount of time is left as today. If
you put this world view in contrast with the idea that time is passing and

280
Unit 11 Update Yourself: Current Trends

will never come back, you might sec how the concept of deadlines can be
confusing between some cultures.

iii) Respect for the man

In The Netherlands there is a problem with authority. People like to see


their bosses as equals, and tend to treat them as such. Respect is something
that should be earned, and hierarchy and upbringing has nothing to do
with that. And even with respect, that doesn't mean I have to treat someone
differently. That is atleast the opinion of the majority of the Dutch people.

In other parts of our planet, upbringing and hierarchy have a lot to do with
getting respect. And disagreement with a respected person is unthinkable.
'111is is the widely known yes from Indian people (yes, I know, the whole
continent) that is misunderstood by their western colleagues.

iv) Me versus us

There is a world of difference if you behave from the idea that you operate
as an individual or that you operate as a small part of a collective.

v) Spelling everything out versus its only natural

Even I learn something everyday. It is normal that everything is expressed


in detail, information is explicitly provided, and everything is spelled out
for you. And then there arc the countries where they assume that you have
some shared knowledge, some inteUigence and a mind of your own. For
this latter culture, it is almost insulting to get everything spelled out like
that.

vi) Doing everything at once or one thing after the other

There is an old discussion that women are better in multi-tasking than


men. This is about the fact that some cultures doing more than one thing at
a time is just nonnal. So if you arc talking with someone and he is taking
phone calls also at the same time, it nlight be insulting in one culture, but
it can also be just plain normal behaviour in another.

With respect to the above points, it becomes necessary to consider these


things while dealing with distributed project teams. Sometimes Indian
software firms arc proactive in training their employees before sending

281
Project Management

them onto foreign assignments. There arc several trainings available in


the market for understanding and acquiring etiquettes and manners in
different parts of the globe.

5. Acceptance to Indian teams

It is quite evident from the above discussion that if you are interacting or working
with someone from a different culture, obviously you will trust that person
100% of the times, or may not find it comfortable dealing with him/her. The
same is true for teams. Because of the preconceived notions, people do not
accept the teams, their ideas. and their working style. One work around for this
problem is to standardize the processes followed on work and obey some
international standards for project management such as PMI or PRTNCE2.

6. Legal aspects

By working on projects, firms are doing business in different countries. It is


mandatory for them to abide by the policies of that country in which they arc
operating. There arc issues due to different cunency rates, different licensing
rules for same software in different countries. Different countries have different
compliances which need to be complied with.

pj Activity C:
A. List down the challenges in managing global software projects.

B. What are the assumptions in the minds of people that become significant in
global environment?

282
Unit 11 Update Yourself: Current Trend~

C. List the ways to overcome the language barriers.

11.5 CHALLENGES DUE TO NEW SOFT"VARE DEVELOPMENT


MODELS
- -- --- - - - - - - - - - - -- -- -
As we know, project management is the overall umbrella of processes to manage
the software development and engineering, the two are interlinked. By now, you
must have learnt software development models and especially Rational Unified
Process and Agile development. In this point, we are going to see what differences
have these process models made to the way project-; are handled. Mainly the above
mentioned two software development models demand a different approach to
managing the projects.
Let me throw some light on these two models first.
1. Rational Unified Process (RUP)
This is a process model designed and marketed by IBM Rational. According to
IBM, it is a comprehensive process framework that provides industry-tested
practices for software and systems delivery and implementation and for effective
project management. It is iterative development model.
It has 4 phases, namely, Inception, Elaboration, Construction and Transition.
Each succeeding phase builds on the work accomplished in the previous phase
and develops the program into a usable product that is likely to attract the
attention of end users.
Software developers begin the Rational Unified process by entering into what
is known as the inception phase. At this point, the focus is on defining the
purpose and function of the software. This includes the identification of what
the software is intended to accomplish that is not being done by other programs
on the market.
The second stage is known as the elaboration phase. Here the Rational Unified
Process demands that the scope and purpose defined in the inception phase be
scrutinized and broken down into the essential building blocks needed to begin

2X3
Project Management

developing the specific architecture for the software program. Each aspect of
the program is analyzed thoroughly and the relationship between individual
functions is defined.
After completion of the elaboration phase, the construction phase of the Rational
Unified Process begins. Here, all the building blocks that were identified and
created during the elaboration phase begins to be assembled into a workable
product. It is here that the programmer begins to lay out the final application
design and also refines the source code. Beta testing also takes place during
this phase.

The final stage of the Rational Unified Process is known as the transition phase.
This is simply the point at which the programmer's work is essentially done
and the software is made available to end users.

Pha~cs

.Dfsdp.....

• 8uSlni!$'S MCCfeling

a R~q\llramerts

o Nlaf)ltls&Otl'll!ll"

o mJ>ternent:aecn
• Teet
• DepiGJJ~Mn1
• Comtlf,J~Oit &.
Ch•n~~~tMGm

• ,.,._,jed Management

• Emtn:mmanl

Fig. 11.2: Rational Unified Process Phases

There are several benefits of using RUP:

1. It enhances team collaboration

IBM has several other tools for increased collaboration among the team such
as Rational Team Unifying Platform which integrates with RUP to provide the

284
Unit 11 Update Yourself: Current Trends

best possible team performance. You can easily determine if a RUP team is on
track or not, and redirect them if required.

2. Addresses project risk with iterative processes

Working incrementally allows higher risks to be addressed early. If there is a


question about whether or not a requirement can be met or a technical challenge
can be overcome, it can be addressed in an early iteration. If it cmmot be
implemented or can be implemented but in a manner which docs not meet the
stakeholders' needs, the project can be refocused or cancelled outright.

3. Improved governance

As you can monitor the performance of the team and because of the iterative
nature of the process, the governance metrics can be defined and managed
easily.

4. Implement the actual requirements

By developing systems in smaller iterations, you can react to any changes and
thereby build software which meets the actual needs of your stakeholders instead
of their perceived needs which were documented months or years earlier.
Changes in requirements that impact later iterations do not impact the work
being done on the current iteration. In addition, changes to requirements within
the current iterations arc easier to deal with because the scope of requirements
in each iteration is smaller. Chm1ges to previous iterations are simply scheduled
as new requirements in future iterations.

£S Activity D:
A. What arc the different phases defined in RUP?

285
Project Management

B. List down the benefits of RUP.

2. Agile Software Development

The very meaning of the term agile is lively, alert, and responsive. In a way,
this methodology tries to be an alert and responsive methodology of project
management. In 200 I. this term was coined when the agile manifesto was
formulated. This method is based on iterative development and self-organizing
team work. Agile project management takes the ideas from Agile software
development and applies them to project management. Agile methodologies
generally promote a project management process that encourages stakeholder
involvement, feedback, objective metrics and effective controls.

Following methods arc popularly used in Agile practices:

1. Extreme Programming (XP)

It is intended to improve software quality and responsiveness to changing customer


requirements. It advocates frequent releases in short development cycles, which is
intended to improve productivity and introduce checkpoints where new customer
requirements can he adopted. Extreme Programming has been dcsc1ibcd as having
12 practices, grouped into four areas:

1. Fine scale feedback by the means of pair programming, ~mQ, test-


driven development. whole team

2. Continuous process which is exercised by continuous integration, .refactoring


or design improvement and small releases

3. Shared understanding for coding standards, collective code ownership, simple


design, system metaphor

4. Programmer welfare i.e. sustainable pace

286
Unit 11 Update Your!>clf: Current Trends

The concept is that programmers or software developers should not work more
than 40 hour weeks, and if there is overtime one week, that the next week
should not include more overtime.

"Fig. 11.3: Processes in extreme programming

The methodology takes its name from the idea that the beneficial clements of
traditional software cngineeting practices arc taken to "extreme" levels.

2. l<'eature Driven Development (FDD)

FDD blends a number of industry-recognized pest practices into a cohesive whole.


Its main purpose is to deliver tangible, working software repeatedly in a timely
manner.

A feature is a client-valued functionality. The process model is based on the features


at its centre. The best features used in FDD arc listed below:

1. Domain Object Modelling: Domain Object Modelling consists of exploring


and explaining the domain of the problem to be solved. The resulting domain
object model provides an overall framework in which to add features.

287
Project Management

2. Developing by Feature: Any function that is too complex to be implemented


within two weeks is further decomposed into smaller functions until each sub-
problem is small enough to be called a feature. This makes it easier to deliver
correct functions and to extend or modify the system.

3. Individual Class (Code) Ownership: Individual class ownership means that


distinct pieces or grouping of code are assigned to a single owner. The owner is
responsible for the consistency, performance, and conceptual integrity of the
class.

4. Feature Teams: A feature team is a small, dynamically formed team that develops
a small activity. By doing so, multiple minds are always applied to each design
decision and also multiple design options arc always evaluated before one is
chosen.

5. Inspections: Inspections are carried out to ensure good quality design and code,
primarily by detection of defects.

6. Configuration Management: Configuration management helps with identifying


the source code for all features that have been completed to date and to maintain
a history of changes to classes as feature teams enhance them.

7. Regular Builds: Regular builds ensure there is always an up to date system that
can be demonstrated to the client and helps highlighting integration errors of
source code for the features early.

8. Visibility of progress and results: By frequent, appropriate, and accurate progress


reporting at all levels inside and outside the project, based on completed work,
managers arc helped at steering a project correctly.

288
linit ll Update Yourself: Current Trends

ltievelop ~ ModeJ
( Por-m~1'~
• )

( ~= )
,........._....,~-
( $till~'~ )
l
(01~~~.-ar~~)

1
j"
( ~T~~ Modf;l

.J,
( ~OYar~! ~'1 '-'kdnl ( ................... )
J,

'
~-Featlll'O Uat
( FcnnN:!~~tTu~~l

c a.tld F"ol!!'!lltur. 1.ti;f )

(Plan By f'eilllure
( FOiftl A:uvU..g Tftl;m• "
J..
( ~~;;;OJnr.ff~:) ( A~~~~=:;..re~ ) ( Matvn;;;;:~
OtM::obpll!ts )
rb••lgn Qy Felltul'a ( fiOJM'I-Fca&r:.:s fawn )
10""1 -* ~-ltl\l:@ll'~lltatlftl
1
j, J.
tA:HVJ J..tOI DOfYllln
( W .:tk.mJtJ!AQh ( ""'""""""""""'
~. )
j, !
I
O~p~
( D~•) )
.J,
c Rufina ObFCI Mc:ldct

( ....... '~U.:'"""""' )
.t
c D~r..tllpo<=t.en

I
)

(BuudByl'e......
c -
Cbli&M:• IWid Nt!11~
_ __j,
-
)

c lrwipof; t C~ ) ( C.cn:itd Unit 'Tas1 )


j, -·
c Prmnott;; H) fiutd )


I

Fig. 11.4: Process model of feature driven development

289
Project Management

3. Dynamic System Development Method (DSDM)

Its goal is to deliver software systems on time and on budget while adjusting for
changing requirements along the development process. DSDM is one of a number
of Agile methods for developing software, and it forms a part of the Agile Alliance.

There are three phases in DSDM namely, the pre-project, the project life-cycle and
the post-project phase. In turn, the project life-cycle has four phases, the feasibility
study, the business study, functional model iteration, design and builds iteration and
implementation.

Feasibility

Fundional Mode I Implementatiot


Iteration

Design and build


Iteration

Fig. 11.5: The processes followed in DSDM

Following factors are identified as success factors;


Factor I: First there is the acceptance of DSDM by senior management and other
employees. This ensures that the different actors of the project arc motivated from
the start and remain involved throughout the project.
Factor 2: The second factor follows directly from this and that is the commitment of
management to ensure end-user involvement. The prototyping approach requires a
strong and dedicated involvement by end user to test and judge the functional
prototypes.
Factor 3: Then there is tl1e project team. This team has to be composed of skilful
members that form a stable union. An important issue is the empowerment of the
project team. This means that the team (or one or more of its members) has to
possess the power and possibility to make important decisions regarding the project
without having to write fom1al proposals to higher management, which can be very
time-consuming. In order for the project team to be able to run a successful project,
they also need the right technology to conduct the project. This means a development
environment. project management tools, etc.

290
l;nit 11 l:pdat~ Yourself: Current Trends

Pactor 4: Finally DSDM also states that a supportive relationship between customer
and vendor is required. This goes for both projects that are released internally within
companies or by outside contractors. An aid in ensuring a supporting relationship
could be ISPL

4. Serum

Serum is a ''process skeleton," which contains sets of practices and predefined roles.
The main roles in Serum arc:

• The "ScrumMastcr'', who maintains the processes (typically in lieu of a project


manager);

• The "Product Owner", who represents the stakeholders;

• The "Team'', is a cross-functional group of about 7 people who do the actual


analysis, design, implementation, testing, etc.

PCTENTlA.&.J...Y
PADDUCT SP~INT !!IHI....ABL.II:
BACKL.DIJ PRODUCt

J<'ig. 11.6
A key principle of Serum is it<> recognition that during a project the customers can
change their minds about what they want and need (often called requirements churn),
and that unpredicted challenges cannot be easily addressed in a traditional predictive
or planned manner. As such, Serum adopts an empirical approach - accepting that
the problem cannot be fully understood or defined, focusing instead on maximizing
the team's ability to deliver quickly and respond to emerging requirements.

There arc several implementations of systems for managing the Serum process,
which range from yellow stickers and whitcboards, to software packages. One of

291
Project Management

Serum's biggest advantages is that it is very easy to learn and requires little effort to
start using.

2S Activity E:
A. List the features used in FDD.

B. Why is extreme programming given the name so?

3. I..ean principles in software development

Lean manufacturing originated in manufacturing industry in late 1940s and is


practiced successfully by Toyota. As software industry started getting mature, the
need was felt to optimize the processes used in developing and managing software.
As we know
Profit = price - cost,
And we cannot increase price to make more profits. The only way is to reduce the
cost of developing the software if we have to make maximum profits. This is where
lean principles can guide software development.
The principles were studied and configured to suit software industry. The principles
are as follows:
1. Eliminate waste

In software development, waste can be in terms of extra features, requirements,


extra steps, bugs not caught by testers, time wasted waiting for decisions,
handoffs/transformation.

292
Unit ll lJpdatc Yourself: Current Trends

2. Amplify learning
Using short iteration cycles, mistakes can be detected at an early stage which
can add to learning. Short feedback sessions with the customers, help in
determine the current and future features.

3. Decide as late as possible


Project keeps on elaborating progressively so it is better to delay the decisions
till late. In meanwhile, customers also get a better understanding of their own
requirements. The costly rework can be avoided by this practice.

4. Deliver as fast as possible


The sooner a feature is delivered without bugs, the sooner the feedback is
received for further enhancements or changes. With the advent of new
technologies, it is possible to deliver the features fast. Everyday stand up
meetings make it possible to review the dclivcrables on a continuous basis
speeding up the delivery.

5. Empower the team


Here the philosophy is to recognize the contribution made by each employee
and treat them as human beings and not just resources. The practice of pair
programming makes it possible to empower the novice or less experienced
employees to learn from their expert counterparts.

6. Build integrity in
The customer needs to have an overall experience of the system - this is the so
called perceived integrity: how it is being advertised, delivered, deployed,
accessed, how intuitive its use is, price and how well it solves problems.

7. See the whole


The larger the system, the more organizations that are involved in its
development and the more parts are developed by different teams, the greater
the importance of having well defined relationships between different vendors,
in order to produce a system with smoothly interacting componenl'i.

The principles arc integrated in Agile project management practices also. In


all, there are 22 tools defined on software development processes to follow
lean principles.

293
Project :Ylanagcmcnt

Sr. No. Tool Sr. No. Tool

1 Seeing waste 12 Cost of delay

2 Value stream mapping 13 Self determination

3 Peedback 14 Motivation

4 Iterations 15 Leadership

5 Synchronization 16 Expertise

6 Set based development 17 Perceived integrity

7 Options thinking 18 Conceptual integrity

8 The last responsible moment 19 Refactoring

9 Making decisions 20 Testing

10 Pull systems 21 Measurements

11 Queuing theory 22 Contracts

The advantages of lean software project management can be stated as:

1. The elimination of waste leads to the overall efficiency of the development


process. This in turn speeds up the process of software development which
reduces project time and cost. This is absolutely vital in today's environment.
Anything which allows organizations to deliver more projects in the same
timeframe is going to be popular!

2. Delivering the product early is a definite advantage. It means your development


team can deliver more functionality in a shorter period of time, hence enabling
more project<; to be delivered. This will not only please your finance department,
but also the end customers.

3. Empowerment of the development team helps in developing the decision making


ability of the team members which in turn, creates a more motivated team. This
benefit really cannot he overstressed enough. Developers hate nothing more
than being micro-managed and having decisions forced upon them. This way

294
Unit ll Update Yourself: Current Trends

they can determine how best to develop the functionality which will usually
result in a much better end product.

RSActivity F:
A. List the seven principles used in lean philosophy.

B. List the tools used with reference to the principle "Empower the team".

11.6 SUMMARY

In this unit, we discussed what the current trends in managing software projects arc.
Managing global software projects needs a special skill set as well as special
infrastructure. But with the invent of global projects, the world has shrunk in its true
sense and has become a global village . .!'\ow the best offers can be made to the
customers with the competent cosL<; as well as profit margins for the business arc
increasing with the global market.

Also, we have seen that the new software development models arc designed in such
a way that they support project management. So we can conclude that the
distinguishing line between software engineering and project management is
diminishing. The software stream is also getting mature like manufacturing or civil
streams by following their respective best services. To conclude, newer models will
be practiced in software development and they will demand new ways of handling
software projects.

295

Вам также может понравиться