Team Organization and Project Management
description
Transcript of Team Organization and Project Management
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?