SE 477 Software and Systems Project Management Dennis Mumaugh,

SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor [email protected] Office: CDM, Room 428 Office Hours: Wednesday, 4:00 – 5:30 January 18, 2017 SE 477: Lecture 3 1 of 94

Administrivia Comments and feedback Teams – assignments posted on D2L 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 January 18, 2017 SE 477: Lecture 3 2 of 94

Assignment 2 Due January 25, 2017 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 [and on D2L]: 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 PMBOK-SWE Ch. 2.4.2.3 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! January 18, 2017 SE 477: Lecture 3 3 of 94

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: PMBOK-SWE Ch. 3.3 PMBOK-SWE Ch. 4 Intro & 4.1, 4.2 PMBOK-SWE Ch. 13 Intro & 13.1 January 18, 2017 SE 477: Lecture 3 4 of 94

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

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 January 18, 2017 SE 477: Lecture 3 6 of 94

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 January 18, 2017 SE 477: Lecture 3 7 of 94

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

Initiating the Project January 18, 2017 SE 477: Lecture 3 9 of 94

Initiating processes overview 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 Adapted from Figure 2-10 PMBOK Guide, 5th Edition January 18, 2017 SE 477: Lecture 3 10 of 94

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 January 18, 2017 SE 477: Lecture 3 11 of 94

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 January 18, 2017 SE 477: Lecture 3 12 of 94

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 January 18, 2017 SE 477: Lecture 3 13 of 94

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 January 18, 2017 SE 477: Lecture 3 14 of 94

The Charter January 18, 2017 SE 477: Lecture 3 15 of 94

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 January 18, 2017 SE 477: Lecture 3 16 of 94

Define the Project There is a need for clear understanding of exactly what is to be done. Project definition starts with the Conditions of Satisfaction document based on conversation with the customer. Project Overview Statement aka Charter or Vision is 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. January 18, 2017 SE 477: Lecture 3 17 of 94

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) January 18, 2017 SE 477: Lecture 3 18 of 94

Preliminary Scope Project objectives Product description Deliverables Constraints Assumptions Project acceptance criteria January 18, 2017 SE 477: Lecture 3 19 of 94

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) January 18, 2017 SE 477: Lecture 3 20 of 94

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 January 18, 2017 SE 477: Lecture 3 21 of 94

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 January 18, 2017 SE 477: Lecture 3 22 of 94

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 January 18, 2017 SE 477: Lecture 3 23 of 94

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 January 18, 2017 SE 477: Lecture 3 24 of 94

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 January 18, 2017 SE 477: Lecture 3 25 of 94

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/2017; Web site on-line with training: 6/30/2017 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.) January 18, 2017 SE 477: Lecture 3 26 of 94

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 January 18, 2017 SE 477: Lecture 3 27 of 94

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 January 18, 2017 SE 477: Lecture 3 28 of 94

Develop Project Charter: Data Flow Diagram January 18, 2017 SE 477: Lecture 3 29 of 94

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 1. List of deliverables for an RFP 2. More detailed within final RFP 3. Binding version from contract January 18, 2017 SE 477: Lecture 3 30 of 94

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. January 18, 2017 SE 477: Lecture 3 31 of 94

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 January 18, 2017 SE 477: Lecture 3 32 of 94

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. January 18, 2017 SE 477: Lecture 3 33 of 94

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 January 18, 2017 SE 477: Lecture 3 34 of 94

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 January 18, 2017 SE 477: Lecture 3 35 of 94

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

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 January 18, 2017 SE 477: Lecture 3 37 of 94

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 January 18, 2017 SE 477: Lecture 3 38 of 94

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 January 18, 2017 SE 477: Lecture 3 39 of 94

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 January 18, 2017 SE 477: Lecture 3 40 of 94

Stakeholders January 18, 2017 SE 477: Lecture 3 41 of 94

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 January 18, 2017 SE 477: Lecture 3 42 of 94

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

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 January 18, 2017 SE 477: Lecture 3 44 of 94

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 January 18, 2017 SE 477: Lecture 3 45 of 94

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. January 18, 2017 SE 477: Lecture 3 46 of 94

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

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

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. January 18, 2017 SE 477: Lecture 3 49 of 94

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 January 18, 2017 SE 477: Lecture 3 50 of 94

Functional Organization Pros – Clear definition of authority – Eliminates duplication – Encourages specialization – Clear career paths January 18, 2017 Cons – “Walls”: can lack customer orientation – “Silos” create longer decisions cycles – Conflicts across functional areas – Project leaders have little power SE 477: Lecture 3 51 of 94

Projectized Organization Pros – Unity of command – Effective intra-project communication Cons – Duplication of facilities – Career path Examples: defense avionics, construction January 18, 2017 SE 477: Lecture 3 52 of 94

Matrix Organization Pros – Project integration across functional lines –Efficient use of resources –Retains functional teams January 18, 2017 Cons – Two bosses for personnel – Complexity – Resource & priority conflicts SE 477: Lecture 3 53 of 94

Matrix Forms Weak, Strong, Balanced Degree of relative power Weak: functional-centric Strong: project-centric January 18, 2017 SE 477: Lecture 3 54 of 94

Organizational Structure – Influences on Projects Organization Type Project Characteristics Project Manager's Authority Percent of Performing Organization's Personnel Assigned Fulltime to Project Work Project Manager's Role Common Title for Project Manager's Role Project Management Administrative Staff Functional Weak Matrix Little or None Limited Virtually None 0-25% Part-time Project Coordinator/ Project Leader Part-time Matrix Balanced Matrix Low to Moderate Strong Matrix Projectized Moderate To High High to Almost Total 15-60% 50-95% 85-100% Part-time Project Coordinator/ Project Leader Full-time Project Manager/ Project Officer Full-time Project Manager/ Program Manager Full-time Project Manager/ Program Manager Part-time Part-time Full-time Full-time PMBOK Guide, 2000, p. 19 January 18, 2017 SE 477: Lecture 3 55 of 94

Common-Sense Approach to Projects Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way. Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.” Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. January 18, 2017 SE 477: Lecture 3 56 of 94

Project Planning January 18, 2017 SE 477: Lecture 3 57 of 94

Project Planning “Now the general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat” Sun Tzu, The Art of War January 18, 2017 SE 477: Lecture 3 58 of 94

Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Or, A Plan is the strategy for the successful completion of the project. It's a description of the project steps that produce increasing maturity of the products or processes produced by the project. Why? So the end result gets done on time, with quality! January 18, 2017 SE 477: Lecture 3 59 of 94

Planning “You've got to be very careful if you don't know where you're going, because you might not get there.” “If you don't know where you are going, you will wind up somewhere else.” “If you don't know where you're going, any road will take you there.” “If you don’t know where you’re going, how do you know when you get there?” – Yogi Berra “The nicest thing about not planning is that failure comes as a complete surprise and is not preceded by a period of worry and depression.” – John Preston, Boston College January 18, 2017 SE 477: Lecture 3 60 of 94

Why plan? Why plan? Consider driving a car: do you drive looking backwards? Recall from the Standish Group's 2009 CHAOS Report: ‘Proper Planning’ was the 4th ranked factor cited for successful projects (just behind ‘Clear Statement of Requirements’) ‘Lack of Planning’ was the 7th ranked factor cited for failed projects (just behind ‘Changing Requirements’) We will soon see that the close correlation of requirements and planning is no coincidence: establishing requirements is an essential part of planning January 18, 2017 SE 477: Lecture 3 61 of 94

Reasons people don’t plan Don’t believe in planning Management or organization culture does not support planning Find the process painful If you do plan, the pain will be greatest early and will diminish with time If you don’t plan, you defer the pain (and it will usually be greater ) Don’t have time to plan! Consider the simple task of getting yourself to class Now consider having the responsibility of getting all the other people to class on time, not just SE 477 but other classes, as well January 18, 2017 SE 477: Lecture 3 62 of 94

Planning is essential to control An effective way to exert control is to: Know where you are Know where you are supposed to be Take corrective action if there is a difference between the two Note: You have to have a plan to know where you are supposed to be If you have no plan, you have no control » Example: Commercial airliner flying from Chicago to Tokyo Planning and control Two phases both needed January 18, 2017 SE 477: Lecture 3 63 of 94

Planning processes Planning processes determine the total project scope, define or refine the project objectives, and develop the course of action to achieve the objectives Planning employs progressive elaboration: the process of revisiting planning (and possibly initiating) processes as additional project information becomes available The planning processes covered in SE 477 encompass project integration management, project scope management, project time management, project risk management, and project stakeholder management January 18, 2017 SE 477: Lecture 3 64 of 94

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 January 18, 2017 SE 477: Lecture 3 65 of 94

Planning Scoping What is the problem How much will it cost? Estimation How long will it take? Schedule Resources How many people will it take? Risk What might go wrong? Control Strategy January 18, 2017 SE 477: Lecture 3 66 of 94

Planning processes and knowledge areas January 18, 2017 SE 477: Lecture 3 67 of 94

Primary Planning Steps 1. Identify project scope and objectives 2. Define and Record Requirements 3. Identify project organizational environment Analyze project characteristics Identify Project Team and Define Roles and Responsibilities 4. Identify project products and activities Create the WBS Estimate effort for each activity Allocate resources Schedule deliveries and milestones January 18, 2017 SE 477: Lecture 3 68 of 94

Primary Planning Steps 5. 6. 7. 8. 9. Develop Change Management Plan Identify Risks and Define Risk Strategies Review and communicate plan Obtain Plan Approval Conduct Kick-off Meeting January 18, 2017 SE 477: Lecture 3 69 of 94

Project Planning Task Set – I Establish project scope Determine feasibility Define required resources Determine required human resources Define reusable software resources Identify environmental resources Estimate cost and effort Decompose the problem Develop two or more estimates using size, function points, process tasks or use-cases Reconcile the estimates January 18, 2017 SE 477: Lecture 3 70 of 94

Project Planning Task Set – II Develop a project schedule Scheduling is considered in detail later. » Establish a meaningful task set » Define a task network » Use scheduling tools to develop a timeline chart » Define schedule tracking mechanisms Analyze risks Risk analysis is considered in detail later. January 18, 2017 SE 477: Lecture 3 71 of 94

Software Project Survival Guide Documents Plans, reports Schedules Checklists See previous lecture (2), slide 67 January 18, 2017 SE 477: Lecture 3 72 of 94

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 January 18, 2017 SE 477: Lecture 3 73 of 94

Plans Evolve Over Time NASA's “Manager's Handbook for Software Development” January 18, 2017 SE 477: Lecture 3 74 of 94

Software Development Plan (SDP) Software Project Management Plan (SPMP) Some consider it the most important document in the project (along with requirements document) Can be seen as an aggregation of other core documents Evolves over time as pieces come together January 18, 2017 SE 477: Lecture 3 75 of 94

SDP / SPMP Fundamental Sections Project overview Deliverables Project organization Managerial processes Communication management plan Milestones Technical processes Budget Schedule January 18, 2017 SE 477: Lecture 3 76 of 94

Preliminary Scope Project objectives Product description Product objectives Product deliverables Requirements (product and project) Exclusions (project boundary) Constraints January 18, 2017 Assumptions High-level risks and definitions Milestones Initial WBS Cost Estimate Configuration management requirements Project acceptance criteria SE 477: Lecture 3 77 of 94

Deliverables List of items to be delivered Must be tangible items Sample deliverables The product – the actual software, in the installable format Product documentation Reports and planning documentation Most projects are driven by deliverables, so you need several Project deliverables (aka documents) are included January 18, 2017 SE 477: Lecture 3 78 of 94

Communications Management Plan Often a section of Software Project Management Plan (SPMP) Describes information flow to all parties Gathering and distributing information Status meetings Monthly, Weekly, Daily? Status reports are vital Stakeholder Management Plan January 18, 2017 SE 477: Lecture 3 79 of 94

Documents Two kinds of documents Planning Product Let us review each kind January 18, 2017 SE 477: Lecture 3 80 of 94

Planning Documents Project ROI Analysis Business Case (include competitive analysis if appropriate) Project Charter Statement of Work (SOW) Software Project Management Plan (SPMP) Software Development Plan (SDP) » Schedule Communications Management Plan Budget Responsibility Assignment Matrix (RAM) Risk Management Plan January 18, 2017 SE 477: Lecture 3 81 of 94

Planning Documents Other documents you may want/need Software Quality Assurance Plan (SQAP) Software Process Improvement Plan Software Configuration Management Plan (SCMP) Migration Plan Operations Plan January 18, 2017 SE 477: Lecture 3 82 of 94

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 January 18, 2017 SE 477: Lecture 3 83 of 94

Product Documents Statement of Need System Interface Specification Software Requirements Specification Software Design Specification Software Validation & Verification Plan User Documentation Support Plan Maintenance Documentation January 18, 2017 SE 477: Lecture 3 84 of 94

Project Phases January 18, 2017 SE 477: Lecture 3 85 of 94

Potential Deliverables by Phase January 18, 2017 SE 477: Lecture 3 86 of 94

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 ” January 18, 2017 SE 477: Lecture 3 87 of 94

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” January 18, 2017 SE 477: Lecture 3 88 of 94

Activities by % of Total Effort NASA's “Manager's Handbook for Software Development” January 18, 2017 SE 477: Lecture 3 89 of 94

Conventional planning approach Planning seems to be a straightforward process: Determine the tasks to be done Determine the order of the tasks Execute the tasks in the proper order Uncertainty can, and usually does, disrupt this flow Not every task can be identified before the project starts Contingent factors—internal or external—add, delete, or modify tasks Task ordering is changed due to new or unforeseen dependencies At their very foundations, conventional planning approaches implicitly assume an unrealistic model of human cognition and behavior, while ignoring or underestimating real-world risk January 18, 2017 SE 477: Lecture 3 90 of 94

Planning in an IID methodology In contrast to big, up-front planning or even planning in conventional iterative and incremental methodologies, an IID methodology spreads planning out over the entire project lifecycle Planning in an IID methodology: Distributes planning from the top-level stakeholders to the individual developers—each plans at the appropriate scale Delays fine-grained planning to ‘just-in-time’ before corresponding task or activity Is low-overhead—‘barely sufficient’ planning documents are lightweight and the majority are produced ‘as-needed’ rather than as a matter of protocol Is resilient to requirements changes—it embraces change rather than attempts to prevent or avoid it January 18, 2017 SE 477: Lecture 3 91 of 94

Planning In The Iterative Development Model Needs to take into consideration the iterations See slides 45-51, 92-96 of lecture 2 See PMBOK-SWE Ch. 2.4.2.3 See also: Kruchten, P (2002, Oct 15) Planning an Iterative Project: http://www.ibm.com/developerworks/rational/library/2831.ht ml January 18, 2017 SE 477: Lecture 3 92 of 94

Next Class Topic: Project Planning » Creating the Work Breakdown Structure (WBS) » Activity: Activity Definition Activity Sequencing » Estimating Size and complexity Reading: PMBOK-SWE Ch. 5 Other texts on Reading List page Assignment: Paper: summary and analysis on how to integrate the iterative/evolutionary SDLC into PM January 18, 2017 SE 477: Lecture 3 93 of 94

Journal Exercise Considering the Charter: How detailed should a charter be? January 18, 2017 SE 477: Lecture 3 94 of 94