CH 5

1. CH 5 Project Scope and Human Resources Planning

2. Objectives • Acquire a general understanding of the parts of the project management plan • Understand the importance of discovering and documenting stakeholder requirements • Understand how to create a detailed scope statement and WBS • Learn how to match the right person, with the needed skill set, to the appropriate activity • Understand the importance of both formal and informal organizational charts • Understand past and current research associated with effective human resources management

4. Integration Management KA Project planning starts with the project plan development process, which is part of theIntegration Management knowledge Area (see the opening chapter map figure). The singledeliverable from this process is the project management plan, which consists of deliverablesfrom each of the other eight knowledge areas.

5. Integration Management KA Remember from Chapter 3 that theIntegration Management knowledge area describes the processes and methods required toidentify, define, combine, unify, and coordinate the various processes with all of the othereight knowledge areas (from the project management body of knowledge [PMBOK])

6. Integration Management KA • Develop the Project Management Plan Process: taking the artifacts created in each of the other eight Knowledge areas and putting them into a consistent, coherent document—the project plan • Telling the team “What” to do • The text will spend several chapters describing the elements of the project plan!

7. Project Plan Theproject plan consists of the following topics:

8. Build the Project Plan • Scope management plan (Chapter 5) • Work breakdown structure (WBS) (Chapter 5) • WBS dictionary (Chapter 5) • Staffing management plan (Chapter 5) • Schedule management plan (Chapter 6) • Cost management plan (Chapter 6) • Quality management plan (Chapter 7) • Process improvement plan (Chapter 7) • Communication management plan (Chapter 7) • Risk management plan (Chapter 8) • Procurement management plan (Chapter 9)

9. Build the Project Plan Organizations that are successful atproject management have examples and templates already set up for each deliverable. A project manager should be able to start with the default cost management plan or aplan from a prior project and just customize it for the current project. Organizationsand project managers who use standard processes and templates have a significant advantage(in terms of cost, time, and accuracy) over those who create a new plan for eachand every project.

10. Build the Project Plan Many organizations not only havedocumented templates for each part of the planbut also may have slightly different standard formats, based on different project characteristics,such as size, complexity, length, and risk level.

11. Build the Project Plan Project teams make their most expensive (in terms of both time and money) mistakesduring the planning phase of a project. A project team may do little or no planning, or itmay plan incorrectly. By definition, a project is unique and has never been done before, soplanning is crucial

12. Project Plan Development • A project plan is a document used to coordinate all project planning documents • Its main purpose is to guide project execution • Project plans assist the project manager in leading the project team and assessing project status • Project performance should be measured against a baseline project plan • Building the plan should notbe done in secret or in isolation; the whole project team needs to participate

13. Attributes of Project Plans Just as projects are unique, so are project plans • Plans should be dynamic • Plans should be flexible • Plans should be updated as changes occur (Integrated Change Control) • Plans should first and foremost guide project execution • Plans should never assume the team will work overtime, at least not at the start

14. Project Plan Creation • Most expensive project mistakes are made during planning. McConnell (1998) states that errors found “upstream” during the planning phase cost on the order of 200 times less to fix than errors found “downstream” during the building of the product • Planning “forecasting” “seeing into the future” is not an easy task

15. Project Plan Creation • T. Capers Jones (1998) summed it up this way: “The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling, irrational commitments, unprofessional estimating techniques, carelessness of the project management function are the factors that tend to introduce terminal problems.” • Planning isn’t done just once but is a continuous process of adaptation and change

16. Project Plan Creation • Although planning is crucial, project teams must be careful to avoid over-planning • the planning must be appropriate to the size, complexity, and risk of the project • Project managers must be careful to avoid what many systems analysis text books refer to as “analysis paralysis”—getting stuck in the analysis phase, trying to get everything defined perfectly

17. SCOPE MANAGEMENT PLANNING Project planning starts with the project plan development process, which is part of theIntegration Management knowledge area (see the opening chapter map figure). By building on the objectives listed inthe project charter, you can build a morecomplete scope statement.

18. SCOPE MANAGEMENT PLANNING A project's scope comes from many sources. In addition to stakeholders and theother members of the team contributing ideas, other sources of scope may be existing industrystandards, organizational culture, or government regulations

19. SCOPE MANAGEMENT PLANNING Scope creep happens for many reasons; for example: the marketing departmentmay want to get ahead of the competition, the softwaredevelopers might want to learnabout the latest new tool or technique, or the key stakeholder may have recently read anarticle about the next great feature and want it added to the application. If scope is definedcorrectly and the team follows a disciplined change control process, scope creep can beminimized or avoided

20. What Is Project Scope Management? • Scope - refers to all (100%) the work involved in creating the products of the project and the processes used to create them • A Deliverable - is a product produced as part of a project, such as hardware or software, planning documents, or meeting minutes • Project scope management includes the processes involved in defining and controlling what is or is not included in a project

21. 3 key Deliverables • Scope statement • Scope management plan • Work breakdown structure (WBS)

22. Scope Planning • The scope management plan describes how the project team will define the scope, develop the detailed scope statement, define and develop the work breakdown structure (WBS), verify the scope, and control the scope • A scope statement describes the characteristics of the product that the project was created to deliver. It should include the following information: • a project justification • a brief description of the project’s products • a summary of all project deliverables • a statement of what determines project success – user acceptance criteria

23. Scope Statement • Size and depth depends on: • Project size • Degree of risk • Cash requirements • Technology utilized • Nature of the deliverables • Strategic importance of the project • Project definition

24. Scope Planning • Good Scope planning is one of the best ways to limit scope creep • Scope Creep is the unanticipated gradual growth of systems requirements during the life of the project causing budget and time overruns

25. Scope Definition • Is accomplished by conducting a requirements discovery and analysis exercise, the use of subject matter experts, and a stakeholder analysis • Requirements Discovery • Interviews • History documents • Research • PIECES (Performance, Information, Economics, Control, Efficiency, Service) • Other means

26. Collecting Requirements Scope definition is accomplished by conducting a requirements discovery and analysis exercise,getting help from subject matter experts (SMEs), and using the results of the stakeholderanalysis.

27. Collecting Requirements The requirements discovery and analysis is donenot by the project manager but by skilled systems analysts, who have many tools to aidthem in their job. But one technique that bears mentioning is called PIECES (Wetherbe, 1994), whichdescribes different categories of potential requirements:

28. Collecting Requirements • Performance-Fixing or improving performance, work throughput issues, transactions,or request response times • Information-Fixing or improving all forms of information, including stored dataelements, input processes and data, output processes, format, timing, and content • Economics-Fixing or improving a company's economic situation, with expensesand revenue, new markets, new products, faster product releases, and so on • Control and security-Fixingor improving control and security of all company electronicassets

29. Collecting Requirements • Efficiency-Fixing or improving resource (people, machines, computers, networks)productivity and efficiency • Service-Fixing or improving service usability, accuracy, reliability, adaptability, andcompatibility The list is not exhaustive but offers a framework to aid the analyst in capturing requirements

30. Requirements Documentation The requirements should be documented using a requirements management system,preferably an electronic system to aid the team in improving communication, traceability,and visibility. The requirements documentation may consist of the following:

31. Requirements Documentation • Functional and nonfunctional system requirements • Business rules • Impacts on any other systems and/or departments • Support and training requirements • Specific acceptance criteria for each requirement or set of requirements • Quality requirements

32. Requirements Management • Who has authority to update the list of requirements? • What process will be used to manage the changes to the requirements? • How are requirements prioritized? In other words, which ones are done first or are done at all? • How are requirements traced from discovery to system design to prototype to finished product?

33. Work Breakdown Structure (WBS) When the product and project requirements have been discovered and documented andthe scope statement has been created, the next step is to begin building the work breakdownstructure (WBS), which organizes the total scope of the project.

34. Work Breakdown Structure (WBS) The WBS is used for many different purposes throughout the project, so it is extremelyimportant to get it as accurate as possible. The following is a list of uses for the WBS:

35. Work Breakdown Structure (WBS) • After completing scope planning, the next step is to further define the work by breaking it into manageable pieces “Systems Analysis” • Good scope definition: • helps improve the accuracy of time, cost, and resource estimates • defines a baseline for performance measurement and project control • aids in communicating clear work responsibilities

36. WBS • A WBS is an outcome oriented list of tasks executed by the project team to accomplish stated project objectives • It is a foundation document that provides the basis for planning and managing project schedules, costs, and changes

37. WBS The WBS is used for many different purposes throughout the project, so it is extremelyimportant to get it as accurate as possible. The following is a list of uses for the WBS:

38. WBS Uses Throughout the Project • Guide the work of the entire project team • Facilitate communication • Aid the team in building the schedule and budget • Assigning the right person to the right task • Getting the project to a done state • Aid in quality control • Accountability • Reduce scope creep • Aid in budget and schedule progress reporting and performance reporting • Aid in examining alternative steps in building a product

39. WBS Uses Throughout the Project Many people believe that building an accurate WBS that meetsthe 100 percent rule is more of an art than a science, and it takes years of experience tobecome proficient at it.

40. Building the WBS • Using guidelines: Some organizations, like the DOD, provide guidelines/requirements for preparing a WBS • The analogy approach: A WBS is first created by looking for a similar project done in the past and using its WBS as a starting point • The top-down approach: Start with the largest items of the project and keep breaking them down into smaller and smaller parts • The bottoms-up approach: Start with the detailed tasks and roll them up • Thread – concentrate on most important items first

41. Analogy Technique A WBS is first created by looking for a similar project done inthe past and using its WBS as a starting point. The team simply copies the WBS from theprevious similar project and changes the name. The team must then begin reviewing theWBS to make any necessary changes for the new project.

42. Analogy Technique IT projects fall into three broad categories: new functionality; maintenance; or conversion of an existing system to a newplatform, a new vendor, or a new user interface. Identifying an IT project as one of thesethree categories can help you find similar projects to use in building a WBS.

43. Analogy Technique Advantages • Is the fastest path to a completed WBS • Is a valuable tool for brainstorming a new project and looking for deliverables • Enhances cross-project consistency • Improves budget and time estimates • Improves resource allocations

44. Analogy Technique The following issues are associated with using the analogy technique: The team needs to ensure that the previous WBS is completely understood and similar. The team needs to make sure the previous WBS is accurate and updated. The team needs to critically review the previous WBS and its appropriateness for thenew project

45. Analogy Technique Issues • Ensure that the previous WBS is completely understood and similar • Ensure the previous WBS is accurate and updated • Critically review the previous WBS and its appropriateness for the new project

46. Top Down Technique THE TOP-DOWN TECHNIQUE If a similar project's WBS doesn't exist, you must start fromscratch. You can use the top-down approach during a brainstorming session, with SMEs,stakeholders, and team members. The team first looks at the list of objectives from the projectcharter and uses them to determine a high-level list of deliverables that will be used to buildthe final product.

47. Top Down Technique Each deliverable is then decomposed into smaller and smaller steps neededto create that deliverable. This process continues until all objectives have been decomposedsufficiently (see Chapter 6 for more definition on the level of decomposition necessary).

48. Top-Down Approach Advantages • Ensures projects are organized logically based on the nature of the project • Promotes stakeholder participation in the planning phase of the project • Can create a greater understanding of the entire project by all participants

49. Top-Down Approach Issues • Need to make sure major objectives are not forgotten • Make sure to decompose the tasks to appropriate levels • Can be time consuming, must guard against “analysis paralysis” • Cost and time estimates are more difficult to create and generally less accurate than under the analogy approach

50. Bottom up approach If a similar project's WBS doesn't exist but the team is veryfamiliar with this type of project, you can use start from scratch with the bottom-up technique. Like the top-down approach, this approach is also generally done during a brainstormingsession, with SMEs, stakeholders, and team members. The team first looks at thelist of objectives from the project charter and generates a list of low-level activities that willbe needed to complete the objectives.