quan ly du an phan mem

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.95 MB, 180 trang )

(1)DANANG UNIVERSITY OF TECHNOLOGY. FACULTY OF INFORMATION TECHNOLOGY. SOFTWARE PROJECT MANAGEMENT VO TRUNG HUNG, Ph.D. Associate Professor Tel.: (84)511- 3841292, (84)511- 3847373, Fax.: (84)511- 3842771 E-mail: , Principles of Project Management. 1. References . Rapid Development, Steve McConnell Information Technology Project Management, Kathy Schwalbe “Quality Software Project Management”, D. Shafer “Software Project Survival Guide”, Steve McConnell “Peopleware”, T. DeMarco and T. Lister. Principles of Project Management. 2. SOFTWARE PROJECT MANAGEMENT Session 1: Introduction, Fundamentals, Classic Mistakes. Principles of Project Management. 3. •1.

(2) Basics. . Essential elements of software project management Practical, rapid development focus Real-world case studies. . Highly interactive. . . . And other examples like job interviews. Principles of Project Management. 4. Job Fundamentals . Skills required PM Positions and roles The process. Principles of Project Management. 5. Project Management Skills . Leadership Communications Problem Solving Negotiating Influencing the Organization Mentoring Process and technical expertise. Principles of Project Management. 6. •2.

(3) Project Manager Positions . Project Administrator / Coordinator Assistant Project Manager Project Manager / Program Manager Executive Program Manager V.P. Program Development. Principles of Project Management. 7. Software Project Management Management Project Management. Software Project Management. Principles of Project Management. 8. Project Management . What’s a project? PMI definition . A project is a temporary endeavor undertaken to create a unique product or service. . Progressively elaborated. . A project manager. . . With repetitive elements Analogy: conductor, coach, captain. Principles of Project Management. 9. •3.

(4) Project vs. Program Management . What’s a ‘program’? Mostly differences of scale Often a number of related projects Longer than projects Definitions vary Ex: Program Manager for MS Word. Principles of Project Management. 10. Interactions / Stakeholders . As a PM, who do you interact with? Project Stakeholders . Project sponsor Executives Team Customers Contractors Functional managers. Principles of Project Management. 11. PM Tools: Software . Low-end . . Mid-market . . Basic features, tasks management, charting MS Excel, Milestones Simplicity Handle larger projects, multiple projects, analysis tools MS Project (approx. 50% of market). High-end . Very large projects, specialized needs, enterprise AMS Realtime Primavera Project Manager. Principles of Project Management. 12. •4.

(5) Tools: Gantt Chart. Principles of Project Management. 13. Tools: Network Diagram. Principles of Project Management. 14. PMI’s 9 Knowledge Areas . Project integration management . Scope Time Cost Quality Human resource Communications Risk Procurement. Principles of Project Management. 15. •5.

(6) First Principles . One size does not fit all Patterns and Anti-Patterns Spectrums . Project types Sizes Formality and rigor. Principles of Project Management. 16. Why Rapid Development . Faster delivery Reduced risk Increased visibility to customer Don’t forsake quality. Principles of Project Management. 17. Strategy . Classic Mistake Avoidance Development Fundamentals Risk Management Schedule-Oriented Practices. Principles of Project Management. 18. •6.

(7) Four Project Dimensions . People Process Product Technology. Principles of Project Management. 19. Trade-off Triangle . Fast, cheap, good. Choose two.. Principles of Project Management. 20. Trade-off Triangle . Know which of these are fixed & variable for every project. Principles of Project Management. 21. •7.

(8) People . “It’s always a people problem” Gerald Weinberg, “The. . Developer productivity: 10-to-1 range Improvements:. Secrets of Consulting”. . . Team selection Team organization Motivation. Principles of Project Management. 22. People 2 . Other success factors . Matching people to tasks Career development Balance: individual and team Clear communication. Principles of Project Management. 23. Process . Is process stifling? 2 Types: Management & Technical Development fundamentals Quality assurance Risk management Lifecycle planning Avoid abuse by neglect. Principles of Project Management. 24. •8.

(9) Process 2 . Customer orientation Process maturity improvement Rework avoidance. Principles of Project Management. 25. Product . The “tangible” dimension Product size management Product characteristics and requirements Feature creep management. Principles of Project Management. 26. Technology . Often the least important dimension Language and tool selection Value and cost of reuse. Principles of Project Management. 27. •9.

(10) Planning . Determine requirements Determine resources Select lifecycle model Determine product features strategy. Principles of Project Management. 28. Tracking . Cost, effort, schedule Planned vs. Actual How to handle when things go off plan?. Principles of Project Management. 29. Measurements . To date and projected . . Cost Schedule Effort Product features. Alternatives . Earned value analysis Defect rates Productivity (ex: SLOC) Complexity (ex: function points). Principles of Project Management. 30. •10.

(11) Technical Fundamentals . Requirements Analysis Design Construction Quality Assurance Deployment. Principles of Project Management. 31. Project Phases . . . All projects are divided into phases All phases together are known as the Project Life Cycle Each phase is marked by completion of Deliverables Identify the primary software project phases. Principles of Project Management. 32. Lifecycle Relationships. Principles of Project Management. 33. •11.

(12) Seven Core Project Phases. 34. Principles of Project Management. Project Phases A.K.A.. 35. Principles of Project Management. Phases Variation Concept Exploration System Exploration. Requirements. Design. Implementation. Installation. Operations and Support. Maintenance. Retirement. Principles of Project Management. 36. •12.

(13) 36 Classic Mistakes . Types . People-Related Process-Related Product-Related Technology-Related. Principles of Project Management. 37. People-Related Mistakes Part 1 . Undermined motivation Weak personnel . . Weak vs. Junior. Uncontrolled problem employees Heroics Adding people to a late project. Principles of Project Management. 38. People-Related Mistakes Part 2 . Noisy, crowded offices Customer-Developer friction Unrealistic expectations Politics over substance Wishful thinking. Principles of Project Management. 39. •13.

(14) People-Related Mistakes Part 3 . Lack of effective project sponsorship Lack of stakeholder buy-in Lack of user input. Principles of Project Management. 40. Process-Related Mistakes Part 1 . Optimistic schedules Insufficient risk management Contractor failure Insufficient planning Abandonment of plan under pressure. Principles of Project Management. 41. Process-Related Mistakes Part 2 . Wasted time during fuzzy front end Shortchanged upstream activities Inadequate design Shortchanged quality assurance. Principles of Project Management. 42. •14.

(15) Process-Related Mistakes Part 3 . Insufficient management controls Frequent convergence Omitting necessary tasks from estimates Planning to catch-up later Code-like-hell programming. Principles of Project Management. 43. Product-Related Mistakes . Requirements gold-plating. . Feature creep Developer gold-plating. . . . . Gilding the lily. Beware the pet project. Push-me, pull-me negotiation Research-oriented development. Principles of Project Management. 44. Technology-Related Mistakes . Silver-bullet syndrome Overestimated savings from new tools and methods . . Fad warning. Switching tools in mid-project Lack of automated source-code control. Principles of Project Management. 45. •15.

(16) SOFTWARE PROJECT MANAGEMENT Session 2: Processes, Organization. Principles of Project Management. 46. Content . PMI Fundamentals Project Organization Project Selection Project Portfolio Management Procurement Management Statement of Work (SOW) Project Charter. Principles of Project Management. 47. Why Do Projects Succeed? . How to identify a projects success potential . What metrics could you look at? . Project size Project duration Project team size. Principles of Project Management. 48. •16.

(17) Why Do Projects Succeed? . Executive support User involvement Experience project manager Clear business objectives Minimized scope Standard software infrastructure Firm basic requirements Formal methodology Reliable estimates Standish Group “CHAOS 2001: A Recipe for Success”. Principles of Project Management. 49. Why Executive Support? . Top management can help to: . . . Secure adequate resources Get approval for unique project needs in a timely manner Receive cooperation from people throughout the organization Provide leadership guidance. Principles of Project Management. 50. 15 PM Job Functions . . . . Define scope of project Identify stakeholders, decision-makers, and escalation procedures Develop detailed task list (work breakdown structures) Estimate time requirements Develop initial project management flow chart Identify required resources and budget. . . . . . Evaluate project requirements Identify and evaluate risks Prepare contingency plan Identify interdependencies Identify and track critical milestones Participate in project phase review Secure needed resources Manage the change control process Report project status. *Northwest Center for Emerging Technologies, "Building a Foundation for Tomorrow: Skills Standards for Information Technology,"Belleview, WA, 1999. Principles of Project Management. 51. •17.

(18) PMI Framework. Source: Project Management Institute. 52. Principles of Project Management. The 5 PMI Process Groups. . 1. Initiating 2. Planning 3. Executing 4. Controlling 5. Closing Note: these can be repeated for each phase. . Each process is described by:. . . Inputs Tools & Techniques Outputs. 53. Principles of Project Management. PMI Process Groups. Source: Project Management Institute. Principles of Project Management. 54. •18.

(19) PMI: Process Links. 55. Principles of Project Management. PMI Phase Interactions Design Phase Initiating Processes. Planning Processes. Controlling Processes. Implementation Phase Initiating Processes. Executing Processes. Planning Processes. Controlling Processes. Closing Processes. Executing Processes. Closing Processes. Principles of Project Management. 56. PMI: Initiating Process . Inputs . . Product Description Strategic plan Project Selection Criteria Historical Information. Outputs . . Project charter Project Manager assigned Constraints Assumptions. Principles of Project Management. 57. •19.

(20) PMI: Planning Process Devising and maintaining a workable scheme to accomplish the business need that the project was undertaken to address . . Scope Planning Scope Definition Activity Definition Activity Sequencing Activity Duration Estimating Resource Planning Cost Estimating Cost Budgeting. . Risk Planning Schedule Development Quality Planning Communications Planning Organization Planning Staff Acquisition Procurement Planning Project Plan Development. Principles of Project Management. 58. PMI: Executing Process Coordinating people and other resources to carry out the plan . Project Plan Execution Scope Verification Quality Assurance Team Development. . . Information Distribution Solicitation Source Selection Contract Administration. Principles of Project Management. 59. PMI: Controlling Process Ensuring that project objectives are met by monitoring and measuring progress and taking corrective measures when necessary. . . Overall Change Control Scope Change Control Schedule Control Cost Control Quality Control. . . Performance Reporting Risk Response Control. Principles of Project Management. 60. •20.

(21) PMI: Closing Process Formalizing acceptance of the project or phase and bringing it to an orderly end . Administrative Closure Contract Close-out. Principles of Project Management. 61. PMI Knowledge Areas. Principles of Project Management. 62. Importance of Phases . Define your management review points . “Phase exits” or “kill points” Ensure continued alignment with goals Form of Validation & Verification (V&V) . More later in term. Principles of Project Management. 63. •21.

(22) Understanding Organizations Structural frame: Focuses on roles and responsibilities, coordination and control. Organization charts help define this frame.. Human resources frame: Focuses on providing harmony between needs of the organization and needs of people.. Political frame: Assumes organizations are coalitions composed of varied individuals and interest groups. Conflict and power are key issues.. Symbolic frame: Focuses on symbols and meanings related to events. Culture is important.. Principles of Project Management. 64. Organizational Structures . Functional . . Project . . Engineering, Marketing, Design, etc P&L from production Project A, Project B Income from projects PM has P&L responsibility. Matrix . Functional and Project based Program Mgmt. Model Shorter cycles, need for rapid development process Principles of Project Management. 65. Functional Organization. • Cons. • Pros – Clear definition of authority – Eliminates duplication – Encourages specialization – Clear career paths. – “Walls”: can lack customer orientation – “Silos” create longer decisions cycles – Conflicts across functional areas – Project leaders have little power. Principles of Project Management. 66. •22.

(23) Project Organization. • Pros. • Cons. – Unity of command – Effective inter-project communication. – Duplication of facilities – Career path. • Examples: defense avionics, construction Principles of Project Management. 67. Matrix Organization. • Pros. • Cons. – Project integration across functional lines –Efficient use of resources –Retains functional teams. – Two bosses for personnel – Complexity – Resource & priority conflicts. Principles of Project Management. 68. Matrix Forms . Weak, Strong, Balanced Degree of relative power Weak: functional-centric Strong: project-centric. Principles of Project Management. 69. •23.

(24) IT Planning Process. Principles of Project Management. 70. Methods for Selecting Projects . There are usually (always?) more projects than available time and resources to implement them . . Therefore: It is important to follow a logical process for selecting IT projects to work on. Methods include . Focusing on broad needs Categorizing projects Financial methods Weighted scoring models . (last 2 models covered later in term). Principles of Project Management. 71. Broad Organizational Needs . It is often difficult to provide strong justification for many IT projects, but everyone agrees they have a high value . . “It is better to measure gold roughly than to count pennies precisely”. Three important criteria for projects: . There is a need for the project There are funds available There’s a strong will to make the project succeed. Principles of Project Management. 72. •24.

(25) Categorizing IT Projects . . One categorization: whether project addresses a problem an opportunity a directive Another: how long it will take & when it is needed Another: overall priority of the project. Principles of Project Management. 73. Project Portfolio Management . . Portfolio: a group of IT project under a coordinated management structure Different ‘portfolio models’ are available: . Economic return model. . Cost-benefit model. . Market research model. . . . . . NPV, IRR, ROI Can include less tangible factors For new products. Each considers relative value and resource/budget interactions More details in Session 4 Principles of Project Management. 74. Portfolio Management . A 5 level approach (from CIO magazine) 1. Create a Portfolio Database . . Project names & descriptions Estimated costs, timeframes, staffing. Benefits . Spotting redundancies Communication across orgs & teams Holistic view. Principles of Project Management. 75. •25.

(26) Portfolio Management . 2. Prioritize Projects . Try quantifiable rankings . . . Risk and return. Still subjectivity and disagreements. 3. Divide into budgets based on type . To align with business needs Ex: utilities (‘keeping the lights on’), incremental upgrades, strategic investments. Principles of Project Management. 76. Portfolio Management . 4. Automate the repository . . Input of new data (new projects) Automated tracking (PM software integration). 5. Apply modern portfolio theory . Ex: www.modporttheory.com More advanced than most of us need. Principles of Project Management. 77. Procurement Management . Procurement means acquiring goods and/or services from an outside source. . Know how your ADIS project fits-into this model. . . a.k.a. purchasing or outsourcing. Are you building “in-house”? “for hire”? . . Thus are you the ‘outside source’?. As a startup? (thus in-house but as basis for the business itself). Principles of Project Management. 78. •26.

(27) Why Outsource? . . To reduce both fixed and recurrent costs To allow the client organization to focus on its core business To access skills and technologies To provide flexibility To increase accountability. Principles of Project Management. 79. Procurement Management . . . . . . Procurement planning: determining what to procure and when Solicitation planning: documenting product requirements and identifying potential sources Solicitation: obtaining quotations, bids, offers, or proposals as appropriate Source selection: choosing from among potential vendors Contract administration: managing the relationship with the vendor Contract close-out: completion and settlement of the contract Principles of Project Management. 80. Project Procurement Management. Principles of Project Management. 81. •27.

(28) Procurement Tools & Techniques . Make-or-buy analysis (build vs. buy) . . Determining whether a particular product or service should be made or performed inside the organization or purchased from someone else. Often involves financial analysis. Experts . Both internal and external, can provide valuable inputs in procurement decisions. Principles of Project Management. 82. Types of Contracts . . . . Fixed price or lump sum: involve a fixed total price for a well-defined product or service Cost reimbursable: involve payment to the seller for direct and indirect costs Time and material contracts: hybrid of both fixed price and cost reimbursable, often used by consultants Unit price contracts: require the buyer to pay the seller a predetermined amount per unit of service. Principles of Project Management. 83. Cost Reimbursable Contracts . Cost plus incentive fee (CPIF) . . Cost plus fixed fee (CPFF) . . Buyer pays seller for allowable performance costs plus a predetermined fee and an incentive bonus Buyer pays seller for allowable performance costs plus a fixed fee payment usually based on a percentage of estimated costs. Cost plus percentage of costs (CPPC) . Buyer pays seller for allowable performance costs plus a predetermined percentage based on total costs. Principles of Project Management. 84. •28.

(29) Contract Types Versus Risk. Principles of Project Management. 85. Statement of Work (SOW) . . A description of the work required for the project Sets the “boundary conditions” SOW vs. CSOW (Contract SOW) . . Latter: uses legal language as part of a competitive bidding scenario. Can be used in the final contract – be careful, be specific, be clear. Principles of Project Management. 86. SOW Continued . Typically done after approval (after “Go”) Can be multiple versions . 1. List of deliverables for an RFP 2. More detailed within final RFP 3. Binding version from contract. Principles of Project Management. 87. •29.

(30) SOW Template I.. Scope of Work: Describe the work to be done to detail. Specify the hardware and software involved and the exact nature of the work.. II.. Location of Work: Describe where the work must be performed. Specify the location of hardware and software and where the people must perform the work. III.. Period of Performance: Specify when the work is expected to start and end, working hours, number of hours that can be billed per week, where the work must be performed, and related schedule information. Optional “Compensation” section.. IV.. Deliverables Schedule: List specific deliverables, describe them in detail, and specify when they are due.. V.. Applicable Standards: Specify any company or industry-specific standards that are relevant to performing the work. Often an Assumptions section as well.. VI.. Acceptance Criteria: Describe how the buyer organization will determine if the work is acceptable.. VII.. Special Requirements: Specify any special requirements such as hardware or software certifications, minimum degree or experience level of personnel, travel requirements, documentation, testing, support, and so on. Principles of Project Management. 88. Project Charter . A high-level project description:. . Often precedes SOW Often 2-4 pages (can be longer). . . Business need, product, assumptions. Principles of Project Management. 89. Project Charter . Typical outline . Overview . . Business need Objectives Method or approach. General scope of work Rough schedule & budget Roles & responsibilities Assumptions. Principles of Project Management. 90. •30.

(31) Charter Examples . Assumptions . We will reuse the architecture from the previous ordering system The system will be built using an ASP model Customer will provide necessary business experts as needed during development System will run on existing networking and computer resources Customer will sign-off on interim deliverables within one week of each delivery All import data will be available in XML format This will be a web-based application Our in-house development team will do the work The rendering engine will be licensed from a third party We will partner with an overseas development firm to create the security systems. Principles of Project Management. 91. Charter Examples . Primary Stakeholders (following examples are not of one set) . Sponsor: VP of Marketing Sponsor: Five Star Brokerage Consortium Sponsor: Bill Smith, CEO Users: Call center operators Users: Our partner banks Customers: Attorneys from small-to-mid size law firms Customers: Males 30-45 earning $75K or more. Principles of Project Management. 92. Charter Examples . Deliverables . Retail Web Site . . Full catalog Shopping-cart system Search engine User registration system. Trading System . Equities order entry system Portfolio management Order execution engine Integration with X legacy systems Security infrastructure. Principles of Project Management. 93. •31.

(32) Charter Examples . Deliverables . Corporate Application . Network and hardware Web-based HR portal Connectivity for VPN “Asset Management Viewport” application Customized Reporting Engine . . Allowing users to Perseus data mart Delivery into HTML and Excel. User manuals. Principles of Project Management. 94. Charter Examples . Out of Scope . . News feeds Dynamic pricing Jazzy color picker Auction engine EDI support Legacy integration Help system. Schedule . We anticipate an overall 12-14 month development timeframe The project is expected to start in Q1 2003 and complete in Q3 2004 The initial release is expect within 10 months with the follow-on delivery within 4-6 months Principles of Project Management. 95. SOFTWARE PROJECT MANAGEMENT Session 3: Planning. Principles of Project Management. 96. •32.

(33) Project Phases. 97. Principles of Project Management. Time Allocation by Phase . Remember the 40-20-40 Rule . Specification-Implementation-Test Planning. Code & Unit Test. Integration & Test. Commercial DP. 25%. 40%. 35%. Internet Systems. 55%. 15%. 30%. Real-time Systems. 35%. 25%. 40%. Defense Systems. 40%. 20%. 40% Bennatan, E.M, “On Time Within Budget”. 98. Principles of Project Management. Time Allocation by Phase Activity. Small Project (2.5K LOC). Large Project (500K LOC). Analysis. 10%. 30%. Design. 20%. 20%. Code. 25%. 10%. Unit Test. 20%. 5%. Integration. 15%. 20%. System test. 10%. 15% McConnell, Steve, “Rapid Development”. Principles of Project Management. 99. •33.

(34) Activities by % of Total Effort. NASA’s “Manager’s Handbook for Software Development”. Principles of Project Management. 100. Potential Deliverables by Phase. Principles of Project Management. 101. Concept Exploration . The “Why” phase Not a “mandatory formal” phase. . Collecting project ideas. . Project Justification. . . . . . Sometimes called the “pre-project” phase Then the “funneling” process ROI Cost-benefit analysis Project Portfolio Matrix. Initial planning and estimates. Principles of Project Management. 102. •34.

(35) Concept Exploration . Possibly includes Procurement Management: . RFP Process Vendor selection Contract management. . Gathering the initial team. . Identify the project sponsor. . Potential Phase Outputs:. . . . Including PM if not already on-board Primary contact for approval and decision making Concept Document, Product Description, Proposal, SOW, Project Charter. Principles of Project Management. 103. Concept Exploration . Characteristics & Issues . Lack of full commitment and leadership Some frustrations: . . Management only getting rough estimates from development Development not getting enough specifics from customer Finding a balanced team. Budget sign-off may be your 1st major task Achieved via: . Good concept document or equivalent Demonstration of clear need (justification) Initial estimates. Principles of Project Management. 104. Requirements . The “What” phase Inputs: SOW, Proposal Outputs: . Requirements Document (RD) . . a.k.a.Requirements Specification Document (RSD) Software Requirements Specification (SRS). 1st Project Baseline Software Project Management Plan (SPMP) Requirements Approval & Sign-Off . Your most difficult task in this phase. Principles of Project Management. 105. •35.

(36) Requirements . Perhaps most important & difficult phase Shortchanging it is a ‘classic mistake’ Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR) . For Sponsor and/or customer(s) approval. Principles of Project Management. 106. Why are Requirements so Important?. Principles of Project Management. 107. Requirements . Characteristics & Issues . Conflict of interest: developer vs. customer Potential tug-of-war: . . . Disagreement on Features & Estimates Especially in fixed-price contracts. Frequent requirements changes Achieving sign-off. Project planning occurs in parallel. Principles of Project Management. 108. •36.

(37) Requirements . Requirements are capabilities and condition to which the system – more broadly, the project – must conform. Principles of Project Management. 109. 2 Types of Requirements . Functional (behavioral). . Non-functional (a.k.a. “technical”) (everything else). . . . . . . Features and capabilities Usability Human factors, help, documentation Reliability Failure rates, recoverability, availability Performance Response times, throughput, resource usage Supportability Maintainability, internationalization Operations: systems management, installation Interface: integration with other systems Other: legal, packaging, hardware Principles of Project Management. 110. Requirements . Other ways of categorizing . Go-Ahead vs. Catch-up . . . . Backward: address issues with previous version Forward: Anticipating future needs of customers. Must be prioritized . . Relative to competition. Backward-looking vs. Forward-looking. Must-have Should-have Could-have (Nice-to-have: NTH). Must be approved. Principles of Project Management. 111. •37.

(38) Early Phase Meetings . Project Kickoff Meeting Project Brainstorming Meeting . . Clarify goals, scope, assumptions Refine estimates. WBS Meeting. Principles of Project Management. 112. Analysis & Design . The “How” Phases Inputs: Requirements Document Outputs: . Functional Specification Detailed Design Document User Interface Specification Data Model Prototype (can also be done with requirements) Updated Plan (improved estimates; new baseline). Principles of Project Management. 113. Analysis & Design . a.k.a. Top-level design & detailed design Continues process from RD Ends with Critical Design Review (CDR) . Formal sign-off Can also include earlier Preliminary Design Review (PDR) for high level design. Principles of Project Management. 114. •38.

(39) Analysis & Design . Characteristics & Issues . . Enthusiasm via momentum Team structure and assignments finalized Delays due to requirements changes, new information or late ideas Issues around personnel responsibilities Unfeasible requirements (technical complexity) Resource Issues . Including inter-project contention. Principles of Project Management. 115. Development . The “Do It” phase Coding & Unit testing Often overlaps Design & Integration phases . To shorten the overall schedule PM needs to coordinate this. Principles of Project Management. 116. Development . Other concurrent activities . Design completion Integration begins Unit testing of individual components Test bed setup (environment and tools) Project plans updated Scope and Risk Management conducted. Principles of Project Management. 117. •39.

(40) Development . Characteristics . . Pressure increases Staffing at highest levels Often a “heads-down” operation. Issues . Last-minute changes Team coordination (esp. in large projects) Communication overhead Management of sub-contractors. Principles of Project Management. 118. Integration & Test . Evolves from Dev. Phase Often done as 2 parallel phases . . Partial integration & initial test. Starts with integration of modules An initial, incomplete version constructed Progressively add more components. Principles of Project Management. 119. Integration & Test . Integration primarily a programmer task Test primarily a QA team task Integration: . . Top-down: Core functionality first, empty shells for incomplete routines (stubs) Bottom up: gradually bind low-level modules Prefer top-down generally. Principles of Project Management. 120. •40.

(41) Integration & Test . Tests . . Integration testing Black & White-box testing Load & Stress testing Alpha & Beta testing Acceptance testing. Other activities . Final budgeting; risk mgmt.; training; installation preparation; team reduced. Principles of Project Management. 121. Integration & Test . Characteristics & Issues . Increased pressure Overtime Customer conflicts over features Frustration over last-minute failures Budget overruns Motivation problems (such as burnout) Difficulty in customer acceptance . Esp. true for fixed-price contracts. Principles of Project Management. 122. Deployment & Maintenance . Installation depends on system type. . Migration strategy How to get customers up on the system. . . . . Web-based, CD-ROM, in-house, etc.. Parallel operation. Deployment typically in your project plan, maintenance not. Principles of Project Management. 123. •41.

(42) Deployment & Maintenance . Maintenance . . Fix defects Add new features Improve performance. Configuration control is very important here Documents need to be maintained also Sometimes a single team maintains multiple products. Principles of Project Management. 124. Deployment & Maintenance . Characteristics & Issues . Lack of enthusiasm Pressure for quick fixes Insufficient budget Too many patches Personnel turnover Regression testing is critical . Preferably through automated tools. Principles of Project Management. 125. Lifecycle Planning . a.k.a. Lifecycle Management or SDLC Greatly influences your chance of success Not choosing a lifecycle is a bad option Three primary lifecycle model components . Phases and their order Intermediate products of each phase Reviews used in each phase. Principles of Project Management. 126. •42.

(43) Lifecycle Planning . . Different projects require different approaches You do not need to know all models by name You should know how that if given a certain scenario what sort of SDLC would be appropriate There are more than covered here A lifecycle is not a design, modeling or diagramming technique . The same technique (UML, DFD, etc) can be used with multiple lifecycles. Principles of Project Management. 127. Pure Waterfall . The “granddaddy” of models Linear sequence of phases . . “Pure” model: no phases overlap. Document driven All planning done up-front. Principles of Project Management. 128. Waterfall Risk . Why does the waterfall model “invite risk”? Integration and testing occur at the end . Often anyone’s 1st chance to “see” the program. Principles of Project Management. 129. •43.

(44) Pure Waterfall . Works well for projects with . Stable product definition Well-understood technologies Quality constraints stronger than cost & schedule Technically weak staff . Provides structure Good for overseas projects. Principles of Project Management. 130. Pure Waterfall . Disadvantages . Not flexible . . Rigid march from start->finish. Difficult to fully define requirements up front Can produce excessive documentation Few visible signs of progress until the end. Principles of Project Management. 131. Code-and-Fix . “Code-like-Hell” Specification (maybe), Code (yes), Release (maybe) Advantages . . Disadvantages . . No overhead Requires little expertise No process, quality control, etc. Highly risky. Suitable for prototypes or throwaways. Principles of Project Management. 132. •44.

(45) Spiral. Principles of Project Management. 133. Spiral . Emphasizes risk analysis & mgmt. in each phase A Series of Mini-projects Each addresses a set of “risks” . . Start small, explore risks, prototype, plan, repeat. Early iterations are “cheapest” Number of spirals is variable . Last set of steps are waterfall-like. Principles of Project Management. 134. Spiral . Advantages . . Can be combined with other models As costs increase, risks decrease Risk orientation provides early warning. Disadvantages . More complex Requires more management. Principles of Project Management. 135. •45.

(46) Modified Waterfall – Sashimi . Overlapping phases Advantages . . Reduces overall schedule Reduces documentation Works well if personnel continuity. Disadvantages . Milestones more ambiguous Progress tracking more difficult Communication can be more difficult. Principles of Project Management. 136. Evolutionary Prototyping . Design most prominent parts first. . Good for situations with:. . . . Usually via a visual prototype Rapidly changing requirements Non-committal customer Vague problem domain. Provides steady, visible progress Disadvantages . Time estimation is difficult Project completion date may be unknown An excuse to do “code-and-fix” Principles of Project Management. 137. Staged Delivery . . Waterfall steps through architectural design Then detailed design, code, test, deliver in stages Advantages . . Disadvantages . . Customers get product much sooner Tangible signs of progress sooner Problems discovered earlier Increases flexibility Reduces: status reporting overhead & estimation error Requires more planning (for you the PM) More releases increase effort (and possible feature creep). How’s this differ from Evolutionary Prototyping? Principles of Project Management. 138. •46.

(47) V Process Model. Principles of Project Management. 139. V Process Model . Designed for testability. . Variation of waterfall Strengths. . Weaknesses. . . . . Emphasizes Verification & Validation. Encourages V&V at all phases Does not handle iterations Changes can be more difficult to handle. Good choice for systems that require high reliability such as patient control systems. Principles of Project Management. 140. RAD . Rapid Application Development Popular in the 80’s . 1. Joint Requirements Planning (JRP) 2. Joint Application Design (JAD) 3. Construction . . . Heavy use of tools: code generators Time-boxed; many prototypes. 4. Cutover. Good for systems with extensive user input available. Principles of Project Management. 141. •47.

(48) COTS . Commercial Off-The-Shelf software Build-vs.-buy decision Advantages . Available immediately Potentially lower cost. . Disadvantages. . Remember: custom software rarely meets its ideal (so compare that reality to COTS option). . Not as tailored to your requirements. Principles of Project Management. 142. IEEE 1074 . A standard for developing software processes . Lifecycle model selection Project management process Predevelopment processes Development processes Post-development processes Integral process. Principles of Project Management. 143. Planning . “Plans are nothing. But planning is everything.” Gen. Dwight Eisenhower. Principles of Project Management. 144. •48.

(49) Planning . Preliminary planning starts on day one Even in the pre-project phase Should not be conducted “in secret” Need buy-in and approval . Very important step Both from above and below. 145. Principles of Project Management. Your PM Process . Why. . What. . How. . Do. . Done. . . . . . Deliverable: ROI. SOW, Requirements. Design Specification, SDP, Lifecycle. Futrell, Shafer, Shafer, “Quality Software Project Management”. Execution. PPR Principles of Project Management. 146. Primary Planning Steps . Identify project scope and objectives Identify project organizational environment Analyze project characteristics Identify project products and activities Estimate effort for each activity Identify risk Allocate resources Review and communicate plan Principles of Project Management. 147. •49.

(50) Documents . Planning Product. Principles of Project Management. 148. Planning Documents . Software Development Plan (SDP) Software Quality Assurance Plan (SQAP) Software Configuration Management Plan (SCMP) Risk Management Plan Software Process Improvement Plan Communications Management Plan Migration Plan Operations Plan. Principles of Project Management. 149. Planning Documents . . You (the PM) need to choose which documents are appropriate Docs do not have to be lengthy Small Set: . Software Development Plan Risk Management Plan Software Quality Assurance Plan Software Configuration Management Plan. Principles of Project Management. 150. •50.

(51) Planning Documents . Project ROI Analysis Statement of Work (SOW) Project Charter Software Project Management Plan (SPMP) Budget Responsibility Assignment Matrix (RAM) Risk Management Plan. Principles of Project Management. 151. Product Documents . . . . . Statement of Need System Interface Specification Software Requirements Specification Software Design Specification Software Validation & Verification Plan User Documentation. . Support Plan Maintenance Documentation. Principles of Project Management. 152. Software Project Survival Guide . Another McConnell book See construx.com’s SPSG section . Good content online Documents Schedules Checklists Project web site template. Principles of Project Management. 153. •51.

(52) Planning . How much will it cost? How long will it take? How many people will it take? What might go wrong?. Principles of Project Management. 154. Planning . Scoping Estimation Risk Schedule Control Strategy. Principles of Project Management. 155. Process Issues . . . You want a fairly sophisticated process without incurring much overhead Remember, projects are often larger than they first appear Easier to loosen too much process than add later. Principles of Project Management. 156. •52.

(53) Plans Evolve Over Time. NASA’s “Manager’s Handbook for Software Development”. Principles of Project Management. 157. Software Development Plan . Software Project Management Plan (SPMP) Some consider it the most important document in the project (along with SRS) . . Can be seen as an aggregation of other core documents. Evolves over time as pieces come together. Principles of Project Management. 158. SDP / SPMP . Fundamental Sections . Project overview Deliverables Project organization Managerial processes Technical processes Budget Schedule. Principles of Project Management. 159. •53.

(54) Communications Management Plan . Often a section of SPMP Describes information flow to all parties . . Gathering and distributing information. Status meetings . Monthly, Weekly, Daily? Status reports are vital. Principles of Project Management. 160. Create a Project Intranet . A great communications tool Reference all project resources here. Principles of Project Management. 161. SOFTWARE PROJECT MANAGEMENT Session 4: WBS, Estimation & Scheduling. Principles of Project Management. 162. •54.

(55) Real-world Case Study . Web-based customized reporting project “How to Fail with the Rational Unified Process or 7 Steps to Pain and Suffering”. Principles of Project Management. 163. Project Considerations . Is infrastructure setup part of your project? Assumptions . What are you counting on? These can be critical to identify Resources expected: equip/people, approvals Availability of partners, connections Delineate key limits: . System load: expect an maximum of 100 users. Principles of Project Management. 164. Estimation . . “Predictions are hard, especially about the future”, Yogi Berra 2 Types: Lucky or Lousy?. Principles of Project Management. 165. •55.

(56) Planning, Estimating, Scheduling . . . What’s the difference? Plan: Identify activities. No specific start and end dates. Estimating: Determining the size & duration of activities. Schedule: Adds specific start and end dates, relationships, and resources.. Principles of Project Management. 166. Project Planning: A 12 Step Program Set goal and scope Select lifecycle Set org./team form Start team selection Determine risks Create WBS. 1) 2) 3) 4) 5) 6). 7) 8) 9) 10). 11) 12). Identify tasks Estimate size Estimate effort Identify task dependencies Assign resources Schedule work. Principles of Project Management. 167. How To Schedule . 1. Identify “what” needs to be done. . 2. Identify “how much” (the size). . 3. Identify the dependency between tasks. . 4. Estimate total duration of the work to be done. . . . . Work Breakdown Structure (WBS) Size estimation techniques Dependency graph, network diagram The actual schedule. Principles of Project Management. 168. •56.

(57) WBS & Estimation . How did you feel when I asked. . Not an easy answer to give right? At least not if I were are real customer on a real project How can you manage that issue?. . . . “How long will your project take?”. Principles of Project Management. 169. Partitioning Your Project . . You need to decompose your project into manageable chunks ALL projects need this step Divide & Conquer Two main causes of project failure . . Forgetting something critical Ballpark estimates become targets. How does partitioning help this?. Principles of Project Management. 170. Project Elements . A Project: functions, activities, tasks. Principles of Project Management. 171. •57.

(58) Work Breakdown Structure: WBS . Hierarchical list of project’s work activities 2 Formats . . Outline (indented format) Graphical Tree (Organizational Chart). Uses a decimal numbering system . Ex: 3.1.5 0 is typically top level. . Includes. . Shows “is contained in” relationships Does not show dependencies or durations. . . Development, Mgmt., and project support tasks. Principles of Project Management. 172. WBS . Contract WBS (CWBS) . . First 2 or 3 levels High-level tracking. Project WBS (PWBS) . Defined by PM and team members Tasks tied to deliverables Lowest level tracking. Principles of Project Management. 173. A Full WBS Structure . Up to six levels (3-6 usually) such as. . Upper 3 can be used by customer for reporting (if part of RFP/RFQ) Different level can be applied to different uses. . . Ex: Level 1: authorizations; 2: budgets; 3: schedules. Principles of Project Management. 174. •58.

(59) WBS Chart Example. Principles of Project Management. 175. WBS Outline Example 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production Principles of Project Management. 176. WBS Types . Process WBS . . Product WBS . . a.k.a Activity-oriented Ex: Requirements, Analysis, Design, Testing Typically used by PM a.k.a. Entity-oriented Ex: Financial engine, Interface system, DB Typically used by engineering manager. Hybrid WBS: both above . . This is not unusual Ex: Lifecycle phases at high level with component or feature-specifics within phases Rationale: processes produce products Principles of Project Management. 177. •59.

(60) Product WBS. Principles of Project Management. 178. Process WBS. Principles of Project Management. 179. Outline WBS w/Gantt. Principles of Project Management. 180. •60.

(61) WBS by PMI Process Groups. Principles of Project Management. 181. WBS Types . Less frequently used alternatives . Organizational WBS Research, Product Design, Engineering, Operations Can be useful for highly cross-functional projects. . . Geographical WBS Can be useful with distributed teams NYC team, San Jose team, Off-shore team. . Principles of Project Management. 182. Work Packages. . Generic term for discrete tasks with definable end results Typically the “leaves” on the tree The “one-to-two” rule. . Basis for monitoring and reporting progress. . . . . Often at: 1 or 2 persons for 1 or 2 weeks Can be tied to budget items (charge numbers) Resources (personnel) assigned. Ideally shorter rather than longer . Longer makes in-progress estimates needed These are more subjective than “done” 2-3 weeks maximum for software projects 1 day minimum (occasionally a half day) Not so small as to micro-manage. Principles of Project Management. 183. •61.

(62) WBS . List of Activities, not Things List of items can come from many sources. . Describe activities using “bullet language”. . All WBS paths do not have to go to the same level Do not plan more detail than you can manage. . . . . SOW, Proposal, brainstorming, stakeholders, team Meaningful but terse labels. Principles of Project Management. 184. WBS & Methodology . PM must map activities to chosen lifecycle Each lifecycle has different sets of activities Integral process activities occur for all . . . . . Planning, configuration, testing. Operations and maintenance phases are not normally in plan (considered post-project) Some models are “straightened” for WBS Spiral and other iterative models Linear sequence several times. Deliverables of tasks vary by methodology. Principles of Project Management. 185. WBS Techniques . Top-Down Bottom-Up Analogy Rolling Wave . . 1st pass: go 1-3 levels deep Gather more requirements or data Add more detail later. Post-its on a wall. Principles of Project Management. 186. •62.

(63) WBS Techniques . Top-down . Start at highest level Systematically develop increasing level of detail Best if . . The problem is well understood Technology and methodology are not new This is similar to an earlier project or problem. But is also applied in majority of situations. Principles of Project Management. 187. WBS Techniques . Bottom-up . Start at lowest level tasks Aggregate into summaries and higher levels Cons . . Time consuming Needs more requirements complete. Pros . Detailed. Principles of Project Management. 188. WBS Techniques . Analogy . Base WBS upon that of a “similar” project Use a template Analogy also can be estimation basis Pros . . Based on past actual experience. Cons . Needs comparable project. Principles of Project Management. 189. •63.

(64) WBS Techniques . Brainstorming . . . . Generate all activities you can think of that need to be done Group them into categories. Both Top-down and Brainstorming can be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!). Principles of Project Management. 190. WBS – Basis of Many Things . Network scheduling Costing Risk analysis Organizational structure Control Measurement. Principles of Project Management. 191. WBS Guidelines Part 1 . . Should be easy to understand Some companies have corporate standards for these schemes Some top-level items, like Project Mgmt. are in WBS for each project . . . Others vary by project. What often hurts most is what’s missing Break down until you can generate accurate time & cost estimates Ensure each element corresponds to a deliverable. Principles of Project Management. 192. •64.

(65) WBS Guidelines Part 2 . How detailed should it be? . . What tool should you use? . . Not as detailed as the final MS-Project plan Each level should have no more than 7 items It can evolve over time Excel, Word, Project Org chart diagramming tool (Visio, etc) Specialized commercial apps. Re-use a “template” if you have one. Principles of Project Management. 193. Estimations Very difficult to do, but needed often Created, used or refined during. . Strategic planning Feasibility study and/or SOW Proposals Vendor and sub-contractor evaluation Project planning (iteratively). Basic process. 1) 2) 3) . Estimate the size of the product Estimate the effort (man-months) Estimate the schedule NOTE: Not all of these steps are always explicitly performed. Principles of Project Management. 194. Estimations . Remember, an “exact estimate” is an oxymoron Estimate how long will it take you to get home from class tonight . . On what basis did you do that? Experience right? Likely as an “average” probability For most software projects there is no such ‘average’. Most software estimations are off by 25-100%. Principles of Project Management. 195. •65.

(66) Estimation . Target vs. Committed Dates . Target: Proposed by business or marketing Do not commit to this too soon! Committed: Team agrees to this After you’ve developed a schedule. Principles of Project Management. 196. Cone of Uncertainty. Principles of Project Management. 197. Estimation . Size: . . Small projects (10-99 FPs), variance of 7% from post-requirements estimates Medium (100-999 FPs), 22% variance Large (1000-9999 FPs) 38% variance Very large (> 10K FPs) 51% variance. Principles of Project Management. 198. •66.

(67) Estimation Methodologies . Top-down Bottom-up Analogy Expert Judgment Priced to Win Parametric or Algorithmic Method . Using formulas and equations. Principles of Project Management. 199. Top-down Estimation . Based on overall characteristics of project . . Advantages . . Some of the others can be “types” of top-down (Analogy, Expert Judgment, and Algorithmic methods) Easy to calculate Effective early on (like initial cost estimates). Disadvantages . Some models are questionable or may not fit Less accurate because it doesn’t look at details. Principles of Project Management. 200. Bottom-up Estimation. . Create WBS Add from the bottom-up Advantages. . Disadvantages. . . . Works well if activities well understood Specific activities not always known More time consuming. Principles of Project Management. 201. •67.

(68) Expert Judgment . . Use somebody who has recent experience on a similar project You get a “guesstimate” Accuracy depends on their ‘real’ expertise Comparable application(s) must be accurately chosen . . Systematic. Can use a weighted-average of opinions. Principles of Project Management. 202. Estimation by Analogy . Use past project . Must be sufficiently similar (technology, type, organization) Find comparable attributes (ex: # of inputs/outputs) Can create a function. . Advantages. . Disadvantages. . . Based on actual historical data Difficulty ‘matching’ project types Prior data may have been mis-measured How to measure differences – no two exactly same. Principles of Project Management. 203. Priced to Win . . Just follow other estimates Save on doing full estimate Needs information on other estimates (or prices) Purchaser must closely watch trade-offs Priced to lose?. Principles of Project Management. 204. •68.

(69) Algorithmic Measures . Lines of Code (LOC) Function points Feature points or object points Other possible . Number of bubbles on a DFD Number of of ERD entities Number of processes on a structure chart. . LOC and function points most common. . Majority of projects use none of the above. . (of the algorithmic approaches). Principles of Project Management. 205. Code-based Estimates . LOC Advantages . . Commonly understood metric Permits specific comparison Actuals easily measured. LOC Disadvantages . Difficult to estimate early in cycle Counts vary by language Many costs not considered (ex: requirements) Programmers may be rewarded based on this . . Can use: # defects/# LOC. Code generators produce excess code. Principles of Project Management. 206. LOC Estimate Issues . How do you know how many in advance? What about different languages? What about programmer style? Stat: avg. programmer productivity: 3,000 LOC/yr Most algorithmic approaches are more effective after requirements (or have to be after). Principles of Project Management. 207. •69.

(70) Function Points . . Software size s/b measured by number & complexity of functions it performs More methodical than LOC counts House analogy . . House’s Square Feet ~= Software LOC # Bedrooms & Baths ~= Function points Former is size only, latter is size & function. Six basic steps. Principles of Project Management. 208. Function Point Process . 1. Count # of biz functions per category . . Categories: outputs, inputs, db inquiries, files or data structures, and interfaces. 2. Establish Complexity Factor for each and apply . Simple, Average, Complex Set a weighting multiplier for each (0->15) This results in the “unadjusted function-point total”. . 3. Compute an “influence multiplier” and apply. . 4. Results in “function point total”. . . It ranges from 0.65 to 1.35; is based on 14 factors This can be used in comparative estimates. Principles of Project Management. 209. Wideband Delphi . . Group consensus approach Rand corp. used orig. Delphi approach to predict future technologies Present experts with a problem and response form Conduct group discussion, collect anonymous opinions, then feedback Conduct another discussion & iterate until consensus Advantages Easy, inexpensive, utilizes expertise of several people Does not require historical data Disadvantages Difficult to repeat May fail to reach consensus, reach wrong one, or all may have same bias. Principles of Project Management. 210. •70.

(71) Parametric Method Issues. . Remember: most projects you’ll run into don’t use these Which is ‘normal’, so don’t be surprised. . These are more effective on large projects. . Primary issue for most projects are. . . . . Or come-in to new job and say “Hey, let’s use COCOMO” Where a past historical base exists Lack of similar projects . . Thus lack of comparable data. Catch-22: how to get started. Principles of Project Management. 211. Code Reuse & Estimation . Does not come for free Code types: New, Modified, Reused If code is more than 50% modified, it’s “new” Reuse factors have wide range . . Reused code takes 30% effort of new Modified is 60% of new. Integration effort with reused code almost as expensive as with new code. Principles of Project Management. 212. Effort Estimation . . Now that you know the “size”, determine the “effort” needed to build it Various models: empirical, mathematical, subjective Expressed in units of duration . Man-months (or ‘staff-months’ now). Principles of Project Management. 213. •71.

(72) Effort Estimation . . . McConnell shows schedule tables for conversion of size to effort As with parametric size estimation, these techniques perform better with historical data Again, not seen in ‘average’ projects Often the size and effort estimation steps are combined (not that this is recommended, but is what often is done) “Commitment-Based” Scheduling is what is often done . Ask developer to ‘commit’ to an estimate (his or her own). Principles of Project Management. 214. COCOMO . . COnstructive COst MOdel Allows for the type of application, size, and “Cost Drivers” Outputs in Person Months Cost drivers using High/Med/Low & include . . Motivation Ability of team Application experience. Biggest weakness? . Requires input of a product size estimate in LOC. Principles of Project Management. 215. Estimation Issues . Quality estimations needed early but information is limited Precise estimation data available at end but not needed . Or is it? What about the next project?. . Best estimates are based on past experience Politics of estimation:. . For many software projects there is little or none. . . . You may anticipate a “cut” by upper management Technologies change Historical data unavailable Wide variance in project experiences/types Subjective nature of software estimation. Principles of Project Management. 216. •72.

(73) Over and Under Estimation . Over estimation issues . The project will not be funded . . . Conservative estimates guaranteeing 100% success may mean funding probability of zero.. Parkinson’s Law: Work expands to take the time allowed Danger of feature and scope creep Be aware of “double-padding”: team member + manager. Under estimation issues . Quality issues (short changing key phases like testing) Inability to meet deadlines Morale and other team motivation issues. Principles of Project Management. 217. Estimation Guidelines . Estimate iteratively! . Process of gradual refinement Make your best estimates at each planning stage Refine estimates and adjust plans iteratively Plans and decisions can be refined in response Balance: too many revisions vs. too few. Principles of Project Management. 218. Know Your Deadlines . Are they ‘Real Deadlines’? . . Tied to an external event Have to be met for project to be a success Ex: end of financial year, contractual deadline, Y2K. Or ‘Artificial Deadlines’? . Set by arbitrary authority May have some flexibility (if pushed). Principles of Project Management. 219. •73.

(74) Estimation “Presentation” . How you present the estimation can have huge impact Techniques . Plus-or-minus qualifiers . . . . . Best / Planned / Current / Worst cases. Coarse Dates . . +/- with added information +1 month of new tools not working as expected -2 weeks for less delay in hiring new developers. Cases . . 6-8 months. Risk Quantification . . 6 months +/-1 month. Ranges. Q3 02. Confidence Factors . April 1 – 10% probability, July 1 – 50%, etc. Principles of Project Management. 220. Other Estimation Factors . Account for resource experience or skill . Up to a point Often needed more on the “low” end, such as for a new or junior person. . Allow for “non-project” time & common tasks. . There are commercial ‘estimation tools’ available. . . Meetings, phone calls, web surfing, sick days They typically require configuration based on past data. Principles of Project Management. 221. Other Estimation Notes. . Remember: “manage expectations” Parkinson’s Law. . The Student Syndrome. . . . “Work expands to fill the time available” Procrastination until the last minute (cram). Principles of Project Management. 222. •74.

(75) Financial Analysis of Projects . . Financial considerations are often an important consideration in selecting projects Three primary methods for determining the projected financial value of projects: . Net present value (NPV) analysis Return on investment (ROI) Payback analysis. Principles of Project Management. 223. Net Present Value Analysis: NPV . . . NPV: a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time Projects with a positive NPV should be considered if financial value is a key criterion The higher the NPV, the better. Principles of Project Management. 224. Principles of Project Management. 225. NPV Example. •75.

(76) Return on Investment (ROI) . ROI: income divided by investment ROI = (total discounted benefits - total discounted costs) / discounted costs. . The higher the ROI, the better Many organizations have a required rate of return or minimum acceptable rate of return on investment for projects. Principles of Project Management. 226. SOFTWARE PROJECT MANAGEMENT Session 5: Scheduling. Principles of Project Management. 227. WBS . . Types: Process, product, hybrid Formats: Outline or graphical org chart High-level WBS does not show dependencies or durations What hurts most is what’s missing Becomes input to many things, esp. schedule. Principles of Project Management. 228. •76.

(77) Estimation . . “The single most important task of a project: setting realistic expectations. Unrealistic expectations based on inaccurate estimates are the single largest cause of software failure.” Futrell, Shafer, Shafer, “Quality Software Project Management” Session 4 cont.. Principles of Project Management. 229. Estimation . History is your best ally. . Use multiple methods if possible. . . . Especially when using LOC, function points, etc. This reduces your risk If using “experts”, use two. Get buy-in Remember: it’s an iterative process! Know your “presentation” techniques. Principles of Project Management. 230. Estimation . Bottom-up . . More work to create but more accurate Often with Expert Judgment at the task level. Top-down . Used in the earliest phases Usually with/as Analogy or Expert Judgment. . Analogy. . Expert Judgment. . . Comparison with previous project: formal or informal Via staff members who will do the work Most common technique along w/analogy Best if multiple ‘experts’ consulted Principles of Project Management. 231. •77.

(78) Estimation . Parametric Methods. . Function Points. . . . . Know the trade-offs of: LOC & Function Points Benefit: relatively independent of the technology used to develop the system We will re-visit this briefly later in semester (when discussing “software metrics”) Variants: WEBMO (no need to know this for exam). . Re-Use Estimation. . U Calgary. . See QSPM outline. Principles of Project Management. 232. Your Early Phase Processes . Initial Planning: . Why . . . . WBS Other planning documents Software Development Plan, Risk Mgmt., Cfg. Mgmt.. Estimating . . SOW, Charter. What/How (partial/1st pass). Size (quantity/complexity) and Effort (duration) Iterates. Scheduling . Begins along with 1st estimates Iterates Principles of Project Management. 233. Scheduling . . Once tasks (from the WBS) and size/effort (from estimation) are known: then schedule Primary objectives . . Best time Least cost Least risk. Secondary objectives . Evaluation of schedule alternatives Effective use of resources Communications. Principles of Project Management. 234. •78.

(79) Terminology . Precedence: . . Concurrence: . . A task that must occur before another is said to have precedence of the other Concurrent tasks are those that can occur at the same time (in parallel). Leads & Lag Time . Delays between activities Time required before or after a given task. Principles of Project Management. 235. Terminology . Milestones . Have a duration of zero Identify critical points in your schedule Shown as inverted triangle or a diamond Often used at “review” or “delivery” times . . Or at end or beginning of phases Ex: Software Requirements Review (SRR) Ex: User Sign-off. Can be tied to contract terms. Principles of Project Management. 236. Principles of Project Management. 237. Terminology Example Milestones. •79.

(80) Terminology . Slack & Float . Float & Slack: synonymous terms Free Slack. . Total Slack. . Slack Time TS = TL – TE. . . . . Slack an activity has before it delays next task Slack an activity has before delaying whole project. TE = earliest time an event can take place TL = latest date it can occur w/o extending project’s completion date. Principles of Project Management. 238. Scheduling Techniques . Mathematical Analysis . Network Diagrams . . PERT CPM GERT. Bar Charts . Milestone Chart Gantt Chart. Principles of Project Management. 239. Network Diagrams . . Developed in the 1950’s A graphical representation of the tasks necessary to complete a project Visualizes the flow of tasks & relationships. Principles of Project Management. 240. •80.

(81) Mathematical Analysis . PERT. . CPM. . . . Program Evaluation and Review Technique Critical Path Method. Sometimes treated synonymously All are models using network diagrams. Principles of Project Management. 241. MS-Project Example. Principles of Project Management. 242. Network Diagrams . Two classic formats . . AOA: Activity on Arrow AON: Activity on Node. Each task labeled with . . Identifier (usually a letter/code) Duration (in std. unit like days). There are other variations of labeling There is 1 start & 1 end event Time goes from left to right. Principles of Project Management. 243. •81.

(82) Node Formats. Principles of Project Management. 244. Network Diagrams . AOA consists of . Circles representing Events . . . . Such as ‘start’ or ‘end’ of a given task. Lines representing Tasks Thing being done ‘Build UI’. a.k.a. Arrow Diagramming Method (ADM). AON . Tasks on Nodes . . Nodes can be circles or rectangles (usually latter) Task information written on node. Arrows are dependencies between tasks a.k.a. Precedence Diagramming Method (PDM). Principles of Project Management. 245. Critical Path . “The specific set of sequential tasks upon which the project completion date depends” . . or “the longest full path”. All projects have a Critical Path Accelerating non-critical tasks do not directly shorten the schedule. Principles of Project Management. 246. •82.

(83) Critical Path Example. Principles of Project Management. 247. CPM . Critical Path Method . . . . The process for determining and optimizing the critical path. Non-CP tasks can start earlier or later w/o impacting completion date Note: Critical Path may change to another as you shorten the current Should be done in conjunction with the you & the functional manager Principles of Project Management. 248. 4 Task Dependency Types . Mandatory Dependencies . . “Hard logic” dependencies Nature of the work dictates an ordering Ex: Coding has to precede testing Ex: UI design precedes UI implementation. Discretionary Dependencies . “Soft logic” dependencies Determined by the project management team Process-driven Ex: Discretionary order of creating certain modules. Principles of Project Management. 249. •83.

(84) 4 Task Dependency Types . External Dependencies . . Outside of the project itself Ex: Release of 3rd party product; contract signoff Ex: stakeholders, suppliers, Y2K, year end. Resource Dependencies . Two task rely on the same resource Ex: You have only one DBA but multiple DB tasks. Principles of Project Management. 250. Task Dependency Relationships . Finish-to-Start (FS) . . Start-to-Start (SS) . . B cannot start till A starts A: Pour foundation; B: Level concrete. Finish-to-Finish (FF) . . B cannot start till A finishes A: Construct fence; B: Paint Fence. B cannot finish till A finishes A: Add wiring; B: Inspect electrical. Start-to-Finish (SF) . B cannot finish till A starts (rare). Principles of Project Management. 251. Example Step 1. Principles of Project Management. 252. •84.

(85) Forward Pass . . To determine early start (ES) and early finish (EF) times for each task Work from left to right Adding times in each path Rule: when several tasks converge, the ES for the next task is the largest of preceding EF times. Principles of Project Management. 253. Example Step 2. Principles of Project Management. 254. Backward Pass . To determine the last finish (LF) and last start (LS) times Start at the end node Compute the bottom pair of numbers Subtract duration from connecting node’s earliest start time. Principles of Project Management. 255. •85.

(86) Example Step 3. Principles of Project Management. 256. Example Step 4. Principles of Project Management. 257. Slack & Reserve . How can slack be negative? What does that mean? How can you address that situation?. Principles of Project Management. 258. •86.

(87) Slack & Reserve Reserve Time. Negative Slack. Forward Pass A. B Backward Pass. Project Due Date. Start Date. Principles of Project Management. 259. Network Diagrams . Advantages . . Show precedence well Reveal interdependencies not shown in other techniques Ability to calculate critical path Ability to perform “what if” exercises. Disadvantages . Default model assumes resources are unlimited . . You need to incorporate this yourself (Resource Dependencies) when determining the “real” Critical Path. Difficult to follow on large projects. Principles of Project Management. 260. PERT . Program Evaluation and Review Technique Based on idea that estimates are uncertain . . . Therefore uses duration ranges And the probability of falling to a given range. Uses an “expected value” (or weighted average) to determine durations Use the following methods to calculate the expected durations, then use as input to your network diagram. Principles of Project Management. 261. •87.

(88) PERT . Start with 3 estimates . Optimistic . . . . Would likely occur 1 time in 20. Most likely Modal value of the distribution. Pessimistic . Would be exceeded only one time in 20. Principles of Project Management. 262. PERT Formula . Combined to estimate a task duration. Principles of Project Management. 263. PERT Formula . Confidence Interval can be determined Based on a standard deviation of the expected time . . Using a bell curve (normal distribution). For the whole critical path use. Principles of Project Management. 264. •88.

(89) PERT Example. . . Description. Planner 1. Planner 2. m. 10d. 10d. a. 9d. 9d. b. 12d. 20d. PERT time. 10.16d. 11.5d. Std. Dev.. 0.5d. 1.8d. Confidence interval for P2 is 4 times wider than P1 for a given probability Ex: 68% probability of 9.7 to 11.7 days (P1) vs. 9.5-13.5 days (P2). Principles of Project Management. 265. PERT . Advantages. . Disadvantages. . . . Accounts for uncertainty Time and labor intensive Assumption of unlimited resources is big issue Lack of functional ownership of estimates Mostly only used on large, complex project. Get PERT software to calculate it for you Principles of Project Management. 266. CPM vs. PERT . Both use Network Diagrams CPM: deterministic PERT: probabilistic CPM: one estimate, PERT, three estimates PERT is infrequently used. Principles of Project Management. 267. •89.

(90) Milestone Chart . Sometimes called a “bar charts” Simple Gantt chart . Either showing just highest summary bars Or milestones only. Principles of Project Management. 268. Principles of Project Management. 269. Principles of Project Management. 270. Bar Chart. Gantt Chart. •90.

(91) Gantt Chart . Disadvantages . . Advantages . . Does not show interdependencies well Does not uncertainty of a given activity (as does PERT) Easily understood Easily created and maintained. Note: Software now shows dependencies among tasks in Gantt charts . In the “old” days Gantt charts did not show these dependencies, bar charts typically do not. Principles of Project Management. 271. Reducing Project Duration . How can you shorten the schedule? Via . Reducing scope (or quality) Adding resources Concurrency (perform tasks in parallel) Substitution of activities. Principles of Project Management. 272. Compression Techniques . Shorten the overall duration of the project Crashing . . Looks at cost and schedule tradeoffs Gain greatest compression with least cost Add resources to critical path tasks Limit or reduce requirements (scope) Changing the sequence of tasks. Fast Tracking . . Overlapping of phases, activities or tasks that would otherwise be sequential Involves some risk May cause rework. Principles of Project Management. 273. •91.

(92) Mythical Man-Month . Book: “The Mythical Man-Month”. . “The classic book on the human elements of software engineering” First two chapters are full of terrific insight (and quotes). . . Author: Fred Brooks. Principles of Project Management. 274. Mythical Man-Month . . “Cost varies as product of men and months, progress does not.” “Hence the man-month as a unit for measuring the size of job is a dangerous and deceptive myth”. Principles of Project Management. 275. Mythical Man-Month . Why is software project disaster so common? . . . . 1. Estimation techniques are poor & assume things will go well (an ‘unvoiced’ assumption) 2. Estimation techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable 3. Because of estimation uncertainty, manager lack courteous stubbornness 4. Schedule progress is poorly monitored 5. When schedule slippage is recognized, the natural response is to add manpower. Which, is like dousing a fire with gasoline.. Principles of Project Management. 276. •92.

(93) Mythical Man-Month . Optimism . . . “All programmers are optimists” 1st false assumption: “all will go well” or “each task takes only as long as it ‘ought’ to take” The Fix: Consider the larger probabilities. Cost (overhead) of communication (and training) . His formula: n(n-1)/2. How long does a 12 month project take? . . 1 person: 1 month 2 persons = 7 months (2 man-months extra) 3 persons = 5 months (e man-months extra). Fix: don’t assume adding people will solve the problem Principles of Project Management. 277. Mythical Man-Month . Sequential nature of the process . “The bearing of a child takes nine months, no matter how many women are assigned”. . What is the most mis-scheduled part of process?. . Why is this particularly bad?. . . . Testing (the most linear process) Occurs late in process and w/o warning Higher costs: primary and secondary. Fix: Allocate more test time . Understand task dependencies. Principles of Project Management. 278. Mythical Man-Month . Reliance on hunches and guesses. . The myth of additional manpower. . . What is ‘gutless estimating’? Brooks Law “Adding manpower to a late project makes it later”. Principles of Project Management. 279. •93.

(94) Mythical Man-Month . Q: “How does a project get to be a year late”?. . Studies. . . . A: “One day at a time” Each task: twice as long as estimated Only 50% of work week was programming. Fixes . No “fuzzy” milestones (get the “true” status) Reduce the role of conflict Identify the “true status”. Principles of Project Management. 280. SOFTWARE PROJECT MANAGEMENT Session 6: MS-Project Intro & Mid-term Exam. Principles of Project Management. 281. MS-Project . . Mid-market leader Has approx. 50% overall market share 70-80% MS-Project users never used automated project tracking prior (a “first” tool) Not a mid/high-end tool for EPM (Enterprise Project Mgmt.). Principles of Project Management. 282. •94.

(95) Project Pros . Easy outlining of tasks Resource management Accuracy: baseline vs. actual; various calculations Easy charting and graphics Cost management Capture historical data. Principles of Project Management. 283. Project Cons . Illusion of control Workgroup features ok, still in-progress Scaling No estimation features Remember: . . Being a MS-Project expert does not make you an expert project manager! No more so than knowing MS-Word makes you a good writer.. Principles of Project Management. 284. The MS-Project Process . Move WBS into a Project outline (in Task Sheet) Add resources (team members or roles) Add costs for resources Assign resources to tasks Establish dependencies Refine and optimize Create baseline Track progress (enter actuals, etc.). Principles of Project Management. 285. •95.

(96) Project Overview . . This is a ‘quickie’ overview We will return to all of these steps individually over the next few weeks Sample project from McConnell. 286. Principles of Project Management. Project UI . Views . Default is Gant Chart View . . 2 panes Task Sheet on left (a table) Gantt Chart on right. View Bar on far left. 287. Principles of Project Management. Project UI (Un)Link Buttons. Toolbars. Outline Buttons. Indicators Timescale. Enter Tasks Here. Gantt Chart View Bar. Task Bars Task Sheet Milestone. Split Bar. Principles of Project Management. 288. •96.

(97) Create Your Project . File/New Setup start date Setup calendar . Menu: Project/Project Information Often left with default settings Hours, holidays. Principles of Project Management. 289. Enter WBS . . Outlining Sub-tasks and summary tasks Do not enter start/end dates for each Just start with Task Name and Duration for each Use Indent/Outdent buttons to define summary tasks and subtasks You can enter specific Start/End dates but don’t most of the time. Principles of Project Management. 290. Establish Durations . Know the abbreviations . h/d/w/m D is default. . Can use partial. . Elapsed durations Estimated durations. . . . .5d is a half-day task. Put a ‘?’ after duration. Principles of Project Management. 291. •97.

(98) Add Resources . Work Resources. . Material Resources. . . People Things Can be used to track costs . . Ex: amount of equipment purshased. Not used as often in typical software project. Principles of Project Management. 292. Resource Sheet . Can add new resources here . Or directly in the task entry sheet . . Beware of mis-spellings (Project will create near-duplicates). Setup costs . Such as annual salary (put ‘yr’ after ‘Std. Rate’). Principles of Project Management. 293. Effort-Driven Scheduling . MS-Project default Duration * Units = Work . . Adding more resources to a task shortens duration Can be changed on a per-task basis . . Duration = Work / Units (D = W/U) Work = Duration * Units (W = D*U) Units = Work / Duration (U = W/D). In the advanced tab of Task Information dialog box Task Type setting. Beware the Mythical Man-month . Good for laying bricks, not always so for software development Principles of Project Management. 294. •98.

(99) Link Tasks . On toolbar: Link & Unlink buttons. . Or via Gantt chart. . . Good for many at once Drag from one task to another. Principles of Project Management. 295. Milestones . Zero duration tasks Insert task ‘normally’ but put 0 in duration. Principles of Project Management. 296. Make Assignments . Approach 1. Using Task Sheet . . Using Resource Names column You can create new ones by just typing-in here. 2. Using Assign Resources dialog box . Good for multiple resources Highlight task, Tools/Resources or toolbar button. . 3. Using Task Information dialog. . 4. Task Entry view. . . Resources tab View/More Views/Task Entry Or Task Entry view on Resource Mgmt. toolbar. Principles of Project Management. 297. •99.

(100) Save Baseline . Saves all current information about your project . Dates, resource assignments, durations, costs. Principles of Project Management. 298. Fine Tune . . Then is used later as basis for comparing against “actuals” Menu: Tools/Tracking/Save Baseline. Principles of Project Management. 299. Project 2002 . 3 Editions: Standard, Professional, Server MS Project Server 2002 . Upgrade of old “Project Central” Includes “Project Web Access”, web-based UI (partial) Workgroup and resource notification features Requires SQL-Server and IIS “Portfolio Analyzer” . . . Drill-down into projects via pivot tables & charts. “Portfolio Modeler” Create models and “what-if” scenarios. SharePoint Team Services integration. Principles of Project Management. 300. •100.

(101) Project 2002 . MS-Project Professional . “Build Team” feature . . . Skills-based resource matching. Resource Pools: with skill set tracking Resource Substitution Wizard. “Project Guide” feature . Customizable “process component”. Principles of Project Management. 301. SOFTWARE PROJECT MANAGEMENT Session 7: Risk and Change Management. Principles of Project Management. 302. Risk Management . Problems that haven’t happened yet Why is it hard? Some are wary of bearing bad news . . No one wants to be the messenger Or seen as “a worrier”. You need to define a strategy early in your project. Principles of Project Management. 303. •101.

(102) Risk Management . Identification, Analysis, Control Goal: avoid a crisis Thayer: Risk Mgmt. vs. Project Mgt. . For a specific vs. all projects Proactive vs. reactive. Principles of Project Management. 304. Project Risk . Characterized by: . Uncertainty (0 < probability < 1) An associated loss (money, life, reputation, etc) Manageable – some action can control it. . Risk Exposure. . Problem. . . Product of probability and potential loss A risk that has materialized. Principles of Project Management. 305. Types of Risks . Schedule Risks. . Cost Risks. . Requirements Risks. . . . Schedule compression (customer, marketing, etc.) Unreasonable budgets Incorrect Incomplete Unclear or inconsistent Volatile. Principles of Project Management. 306. •102.

(103) Types of Risks . Quality Risks Operational Risks Most of the “Classic Mistakes” . Classic mistakes are made more often. 307. Principles of Project Management. Risk Management Process Risk Identification Risk Assesment. Risk Analysis Risk Prioritization. Risk Management Risk Management Planning Risk Control. Risk Resolution. Risk Monitoring. “Software Risk Management”, Boehm, 1989. Principles of Project Management. 308. Risk Identification . Get your team involved in this process. . Produces a list of risks with potential to disrupt your project’s schedule Use a checklist or similar source to brainstorm possible risks. . . Don’t go it alone. Principles of Project Management. 309. •103.

(104) Risk Analysis . Determine impact of each risk Risk Exposure (RE) . a.k.a. “Risk Impact” RE = Probability of loss * size of loss Ex: risk is “Facilities not ready on time” . . . Probability is 25%, size is 4 weeks, RE is 1 week. Ex: risk is “Inadequate design – redesign required” Probability is 15%, size is 10 weeks, RE is 1.5 weeks. Statistically are “expected values” Sum all RE’s to get expected overrun . Which is pre risk management. Principles of Project Management. 310. Risk Analysis . Estimating size of loss . Loss is easier to see than probability . . You can break this down into “chunks” (like WBS). Estimating probability of loss . . Use team member estimates and have a risk-estimate review Use Delphi or group-consensus techniques Use gambling analogy” “how much would you bet” Use “adjective calibration”: highly likely, probably, improbable, unlikely, highly unlikely. Principles of Project Management. 311. Risk Prioritization . Remember the 80-20 rule Often want larger-loss risks higher . . Or higher probability items. Possibly group ‘related risks’ Helps identify which risks to ignore . Those at the bottom. Principles of Project Management. 312. •104.

(105) Types of Unknowns . Known Unknowns. . Unknown Unknowns. . . Information you know someone else has Information that does not yet exist. Principles of Project Management. 313. Risk Control . Risk Management Plan . Can be 1 paragraph per risk McConnell’s example. Principles of Project Management. 314. Risk Resolution . Risk Avoidance . Don’t do it Scrub from system Off-load to another party . . McConnell: design issue: have client design. Risk Assumption . Don’t do anything about it Accept that it might occur But still watch for it. Principles of Project Management. 315. •105.

(106) Risk Resolution . Problem control . . Risk Transfer . . Develop contingency plans Allocate extra test resources See McConnell pg. 98-99 To another part of the project (or team) Move off the critical path at least. Knowledge Acquisition . Investigate . . Ex: do a prototype. Buy information or expertise about it Do research. Principles of Project Management. 316. Risk Monitoring . Top 10 Risk List . Rank Previous Rank Weeks on List Risk Name Risk Resolution Status. . A low-overhead best practice Interim project post-mortems. . McConnell’s example. . . After various major milestones. Principles of Project Management. 317. Risk Communication . Don’t be afraid to convey the risks Use your judgment to balance . Sky-is-falling whiner vs. information distribution. Principles of Project Management. 318. •106.

(107) Miniature Milestones . A risk-reduction technique Use of small goals within project schedule . . . . One of McConnell’s Best Practices (Ch. 27). Fine-grained approach to plan & track Reduces risk of undetected project slippage Pros Enhances status visibility Good for project recovery. Cons . Increase project tracking effort. Principles of Project Management. 319. Miniature Milestones . Can be used throughout the development cycle Works with will hard-to-manage project activities or methods . . . . Such as with evolutionary prototyping. Reduces unpleasant surprises Success factors Overcoming resistance from those managed Staying true to ‘miniature’ nature. Can improve motivation through achievements. Principles of Project Management. 320. Miniature Milestones . Requires a detailed schedule Have early milestones McConnell says 1-2 days . . Longer is still good (1-2 weeks). Encourages iterative development Use binary milestones . Done or not done (100%). Principles of Project Management. 321. •107.

(108) Feature-Set Control . Class mistake avoidance Early Stages . 1. Minimal Specification 2. Requirements Scrubbing 3. Versioned Development. . Mid-Project. . Late-Project. . . Effective change control Feature cuts. Principles of Project Management. 322. Traditional Specs . Drive for “traditional” specs . Necessity Downstream cost avoidance Full control over all aspects. As McConnell notes: . . “But the goal is not to build exactly what you said you would at the beginning. It is to build the best possible software within the available time.” Idealistic but worth remembering. Principles of Project Management. 323. Minimal Specification . This is not XP (extreme programming) Tradition spec. issues . Wasted effort . . Too much detail. Obsolescence Lack of efficacy -- details do not guarantee success Overly constrained design User assumption that costs are equal (UI ex.). Principles of Project Management. 324. •108.

(109) Minimal Specification . Benefits . . Improved morale and motivation Opportunistic efficiency Shorter requirements phase. Costs and Risks . Omission of key requirements Unclear or impossible goals Gold plating Used for the wrong reasons . . Lazy substitute for doing good requirements. Success Factors . Used only when requirements are flexible Capture most important items; involve key users Principles of Project Management. 325. Requirements Scrubbing . Removing a feature from the product . . Eliminates all effort: spec., design, dev., test, doc. The earlier the better Typically done during or right after Requirements. Less risky than minimal specification Aims . Eliminate all but absolutely necessary requirements Simplify all complicated requirements Substitute cheaper items. Principles of Project Management. 326. Versioned Development . Eliminate them from the current version “Let’s put it in release 1.1” . . You’re still saying “Yes”, not “No”. By next rev. the list has changed anyway My favorite. Principles of Project Management. 327. •109.

(110) Mid-Project Feature-Creep . . Avg. project has 25% change in requirements during development Sources of change . . Marketing: want to meet customer’s check-list Developers: want to perfect r1 deficiencies Users: want more functionality or now ‘know’ what they want. They will all try to ‘insert’ these during dev.. Principles of Project Management. 328. Mid-Project Feature-Creep . . The devil is in the details McConnell’s example: “trivial” feature can have +/weeks of impact Developers can insert things when you’re not looking No spec. can cover all details. You must. Programmer ideal: flip switch- Word -> Excel Up to 10-1 differences in prog. size w/same specs.. Principles of Project Management. 329. Change Control Board (CCB) . McConnell “best practice” Structure: representatives from each stakeholder party . . . . . Importance, priority, cost, benefit. Triage . . Dev., QA, Marketing, Mgmt., Customer support. Perform “change analysis”. Allocating scare resources Some will not receive treatment Life-critical to the project. Will say “No” more than “Yes” Watch for bureaucracy. Principles of Project Management. 330. •110.

(111) Change Control. CM System. Change Control System. CM Tool. “Quality Software Project Management”, Futrell, Shafer, Shafer. Principles of Project Management. 331. Configuration Control . A management support function Includes . Program code changes Requirements and design changes Version release changes. . Essential for developed items. . Example. . . Code, documentation, etc. The case of the code that used to work . But didn’t in time for the demo. Principles of Project Management. 332. Configuration Control Terminology . Software Configuration Control Item (SCCI) . a.k.a. Source Item (SI) Anything suitable for configuration control Source code, documents, diagrams, etc.. . Change Control: process of controlling changes. . Version Control: controlling software version releases. . . . Proposal, evaluation, approval, scheduling, implementation, tracking Recording and saving releases Documenting release differences. Configuration Control: process of evaluating, approving and disapproving, and managing changes to SCCIs.. Principles of Project Management. 333. •111.

(112) SCM . Software Configuration Management Formal engineering discipline Methods and tools to identify & manage software throughout its use. Principles of Project Management. 334. Configuration Control Needs . Establish clearly defined mgmt. Authority Setup control standards, procedures and guidelines . . All team members must be aware of these. Requires appropriate tools and infrastructure Configuration Management Plan must be produced during planning phase . Often part of Software Development Plan. Principles of Project Management. 335. Maintenance . . SCM is very important during all phases starting with Requirements Continues to be important during Maintenance. Principles of Project Management. 336. •112.

(113) SOFTWARE PROJECT MANAGEMENT. Session 8: Development Management. Principles of Project Management. 337. Feature Set Control . Minimal Specification Requirements Scrubbing Versioned Development Effective Change Control Feature Cuts. Principles of Project Management. 338. Change Control . . Average project has 25% requirements change Sources of change Change control is a process Overly detailed specs. or prolonged requirements phase are not the answer Change Control Board (CCB) . Structure, process, triage. Principles of Project Management. 339. •113.

(114) Configuration Control . Items: code, documents Change & Version control SCM Configuration Management Plan Maintenance. Principles of Project Management. 340. Project Roles . Programmers (system engineers) . . . . QA Manager, QA Lead, QA staff. DBAs . . Technical lead, architect, programmer, Sr. programmer. Quality Assurance (QA) engineers (testers). 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 Principles of Project Management. 341. Project Roles . . 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. Principles of Project Management. 342. •114.

(115) Staffing Profile . . Projects do not typically have a ‘static team size’ Who and how many varies as needed. Copyright: Rational Software 2002. Principles of Project Management. 343. Roll-on & Roll-off . 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. Principles of Project Management. 344. Staffing Management Plan . 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. . Team size: often dictated by budget as often as any other factor. . Simply a list of those involved with contact info.. Principles of Project Management. 345. •115.

(116) Team Structure . 1st: What’s the team’s objective? . Problem resolution . . Creativity . . Complex, poorly-defined problem Focuses on 1-3 specific issues Ex: fixing a showstopper defect Sense of urgency New product development. Tactical execution . Carrying-out well-defined plan Focused tasks and clear roles. Principles of Project Management. 346. Team Models . Two early philosophies . . Decentralized/democratic Centralized/autocratic. Variation . Controlled Decentralized. Principles of Project Management. 347. Team Models . 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 See Weinberg’s “egoless programming” model. Principles of Project Management. 348. •116.

(117) Team Models . 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. Principles of Project Management. 349. Team Models . SWAT Team . Highly skilled team Skills tightly match goal Members often work together Ex: security swat team, Oracle performance team. Principles of Project Management. 350. Team Models . 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. Principles of Project Management. 351. •117.

(118) Team Size . 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. Principles of Project Management. 352. Responsibility Assignment Matrix . . 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). Principles of Project Management. 353. Principles of Project Management. 354. Simple RAM. •118.

(119) Sample RAM With Stakeholders. Principles of Project Management. 355. Skills Matrix . 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.). Principles of Project Management. 356. Capability Maturity Model: CMM . 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’. . Links: SEI, Diagram, Levels, Drexel. . . Later to be used as a marketing or validation tool. Principles of Project Management. 357. •119.

(120) CMM Levels . 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. Principles of Project Management. 358. CMM Levels . 4. Managed . . Detailed metrics of process & quality Quantitative control. 5. Optimizing . Continuous process improvement Using quantitative feedback. Principles of Project Management. 359. Tools . Requirements Tools Design Tools Construction Tools Test Tools Maintenance Tools CM Tools. Principles of Project Management. 360. •120.

(121) Tools . Tools could save 10-25% on some projects. . Choose tools to meet your needs No can guarantee you anything. . . . But that’s optimistic at best. They *may* help Tools don’t control people, especially customers. Principles of Project Management. 361. Programming Languages . Your projects: do you choose a language? Typically not the PM’s choice, but does effect you . Staffing requirements Methodology Tools and infrastructure. Principles of Project Management. 362. Requirements . Requirements are capabilities and condition to which the system – more broadly, the project – must conform. Principles of Project Management. 363. •121.

(122) Requirements . Perhaps most important & difficult phase Shortchanging it is a ‘classic mistake’ Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR) . For Sponsor and/or customer(s) approval. Principles of Project Management. 364. Why are Requirements so Important?. Principles of Project Management. 365. Requirements . Characteristics & Issues . Conflict of interest: developer vs. customer Potential tug-of-war: . . . Disagreement on Features & Estimates Especially in fixed-price contracts. Frequent requirements changes Achieving sign-off. Project planning occurs in parallel. Principles of Project Management. 366. •122.

(123) 2 Types of Requirements . Functional (behavioral). . Non-functional (a.k.a. “technical”) (everything else). . . . . . . Features and capabilities Usability Human factors, help, documentation Reliability Failure rates, recoverability, availability Performance Response times, throughput, resource usage Supportability Maintainability, internationalization Operations: systems management, installation Interface: integration with other systems Other: legal, packaging, hardware Principles of Project Management. 367. Requirements . Must be prioritized . . Must-have Should-have Could-have (Nice-to-have: NTH). Must be approved. Principles of Project Management. 368. Requirements . Used by many people for many purposes Purposes . Management: Yes, that’s what I funded Users: Yeah, that’s what I need Developers: Yes, that’s I will build. Principles of Project Management. 369. •123.

(124) Requirements . The “What” phase Inputs: SOW, Proposal Outputs: . Requirements Document (RD) . . a.k.a.Requirements Specification Document (RSD) Software Requirements Specification (SRS). 1st Project Baseline Software Project Management Plan (SPMP) Requirements Approval & Sign-Off . Your most difficult task in this phase. Principles of Project Management. 370. Requirements . . “There’s no sense being exact about something if you don’t even know what you’re talking about” John von Neumann “When the map and the territory don’t agree, always believe the territory”, taught to all Swedish army recruits. Principles of Project Management. 371. Requirements Gathering Techniques . Interviews Document Analysis Brainstorming Requirements Workshops Prototyping Use Cases Storyboards There are moreY. Principles of Project Management. 372. •124.

(125) Interview Techniques . Best practice: use ‘context free’ questions . . A question that does not suggest a response High-level, early questions to obtain ‘global’ properties of the problem and solution Applicable to any project/product Get the ball rolling. Principles of Project Management. 373. Context-free Questions . Process, product and meta questions Process . . Product . . “Who is the client for project X”? “What is a very successful solution really worth to the client”? “What is the reason for this project”? “ What problems does this system solve”? “What problems could this system create”?. Meta-questions . “Are these questions relevant”? “Is there anyone else who can give useful answers”? “Is there anything you want to ask me”?. Principles of Project Management. 374. Document Analysis . Review of existing documents . Business plans Market studies Contracts Requests for proposals (RFP) Statements of work (SOW) Existing guidelines Analyses of existing systems and procedures. Principles of Project Management. 375. •125.

(126) Brainstorming . Idea generation & idea reduction Typically via group meetings Generation Best practices . Minimize criticism and debate. . Aim for quantity Mutate or combine ideas. . . . Editing occurs at end of meeting or later. Reduction best practices . Voting with a threshold (N votes/person) Blending ideas Applying criteria Scoring with a weighting formula. Principles of Project Management. 376. Requirements Workshops . Typically 1-5 days Who? Varies. Users & stakeholders Pros . . Good for consensus building Builds participant commitment Can cost less than numerous interviews Provide structure to capture and analysis process Can involve users across organizational boundaries Can help identify priorities and contentious issues. JAD . A type of requirements workshop using a facilitator. Principles of Project Management. 377. Prototyping . . Quick and rough implementation Good communications mechanism Can be combined with other techniques such as JAD Issues: creating the mis-appearance that development is more complete than it actually is . See joelonsoftware’s “The Iceberg Secret Revealed”. Principles of Project Management. 378. •126.

(127) Use Cases . Picture plus description Often misunderstood: the text is more important Diagrams Text structure . . Use case name and number (ID) Goal Pre-conditions Primary & secondary actors Trigger Description Business rules Open issues. For good examples, see usecases.org. Principles of Project Management. 379. Storyboards . Set of drawings depicting user activities Paper prototyping Drawing screens or processes. Principles of Project Management. 380. Requirements: Who? . Customers and users (note: often not the same) . . Customers can be users, but rarely opposite Sometimes user constituencies need to be ‘found’. Subject matter experts Other stakeholders . Marketing, sales Product managers. Principles of Project Management. 381. •127.

(128) Other Requirements Tips . Meetings . Treat them like a tool: design them Boy scout motto: “Be Prepared” As small as possible – but no smaller Make it safe not to attend . . Publish an agenda before Publish a summary after. Generate a ‘related issues’ list Can formal/informal, scheduled/ad-hoc. Principles of Project Management. 382. Other Requirements Tips . Manage expectations . Don’t forget to ask people theirs Listen Make explicit otherwise implicit decisions . . PDA: Possibility, Deferred, Absolutely impossible. Technical reviews . Requirements can be wrong by: inadequate or inaccurate . . Quantity & quality. Reviews help with the latter. Principles of Project Management. 383. Requirements Tools . Starbase: CaliberRM Telelogic: DOORS Databases of requirements Displayable in various formats Optional requirements control metrics: . Requirements Stability Index . To help manage feature creep and ‘vibration’. Principles of Project Management. 384. •128.

(129) The MS-Project Process . Move WBS into a Project outline (in Task Sheet) Add resources (team members or roles) Add costs for resources Assign resources to tasks Establish dependencies Refine and optimize Create baseline Track progress (enter actuals, etc.). Principles of Project Management. 385. Project Overview . . This is a ‘quickie’ overview We will return to all of these steps individually over the next few weeks Sample project from McConnell. Principles of Project Management. 386. Project UI . Views . Default is Gant Chart View . . 2 panes Task Sheet on left (a table) Gantt Chart on right. View Bar on far left. Principles of Project Management. 387. •129.

(130) Project UI (Un)Link Buttons. Toolbars. Outline Buttons. Indicators Timescale. Enter Tasks Here. Gantt Chart View Bar. Task Bars Task Sheet Milestone. Split Bar. Principles of Project Management. 388. Create Your Project . File/New Setup start date Setup calendar . Menu: Project/Project Information Often left with default settings Hours, holidays. Principles of Project Management. 389. Enter WBS . . Outlining Sub-tasks and summary tasks Do not enter start/end dates for each Just start with Task Name and Duration for each Use Indent/Outdent buttons to define summary tasks and subtasks You can enter specific Start/End dates but don’t most of the time. Principles of Project Management. 390. •130.

(131) Establish Durations . Know the abbreviations . h/d/w/m D is default. . Can use partial. . Elapsed durations Estimated durations. . . . .5d is a half-day task. Put a ‘?’ after duration. Principles of Project Management. 391. Add Resources . Work Resources. . Material Resources. . . People Things Can be used to track costs . . Ex: amount of equipment purshased. Not used as often in typical software project. Principles of Project Management. 392. Resource Sheet . Can add new resources here . Or directly in the task entry sheet . . Beware of mis-spellings (Project will create near-duplicates). Setup costs . Such as annual salary (put ‘yr’ after ‘Std. Rate’). Principles of Project Management. 393. •131.

(132) Effort-Driven Scheduling . MS-Project default Duration * Units = Work . . Adding more resources to a task shortens duration Can be changed on a per-task basis . . Duration = Work / Units (D = W/U) Work = Duration * Units (W = D*U) Units = Work / Duration (U = W/D). In the advanced tab of Task Information dialog box Task Type setting. Beware the Mythical Man-month . Good for laying bricks, not always so for software development Principles of Project Management. 394. Link Tasks . On toolbar: Link & Unlink buttons. . Or via Gantt chart. . . Good for many at once Drag from one task to another. Principles of Project Management. 395. Milestones . Zero duration tasks Insert task ‘normally’ but put 0 in duration. Principles of Project Management. 396. •132.

(133) Make Assignments . Approach 1. Using Task Sheet . . Using Resource Names column You can create new ones by just typing-in here. 2. Using Assign Resources dialog box . Good for multiple resources Highlight task, Tools/Resources or toolbar button. . 3. Using Task Information dialog. . 4. Task Entry view. . . Resources tab View/More Views/Task Entry Or Task Entry view on Resource Mgmt. toolbar. Principles of Project Management. 397. Save Baseline . Saves all current information about your project . Dates, resource assignments, durations, costs. Principles of Project Management. 398. Fine Tune . . Then is used later as basis for comparing against “actuals” Menu: Tools/Tracking/Save Baseline. Principles of Project Management. 399. •133.

(134) Project 2002 . 3 Editions: Standard, Professional, Server MS Project Server 2002 . Upgrade of old “Project Central” Includes “Project Web Access”, web-based UI (partial) Workgroup and resource notification features Requires SQL-Server and IIS “Portfolio Analyzer” . . . Drill-down into projects via pivot tables & charts. “Portfolio Modeler” Create models and “what-if” scenarios. SharePoint Team Services integration. Principles of Project Management. 400. Project 2002 . MS-Project Professional . “Build Team” feature . . . Skills-based resource matching. Resource Pools: with skill set tracking Resource Substitution Wizard. “Project Guide” feature . Customizable “process component”. Principles of Project Management. 401. MS-Project Q&A . Your WBS in Project How did it go? Any questions?. Principles of Project Management. 402. •134.

(135) SOFTWARE PROJECT MANAGEMENT Session 9: Project Control. Principles of Project Management. 403. Project Control . Ongoing effort to keep your project on track 4 primary activities: . 1. Planning performance . . . Variances. 4. Taking corrective action as needed . . Actuals. 3. Comparing to baseline . . A SDP, schedule, and a control process. 2. Measuring status of work performed. Response. Prerequisite to good control is a good plan Principles of Project Management. 404. Project Control . “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 Principles of Project Management. 405. •135.

(136) Progress Monitoring . The 3 key Progress Monitoring Questions . . What is the actual status? If there’s a variance, what is cause? What to do about it?. Possible responses . 1. Ignore 2. Take corrective action 3. Review the plan. Principles of Project Management. 406. Progress Monitoring . 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. Principles of Project Management. 407. Status Reports . From team to PM, from PM to stakeholders. . Typical format for latter . Summary Accomplishments for this period (done) . . . Tasks, milestones, metrics. Plans for next period (to-do) Risk analysis and review Issues & Actions. Shoot for weekly updates . Email notes, then hold brief meeting More frequently during crises. Principles of Project Management. 408. •136.

(137) Programming Status Reporting . A programmer reports that he’s 90% done.. . A programmer reports completing 4,000 LOC on estimated 5,000 LOC effort.. . What does this mean?. . Is this 80% complete? Quality? Ratio, estimated to completed? . . Your estimates could have been wrong. If you can’t measure scope or quality you don’t know “reality” You really only know cost (hours spent) How can you improve this?. Principles of Project Management. 409. Binary Reporting . Work packages (tasks) can only be in one of 2 states: complete or incomplete. . Preferred to anything subjective! “90% Complete Syndrome”. . . . . No partial credit. Software is 90% complete 90% of the time. Use lower-level task decomposition Tangible exit criteria Plan for 4-80 staff hours of effort per task. Principles of Project Management. 410. Earned Value Analysis (EVA). . a.k.a. Earned Value Management (EVM) a.k.a. Variance Analysis Metric of project tracking “What you got for what you paid”. . Pre-EVA ‘traditional’ approach. . . Physical progress . . 1. Planned time and costs 2. Actual time and costs Progress: compare planned vs. actual. EVA adds third dimension: value . Planned, actual, earned Principles of Project Management. 411. •137.

(138) Earned Value Analysis . Forecasting . Old models include cost & expenditure EVA adds schedule estimation. . Measured in dollars or hours. . Performance Measurement Baseline (PMB). . Often time used in software projects . . Time-phased budget plan against which contract performance is measured Cost & schedule variances go against this Best via a bottom-up plan. Principles of Project Management. 412. Earned Value Analysis . Different methods are available . Binary Reporting Others include . . . Based on % complete Weights applied to milestones. EVA can signal errors as early as 15% into project Alphabet Soup. Principles of Project Management. 413. Earned Value Analysis . 3 major components . BCWS: Budgeted Cost of Work Scheduled . . BCWP: Budgeted Cost of Work Performed . . Now called “Planned Value” (PV) “Yearned” How much work should be done? Now called “earned value” (EV) “Earned” How much work is done? BCWS * % complete. ACWP: Actual Cost of Work Performed . Now called “Actual Cost” (AC) “Burned” How much did the work done cost? Principles of Project Management. 414. •138.

(139) Derived EVA Variances . SV: Schedule Variance . . CV: Cost Variance . . BCWP – ACWP Budgeted costs vs. actual costs. Negatives are termed ‘unfavorable’ Can be plotted on ‘spending curves’ . . BCWP – BCWS Planned work vs. work completed. Cumulative cost (Y axis) vs. Time (X axis) Typically in an ‘S’ shape. “What is the project status”? . You can use variances to answer this. Principles of Project Management. 415. Earned Value Analysis. Principles of Project Management. 416. Derived EVA Ratios . SPI: Schedule Performance Index. . CPI: Cost Performance Index. . . . BCWP / BCWS BCWP / ACWP. Problems in project if either of these less than 1 (or 100%). Principles of Project Management. 417. •139.

(140) Earned Value Analysis . Other Derived Values . BAC: Budget At Completion . . . Sum of all budges (BCWS). Your original budget.. EAC: Estimate At Completion Forecast total cost at completion EAC = ((BAC – BCWP)/CPI) + ACWP Unfinished work divided by CPI added to sunk cost If CPI < 1, EAC will be > BAC. CR: Critical Ratio . SPI x CPI 1: everything on track > .9 and < 1.2 ok Can be charted. Principles of Project Management. 418. EVA Example. As of 1-July where are we? BCWS BCWP ACWP. Principles of Project Management. 419. EVA Example. CV SV CPI SPI CR. Principles of Project Management. 420. •140.

(141) Earned Value Analysis . BCWS . Use ‘loaded labor’ rates if possible . . Direct pay + overhead. Remember it’s an aggregate figure . May hide where the problem lies Beware of counterbalancing issues . Over in one area vs. under in another. Principles of Project Management. 421. Earned Value Analysis . Benefits . Consistent unit of measure for total progress Consistent methodology . . . Across cost and completed activity Apples and apples comparisons. Ability to forecast cost & schedule Can provide warnings early. Success factors . A full WBS is required (all scope) Beware of GIGO: Garbage-in, garbage-out. Principles of Project Management. 422. The MS-Project Process . Move WBS into a Project outline (in Task Sheet) Add resources (team members or roles) Add costs for resources Assign resources to tasks Establish dependencies Refine and optimize Create baseline Track progress (enter actuals, etc.). Principles of Project Management. 423. •141.

(142) Project Overview . . This is a ‘quickie’ overview We will return to all of these steps individually over the next few weeks Sample project from McConnell. 424. Principles of Project Management. Project UI . Views . Default is Gant Chart View . . 2 panes Task Sheet on left (a table) Gantt Chart on right. View Bar on far left. 425. Principles of Project Management. Project UI (Un)Link Buttons. Toolbars. Outline Buttons. Indicators Timescale. Enter Tasks Here. Gantt Chart View Bar. Task Bars Task Sheet Milestone. Split Bar. Principles of Project Management. 426. •142.

(143) Create Your Project . File/New Setup start date Setup calendar . Menu: Project/Project Information Often left with default settings Hours, holidays. Principles of Project Management. 427. Enter WBS . . Outlining Sub-tasks and summary tasks Do not enter start/end dates for each Just start with Task Name and Duration for each Use Indent/Outdent buttons to define summary tasks and subtasks You can enter specific Start/End dates but don’t most of the time. Principles of Project Management. 428. Establish Durations . Know the abbreviations . h/d/w/m D is default. . Can use partial. . Elapsed durations Estimated durations. . . . .5d is a half-day task. Put a ‘?’ after duration. Principles of Project Management. 429. •143.

(144) Add Resources . Work Resources. . Material Resources. . . People Things Can be used to track costs . . Ex: amount of equipment purshased. Not used as often in typical software project. Principles of Project Management. 430. Resource Sheet . Can add new resources here . Or directly in the task entry sheet . . Beware of mis-spellings (Project will create near-duplicates). Setup costs . Such as annual salary (put ‘yr’ after ‘Std. Rate’). Principles of Project Management. 431. Effort-Driven Scheduling . MS-Project default Duration * Units = Work . . Adding more resources to a task shortens duration Can be changed on a per-task basis . . Duration = Work / Units (D = W/U) Work = Duration * Units (W = D*U) Units = Work / Duration (U = W/D). In the advanced tab of Task Information dialog box Task Type setting. Beware the Mythical Man-month . Good for laying bricks, not always so for software development Principles of Project Management. 432. •144.

(145) Link Tasks . On toolbar: Link & Unlink buttons. . Or via Gantt chart. . . Good for many at once Drag from one task to another. Principles of Project Management. 433. Milestones . Zero duration tasks Insert task ‘normally’ but put 0 in duration. Principles of Project Management. 434. Make Assignments . Approach 1. Using Task Sheet . . Using Resource Names column You can create new ones by just typing-in here. 2. Using Assign Resources dialog box . Good for multiple resources Highlight task, Tools/Resources or toolbar button. . 3. Using Task Information dialog. . 4. Task Entry view. . . Resources tab View/More Views/Task Entry Or Task Entry view on Resource Mgmt. toolbar. Principles of Project Management. 435. •145.

(146) Save Baseline . Saves all current information about your project . Dates, resource assignments, durations, costs. Principles of Project Management. 436. Fine Tune . . Then is used later as basis for comparing against “actuals” Menu: Tools/Tracking/Save Baseline. Principles of Project Management. 437. Project 2002 . 3 Editions: Standard, Professional, Server MS Project Server 2002 . Upgrade of old “Project Central” Includes “Project Web Access”, web-based UI (partial) Workgroup and resource notification features Requires SQL-Server and IIS “Portfolio Analyzer” . . . Drill-down into projects via pivot tables & charts. “Portfolio Modeler” Create models and “what-if” scenarios. SharePoint Team Services integration. Principles of Project Management. 438. •146.

(147) Project 2002 . MS-Project Professional . “Build Team” feature . . . Skills-based resource matching. Resource Pools: with skill set tracking Resource Substitution Wizard. “Project Guide” feature . Customizable “process component”. 439. Principles of Project Management. SOFTWARE PROJECT MANAGEMENT Session 10: Integration & Testing. Principles of Project Management. 440. Deliverables by Phase Possible Deliverables by Phase Concept Document Statement of W ork (SOW ) Project Charter RFP & Proposal Software Concept. Requirements Document (Software Requirements Specification) Work Breakdown Structure (W BS) Functional Specification ( Top Level Design Specification) Entity Relationship Diagram Data Flow Diagram. Requirements. Analysis . Project Development Plan (Software Development Plan ) Baseline Project Plan Quality Assurance Plan Configuration Management Plan Risk Management Plan. Detailed Design Specification Object Diagrams Detailed Data Model Design. Coding Standards Working Code Unit Tests Coding and Debugging. Integration Plan Detailed SQA Test Plan SQA Test Cases. Acceptance Test Procedures Tested Application Systems Testing. User Documentation Training Plan. Maintenance Specification Deployed Application Deployment & Maintenance. Principles of Project Management. 441. •147.

(148) Development Costs. 7% 29%. Requirements 16%. Preliminary Design Detailed Design Code & Unit Test. 24% Integration & System Test. 24%. Principles of Project Management. 442. Integration & Testing . Development/Integration/Testing . . . Most common place for schedule & activity overlap. Sometimes Integration/Testing thought of as one phase Progressively aggregates functionality QA team works in parallel with dev. team. Principles of Project Management. 443. Integration Approaches . Top Down . Core or overarching system(s) implemented 1st Combined into minimal “shell” system “Stubs” are used to fill-out incomplete sections . . Eventually replaced by actual modules. Bottom Up . . Starts with individual modules and builds-up Individual units (after unit testing) are combined into sub-systems Sub-systems are combined into the whole. Principles of Project Management. 444. •148.

(149) Integration . Who does integration testing?. . Staffing and budget are at peak “Crunch mode” Issues. . . Can be either development and/or QA team. . Pressure Delivery date nears Unexpected failures (bugs) Motivation issues User acceptance conflicts. Principles of Project Management. 445. Validation and Verification. . V&V Validation. . Verification. . . . Are we building the right product? Are we building the product right? Testing Inspection Static analysis. Principles of Project Management. 446. SQAP . Standard sections . Purpose Reference documents Management Documentation Standards, practices, conventions, metrics . Quality measures Testing practices. Principles of Project Management. 447. •149.

(150) SQAP (Software Quality Assurance Plan) . Standard sections continued . Reviews and Audits . Process and specific reviews . . Risk Management . . Requirements Review (SRR) Test Plan Review Code reviews Post-mortem review. Tie-in QA to overall risk mgmt. Plan. Problem Reporting and Corrective Action Tools, Techniques, Methodologies Records Collection and Retention. Principles of Project Management. 448. Software Quality . Traceability . . Ability to track relationship between work products Ex: how well do requirements/design/test cases match. Formal Reviews . Conducted at the end of each lifecycle phase SRR, CDR, etc.. Principles of Project Management. 449. Testing . . . Exercising computer program with predetermined inputs Comparing the actual results against the expected results Testing is a form of sampling Cannot absolutely prove absence of defects All software has bugs. Period. Testing is not debugging.. Principles of Project Management. 450. •150.

(151) Test Cases . Key elements of a test plan May include scripts, data, checklists May map to a Requirements Coverage Matrix . A traceability tool. 451. Principles of Project Management. Rework . Software equivalent of “scrap” in manufacturing. 30% 25% 8%. 20% 4%. Rew ork Production. 10% 1% 5%. 19%. 12%. 15%. 16% 12%. 12%. 10%. 6%. 0% Requirements. Detailed Design. Integration & System Test. 452. Principles of Project Management. Sources of Defects. 27%. Design Other Code. 56%. 10%. Requirements. 7%. Principles of Project Management. 453. •151.

(152) V Process Model Project Requirements and Planning. Non-functional Requirements. Product Requirements and Specification Analysis. Production, Operations, and Maintenance. Load & Performance Test. User Interface Design. Usability Test. System Testing and Acceptance Testing. Integration and Testing. High-Level Desig. Detailed Design. Unit Testing. Coding. Principles of Project Management. 454. Project Testing Flow . Unit Testing Integration Testing System Testing User Acceptance Testing. Principles of Project Management. 455. Black-Box Testing . Functional Testing Program is a “black-box” . . Not concerned with how it works but what it does Focus on inputs & outputs. Test cases are based on SRS (specs). Principles of Project Management. 456. •152.

(153) White-Box Testing . Accounts for the structure of the program Coverage . Statements executed Paths followed through the code. Principles of Project Management. 457. Unit Testing . a.k.a. Module Testing Type of white-box testing. . Who does Unit Testing?. . . Sometimes treated black-box . Developers Unit tests are written in code . . Same language as the module a.k.a. “Test drivers”. When do Unit Testing? . Ongoing during development As individual modules are completed. Principles of Project Management. 458. Unit Testing . Individual tests can be grouped. . JUnit. . “Test Suites” . Part of the XP methodology “Test-first programming”. Principles of Project Management. 459. •153.

(154) Integration Testing . . . Testing interfaces between components First step after Unit Testing Components may work alone but fail when put together Defect may exist in one module but manifest in another Black-box tests. Principles of Project Management. 460. System Testing . Testing the complete system A type of black-box testing. Principles of Project Management. 461. User Acceptance Testing . . Last milestone in testing phase Ultimate customer test & sign-off Sometimes synonymous with beta tests Customer is satisfied software meets their requirements Based on “Acceptance Criteria” . . Conditions the software must meet for customer to accept the system Ideally defined before contract is signed Use quantifiable, measurable conditions. Principles of Project Management. 462. •154.

(155) Regression Testing . . . Re-running of tests after fixes or changes are made to software or the environment EX: QA finds defect, developer fixes, QA runs regression test to verify Automated tools very helpful for this. Principles of Project Management. 463. Compatibility Testing . Testing against other “platforms” . Ex: Testing against multiple browsers Does it work under Netscape/IE, Windows/Mac. Principles of Project Management. 464. External Testing Milestones . Alpha 1st, Beta 2nd Testing by users outside the organization. . Alpha release. . . . . Typically done by users Given to very limited user set Product is not feature-complete. During later portions of test phase Beta release . Customer testing and evaluation Most important feature Preferably after software stabilizes. Principles of Project Management. 465. •155.

(156) External Testing Milestones . Value of Beta Testing . Testing in the real world Getting a software assessment Marketing Augmenting you staff. . Do not determine features based on it. . Beta testers must be “recruited”. . Requires the role of “Beta Manager” All this must be scheduled by PM. . . . Too late! From: Existing base, marketing, tech support, site. Principles of Project Management. 466. External Testing Milestones . Release Candidate (RC) . To be sent to manufacturing if testing successful. . Release to Manufacturing (RTM). . Aim for a “stabilization period” before each of these milestones. . . Production release formally sent to manufacturing. Team focus on quality, integration, stability. Principles of Project Management. 467. Test Scripts. . Two meanings 1. Set of step-by-step instructions intended to lead test personnel through tests. . 2. Automated test script (program). . . List of all actions and expected responses. Principles of Project Management. 468. •156.

(157) Static Testing . Reviews . . Most artifacts can be reviewed Proposal, contract, schedule, requirements, code, data model, test plans. Peer Reviews . . Methodical examination of software work products by peers to identify defects and necessary changes Goal: remove defects early and efficiently Planned by PM, performed in meetings, documented CMM Level 3 activity. Principles of Project Management. 469. Automated Testing . Human testers = inefficient Pros . . Lowers overall cost of testing Tools can run unattended Tools run through ‘suites’ faster than people Great for regression and compatibility tests Tests create a body of knowledge Can reduce QA staff size. Cons . But not everything can be automated Learning curve or expertise in tools Cost of high-end tools $5-80K (low-end are still cheap) Principles of Project Management. 470. Test Tools . Capture & Playback Coverage Analysis Performance Testing Test Case Management. Principles of Project Management. 471. •157.

(158) Load & Stress Testing . Push system beyond capacity limits Often done via automated scripts . . By the QA team Near end of functional tests. Can show . Hidden functional issues Maximum system capacity Unacceptable data or service loss Determine if “Performance Requirements” met . Remember, these are part of “non-functional” requirements. 472. Principles of Project Management. Load & Stress Testing . Metrics . . Minimal acceptable response time Minimal acceptable number of concurrent users Minimal acceptable downtime. Vendors: High-End . Segue Mercury Empirix. 473. Principles of Project Management. Performance Metrics Bad. Good. Must support 500 users Must support 500 simultaneous users 10 second response time. [Average|Maximum|90th percentile] response time must be X seconds. Must handle 1M hits per Must handle peak load day of 28 page requests per second Source: Athens Consulting Group. Principles of Project Management. 474. •158.

(159) Other Testing . Installation Testing . . Very important if not a Web-based system Can lead to high support costs and customer dissatisfaction. Usability Testing . Verification of user satisfaction . Navigability User-friendliness Ability to accomplish primary tasks. Principles of Project Management. 475. SOFTWARE PROJECT MANAGEMENT Session 11: Final Stages. Principles of Project Management. 476. Resource Leveling . Techniques . Activity shifting. . Activity splitting. . Activity stretching. . . . Move start/end dates forward or backward Break an activity into two or more pieces Use less of a given resource continuously. . Resource substitution. . Allocating overtime. . . Assign a different resource Work resources longer. Principles of Project Management. 477. •159.

(160) Migration . Moving users from existing system to your new one. Principles of Project Management. 478. Migration Plan . Includes . . . Description of environment (computers, DBs, interfaces) Description of existing data needed Description of operational constraints (ex: when can we move to the new system? Weekends only? Last week of month only?) List of affected organizations and contacts Plan of steps to be taken. Principles of Project Management. 479. Migration Plan . Does it require a service interruption?. . Training? Is there a helpdesk?. . . . If so, when does this happen? A weekend?. If do, do they have “scripts” or new material?. Principles of Project Management. 480. •160.

(161) Migration Strategies . Communication with customers is crucial . . What is happening, when, and why “Why” should remind them of the benefits Not too much detail or too little Where do customers go for more information?. Minimize intrusiveness Find-out about customer’s key dates . When does the system absolutely need to be stable? Know about their important deadline dates They must buy-into the approach!. Principles of Project Management. 481. Migration Strategies . 1. Flash-Cut . Straight-move from old system to new A) Immediate Replacement . . B) Parallel Operation . . Fastest approach Still want a back-out plan Requires strong planning and testing Mitigates risk Parallel to either existing manual or system process Cut occurs once new system “burned-in”. 2. Staged . Replace one part of existing system at a time. Principles of Project Management. 482. Migration Strategies . Considerations: . Level of business disruption Degree of latitude in “production” date How much internal opposition to system is there? . . If higher, perhaps a longer ‘adjustment’ period. Your comfort level of system quality . If questionable, may want to mitigate risk. Principles of Project Management. 483. •161.

(162) Cutover . Criteria: What conditions must be met prior? Responsibility: Who decides? Operations: Who ‘owns’ it once it’s live? Rehearsals: Sometimes used.. Principles of Project Management. 484. Flash-Cut . Immediate Replacement. . Requires very careful planning & testing Still try to get some users to “try” it first if possible Develop a back-out plan. . . . Ex: new corporate-wide calendaring system. Principles of Project Management. 485. Back-Out Plan . Especially important for “conversions” . . . . Customers already have expectations and needs as defined by their existing system Must be able to restore customer’s service ASAP. May mean running both simultaneously “just in case” Leave it in place for awhile (more than a day!) When to fall-back? . Mgmt: sooner, Tech: one-more-fix Set a time limit (ex: 3 hours of start). Principles of Project Management. 486. •162.

(163) Data Conversion . Quote: . . . . If you add a cup of champagne to a barrel of sewage, you’ll have a barrel of sewage If you add a cup of sewage to a barrel of champagne, you’ll have a barrel of sewage. Most systems need this step Most PMs forget this Impacts both completely new and replacement systems The “data” often more valuable than the “system”. Principles of Project Management. 487. Data Conversion Areas . Data Sources: . . Process Controls: . . Where does it come from? Do you need to modify data on the way in? Is it accurate? Does it happen all at once? How do you guarantee it’s been done correctly?. Completion: . How do you handle any ‘exceptions’? Do you make backups? Can you restart?. Principles of Project Management. 488. Parallel Operation . Multiple variations of this method An “adoption” period . . See telephone industry w/new area codes Both work for a period of time. Strategies . Avoid flash-cuts if possible . Start with test subjects. Principles of Project Management. 489. •163.

(164) Rollout . Create a “Release Checklist” . Avoid activities falling through the cracks Example Activities by Group: . . . Engineering, QA, Documentation, Operations. Possibly sign-off signatures. Roll-out: Must have a plan for the process . Often on a given day (ex: a Sat.) Must be a very detailed plan. Principles of Project Management. 490. Training . Often more than just end-users . Users Sales & Marketing staff System operators Maintenance engineers (possibly) Sales engineers (possibly). Principles of Project Management. 491. Documentation . Must be ready by ship-date Final user documentation Updates to other . Operations documentation Development documentation Sales and marketing material Wed site Test reports. Principles of Project Management. 492. •164.

(165) Shipping Details . Packaging (if commercial product) Marketing collateral Security mechanisms (if commercial product) Licensing . Plan Mechanism. Principles of Project Management. 493. Installation . Scripts Uninstall (if not Web-based) If you need to install your software (as on PCs): . Don’t underestimate: . . Time this takes to develop Importance of a “first impression”. Or, if “custom” software you’re reselling . Installation at site is often a “mini-project”. Principles of Project Management. 494. Project Recovery . How to save a “drowning project” 3 Approaches . 1. Cut the size of the software 2. Increase process productivity 3. Slip the schedule, proceed with damage control. . Opportunity for decisive leadership action Not a time to ‘just cut corners’. . Timing: politically important. . . . Be realistic (not foolish) Not too early, not “too” late. Principles of Project Management. 495. •165.

(166) Project Recovery . Steps . Assess situation . . Is there a hard deadline, what’s negotiable, etc.. Don’t do what’s been done already Ask team what needs to be done. People Steps . Restore morale . . Sacrifice a sacred cow Dress code, off-site, catered meals, etc Cleanup personnel problems. Focus people’s time . Remove non-essential work. Principles of Project Management. 496. Project Recovery . Process Steps . Fix classic mistakes . . . . Inadequate design, shortchanged activities, etc?. Create “Miniature Milestones” Small (in day(s)), binary, exhaustive Boosts morale: getting things done!. Track progress meticulously Recalibrate after a short time Manage risk painstakingly. Principles of Project Management. 497. Project Recovery . Product Steps . Stabilize the requirements Raise the bar on change requests Trim the feature set . . . . Determine priorities, cut the low ones. “Take out the garbage” Find error-prone modules; re-design. Get to a known, stable state & build from there. Principles of Project Management. 498. •166.

(167) SOFTWARE PROJECT MANAGEMENT Session 12: Project Success. Principles of Project Management. 499. Concluding Software Projects . Seems simple, often isn’t Potential Issues . Last-minute change requests . . . . “One more feature”. Disputes of fulfillment of all requirements Often “interpretation” issues. Keeping the team motivated Difficult transition to maintenance. Principles of Project Management. 500. Maintenance Phase . The “No respect” phase Less “glamorous”. . Pressure to make fixes quickly. . Software can become “hacked” “patchwork” over time Finding a support & test platform can be difficult. . . . . . Lack of enthusiasm For “production” problems. Often the forgotten child until fixes are needed. Principles of Project Management. 501. •167.

(168) Maintenance Phase . Compare to hardware maintenance . Not to keep state same; but changes to state Fixes and enhancements. . Configuration control is very important. . Project management not always carried over Smaller team. . . . Fixing the “right” version; tracking branches. Often not a ‘dedicated team’ Drawn from developer with other main tasks. Principles of Project Management. 502. Maintenance Phase . Contracts, remember those? . Always consider the maintenance phase here Often via a “labor hours” contract . . . . Time & materials in a “direct” scenario. Otherwise via “maintenance contract” Percentage of software license fee Ex: 20% of original cost per year. Corp. budget if internal/IS projects . Often annual/monthly “maintenance” allocations. Principles of Project Management. 503. Success Metrics . 1. On schedule. . 2. Within budget. . 3. According to requirements. . . . Requires good: plan; estimation; control Again: planning, estimation & control Importance of good requirements Perception & negotiation critical. Principles of Project Management. 504. •168.

(169) You are not Santa Claus . Learn to say “No”. . The Value of Versions. . . . Be polite but firm “We will put that in phase 2”. An Ounce of Prevention. 505. Principles of Project Management. Think Small . Keep requirements tight & focused One milestone at a time Smaller, incremental chunks As simple as possible but no simpler. 506. Principles of Project Management. Process Spectrum . Too much medicine can kill the patient Process Spectrum. Bureauracracy. Chaos. • Balance is crucial Principles of Project Management. 507. •169.

(170) Paralysis . Analysis Paralysis . . Over-process Nothing gets finished 65% of software professionals have experienced this. Paralysis Paranoia . Fear of over-process = process avoidance. Principles of Project Management. 508. Miscellaneous . MBWA . Management by Walk About . Shows your actually involved day-to-day Recognizes individuals may say more 1-on-1 Allows spontaneity Finds personnel problems sooner. Principles of Project Management. 509. Delegate . Don’t be a “Control Freak” You need to be the “hub” but not everything. Principles of Project Management. 510. •170.

(171) Success Rates . By Industry . Best: Retail . . Tight cost controls in general. Worst: Government . Least cost controls. . By Size. . Stats. . Smaller is better: cost, duration, team. Principles of Project Management. 511. Project Home Page . . Give your project an intranet page Central repository for project status, documents and other resources McConnell’s example. Principles of Project Management. 512. Continuous Process Improvement. Herbsleb, 1994, “Benefits of CMM-Based Software Process Improvement”. Principles of Project Management. 513. •171.

(172) Risk Management . Risk Management. . Risk Identification. . Risk Analysis. . . Types of risk: schedule, cost, requirements Involve the team. . Risk Exposure (RE = Prob. * Size). . Probability is 15%, size is 10 weeks . . .15 * 10w = 1.5w. Risk Prioritization . 80-20 rule; large size or prob. 1st; grouping; ignoring. Principles of Project Management. 514. Risk Management . Risk Control. . Risk Resolution (5 Types). . . . Plan Avoidance (ex: scrub) Assumption (just monitor) Control (contingency) Knowledge Acquisition (learn/buy/prototype) Transfer (off project, team, critical path). Risk Monitoring . Top 10 Risk List (McConnell’s example). Principles of Project Management. 515. Requirements . Functional vs. Non-functional (technical) . Functional . . Features. Non-functional . Reliability Usability Performance Operations: systems management, installation Other: legal, packaging, hardware. Principles of Project Management. 516. •172.

(173) Requirements . Requirements gathering techniques . Interviews Document Analysis Brainstorming Requirements Workshops Prototyping Use Cases Storyboards. Principles of Project Management. 517. Teams . Start with objective. . Decentralized vs. Centralized Large teams. . Optimal size?. . Hiring. . . . . Problem resolution, creativity, tactical execution. Decompose via hierarchy, into optimal sizes 4-6 developers Hire for trait – train for skill. Principles of Project Management. 518. Team Models . Business team . . Chief-programmer team . . Off-site; pro: buy-in; con: minimal visibility. Feature team . . Surgical team; star at top; ego issues. Skunkworks team . . Technical lead + team; most common Can be strong or loose hierarchy. Interdisciplinary; balanced. SWAT team . Highly skilled/specialized; Ex: security team. Principles of Project Management. 519. •173.

(174) Resource Allocation . Responsibility Assignment Matrix. . Skills Matrix. . Hiring Guidelines. . . . . Who does What Who has what skills Hire for trait, train for skill Smart, gets things done. Balance. Principles of Project Management. 520. Feature Set Control . Minimal Specification Requirements Scrubbing Versioned Development Effective Change Control Feature Cuts. Principles of Project Management. 521. Change Control . . Average project has 25% requirements change Sources of change Change control is a process Overly detailed specs. or prolonged requirements phase are not the answer Change Control Board (CCB) . Structure, process, triage. Principles of Project Management. 522. •174.

(175) Configuration Control . Items: code, documents Change & Version control SCM Configuration Management Plan Maintenance. Principles of Project Management. 523. Exam Review . Project Roles Project Control . . Planning Measuring Evaluating Acting. Binary Reporting. Principles of Project Management. 524. Earned Value Analysis . BCWS BCWP . Earned value. . ACWP Variances. . Ratios. . . . . CV (BCWP – BCWS), SV (BCWP – ACWP) SPI (BCWP / BCWS), CPI (BCWP / ACWP) CR (SPI x CPI). Benefits . Consistency, forecasting, early warning. Principles of Project Management. 525. •175.

(176) CMM . Capability Maturity Model Five levels . . Initial Repeatable Defined Managed Optimizing. Links: Diagram, Levels Principles of Project Management. 526. Tools & Languages . Impact of platform and language choice . Staffing requirements Methodology . . . . Cobol != Java. Tools and infrastructure Software, hardware. Classic Mistake: silver bullet syndrome . Over-reliance/expectation on tool benefits. Principles of Project Management. 527. QA & Testing . Testing “Phases” . . Unit Integration System User Acceptance Testing. Testing Types . Black-box White-box. Principles of Project Management. 528. •176.

(177) QA & Testing . Static vs. Dynamic Testing Automated Testing . . Pros and cons. Defect tracking Integration: 2 types . Top down Bottom up. Principles of Project Management. 529. Defect Metrics . Open Bugs (outstanding defects). . Open Rates. . Close Rates. . . . Ranked by severity How many new bugs over a period of time How many closed over that same period Ex: 10 bugs/day. . Change Rate. . Fix Failed Counts. . . Number of times the same issue updated Fixes that didn’t really fix (still open) One measure of “vibration” in project. Principles of Project Management. 530. Migration and Rollout . Migration Strategies . 1. Flash Cut . . A. Immediate Replacement B. Parallel Operation. 2. Staged . One part at a time. Principles of Project Management. 531. •177.

(178) Exam Review – MS-Project . Effort-driven scheduling . Duration = Work / Units (D = W/U) Work = Duration * Units (W = D*U) Units = Work / Duration (U = W/D). Principles of Project Management. 532. Resource Leveling . 5 Leveling techniques . Activity shifting Activity splitting Activity stretching Resource substitution Allocating overtime. Principles of Project Management. 533. Migration . Migration Plan Importance of 2-way communication . . Find-out customer’s key dates. Minimize intrusiveness Back-out Plan Data Conversion. Principles of Project Management. 534. •178.

(179) Migration . Flash-Cut Migration . . Immediate Replacement Parallel Operation. Staged Migration. Principles of Project Management. 535. Other Final Steps . Roll-Out. . Training. . . Release Check-List More than just end-users . . Users, systems ops, maintenance developers, sales. Documentation . Many types: End-user, sales & marketing, operations, design. Principles of Project Management. 536. Project Recovery . 3 Approaches . 1. Cut the size of the software 2. Increase process productivity 3. Slip the schedule, proceed with damage control. . People Steps. . Process Steps. . Product Steps. . . . Morale; focus; re-assign Fix classic mistakes; mini-milestones Stabilize; trim features; take out the garbage. Principles of Project Management. 537. •179.

(180) Post Project Reviews . Focused on process not people Steps . Prepare survey form Email team with survey and schedule meeting . . Gather data. Conduct meeting Prepare PPR report. Principles of Project Management. 538. •180.

(181)

quan ly du an phan mem

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về