ATTACHMENT I Scheduling Expressions
J- node: The number assigned to the ending event of an activity arrow
Lag factor: A ratio or quantity used in precedence diagramming (PDM) which numerically indicates when a dependent activity can start relative to the duration of the predecessor.
Lag time: A time delay required by a sequential connection in a network.
Late finish (LF): Computed value for the latest possible time an activity should be completed according to CPM calculations.
Late start (LS): Computed value for the latest possible time an activity should begin according to CPM calculations.
Lead time:
a) Time between the ES and schedule start for an activity.
b) Time period acting as a constraint for the beginning of an activity.
c) Time in overlapping related activities between the start of one and the start of the second.
Loop: A networking drafting error situation in which activities are so arranged as to cause a sequence of work to return to the originating point.
Leeway: Synonym for float
Logic diagram: The network plan without quantification time data.
Milestone: Planned date to start or to finish a special event.
Merge: To combine or relate two or more networks at any level to form a single network.
Node: A circle graphically depicting the beginning or the ending event of an activity.
Normal cost: Direct cost estimate for an activity based on the normal time to perform it.
Normal time: The estimated duration time allocated to an activity according to established standards.
Operational planning: That aspect of planning that relates to how things will be accomplished.
Original schedule: The user approved schedule at the time, or immediately following project award.
Output: Material coming out of the computer which results from processing input data
Precedence diagramming: A network diagramming technique for showing the relationships of activities in a project with rectangular boxes symbolizing the activities.
Print out: A document usually produced from a computer that translates data into usable, readable form.
Remaining Duration: Time required finishing an activity once it has been started.
Revised schedule: Original adjusted schedule after actual data and /or new change decisions have been introduced.
Resource leveling: The process of scheduling activities within their available float so as to control fluctuations of resource requirements.
Status: Activity completion level at a given point in time.
Sorting: The selective arranging of data to provide a needed pattern of information.
Strategic planning: That aspect of planning which evaluates what must be done within a reasonable period of time.(usually 5 years or more)
Target: A copy of the original plan saved to compare it against performance in the field.
Time compression: A scheduling technique by which project duration is shortened by resource allocation speculation.
Updating: Revising the monitoring plans and documents to reflect current
performance, needed changes on logic, durations, and physical resource allocations as of a given date.
Work Breakdown Structure: Breakdown of a project in activities and sub-activities to allow better planning and control.
Working days: Scheduling time units for measuring activity durations which excludes weekends and holidays.
REFERENCES
Manzanera I., “PLANNING AND SCHEDULING REFERENCES”, Aramco Saudi Arabia, 1991
Lasser's, J.K.,"BUSINESS MANAGEMENT HANDBOOK", McGraw Hill Book Company, 1998
Joseph J. Moder, Cecil R. Phillips, Edward W. Davis, “PROJECT MANAGEMENT WITH CPM, PERT AND PRECEDENCE DIAGRAMMING”, Van Nostrand Reinhold Company, 1995
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
CHAPTER IV
Project Scope Management
Scope Definition is one of the most important processes in any project, because effective Scope Definition provides a common understanding of the project scope among all project stakeholders and describes the project's major objectives. It involves developing the project scope statement that will be the source of future project decisions, including the criteria to determine if the project is successful.
Scope Definition involves the expansion and further definition of project deliverables, constraints, and assumptions that were initially documented in the preliminary project scope statement during the Develop Preliminary Project Scope Statement process of the Project Integration Management Knowledge Area. Scope Definition is one of the most important processes in any project, because effective Scope Definition ensures an understanding of the business case. It involves developing the project scope statement that will be the source of future project decisions, including the criteria to determine if the project is successful.
During Scope Definition the team will analyze the product, identify alternative methods for performing the project work, and perform further stakeholder analysis to document their needs, wants, and expectations. This will also result in a clearer definition of project requirements, and might even lead to the discovery of new requirements that must then be converted into requested changes.
The result of this analysis and discovery work is documented in the detailed project scope statement.
Purpose of the Scope Definition Process
The purpose of the Scope Definition process is to define all project work in a written document called the project scope statement.
This document is used to confirm a common understanding of the project scope among all stakeholders, and to describe the major objectives of the project.
Inputs, Tools and Techniques
This section introduces the inputs, tools and techniques, and outputs of the Scope Definition process.
Project Scope Statement
The project scope statement describes the project's deliverables and the work needed to create those deliverables. The project scope statement guides the project team in making decisions about which requirements from stakeholders are within the approved scope, and which must be treated as change requests.
The project scope statement is a concise document describing the project and the value it has for the company. The detail used in defining the project's requirements and deliverables will exert tremendous leverage in controlling the project's scope and the accuracy of the remaining project planning deliverables. However, excessive detail can even be counterproductive as project participants become overwhelmed with the level of work required to compare related and interdependent project requirements, and to maintain them as changes are incorporated.
The project scope statement defines boundaries by answering the following questions about the project:
• What does the project consist of and not consist of?
• Why is the project necessary?
• What business value will the project provide when it is done?
One of the greatest challenge project teams face is determining an accurate scope and budget. Through progressive elaboration, project teams often develop progressively more sophisticated versions of the project scope statement that are appropriate for the next stage of project work.
Requested Changes
The Scope Definition process may result in requested changes to the project scope management plan or the project scope statement upon an iteration of this process. The requested changes are directed to the Integrated Change Control process, where they are approved, amended, or rejected.
Project Scope Management Plan (Updates)
There may be a need to update the project scope management plan during an iteration of the Scope Definition process to incorporate any requested changes that were approved from the Integrated Change Control process.
Project Scope Statement Contributors
Having a project scope statement ensures that the project manager, management, and customers have the same understanding of the project. The project scope statement is also valuable for briefing the project team.
A number of individuals (the project stakeholders) participate in the drafting and approval of the project scope statement. These include the following:
• Project team members;
• Project manager;;
• Resource managers
• Functional managers;
• Customers; and
• Senior management.
Project Requirements
The project requirements define what standards and specifications the deliverables of the project must satisfy, including how the work is performed. For example, the organization may be governed by ISO9000 quality standards, in which case all processes used by the project team must conform to strict process documentation, test, and audit requirements.
The specifics of the product's capabilities are also documented as requirements; these are the minute elements of the project scope. Later, the deliverables will be evaluated to determine whether they adequately address the defined requirements. Any requirements that are not addressed by one or more deliverables are evaluated as "missing," and any elements of the deliverables that do more than the requirements stipulate are assessed as
"extra," and must be eliminated. Those that were incorrectly implemented are defined as
"wrong," and must be corrected before the deliverable can be accepted.
Project Objectives
The project objectives are specific, measurable criteria that help determine project success.
Common practice requires cost, schedule, and quality criteria to be explicitly identified and agreed upon by the key stakeholders. Success criteria are defined as early as possible in the project's life cycle. Failure to document complete project objectives often leads to scope creep, and ultimately, project failure.
Project objectives must include at least these three items:
• Cost;
• Schedule; and
• Quality measures.
Project objectives should include:
• An attribute; e.g., cost;
• A metric; e.g., United States (US) dollars; and
• An absolute or relative value; e.g., less than 1.5 million.
The best type of objective clearly states the project's impact on the bottom line. This may be expressed in terms such as:
• Increased margins;
• Higher net revenues;
• Reduced turnaround time; and
• Reduced cost of sales.
For a number of reasons, it may not always be possible for the objectives to impact the bottom line. Other criteria to be considered include the impact the project will have on:
• Efficiency and effectiveness;
• Error rates;
• Reduced turnaround time to service a customer request;
• Reduced cost of providing service;
• Quality impact; and
• Improved customer satisfaction.
Objectives are stated in tangible, measurable terms that should leave no room for disagreement as to whether or not the criteria have been met. Some project managers use the SMART criteria to help define project objectives.
These guidelines indicate that project objectives should be:
• Specific;
• Measurable;
• Assignable;
• Realistic; and
• Time-framed.
Product Scope Definition
The product of the project is the final deliverable or outcome of the project. This item must be explicitly described so that all stakeholders know what is to be accomplished and what the product will do. The form and substance of the product's characteristics may vary, but the detail must be sufficient for effective planning.
For example, when a team develops a new satellite, they must deliver a product that meets certain design limitations and performance capabilities. It will usually have to fit within a defined volume, have a center of gravity within a small tolerance of a specified point above the launch vehicle, and be able to tolerate a large range of operating temperatures as it travels through the atmosphere and then orbits through arcs while alternatively exposed to sunlight and then complete darkness.
Project Boundaries
The project scope statement must explicitly define what is included in the project. But, it must also specifically state what will be excluded, so as to avoid future misunderstandings or the risk of scope creep.
Major Project Deliverables development project, while the software product itself is the desired final deliverable.
Product Acceptance Criteria
The product acceptance criteria stipulate how the final product will be evaluated for acceptability. These criteria are of particular importance in subcontracted work, and are valuable to ensure that projects close when their objectives have been met. Product acceptance criteria are also important, to avoid the tendency to "declare victory" when, in fact, major objectives have been missed.
Project Constraints
A constraint is an applicable restriction that will affect project options. This includes any factor that affects when an activity can be scheduled, or how work must be performed.
For example, a constraint may specify that the project must not interfere with the progress of another project that is competing for the same resources, or that it must await the development of a component that another project will produce, and re-use it.
Another example of a constraint might be the stipulation that the project must complete within the current fiscal year in so it will not require another round of funding. Contractual provisions are also generally considered constraints in that they can limit the project team's options.
The number of constraints listed in the scope statement is typically greater than the number of constraints identified in the project charter, as more information about relevant constraints is uncovered through progressive elaboration.
Project Assumptions
Project assumptions are factors that, for planning purposes, are considered true, real, or certain. Assumptions affect all aspects of the project planning and are part of the progressive elaboration of the project. Project teams frequently identify, document, and validate assumptions as part of their planning process. Assumptions generally involve a degree of risk. The number of assumptions listed in the scope statement is typically greater than the number of assumptions listed in the project charter, as more assumptions are typically uncovered during the early stages of planning and progressive elaboration.
Initial Project Organization
The major players and participating organizations who will become (or are already part of) the project team are now known. Documenting them here ensures that their allocation is secure and cannot be easily undermined by competing initiatives.
The project's stakeholders are also listed here. This ensures that they will not be overlooked as the project progresses, particularly when tradeoffs must be negotiated to cope with changing circumstances or new discoveries.
Initial Defined Risks
This section lists any risks that could impact the success of the project so that senior management is aware of them. Items of interest to senior management include those that they must directly address, or those that are out of their control but may result in project failure and diminish the expected project's net value.
Several areas affect the project's success, including the following:
• Technology;
• Environment;
• Interpersonal relationships; and
• Cultural factors.
The project team should use a method of categorizing project risks to ensure that all possible sources of risk are considered.
Schedule Milestones
Often the project must conform to externally imposed milestone dates. These may be the result of constraints such as fiscal year-limited funding or interdependencies with other projects. The team might identify key milestones events during planning.
Fund Limitation
Funding limitations are of major significance to the project sponsor and the supporting accounting and budgeting functions. Projects are usually performed within the limits of a total portfolio of projects whose total investment is capped for a specific period, so both the individual projects and their related investment periods must be capped and tracked.
Cost Estimate
The initial cost estimate is a major factor in determining whether the project will proceed.
Management must always govern projects with an eye on their cost-effectiveness, and take prompt action when the expenditure pattern of a project demonstrates that it will not meet its initial estimate. All estimates provided at this stage should be preceded by a modifier that provides an indication of the level of accuracy.
Project Configuration Management Requirements
The project's deliverables and project management work products must be kept under careful control if the project itself is to remain under control. The project configuration management requirements will describe how the project's work products will be controlled.
Project Specifications
Project specifications identify any specification documents that the project must comply with. These are particularly common in projects that belong to a program, where there may be numerous interfaces that the project's product will be required to implement in order to function with other products. Examples might be weapons systems for aircraft, where carrying pods and arming and launching circuitry have already been specified, while the munitions may be new and completely different from previous types. Another example might be the branding requirements for packaging a new perfume, where bottle type, color, label bordering, font, and background may already be part of a product family specification.
Approval Requirements
Approval requirements describe how the project's deliverables will be accepted, and include the participation of supporting organizations that must adopt and support the product after its implementation, or interface with it.
Attachments to the Project Scope Statement
While the scope statement should, preferably, be as concise as possible, some organizations require additional detailed information which should be included as an attachment.
The most common project scope statement attachments are:
• Risk analyses;
• Feasibility studies;
• Financial analyses;
• Cost/benefit analyses;
• Break-even analyses; and
• Return on investment analyses.
Project Scope Statement Approval Process
Approval of the project scope statement is a significant event that requires input from:
• Senior management: Stating that the project makes enough business sense to move to the detailed planning stage;
• Customer: Concurrence that the project has been correctly described and that they are in agreement with the solution being offered; and
• Project team: Indication that the project has been clearly defined at this high level of detail.
Approval is not authorization for the project. Rather, it is a commitment of resources to complete the detailed plan.
Project Sponsors Level of Commitment
Approval of the project scope statement is a significant action on the part of the project sponsor, and reflects their commitment to the project. A project sponsor is likely to ask a number of questions, such as:
1. Does the project solution relate directly to the business need?
2. Are the project deliverables clear representations of the solution?
3. Is there sufficient business value to warrant further expenditures on the project?
4. Is the relationship between project deliverables and project objectives clearly established?
5. Are initial risks too high and business value too low?
6. Can senior management mitigate any identified risks?
The project manager should pay close attention to the questions most important to the project sponsors. This helps the project manager understand the sponsors' criteria for success.
Scope Planning
Scope Planning involves deciding how the scope will be defined, verified, and controlled, and how the WBS will be created. The project team creates a project scope management plan as the main output of the Project Scope Planning process.
Successful project management begins with a plan to provide an effective approach for managing the scope of work on a project. Scope Planning is the most important phase in any project, because effective scope planning ensures an understanding of the business case. It involves developing the project scope management plan that will be the source of future business decisions, including the criteria to determine if the project is successful.
The purpose of the Scope Planning process is to document Scope Management decisions such as the tools, data sources, methodologies, processes, and procedures that will be used during the Scope Management processes to influence the outcome of the project. The outcome of this process is the project scope management plan that determines how the team will:
• Define the project scope;
• Develop the project scope statement;
• Define and develop the WBS;
• Formalize the completed project deliverables for Scope Verification;
• Determine and manage the monitoring and controlling processes; and
• Control and make refinements to the existing project management methodology for
• Control and make refinements to the existing project management methodology for