CH - 09
Project
Management
1
Topics
◦ Software project management
◦ Risk management
◦ Managing people
◦ Teamwork management
2
Software project
management
Interested in the steps required to ensure that software is delivered
on schedule, according to plan, and in accordance with the
requirements of the businesses generating and purchasing the
software.
Because software development is always subject to time and
financial restraints imposed by the company creating the system,
project management is necessary.
3
Success criteria in project
management
◦ Provide the customer with the program at the scheduled time.
◦ Maintain total costs within the budget.
◦ Provide customers with software that lives up to their
expectations.
◦ Retain a cohesive and effective development team.
4
Software management
distinctions
◦ The software is intangible. Software is invisible and touchless.
Managers of software projects cannot gauge progress by merely looking
at the artefact that is being built.
◦ Most software projects are 'one-off' projects. Most of software
projects typically differ from earlier initiatives in some respects. Even
very experienced managers could find it challenging to foresee issues.
◦ Software processes vary and are unique to each environment. We are
still unable to accurately forecast when a specific software procedure
would most likely cause issues during development.
5
Factors influencing project
management
◦ Software size
◦ Software development processes
◦ Software customers
◦ Company size
◦ Software type
◦ Organizational culture
Due to these characteristics, project managers in various system
developments may operate in quite diverse ways.
6
Universal management
activities
◦ Project planning: Planning is the responsibility of project
managers. Scheduling and estimating project development, as well
as task assignment.
◦ Risk management: A project's potential risks are assessed by
project managers, who also monitor them and act when problems
arise.
◦ People management: To ensure effective team performance,
project managers must choose team members and establish
working procedures.
7
Management activities
◦ Reporting: Project managers are typically responsible for providing
regular updates on a project's status to clients and the managers of
the software development company.
◦ Proposal writing: A proposal may need to be written as the initial
step in a software project in order to secure a contract to complete
a task. The project's goals and the plan for execution are laid out in
the proposal.
8
Risk management
Identifying risks and coming up with solutions to lessen their
influence on a project are the objectives of risk management.
Software risk management is essential due to the inherent threats in
software development. Uncertainties are brought on by unclear
requirements, changes to requirements brought on by evolving client
expectations, difficulties estimating the time and resources required
for software development, and individual skill gaps. In order to limit
or eliminate risks, you must be ready for them, understand how they
may impact your project, your product, and your business, and take
appropriate steps.
9
Risk classification
◦ The classification of risk has two aspects.
◦ The kind of risk (technical, organizational, etc.)
◦ What is impacted by the risk?
◦ Product risks affect the program's usability or quality as it is being
developed.
◦ Resources or schedule are impacted by project risks.
◦ Business risks affect the organization that develops or purchases
the software.
10
Examples of product, project, and business risks
Risk Affects Description
Size underestimate Project and product The system's size has been overestimated.
Technology change Business The core technology upon which the system is built has
been replaced by new technology.
Staff turnover Project Before the project is completed, skilled personnel will
depart.
Requirements change Project and product The amount of requirements modifications will increase
more than expected.
Lack of hardware Project Hardware that is essential to the project won't arrive on
time.
Specification delays Project and product Critical interface requirements are not yet available
when needed.
CASE tool underperformance Product The project's supporting CASE tools don't function as
expected.
Management change Project With new priorities, the organizational management will
change.
Product competition Business A competing product is promoted before the system is
finished.
11
The risk management
process
◦ Risk identification: List potential risks to a project, a product, or a business.
◦ Risk analysis: Evaluate the probability and effects of various risks.
◦ Risk planning: Create strategies to reduce or eliminate the risk's impacts.
◦ Risk monitoring: Keep an eye on the hazards as the project progresses.
12
Risk identification
Based on the project manager's experience or possibly team actions.
Risks in a project can be found using a checklist of common risks:-
◦ Requirements risks
◦ People risks
◦ Technology risks
◦ Estimation risks
◦ Organizational risks
13
Examples of different risk types
Risk type Possible risks
Technology The system's database is unable to handle the anticipated number of transactions per second. (1)
Reusable software components have flaws that prevent them from being used as intended. (2)
People Staff with the necessary skills cannot be hired. (3)
Critical personnel are sick and unavailable at crucial periods. (4)
The necessary staff training is not offered. (5)
Organizational The organization has been reorganized so that various management is in charge of the project.
(6)
Organizational financial issues necessitate budget cuts for the project. (7)
Tools Software code creation tools provide ineffective code. (8)
Software tools cannot be merged to operate as a single unit. (9)
Requirements Requirements adjustments that necessitate significant design revision are suggested. (10)
Customers lack the understanding of how shifting needs might affect them. (11)
Estimation The program's development takes longer than predicted. (12)
Underestimation of the rate of fault correction. (13)
The software's size is overestimated. (14)
14
Risk analysis
◦ Determine the likelihood and importance of each risk.
◦ The probability could be very low, low, moderate, high, or very
high.
◦ The effects of a risk could be disastrous, severe, bearable, or
inconsequential.
15
Risk types and examples
Risk Probability Effects
The system's database cannot handle as many transactions per second as anticipated (1). Moderate Serious
Reusable software components must first have any flaws fixed before being used again. (2). Moderate Serious
Staff with the necessary abilities for the project cannot be hired (3). High Catastrophic
During crucial phases of the project, key personnel are ill (4). Moderate Serious
Staff training that is necessary is not offered (5). Moderate Tolerable
The organization has been reorganized so that several management are in charge of the High Serious
project (6).
Reductions in the project budget are required by organizational financial issues (7). Low Catastrophic
Code produced by tools for code generation is ineffective (8). Moderate Insignificant
There is no way for integrating software tools (9). High Tolerable
Requirements changes that necessitate significant design revision are suggested (10). Moderate Serious
The effects of changing requirements are not understood by customers (11). Moderate Tolerable
It takes longer than expected to develop the software (12). High Serious
Defect repair rates are overestimated (13). Moderate Tolerable
Underestimating the software's size (14). High Tolerable
16
Risk planning
Each risk should be taken into account as you create a risk
management plan.
◦ Prevention strategies: The chance that the risk could happen is decreased.
◦ Minimization strategies: The project or product will experience less of the
risk's negative effects.
◦ Recovery plans: Plans for dealing with the danger should it arise are known as
recovery plans.
17
What-if questions
◦ What happens if the firm that provides and maintains software
components fails?
◦ What if the project's budget is reduced by 20% due to a recession?
◦ What happens if multiple engineers fall unwell at the same time?
◦ What if the single expert on the open-source software is no longer
there and the performance of the software is subpar?
◦ What happens if the customer doesn't deliver the updated needs on
time?
18
Techniques for reducing risk
Risk Technique
Staff illness Rearrange the team so that tasks overlap more and employees are more
aware of one another's responsibilities.
Organizational Create a briefing report for top management that demonstrates how the
restructuring project is significantly advancing the company's objectives.
Organizational financial Describe the project's major contribution to the company's goals and the
problems reasons why budget cuts for the project would not be cost-effective in a
briefing report for top management.
Requirements changes Maximize information hiding in the design and derive traceability information
to evaluate the impact of requirements changes.
Underestimated Look into purchasing components and using a program generator.
development time
Defective components Replace possibly damaged components with new ones that have been
purchased and are known to be reliable.
Recruitment problems Inform the customer of probable issues and potential delays; look into
purchasing components.
Database performance Look at the option of purchasing a more performant database.
19
Risk monitoring
◦ Regularly assess each risk indicated to determine whether it is
growing more or less likely.
◦ Examine whether the risk's impacts have altered as well.
◦ Meetings to review the status of management should cover each
significant risk.
20
Risk indicators
Risk type Relevant indicators
Requirements Numerous requests to modify criteria and customer concerns.
Organizational Disinformation within the company; inaction on the part of upper
management.
Technology Several complaints about technical issues; late hardware or support
software deliveries.
Estimation Failure to correct stated problems; failure to stick to the agreed-upon
schedule.
Tools Team members' reluctance to use tools, complaints regarding CASE tools,
and requests for workstations with more power.
People High worker turnover, poor team dynamics, and low employee morale.
21
Managing people
The most valuable resource in any organization is its people. Most of
a manager's responsibilities are people-related. If management does
not have some understanding of people, it will fail. Poor people
management is mostly to blame for project failure.
22
Factors affecting people
management
◦ Honesty: You should always be honest about both the good and the
poor aspects of a project.
◦ Consistency: Team members must be treated equally, without
favouritism or prejudice.
◦ Inclusion: Include every team member and make sure that everyone's
opinions are taken into account.
◦ Respect: Team members differ in their skill sets, and it is important to
acknowledge and value these distinctions.
23
Encouraging and motivating
people
Motivating the team members on a project is a crucial responsibility of a
manager. Motivation is the process of setting up the workload and the
workplace in a way that promotes productive work. People won't be interested
in their work if they are not inspired to do it. They won't support the team's or
organizations larger objectives and will work slowly and more carelessly.
Although motivation is a complicated problem, it appears that there are various
motivational styles based on:-
◦ Personal needs (e.g. self-esteem , respect)
◦ Basic needs (e.g. sleep, food, etc.)
◦ Social needs (e.g. to be welcomed as a member of a group)
24
Need satisfaction
Fundamental physiological and safety requirements are not a
concern in software development teams.
◦ Self-realization: Responsibility; education; people want to learn more.
◦ Esteem: Appreciation for accomplishments; just rewards.
◦ Social: Make available facilities for group interaction and permit informal
communication, such as through social networking.
25
Personality types
It is almost probable that the requirements hierarchy oversimplifies
motivation in real-world situations. Additionally, motivation should
consider the various personality types:-
◦ Interaction-oriented people, who are inspired by their co-workers’ presence
and behaviour. The presence and behaviour of co-workers serve as the
primary motivation. People choose to work because they enjoy it.
◦ Task-oriented people, people are inspired by their work. The work itself
serves as the incentive in software engineering.
◦ Self-oriented people, they are driven only by their own achievement and
recognition. The employment serves as a vehicle for achieving personal
objectives, such as becoming wealthy, learning to play tennis, traveling, etc.
26
Motivational balance
◦ Each class's components are present in each person's motivations.
◦ Depending on internal and external factors, the balance may
change.
◦ People are nevertheless motivated by social and cultural influences
in addition to personal ones.
◦ People go to work because the people they work with inspire
them.
27
Teamwork management
Most software engineering is carried out in teams. Most non-trivial software
projects cannot be completed by a single individual working alone because of
their development timeframes.
A strong team is cohesive and has a sense of unity. The success of the group and
the individuals' own goals are what motivate them. Group performance is
significantly influenced by group interaction.
There is little room for compositional flexibility. Managers must make the most
use of the personnel at their disposal.
28
Teamwork management
◦ Group cohesiveness
Members of a cohesive group value the group as a whole more than they do
any individual member. The benefits of a cohesive group are as follows:-
Group members may create collective quality criteria.
Knowledge-based inhibitions are reduced as a result of team members
learning from one another and becoming familiar with one another's work.
Information is shared. If one of the group members leaves, continuity can still
be kept.
Refactoring and on-going development are welcomed. Regardless matter who
originated the concept or software, members of the group work together to
create excellent results and find solutions to problems.
29
Teamwork management
◦ The effectiveness of a team
◦ The team members: You need a variety of team members because software development
requires a variety of tasks, including customer negotiations, programming, testing, and
documentation.
◦ The structure of the group: A group should be structured to allow for each member to
participate to the best of their skills and the efficient completion of duties.
◦ Technical and management communications: It's critical for the software engineering team
to effectively communicate with all project stakeholders.
30
Teamwork management
◦ Choosing group participants
A manager's or team leader's responsibility is to organize their team and
foster cohesiveness so that they can operate well together. This involves
putting together a team with the proper balance of personalities and
technical know-how and managing that team to ensure that its members
successfully collaborate.
31
Teamwork management
◦ Forming a team
It might not be feasible to select the best candidates to work on a project.
The project budget might not permit the use of highly compensated
personnel; personnel with the necessary expertise might not be available; an
organization might want to help employees advance their abilities on a
software project.
When there is a lack of qualified people, managers must especially work
within these limitations.
32
Teamwork management
◦ Makeup of the group
A group with members who have similar motivations can have problems.
Everyone wants to do their own thing when it comes to tasks, everyone wants
to be in charge, and everyone is too focused on interactions and not enough
on getting things done.
A group that works well has a good mix of each type. Being task-oriented,
software developers might make it challenging to accomplish this. People who
value interaction are crucial because they can spot emerging tensions and
diffuse them.
33
Teamwork management
◦ Group organization
The decisions a group makes, how information is shared, and how the development team interacts with
outside project stakeholders are all influenced by the way the group is structured.
Relevant questions include:
◦ Who will participate in important technical decision-making, and how will these decisions be made?
◦ Should the project manager be the team's technical leader?
◦ How can groups include members who don't share a space?
◦ How will relationships with top firm management and external stakeholders be handled?
◦ How could information be distributed across the group?
Most often, informality operates in small software engineering teams, non-hierarchical organizations.
Major projects could have a hierarchical structure where different groups are in charge of several sub-
projects.
Since formal structure prevents knowledge flow, agile development is always centered on an informal
group.
34
Teamwork management
◦ Informal groups
When making decisions that will have an impact on the system, the group
operates as a whole. While acting as the group's external interface, the group
leader does not assign particular tasks.
Instead, the group as a whole discusses the work and assigns duties based on
knowledge and experience. In teams with all competent and experienced
members, this strategy works well.
35
Teamwork management
◦ Group communications
Effective group work requires effective communication. The project's development, design
decisions, and changes to earlier choices must all be acknowledged. Effective communication
not only promotes comprehension but also strengthens group ties.
The setting of the workplace: Communications can be aided by effective workplace
organization.
Group size: People find it more difficult to converse with one another in huge groups.
Group composition: Different personality types and mixed-sex groups do better in terms of
communication than single-sex ones.
Group structure: Informally structured groups communicate better than hierarchically
structured ones.
36
Summary
◦ Effective project management is essential if software engineering projects are
to be completed on time and on budget.
◦ Engineering management is different from software management. Intangibles
include software. The administration of projects that lack a body of
experience may be unique or inventive. The maturity of software processes is
lower than that of conventional engineering procedures.
◦ Risk management entails identifying and evaluating project risks to determine
their likelihood of happening and the effects on the project should they. You
must prepare for potential risks so that you can avoid, control, or handle them
if and when they occur.
◦ Choosing the best team members and setting up the team's workspace are
both parts of people management.
37
Summary
◦ Interaction with others, receiving praise from management and peers, and
having opportunities for personal growth are all motivating factors for people.
◦ Software development teams should be cohesive and comparatively small.
The individuals that make up a group, the way that group is structured, and
the level of communication among group members are the main
determinants of that group's efficacy.
◦ There are several factors that influence communication inside a group,
including the status of group members, the size of the group, and the gender
mix of the group, personalities, and available communication technologies.
38
## Exercise Questions
How Often Should We Check Project Risks?
How can you identify risks?
What makes up the software project management team?
39
