Project Management

Instructor: Dr. Jerry Gao

 Project Management

- The Management Spectrum

- People
- The Players
- Team Leaders
- The Software Team
- Coordination and Communication Issues

- The Problem
- Software Scope
- Problem Decomposition

- The Process
- Melding the Problem and the Process
- Process Decomposition

- The Project (the 90-90 rule)

Jerry Gao, Ph.D. Jan. 1999

 The Management Spectrum - People
- Three P’s:
Effective software project management focuses on the three P’s:
(1) people, (2) problem, and (3) process

- People:

Software engineering work is an intensely human endeavor.

A people management capability maturity model (PM-CMM)
--> key practice areas for software people:
- recruiting, selection, performance, management,
training, compensation, career development,
organization and work design, and team/culture development

The most important contributor to a successful software project

--> having smart people with good skills

Organizations with high levels of maturity in the people management

---> implementing effective software engineering practice
 The Management Spectrum - The Problem
- Three P’s:
Effective software project management focuses on the three P’s:
(1) people, (2) problem, and (3) process

- Problem (related to a project):

Before starting a project, we need to define and identify its

- Objectives and scope
- Alternative solutions
- Technical and management constraints

Considering other factors:

delivery deadlines, budgetary restrictions, personnel availability
technical interfaces, and so on.

Without these information, it is impossible

- To define reasonable estimates of the cost
- To conduct an effective assessment of risk
- To do realistic breakdown of project tasks
- To come out a manageable project schedule
 The Management Spectrum - The Process

- Three P’s:
Effective software project management focuses on the three P’s:
(1) people, (2) problem, and (3) process

- Process:

A software process provides the framework -->

a comprehensive plan for software development

A number of different tasks sets applicable to all software projects:

- tasks, milestones, deliverables, and quality assurance points

Umbrella activities -> occurs throughout the process:

- software quality assurance
- software configuration management
- measurement
 People - The Players

- In a software process, there are five types of players:

- Senior managers, who defines the business issues.

(strong influence on the project)

- Practitioners, who deliver the technical skills for engineering software

- Project (technical) managers, who must plan. Motivate, organize

and control the practitioners.

- Customers, who specify the requirements for the software.

- End users, who interact with the software once it is released for use.
 People - Team Leaders
- Project management is a people-intensive activity.

How to select a good team manager?

MOI model of leadership suggested by Jerry Weinberg [WEi86]:

- Motivation - the ability to encourage technical people.

- Organization - the ability to mold existing processes that will enable
initial concept to be translated into a final product.
- Ideas or innovation - the ability to encourage people to create and feel creative.

Software managers should concentrate on

- understanding the problem to be solved,
- managing the flow of ideas,
- letting everyone on the team know that quality counts.

Four important key traits to be an effective project manager:

- Problem solving
- Managerial identity
- Achievement
- Influence and team building
 People - The Software Team

Mantei [MAN81] suggests three generic team organizations:

- Democratic decentralized (DD):

- the software engineering team has no permanent leader.
- decision is made by group consensus.
- communication among team members is horizontal.

- Controlled decentralized (CD):

- has a leader -> coordinates specific tasks and secondary leaders.
- secondary leaders have responsibility for subtasks.
- horizontal communications among subgroups and individuals.
- vertical communication in the control structure
- decision is made by leaders.

- Controlled centralized (CC):

- team leader manages top-level problem solving and internal team
coordination.
- communication between the leader and team members is vertical.
 People - The Software Team

DD: group

CC: Team leader DC: Team leader

secondary team leader

communication

group

group
 People - The Software Team
Functional tasks

FT1 FTm

P1 X X

X X
X
Pn X
Project manager + n engineers + m tasks
team
engineer

FT1 FTm T1 Tm
P1 X P1 X

X X

Pn X X Pn X X

Project manager + team leaders

Project manager+ informal teams with coordinator
 People - The Software Team

Mantie’s seven project factors related to project team structure:

- the difficulty of the problem to be solved.

- the size of the resultant programs
- the modularity of problem
- the reliability of the software
- the team life time
- the rigidity of the delivery date
- the degree of sociability (communication overhead)

Team Type DD CD CC

Difficulty High Low Low

Size Small Large Large
Team Life Time Long Short Short
Modularity Low High High
Reliability High High Low
Delivery date Lax Lax Strict
Sociability High Low Low
 People - The Software Team

Constantine [CON’93] suggests four “organization paradigms”

for software engineering teams:

- A closed paradigm:
a team with a traditional hierarchy of authority (like CC)
- The random paradigm:
a team loosely and depends on individual initiative of the team members
- The open paradigm:
heavy communication + control structure like CC
- The synchronous paradigm:
relies on the nature compartmentalization of a problem + little active
communications

Chief programmer team (by Harlan Mills described in Baker’s [BAK72]) :

a senior engineer (1), technical staff (2-5), a backup engineer,
support staff (e.g. technical writers), software librarian (1).

Book “Peopleware” by DeMarco and Lister discussed “jelled team”:

A jelled team is a group of people so strongly knit that the whole is
greater than the sum of the parts… They don’t need managed in a
traditional way, they don’t need to be motivated. They got momentum.
 People - Coordination and Communication Issues
Many failure causes of a software project. Here are some of them related
to communications and coordination of a project:

- The large scale of development efforts

--> complexity, confusion, and significant difficulties in coordination of teams.
- Uncertainty is common due to the changes of requirements and team status
- Interoperability --> interoperations among systems

Good and effective formal and informal communication mechanisms:

- Formal impersonal approaches

documents, deliverables, memos, project milestones,
schedules, project control tools, change requests, and
related documents, error tracking reports and data.

- Formal, interpersonal procedures

quality assurance activities (code & design inspection, review meeting)
- Informal, interpersonal procedures
informal group meeting (such as meeting with customers and users)
- Electronic communication (email, web sites, video-based conference)
- Interpersonal network
 Problem - Software Scope

A software project manager is confronted with a dilemma at the beginning

of a software engineering project.

- Software scope:

(a) Context:
- How does the software to be built fit into a large system, product, or business?
- What constraints are imposed as a result of the context?

(b) Information objectives:

- What customer-visible data objects are produced as output from the software?
- What data objects are required for input?

( c) Function and performance:

- What function does the software perform to transform input data into output?
- Are any special performance characteristics to be addressed?
 Problem Decomposition

Problem decomposition --> problem partitioning.

Problem decomposition --> two areas:

- the functionality of the delivery software system
- the process that will be used to deliver the system

- Functional decomposition:
- Identify and define the functional scope of the system
in terms of functional features and/or sub-functional systems.
- Apply decomposition method on each feature.

An example of the function features for a word processing system:

- spell checking
- sentence grammar checking
- reference checking for large documents
- section and chapter reference validation for large documents.
 Process - Melding the Problem and the Process

Each function to be engineered by the software team must pass through the set
of framework activities:

- customer communication
- tasks to establish effective communications with customers.
- planning - tasks to define resources, timelines, an so on.
- risk analysis - tasks to assess both technical and management risks.
- engineering - tasks to build the application system
- construction and release - installation, release control, and customer support.
- customer evaluation - task to obtain customer feedback and evaluation result.

Process decomposition:
- Select a software process model for the project.
- Define a preliminary project plan based on the set of common
process framework activities.
- Partition the software process based on the tasks and activities

common process framework (CPF)

 Process - Process Decomposition

Each function to be engineered by the software team must pass through the set
of framework activities:

- customer communication
- tasks to establish effective communications with customers.
- planning - tasks to define resources, timelines, an so on.
- risk analysis - tasks to assess both technical and management risks.
- engineering - tasks to build the application system
- construction and release - installation, release control, and customer support.
- customer evaluation - task to obtain customer feedback and evaluation result.

Process decomposition:
- Select a software process model for the project.
- Define a preliminary project plan based on the set of common
process framework activities.
- Partition the software process based on the tasks and activities

common process framework (CPF)

 Process - Process Decomposition

A small project may require the following work tasks:

- Develop list of clarification issues.
- Meet with customer to address clarification issues.
- Jointly develop a statement of scope.
- Review the state of scope with all concerned.
- Modify the statement of scope as required.

A complex project may require the following work tasks:

- Review the customer request.
- Plan and schedule a formal, facilitated meeting with the customer.
- Conduct research to define proposed solutions and existing approaches.
- Prepare a “working document” and an agenda for the formal meeting.
- Conduct the meeting.
- Jointly develop mini-spec for correctness, consistency, and lack of ambiguity.
- Assemble the min-specs into a scoping document.
- Review the scoping document with all concerned.
- Modify the scoping document as required.