CIS 5800 Test 1b

• The process of defining project activities, determining their sequence, and estimating their duration
• The project is decomposed into more manageable and controllable parts
• Scheduling activities are part of project time management
• Involves defining project activities, determining their sequence within a project schedule, estimating resources needed, and estimating the activities' durations

• 1. Lack of clarity in scope of the project
• 2. Shifting organizational priorities
• 3. Project changes not well managed
• 4. A lack of project management skills
• 5. Training of project sponsors

The reiteration of the processes of activity definition, sequencing, and duration estimation as part of schedule development

• PMBOK Project Time Management Processes:
• 6.1 Activity Definition
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Work breakdown structure
• .5 WBS dictionary
• .6 Project management plan
• .2 Tools and Techniques
• .1 Decomposition
• .2 Templates
• .3 Rolling waves planning
• .4 Expert judgment
• .5 Planning component
• .3 Outputs
• .1 Activity list
• .2 Activity attributes
• .3 Milestone list
• .4 Requested changes

• 6.2 Activity Sequencing
• .1 Inputs
• .1 Project scope statement
• .2 Activity list
• .3 Activity attributes
• .4 Milestone list
• .5 Approved change requests
• .2 Tool and Techniques
• .1 Precedence Diagramming Method (PDM)
• .2 Arrow Diagramming Method (ADM)
• .3 Schedule network templates
• .4 Dependency determination
• .5 Applying leads and tags
• .3 Outputs
• .1 Project schedule network diagrams
• .2 Activity list (updates)
• .3 Activity attributes (updates)
• .4 Requested changes

• 6.3 Activity Resource Estimating
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Activity list
• .4 Activity attributes
• .5 Resource availability
• .6 Project management plan
• .2 Tools and Techniques
• .1 Expert judgment
• .2 Alternatives analysis
• .3 Published estimating data
• .4 Project management software
• .5 Bottom-up estimating
• .3 Outputs
• .1 Activity resource requirements
• .2 Activity attributes (updates)
• .3 Resource breakdown structure
• .4 Resource calendar (updates)
• .5 Requested changes

• 6.4 Activity Duration Estimating
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Activity list
• .5 Activity attributes
• .6 Activity resource requirements
• .7 Resource calendars
• .8 Project management plan -- Risk register; Activity cost estimates
• .2 Tools and Techniques
• .1 Expert judgment
• .2 Analogous estimating
• .3 Parametric estimating
• .4 Three-point estimates
• .5 Reserve analysis
• .3 Outputs
• .1 Activity duration estimates
• .2 Activity attributes (updates)

• 6.5 Schedule Development
• .1 Inputs
• .1 Organizational process assets
• .2 Project scope statement
• .3 Activity list
• .4 Activity attributes
• .5 Project schedule network diagrams
• .6 Activity resource requirements
• .7 Resource calendars
• .8 Activity duration estimates
• .9 Project management plan -- Risk register
• .2 Tools and Techniques
• .1 Schedule network analysis
• .2 Critial path method
• .3 Schedule compression
• .4 What if scenario analysis
• .5 Resource leveling
• .6 Critical chain method
• .7 Project management software
• .8 Applying calendars
• .9 Adjusting leads and lags
• .10 Schedule model
• .3 Outputs
• .1 Project schedule
• .2 Schedule model data
• .3 Schedule baseline
• .4 Resource requirements (updates)
• .5 Activity attributes (updates)
• .6 Project calendar (updates)
• .7 Requested changes
• .8 Project management plan (updates) -- Schedule management plan (updates)

• 6.6 Schedule Control
• .1 Inputs
• .1 Schedule management plan
• .2 Schedule baseline
• .3 Performance reports
• .4 Approved change requests
• .2 Tools and Techniques
• .1 Progress reporting
• .2 Schedule change control system
• .3 Performance measurement
• .4 Project management software
• .5 Variance analysis
• .6 Schedule comparison bar charts
• .3 Outputs
• .1 Schedule model data (updates)
• .2 Schedule baseline (updates)
• .3 Performance measurements
• .4 Requested changes
• .5 Recommended corrective actions
• .6 Organizational process assets (updates)
• .7 Activity list (updates)
• .8 Activity attributes (updates)
• .9 Project management plan (updates)

• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Work breakdown structure
• .5 WBS dictionary
• .6 Project management plan

• .2 Tools and Techniques
• .1 Decomposition
• .2 Templates
• .3 Rolling waves planning
• .4 Expert judgment
• .5 Planning component

• .3 Outputs
• .1 Activity list
• .2 Activity attributes
• .3 Milestone list
• .4 Requested changes

• .1 Inputs
• .1 Project scope statement
• .2 Activity list
• .3 Activity attributes
• .4 Milestone list
• .5 Approved change requests

• .2 Tool and Techniques
• .1 Precedence Diagramming Method (PDM)
• .2 Arrow Diagramming Method (ADM)
• .3 Schedule network templates
• .4 Dependency determination
• .5 Applying leads and tags

• .3 Outputs
• .1 Project schedule network diagrams
• .2 Activity list (updates)
• .3 Activity attributes (updates)
• .4 Requested changes

• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Activity list
• .4 Activity attributes
• .5 Resource availability
• .6 Project management plan

• .2 Tools and Techniques
• .1 Expert judgment
• .2 Alternatives analysis
• .3 Published estimating data
• .4 Project management software
• .5 Bottom-up estimating

• .3 Outputs
• .1 Activity resource requirements
• .2 Activity attributes (updates)
• .3 Resource breakdown structure
• .4 Resource calendar (updates)
• .5 Requested changes

• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Activity list
• .5 Activity attributes
• .6 Activity resource requirements
• .7 Resource calendars
• .8 Project management plan -- Risk register; Activity cost estimates

• .2 Tools and Techniques
• .1 Expert judgment
• .2 Analogous estimating
• .3 Parametric estimating
• .4 Three-point estimates
• .5 Reserve analysis

• .3 Outputs
• .1 Activity duration estimates
• .2 Activity attributes (updates)

• .1 Inputs
• .1 Organizational process assets
• .2 Project scope statement
• .3 Activity list
• .4 Activity attributes
• .5 Project schedule network diagrams
• .6 Activity resource requirements
• .7 Resource calendars
• .8 Activity duration estimates
• .9 Project management plan -- Risk register

• .2 Tools and Techniques
• .1 Schedule network analysis
• .2 Critial path method
• .3 Schedule compression
• .4 What if scenario analysis
• .5 Resource leveling
• .6 Critical chain method
• .7 Project management software
• .8 Applying calendars
• .9 Adjusting leads and lags
• .10 Schedule model

• .3 Outputs
• .1 Project schedule
• .2 Schedule model data
• .3 Schedule baseline
• .4 Resource requirements (updates)
• .5 Activity attributes (updates)
• .6 Project calendar (updates)
• .7 Requested changes
• .8 Project management plan (updates) -- Schedule management plan (updates)

• .1 Inputs
• .1 Schedule management plan
• .2 Schedule baseline
• .3 Performance reports
• .4 Approved change requests

• .2 Tools and Techniques
• .1 Progress reporting
• .2 Schedule change control system
• .3 Performance measurement
• .4 Project management software
• .5 Variance analysis
• .6 Schedule comparison bar charts

• .3 Outputs
• .1 Schedule model data (updates)
• .2 Schedule baseline (updates)
• .3 Performance measurements
• .4 Requested changes
• .5 Recommended corrective actions
• .6 Organizational process assets (updates)
• .7 Activity list (updates)
• .8 Activity attributes (updates)
• .9 Project management plan (updates)

A progressively more detailed and accurate projection of the project schedule and duration as the project manager or project team specifies project deliverables and activities in more detail

• Different estimation phases:
• 1. Order of magnitude estimates -- important but inexact estimates occurring very early in a project's life cycle - that may be used to justify a project's consideration. These early estimates may vary by as much as +75% to -25%.
• 2. Budgetary estimates -- occur later as the various project components are specified in greater detail, may vary from +25% to -10%.
• 3. Definitive estimates -- developed when the project's resources and activities are highly detailed, may vary only from +10% to -5%.

• Commonly held truth that is simply not true:
• 1. We can have accurate estimates: The "accuracy" assumption should be tempered by what we know of the cone of uncertainty, but we should also be aware that an estimate is still an estimate, and therefore contains an assumption of possible error. Logically, this makes little sense because this would indicate what we're committing to a probability.
• 2. The job of estimating is to come up with a date for completion: The "end date" assumption assumes that when we estimate a time frame, we're estimating the date that the project will be finished. This is problematic because we're not predicting a specific time frame; we're predicting the probability that we'll complete the project within a certain time frame.
• 3. The estimate and the commitment are the same: The "end date" assumption leads to the "commitment" assumption where people confuse the estimate of an end date and commitment to the estimate.
• 4. A project estimate is dependent on the size of the final system: The assumption that the estimate is dependent on the size of the final system is partly true - on average, larger systems take longer to complete than smaller ones. However, some large projects may not take very long if the system is similar to another that the project manager or organization has completed in the past.
• 5. Historical data is an accurate indicator of productivity: The historical data assumption is partly true in that previous experience from previous projects provides information about how long activities will take. However, the current project is not the same as the previous project no matter how much it appears to be so, and in fact, most companies hope past experience may speed things up for future projects.
• 6. Productivity is an accurate indicator of project duration: Productivity as an indicator of project duration is also problematic, since in many cases productivity might be measured by the speed with which we can build something, without accounting for the quality or what we're building.
• 7. Lines of code count is a good way to size a system: Lines of code (LOC) may not provide a good metric for sizing a system because the quantity of lines may not represent the complexity of a system. For estimation purposes, the size of the system should be related to the amount of knowledge that must be obtained and the difficulty of obtaining such knowledge. We wouldn't measure how much knowledge is in a book by weighing it, so why do we assume that several million lines of code couldn't be written to accomplish simple tasks?
• 8. Function points are a good way to size a system: Similar to the logic use in LOC estimations, the use of function points - a popular method used to gauge the size and complexity of a system based on quantifying the functionality provided by a user - suffers similarly. This may be particularly true in modern development environments making greater use of code reuse from past applications. In this case, great functionality may exist but the application may be less complex to build.
• 9. We can get the system faster by assigning more resources: Adding people to hasten project completion is still one of the most common mistakes project teams make. While it would seem that the resources assigned to a project should have a direct bearing on the speed at which project tasks are completed, the relationships is actually more complicated than this. Different skill sets among participants, the ability to have a common understanding of both the problem and the solution, and the overhead of managing more resources may all contribute to delaying project completion rather than hastening it. This idea was ably captured in "The Mythical Math-Month: Essays on Software Engineering," in which author Fred Brooks posited that adding manpower to a late software project simply makes it later.
• 10. Given enough time, we can create a defect-free system: The assumption that we can create defect-free systems is also problematic. While we may strive for a defect-free end product, this may be an unreachable goal. Humans have a finite capacity for knowledge, and it is impossible for a project team to anticipate every conceivable variable that might affect the system.

• 1. Accuracy: Strive for estimates that are accurate enough to not make bad decisions.
• 2. End-date: Define estimate outputs as a range of probabilities for given dates.
• 3. Commitment: Establish processes with discrete estimate and commitment stages.
• 4. History: Recognize that historical data may not be relevant. Think of it as an indicator, rather than as a predictor.
• 5. Productivity: Recognize this assumption. Think of it as an indicator rather than a predictor.
• 6. Lines of code: Recognize this assumption, and try to find a better metric that represents knowledge.
• 7. Function points: Recognize this assumption. As above, try to determine a better method for measuring knowledge.
• 8. More people: Be attentive to a critical mass of people and that adding more can hinder productivity.
• 9. Defect free: Set goals for quality, develop estimates that will allow achievement of quality goals realistically, realizing the goal is to satisfy the customer not necessarily achieve perfection.

• 1. Technologies:
• New and sophisticated software
• Advancements in networking and web capabilities
• 2. Team processes:
• Resource availability
• Resource allocation
• Resource assignment
• 3. Scheduling creation and execution:
• Developed early
• Followed/monitored/changed throughout project
• Assist in determination of progress

• The process of subdividing tasks to make them more easily manageable
• Decomposition is used at various stages of project scheduling. For example, decomposition is used to create a work breakdown structure, which results in defining the various components that make up the entire project. Further, the decomposition process is also used to break down these components into the activities necessary to complete them.

The output from the process of dividing a product into its individual components

The PMBOK refers to the PBS as the bill of materials (BOM)

• The output that results from the process of dividng the entire project into manageable tasks (usually presented as a hierarchical chart or in tabular form)
• Might include a system requirements analysis which documents the desired functionality of a system
• See all of the WBS components as objects (oriented toward deliverables); then created through activities
• This book treats the components of the WBS as deliverable-oriented
• Others see them as tasks (see them not as objects but activities themselves)

• •Illustrates project scope
• •Describes project subcomponents as:
• –Activities (verbs) – “install new plumbing” (tasks) or
• – Deliverables (noun) – “new plumbing” (objects)
• •Separating deliverables from activities needed to produce them gives more freedom to the “doers”
• –Book treats WBS components as deliverables
• –Necessary work defined in activity definition phase

• WBS Inputs:
• •Project scope management plan
• •Project scope statement
• –Identifies deliverables
• –Major steps required to complete the project
• •Experience with similar past projects
• •Organizational process assets
• –Guidelines, organizational policies, procedures

WBS outputs: Outputs of this step include the WBS itself, as well as a WBS dictionary. A WBS dictionary provides details about the individual components of the WBS, such as a description of each component, who is responsible for its completion, a statement of work (SOW), critical milestones, and preliminary estimates of costs or resources required

• Top-Down: Traditional method
• Bottom-up: Used for unique projects; can be useful for novel projects; helps in getting buy-in of all team members
• Rolling Wave: Greater decomposition occurs as project components becomes more defined over time

A scheduling technique in which the team defers breaking down components until they are further clarified, and the decomposition takes place as the project progresses

• The entire project can be broken down according to:
• 1. Major deliverables
• 2. Phases of the project life cycle, systems development life cycle (SDLC)
• 3. Functional areas
• 4. Combination of these

The lowest-level units/deliverables illustrated in the WBS, used to estimate project schedule and budget

• Should be relatively short in duration; within one or two weeks
• Should all be about the same size or should require about the same effort to produce
• Should be specific enough to be completed by one person or a small, well-defined group
• Provides input to scheduling and budget development

• Top-down: from higher-level to lower-level components
• Bottom-up: all team members try to determine as many of the tasks necessary to complete the project as possible; then, they group those different tasks in some logical way to finally plan the entire project; useful for novel projects; it helps to get the buy-in of all project team members; time consuming

• Lists of activities from previous projects
• Another method of determining the deliverables and individual work packages needed to complete the project

• A bar chart showing the start and end dates for the activities of a project
• Lists activity names on the vertical axis and durations on the horizontal axis

• A document that accompanies the WBS and provides additional information about the individual components of the WBS, such as:
• 1. A description of each component
• 2. Who is responsible for its completion
• 3. A statement of work (SOW)
• 4. Critical milestones
• 5. Preliminary estimates of costs or resources required

• Important dates with a project schedule that are meaningful in terms of the completion of specific sets of project events
• •**SMART Criteria – milestones should be: Specific, Measurable, Assignable, Realistic, Time-Framed

• A document containing the WBS and the WBS dictionary; the scope baseline specifies the deliveries and components of a project and serves to measure any deviations from that baseline during project execution
• The project scope statement, the WBS, and the WBS dictionary together form the scope baseline

• The process of identifying and defining activities that must be performed to produce project deliverables
• •Work packages (lowest level deliverables) broken down into discrete activities and attributes required to produce project deliverables
• It's the next step in scheduling a project. In this stage, the different work packages of the WBS are broken down into discrete activities, and the attributes of these activities are defined, including:
• 1. Activity description
• 2. Resource requirements
• 3. Logical predecessor or successor activities, and the like

• Small components used to plan, schedule, execute, monitor, and control the project
• During activity definition, the schedule activities within a given project are identified
• These activities are needed to produce the lowest-level deliverables of the WBS, namely, the work packages, and usually have verb labels (such as "pour cement")

• 1. The preliminary WBS
• 2. WBS dictionary
• 3. Project scope statement (document that contains both the project justification and the project objectives)
• 4. Project management plan (also called the baseline project plan, contains all pertinent information about the project)
• 5. Organizational process assets (such as historical information, procedures, and policies)
• 6. Enterprise environmental factors (such as availability of tools and resources)

• 1. Can be performed by one person or a well-defined group
• 2. Has a single, clearly identifiable deliverable
• 3. Has a known method or technique
• 4. Has well-defined predecessor and successor steps
• 5. Is measurable so that the level of completion can be determined

• 1. Decomposition
• 2. Tempates
• 3. Rolling wave planning
• 4. Expert judgment
• 5. Planning component

• A complete listing of all the schedule activities
• Although the activity list is based on - and can be seen as an extension of - the WBS, the PMBOK does not consider the schedule activities as part of the WBS. Rather, it sees them as components of the project schedule (although, depending on your needs and your software's capabilities, you might choose to include the activities in the WBS)

Include all pertinent attributes of a schedule activity, including description, contraints and assumptions, leads and lags, logical relationships, and predecessor and success activities

• The process of developing a network diagram and updating the activity list from the activity definition phase
• Network diagram: a schematic display that illustrates the various activities (or tasks) in a project as well as their sequential relationships
• •Sequential or parallel activity development

A schematic display that illustrates the various tasks/activities in a project as well as their sequential relationship

• 1. Technical requirements and specifications
• 2. Safety and efficiency - ex. important data should be backed up; efficiency concerns are not mandatory
• 3. Preferences and policies
• 4. Resource availability

• A network diagramming technique that uses boxes and rectangles connected by arrows to represent activities and their precedence relationships
• The boxes represent project activities, and the arrows represent the relationships among these activities or tasks

• Ability to illustrate **4 types of task relationships or dependencies among acitivites (4 ways that tasks exist in relation to other tasks, in order of decreasing frequency of occurrence):
• 1. Finish-to-start (FS): most common of the task dependency types; indicates that one activity cannot be started until another has been completed. A FS B = B doesn't start before A is finished. For example, the programmer cannot begin actual programming until the programming language has been chosen or (programming language chosen) FS (programming started)
• 2. Start-to-start (SS): the start of the successor depends on the start of the predecessor. A SS B = B doesn't start before A starts. For example, programming cannot begin until some portion of the program design is decided on (e.g., 75% of the design activities might be completed) or (program design) SS (programming started)
• 3. Finish-to-finish (FF): the completion of the successor activity depends on the competion of the predecessor. A FF B = B doesn't finish before A is finished. For example, testing a system cannot be finished until the programming is completed or (programming completed) FF (testing of program)
• 4. Start-to-finish (SF): completion of the successor depends on the beginning of the predecessor. A SF B = B doesn't finish before A starts. For example, a copy of the program - even if incomplete - cannot be saved until programming begins or (programming started) SF (saving a copy of the program)

• 1. Team members in different time zones likely have different cultural and social attitudes and different physiological cycles with respect to time. These attitudes and cycles are difficult to change, and perceived lack of sympathy to these differences can cause problems in developing relationships.
• 2. With differences in time zones and possible differences with respect to daylight savings or standard time, seemingly simple clock-time differences become increasingly difficult to accommodate. Mistakes regarding clock time can cause groups to miss important meetings and deadlines.
• 3. Being able to work simultaneously with team members who could be as many as 12 to 16 hours behind or ahead becomes almost impossible. Because some tasks require responses from the distributed team members, group can have long unproductive lapses while they wait for the other team members to respond.
• 4. Such lapses, even if only due to the time difference, can be interpreted by the waiting team members as incompetence or lack of commitment.

• An activity of zero duration that is used to show a logical relationship or dependency in a network diagram
• All nodes with no successor are connected to a dummy end node

• A network diagram consisting of arrows to represent activities and their precedence relationships and nodes to represent project milestones
• Also called the activity on arrow (AOA) method
• Sometimes dummy nodes are needed

• A template developed from previous projects used to shorten the development time of network diagrams
• Templates used for only parts of a project are referred to as subnetwork templates; such templates can exist for different parts of a project, such as interface or database design

• 1. Mandatory dependencies: The relationship of activities that cannot be performed in parallel such as a system cannot be built before the user requirements are determined
• 2. Discretionary dependencies: The relationship of activities based on the preferences of project managers; often based on best-practices procedures such as the selection of a development language after doing a requirements analysis on what a system is supposed to do; although it is certainly possible to choose a language first
• 3. External dependencies: The relationship of project activities and external events, such as the delivery of project components or can’t install network before network switch is delivered. In an information systems development project, creating a new human resource intranet may require the installation of new hardware supplied by a vendor outside the control of the project team

• Lead time: The time required by one task before another task can begin. As an example, in a start-to-start relationship, activity A may need to be worked on for a certain amount of time before activity B can commence. As a specific information systems example, ongoing quality control inspections (activity B) may not begin until a sufficient amount of progress (e.g., some threshold number of lines of code) has been made on developing a particular aspect of the information system (activity A).
• Lag time: The time delay between the completion of one task and the start of the successor. An example is while the task of painting a wall might take 1 hour, it might require an additional 4 hours of lag time before the next task - putting on the second coat of paint - can begin. An information systems example might include the time required to compile a program before testing it for errors

• A network logic method that allows managers to depict nonsequential activities, as well as activities that may have loops or conditional branches
• Other tool and technique available to assist the project manager in accomplishing the activity sequencing process (not mentioned in PMBOK Project Time Management processes)

A source of supply or support, such as money, people/personnel, materials, technology, and space

All project stakeholders, including customers, project team members, support staff, project suppliers, and end users

The tools and infrastructure used to produce other goods and services

The measure of the alternative opportunities forgone in the choice of one good or activity over others

Actual time spent working on an activity

Elapsed time between the start and finish of an activity

• 1. Expert judgment: Estimation based on the experience of one or more experts on the particular activity or project.
• 2. Published estimating data: Hard data from specific activities carried out on previous projects that may be used to more accurately estimate resource needs.
• 3. Alternatives analysis: An estimating technique in which trade-offs between the time needed, the resources invested, and the desired quality of the final deliverable are examined.
• 4. Bottom-up estimating: An estimating technique in which complex activities are further decomposed to a point where more accurate estimates can be made.

A very detailed listing of the resource requirements for the individual activities

A hierarchical, graphical representation of all needed resources ordered by type or category

A specific type of project calendar that is used to track the hours when certain resources are available

The process of estimating the duration of the project activities using both project scope and resource information

• 1. Expert judgment: Previously mentioned under the activity definition process, can be used as a means to better estimate activities' durations and their need for specific resources. Expert judgment can rely on the subjective option of project participants (so be careful).
• 2. Analogous estimating: The estimation of activities' durations based upon the duration of similar activities.
• 3. Parametric estimating: The estimation of activities' durations using some type of mathematical process.
• 4. Three-point estimates: The estimation of activities' durations by averaging the optimistic, pessimistic, and most likely estimates.
• 5. Reserve analysis: Technique used to establish contingency reserves during a project to guard against potential risk.

The process of determining start and finish dates for project activities

Dates imposed to meet some type of development deadline

The process of calculating expected, early, and late start and finish dates of a project

A technique used for determining the sequence of task activities that directly affect the completion of a project, accomplished by determining the longest path through a network diagram that illustrates the shortest amount of time in which a project can be completed

The longest path through a network diagram illustrating the shortest amount of time in which a project can be completed

Any activity on the critical path

The time an activity can be delayed without affecting the immediately following activity

The time an activity can be delayed without affecting the overall competion date of a project

A technique that uses optimistic, pessimistic, and realistic time estimates to calculate the expected time for a particular task

The use of mathematical techniques to shorten a project's duration

Dedicating extra resources to a particular activity in an attempt to finish the activity sooner than the scheduled completion date

The performance of activities in parallel that would normally be performed in sequence, in an attempt to shorten the duration of a project

A process of evaluating different scenarios and their effects on the project schedule

A process of evaluating alternative strategies by observing how changes to selected factors affect other factors and outcomes

Any form of network analysis where resource management issues drive scheduling decisions

Rules of thumb used to allocated resources to project activities

The longest path through a network diagram, considering both task dependencies and resource dependencies

Data and information that are complied and used in conjunction with manual methods or project management software to perform schedule network analysis to generate the project schedule

The process of putting procedures and rules in place for controlling changes to the project schedules

A control system developed to outline the process for the evaluation and implementation of schedule changes

A process used to determine the magnitude and criticality of schedule variations

An analysis used to evaluate the effects of variance on the schedule of project activities

• 1. Activity list: A complete listing of all the schedule activities
• 2. Activity attributes: Description; Assumptions and constraints; Leads and lags; Logical relationships; Predecessor and successor activities
• 3. Milestones: Important dates that are meaningful in terms of the completion of sets of project events
• 4. Requested changes to project scope statement and WBS