• No results found

Correct and Complete?

In document PROJECT MANAGEMENT REFERENCES (Page 96-106)

Verify completion of the decomposition with three questions:

1. Are all lower-level items necessary and sufficient for completion of the decomposed item?

2. Is each item clearly and completely defined?

3. Can each item be appropriately scheduled, budgeted, and assigned to a specific organizational unit (department, team, or person) who will accept responsibility for the satisfactory completion of the item?

If each of these questions cannot be answered yes, then the item must be moved from Step 4, returned to Step 2, and decomposed further;

Once these questions can all be answered yes, then the item is completed; and

Continue this process for all items.

Progressive Elaboration

It is normal for decomposition to be detailed only for the upcoming phase of work for which management must approve detailed plans. Often, there is not sufficient information about work later in the project to break that work down beyond only the highest levels.

Hence, the portions of project planning deliverables related to the immediately upcoming work are detailed and specific.

Those related to later work may be more general, however, and may be presented with a margin of variation within which the project management team expects the project to perform.

As each phase of work concludes, the next phase's WBS will be further decomposed to the necessary level of detail to offer management accurate enough estimates of cost to assure them that the project's value still merits further investment, and to give them a standard against which the project's actual performance during that phase can be compared. That way, they know whether the project will hit its targets.

WBS Dictionary

This is a catalog of all the entries in the WBS which provides descriptive information for each work package, such as:

A statement of work (SOW) describing the work content;

Schedule or milestone data;

Budget estimates and how the estimate was derived; and

Team member who is responsible for the work package or deliverable.

Scope Baseline

Scope baseline is simply the aggregate of the:

Project scope statement;

WBS; and

WBS Dictionary.

Updates to the Project Scope Management Plan

This process involves any changes to the processes for creating and updating the project scope statement or WBS that have been approved through the Integrated Change Control process.

Requested Changes

Requested changes to the project scope statement and its components may arise from the Create WBS process. These changes are processed for review and approval through the Integrated Change Control process.

Scope Verification

Scope Verification is the process of obtaining the stakeholders' formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily.

Scope Verification requires the team to review deliverables and work results to ensure that all were completed correctly. As the deliverables reach completion, it is just as important that the stakeholders agree that these products fulfill the expectations defined at the start of the project. During the Scope Verification, key stakeholders confirm that these expectations have been met. If the project is terminated early, the Scope Verification process should establish and document the level and extent of completion.

Quality Control vs. Scope Verification

Quality Control may require that, before external release of the product to the customer for acceptance, certain procedures/processes relating to quality management for both the product and project, such as Quality Planning, Quality Assurance, and Quality Control, are included as part of the project scope statement.

Scope Verification differs from Quality Control in that it is primarily concerned with acceptance of the work results, while Quality Control is primarily concerned with the correctness of the work results (validation). These processes are often performed in parallel to ensure both correctness and acceptance.

Gaining Stakeholder Acceptance

Once the project is defined, the project manager should seek validation that it has been defined properly, i.e., that the deliverables will meet stakeholder expectations. When the project is complete or when particular deliverables are complete, then the project manager will seek formal acceptance of the deliverables. Formal acceptance is obtained from the project sponsor, customers, and other key stakeholders through the Scope Verification process. This process, including inspection procedures and identification of the approval authorities, is defined in the scope management plan. Verifying the project scope entails reviewing deliverables to ensure that each is completed satisfactorily.

Some of the stakeholders who do not have this level of approval authority must still be engaged by the project manager to ensure their continued commitment to the project, and to minimize the risk that they will object to some aspect of a key deliverable at a later date.

These stakeholders and their interests are initially identified in the project charter, and are subsequently analyzed through ongoing stakeholder analysis. They may have the ability to influence the project outcome, and their support (or, at least, neutrality) is essential to the project's success.

An Acceptance Process

The graphic below illustrates a sample product and deliverable acceptance process. The process begins by identifying the high-level Scope Verification process and approval authorities in the project scope management plan, as well as the product acceptance criteria in the project scope statement. If these elements require refinement (based on changes that occurred during project execution), those refinements to the scope management plan should be processed through Integrated Change Control.

Tools and Techniques used during the Scope Verification Process Inspection

Inspection is the general term used in the PMBOK® Guide, Third Edition, to refer to verifying whether a project deliverable meets the allocated requirements and related product acceptance criteria.

It can include any or several of the following techniques:

Measurement;

Testing;

Review;

Walk-through;

Desk-check; and

Audit.

It is important to note that practice varies widely between application areas regarding the meaning and details of implementation of each of these techniques.

In manufacturing, however, an inspection is usually a quality control check of a subcomponent, usually involving test equipment and measurement of the component against a specified target with limited tolerances for variation.

The intended result of the Scope Verification is to get a documented acceptance of the deliverable. As a result, all inspection techniques must result in the documented approval of the deliverable by the affected stakeholders, or their designated reviewers.

Scope Control

Project Scope Control is concerned with influencing the factors that create project scope changes, and controlling the impact of those changes.

The Scope Control process includes activities to review the project team's progress against the schedule of deliverables. The biggest challenge to the project manager/team is to resist adding changes to project deliverables after they have been formally approved in the project scope statement.

Controlling Scope Creep

Scope Control is the process used to prevent scope creep by:

Formalizing how modifications are managed;

Regulating and managing the impact of changes to project scope;

Assuring all proposed changes, approved changes, and recommended corrective actions are processed using integrated change control; and

Minimizing, detecting, and correcting unauthorized changes to scope.

The Scope Control process includes activities to review the project team's progress against the schedule of deliverables. The biggest challenge to the project manager/team is to resist adding changes to the list of project deliverables after they have been formally approved in the project scope statement.

Scope Control also manages the actual changes when they occur, and ensures that they are integrated with changes to other project management deliverables. It must be recognized that changes to project scope are almost inevitable, both because business domains undergo continuous change themselves, and because new and more effective means for performing business operations are continuously being developed and introduced. Neither of these dynamics can be ignored during the project; they must be continuously evaluated for their potential impact, both positive and negative, on the project scope.

Scope Change Impacts

Allowing the project's scope to change mid-course usually means added costs, quality, greater risks, and longer duration. Many projects fail due to poor scope management. Very often it is a large number of small scope changes that do the damage, rather than the big, obvious ones. The successful project manager has learned that rigorous scope control is essential to delivering projects on time, on budget and with expected quality.

Standard IT development models are requirements-driven. They assume that the project team will be delivering a final product with characteristics that can be clearly defined up front. These methodologies provide a disciplined, sequential process for defining the schedule, budget, resources, risks, quality and scope. This process assures all requested changes and recommended corrective actions are included as part of the process.

An important rule of thumb to remember is:

The later a change is addressed, the greater the cost, risk, and duration of the project.

Scope Control occurs throughout the life of the project (the processes are iterative) and the inputs change based on the phase of the project.

How Stakeholders May Think About Scope Changes

Project team members should be alert to how stakeholders and team members think about scope change. For example, during reviews and other audits and walkthroughs, listen for and watch out for the use of scope change as defensive or aggressive behavior.

Performance Reports

The performance reports indicate how the project is progressing, and specifically, which deliverables have been completed and specifically whether project performance is adequate within ongoing activities.

Approved Change Requests

The approved change requests are received from the Integrated Change Control process in Integrated Change Management, and must be accommodated in the project scope baseline.

Work performance information

Work performance information indicates the extent to which quality standards are being met, estimates to complete on the schedule activities that have started, and documented lessons learned.

Recommended Corrective Actions

Recommended corrective actions may be necessary to bring future project performance back into line with the project management plan. They do not require a change to a project baseline, but represent minor alterations in work processes or resources utilization.

REFERENCES

PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008

PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008

R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009

PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986

M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010

M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001

M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley

& Sons 2003

Chapter V

Procurement Management

Procurement management may be defined as the combined functions of purchasing planning, vendor’s qualification, purchasing, inventory control, traffic control, quality control, and salvage operations.

Procurement management is a concept originally introduce by governments whereby the purchasing function is expanded from merely exchanging money for goods to one of total responsibility for acquiring goods.

From the project management point of view, procurement functions vary according to the job progress within the project life cycle. Since material supply for projects is usually one of the main components of the total construction effort, special attention should be given to the functional organization that will be handling the procurement operation.

Procurement during conceptual estimate paper and design basis paper, is limited to consulting services from the engineering department about:

• Vendor availability;

• Market conditions;

• Order of magnitude estimates; and

• Delivery time estimates.

This consulting service is a simple but vital function considering that project procurement cost is usually found to be 40 to 60 percent of the total cost of the project.

During Project Proposal (PP) development the main function of the procurement

organization should be the creation of an acquisition schedule for long lead time materials according to the project milestone schedule implemented within the project execution plan.

The acquisition schedule is usually called the Long Lead Time Material (LLTM) and equipment schedule and it is always a commanding element for the total project duration.

Additionally, during the project proposal phase preliminary materials take-off (TO) is carried out and a program for procurement of items other than LLTM is established.

Materials 'take-off' (TO) is an engineering function that consist of reading design drawings and producing material and equipment schedules required for supporting construction of the project. Once the material/equipment TO's are completed, purchase requisitions are generated.

Purchase requisitions (PR) usually contain the following:

• Engineering drawings;

• Engineering specifications;

• Inspection requirements;

• Contracting terms and conditions;

• Shipping requirements; and

• Required ex-plant date.

Once the project is funded, definitive design generates more detail information and purchasing functions become more involved in the project development. The already started vendor consultation and qualification will be complemented with new information resulting from the design team and purchase requisitions will be consolidated.

Long lead time material and equipment purchasing orders will be generated immediately after funding if prior provisions for this issue have not been made. This phase of

procurement development requires a great deal of bidding and contracting before the total project requirements are committed.

When all purchase orders have been placed and the contract awarded, the procurement organization has some of the most important tasks within the project life cycle, they are:

• Expediting;

• Quality assurance;

• Quality control;

• Shipping; and

• Delivering to site.

Expediting:

Vendors and sub-vendors have to be closely supervised to avoid unnecessary delays and ascertain delivery according to technical specifications.

Expediting requires:

• Original vendor production schedule;

• Original buyer milestone schedule;

• Establishing a progress measurement system;

• Reporting progress according to the above; and

• Analysis of performance to date and recommending action if necessary.

Quality assurance & Quality control:

Quality assurance and quality control are procurement activities dealing with the

accomplishment of design specifications. A quality assurance program is run by the vendor and control by the buyer at production time. Planning and scheduling for testing and

checking are established at purchase order issuance.

A quality control program is run by the project owner to ascertain that received and installed equipment and material comply with designed specifications and quantities.

In document PROJECT MANAGEMENT REFERENCES (Page 96-106)