# Organizational structure
###### tags: `SPM`

## SMP 12.4 - Organizational structures

**Organizational structures and projects**
On large project there could be several groups contributing to different aspects of the project.

Some organizationel structures is needed to form and manage these groups.

This organizational structure would take account of the totality of projects and other, non-project, activities being undertaken by the organization.

**Formal vs informal structures**

Formal:
- expressed in the staff hierarchy chart.
- focus on authority, who has which boss

Informal:
- contracts and communication emerges spontaneously between memebers of staff while working
- takes over when unexpected happens.

**Hierarchical approach**
The traditional management structure is based on hierarchy. Each staff member has only one managemr, while a manager will have responsibility for serveral members of staff.

Authority flows from the top down through the structure.

**Staff vs line**

Staff can often be divided into line workers who actually produce the end product and support staff who carry out supporting roles.

**Departmentalization**
*Differentiation* concerns the departmentalization of organizations.

Software development
- usually orginazied using either a functional or a task-oriented approach or life-cycle-phase.

Functional departmentalization:
- system analysts may be put in a seperate group from the programmers.
- The programmer would act as a pool from which resources are drawn for particular tasks.
- can lead to a more effective use of staff.
- Programmers can be allocated to jobs on a need basis and be released for other work when the task is completed.
- Make it easier for the programmer to have a carrer department which allows programmers to rise without change their specialism.
- encourage the interchange of new technical ideas betwwen techincal staff and promulgation of company-wide standards.
- separate departments can lead to communication problems.

Tasks-oriented departmentalization:
- programmers and system analysts are grouped together in project teams.
- The project team could be gathered to implement a specific long-term project or could exists on a permerant basis to service the needs of a particular set of users.
- can lead to good communication in the team.

Life-cycle-phase departmentalization:
- seperate teams for development and mainterance.
- Some staff can concentrate on developing new systems with few interruptions while other teams, more oritented towards service and support.

Programme management can facilitate better sharing of staff between projects.

Some orginzations have attempted to get the best of all worlds by having a matrix structure.
- developers have 2 managers: A project leader (give them day-to-day directions) and a programmering leader (give them day-to-day directions about the work in hand)
> Cisco is kinda a Matrix

## Two different Organization structures
**Circular**
Structure
The center-most circle represents the highest-level officer.

The outermost circles represent entry-level employees and individual contributors.

Promotes communication and free flow between different departments

Spreading their vision outward, instead of the chain of command

*Advantages*
- Enforces hierarchy
- psychological

*Disadvantages*
- Can be confusing
- Difficult to find out who to report to

*Best suited*
- Large organizations where communication between departments is encouraged


**Line**
Structure
Oldest form of organization

Simple type of organizational structure

Divided into departments, each with its own responsibilities

Chain of command
Leader at top, with a leader for each department beneath

*Advantages*
- Effective communication
- Self containing departments, can take own decisions

*Disadvantages*
- Low, to none information structure
- Bureaucratic

*Best suited*
- Good for use in large organizations, with low use of collaboration


## Architectures, coordination, and distance: Conway's law and beyond
Architecture of a system plays a pivotal role in coordinating development work.

Conway's law: the structure of the system mirrors the structure of the organization that designed it.
- This relation is a necessary consequence of the communcation needs of the people doing the work.

Defining a software module as: "A responsibility assignment rather than a subprogram."

The point of structure is to support coordination of the development work.

Architecture however, addresses only one of the serveral dimensions on which we must coordinate development.
To support effeicient use of resources, project requires plans that specify when milestones must be completed and who will do the work.

People must agree on how the product will be developed. (project process)
- Ideally: architecture, plans and processes - coordination mechanisms would be sufficient to establish effective coordination among teams.

In real world: This idea is seldom fully attrined because unpredicted events occur that must be accommondated
- estimates are in accurrate, process steps are executed imperfectly, requirements and technologies change, and people leave.

Empirical studies suggest that developers rely heavily on informal ad hoc communications.
- to fill in the details, handle exceptions, correct mistakes, and bad predictions, and manage the ripple effect of all these changes.

many companies are driven to distribute development resources around the globe for marketing purposes.
- acquisitions, cost considerations, availability of needed to expertise.

Geographical distribution challenges coordination mechanisms and informal communication
- requireing that they robust across distances.

**Architecture-based coordination**
Highlights from the struggeles.

following the design agreements, project teams developed each component at a single site, in relative isolation from teams at the other sites.

There were times when a developer working on a particular component did recornize a potential confilcs.
- tried to identify the people responsible for components that used the interface and then tried to work out specifications refinements.

The refinements were infrequently recorded in the documentation because that took time away from development.
- caused difficulties on a number of occasions.
- new person, unaware of refinement takes over.
- problematic during testing, when tests that violates these agreements generated bug reports.

Developers has to manage interfaces between the product and its substrate techonogies.

**Plan-based coordination**
40-step integration plan
- was not closely followed because it depended on the overall development plan and assumed that the substrate environments would be easy to assemble.

plan relied on having components available for integration at a certain times
- the project suffered from many of the usual difficulties and delays
- changing requirements, staff turnover, extreme schedule pressure.

As developers strove to adjust to the project realities: "chopped and changed as things became ready."

Project progressed, they augmented the documentation to help them deal with the unpredictability.

In retrospect:
- the plan missed a critical, initial step: building the product's substrate environment.

**Process-based coordination**
The developers also used a number of processes tió help organize and structure the development environment.

each development site has its own change-management process.

Collocated developers can initiate communication easily because they know who is around and if they are available.

**Distance and flexible ad hoc communication**
Architectures, plans, and processes are all vital coordination mechanisms in software projects.

Their effectiveness extends only as far as our ability to see into the future.

Handling the unanticipated both radidly and gracefully requires flexible ad hoc communication.

---
When developers work at the same location, project members run into each other frequently.

chance meetings are basically social.
- unplanned contact are surpricingly important in keeping project coordinated.

The most obvious obstacle to communicating across sites is the inability to share the same environment and to see what is happening at the other site.

Developers often reported great diciculty in deciding who to contact at the other site with questions. (Think cisco here again)

Collocated developers can initiate communication easily because they know who is around and if they are available.

For developers at different locations, the difficulty of initiating contact was often much greater.

3 consequences
1. developers did not try to communicate as frequently as they would have
2. cycle time increased.
3. Issues has to be escalated to management more often.

**The ability to communicate effectively**
The most obvious obtacle to communicating across sites is the inability to share the same environment and to see what is happing at the other site.

Collaborative technologies offer the promise of supporting cross-site development.

**Lack of trust**
The 2 sites did not see themselves as partners, cooperating towards the same end.

found it a bit to specific for that project.

**Overcoming distance**
The most effective approaches to overcoming distance will have to address both parts of the equation.

The essence of good design is facilitating coordination developers.

Good design is vital, but good design is not enough.

It is essential to coordinate when, how, where, and by whom the product will be developed.
- when intermediate work products are handed off between groups
- It is necessary for both to have a clear idea of what steps have and not been carried out at that point.
- Gennerally requires common understanding of a defined development process.
- for Large projects
- replete with temporal dependencies that have major implications for resources planning and on-time delivery.

Stability of the design is also important for multisite coordination.

if... work to different teams and sites on the basis of an architecture that is constantly changing, the benefits of modularity might be lost as interfaces, functionality, and project commitments are continually renegotiated.

> you can only optimize the organizational arrangements with respect to "the system concept in effect at that time

Instability creates an enormous need for communication, which is precisely what distributed organization do least well.

**3 lessons to rediuce the need for cross-site communication**
1. Have a good, modular design and use it as the basis for assigning work to different sites. The more cleanly separated the modules, the more likely the organization can successfully develop them at different sites.
2. To the ectent possible, only split the development of well-understood products where architectures, plans and processes are likely to be stable. Instability will greatly increase the need for communication.
3. Record decisions and make sure this documentation is easily available. Documenting specification refinements and dedisions reached in multisite meetings will save many troublesome misunderstandings. Take all possible steps to overcome the barries to informal communication.
4. Front-load travel: Dont postpone using the travel budget; bring people who will need to communicate together early on.
5. Plan travel to create a pool of liaisons. Give the early travelers the explicit assignment of meeting people in a variety of groups at the other site and learing the overall organizational structure.
6.