Lecture 9b


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • OpenUI 201K OPL + 333K C++ NetDeploy team size 3 -> 10
  • Commentary : A project is a related and interdependent set of activities that: Project work is the opposite of process work Process : ongoing, general objectives, and maybe no deliverables; about the way things are done. Project : planned end, specific objectives & deliverables; about the things (products) themselves. Projects change the status quo significant functional and/or quality improvement improve the product’s competitive position to open new market opportunities to satisfy particular customer requirements
  • Commentary : If the first three points are not achieved, then the project team won’t be given many more projects … If the last point is not achieved, then the project team won’t want to do many more projects ...
  • Lecture 9b

    1. 1. Software Engineering: Analysis and Design (CSE3308) Lecture 9b: Project Management in Industry CSE3308/CSC3080/DMS/2000/24
    2. 2. Lecture 9b: Project Management in Industry <ul><li>Goal </li></ul><ul><ul><li>To cover some of the key topics in Project Management, in a practical way, using actual industry examples. </li></ul></ul><ul><li>Focus </li></ul><ul><ul><li>Focus on (software) product development projects. </li></ul></ul><ul><li>Topics </li></ul><ul><ul><li>Project Management Overview </li></ul></ul><ul><ul><li>Scope Management </li></ul></ul><ul><ul><li>Estimation </li></ul></ul><ul><ul><li>Risk Management </li></ul></ul><ul><ul><li>People Management </li></ul></ul>
    3. 3. Trevor Holmes <ul><li>Education </li></ul><ul><ul><li>B.Sc (Physics/Mathematics) Deakin 1980 </li></ul></ul><ul><ul><li>Dip.Eng (Digital Control) FIT 1985 </li></ul></ul><ul><ul><li>M.App.Sc Monash 1993 “The Intelligent Interpretation of Line Drawings and Text using Pattern Recognition Analysis”. </li></ul></ul><ul><li>Career </li></ul><ul><ul><li>Olex Cables 1980-1983 Software Engineer </li></ul></ul><ul><ul><li>ACI Computer Services 1983 - 1987 System Manager, Systems Engineer. </li></ul></ul><ul><ul><li>Varian Australia 1987-1995 Software Engineer, Software Marketing Manager, Project Manager, Software Quality Manager </li></ul></ul><ul><ul><li>Hewlett-Packard 1985-1996 Consultant (PSO) </li></ul></ul><ul><ul><li>Siemens Research 1996-1997 Project Manager (SIEPLAN / Capacity Integrator Project) </li></ul></ul><ul><ul><li>Open Software Associates 1998 - current Project Manager </li></ul></ul>
    4. 4. Varian OSI Products <ul><li>SpectrAA-600/800 Atomic Absorption spectrometer system. </li></ul><ul><ul><li>consists of: </li></ul></ul><ul><ul><ul><li>Microprocessor controlled instrument (near real-time control). </li></ul></ul></ul><ul><ul><ul><li>PC Workstation for system control and data management. </li></ul></ul></ul><ul><ul><ul><li>Accessories </li></ul></ul></ul><ul><ul><ul><ul><li>Graphite Tube Atomizer (GTA) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Sample Preparation System (SPS) </li></ul></ul></ul></ul><ul><ul><li>product price </li></ul></ul><ul><ul><ul><li>$40K to $80K </li></ul></ul></ul><ul><ul><li>effort: </li></ul></ul><ul><ul><ul><li>max team 15 </li></ul></ul></ul><ul><ul><ul><li>50+ engineering years </li></ul></ul></ul><ul><ul><ul><li>>500K lines code </li></ul></ul></ul><ul><ul><li>on the web: </li></ul></ul><ul><ul><ul><li>http :// www. varianinc .com/ osi </li></ul></ul></ul>
    5. 5. Siemens Research Products <ul><li>Sieplan/Capacity Integrator Network planning and design tool for Telecommunications Transmission (SDH & PDH) Networks. </li></ul><ul><ul><li>consists of: </li></ul></ul><ul><ul><ul><li>5 to 200 GUI Clients (Windows) </li></ul></ul></ul><ul><ul><ul><li>Unix based server (HPUX) </li></ul></ul></ul><ul><ul><ul><li>Versant OODBMS with databases up to 20GB. </li></ul></ul></ul><ul><ul><li>product price </li></ul></ul><ul><ul><ul><li>$500K to $10M </li></ul></ul></ul><ul><ul><li>effort: </li></ul></ul><ul><ul><ul><li>max team 60 </li></ul></ul></ul><ul><ul><ul><li>100+ engineering years </li></ul></ul></ul><ul><ul><ul><li>development budget > $20M </li></ul></ul></ul><ul><ul><ul><li>500K lines code </li></ul></ul></ul><ul><ul><li>on the web </li></ul></ul><ul><ul><ul><li>http://www.sr.com.au </li></ul></ul></ul>
    6. 6. OSA Products <ul><li>OpenUI cross-GUI client/server UIMS </li></ul><ul><ul><li>consists of: </li></ul></ul><ul><ul><ul><li>cross GUI runtime engine </li></ul></ul></ul><ul><ul><ul><li>GUI Builder </li></ul></ul></ul><ul><ul><ul><li>integrated client / server messaging </li></ul></ul></ul><ul><ul><ul><li>compiler and virtual machine interpreter </li></ul></ul></ul><ul><ul><li>effort </li></ul></ul><ul><ul><ul><li>65 engineering years </li></ul></ul></ul><ul><ul><ul><li>550K lines code </li></ul></ul></ul><ul><ul><li>on the web </li></ul></ul><ul><ul><ul><li>http://www.osa.com.au </li></ul></ul></ul><ul><li>NetDeploy Internet application deployment and version management system </li></ul><ul><ul><li>consists of: </li></ul></ul><ul><ul><ul><li>Packer </li></ul></ul></ul><ul><ul><ul><ul><li>identifies component files of application </li></ul></ul></ul></ul><ul><ul><ul><ul><li>generates catalogue file </li></ul></ul></ul></ul><ul><ul><ul><ul><li>installs application files on Web Server </li></ul></ul></ul></ul><ul><ul><ul><li>Launcher </li></ul></ul></ul><ul><ul><ul><ul><li>checks client machine against catalogue </li></ul></ul></ul></ul><ul><ul><ul><ul><li>downloads necessary files via HTTP </li></ul></ul></ul></ul><ul><ul><li>effort to date: </li></ul></ul><ul><ul><ul><li>27 engineering years </li></ul></ul></ul><ul><ul><ul><li>250K lines code </li></ul></ul></ul>
    7. 7. Project Management <ul><li>What is a project ? </li></ul><ul><li>What is a successful project ? </li></ul><ul><li>What drives project management ? </li></ul><ul><li>How are projects organized ? </li></ul><ul><li>How is progress measured ? </li></ul><ul><li>How is progress monitored ? </li></ul><ul><li>Additional Resources </li></ul>
    8. 8. What is a Project ? <ul><li>A project is a related and interdependent set of activities that: </li></ul><ul><ul><li>are related together to meet a set of objectives </li></ul></ul><ul><ul><li>have a number of defined starts and finishes over an extended period of time </li></ul></ul><ul><ul><li>are implemented by a team </li></ul></ul><ul><li>Project work is the opposite of process work </li></ul><ul><li>Projects change the status quo </li></ul>
    9. 9. What is a successful project ? <ul><li>A project is successful when: </li></ul><ul><ul><li>the project has a satisfied client group </li></ul></ul><ul><ul><li>the project has met it’s deliverable and quality objectives </li></ul></ul><ul><ul><li>the product or system is delivered “on time, on budget” </li></ul></ul><ul><ul><li>the project team has a sense of professional satisfaction and accomplishment </li></ul></ul>
    10. 10. What drives project management ? <ul><li>Each project is different. </li></ul><ul><li>Many factors influence how a project is conducted, and often these factors interact. </li></ul><ul><ul><li>Product functional requirements </li></ul></ul><ul><ul><ul><li>Scope/Size, </li></ul></ul></ul><ul><ul><ul><li>Availability of domain expertise </li></ul></ul></ul><ul><ul><li>Maturity of technology, development tools, and methodologies </li></ul></ul><ul><ul><ul><li>New ?, Well understood ?, Vendor support ? </li></ul></ul></ul><ul><ul><li>Time to Market, </li></ul></ul><ul><ul><li>Team size and experience, </li></ul></ul><ul><ul><li>Relationship with client </li></ul></ul><ul><ul><ul><li>Product Sale vs. Contract, Joint Development ... </li></ul></ul></ul><ul><ul><ul><li>Prototypes, Product Trials, Acceptance arrangements ... </li></ul></ul></ul>
    11. 11. How are projects organized ? <ul><li>In software development: ... designers have patterns, ... programmers have templates, … and Project Managers have Lifecycle Models . </li></ul><ul><ul><li>Mature project managers and development organizations design Lifecycles to best fit the constraints and circumstances of their projects. </li></ul></ul><ul><li>Lifecycle Model types are: </li></ul><ul><ul><li>Waterfall, Incremental, Iterative, Spiral ... </li></ul></ul><ul><ul><li>RAD, Component Assembly ... </li></ul></ul><ul><li>Lifecycle Model Resources: </li></ul><ul><ul><li>EVO (Hewlett-Packard) http://www.hp.com/hpj/aug96/augart4.htm </li></ul></ul><ul><ul><li>MeNtOR SEP (OOPL) http://www.oopl.com.au </li></ul></ul><ul><ul><li>Rational Unified Process http://www.rational.com/products/rup </li></ul></ul>
    12. 14. How is progress measured ? <ul><li>Indicators of progress are: </li></ul><ul><ul><li>the attainment of sub-goals </li></ul></ul><ul><ul><li>the completion of tasks </li></ul></ul><ul><ul><li>the completion of deliverables </li></ul></ul><ul><li>Milestones </li></ul><ul><ul><li>‘Milestones’ are markers, used in a project plan to track progress. </li></ul></ul><ul><ul><ul><li>A project is said to be “running to schedule” if all of the planned milestones have been passed on time </li></ul></ul></ul><ul><ul><ul><li>Schedule ‘slippage’ is quantified by the projected delay in passing milestones. </li></ul></ul></ul><ul><ul><li>Project Reviews are conducted when key project milestones are passed. </li></ul></ul>
    13. 15. Milestone Tracking Chart (45º Chart) Date Charted 1/1/99 1/2/99 1/3/99 1/4/99 1/5/99 Milestone Date 1/1/99 1/2/99 1/3/99 1/4/99 1/5/99              milestone-2 milestone-1 milestone-3
    14. 16. How is progress monitored ? <ul><li>Project Reviews </li></ul><ul><ul><li>Periodic: Weekly / Monthly Progress Reviews </li></ul></ul><ul><ul><li>Milestone: End of Phase or Stage Reviews </li></ul></ul><ul><ul><li>The purpose of a review is to check that a project is on track, and agree actions to keep, or put, it on track. </li></ul></ul><ul><ul><ul><li>If a project is not on track, then steps must be taken to get it back on track. For example: </li></ul></ul></ul><ul><ul><ul><ul><li>change deadlines </li></ul></ul></ul></ul><ul><ul><ul><ul><li>change specifications </li></ul></ul></ul></ul><ul><ul><ul><ul><li>overtly degrade quality </li></ul></ul></ul></ul><ul><ul><ul><ul><li>partition product and add resources </li></ul></ul></ul></ul><ul><ul><ul><ul><li>use faster / better technology </li></ul></ul></ul></ul><ul><ul><ul><ul><li>work harder - in the short term. </li></ul></ul></ul></ul><ul><ul><ul><li>If a project is on track, there will still be issues and risks that need to be identified, and appropriate action plans established. </li></ul></ul></ul>
    15. 17. Additional Resources <ul><li>Pressman: Software Engineering - A Practitioner’s Approach </li></ul><ul><li>Thomsett: The Busy Person’s Project Management Book </li></ul><ul><ul><li>http://www.ozemail.com.au/~thomsett/book/busy_book.htm </li></ul></ul><ul><li>Jarvis & Crandall: Inroads to Software Quality, Prentice Hall, ISBN 0-13-238403-5 </li></ul>
    16. 18. Scope Management <ul><li>How to define the scope of a project </li></ul><ul><li>Project Scoping </li></ul><ul><li>Scoping in contracted projects </li></ul><ul><li>Scoping Example </li></ul>
    17. 19. How to define the scope of a project <ul><li>Project scope is defined by the activities, responsibilities, and deliverables required to complete the project. </li></ul><ul><ul><li>In a product development project, the scope is determined by the product ‘features’ that are declared to be “in”, “out”, and “undecided”. </li></ul></ul><ul><li>A project should proceed only when the “in” and “out” scoping is agreed, and a process for finalizing the “undecided” is agreed. </li></ul><ul><li>Even minor scope changes can have a major impact on a project </li></ul><ul><ul><li>may need to replan after every scope change </li></ul></ul>
    18. 20. Project Scoping <ul><li>Roles </li></ul><ul><ul><li>Product Specification/Project Scope developed at the intersection of the Sales & Marketing and Product Engineering cycles. </li></ul></ul><ul><ul><li>Sales & Marketing gather, filter, and interpret market requirements. </li></ul></ul><ul><ul><li>Product Engineering maintains the specification, and proposes technologies and solutions. </li></ul></ul><ul><li>Processes </li></ul><ul><ul><li>Often adhoc. Can be driven by individual biases, </li></ul></ul><ul><ul><li>QFD: Quality Function Deployment (the House of Quality) </li></ul></ul><ul><ul><ul><li>used by HP, Varian OSI </li></ul></ul></ul><ul><ul><ul><li>http://mijuno.larc.nasa.gov/dfc/qfd.html </li></ul></ul></ul>Sales and Marketing Product Engineering Product Specification
    19. 21. Scoping in contracted projects <ul><li>Contract Scoping </li></ul><ul><ul><li>More emphasis on a negotiated specification, delivery schedule, acceptance criteria, and other contract details. </li></ul></ul><ul><ul><li>Client representative propose a Feature List and provide Domain Expertise. </li></ul></ul><ul><ul><li>Project Team maintains the specification, and proposes technologies and solutions. </li></ul></ul>
    20. 22. Scoping Example <ul><li>Initial Brief (Enhancement Project) </li></ul><ul><ul><li>A major enhancement for a large client-server product is proposed to be released in 8 months. </li></ul></ul><ul><ul><li>The existing product specification details 54 significant “features”. </li></ul></ul><ul><ul><li>A new specification is to be developed in workshops with the client, and detailed using Use Cases. </li></ul></ul><ul><ul><li>The workshops will address three distinct business areas within the overall application domain. </li></ul></ul><ul><li>Project Planning </li></ul><ul><ul><li>The Project Manager develops a plan & schedule for the “Use Case workshops”, and a series of “scoping workshops”. </li></ul></ul><ul><ul><li>The scoping workshops will be conducted through an “Expert Group” drawn from (customer) domain experts, and senior project staff. </li></ul></ul>
    21. 23. Scoping Example - project plan extract Use Case Sets Business Sub-Domain A Final U/C Workshop Draft Feature Assessment Scoping Workshop Œ Finalize Use Cases Business Sub-Domain B Final U/C Workshop Draft Feature Assessment Scoping Workshop  Finalize Use Cases Presentation to U/C Workshop participants Business Sub-Domain C + Sub-Domain D Final U/C Workshop Draft Feature Assessment Scoping Workshop Ž Finalize Use Cases Sep Oct 15/12 8/12 1/12 24/11 17/11 10/11 3/11 27/10 20/10 13/10 6/10 22/9 29/9 15/9 8/9 22/12 1/9 Nov Dec 7/10 30/9 9/10 16/9 2/10 30/9 21/10 13/10 23/10 13/10
    22. 24. Scoping Example - process feature 1 feature 2 ... … feature M consolidate & rank Use Case Sets 1 - 3 Ranked Features ... feature N deployable system development budget <ul><li>Feature Assessment </li></ul><ul><ul><li>1. Complete Use Case drafts. </li></ul></ul><ul><ul><li>2. Identify “new” Features and Issues in Use Cases. </li></ul></ul><ul><ul><li>3. Assess Use Case Features/Issues </li></ul></ul><ul><ul><li>4. Prepare submission to Expert Group with indicative estimates. </li></ul></ul><ul><li>Scope Verification (by Expert Group) </li></ul><ul><ul><li>Meetings: Œ 2/10,  9/10,  23/10 </li></ul></ul><ul><ul><li>5. Resolve Issues / Clarify Requirements </li></ul></ul><ul><ul><li>6. Consolidate and Rank Features </li></ul></ul><ul><ul><li>7. Adjust list order & Identify minimum feature set for a “deployable system”. </li></ul></ul><ul><ul><li>8. Management Review. </li></ul></ul>Feature List & Use Case Finalisation Process Use Case (set 1.) Use Case (set 1.) Product Feature List 54 Features Use Case drafts Set 1: + 27 Features Feature List (scoped)
    23. 25. Scoping Example <ul><li>Workshop Results </li></ul><ul><ul><li>The Use Case and Scoping workshops identified and detailed: </li></ul></ul><ul><ul><ul><li>Business Sub-Domain A: 16 Use Cases, 27 New Features </li></ul></ul></ul><ul><ul><ul><li>Business Sub-Domain B: 15 Use Cases, 9 New Features </li></ul></ul></ul><ul><ul><ul><li>Business Sub-Domain C: 25 Use Cases, No New Features </li></ul></ul></ul>
    24. 26. Scoping Example <ul><li>Budgeting </li></ul><ul><ul><li>Available Resource </li></ul></ul><ul><ul><ul><li>The Project Manager has a budget of 2868 Man Days for the development team (those project staff directly responsible for implementing the system). </li></ul></ul></ul><ul><ul><li>Estimates </li></ul></ul><ul><ul><ul><li>After analyzing the results of the workshops, the development team estimate that: </li></ul></ul></ul><ul><ul><ul><ul><li>1424 Man Days will be required to re-develop system infrastructure. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>1414 Man Days will be required to implement the 36 new features </li></ul></ul></ul></ul><ul><ul><ul><li>The Project Manager estimates that development overheads, finals testing, acceptance and release will require 710 Man Days. </li></ul></ul></ul><ul><ul><li>Discretionary Capacity </li></ul></ul><ul><ul><ul><li>After subtracting “fixed costs” only 734 Man Days are available to implement the requested features. </li></ul></ul></ul>
    25. 27. Scoping Example - process feature 1 feature 2 ... … feature M consolidate & rank Use Case Sets 1 - 3 Ranked Features ... feature N deployable system development budget limit N features = XX man days Basic Functionality & System Infrastructure (1454 man days) Discretionary Capacity (XX Man days) Development Capacity Discretionary Capacity XX < 734 man days Note: 2868 man day budget must be confirmed. <ul><li>Confirm Scope </li></ul><ul><ul><li>9. Confirm scope against Development Capacity. </li></ul></ul><ul><li>Use Case Detailing </li></ul><ul><ul><li>10. Use scoped Feature List to complete detailing of Use Cases. </li></ul></ul><ul><ul><li>11 Confirm cost estimates for all features in scoped system. </li></ul></ul>Feature List & Use Case Finalisation Process Overheads + Release (710 Man days) Use Case (set 1.) Use Case (set 1.) Product Feature List 54 Features Use Case drafts Set 1: + 27 Features Project Feature List (scoped) N Features costed at < XX man days
    26. 28. Scoping Example <ul><li>Scope Finalization </li></ul><ul><ul><li>Project team and Client representatives negotiate on a final set of features that fit the development budget, while meeting the customer’s minimum requirement for a deployable system. </li></ul></ul><ul><ul><ul><li>Each feature assessed for its value to the client cf. it’s incremental development cost. </li></ul></ul></ul><ul><ul><ul><li>A final Feature List proposed to Client Management. </li></ul></ul></ul><ul><li>Conclusion </li></ul><ul><ul><li>Negotiations Failed. </li></ul></ul><ul><ul><ul><li>Unable to derive a Feature List that met the Client’s minimum requirement. </li></ul></ul></ul><ul><ul><li>Never commit to a “fixed price” (in $ or delivery date) before finalizing scope. </li></ul></ul>
    27. 29. Estimation <ul><li>Estimation vs. Guesstimation </li></ul><ul><li>Best / Average / Worst </li></ul><ul><li>Estimation Example </li></ul><ul><li>Productivity </li></ul><ul><li>Scheduling </li></ul><ul><li>Additional Resources </li></ul>
    28. 30. Estimation vs. Guesstimation <ul><li>A guess is a guess … an estimate is an estimate … </li></ul><ul><ul><li>Guess : an unsupported prediction. </li></ul></ul><ul><ul><li>Guesstimate : a guess based on relevant experience, undocumented information, or history. </li></ul></ul><ul><ul><li>Estimate : a prediction based on experience, history or information formally recorded. </li></ul></ul><ul><li>When most people say “I estimate that it will take 6 days”, they are guessing or guesstimating. </li></ul><ul><li>Estimation requires a formal history, including predicted and actual times for tasks, that document the organization's past projects. </li></ul><ul><li>When guesstimating: </li></ul><ul><ul><li>get independent guestimates from multiple sources (project team members) </li></ul></ul><ul><ul><li>document all assumptions </li></ul></ul>
    29. 31. Best/Average/Worst <ul><li>Single figure estimates hide uncertainty </li></ul><ul><li>Three figure estimates capture the range of uncertainty </li></ul><ul><ul><li>best : assume that things go better than expected. (10% confidence) </li></ul></ul><ul><ul><li>average : assume that things go to plan. (50% confidence) </li></ul></ul><ul><ul><li>worst : assume that things go worse than expected. (90% confidence) </li></ul></ul><ul><li>If there is a wide variation between the best and worst: </li></ul><ul><ul><li>allow more time for a more detailed investigation </li></ul></ul><ul><ul><li>divide the task into subtasks and estimate individually </li></ul></ul>
    30. 32. Estimation Example <ul><li>Based on project history </li></ul><ul><li>Effort calibrated against size using a Class Count </li></ul><ul><li>Project Outline </li></ul><ul><ul><li>Enhancement Project </li></ul></ul><ul><ul><li>3-tier Client-Server system (product) </li></ul></ul><ul><ul><li>Size </li></ul></ul><ul><ul><ul><li>The new specification details functionality for 110 Business Domain classes. </li></ul></ul></ul><ul><ul><li>Productivity </li></ul></ul><ul><ul><ul><li>Developer productivity has been measured and recorded for previous releases of this product. </li></ul></ul></ul><ul><ul><ul><li>Productivity rates are available for new code development, code modification, and code reuse. </li></ul></ul></ul>
    31. 33. Estimation Example <ul><li>Business Domain Model (BDM) </li></ul><ul><ul><li>Classes Count: 110 </li></ul></ul><ul><li>Data & Presentation Layers </li></ul><ul><ul><li>Assume 2.6 DPO classes per Business Domain class </li></ul></ul><ul><ul><li>Productivity Rates (Coding): </li></ul></ul><ul><ul><ul><li>New: 04 Classes/person month </li></ul></ul></ul><ul><ul><ul><li>Modify: 06 Classes/person month </li></ul></ul></ul><ul><ul><ul><li>Re-Use: 10 Classes/person month </li></ul></ul></ul><ul><li>User Interface (GUI) Layer </li></ul><ul><ul><li>Assume 1 GUI class per Business Domain class </li></ul></ul><ul><ul><li>Productivity Rates (Coding): </li></ul></ul><ul><ul><ul><li>New: 04 Classes/person month </li></ul></ul></ul><ul><ul><ul><li>Modify: 06 Classes/person month </li></ul></ul></ul><ul><ul><ul><li>Re-Use: 10 Classes/person month </li></ul></ul></ul>
    32. 34. Estimation Example <ul><li>Resource Effort / Availability Estimates </li></ul>
    33. 35. Productivity <ul><li>Variation between individuals </li></ul><ul><ul><li>A number of studies indicate that there is an order of magnitude difference in productivity between the strongest and weakest team members. </li></ul></ul><ul><ul><ul><li>Researchers have obtained the following results for defect free, non-commented, 3GL code: </li></ul></ul></ul><ul><ul><ul><li>Worst Best Case study 1 4 Barry Boehm 1 10 Capers Jones 1 16 Sackman 1 30 Putnam & Myers </li></ul></ul></ul><ul><ul><li>Assumptions about who is to do the work and under what conditions must be made clear when estimating and not lost when developing a team schedule. </li></ul></ul>
    34. 36. Scheduling <ul><li>Many other tasks need to be performed in the working environment. </li></ul><ul><li>When developing a schedule, a Project Manager must take into account time and effort expended for: </li></ul><ul><ul><li>holidays and sick lease </li></ul></ul><ul><ul><li>training </li></ul></ul><ul><ul><li>reviewing other people’s work including estimates, design, code, documentation ... </li></ul></ul><ul><ul><li>progress tracking & reporting </li></ul></ul><ul><ul><li>inter & intra-team interaction, and other team and management communication. </li></ul></ul><ul><li>Elapsed time is 2 - 3 times the estimated time </li></ul>
    35. 37. Additional Resources <ul><li>Productivity benchmark data </li></ul><ul><ul><li>International Software Benchmarking Standards Group (ISBSG) </li></ul></ul><ul><ul><ul><li>http://www.isbsg.org.au </li></ul></ul></ul><ul><ul><li>OSA </li></ul></ul><ul><ul><ul><li>The sustained average coding rate at OSA is 40 lines per engineer per day </li></ul></ul></ul><ul><li>Tools </li></ul><ul><ul><li>SPR KnowledgePLAN, SPR CHECKPOINT </li></ul></ul><ul><ul><ul><li>http://www.spr.com/html/products.htm </li></ul></ul></ul>
    36. 38. Risk Management <ul><li>Planning for risk management </li></ul><ul><li>Risk Management Example </li></ul><ul><li>Additional Resources </li></ul>
    37. 39. Planning for risk management <ul><li>Project Plan </li></ul><ul><ul><li>Seek early identification of project risks, and the development of a risk management plan with the project plan. </li></ul></ul><ul><ul><li>The table of project risks from the project plan should be regularly updated and reviewed at Project Reviews. </li></ul></ul><ul><li>Risk Table </li></ul><ul><ul><li>For each identified risk, should include: </li></ul></ul><ul><ul><ul><li>the current ranking </li></ul></ul></ul><ul><ul><ul><li>the probability of the risk eventuating </li></ul></ul></ul><ul><ul><ul><li>the severity of the risk </li></ul></ul></ul><ul><ul><ul><li>consequences if the risk eventuates </li></ul></ul></ul><ul><ul><ul><li>a mitigation strategy </li></ul></ul></ul><ul><ul><ul><li>a contingency plan </li></ul></ul></ul>
    38. 40. Risk Management Example
    39. 41. Risk Management Example
    40. 42. Risk Management Example <ul><li>Risk Analysis & Planning </li></ul><ul><ul><li>1. Feedback from Widget 1.0 trials is not received in time to be incorporated in the Widget 2.0 product. </li></ul></ul><ul><ul><ul><li>Probability : High Severity : High </li></ul></ul></ul><ul><ul><ul><li>Consequence : No prior field experience from Widget 1.0 reduces ability to avoid acceptance problems. </li></ul></ul></ul><ul><ul><ul><li>Mitigation Strategy : Make results from Incremental Releases available to customers for preview. </li></ul></ul></ul><ul><ul><li>2. Customer doesn’t meet delivery milestones for ‘external dependencies’. </li></ul></ul><ul><ul><ul><li>Probability : Medium Severity : High </li></ul></ul></ul><ul><ul><ul><li>Consequence : Schedule slippage. </li></ul></ul></ul><ul><ul><ul><li>Mitigation Strategy : a) Regular progress reviews in Project Management forums. b) Escalate to customer sponsor . </li></ul></ul></ul><ul><ul><ul><li>Contingency : No delivery schedule commitments. </li></ul></ul></ul>
    41. 43. Risk Management Example <ul><li>Risk Analysis & Planning </li></ul><ul><ul><li>3. Key resources are diverted to Widget 1.0 support during Widgets 2.0 development. </li></ul></ul><ul><ul><li>4. Insufficient resources and duration planned for Acceptance Testing </li></ul></ul><ul><ul><li>5. New or immature business practices (eg. Red Widget Design) in Customer lead to change requests in Construction or Acceptance phases. </li></ul></ul><ul><ul><ul><li>Probability : Medium Severity : Medium </li></ul></ul></ul><ul><ul><ul><li>Consequence : a) Identification of new features after specification sign-off. b) Extra incremental releases delayed final release to Customer acceptance. </li></ul></ul></ul><ul><ul><ul><li>Mitigation Strategy : a) Early analysis of potential for process changes. b) Strict observance to Change Management processes. </li></ul></ul></ul><ul><ul><ul><li>Contingency : Schedule implementation of change requests after acceptance of baseline Widget 2.0 system. </li></ul></ul></ul><ul><ul><li>6. Support for Widget 1.0 sales diverts resources from new product development. </li></ul></ul>
    42. 44. Risk Management Example <ul><li>Risk Analysis & Planning </li></ul><ul><ul><li>7. Integration risk with technologies new to ACME Widgets being introduced in Widget 2.0 architecture (eg. CORBA). </li></ul></ul><ul><ul><ul><li>Probability : High Severity : Low </li></ul></ul></ul><ul><ul><ul><li>Consequence : a) Schedule Slippage. b) Non-optimal design decisions.. </li></ul></ul></ul><ul><ul><ul><li>Mitigation Strategy : Prototype in Nov - Dec. </li></ul></ul></ul><ul><ul><ul><li>Contingency : a) Look at alternate technologies. b) ‘Buy in’ expertise by hire experts in technologies. </li></ul></ul></ul>
    43. 45. Risk Management Example <ul><li>Risk Analysis & Planning (managed) </li></ul><ul><ul><li>1. Too much parallelism in specification and modeling tasks (inefficient and faulty information flow between modeling teams). </li></ul></ul><ul><ul><li>2. Divergence in Wingdings and Widgets specifications. ACME Widgets and Customer teams disagree on requirement specifications. </li></ul></ul><ul><ul><ul><li>Probability : Low Severity : High </li></ul></ul></ul><ul><ul><ul><li>Consequence : Delay in achieving sign-off for specifications. </li></ul></ul></ul><ul><ul><ul><li>Mitigation Strategy : a) Re-focus on project goals. b) Regular Use Case team review of draft specifications. c) Scope resolution through the Expert Group. </li></ul></ul></ul><ul><ul><ul><li>Contingency : Escalate to as necessary to the Widgets Expert Group, Widgets Management Group, and Governance Board. </li></ul></ul></ul><ul><ul><li>3. Can’t identify a new (viable) Architecture. </li></ul></ul><ul><ul><li>4. ACME Widgets and Customer disagree on Feature Scope </li></ul></ul>
    44. 46. Additional Resources <ul><li>Project Risk Assessment Form </li></ul><ul><ul><li>http://www.ozemail.com.au/~thomsett/form/Default.htm </li></ul></ul>
    45. 47. People Management <ul><li>Manager’s Role </li></ul><ul><ul><li>ensure that a team meets its set objectives </li></ul></ul><ul><ul><li>ensure that all team members have an opportunity to contribute </li></ul></ul><ul><ul><li>help team members to achieve the goals that they set themselves </li></ul></ul><ul><li>Remember </li></ul><ul><ul><li>Management decisions effect people </li></ul></ul><ul><ul><li>Team members are not just resources: </li></ul></ul><ul><ul><ul><li>they are individuals with their own ambitions and interests </li></ul></ul></ul><ul><ul><ul><li>they MUST be treated with respect. </li></ul></ul></ul><ul><ul><li>Above all … have fun ! </li></ul></ul>
    46. 48. Questions