Organizing a Software Project José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004

Organizing a Software Project

José Onofre Montesa AndrésUniversidad Politécnica de

ValenciaEscuela Superior de Informática

Aplicada2003-2004

GpiI-3A Organizing a Software Project 2

Table of contents

• Introduction• Team Structures• Communication in the software

project


Introduction• Ones the project is approves, the

management of it concentrate on two themes:– Creating a working team.– Tracking what was planed.

• In this chapter we’ll focus on: How to organize a working team?”


A global vision of the development.

Clients and

UsersDevelopers

softwarePeople, teams, Organizations

Ideas …specification… Design… Code


Context of the enterprise structure and the project team

• There are two kinds or people in the team:– The ones coming from the client

enterprise.– The technicians whose job is building the

software.


Context of the enterprise structure and the project team

• The team can use an organization structure different from the user’s enterprise one.

• Both organizations have to be connected in order to avoid conflicts between them.


Why do we need to create a project organization?

• The activities have been split up when planning so that the achievement and control of each task would be easer.

• Now we have to create de conditions for:• coordinating easily: starting of tasks; taking

decisions; tracking; and ending of tasks. • Providing communications between people in

charge of each task and people in the same or other tasks.


Different situations about the project team and client

• The project team belong to the user’s enterprise division.

• The project team belong to the user’s enterprise, but to other division (big organizations).

• The project team is extern to the user’s enterprise.


Different situations

• The project team belong to the user’s enterprise division.

• The project team belong to the user’s enterprise, but to other division

• The project team is extern to the user’s enterprise


The project team belong to the user’s enterprise

division.• We’ll have few liberty in order to set

the team (The available people).• If the division’s management

support the project:– All the concerned people about the

project arrive easily to commitments. – The team goal and the client enterprise

is exactly the same.


The project team belong to the user’s enterprise, but to other

division.• As the project team is a part of the

DPC it can include specialist, due to the size of the DPC and it’s specialization.

• It’s possible that the goals don’t be the same.


The project team is extern to the user’s enterprise.

• The project team is build with external people.– There is freedom to select the people in

the team.– It depends on the supplier enterprise

size.

• Goals are shared in a Client-Supplier fashion.


Organization structure• Client and future user, as enterprises have

their own organization. And we will have problems with them. It's interesting for us identify the organization structure and understand their authority and knowledge distribution.

• Typical structures are:– Functional organization– Project organization– Matrix organization


Organization assigns:

• Tasks and activities to people groups.• Objectives to each group.• Responsibilities to groups and

coordinators• Authorities between groups and their

member's.• Formal communication channels.


Functional organization (I)

• Is the more known structure (military, church,...)

• Is the typical pyramidal structure. Each new level introduces a type of specialization. It can be:– type of work (functional), – geographic localization (Territorial), – Size of clients (Clients oriented), – product (Product oriented).


Functional organization (II)

• Communication is allowed between:– People at under the same boss (same

level).– Boss and subordinate.

• Formal communication between two people in different areas must follow a long trip.– Worker to boss,… boss to boss until a

pint in the pyramid were starts to down until boss to worker.


Functional organization (III) Example:

Dirección general

Secretaría General

DirecciónCompras

DirecciónVentas

Almacén

Alicante Castellon Valencia

A-1

A-2

C-1

C-2

V-1

V-2

V-3


A-3

A-4

C-3

C-4

V-4

V-5


A-5

A-6

A-7

C-5 V-6


Advantages of functional organization

• Centralización de recursos similares.– Specialists in the same area close.

• Better professional carriers• Cooperation between specialists in the same

area

– Less need of technical experts.– Maximum flexibility in the use of staff.

• Higher standardization level.


Disadvantages of Functional Organization

• Cracks in the inter-functional areas, generating conflicts as:– Responsibility: “this isn't of my incumbency”– Power: several boss want to take decisions,

in the same subject.– Communication, “I finish mi task”, “Nobody

tell me about …”, ...

• Deferent functions can have opposite objectives.


Project organization (I)

• Objectives attainment in a quick manner.• Enterprise organization depends on the

actual projects• Each project has their own team and all

the necessary resources.• The project manager has decision capacity. • Team duration depends on the project

duration.


Project organization (II), Example:

S e cre ta r ía G e n era l

In ge n ie r ía V e n tas P rod ucción

P roye cto AD ire c to r A


P roye cto BD ire c to r B


P roye cto CD ire cto r C

D irec ció n G e n era l


Advantages of Project Organization.

• objectives unity (clear objective)• Control unity. Every body depends on

the same boss.• Easy communication.• Clear responsibilities.


Disadvantages of Project Organization

• Changing enterprise organization.• Duplication of resources and inefficiency. • Difficult to share individuals/expertise

across projects• Complex staff management

– What's the mater when de project is finished?– What about staff curricula?– Dead time…


Matrix organization (I)

• It's a multidimensional structure.• Try to take the best of both.• First we create functional structure

and over this we put a project structure.


Matrix organization (II)

D ire c to rP ro jec to A

D ire c to rP ro jec to B

D ire c to rP ro je c to C

D ire c to r G e n e ra ld e P ro yec tos

D ire c to r deV e ntas

D ire c to r deP ro d ucc ión

D ire c to r deF in a na zas

D ire c to r deIn ge n ie ría

D ire cc ió n G e n e ra l


Matrix organization: Advantages

• Equilibrate project objectives and departments.

• Staff has better professional stability• Specialists belong to the same

department and consults are easy.• Easy professional carriers.


Matrix organization :disadvantages

• Staff has two or more managers when they are in different projects.

• Project managers fell few authority.


Teams Structure

• The development of software projects usually requires:– Small teams.

• Classical structures aren’t an appropriate reference

– Specialists in different areas:• Software technical knowledge • Knowledge about the implied area.

– (Multifunctional teams).


Team Structure in software projects

• Three team structures are popular in this field:– Egoless programming team (Weinberg)– Chief programming team.– Controlled decentralized team structure.

» Marilyn Mantei (1981)


Egoless programming team (Weinberg)

• Ten or fewer programmers• Exchange their code with other team

members for error examination.• Goals are set by group consensus.• Group leadership is a rotating

function, becoming the responsibility of the individual with the abilities that are currently needed.


Egoless team: Management Structure.

• People are in different knowledge areas and experience levels.


Egoless team: Communication exchanges

that occur.• Everybody can communicate with

everybody.


Chief programming team.

• Use to be little teams.• It have a chief programmer who:

– manages all technical aspects.– Takes problem solutions and and goal

decisions.– Assign well defined (but large and

complex) to the team members.


Chief programmer

Programmer Data Bases Specialist

Chief programming team. Management Structure.

• Is a centralized autocratic structure.


Chief programming team: Communication exchanges that

occur.• All the communications past throw

the chief.


Controlled Decentralized Team.

• Teams can be large teams.• Has a project leader who governs a

group of senior programmers.• Each senior programmer in turn,

manages a group of junior programmers.

• The objective is to maintain other teams the best characteristics.


Project Leader

Senior Programmer

Junior Programmers

Controlled Decentralized Team: Management Structure.

• Responsibility is shared by the project leader and the seniors programmers.


Controlled Decentralized Team: Communication exchanges.

• People at he same level and their boss is decentralized.


Relations between team structures:

Difficulty

Size Duration

Modularity

Reliability

Timerequired

Sociability

Group structures High

Low

Large

Small

Short

Long

High

Low

High

Low

Strict

Lax

High

Low

Democraticdecentralized

X X X X X X X

Controlleddecentralized

X X X X X X X

Controlled centralized X X X X X X X


Communication in the software project.

• Communicating in harmony• In software development projects, the

inability of people to communicate effectively with one another represents one of the more common obstacles to the achievement of:– High product quality, and– High productivity.


Improving communications among

project players offers substantial morale,

productivity,quality, and, cost benefits to a project.


Ones communications problems surfaces, the process to follow...:

• Understand the cause of the problems.

• Put corrective action into place.• Enforce an ongoing communicative

work environment.


Actions to improve communication.

• When you are wrong, admit it.• Exercise tolerance.• Meet people.• Be quick to assist.• Ask others for assistance.• Use tact - put your comments in the

correct perspective.



• Keep others informed - do not surprises.

• Close problems.• Show appreciation.• Be a good listener.• Greet people - remember their

names.• Consider compromise.



• Be willing to break with tradition.• Know what to expect from others.

• Respect people.


Bibliography

– Mantei, M. “The effect of Programming Team Structures on Programming Task”. CACM March 1981. Reprinted en “Tutorial: Software Engineering Project Management de R. Thayer, IEEE Computer Society Prees, 1988.

– Whitten, N., Managing Software Development Projects - 2nd de.. John Whiley & Sons Inc. 1995.

Documents

Organizing a Software Project José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004