Ch 4 Creating the Project Scope
Project exclusions
The project scope statement defines what's included in scope and what's out of scope. By establishing the boundaries of the project, you'll eliminate many assumptions and disappointments when your project is near closure.
Presenting to the project sponsor
The project sponsor, the advocate of the project, will be the first stop on the road to approval of the WBS. However, if the project manager has failed to work with the team, to consider business needs, or to take into account other implementations within the company, the project sponsor can (and should) work with the project manager to correct these issues.
activity list
The project's activity list is derived from the work packages the decomposition of the project scope creates.
Stakeholder Management Plan
The stakeholder management plan is a subsidiary plan of the project management plan that defines the processes, procedures, tools, and techniques to effectively engage stakeholders in project decisions and execution based on the analysis of their needs, interests, and potential impact.
Top-Down Approach
The top-down approach requires more logic and structure, but it is generally the preferred method for creating a WBS. A WBS using the top-down approach would identify a solution first and then dissect the solution into the steps required to implement it. You probably use the top-down approach in your daily life.
WBS Approach(Top-Down and Bottom-Up)
There are two broad methods used to create a WBS: top-down and bottom-up. 1- The topdown approach uses deductive reasoning because it starts with the general and moves to the very specific. 2-Bottom-up moves from the very specific toward the general.
Creating the WBS
project manager and the project team. On some occasions, it may require the project sponsor or other stakeholders.
Project Constraints
specific factors that can limit options. A constraint is anything that limits the project manager's options. You can usually see a constraint when the word "must," "required," or "mandatory" is included in the description. Common constraints are budgets, schedules, and contractual terms.
Work packages are
the lowest-level of breakdown on the work breakdown structures.
WBS is Necessary Because:
-A WBS defines the work required to complete the project. How many times have you started a project only to uncover deliverables that you had totally forgotten about? -A WBS creates a sense of urgency. By creating a WBS, a project manager and his team are working toward the project deliverables. -The WBS is needed to ensure proper scheduling and sequencing for the identified activities to create the project deliverables. -A WBS can help prevent scope changes. When management and departments try to add new features for an existing project, a WBS can ward them off. -A WBS provides control. As a project manager, you may be in charge of several different IT projects. A WBS can allow you to graphically view the status of any project and how progress is being made. -The WBS is a portion of the scope baseline. The scope baseline is the combination of the project scope statement, the WBS, and the WBS dictionary.
code of accounts
A code of accounts is a numbering system that shows the different levels of WBS components and identifies which components belong to which parts of the WBS. For example, I could have a project named Data Center (let's pretend it's been assigned a project code of 507 in my organization). Within this project are four major categories of deliverables: database, network, application, and hardware. Each of these categories would append the assigned project code and would look like this: ■■ 507.1 Database ■■ 507.2 Network ■■ 507.3 Application ■■ 507.4 Hardware There's no confusion as to which deliverable I'm discussing with my project team, and it's easier to track time and costs for just that one particular project element.
Requirements Documentation
A description of how individual requirements meet the business need for the project. The requirements documentation usually includes all of the following information: ■■ Business need to solve or the opportunity the project will seize ■■ Project objectives and goals that can be traced to the requirements ■■ Functional requirements of the project deliverable, such as features and functions of the thing or condition the project will create ■■ Nonfunctional requirements of the project deliverable, such as the level of service, performance objectives, security, interoperability, and support ■■ Quality requirements ■■ Factors for project acceptance ■■ Effect of the deliverable on the organization, departments, or lines of business ■■ Effect of the deliverable on entities outside of the organization ■■ Need for education, training, and ongoing stakeholder competency support ■■ Identified assumptions and constraints
Project Scope Statement (PSS)
A document prepared for the customer that describes what the project will deliver and outlines generally at a high level all work required to complete the project. Remember that the project scope is all of the work, and only the required work, that the project must complete in order for the project to be done. In this document, "work" doesn't refer to the physical activity but to the deliverables that the project team will create.
WBS Dictionary
A document that provides detailed deliverable, activity, and scheduling information about each component in the work breakdown structure. The WBS dictionary typically defines, at a minimum, all of the following about each WBS element: ■■ Code of accounts number ■■ Description of the WBS element ■■ Person, vendor, or other organization responsible for the WBS element ■■ Scheduled creation of the WBS element ■■ Resources required to create the WBS element (resources are people, materials, and facilities) ■■ Cost to create the WBS element ■■ Quality requirements ■■ Criteria for acceptance of the specific deliverable ■■ Technical references, drawings, and other supporting detail ■■ Contract terms and information ■■ Milestone schedule
Work Breakdown Structure (WBS)
A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. An approved project scope statement is needed in order to begin creating the project's work breakdown structure (WBS). A WBS is a deliverables-oriented collection of project components. It is a categorization and decomposition of the project scope statement. ■■ Cost estimating ■■ Cost budgeting ■■ Resource planning ■■ Risk management planning ■■ Activity definition
Balanced Scorecard (BSC)
A measurement framework that helps managers translate strategic goals into operational objectives The balanced scorecard has four categories that are scored based on key performance indicators (KPIs): ■■ Financial Aim to increase profits by lowering costs and increasing revenue. ■■ Customer Reduce customer wait times and improve customer retention for the organization. ■■ Internal process improvement Increase organization efficiency and lower the process cycle time to complete activities. ■■ Organizational capacity Improve the organization's knowledge and skills and improve tools and technology.
Phase
A phase is a portion of the project that typically must be completed before the next phase can begin.
8/80 Rule
A planning heuristic for creating the WBS. This rule states that the work package in a WBS must take no more than 80 hours of labor to create and no fewer than 8 hours of labor to create.
requirements traceability matrix (RTM)
An RTM identifies the project requirements, documents when each requirement is to be created in the project life cycle, and records when the deliverable was actually created. The RTM can also help control and evaluate changes to the project scope. At the end of a project phase and at the end of the project, the RTM can be examined as part of scope verification to confirm that the requirements that were expected were created. You can also use the matrix to record attributes about each deliverable, such as a globally unique identifier, a description of the requirement, the requirement's owner, the versioning information, and the status of the requirement.
decomposition of the project scope
An additional key attribute of the WBS is that it is a "hierarchical decomposition of the work." Decomposition is "a planning technique that subdivides the project scope and project deliverables into smaller, more manageable components, until the project work associated with accomplishing the project scope. As you plow through the decomposition of the project scope to create the work packages, you'll likely notice that you'll need to rearrange elements, add deliverables, and refine the WBS several times.
project deliverables
Any measurable, tangible, verifiable outcome, result, or item that is produced to complete a project or part of a project. Deliverables are the products, services, or conditions the project will create for the project customer and for the organization.
Phase Identification
Are there logical partitions within this project such as deadlines, milestones, or activities based on the calendar? ■■ Are there business cycles within your organization that need to be considered? ■■ Are there financial obligations or constraints within this project that could signify phases? ■■ What processes are currently in place for system development within your organization?
business analyst
Focuses on designing solutions for business problems; interfaces closely with users to demonstrate how IT can be used innovatively. will complete the requirements the collection process for you, you'll want to discuss the requirements in-depth with the business analyst and the stakeholders to confirm that you understand the requirements.
Balanced scoreboard approach
Many organizations use a strategic tool called the balanced scorecard to align their projects to the company's vision and strategy. If your organization uses this approach, you'll work with management to ensure that the project requirements and its scope are in alignment with the organization's balanced scorecard.
milestone charts
Milestone charts track planned targets and actual fulfillments of milestones. Can be in table or Gantt chart format.
Stakeholder approval
Once the WBS has been initially created, it must pass through management for a final sign-off.
Advantages to PM managing project requirements
One advantage of this approach, however, is that you'll have an in-depth understanding of what the customer expects, and that will help you create the project scope, maintain quality, and address any threats or stakeholder concerns. Through interviews, focus groups, workshops, and requirements analysis meetings, you can discover, define, and document what the stakeholders expect the project scope to achieve.
bottom-up model Benefits
The bottom-up method is ideal for brainstorming a solution to a problem. The bottom-up method would call for very specific solutions without delving into all of the details of each solution. The method could investigate the use of new software, a new service provider, or practically any implementation that is still open for discussion on the actual work to be implemented. You might also use the bottom-up method when a stakeholder with lots of influence and power over your project is demanding a very specific feature in the project. With the bottom-up approach, you could start at the specific deliverable the stakeholder is demanding and work backward to the rest of the project scope.
Project requirements
These are the demands set by the customer, regulations, or the performing organization that must exist for the project deliverables to be acceptable. Requirements are often prioritized in a number of ways, from "must have" to "should have" to "would like to have." The requirements of a project define the boundaries. Requirements are the elements, conditions, services, and expectations that the project customers, stakeholders, and management expect the project to create.
Product Scope Description
This is a narrative description of what the project is creating as a deliverable for the project customer. Remember, the project will ultimately create the product scope, or the deliverables. It's essential that the project scope statement define the product scope either directly or refer the reader to a specific document where the existing and approved product scope resides. You're basically confirming that your project will create the product, service, or condition defined in the product scope documentation and the requirements documentation.
Product acceptance criteria
This project scope statement component works with the project requirements but focuses specifically on the product and what the conditions and processes are for formal acceptance of the product. You need to know what it will take for this project to be considered done. You and the customers, the project sponsor, and any other key stakeholders need to define in the project scope statement the conditions that must be met for the project deliverables to be accepted and the project to be closed.
Presenting to Key Stakeholders
To begin the presentation of the WBS, start with the deliverables of the project. By again reminding the stakeholders what the project will produce, you'll be reinforcing their decision to move the project forward. The whole point of presenting the WBS to the stakeholders is to confirm that your project includes all of the requirements they've requested for the project. Reveal the phases required to reach them (deliverables). Milestone Schedule.
Milestones
an action or event marking a significant change or stage in development. Phases make up the project life cycle, and the completion of a phase usually creates a milestone that shows progress in the project.
project assumptions
factors considered to be true, real, or certain without proof or demonstration. An assumption is anything that you believe to be true but that hasn't been proven to be true. Assumptions can have huge impacts on the project's success if they prove false. For example, you might assume a vendor will be available for the duration of the project or make assumptions about software compatibility and data security. These assumptions are difficult to prove in IT, but you often have to accept them to get moving on the project work.