SE 477 Software and Systems Project Management - PowerPoint PPT Presentation

se 477 software and systems project management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SE 477 Software and Systems Project Management PowerPoint Presentation
Download Presentation
SE 477 Software and Systems Project Management

play fullscreen
1 / 94
SE 477 Software and Systems Project Management
116 Views
Download Presentation
timothy-davidson
Download Presentation

SE 477 Software and Systems Project Management

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 429 Office Hours: Tuesday, 4:00 – 5:30 SE 477: Lecture 3

  2. Administrivia • Comments and feedback • Tools • MicroSoft Word • MicroSoft Project • Look at Musser’s slides (see class page for access)Note they are old and out dated. • Download the Automatic Tollbooth example and work with it. • Google “microsoft project tutorial” • A random such tutorial is http://www.profsr.com/msproject/msproj01.htm • You won’t need many other tools SE 477: Lecture 3

  3. Assignment 2 Due October 7, 2014 • Critical Analysis: Show how the Iterative/Evolutionary Process can be integrated with Project Management • Read the following two Gartner Reports, available on the DePaul Libraries Web site: • Waterfalls, Products and Projects: A Primer to Software Development Methods by Matthew Hotle (Gartner document ID: G00155147) • 'Just Enough Process' for Applications by Matthew Hotle (Gartner document ID: G00145561) • See also: Kruchten, P (2002, Oct 15) Planning an Iterative Project: http://www.ibm.com/developerworks/rational/library/2831.html • Your assignment is to write a one- to two-page critical analysis that directly addresses the question posed at the top of this page. • The purpose of the assignment is to discuss how to integrate the Project Management with the Iterative/Evolutionary Process. • Note: I do not want a discussion of Waterfall vs. Iterative! SE 477: Lecture 3

  4. SE 477 – Class 3 Topics: • Project Management – Initial Phase: • Developing the project charter • Statement of work (SOW) • Agile Perspective: The Product Overview Document • Stakeholders • Organizational Structures & Influences • The Project Management Plan; • Initial documents • Project Charter – Statement of Work (SOW) • Project plans Reading: • PMP Study Guide: Chapter 3-4 SE 477: Lecture 3

  5. Thought for the Day Planning a project takes as much effort as planning a war. Hope is not a strategy! SE 477: Lecture 3

  6. Last time • Software Project Management • Software project management overview • Project managers • Project organization • Putting a process in place • Software process • Phases for software project management • Project management tools SE 477: Lecture 3

  7. Managing various project management processes • Recall the three main approaches to project management: • Predictive: Conventional, linear processes exemplified by ‘Waterfall’ • Iterative and incremental: Exemplified by UP and UP+Scrum hybrid • Adaptive: Value-driven, exemplified by Agile (Scrum, in our case) • PMBOK project management practices are generally oriented toward predictive approaches, though this is diminishing with each update • Adaptive project management practices (usually) differ substantially from predictive approaches, particularly in depth and timing • A iterative/incremental hybrid blends the project management practices from the other two ‘as-needed’ • Iterative/incremental hybrid, in effect, selects and adapts the ‘best practices’ from the other approaches SE 477: Lecture 3

  8. Project management processes • Regardless of the type of project lifecycle, project management encompasses the following process groups, shown with some representative tasks: • Initiating/Define – Scope the project; Charter the project; identify stakeholders • Planning – Develop the project plan. Collect requirements; identify schedule; plan scope, cost, quality, human resource, risk, and procurement management • Executing – Launch the plan. Direct and manage project work; perform quality assurance; manage and develop project team; conduct procurements • Monitoring and Controlling – Monitor project progress. Monitor and control project work; manage scope change; monitor and control schedule; control quality; control risks; control procurements • Closing – Close out the project: Close project; close procurements See note below. SE 477: Lecture 3

  9. Initiating the Project SE 477: Lecture 3

  10. Initiating processes overview Adapted from Figure 2-10 PMBOK Guide, 5th Edition • Initiating processes define a new project or new phase of an existing project • Initial project scope, project stakeholders, and project manager are identified • Key purposes are to: • Align the stakeholders' expectations with project purpose • Give stakeholders visibility into project scope and objectives • Demonstrate that stakeholder participation helps ensure project success • All of these set the vision of the project: what needs to be accomplished SE 477: Lecture 3

  11. Initiating Processes • Develop Project Charter • This process falls under the Project Integration Management knowledge area • Justifies and formally authorizes a project or a project phase • Documents the stakeholders’ initial requirements and expectations • Forms the basis for the partnership between the requesting (customer) and performing (supplier) organizations • Identify Stakeholders • This process falls under the Project Communications Management knowledge area • Identifies all people or organizations impacted by the project • Documents their interests and involvement with the project, as well as their potential impact on project success • Forms the basis for developing a strategy to approach and involve each stakeholder to maximize positive influences and minimize negative influences SE 477: Lecture 3

  12. Concept Exploration • The “Why” phase • Not a “mandatory formal” phase • Sometimes called the “pre-project” phase • Collecting project ideas • Then the “funneling” process • Project Justification • ROI – Return on Investment • Cost-benefit analysis • Competitive analysis (if appropriate) • Initial planning and estimates SE 477: Lecture 3

  13. Concept Exploration • Possibly includes Procurement Management: • RFP Process • Vendor selection • Contract management • Gathering the initial team • Including PM if not already on-board • Identify the project sponsor • Primary contact for approval and decision making • Potential Phase Outputs: • Concept Document, Product Description, Proposal, SOW, Project Charter SE 477: Lecture 3

  14. 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 SE 477: Lecture 3

  15. The Charter SE 477: Lecture 3

  16. Inputs, tools & techniques, and outputs Inputs Project statement of work Business case Agreements Enterprise environmental factors Organizational process assets Tools & Techniques Expert judgement Facilitation techniques Outputs Project charter SE 477: Lecture 3

  17. Define the Project • There is a need for clear understanding of exactly what is to be done. Project definition starts with the Conditions of Satisfactiondocument based on conversation with the customer. • Project Overview Statement akaCharterorVisionis generated from the Conditions of Satisfaction document. • The Project Overview Statement clearly states what is to be done. • Once the Project Overview Statement is approved, the scoping phase is complete. In most cases the Project Overview Statement, the Statement of Work, and Project Charter are the same. Even scope will fit here. We will use them interchangeably. SE 477: Lecture 3

  18. Project Charter • Activities • Define scope • Document Project Risks, Assumptions, and Constraints • Identify and Perform Stakeholder Analysis • Develop Project Charter • Obtain Project Charter Approval • Deliverables • Project charter • Statement of work (SOW) (aka Scope) SE 477: Lecture 3

  19. Preliminary Scope Project objectives Product description Deliverables Constraints Assumptions Project acceptance criteria SE 477: Lecture 3

  20. Project Charter The Conditions of Satisfaction statement provides the input we need to generate the Charter. The Charter is a short document that concisely states what is to be done in the project, why it is to be done, and what business value it will provide to the organization when completed. The main purpose of the Charter is to secure senior management approval and the resources needed to develop a detailed project plan. It will be reviewed by the managers who are responsible for setting priorities and deciding what projects to support. It is also a general statement, it is not detailed technical statement. A high-level project description: Business need, product, assumptions Often precedes SOW Often 2-4 pages (can be longer) SE 477: Lecture 3

  21. Project Charter • Typical outline • Overview • Business need • Problem/opportunity • Objectives • Project goal • Method or approach • General scope of work • Success criteria • Rough schedule & budget • Roles & responsibilities • Assumptions, risks, obstacles SE 477: Lecture 3

  22. Project charter content • Project purpose or justification • Define the reason why the project is being done, by referring to any of the Initiating process inputs [See the “vision statement”] • Measurable project objectives and related success criteria • Scope. Scope needed to achieve project goals and measurable criteria for scope success • Time. Goals for timely completion and specific dates for success • Cost. Goals for project expenditures and range of costs for success • Quality. Quality criteria and specific measures for criteria for success • Other. Any other objectives along with measurable criteria of success SE 477: Lecture 3

  23. Project charter content • High-level requirements • Describe the high-level product capabilities that satisfy stakeholder needs and expectations. Do not include detailed requirements • Example: As a retail customer, I want to shop by either brand or by product category • Example: As the site owner, I want a retail customer to find a stocked product on the site within three (3) mouse clicks • Anti-example: As the site owner, I want the products to be displayed in a 4- across grid against a light grey background SE 477: Lecture 3

  24. Project charter content • Assumptions and constraints • An assumption is “a thing that is accepted as true or as certain to happen, without proof” • Example: The site will allow all site visitors to access all public features of the site • A constraint is a limitation or restriction • Example: The site must use a hosting service for the new site SE 477: Lecture 3

  25. Project charter content • High-level project description and boundaries [scope] • Provide an executive-summary-level description of the project, identify what will and will not be included in the project • Example: The site is a one-stop source for health and wellness information … It will not provide direct access to the HR site. • High-level risks • Risks represent any major areas of uncertainty for the project • Risks may be internal or external • Example: Existing customers may have difficulty transitioning to new site • Example: The company does not have sufficient in-house Web design expertise to match the goals for the new site SE 477: Lecture 3

  26. Project charter content • Summary milestone schedule • Identify any significant points or events in the project, such as key deliverables, beginning or ending of phases, or product acceptance • Include estimated completion dates for the milestones • Examples: Requirements document complete: 1/31/2015; Web site on-line with training: 6/30/2015 • Summary budget • Provide a rough order of magnitude (ROM) estimate of expenditures schedule for project • ROM estimates may be as broad as ±100% but usually range ±35% • Budget should break down total expenditures by major categories (software, hardware, human resources, etc.) SE 477: Lecture 3

  27. Project charter content • Stakeholder list • A stakeholder is “a[n] individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project”* • Identify a preliminary list of the most critical project stakeholders–this list will be refined later • Project approval requirements • Identify any criteria that must be met in order for the project to be accepted by the project customer • Example: The project must implement the set of ‘must-have’ user stories agreed upon at project initiation SE 477: Lecture 3

  28. Project charter content • Project manager, responsibility, and authority levels • Staffing. Specific authority project manager is granted to hire/fire, discipline, or accept/reject project staff • Budget management and variance. Specific authority project manager is granted to commit, manage, and control project funds; also, what variance requires higher approval • Technical decisions. Specific authority project manager is granted regarding deliverable technical decisions or project approach • Conflict resolution. Specific authority the project manager is granted to resolve team and organizational conflict, as well as conflict with external stakeholders • Escalation path for authority limitations. Define the path for escalation of issues exceeding the project manager’s authority • Name and authority of the sponsor or other person(s) authorizing the project charter SE 477: Lecture 3

  29. Develop Project Charter: Data Flow Diagram SE 477: Lecture 3

  30. Statement of Work (SOW) • A description of the work required for the project; normally this is used when the project is being contracted out, but most of this is part of the Project Overview or Charter • 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 • Typically done after approval (after “Go”) • Can be multiple versions • List of deliverables for an RFP • More detailed within final RFP • Binding version from contract SE 477: Lecture 3

  31. SOW Template SE 477: Lecture 3

  32. S.M.A.R.T. characteristics for Goal • Doran’s S.M.A.R.T. characteristics provide the criteria for a goal statement: • Specific: Be specific in targeting and objective. • Measurable: Establish measurable indicator(s) of progress. • Assignable: Make the object assignable to one person for completion. • Realistic: State what can realistically be done with available resources. • Time-related: State when the objective can be achieved; that is, duration SE 477: Lecture 3

  33. The Project Definition Statement : PDS • Just as the customer and the project manager benefit from the Charter, the project manager and project team can benefit from a closely related document, which we call the Project Definition Statement (PDS). • The PDS uses the same form as the Charter but incorporates considerably more detail. The detailed information provided in the PDS is for the use of the project manager and the project team. SE 477: Lecture 3

  34. Charter Tips on writing the charter • Distribution of project by type • In-house, contract/for-hire, startup • Distribution of project by technology • Web, Windows/Mac OS/Linux, Mobile, No platform • Distribution by industry • Financial Services, Law, Retail • A reminder why no two projects are same • Most important elements • Why, who, what, what not • A little bit of when • Make sure it’s clear • Some more re-purposed than others • Occasionally read more like business plans SE 477: Lecture 3

  35. Charter • Make the stakeholder relationships clear • You, sponsor, user, etc. • If “for real” you’d want additional assumptions and scope constraint • The justification or cost-benefit analysis “materializes” in some of the Charters • Don’t shortchange downstream activities • Integration, testing, rollout, etc. • Risks • Business risks vs. Project risks • Ex: “lack of market adoption” vs. “inexperienced team” • Functionality • “Forgotten” items: user registration, help, security • Good out of scope items • Internationalization • Search system SE 477: Lecture 3

  36. Charter • Formalities • Spell check. • Proof read • Make sure your name is on first page and also header and/or footer on each page. SE 477: Lecture 3

  37. To Get to the Essence of a Project • Why is the system being developed? • What will be done? • When will it be accomplished? • Who is responsible? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehm SE 477: Lecture 3

  38. The project charter & agile • The project charter sets out the earliest definition for the project • Note: PMI has eliminated an earlier (v. 3) Define Preliminary Scope Statement from among the PMBOK processes, which further defined and constrained the project • The agile product overview document provides a high-level view of the most essential project elements that parallels the charter • The product overview is less detailed and more flexible SE 477: Lecture 3

  39. Product overview document content Product Name Product Vision Statement. Include both product problem statement and product position statement Dedicated Team. List names of team members Project Manager Customer/Product Owner. Customer or customer representative Architecture. Specify if constrained; else, to be determined by team Features Backlog. High-level list of major features Product Roadmap. Releases with themes and corresponding features Risks/Opportunities. Consider market, project, and product aspects Success Criteria. What the customer considers most critical criteria Flexibility Matrix. Trade-off matrix of time, resources, and objectives SE 477: Lecture 3

  40. Agile initiating process Obtain input and feedback from customer and team on project objectives and justifications as part of vision meeting If needed, prepare ‘barely sufficient’ business case and associated documentation required by the company and/or project approval board in order to obtain project approval Use an agile software development methodology and prepare accordingly SE 477: Lecture 3

  41. Stakeholders SE 477: Lecture 3

  42. Project stakeholders • Project stakeholders are individuals or organizations who have influence over, or are influenced by project execution or completion • Different stakeholders have varying amounts of influence, responsibility, or authority over a project • Stakeholders can have a positive, neutral, or negative influence on a project • Identifying all stakeholders associated with a project may be difficult • Stakeholders that are overlooked almost inevitably have a negative impact on project SE 477: Lecture 3

  43. Interactions / Stakeholders As a PM, who do you interact with? Project Stakeholders • External people • Project sponsor • Executives • Customers • Contractors • Functional managers • Users • Team • Architects • System Engineers • Designers • Developers • Testers • Documenters SE 477: Lecture 3

  44. Key project stakeholder roles • Customer. Person or organization that acquires product • User. Person or organization that uses product • Performing organization. Organization performing work of project • Project manager. Responsible for managing project • Project management team. Individuals directly involved in project management activities • Project team members. Individuals performing work of project • Sponsor. Entity providing financial resources for project • Influencers. Entities indirectly affecting project • PMO. Project management office. Responsible for centralized and coordinated management of all projects under its supervision SE 477: Lecture 3

  45. Significant project stakeholders Functional managers. Manage within functional or administrative areas of the business, such as human resources, accounting, or procurement. Do not deal directly with products or services Operations management. Manage within core business areas, such as research and development, design, manufacturing, testing, or maintenance. Deal directly with producing and maintaining products Sellers. External companies or individuals that enter into contractual agreements to provide components or services necessary for project. Also known as vendors, suppliers, or contractors Business partners. External companies or individuals that have a closer relationship with enterprise, providing expertise or filling specific roles such as installation, training, or support SE 477: Lecture 3

  46. Stakeholders • Senior managers who define the business issues that often have significant influence on the project. • Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. • Practitioners who deliver the technical skills that are necessary to engineer a product or application. • Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. • End-users who interact with the software once it is released for production use. SE 477: Lecture 3

  47. Software System Stakeholders Developer Tester Architect Manager Customer Components Connectors Class/Pattern Data flow Reuse Flexibility Extensibility Functionality Requirements Regression Tools Simulators Maintainability Portability Feasibility Reusability Extensibility Flexibility The ilities Cost Schedule Requirements Process Resources Requirements Cost Schedule Performance Reliability Security Each stakeholder has different concerns: SE 477: Lecture 3

  48. Stakeholder Triad • Function Representative • The ‘business person’, Business Analyst (BA) • Or SME: Subject Matter Expert • Executive Sponsor • Project’s visionary & champion • Also the ‘General’, ‘Fall Guy’, and ‘Minesweeper’ • Not the PM, ‘Santa Claus’, or the ‘Tech Guy’ • Project Manager • The ‘Linchpin’ • Must be ‘multi-lingual’ SE 477: Lecture 3

  49. 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. SE 477: Lecture 3

  50. Organizational Structures • Functional • Engineering, Marketing, Design, etc • P&L from production • Projectized • 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 SE 477: Lecture 3