Team Organization and Project Management Based on Hans Van Vliet,

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?