1、Project Management,Planning, Work Breakdown, Tasks & Activities,Overview,Planning Foundations The Plan WBS LRC Project Charter,2,Planning,“Plans are nothing. But planning is everything.” Gen. Dwight Eisenhower,3,4,Project Phases,Time Allocation by Phase,Remember the 40-20-40 Rule Specification-Imple
2、mentation-Test,5,Bennatan, E.M, “On Time Within Budget”,Time Allocation by Phase,6,McConnell, Steve, “Rapid Development”,7,Activities by % of Total Effort,NASAs “Managers Handbook for Software Development”,8,Potential Deliverables by Phase,9,Project Integration Management Overview,Note: The PMBOK Gu
3、ide includes similar charts for each knowledge area.,Three Essential Elements of Project Planning,10,Objectives,Project Planning,Problem,Mission,Project Objectives Criteria,Specific Measurable Agreed upon Achievable Realistic Timebound,Demonstrable Understandable Deliverable Elevated Integrated Sing
4、ular,11,Foundation Elements For Software Projects,Software Projects Are Based On: Product Specifications: What to Make User Needs & Customer Expectations System Requirements Software Requirements Domain and Environmental Constraints Process Specifications: How to Make It Engineering Process Model Co
5、ntractual Obligations Workforce Competencies Project Plans,12,Project is Driven by an Agreement Between the Acquirer & Provider,The Acquirer is usually a Customer, another department or Product Management Customers will issue fixed price or time and materials contracts Departments will issue service
6、 level agreements & a budget Product Managers will issue a product spec supported by a business case driven by a market study A contract is a statement of understanding between a developer and an acquirer Every software project should have a contractual agreement Usually an acquirer will expect or d
7、emand a project plan that provides assurance of delivery and visibility into progress,13,Elements Of A Contractual Agreement,Scope of work Delivery date(s) and deliverables Joint review schedule Change request procedures Development constraints Acceptance criteria Work authorization procedures Deliv
8、ery, installation, and training schedule (if appropriate) Price and payment schedule If appropriate A Project Plan should address these agreement items.,14,Project “Elasticity” (initial position),15,Essential difficulties of developing software (companys challenge) + Inability to specify detailed re
9、quirements a priori (customers challenge) Imply: A fully constrained project not a realistic posture assures failure! Solution: Convince customer and senior management this is true Negotiate an elastic but constrained position that assures success (“win-win”),?,?,?,Project “Elasticity” (possible neg
10、otiated position),16,Customer wants to ensure a fixed price for the project Schedule is fixed with respect to “essential” requirements (TBD during project) but constrained with respect to “desirables” and “nice-to-have” requirements Scope with respect to “essential” requirements is fixed but there i
11、s flexibility with respect to desirable and “nice-to-have” requirements Company is ready to invest (to a point) in the project for future business opportunities,Project Plans,The Project Plan,The project plan is the road map A map tells you what route to follow Without a map you only know to “head r
12、oughly east; turn right at the Rocky Mountains” Without a map you do not know if you are making progress toward your destination If you get lost, a map can help you find the correct way But remember, if the map and the terrain are in disagreement, believe the terrain,18,Additional Plans,User Trainin
13、g Plan Installation and Conversion Plan User Support Plan Software Maintenance Plan Physical Security Plan Facilities Management Plan System Integration and Test Plan,19,These may be written up as separate plans but for smaller Projects these topics can be integrated as separate Sections in the Proj
14、ect Management Plan.,PM Plan What does it do?,A simulation of project work - early identification of “problematic” areas Definition and clarity of roles and work - provides “fit” and coordination Reference point for changes,20,Why Is A Project Plan Important?,To assess project feasibility To demonst
15、rate breadth and depth of planning To provide a vehicle for trade studies & negotiations To assess consistency of cost, schedule & estimates Provides a mechanism for assessing progress Provide a basis for controlling the project,21,Why Is Planning Not Adequately Done?,(Apparent) lack of time Lack of
16、 skills and tools Lack of information: Insufficient understanding of the project Inadequate requirements analysis Novelty of the project Insufficient historical data for planning Frequently heard excuses: “Why plan, when everything will change anyway?” “Excessive planning indicates a lack of confide
17、nce” “Im a doer, not a planner”,22,The Project Planning Space,23,The initial plan must achieve a balance among these factors, at an acceptable level of risk; any subsequent changes in one must be balanced by adjustments in one or both of the others,The Project Planning Space,The project planning spa
18、ce is characterized by: Schedule: time available to do the work Assets: resources available to do the work Budget: money available to acquire the resources Requirements: the work to be done Risk exposure: probability of failure x cost of failure,24,A Process Model For Managing Software Projects,25,p
19、roducts,Project Plan: Essential Elements Based on IEEE Std 1058 (QSPM: Appendix F also contains IEEE Std 1058 Details),Overview References Definitions Project Organization: Roles & Relationships Management Processes: Deliverable Work Products Tasks, Schedules, Resources, Budget Progress Metrics Risk
20、 Management Technical Processes: Processes, Methods & Tools Technical Product & Process Metrics Supporting Process Plans Additional Plans Annexes,26,Getting into the Details,A software project is (or should be) characterized by the following details: A one-time effort is planned Starting and ending
21、dates are prescribed Tasks & Activities Defined in terms of “Work Packages” Schedule and budget are planned Well-defined technical objectives & milestones are specified A project team is assembled Resources are allocated Responsibilities are assigned Risks are identified and confronted,27,Primary Pl
22、anning 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,28,Documents,Planning Product,29,Plan
23、ning 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,30,Planning Documents,You (the PM) need to choose w
24、hich 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,31,Planning Documents,Project ROI Analysis Statement of Work (SOW) Project Charter Software Project Managemen
25、t Plan (SPMP) Budget Responsibility Assignment Matrix (RAM) Risk Management Plan,32,Product Documents,Statement of Need System Interface Specification Software Requirements Specification Software Design Specification Software Validation & Verification Plan User Documentation,Support Plan Maintenance
26、 Documentation,33,34,Plans Evolve Over Time,NASAs “Managers Handbook for Software Development”,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
27、over time as pieces come together,35,SDP / SPMP,Fundamental Sections Project overview Deliverables Project organization Managerial processes Technical processes Budget Schedule,36,Communications Management Plan,Often a section of SPMP Describes information flow to all parties Gathering and distribut
28、ing information Status meetings Monthly, Weekly, Daily? Status reports are vital,37,38,Work Breakdown, Tasks & Activities,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 e
29、ffort Identify task dependencies Assign resources Schedule work,39,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 d
30、oes partitioning help this?,40,A Project: functions, activities, tasks,41,Project Elements,Work Packages,The work package is the fundamental unit of planning and control for software projects For each work activity and task, a work package specifies: Identity (WBS Number + Task Name) Task Start Time
31、, End Time and Duration Resources Required to Complete the Task Predecessor Activities Successor Activities Work Product(s) Completion / Acceptance Criteria Risk Factors that may Affect Task Completion,42,A Work Package Example,Activity : 3.2.2.1 DESIGN_COMM_SUBSYSTEMActivity description: Specify in
32、ternal architecture of the COMM subsystemEstimated duration: 5 weeksPlanned Start and End: TBDResources Needed: Personnel:2 senior telecom designers allocated full time (100%)Skills: Designers must know the X.25 protocolTools: One Sun workstation running StatemateTravel: 3 day Design Review in San D
33、iego for 2 peoplePredecessor tasks: 3.2.1 - Develop system architectureSuccessor tasks: 3.3.2.2 - Implement COMMWork Products: Architectural specification for COMM subsystemTest plan for COMM Completion criteria: Design inspection by peers andapproval of COMM design by the Chief ArchitectRisks: Seni
34、or designers not identified,43,Analysis of Work Packages,During planning, work packages and collections of work packages can be analyzed to determine: Estimated duration of each task Scheduling information Predecessors, successors, durations, concurrent and sequential work activities, critical paths
35、 Number of personnel By skill level and need date Other resources needed Quantities and need dates Estimated effort and cost Risks for tasks and activities (collections of tasks),44,Tracking of Work Packages,During project execution, work packages can be tracked to determine: Actual vs. planned star
36、t date Actual vs. planned end date Actual vs. planned resources Actual vs. planned cost Actual vs. planned work products Problems vs. anticipated risks (more later),45,Work Breakdown Structure,An aggregation of Work Packages “Part-of” relationships among work packages are specified in a Work Breakdo
37、wn Structure (WBS) A process-oriented, hierarchical decomposition of the work activities Often driven by product breakdown Structure is imposed on a WBS using a decimal numbering system to specify the “is-part-of” aggregation of work packages,46,Purpose of a WBS,A WBS helps to define the work requir
38、ed for the project and to break it into manageable pieces called work packages A good WBS can help in the development of schedules, budgets, and resource requirements The WBS is a useful tool for identification of activities and assignment of responsibilities,47,Possible Ways to Organize Work Breakd
39、own Structures,By project phases By project components By functional areas By types of work By resource types,48,Work Breakdown Structure: WBS,2 Formats Outline (indented format) Graphical Tree (Organizational Chart) Uses a decimal numbering system 0 is typically top level Includes Development, Mgmt
40、., and project support tasks Shows “is contained in” relationships Does not show dependencies or durations,49,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,50,Up to six levels (3-6 us
41、ually) such asUpper 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,51,A Full WBS Structure,WBS Elements for an ATM Project,52,53,Requirements Definition,System Development,System Test
42、ing,Documentation,System Design,Equipment HistoryModule,Spare Parts Inventory Control Module,Data Dictionary Development,Screen & ReportDesign,Logic Diagrams,Code Development,Module Testing,Work Order ControlModule,Development & Implementation Maintenance Management Information System,Example WBS (I
43、nverted Tree Structure),Example WBS (Indented List Format),Development & Implementation Maintenance Management Information System Requirements Definition System Design System Development Equipment History Module Work Order Control Module Data Dictionary Development Screen & Report Design Logic Diagr
44、ams Code Development Module Testing Spare Parts Inventory Control Module System Testing Documentation Implementation,54,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 sy
45、stem, 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,55,56,Product WBS,57,Process WBS,58,Outline WBS w/Gantt,59,WBS by PMI Process Groups,WB
46、S 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,60,WBS Techniques,Top-Down Bottom-Up Analogy
47、 Rolling Wave 1st pass: go 1-3 levels deep Gather more requirements or data Add more detail later Post-its on a wall,61,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
48、is similar to an earlier project or problem But is also applied in majority of situations,62,WBS Techniques,Bottom-up Start at lowest level tasks Aggregate into summaries and higher levels Cons Time consuming Needs more requirements complete Pros Detailed,63,WBS Techniques,Analogy Base WBS upon that
49、 of a “similar” project Use a template Analogy also can be estimation basis Pros Based on past actual experience Cons Needs comparable project,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
50、be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!),65,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 whats missing Break down until you can generate accurate time & cost estimates Ensure each element corresponds to a deliverable,
