TeamOrganizationAndProjectManagement

TeamOrganizationAndProjectManagement - Team Organization...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon
Team Organization and Project Management Based on Hans Van Vliet, Software Engineering: Principle and Practice , chapters 5 and 8 Glenn D. Blank
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
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?
Background image of page 2
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
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
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?
Background image of page 4
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.”
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Chief Programmer Team What do the graphics imply about this team structure?
Background image of page 6
Image of page 7
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 08/06/2008 for the course CSE 432 taught by Professor Blank during the Fall '08 term at Lehigh University .

Page1 / 23

TeamOrganizationAndProjectManagement - Team Organization...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online