Team Organization and Project Management

1
Team Organization and Project Management

• Based on Hans Van Vliet, Software Engineering
  Principle and Practice,
• chapters 5 and 8
• Glenn D. Blank

2
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?

3
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

4
Mintzbergs 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?

5
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 worka
  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.

6
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?

7
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 projects progress

8
Democratic orOpen structured teams
Why are democratic teams often favoredin Extreme
Programming process?

• 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 doesnt reach
  consensus

9
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?

10
Team organization exercise

• Suppose you have a great idea for a program that
  calculates and files a persons 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?

11
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.

12
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

13
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

14
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

15
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

16
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

17
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

18
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)
• doesnt meet real-time requirements

19
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 a
• 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

20
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)

21
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 50s
• Shows task duration (on the task node)
• Shows precedence relations
• Generally does not show task decomposition

22
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 projects progress and
  expenditures

23
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?