Project Management Tools and Techniques

A Practical Guide, Second Edition

Deborah Sater Carstens, Gary L. Richardson

• Publisher: CRC Press
• Year: 2019
• ISBN:
  9780429558214
• Edition: 2
• Topic: Business
• Subtopic: Project Management
• Index: Business

The topic of project management is truly an evolution of art seeking science. This activity involves balancing project objectives against the constraints of time, budget, and quality. Achieving this balance requires skill, experience, along with the use of many tools, and techniques which are the focus of this book.

This new edition provides updated content to incorporate examples from Microsoft Project 2016 and material from the Project Management Body of Knowledge (PMBOK® Guide), sixth edition. The chapter structure includes step-by-step instructions regarding the basic mechanics and various software tools that can be used to assist in the processes. To reinforce the textbook's learning objectives, extra material is provided on the textbook website. This includes mechanical tool examples and lab assignments representative of the chapter topics. An external video tutorial library is available to help with various mechanics related to Microsoft Project mechanics. An instructor manual is available for qualifying adoptions for classroom use.

NOTE: Chapter 26 is not in the textbook and is only located in the book's Downloads tab on the CRCPress.com website.

Features

• 
  
  

• Illustrates the use of Microsoft Project throughout the project life cycle

• 
  
  

• Offers templates as productivity enhancement tools

• 
  
  

• Includes supplemental material for students and instructors

• 
  
  

• Provides assignments for hands-on experience

• 
  
  

• Follows the PMI PMBOK ® Guide model structure that will support a better understanding of the model and help prepare students for PMP and CAPM certification

• 
  
  

• Illustrates both traditional and contemporary management techniques

Section II

Planning Processes

6 Developing the Project Scope

Chapter Objectives

1. Understand the basic process of translating initial requirements into required work units

2. Understand key elements that need to be defined for adequate scope definition

3. Understand the concept of design “ibilities”

Chapter 5 discussed how every organization has a slightly different method for identifying and approaching the official launch of a project. However, one of the core requirements is to identify the PM and key stakeholders as they collectively form the nucleus for elaborating what is to be accomplished. The basic roles for a project charter were also discussed and this provides necessary start-up delegation of authority and formal management approval for the project to commence. The aim of this chapter is to address the next step in the launch process, which is to develop the scope planning, which yields a scope management plan and the scope definition, resulting in an updated scope management plan, scope statement, and requested changes to the project scope (PMI 2017). Before reading this chapter, it is important to first understand the definition of a scope management plan and scope statement. PMI (2017) describes a scope management plan as explaining how the project scope will be defined, developed and verified. It will also describe how the Work Breakdown Structure (WBS) will be created and defined. Therefore, the scope management plan provides guidance on how the project scope will be managed and controlled by the PM and the team. It is contained within or is a subsidiary of the project management plan, while a project scope statement contains a description of the project scope which consists of information, such as the deliverables, assumptions, constraints, and a description of the work that is to be accomplished by the project. The scope statement for the project is documented so it will be the basis for making future project decisions and to confirm or develop a common understanding of project scope among the stakeholders.

The creation of the scope management plan and the scope statement establishes the foundation for WBS development. Successful projects are just as much about managing relationships as they are about managing change, so the PM must be vigilant in controlling the project outcome (Bourne and Walker 2005). There is a management concept that says you cannot control what has not been defined, and scope definition is the important beginning step for project definition. Our primary goal now is to begin our journey through planning and defining the project scope.

Scope Planning and Definition

As discussed previously, the scope planning process yields a scope management plan, and the scope definition results in an updated scope management plan, the scope statement, and requested changes to the project scope (PMI 2017). The input into scope planning is organizational factors such as the organizational culture, the project charter, the preliminary scope statement, the project management plan, and organizational process assets defined by PMI (2017) as information, policies or procedures external to a project. The process in scope planning used by organizations to produce the output, the scope management plan, is templates and expert judgment. The scope definition input is similar to the scope planning input as it also has organizational process assets, the project charter, the preliminary scope statement, but also the project scope management plan and approved project scope change requests. The process used to produce the outputs of the project scope statement requested changes and updated scope management plan consists of the methods and techniques used to translate project objectives into project deliverables, expert judgment, and management of stakeholder’s needs, wants, and expectations.

A scope statement typically is a text document used to develop and confirm a common understanding of the project scope. It should include project justification, a brief description of the project’s deliverables, and a summary of all project deliverables and a statement of what determines project success. The scope statement is the first translation of the vague charter language into more specific technical language. Just as every organization may have a slightly different way of approaching the official launch of a project, an organization also has different approaches to scope planning and definition. However, the proper outcome is a scope statement used to drive the subsequent scope planning and the scope management plan for scope definition. The difference is that the scope management plan is procedural input into the development of the very detailed scope statement. The scope management plan will either already contain the level of detail that is found in a scope statement or will be broader, leaving the details to be found in the scope statement. Therefore, the discussion of this chapter revolves around the development of the detailed scope statement since this will discuss all of the necessary scope input needed before Chapter 7 that focuses on the development of the WBS.

Identification of the team members is an important part of the launch process as the team will then assist the PM in the creation of the scope statement as teamwork is a vital ingredient in the success for the project team (Kimberly-Clark 2002; Swan and Khalfan 2007; Little 2011). Assembling the project team requires the right mix of individuals and the composition of skills that will successfully accomplish the project goals (Maddalena 2012).

Unclear objectives, unrealistic deadlines, and unclear management roles and lines of authority are weaknesses in project management (Kimberly-Clark 2002). As discussed in Chapter 5, if any part of the project is being outsourced, the role of the outsourced tasks must be carefully and clearly defined. A clearly defined line of authority to include an accountability framework must be established (Maddalena 2012). Clearly defined goals are the first step before assigning individuals to different tasks that lead to each of the defined goals.

Requirements “Ibilities”

This section is adapted from Richardson and Jackson (2019). On the surface, the requirements definition concept seems pretty simple—that is, to identify what the customer wants and then engineer the technical details necessary to construct it. The general scope discussion to this point has had that flavor. However, there are a set of not so obvious issues that often fall into the crack of the requirements definition. We call these the basic nine “ibilities”:

1. Traceability

2. Affordability

3. Feasibility

4. Usability

5. Producibility

6. Maintainability

7. Simplicity

8. Operability

9. Sustainability.

Each “ibility” represents a work unit attribute to be considered in the requirements definition. We must recognize that the project goal is not just trying to produce a stated deliverable. It must also consider a broader technical look at the attributes of the result. To do this, it is necessary to review the approach taken and adjust the scope statement according to each of the nine “ibility” attributes to ensure that the approach chosen appropriately matches the real requirement. In many cases, a particular solution will involve a trade-off of one or more of these attributes, based on time, quality, functionality, or cost constraints. These decision alternatives will present themselves along the following general lines:

1. Present versus future time aspects.

2. Ease of use versus cost or time.

3. Quality versus time or cost.

4. Risk of approach.

5. Use of new strategic technology versus a more familiar tactical approach, etc.

As the project moves through its life cycle processes of scope definition, physical design, and execution, each of these considerations should be reviewed. All too often one or more of the “ibilities” is ignored or overlooked, and the result is downstream frustration by someone in the chain of users or supporters of the item. The section below will offer a brief definition and consideration review for each of the “ibility” items:

1. Traceability relates to the ability to follow a requirement’s life span, in a forward and backward direction (i.e., from origin, development, and specification, its subsequent deployment and use, and periods of ongoing refinement and iteration in any of these phases). Envision traceability through the following example: If a design element or work unit specification is changed, the configuration management process will document this version and be able to ensure that the proper version is used.

2. Affordability relates to the match of the design approach to the defined budget constraint. There is always pressure to cut costs through the design, but many of those decisions cause some adverse impact on other “ibilities.”

3. Feasibility can wear many hats in the project environment. The most obvious of these is the technical feasibility of the approach. Often, stretching to achieve some performance goal will go beyond the existing technical capabilities and create additional risk. Similarly, the lack of critical skills availability can adversely affect the outcome. Think of feasibility as anything that can get in the way of success, whether that be technical, organizational, political, resource, or otherwise.

4. Usability is similar in concept to operability, except that in this case, it more involves the resulting value generated by the output. It is what the process or product does in the hands of the future user. This can be either based on reality or perception but is certainly a concern for the project team to handle.

5. Producibility is an attribute associated with how the actual item will be created. In many cases, there is a gap between the designer and the builder, so the key at this stage is to be sure that the building entities are represented in the design and probably even in the initial requirements process. Think of this as a “chain” of events that need to be linked together and not just thrown over the wall to the next group. Each component in the life cycle needs to consider this attribute.

6. Maintainability deals with the item in production. The consideration here is how much effort is involved in keeping the device ready for operations. In the case of high-performance devices, there is often a significant downtime for maintenanc...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Dedication
• Table of Contents
• List of Figures
• List of Tables
• Authors
• Preface
• Acknowledgments
• List of Abbreviations
• Introduction
• SECTION I Project Environment
• SECTION II Planning Processes
• SECTION III Supporting Processes
• SECTION IV Project Execution
• SECTION V Advanced Tools and Techniques
• Index