:: wikimiki.org ::

Project Management

Project management

Project management is the discipline of defining and achieving targets while optimizing the use of resources (time, money, people, materials, energy, space, etc). ---- Project management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and productive mutual interaction of various parties in such a way that overall risk of failure is reduced. Typical projects include the engineering and construction of various objects or consumer products, including buildings, vehicles, or electronic devices. The duration of a project is the time from its start to its completion, which can take days, weeks, months or even years. In contrast to on-going, functional work, a project is "a temporary endeavor undertaken to create a unique product, service,

Approaches

There are several approaches that can be taken to project management, including phased, incremental, and iterative approaches. The "traditional" approach identifies a sequence of steps to be completed. This contrasts with the agile software development approach in which the project is seen as relatively small tasks rather than a complete process. The objective of this approach is to impose as little overhead as possible in the form of rationale, justification, documentation, reporting, meetings, and permission. This approach may also be called the "spiral" approach, since completion of one of the small tasks leads to the beginning of the next. Advanced approaches to agile project management, applicable not only to software development but to any area, utilize the principles of human interaction management to deal with the complexities of human collaboration.

The traditional approach

In the traditional approach, we can distinguish 5 components of a project (4 stages plus control) in the development of a project: #project initiation (Kickoff) #project planning #project production or execution #project monitoring or controlling #project completion Not all projects will visit every stage as projects can be terminated before they reach completion. Some projects probably don't have the planning and/or the monitoring. Some projects will go through steps 2, 3 and 4 multiple times. Many industries utilize variations on these stages. For example, in bricks and mortar architectural design, projects typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. While the names may differ from industry to industry, the actual stages typically follow common steps to problem solving--defining the problem, weighing options, choosing a path, implementation and evaluation. Project management tries to gain control over five variables:
- time - The amount of time required to complete the project. Typically broken down for analytical purposes into the time required to complete the components of the project, which is then further broken down into the time required to complete each task contributing to the completion of each component.
- cost - Calculated from the time variable. Cost to develop an internal project is time multiplied by the cost of the team members involved. When hiring an independant consultant for a project, cost will typically be determined by the consultant or firm's hourly rate multiplied by an estimated time to complete.
- quality - The amount of time put into individual tasks determines the overall quality of the project. Some tasks may require a given amount of time to complete adequately, but given more time could be completed exceptionally. Over the course of a large project, quality can have a significant impact on time and cost (or vice versa).
- scope - Requirements specified for the end result. The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.
- risk - Potential points of failure. Most risks or potential failures can be overcome or resolved, given enough time. Three of these variables can be given by external or internal customers. The value(s) of the remaining variable(s) is/are then set by project management, ideally based on solid estimation techniques. The final values have to be agreed upon in a negotiation process between project management and the customer. Usually, the values in terms of time, cost, quality and scope are contracted. To keep control over the project from the beginning of the project all the way to its natural conclusion, a project manager uses a number of techniques: project planning, earned value, risk management, scheduling, process improvement....

History of project management

Project management was not used as an isolated concept before the Sputnik crisis of the Cold War. After this crisis, the United States Department of Defense needed to speed up the military project process. New tools (models) for achieving this goal were invented. In 1958 they invented the Program Evaluation and Review Technique or PERT, as part of the Polaris missile submarine program. At the same time, the DuPont corporation invented a similar model called CPM, critical path method. PERT was later extended with a work breakdown structure or WBS. The process flow and structure of the military undertakings quickly spread into many private enterprises. There are a number of guiding techniques that have been developed over the years that can be used to formally specify exactly how the project will be managed. These include Project Management Body of Knowledge (PMBOK® Guide), and such ideas as the Personal Software Process (PSP), and the Team Software Process (TSP) and PRINCE2. These techniques attempt to standardize the practices of the development team making them easier to predict and manage as well as track. Critical chain is the latest extension to the traditional critical path method. In critical studies of project management, it has been noted that several of these fundamentally PERT-based models are not well suited for the multi-project company environment of today. Most of them are aimed at very large-scale, one-time, non-routine projects, and nowadays all kinds of management are expressed in terms of projects. Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to cause unnecessary costs and low maneuverability in several cases. Instead project management experts try to identify different "lightweight" models, such as, for example Extreme Programming for software development and Scrum techniques. The generalization of extreme programming to other kinds of projects is extreme project management, which may be used in combination with the process modeling and management principles of human interaction management.

Project Management Activities

Project Management is composed of several different types of activities such as: # Planning the work # Estimating resources # Organizing the work # Acquiring human and material resources # Assigning tasks # Directing activities # Controlling project execution # Reporting progress

Process-based management

Also furthering the concept of project control is the incorporation of process-based management. This area has been driven by the use of Maturity models such as the CMMi (Capability Maturity Model Integration) and ISO/IEC15504 (SPICE - human interaction management]] are founded on a process view of HUMAN collaboration..

Project management standards and professional certification

There have been several attempts to develop project management [[standards, such as:
- ISO 10006:1997, Quality management - Guidelines to quality in project management
- A Guide to the Project Management Body of Knowledge (PMBOK Guide)
- PRINCE2 (Projects IN a Controlled Environment)
- V-Modell (German project management method)
- [http://www1.bcs.org.uk/DocsRepository/00800/899/docs/certsyll.pdf ISEB Project Management Syllabus] See also: [http://www.pmforum.org/prof/matmatrix.htm An exhaustive list of standards (maturity models)] So far, there is no known attempt to develop a project management standard available under the GNU Free Documentation License. There is a proposed [http://www.pacificedge.com/xml/xml.asp Project Management XML Schema].

Case Studies

- Salvage of the Port of Massawa, Eritrea, 1942. The port was a chaotic mess. Access had been blocked with scuttled ships and port facilities had been wrecked. Captain Edward Ellsberg, a US Navy salvage expert, rapidly salvaged scuttled ships for service in the Allied merchant fleets. He also salvaged a large floating dry dock and returned port shops and facilities to operation. Ellsberg had very limited resources and poor administrative support. Ellsberg's efforts show that a project oriented expert can accomplish a nearly insurmountable task. Interestingly, Ellsberg had virtually no support staff and few skilled. He planned and managed the entire project by himself. Ellsberg, an accomplished author, documented this case in Under the Red Sea Sun (New York: Dodd, Mead & Company, 1946). That is a World War II memoir with a difference.
- The Great Escape, 1944. The escape from Stalag Luft III in 1944 is documented in The Great Escape (New York: Norton, 1950) by Paul Brickhill. In this case, a large, highly-decentralized organization worked toward the goal of a mass escape over a long period of time. This shows how an ad hoc group can use diverse talents to accomplish a difficult task under very adverse circumstances. This highly dramatic episode lent itself dramatization in the movie, The Great Escape, in 1963. The Longest Tunnel by Alan Burgess is another excellent account of this event.

External links

- [http://www.projectmanagementcertification.org/ American Academy of Project Management]
- [http://www.ipma.ch/ International Project Management Association]
- [http://www.apm.org.uk/ Association for Project Management]
- [http://www.pmi.org/ The Project Management Institute] Project management Category:Groupware Category:Product Lifecycle Management ja:プロジェクトマネジメント

Project

:For the form of US public housing, see housing projects. For project management software, see: Microsoft Project. For WikiPedia projects, see Wikipedia:WikiProject. A project is a temporary endeavor undertaken to create a unique product or service. Temporary means that the project has an end date. Unique means that the project's end result is different than the results of other functions of the organization. It can also comprise an ambitious plan to define and constrain a future by limiting it to set goals and parameters. The planning, execution and monitoring of major projects sometimes involves setting up a special temporary organization, consisting of a project team and one or more work teams. A project usually needs resources. The word project comes from the Latin word projectum from projicere, "to throw something forwards" which in turn comes from pro-, which denotes something that precedes the action of the next part of the word in time (paralleling the Greek πρό) and jacere, "to throw". The word "project" thus actually originally meant "something that comes before anything else is done". When the word was initially adopted, it referred to a plan of something, not to the act of actually carrying this plan out. Something performed in accordance with a project was called an object. This use of "project" changed in the 1950s when several techniques for project management were introduced: with this advent the word slightly changed meaning to cover both projects and objects. However in certain projects there may still exist so called objects and object leaders, reflecting the older use of the words. One may also think in terms of platonism, where ideas from the realm of ideals are projected onto the physical world. (See: Plato's allegory of the cave.) Particularly liked by Western business, projects can subdivide into sub-projects and spawn an industrial sub-culture of project planning and project management, all oblivious to more holistic developments. Some feel this habit of short-termism has permeated economic planning and personal growth to the detriment of cyclical and multi-cultural world views. Alternatives to project-centric planning include trend-oriented goal-setting and directional planning. However, this view is contentious, and indeed industrial program management and portfolio management represent ways of administering a range of projects to fulfil an over-arching strategy. Notable projects include:
- Manhattan Project: Developed the first nuclear weapon
- Polaris missile project: an ICBM control system
- Human Genome Project: To map the human genome
- Project Apollo: Landing a man on the moon

Compare

: campaign, process, program (management)

External links

- [http://www.sixsigmafirst.com/projectplan.htm Project Planning]
- [http://outsourceking.com/PM/Project-Management-Defined.aspx Project Management Tutorial]
- [http://www.pmkb.com/ Project Management Knowledge Base]

Agile software development

Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies, such as those espoused by the [http://www.agilealliance.com Agile Alliance], a non-profit organization.

Introduction

Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities. Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers." (Customers are the people who define the product. They may be product managers, business analysts, or actual customers.) The bullpen may also include testers, interaction designers, technical writers, and managers. Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined hacking (aka Cowboy coding).

The Agile Manifesto

Agile methodologies are a family of methodologies, not a single approach to software development. In 2001, 17 prominent figures in the field of agile development (then called "light-weight methodologies") came together at the Snowbird ski resort in Utah to discuss the unifying theme of their methodologies. They created the [http://www.agileManifesto.org Agile Manifesto], widely regarded as the canonical definition of agile development. : Manifesto for Agile Software Development : We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: : Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan : That is, while there is value in the items on the right, we value the items on the left more.. : Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas :© 2001, the above authors
this declaration may be freely copied in any form, but only in its entirety through this notice.. The Agile Manifesto is accompanied by the [http://www.agilemanifesto.org/principles.html Principles behind the Agile Manifesto], a complete list of agile principles.

Comparison with other types of methodologies

Agile methods are often characterized as being at the opposite end of a spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum. <--Agile--> <--Iterative--> <--Waterfall--> <----|-------------|----------------|-----> Adaptive Predictive Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

Contrasted with iterative development

Most agile methods share iterative development's emphasis on building releasable software in short time periods. Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox rather than a planned goal.

Contrasted with the waterfall model

Agile development has less in common with the waterfall model. In some eyes the waterfall is discredited, but [http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=110 circa 2005], this model is in common use. The waterfall model is the most predictive of the methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts - requirement specifications, design documents, test plans, code reviews and the like. The waterfall model can result in a substantial integration and testing effort toward the end of the cycle, a time period typically extending from several months to several years. The size and difficulty of this integration and testing effort is one cause of waterfall project failure. Agile methods, in contrast, produce completely developed and tested features (but a very small set subset of the whole) every few weeks or months. The emphasis is on obtaining a crude but executable system early, and continually improving it. Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams, most notably Extreme Programming teams, work on activities simultaneously.

Cowboy coding is not Agile

Another "method" in common use is cowboy coding. Cowboy coding is the absence of a defined method: team members do whatever they feel is right. Agile development's frequent reevaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documents sometimes causes people to confuse it with cowboy coding. Agile teams, however, do follow defined (and often very disciplined and rigorous) processes, distinguishing agile approaches from cowboy coding.

When to use agile methods

Agile development has been widely documented as working well for small (<10 developers) collocated teams. Agile development is particularly indicated for teams facing unpredictable or rapidly changing requirements. While there are experience reports of teams succeeding with agile development outside of these parameters, there are too few experiences reported as of April 2005 to draw firm conclusions. Agile development's applicability to the following scenarios is open to question:
- Large scale development efforts (>20 developers)
- Distributed development efforts (non-collocated teams)
- Mission- and life-critical efforts
- Command-and-control company cultures

Boehm and Turner's risk-based approach

Barry Boehm and Richard Turner, in [1], suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods. The authors suggest that each side of the continuum has its own home ground: Agile home ground:
- Low criticality
- Senior developers
- High requirements change
- Small number of developers
- Culture that thrives on chaos Plan-driven home ground:
- High criticality
- Junior developers
- Low requirements change
- Large number of developers
- Culture that demands order By analyzing the project against these home grounds, the risk of using an agile or plan-driven method can be determined.

History

The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods, as typified by a heavily regulated, regimented, micro-managed use of the waterfall development model. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and contradicted the ways that software engineers actually perform effective work. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development [http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf]. Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird (see "The Agile Manifesto," above) and adopted the name "agile methods." Later, some of these people formed the [http://www.agilealliance.com Agile Alliance], a non-profit organization that promotes agile development. Early agile methods--created prior to 2000--include Scrum (in management), Crystal Clear, Extreme Programming, Adaptive Software Development, and DSDM. Extreme Programming, while it may not have been the first agile method, inarguably established the popularity of agile methods. Extreme Programming was created by Kent Beck in 1996 as a way to rescue the struggling Chrysler Comprehensive Compensation (C3) project. While that project was eventually canceled, the methodology was refined by Ron Jeffries' full-time XP coaching, public discussion on Ward Cunningham's Portland Pattern Repository wiki and further work by Beck, including a book in 2000. [2]. Elements of Extreme Programming appear to be based on Scrum and Ward Cunningham's Episodes pattern language. DSDM is considered the first established agile method throughout Europe.

Agile methodologies

Some of well-known agile software development methodologies include
- Extreme Programming (XP)
- Scrum [http://www.controlchaos.com/]
- Adaptive Software Development (ASD) [http://www.adaptivesd.com/]
- Crystal Clear and Other Crystal Methodologies [http://alistair.cockburn.us/crystal/wiki]
- DSDM [http://na.dsdm.org/]
- Feature Driven Development [http://www.featuredrivendevelopment.com/]
- Lean software development [http://www.poppendieck.com/] Other methodologies include
- Agile documentation
- Agile ICONIX
- Microsoft Solutions Framework (MSF)
- Agile Data [http://www.agiledata.org/]
- Agile Modeling [http://www.agilemodeling.com] Examples of similar concepts beyond the realm of software include
- Lean manufacturing

Criticism

Agile development is sometimes criticised as cowboy coding. Extreme Programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticism, such as McBreen [9] and Boehm and Turner [1]. In particular, Extreme Programming is reviewed and critiqued by Matt Stephens' [http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp Extreme Programming Refactored]. Criticisms include charges that agile development:
- fails to provide an adequate level of structure and necessary documentation
- only works with senior-level developers
- incorporates insufficient software design
- requires too much cultural change to adopt

References

- [1] Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston. 2004.
- [2] Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, Boston. 1999.
- [3] Fowler, Martin. [http://www.martinfowler.com/articles/designDead.html Is Design Dead?]. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
- [4] Riehle, Dirk. [http://www.riehle.org/computer-science/research/2000/xp-2000.html A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other]. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
- [5] Tomek, Ivan. What I Learned Teaching XP. [http://www.whysmalltalk.com/articles/tomek/teachingxp.htm http://www.whysmalltalk.com/articles/tomek/teachingxp.htm]
- [6] M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003.
- [7] D. Rosenberg, M. Stephens. Agile Development with ICONIX Process. Apress L.P., Berkeley, California. 2005.
- [8] Beck, et. al., Manifesto for Agile Software Development. [http://www.agilemanifesto.org/]
- [9] McBreen, P. Questioning Extreme Programming. Addison-Wesley, Boston. 2003.
- [10] Larman, Craig and Basili, Victor R. [http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf Iterative and Incremental Development:A Brief History IEEE Computer, June 2003]

External links

- [http://www.agileManifesto.org Manifesto for Agile Software Development]
- [http://www.agilealliance.com/ The Agile Alliance]
- [http://www.agileplanet.org Agile Planet weblog aggregator]
- Matt Stephens' website [http://www.softwarereality.com/ SoftwareReality.com - a critical eye on agile development]
- [http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=110 "The Demise of the Waterfall Model Is Imminent" and Other Urban Myths]
- [http://csdl.computer.org/comp/mags/so/2003/06/s6040abs.htm. Neill, C. J., and Laplante, P. A. Requirements engineering: the state of the practice. IEEE Software 20, 6 (Nov./Dec. 2003), 40-45; ] Category:Project management Category:Software development category:ISBN needed

Human interaction management

Although the initial focus of Business Process Management (BPM) was on the automation of mechanistic business processes, this has since been extended to include support for human-driven processes focused on human collaborative activity. Building on traditional techniques in which individual steps in the business process (which require human knowledge, judgment or experience to be performed) are assigned to the appropriate members of an organization via workflow systems. A more advanced form of process management supports the complex interaction between human workers necessary to carry out more sophisticated and/or large-scale tasks. An emerging methodology known as Human Interaction Management, and corresponding class of BPM software known as the Human Interaction Management System, is used to support and monitor tasks as well as to permit the ongoing process definition and redefinition during operation that is endemic to such activity.

The 2 Types Of Process

Mechanistic processes are different from human-driven processes:
- Mechanistic
- Routinized
- Human involvement limited to key points
- Semi- or fully-automated
- Human-driven
- Involve innovation
- Depend on interaction
- Dynamically shaped by the participants

Example Processes Of The 2 Types

- Mechanistic
- Compliance testing
- Facilities construction
- New product release
- Component sourcing
- Assembly line
- Logistics
- Invoicing
- Settlement
- Returns
- Stock level maintenance
- Purchase order approval
- Payroll
- Stock trading
- Human-driven
- Research
- Product design, and Product Lifecycle Management (PLM) generally
- Business system support
- Marketing
- Company merger/divestment
- Auditing
- Healthcare
- Controlling an epidemic
- Government policy implementation
- Political/social negotiation
- Natural disaster prevention/handling
- Election campaign management
- Crime solving
- Legal action
- Military action
- Building restoration

Web Resources

[http://www.human-interaction-management.info Books, articles and white papers on Human Interaction Management]

References

Keith Harrison-Broninski. Human Interactions: The Heart and Soul of Business Process Management. ISBN 0929652444 Business Process Management Group In Search Of BPM Excellence: Straight From The Thought Leaders. ISBN 0929652401 Category:Business terms

Kickoff

A kick-off (or kickoff) is a method of starting and restarting play in a number of sports, including:
- Association football (soccer)
- American and Canadian football
- Rugby football By derivation kick-off also means the commencement of a project or an event, as if the project was like a football match and when the ball got kicked off the match started. ja:キックオフ

Project planning

Project planning within project management is the process to quantify the amount of time and budget a project will cost. The purpose of project planning is to create a project plan that a project manager can use to track the progress of his team. The [http://csdl.computer.org/comp/mags/so/2001/05/s5toc.htm September/October 2001 issue of IEEE Software] lists the Nine Deadly Sins of Project Planning: # Not planning at all # Failing to account for all project activities # Failure to plan for risk # Using the same plan for every project # Applying prepackaged plans indiscriminately # Allowing a plan to diverge from project reality # Planning in too much detail too soon # Planning to catch up later # Not learning from past planning sins

Read further

- [http://www.c2.com/cgi/wiki?PlanningGame The planning game]

External links

- [http://www.ipma.ch/ International Project Management Association]
- [http://www.pmkb.com/ Project Management Knowledge Base]
- [http://www.projectkickstart.com/ Popular Project Planning Software]
- [http://www.planningengineers.org/ Planning Engineers Organization] Category:Project management th:การวางแผนโครงการ

Quality

Quality refers to the inherent or distinctive characteristics or properties of a person, object, process or other thing. Such characteristics may enhance a subject's distinctiveness, or may denote some degree of achievement or excellence. When used in relation to people, the term may also signify a personal character or trait. The term is sometimes contrasted with the concept of quantity. In science, the work of Aristotle focused on measuring quality, whereas the work of Galileo resulted in a shift towards the study of quantity. Quality can be used as a tool of measurement, like metric or fahrenheit, as it is used to judge both subjects that are esteemed as credible and agreeable as "high quality" and subjects that are viewed as confusing, offensive, unhelpful, or incredible as "low quality." But quality is also used as a positive word, as in the sense of "this is a quality chair." Its antonym can be perceived as poorness, incredibility, unhelpfulness, and a variety of other words that reflect the concept of having low quality. ISO 9000 defines quality as "degree to which a set of inherent characteristic fulfils requirements".

In manufacturing

In manufacturing, "quality" means on target with minimum variation. Many different techniques and concepts have been tried to minimize defects in products, including SPC, Zero Defects, Six Sigma, quality circles, TQM and continuous improvement. Most of these techniques and concepts are controversial to one degree or another, since there are two opposing schools of thought with regard to quality. One school subscribes to a statistical approach to quality, measuring variation and then taking corrective action. The other school subscribes to a more organic approach, arguing that one should "design in quality" rather than trying to "test in quality".

Historical development of the concept

The meaning for the term quality has developed over time. Five distinctive interpretations: # "Conformance to specifications" (Phil Crosby in the 1980s). The difficulty with this is that the specifications may not be what the customer wants; Crosby treats this as a separate problem. # "Fitness for use" (Joseph M. Juran). Fitness is defined by the customer. # A two-dimensional model of quality (Noriaki Kano and others). The quality has two dimensions: "must-be quality" and "attractive quality". The former is near to the "fitness for use" and the latter is what the customer would love, but has not yet thought about. Supporters characterise this model more succinctly as: "Products and services that meet or exceed customers' expectations". One writer believes (without citation) that this is today the most used interpretation for the term quality. # "Value to some person" (Gerald M. Weinberg) # (W. Edwards Deming), "Quality is pride of workmanship." See http://www.deming.org/

In music

In music quality refers primarily to the timbre, but also dynamics and musical texture, of a section or piece.

In phonetics

In phonetics quality refers to the articulatory features that distinguish vowels and to their acoustic correspondent. Vowel quality is opposed to vowel quantity.

Finding related topics

- list of economics topics
- list of information technology management topics
- list of production topics Category:Production and manufacturing Category:Product management category:Management Category:Services management and marketing category:Marketing

External links

- [http://www.qualitytimes.co.in/ Basic information on Quality]

Risk

:This article is about the concept of risk. There is also a popular board game named Risk (game), and Risk (album). Risk is the potential harm that may arise from some present process or from some future event. In everyday usage, "risk" is often used synonymously with "probability", but in professional risk assessments, risk combines the probability of a negative event occurring with how harmful that event would be.

Definitions

Risk is often mapped to the probability of some event which is seen as undesirable. Usually the probability of that event and some assessment of its expected harm must be combined into a believable scenario (an outcome) which combines the set of risk, regret and reward probabilities into an expected value for that outcome. There are many informal methods which are used to assess (or to "measure" although it is not usually possible to directly measure) risk, and (for some applications) formal methods such as value at risk. In scenario analysis "risk" is distinct from "threat." A threat is a very low-probability but serious event - which some analysts may be unable to assign a probability in a risk assessment because it has never occurred, and for which no effective preventive measure (a step taken to reduce the probability or impact of a possible future event) is available. The difference is most clearly illustrated by the precautionary principle which seeks to reduce threat by requiring it to be reduced to a set of well-defined risks before an action, project, innovation or experiment is allowed to proceed. In information security a "risk" is defined as a function of three variables: the probability that there's a threat, the probability that there are any vulnerabilities, and the potential impact. If any of these variables approaches zero, the overall risk approaches zero. For example, human beings are completely vulnerable to the threat of mind control by aliens, which would have a fairly serious impact. But as we haven't yet met aliens, we can assume that they don't pose much of a threat, and the overall risk is almost zero.

Background

Scenario analysis matured during Cold War confrontations between major powers, notably the USA and USSR, but was not widespread in insurance circles until the 1970s when major oil tanker disasters forced a more comprehensive foresight. It entered finance until the 1980s when financial derivatives proliferated. It did not reach most professions in general until the 1990s when personal computers proliferated. Governments are apparently only now learning to use sophisticated risk methods, most obviously to set standards for environmental regulation, e.g. "pathway analysis" as practiced by the US EPA.

Risk in business

See also insurance industry Means of measuring and assessing risk vary widely across different professions--indeed, means of doing so may define different professions, e.g. a doctor manages medical risk, a civil engineer manages risk of structural failure, etc. A professional code of ethics is usually focused on risk assessment and mitigation (by the professional on behalf of client, public, society or life in general).

Risk-sensitive industries

Some industries manage risk in a highly-quantified and numerate way. These include the nuclear power and aircraft industries, where the possible failure of a complex series of engineered systems could result in highly undesirable outcomes. The usual measure of risk for a class of events is then Risk = Probability (of the Event) times Consequence. (The total risk is then the sum of the individual class-risks) The risks are evaluated using Fault Tree/Event Tree techniques (see safety engineering). Where these risks are low they are normally considered to be 'Broadly Acceptable'. A higher level of risk (typically up to 10 to 100 times BA) has to be justified against the costs of reducing it further and the possible benefits that make it tolerable - these risks are described as 'Tolerable if ALARP'. Risks beyond this level are of course 'Intolerable'. The level of risk deemed 'Broadly Acceptable' has been considered by Regulatory bodies in various countries - an early attempt by UK government regulator & academic F. R. Farmer used the example of hill-walking and similar activities which have definable risks that people appear to find acceptable. This resulted in the so-called Farmer Curve, of acceptable probability of an event versus its consequence. The technique as a whole is usually refered to as Probabilistic Risk Assessment (PRA), (or Probabilistic Safety Assessment, PSA). See WASH-1400 for an example of this approach.

Risk in finance

Risk in finance has no one definition, but some theorists, notably Ron Dembo, have defined quite general methods to assess risk as an expected after-the-fact level of regret. Such methods have been uniquely successful in limiting interest rate risk in financial markets. Financial markets are considered to be a proving ground for general methods of risk assessment. However, these methods are also hard to understand. The mathematical difficulties interfere with other social goods such as disclosure, valuation and transparency. In particular, it is often difficult to tell if such financial instruments are "hedging" (decreasing measurable risk by giving up certain windfall gains) or "gambling" (increasing measurable risk and exposing the investor to catastrophic loss in pursuit of very high windfalls that increase expected value). As regret measures rarely reflect actual human risk-aversion, it is difficult to determine if the outcomes of such transactions will be satisfactory. Risk seeking describes an individual who has a positive second derivative of his/her utility function. Such an individual would willingly (actually pay a premium to) assume all risk in the economy and is hence not likely to exist. In financial markets one may need to measure credit risk, information timing and source risk, probability model risk, and legal risk if there are regulatory or civil actions taken as a result of some "investor's regret".

Psychology of risk

Main articles: decision theory, prospect theory

Regret

Main article: regret theory In decision theory, regret (and anticipation of regret) can play a significant part in decision-making, distinct from risk aversion (preferring the status quo in case one gets worse off).

Framing

Framing is a fundamental problem with all forms of risk assessment. In particular, because of bounded rationality (our brains get overloaded, so we take mental shortcuts) the risk of extreme events is discounted because the probability is too low to evaluate intuitively. As an example, one of the leading causes of death is road accidents caused by speeding - partly because any given driver frames the problem by largely or totally ignoring the risk of a serious or fatal accident. The above examples: body, threat, price of life, professional ethics and regret show that the risk adjustor or assessor often faces serious conflict of interest. The assessor also faces cognitive bias and cultural bias, and cannot always be trusted to avoid all moral hazards. This represents a risk in itself, which grows as the assessor is less like the client. For instance, an extremely disturbing event that all participants wish not to happen again may be ignored in analysis despite the fact it has occurred and has a nonzero probability. Or, an event that everyone agrees is inevitable may be ruled out of analysis due to greed or an unwillingness to admit that it is believed to be inevitable. These human tendencies to error and wishful thinking often affect even the most rigorous applications of the scientific method and are a major concern of the philosophy of science. But all decision-making under uncertainty must consider cognitive bias, cultural bias, and notational bias: No group of people assessing risk is immune to "groupthink": acceptance of obviously-wrong answers simply because it is socially painful to disagree. One effective way to solve framing problems in risk assessment or measurement (although some argue that risk cannot be measured, only assessed) is to ensure that scenarios, as a strict rule, must include unpopular and perhaps unbelievable (to the group) high-impact low-probability "threat" and/or "vision" events. This permits participants in risk assessment to raise others' fears or personal ideals by way of completeness, without others concluding that they have done so for any reason other than satisfying this formal requirement. For example, an intelligence analyst with a scenario for an attack by hijacking might have been able to insert mitigation for this threat into the U.S. budget. It would be admitted as a formal risk with a nominal low probability. This would permit coping with threats even though the threats were dismissed by the analyst's superiors. Even small investments in diligence on this matter might have disrupted or prevented the attack-- or at least "hedged" against the risk that an Administration might be mistaken.

Fear as intuitive risk assessment?

For the time being, we must rely on our own fear and hesitation to keep us out of the most profoundly unknown circumstances. In "The Gift of Fear", Gavin de Becker argues that "True fear is a gift." (from book jacket) "It is a survival signal that sounds only in the presence of danger. Yet unwarranted fear has assumed a power over us that it holds over no other creature on Earth. It need not be this way." Risk could be said to be the way we collectively measure and share this "true fear" - a fusion of rational doubt, irrational fear, and a set of unquantified biases from our own experience. The field of behavioral finance focuses on human risk-aversion, asymmetric regret, and other ways that human financial behavior varies from what analysts call "rational". Risk in that case is the degree of uncertainty associated with a return on an asset. A recognition of, and respect for, the irrational influences on our decisions, may go far in itself to reduce disasters due to naive risk assessments that pretend to rationality but in fact merely fuse many shared biases together.

Two widely used antidotes for high risk

#Diversification: #
- Investing in more than one potential innovation lowers risk #Multiple approaches: #
- Pursue two or more possible paths to a single innovation simultaneously #
- Can only have one winner #
- Reduces risk but costs more (may reduce expected return)

References

Papers

- Holton, Glyn A. (2004). [http://www.riskexpertise.com/papers/risk.pdf Defining Risk], Financial Analysts Journal, 60 (6), 19–25. A paper exploring the foundations of risk. (PDF file)

Books

A good example for a risk-controlling, yet utopian civilisation was written by Ian M. Banks in his science fiction Culture novels.

Magazines

- [http://www.riskandinsurance.com/ Risk and Insurance : Home]
- [http://www.actuary.net/ Actuary .NET Actuarial News and Risk Management Info: Home]
- [http://www.actuarialnews.org/ Actuarial News And Risk Management Resource : Home]

External links

- [http://www.risk-glossary.com/ Glossary]
- [http://www-groups.dcs.st-and.ac.uk/~history/Quotations/Whitehead.html Whitehead quotations]
- [http://www.gametheory.net/Mike/applets/Risk/ Certainty equivalents applet] Category:Core issues in ethics Category:Risk ja:リスク th:ความเสี่ยง

Earned value management

Earned value management is a project management technique for estimating how a project is doing in terms of its budget and schedule. Earned value compares the work finished so far with the estimates made in the beginning of the project. This gives a measure of how far the project is from completion. By extrapolating from the amount of work already put into the project, the project manager can get an estimate on how much resources the project will have used at completion. This technique is based on the critical path concept. An alternative project performance measurement and management technique is critical chain, which utilizes buffer management instead. The reason is that the earned value management method does not distinguish between the progress on the project constraint (i.e. its critical chain) from progress on the non-constraints (i.e. other paths in the project network). This can sometimes lead the project manager to expedite non-critical work at the expense of critical work in pursuit of better earned value measures, resulting in delayed project completion. This is a case of local optimization, resulting from a lack of subordination of local measures to global measures. To apply earned value to a project, the project manager needs the following primary data:
- a work breakdown structure (WBS): a list of all tasks broken down in a hierarchical structure
- project master schedule (PMS): a Gantt chart of what task will be done when and by whom
- budgeted cost of work scheduled (BCWS) or planned value (PV): for every period the budgets of the tasks that were planned to be finished in this time unit
- budgeted cost of work produced (BCWP) or earned value (EV): for every period the budgets of the tasks that actually finished in this time unit
- actual cost (AC) of work produced (ACWP) or effort spent: for every period the actual costs of the work
- budget at completion (BAC): ∑BCWS, the total budget estimated to be spent to complete the project
- total funding available (TFA): the budget the client has committed to
- negotiated period of performance (NPOP): the time period the client has agreed upon with the project manager
- planned period of performance (PPOP): the time period thought required to finish the project
- cost accrual ratio (CAR): the total average cost per person per time unit
- forecast of remaining work (FCST) or current schedule: the work that still needs to be done after this time unit From these data, the project manager can calculate: ; the cost variance (CV) :

\beginCV & = & BCWP - ACWP \\ \ & = & EV - AC \end

, greater than 0 is good ; the schedule variance (SV) :

\beginSV & = & BCWP - BCWS \\ \ & = & EV - PV \end

, greater than 0 is good ; the cost performance index (CPI) :

CPI  =

: < 1 means that the cost of completing the work is higher than planned (bad), equal to 1 means that the cost of completing the work is right on plan (good), and greater than 1 means that the cost of completing the work is less than planned (good or sometimes bad.) Having a CPI that is very high (in some cases, very high is only 1.2) may mean that the plan was too conservative, and thus a very high number may in fact not be good, since the CPI is being measured against a poor baseline. Management or the customer may be upset with the planners since an overly conservative baseline does not free up available funds for other purposes, and the baseline is also used for manpower planning. ; the schedule performance index (SPI) :

SPI =

, greater than 1 is good : or :

SPI =

; the estimate at completion (EAC) :

EAC = \sum ACWP +

, an estimate of the budget spent at the end of the project : or :

EAC = \sum AC +

External links

- [http://www.acq.osd.mil/pm Earned value management website] Category:Project management Category:Management Category:Production and manufacturing ja:アーンド・バリュー・マネジメント

Risk management

:For non-business risks, see Risk or the disambiguation page risk analysis. Generally, Risk Management is the process of measuring, or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management, which is discussed here, focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments. Regardless of the type of risk management, all large corporations have risk management teams and small groups and corporations practice informal, if not formal, risk management. In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later. In practice the process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss vs. a risk with high loss but lower probability of occurrence can often be mishandled. Risk management also faces a difficulty in allocating resources properly. This is the idea of opportunity cost. Resources spent on risk management could be instead spent on more profitable activities. Again, ideal risk management spends the least amount of resources in the process while reducing the negative effects of risks as much as possible.

Steps in the risk management process

A definitive generic description of risk management that originated in Australia and New Zealand, now being taken up in many other countries, is set out in the Australian & New Zealand STandard 4360:2004. The core of the process is a series of five steps: - Establish the context - Identify risks - Analyse risks - Evaluate risks - Treat risks In parallel with the core process, communication & consultation is required to ensure adequate information is provided and conclusions are disemminated,. Monitoring and review is an intrinsic part of the process required to ensure that the process is executed in a timely fashion and the identification, analysis, evaluation and treatment are kept up to date. The standard can be found at www.standards.com.au and simple guidance on its application can bbe found at www.broadleaf.com.au/tutorials/Default.htm

Establish the context

Establishing the context includes planning the remainder of the process and mapping out the scope of the exercise, the identity and objectives of stakeholders, the basis upon which risks will be evaluated and defining a framework for the process, and agenda for identification and analysis.

Identification

After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, will cause problems. Hence, risk identification can start with the source of problems, or with the problem itself.
- Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport.
- Problem analysis Risks are related to fear. For example: the fear of losing money, the fear of abuse of privacy information or the fear of accidents and casualties. The fear may exist with various entities, most important with shareholder, customers and legislative bodies such as the government. When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a B747 during takeoff may make all people onboard immediate casualties. The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are:
- Objectives-based Risk Identification Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk. Objective-based risk identification is at the basis of COSO's [http://www.coso.org/Publications/ERM/COSO_ERM_ExecutiveSummary.pdf Enterprise Risk Management - Integrated Framework]
- Scenario-based Risk Identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk.
- Taxonomy-based Risk Identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks. Taxonomy-based risk identification in software industry can be found in [http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html CMU/SEI-93-TR-6].
- Common-risk Checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation. An example of known risks in the software industry is the Common Vulnerability and Exposures list found at http://cve.mitre.org.

Assessment

Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan.

Potential Risk Treatments

Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories: (Dorfman, 1997)
- Transfer
- Avoidance
- Reduction (aka Mitigation)
- Acceptance (aka Retention) Ideal use of these strategies may not be possible. Some of them may involve trade offs that are not acceptable to the organization or person making the risk management decisions.

Risk avoidance

Includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Another would be not flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning the profits.

Risk reduction

Involves methods that reduce the severity of the loss. Examples include sprinklers designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy. Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in increments, software projects can limit effort wasted to a single increment. A current trend in software development, spearheaded by the Extreme Programming community, is to reduce the size of increments to the smallest size possible, sometimes as little as one week is allocated to an increment.

Risk retention

Involves accepting the loss when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much.

Risk transfer

Means causing another party to accept the risk, typically by contract or by hedging. Insurance is one type of risk transfer that uses contracts. Other times it may involve contract language that transfers a risk to another party without the payment of an insurance premium. Liability among construction or other contractors is very often transferred this way. On the other hand, taking offsetting positions in derivatives is typically how firms use hedging to financial risk management: financially manage risk. Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group.

Create the plan

Decide on the combination of methods to be used for each risk

Implementation

Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be yes... avoided without sacrificing the entity's goals, reduce others, and retain the rest.

Review and evaluation of the plan

Initial risk management plans will never be perfect. Practice, experience, and actual loss results, will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.

Limitations

If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur, but if the risk is unlikely enough to occur, it may be better to simply retain the risk, and deal with the result if the loss does in fact occur. Prioritizing too highly the Risk management processes itself could potentially keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete.

Areas of risk management

As applied to corporate finance, risk management is a technique for measuring, monitoring and controlling the financial or operational risk on a firm's balance sheet. See value at risk.

Enterprise Risk Management

In Enterprise Risk Management, a risk is defined as a possible event or circumstance that can have negative influences on the Enterprise in question. Its impact can be on the very existance, the resources (human and capital), the products and services, or the customers of the Enterprise, as well as external impacts on Society, Markets or the Environment. ((Author's Note Amazingly whenever Risk is considered this is often the last Risk to be formally evaluated with such things as Project Risk receiving much higher attention??))

Project management

In project management, a risk is more narrowly defined as a possible event or circumstance that can have negative influences on a project. Its influence can be on the schedule, the resources, the scope and/or the quality. In project management parlance, when a risk escalates, it becomes a liability. A liability is a negative event or circumstance that is hindering the project. Some of the processes for assessing risk include the following (the parentheses contain some of the jargon used to refer to them).
- Choosing unique identifiers for referring to the same risk in company or project documents (identification).
- Describing the risk and how it could become a liability (description).
- Assessing the consequences of that (effect).
- Considering what precautions could be taken to prevent it (precaution).
- Drawing up contingency plans or procedures for handling it (contingency).
- Categorizing the risk as new, ongoing or closed (risk status)
- Estimating the probability of the risk becoming a liability (Risk escalation probability, P)
- Estimating the consequences in terms of time for the project (Schedule impact, S) In addition, every probable risk can have a pre-formulated plan to deal with it to deal with its possible consequences (to ensure contingency if the risk becomes a liability). From the information above and the average cost per employee over time, or Cost Accrual Ratio, a project manager can estimate
- the cost associated with the risk if it arises, estimated by multiplying employee costs per unit time by the estimated time lost (cost impact, C where C = Cost Accrual Ratio
- S)
- the probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs = P
- S):
- Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest risks to the project to be attempted first so that risk is minimized as quickly as possible.
- This is slightly misleading as schedule variances with a large P and small S and visa-versa are not equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the wrong time).
- the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P
- C = P
- CAR
- S = P
- S
- CAR)
- sorting on this value puts the highest risks to the budget first.
- see concerns about schedule variance as this is a function of it, as illustrated in the equation above. Risk in a project or process can be due either to special causes of deviation or common causes of deviation and requires appropriate treatment. That is to re-iterate the concern about extremal cases not being equivalent in the list immediately above.

Risk management activities as applied to project management

In project management, risk management includes the following activities:
- Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget.
- Assigning risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
- Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally risk can have assigned person responsible for its resolution and date till then risk still can be resolved.
- Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project.
- Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled – what, when, by who and how will be done to avoid it or minimize consequences if it becomes a liability.
- Summarizing planned and faced risks, effectiveness of mitigation activities and effort spend for the risk management.

References

-
-
-

External links

Risk Management Certification programs

- [http://www.prmia.org/certification/candidate_info.html The Professional Risk Manager Certification (PRM)]
- [http://www.aicpcu.org/flyers/arm.htm IIA & CPCU Associate in Risk Management Certification (ARM)]
- [http://www.rmahq.org/RMA/KnowledgeandTrainingCenter/AssessmentCenter/Certification/ RMA Certification]
- [http://www.garp.com/ GARP Certification]
- [http://www.bai.org/crp/ BAI Certified Risk Professional]
- [http://www.theiia.org/?doc_id=31 IIA Certification in Control Self-Assessment]

Associations

- International Risk Governance Council
- [http://www.prmia.org/ The Professional Risk Managers' International Association (PRMIA)] (http://www.prmia.org/)
- [http://www.ashrm.org/ The American Society for Healthcare Risk Management (ASHRM)]
- [http://www.theirm.org The Institute of Risk Management (IRM)] Category:Management Category:Project management category:Risk Category:Security ja:リスクマネジメント th:การจัดการความเสี่ยง

Scheduling

Scheduling is the process of assigning tasks to a set of resources. It is an important concept in many areas such as computing and production processes. In mathematical terms, a scheduling problem is often solved as an optimization problem, with the objective of maximizing a measure of schedule quality. For example, an airline might wish to minimize the number of airport gates required for its aircraft in order to reduce its operating costs. Scheduling is important in modern production and chemical industries, where it can have a major impact on the productivity of a process. Common objectives in this type of scheduling are to minimize the makespan (duration) of production or to maximize total profit for a given set of customer demands. Modern computerised scheduling tools greatly outperform the manual (heuristic) scheduling methods commonly employed in the industry. Companies use backward and forward scheduling to plan their human and material resources. Backward scheduling is planning the tasks from the due date to detemine the start date and forward scheduling is planning the tasks from the start date to determine the shipping date or the due date. It is a key concept in multitasking and multiprocessing operating system design, and in real-time operating system design. It refers to the way processes are assigned priorities in a priority queue. This assignment is carried out by software known as a scheduler. In general-purpose operating systems, the goal of the scheduler is to balance processor loads, and prevent any one process from either monopolizing the processor or being starved for resources. In real-time environments, such as devices for automatic control in industry (for example robotics), the scheduler also must ensure that processes can meet deadlines; this is crucial for keeping the system stable. Many scheduling problems are NP-hard and finding efficient ways of solving larger scheduling problems is an active research area. Common mathematical techniques used to solve scheduling problems are Mixed Integer Linear Programming, Logical programming and Constraint programming.

Common scheduling practices

- Round-robin scheduling (RR)
- Shortest job next (SJN)
- Shortest remaining time (SRT)
- Weighted round-robin scheduling
- Rate-monotonic scheduling (RMS)
- Deadline-monotonic scheduling (DMS)
- Earliest deadline first scheduling (EDF)
- Two-level scheduling
- FIFO
- LIFO
- Fair-share scheduling
- Least slack time scheduling (LST)
- Multilevel Feedback Queue
- 'Take' scheduling
- Gang scheduling
- Least-connection scheduling
- Weighted least-connection scheduling
- Shortest expected delay scheduling
- Never queue scheduling
- List scheduling
- Genetic Anticipatory
- Lottery Scheduling
- Critical Path Method of Scheduling

Disk arm scheduling

- Shortest seek first
- Elevator algorithm

Sputnik crisis

The Sputnik crisis was a turning point of the Cold War that began on October 4, 1957 when the Soviet Union launched the Sputnik 1 satellite. The USA had believed itself to be the leader of space technology and thus a leader of missile development. The surprise Sputnik launch and the failure of the first two U.S. launch attempts proved it was not so. After this, the Space Race began, leading up to Project Apollo and the moon landings in 1969, which eventually ended the Sputnik crisis. The Sputnik crisis spurred a whole chain of U.S. initiatives, from large to small, many of them initiated by the Department of Defense.
- Within 2 days, calculation of the Sputnik Orbit (joint work by UIUC Astronomy Dept. and Digital Computer Lab.)
- Entering Space Race, as mentioned, including the creation of NASA in 1958 and Project Mercury.
- Education programs initiated to foster a new generation of engineers. One of the more remarkable and remembered things that came out of this was the concept of "New Math".
- Dramatically increased support for scientific research. For 1959, Congress increased the National Science Foundation appropriation to $134 million, almost $100 million higher than the year before. By 1968, the NSF budget would stand at nearly $500 million.
- The Polaris missile program.
- Project management as an area of inquiry and an object of much scrutiny, leading up to the modern concept of project management and standardized project models such as the DoD Program Evaluation and Review Technique, PERT, invented for Polaris.
- The decision by President Kennedy, who campaigned in 1960 on closing the "missile gap", to deploy 1000 Minuteman missiles, far more ICBMs than the Soviets had at the time.
- At The Pentagon's Defense Advanced Research Projects Agency initiated, in 1969, a computer network project called ARPANET, which would later turn into the Internet. Category:Cold War Category:Sputnik programme

1958

1958 (MCMLVIII) was a common year starting on Wednesday of the Gregorian calendar.

Events

January

- January 1 - Treaty of Rome founding the EU is implemented
- January 4 - Sputnik 1 falls to Earth from its orbit (launched on October 4 1957)
- January 8 - 14 year old Bobby Fischer wins the United States Chess Championship
- January 13 - 9235 scientists publish a plea to stop nuclear bomb tests
- January 18 - Armed Lumbee Native Americans chase off an estimated 5,000 Klansmen and supporters at the town of Maxton, North Carolina.
- January 23 - Following a two-day general strike, dictator Marcos Pérez Jiménez was overthrown by a militar-popular uprising.
- January 28 - Charles Starkweather and Caril Ann Fugate begin their murder spree with the killings of her parents and infant sister
- January 29 - Police capture Charles Starkweather in Wyoming
- January 31 - The first successful American satellite, Explorer I, is launched into orbit
- January 31 - James Van Allen discovers the Van Allen radiation belt

February

- February 1 - Egypt and Syria unite to form the United Arab Republic
- February 5 - Gamel Abdel Nasser is nominated to be the first president of the United Arab Republic
- February 6 - Munich air disaster - 21 dead, including 7 players for Manchester United
- February 11 - Marshal Chen Yi succeeds Zhou Enlai as Chinese Minister of Foreign affairs.
- February 11 - Ruth Carol Taylor is 1st African American woman hired as a flight attendant
- February 17 - Pope Pius XII declares Saint Clare the patron saint of television
- February 20 - Test rocket explodes in Cape Canaveral
- February 23 - Cuban rebels kidnap 5-time world driving champion Juan Manuel Fangio. They release him 28 hours later
- February 23 - Arturo Frondizi wins presidential elections in Argentina
- February 24 - In Cuba, Radio Rebelde, radio of rebels of Fidel Castro, begins broadcasting from Sierra Maestra
- February 25 - Bertrand Russell launches the Campaign for Nuclear Disarmament
- February 28 - One of the worst school bus accidents in U.S. history occurred at Prestonsburg, Kentucky, killing 27.

March-April

- March 1 - Samuel Alphonsus Stritch, ninth bishop (fourth archbishop) of the Roman Catholic diocese of Chicago, appointed Pro-Perfect of the Propagaion of Faith and thus becomes the first American member of the Roman Curia
- March 2 - A British team led by Sir Vivian Fuchs completes the first crossing of the Antarctic in Snow-cat caterpillar tractors and dogsled teams in 99 days
- March 8 - USS Wisconsin is decomissioned, leaving the United States Navy without an active battleship for the first time since 1896.
- March 11 - The US B-47 bomber drops a nuclear bomb in the Mars Bluff, South Carolina
- March 17 - The United States launches the Vanguard 1 satellite
- March 26 - The United States Army launches Explorer III
- March 27 - Nikita Khrushchev becomes Premier of the Soviet Union
- April 3 - Castro's revolutionary army begins its attacks on Havana
- April 4-April 7 - The first protest march for the Campaign for Nuclear Disarmament from Hyde Park, London to Aldermarston, Berkshire. Demonstrators demand ban of nuclear weapons
- April 4 - The daughter of the actress Lana Turner stabs her mother's gangster lover to death (eventually ruled self defence)
- April 6 - Soraya Esfandiary Bakhtiari divorces the Shah of Iran, Mohammad Reza Pahlavi after she is unable to produce any children.
- April 17 - King Baudouin of Belgium officially opens the World Fair in Brussels, also known as Expo '58.

May-June

- May 1 - Arturo Frondizi becomes President of Argentina
- May 2 - A State of Emergency is declared in Aden
- May 12 - A formal North American Aerospace Defense Command agreement is signed between the United States and Canada
- May 13 - During a visit to Caracas, Venezuela, Vice President Richard M. Nixon's car is attacked by anti-American demonstrators
- May 15 - The Soviet Union launches Sputnik 3
- May 16 - Short-lived outburst of friendship between Arabs and Europeans in Algiers
- May 18 - An F-104 Starfighter sets a world speed record of 1,404.19 mph
- May 20 - Batista's government launches counteroffensive against Castro's rebels
- May 21 - United Kingdom Postmaster General Ernest Marples announces that from December, Subscriber Trunk Dialling will be introduced in the Bristol area. [http://news.bbc.co.uk/onthisday/hi/dates/stories/may/21/newsid_2510000/2510289.stm]
- May 23 - Explorer I ceased transmission
- May 30 - The bodies of unidentified soldiers killed in action during World War II and the Korean War are buried at the Tomb of the Unknowns in Arlington National Cemetery.
- June 1 - Charles De Gaulle is brought out of retirement to lead France by decree for six months
- June 1 - Iceland extends its fishing limits to 12 miles
- June 4 - Charles De Gaulle visits Algeria
- June 16 - Imre Nagy is hanged for treason in Hungary
- June 27 - Peronist party becomes legal again in Argentina
- June 29 - Brazil beat Sweden 5-2 to win the 1958 World Cup

July-August

- July 5 - First ascent of Gasherbrum I, 11th highest mountain in the world
- July 7 - President Dwight D. Eisenhower signs the Alaska Statehood Act into United States law
- July 8 - 7.5 Richter scale earthquake in Lituya Bay, Alaska, causes a landslide that produces a huge 520 meter high wave
- July 10 - First parking meters installed in Britain
- July 14 - Iraqi Revolution: In Iraq the monarchy is overthrown by Arab nationalists and Abdul Karim Qassim becomes the nation's new leader
- July 14 - A left wing military coup in Iraq leads to the murder of the king, Faisal II
- July 15 - In Lebanon, 5,000 United States Marines land in the capital Beirut in order to protect the pro-Western government there
- July 17 - British paratroopers arrive in Jordania; king Hussein has asked help against pressure from Iraq
- July 20 - Various rebel groups in Cuba join forces but communists do not join the deal
- July 24 - The first life peerage is created in Britain
- July 26 - Explorer program: Explorer IV is launched
- July 29 - The U.S. Congress formally creates the National Aeronautics and Space Administration (NASA)
- August 3 - The nuclear powered submarine USS Nautilus (SSN-571) became the first vessel to cross the North Pole under water
- August 23 - Chinese Civil War: The Second Taiwan Strait crisis begins with the People's Liberation Army's bombardment of Quemoy.
- August 30-September 1 - Riots between blacks and whites in Notting Hill, London

September-October

- September 14 - Two rockets of the German engineer Ernst Mohr reach as first German post-war rockets the upper atmosphere
- September 27 - Hurricane Vera in Honshu, Japan, kills 615
- September 28 - In France, a majority of 79% says yes to the constitution of the Fifth Republic.
- October 1 - Tunisia and Morocco join the Arab League
- October 1 - NASA starts operations and replaces the NACA
- October 2 - Guinea declares itself independent from France
- October 4 - BOAC uses new Comet jets to become the first airline to fly jet passenger services across the Atlantic.
- October 9 - Pope Pius XII dies.
- October 11 - Pioneer program: NASA launches the lunar probe Pioneer 1 (the probe falls back to Earth and burns up)
- October 24 - Soviet Union loans Egypt 400 million rubles for the Aswan dam
- October 27 - Gen Ayub Khan succeeds Iskander Mirza as president of Pakistan
- October 28 - Boris Pasternak is expelled from soviet author's society
- October 28 - Angelo Giuseppe Roncalli becomes Pope and takes the name Pope John XXIII.

November-December

- November 3 - New UNESCO building inaugurated in Paris
- November 22 - Menzies Government re-elected for a 5th Term
- November 23 - Have Gun, Will Travel debuts on radio
- November 25 - French Sudan gains autonomy as a self-governing member of the French Community
- November 28 - Chad, the Republic of the Congo, and Gabon become autonomous republics within the French Community
- November 30 - Gaullists win parliamentary elections in France
- December 1 - Central African Republic becomes independent from France
- December 5 - Subscriber Trunk Dialling (STD) is inaugurated in the UK by the Queen when she dials a call from Bristol to Edinburgh and speaks to the Lord Provost. [http://www.bt.com/archives/history/19461959.htm#1958]
- December 9 - The John Birch Society is formed in the USA
- December 14 - The 3rd Soviet Antarctic Expedition becomes the first ever to reach The Pole of Relative Inaccessibility
- December 21 - General Charles de Gaulle is elected president of France with 78.5% of the votes.
- December 28 - The Baltimore Colts beat The New York Giants 23-17 in overtime to win The NFL Championship.
- December 29 - Rebel troops under Che Guevara begin to invade Santa Clara in Cuba

unknown date

- The First Cod War between UK and Iceland
- BBC Radiophonic Workshop created
- During the International Geophysical Year, Earth's magnetosphere is discovered
- The United States conducts Operation Argus during August and September
- Foundation of Amirkabir University of Technology
- Based on birth rates (per 1,000 population), the post-war baby boom ended in the United States as an eleven-year decline in the birth rate began - the longest on record in that country
- Last legal female circumcision in the United States.
- Denatonium, the bitterest substance known is discovered. It is used as an aversive agent in products such as bleach to reduce the risk of children drinking them.
- Van Cliburn wins the Tchaikovsky International Piano Competition in the USSR, breaking cold war tensions.
- The Jim Henson Company founded
- Andorra declared peace with Germany, having been forgotten on the Treaty of Versailles and remaining legally at war.

Births

January-March

- January 20 - Lorenzo Lamas, American actor
- January 24 - Jools Holland, British musician
- January 26 - Ellen DeGeneres, American actress and comedienne
- February 4 - Tomasz Pacyński, Polish writer (d. 2005)
- February 11 - Michael Jackson, British broadcast executive
- February 11 - Regina Marsikova, Czechoslovakian tennis player
- February 13 - Pernilla August, Swedish actress
- February 16 - Ice-T, American singer, songwriter, and actor
- February 21 - Mary Chapin Carpenter, American singer
- February 22 - Jake Burns, Irish musician
- February 24 - Sammy Kershaw, American musician
- February 28 - Michael Kennedy, son of Robert F Kennedy and Ethel Kennedy and nephew of John F Kennedy and Robert F Kennedy and Edward M Kennedy (d. 1997)
- March 3 - Miranda Richardson, English actress
- March 4 - Patricia Heaton, American actress
- March 5 - Andy Gibb, English-born singer (d. 1988)
- March 8 - Gary Numan, British singer
- March 10 - Sharon Stone, American actress
- March 14 - Albert II, Prince of Monaco
- March 18 - Kayo Hatta, American film director (d. 2005)
- March 20 - Holly Hunter, American actress
- March 21 - Gary Oldman, English actor

April-August

- April 3 - Alec Baldwin, American actor
- April 10 - Yefim Bronfman, Russian-born pianist
- April 10 - Kenneth "Babyface" Edmonds, American musician and record producer
- April 15 - Benjamin Zephaniah, British writer and musician
- April 21 - Andie MacDowell, American actress
- April 22 - Ken Olandt, American actor
- April 25 - Fish, Scottish singer
- April 28 - Hal Sutton, American golfer
- April 29 - Michelle Pfeiffer, American actress
- May 23 - Mitch Albom, American author
- May 23 - Drew Carey, American comedian and actor
- May 27 - Neil Finn, New Zealand singer and songwriter
- May 28 - Annette Bening, American actress
- June 7 - Prince, American musician
- June 8 - Keenen Ivory Wayans, American comedian, actor, and director
- June 12 - Rebecca Holden, American actress, singer, and entertainer
- June 17 - Jello Biafra, American musician and activist
- June 20 - Chuck Wagner, American actor
- June 27 - Magnus Lindberg, Finnish composer
- June 30 - Esa-Pekka Salonen, Finnish conductor and composer
- July 2 - Thomas Bickerton, American Methodist bishop
- July 7 - Michala Petri, Danish recorder player
- July 15 - Mac Thornberry, American politician
- July 28 - Terry Fox, Canadian athlete and cancer activist (d. 1981)
- July 30 - Kate Bush, British singer and songwriter
- July 31 - Mark Cuban, American entrepreneur and basketball team owner
- August 7 - Bruce Dickinson, English musician
- August 15 - Victor Shenderovich, Russian writer
- August 16 - Madonna, American musician, songwriter, and actress
- August 19 - Anthony Muñoz, American football player
- August 22 - Colm Feore, American-born actor
- August 29 - Michael Jackson, American singer

September-December

- September 10 - Dan Castellaneta, American voice actor
- September 14 - Jeff Crowe, New Zealand cricket captains
- September 16 - Orel Hershiser, baseball player
- September 19 - Azumah Nelson, Ghanaian boxer
- September 22 - Andrea Bocelli, Italian tenor
- September 23 - Marvin Lewis, American football coach
- September 23 - Scott Shaw, Author, Actor, Filmmaker
- October 5 - Bernie Mac, American actor and comedian
- October 13 - Derri Daugherty, American musician (The Choir and The Lost Dogs)
- October 14 - Thomas Dolby, English musician
- October 16 - Tim Robbins, American actor
- October 17 - Alan Jackson, American singer and songwriter
- October 20 - Viggo Mortensen, American actor
- October 27 - Simon Le Bon, English musician (Duran Duran)
- November 2 - Willie McGee, baseball player
- November 18 - Laura Miller, Mayor of Dallas, Texas
- November 22 - Jamie Lee Curtis, American actress
- November 25 - Kim Ashfield, British model
- November 28 - Dave Righetti, baseball player
- November 30 - Juliette Bergmann, Dutch bodybuilder
- December 1 - Charlene Tilton, American actress
- December 6 - Nick Park, English filmmaker and animator
- December 11 - Nikki Sixx, American musician, Motley Crue
- December 25 - Hanford Dixon, American football player
- December 25 - Rickey Henderson, baseball player
- December 31 - Bebe Neuwirth, American actress

Deaths

- January 1 - Edward Weston, American photographer (b. 1886)
- January 8 - Paul Pilgrim, American athlete (b. 1883)
- January 11 - Edna Purviance, American actress (b. 1895)
- January 30 - Jean Crotti, Swiss artist (b. 1878)
- February 1 - Clinton Davisson, American physicist, Nobel Prize laureate (b. 1888)
- February 4 - Henry Kuttner, American author (b. 1915)
- February 13 - Christabel Pankhurst, English suffragette (b. 1880)
- March 21 - Cyril M. Kornbluth, American writer (b. 1923)
- March 22 - Mike Todd, American film producer (b. 1909)
- March 25 - Tom Brown, American musician (b. 1888)
- March 26 - Phil Mead, English cricketer (b. 1887)
- March 28 - W.C. Handy, American composer (b. 1873)
- April 16 - Rosalind Franklin, British crystallographer (b. 1920)
- April 19 - Billy Meredith, Welsh footballer (b. 1874)
- May 3 - Frank Foster, English cricketer (b. 1889)
- May 19 - Ronald Colman, English actor (b. 1891)
- May 29 - Juan Ramón Jiménez, Spanish writer, Nobel Prize laureate (b. 1881)
- June 20 - Kurt Alder, German chemist, Nobel Prize laureate (b. 1902)
- June 26 - George Orton, Canadian athlete (b. 1876)
- June 28 - Alfred Noyes, English poet [b. 1880)
- July 14 - King Faisal II of Iraq (b. 1935)
- August 14 - Frédéric Joliot, French physicist, recipient of the Nobel Prize in Chemistry (b. 1900)
- August 22 - Roger Martin du Gard, French writer, Nobel Prize laureate (b. 1881)
- August 27 - Ernest Lawrence, American physicist, Nobel Prize laureate (b. 1901)
- October 9 - Pope Pius XII (b. 1876)
- October 17 - Charlie Townsend, English cricketer (b. 1876)
- November 24 - Robert Cecil, 1st Viscount Cecil of Chelwood, English politician and diplomat, recipient of the Nobel Peace Prize (b. 1864)
- November 27 - Artur Rodzinski, Croatian conductor (b. 1892)
- December 8 - Tris Speaker, baseball player (b. 1888)
- December 15 - Wolfgang Ernst Pauli, Austrian-born physicist, Nobel Prize laureate (b. 1900)

Nobel Prizes

- Physics - Pavel Alekseyevich Cherenkov, Ilya Mikhailovich Frank, Igor Yevgenyevich Tamm
- Chemistry - Frederick Sanger
- Medicine - George Wells Beadle, Edward Lawrie Tatum, Joshua Lederberg
- Literature - Boris Leonidovich Pasternak
- Peace - Georges Pire

Fields Medalists

- Klaus Roth, Rene Thom
- ko:1958년 ja:1958年 simple:1958 th:พ.ศ. 2501

Program Evaluation and Review Technique

The Program Evaluation and Review Technique commonly abbreviated PERT is a model for project management invented by United States Department of Defense's US Navy Special Projects Office in 1958 as part of the Polaris mobile submarine launched ballistic missile project. This project was a direct response to the Sputnik crisis. PERT is basically a method for analyzing the tasks involved in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. This project model was the first of its kind, a revival for scientific management, founded in Fordism and Taylorism. Though every company now has their own "project model" of some kind, they all resemble PERT in some respect. Only DuPont corporation's critical path method was invented at roughly the same time as PERT. The most famous part of PERT is the "PERT Networks", charts of timelines that interconnect. PERT is intended for very large-scale, one-time, complex, non-routine projects. Each task's estimate in PERT is calculated using the following formula. Three types of estimates need to be done on each task, namely optimistic (O), most likely (M), and pessimistic (P). The estimate would be made as (O+4M+P)/6.

External links

- [http://www.nnh.com/ev/pert2.html The rudaments of PERT]
- [http://www.netmba.com/operations/project/pert more explanation of PERT] Category:Project management category:Production and manufacturing Category:Diagrams

DuPont corporation

:This article is about the DuPont company. For the other uses of DuPont, see Dupont (disambiguation). E.I. du Pont de Nemours and Company was founded in July 1802 as a gun powder mill by Eleuthère Irénée du Pont on Brandywine Creek, near Wilmington, Delaware, USA. DuPont has evolved into the world's second largest chemical company (behind Dow Chemical Company), and in the 20th century led the polymer revolution by developing many highly successful materials such as neoprene, nylon, Corian, Lucite, Teflon, Mylar, Kevlar, M5 fiber, Nomex, and Tyvek. DuPont has also been significantly involved in the refrigerant industry, developing and producing the Freon series and more modern environmentally-friendly refrigerants, and the color industry, creating synthetic pigments and paints like ChromaFlair. The company often gives trademark names to its material products, many of which have become more well-known and commonly used than the generic or chemical word for the material itself.

Corporate governance

Current members of the board of directors of DuPont are: Alain Belda, Richard H. Brown, Curtis Crawford, Louisa Duemling, John T. Dillon, Charles Holliday, Lois Juliber, Masahisa Naitoh, Sean O'Keefe, William Reilly, Rodney Sharp, and Charles Vest.

History

DuPont participated from 1943 in the Manhattan project. In 1999, Chad Holliday, CEO of DuPont, switched the company's focus towards growing DuPont chemicals in green plants instead of processing them from petroleum.

Currently

Today, DuPont is a global science company with 2004 revenues of approximately $28 billion, employs 55,000 people worldwide and is the 66th largest corporation in the United States. DuPont businesses are organized into the following five categories, known as marketing "platforms" - Electronic and Communication Technologies, Performance Materials, Coatings and Color Technologies, Safety and Protection, and Agriculture and Nutrition. In 2004 the company sold its textiles business to Koch Industries, losing some of its most well known brands such as Lycra (Spandex) and Thermolite.

Criticisms

In 1941, an investigation of Standard Oil Co. and IG Farben also brought new evidence concerning complex price and marketing agreements between DuPont, a major investor in and producer of leaded gasoline, U.S. Industrial Alcohol Co. and their subsidiary, Cuba Distilling Co. The investigation was eventually dropped, like dozens of others in many different kinds of industries, due to the need to enlist industry support in the war effort. DuPont is an inventor of CFCs and the largest producer of ozone depleting chemicals in the world. DuPont sells $3 billion in CFCs worldwide. In 1987, Du Pont campaigned against effective controls on the use of CFCs. On April 27, 1992 Du Pont announced that "we will stop selling CFC's as soon as possible," but only in the "US and other developed countries." The chemical industry plans to replace CFCs with a new generation of chemicals, such as HCFCs and HFCs. In June 1999, in West Virginia, the Tennant family sued DuPont for accidentally killing 280 Hereford cows with C-8, a proven animal carcinogen. DuPont was dumping the chemical in a landfill for nonhazardous waste. The chemical leaked into Dry Run Creek, where the cows drank it. The Tennants settled. As part of the settlement, the Tennants were forbidden to discuss the case. The local drinking water was also contaminated with the C-8. Up to 50,000 residents of the mid-Ohio Valley started a class-action lawsuit against DuPont. They claim that DuPont knew that C-8 was in the public water supply since 1984, but never informed the community. DuPont says the amount of C-8 is too low to raise health concerns, and that they met their reporting obligations. The EPA is researching how C-8 has entered the bloodstream of much of the country’s population. Blood-bank samples from across the U.S. are being looked at. This investigation seeks to determine if DuPont violated federal law by not informing the EPA years ago. On May 26, 2003, ammonium perfluorooctanoate or APFO (used to produce Teflon and similar products) was found in groundwater near a North Carolina DuPont plant. The chemical leaked from a cement cistern the company wasn't using. Based on the revelations made by Smedley Butler in 1933, the DuPont corporation has also been implicated in the Business Plot, or The Plot Against FDR. This alleged failed coup attempt was said to be a conspiracy of moneyed interests intended to strip President Franklin D. Roosevelt of his political power as a reaction against the New Deal Some conspiracy theorists surmise that cannabis sativa was made illegal because the fibres from the hemp plant, used for fabrics and ropes, were in strong competition with DuPont's nylon, a newly develloped fiber at the time. Since hemp cannot be used as a drug, but was made illegal along with cannabis sativa, it has been said that the inclusion of cannabis sativa into the same category of substances as heroin was made purposefully in order to destroy the hemp industry, therefore promoting nylon production.

External links

- [http://www.dupont.com/ DuPont homepage]
- [http://biz.yahoo.com/ic/10/10487.html Yahoo! company profile: EI du Pont de Nemours and Company]
- [http://heritage.dupont.com/sitemap.shtml DuPont heritage site] Category:Chemical companies of the United States Category:Companies based in Delaware Category:Fortune 500 companies Category:Companies traded on the New York Stock Exchange ja:デュポン

Critical path

In project management, a critical path is the sequence of project network terminal elements with the longest overall duration, determining the shortest time to complete the project. The duration of the critical path determines the duration of the entire project. Any delay of a terminal element on the critical path directly impacts the planned project completion date (i.e. there is no float on the critical path). A project can have several, parallel critical paths. An additional parallel path through the network with the total durations just shorter than the critical path is called a sub-critical path. Originally, the critical path method considered only logical dependencies among terminal elements. A related concept is the critical chain, which adds resource dependencies. The critical path method was invented by the DuPont corporation.

Work breakdown structure

In project management, a work breakdown structure (WBS) is an exhaustive, hierarchical (from general to specific) tree structure of deliverables and tasks that need to be performed to complete a project. image:wbs.png The purpose of a WBS is to identify terminal elements (the actual items to be done in a project). Therefore, WBS serves as the basis for much of project planning. Work breakdown structure is a very common project management tool. Many United States government statements of work require work breakdown structures.

How to build a WBS

Whether the WBS should be activity-oriented or deliverable-oriented is a subject of much [http://www.maxwideman.com/musings/wbswar.htm discussion]. There are also various approaches to building the WBS for a project (see e.g. How to Build a Work Breakdown Structure below). Project management software, when used properly, can be very helpful in developing a WBS, although in early stages of WBS development, plain sticky notes are the best tool (especially in teams). An example of a work breakdown for painting a room (activity-oriented) is, to state the obvious:
- Prepare materials
- Buy paint
- Buy a ladder
- Buy brushes/rollers
- Buy wallpaper remover
- Prepare room
- Remove old wallpaper
- Remove detachable decorations
- Cover floor with old newspapers
- Cover electrical outlets/switches with tape
- Cover furniture with sheets
- Paint the room
- Clean up the room
- Dispose or store left over paint
- Clean brushes/rollers
- Dispose of old newspapers
- Remove covers The size of the WBS should generally not exceed 100-200 terminal elements (if more terminal elements seem to be required, use subprojects). The WBS should be up to 3-4 levels deep. Each level should be 5-9 elements broad. These suggestions derive from the following facts: # short-term memory capacity is limited to 5-9 items. # having fixed time to plan a project, the more terminal elements there are, the less time there is to pay attention to any single one of them. Consequently, the estimates are less thought-through. # the more terminal elements there are the more there are potential dependencies among them (see fact 2 above for consequences).

Example of a work breakdown structure

dependencies

Books

- Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure. ISBN 1890367125
- Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures. ISBN 1880410818
- Gregory T. Haugan. Effective Work Breakdown Structures (The Project Management Essential Library Series). ISBN 1567261353

External links

- [http://www.acq.osd.mil/pm/currentpolicy/wbs/mil_hdbk_881/mil_hdbk_881.htm US Department of Defence(DoD) Handbook Work Breakdown Structure]
- [http://www.gantthead.com/article.cfm?ID=105776 Taking the work out of WBS] Category:Project management Category:Management category:Production and manufacturing ko:WBS

Personal Software Process

Software professionals use Personal Software Process as a set of guidelines and best practices to incorporate discipline in the software development process. The PSP philosophy is largely based on reviews at every stage of development cycle. Designed by Software Engineering Institute at Carnegie Mellon, PSP has its roots in Capability Maturity Model (CMM).

PRINCE2

PRINCE2, or Projects in a Controlled Environment, is a project management method. It covers the management, control and organisation of a project.

History

PRINCE (Projects in Controlled Environments) is a project management methodology for the organisation, management and control of projects. It was initially developed in 1989 by the Central Computer and Telecommunications Agency (CCTA) as a UK Government standard for information technology (IT) project management; however, it soon became regularly applied outside the purely IT environment. PRINCE2 was released in 1996 as a generic project management method. PRINCE2 has become increasingly popular and is now the de facto standard for project management in the UK. Its use has spread beyond the UK to more than 50 other countries. The most current revision was released in 2002 by the Office for Government Commerce (OGC), which has replaced the CCTA.

Processes

Office for Government Commerce PRINCE2 is a process based approach to project management. It consists of eight high level processes:
- Directing a project (DP)
- Planning (PL)
- Starting up a project (SU)
- Initiating a project (IP)
- Controlling a stage (CS)
- Managing product delivery (MP)
- Managing stage boundaries (SB)
- Closing a project (CP) The processes Starting up a project, Initiating a project and Closing a project are specific phases in a project. Three processes are involved in the implementation phase - Controlling a stage, Managing product delivery and Managing stage boundaries. The process Directing a project applies for the length of the project, while Planning applies for all phases except the final one - Closing a project. A PRINCE2 project must consist of at least two phases, but will typically contain four:
- Starting a project
- Initiating a project
- Implementation
- Closing a project. The implementation phase can be broken up into multiple stages if, as is often the case, it proves sensible.

Starting up a project

The purpose of this process is to set the project up in the right way. It is a pre-project process that ascertains if the project would be worthwhile and viable before seeking commitment of resources. Its major input is the Project Mandate. It involves identifying the senior decision makers required to make up the project board who will oversee the project. The project board selects a project manager. The reasons for the project are outlined in a Project Brief. The project approach is decided, as is the plan for the initiation stage, to give the project a firm foundation. The actual elements of Starting Up a Project are:
- SU1. Appointing a Project Executive and a Project Manager
- SU2. Designing a Project Management Team
- SU3. Appointing a Project Management Team
- SU4. Preparing a Project Brief
- SU5. Defining Project Approach
- SU6. Planning Initiation Stage

Directing a project

This process defines the functions of the Project Board who are responsible for the project. The project manager keeps the Project Board informed with regular reports, who leave the day to day management of the project to the Project Manager. They only become involved at stage boundaries when they must approve progress so far and give the go ahead to the next stage. A fundamental principle of PRINCE2 is management by exception, which means the only other time the Project Board make decisions about the project is when the project is forecast to go off course. The actual elements of Directing a Project are:
- DP1. Authorising Initiation
- DP2. Authorising a Project
- DP3. Authorising a Stage or Exception Plan
- DP4. Giving Ad Hoc Direction
- DP5. Confirming Project Closure

Planning

Planning is a process involved throughout the project's life-cycle. The actual elements of Planning are:
- PL1. Designing a Plan
- PL2. Defining and Analysing Products
- PL3. Identifying Activities and Dependencies
- PL4. Estimating
- PL5. Scheduling
- PL6. Analysing Risks
- PL7. Completing a Plan.

Initiating a project

In order for a project to be approved it must be carefully planned to show how it will meet its goals. This requires making detailed estimations of costs. These go together to create the main product of this process, the PID or Project Initiation Document, which must be approved by the Project Board before implementation can commence. The actual elements of Initiating a Project are:
- IP1. Planning Quality
- IP2. Planning a Project
- IP3. Refining the Business Case and Risks
- IP4. Setting Up Project Controls
- IP5. Setting Up Project Files
- IP6. Assembling a Project Initiation Document (PID)

Controlling a stage

PRINCE2 projects are divided into stages so the project can be more easily managed and controlled. The exact number of stages is not fixed; it depends on the size of the project and the degree of risk. This process covers the day-to-day management of the project by the Project Manager. The actual elements of Controlling a Stage are:
- CS1. Authorising Work Package
- CS2. Assessing Progress
- CS3. Capturing Project Issues
- CS4. Examining Project Issues
- CS5. Reviewing Stage Status
- CS6. Reporting Highlights
- CS7. Taking Corrective Action
- CS8. Escalating Project Issues
- CS9. Receiving Completed Work Package

Managing product delivery

PRINCE2 is a product based system. A product can be a physical thing like a book, or it could be a more intangible thing like a service agreement. In fact everything created by PRINCE2 including documents is a product. Products can be created by anyone including external suppliers. This process creates the products of the project and is where most of its resources are used. The actual elements of Managing Product Delivery are:
- MP1. Accepting a Work Package
- MP2. Executing a Work Package
- MP3. Delivering a Work Package

Managing stage boundaries

According to PRINCE2 principles, each stage must be completed and approved by the project board before the go ahead is given to proceed to the next stage. The actual elements of Managing Stage Boundaries are:
- SB1. Planning a Stage
- SB2. Updating a Project Plan
- SB3. Updating a Project Business Case
- SB4. Updating the Risk Log
- SB5. Reporting Stage End
- SB6. Producing an Exception Plan

Closing a project

Another principle of PRINCE2 is that projects must be closed down in a controlled and orderly way. This involves evaluating the project's result (The Post Project Review). Any lessons learned are recorded, a handover document is created if necessary and a post implementation review is planned. The actual elements of Closing a Project are:
- CP1. Decommissioning a Project
- CP2. Identifying Follow-on Actions
- CP3. Project Evaluation Review

Components

PRINCE2 recognises eight key concepts or what it calls components in project management:

Business Case

The purpose of the Business Case is to justify the project – it drives the business process and ensures the project’s progress is aligned with the business’ objectives. The Business Case must be valid for life of project. The owner of the business case is the project’s Executive. A major input to the business case will be the project mandate.

The Organisation

Defines all the roles and responsibilities for the people managing and executing the project. PRINCE2 assumes that projects take place in a Customer – Supplier environment. The main roles are:
- Project Board
- Executive
- Senior User
- Senior Supplier
- Project Manager
- Project Assurance
- Optional roles are:
- Team Manager
- Project Support

Plans

PRINCE2 plans need to be approved before they are put into action. There are 3 levels of plan:
- Project Plans
- Stage Plans
- Team Plans A fourth type of plan, an exception plan, is used to replace the stage plan when a project deviation occurs.

Controls

Controls ensure the right projects are produced at the right time and that the project remains viable against the business case. PRINCE2 uses management by exception. Therefore there is no standard requirement to hold meetings with the Project Board, who will be informed immediately if there are exceptions. The main types of control used are:
- Project initiation
- Highlight reports
- Exceptions reports
- Exception assessment
- End stage assessment
- Project closure
- Tolerance

Management of Risk

Projects are unique undertakings and therefore are subject to unpredictability. Risk is “uncertainty of outcome”. The management of risk is about keeping risks within acceptable bounds, in an efficient and cost effective manner. Risk management has 3 main principles:
- Risk Tolerance
- Risk Responsibility
- Risk Ownership

Quality in a Project Environment

The aim of a project is to produce products that are fit for purpose and satisfy the needs and expectations of the customer. The quality expectations are stated in the Project Mandate, Project Brief and the PID. There are 4 main elements that make up quality management:
- Quality Management System
- Quality Assurance Function
- Quality Planning
- Quality Control

Configuration Management

Configuration management is concerned with controlling all of the products of the project. A configuration is a logically related set of products that need to be managed as a composite set. In project management terms, this means all the products and deliverables of the project. Configuration management consists of 5 main functions:
- Planning
- Identification
- Control
- Status Accounting
- Verification

Change Control

Controlling change is dealt with by the technique change control (see below).

Techniques

PRINCE2 identifies three specific techniques for use on projects.

Product based planning

PRINCE2 uses product based planning as opposed to activity based planning. i.e. PRINCE2 plans and measures progress against objectively measurable products (e.g. "the wall") rather than more subjectively defined and measured activities (e.g. "50% of building the wall"). Product based planning involves the production of:
- Product breakdown structures
- Product descriptions
- Product flow diagrams

Change control

In PRINCE2 all changes are treated as Project Issues, of which there are three types:
- Request for change. This is raised for a change to a requirement or product.
- Off specification. This is where a product fails to meet a requirement.
- Query All project issues are the responsibility of the Project Manager and are recorded in an Issues Log. Requests for change must be approved by the Project Board, who will require an impact analysis of the change. Off specifications can be dealt with directly by the project manager if they fall within pre-determined tolerance limits. The project board can approve an off specification without any change, known as a concession.

Quality reviews

PRINCE2 requires products to be reviewed for quality. This takes place in a quality review meeting, which identifies errors in the product. The quality review meeting will not attempt to solve the problems it identifies.

Strengths

PRINCE2 has a number of strengths, namely:
- It produces highly standardised projects which share a common approach, vocabulary and documents. Consequently it is a transferable skill and anyone familiar with a method can quickly be brought up to speed on a properly applied PRINCE2 project.
- It is a method which embodies best practise in project management
- It enshrines management by exception as a guiding rule, which allows the Project Manager to do their job without undue interference, while at the same time involving higher level managers when things go badly off plan or in PRINCE terms out of tolerance.
- It provides a controlled start, middle and end of projects
- Each type of document required by PRINCE2 is supplied as a template, which includes required sub-headings which produces easily comprehensible, standardised and complete documentation.
- It is tailorable to the needs of a specific organisation and/or project.
- It is royalty-free, therefore an organisation can advise/require its suppliers to use PRINCE2 without royalty concerns.
- PRINCE2 reference/material are published, so that an organisation need not develop and document its own project management method in order to train staff in its use.

Weaknesses

PRINCE2 has the following weaknesses:
- A number of organisations suffer from PINO (Prince In Name Only), carelessly picking and choosing from the methodology, thereby failing to abide by its key principles. (As with several of the items below, this problem is, of course, not a weakness of the methodology itself but of its practitioners.)
- PRINCE2 is strongly document centric in order to provide good control. However, in some organisations the documents become ends in themselves, and the actual projects themselves falter.
- PRINCE2 provides no explicit treatment of requirements analysis. It is an implementation methodology, which can lead to projects being adopted on false premises, and thereby inevitably failing.
- If not tailored to the needs of the project properly, PRINCE2 can be far too heavy duty an approach for small projects, because it will generate too much work.
- Not very agile

Examinations

There are two examinations in PRINCE2.

Foundation Examination

This is a knowledge check on the PRINCE2 manual and its project management methodology, taken through a one-hour multiple choice paper, composed of 75 questions. Candidates must achieve 38 correct answers to pass.

Practitioner Examination

Candidates for the PRINCE2 Practitioner examination must first have passed the Foundation examination. The Practitioner exam is a three-hour case-based examination, with a scenario background and 3 questions. Anyone taking this examination should be able to apply PRINCE2 to the running and management of a project.

Accredited Training Organisations

To train people for either of the PRINCE2 examinations, training organisations need to be properly accredited by the Office of Government Commerce's partner, the APM Group.

References

- The Stationery Office. Managing Successful Projects with PRINCE2. ISBN 0113308914 (Official PRINCE2 publication)
- The Stationery Office. Tailoring PRINCE2. ISBN 0113308973 (How to adapt PRINCE2 to your particular situation)

External links

- [http://www.ogc.gov.uk/prince2/ Official PRINCE2 site]
- [http://www.ogc.gov.uk/sdtoolkit/reference/documentation/index.html PRINCE2 Documents]
- [http://www.usergroup.org.uk The OGC officially recognised User Group]
- [http://www.prince2.org.uk The APM Group PRINCE2 site - contains list of Accredited Training Organisations]
- [http://www.p2ug.com The PRINCE2 User Group Forum]
- [http://prince2.technorealism.org PRINCE2 Wiki] Category: Project management category:PRINCE2

Critical chain

In project management, the critical chain is the sequence of both precedence- and resource-dependent terminal elements that prevents a project from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project's critical chain is identical to its critical path. Critical chain is used as an alternative to critical path analysis. The main features that distinguish the critical chain from the critical path are: # The use of (often implicit) resource dependencies. Implicit means that they are not included in the project network but have to be identified by looking at the resource requirements. # Lack of search for an optimum solution. This means that a "good enough" solution is enough because: ## As far as is known, there is no analytical method of finding an absolute optimum (i.e. having the overall shortest critical chain). ## The inherent uncertainty in estimates is much greater than the difference between the optimum and near-optimum ("good enough" solutions). # The identification and insertion of buffers: #
- project buffer #
- feeding buffers #
- resource buffers. It aggregates the large amounts of safety time added to many subprojects in project buffers to protect due-date performance, and to avoid wasting this safety time through bad multitasking, student syndrome, and poorly synchronised integration. Critical chain project management uses buffer management instead of earned value management to assess the performance of a project. Some project managers feel that the earned value management technique is misleading, because it does not distinguish progress on the project constraint (i.e. on the critical chain) from progress on non-constraints (i.e. on other paths). The critical chain concept was developed by Eliyahu M. Goldratt as an application of his theory of constraints. See also: list of project management software

External links

- [http://www.realization.com/executionresults.htm Critical Chain Implementation Results]
- [http://www.Advanced-projects.com/ Critical Chain Mind Map and other goodies!]
- [http://www.prochain.com/ Free Critical Chain Articles]
- [http://www.focusedperformance.com/articles/ccpm.html Getting Out From Between Parkinson's Rock and Murphy's Hard Place] (Critical Chain basics for single projects)
- [http://www.focusedperformance.com/articles/multipm.html Program Management -- Turning Many Projects into Few Priorities with TOC] (Multi-project management)
- [http://www.focusedperformance.com/articles/ccrisk.html Critical Chain and Risk Management - Protecting Project Value from Uncertainty]
- [http://www.focusedperformance.com/blogger.html Focused Performance weblog] Category:Project management Category:Theory of constraints Category:Management category:Production and manufacturing Category:business books

Extreme project management

Extreme project management (XPM) refers to the method of managing very complex and very uncertain projects. Extreme project management differs from traditional project management mainly in its open, elastic and undeterministic approach. The main focus of XPM is on the human side of project management (e.g. managing project stakeholders), rather than on intricate scheduling techniques and heavy formalism. Other names for extreme project management are:
- radical project management
- agile project management.
- Extreme project management is a generalization of extreme programming. Advanced approaches to extreme project management utilize the principles of human interaction management to deal with the complexities of human collaboration. Key authorities on extreme project management are:
- [http://dougdecarlo.com/ Doug deCarlo]
- [http://www.thomsett.com.au Rob Thomsett]
- [http://www.cutter.com/ The Cutter Consortium]

Books

- Ajani, Shaun H. Extreme Project Management: Unique Methodologies - Resolute Principles - Astounding Results. ISBN 0595213359
- DeCarlo, Douglas. eXtreme Project Management: Using Leadership, Principles and Tools to Deliver Value in the Face of Volatility. ISBN 0787974099
- Highsmith, Jim. Agile Project Management: Creating Innovative Products. ISBN 0321219775
- Thomsett, Rob. Radical Project Management. ISBN 0130094862
- Wysocki, Robert K., Rudd McGary. Effective Project Management: Traditional, Adaptive, Extreme, Third Edition. ISBN 0471432210
- Harrison-Broninski, Keith. Human Interactions: The Heart and Soul of Business Process Management. ISBN 0929652444 Category: Project management

External links

- [http://agileprojectmgt.org/ Agile Project Management Homepage]
- [http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap C2 Entry Page to Extreme Programming]
- [http://outsourceking.com/PM/Project-Management-Defined.aspx Project Management Tutorial]
- [http://www.rolemodellers.com/abstracts Books, articles and white papers on Human Interaction Management]
- [http://www.targetprocess.com TargetProcess - Agile Project Management Tool]
- [http://www.architecturalpractices.com XPM for architectural projects]

Process-based management

Process-based management is a management approach that governs the mindset and actions in an organization. It is a philosophy of how an organization manages its operations, aligned with and supported by the vision, mission and values of the organization. The process is the basis on which decisions are made and actions are taken. It is oriented toward achieving a vision rather than targeting specific activities and tasks of individual functions. The general process is that the vision determines the necessary strategy, structure and human resource requirements for the organisation. It can also be used on the project management level in that a clear vision of a project defines the strategy, structure and resources required to achieve success. The project process continues with the implementation of the tasks and activities required to achieve the vision. Category:Management Category:Psychology

CMMI

The Capability Maturity Model (CMM) is a method for evaluating and measuring the maturity of the software development process of organizations on a scale of 1 to 5. The CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh. It has been used extensively for avionics software and for government projects since it was created in the mid-1980s. The SEI has subsequently released a revised version known as the Capability Maturity Model Integration (CMMI).

Levels of the CMM

(See chapter 2 of ([http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf March 2002 edition of CMMI^SM from SEI]), page 11.) There are five levels of the CMM. According to the SEI, :"Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."

Level 1 - Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects. Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes.

Level 2 - Repeatable

At maturity level 2, Software development successes are repeatable. The organization may use some basic project management to track cost and schedule. Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans. Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).

Level 3 - Defined

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes, which is the basis for level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization’s set of standard processes according to tailoring guidelines. The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed. A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.

Level 4 - Managed

Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

Level 5 - Optimizing

Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities. Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed. Optimizing processes that are agile and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning. A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.

Extensions

Recent versions of CMMI from SEI indicate a "level 0", characterized as "Incomplete". Many observers leave this level out as redundant or unimportant, but Pressman and others make note of it. See page 18 of the [http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr011.pdf August 2002 edition of CMMI from SEI] (Note: PDF file). Anthony Finkelstein extrapolated that negative levels, or the [http://www.stsc.hill.af.mil/crosstalk/1996/11/xt96d11h.asp Capability Immaturity Model], are necessary to represent environments that are not only indifferent, but actively counterproductive, and this was refined by Tom Schorsch:
- CMM level 0 (negligent)
- CMM level -1 (obstructive)
- CMM level -2 (contemptuous)
- CMM level -3 (undermining)

Praise

- The CMM was developed to give Defense organizations a yardstick to assess and describe the capability of software contractors to provide software on time, within budget, and to acceptable standards. It has arguably been successful in this role, even reputedly causing some software salespeople to clamour for their organizations' software engineers/developers to "implement CMM."
- The CMM is intended to enable an assessment of an organization's maturity for software development. It is an important tool for outsourcing and exporting software development work. Economic development agencies in India, Ireland, Egypt, and elsewhere have praised the CMM for enabling them to be able to compete for US outsourcing contracts on an even footing. Whilst this may have been very positive for the employment of software engineers in emerging or Third World economies - notably in India during the early 2000s - it is regarded as having adversely affected the potential employment opportunities for software engineers in the developed economies - notably the USA and Europe. This outsourcing is a form of labor arbitrage which is similar to the movement of manufacturing of (for example) fashion clothing or Nike shoes to Third World economies with relatively cheap labor rates.

Criticism

- CMM has failed to take off the world over. It's hard to tell exactly how wide spread it is as the SEI only publishes the names and achieved levels of compliance of companies that have requested this information to be listed[http://www.sei.cmu.edu/cmmi/faq/ares-faq.html#RATE03]. The most current Maturity Profile for CMMI is available online[http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2005marCMMI.pdf ].
- No external body actually certifies a software development center as being CMM compliant. It is supposed to be an honest self-assessment ([http://www.sei.cmu.edu/cmmi/faq/ares-faq.html#APR04] and [http://www.sei.cmu.edu/cmmi/faq/ares-faq.html#APR05]).
- The CMM does not describe how to create an effective software development organization. The CMM contains behaviors or best practices that successful projects have demonstrated. Being CMM compliant is not a guarantee that a project will be successful, however being compliant can increase a project's chances of being successful.
- The CMM can seem to be overly bureaucratic, promoting process over substance. For example, for emphasizing predictability over service provided to end users. More commercially successful methodologies (for example, the Rational Unified Process) have focused not on the capability of the organization to produce software to satisfy some other organization or a collectively-produced specification, but on the capability of organizations to satisfy specific end user "use cases" as per the Object Management Group's UML (Unified Modeling Language) approach[http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.024.html].

The most beneficial elements of CMM Level 2 and 3

- Creation of Software Specifications, stating what it is that is going to be developed, combined with formal sign off, an executive sponsor and approval mechanism. This is NOT a living document, but additions are placed in a deferred or out of scope section for later incorporation into the next cycle of software development.
- A Technical Specification, stating how precisely the thing specified in the Software Specifications is to be developed will be used. This is a living document.
- Peer Review of Code (Code Review) with metrics that allow developers to walk through an implementation, and to suggest improvements or changes. Note - This is problematic because the code has already been developed and a bad design can not be fixed by "tweaking", the Code Review gives complete code a formal approval mechanism.
- Version Control - a very large number of organizations have no formal revision control mechanism or release mechanism in place.
- The idea that there is a "right way" to build software, that it is a scientific process involving engineering design and that groups of developers are not there to simply work on the problem du jour.

External links

- [http://www.sei.cmu.edu/cmmi/ CMMI Official Web Site]
- [http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview05.pdf Capability Maturity Model® Integration (CMMI®) Overview] [PDF]
- [http://www.processmax.com CMMi Automation Software]
- [http://www.tc.umn.edu/~hause011/article/Capability_maturity_models.html A critical look at implementing CMM Level 2]
- [http://www.cio.com/archive/030104/cmm.html CIO Article, Bursting the CMM Hype] Category:Software engineering

ISO 10006

ISO 10006:1997, Quality management; Guidelines to quality in project management, is an international standard developed by the International Organization for Standardization.

External links

- [http://www.pmpartners.com/resources/iso10006.html Overview and discussion of the ISO 10006 Standard]
- [http://www.welchco.com/sd/08/00101/02/95/07/21/134937.HTM Comparison of ISO 10006 and PMBOK]
- [http://www.standardsdirect.org/iso10006.htm Download source of ISO 10006 from BSI]
- [http://www.sfs.fi/standard/scope10006.pdf Scope of the ISO 10006 Standard] #10006 Category:Project management

Harakat at-Tahrir al-Filastin

Al-Fatah (arab.: الفتح der Sieg) ist eine politische Partei in Palästina. Der Name ist ein Akronym von Harakat at-Tahrir al-Filastini (Bewegung zur Befreiung Palästinas). Die Organisation, die die Zerstörung Israels und die Errichtung eines palästinensischen Staats verfolgt, bedient sich auch terroristischer Mittel um diese Ziele zu verfolgen. Die Fatah ist die stärkste Fraktion innerhalb der PLO. Im politischen Spektrum nimmt sie den Platz einer bürgerlich-konservativen Partei ein, die sich sowohl vom Islamismus als auch vom Sozialismus abgrenzt.

Geschichte

Am 10. Oktober 1959 wurde sie als Guerillaorganisation von Jassir Arafat zusammen mit Salah Chalaf, Chalil Wasir und Faruk Kadumi in Kuwait gegründet. Ideologisch verstand sie sich als unabhängig. Die Fatah sieht im bewaffneten Kampf ein geeignetes Mittel zur Erreichung ihrer Ziele, der palästinensischen Unabhängigkeit. Ende 1964 verübten Fatah-Kommandos erste Anschläge in Israel. In den Folgejahren operierten die Freischärler hauptsächlich von Jordanien aus, verübten Bombenattentate und legten Hinterhalte. Die israelische Regierung reagierte mit der Sprengung von Häusern, die Fatah-Kämpfer beherbergen, und der Ausweisung von Unterstützern. Zwischen Juni 1967 und Dezember 1968 kamen dabei über 600 Palästinenser, über 200 israelische Soldaten und 47 israelische Zivilisten ums Leben. Einen Wendepunkt in der weiteren Entwicklung stellte die Schlacht von Karame dar. Die israelische Strafexpedition nach Karame (Jordanien) kostete zwar 124 Freischärler, davon 91 Angehörige der Fatah, das Leben, aber die Verluste auf israelischer Seite waren ebenfalls hoch. In der arabischen Welt wurde die Schlacht als grosser Sieg gefeiert, der die seit der Niederlage im Sechstagekrieg angeschlagene arabische Ehre wieder herstellte. Die Schlacht bestätigte Fatah in ihrem eingeschlagenen Weg und leitete die Machtübernahme des Widerstandes in der PLO ein. Im Juni 1968 wurden die Mandate der PLO neu verteilt, wobei nun die verschiedenen Widerstandsbewegungen die grosse Mehrheit bildeten. Fatah avancierte zur stärksten Fraktion der PLO und im Februar 1969 wurde der Fatah-Chef Arafat zum Vorsitzenden der Organisation gewählt. Die PLO war damit von einer unter der Ägide Nassers gegründeten Organisation zu einem Forum des palästinensischen Widerstandes geworden. Dennoch wurde sie, wie auch die Sache der Palästinenser im Allgemeinen, weiter von den arabischen Staaten für ihre Zwecke instrumentalisiert. In den Jahren 1970 - 1971 kam es in Jordanien zu schweren Zusammenstössen (Schwarzen September) zwischen den Truppen Husseins und des Widerstandes, die schliesslich in der vollständigen Vertreibung der Freischärler mündeten. Als neue Basis im Kampf gegen Israel diente nun der Libanon. Als Israel 1982 in den Libanon eindrang, zerstreute sich die Gruppe in verschiedene Staaten: Tunesien, Jemen, Algerien, den Irak und andere.

Politisches Programm

Oberstes Ziel der Fatah ist die "komplette Befreiung Palästinas und die Vernichtung der ökonomischen, politischen, militärischen und kulturellen Existenz der Zionisten" (Artikel 12). Danach soll laut Programm ein unabhängiger demokratischer Staat mit vollständiger Souveränität auf dem Gebiet ganz Palästinas entstehen. Jerusalem solle die Hauptstadt werden und es solle allen Bürgern gleiche Rechte zugestanden werden, ohne rassische oder religiöse Diskriminierung. Die bewaffnete Volksrevolution sei dabei ein unverzichtbares Mittel um Palästina zu befreien. Mehrere Gruppen blieben u.a. im Libanon und in Palästina aktiv: die Hawari, Tanzim und die Al-Aqsa-Märtyrer-Brigaden.

Fatah-Tanzim

Die Tanzim-Miliz wurde Mitte der 1990er-Jahre als Miliz der Fatah gegründet. Unter ihrem Führer Marwan al-Barghouti spielte sie eine zentrale Rolle in der im September 2000 begonnenen Al-Aqsa-Intifada.

Al-Aqsa-Märtyrer-Brigaden

Die Al-Aqsa-Märtyrer-Brigaden sind ein bewaffneter Zweig der Al-Fatah. Sie wurden nach Beginn der Al-Aqsa-Intifada gegründet und verübten zahlreiche Selbstmordattentate gegen israelische Zivilisten. Zu ihren Opfern gehören außerdem vermeintliche palästinensische Kollaborateure. Die Al-Aqsa-Märtyrer-Brigaden sind in Zellen organisiert. Anfang 2004 war unklar, welche dieser Zellen noch loyal gegenüber Jassir Arafat sind und welche Zellen externen Geldgebern gehorchen.

Siehe auch

- Nahostkonflikt
- Israelisch-palästinensischer Konflikt
- Terrorismus

Weblinks

- [http://www.alkrama.com alkrama.com - Parteiorgan] (arabisch)
- [http://www.fateh.net/e_public/constitution.htm Das Programm der Fatah] (englisch) Kategorie:Palästina Kategorie:Nahostkonflikt

accommodation in valencia heavy metal gry gu Links disco polo

:: RELATED NEWS ::

Wikipedia:行事曆
行事曆幫助排定並公告維基社群上正在或將要發生的重要事務——尤其是那些有時限的事情，比如各項評選、投票、獎勵、質量提升計畫、战锤 40000"里的一个虚构的星际帝国.

人类帝国的历史

人类帝国最初由皇帝(人类的领导人和神)创建于"Age of Strife",那是一个充满着混乱,毁灭和无法律的时代,并且除了很少一部份以外所有以前人类的文明全部消失. 不过当warpstorm消失后皇帝开使准备联合所有人类于他的统制下,并将他手下�