Project Management Body of Knowledge
The Project Management Body of Knowledge is a set of standard terminology and guidelines for project management. The body of knowledge evolves over time and is presented in A Guide to the Project Management Body of Knowledge, a book whose sixth edition was released in 2017; the Guide is a document resulting from work overseen by the Project Management Institute, which offers the CAPM and PMP certifications. Much of the PMBOK Guide is unique to project management e.g. critical path method and work breakdown structure. The PMBOK Guide overlaps with general management regarding planning, staffing and controlling the operations of an organisation. Other management disciplines which overlap with the PMBOK Guide include financial forecasting, organisational behaviour, management science and other planning methods. Earlier versions of the PMBOK Guide were recognized as standards by the American National Standards Institute which assigns standards in the United States and the Institute of Electrical and Electronics Engineers.
The evolution of the PMBOK Guide is reflected in editions of the Guide. The Guide was first published by the Project Management Institute in 1996; that document was to some extent based on earlier work that began with a white paper published in 1983 called the "Ethics and Accreditation Committee Final Report." The second edition was published in 2000. In 2004, the PMBOK Guide — Third Edition was published with major changes from the previous editions; the Fourth edition was published in 2008. The Fifth Edition was released in 2013; the latest English-language version of The PMBOK Guide — The Sixth Edition was released in September 2017. The PMBOK Guide is intended to be a "subset of the project management body of knowledge, recognized as a good practice.'Generally recognized' means the knowledge and practices described are applicable to most projects most of the time and there is a consensus about their value and usefulness.'Good practice' means there is a general agreement that the application of the knowledge, skills and techniques can enhance the chance of success over many projects."
This means that sometimes the "latest" project management trends promoted by consultants, may not be part of the latest version of The PMBOK Guide. However, the 6th Edition of the PMBOK Guide now includes an "Agile Practice Guide" The PMBOK Guide is process-based, meaning it describes work as being accomplished by processes; this approach is consistent with other management standards such as ISO 9000 and the Software Engineering Institute's CMMI. Processes interact throughout a project or its various phases. Inputs Tools and Techniques Outputs A Guide to the Project Management Body of Knowledge — Sixth Edition provides guidelines for managing individual projects and defines project management related concepts, it describes the project management life cycle and its related processes, as well as the project life cycle. And for the first time it includes an "Agile Practice Guide"; the PMBOK as described in the Guide recognizes 49 processes that fall into five basic process groups and ten knowledge areas that are typical of most projects, most of the time.
The five process groups are: Initiating: processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase. Planning: Those processes required to establish the scope of the project, refine the objectives, define the course of action required to attain the objectives that the project was undertaken to achieve. Executing: Those processes performed to complete the work defined in the project management plan to satisfy the project specifications Monitoring and Controlling: Those processes required to track and regulate the progress and performance of the project. Closing: Those processes performed to finalize all activities across all Process Groups to formally close the project or phase; the ten knowledge areas, each of which contains some or all of the project management processes, are: Project Integration Management: the processes and activities needed to identify, combine and coordinate the various processes and project management activities within the project management process groups.
Project Scope management: the processes required to ensure that the project includes all the work required, only the work required, to complete the project successfully. Project Schedule Management: the processes required to manage the timely completion of the project; until the 6th edition of the PMBOK Guide this was called "Project Time Management" Project Cost Management: the processes involved in planning, budgeting, funding and controlling costs so that the project can be completed within the approved budget. Project Quality Management: the processes and activities of the performing organization that determine quality policies and responsibilities so that the project will satisfy the needs for which it was undertaken. Project Resource Management: the processes that organize and lead the project team; until the 6th edition of the PMBOK Guide this was called "Project Human Resource Management" Project Communications Management: the processes that are required to ensure timely and appropriate planning, creation, storage, management, control and the ultimate disposition of project information.
Project Risk Management: the pr
SAPHIRE is a probabilistic risk and reliability assessment software tool. SAPHIRE stands for Systems Analysis Programs for Hands-on Integrated Reliability Evaluations; the system was developed for the U. S. Nuclear Regulatory Commission by the Idaho National Laboratory. Development began in the mid-1980s when the NRC began exploring two notions: 1) that Probabilistic Risk Assessment information could be displayed and manipulated using the emerging microcomputer technology of the day and 2) the rapid advancement of PRA technology required a inexpensive and available platform for teaching PRA concepts to students. 1987 Version 1 of the code called IRRAS introduced an innovative way to draw and analyze graphical fault trees. 1989 Version 2 is released incorporating the ability to draw and analyze graphical event trees. 1990 Analysis improvements to IRRAS led to the release of Version 4 and the formation of the IRRAS Users Group. 1992 Creation of 32-bit IRRAS, Version 5, resulted in an order-of-magnitude decrease in analysis time.
New features included: end state analysis. 1997 SAPHIRE for Windows, version 6.x, is released. Use of a Windows user-inferface makes SAPHIRE easy to learn; the new "plug-in" feature allows analysts to expand on the built-in probability calculations. 1999 SAPHIRE for Windows, version 7.x, is released. Enhancements are made to the event tree "linking rules" and to the use of dual language capability inside the SAPHIRE database. 2005 SAPHIRE for Windows, version 8.x, undergoes development. 2008 SAPHIRE for Windows, version 8.x, release as a beta version. 2010 SAPHIRE for Windows, version 8.x, release for U. S. Government and industry use; the evolution of software and related analysis methods has led to the current generation of the SAPHIRE tool. The current SAPHIRE software code-base started in the mid-1980s as part of the NRC’s general risk activities. In 1986, work commenced on the precursor to the SAPHIRE software – this software package was named the Integrated Reliability and Risk Analysis System, or IRRAS.
IRRAS was the first IBM compatible PC-based risk analysis tool developed at the Idaho National Laboratory, thereby allowing users to work in a graphical interface rather than with mainframe punch cards. While limited to the analysis of only fault trees of medium size, version 1 of IRRAS was the initial step in the progress that today has led to the SAPHIRE software, software, capable of running on multiple processors and is able to handle large analyses. NASA relied on worst-case Failure mode and effects analysis for safety assessment. However, this approach has problems, such as it is qualitative and does not aggregate risk at a system or mission level. On October 29, 1986, the investigation of the Challenger accident criticized NASA for not “estimating the probability of failure of the various elements.” Further, in January 1988, the Post-Challenger investigation recommended that “probabilistic risk assessment approaches be applied to the Shuttle risk management program." Probabilistic methods are now being used at NASA.
The following projects have all used the SAPHIRE software as the primary analysis tool for risk: PRA for the International Space Station PRA for the Space Shuttle PRA studies in support of nuclear missions PRA for conceptual designs PRA for the Mars Exploration Rover SAPHIRE contains an advanced minimal cut set solving engine. This solver, fine tuned and optimized over time, has a variety of techniques for analysis, including: Extensive use of recursive routines Restructuring and expansion of the logic model Conversion of complemented gates and treatment of success branches Logic pruning due to TRUE or FALSE house events Coalescing gates and the identification of modules and independent sub-trees Intermediate results caching Bit-table Boolean absorptionUse of these and other optimization methods has resulted in SAPHIRE having one of the most powerful analysis engines in use for probabilistic risk assessment today. General basic event probability capabilities for SAPHIRE include: Four different Markov models to represent the failure of a single component A common cause module to determine a group common cause failure probability for groups of up to six redundant components A load-capacity calculation allowing the user to specify a load and capacity distribution to determine P A human reliability analysis calculator to determine a human failure event probability based upon the task type and compounding performance shaping factors The use of template events which allow for failure information to be shared where applicable A seismic fragility method that uses an associated earthquake acceleration level to determine a components failure probability House events to set basic events to logically true or false or to ignore the event A module to determine the loss-of-offsite power frequency and recoverabilitySAPHIRE has been designed to handle large fault trees, where a tree may have up to 64,000 basic events and gates.
To handle the fault trees, two mechanisms for developing and modifying the fault tree are available – a graphical editor and a hierarchical logic editor. Analysts may use either editor. Conversely, if the user modifies the fault tree graphic, SAPHIRE automatically updates the associated logic. Applicable objects available in the fault tree editors include basic events and several gate types, including: OR, AND, NOR, NAND, N-of-M. In addition to these objects, SAPHIRE has a unique feature known as “table events” that allows the u
Event chain methodology
Event chain methodology is a network analysis technique, focused on identifying and managing events and relationship between them that affect project schedules. It is an uncertainty modeling schedule technique. Event chain methodology is an extension of quantitative project risk analysis with Monte Carlo simulations, it is the next advance beyond critical chain project management. Event chain methodology helps to mitigate the effect of motivational and cognitive biases in estimating and scheduling, it improves accuracy of risk assessment and helps to generate more realistic risk adjusted project schedules. Event chain methodology is an extension of traditional Monte Carlo simulation of project schedules where uncertainties in task duration and costs are defined by statistical distribution. For example, task duration can be defined by three point estimates: low and high; the results of analysis is a risk adjusted project schedule, crucial tasks, probabilities that project will be completed on time and on budget.
Defining uncertainties using statistical distribution provide accurate results if there is a reliable historical data about duration and cost of similar tasks in previous projects. Another approach is to define uncertainties using risk events or risk drivers, which can be assigned to different tasks or resources. Information about probabilities and impact of such events is easier to elicit, which improves accuracy of analysis. Risks can be recorded in the Risk register. Event chain methodology was first proposed in the period of 2002-2004, it is or implemented in a number of software application. Event Chain Methodology has a number of outcomes. Activities are not a continuous uniform procedure. Tasks are affected by external events. One of the important properties of an event is the moment when an event occurs during the course of an activity; this moment, when an event occurs, in most cases is probabilistic and can be defined using statistical distribution. The original state is called a ground state, other states are called excited states.
For example, if the team completes their job on activity, they can move to other activities. The notion of an activity's state is important because certain events can or cannot occur when activity is in certain state, it means. Events can be local, affecting particular tasks or resources, or global affecting all tasks or resources. Events can be related to other events; these event chains can affect the course of the project. For example, requirement changes can cause an activity to be delayed. To accelerate the activity, the project manager allocates a resource from another activity, which leads to a missed deadline; this can lead to the failure of the project. It could be different relationship between events. One event can trigger multiple events. Events can be correlated with each other without one triggering another one. In this case if one risk has occurred, another one will occur and vice versa. One event assigned in one activity can execute another group of activities. In many cases it the execution of risk response plans.
For example, event “structural defect is discovered” can cause one or many activities “Repair”. Events can cause other events to occur either or with a delay; the delay is a property of the event subscription. The delay can be deterministic. Risks can be transferred from one activity to another. To define event chains, we need to identify a "sender", the event that initiates the chain of events; the sender event can cause one or more events. These are called "receiver" events. In turn, the receiver events can act as sender events. Event chain diagram is a visualization that shows the relationships between events and tasks and how the events affect each other; the simplest way to represent these chains is to depict them as arrows associated with certain tasks or time intervals on the Gantt chart. Here are a few important rules: Event chains diagrams present events as arrows on the Gantt charts. Arrows pointing down are threats. Arrows pointing up are opportunities. Issues are shown as an arrow within a circle.
Color of the issue arrow is red. Closed or transferred risks are shown using dashed lines. Color of arrow is white. Closed issue is shown in the circle with dashed border line. Excited states are represented by elevating the associated section of the bar on the Gantt chart. Colors represent the calculated impact of the risk. Higher impacts are red or darker shade. Low impacts are green or lighter shade; the size of the arrow represents probability. Event chains are shown as lines connecting arrows depicting events. Event chains may trigger another activity. In this case event chain line will be connected with the beginning of activity with optional arrow. Event chains may trigger a group of activities. In this case this group of activities will be surrounded by the box or frame and event chain line will be connected to the corner of the box or first activity within a frame. By using event chain diagrams to visualize events and event chains, the modeling and analysis of risks and uncertainties can be simplified.
Another tool that can be used to simplify the definition of events is a state table. Columns in the state table represent events. Information for each event in each state includes four properties of event subscription: probability, moment of event, excited state, impact of the event. Once events and event chains are defined, quantitative analy