SOFTWARE

PROJECT
MANAGEMENT
OBJECTIVES

The The The

People Product Process

The The W5HH

Project Principle

SOFTWARE PROJECT MANAGEMENT 2

THE MANAGEMENT SPECTRUM

SOFTWARE PROJECT MANAGEMENT 3

THE 4 P’s
• The People
• The Product
• The Process
• The Project

SOFTWARE PROJECT MANAGEMENT 4

THE PEOPLE

SOFTWARE PROJECT MANAGEMENT 5

THE STAKEHOLDERS
• Senior managers – define business issues that have
significant influence on the project
• Project (technical) managers – plan, motivate, organize,
and control the practitioners
• Practitioners – deliver technical skills to engineer product
• Customers/Stakeholders – specify requirements for the
software/have a peripheral interest in the outcome
• End-users – interact with the software once it is released

SOFTWARE PROJECT MANAGEMENT 6

TEAM LEADER/PROJECT MANAGER
“Competent practitioners often make poor team leaders”

• MOI model of leadership

1. Motivation – ability to encourage technical people to
produce to their best ability
2. Organization – ability to mould initial concept into a
final product
3. Ideas/Innovation – ability to encourage people to
create and feel creative while working

SOFTWARE PROJECT MANAGEMENT 7

TEAM LEADER/PROJECT MANAGER
• Problem solving – diagnose technical/organizational
issues, structure a solution or motivate others to develop
the solution, apply lessons learned from past projects,
and remain flexible to change direction if initial attempts
fail
• Managerial identity – take charge of the project and
allow good technical people to follow their instincts
• Achievement – reward team for controlled risk taking to
optimize the productivity
• Influence and team building – understand and react to
the needs of the people, remain under control in high-
stress situations

SOFTWARE PROJECT MANAGEMENT 8

THE SOFTWARE TEAM
Mantei – 7 project factors to be considered when planning
the structure of software engineering teams:
1. Difficulty of the problem to be solved
2. “Size” of the resultant program(s) in lines of code or
function points
3. Time that the team will stay together (team lifetime)
4. Degree to which the problem can be modularized
5. Required quality and reliability of the system to be built
6. Rigidity of the delivery date
7. Degree of sociability (communication) required for the
project

SOFTWARE PROJECT MANAGEMENT 9

THE SOFTWARE TEAM
Team structures by Constantine - organizational paradigms
• Closed paradigm – traditional hierarchy, work well
when producing software similar to past efforts, less
innovative
• Random paradigm – loosely bonded team, more
innovative, lack orderly performance
• Open paradigm – control from closed paradigm and
innovation from random paradigm, work is performed
collaboratively with heavy communication and
consensus-based decision making, well suited to the
solution of complex problems, lack efficiency
• Synchronous paradigm – relies on the natural
compartmentalization of a problem and organizes
team members to work on pieces of the problem with
little active communication among themselves

SOFTWARE PROJECT MANAGEMENT 10

THE SOFTWARE TEAM
Chief programmer team by Harlan Mills
Earliest team organization with a closed paradigm structure
1. Chief programmer (senior engineer): plans, coordinates
and reviews all technical activities
2. Technical staff (2-5 people): conduct analysis and
development activities
3. Backup engineer: supports the senior engineer and can
even replace him if needed
4. Software librarian: acts as a controller, coordinator, and
potentially, an evaluator of the software configuration
5. Specialists (telecommunications expert, database
designer)
6. Support staff (technical writers, clerical personnel)

SOFTWARE PROJECT MANAGEMENT 11

THE SOFTWARE TEAM
For high performance
1. Team members must trust one another
2. The distribution of skills must be appropriate to the
problem.
3. Rebels to be excluded from the team

SOFTWARE PROJECT MANAGEMENT 12

 THE SOFTWARE TEAM • Access to all
necessary
information
Toxic Influencers Effects •• Objectives,
Caused usually once
defined,
due to lack should
of
Chaotic work waste energy, lose not be modified
authority to
atmosphere focus • unless
Allow necessary
controlthea team
• Bad
to newsthe
select
situation to be
High frustration by shared
Give asASAP
• process much
friction among team
personal, business, or • Be certain that
technological factors
members • responsibility
Establish a for
characteristics
decision making of
mechanism for
the
as software
possible
Improperly chosen accountability
Establish to the
• conform
roadblock for work
process model • Define
techniquesa series of
precision of for
the
corrective
feedback and
process
lack of approaches
problem solving if
Unclear definition of roles
accountability • someone
Rather than fails to
perform
finger-pointing,
Continuous/repeated an individual
loss of confidence
failure failure must be
viewed as team
SOFTWARE
failure
PROJECT MANAGEMENT 13
AGILE TEAMS
• Encourages
• customer satisfaction
• early incremental delivery of software
• small highly motivated project teams
• Stresses individual competency coupled with group
collaboration
• Self-organization - no single team structure, but a mixture
of Constantine’s random, open, and synchronous
paradigms

SOFTWARE PROJECT MANAGEMENT 14

AGILE TEAMS
• Give the team independence to make technical
decisions
• Planning is kept to a minimum and the team is allowed
to select its own approach (e.g., process, methods,
tools), constrained only by business requirements and
organizational standards
• Conduct daily team meetings to coordinate and
synchronize the work

SOFTWARE PROJECT MANAGEMENT 15

THE PRODUCT

SOFTWARE PROJECT MANAGEMENT 16

SOFTWARE SCOPE
1. Context: How does the software to be built fit into a
larger system, product, or business context and what
constraints are imposed as a result of the context?
2. Information objectives: What customer-visible data
objects are produced as output from the software?
What data objects are required for input?
3. Function and performance: What function does the
software perform to transform input data into output?

SOFTWARE PROJECT MANAGEMENT 17

PROBLEM DECOMPOSITION
• Partitioning or problem elaboration is the core of
software requirements analysis
• Decomposition is applied on the functionality that must
be delivered
• Divide and conquer strategy
• Define software functions and then decompose the
ones that are complex

SOFTWARE PROJECT MANAGEMENT 18

THE PROCESS

SOFTWARE PROJECT MANAGEMENT 19

Models are decided on the basis of:
1. Customers who have requested the product
2. People who will do the work
3. Characteristics of the product

After finalizing the model, project plan is formulated by

decomposing the problem into work tasks

SOFTWARE PROJECT MANAGEMENT 20

THE PROJECT

SOFTWARE PROJECT MANAGEMENT 21

WHAT CAN GO WRONG?
1. Software people don’t understand their customer’s
needs
2. Scope is poorly defined
3. Changes are managed poorly
4. The chosen technology changes
5. Business needs change [or are ill-defined]
6. Deadlines are unrealistic
7. Sponsorship is lost
8. The project team lacks people with appropriate skills
9. Managers [and practitioners] avoid best practices and
lessons learned

SOFTWARE PROJECT MANAGEMENT 22

1. Start on the right foot: work hard to understand the
problem, set realistic objectives, build the right team
and give them independence, authority and
technology needed
2. Maintain momentum: provide incentives ,emphasize
quality in every task
3. Track progress: after production and approval of each
work product
4. Make smart decisions: reuse components, prefer
standard over custom-built, identify and avoid obvious
risks, give more time to complex tasks
5. Conduct a post-mortem analysis: evaluate the planned
and actual schedules, get feedback, record lessons
learnt

SOFTWARE PROJECT MANAGEMENT 23

THE W5HH PRINCIPLE

SOFTWARE PROJECT MANAGEMENT 24

Why is the system being developed? assess the validity of
business reasons for the software work, does the business
purpose justify the expenditure of people, time, and
money?
What will be done, by when? establish a project schedule by
identifying key project tasks and the milestones required by
the customer.
Who is responsible for a function? role and responsibility of
each member of team to be defined
Where are they organizationally located? roles and
responsibilities of customer, users, and other stakeholders
(not part of the software team)
How will the job be done technically and managerially?
management and technical strategy for the project after
scope
How much of each resource is needed? developing estimates
based on answers to earlier questions

SOFTWARE PROJECT MANAGEMENT 25

 HOME TASK
Read and understand the following paper by the next
class:
“On Becoming A Leader”, By Warren Bennis
http://www.cognitionnet.com/member/resources/Summari
es/Leadership/On_Becoming_a_Leader.pdf

SOFTWARE PROJECT MANAGEMENT 26

 ACTIVITY
You are the project manager of an organization. Which
team structure will you choose in the following scenarios
and why?
1. Your job is to build an application that is quite similar to
others your team has built, but is larger and more
complex. Requirements have been thoroughly
documented by the customer
2. Your job is to build a breakthrough product that
combines virtual reality hardware with state-of-the-art
software. Because competition for the home
entertainment market is intense, there is significant
pressure to get the job done.

SOFTWARE PROJECT MANAGEMENT 27