PROJECT MANAGEMENT AND PROJECT TEAM STRUCTURE

Transcription

1 PROJECT MANAGEMENT AND PROJECT TEAM STRUCTURE CSA 3203 Joseph Bonello WHAT IS A PROJECT? A collection of linked activities, carried out in an organised manner, with a clearly defined start point and end point to achieve some specific results desired to satisfy the needs of the organisation at the current time 1

2 WHAT IS PROJECT MANAGEMENT? Project : A group of milestones or phases, activities or tasks that support an effort to accomplish something. Management : is the process of Planning, Organizing, Controlling and Measuring PROJECT MANAGEMENT A dynamic process that utilises the appropriate resources of the organisation in a controlled and structured manner, to achieve some clearly defined objectives identified as needs. It is always conducted within a defined set of constraints 2

3 ASPECTS OF PROJECT MANAGEMENT Planning: is the most critical and gets the least amount of our time Organizing: orderly fashion (Contingent/Prerequisites) Controlling: is critical if we are to use our limited resources wisely Measuring: to determine if we accomplished the goal or met the target? PROJECT CONTROL Control is focused on three elements of a project Performance Cost Time 3

4 CONTROLLING PERFORMANCE There are several things that can cause a project s performance to require control: Unexpected technical problems arise Insufficient resources are available when needed Insurmountable technical difficulties are present Quality or reliability problems occur Client requires changes in specifications Inter-functional complications arise Technological breakthroughs affect the project CONTROLLING COST There are several things that can cause a project s cost to require control: Technical difficulties require more resources The scope of the work increase Initial bids were too low Reporting was poor or untimely Budgeting was inadequate Corrective control was not exercised in time Input price changes occurred 4

5 CONTROLLING TIME There are several things that can cause a project s schedule to require control: Technical difficulties took longer than planned to resolve Initial time estimates were optimistic Task sequencing was incorrect Required inputs of material, personnel, or equipment were unavailable when needed Necessary preceding tasks were incomplete Customer generated change orders required rework Governmental regulations were altered WHAT ASPECTS DO WE MEASURE? Are we efficient? Are we productive? Are we doing a good job? What is the outcome? Is it what we wanted to be? If you can t plan it, You can t do it If you can t measure it, you can t manage it 5

6 WHY IS PROJECT MANAGEMENT USED? It is necessary to Track or Measure the progress we have achieved towards a Goal we wish to accomplish We use Project Management to Aid us in Maximizing and Optimizing our resources to accomplish our goals WHY IS PROJECT MANAGEMENT IMPORTANT? Enables us to map out a course of action or work plan Helps us to think systematically and thoroughly Unique Task Specific Objective Variety of Resources Time bound 6

7 TASKS OF A PROJECT MANAGER Regular Monitoring Resource Support Critical issues discussed and solution Meeting with the team on completion of each major milestone Track the progress against the plan ADVANTAGES In built Monitoring/ Sequencing Easy and Early identification of Bottlenecks Activity based costing Identification and Addition of missing and new activities 7

8 ADVANTAGES Preempting unnecessary activity/expenditure Timely Completion Assigning tasks Reporting RISKS OF NOT MANAGING A PROJECT Delivery Delay Additional Cost Waste of Resources Lack of Quality Customer Dissatisfaction Loss of Reputation 8

9 RISK MANAGEMENT Risk management is project management for adults. Tim Lister. During project planning, use a risk management strategy such as the following: RISK MANAGEMENT 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 9

10 RISK MANAGEMENT 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 TEAM ORGANISATION How does Project Management relate to Team Organisation? What structures exist, and which are suitable for a software project team? Are there any pitfalls to watch out for? 10

11 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 MINTZBERG S ORGANIZATIONAL CONFIGURATIONS Divisional 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 11

12 HIERARCHICAL TEAM ORGANISATION 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 HIERARCHICAL TEAM ORGANISATION Large projects often distinguish levels of management: 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. 12

13 CHIEF PROGRAMMER TEAM 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 MATRIX ORGANISATION 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 13

14 DEMOCRATIC (OPEN 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 DISCUSSION 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? 14

15 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. EXERCISE COMMENTS 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. 15

16 BROOKS LAW (1975) Adding manpower to a late software project makes it later What is the implication of this law on software 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 16