Software Project Management

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

2. Agenda • Software Project Planning • Software Project Estimation • Software Project Scheduling

3. Agenda • Software Project Planning • Software Project Estimation • Software Project Scheduling

4. 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.

5. 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

6. Planning FAQ • How much will it cost? • How long will it take? • How many people will it take? • What might go wrong?

7. Planning • Scoping • Estimation • Risk • Schedule • Control Strategy

8. Project Planning: A 12 Step Program • Set goal and scope • Select lifecycle • Set org./team form • Start team selection • Determine risks • Create WBS • Identify tasks • Estimate size • Estimate effort • Identify task dependencies • Assign resources • Schedule work

9. Your PM Process • Why • Deliverable: ROI • What • SOW, Requirements • How • Design Specification, SDP, Lifecycle • Do • Execution • Done • PPR Futrell, Shafer, Shafer, “Quality Software Project Management”

10. 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 Planning Document Product Document

11. 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

12. Planning Documents (cont.) • 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

13. Planning Documents (cont.) • Project ROI Analysis • Statement of Work (SOW) • Project Charter • Software Project Management Plan (SPMP) • Budget • Responsibility Assignment Matrix (RAM) • Risk Management Plan

14. Product Documents • Statement of Need • System Interface Specification • Software Requirements Specification • Software Design Specification • Software Validation & Verification Plan • User Documentation Support Plan Maintenance Documentation

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

16. Plans Evolve Over Time NASA’s “Manager’s Handbook for Software Development”

17. SDP / SPMP • Fundamental Sections • Project overview • Deliverables • Project organization • Managerial processes • Technical processes • Budget • Schedule • Example: ACID project

18. Process Planning

19. Risk Management Plan • Brainstorm potential risks • Estimate the impact of each risk • a rough estimate of the probability that the risk will occur • the potential impact of that risk on the project if it does eventually materialize • Make a mitigation plan • Alter the project plan • Add additional tasks • Plan for risks

20. 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

21. How To Schedule • 1. Identify “what” needs to be done • Work Breakdown Structure (WBS) • 2. Identify “how much” (the size) • Size estimation techniques • 3. Identify the dependency between tasks • Dependency graph, network diagram • 4. Estimate total duration of the work to be done • The actual schedule

22. WBS & Estimation • How did you feel when I asked • “How long will your project take?” • 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?

23. 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?

24. Project Elements • A Project: functions, activities, tasks

25. 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 • Development, Mgmt., and project support tasks • Shows “is contained in” relationships • Does not show dependencies or durations

26. 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

27. 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

28. WBS Chart Example

29. 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

30. WBS Types • Process WBS • a.k.a Activity-oriented • Ex: Requirements, Analysis, Design, Testing • Typically used by PM • Product WBS • 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

31. WBS Types (cont.) • 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

32. Product WBS

33. Process WBS

34. Outline WBS w/Gantt

35. Work Packages • Generic term for discrete tasks with definable end results • Typically the “leaves” on the tree • The “one-to-two” rule • Often at: 1 or 2 persons for 1 or 2 weeks • Basis for monitoring and reporting progress • 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

36. 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

37. 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

38. 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

39. WBS Techniques • Bottom-up • Start at lowest level tasks • Aggregate into summaries and higher levels • Cons • Time consuming • Needs more requirements complete • Pros • Detailed

40. 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

41. 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!)

42. WBS – Basis of Many Things • Network scheduling • Costing • Risk analysis • Organizational structure • Control • Measurement

43. 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

44. WBS Guidelines Part 2 • How detailed should it be? • Not as detailed as the final MS-Project plan • Each level should have no more than 7 items • It can evolve over time • What tool should you use? • Excel, Word, Project • Org chart diagramming tool (Visio, etc) • Specialized commercial apps • Re-use a “template” if you have one

45. Agenda • Software Project Planning • Software Project Estimation • Software Project Scheduling

46. 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 • Estimate the size of the product • Estimate the effort (man-months) • Estimate the schedule • NOTE: Not all of these steps are always explicitly performed

47. 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%

48. 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

49. Cone of Uncertainty

50. 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