Project Integration Management & Scope Management

Inhalte von Prof. Dr. Kurt Englmeier

Project Integration Management

Project integration management is the heart of project management and is made up of the day-to-day processes the project manager relies on to ensure that all of the parts of the project work together. PIM gears the project work together.

Developing the Project Charter

The point of the charter, other than authorizing the project and the project manager, is to officially launch the project and allow the project manager to go about the business of getting the project work planned and then finished.

Developing the Project Charter

Project requirements for satisfaction The charter must identify what it'll take to complete the project - in other
words, it should identify the metrics for success.
Project approval requirements The project charter needs to clearly state what it takes for the project to be successful and who signs off on project deliverables, project decisions, and project completion.
Project manager The project charter defines who the project manager is and what level of power the project manager has in the project.
Project sponsor The project charter defines who the project sponsor is; if the project sponsor is not the person signing the project charter, it should define who is authorizing the project (it's almost always the project sponsor who signs the charter).
The big picture The charter should identify the high-level purpose of the project, the business need the project aims to accomplish, and/or the product requirements the project will create.
Project purpose The charter needs to answer why the project is being launched and why it's important to the organization.
Milestone schedule Milestones are timeless events that show the progress within a project.
Stakeholder influences The charter needs to identify the stakeholders who will influence the project.
Risks Any of the known risks should be referenced in the project charter.
Functional organizations Functional organizations, such as departments, communities, agencies, and other stakeholders, should be identified and their expected level of participation should be addressed.
Summary budget The charter should have a summary budget.

Developing the Project Plan

The project plan guides the project manager through the execution and monitor and control process groups. The project plan is designed to control the project. As a whole, the point of the project plan is to communicate to the project team, stakeholders, and management how the project will be managed and controlled.

Example: evolution of the planning to action process for a typical technology project



The project plan is actually a bunch of plans and documents:

• Project Scope Management Plan

• Project Change Management Plan

• Schedule Management Plan

• Cost Management Plan

• Quality Management Plan

• Process Improvement PlanDeveloping the Project Plan

• Human Resources Plan

• Risk Management Plan

• Communication Management Plan

• Procurement Management Plan

Executing the Project Plan

The project manager and the project team will go about completing the promises made in the project plan to deliver, document, measure, and complete the project work. The project plan will communicate to the project team, the stakeholders, management, and even vendors what work happens next, how it begins, and how it will be measured for quality and performance. The product of the project is created during these execution processes. The largest percentage of the project budget will be spent during the project execution processes. The project manager and the project team must work together to orchestrate the timings and integration of all the project's moving parts. A flaw in one area of the execution can have ramifications in cost and additional risk, and can cause additional flaws in other areas of the project.

Monitoring and Controlling the Project Work

One of the key activities for the project manager is to monitor the project team and control the work that they complete as part of the project. This is the hands-on portion of the project management career.
The project manager, with the project management plan in hand, will examine what was promised in the plan and what's been executed by the project team. This means the project manager needs work information—work results—to inspect in order to ensure that the project is being completed as planned.

Closing the Project or Phase

The project management plan defines what the project or phase is, how the project or phase will be completed, and finally - the good part - how the project or phase will be closed. The close project processes are those activities that the project manager, the project management team, vendors, and the organization's management will undertake to close out the project work. If a project has multiple phases, as most projects do, the closing processes will be implemented at the end of each phase.

Managing the Project Scope

Collecting and Eliciting Project Requirements:
Functional requirements These describe how the solution will work, what the solution will manage, and all the capabilities the solution will provide for the stakeholder. It's how your project deliverable will operate.
Non-functional requirements These describe the conditions that the functional requirements must operate within. You might hear this also described as the quality requirements or environmental requirements, where the solution will operate at its ideal level or performance. You can recognize nonfunctional requirements when stakeholders talk about speed, capacity, security, user interfaces, or production.

Requirements analysis:
Interviews, focus groups, workshops, creativity techniques, group decision, survey, observation, prototypes.

Project scope management has several purposes:
It defines what work is needed to complete the project objectives.
It determines what is included in the project.
It serves as a guide to determine what work is not needed to complete the project objectives.
It serves as a point of reference for what is not included in the project.

Planning the Project Scope

Project scope management has several purposes:
● It defines what work is needed to complete the project objectives.
● It determines what is included in the project.
● It serves as a guide to determine what work is not needed to complete the project objectives.
● It serves as a point of reference for what is not included in the project.

Project Scope vs. Product Scope

The product scope describes the exact features and functions of the product. The project scope defines the work that your project team and vendors must complete in order for the project to be done. The project scope is based on the product scope. The project's execution completes the project scope, which in turn creates the features and functions of the product scope.

Planning the Project Scope

Planning the project scope involves progressive elaboration. The project scope begins broad and through refinement becomes focused on the required work to create the product of the project. The project manager and the project team must examine the product scope—what the customer expects the project to create—in order to plan on how to achieve that goal. Based on the project requirements documentation, the project scope can be created.

Defining the Project Scope Statement

The process of scope definition is all about breaking down the work into manageable chunks. If you had a desire to create a new house, you probably wouldn't stop by the lumberyard, pick up a truck of lumber, some cement, and nails, and set about building
your dream house. You'd follow a logical approach to designing, planning, and then creating the house. The same is true with project management. Your organization and stakeholders may have a general idea of where the project should end up, but a detailed, fully developed plan is needed to get you there. Scope definition is the process of taking the broad vision for the project and breaking it down into logical steps to reach its completion.

● Product scope description Recall that the product scope description defines the characteristics and features of the thing or
service the project is aiming to create. In most projects, the product scope will be vague early in the scope planning process, and then more details will become available as the product scope is progressively elaborated.

● Product acceptance criteria The scope statement defines the requirements for acceptance. Product acceptance criteria estab-
lish what exactly qualifies a project's product as a success or failure.

● Project deliverables The high-level deliverables of the project should be identified. These deliverables, when predefined met-
rics are met, signal that the project scope has been completed. When appropriate, the scope statement should also list what de-
liverables are excluded from the project deliverables. For example, a project to create a new food product may state that it is
not including the packaging of the food product as part of the project. Items and features not listed as part of the project deliv-
erables should be assumed to be excluded.

● Project boundaries Every project has boundaries. The scope statement defines the boundaries of the project by defining
what's included in the project scope and what's excluded. For example, a project to create a piece of software may include the
created compilation of a master software image, but excludes the packaging and delivery of the software to each workstation with-
in an organization. The project scope must clearly state what will be excluded from the project so there's no ambiguity as to what
the stakeholders will receive as part of the product.

● Project constraints A constraint is anything that restricts the project manager's options. Common constraints include pre-
defined budgets and schedules. Constraints may also include resource limitations, material availability, and contractual restric-
tions.

● Project assumptions An assumption is anything held to be true but not proven to be true. For example, weather, travel delays,
the availability of key resources, and access to facilities can all be assumptions.

● Project requirements The scope statement must define the requirements that the project must adhere to in order for the project to be deemed successful. This includes the prioritization of the stakeholders' needs, wants, and expectations.Creating the

Work Breakdown Structure

As you hopefully know by now, the WBS is a deliverables-orientated collection of project components. Work that doesn't fit into the WBS does not fit within the project. The point of the WBS is to organize and define the project scope.



As you can tell, the WBS is pretty darn important. If you're wondering where exactly the WBS fits into the project as a whole, it is an input to the following seven processes:

• Project Management Plan

• Define Project Activities

• Estimate Project Costs

• Determine Project Budget

• Plan Project Quality

• Identify Project Risks

• Plan Project Procurement

Decomposing the Project Deliverables

Decomposition is the process of breaking down the major project deliverables into smaller, manageable components. So what's a manageable component? It's a unit of the project deliverable that can be assigned resources, measured, executed, and controlled.

Deliverables
1) The major deliverables of the project are identified. This includes the project management activities. A logical approach includes identifying the phases of the project life cycle or the major deliverables of the project.

2) Determine if adequate cost and time estimates can be applied to the lowest level of the decomposed work. Adequate is subjective to the demands of the project work. Deliverables that won't be realized until later portions of the project may be difficult to decompose, since there are many variables between now and when the deliverable is created. The smallest component of the WBS is the work package. A simple heuristic of decomposition is the 8/80 rule: no work package smaller than 8 hours and none larger than 80.

3) Identify the deliverable's constituent components. This is a fancy way of asking whether the project deliverable can be measured at this particular point of decomposition. For example, the decomposition of a user manual may have the constituent components of assembling the book, confirming that the book is complete, shrink-wrapping the book, and shipping it to the customer. Each component of the work can be measured, and may take varying amounts of time to complete, but it all must be done to complete the requirement.

4) Verify the decomposition. The lower-level items must be evaluated to ensure they are complete and accurate. Each item within the decomposition must be clearly defined and deliverable-orientated. Finally each item should be decomposed to the point that it can be scheduled, budgeted, and assigned to a resource.

5) Other approaches include breaking it out by geography or functional area, or even breaking the work down by in-house and contracted work.

Verifying the Project Scope

Scope verification is the process of the project customer accepting the project deliverables. Scope verification happens at the end of each project phase, or as major deliverables are created. Scope verification is ensuring that the deliverables the project creates are in alignment with the project scope. It is concerned with the acceptance of the work. A related activity, quality control, is concerned with the correctness of the work. Scope verification and quality control happen in tandem, as the quality of the work contributes to scope verification. Poor quality will typically result in scope verification failure.

Protecting the Project Scope from Change

When it comes to project management, the one constant thing is change. Changes happen, or try to happen, all the time in
projects. The project manager must have a reliable system to track, monitor, manage, and review changes to the project
scope. Change control focuses on three things.

● It facilitates scope changes to determine that changes are agreed upon.
● It determines if a scope change has happened.
● It manages the scope changes when, and if, they happen.

Change requests are more than just changes to the project scope. They include preventive action, corrective action, and defect repairs. Most change requests are a result of:
Value-added The change will reduce costs (this is often due to technological advances since the time the project scope was created)
External events These could be such things as new laws or industry requirements.
Errors or omissions Errors and omissions can happen to both the project scope (the work to complete the project) and the product scope, and typically constitute an overlooked feature or requirement.
Risk response A risk has been identified and changes to the scope are needed to mitigate the risk.

---

CategoryDelete