0% found this document useful (0 votes)
18 views

module-4

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views

module-4

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 44

21CS61 Software Engineering &Project Management

MODULE-4

1.1 INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT


1. Software Project Management is an art & Science of planning & leading software Projects
from ideas to reality.

2. A Software Project is the complete procedure of software development from requirement


gathering to testing and maintenance, carried out according to the execution
methodologies, in a specified period of time to achieve intended software product

3. Project management is the discipline of defining and achieving targets while optimizing
the new resources (time, money, people, materials, energy, space , etc.) over the course of
a project (a set of activities of finite duration).

4. Project management involves the planning, monitoring, and control of people, process, and
events that occur during software development.

Everyone manages, but the scope of each person’s management activities varies according his or
her role in the project.

Software needs to be managed because it is a complex undertaking with a long duration time.

Managers must focus on the fours P’s to be successful (people, product, process, and project).

A project plan is a document that defines the four P’s in such a way as to ensure a cost effective,
high quality software product.

The only way to be sure that a project plan worked correctly is by observing that a high-quality
product was delivered on time and under budget.
1.2 WHY IS SOFTWARE PROJECT MANAGEMENT IMPORTANT?
• Large amounts of money are spent on ICT (information and communication technology)
e.g. UK government in 2003-04 spent € 2.3 billion on contracts for ICT and only € 1.4
billion on road building. (1 billion =100 crore).
• Project often fail – Standish Group claim only a third of ICT projects are successful. 82 %
were late and 43 % exceeded their budget. Poor project management a major factor in these
failures.
• The methodology used by the Standish Group to arrive at their findings has been criticized,

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 1
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

but the general perception of the prevalence of ICT project failure is still clear.

Software Development Life Cycle:

The Software Development life cycle is a methodology that also forms the framework for
planning and controlling the creation, testing, and delivery of an information system.

The software development life cycle concept acts as the foundation for multiple different
development and delivery methodologies, such as the Hardware development life -cycle and
software development life -cycle . While Hardware development life -cycle deal specially with
hardware and Software development life -cycle deal with software, a systems development life -
cycle differs from each in that it can deal with any combination of hardware and software , as a
system can be composed of hardware only , software only, or a combination of both.

Four Project Dimensions:

o People
o Process
o Product
o Technology

The 5 Variables of Project Control


1. Time: amount of time required to complete the project.
2. Cost: calculated from the time variable
3. Quality: The amount of time put into individual tasks determines the overall quality of the
project.
4. Scope: Requirements specified for the end result.
5. Risk: Potential points of failure.

Trade -off Triangle

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 2
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

The triangle illustrates the relationship between three primart forces in a project. Time is the
available time to deliver the project. Cost represents the amount of money or resources available
and quality represents the fit-to-purpose that the project must achieve to be a scuccess.

The normal situation is that one of thse factors is fixed and the other two will vary in inverse
proportion to each other. For example , time is often fixed and the quality of the end product will
depend on the cost and resources available. Similarly if you are working to a fixed level of quality
then the cost of the project will largely be dependable upon the time available(if you have longer
you can do it with fewer people).

1. Complexity Management
o Software projects often involve intricate systems and interdependencies. Effective
management of this complexity ensures that the project remains coherent and
manageable.
2. Requirement Management
o Clear and precise requirement management is essential to ensure that the final
product meets user needs and expectations. Mismanagement here can lead to scope
creep and project failure.
3. Time and Budget Control
o Monitoring and controlling the project timeline and budget is vital. This includes
planning, estimating, and adhering to schedules and financial constraints to prevent
overruns.
4. Risk Management
o Identifying, assessing, and mitigating risks can prevent unforeseen issues from

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 3
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

derailing a project. This proactive approach helps in managing uncertainties


effectively.
5. Quality Assurance
o Ensuring that the project meets quality standards is crucial for user satisfaction and
reducing post-release defects. Continuous testing and validation are key practices.
o
6. Team Coordination
o Effective communication and coordination among team members are essential for
collaboration and timely problem-solving, ensuring that everyone is aligned with
project goals.
o
7. Stakeholder Management
o Engaging and managing stakeholders helps in gaining their support and addressing
their concerns, which is critical for project acceptance and success.
8. Scope Management
o Defining and controlling what is included in the project prevents scope creep,
ensures that all necessary features are delivered, and avoids unnecessary work.
9. Process Improvement
o Continuously improving processes ensures that the project is using the most
efficient methods and practices, leading to better performance and outcomes.
10. Resource Allocation
o Efficient allocation and management of resources (human, financial, and material)
ensure that the project has what it needs to succeed without wastage.

Statistics Highlighting the Importance of Efficient Project Management

1. 32% of Projects Fail Due to Poor Management


o This statistic underscores the critical impact of project management on the overall
success of software projects. Poor management can lead to project failures,
highlighting the need for skilled project managers.
2. 68% of Projects Fail to Meet Deadlines, Budgets, and Quality Targets
o This indicates that a significant majority of projects struggle with time, budget, and
quality control. Effective project management practices in these areas can
significantly improve success rates.
3. 97% of Businesses Believe Project Management is Essential for Success
o This near-unanimous belief among businesses highlights the recognized value of
project management. It underscores that investing in good project management
practices is seen as crucial for achieving business objectives.
4. 80% of High-Performing Projects are Led by a Project Manager with Qualifications
o This shows a clear correlation between the qualifications of the project manager
and the performance of the project. Qualified project managers bring skills and
knowledge that drive project success.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 4
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

5. On Average, a Large IT Project Runs 45% Over Budget


o This statistic points to common budget overruns in large IT projects, emphasizing
the need for rigorous budget control and efficient resource management to prevent
financial overshooting.

Conclusion

Effective software project management is essential due to the inherent complexities and challenges
of software development. The key areas outlined require diligent attention and management to
ensure project success. The statistics provided illustrate the high stakes involved and the
substantial impact that good project management can have on the success rates of software
projects. By focusing on these areas, businesses can significantly improve their chances of
delivering successful projects that meet deadlines, stay within budget, and satisfy quality
standards.

1.3 WHAT IS A PROJECT:

The definition of a project as being planned assume that to a large extent we can determine
how we are going to carry out a task before we start. There may be some projects of an
exploratory nature where this might be quite hard. Planning is in essence thinking carefully
about something before you do it and even in the case of uncertain projects this is worth doing
as long as it is accepted that the resulting plans will have provisional and speculative elements.
Other activities, concerning, for example, to routine maintenance, might have been performed
so many times that everyone involved knows exactly what needs to be done. In these cases,
planning hardly seems necessary, although procedures might need to be documented to ensure
consistency and to help newcomers to the job.
Dictionary definitions of ‘project’ include:
• A specific plan or design
• A planned undertaking
• A large undertaking e.g. a public works scheme”
Key points above are planning and size of task

Here are some definitions of ‘project’. No doubt there are other ones: for example,

‘Unique process, consisting of a set of coordinated and controlled activities with start and finish
dates, undertaken to achieve an objective conforming to specific requirements, including
constraints of time, cost and resources.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 5
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

There is a hazy boundary between the non-routine project and the routine job. The first time you
do a routine task, it will be like a project. On the other hand, a project to develop a system similar
to previous ones you have developed will have a large element of the routine.

Fig:1.1 Activities most likely to benefit from project management.

1.3.1 Characteristics of Project:


• Non-routine tasks are involved
• Planning is required
• Specific objectives are to be met or a specified product is to be created
• The project has a pre-determined time span
• Work is carried out for someone other than yourself
• Work involves several specialism’s
• Work is carried out in several phases
• The resources that are available for use on the project are constrained
• The project is large or complex.

The project that employs 20 developers is likely to be disproportionately more difficult than one
with only 20 staff because of the need for additional coordination.
1.3.2 Software Projects versus Other Types of Project:

Many of the techniques of general project management are applicable to software project
management. One way of perceiving software project management is as the process of making
visible that which is invisible.

Invisibility: When a physical artifact such as a bridge or road is being constructed the progress
being made can actually be seen. With software, progress is not immediately visible.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 6
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Complexity: Software products contain more complexity than other engineered artifacts.
Conformity: The ‘traditional’ engineer is usually working with physical systems and physical
materials like cement and steel. These physical systems can have some complexity, but are
governed by physical laws that are consistent. Software developers have to conform to the
requirements of human clients. It is not just that individuals can be inconsistent.
Flexibility: The ease with which software can be changed is usually seen as one of its
strengths. However, this means that where the software system interfaces with a physical or
organizational system, it is expected that, where necessary, the software will change to
accommodate the other components rather than vice versa. This means the software systems
are likely to be subject to a high degree of change.
An example for infrastructure project is construction of a flyover. An example for a software
project is development of a payroll management system for an organization using Oracle l0g
and Oracle Forms 10G.

1.4 CONTRACT MANAGEMENT

• ln-house projects are where the users and the developers of new software work for the
same organization.
• However, increasingly organizations contract out ICT development to outside
developers. Here, the client organization will often appoint a 'project manager' to
supervise the contract who will delegate many technically oriented decisions to the
contractors.
• Thus, the project manager will not worry about estimating the effort needed to write
individual software components as long as the overall project is within budget and on
time. On the supplier side, there will need to be project managers who deal with the more
technical issues.

➢ Contract management is the process of managing the creation, execution, and analysis
of contracts to maximize operational and financial performance and minimize risk.
➢ It involves various activities from the initial request for a contract, through negotiation,
execution, compliance, and renewal. Effective contract management ensures that all
parties to a contract fulfill their obligations as efficiently as possible.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 7
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Various Stages of Contract Management

1. Request and Creation:

Request: Identifying the need for a contract and gathering the necessary information to draft it.

Creation: Drafting the contract terms and conditions that align with the requirements and
objectives of all parties involved.

Example: A software company needs to hire a third-party developer to work on a new project.

The project manager identifies the need for a contract and gathers details about the scope of work,
timelines, payment terms, and other specifics.

2. Negotiation:
Parties involved discuss and negotiate the terms of the contract to reach a mutual agreement.
This stage often involves revisions and adjustments.

Example: The software company and the third-party developer negotiate the terms. The
developer might request more time or a higher payment, while the company might request
milestones for progress checks.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 8
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

3. Approval and Execution:

Approval: Obtaining necessary approvals from stakeholders and legal departments.

Execution: Signing the contract, making it a legally binding document.

Example: Once the terms are finalized, the contract is reviewed by both parties' legal teams.
After approval, both the software company and the developer sign the contract.

4. Obligations and Performance:


Ensuring that all parties adhere to the terms and conditions agreed upon in the contract.
Monitoring performance and compliance.

Example: The developer starts working on the project, adhering to the deadlines and
deliverables specified in the contract. The software company provides the necessary resources
and makes payments as per the contract.
5. Modification and Renewal:
Making necessary amendments if any changes occur during the contract period. Reviewing
and renewing contracts as needed.

Example: Midway through the project, the software company requests additional features not
covered in the original contract. An amendment is made to include these new features and
adjust the payment terms accordingly. As the project nears completion, the company and
developer may negotiate a renewal for ongoing maintenance.

6. Closure:

Completing all contractual obligations, ensuring all parties have met their requirements, and
formally closing the contract.

Example: The developer finishes the project, and the software company conducts a final
review to ensure all deliverables meet the agreed-upon standards. Once confirmed, the
contract is closed, and a final payment is made.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering Page 9
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Benefits of Effective Contract Management

Risk Mitigation: Identifies and manages potential risks early in the contract lifecycle.

Improved Compliance: Ensures that all parties comply with legal and regulatory
requirements.

Cost Savings: Avoids unnecessary costs and penalties by managing contracts efficiently.

Performance Tracking: Monitors performance against contract terms to ensure objectives


are met.

Relationship Management: Maintains positive relationships between contracting parties


through clear and consistent communication.

Speed to Market: Accelerates project timelines by leveraging the vendor’s expertise and
resources.
COMPANY: XYZ Tech

1. Identifying Needs: XYZ Tech identifies a need for a mobile app to complement its
existing software suite.

2. Selecting a Vendor: XYZ Tech shortlists several development firms based in India,
known for their expertise in mobile app development.

3. Defining Requirements: XYZ Tech provides detailed specifications, including desired


features, user interface design, and performance metrics.

4. Contract Negotiation: XYZ Tech negotiates terms, focusing on deliverables, timelines,


and confidentiality clauses.

5. Project Management: XYZ Tech assigns a project manager to liaise with the vendor,
ensuring regular updates and adherence to milestones.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 10
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

6. Delivery and Integration: The vendor delivers the app, which is integrated with XYZ
Tech’s software suite after thorough testing.

7. Post-Delivery Support: The vendor provides ongoing maintenance and support,


addressing any post-launch issues. By following these steps and learning from real-world
examples, software companies can effectively outsource projects to thirdparty vendors,
ensuring successful project completion and maximizing business value.

1.5 ACTIVITIES COVERED BY SOFTWARE PROJECT MANAGEMENT:

The activities covered by Software Project management are diagrammatically illustrated as


follows:

1.5.1 The Feasibility Study:


This is an investigation into whether a prospective project is worth starting that it has a
valid business case. Information is gathered about the requirements of the proposed application.
The probable developmental and operational costs, along with the value of the benefits of the new
system, are estimated. The study could be part of a strategic planning exercise examining and
prioritizing a range of potential software developments.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 11
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

1.5.2 Planning:
If the feasibility study produces results which indicate that the prospective project appears
viable, planning of the project can take place. However, for a large project, we would not do all
our detailed planning right at the beginning. We would formulate an outline plan for the whole
project and a detailed one for the first stage. More detailed planning of the later stages would be
done as they approached. This is because we would have more detailed and accurate information
upon which to base our plans nearer to the start of the later stages.
1.5.3 Project Execution:
The project can now be executed. The execution of a project often contains design and
implementation subphases. The same is illustrated in Figure 1.2 which shows the typical
sequence of software development activities recommended in the international standard ISO
12207.
1.5.3.1 Requirements Analysis:
This starts with requirement elicitation or requirement gathering which establishes what
the users require of the system that the project is to implement. Some work along these lines
will almost certainly have been carried out when the project was evaluated, but now the
original information obtained needs to be updated and supplemented.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 12
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

1.5.3.2 Specification:
Detailed documentation of what the proposed system is to do.

1.5.3.3 Design:
A design has to be drawn up which meets the specification. This design will be in two
stages. One will be the external or user design concerned with the external appearance of the
application. The other produces the physical design which tackles the way that the data and
software procedures are to be structured internally.
➢ Architecture Design: This maps the requirements to the components of the system that is
to be built. At the system level, decisions will need to be made about which processes in
the new system will be carried out by the user and which can be computerized. This design
of the system architecture thus forms an input to the development of the software
requirements. A second architecture design process then takes place which maps the
software requirements to software components.

➢ Detailed Design: Each software component is made up of a number of software units that
can be separately coded and tested. The detailed design of these units is carried out
separately.
1.5.3.4 Coding:
This may refer to writing code in a procedural language or an object-oriented language or
could refer to the use of an application-builder. Even where software is not being built from
scratch, some modification to the base package could be required to meet the needs of the new
application.

1.5.3.5 Testing (Verification and Validation):


Whether software is developed specially for the current application or not, careful testing
will be needed to check that the proposed system meets its requirements.

Integration: The individual components are collected together and tested to see if they meet
the overall requirements. Integration could be at the level of software where different software
components are combined, or at the level of the system as a whole where the software and
other components of the system such as the hardware platforms and networks and the user

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 13
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

procedures are brought together.

Qualification Testing: The system, including the software components, has to be tested
carefully to ensure that all the requirements have been fulfilled.
1.5.3.6 Implementation/ Installation:
Some system development practitioners refer to the whole of the project after design as
‘implementation’ (that is, the implementation of the design) while others insist that the term
refers to the installation of the system after the software has been developed.
1.5.3.7 Acceptance Support:
Once the system has been implemented there is a continuing need for the correction of any
errors that may have crept into the system and for extensions and improvements to the system.
Maintenance and support activities may be seen as a series of minor software projects.

1.6 PLANS, METHODS AND METHODOLOGIES

A plan for an activity must be based on some idea of a method of work. To take a simple
example, if you were asked to test some software, even though you do not know anything about
the software to be tested, you could assume that you would need to:
• Analyze the requirements for the software
• Devise and write test cases that will check that each requirement has been satisfiedCreate
test scripts and expected results for each test case
• Compare the actual results and the expected results and identify discrepancies

While a method relates to a type of activity in general, a plan takes that method (and perhaps
others) and converts it to real activities, identifying for each activity:

• Its start and end dates


• Who will carry it out?
• What tools and materials will be used?

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 14
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

‘Materials’ in this context could include information, for example a requirements document. With
complex procedures, several methods may be deployed, in sequence or in parallel. The output from
one method might be the input to another. Groups of methods or techniques are often referred to
as methodologies.

1.7 SOME WAYS OF CATEGORIZING SOFTWARE PROJECTS

Distinguishing different types of projects is important as different types of tasks need different
project approaches e.g.

➢ Changes to the characteristics of software projects


➢ Voluntary systems (such as computer games) versus compulsory systems e.g. the
order processing system in an organization
➢ Information systems versus embedded systems.
➢ Software Products verses services
➢ Product-development versus outsourced.
➢ Object-driven development.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 15
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

1.7.1 Changes to the characteristics of software projects


• Over the last few decades, the characteristics of software projects have undergone
drastic changes. In earlier days of software development every software was being
written from scratch and there was no code reusability. In contrast, at present almost
every programming language supports ways of reusing existing code, by customizing
and extending existing code, efficiently and dynamically linking library routines and
support for frameworks.
• Project durations have now shrunk to only a few months compared to multi-year
projects.
• In past, customer participation in software projects was largely restricted to only initial
interactions, gathering and specification and taking delivery of the developed
software, but at present, customer participation in almost every aspect of a project.
1.7.2 Compulsory versus voluntary users
In workplaces there are systems that staff have to use if they want to do something, such
as recording a sale. However, use of a system is increasingly voluntary, as in the case of
computer games. Here it is difficult to elicit precise requirements from potential users as we
could with a business system. What the game will do will thus depend much on the informed
ingenuity of the developers, along with techniques such as market surveys, focus groups and
prototype evaluation.
1.7.3 Information Systems versus Embedded systems
A traditional distinction has been between information systems which enable staff to carry
out office processes and embedded systems which control machines. A stock control system
would be an information system. An embedded, or process control, system might control the air
conditioning equipment in a building. Some systems may have elements of both where, for
example, the stock control system also controls an automated warehouse.

1.7.4 Software Products verses services


All types of software projects can broadly be classified into software product development
projects and software services projects. It can be further classified as shown in below Fig.1.7
A software product development concerns developing the software by keeping the
requirements to the general customers in mind and developed software is usually sold-off-the

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 16
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

shelf to a large number of customers. Examples of generic software development are


Microsoft’s Windows operating system and Oracle Corporatism’s Oracle 8i database
management software. Domain-specific software targets specific segments of
customers(verticals) Example BANCS from TCS. FINACLE from Infosys.

Fig: 1.7 A Classification of software projects

Software services cover a large gamut of software projects such as customization,


outsourcing, maintenance, testing and consultancy.

Projects may be distinguished by whether their aim is to produce a product or to meet certain
objectives.

1.7.5 Outsourced Projects


While developing a large project, it makes good commercial sense for a company to outsource
some parts of its work to other companies.
For example, A company may consider outsourcing as a good option, it if feels that it does
not have sufficient expertise to develop some specific parts of the product or if it determines
that some parts can be developed cost-effectively another company.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 17
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

1.7.6 Object-driven development


Projects may be distinguished by whether their aim is to produce or to meet certain objective.
Many software projects have two stages, First is an object-driven project resulting in
recommendations which identify the need for a new software system and next stage is a
project actually to create the software product.

1.8 STAKEHOLDERS
These are people who have a stake or interest in the project. It is important that they be
identified as early as possible, because you need to set up adequate communication channels with
them right from the start. The project leader also has to be aware that not everybody who is
involved with a project has the same motivation and objectives. The end-users might, for instance,
be concerned about the ease of use of the system while their managers might be interested in the
staff savings the new system will allow.

Boehm and Ross proposed a ‘Theory W’ of software project management where the
manager concentrates on creating the role and format situations where all parties benefit from a
project and therefore have an of communication interest in its success. (The 'W' stands for 'win-
win'.)

Stakeholders might be internal to the project team, external to the project team but in the
same organization, or totally external to the organization.

• Internal to the project team: This means that they will be under the direct managerial
control of the project leader.
• External to the project team but within the same organization: For example, the project
leader might need the assistance of the information management group in order to add
some additional data types to a database or the assistance of the users to carry out systems
testing. Here the commitment of the people involved has to be negotiated.
• External to both the project team and the organization: External stakeholders may be
customers (or users) who will benefit from the system that the project implements or
contractors who will carry out work for the project. One feature of the relationship with
these people is that it is likely to be based on a legally binding contract.

Different types of Stakeholders may have different objectives and one of the jobs of the
successful project leader is to recognize these different interests and to be able to reconcile them.
It should therefore come as no surprise that the project leader needs to be a good communicator
and negotiator.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 18
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

1.9 SETTING OBJECTIVES

• The objectives should define what the project team must achieve for project success.
• Objectives focus on the desired outcomes of the project rather than the tasks within it-they
are the ‘post-conditions’ of the project.
• Objectives could be set of statements following the opening words ‘the project will be a
success if ….’ .
• To have a successful software project, the manager and the project team members must
know what will constitute success. This will make them concentrate on what is essential
to project success.
• There may be several sets of users of a system and there may be several different groups
of specialists involved its development. There is a need for well-defined objectives that
are accepted by all these people. Where there is more than one user group, a project
authority needs to be identified which has overall authority over what the project is to
achieve.
• This authority is often held by a project steering committee (or project board or project
management board) which has overall responsibility for setting, monitoring and
modifying objectives. The project manager still has responsibility for running the project
on a day-to-day basis, but has to report to the steering committee at regular intervals. Only
the steering committee can authorize changes to the project objectives and resources.

1.9.1 Sub-objectives and Goals:

Setting objectives can guide and motivate individuals and groups of staff. An effective
objective for an individual must be something that is within the control of that individual. An
objective might be that the software application to be produced must pay for itself by reducing
staff costs over two years. As an overall business objective this might be reasonable. For software
developers it would be unreasonable as, though they can control development costs, any reduction
in operational staff costs depends not just on them but on the operational management after the
application has ‘gone live’. What would be appropriate would be to set a goal or sub-objective
for the software developers to keep development costs within a certain budget.

Thus, objectives will need be broken down into goals or sub-objectives. Here we say that

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 19
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

in order to achieve the objective we must achieve certain goals first. These goals are steps on the
way to achieving an objective, just as goals scored in a football match are steps towards the
objective of winning the match.
The mnemonic SMART is sometimes used to describe well defined objectives:

• Specific: Effective objectives are concrete and well defined. Vague aspirations such as
‘to improve customer relations’ are unsatisfactory. Objectives should be defined in such
a way that it is obvious to all whether the project has been successful or not.

• Measurable: Ideally there should be measures of effectiveness which tell us how


successful the project has been. For example, ‘to reduce customer complaints’ would be
more satisfactory as an objective than ‘to improve customer relations’. The measure can,
in some cases, be an answer to simple yes/no questions, e.g. ‘Can we install the new
software by 1 November 2011?’

• Achievable: It must be within the power of the individual or group to achieve the
objective.

• Relevant: The objective must be relevant to the true purpose of the project.

• Time constrained: There should be a defined point in time by which the objective
should have been achieved.

1.9.2 Measures of effectiveness

Measures of effectiveness provide practical methods of ascertaining whether an objective


has been met. ‘Mean time between failures’ (mtbf) is used to measure reliability. A measure
of effectiveness will usually be related to the installed operational system.

1.10 BUSINESS CASE

• Most projects need to have a justification or business case: the effort and expense of
pushing the project through must be seen to be worthwhile in terms of the benefits that
will eventually be felt.

• The quantification of benefits will often require the formulation of a business model which
explains how the new application can generate the claimed benefits.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 20
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Any project plan must ensure that the business case is kept intact. For example:

• The development costs are not allowed to rise to a level which threatens to exceed the
value of benefits.

• The features of the system are not reduced to a level where the expected benefits cannot
be realized.

• The delivery date is not delayed so that there is an unacceptable loss benefit.

1.11 PROJECT SUCCESS AND FAILURE

• The project plan should be designed to ensure project success preserving the business
case for the project.

• Different stakeholders have different interests, some stakeholders in a project might see
it as a success while others do not.

• The project objectives are the targets that the project team is expected to achieve—They
are summarized as delivering:
➢ The agreed functionality
➢ To the required level of quality
➢ In time
➢ Within budget

• A project could meet these targets but the application, once delivered could fail to meet
the business case. A computer game could be delivered on time and within budget, but
might then not sell.

• In business terms, the project is a success if the value of benefits exceeds the costs.

• A project can be a success on delivery but then be a business failure, On the other hand,
a project could be late and over budget, but its deliverables could still, over time, generate
benefits that outweigh the initial expenditure.
• The possible gap between project and business concerns can be reduced by having a
broader view of projects that includes business issues.

• Technical learning will increase costs on the earlier projects, but later projects benefit
as the learnt technologies can be deployed more quickly cheaply and accurately.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 21
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

• Customer relationships can also be built up over a number of projects. If a client has
trust in a supplier who has done satisfactory work in the past, they are more likely to use
that company again.

1.12 MANAGEMENT AND MANAGEMENT CONTROL

1.12.1 MANAGEMENT:
Management involves following activities:
• Planning - deciding what is to be done;
• Organizing - making arrangements;
• Staffing - selecting the right people for the job etc.;
• Directing - giving instructions;
• Monitoring - checking on progress;
• Controlling - taking action to remedy hold-ups;
• Innovating - coming up with new solutions;
• Representing - liaising with clients, users, developer, suppliers and other
stakeholders.

Much of the project manager’s time is spent only in three activities, i.e. Project Planning,
Monitoring and control. This time period during which these activities are carried out is indicated
in Fig 1.5.
It shows that project management is carried out over three well-defined stages or processes

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 22
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

irrespective of the methodology used.


In the Project initiation stage, an initial plan is made. As a project starts, the project is
monitored and controlled to process as planned. Initial plan is revised periodically to
accommodate additional details and constraints about the project as they become available.
Finally, the project is closed.
Initial project is undertaken immediately after the feasibility study phase and before starting the
requirement analysis and specification process.
Initial project planning involves estimating several characteristics of a project. Based on these
estimates all subsequent project activities are planned.
The monitoring activity involves monitoring the progress of the project. Control activities are
initiated to minimize any significant variation in the plan,
Project Planning is an important responsibility of the project Manager. During project planning,
the project manger needs to perform a few well-defined activities that have been outlined below/
Several best practices have been proposed for software project planning activities, PRINCE2 is
used extensively in UK and Europe . In USA Project management Institute’s ‘PMBOK’ which
refers to their publication “A Gude to the Project Management Body of knowledge, is used.
• Estimation: The following project attributes are estimated.
• Cost: How much is it going to cost to complete the project.
• Duration: How long is it going to take to complete the project.
• Effort: How much effort would be necessary for completing the project?

The effectiveness of all activities such as scheduling and staffing are planned at later stage.

• Scheduling: Based on estimations of effort and duration, the schedules for manpower
and other resources are developed.
• Staffing: Staff organization and staffing plans are made.
• Risk Management: This activity includes risk identification, analysis, and abatement
planning.
• Miscellaneous Plans: This includes making several other plans such as quality
assurance plan, configuration management plan etc.

While carrying out project monitoring and control activities, a project manager may sometimes
find it necessary to change the plan to cope with specific situations and make the plan more
accurate as more project data becomes available.

1.12.2 MANAGEMENT CONTROL

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 23
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Management involves setting objectives for a system and monitoring the performance of
the system.

Fig: The Project control cycle

• In the above Fig, local mangers involve in data collection. Bare details such as “location X has
processed 2000 documents” may not be useful to higher management.
• Data processing is required to transform this raw data into useful information. This might be
in such forms as “Percentage of records Processed”, average documents per day per person”,
and estimated completion date”.
• In this example , the project management might examine the “estimated completion date” for
completing data transfer for each branch. They are comparing actual performance with overall
project objectives.
• They might find that one or two branches will fail to complete the transfer of details in time.
• It can be seen that a project plan is dynamic and will need constant adjustment during the
execution of the project. A good plan provides a foundation for a good project, but is nothing
without intelligent execution.

1.13 PROJECT MANAGEMENT LIFE CYCLE

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 24
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Software development life cycle denotes (SDLC) the stages through which a software is
developed. In contrast to SDLC, the project management life cycle typically starts well before the
software development activities start and continues for the entire duration of SDLC. (Fig 1.7)

In Project Management process, the project manager carries out project initiation, planning,
execution, monitoring, controlling and closing.

The different phases of the project management life cycle are shown in Fig: 1.8.

1. Project Initiation: The project initiation phase starts with project concept development.
During concept development the different characteristics of the software to be developed
are thoroughly understood, which includes, the scope of the project, the project constraints,
the cost that would be incurred and the benefits that would accrue. Based on this
understanding, a feasibility study is undertaken to determine the project would be
financially and technically feasible.
Based on feasibility study, the business case is developed. Once the top management
agrees to the business case, the project manager is appointed, the project charter is
written and finally project team is formed. This sets the ground for the manager to start

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 25
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

the project planning phase.

W5HH Principle: Barry Boehm, summarized the questions that need to be asked and answered in
order to have an understanding of these project characteristics.

➢ Why is the software being built?


➢ What will be done?
➢ When will it be done?
➢ Who is responsible for a function?
➢ Where are they organizationally located?
➢ How will the job be done technically and managerially?
➢ How much of these each resource is needed.

2. Project Bidding: Once the top management is convinced by the business case, the project
charter is developed. For some categories of projects, it may be necessary to have formal
bidding process to select suitable vendor based on some cost-performance criteria. The
different types of bidding techniques are:

• Request for quotation(RFQ) : An organization advertises an RFQ if it has good


understanding of the project and the possible solutions.

• Request for Proposal(RFP) : An organization had reasonable understanding of


the problem to be solved, however, it does not have good grasp of the solution
aspects. i.e. may not have sufficient knowledge about different features to be
implemented. The purpose of RFP is to get an understanding of the alternative
solutions possible that can be deployed and not vendor selection. Based on the RFP
process, the requesting organization can form a clear idea of the project solutions
required, based on which it can form a statement work (SOW) for requesting RFQ
for the vendors.

• Request for Information (RFI): An organization soliciting bids may publish an


RFI. Based on the vendor response to the RFI, the organization can assess the
competencies of the vendors and shortlist the vendors who can bid for the work.

3. Project Planning: An importance of the project initiation phase is the project charter.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 26
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

During the project planning the project manger carries out several processes and creates
the following documents:
• Project plan: This document identifies the project the project tasks and a schedule
for the project tasks that assigns project resources and time frames to the tasks.
• Resource Plan: It lists the resources , manpower and equipment that would be
required to execute the project.
• Functional Plan: It documents the plan for manpower, equipment and other costs.
• Quality Plan: Plan of quality targets and control plans are included in this
document.
• Risk Plan: This document lists the identification of the potential risks, their
prioritization and a plan for the actions that would be taken to contain the different
risks.

4. Project Execution: In this phase the tasks are executed as per the project plan developed
during the planning phase. Quality of the deliverables is ensured through execution of
proper processes. Once all the deliverables are produced and accepted by the customer, the
project execution phase completes and the project closure phase starts.

5. Project Closure: Project closure involves completing the release of all the required
deliverables to the customer along with the necessary documentation. All the Project
resources are released and supply agreements with the vendors are terminated and all the
pending payments are completed. Finally, a postimplementation review is undertaken to
analyze the project performance and to list the lessons for use in future projects.

1.14 TRADITIONAL VERSUS MODERN MANAGEMENT PRACTICES


Over the last two decades, the basic approach taken by the software industry to develop software
has undergone a radical change.

Software is not developed from scratch any more, Software development projects are based on
either tailoring some existing product or reusing certain pre-built libraries both will maximize
code reuse and compression of project durations.

Other goals include facilitating and accommodating client feedback and client feedbacks and
customer participation in project development work and incremental delivery of the product

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 27
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

with evolving functionality.

Some Important difference between modern management practices and traditional practices are:

• Planning Incremental Delivery: Earlier, projects were simpler and therefore more
predictable than the present-day projects. In those days, projects were planned with
sufficient detail much before the actual project execution started. After the project
initiation, monitoring and control activities were carried out to ensure that the project
execution proceeded as per plan, Now, the projects are required to be completed over a
much shorter duration, and rapid application development and deployment are considered
key strategies.
Instead of making a long-term project completion plan, the project manger now plans all
incremental deliveries with evolving functionalities. This type of project management is
often called extreme project management. Extreme project management is highly
flexible approach that concentrates on human side of project management(e.g. managing
project stakeholders).

• Quality Management: Customer awareness about product quality has increased


significantly. The key responsibility of a project manager now includes assessment of
project progress and tracking the quality of all intermediate artifacts.

• Change Management: Earlier, when the requirements were signed off by the customer,
any changes to the requirements were rarely entertained. Customer suggestions are now
actively solicited and incorporated throughout the development process. To facilitate
customer feedback, incremental delivery models are popularly being used. Product
development is being carried out through a series of product versions implementing
increasingly greater functionalities. The Project manager plays a key role in product base
lining and version control. This has made change management a crucial responsibility of
the project manager. Change Management is also known as configuration management.

• Requirement Management: In older development methodologies , the requirements had


to be identified upfront and these were ‘signed off’ by the customer and frozen before the
development could start. At present , in most projects, the requirements change frequently
during the development cycle. Requirement management has therefore become a
systematic process of controlling changes, documenting , analyzing, tracing, prioritizing

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 28
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

requirements and then communicating the changes to the relevant stakeholders.

• Release Management: Release management concerns planning, prioritizing and


controlling the different releases of a software. Modern development processes such as
Agile development processes advocate frequent and regular releases of the software to be
made to the customer during the software development. Starting with the release of basic
or core functionalities of the software, more complete functionalities are made available to
the customer every couple of weeks . Hence effective Release Management has become
important.

• Risk Management: In modern software development practices. Effective risk


management is considered very important to the success of a project. A risk is any negative
situation that may arise as the project progresses and may threaten the success of the
project. Risk Management involves identification of risks, assessment of the impacts of
various risks, prioritization of the risks and preparation of risk-containment plans.

• Scope Management: Modern software development encourages customer to come up with


change requests. While accepting the requests, three critical project parameters: scope ,
schedule and project cost are interdependent and related.
Additional Learning—1.12 MANAGEMENT

Case Study: Paul Duggan is the manager of a software development section. On Tuesday at 10.00
am he and his fellow section heads have a meeting with their group manager about the staffing
requirements for the coming year. Paul has already drafted document ‘bidding’ for staff’. This is
based on the work planned for his section for the next year. The document is discussed at the
meeting. At 2.00 pm Paul has a meeting with his senior staff about an important project his section
is undertaking. One of the software development staff has just had a road accident and will be in
hospital for some time. It is decided that the project can be kept on schedule by transferring
another team member from less urgent work to this project. A temporary replacement is to be
brought in to do the less urgent work, but this might take a week or so to arrange. Paul has to
phone both the personnel manager about getting a replacement and the user for whom the less
urgent work is being done explaining why it is likely to be delayed. Identify which of the eight
management responsibilities listed above Paul was responding to at different points during his
day.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 29
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Project Planning: In the project initiation stage, an initial plan is made. As the project start, the
project is monitored and controlled to proceed as per the plan. But, the initial plan is refined from
time to time to factor in additional details and constraints about the project become available.

Based on the details of Paul Duggan's day, we can map his activities to the eight management
responsibilities. The typical management responsibilities include:

1. Planning: Setting objectives and deciding on the actions needed to achieve them.
2. Organizing: Arranging tasks, people, and other resources to accomplish the work.
3. Staffing: Recruiting, selecting, training, and developing employees.
4. Directing: Leading, motivating, and communicating with employees.
5. Controlling: Monitoring and evaluating performance.
6. Coordinating: Ensuring all parts of the organization are working together towards
common goals.
7. Reporting: Keeping all stakeholders informed.
8. Budgeting: Planning and controlling financial resources.
Let's analyze Paul's day:
1. Drafting the document ‘bidding’ for staff:
o Planning: Paul is planning the staffing needs for the next year based on the
upcoming work for his section.
2. 10:00 am meeting with fellow section heads and group manager:
o Coordinating: Paul is coordinating with other section heads and the group
manager to ensure that the staffing requirements align with the overall needs of
the organization.
o Reporting: He is discussing and providing information about his staffing plan.
3. 2:00 pm meeting with senior staff about an important project:
o Directing: Paul is leading and discussing how to manage the project, especially in
light of the recent accident.
o Controlling: He is ensuring the project stays on schedule despite the unforeseen
incident.
4. Deciding on transferring another team member:
o Organizing: Paul is organizing his team's workload to keep the important project
on track by reallocating resources.
o Staffing: This also involves staffing decisions, as he needs to bring in a temporary
replacement.
5. Phoning the personnel manager about getting a replacement:
o Staffing: Paul is working on staffing by arranging for a temporary replacement.
6. Phoning the user about the delay in less urgent work:
o Reporting: He is informing the user about the situation and the expected delays.

In summary:

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 30
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

• Planning: Drafting the document ‘bidding’ for staff.


• Coordinating: 10:00 am meeting with section heads and group manager.
• Reporting: 10:00 am meeting and phoning the user about delays.
• Directing: 2:00 pm meeting with senior staff.
• Controlling: 2:00 pm meeting with senior staff.
• Organizing: Deciding on transferring a team member.
• Staffing: Phoning the personnel manager and deciding on a temporary replacement.

Evaluation of Individual projects

Evaluating individual projects is a crucial process in project management, as it helps determine


whether the project has met its objectives, adhered to its budget and schedule, and delivered value.
The evaluation process ensures that lessons are learned and improvements can be made for future
projects.

Technical Assessment

Technical assessment of a proposed system consists of evaluating the required functionality against
the hardware and software available. Organizational policy, aimed at the provision of a uniform and
consistent hardware/software infrastructure, is likely to place limitations on the nature of technical
solutions that might be considered. The constraints will, of course, influence the cost of the solution
and this must be taken into account in the cost-benefit analysis.

Cost-benefit analysis, or CBA, is a data-driven approach to evaluating a project or decision's


financial benefits and costs from a business perspective. By forecasting profitability through a
CBA, teams can work to avoid financial loss.

A CBA involves defining the project scope, identifying costs and benefits, assigning monetary
values, calculating the net present value (NPV), analyzing results, and making informed decisions.
It compares the total expected costs against the expected benefits to determine the project's overall
value and feasibility (often in the form of a ratio).

This guide will discuss the advantages and disadvantages of CBA, identify critical components of a
CBA, and explain how to conduct a cost-benefit analysis correctly.

Understanding cost-benefit analysis

Cost-benefit analysis compares a project or decision's estimated or projected costs and benefits. It’s
a vital component of project management because it measures a project’s financial feasibility and

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 31
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

helps companies avoid losses. If the analysis shows that the benefits outweigh the costs, you can
assume that the project will be profitable for your company and that it’s viable to proceed.
In contrast, if the costs exceed the expected benefits, the project is not viable and should be rejected.

You can use cost-benefit analysis in the following scenarios:

• Project initiation: CBA allows you to forecast the viability of your project by comparing the
potential benefits and costs. You can decide whether to proceed or decline based on the expected
value.
• Budgeting: You can manage multiple projects more efficiently with a limited budget. By evaluating
the anticipated benefits, CBA will tell you whether to approve your allocated budget.
• Resource allocation: You can effortlessly calculate the ROI (Return on investment) and thus
identify which projects will be more lucrative. CBA can optimize your resource allocation and
distribute them more efficiently, especially when integrated with project scheduling software.
• Risk management: Using CBA, you can assess risks and apply mitigation strategies,
leveraging Scrum to address risks iteratively and adaptively. It also enables you to allocate a budget
for potential risks based on the cost-benefit trade-offs of different contingency measures.
• Improving communication: Evaluating CBA, especially when visualized through a Kanban Board,
can help justify your project decisions and enhance transparency with a quantitative approach,
improving stakeholder communication.
• Policy development: CBA can guide you in evaluating new policies or regulations within the
project framework to apply implementation strategies. You can ensure regulatory compliance by
assessing the costs and benefits of different compliance approaches.
Using cost-benefit analysis, you can make informed decisions that evaluate your project discovery,
align with your organizational goals, optimize resource use, and maximize project value.
Due to its data-driven nature, CBA can also be applied to product analytics, product development
strategy, and other economic decisions. Whether using Agile or Waterfall methodology to manage
your projects, CBA is crucial.
Key components of a cost-benefit analysis

The key components of cost-benefit analysis are costs, benefits, timeframes, and discount rates.
These components help project managers efficiently calculate a business's costs and benefits.
You can assess the following costs throughout the CBA process:
• Direct costs: You can trace direct costs to producing a specific product or service, including labor,
materials, supplies, and wages.
• Indirect costs: You can't link indirect costs to producing goods or services. These costs include
office rent, administrative salaries, utilities, and overheads.
• Intangible costs: You can identify intangible costs, but measuring them in monetary value is
difficult. Examples of intangible costs include decreases in productivity, loss of goodwill, and
customer dissatisfaction.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 32
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

• Opportunity costs: Opportunity costs refer to choosing one project or strategy over another. For
instance, allocating resources to develop a new feature for a software project rather than improving
existing features represents an opportunity cost of potentially enhanced user satisfaction and
retention.
After identifying the costs, it’s crucial to recognize the benefits of projects that CBA measures:
• Tangible benefits: Tangible benefits are easily quantified and measured in terms of monetary
value. Examples include revenue growth, cost savings, and increased efficiency.
• Intangible benefits: Similar to intangible costs, intangible benefits are difficult to measure in
monetary value. These benefits include enhanced reputation, employee satisfaction, and customer
loyalty.
When conducting a cost-benefit analysis, you must consider both short-term and long-term costs
and benefits:
• Short-term: Short-term cost-benefit analysis gives you an idea of the immediate results you can
expect from your project. For example, hiring temporary staff for a project increases immediate
payroll expenses.
• Long-term: Long-term analysis provides a broader picture of the project's feasibility. For instance,
investing in new equipment involves maintenance and replacement costs.
The discount rate is the rate of return a company must earn from a project to be profitable. It’s
essential to find the discount rate to accurately calculate the present value of all the future cash
flows.

If not calculated correctly, it will give a false NPV, leading to wrong decision-making that can
cause project losses.

There are different approaches to calculating the discount rate, such as:
• The capital asset pricing model (CAPM): The CAPM method considers an investment's
systematic or market risk compared to the overall market.
• The build-up method: This method focuses on the company's capital structure. It calculates the
weighted average cost of capital (WACC) by considering the cost of debt and equity financing,
proportional to their usage.
• The Fama-French three-factor model: It’s a more comprehensive approach than CAPM. It
considers factors beyond market risk, incorporating size and value factors to refine the discount rate
estimate.
The CAPM model is the perfect choice for publicly traded companies as it leverages publicly
available data. The build-up method is suitable if you have detailed information regarding the
company's capital structure, including debt and equity proportions and their respective costs.

Moreover, if you have access to the necessary data on market risk, size, and value factors, the
Fama-French factor model can offer more accurate results than the other two.
Advantages of using CBA in project management

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 33
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Decision-makers need information to make crucial decisions, making CBA a helpful tool for project
management. For example, if you constantly want to evaluate your project and make decisions to
ensure a smooth and dynamic analysis, use lean methodology to avoid chaos.
Cost-benefit analysis can help you with the following aspects of project planning:
• Objective decision-making. Objective decision-making is a data-driven approach in which
analysts collect and analyze data to help make decisions. This approach is fully evidence-based and
free from biases, allowing for more informed decisions. Remember, CBA is a useful tool for
collecting relevant data.
• Risk mitigation. CBA helps the project management team identify potential issues such as budget
overruns, scope creep, resource allocation problems, risk management challenges, stakeholder
conflicts, regulatory compliance issues, technological difficulties, quality assurance problems,
market changes, environmental and social impacts, and communication breakdowns. Alternatively,
if the project seems unprofitable, the company can drop it to avoid the risk of losses.
• Resource optimization. CBA helps you identify hidden costs associated with a project. This
information provides the tools you need to generate alternate options for resource allocation and
optimize resources to minimize costs and maximize benefits.
• Stakeholder confidence. CBA increases the chance of project success because the team will only
select profitable projects. Successful projects help companies gain stakeholder confidence.
Challenges and limitations of CBA

Although CBA is crucial for the decision-making process in project management, it’s not free from
limitations.

Determining the monetary value of intangible costs and benefits can be challenging as they rely
heavily on assumptions. As a result, you may not get a clear picture of the effect of these
components. Initially, a project may seem profitable, but intangible losses underestimated during
the CBA process can lead to unexpected future losses.

Moreover, if you’re working with limited cost and benefit data, the result will not be accurate.
These factors can influence the analysis's results and lead to false predictions.
How to conduct a cost-benefit analysis for project management

Follow these steps to conduct an accurate cost-benefit analysis for your next project:

Define the project scope

The first step in cost-benefit analysis is defining the project scope and creating a framework. A
simple project plan template makes this easy. You can start by stating the purpose of the analysis.
Similarly, you should define your goals and objectives.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 34
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Determine the required resources, equipment, timeline, evaluation technique, personnel


requirements, and relevant data. At this stage, you should also identify and notify key stakeholders
so they can provide their input.

To simplify the process, use a common currency for all monetary values. Remember, this is
teamwork, and you should apply proper team management strategies to achieve the best outcome.
Identify costs and benefits

The second step is to identify all the related costs and benefits. Sit down with your project
management team and hold a brainstorming session to ensure you cover all the bases --
a brainstorming template can help keep the conversation productive. This is where you may find
hidden costs that were not apparent at first glance.
Once you identify the project’s costs and benefits, you should start categorizing them as direct,
indirect, tangible, intangible, and others. Note that you only identify the items in this step, not their
monetary values.

Assign monetary values

When you finish categorizing all the cost and benefit items, it’s time to assign them a monetary
value.

Quantifying tangible costs and benefits using market prices, historical data, and estimation
techniques should be easy, but quantifying intangible items can be difficult.

However, you can try the contingent valuation method (CVM), hedonic pricing method, cost-
effectiveness Analysis (CEA), or software to get closer to an accurate estimation and assign dollar
value more efficiently.

Calculate net present value (NPV)

The cost-benefit analysis includes many future cash inflows and outflows. Calculating their current
worth is essential to understanding their current worth.

Then, you can find the difference between the costs and benefits to calculate the NPV, which
indicates whether the project will be profitable.

The calculations include four factors: benefits (B), costs (C), interest rate or discount rate (i), and
the number of years since starting the project (t).

Below is the formula for calculating net present value:

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 35
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

NPV = B0-C0(1+i)0+B1-C1(1+i)1+......+Bt-Ct(1+i)t,
Or, NPV =

Where:

• NPV is the present value.


• t is the time period (starting from 0 up to T).
• Bt is the cash inflow at time t.
• Ct is the cash outflow at time t.
• i is the discount rate or the interest rate.
The formula uses a chosen discount rate to find the present value of all the future costs and benefits.
As discussed earlier, different methods can be used to select a discount rate for the analysis. Finding
the present value of all the future cash flows sums up the differences between the costs and benefits
to find the NPV.

Here is the simpler formula:

Net present value (NPV) = Present value of future benefits - Present value of future costs

Analyze your results

The NPV tells you whether the project will be profitable. You’ll likely get one of the three results:

• Positive: A positive value means the project will be profitable, and you can accept it.
• Negative: A negative value means it will be unprofitable, and you should ditch the project.
• Zero: A zero value means you’ll neither profit nor lose money from it.
Make informed decisions

Depending on the results of the analysis, you will need to make a decision. Meet with your project
management team and decide whether to proceed or halt the project.

Cash Flow Forecasting in Software Engineering is crucial for managing the finances of a software
development company or tech startup. This process helps ensure that the company has enough liquidity to
fund its operations, development projects, and growth initiatives while planning for any cash shortages or
surpluses. In a software business, cash flow forecasting takes into account the unique aspects of the industry,

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 36
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

such as revenue from subscriptions, software licenses, maintenance, consulting, and more.

Step-by-Step Process for Cash Flow Forecasting in Software Engineering

1. Identify Revenue Streams (Cash Inflows)

Software companies often have multiple revenue streams, including:

• Subscription Revenue: Recurring income from SaaS (Software as a Service) subscriptions or


software licensing fees. This is the most predictable revenue stream.
• One-time Software Sales: Cash received from customers purchasing perpetual software licenses or
one-time services.
• Service & Support Fees: Revenue from offering maintenance contracts, technical support, or
consulting services.
• Professional Services: Income from offering custom development, training, or implementation
services.
• Investment or Grants: Occasionally, software companies may receive funds from investors or
grants.

2. Estimate Future Cash Inflows

To forecast future revenue, consider:

• Sales Projections: Estimate the expected sales based on historical data, marketing strategies, and
growth trends. For SaaS companies, the forecast might include new customers and customer churn.
• Payment Terms: Consider the payment schedule—whether your clients pay monthly, annually, or
on a custom schedule. SaaS companies often have monthly or annual subscriptions, which should be
included in the forecast.
• Renewals and Upsells: For SaaS companies, customers often renew subscriptions or purchase
additional services over time.

3. Estimate Cash Outflows (Expenditures)

Software companies have both fixed and variable costs, such as:

• Fixed Costs:
o Salaries and wages of software developers, product managers, QA testers, and support staff.
o Rent for office space (if applicable).
o Software licenses and subscriptions for development tools (e.g., IDEs, cloud services, etc.).
o Utilities (internet, power, etc.).
• Variable Costs:
o Hosting/Cloud Costs: Fees related to cloud storage and computing power (e.g., AWS,
Azure).
o Marketing & Advertising: Budget for customer acquisition and brand promotion.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 37
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

o Research and Development: Costs to fund new software development projects, including
hiring new developers and purchasing resources.
o Legal & Compliance: Licensing fees, intellectual property protections, and other legal
expenses.
o Debt Payments: Any repayments on loans or credit.

4. Account for Investments & Capital Expenditures

Software companies may have large upfront investments such as:

• New Infrastructure: Servers, cloud infrastructure, or hardware purchases.


• Acquisitions: Buying another software company or acquiring intellectual property (IP).
• Software Development Tools: New development tools, testing platforms, or design software.

These types of cash outflows will impact your cash flow but are often long-term investments.

5. Calculate the Cash Flow for Each Period

For each forecasted period (weekly, monthly, or quarterly):

• Add Total Cash Inflows: This includes projected revenues from all the revenue streams
(subscriptions, one-time sales, services, etc.).
• Subtract Total Cash Outflows: Include fixed and variable costs, R&D, marketing, etc.
• Determine Net Cash Flow: The difference between inflows and outflows.

6. Evaluate Cash Flow Gaps or Surpluses

• If cash inflows exceed outflows, you have a cash surplus, which can be used for expansion,
reinvestment, or savings.
• If cash outflows exceed inflows, this results in a cash shortfall, and you may need to consider
additional financing options, such as a loan or investment.

7. Monitor and Adjust

Cash flow forecasting is not a one-time task. Monitor actual cash flows regularly and compare them
with the forecast to adjust projections as needed, especially if there are significant changes in
customer behavior, sales cycles, or operational costs.

Example of a Cash Flow Forecast for a Software Company

Let's assume we are forecasting the cash flow for a SaaS company for the next 3 months.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 38
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Step 1: Forecast Revenue (Cash Inflows)

• Subscription Revenue: 100 customers, each paying $1,000 annually, with 10 new
customers added each month.
o Month 1: $100,000 (100 customers × $1,000)
o Month 2: $110,000 (110 customers × $1,000)
o Month 3: $120,000 (120 customers × $1,000)
• Consulting and Professional Services: Estimated revenue from offering training,
implementation, and support services.
o Month 1: $20,000
o Month 2: $22,000
o Month 3: $25,000

Step 2: Forecast Expenses (Cash Outflows)

• Salaries and Wages: $50,000 per month for software engineers, product managers, and support
staff.
• Cloud Hosting Costs: $10,000 per month.
• Marketing and Sales: $5,000 per month to acquire new customers.
• R&D Expenses: $15,000 per month for ongoing development of new features.
• Legal & Compliance Fees: $3,000 per month.
• Miscellaneous Operating Expenses: $2,000 per month.

Step 3: Forecast Capital Expenditures

• Cloud Infrastructure Expansion: $25,000 in Month 2 for scaling the cloud infrastructure.
• New Development Tools: $10,000 in Month 3 for upgrading software development tools.

Step 4: Calculate Net Cash Flow for Each Month

Month 1:

• Cash Inflows: $100,000 (subscriptions) + $20,000 (services) = $120,000


• Cash Outflows: $50,000 (salaries) + $10,000 (cloud) + $5,000 (marketing) + $15,000 (R&D) +
$3,000 (legal) + $2,000 (misc.) = $85,000
• Net Cash Flow: $120,000 - $85,000 = $35,000 surplus

Month 2:

• Cash Inflows: $110,000 (subscriptions) + $22,000 (services) = $132,000


• Cash Outflows: $50,000 (salaries) + $10,000 (cloud) + $5,000 (marketing) + $15,000 (R&D) +
$3,000 (legal) + $2,000 (misc.) + $25,000 (cloud expansion) = $110,000
• Net Cash Flow: $132,000 - $110,000 = $22,000 surplus

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 39
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

Month 3:

• Cash Inflows: $120,000 (subscriptions) + $25,000 (services) = $145,000


• Cash Outflows: $50,000 (salaries) + $10,000 (cloud) + $5,000 (marketing) + $15,000 (R&D) +
$3,000 (legal) + $2,000 (misc.) + $10,000 (tools) = $95,000
• Net Cash Flow: $145,000 - $95,000 = $50,000 surplus

Risk evaluation

Risk evaluation is a critical process in project management, business analysis, and decision-
making, where the potential risks of a project or initiative are assessed in terms of their probability
of occurrence and the severity of their impact. The goal is to identify, assess, and prioritize risks,
and then develop strategies to manage or mitigate them effectively. Here's a detailed breakdown of
the risk evaluation process:

1. Risk Identification

The first step in risk evaluation is to identify potential risks. This involves brainstorming, using
historical data, or applying risk checklists to uncover both obvious and less apparent risks. The risks
can arise from various sources, including:

• External risks (e.g., regulatory changes, market shifts, natural disasters).


• Internal risks (e.g., resource limitations, organizational issues, technological failures).
• Project-specific risks (e.g., schedule delays, budget overruns, scope creep).

Risk identification is often done through the following techniques:

• Expert Judgment: Consulting subject matter experts.


• Risk Breakdown Structure (RBS): Organizing risks into categories based on their source
or type.
• SWOT Analysis: Analyzing strengths, weaknesses, opportunities, and threats.

2. Risk Assessment

Once risks are identified, the next step is to assess their probability (likelihood of occurrence) and
impact (the extent of the effect if the risk occurs). This assessment helps prioritize risks and focus
efforts on the most critical ones.

• Risk Probability: The likelihood of a risk occurring (usually expressed as a percentage or


rating from low to high).

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 40
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

• Risk Impact: The potential severity or consequence if the risk materializes, which could
affect cost, schedule, quality, or scope.

Risk Matrix: A common tool used in risk assessment is the Risk Probability and Impact Matrix,
which helps visually map risks by their likelihood and impact, and assign them a priority. For
example:

• Low probability, low impact = Low priority.


• High probability, high impact = High priority.

The matrix may look like this:

Impact \ Probability Low Medium High


Low Low Risk Low Risk Medium Risk
Medium Low Risk Medium Risk High Risk
High Medium Risk High Risk High Risk

This matrix helps prioritize risks so that those with the highest probability and impact are addressed
first.

3. Quantitative Risk Evaluation

For more complex projects, quantitative risk evaluation is used to provide more detailed
numerical analysis, especially when the risks are related to financial, time, or resource factors.
Quantitative risk techniques typically involve:

• Expected Monetary Value (EMV): This technique calculates the average outcome when
there is uncertainty in the project. It combines probability and impact (monetary value) to
determine the potential financial effect of risks.

Formula:

EMV=∑(Probability of Event×Monetary Impact of Event)\text{EMV} = \sum


(\text{Probability of Event} \times \text{Monetary Impact of
Event})EMV=∑(Probability of Event×Monetary Impact of Event)

• Monte Carlo Simulation: A computer-based technique that uses probability distributions to


simulate a range of possible outcomes and their likelihoods. This helps model uncertainty in
project costs, timelines, and other variables.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 41
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

• Sensitivity Analysis: This technique helps assess how changes in one or more variables
(e.g., cost estimates, timeline assumptions) affect the overall project outcome.

4. Risk Prioritization

After assessing the probability and impact of each risk, the next step is to prioritize them based on
their severity. This is done to focus resources and mitigation strategies on the most critical risks that
have the potential to derail the project. The prioritization process involves:

• Risk Scoring: Assign a score to each risk based on its probability and impact. A common
approach is multiplying the probability and impact scores to generate a total risk score.
• Pareto Analysis (80/20 Rule): Often, a small number of risks (20%) will account for the
majority (80%) of potential problems. By focusing on the highest-priority risks, teams can
reduce most of the uncertainty.
• Risk Ranking: Risks are ranked from highest to lowest according to their calculated
priority, and this helps in focusing on the most critical ones.

5. Risk Response Planning

Once risks are evaluated and prioritized, the next step is to plan how to handle or mitigate them.
The four primary risk response strategies are:

• Avoidance: Altering the project plan to eliminate the risk or its impact. For example,
changing the scope or timelines to avoid risky scenarios.
• Mitigation: Reducing the likelihood or impact of the risk. This could involve adding safety
margins to project timelines or budgets, or implementing backup systems to prevent
technical failures.
• Transfer: Shifting the risk to a third party, such as through insurance or outsourcing. For
example, purchasing insurance to cover potential property damage.
• Acceptance: Acknowledging that the risk exists and deciding to live with it. This is often
done when the cost of mitigation is higher than the potential impact of the risk, or when the
risk is deemed unlikely.

6. Monitoring and Controlling Risks

Risk evaluation doesn’t end after the initial assessment and response planning. Ongoing

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 42
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

monitoring and controlling of risks is essential throughout the life of the project to ensure that
new risks are identified and existing risks are being managed effectively.

• Risk Tracking: Regularly track identified risks and any new risks that arise. This involves
reviewing the risk register and updating the status of risk response actions.
• Risk Audits: Periodically perform audits to ensure that risk management processes are
being followed.
• Contingency Planning: Implement contingency plans if risks materialize. This includes
ensuring that there are predefined actions in place to address critical risks.

7. Risk Evaluation Tools and Techniques

Several tools and techniques can assist in risk evaluation:

• Risk Register: A document that tracks all identified risks, their assessments (probability,
impact), mitigation strategies, and their status.
• SWOT Analysis: Analyzing strengths, weaknesses, opportunities, and threats in relation to
the project.
• Bowtie Analysis: A method to visualize the cause-and-effect relationships between potential
risks, their impacts, and the controls in place.
• Fishbone Diagram (Ishikawa): A visual tool to identify potential causes of a specific risk
or problem.
• Delphi Technique: A structured method for obtaining expert opinions on risks, often used
for qualitative risk assessments.

8. Risk Evaluation Reporting

After evaluating and prioritizing risks, it’s important to report the findings to stakeholders and the
project team. A Risk Evaluation Report typically includes:

• A summary of identified risks.


• The results of the risk assessment (probability, impact, and priority).
• Proposed risk response strategies.
• A plan for monitoring and controlling risks throughout the project lifecycle.

Risk evaluation is a dynamic and ongoing process that is essential to the successful management of
projects, businesses, and investments. By identifying, assessing, prioritizing, and planning
responses to risks, organizations can reduce the likelihood of adverse outcomes and ensure the

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 43
Prof. Shyji Ealais AP / CSE
21CS61 Software Engineering &Project Management

project remains on track. Regular monitoring and adaptation are necessary to deal with new risks as
they arise and ensure that risk management strategies remain effective.

Prepared by: Prof. Sadhana R AP / CSE & Sri Sairam College of Engineering P a g e 44
Prof. Shyji Ealais AP / CSE

You might also like