Initiating Projects and Managing Scope This material is

Initiating Projects and Managing Scope This material is based on the Fifth Edition of the Guide to the Project Management Body of Knowledge (PMBOK® Guide) published by the Project Management Institute (PMI®) in 2013. PMI and PMBOK are registered marks of Project Management Institute, Inc. 1

Key Learning Outcomes When you complete this course you will be able to: 1) Distinguish the project management knowledge areas from project management process groups 2) Describe what is needed to get a project started 3) Explain what SMART objectives are 4) Describe the purpose and typical content of a project charter 5) Define project stakeholders 6) Describe stakeholder analysis and its purpose 7) Describe the four essentials of project initiation 8) Explain the crucial importance of getting scope correct 9) Explain what a work breakdown structure (WBS) is 10) Describe the uses and importance of a WBS 11) Discuss how a WBS can be used for bottom-up estimating 12) Explain what change control is and why it is necessary 2

CONTENTS n n n Module 1: Process Groups and Knowledge Areas Module 2: Initiating the Project Module 3: Completing the Project Charter Module 4: Identifying Stakeholders Module 5: Managing Scope Module 6: Controlling Scope 3

MODULE 1 Process Groups and Knowledge Areas 4

Accomplishing Tasks through Processes § § § Recall that the PMBOK® Guide identifies a total of 47 fundamental project management processes These processes are logically grouped in two complementary ways: by major process group and by project management knowledge area There are five process groups There are ten knowledge areas The knowledge areas are integrated across various process groups 5

The Five Project Management Process Groups (Five Process Groups) Monitoring & Controlling Processes Project Deliverables Project Inputs Closing Processes Initiating Processes Executing Processes 6 Project Records This diagram is adapted from the Guide to the Project Management Body of Knowledge (PMBOK ® Guide), 5 th Edition Process Assets Project Sponsor Planning Processes End users Project Boundaries

The Five Process Groups Reviewed n The Initiating Process Group q n The Planning Process Group q n This group encompasses the set of processes that are performed at the beginning of a project to define the project at a high level and obtain the authorization necessary to commit resources to officially start the project This group is engaged to establish the scope of the project -- what is inside and what is outside the project’s boundaries, and to refine the project objectives and plan a course of action that will achieve these objectives. The Executing Process Group q This group focuses on managing the performance of the planned work activities so that they will produce results that satisfy the project objectives. 7

The Five Process Groups Reviewed (cont’d) n The Monitoring and Controlling Process Group q q n This group is designed to monitor, track, review and adjust the project activities based on the performance being observed In addition, the monitoring and controlling process group will help identify and initiate needed changes to the project plan. The Closing Process Group q This group is used to finalize all the activities at the end of the project and formerly close the project 8

The Ten Knowledge Areas n There are 9 major management activities plus the integration of all these throughout the project, and these comprise the ten fundamental knowledge areas of project management: q Scope Management q Time Management q Cost Management q Quality Management q Human Resource Management q Communications Management q Stakeholder Management q Risk Management q Procurement Management q Integration Management Memory Joggers S T C – triple constraints Q H C S – team-oriented issues R P I – overall project challenges 9

Knowledge Areas Integration Management Project Management Process Groups Initiating Planning Executing Monitoring/Controlling Closing • Develop Project Charter • Develop Project Management Plan • • • • Scope Management Time Management Cost Management Quality Management Plan Scope Management Collect Requirements Define Scope Create WBS Plan Schedule Management Define Activities Sequence Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule Plan Cost Management Estimate Costs Determine Budget • Plan Quality Management Human Resource Management • Plan Human Resource Management Communications Management • Plan Communications Management • Direct and Manage Project Work • Monitor and Control Project Work • Perform Integrated Change Control • Validate Scope • Control Schedule Adapted from PMBOK® Guide Our Focus In this lecture • Control Costs • Perform Quality Assurance • Acquire Project Team • Develop Project Team • Manage Communications • Control Quality • Control Communications Risk Management • • • Procurement Management • Plan Procurement Management • Conduct Procurements • Control Procurements • Plan Stakeholder Management • Manage Stakeholder Engagement • Control Stakeholder Engagement Stakeholder Management • Identify Stakeholders • Close Project or Phase • Control Risks Plan Risk Management Identify Risks Quantitative Risk Analysis Qualitative Risk Analysis Plan Risk Responses • Close Procurements

MODULE 2 Initiating the Project 11

Project Management and System Development Recall that: n n Project management acts as an umbrella process over the software development methodology These must be smoothly integrated for optimal success Project Management Initiating System Development Methodology 12

Projects are Developed and Managed via Work Products PM Methodology Project Management Work Products Design Build Accept Roll out Product Development Work Products Build Methodology 13

Characteristics of Product Life Cycle Phases n n n Each phase is marked by completion of one or more deliverables Conclusion of a phase is marked by a review of the deliverables in order to: q Detect and correct errors q Determine when we’re ready to continue to the next phase The goal is to build the product via these deliverables 14

Characteristics of Project Management Process Groups n Each process group in project management is also n n marked by completion of one or more deliverables or work products The goal is to manage the building of the product via these deliverables and work products Recall though that process groups are not phases – they interact throughout the project life cycle Monitoring & Controlling Planning Closing Initiating This diagram adapted from PMBOK ® Guide, 5 th Edition Executing 15

The Initiating Process Group n n n Shortest in duration of all the project management processes – but the most important Closely tied to the scope phase of the software development life cycle Simply put: q q n If done well, it sets the stage for a successful scope phase If done hastily or sloppily, it sets the stage for failure of the entire project There are two major deliverables within the Initiating Process Group: Project Charter Stakeholder Register 16

What Do We Need to Start a Project? n n n The Initiating Process Group comprises the set of processes that are performed at the beginning of a project A primary focus at this point is to define the project scope at a high level and obtain the authorization necessary to commit resources to officially start the project If not already been done, the project manager will also be selected and assigned All this is captured in the Project Charter Also, important internal and external stakeholders are identified, analyzed, and classified This information is recorded in a document called the Stakeholder Register 17

What Do We Need to Start a Project? (cont’d) n Hence the two major processes within the Initiating n Process Group are the Develop Project Charter process the Identify Stakeholders process The Develop Project Charter process belongs to the Integration Management knowledge area and the Identify Stakeholders process belongs to the Stakeholder Management knowledge area See next slide 18

Knowledge Areas and Processes Used in Initiating Project Management Process Groups Knowledge Area Initiating Planning Executing Monitoring/ Closing Integration Management • Develop Project Charter • Develop Project • Direct and Management Plan Project Work Stakeholder Management • Identify Stakeholders • Plan Stakeholder Management Controlling • Monitor and Control • Close Project or Phase Project Work • Perform Integrated Change Control • Manage Stakeholder • Control Stakeholder Engagement See Chap 4 in the PMBOK® Guide Adapted from the PMBOK® Guide 19

Process Inputs, Tools/Techniques, and Outputs n All processes can be characterized at a high level by three components, namely: q q q n n Inputs Tools and techniques applicable within the process Outputs As a consequence we can shed considerable light on each process we define by identifying for it the essential elements of these three major components The PMBOK takes the Inputs-Tools/Techniques-Outputs approach in describing processes. 20

Develop Charter: Inputs n Inputs that are typical for the Develop Project Charter process are: q Statement of work (SOW) q Business case q Agreements q Enterprise environmental factors (EEF) q Organizational process assets (OPA) 21

Statement of Work (SOW) n n Charter Inputs • • • Statement of Work Business Case Agreements Enterprise Environmental Factors Organizational Process Assets An SOW is a narrative description of products, services, or results to be delivered by a project The SOW should reference the Business Need and state how, at a high-level, the project will respond to and satisfy that need This kind of SOW is sometimes called a Work Definition Document Note that if the project is to be performed by an outside organization, the SOW must be more detailed as it will form the basis for a contract for the work to be done. We'll cover this more formal SOW in detail in the later course PM 525 where we discuss contracts and procurement. 22

Statement of Work (SOW) n Charter Inputs • • • Statement of Work Business Case Agreements Enterprise Environmental Factors Organizational Process Assets An SOW references: n Business need (the fundamental reason for the project work) n Product scope description (documents the characteristics of the product, service, or results that the project will create) n Strategic plan (all projects should be aligned with their organization’s strategic plan) 23

Business Case n n n Charter Inputs • • • Statement of Work Business Case Agreements Enterprise Environmental Factors Organizational Process Assets A business case documents an analysis of the business need and the proposed work to decide from a business standpoint whether the project is worth the required investment Such analysis, often called a cost/benefits analysis, is usually conducted before the project begins by a business analyst and/or a steering group The business case is created as result of one or more of the following: n n n Market demand Organizational need Customer request Available technology Ecological impacts 24

Agreements n Charter Inputs • • • Agreements can take the form of: n Contracts n Service level agreements (SLAs) n Memorandums of understanding (MOUs) n Letters of intent, etc. n Statement of Work Business Case Agreements Enterprise Environmental Factors Organizational Process Assets Contracts are typically used when the project is performed for an external customer 25

Enterprise Environmental Factors (EEF) Charter Inputs n n • • • Enterprise Environmental Factors refer to conditions, not under the control of the project team, that influence, constrain, or direct the project EEFs that influence the charter might include: n Government standards or regulations n Quality standards n Organizational culture and structure n Marketplace conditions Statement of Work Business Case Agreements Enterprise Environmental Factors Organizational Process Assets 26

Organizational Process Assets (OPA) Charter Inputs n n • Statement of Work Organizational Process Assets are the • Business Case • Agreements plans, processes, policies, procedures, • Enterprise Environmental Factors • Organizational Process Assets and knowledge bases specific to, and used by, the performing organization. OPAs that can influence the charter might include: n Organizational standard processes n Organizational policies n Templates (e. g. project charter template) n Historical project information including available lessons learned knowledge bases PMP Exam Note: The PMBOK assumes every organization has this! 27

Develop Charter: Tools and Techniques n Relevant tools and techniques for the Develop Project Charter process are: q Expert judgment n n n q Other units in the organization Consultants Stakeholders Industry groups Subject matter experts (SMEs) Project management office (PMO) Facilitation techniques n n Brainstorming Conflict resolution Meeting management Escalation 28

Develop Charter: Output n n The single output of the Develop Charter process is, of course, the project charter itself The project charter is the document that: 1. 2. Formally authorizes the existence of the project and Provides the project manger with the authority to apply organizational resources to project activities PMP Exam Note: The PMBOK emphasizes these two major purposes of a Charter. 29

The Project Charter n A project charter typically contains: n n n Project purpose Measurable project objectives and related success criteria High-level requirements Known assumptions and constraints High-level risks Summary (high-level) milestone schedule Summary (high-level) budget Stakeholder list Project approval requirements (what comprises a successful project and who will sign off on a successful conclusion) Assigned project manager Project sponsor (who has authorized and will pay for the project) 30

Four Essentials of Any Project Initiation 1 Business Need 4 Agreed Upon By All Relevant Stakeholders our response to 2 Project Purpose reflecting 3 Project Objectives 31

Business Need … n n n What is the business problem to be addressed? Do the primary stakeholders agree on its statement? Why is the problem important? Can we define its scope? Can we agree on its scope? 32

Project Purpose Includes … n n What are we going to do? Who are we doing it for? (Customers) Who else will be impacted? (Stakeholders) How will we go about it at a very high level? 33

Exercise #1 You work for a website design firm and a potential client has contacted your company with the following possible project. The client, named Diane, is the co-owner and overall manager of a local book store (with coffee shop). Diane is feeling the need to offer an “online” presence in the face of the intense competition the store is getting from Barnes and Noble, Amazon, Books-a-Million, etc. Her initial thoughts are to build a website to attract new customers and keep the loyalty of her current customers. You’ve been asked to investigate (as the likely project manager) a project for creating a system that will win this client’s business. Diane and her management team have suggested the following features, but they are open to explore others: 1. Customers will be able to buy books in the store’s inventory online – for delivery via post or for store pickup. 2. Customers will be able to order books not in inventory. 3. Customers will be able to access the shop’s schedule of book signings, readings, and other promotional offers. 4. The site should push email to “registered” customers offering them incentives to visit the store (coupons, private readings, coffee shop specials, etc. ). 5. Customers can sign up online for two different levels of loyal customer memberships (depending on the amount of purchases they made during the previous year – the site should be able to look up their buying records). Cont’d 34

Exercise #1 (cont’d) Your instructor will allocate one or more teams to act as the “customer”, i. e. Diane and her team. The other teams will begin the development of the elements of a project charter in consultation with the customer team(s). Particularly, the task at hand in this exercise is to: 1) 2) 3) 4) Identify, and write a description of, the business need. Write a project purpose statement. Should a purpose statement be measurable? Explain your response. Once each development team has presented, work as a group to arrive at a consensus business need and project purpose statement. 35

Project Objectives Provide … n n ! ed v e i h c A se o p Pur Specificity for the project purpose, which by itself is very high-level Goals whose attainment will guarantee that the project purpose has been achieved 36

Objectives Should be SMART Specific n Measurable n Attainable n Realistic n Time-Limited n From James P. Lewis, Fundamentals of Project Management 37

Achieving SMART Objectives. . . When assessing whether an objective is SMART, here are some questions to ask: n Specific: q q n Measureable: q q n q Can this be done at all? If so, is it within our capabilities? Are sufficient resources available to achieve it? Realistic: q q q n How will we know when the objective has been achieved? What evidence will be needed to confirm this? How will you judge this evidence? Attainable: q n Is the objective precise and well-defined? Will its meaning be clear to anyone who reads it? Is it possible for the individuals who will work on the objective to accomplish it? How sensible is it in the current economic and technological environment? Does it fit into our overall strategy? Time-Limited: q q Can we do it within the given timeframe? Should it be done now, or should we wait? 38

Goals, Objectives and Requirements n n A project comes into existence to do something: to have the end result - effect some change. This is nearly always expressed in the language of the sponsor's business. For example, the result of a web development project might be to increase sales or to implement customer self-service. We call these Project Goals, and meeting these goals is the primary focus of the project sponsor. Project goals capture the intended fulfillment of a stated business need. The project exists to produce accomplishments that do fulfill the stated goals. These accomplishments, which should be measurable, we typically call Project Objectives. These are things that the project directly produces: an e. Commerce site; a web-enabled self-service application, etc. Accomplishing the project objectives should ensure that the project fulfills the stated goals. So what are Requirements? Requirements are the necessary specific outcomes that are required to realize the objectives - and that the project therefore must deliver. To put it another way, requirements are the detailed view of the project objectives. Because requirements are things that the project must deliver, they are the absolute definition of whether the project has achieved its objectives (and thus fulfilled its goals). Adapted from Introducing Project Requirements, by Martin Burns, www. evolt. org. 39

Exercise #2 This activity continues with the requested bookstore website project. Each team should use the consensus business need and project purpose statements the group agreed to in Exercise #1 as the starting point for this activity. Particularly, the task at hand in this activity is to: 1) 2) 3) 4) 5) Develop a set of high-level project objectives. Get customer agreement on these. Attempt to get your customers to agree on a prioritization of these objectives (use a scale from 1 to 3, with 1 = highest priority) Once each team has presented, work as a group to arrive at a consensus set of prioritized project objectives. Evaluate this consensus set of objectives to make sure that all objectives are SMART. Evaluate the level of detail carefully – remember that these objectives would be expanded later into system requirements, so the objectives can still be at a reasonably high-level. 40

MODULE 3 Completing the Project Charter 41

Constraints Factors that limit options n Fixed or limited budget n Mandatory end date n Predetermined software components or hardware n Contractual provisions A limiting factor that affects the execution of a project, program, portfolio, or process. . From PMBOK® Guide 42

Assumptions Items believed to be true, real, certain n Provide a foundation for further planning n Establish expectations n Need to be validated (or voided) as project progresses n May later be determined as false n Helps identify knowledge gaps about the project context A factor in the planning process that is considered to be true, real, or certain without proof or demonstration. From PMBOK® Guide 43

Risks n n n n Uncertain events which, if they occur, will have an impact on the project Identify potential risk events Evaluate/prioritize these risks Avoid risks if possible Balance risk avoidance to retain opportunities Manage the remaining risks Risk management continues through the entire project life cycle Risks are uncertain events or conditions that, if they occur, have an effect on one or more project objectives. From PMBOK® Guide 44

Summary Budget and Summary Schedule n Use the high-level estimate, developed as part of the business case, and SMART project objectives, developed in response to the project purpose, to establish: n An initial high-level summary budget q n This will be revised as the project requirements are better understood A summary milestone schedule q This will be refined as a Work Breakdown Structure is developed during the Scope Management process 45

Is a Change Control System Necessary? n n n Always Should be agreed on at the beginning as part of the project charter A change control system is needed from the beginning of the project because early baselines, like the summary budget and summary milestone schedule, must inevitably be changed as more knowledge about the project is gained 46

Typical Project Charter Components (recalled) n A project charter typically contains: n n n Project purpose Measurable project objectives and related success criteria High-level requirements Known assumptions and constraints High-level risks Summary (high-level) milestone schedule Summary (high-level) budget Stakeholder list Project approval requirements (what comprises a successful project and who will sign off on a successful conclusion) Assigned project manager Project sponsor (who has authorized and will pay for the project) 47

MODULE 4 Identifying Stakeholders 48

Recall Knowledge Areas and Processes used in Initiating Project Management Process Groups Knowledge Area Initiating Planning Executing Monitoring/ Closing Integration Management • Develop Project Charter • Develop Project • Direct and Management Plan Project Work Stakeholder Management • Identify Stakeholders • Plan Stakeholder Management Controlling • Monitor and Control • Close Project or Phase Project Work • Perform Integrated Change Control • Manage Stakeholder • Control Stakeholder Engagement See Chap 13 in the PMBOK® Guide) Adapted from the PMBOK® Guide 49

Identify Stakeholders Process n n n Identify Stakeholders is the process of identifying the people, groups, or organizations that could impact or be impacted by a decision, activity, or outcome of the project, and analyzing their interests in, and potential influence on, the project It is very important to identify stakeholders as early as possible in the project life cycle, so we can properly inform them about the project from the beginning and receive their input as appropriate Note that every project is likely to have stakeholders who are impacted by, or can impact the project, in both positive and negative ways 50

Examples of Project Stakeholders are individuals and organizations actively involved in the project n n n Project manager Individual responsible for managing the project Project team Individuals responsible for doing the project work Customer Individual or organization who will use the project product May be multiple layers of customers Other performing organization stakeholders Individuals, beyond the project team, within the enterprise involved in doing the work for the project Sponsor Individual or group who provides the financial resources for the project 51

Identify Stakeholders: Tools and Techniques n There are two main tools/techniques that are useful within the Identify Stakeholders process: q Stakeholder analysis q Expert judgment 52

Stakeholder Analysis n n n Involves a systematic gathering and analysis of information about stakeholders Seeks to understand the level of interest and influence various stakeholders have Objective is to determine whose interests should be taken into account throughout the project, and the relative weights that should be given to these interests to optimize the chances for project success 53

Project Stakeholder Conflict n n Stakeholders frequently have different objectives for the project and these differences often lead to conflict As a general rule, differing objectives among stakeholders should be resolved in favor of the customer, while not disregarding the needs of other stakeholders Managing stakeholder conflicting objectives and interests is a major challenge for the project manager 54

Expert Judgment n n n Judgment and expertise should be sought to ensure a comprehensive identification of project stakeholders – a missing stakeholder can have a tremendous impact on a project, especially when that stakeholder surfaces after the project is well underway Expertise and judgment can also be valuable in attempting to ascertain the level of interest, the kind of interest, and the amount of power or influence of various identified stakeholders Some typical sources of expertise: n n n Senior management Other units within the organization Previously identified key stakeholders 55

The Stakeholder Register n n The stakeholder register is a document that includes the identification, assessment, and classification of all known project stakeholders. The stakeholder register is the output of the Identify Stakeholders process 56

Exercise #3 This activity continues with the requested bookstore website project. Each team should use the consensus business need and project purpose statements as well as the prioritized project objectives the group agreed to in Exercise #1 and #2 as the starting point for this activity. Specifically, the task at hand in this activity is to: 1) 2) 3) 4) Given what we now know about the project, identify the potential impact of the project on other persons, groups, systems, etc. Using this impact analysis, identify all major stakeholders for the project. Do you anticipate issues arising from stakeholder conflict in this project? Explain. Can you think of possible additional sources of expertise in helping you identify and analyze stakeholders for this project? 57

MODULE 5 Managing Scope 58

What is Scope Management? According to the PMBOK® Guide: Project Scope Management includes the processes required to make sure that the project includes all the work required, and only the work required, to complete the project successfully. In short, managing scope means defining and controlling what is included, as well as what is not included, in the project work. 59

The Scope Management Knowledge Area The Manage Project Scope knowledge area includes six constituent processes n Plan Scope Management n Collect Requirements n Define Scope n Create WBS (Work Breakdown Structure) n Validate Scope n Control Scope These five processes are spread among two of the five Project Management Process Groups: Planning and Monitoring/Controlling (see next slide) 60

The Scope Management Knowledge Area Project Management Process Groups Knowledge Area Initiating Planning Executing Monitoring/ Closing Controlling Integration • Develop Project Management Charter • Develop Project Management Plan Scope Management • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS • Direct and Manage Project Work • Monitor and Control • Close Project or Phase Project Work • Perform Integrated Change Control • Validate Scope • Control Scope See Chap 5 in the PMBOK® Guide Stakeholder Management • Plan Stakeholder • Identify Management Stakeholders • Manage Stakeholder • Control Stakeholder Engagement Adapted from the PMBOK® Guide 61

Plan Scope Management n n Plan Scope Mgmt Collect Req’mts Define Scope Create WBS Plan Scope Management is the process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled The outputs of the Plan Scope Management process are: q q n • • Scope management plan Requirements management plan Note that in organizations (like the I/S Division) with a well-defined and repeatable product development methodology, both the scope management plan and the requirements management plan are implicit within the methodology 62

Collect Requirements n n Plan Scope Mgmt Collect Req’mts Define Scope Create WBS Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives The outputs of the Collect Requirements process are: q q n • • Requirements documentation Requirements traceability matrix Once again, in organizations which employ a welldefined and repeatable product development methodology, the processes to create requirements documentation and a requirements traceability matrix will be implicit within the methodology 63

Collect Requirements: Tools and Techniques n Interviews n n n n • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS Focus groups Facilitated workshops (like JRPs) Group creativity techniques Group decision-making techniques (Ishikawa diagrams etc) Questionnaires Prototypes Benchmarking (to identify best practices from other organizations) Context Data Flow Diagrams 64

Exercise #4 This activity continues with the requested bookstore website project. While excited about the proposed new system and its potential benefits, Diane is concerned about any negative impact the new system might have on the store’s current loyal customer base. The task at hand in this activity is to: 1) 2) In your team, try to think through some possible ways the new system might negatively impact current customer loyalty. Once you’ve identified some of these potentially negative impacts using this analysis, suggest some mitigating strategies that might be incorporated into the project to minimize some of these. 65

Context Data Flow Diagrams: Bound the Problem n n n • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS Identify in-the-large constraints Identify major data -- in and out A Context Data Flow Diagram (DFD) provides a first broad-based cut 66

A Context DFD. . . n n n Is a high-level functional model illustrating basic information flow Shows the relationships of external entities, such as processes, data items, data bases, and existing systems, to the proposed system Identifies all major input and output data flows of the proposed system, as well as the sources and destinations of these data flows At a high-level, it answers the question: “What are we trying to do? ” It lays out the broad scope and outline of the system 67

Context DFD – An Example Here’s a Context DFD for a proposed system that is to produce weekly project cost reports and data at a hypothetical company. Employee fte_employee_data FTE Employees contractor_data project_time Contractors Proposed Project Cost System Other Direct Costs project charges new_project_ data Proposed or new Existing Processes People/entities/roles Overhead_allocation_ parameters Contractor allocated_ project_ costs weekly_ project_ cost_ summary Corporate Cost-Tracking System Project Mgmt Office Legend 68

Usefulness of the Context DFD n n n Enhances communication about the proposed system Can be understood by a variety of stakeholders, including customers Allows quick explorations of ideas, concepts, and understandings Helps validate understanding with customers Easy to modify and re-validate 69

Exercise #5 This activity continues with the requested bookstore website project. Each team should use the consensus business need and project purpose statements as well as the prioritized project objectives the group agreed to in Exercise #1 and #2 as the starting point for this activity. Specifically, the task at hand in this activity is to: 1) 2) 3) 4) Given what we now know about the project, construct a Context Diagram for the project. Remember that the Context DFD is primarily an iterative communication tool, so it is perfectly alright to make some assumptions in your first version, then let the customer(s) react to and/or correct these when the diagram is presented. Does your diagram incorporate all the main stakeholders? Does it suggest any additional stakeholders? Do you see potential for such diagrams to be useful tools for communication within your projects? Explain. 70

Separating Requirements Analysis and Design n Context DFDs illustrate an important principle in system n n n development: separate the what from the how Requirements analysis focuses on answering the “what questions” It specifies what we want to accomplish The “how questions” should be left to design What? Requirements Analysis Then How? Design 71

Getting It Right Up Front • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS n Correcting errors made in software requirements, but only discovered downstream, can be very expensive – even impossible – to correct. n This relationship (cost to fix vs. time the error is discovered) is very nonlinear. “Small errors” in software requirements become major issues later. See the graph on the next slide 72

Importance of Requirements in IT Projects! Assumes error is made during requirements analysis Relative cost to correct error 100 10 rework 1 requirements design coding delivery Phase in which error is discovered 73

Project Scope Document • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS The project charter contains a high-level description of the project scope. But the project scope document will supply more detail as knowledge about the project builds. The scope document will contain the following: n n n Project scope description (progressively elaborated) Acceptance criteria Project deliverables Project exclusions Project constraints Project assumptions 74

The Work Breakdown Structure 75

The Work Breakdown Structure (WBS) … • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS 1) Ensures that the project includes all the work needed 2) Ensures that the project includes no unnecessary work 76

The Work Breakdown Structure (WBS) n n n Allows the progressive decomposition of work into simpler components, allowing us to better manage project complexity Separates the project deliverable into its constituent parts Supports planning and assignment of project responsibilities and accountabilities Helps determine resource requirements Assists in tracking status and progress 77

The Work Breakdown Structure (WBS) n n The WBS is arguably the single most important project management tool available It evolves through an iterative analysis of the project’s objectives and scope The team should participate in its development It becomes the foundation for: q q Schedule planning Estimating effort required Resource planning Assigning responsibility for accomplishing and coordinating work 78

Format of the WBS n n • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS The WBS organizes the work of the project in a hierarchical format It divides work into categories, then subdivides further as needed or desirable As you move down the WBS hierarchy the scope of the work becomes more focused Work units at the bottom of any part of the WBS are referred to as work packages 79

WBS – An Example Integrate a Third-Party Online Ordering Component with the Existing Catalog Website Hire Consultant Assess Requirements Acquire Software Recommend Solution Get Approval Create Design to Integrate Implement Design Install Software Test Design Get Training 80

The WBS as a Communication Tool • • n n Plan Scope Mgmt Collect Req’mts Define Scope Create WBS The WBS assists stakeholders in developing a clear vision of project deliverables It models the overall process by which these deliverables will be managed and produced Gives a graphical representation of project scope Establishes a basis for accountability for project work 81

The WBS as an Effort Estimation Tool n n n The WBS enables a bottom-up estimating approach Bottom-up estimating is appropriate when we have a good handle on work decomposition It works on the premise that the effort required for smaller tasks can be more accurately estimated than the effort required for larger ones 82

WBS and Effort Estimation n n We define work packages as those at the bottom of the WBS – with no subtasks of their own Estimate all the work packages first Rollup these estimates (add them) to get estimates for higher-level subtasks In this way you can derive an overall estimate, as well as estimates for subsystems at various levels 83

More on Creating the WBS. . . n n • • Plan Scope Mgmt Collect Req’mts Define Scope Create WBS In the next lecture, we will explore the creation of a WBS more thoroughly There we will see how to: q q Progressively develop the WBS and Use it as a basis for working out a schedule 84

MODULE 6 Controlling Scope 85

Change Control n n Scope change by itself is not necessarily scope creep Unmanaged scope change is scope creep Scope creep is exacerbated by allowing work on unapproved scope items Remember that change control procedures should be specified and agreed on by all stakeholders at the beginning of the project as a part of the project charter 86

Validating Scope Validate Scope is the process of formalizing acceptance of the completed project deliverables n Inputs include: q q q n Tools and Techniques include: q n Requirements documentation Verified deliverables (checked for correctness) Work performance data (degree of compliance with requirements, testing results, etc. ) Inspections, reviews, walkthroughs Outputs include: q q q Accepted deliverables Change requests for those deliverables not formally accepted Applicable project document updates 87

Controlling Scope Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline n Inputs include: q q q n Tools and Techniques include: q n Requirements documentation Verified deliverables (checked for correctness) Work performance data (degree of compliance with requirements, testing results, etc. ) Variance analysis Outputs include: q q Change requests to scope baseline, including preventive and corrective actions, defect repairs, and enhancements Work performance information 88

Scope Change Control Basics n n n n Identify requested scope change Identify source and date Identify decision makers Document reason for change Assess impact Make recommendation Record decision 89

Scope Change Control Board n n n Makes sure all groups have ownership in decisions Ensures that different aspects of a scope change are considered Records the analysis and the decision for later lessons learned 90

Final Check -- Key Learning Outcomes When you complete this course you will be able to: 1) Distinguish the project management knowledge areas from project management process groups 2) Describe what is needed to get a project started 3) Explain what SMART objectives are 4) Describe the purpose and typical content of a project charter 5) Define project stakeholders 6) Describe stakeholder analysis and its purpose 7) Describe the four essentials of project initiation 8) Explain the crucial importance of getting scope correct 9) Explain what a work breakdown structure (WBS) is 10) Describe the uses and importance of a WBS 11) Discuss how a WBS can be used for bottom-up estimating 12) Explain what change control is and why it is necessary 91