Unit 2 : Project Management in

Software Engineering
 Unit 2: Project Management in Software Engineering

2.1 Four P’s of Software Project Management :

• Project management involves in planning, monitoring and control of the people, process and the events that occur as software evolves from a preliminary concept to full operational deployment.

• Scope of management activities varies among people involved in a software project.

• Software development involves many people working over a relatively long time.

• That’s why software projects need to be managed.

• Understand the four P’s – People, Product, Process and Project.

2.1 Four P’s of Software Project Management :
1) People :

• The most important element of a successful project.

• Companies, that sensibly manage their investment in people will
prosper in the long run.
• Cultivation of motivated and highly skilled software people has
always been important for software organizations .
• Peoples involved in Software Process are :
a) Stakeholders
b) Team Leaders
c) Software Team
d) Agile Teams
e) Coordination and Communication
Issues
 1) People :
a) Stakeholder :

• The Software process is populated by stakeholders who can be further categorized into five forms.
1) Senior Managers : They define business issues that often have significant influence on the project.

2) Project (technical) managers : They must plan, motivate, organize and control the practitioners who do software work.

3) Practitioners : They deliver the technical skills necessary to engineer a product or application.

4) Customers : They specify the requirements for the software to be engineered.

5) End Users : They interact with the software after it is released for production use.
1) People :

b) Team Leader :

• Competent Practitioners often make poor team leaders as they lack

the right mix of skills.
• In his excellent book of technical leadership, Jerry Weinberg
suggests a MOI model of leadership.
1) Motivation : encourage technical people (by “push” or “pull” ) to
produce.
2) Organization : Apply, improve processes efficiently.
3) Ideas or Innovation : Make people feel creative, Be Creative.
1) People :

b) Team Leader :

• Another set of useful leadership traits :

Problem solving – diagnose, structure a solution, apply lessons
learned, remain flexible.
1) People :

b) Team Leader :

• Another set of useful leadership traits :

Managerial identity – take charge of the project, have
confidence to assume control, have assurance to allow good
people to do their jobs.
1) People :

b) Team Leader :

• Another set of useful leadership traits :

Achievement – reward initiative, demonstrate that controlled risk
taking will not be punished.
1) People :

b) Team Leader :

• Another set of useful leadership traits :

Influence and team building – be able to “read” people,
understand verbal and nonverbal signals, be able to react to
signals, remain under control in high-stress situations.
1) People :

c) Software Team :

• There are many human organizational structures for software

development.

• People directly involved in a new software project under a

supervision of team leader or project manager.

• Team structure depends upon the management style of your

organization, number of people and their skills level.
1) People :

c) Software Team :

• There are many human organizational structures for software

development.
• People directly involved in a new software project under a
supervision of team leader or project manager.
• Team structure depends upon the management style of your
organization, number of people and their skills level.
How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

1) People :
c) Software Team :

• Seven project factors to consider when structuring a software

development team.
o The difficulty of the problem to be solved
o The size of the resultant program(s) in source lines of code
o The time that the team will stay together
o The degree to which the problem can be modularized
o The required quality and reliability of the system to be built
o The rigidity of the delivery date
o The degree of sociability (communication) required for the
project
1) People :
c) Software Team :
• Four organizational paradigms for software development teams :
• closed paradigm - structures a team along a traditional hierarchy of
authority.

• random paradigm - structures a team loosely and depends on

individual initiative of the team members.

• open paradigm - attempts to structure a team in a manner that

achieves some of the controls associated with the closed paradigm but
also much of the innovation that occurs when using the random
paradigm.

• synchronous paradigm - relies on the natural process of a problem

and organizes team members to work on pieces of the problem with
little active communication among themselves.
1) People :
c) Software Team :

• Five factors that cause team toxity (i.e., a toxic team

environment)

o A frenzied work atmosphere.

o High frustration that causes friction among team member.s

o A fragmented or poorly coordinated software process.

o An unclear definition of roles on the software team.

o Continuous and repeated exposure to failure.

1) People :
c) Software Team :

• How to avoid toxic team environment

o Give the team access to all information required to do the
job.
o Do not modify major goals and objectives, once they are
defined, unless absolutely necessary.
o Give the team as much responsibility for decision making as
possible.
o Let the team recommend its own process mode.l
o Let the team establish its own mechanisms for accountability
(i.e., reviews).
o Establish team-based techniques for feedback and problem
solving.
1) People :
d) Agile Team :
• Agile software development encourages customer satisfaction and early
incremental delivery of software with overall simplicity.

• Agile teams are small, highly motivated teams.

• They adopt many characteristics of successful software project teams and
avoid toxins that create problems.

• They are self organizing and do not necessarily maintain a single team
structure

• Agile process models give significant autonomy to agile teams.

• Planning is kept to minimum.
• The agile team is allowed to select its own approach (e.g., process,
methods, tools).
1) People :
d) Agile Team :

• The agile team may have daily team meetings to coordinate and
synchronize the day’s work.

• With each passing day, this self organization and collaboration

move the team towards a completed software increment.
1) People :
e) Coordination and Communication Issues:

• Formal approaches
o Writings (SE documentation, Customer requests, etc.).

o Status review meetings.

o Design and code inspections.

1) People :
e) Coordination and Communication Issues:

• Informal approaches (more personal)

o Interpersonal networking.

o Sharing of ideas on ad hoc basis.

o Seeking help from inside or outside the project team when

problem arises.
1) People :
e) Coordination and Communication Issues:

• Electronic Communication
o E-mail, electronic bulletin boards, video conferencing.
Group Dynamics :

• Based on studies published by B. Tuckman in 1965

• Updated later in 1977.
• Describes a four-stage model.
a) Forming

b) Storming

c) Norming

d) Performing

21
Group Dynamics :

• Forming :
o Group members rely on safe, patterned behavior and look to
the group leader for guidance and direction.

o Impressions are gathered and similarities and differences are

noted.

o Serious topics and feelings are avoided.

o To grow, members must relinquish the comfort of non-

threatening topics and risk the possibility of conflict.

22
Group Dynamics :

• Storming :
o As group members organize for the tasks, conflict inevitably results in their
personal relations and cliques start to form.

o Individuals have to bend and mold their feelings to fit the group.

o Fear of exposure or fear of failure causes an increased desire for structural

clarification and commitment.

o Conflicts arise over leadership, structure, power, and authority.

o Member behavior may have wide swings based on emerging issues of

competition and hostilities.

o Some members remain silent while others attempt to dominate.

23
Group Dynamics :

• Norming :

◦ Members engage in active acknowledgement of all members’

contributions, community building, and solving of group issues.

◦ Members are willing to change their preconceived ideas or opinions

based on facts presented by the group.

◦ Leadership is shared, active listening occurs.

◦ Members began to identify with one another, which leads to a level

of trust in their personal relations and contributes to cohesion.

◦ Members begin to experience a sense of group belonging.

24
Group Dynamics :

• Performing :
◦ The capacity, range, and depth of personal relations in the
group expand to true interdependence.

◦ Members can work independently, in subgroups, or altogether

with equal ability and success.

◦ The group is most productive, members become self-assuring,

and the need for group approval is past.

◦ Genuine problem solving can occur leading towards optimal

solutions.

25
2.1 Four P’s of Software Project Management :
2) Product :

• The product and the problem it is intended to solve must be

examined at very beginning of the software project.

• The scope of product must be established and bounded.

Bounded scope means

o establishing quantitative data like no. of simultaneous users, max.

allowable response time. etc.

o Constraints and limitations

o and mitigating factors described

• The problem that the product is addressing must be

decomposed.
2) Product :

Product Scope :

• It’s why you’re in business.

• Determine what are you building (market/customer

research).

• How big a job (scope).

• What do you have to accomplish task (resources).

• How hard (effort + ability + resources = feasibility).

2) Product :
Software Scope :
• Scope is defined by :
a) Context
o Functional location of the software product into a large system,
product or business context
o Constraints involved
a) Information Objectives
o What data objects are required as i/p or o/p
a) Function and Performance
o What function does the software system perform on i/p to produce
o/p
o What level of performance is required
2) Product :
Problem Decomposition :

• Also called partitioning OR problem elaboration.

• This activity is at core of requirements analysis.
• Divide and conquer policy for complex problems.
• A complex problem is partitioned into smaller problems that are
more manageable.

• Decomposition make planning easier.

• Decomposition in 2 major areas :
o Functionality that must be delivered

o Process that will be used to deliver product

2.1 Four P’s of Software Project Management :
3) Process :

• A software process provides the framework from which a

comprehensive plan for software development can be established.

• Common process framework activities which are applicable to all

software projects are:

o Communication

o Planning

o Modelling

o Construction

o Deployment
3) Process :
Process Concept :

• The framework organizing tasks of your development

work.

• Provides structure and context for development effort.

• Gives guidance on best practices for s/w development.

• Identifies common concerns, e.g., organization, resources,

risks.
3) Process :
Process Models:
• These characterize a software process and are applicable to all
software projects .
• Different process models :
o The linear sequential model ( Waterfall model )
o The prototyping model
o The RAD model
o The incremental model
o The spiral model
o The component-based development model
o The concurrent development model
o The formal methods
o The fourth generation techniques model
3) Process :
Process Models:

• Project manager must decide about which model to use depending

on :

o Customers who have requested the product.

o People who would work on project.

o Product characteristics.

o Project environment.

• Project planning begins once model is selected.

3) Process :
Process Decomposition :

• The way a process is decomposed depends on project complexity.

• Decomposition involves outlining of work tasks involved in each
process framework activity.

• Example of decomposition for “communication‟ activity for a simple

project:

o Develop a list of clarification issues.

o Meet with customer to discuss clarification issues.

o Jointly develop statement of scope.

o Review the statement of scope with all concerned.

o Modify the statement of scope id required.

 2.1 Four P’s of Software Project Management :
3) Project :

• Organizes and integrates the other three elements.

• The software projects must be planned and controlled effectively to avoid complexities.

• The project managers and engineers must understand the critical success factors.

• Develop a common sense approach for planning, monitoring and controlling the project.
 2.1 Four P’s of Software Project Management :
3) Project :

• Contains the plan of action :

o Uses the process as a guideline.

o Considers the people and resources in estimating.

o Decomposes the product and develops the schedule, resource needs, cost, and risk.

o Provides the “concrete” information needed for tracking (or monitoring) and controlling the effort.
3) Project :
Project Signs:

• Must understand what can go wrong (so that problems can be

avoided).

• Ten signs that indicate that an information systems project is in

jeopardy:

1) Software people don’t understand their customer’s needs

2) The product scope is poorly defined

3) Changes are managed poorly

4) The chosen technology changes

3) Project :
Project Signs:

5) Business needs change (or ill-defined)

6) Deadlines are unrealistic

7) Users are resistant

8) Sponsorship is lost (or was never properly obtained)

9) The project team lacks people with appropriate skills

10) Managers (and practitioners) avoid best practices and lessons

learned
3) Project :
Common Sense Approach :

Five-part commonsense approach to software project:

1. Start on the right foot: working hard to understand the problem

that is to be solved and then setting realistic objectives and
expectations.

2. Maintain momentum: provide incentives, the team should

emphasize quality in every task it performs, and senior
management should do everything possible to stay out of the
team’s way.
3) Project :
Common Sense Approach :

Five-part commonsense approach to software project:

3. Track progress: track work products (e.g., models, source code,

sets of test cases), which are produced and approved (using formal
technical reviews).

4. Make smart decisions: decisions should be “keep it simple”.

5. Conduct a postmortem analysis: Establish a consistent

mechanism for extracting lessons learned and evaluation of
project.
3) Project :
W5HH Principle :

• Suggested by Barry Boehm in one of his papers.

• Excellent planning outline for project managers and software team.

• Applicable to all sizes of software projects.

• It is an approach to address :
o Project objectives

o Milestones & schedule

o Responsibilities

o Management & technical approaches

o
3) Project :
W5HH Principle :

• A series of questions that lead to a definition of key project

characteristics and the resultant project plan.
Why is the system being developed?

Assesses the validity of business reasons and justifications

What will be done?

Establishes the task set required for the project

When will it be done?

Establishes a project schedule

Who is responsible for a function?

Defines the role and responsibility of each team member

3) Project :
W5HH Principle :

Where are they organizationally located?

Notes the organizational location of team members, customers,

and other stakeholders

How will the job be done technically and managerially?

Establishes the management and technical strategy for the

project

How much of each resource is needed?

Establishes estimates based on the answers to the previous

questions
END