1. Dr. Nguyen Hai Quan Email: Quan_nh@yahoo.com Phone: 0934221978

2.  Project Roles & Team Structure  Project Reviews  Project Monitoring and Control  Project Cloture Analysis  CMM 2

3.  Project Roles & Team Structure  Project Reviews  Project Monitoring and Control  Project Cloture Analysis  CMM 3

4. ◦ Programmers (system engineers)  Technical lead, architect, programmer, Sr. programmer ◦ Quality Assurance (QA) engineers (testers)  QA Manager, QA Lead, QA staff ◦ DBAs  DB Administrator, DB Programmer, DB Modeler ◦ CM engineers (build engineers) ◦ Network engineers, System Administrators ◦ Analysts (business analysts) ◦ UI Designers ◦ Information Architects ◦ Documentation writers (editors, documentation specialist) ◦ Project manager ◦ Other  Security specialist, consultants, trainer 4

5.  You need to decide which of these are necessary for your class project  Depends on what you’re building  How big is it?  Is it UI intensive? Data intensive?  Are you installing/managing hardware?  Do you need to run an operations center?  Is it in-house, contract, COTS, etc?  Depends on your budget 5

6.  Projects do not typically have a ‘static team size’  Who and how many varies as needed 6 Copyright: Rational Software 2002

7.  PM must have a plan as to how & when  Roll-on ◦ Hiring or ‘reserving’ resources ◦ Ramp-up time  Learning project or company  Roll-off ◦ Knowledge transfer ◦ Documentation ◦ Cleanup 7

8.  Part of Software Development Plan  Includes ◦ What roles needed, how many, when, who ◦ Resource assignments ◦ Timing: Start/stop dates ◦ Cost/salary targets (if hiring)  Project Directory ◦ Simply a list of those involved with contact info.  Team size: often dictated by budget as often as any other factor 8

9.  1 st : What’s the team’s objective? ◦ Problem resolution  Complex, poorly-defined problem  Focuses on 1-3 specific issues  Ex: fixing a showstopper defect  Sense of urgency ◦ Creativity  New product development ◦ Tactical execution  Carrying-out well-defined plan  Focused tasks and clear roles 9

10.  Two early philosophies ◦ Decentralized/democratic ◦ Centralized/autocratic  Variation ◦ Controlled Decentralized 10

11.  Business Team ◦ Most common model ◦ Technical lead + team (rest team at equal status) ◦ Hierarchical with one principal contact ◦ Adaptable and general ◦ Variation: Democratic Team  All decisions made by whole team 11

12.  Chief-Programmer Team  From IBM in 70’s  See Brooks and Mythical Man-Month  a.k.a. ‘surgical team’  Puts a superstar at the top  Others then specialize around him/her  Backup Programmer  Co-pilot or alter-ego  Administrator  Toolsmith  “Language lawyer”  Issues  Difficult to achieve  Ego issues: superstar and/or team  Can be appropriate for creative projects or tactical execution 12

13.  Skunkworks Team ◦ Put a bunch of talented, creative developers away from the mother ship  Off-site literally or figuratively ◦ Pro: Creates high ownership & buy-in ◦ Con: Little visibility into team progress ◦ Applicable: exploratory projects needing creativity  Not on well-defined or narrow problem 13

14.  SWAT Team  Highly skilled team  Skills tightly match goal  Members often work together  Ex: security swat team, Oracle performance team 14

15.  Large teams ◦ Communication increases multiplicatively  Square of the number of people  50 programmers = 1200 possible paths  Communication must be formalized ◦ Always use a hierarchy ◦ Reduce units to optimal team sizes  Always less than 10 15

16.  What is the optimal team size?  4-6 developers  Tech lead + developers  Small projects inspire stronger identification  Increases cohesiveness  QA, ops, and design on top of this 16

17.  “Hire for Trait, Train for Skill”  Look for: “Smart, Gets Things Done” ◦ For programmers, see joelonsoftare’s “Guerilla Guide to Interviewing”Guerilla Guide to Interviewing  Balance the team 17

18.  A resource planning tool  Who does What  Can be for both planning and tracking  Identify authority, accountability, responsibility  Who: can be individual, team or department  Can have totals/summary at end of row or column (ex: total Contributors on a task) 18

19. 19

20. 20

21.  Another resource planning tool  Resources on one axis, skills on other  Skills can high level or very specific  Cells can be X’s or numeric (ex: level, # yrs.) 21

22.  Requirements Tools  Design Tools  Construction Tools  Test Tools  Maintenance Tools  CM Tools 22

23.  Tools could save 10-25% on some projects ◦ But that’s optimistic at best  Choose tools to meet your needs  No can guarantee you anything ◦ They *may* help ◦ Tools don’t control people, especially customers 23

24.  Your projects: do you choose a language?  Typically not the PM’s choice, but does effect you ◦ Staffing requirements ◦ Methodology ◦ Tools and infrastructure 24

25.  Project Roles & Team Structure  Project Reviews  Project Monitoring and Control  Project Cloture Analysis  CMM 25

26.  Reviews are the most effective and commonly used method for identifying defects, not only in nonexecutable documents such as the test plan and design document but also in code.  Advantages: ◦ Through reviews, the best talent in the organization can be utilized in a project even if they are not assigned to it. ◦ Help preserve team motivation by giving people a sense of achievement, participation, and recognition. ◦ Team members can develop their skills and senior people can mentor less-experienced colleagues. ◦ help prevent defects by creating more awareness about them Dr. Nguyen Hai Quan, Project Management, 2010 26

27. Dr. Nguyen Hai Quan, Project Management, 2010 27

28. Dr. Nguyen Hai Quan, Project Management, 2010 28 Work ProductFocusEntry CriteriaParticipants Requirement specification  Requirements meet customer needs. -Requirements are implementable. -Omissions, inconsistencies, and ambiguities in the reuiremnts. The document conforms to the standards. Customer Designers Tester (system testing) Installation team member User documentation author

29. Dr. Nguyen Hai Quan, Project Management, 2010 29 Work ProductFocusEntry CriteriaParticipants High-level design -High-level design implements the requirements. -The design is implementable. -Omissions and other defects in the design. -The document conforms to standards. -The requirements have been reviewed and finalized. -Requirements author -Detailed designer -Developer

30.  Project Roles & Team Structure  Project Reviews  Project Monitoring and Control  Project Cloture Analysis  CMM 30

31.  project managers must have visibility into the true status of the project, for which the best approach is to quantitatively measure the key parameters 31

32. 32

33. 33  Monitoring rates ◦ Daily, weekly, monthly ◦ If problems occur – then adjust  You may have to monitor problem areas more closely  For some period of time  Almost always there’s one or more areas under closer scrutiny  Status Reporting ◦ Part of the communications management plan  Which is usually just a section of SDP

34. 34  Ongoing effort to keep your project on track  4 primary activities: ◦ 1. Planning performance  A SDP, schedule, and a control process ◦ 2. Measuring status of work performed  Actuals ◦ 3. Comparing to baseline  Variances ◦ 4. Taking corrective action as needed  Response  Prerequisite to good control is a good plan

35. 35  “Control”  Power, authority, domination. No.  Guiding a course of action to meet an objective. Yes.  Principles  Work is controlled, not workers  Control helps workers be more effective & efficient  Control based on work completed  Use concrete deliverables  Balance  Appropriate level between too much and too little  Includes:  Micro-managing vs. neglect  Too much tracking detail vs. too little

36.  Activities Tracking ◦ to ensure that planned activities are done on time ◦ MSP is also used for activities tracking  Defect Tracking ◦ Once information about a defect is entered in this system, it remains open until it has been fixed ◦ At the end of the project, ideally no open defects should remain  Issues Tracking ◦ many small jobs or clarifications come up during a project. These problems are called issues ◦ projects usually open an issues log Dr. Nguyen Hai Quan, Project Management, 2010 36

37.  Status Reports ◦ the main mechanism for regularly communicating the state of the project to senior management and the customer. ◦ generated weekly  Status reports contains ◦ Customer complaints ◦ Milestones achieved this week ◦ Milestones missed this week and the reasons for them ◦ Milestones planned for the next week ◦ Issues requiring clarification or attention ◦ Estimated work versus available time by milestone Dr. Nguyen Hai Quan, Project Management, 2010 37

38. Dr. Nguyen Hai Quan, Project Management, 2010 38

39.  Project Roles & Team Structure  Project Reviews  Project Monitoring and Control  Project Cloture Analysis  CMM 39

40.  to determine what went right, what went wrong, what worked, what did not, and how it could be made better the next time  Closure Analysis Report contains: ◦ General and Process-Related Information ◦ Risk Management ◦ Size ◦ Effort ◦ Defects ◦ Causal Analysis ◦ Process Assets Dr. Nguyen Hai Quan, Project Management, 2010 40

41.  Project Roles & Team Structure  Project Reviews  Project Monitoring and Control  Project Cloture Analysis  CMM 41

42.  A software process framework  “Process determines capability”  5 ‘maturity’ levels  ‘Evolutionary plateaus’ to a mature software process  Each level has its own goals  Organizations can be ‘certified’certified’ ◦ Later to be used as a marketing or validation tool  Links: SEI, Diagram, Levels, DrexelSEIDiagramLevelsDrexel 42

43.  1. Initial ◦ ‘Ad hoc’ process, chaotic even ◦ Few defined processes ◦ Heroics often required here  2. Repeatable ◦ Basic PM processes  For cost, schedule, functionality ◦ Earlier successes can be repeated  3. Defined ◦ Software & Mgmt. process documented ◦ All projects use a version of org. standard 43

44.  4. Managed ◦ Detailed metrics of process & quality ◦ Quantitative control  5. Optimizing ◦ Continuous process improvement ◦ Using quantitative feedback 44