SE 477 Software and Systems Project Management

SE 477 Software and Systems Project Management
January 25, 2017 SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor Office: CDM, Room 428 Office Hours: Wednesday, 4:00 – 5:30 January 25, 2017 SE 477: Lecture 4 Lecture 4

Administrivia Comments and feedback MS-Project Homework
SE 477 January 25, 2017 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 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! January 25, 2017 SE 477: Lecture 4 Lecture 4

Administrivia Project Continue work on team assignment
SE 477 January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 4

Homework Assignment 3 – Due February 8, 2017
SE 477 January 25, 2017 Assignment 3 – Due February 8, 2017 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 3/20/2017? Don’t forget holidays! Show the duration and delivery schedule given the start date is March 20, 2017. Show the staffing and resources used, and the total staff time. You should use ProjectLibre or MS Project to develop this. January 25, 2017 SE 477: Lecture 4 Lecture 4

SE 477 – Class 4 Topic: Project Planning Project scope management
January 25, 2017 Topic: Project Planning Project scope management Project requirements Creating the Work Breakdown Structure (WBS) Activity: Activity Definition Activity Sequencing Reading: PMBOK-SWE Ch. 5, Ch January 25, 2017 SE 477: Lecture 4 Lecture 4

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

Last time Initial Phase: Project planning
January 25, 2017 Initial Phase: Developing the project charter Statement of work (SOW) Agile Perspective: The Product Overview Document Stakeholders Organizational Structures & Influences Project planning Initial documents Project Charter – Statement of Work (SOW) Project plans The Project Management Plan; January 25, 2017 SE 477: Lecture 4 Lecture 4

Project Planning: A 12 Step Program
SE 477 January 25, 2017 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 January 25, 2017 SE 477: Lecture 4 Lecture 4

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

SE 477 Scope January 25, 2017 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 January 25, 2017 SE 477: Lecture 4 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 January 25, 2017 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 January 25, 2017 SE 477: Lecture 4

Inputs, tools & techniques, and outputs
Project management plan Project Charter Enterprise environmental factors Organizational process assets Tools & Techniques Expert judgment Meetings Outputs Scope management plan Requirements management plan January 25, 2017 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 January 25, 2017 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 January 25, 2017 SE 477: Lecture 4

Plan Scope Management: Data Flow Diagram
January 25, 2017 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 January 25, 2017 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’ January 25, 2017 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 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 January 25, 2017 SE 477: Lecture 4

Inputs, tools & techniques, and outputs
January 25, 2017 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. January 25, 2017 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 January 25, 2017 SE 477: Lecture 4

Project Considerations
SE 477 January 25, 2017 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 January 25, 2017 SE 477: Lecture 4 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 January 25, 2017 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 January 25, 2017 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 January 25, 2017 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 January 25, 2017 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] January 25, 2017 SE 477: Lecture 4

Process: Create WBS SE 477 January 25, 2017 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 PERT - short for Program Evaluation & Review Technique - is an outgrowth of research work carried out by the U.S. navy in the late 1950s, when they were trying to put the Polaris Fleet Ballistic Missile Project on schedule. The Basics Stripped off its glamour, PERT at its core is a management of probabilities, which it handles quite elegantly through simple statistics. People often speak of PERT and CPM in the same breath. CPM, or Critical Path Method, too has the same mandate as PERT, though the focus of CPM is slightly different. The basic take-off stage in both CPM and PERT is to identify the tasks (or activities) required to complete the given project. A Gantt chart may be deployed to list the activities in a structured fashion, along with their interdependencies. This logically flows into the next stage, where a "network" of the activities and their dependencies is drawn up. In this network, each event may be represented by a node. Activities form arrows, with their tail touching one predecessor event, and their head touching the event that logically follows it (or is subsequent to it). Before any activity can begin, all its predecessor activities must have been completed. January 25, 2017 SE 477: Lecture 4 Lecture 3

The Work Breakdown Structure
SE 477 January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

“Gallia est omnis divisa in partes tres”
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 “Gallia est omnis divisa in partes tres” Commentarii de Bello Gallico Julius Caesar Divide and Conquer Decomposition is the process of breaking the project scope and deliverables 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 ‘Work’ in the context of the WBS means work products or deliverables, not the effort itself, as in ‘staff-hours of effort’ January 25, 2017 SE 477: Lecture 4

Decomposition 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 The level of detail for work packages vary depending on project size and complexity As we have seen, for IT projects using the agile process we have defined, each iteration (sprint) defines one or more work packages January 25, 2017 SE 477: Lecture 4

Overview: Tasks Decomposition is the core tool and technique of all WBS effort 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’ January 25, 2017 SE 477: Lecture 4

Work Breakdown Structure
A Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an organized way. It is often portrayed graphically as a hierarchical tree, however, it can also be a tabular list of "element" categories and tasks or the indented task list that appears in your Gantt chart schedule. Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. A $1,000,000,000 project is simply a lot of $50,000 projects joined together. The Work Breakdown Structure (WBS) is used to provide the framework for organizing and managing the work. In planning a project, it is normal to find oneself momentarily overwhelmed and confused, when one begins to grasp the details and scope of even a modest size project. This results from one person trying to understand the details of work that will be performed by a number of people over a period of time. The way to get beyond being overwhelmed and confused is to to break the project into pieces, organize the pieces in a logical way using a WBS, and then get help from the rest of your project team. The psychologists say our brains can normally comprehend around 7-9 items simultaneously. A project with thousands or even dozens of tasks goes way over our ability to grasp all at once. The solution is to divide and conquer. The WBS helps break thousands of tasks into chunks that we can understand and assimilate. Preparing and understanding a WBS for your project is a big step towards managing and mastering its inherent complexity. Work Breakdown Structure SE 477 January 25, 2017 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!] A Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an organized way. It is often portrayed graphically as a hierarchical tree, however, it can also be a tabular list of "element" categories and tasks or the indented task list that appears in your Gantt chart schedule. Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. A $1,000,000,000 project is simply a lot of $50,000 projects joined together. The Work Breakdown Structure (WBS) is used to provide the framework for organizing and managing the work. In planning a project, it is normal to find oneself momentarily overwhelmed and confused, when one begins to grasp the details and scope of even a modest size project. This results from one person trying to understand the details of work that will be performed by a number of people over a period of time. The way to get beyond being overwhelmed and confused is to to break the project into pieces, organize the pieces in a logical way using a WBS, and then get help from the rest of your project team. The psychologists say our brains can normally comprehend around 7-9 items simultaneously. A project with thousands or even dozens of tasks goes way over our ability to grasp all at once. The solution is to divide and conquer. The WBS helps break thousands of tasks into chunks that we can understand and assimilate. Preparing and understanding a WBS for your project is a big step towards managing and mastering its inherent complexity. January 25, 2017 SE 477: Lecture 4 Lecture 3

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 January 25, 2017 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 or 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 January 25, 2017 SE 477: Lecture 4

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

Work Breakdown Structure
SE 477 January 25, 2017 Work Breakdown Structure Out of date Breaks project into a hierarchy. Creates a clear project structure. Avoids risk of missing project elements. Enables clarity of high level planning. Lecture 3

Uses for the WBS Thought process tool:
January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

Uses for the WBS Planning tool:
January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

Uses for the WBS Project status reporting tool.
January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

Six Criteria to Test for Completeness in the WBS
SE 477 January 25, 2017 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 … January 25, 2017 SE 477: Lecture 4 Lecture 3

SE 477 January 25, 2017 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.” January 25, 2017 SE 477: Lecture 4 Lecture 3

SE 477 January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

SE 477 January 25, 2017 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

SE 477 January 25, 2017 Activity Independence It is 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

Approaches to Building the WBS
SE 477 January 25, 2017 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 January 25, 2017 SE 477: Lecture 4 Lecture 3

Approaches to Building the WBS
SE 477 January 25, 2017 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-implement and project objectives approaches. 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. January 25, 2017 SE 477: Lecture 4 Lecture 3

WBS and Gantt Chart in Microsoft Project
SE 477 January 25, 2017 Out of date screen shot January 25, 2017 SE 477: Lecture 4 Lecture 3

Importance of Phases The end of each phase should be a milestone
January 25, 2017 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” January 25, 2017 SE 477: Lecture 4 Lecture 3

Work Breakdown Structure (WBS)
SE 477 January 25, 2017 Recall the definition from the PMBOK Guide: “The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.” WBS is the primary tool for managing the scope of a project Work in the WBS is within scope Work not in the WBS is out of scope Though relatively simple, considered the single most important project management tool In WBS, levels represent different levels of project decomposition January 25, 2017 SE 477: Lecture 4 Lecture 4

The 100% rule The 100% rule is one of the most important principles guiding development, decomposition, and evaluation of the WBS Rule states that the WBS: Includes 100% of the work defined by the project scope Captures all internal, external, and interim deliverables in terms of work to be completed, including project management Rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent” WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work January 25, 2017 SE 477: Lecture 4

Conventional WBS levels
SE 477 January 25, 2017 Level 1 Project name Level 2 Major subsystems of the project Level 3 Components/task activities of subsystems at Level 2 Level 4 Subcomponents/subtasks of components/tasks at Level 3 Level 5 Work packages for subcomponents/subtasks at Level 4 Work packages are where the actual work takes place Assigned to a person and given a schedule and budget Note that conventional WBS decomposition levels are product-oriented January 25, 2017 SE 477: Lecture 4 Lecture 4

Criticisms of conventional WBS
SE 477 January 25, 2017 Conventional WBS is prematurely structured around product design Note early orientation toward concrete subsystems Conventional WBS is prematurely decomposed, planned, and budgeted in too much or too little detail Recall the idea of progressive elaboration Conventional WBS is project-specific, making cross-project comparisons difficult or impossible Result of first item, above January 25, 2017 SE 477: Lecture 4 Lecture 4

Sample conventional WBS
SE 477 January 25, 2017 Note early commitment to a specific system decomposition or architecture Other subsystems have same WBS pattern as sensor detection subsystem Comparison of different projects requires extracting this information for each subsystem & combining January 25, 2017 SE 477: Lecture 4 Lecture 4

WBS terminology (PMI) Deliverable. Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project Milestone. A significant point or event in the project Work Breakdown Structure Component. Entry in the work breakdown structure that can be at any level. Also known as WBS Element Work Package. Deliverable or project work component at the lowest level of each branch of the WBS. Includes schedule activities and milestones required to complete the work package deliverable or project work component Note: It is not necessary to enter every work package activity as a separate WBS component January 25, 2017 SE 477: Lecture 4

WBS representations There are two common ways of representing the WBS
Hierarchical graphical format. A graphical view, similar in form to an organization chart Hierarchical textual format. This is the common hierarchical list view of the WBS, provided by most project management software such as MS Project WBS should always be developed before the schedule is worked out, without trying to sequence specific activities This is primarily important (and essential) when using a functional WBS decomposition Process-oriented WBS decomposition (e.g. evolutionary) usually has well-defined higher-level WBS components Specific activity sequencing is determined in the schedule January 25, 2017 SE 477: Lecture 4

Rolling wave planning SE 477 January 25, 2017 Our understanding of work that must be accomplished in the near term is better than that for work to be performed far in the future Rolling wave planning varies the amount of planning detail depending on the immediacy of the tasks to be performed Rolling wave planning is a means for implementing progressive elaboration Work in the upcoming one or two reporting periods is planned in detail, while later work is planned at a lower level of detail January 25, 2017 SE 477: Lecture 4 Lecture 4

Rolling wave planning Note on 100% rule:
SE 477 January 25, 2017 Note on 100% rule: What encompasses 100% of the project work is referenced to a particular time point in the project Scope may change, but only with proper approval and control Implication: ‘100%’ comprises all approved work at a particular point in time January 25, 2017 SE 477: Lecture 4 Lecture 4

Create WBS: Outputs Scope baseline. The scope baseline is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary: Project scope statement. Output from Deﬁne Scope process WBS. Either graphical or tabular form WBS dictionary. A companion document to the WBS, providing detailed information about components in the WBS, including work packages (see next slide for content) In a conventional project management environment the scope baseline can be changed only through formal change control procedures January 25, 2017 SE 477: Lecture 4

WBS dictionary Companion document to the WBS
Provides the detailed content for the WBS, including work packages Practically, WBS dictionary is developed concurrently with Activity Definition process under Project Time Management knowledge area WBS components are cross-referenced to other WBS components as needed January 25, 2017 SE 477: Lecture 4

WBS dictionary content
Required Code or account identifier – unique number assigned to a WBS component Statement of work – scope statement for the WBS component Responsible organization for WBS component Schedule milestones for WBS component Optional Contract information Quality requirements – may be used in assessment planning Technical references to assist in executing work Charge number List of schedule activities Resources required Estimate of cost January 25, 2017 SE 477: Lecture 4

WBS template January 25, 2017 SE 477: Lecture 4
Component groups with a ‘+’ in front of them are ‘rolled up’–subcomponents are hidden to reduce clutter January 25, 2017 SE 477: Lecture 4

Activity or task definition
SE 477 January 25, 2017 Activity or task definition Added System architecture definition WBS component Note expansion and detailing of WBS template Architecture design modeling entry; renamed Software architecture description to Document software architecture Note expansion and detailing of WBS template Design demonstration planning and conduct entry Consider the example: Automatic Toll Booth See Note rework of WBS template Elaboration phase assessment entry Note expansion and detailing of WBS template Critical component coding demo integration entry January 25, 2017 SE 477: Lecture 4 Lecture 4

Create WBS: Data Flow Diagram
SE 477 January 25, 2017 Adapted from Figure 5-10 PMBOK Guide, 5th Edition January 25, 2017 SE 477: Lecture 4 Lecture 4

Agile Perspective: Create WBS
Valuable concepts and tools The Create WBS process is among the least compatible with a complex (or agile) project perspective It encourages solidifying the scope of the project in a complex, difﬁcult to change artifact, the WBS Once an artifact is created, it assumes an authority that may not be justiﬁed Most WBSs are out-of-date shortly after being created People are reluctant to toss something that has taken so much effort Nevertheless, the process of thoughtful decomposition of the product into smaller, more manageable pieces is certainly compatible with an adaptive/agile methodology Adaptive/agile limits high-level decomposition to the product roadmap, and defers low-level decomposition to the release and iteration (sprint) level January 25, 2017 SE 477: Lecture 4

WBS – Basis of Many Things
Network scheduling Costing Risk analysis Organizational structure Control Measurement January 25, 2017 SE 477: Lecture 4

The MS-Project Process
SE 477 The MS-Project Process January 25, 2017 Move WBS into a Project outline (in Task Sheet) Add resources (team members or roles) Add costs for resources Assign resources to tasks Establish dependencies Refine and optimize Create baseline Track progress (enter actuals, etc.) January 25, 2017 SE 477: Lecture 4 Lecture 4

Defining Task Sets Determine type of project
January 25, 2017 Determine type of project Assess the degree of rigor required Identify adaptation criteria Select appropriate software engineering tasks Task Set Refinement Use Work Breakdown Structure to determine tasks Define a Task Network Use a Gantt Chart and/or PERT to document January 25, 2017 SE 477: Lecture 4 Lecture 3

Project Planning Project Time Management I
Introduction Activity Definition Activity Sequencing January 25, 2017 SE 477: Lecture 4

Overview Project time management is the project management knowledge area concerned with analyzing the logical and temporal relationships among the activities needed to complete the project Three elements form the core of time management analysis: The schedule data and associated calculations (e.g., activity deﬁnitions and estimates) The scheduling method applied to the schedule data in order to deﬁne estimated start and end dates for activities and milestones, including project completion The schedule that represents the output from a scheduling tool applying the method to the data In a conventional methodology, the project schedule acts as the planning backbone for virtually all other project activities January 25, 2017 SE 477: Lecture 4

Project time management processes
The project time management processes include: Define activities. Identifies specific activities to be carried out in work packages Sequence activities. Identify and document relationships among activities Estimate activity resources. Estimate the number and type of resources needed for activity, such as staff, materials, equipment, software, etc. Estimate activity durations. Estimate number of work periods (e.g. hours, days, weeks) to complete activity with estimated resources Develop schedule. Analyze network of activity sequences, durations, resources, and constraints to estimate planned dates for activities and milestones January 25, 2017 SE 477: Lecture 4

Project time management processes
The project time management processes include: Control schedule. Monitor schedule status and manage schedule updates We focus only on the planning process knowledge area for time management, comprising the the ﬁrst ﬁve processes above. In practice, on smaller projects, the middle four processes are carried out concurrently January 25, 2017 SE 477: Lecture 4

Scheduling workflow Define activities
Use of WBS helps guide definition process and organize activities Perform activity sequencing Develop schedule framework according to what is logically possible – perform resource allocation later Estimate effort – the total number of labor units (e.g. staff-days) for each activity Estimate elapsed time Identify resources for each activity Apply calendars to schedule framework January 25, 2017 SE 477: Lecture 4

Scheduling workflow Some of these will be covered in a later lecture.
Estimate activity duration based on resources for activity Perform forward pass or backward pass critical path analysis to generate schedule model [later lecture – appendix] Apply schedule compression, if needed Perform ‘what-if’ scenario analysis to identify contingency and risk response needs Apply resource leveling to schedule model January 25, 2017 SE 477: Lecture 4

Planning, Estimating, Scheduling
SE 477 January 25, 2017 What's the difference? Plan: Identify activities. No specific start and end dates. Estimating: Determining the size & duration of activities. Schedule: Adds specific start and end dates, relationships, and resources. Note the term activities – much the same as tasks but more general. January 25, 2017 SE 477: Lecture 4 Lecture 4

How To Schedule Identify “what” needs to be done
SE 477 January 25, 2017 Identify “what” needs to be done Work Breakdown Structure (WBS) Identify “how much” (the size) Size estimation techniques Identify duration Effort estimation techniques Identify the dependency between tasks Dependency graph, network diagram Gantt chart and PERT Estimate total duration of the work to be done The actual schedule PERT and CPM January 25, 2017 SE 477: Lecture 4 Lecture 4

Overview The Define Activities process identifies the specific actions or tasks needed to carry out the project and produce the project deliverables In a conventional project methodology, the Create WBS process defines the project deliverables and work packages In an adaptive/agile project methodology, only the high-level deliverables are defined up front, while work packages are defined at the iteration level Each work package comprises the specific activities needed to complete the work package Recall that: Deliverables and work packages are the planning units for project management purposes Tasks (activities) are the planning unit for development purposes An iteration/sprint comprises one or more work packages (and their associated activities) January 25, 2017 SE 477: Lecture 4

Activity definition PMBOK factors out activity definition as a separate process from the creation of the WBS However, in practice, the activity definition list, WBS, and WBS dictionary are usually developed concurrently Rolling wave planning should be applied to activity definition in order to optimize the level of detail in the WBS: neither too little (for immediate work) or too much (for later work) The main tool for activity definition is decomposition January 25, 2017 SE 477: Lecture 4

Activity definition 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 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 Significant part of the WBS decomposition can be defined by WBS templates (see Practice Standard for Work Breakdown Structures, Second Edition (ebooks 24x7), for examples) January 25, 2017 SE 477: Lecture 4

Sidebar: A useful rule of thumb
No work package should have a duration greater than four to six weeks For knowledge work, durations should be in the range of one to three weeks, because knowledge work is harder to track than tangible work People tend to back-end load tasks with lengthy durations by pushing all the effort toward the end For this class [the team project], keep work package durations in the one-to-two-week range January 25, 2017 SE 477: Lecture 4

Activity definition workflow
Choose an appropriate WBS template as a guide for activity definition Enter WBS template into a project management tool (if preloaded template not available) Define activities in the task list of the project management tool If decomposition results in an activity with a deliverable/work component and a duration of 1-2 weeks, consider it a work package If decomposition results in a set of shorter (<1 wk) activities, group them into one or more 1-2 week work packages that produce deliverable/work components January 25, 2017 SE 477: Lecture 4

Activity definition workflow
Assign each activity a unique identification code that remains with the activity if it is moved in the list The WBS code is a position-dependent hierarchical code – it does not stay with an activity if moved Example: Architectural Cost-Benefit Analysis has a WBS code of but a unique identification code of (hypothetically) ADM2 (or 25.0, or any other code) Work packages usually have additional activity detail specified in their WBS dictionary entry This is essential if the work package is not a highly standardized process January 25, 2017 SE 477: Lecture 4

Agile Perspective: Define Activities
Essential, but do it just in time In this process, PMBOK leans heavily toward the complicated—rather than complex—project methodology The PMBOK states: “The activity list is a comprehensive list that includes all schedule activities required on the project” In an adaptive/agile project, this list cannot—and should not—be generated early in the project Attempting to define activities up-front in a complex project leads to wasted effort and inconsistencies between documents and reality Instead, application of the agile method delays specific activity definition to the start of each individual sprint, and delegates the activity definition to the individual sprint development teams Define activities no earlier than during iteration planning January 25, 2017 SE 477: Lecture 4

Reading Practice Standard for Work Breakdown Structures, Second Edition by Project Management Institute (2006) Available on Books 24x7 (through the DePaul e-library) Appendix K: Web Design Work Breakdown Structure (WBS) Example Appendix O: Software Implementation WBS Example Note that both of these templates are process-oriented January 25, 2017 SE 477: Lecture 4

Precedence diagram method Dependency types Leads and lags
Activity Sequencing Precedence diagram method Dependency types Leads and lags January 25, 2017 SE 477: Lecture 4

Introduction Activity sequencing identifies and documents the logical relationships among activities in a project Logical sequencing is determined by precedence (predecessor-successor) relationships Activity sequencing, though executed differently is an important concept in all project management methodologies Essential inputs Activity list, which may be developed concurrently with WBS May use scope statement information to determine or refine precedence constraints Essential outputs Project schedule network diagrams Updated activity list/WBS January 25, 2017 SE 477: Lecture 4

Precedence Diagram Method (PDM)
The Precedence Diagram Method (PDM) is a graphical schedule diagramming method aka Network Diagram Represents activities as rectangular nodes Connects the nodes with arrows to show dependencies Connection points of arrows to activities refine and impose constraints on dependencies Classified as an ‘Activity on Node’ (AON) diagramming scheme Alternative is ‘Activity on Arrow’ (AOA) that models project in states, with activities as transitions from one state to another January 25, 2017 SE 477: Lecture 4

Dependency types illustrated
Activity 2 Percent Complete Activity 1 Finish-to-Start Start-to-Start Finish-to-Finish Start-to-Finish 50% 30% January 25, 2017 SE 477: Lecture 4

Dependency types SE 477 January 25, 2017 Finish-to-start. Start of successor activity depends on finish of predecessor activity Example: Start of testing after code completion in traditional waterfall development Finish-to-finish. Finish of successor activity depends on finish of predecessor activity Example: Acceptance of a component can only complete when acceptance of last subcomponent is complete Start-to-start. Start of successor activity depends on start of predecessor activity Example: Start of acquisition of third-party software component triggers training for involved developers January 25, 2017 SE 477: Lecture 4 Lecture 4

Dependency types Start-to-finish. Finish of successor activity depends on start of predecessor activity Example: Subcontract x will complete t days after subcontract y begins Percent complete: Last n% of successor activity depends on m% completion of predecessor activity Example: Last 30% of network interface development will begin when 50% of application development is complete Note: A better choice of terms might be dependent and independent activities, as in the cases of Start-to-start and Start-to-finish January 25, 2017 SE 477: Lecture 4

PDM example January 25, 2017 SE 477: Lecture 4

Activity sequencing Note dual predecessors.
Default relationship is Finish-to-Start. Here, we have defined a Start-to-Start relationship with an added lag of 5 days Here, we have defined a Finish-to-Finish relationship: this is common for implementation/integration task pairs

Dependency type determination
Mandatory dependencies. Dependencies that are inherent in the nature of the work Example: Acceptance testing can only begin after all code development is complete (except for bug fixes) Discretionary dependencies. Dependencies that are not inherent in the work, but might be preferred by the PM team based on best practices or other factors. Also known as preferred or soft logic Discretionary dependencies should be fully documented so they can be properly considered and evaluated for later scheduling options Example: Schedule high-risk activities early in development in order to mitigate those risks (best practice) Example: Beginning work on second draft of a document before first draft is complete Example: admissions system has a dependency upon delivery and configuration of smart card reader January 25, 2017 SE 477: Lecture 4

Dependency type determination
Internal dependencies. Dependencies that are between project activities and within the project team's control Example: Start of procurement of third-party software component triggers training for developers who will work with the component (internal, discretionary dependency) External dependencies. Dependencies that involve a relationship between project and non-project activities External dependencies are usually outside the project team's control Example: Delivery of any third-party component, such as a custom or COTS component January 25, 2017 SE 477: Lecture 4

Leads and lags Lead. A lead moves an activity back in time from its expected point. Sometimes referred to as an accelerated activity Example: Beginning work on second draft of document before first draft is complete Lag. A lag introduces a delay into a successor activity. Restricts the start of the successor, even if predecessor activity is complete Example: Requiring ten days lag before acceptance testing can begin (possibly introduced as contingency) January 25, 2017 SE 477: Lecture 4

Outputs Schedule network diagrams. Schedule network diagrams graph the project activities and their dependencies. These may be produced manually or using project management software Documentation explaining discretionary dependencies, leads and lags, or other exceptional dependencies should accompany the diagram Project document updates. The Sequence Activities process may lead to updates in the following project documents: Activity lists Activity attributes, speciﬁcally the predecessor and successor activities, logical relationships, and leads and lags attributes Milestone lists Risk register January 25, 2017 SE 477: Lecture 4

Task Name ID Description of work Duration (days)
Start Date (Earliest, Latest) Finish Date (Earliest, Latest) Resources (People and equipment) Effort (In staff-days) Predecessors (other tasks) Inputs (documents, decisions, information) Successors (other tasks) Outputs (documents, decisions, information) January 25, 2017 SE 477: Lecture 4

Agile Perspective: Sequence Activities
Useful concepts, but apply them just in time As in the Define Activities process, PMBOK leans heavily toward the complicated—rather than complex—project methodology perspective The concepts of activity dependency are applicable across all project management methodologies However, in an adaptive/agile project, the activity list, upon which sequencing depends, is generated in small chunks throughout the project at the start of each individual sprint This is the logical time at which to work out sequencing of specific activities Define activities no earlier than during iteration planning January 25, 2017 SE 477: Lecture 4

Next Class Topic: Reading: Activity Resource Estimating
SE 477 January 25, 2017 Topic: Activity Resource Estimating Activity Duration Estimating Estimating Size and complexity Tools Gantt Chart PERT Schedule Development Reading: PMBOK-SWE Ch. 6 Intro & Ch. 6.1-Ch. 6.6 January 25, 2017 SE 477: Lecture 4 Lecture 4

Journal Exercise Considering the WBS:
Lecture 1 January 8, 2008 January 25, 2017 April 3, 2008 April 3, 2008 Considering the WBS: How detailed should a project get? Should we include sub-activities? For example, should the coding task have sub-tasks of Write code Review code Test code Release code to the CM system Should we have a test for each code module? We don't even know what the software looks like! January 25, 2017 SE 477: Lecture 4 Lecture 3 SE 425 Lecture 1 Lecture 1 101/108 101/85 101/108

SE 477 Software and Systems Project Management

Similar presentations

Presentation on theme: "SE 477 Software and Systems Project Management"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SE 477 Software and Systems Project Management

Similar presentations

Presentation on theme: "SE 477 Software and Systems Project Management"— Presentation transcript:

Similar presentations

About project

Feedback