Scope « Project Management

Construtcing a Project Charter – the Beginning of the Project Scope

The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. A project manager is identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of planning, and preferably while the project charter is being developed.

A project initiator or sponsor external to the project organization, at a level that is appropriate to funding the project, issues the project charter. Projects are usually chartered and authorized external to the project organization by an enterprise, a government agency, a company, a program organization, or a portfolio organization, as a result of one or more of the following:

• A market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages)

• A business need (e.g., a training company authorizing a project to create a new course to increase its revenues)

• A customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park)

• A technological advance (e.g., an electronics firm authorizing a new project develop a faster, cheaper, and smaller laptop after advances in computer memory and electronics technology)

• A legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials)

• A social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).

These stimuli can also be called problems, opportunities, or business requirements. The central theme of all these stimuli is that management must make a decision about how to respond and what projects to authorize and charter. Project selection methods involve measuring value or attractiveness to the project owner or sponsor and may include other organizational decision criteria. Project selection also applies to choosing alternative ways of executing the project.

Chartering a project links the project to the ongoing work of the organization. In some organizations, a project is not formally chartered and initiated until completion of a needs assessment, feasibility study, preliminary plan, or some other equivalent form of analysis that was separately initiated. Developing the project charter is primarily concerned with documenting the business needs, project justification, current understanding of the customer’s requirements, and the new product, service, or result that is intended to satisfy those requirements. The project charter, either directly, or by reference to other documents, should address the following information:

Requirements that satisfy customer sponsor, and other stakeholder needs, wants and expectations;

• Business needs, high-level project description, or product requirements that the project is undertaken to address

• Project purpose or justification

• Assigned Project Manager and authority level

• Summary milestone schedule

• Stakeholder influences

• Functional organizations and their participation

• Organizational, environmental and external assumptions

• Organizational, environmental and external constraints

• Business case justifying the project, including return on investment

• Summary budget.

During subsequent phases of multi-phase projects, the Develop Project

Charter process validates the decisions made during the original chartering of the project. If required, it also authorizes the next project phase, and updates the charter.

Contract (When Applicable)

A contract from the customer’s acquiring organization is an input if the project is being done for an external customer.

Project Statement of Work:

The statement of work (SOW) is a narrative description of products or services to be supplied by the project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, for example, request for proposal, request for information, request for bid, or as part of a contract. The SOW indicates a:

Business need – an organization’s business need can be based on needed training, market demand, technological advance, legal requirement, or governmental standard.

• Product scope description – documents the product requirements and characteristics of the product or service that the project will be undertaken to create. The product requirements will generally have less detail during the initiation process and more detail during later processes, as the product characteristics are progressively elaborated. These requirements should also document the relationship among the products or services being created and the business need or other stimulus that causes the need. While the form and substance of the product requirements document will vary, it should always be detailed enough to support later project planning.

• Strategic plan – all projects should support the organization’s strategic goals. The strategic plan of the performing organization should be considered as a factor when making project selection decisions.

Enterprise Environmental Factors:

When developing the project charter, any and all of the organization’s enterprise environmental factors and systems that surround and influence the project’s success must be considered. This includes items such as, but not limited to:

• Organizational or company culture and structure

• Governmental or industry standards (e.g., regulatory agency regulations, product standards, quality standards, and workmanship standards)

• Infrastructure (e.g., existing facilities and capital equipment)

• Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing)

• Personnel administration (e.g., hiring and firing guidelines, employee performance reviews, and training records)

• Company work authorization system

• Marketplace conditions

• Stakeholder risk tolerances

• Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases)

• Project management information systems (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems.

Organizational Process Assets

When developing the project charter and subsequent project documentation, any and all of the assets that are used to influence the project’s success can be drawn from organizational process assets. Any and all of the organizations involved in the project can have formal and informal policies, procedures, plans, and guidelines whose effects must be considered. Organizational process assets also represent the organizations’ learning and knowledge from previous projects; for example, completed schedules, risk data, and earned value data. Organizational process assets can be organized differently, depending on the type of industry, organization, application area. For example, the organizational process assets could be grouped into two categories:

Organization’s processes and procedures for conducting work:

· Organizational standard processes, such as standards, policies (e.g., safety and health policy, and project management policy), standard product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization)

· Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria templates (e.g., risk templates, work breakdown structure templates, and project schedule network diagram templates)

· Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project

· Organization communication requirements (e.g., specific communication technology available, allowed communication media, record retention, and security requirements)

· Project closure guidelines or requirements (e.g., final project audits, project evaluations, product validations, and acceptance criteria)

· Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions)

· Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking

· Change control procedures, including the steps by which official company standards, policies, plans, and procedures—or any project documents—will be modified, and how any changes will be approved and validated

· Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix

· Procedures for approving and issuing work authorizations.

Organizational corporate knowledge base for storing and retrieving information:

· Process measurement database used to collect and make available measurement data on processes and products

· Project files (e.g., scope, cost, schedule, and quality baselines, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact)

· Information and lessons learned knowledge base (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from the risk management effort)

· Issue and defect management database containing issue and defect status, control information, issue and defect resolution, and action item results

· Configuration management knowledge base containing the versions and baselines of all official company standards, policies, procedures, and any project documents

· Financial database containing information such as labor hours, incurred costs, budgets, and any project cost overruns.

Develop Project Charter: Tools and Techniques

Project Selection Methods

Project selection methods are used to determine which project the organization will select. These methods generally fall into one of two broad categories:

• Benefit measurement methods that are comparative approaches, scoring models, benefit contribution, or economic models.

• Mathematical models that use linear, nonlinear, dynamic, integer, or multi-objective programming algorithms.

Project Management Methodology

A project management methodology defines a set of Project Management Process Groups, their related processes and the related control functions that are consolidated and combined into a functioning unified whole. A project management methodology may or may not be an elaboration of a project management standard. A project management methodology can be either a formal mature process or an informal technique that aids a project management team in effectively developing a project charter.

Project Management Information System

The Project Management Information System (PMIS) is a standardized set of automated tools available within the organization and integrated into a system. The PMIS is used by the project management team to support generation of a project charter, facilitate feedback as the document is refined, control changes to the project charter, and release the approved document.

Expert Judgment

Expert judgment is often used to assess the inputs needed to develop the project charter. Such judgment and expertise is applied to any technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including:

• Other units within the organization

• Consultants

• Stakeholders, including customers or sponsors

• Professional and technical associations

• Industry groups.

October 23, 2008 Posted by Donna Ritter | Project Initiation, Project Management, Scope Management | project charter, Project Initiation, Scope | Leave a comment

Using EVM as a Performance Management Methodology

As a performance management methodology, EVM adds some critical practices to the project management process. These practices occur primarily in the areas of project planning and control, and are related to the goal of measuring, analyzing, forecasting, and reporting cost and schedule performance data for evaluation and action by workers, managers, and other key stakeholders.

In the planning process, the means for assessing physical work progress and assigning budgetary earned value needs to be established. In addition to routine project management planning, earned value measurement techniques are selected and applied for each work task, based on scope, schedule, and cost considerations.

In the project execution process, EVM requires the recording of resource utilization (i.e., labor, materials, and the like) for the work performed within each of the work elements included in the project management plan. In other words, actual costs need to be captured in such a way that permits their comparison with the performance measurement baseline.

In the project control process, EVM requires that physical work progress be assessed and budgetary earned value be credited (using the selected earned value measurement techniques), as prescribed in the project management plan. With this earned value data, the planned value data from the performance measurement baseline, and the actual cost data from the project cost tracking system, the project team can perform EVM analysis at the control account and other levels of the project work breakdown structure, and report the EVM results as needed.

During the project planning process, EVM requires the establishment of a performance measurement baseline (PMB). This requirement amplifies the importance of project planning principles, especially those related to scope, schedule, and cost. EVM elevates the need for project work to be executable and manageable and for the workers and managers to be held responsible and accountable for the project’s performance. Project work needs to be broken down—using a work breakdown structure—into executable tasks and manageable elements often called control accounts. Either an individual or a team needs to manage each of the work elements. All of the work needs to be assigned to the workforce for execution using an organization breakdown

structure (OBS).

In the planning process, the means for assessing physical work progress and assigning budgetary earned value also needs to be established. In addition to routine project management planning, earned value measurement techniques are selected and applied for each work task, based on scope, schedule, and cost considerations.

In the project execution process, EVM requires the recording of resource utilization (i.e., labor, materials, and the like) for the work performed within each of the work elements included in the project management plan. In other words, actual costs need to be captured in such a way that permits their comparison with the performance measurement baseline.

In the project control process, EVM requires that physical work progress be assessed and budgetary earned value be credited (using the selected earned value measurement techniques), as prescribed in the project management plan. With this earned value data, the planned value data from the performance measurement baseline, and the actual cost data from the project cost tracking system, the project team can perform EVM analysis at the control account and other levels of the project work breakdown structure, and report the EVM results as needed.[1]

October 10, 2008 Posted by Donna Ritter | earned value, Performance Management | cost, Scope, Stakeholders, Work Process | 1 Comment

Scope Management

Scope Management is the process of defining what work is required and then making sure that all of the work and only the work is done. This Process includes scope planning, scope definition, creation of the Work Breakdown Structure (WBS), scope verification and scope control.

Any Project Manager will tell you that “scope creep”is one of the worst problems on a project. That means you must institute a formal Change Control mechanism. All scope must fit the Program’s charter (defined earlier in the process).

You should be giving the customer what he asked for; no more, no less. I heard someone once compare it to having a customer order a VW and the engineering team building a Cadillac. Giving away extras is a waste of time and adds to the risk of the project. Maybe it only takes 30 minutes to code; but what about testing, documentation, and training to name a few.

Scope Management involves mastering both product and project scope. Product Scope is another way to say “requirements that relate to the product of the project”. Project scope is the work you need to deliver that product. This includes meetings, reports, analysis and any other project related activities.

Scope baseline: Measurements of success on the project include whether the requirements have been met and whether the scope baseline has been met. The scope baseline is the scope statement , the work breakdown structure and the work breakdown structure dictionary.

Scope planning is focused on thinking ahead and thinking “how will I do this” before doing the work and the Scope Management Plan.

The Scope Management Plan answers “how will I do scope? What tools should I use to plan how the project will accomplish the scope of this project?” The output of Scope Planning is the Project Scope Management Plan. It should contain 3 parts: how will the scope be planned, executed and controlled. It may be created in iterative steps during project planning. Once complete, it becomes part of the overall Project Plan and cannot be changed without going through a formal Change review process. Once you get to Risk Planning, it is possible that changes will have to be made to the Scope using the formal Change review process.

Scope definition: Scope definition is primarily concerned with what is and is not included in the project. Scope definition takes into account constraints and assumptions. The result is used to manage and measure the project performance.

Stakeholder Analysis: This process makes sure the stakeholders’ needs are metm and turned into requirements.

Product Analysis: This analyzes the objectives stated by the customer or sponsor and turns them into tangible requirements.

Project Scope Statement: The preliminary scope statement is expanded into the “final” project scope statement to be used on the project. Different approaches to performing the work and incorporating the needs of the stakeholders are taken into consideration.

Scope planning inputs:

Product description
Project Charter
Project constraints
Project assumptions

The tools and techniques that may be used are benefit/cost analysis, expert judgement, product analysis and alternatives identification.

The main key message here is to have a clearly defined Change Management Plan to address any changes to the final scope. When a change is made, if it is deemed necessary, will cause many other plans and the schedule to be re-done. Changes should be documented as required, important, non-critical or nice to have.

Scope Management is the process of defining what work is required and then making sure that all of the work and only the work is done. This Process includes scope planning, scope defintion, creation of the Work Breakdown Structure (WBS), scope verification and scope control.