Team Organization and Project Management

Based on Hans Van Vliet, Software Engineering: Principle and Practice,

chapters 5 and 8Glenn D. Blank

Brooks’ law(1975)

Adding manpower to a late project only makes it later. Why? As team gets larger, communication overhead increases As more people are added to a project, total team

productivity decreases at first. Why?

Boehm: A system that has to be delivered too fast gets into the “impossible region” Chance of success becomes almost nil if schedule

is pressed too far Why is it useful to explain this reality to project

managers?

Brooks’ Law revisited

Quick review: what is Brooks’ law? “Adding manpower to a late software project makes it

later.” What does this law (or maxim) imply about the

importance of team organization for software development projects?

“There is no substitute for careful planning and team formation if overruns and later confusion, not to mention disaster, are to be avoided.”-- John S. MacDonald, MacDonald Dettwiler

Mintzberg’s organizational configurations

Five ways organizations typically configure and coordinate teams: Simple structure – one or few managers, direct supervision

Typically found in new, relatively small organizations Machine bureaucracy – mass-production and assembly lines

Coordination requires standardization of work processes Divisionalized form – each division has autonomy

Split up work and let each group figure out how to do it Coordination achieved through standardization of work outputs and

measuring performance of divisions Professional bureaucracy – skilled professionals with autonomy

Coordination achieved through standardization of worker skills Adhocracy – for innovative or exploratory projects

Coordination achieved through mutual adjustment Which configurations apply for software development projects?

Hierarchical team organization

Large projects often distinguish levels of management: Leaf nodes is where most development gets done; rest of tree is management Different levels do different kinds of work—a good programmer may not be a

good manager Status and rewards depend on your level in the organization Works well when projects have high degree of certainty, stability and repetition But tends to produce overly positive reports on project progress, e.g.:

Bottom level: “We are having severe trouble implementing module X.” Level 1: “There are some problems with module X.” Level 2: “Progress is steady; I do not foresee any real problems.” Top: “Everything is proceeding according to our plan.”

Chief Programmer Team

What do the graphics imply about this team structure? Chief programmer makes all important decisions

Must be an expert analyst and architect, and a strong leader Assistant Chief Programmer can stand in for chief, if needed Librarian takes care of administration and documentation Additional developers have specialized roles Pros and cons of this team structure? Will you use this organization?

Matrix organization

Organize people in terms of specialties Matrix of projects and specialist groups People from different departments allocated to software

development, possibly part-time

Pros and cons? Project structure may not match organizational structure Individuals have multiple bosses Difficult to control a project’s progress

Democratic orOpen structured teams

A “grass roots” anti-elitist style of team organization Egoless: group owns the documents & code (not individuals) All decisions are based on team consensus Depends on total cooperation of its members Requires clear structure for the way the team interacts Functional roles (e.g. moderator, recorder) rotate among

team members A technical leader has external responsibility and resolves

issues when team doesn’t reach consensus

Why are democratic teams often favoredin Extreme Programming process?

What kind of organization does this cartoon illustrate?

• Do hierarchical organizations have to be like this?• Why are hierarchical organizations the most common in industry and government?

Team organization exercise Suppose you have a great idea for a program that

calculates and files a person’s yearly tax return, without getting them in trouble with the IRS. Keep in mind that this program must know the details of the tax laws for each city and state in the United States. In other words, the complexity is high, and the program will be susceptible to change a year or two down the road.

Which team structure would you prefer for this task? Chief programmer team, Democratic team, or Hierarchical team?

Exercise comments

Chief programmer team: Best for low difficulty projects, with a short life span. Just imagine a chief programmer trying to write documentation

for every tax law in every city and state in the United States! Democratic team:

A project of this scale requires a large development team. The communication necessary for a democratic structure might

be difficult to manage. Hierarchical team:

While hierarchy may be suitable for large projects, it may also create something as cumbersome as the tax code!

None of these team structures are necessarily optimal. As Fred Brooks once argued, “there is no silver bullet” in

software engineering. Each choice will have certain tradeoffs.

A systems view of project control In systems theory, effective, the controlling entity

(project manager and decision rules) must meet the following conditions: Must know the goals of the system Must have sufficient control variety (tools, project

organization, etc.) Must have information on state, input and output of the

system Must have a conceptual control model, i.e., to what extent

different variables depend and influence each other When all these conditions are met, control is rational

So, are software development projects usually rational? Not if there are lots of uncertainties about control conditions

Taxonomy of software projects

Uncertainties affect three project characteristics: Product, process, and resource characteristics E.g., if we have clear and stable user requirements, then

product certainty is high and this aspect of control is rational The grid shows a taxonomy of four archetypal kinds of

projects, depending on their characteristics

Realization problems

Requirements are clear, process predictable, resources sufficient Emphasis is on how to realize (design and implement) the solution

Linear waterfall process model should work — Why? Requirements are known and stable and personnel can realize them

Direct supervision (such as chief programmer team) is a reasonable coordination mechanism – Why?

Formalized cost model (such as COCOMO) usually works well

Allocation problems

Requirements and process are known but resources are uncertain Emphasis on getting adequate staffing, or developing product with

limited staff Linear waterfall process model could still work — Why?

Standardize the process as much as possible, so that staff can move between tasks. Maybe outsource?

Formalized cost model (such as COCOMO) usually works well

Design problems

Requirements are known but resources and process uncertain Problem is controlling the development process: milestones,

personnel, responsibilities, all need to be identified Iterative and incremental process model is better – Why?

Frequently measure progress and adjust process as necessary Standardization of work outputs is good coordination mechanism

E.g., UML diagrams, standardized unit tests, etc. Cost estimation must rely on data from past projects

Not enough data for formal cost model

Exploration problems

Uncertainty about requirements, process and resources Sounds like a research project! – either in graduate school or industry Need flexibility and commitment from staff, and in budget

Prototyping is a good process model – Why? Adhocracy is the coordination mechanism Use expert judgments to gauge the magnitude of the project, and

repeat cost estimates with each successive prototype

Risk management

“Risk management is project management for adults.” – Tim Lister.

During project planning, use a risk management strategy such as the following:

1. Identify risk factors, e.g.: personnel shortfall (not enough people, wrong or weak skills) unrealistic schedule/budget product has wrong functionality product has wrong user interface product has unneeded features volatile requirements bad external components bad external tasks (e.g. subcontractors) doesn’t meet real-time requirements

Risk management (2)

2. Determine risk exposure: how likely a given risk will occur

Risk exposure = p (probability) x E (effect in person-months)

3. Develop strategies to mitigate the risks For those with highest risk exposure, above threshold α Kinds of strategies:

Avoid, by taking precautions so the risk does not occur Transfer, by finding an alternate solution (e.g. prototype to

handle unstable requirements) Accept, and provide a contingency plan

4. Handle risks: monitor them, apply mitigation strategies as necessary

Project planning techniques: Work breakdown structure (WBS)

Hierarchical decomposition of a project into subtasks Shows how tasks are decomposed into subtasks Does not show duration Does not show precedence relations (e.g. task A must be

finished before task B can start)

Project planning techniques: PERT charts

PERT chart (Program Evaluation and Review Technique) A network (graph) where the nodes represent tasks and arrows

describe precedence relations Used successfully in management of Polaris missile project in 50’s Shows task duration (on the task node) Shows precedence relations Generally does not show task decomposition

Project planning techniques: Gantt charts

A graphical visualization of a schedule, where the time span for each activity is depicted by the length of a segment drawn on an adjacent calendar Generally does not show task decomposition Does not show duration, only the time span over which the task is

scheduled Does not show precedence relations Can show activity of multiple developers in parallel Makes it easy to monitor a project’s progress and expenditures

Discussion

Classify your term project with respect to: Product certainty? Process certainty? Resource certainty? Control situation: realization, allocation, design or

exploration? Potential risks and how did you mitigate them? What project planning techniques (work breakdown

structure, PERT charts or Gantt charts) were or might have been helpful?

What project management organization (hierarchical, chief programmer team, democratic/egoless, matrix) did you use?