CIS 5800 Final A.txt

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 (Cover in Chapter 6)
• .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 (Cover in Chapter 6)
• .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: Such as scheduling tools and software.
• .2 Organizational process assets: Such as historical information from prior projects, to establish initial activity sequences and assign and manage resources.
• .3 Activity list: Output from prior stages of project planning, helps to estimate the resources needed.
• .4 Activity attributes: Output from prior stages of project planning, helps to estimate the resources needed.
• .5 Resource availability: Resource needs have to be matched with resource availability.
• .6 Project management plan: Uses as an input to activity resource estimating. Specifically, the schedule management plan is used, primarily in determining how to manage changes in a project's schedule.

• **.2 Tools and Techniques
• .1 Expert judgment: Estimation based on the experience of one or more experts on the particular activity or project. In most cases, the "doers" can give very precise estimates about the resources needed. Combination of expert judgment and hard data is preferable.
• .2 Published estimating data: Hard data from specific activities carried out on previous projects that may be used to more accurately estimate resource needs. Available from market research companies, a form of benchmarking. These companies gather and analyze research needs for a variety of projects in a variety of industries.
• .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. Ex.: varying amount, source of labor.
• .4 Bottom-up estimating: An estimating technique in which complex activities are further decomposed to a point where more accurate estimates can be made; applied when the resource needs of an activity cannot be easily estimated. This is often the case if the work package itself is fairly complex. These lower-level estimates can then be combined into an estimate for the activity itself.
• .5 Project management software: Such as Microsoft Project can greatly help in estimating resource needs and matching those needs with resource availability and costs. Resource Sheet view lets you specify a name for each resource, as well as attributes such as type, standard and overtime rate, cost/use, and the like. Other views such as Resource Usage display the resource allocation in an easy-to-use way. **Resource calendar can be used to assign resources or resource groups to specific activities. These calendars help the project manager by displaying whether a resource is available or might be tied up by a different activity. Further, costs can be assigned to the different resources, which helps in conducting alternative analyses.
• .6 Benchmarking against competitors: Common practice. For example, competing automakers might benchmark their time from conception to market.
• .7 Techniques utilizing project team members: Such as brainstorming sessions or mind mapping to gather valuable information about expected project duration. In brainstorming sessions, participants are charged with generating ideas without fear of group censure. Group effects, such as social disapproval, effects of authority hierarchy, and domination by vocal people may be inhibiting factors. In mind mapping, visual representation of tasks and problems may help the project team come up with more accurate project representations and associated durations. Visual representation of task and problems – branches radiating out from a core to structure thoughts and ideas. Use a whiteboard, post-its, special software. Helpful to have a facilitator.
• (Multiple techniques should be applied and avoid quick estimates)

• .3 Outputs
• .1 Activity resource requirements: A very detailed listing of the resource requirements for the individual activities and should include any assumptions made during the estimation process; if a certain assumption does not hold, the project immediately knows that the schedule has to be adjusted accordingly.
• .2 Activity attributes (update): Activity definition process entails providing preliminary activity attributes, such as predecessor, successors, and constraints; the resources needed to accomplish the activities estimated in the present stage also become part of a more refined set of activity attributes that can now be used to create more accurate schedules; further, in case the process of estimating resources yields additional changes to the activities (e.g., the realization that additional resources may be necessary to accomplish an activity), such changes will be incorporated into updated activity attributes; all changes must be approved following the project's change control guidelines.
• .3 Resource breakdown structure (RBS): A hierarchical, graphical representation of all needed resources ordered by type or category; to represent the resources in an easy-to-use format; helps to visualize the different types of resources needed for a project; useful in roll-up reporting, for instance, where the project manager wants to show all of the resources (both human and capital) necessary for accomplishing various components of a project.
• .4 Resource calendar (update): A specific type of project calendar that is used to track the hours when certain resources are available; for human resources, a resource calendar specifies working and nonworking days, such as weekends or holidays; use resource calendars to quickly identify whether specific resources are idle (and available) or occupied by another task; every work resource should have its own calendar.
• .5 Requested change

The primary output of the activity resource estimating process is a detailed listing of the resource requirements (both types and quantities needed) for the individual activities; often, the resource needs for different activities are combined to represent the resources needs for each WBS work package

• .1 Inputs
• .1 Enterprise environmental factors (such as project management software, estimating databases): Assist in the duration estimation.
• .2 Organizational process assets (such as historical information): Assist in the duration estimation.
• .3 Project scope statement: Scope of the project is captured in the project scope statement and is used as an input to keep the focus on the project's activities.
• .4 Activity list: Primary input produced as an output from the last phase during the process of resource estimation.
• .5 Activity attributes (schedule-related info. such as predecessors, successors, constraints, dates assumptions, leads, lags, etc.): Primary input produced as an output from the last phase during the process of resource estimation.
• .6 Activity resource requirements: Primary input produced as an output from the last phase during the process of resource estimation.
• .7 Resource calendars: Produced during the activity resource estimation, specifies the times when the resources are available for a certain task.
• .8 Project management plan -- (a) Risk register (a formal listing of identified risks): Captures the different activities' risks, taking into consideration those that have a high probability of impacting the project schedule; (b) Activity cost estimates (both part of the project management plan): Help identify to what degree resource allocations impact the costs for completing the activities.

• **.2 Tools and Techniques
• The process of estimating the duration of the project activities using both project scope and resource information. The duration estimates will then be combined with the activity sequencing to determine the duration of the entire project, as well as to identify the critical path. Reassessments related to calculating activity duration can also occur at this point. For instance, if it appears that an activity's duration is going to be too long, more resources should be assigned.
• .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. For information systems development projects, it can be used for standard tasks such as building interfaces. Historical data, published data (from past projects done in the company), or expert judgment can be used because these are often fairly standardized.
• .3 Parametric estimating: The estimation of activities' durations using some type of mathematical process, i.e. Line Of Code estimate of program/(LOC/day); quantitatively based.
• .4 Three-point estimates: The estimation of activities' durations by averaging the optimistic, pessimistic, and most likely estimates (PERT analysis is an example); quantitatively based. If a high risk is associated with the activity, the estimate will lean toward the pessimistic end.
• .5 Reserve analysis: Technique used to establish contingency reserves during a project to guard against potential risk; any buffer in the project schedule should be documented and accounted for. Basically, time set aside as a reserve in case activity durations don't match the plan.

• .3 Outputs
• .1 Activity duration estimates
• .2 Activity attributes (updates)
• – Gantt chart - bar chart that employs time lines and other types of symbols to illustrate the project schedule; doesn't capture all aspects of a network diagram such as the precedence relationships, but it does convey information about the duration of the various activities, and by capturing the various anticipated start and stop dates of those activities, it also illustrates the duration of the overall project
• –Fixed point – very precise estimate of the time, e.g. July 15th
• –Range estimates – especially during the early stages, very difficult to give precise estimates; the estimates should be more precise only to the degree possible, e.g. 6 months +/- 2 weeks
• –Three-Point - Optimistic, Pessimistic, Most likely

• The process of putting procedures and rules in place for controlling changes to the project schedules
• .1 Inputs
• .1 Schedule management plan: Plan developed during the schedule development process.
• .2 Schedule baseline: Preliminary project schedule developed in the schedule development process.
• .3 Performance reports: To track the project at the activity level, such as tracking which activities have or have not been finished on time.
• .4 Approved change requests: Simply requests for changes in the project schedule.

• .2 Tools and Techniques
• .1 Progress reporting: Continuous updates about the current status of the project.
• .2 Schedule change control system: Determines the process for evaluating and implementing potential schedule changes, including changing approval authorization hierarchies; a control system developed to outline the process for the evaluation and implementation of schedule changes.
• .3 Performance measurement: Aprocess used to determine the magnitude and criticality of schedule variations; i.e., variations in a minor activity not on the critical path are typically much less disruptive than variance in the scheduled completion of a critical activity.
• .4 Project management software: To track project schedules and the effects, or forecast effects, of variations in activity completion dates.
• .5 Variance analysis: To evaluate potential and actual variance on the project schedule; an analysis used to evaluate the effects of variance on the schedule of project activities.
• .6 Schedule comparison bar charts: Help to visualize any deviations of the current status from the baseline to see whether corrective actions need to be taken.

• .3 Outputs
• .1 Schedule model data (updates): Documentation and notification procedures associated with schedule changes.
• .2 Schedule baseline (updates)
• .3 Performance measurements
• .4 Requested changes
• .5 Recommended corrective actions: Procedure for addressing schedule performance problems.
• .6 Organizational process assets (updates): Lessons learned include documentation of the causes of variance from the project schedule; the documentation becomes part of the organizational process assets.
• .7 Activity list (updates)
• .8 Activity attributes (updates)
• .9 Project management plan (updates)

• One other reason companies might choose to offshore is to "follow the sun" in an attempt to maintain a 24-hour software development cycle.
• Motorola revealed several techniques that is used to manage human resources across the globe during a critical project. Anticipating potential problems with globally distributed teams, the Motorola team identified 10 problems likely to emerge and developed 12 techniques to alleviate them.
• As can be seen from the figure, many of these problems are resource management issues, including how to manage capital resources (e.g., choosing and managing the types of technology used by the project team to communicate, coordinate, and execute project activities across time and space) as well as human resources (developing a sense of "teamness" and managing cultural differences). Motorola's example shows that global resources can be used to the project's advantage if properly managed.

• Global development issues and solution strategies
• 

• A source of supply or support, a description that holds true in the case of project management resources, such as money, people/personnel/human, materials, technology/equipment, and space
• For information systems projects, a more specific listing of resources might include systems developers, project managers, systems analysts, stakeholders, development environments, facilities, and information architectures for both the development team and the final implementation of the system

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

• Project stakeholders:
• –Customers
• –Project team members
• –Support staff
• *Systems analyst - may be to elicit requirements from the customer, then determine the design of the system
• *System developers - depend less on business knowledge and more on in-depth technical knowledge of the hardware and software platforms necessary to optimize system performance
• –Project suppliers and vendors
• –End users

• Selected by:
• –Availability
• –Skill set
• –Cost

• The tools and infrastructure (such as hardware, software, and computing environment) used to produce other goods and services
• In information systems development projects, both the development software and the technological platform on which the software resides are capital resources
• Available within or outside the company through external third parties

• Also called the IT war room
• A dedicated part of the organization - frequently consisting of support personnel and a physical facility - whose purpose is to focus on various aspects of project management, including help with methodologies for planning and controlling project activities
• Group dedicated to providing support and expertise on project management functions and activities
• An organizational unit created to centralize and coordinate the projects within an organization
• Function varies among organizations:
• –Collect and organize project data
• –Develop and maintain templates and standards
• –Develop or coordinate training
• –Develop and provide a career path for PMs
• –Provide PM consulting services
• –Provide a structure to house PM while in or between projects

• The measure of the alternative opportunities forgone in the choice of one good or activity over others
• Organizations decide in the selection phase of project initiation how to use limited capital resources

• Project resource availability and selection will impact other project (key knowledge) areas:
• –Schedule/time
• –Cost
• –Quality
• –Risk

• The Standish Group’s CHAOS (Extreme Chaos) studies show improvements in IT projects in the past decade
• Several key statistics regarding the success and failure of projects improved from 1994 to 2000. From a resource allocation standpoint, the most impressive statistics are the percentages of time overruns and cost overruns from 1994 to 2000. Time overruns fell from 222% in 1994 to 63% in 2000, and cost overruns fell from 189% to 45%.
• "The reasons for the increase in successful projects vary. First, the average cost of a project has been more than cut in half. Better tools have been created to monitor and control progress and better skilled project managers with better management processes are being used. The fact that there are processes is significant in itself.”

• Glass is critical of their research:
• Other research does not support their conclusions
• Standish won’t discuss where their data comes from and the validity of their findings
• Standish report says they solicited “failure stories”

• 1. On time
• 2. Within budget
• 3. Meets stakeholders expectations

**Resource selection and management impacts all three

• 1. Activity resource estimating: Identifies what resources are required for each activity
• 2. Activity duration estimating: Determines time required of resource to perform specific activity
• 3. Schedule development: Developing the schedule

• Effort: Actual time spent working on an activity excluding interruptions
• Duration: Elapsed time between the start and finish of an activity including any interruptions (holidays; weekends; sickness; etc.)

For example, designing an interface might take 8 hours of effort, so a programmer could finish the activity in one day. If, however, the programmer has to attend meetings during the day, she might need 2 or 3 days to complete the task. Although the effort would still be 8 hours, the duration from start to finish for that task would be 2 or 3 days.

• Defining all the activities necessary to create a particular project deliverable
• Entails providing preliminary activity attributes, such as predecessors, successors, and constraints

• The iterative process of determining start and finish dates for project activities
• During the process of schedule development, the activity duration estimates, in combination with the activity sequences, are used to establish the final project schedule
• .1 Inputs
• .1 Organizational process assets: Can be as simple as a project calendar; often developed using Microsoft Project or collaboration tools such as Outlook or SharePoint, such as a calendar specifies working and nonworking days.
• .2 Project scope statement: Presents the scope of the entire project and also details any constraints or assumptions that can affect the project's schedule; constraints are usually two types, imposed dates and milestones.
• .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: Specifies how control measures will be implemented to identify potential risks to the project schedule; e.g. if the risk is high that a new mainframe computer will not be installed on time, this might influence the project schedule, and more contingency reserve should be planned for this activity.

• **.2 Tools and Techniques
• .1 Schedule network analysis: Dealing with the time component of project scheduling, calculating the expected start and finish dates, as well as early or late start and finish dates of project activities. Aids managers in determining when activities can be performed given resources and constraints. Some techniques require certain adjustments to the network diagrams. Specifically, the network diagrams have to be analyzed for any errors in the network, such as network loops (path that follow through the same node more than once) or open ends (activities that do not have a successor).
• .2 Critial path method (CPM): A network analysis technique that determines 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. Uses the concepts of **free float/slack and total float/slack to determine the late and early completion times of a project; determined by the calculations of forward and backward passes; free vs. total. (Used to assign a deterministic start and stop date for each activity.) Program Evaluation and Review Technique (PERT) is a technique that uses optimistic, pessimistic, and realistic time estimates to calculate the expected time for a particular task; uses a weighted average method. Not a chart, but rather a mathematical technique used to estimate task or project duration; nonetheless, in many organizations the use of the term PERT chart is refer to an Activity-On-Node Network Diagram is common.
• **.3 Schedule compression: Involves the use of crashing and fast-tracking mathematical techniques in an attempt to shorten the project schedule; what-if-scenario analysis (what-if a major component is delayed?). The use of 2 mathematical techniques to shorten a project's duration. These techniques are known as (1) crashing, which looks at cost-schedule trade-offs, and (2) fast-tracking, which looks at the possibility of performing activities in parallel that would normally be done in sequence. What-if-scenario analysis is a process of evaluating alternative strategies by observing how changes to selected factors affect other factors and outcomes.
• .4 What-if-scenario analysis: A process of evaluating alternative strategies by observing how changes to selected factors affect other factors and outcomes.
• **.5 Resource leveling: Any form of network analysis where resource management issues drive scheduling decisions. If insufficient resources available (say two parallel tasks require the same resource) may have to stretch out schedule.
• .6 Critical chain method: The longest path through a network diagram, considering both task dependencies and resource dependencies; combines CPM and leveling.
• .7 Project management software: Frequently employs third-party add-ons for critical chain scheduling.
• .8 Applying calendars: Always monitor project and resource calendars.
• .9 Adjusting leads and lags: A lead is the time between the start of one activity and the start of an overlapping activity; a lag is the time between the finish of one activity and the start of a succeeding activity.
• .10 Schedule model: Data and information that are complied (collected together) and used in conjunction with manual methods or project management software to perform schedule network analysis to generate the project schedule. All of the information that is generated through whatever schedule development techniques are used will be collected together and serve as a schedule model. The model, or tool, contains all the logic, constraints, resources, and algorithms to do its calculation. The model may contain various electronic files, such as diagrams or documents generated during the estimating tasks. Microsoft Project contains many of these elements and can be thought of as a schedule modeling tool. By running the model, we generate an output, the project schedule.

• .3 Outputs
• .1 Project schedule
• .2 Schedule model data
• .3 Schedule baseline: Once the schedule has been finalized and approved, it becomes the schedule baseline. Shows the set of original start and finish dates, activity durations, as well as work and cost estimates, serves as a basis for comparison during project execution. The Gantt chart view in Microsoft Project will show a black bar for the baseline and a colored bar for the actual progress of the project.
• .4 Resource requirements (updates)
• .5 Activity attributes (updates)
• .6 Project calendar (updates)
• .7 Requested changes
• .8 Project management plan (updates) -- Schedule management plan (updates)

• Dates imposed to meet some type of development deadline
• For example, a new information systems rollout may need to be in effect by a certain date for the company to keep its first-mover strategic advantage
• Another example would be a date imposed by an environmental agency that the company must meet in order to remain in business
• Most common types of such constraints are "start no earlier than" and "finish no later than"

• Dates in the schedule that are meaningful for the completion of specific sets of project events
• Usually set by senior management and usually cannot be changed

• The longest path through a network diagram illustrating the shortest amount of time in which a project can be completed
• A path that has zero or negative (get behind the schedule) total float
• Purpose is to establish how quickly a project can be quickly completed given the tasks, durations, and dependencies illustrated in the networking diagram
• Activities not on the critical path can be delayed (to some extent) without affecting the duration of the entire project; these activities contain slack time (or float)

• Any activity on the critical path
• If any of the critical activities is delayed, the completion of the entire project will be delayed because the overall time or the critical path increases

• The time an activity can be delayed without affecting the immediately following activity
• Always found in noncritical paths because any increase in duration of the activities in the critical path directly affects a project's schedule

• Free slack and total slack displayed in Microsoft Project:
• 

• The time an activity can be delayed without affecting the overall completion date of a project
• If a network path is not a critical path, it can have positive float; a delay in completion of one activity does not necessarily affect the completion date of the entire project
• The existence of positive total float implies that somewhere in the project there is free float; that is, at least one activity can be delayed without affecting the early start date of its immediate successor

• Dedicating extra resources to a particular activity in an attempt to finish the activity sooner than the scheduled completion date
• An example is adding resources so that a data entry task scheduled to take 2 weeks could be accomplished in 1 week by hiring additional data entry personnel
• Another example is to use additional nonhuman resources, such as computer time, in order to shorten the time necessary to complete a task

• The performance of activities in parallel that would normally be performed in sequence, in an attempt to shorten the duration of a project
• Involves doing project tasks at the same time rather than in sequence
• Requires, by necessity, that the task dependencies allow such parallel work

• Fast-tracking and crashing:
• 

• With all the possible contingencies organizations face during projects, it is no wonder that projects can go wrong. When things go wrong, 2 techniques that project managers use to make things right again - fast-tracking and crashing.
• Fast-tracking involves performing in parallel activities that were originally planned to be performed in sequence. In some cases, during a software development project, a manager may choose to begin coding based only on a partial identification of user requirements. The primary advantage is to shorten the duration of the project that is in danger of not being completed on schedule.
• Crashing involves dedicating extra resources to a particular activity in attempt to finish it sooner than its scheduled completion date. In particular, crashing can be seen as trade-off between the dedication of resources and the project schedule. For example, a project manager may decide to use additional project resources (such as additional coders) to finish a particular task so that the schedule may be improved.

• A process of evaluating different scenarios and their effects on the project schedule
• The process of calculating project and activity durations using different assumptions, constraints, and resource allocations
• 2 Common used types of simulation are (1) Monte Carlo simulations - probabilistic analyses used to calculate a distribution of likely results (in our case likely project or task durations) and (2) what-if analyses - take advantage of logic networks by simulating various scenarios, such as what if a major component for a system is delayed

• Any form of network analysis where resource management issues drive scheduling decisions
• This process involves rescheduling activities so that resource requirements for any particular phase of a project do not exceed the availability of those resources
• Example, in a particular software development environment, there may be only one person who has the skill set or knowledge needed to accomplish particular aspects of the development process. If activities requiring that particular developer's skills were originally scheduled at the same time, resources leveling would be used to change the schedule so that they could be accomplished at different times.

• Rules of thumb used to allocate limited resources to project activities
• Schedules based on resource leveling are referred to as resource-limited (or resource-constrained) schedules

• Final technique based on the theory of constraints by Eliyahu Goldratt
• Similar to resource leveling, the critical chain method is used if activities contend for limited resources
• When using this method, the critical path is first identified, independent of resource availability. Entering resource availability might then reveal conflicting activities, which were planned to be completed in parallel but draw upon the same (limited) resources. Based on resource availability, an alternative critical path is created. This new path, based on both task dependencies and resource dependencies, is referred to as a critical chain.
• Another advantage to this method is that it helps to minimize uncertainty in a project's schedule, therefore leading to a shorter overall completion time.

• CCM combines CPM and leveling
• Techniques/aggressive target duration schedules:
• • Avoid multitasking a person (switching tasks is inefficient due to overhead)
• • Reduce use of buffers (people tend to use the allotted time – Parkinson’s Law)
• • Place buffers strategically (where they can be shared rather than built into each activity)
• • Reduce overallocation of time
• • Emphasizing resource and the contention for resources when planning
• • Track buffer status managing both their depletion and replenishment

• The longest path through a network diagram, considering both task dependencies and resource dependencies
• Critical chain scheduling prohibits multitasking with the goal of arriving at a shorter overall completion time

• To cope with uncertainty in project durations, a project's activities often contain duration buffers (i.e., additional time allocated to an activity to account for any unforeseen circumstances).
• Because this buffer is added to every activity, the entire project contains more reserve time than is usually needed.

If a certain time is allotted for an activity, people tend to use it

• 1. When asked to estimate the duration of an activity the activity owner's estimate includes a "safety factor" that serves as a personal buffer
• 2. People will tend to use such buffers if they are available (Parkinson's law)

• The degree to which a set of inherent characteristics fulfill requirements
• Often referred to as a 4th dimension of project management that must be considered along with the classic project constraints of cost, time, and scope
• The customer ultimately decides if quality is acceptable, so the project team must understand stakeholder needs and expectations
• Is about providing excellence in the products or services that an organization produces
• Importance of quality:
• • Determined by industry or tolerance for error
• • Critical: health or safety related

• Can be applied to:
• –The project team - Sets performance expectations; helps establish the development of company quality standards for future projects
• –Processes - Identifies ways to control quality
• –Success level - Allows team to determine the level of quality attainment

• Are often considered during all the processes of project management:
• 1. Initiation - as teams initiate and choose projects, they need to understand what quality standards they must achieve; goals and level of achievement (lessons learned)
• 2. Planning - quality perspectives also have to be practiced during the project planning process as project teams develop the quality control mechanisms they'll use throughout the project life cycle; determine ways to control quality
• 3. Execution - together with control, quality control mechanisms are put into practice, giving the project team constant feedback on their performance; feedback mechanisms to monitor and adjust
• 4. Control - together with execution, quality control mechanisms are put into practice, giving the project team constant feedback on their performance; feedback mechanisms to monitor and adjust
• 5. Closing - also practice in project closure when the team documents its experiences for future organizational projects; goals and level of achievement (lessons learned)

• 1. W. Edwards Deming: best known for his 14 points of quality, stated in his popular publication, Out of Crisis. Deming achieved worldwide prominence and became known as the "prophet of quality." He played in significant role in the economic resurgence in Japan following WWII, where he served as a consultant to Japanese industry. He also did Plan – Do – Check – Act (PDCA)
• 

• 2. Joseph Juran: credited with adding the human element to what was previously a statistical view of project quality. He is further credited with the Pareto Principle, or the 80/20 rule. His book, Juran Trilogy, focused on 3 areas of quality planning, quality improvement, and quality control; fitness for use (customer’s view) vs. conformance to requirements (manufacturer’s view)
• 3. Philip B. Crosby: dedicated his career to convincing managers that preventing problems was cheaper than fixing them. Crosby defined quality in an absolute way so that companies could readily see whether or not quality existed in the workplace; four absolutes of quality management. He wrote Quality is Free suggesting that the cost of defects is so high that companies should strive for zero defects.
• 4. Kaoru Ishikawa: best known for his cause-and-effect diagram, also called a Ishikawa or fishbone diagram which is a diagramming technique used to explore potential and real causes of problems. He was also known for his insistence that quality could always be taken one step further. He expanded on Deming's plan-do-check-act model to create an actionable list of six items. He developed concept of quality circles, a volunteer group composed of workers, who are trained to identify, analyze and solve work-related problems and present their ideas to management in order to improve the performance of the organization and motivate and enrich the work of employees. He led by a supervisor or elected leader.

5. Robert Kaplan and David Norton: developed a new approach for managing and measuring business performance (including management and measurement related to quality). They created a system named the balanced scorecard, which recognized some of the potential problems of previous management approaches. It goes beyond traditional financial measures which describe what happened in the past. Methods are developed and data collected and analyzed to assess performance in each area.

• A rule of thumb used to indicate that a small number of issues typically create the most work in projects
• This rule of thumb can be applied in a variety of ways; i.e., 80% of a project's problems are likely caused by 20% of the defects, or 80% of a project manager's time is consumed by 20% of the problems in a project
• It's typically used for project quality control
• American Society for Quality proposed changing the name of the Pareto Principle to the Juran Principle in 2003

• 1. Build awareness of the need for improvement
• 2. Set goals for improvement
• 3. Organize to reach goals
• 4. Provide training
• 5. Carry out projects to solve problems
• 6. Report progress
• 7. Give recognition
• 8. Communicate results
• 9. Keep score
• 10. Maintain momentum – make annual improvement a part of regular processes

• 1. Make it clear that management is committed to quality
• 2. Form quality improvement teams
• 3. Determine where current and potential quality problems lie
• 4. Evaluate the cost of quality
• 5. Raise quality awareness
• 6. Take actions to correct problems
• 7. Establish a zero-defects program
• 8. Train supervisors
• 9. Hold a “zero-defects” day
• 10. Encourage individuals to establish improvement goals for themselves
• 11. Encourage individuals to communicate obstacles to management
• 12. Recognize those who participate
• 13. Establish quality councils
• 14. Keep doing it to emphasize that quality improvement never ends

• A tool for assessing organizational activity from perspectives beyond the typical financial analysis
• Developed by DRs. Robert Kaplan and David Norton
• Gives advice about what factors (or perspectives) companies should assess in addition to the traditional financial metrics that are typically used
• Is a management system (as opposed to simply being a measurement system) that helps firm clarify and accomplish their corporate vision and strategy
• Suggests viewing organizational activity from 4 perspectives: the learning and growth perspective, the business process perspective, the customer perspective, and the financial perspective

• 1. ISO 9000 certification
• 2. Six Sigma certification
• 3. Baldrige (Sec of Commerce) National Quality Program
• 4. Total Quality Management (TQM)

• A generic management systems standard that any organization can follow to achieve ISO (International Organization for Standardization) certification
• Is applicable to any industry or organization, including information systems focused enterprises
• Is primarily concerned with quality management, specifically the processes that the organization performs to (1) satisfy customer quality requirements, (2) to satisfy regulatory requirements, (3) to enhance customer satisfaction, and finally (4) to provide for continual improvement in performance of these objectives

• ISO 9000 Principles:
• 1 Customer focus
• 2 Leadership
• 3 Involvement of people
• 4 Process approach
• 5 System approach to management
• 6 Continual improvement
• 7 Factual approach to decision making
• 8 Mutually beneficial supplier relationships

• To achieve Six Sigma, a process must not produce more than 3.4 defects per million opportunities
• Identifies and removes causes of errors and produces predictable results
• Is a registered trademark of the Motorola Company
• Purpose is to reduce variation and, therefore, the number of product or service defects
• Has been embraced as a management philosophy that relies on factors such as company culture to enhance quality
• Requires company to embrace and learn a body of knowledge related to quality, to pass proficiency tests on the subject matter, and then to demonstrate appropriate levels of competency in real environments

• Objectives:
• •Define the customer in terms of quality
• •Measure core business processes
• •Analyze the data – no guesswork
• •Improve processes
• •Make sure the processes produced the desired result
• •Follows a five-phase improvement process called DMAIC

Is a systematic, closed-loop process for continued improvement

• 1. Define: Define the problem/opportunity, process, and customer requirements; defining the customer in terms of quality
• 2. Measure: Define measures, then collect, compile, and display data; measuring core business processes
• 3. Analyze: Scrutinize process details to find improvement opportunities; analyzing the data collected
• 4. Improve: Generate solutions and ideas for improving the problem; improving target processes
• 5. Control: Track and verify the stability of the improvements and the predictability of the solution; controlling improvements to ensure the processes remain in line with any changes

• The Baldrige National Quality Program and the associated Malcolm Baldrige National Quality Award are focused on recognizing excellence and quality achievement and recognizes outstanding achievements in 7 areas - (1) leadership, (2) strategic planning, (3) customer and market focus, (4) information and analysis, (5) human resource focus, (6) process management, and (7) results
• Designed to encourage organizations to increase their competitiveness by focusing on:
• 1. Delivering ever improving value to customers
• 2. Improving overall organizational performance

• Is a systematic approach to managing quality
• A description of the culture, attitude, and organization of a company that strives to provide customers with products and services that truly satisfy their needs
• Emphasizes processes being done right the first time and defects and waste eradicated from operations by continuous improvement
• TQM requires management and employees to become involved in continuous improvement of the firm's goods and services
• Companies that have implemented TQM include Ford Motor Company, Phillips Semiconductor, SGL Carbon, Motorola, and Toyota Motor Company

• 8.1 Quality Planning
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Project management plan
• .2 Tools and Techniques
• .1 Cost-benefit analysis
• .2 Benchmarking
• .3 Design of experiments
• .4 Cost of quality (COQ)
• .5 Additional quality planning tools
• .3 Outputs
• .1 Quality management plan
• .2 Quality metrics
• .3 Quality checklists
• .4 Process improvement plan
• .5 Quality baseline
• .6 Project management plan (updates)

• 8.2 Perform Quality Assurance
• .1 Inputs
• .1 Quality management plan
• .2 Quality metrics
• .3 Process improvement plan
• .4 Work performance information
• .5 Approved change requests
• .6 Quality control measurements
• .7 Implemented change requests
• .8 Implemented corrective actions
• .9 Implemented defect repair
• .10 Implemented preventive actions
• .2 Tools and Techniques
• .1 Quality planning tools and techniques
• .2 Quality audits
• .3 Process analysis
• .4 Quality control tools and techniques
• .3 Outputs
• .1 Requested changes
• .2 Recommended corrective actions
• .3 Organizational process assets (updates)
• .4 Project management plan (updates)

• 8.3 Perform Quality Control
• .1 Inputs
• .1 Quality management plan
• .2 Quality metrics
• .3 Quality checklists
• .4 Organizational process assets
• .5 Work performance information
• .6 Approved change requests
• .7 Deliverables
• .2 Tools and Techniques
• .1 Cause and effect diagram
• .2 Control charts
• .3 Flowcharting
• .4 Histogram
• .5 Pareto chart
• .6 Run chart
• .7 Scatter diagram
• .8 Statistical sampling
• .9 Inspection
• .10 Defect repair review
• .3 Outputs
• .1 Quality control measurements
• .2 Validated defect repair
• .3 Quality baseline (updates)
• .4 Recommended corrective actions
• .5 Recommended preventive actions
• .6 Requested changes
• .7 Recommended defect repair
• .8 Organization process assets (updates)
• .9 Validated deliverables
• .10 Project management plan (updates)

• The process of identifying relevant quality standards and developing a plan to ensure the project meets those standards
• Is usually performed at the same time that other project planning issues are addressed because many planning issues (e.g., scheduling, resource allocation, etc.) have quality dimensions
• .1 Inputs
• .1 Enterprise environmental factors: Include the government regulations accoding to which the company must operate, as well as rules standards or guidelines specific to the organization's products or services.
• .2 Organizational process assets: Include factors like the organization's quality policy, quality-related procedures and guidelines, and finally, any documented lessons learned from prior projects. Quality policy is the overall intentions and directions of an organization with regard to quality, as formally expressed by top management.
• .3 Project scope statement
• .4 Project management plan

• **.2 Tools and Techniques
• **.1 Cost-benefit analysis: An evaluation of the costs and benefits of alternative approaches to a proposed activity to determine the best alternative. It can be used to determine the trade-off between the benefits of higher quality and the costs incurred by ensuring a particular product meets those higher quality standards. For example, certain products may experience a "quality threshold." In other words, a product may be of very high quality, yet if it does not fill a customer need, it will not be purchased regardless of the quality. In this case, it would not make sense to incur additional costs to improve the product's quality. It's sometimes criticized as being too simplistic or inaccurate because they reduce everything to monetary terms.
• **.2 Benchmarking: The study of a competitor's product or business practices in order to improve the performance of one's own company.
• .3 Design of experiments: The use of statistical techniques to test the efficiency of certain project management approaches by testing factors that might influence a specific variable. For example, managers might test the efficiency of teams made up of personnel with varying levels of expertise. The design of experiments allows for a statistical framework to be used to systematically change factors that are important to the project rather than having to change these factors one at a time to determine their overall effect. The resulting experimental data should theoretically provide information that leads to optimal conditions for a particular product or process. Software or systems developers can use such a process to help design the most efficient system.
• **.4 Cost of quality (COQ): The cost to improve or ensure quality measures, as well as the cost associated with a lack of quality. Most specifically, the cost of quality might represent the amount of money a business could lose from products or services not being done well the first time around. These costs include anything from rework to lawsuits resulting from poor quality. Estimates are that the cost of quality may run from 15 to 30% of total costs for most businesses.
• .5 Additional quality planning tools

• .3 Outputs
• .1 Quality management plan: A plan specifying how quality measures will be implemented during a project. It lays out the specifics, rather than a philosophy of how quality will be managed during the project. The quality plan serves the additional purpose of being an input into the overall project plan.
• .2 Quality metrics: Operational definitions of specific, processes, events, or products, as well as an explanation of how they will be measured in terms of quality.
• .3 Quality checklists: Tools used to ensure that a specific set of actions has been correctly performed.
• .4 Process improvement plan: A plan specifying how to identify wasteful and non-value-added activities. It details the specific steps required to analyze processes to discover inefficiencies. These steps include - (1) Process boundaries - determine the specifics of each process, including when it starts and finishes, its purpose, its inputs and outputs, its major stakeholders, and its owner; (2) Process configuration - graphically represent the processes to examine how they interrelate and to help analyze them; (3) Process metrics - keep an eye on and maintain control over process status; (4) Targets for improved performance - targets give guidance to any process improvement activities.
• .5 Quality baseline: The basis for which project quality is measured and reported. It may be based on past performance metrics from other similar projects, or it may be determined by experts in the domain.
• .6 Project management plan (updates): Incorporation of quality management plan outputs into project management plan.

• 1. Customer focus: The main goal of the IS department should be to provide products/services that add value and contribute to keeping customers satisfied.
• 2. Process approach: Resources, activities, and outcomes of the IS function are interrelated, and therefore, these associations should be managed as processes. Viewing the IS function as a process makes the implementation of continuous improvement activities easier.
• 3. Leadership: Most quality programs are successful because of strong leadership. Strong leaders are the ones who are willing to invest energy and resources to make the IS quality program a success.
• 4. Culture: The cultural environment of an organization influences the success of a quality program. A culture where IS is treated as an important and integral function in organizational change should be promoted.
• 5. Broad participation: IS quality management should be a joint effort, where all stakeholders participate in, and contribute to, the success of the quality program.
• 6. Motivating the troops: For a quality program to succeed, committed and motivated personnel are very essential. IS personnel should be aware of the benefits of a quality program, in terms of work satisfaction and personal rewards.
• 7. Training: Well-trained personnel are more likely to be leaders and will more vigorously work toward the success of a quality program.
• 8. Measurement and constructive feedback: After the implementation of the IS quality program, results should be measured systematically in order to provide feedback to continuous improvement.
• 9. Accountability for results and rewarding achievements: Teams and individual persons should be rewarded for their efforts in the success of the quality program.
• 10. Self-assessment: The quality program should be evaluated continuously to provide critical feedback, which can be used to sustain it.

• A technique used to determine a company's capabilities with respect to a set of procedures considered as best practices within a given industry
• Serving a function similar to benchmarking
• Is a methodology used to develop and refine how an organization approaches its software development processes
• Is similar to ISO 9001, one of the ISO 9000 series of standards. ISO 9001 focuses specifically on the development and maintenance of software and specifies minimally acceptable quality levels for the processes used to develop software. CMM goes beyond ISO 9001 in establishing a framework for continuous process improvements surrounding software development, and in providing more detail on how to achieve these new quality standards.

• CMM's 5 maturity levels of software processes:
• 1. Initial level: processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.
• 2. Repeatable level: basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.
• 3. Defined level: an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.
• 4. Managed level: an organization monitors and controls its own processes through data collection and analysis.
• 5. Optimizing level: processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization's particular needs.

• 1. Avoiding any failure costs by driving defects to zero
• 2. Investing in prevention activities to improve quality
• 3. Reducing appraisal costs as quality improves
• 4. Continuously evaluating and altering preventive efforts for more improvement

• Cost of Conformance
• 1. Prevention costs such as costs of training staff in design methodologies
• 2. Appraisal costs such as code inspection and testing

• Cost of Nonconformance
• 3. Internal failure costs such as costs of network in programming
• 4. External failure costs such as costs of support and maintenance

• A quality plan should ask:
• 1. What needs to go through a quality check?
• 2. What is the most appropriate way to check the quality?
• 3. When should it be carried out?
• 4. Who should be involved?
• 5. What "Quality Materials" should be used?

• 1. A set of clear and comprehensive requirements should be developed for the project
• 2. The project deliverables must be clearly described, and all stakeholders should agree to and approve this definition
• 3. Project success should be clearly defined by developing the criteria for assessing the project deliverables in terms of completeness and correctness
• 4. The project plan should clearly describe how the development team will do the work
• 5. Milestones should be set for the major deliverables and there should be an approval and sign-off at each point to ensure quality
• 6. All formal communication during the project life cycle should be addressed to the project managers; the project manager knows what is going on at every stage of the project and can, therefore, better manage everyone's expectations
• 7. Any problems that arise during the life cycle of the project should be communicated and addressed as soon as possible

• The process of ensuring that the project meets the quality standards outlined during the quality planning phase
• Focuses on the processes required to produce the results, helping to prevent problems before they occur
• Is comprised of all the activities and actions required to ensure that the project meets the quality standards outlined during the quality planning phase
• Is typically overseen by quality assurance department, a group responsible for making sure that a project satisfied all of the processes needed to meet stakeholder requirements
• .1 Inputs
• .1 Quality management plan: This plan and operational definitions were developed as part of the quality planning process. It's used to outline the specifics of the quality measures that will be in place during the project.
• .2 Quality metrics
• .3 Process improvement plan
• .4 Work performance information
• .5 Approved change requests
• .6 Quality control measurements: The results are often based on quality testing procedures and should be formatted for further analyses.
• .7 Implemented change requests
• .8 Implemented corrective actions
• .9 Implemented defect repair
• .10 Implemented preventive actions

• .2 Tools and Techniques
• .1 Quality planning tools and techniques: Used as part of the quality planning process can also be used during quality assurance.
• .2 Quality audits: Structured and independent review activities designed to review quality management procedures and to identify potential lessons learned. The review is conducted in either scheduled or random fashion by trained personnel from within the organization or, in some cases, by qualified third-party auditors. Quality editors typically examine a number of different project facets looking for ineffective or inefficient policies, processes, or procedures.
• .3 Process analysis: Examines not what is done, but how it is done. It follows steps outlined in the process improvement plan.
• .4 Quality control tools and techniques

• .3 Outputs
• .1 Requested changes: Should be recorded along with recommended corrective actions.
• .2 Recommended corrective actions
• .3 Organizational process assets (updates)
• .4 Project management plan (updates)

• The process of monitoring results/outcomes to determine if the quality standards of the project are being met (Accept the work, rework, adjust process)
• .1 Inputs
• .1 Quality management plan
• .2 Quality metrics
• .3 Quality checklists
• .4 Organizational process assets
• .5 Work performance information: A summary of the status of project deliverables, any performance measures that have been collected, and any implemented changes from the original project management plan.
• .6 Approved change requests
• .7 Deliverables

• .2 Tools and Techniques
• **.1 Cause and effect diagram: Also called fishbone or Ishikawa.
• **.2 Control charts: Graphical, time-based charts used to display process results. The seven run rule states that if seven data points in a row are all below the mean, above the mean, or are all increasing or decreasing, then the process needs to be examined for nonrandom problems.
• .3 Flowcharting: Graphic display of logic and flow.
• .4 Histogram
• .5 Pareto chart: Histograms (or bar charts) where the values being plotted are arranged in descending order.
• .6 Run chart
• .7 Scatter diagram: Relationship between 2 variables.
• .8 Statistical sampling
• .9 Inspection
• .10 Defect repair review

• .3 Outputs
• .1 Quality control measurements
• .2 Validated defect repair
• .3 Quality baseline (updates)
• .4 Recommended corrective actions
• .5 Recommended preventive actions
• .6 Requested changes
• .7 Recommended defect repair
• .8 Organization process assets (updates)
• .9 Validated deliverables
• .10 Project management plan (updates)

• A diagramming technique used to explore potential and real causes of problems
• Typically organizes problems into categories relevant to the industry
• Can be created with MS Visio. See http://office.microsoft.com/en-us/visio/HP012076691033.aspx

Graphical, time-based charts used to display process results

Histograms ordered in terms of the number of occurrences of outline project problems that have been identified

• 1. Cost-benefit analysis: An evaluation of the costs and benefits of alternative approaches to a proposed activity to determine the best alternative.
• 2. Inspection: Measurement and testing procedures to determine whether results conform to the particular project standards.
• 3. Statistical sampling: The process of selecting a random sample from a population in order to infer characteristics about that population.
• 4. Control charts: Graphical, time-based charts used to display process results.
• 5. Cause-and-efect (fishbone) diagrams: A diagramming technique used to explore potential and real causes of problems. The fishbone diagram typically organizes problems into categories relevant to the industry.
• 6. Pareto diagrams: Histograms ordered in terms of the number of occurrences of outline project problems that have been identified.

• Many IT professionals think of testing as a stage that comes near the end of IT product development
• Testing should be done during almost every phase of the IT product development life cycle

• Testing Tasks in the Software Development Life Cycle
• 

• 1. Unit testing: tests each individual component (often a program) to ensure it is as defect-free as possible
• 2. Integration testing: occurs between unit and system testing to test functionally grouped components
• 3. System testing: tests the entire system as one entity
• 4. User acceptance testing (UAT): an independent test performed by end users prior to accepting the delivered system

Including regression testing and separate environments for development, and quality assurance (QA) testing

• Involved in all project management stages:
• –Initiation: Resources critical to the project should be considered when deciding which type of project to pursue; one selection criterion might be the availability of new technologies
• –Planning: Allocation and scheduling of resources
• –Execution: Possible resource reallocation may be required to protect the project schedule
• –Control: Potential project changes may occur requiring action; managers need to constantly monitor the allocation and use of resources to facilitate any approved project changes
• –Close-out: Release of resources and/or termination of contracts; purchased resources and any outstanding contracts must be settled