SE 477 Software and Systems Project Management

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

Administrivia • Comments and feedback • MS-Project • Short set of slides (from John Musser) on class web page • 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 • Homework • Page size suggestions are for single spaced documents. Double them for double spaced. I prefer single spaced or space and a half! • Show paragraphs: indent or use a space [change MS Word style]. Show section heads. • Proof read! SE 477: Lecture 4

Administrivia • Project • Continue work on team assignment • By now you should have organized and have had some virtual meetings. • Should have some of the work on Project Charter and Preliminary Project Scope finished. • Should have rough schedule for rest of work. • Keep in touch and make sure your team members are communicating and doing work. • Inform me immediately if your partner(s) are not keeping up and you are having problems. SE 477: Lecture 4

Homework Assignment 3 – Due May 5, 2014 • Develop a plan and project schedule for a small subsystem • Assume the project is using the waterfall SDLC and has the following phases: Requirements, High Level Design, Detailed Design, Coding and Unit Test, Integration and Testing, Documentation. • There is a WBS provided with the required phases, activities and information to complete this project. • Assign Resources to the Tasks making any assumptions you consider appropriate (Software Engineering Assumptions). • Provide an executive summary • What is the earliest finish date for this project if it is scheduled to start on 4/28/2014? Don’t forget holidays! • Show the duration and delivery schedule given the start date is April 28, 2014. • Show the staffing and resources used, and the total staff time. • You should use OpenProject, ProjectLibre or MS Project to develop this. SE 477: Lecture 4

SE 477 – Class 4 Topic: • Project Planning • Project scope management • Project requirements • Creating the Work Breakdown Structure (WBS) • Activity: • Activity Definition • Activity Sequencing Reading: • PMP Study Guide: Chapters 4, 5, 7 SE 477: Lecture 4

Thought for the day “Predictions are hard, especially about the future” – Yogi Berra SE 477: Lecture 4

Last time • 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 SE 477: Lecture 4

Project Planning: A 12 Step Program Set goal and scope Select lifecycle Set organization/team form Start team selection Determine risks Create WBS Identify tasks Identify task dependencies Estimate size Estimate effort Assign resources Schedule work SE 477: Lecture 4

Project scope management Scope Planning Project Requirements Define Scope Creating the Work Breakdown Structure (WBS) SE 477: Lecture 4

Scope • Project scope management is one of the most critical project management knowledge (skill) areas • Scope defines • All the work that is required to complete the project successfully and • Only the work that is required, no more, no less • This latter point is critical: project scope management defines and controls what is and is not part of the project work SE 477: Lecture 4

Scope planning • Scope planning is concerned with choosing the most appropriate, most effective approach to managing the scope of the project • Scope planning defines how to: • Define the scope • Develop the detailed project scope statement • Define and develop the WBS • Verify project scope • Control project scope • Scope planning takes two primary inputs: the project charter and the preliminary project scope statement • Scope planning results in a project scope management plan SE 477: Lecture 4

Project detailed scope statement • The project detailed scope statement is an evolved version of the preliminary project scope statement • Content (template) requirements are identical to the preliminary version • Actual content of the detailed scope definition should reflect any additional information gathered since preliminary scope statement SE 477: Lecture 4

Inputs, tools & techniques, and outputs Inputs Project management plan Project Charter Enterprise environmental factors Organizational process assets Tools & Techniques Expert judgement Meetings Outputs Scope management plan Requirements management plan SE 477: Lecture 4

Scope management plan • According to PMBOK 5: “The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.” • This course adopts the informal, broadly-framed perspective • The components of a scope management plan include: • Process for preparing a detailed project scope statement • Process that enables the creation of the WBS from the detailed project scope statement • Process that establishes how the WBS will be maintained and approved • Process that speciﬁes how formal acceptance of the completed project deliverables will be obtained • Process to control how requests for changes to the detailed project scope statement will be processed—this process is directly linked to the Perform Integrated Change Control process SE 477: Lecture 4

Requirements management plan • Components of the requirements management plan can include, but are not limited to: • How requirements activities will be planned, tracked, and reported • Conﬁguration management activities such as: • How changes to the product will be initiated • How impacts will be analyzed, how they will be traced, tracked, and reported • Authorization levels required to approve these changes • Requirements prioritization process • Product metrics that will be used and the rationale for using them • Traceability structure to reﬂect which requirement attributes will be captured on the traceability matrix SE 477: Lecture 4

Plan Scope Management: Data Flow Diagram SE 477: Lecture 4

Process: Collect Requirements • Recall the most critical lesson from the Standish Group’s 2009 CHAOS report: • Requirements, requirements, requirements • Requirements are unclear, incomplete, or the project management methodology does not accommodate changing requirements effectively • Collecting initial requirements is a critical ﬁrst step in managing requirements over the course of the project • In an iterative/incremental or adaptive/agile project, requirements collection continues throughout the life cycle of the project • Requirements elicitation and analysis requires a complete course; we touch on the topic here for completeness SE 477: Lecture 4

Types of requirements • Business requirements. Describe the high-level needs of the organization as a whole • Examples: Increase e-commerce purchases by 25% • Stakeholder requirements. Describe the needs of a particular stakeholder, especially with respect to external stakeholders • Example: As the site owner, I want the site supply chain applications to interface with the Web site • Functional requirements.* Describe the behavior of the product • Example: As a retail customer, I want to be able to shop by brand or product category • Nonfunctional requirements.* Describe the behavioral qualities required for the product to be effective • Example: As the Web site owner, I want the site to be available 99.99% of the time over a 1-year period *PMBOK 5 groups functional and nonfunctional requirements under the heading ‘Solution Requirements’ SE 477: Lecture 4

Types of requirements • Transition requirements. Describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current to the future state • Example: As a data entry clerk, I want to be able to use the keyboard shortcuts from the previous order system, so that I can maintain my level of productivity • Project requirements. Describe the actions, processes, or other conditions the project needs to meet • Example: Project must use the a hybrid plan-driven, iterative and agile methodology • Quality requirements. Capture condition or criteria needed to validate the successful completion of a project deliverable • Example: As the site owner, I want a retail customer test group to be able to successfully search for and ﬁnd a requested product within 30 seconds SE 477: Lecture 4

Inputs, tools & techniques, and outputs SE 477: Lecture 4

Requirements documentation • Business requirements • Business and project objectives • Business rules for the performing organization • Guiding principles of the organization. • Stakeholder requirements • Impacts to other organizational areas • Impacts to other entities inside or outside the performing organization • Stakeholder communication and reporting requirements. SE 477: Lecture 4

Requirements documentation • Solution requirements • Functional and nonfunctional requirements • Technology and standard compliance requirements • Support and training requirements • Quality requirements • Reporting requirements • Project requirements • Levels of service, performance, safety, compliance, etc. • Acceptance criteria • Transition requirements • Requirements assumptions, dependencies, and constraints SE 477: Lecture 4

Project Considerations • Is infrastructure setup part of your project? • Assumptions • What are you counting on? • These can be critical to identify • Resources expected: equipment/people, approvals • Availability of partners, connections • Delineate key limits: • For example: System load: expect a maximum of 100 users SE 477: Lecture 4

Overview • The Define Scope process develops a detailed description of the project and product • Implicit (and stated) in the Define Scope process is the assumption that not all of the requirements collected in the Collect Requirements process may be included in the project • Though compatible with an adaptive/agile methodology, this assumption represents a less-flexible approach to managing requirements and scope • The Project Scope Statement describes the project scope, major deliverables, assumptions, and constraints SE 477: Lecture 4

Tools and techniques • Product analysis. Product analysis is the process of translating high-level product descriptions into tangible deliverables. Product analysis in IT includes techniques such as: • System analysis • Requirements analysis • Systems engineering • Alternatives identiﬁcation. Attempts to uncover alternative approaches to executing and performing the project work, using techniques such as brainstorming and mind mapping • Alternatives provide contrasting options to the planned approach, allowing better deﬁnition of scope SE 477: Lecture 4

Project scope statement • The project scope statement documents the entire scope, including project and product scope • Project scope encompasses product scope plus the work required to create the product: any project-related activities, such as documentation delivery and training • Product scope encompasses the functional and non-functional requirements for the ﬁnal project deliverable • The project scope statement provides a common understanding of the project scope among project stakeholders • The project scope statement may contain explicit scope exclusions that can help to manage stakeholder expectations • This can prevent the project from straying from the original vision in all project methodologies: sequential, iterative/incremental, and adaptive/agile SE 477: Lecture 4

Project scope statement • Project scope statement. The project scope statement contents include: • Product scope description. Progressively elaborates the characteristics of the product described in the project charter and requirements • Product acceptance criteria. Conditions required for acceptance of deliverables • Project deliverables. Deliverables include both product outputs and project outputs, such as project reports and documentation • Project exclusions. Identiﬁes what is excluded from project • Project constraints. Lists and describes anything that limits the project team’s options, such as budget, imposed schedule, milestones, etc. • Project assumptions. Lists and describes anything assumed to be true with respect to the scope and impact if these prove to be false SE 477: Lecture 4

Project document updates • Results of the Deﬁne Scope process may affect other project documents, including: • Stakeholder register • Requirements documentation • Requirements traceability matrix [not discussed] SE 477: Lecture 4

Process: Create WBS • WBS – Work Breakdown Structure. Technique for describing all work in a project. • PERT – Program Evaluation and Review Technique. A well-entrenched technique for scheduling. • CPM – Critical Path Method. Used with PERT to determine problems in scheduling. • Gantt Charts – bar chart that graphically displays project schedule SE 477: Lecture 4

The Work Breakdown Structure • The Work Breakdown Structure (WBS) is a hierarchical description of the work that must be done to complete the project as defined in the Project Overview Statement (POS). • The WBS terms • Activity: An activity is simply a chunk of work. • Task: A task is a smaller chunk of work. • Milestone: a task of zero duration. Usually an external event. Can be used to mark completion of an activity or phase. SE 477: Lecture 4

Overview: Tasks • Planning and scheduling use tasks as the basic element. • Sometimes this is known as activities. • The main tool for activity definition is decomposition • Decomposition is the process of breaking the project scope and deliverables into smaller, more manageable components • Decomposition is usually performed in a top-down, hierarchical manner as expressed by the Work Breakdown Structure (WBS) • Creating the Work Breakdown Structure (WBS) is the process of decomposing project deliverables and work into smaller, more manageable components • ‘Work’ in the context of the WBS means work products or deliverables, not the effort itself, as in ‘staff-hours of effort’ SE 477: Lecture 4

Overview: Tasks • The WBS is: • Structured hierarchically: each successively lower level represents a more-detailed definition of project work • Deliverable-oriented: each lower level represents a more detailed definition of project work • A representation of project scope: it organizes and defines the total scope of the project • The lowest level of detail in the WBS is the work package • Work packages are scheduled, cost estimated, monitored, and controlled • Decomposition proceeds until it is possible to define the component as a work package: • A deliverable or work component at the lowest WBS level that includes schedule activities and milestones to complete the deliverables or ‘work’ SE 477: Lecture 4

Work Breakdown Structure • A Work Breakdown Structure (WBS) captures all the work of a project in an organized way. • Portrayed graphically as a hierarchical tree, • A tabular list of "element" categories and tasks or the indented task list that appears in your Gantt chart schedule. • Breaking Large, complex projects into progressively smaller pieces • A collection of defined "work packages" that may include a number of tasks. • Continue to refine work until packages are of a suitable size • A work package can include design, coding, testing, etc. • [See notes below!] SE 477: Lecture 4

Decomposition • Decomposition is the core tool and technique of all WBS effort • Decomposition is the process of breaking down project deliverables and work into smaller, more manageable components • These more manageable components are called work packages • Work packages are the lowest level of decomposition in the WBS • Reliable time, cost, and resource estimates can be made at the level of work packages in a project • The level of detail for work packages vary depending on project size and complexity • As we have seen, for IT projects using the process we have defined, each iteration (sprint) defines one or more work packages SE 477: Lecture 4

Decomposition activities • Identify and analyze the deliverables and related work • The project scope statement provides the basis for the first iteration of deliverable identification • Structure and organize the WBS according to an appropriate high-level hierarchy • For IT projects using an iterative system development model, a phase/iteration/discipline hierarchy most closely matches the SDLC process • Note that one of the disciplines in the iterative SDLC process is ‘Project Management’–it is here that appropriate project management processes may be entered • Decompose the upper WBS levels into lower-level detailed components • If appropriate, larger deliverables may be decomposed into smaller deliverables, all the way down to the work package level SE 477: Lecture 4

Decomposition activities • Develop and assign identification codes to the WBS components • Note that each item in the WBS has both a unique identifier (the code of account identifier) and a WBS code • The unique identifier does not change if a component is moved about in the WBS structure; however, the WBS code does change • Verify that the amount of decomposition of work is necessary and sufficient • This can be translated into a simple concept: the ‘just right’ principle • The just right principle states that no more decomposition is needed–it would be too detailed–and any less decomposition would be too coarse • Insufficient decomposition leads to reduced ability to plan, manage, and control the work • Excessive decomposition leads to wasted effort and decreased efficiency SE 477: Lecture 4

The Work Breakdown Structure GOAL Activity Activity Activity Activity Activity Activity Level 1 Level 2 Activity Task #1 Task #2 Task #3 Task #4 … Task #n SE 477: Lecture 4

Work Breakdown Structure • Breaks project into a hierarchy. • Creates a clear project structure. • Avoids risk of missing project elements. • Enables clarity of high level planning.

Uses for the WBS • Thought process tool: • The WBS is a design and planning tool. • It helps the project manager and the project team visualize exactly how the work of the project can be defined and managed effectively. • Architectural design tool: • The WBS is a picture of the work of the project and how the items of work are related to one another. SE 477: Lecture 4

Uses for the WBS • Planning tool: • In the planning phase, the WBS gives the project team a detailed representation of the project as a collection of activities that must be completed in order for the project to be completed. • It is at the lowest activity level of WBS that we will estimate effort, elapsed time, and resource requirements; build a schedule of when the work will be completed; and estimate deliverable dates and project completion. SE 477: Lecture 4

Uses for the WBS • Project status reporting tool. • The WBS is used as structure for reporting project status. • The project activities are consolidated from the bottom as lower-level activities are completed. • Completion of lower-level activities cause higher-level activities to be partially complete. • Therefore, WBS defines milestone events that can be reported to senior management and to the customer. SE 477: Lecture 4

Six Criteria to Test for Completeness in the WBS • The WBS is developed as part of a Joint Planning session. But how do you know that you’ve done this right? Each activity must possess six characteristics to be considered complete – that is, completely decomposed. The six characteristics are • Status/completion is measurable • Start/end events are clearly defined • Activity has a deliverable • Time/cost is easily estimated • Activity duration is within acceptable limits • Work assignments are independent • Let us review each one in detail … SE 477: Lecture 4

Six Criteria to Test for Completeness in the WBS • Measurable Status: The project manager can ask for the status of an activity at any point in time during the project. If the activity has been defined properly, that question is answered easily. • Example: a system’s documentation is estimated to be about 300 pages long and requires approximately four months of full-time work to write, here is a possible report that a developer can provide regarding the status: “I’ve written 150 pages, so I guess I am 50 percent complete.” SE 477: Lecture 4

Six Criteria to Test for Completeness in the WBS • Bounded: • Each activity should have a clearly defined start and end event. • Once the start event has occurred, work can begin on the activity. • The deliverable is most likely the end event that signals work is closed on the activity. • For example, using the systems documentation example, the start event might be notification to the team member who will manage the creation of the systems documentation that the final acceptance tests of the systems are complete. The end event would be notification to the project manager that the customer has approved the systems documentation. SE 477: Lecture 4

Six Criteria to Test for Completeness in the WBS • Deliverable • The result of completing the work that makes up the activity is the production of a deliverable. • The deliverable is a visible sign that the activity is complete. • This could be an approving manager’s signature, a physical product or document. • Cost/Time Estimate • Each activity should have an estimated time and cost of completion. • Being able to do this at the lowest level of decomposition in the WBS allows you to aggregate to higher levels and the total project cost and the completion date. SE 477: Lecture 4

Six Criteria to Test for Completeness in the WBS • Activity Independence • It is more important that each activity be independent. Once work has begun on the activity, it can continue reasonably without interruption and without the need of additional input or information until the activity is complete. • Though it is possible that an activity could be scheduled during different times based on resource availability. SE 477: Lecture 4

Approaches to Building the WBS • There are many ways to build the WBS. There is no one correct way to create the WBS. Hypothetically, if we put each member of the JPP session in a different room and asked that person to develop the project WBS, they might all come with different answers. • There are three general approaches to building the WBS: • Noun-type approaches. • Verb-type approaches. • Organizational approaches SE 477: Lecture 4

Approaches to Building the WBS • Noun-type approaches. Noun-type approaches define the deliverable of the project work in terms of the components ( physical or functional) that make up the deliverable. • Verb-type approaches. Verb-type approaches define the deliverable of the project work in terms of the actions that must be done to produce the deliverable. These include the design-build-test-implementand project objectivesapproaches. • Organizational approaches. Organizational approaches define the deliverable of the project work in terms of the organizational units that will work on the project. This type of approach includes the department, process, and geographic location approaches. SE 477: Lecture 4

WBS and Gantt Chart in Microsoft Project SE 477: Lecture 4

Importance of Phases • The end of each phase should be a milestone • The end of each significant task should be a milestone • These can define your management review points • “Phase exits” or “kill points” • Ensure continued alignment with goals • Form of Validation & Verification (V&V) • Milestones should be entered into the WBS as a zero duration task such as “approve project plan” SE 477: Lecture 4

SE 477 Software and Systems Project Management