SOFTWARE ENGINEERING AND

PROJECT MANAGEMENT
(BCS501)

Prepared by,
Kavya Jayaprasad
Assistant Professor
AI&ML department
AIEMS, Bidadi
 Course Outcomes

Learning Resources
 Module 4
Introduction to Project Management
 Introduction to Project Management
• 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.
• 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 .
• Project management involves planning, monitoring, and control of people,
process, and events that occur during software development.
• 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 Ps 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.
 WHY IS SOFTWARE PROJECT MANAGEMENT IMPORTANT?

• Large amounts of money are spent on ICT (information and

communication technology) projects.
• 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 in US claim that only a third of ICT
projects were successful, 82 % were late and 43 % exceeded their budget.
• Poor project management is a major factor in these failures.

• Other factors causing failure were identified as : ‘Lack of skills and

proven approach to project management and risk management’.
 What is a Project ?
• Dictionary definitions of ‘project’ include:
• A specific plan or design
• A planned undertaking
• A large undertaking e.g. a public works scheme”

• 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.

• 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.
 What is a Project ?
• Activities that benefit most from conventional project management are likely to lie
between two extremes as shown in the fig below.

• 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: Activities most likely to benefit from project management.

 What is a Project ?
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 specialisms.
• 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.
Software Projects versus Other Types of Projects
Characteristics of software projects which make them particularly difficult are:
• 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.
• 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 but also depends on
organization consistency.
• 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.
 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.
Activities Covered By Software Project Management
 Activities Covered By Software Project Management

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.
Planning:
• If the feasibility study produces results which indicate that the prospective project
appears viable, planning of the project can take place.
• 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.
Project Execution:
• The project can now be executed.
• The execution of a project often contains design and implementation subphases.
Activities Covered By Software Project Management
Sub phases in project Execution
 Sub phases in project Execution
Requirement Analysis:
• This starts with requirement elicitation or requirement gathering which
establishes what the users require of the system that the project is to
implement.
• The original information obtained needs to be updated and supplemented.

Specification:
• Detailed documentation of what the proposed system is to do.
 Sub phases in project Execution
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.
 Sub phases in project Execution
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.

Coding:
• Coding refers 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.

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.
 Sub phases in project Execution
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 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.

Implementation/ Installation:
• Some system development practitioners refer to the whole of the project
after design as ‘implementation’ while others insist that the term refers to
the installation of the system after the software has been developed.
 Sub phases in project Execution
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.
 PLANS, METHODS AND METHODOLOGIES
Plan:
• 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 satisfied
• Create test scripts and expected results for each test case
• Compare the actual results and the expected results and identify discrepancies.

Methods:
• While a method relates to a type of activity in general, a plan takes that
method 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?
‘Materials’ in this context could include information.
 PLANS, METHODS AND METHODOLOGIES
Methodologies:
• Group of methods or techniques are often referred to as methodologies.
 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
• Information systems versus embedded systems.
• Software Products verses services
• Product-development versus outsourced.
• Object-driven development.
 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.
• 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.
 Compulsory versus voluntary users
There are two types of users of systems:

Compulsory users – These are people who must use the system to do
their job.
• Example: Employees using billing software to record a sale.
• Since they have to use it, developers can clearly find out what features they
need.

Voluntary users – These are people who choose to use the system
because they want to, not because they have to.
• Example: People playing computer games.
• It’s hard to know exactly what such users want, so developers rely on
creativity, market surveys, focus groups, and testing prototypes to make the
product appealing.
 Information Systems versus Embedded systems

• Information Systems
• These systems help people manage and process information in offices or
businesses.
• Example: A stock control system used to track goods in a store or warehouse.
• They mainly deal with data and decision-making.

• Embedded Systems
• These systems are built inside machines or devices to control their operations
automatically.
• Example: A system that controls air conditioning in a building.
• They mainly deal with hardware control and automation.

• Combination of Both
• Some systems combine both features.
• Example: A stock control system that also controls an automated warehouse
(uses information processing + machine control).
 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:
 Software Products verses services
• Software Products
• These are ready-made software packages developed for many users or businesses.
• They are designed with general customer needs in mind.
• Example:
• Microsoft Windows (used by everyone)
• Oracle 8i database
• Some products are domain-specific (for a particular field):
• BANCS from TCS (for banking)
• FINACLE from Infosys (for banking)
• Software Services
• These involve customized software work done for specific clients or needs.
• Examples include:
• Customization of software
• Outsourcing
• Maintenance
• Testing
• Main Difference:
• Products are created once and sold to many customers.
• Services are developed or tailored to meet the specific goals of a particular client or
project.
 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
by another company.
 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.
 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.
 Stakeholders
• 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.
• 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.
 Setting Objectives

• The objectives should define what the project team must do to achieve success in the project.
• 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.
 Sub-Objectives and goals
• 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.
• A more appropriate goal or sub-objective for the software developers would be to
keep development costs within a certain budget.
• We can say that in order to achieve the objective we must achieve certain goals or
sub-Objectives first.
• The mnemonic SMART is sometimes used to describe well-defined objectives:
• Specific: Effective objectives are concrete and well defined. 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.
• 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.
 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.
• Project managers want to get some idea of the performance of
completed system as it is being constructed.
• They can therefore seek predictive measures.
 The Business Case
• Most projects need to have a justification or business case.
• Cost benefit analysis will often be a part of project’s feasibility
study.
• The quantification of benefits will often require the
formulation of a business model which explains how the new
application can generate the claimed benefits.
• 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.
 Project Success And Failure
• The project plan should be designed to ensure project success preserving the business case for the
project.
• 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
• In business terms, the project is a success if the value of benefits exceeds the costs.
• A project could meet these targets but the application, once delivered could fail to meet the business
case.
• A project could be late and over budget, but its deliverables could still, over time, generate benefits
that outweigh the initial expenditure.
• 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.
• 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.
 Management And Management Control
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.
 Management And Management Control
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
below:
 Management And Management Control
Project management is carried out over three well-defined stages:
❑ 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.
Management And Management Control

• Project Planning is an important responsibility of the project

Manager.

• During project planning, the project manager needs to perform a few

well-defined activities that have been outlined below:

• 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?
Management And Management Control

• 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.
Management Control
 Management Control
• Management involves setting objectives for a system and monitoring the
performance of the system.
• In the above Fig (Previous slide), local mangers involve in data collection.
• 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”.
• 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.
• 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.
 Project Management Life Cycle

• Software development life cycle (SDLC) denotes 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.
• In Project Management process, the project manager carries out project
initiation, planning, execution, monitoring, controlling and closing.
Project Management Life Cycle
 Project Management Life Cycle
• 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 the project planning
phase.
Project Management Life Cycle

• 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.
 Project Management Life Cycle
• 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
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.
 Project Management Life Cycle

• Project Planning: An importance of the project initiation phase is the

project charter.
• During the project planning the project manger carries out several
processes and creates the following documents:
• Project plan: This document identifies 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.
 Project Management Life Cycle

• 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.

• 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.
 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 with evolving functionality.
 Traditional Versus Modern Management Practices
• 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).
 Traditional Versus Modern Management Practices
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.
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 requirements and then communicating the
changes to the relevant stakeholders.
 Traditional Versus Modern Management Practices

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 .
Risk Management:
• In modern software development practices, 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.
 PROJECT EVALUATION

• The project lifecycle ensures alignment with software management

principles, including planning, execution, monitoring, and control.
Key Evaluation Criteria:
• Project Planning and Scope Management:
• Clear definition of project goals, deliverables, and scope.
• Feasibility analysis and resource allocation.
• Requirement Analysis:
• Thorough understanding of stakeholder requirements.
• Proper documentation of functional and non-functional requirements.
• Software Development Lifecycle (SDLC) Adherence:
• Implementation of an appropriate SDLC model (Agile, Waterfall, etc.).
• Analysis of how well phases like design, development, testing, and deployment are
executed.
• Risk Management:
• Identification, assessment, and mitigation of potential risks.
• Monitoring and updating risk management plans.
• Quality Assurance:
• Implementation of testing strategies (unit, integration, system testing).
• Conformance to coding standards and best practices.
 Evaluating individual projects
• Project Monitoring and Control:
• Use of metrics and key performance indicators (KPIs) to track progress.
• Change management processes to address scope creep or unexpected issues.
• Team Collaboration and Communication:
• Efficiency of collaboration tools and platforms used.
• Regular updates and effective stakeholder communication.
• Conflict resolution strategies within the team.
• Resource and Time Management:
• Analysis of resource utilization (human, technical, and financial).
• Adherence to project timelines and milestones.
• Evaluation of contingency plans for delays.
• Documentation and Deliverables:
• Completeness and clarity of technical and user documentation.
• Final deliverable quality and its alignment with initial requirements.
• Post-Implementation Review:
• Assessment of project outcomes and stakeholder satisfaction.
• Identification of lessons learned for future projects.
 Cost–benefit evaluation techniques
• This help organizations assess whether the benefits of a software project
outweigh its costs.
• These techniques enable informed decision-making by quantifying the
potential value and ensuring resource optimization.
Key techniques are:
• Cost–Benefit Analysis (CBA)
• A systematic process to compare the costs of a project against its expected benefits
in monetary terms.
• Return on Investment (ROI)
• Measures the profitability of the software investment.
• Payback Period
• The time required to recover the initial investment.
• Net Present Value (NPV)
• Evaluates the present value of future cash flows from a software project.
 Cost–benefit evaluation techniques

Technique Meaning Good When

CBA Compares total costs vs benefits Benefits > Costs

ROI Measures profitability ROI is high

Payback Period Time to recover investment Payback is short

Value considering future money

NPV NPV is positive
value
 Risk evaluation
• Is a critical component of software project management, focusing on identifying,
analyzing, and prioritizing potential risks to ensure that they are effectively managed or
mitigated.
• It helps organizations balance risk exposure against project goals, timelines, and
resources.
• Key Elements of Risk Evaluation are
• Risk Identification:
• Systematic discovery of risks that could impact the project's success.
• Sources include technical challenges, resource limitations, stakeholder expectations, and
external factors like regulatory changes.
• Risk Analysis:
• Qualitative Analysis: Categorizes risks based on severity and likelihood using descriptive
metrics (e.g., low, medium, high).
• Quantitative Analysis: Uses numerical data to measure risks, often employing statistical
methods or simulation techniques .
• Risk Assessment:
• Evaluates the potential impact of identified risks on project objectives, such as cost, scope,
schedule, and quality.
• Risk Prioritization:
• Ranks risks based on their likelihood and impact, enabling teams to focus on the most
critical threats.
THANK YOU