Transcript Team Organization and Project Management Based on Hans Van Vliet, Software Engineering: Principle and Practice, chapters 5 and 8 Glenn D.

Team Organization and
Project Management
Based on Hans Van Vliet,
Software Engineering:
Principle and Practice,
chapters 5 and 8
Glenn 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 or
Open structured teams
Why are democratic teams often favored
in 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 doesn’t reach consensus
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:



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:


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!
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


Linear waterfall process model should work — Why?



Emphasis is on how to realize (design and implement) the solution
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


Linear waterfall process model could still work — Why?


Emphasis on getting adequate staffing, or developing product with
limited staff
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


Iterative and incremental process model is better – Why?


Frequently measure progress and adjust process as necessary
Standardization of work outputs is good coordination mechanism


Problem is controlling the development process: milestones,
personnel, responsibilities, all need to be identified
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?