Information Technology
Project Management Providing Measurable Organizational Value 5th Edition
Marchewka Solutions Manual
Full download at link:
Test Bank: https://testbankpack.com/p/test-bank-for-information-technology-project-management-providing-measurable-organizational-value-5th-edition-marchewka-11189110169781118911013/
Soluttion Manual: https://testbankpack.com/p/solution-manual-for-information-technology-project-management-providing-measurable-organizational-value-5th-edition-marchewka1118911016-9781118911013/
Chapter 5: Project Planning: Scope and the Work Breakdown Structure
Teaching Strategies
From my experience, I have seen many projects become challenged as result of the project team not properly defining or managing the project’s scope. Being able to define exactly what needs to be done requires a clear direction. Therefore, it is important that the project stakeholders understand the project’s goal or MOV before trying to define the
work that has to be done. The students should understand that there is an important link between the project’s MOV and scope.
Scope is really the deliverables that the project team must deliver. This chapter has been updated in the new edition to include the revised scope management processes in the third edition of the PMBOK® Guide. In short, the revised scope management process includes a “create work breakdown structure” process. However, I believe it is important not to confuse scope with activities. While both may be considered “work,” it is important that the project team (and students) separate deliverables from activities or tasks. Project scope, defined in terms of tangible, verifiable products or deliverables, provides a clearer focus and direction. Moreover, it sets clearer expectations for all the stakeholders involved. Subsequently, activities or tasks are actions to create the work products. This can lead to people being busy, but accomplishing little.
The students should understand that we must put a boundary around the project’s scope much like a fence to keep certain things in and other things out. The project manager should act as a gatekeeper so that once the project scope is defined only work products that will help us achieve the MOV (without increasing schedule and budget unnecessarily) should be let in. Once again, the concept of the triple constraint should be revisited to highlight the relationships between scope, schedule, and budget. This chapter introduces several tools for defining the project’s scope. Some tools like a context DFD or use case diagram come from the MIS/Software Engineering bodies of knowledge, while the deliverable structure chart and table have been adapted or inspired by the work of Graham McLeod and Derek Smith. Once we have a clear understanding of the work products we call scope, we can use the WBS introduced in the next chapter to create work packages that include phases, deliverables, activities or tasks, and milestones. This WBS becomes the foundation for developing the detailed baseline project plan that yields the project schedule and budget.
This chapter also introduces a number of approaches and tools for estimating the project activities. Although there is no perfect estimation tool, having an understanding and clear definition of the project deliverables can provide a higher degree of confidence in our estimates. I also like to point out to the students that there are two basic approaches to project estimation. The first is the traditional project management approach (i.e., time boxing, top-down, bottom-up, and the Delphi technique), which may be better suited for estimating project-oriented scope/deliverables. However, the most difficult (and perhaps the most important) deliverable to estimate is the system solution – especially if a custom system artifact is to be designed and developed. It is important the students appreciate the fact that we will not have a clear idea of what this system will even look like until we are well into the SDLC. However, we need to know enough about the system solution at this point to develop a realistic and usable project plan. To estimate the product-oriented deliverable/scope, a software engineering approach may be more useful. The tools for
estimating the schedule and budget associated with the creation and delivery of the system may be best suited using such tools as function point analysis, COCOMO, and heuristics (with limited effectiveness using the traditional counting of lines of code).
In my classes, I don’t expect my students to be effective function point counters. If you do, then there’s an appendix that provides more detail in counting function points. However, I do expect that they understand and hope that they gain an appreciation for the function point and COCOMO approaches. While these approaches may not provide the perfect estimation tool, they are better than trying to estimate how many lines of code will be required for software programs that are yet to be written. Like most things in life, we tend to get better at them through repetition and experience. I have used the Husky Air cases extensively in my classes and like to compare how teams working on the same case can come up with a wide range of schedule and budget estimates.
Teaching Chapter 5 in a Nutshell
➢ This chapter introduces the six PMBOK® scope management processes called scope planning, requirements collection, scope definition, create-work breakdown structure, scope validation, and scope control. The work breakdown structure process is used to create the project schedule in the next chapter.
➢ Scope can be classified or viewed as being product or project scope. Project scope centers on the deliverables defined in the ITPM. This includes the business case, project charter, baseline plan, etc. On the other hand, product scope focuses on the product of the project – in other words, the information system solution. Product scope concerns the features, functionality, or requirements of the system.
➢ Several tools for defining the project’s scope are introduced. These tools include the use case diagram and the deliverable structure chart.
➢ Once the project’s scope is defined, it must be verified and controlled against scope leap and creep. Scope grope is a situation that may arise if the scope was never defined properly in the first place. Subsequently, the project team may try to grope their way in terms of finding a direction.
➢ The WBS is an important and widely used tool for planning projects. Unfortunately, there is no general standard or accepted WBS style or approach. Since the WBS must be tied to the project’s scope (and in turn to the project’s MOV), the WBS should follow a work package approach that breaks up the project into phases, with each phase tied to one or more deliverables. Moreover, each deliverable should include specific tasks (or activities) that represent actions needed to complete the deliverable. Examples of the work package concept can be found in the Husky Air case examples that are part of the instructor’s materials.
➢ Deliverables and milestones are tightly linked. Deliverables are the specific work products defined in the project’s scope. Milestones represent quality checks to show that deliverables and phases have not only been completed, but completed according to predefined standards. Milestones also play other important roles such as cruxes or proof of concepts, and tend to keep the project team focused because a project team that hits its milestones should be on track.
➢ As mentioned above, the traditional project management approaches to estimation are useful for estimating many of the project-oriented deliverables, while the software engineering approaches may be better for estimating the product-oriented deliverables. No one approach is best, so using more than one approach may help triangulate the estimates for the project activities. On the other hand, estimating with little experience is similar to shooting in the dark – one may hit the target, but it may be a matter of luck instead of skill. Experience and repetition are keys to better estimation and confidence in those estimates.
Review Questions
1. What is the triple constraint?
The Triple Constraint describes the relationship among scope, schedule, and budget.
2. Describe the relationship among scope, schedule, and budget.
The project is balanced or “in harmony” when the schedule and budget support the project’s scope in order to achieve the MOV. The project becomes imbalanced when scope increases without adjusting schedule and budget accordingly.
3. What is meant by project scope?
The term scope is used to define the work boundaries and deliverables of the project so what needs to get done, gets done and only what needs to get done, gets done.
4. Briefly describe the six scope management processes.
• Scope planning: The development of a scope management plan that defines the project’s scope and how it will be verified and controlled throughout the project.
• Collect Requirements: engaging customers or users in order to define their needs
• Scope definition: A detailed scope statement that defines what work will and will not be part of the project and will serve as a basis for all future project decisions.
• Create work breakdown structure: The decomposition or dividing of the major project deliverables into smaller and more manageable components.
• Scope verification: Confirmation and formal acceptance that the project’s scope is accurate, complete, and supports the project’s MOV.
• Scope change control: Ensures that controls are in place to managed proposed scope changes once the project’s scope is set. These procedures must be communicated and understood by all project stakeholders.
5. Briefly describe the plan scope management process.
Scope planning is a process for defining and documenting the project work. More specifically, a project’s scope defines all the work, activities, and deliverables that the project team must provide in order for the project to achieve its MOV. It is an important step in
developing the project plan since one must know what work must be done before an estimate can be made on how long it will take and how much it will cost.
6. Briefly describe the collect requirements process.
Collecting requirements focuses on engaging customers or users in order to define their needs. In essence, this entails planning how the project team will work with the customer, client, or users to define the scope of the project. Some common methods include:
▪ Interviews
▪ Workshops
▪ Brainstorming sessions
▪ Focus groups
▪ Surveys
▪ Observing people while they work
7. Briefly describe the define scope process.
Developing a scope statement is a useful first step for defining the scope of the project and setting a boundary. A project’s scope, however, should also be defined in terms of the deliverables that the team must provide. These deliverables can be divided into project-oriented deliverables and product-oriented deliverables. This separation gives the team a clearer definition of the work to be accomplished and improves the likelihood of accurately assigning resources and estimating the time and cost of completing the work. Moreover, a clear definition of the project’s deliverables sets unambiguous expectations and agreement among all of the project stakeholders.
8. Briefly describe the purpose of a work breakdown structure (WBS).
How the work or scope is to be accomplished entails the use of a project management tool called the work breakdown structure (WBS) . It provides a hierarchical structure that acts as a bridge, or link, between the project’s scope and the detailed project plan that will be created using a project management software package.
9. Briefly describe the validate scope process.
Project scope validation is the scope management process that provides a mechanism for ensuring that the project deliverables are completed according to the standards described in the DDT. Gray and Larson (2000) provide a project scope checklist for ensuring that the deliverables are completed and completed correctly. The checklist items include: MOV, Deliverables, Quality standards, Milestones, Review and acceptance.
10. Briefly describe the control scope process.
Scope change control is concerned with ensuring that any changes to the project scope will be beneficial, with determining that an actual scope change has occurred, and with managing the actual changes when and as they occur. Scope control is also concerned with: Scope grope, Scope creep, and Scope leap.
11. Why is it important to define the project’s scope accurately and completely?
The procedures for defining and managing the scope of a project must be communicated and understood by all of the project’s stakeholders to minimize the likelihood of misunderstandings. Moreover, the project’s scope must align and support the project’s MOV. Why spend time and resources to perform work that will not add any value to the organization or help the project achieve its MOV? Again, work that does not add value consumes valuable time and resources needlessly.
12. What is a scope boundary? What purpose does it serve?
Defining the scope boundary is the first step to establishing what is, and what is not, part of the project work to be completed by the project team. Think of the scope boundary as a fence designed to keep certain things in and other things out. The scope boundary must protect the scope from activities that will not help the project achieve its MOV.
13. What is the difference between product-oriented deliverables and project-oriented deliverables?
Product scope therefore focuses on identifying the features and functionality of the information system to be implemented.
The role of project-oriented deliverables is to ensure that the project processes are being competed so that the project’s product (i.e., the information system) achieves the project’s MOV and objectives. Project-oriented deliverables also provide tangible evidence of the project’s progress (or lack of progress). Finally, they allow the project manager to set a baseline for performance and quality control because they usually require some form of approval before work on the next project phase or deliverable begins.
14. How does a project’s scope support the MOV concept?
The project’s scope defines and limits the project’s activities to only those things that support the project MOV. It makes sure that time and resources are only expended on things that contribute to the project MOV.
15. What is a statement of work? What purpose does it serve?
A statement of work (SOW) is a narrative description of the product, service, or information system. Its purpose is based upon whether the project is internal or external to the organization. For internal projects, the SOW should tie together the business need with the specific requirements or expectation of the project. For external projects, an organization would create a SOW that includes specifications, quantities, quality standards, or performance requirements for inclusion in a document that may be called a request for proposal (RFP), request for information (RFI), or request for bid (RFB).
16. What is a scope statement? What purpose does it serve?
A scope statement documents the project sponsor’s needs and expectations. It serves to clarify what work is within the scope boundary as well as what work is outside of the scope boundary and therefore not to be included.
17. How does a use case diagram help to define the project’s scope?
The use case diagram provides a simple yet effective overview of the functions and interactions between the use cases and the actors. The box separating the use cases from the actors also provides a system boundary that defines the scope boundary. Use cases inside the boundary are considered within the scope of the project, while anything outside of the boundary is considered outside the scope of the project.
18. What is a deliverable structure chart (DSC)? What is its purpose?
A useful tool to define the project-oriented deliverables is to create a deliverable structure chart (DSC). A DSC maps all of the project deliverables of the project life cycle (PLC) and systems development life cycle (SDLC) phases. The purpose of the DSC is to define all of the project-oriented deliverables to be provided by the project team. Each deliverable should have a clear purpose and each phase should produce at least one deliverable.
19. What is a work breakdown structure (WBS)? How does it map to the deliverable structure chart (DSC)?
The work breakdown structure (WBS) is a useful tool for developing the project plan and links the project’s scope to the schedule and budget. The WBS provides a framework for developing a tactical plan to structure the project work. The WBS provides an outline for all of the work the project team will perform. With the WBS, the project is decomposed into phases, with each phase having one or more deliverable as defined in the deliverable structure chart (DSC).
20. What is the purpose of validating and verifying a project’s scope?
The project scope must be verified to ensure that the deliverables are completed and completed correctly.
21. What is the purpose of scope change control procedures?
The purpose of scope change control procedures is to ensure that any changes to the project scope will be beneficial, to determine that an actual scope change has occurred, and to manage the actual changes when and as they occur.
22. Briefly describe scope grope.
Scope grope is a metaphor that describes a project team’s inability to define the project’s scope. This situation is common early in a project when the project team and sponsor have trouble understanding what the project is supposed to accomplish.
23. Briefly describe scope creep.
Scope creep refers to increasing featurism, adding small yet time- and resource-consuming features to the system once the scope of the project has been approved.
24. Briefly describe scope leap.
Scope leap is a fundamental and significant change in the project scope.
25. What are the benefits of having scope control procedures?
The most important benefit of scope change control procedures is that they keep the project manager in control of the project. More specifically, they allow the project manager to manage and control the project’s schedule and budget. Scope control procedures also allow the project team to stay focused and on track in terms of meeting its milestones because it does not have to perform unnecessary work.
26. Briefly describe what should be included on a scope change request form.
First, the description of the change request should be clearly defined so that the project manager and project team understand fully the nature and reason for the scope change.
Second, the scope change should be justified, which separates the would likes from the must haves.
Third, several alternatives may be listed.
Fourth, an assessment of the impact on scope, schedule, resources, and cost.
Fifth, an approval of those scope changes to be implemented.
27. What is the purpose of a scope change request log?
To prevent requests from falling through the cracks, leading to credibility concerns and accusations that the project manager or project team is not being responsive to the client’s needs.
28. Discuss why a project’s scope must be tied to the WBS.
The WBS Should Support the Project’s MOV The WBS should include only tasks or activities that allow for the delivery of the project’s deliverables. Before continuing with the development of the project plan, the project team should ensure that the WBS allows for the delivery of all the project’s deliverables as defined in the project’s scope. In turn, this will ensure that the project is more likely to achieve its MOV.
29. What is a work package?
Work packages provide a logical basis for defining the project activities and assigning resources to those activities so that all of the project work is identified.
30. What is the difference between a deliverable and a milestone? Give an example of each.
Deliverables and milestones are closely related, but they are not the same thing. Recall that deliverables can include such things as presentations or reports, plans, prototypes, and the final application system. A milestone, on the other hand, must focus on an achievement.
For example, a deliverable may be a prototype of the user interface, but the milestone would be a stakeholder’s formal acceptance of the user interface. Only the formal acceptance or approval of the user interface by the project sponsor would allow the project team to move on to the next phase of the project.
31. What purpose do milestones serve?
A milestone is a significant event or achievement that provides evidence that the deliverable has been completed or that a phase is formally over.
32. What are some advantages of including milestones in the WBS?
• If a project team succeeds in meeting all of its scheduled milestones, then the project should finish as planned.
• Milestones can keep the project team focused.
• Milestones reduce the risk associated with a project.
• Milestones can be used to reduce risk by acting as cruxes or proof of concepts.
• Milestones can provide a mechanism for quality control.
33. What is a crux? Why should the project manager and project team identify the cruxes of a project?
Milestones can also be used to reduce risk by acting as cruxes or proof of concepts. A crux can be the testing of an idea, concept, or technology that is critical to the project’s success.
34. What is the proper level of detail for a WBS?
The level of detail should support planning and control. The WBS provides a bridge between the project’s scope and project plan that is, the schedule and budget. Therefore, the level of detail should support not only the development of the project plan but also allow the project manager and project team to monitor and compare the project’s actual progress to the original plan’s schedule and budget.
35. Why should the WBS be deliverable oriented?
The focus of a project should be to produce something, not merely on completing a specified number of activities.
36. Explain why people who do the work on a project should be involved in developing the project plan.
One way to ensure that the WBS has the appropriate level of detail is to ensure that the people who do the work are involved in its development. A person who has experience and expertise in a particular area probably has a better feel for what activities need to be performed in order to produce a particular project deliverable. Although the project manager is responsible for ensuring that a realistic WBS is developed, the people who must carry out the activities and tasks may be more committed to the plan if they are involved in its development.
37. How does the concept of knowledge management support the development of the project plan?
The skills to develop a useful WBS generally evolve over time with practice and experience. Knowledge management provides a means for capturing, managing and using knowledge and experience captured over time.
38. What is guesstimating? Why should a project manager not rely on this technique for estimating a project?
Estimation by guessing or just picking numbers out of the air is not the best way to derive a project’s schedule and budget. Unfortunately, many inexperienced project managers
tend to guesstimate , or guess at the estimates, because it is quick and easy. The problem is that guessing at the estimates is based on feelings rather than on hard evidence.
39. Describe the potential problems associated with providing an off-the-record estimate?
As T. Capers Jones points out:
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, and carelessness of the project management function are the factors that tend to introduce terminal problems. Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably.
40. What is the Delphi technique? When would it be an appropriate estimating technique for a project?
The Delphi technique involves multiple experts who arrive at a consensus on a particular subject or issue. Although the Delphi technique is generally used for group decision making, it can be a useful tool for estimating when time and money warrant the extra effort. To estimate using the Delphi technique, several experts need to be recruited to estimate the same item. Based on information supplied, each expert makes an estimate and then all the results are compared. If the estimates are reasonably close, they can be averaged and used as an estimate. Otherwise, the estimates are distributed back to the experts, who discuss the differences and then make another estimate. In general, these rounds are anonymous and several rounds may take place until a consensus is reached. Not surprisingly, using the Delphi technique can take longer and cost more than most estimation methods, but it can be very effective and provide reasonable assurance when the stakes are high and the margin for error is low.
41. What is time boxing? What are some advantages of using time boxing?
Time boxing is often used on Agile projects whereby a box of time is allocated for a sprint; however, this technique can also be used for a specific activity or task or for any component of the WBS. This allocation is based more on a requirement than just on guesswork. For example, a project team may have two (and only two) weeks to build a prototype during a sprint. At the end of the two weeks, work on the prototype stops, regardless of whether the prototype is 100 percent complete. Used effectively, time boxing can help focus the project team’s effort on an important and critical task.
42. Describe top-down estimating. What are some advantages and disadvantages of topdown estimating?
Top-down estimating involves estimating the schedule and/or cost of the entire project in terms of how long it should take or how much it should cost. Top-down estimating is a
very common occurrence that often results from a mandate made by upper management. Often the schedule and/or cost estimate is a product of some strategic plan or because someone thinks it should take a certain amount of time or cost a particular amount. On the other hand, top-down estimating could be a reaction to the business environment. It is important to keep in mind that top-down estimating works well when the target objectives are reasonable, realistic, and achievable.
43. Describe bottom-up estimating. What are some advantages and disadvantages of bottom-up estimating?
Bottom-up estimating involves dividing the project into smaller modules and then directly estimating the time and effort in terms of person-hours, person-weeks, or personmonths for each module. The work breakdown structure provides the basis for bottom-up estimating because all of the project phases and activities are defined. The project manager, or better yet the project team, can provide reasonable time estimates for each activity. In short, bottom-up estimating starts with a list of all required tasks or activities and then an estimate for the amount of effort is made. The total time and associated cost for each activity provides the basis for the project’s target schedule and budget.
44. Describe poker planning. What are some advantages of poker planning?
Poker planning is a variation of the Delphi technique that begins with a deck of cards that represent an estimate in days. One popular sequence is 0, 1/ 2, 1, 2, 3, 5, 8, 13, 20, 40, 100, while another is based on the Fibonacci numbers that create the sequence 1, 2, 3, 5, 8, 13, 21, 34, 55, . . . The Fibonacci set is created where each subsequent number is the sum of the previous two. Regardless, the idea is to create a set of possible estimates that have some distance between them. Often a deck will include an “unsure” card or an “I need a break” card. Teams can make up their own sets of cards or purchase them commercially.
Playing poker planning is straightforward and includes a moderator and the team of developers. The idea is to have the people who will be actually doing the work participate. The moderator can be the project manager, product owner, or an analyst, but the moderator’s main role is to describe a particular task, feature, deliverable, or user story to be estimated. The moderator or product owner can answer any questions that the estimators may have.
Many people believe it works because:
▪ It brings the people who will be doing the work together to do the estimates.
▪ People who are asked to justify their estimates may be forced to think more critically about the task at hand.
▪ Group discussions may help foster collaboration by engaging the entire team rather than relying on the estimates of a single person.
▪ While poker planning takes advantage of knowledge of the more experienced members of the team, the technique empowers everyone and ensures full team participation.
▪ Poker planning can make estimating more interesting while keeping the planning meeting focused and people motivated.
▪ The team can compare its estimates to its actual progress to see how accurate they were.
45. What is a “death march” project? What situations in project planning can lead to a “death march” project?
Ed Yourdon calls a death march project: I define a death march project as one whose “project parameters” exceed the norm by at least 50 percent. This doesn’t correspond to the “military” definition, and it would be a travesty to compare even the worst software project with the Bataan death march during the Second World War, or the “trail of tears” death march imposed upon Native Americans in the late 1700s. Instead, I use the term as a metaphor, to suggest a “forced march” imposed upon relatively innocent victims, the outcome of which is usually a high casualty rate.
A “death march” project means one or more of the following constraints has been imposed :
▪ The project schedule has been compressed to less than 50 percent of its original estimate.
▪ The staff originally assigned or required to complete the project has been reduced to less than 50 percent.
▪ The budget and resources needed have been reduced by 50 percent or more.
▪ The functionality, features, or other performance or technical requirements are twice what they should be under typical circumstances.