:: 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]

Project manager

A project manager is the person who has the overall responsibility for the successful planning and execution of any project. The project manager must possess a combination of skills including an ability to ask penetrating questions, detect unstated assumptions and resolve interpersonal conflicts as well as more systematic management skills. Key amongst his/her duties is the recognition that risk directly impacts the likelihood of success and that this risk must be both formally and informally measured throughout the lifetime of the project. Risk arises primarily from uncertainty and the successful project manager is the one who focuses upon this as the main concern. Most of the issues that impact a project arise in one way or another from risk. A good project manager can reduce risk significantly, often by adhering to a policy of open communication, ensuring that every significant participant has an opportunity to express opinions and concerns. It follows from the above that a project manager is one who is responsible for making decisions both small and large, in such a way that risk is controlled and uncertainty minimized. Every decision taken by the project manager should be taken in such a way that it directly benefits the project.

Construction project management

In the past, construction project managers were individuals who had worked in construction or a supporting industry and were promoted into project management. This lead to a profession in which it was difficult to gain knowledge. The profession has more recently grown to accommodate several dozen Construction Management Bachelor of Science programs. Until recently, the industry also lacked any level of standardization, with individual States determining the eligibilty requirements within their jurisdiction. However, several Trade Associations based in the USA have made strides in creating a commonly-accepted set of qualifications and tests to determine a project manager's competency. #The Project Management Institute has made some headway into being a standardizing body with its creation of the Project Management Professional (P.M.P.) designation. #The Constructor Certification Commission of the American Institute of Constructors holds semiannual nationwide tests. Eight American Construction Management programs require that students take these exams before they may receive their Bachelor of Science in Construction Management degree, and 15 other Universities actively encourage their students to consider the exams. #The Associated Colleges of Construction Education, and the Associated Schools of Construction have made considerable progress in developing national standards who Construction Education programs.

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

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:การวางแผนโครงการ

Scope (project management)

Scope (products) of a project is the sum total of all projects products and their features. Sometimes scope is used to mean the totality of work needed to complete a project. In traditional project management, the tools to describe a project's scope (product) are the product breakdown structure and product descriptions. The primary tool to describe a project's scope (work) is the work breakdown structure. Extreme project management advocates the use of user stories, feature lists and feature cards to describe a project's scope (product). If there is no effective change control in a project, scope creep may ensue. Category:Project management

Project planning

Read further

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

External links

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:アーンド・バリュー・マネジメント

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

Process improvement

Process improvement is the activity of elevating the performance of a process, especially that of a business process with regard to its goal. Process improvement can take the form of an improvement project, or that of a process. Such a process of continuous improvement is part of organization's management processes (as opposed to business processes and support processes). See also:
- reengineering
- process management
- benchmarking
- theory of constraints
- TQM
- Six Sigma
- ISO 9000
- Donella Meadows' twelve leverage points to intervene in a system
- Just In Time manufacturing
- lean manufacturing
- Business Process Improvement (BPI)
- Lessons Learnt Category:Management Category:Organizational studies and human resource management Category:Production and manufacturing Category:Theory of constraints

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

United States/Department of Defense

:Note: DOD redirects here. For other uses, please see DOD (disambiguation) The United States Department of Defense, abbreviated as DoD or DOD and sometimes called the Defense Department is a civilian Cabinet organization of the United States government. The Department of Defense controls the U.S. military and is headquartered at The Pentagon. It is headed by the Secretary of Defense, who is currently Donald Rumsfeld.

History

Proposals to coordinate the activities of the military services were initially considered by U.S. Congress in 1944. Specific plans were put forth in 1945 by the Army, the Navy, and the Joint Chiefs of Staff. In a special message to U.S. Congress on December 19, 1945, President Harry Truman proposed creation of a unified Department of National Defense, which came under the Department of Transportation. A proposal reached Congress in April 1946, but was held up by the Naval Affairs Committee held hearings in July 1946 due to objections to the concentration of power in a single department. Truman eventually sent new legislation to Congress in February 1947, where it was debated and amended for several months. On July 26, 1947, Truman signed the National Security Act of 1947, which set up the National Military Establishment to begin operations on September 18, 1947, the day after the confirmation of James V. Forrestal as the first Secretary of Defense. The Establishment had the unfortunate abbreviation 'NME' (the obvious pronunciation being "enemy"), and was renamed the "Department of Defense" on August 10, 1949; in addition, the secretary was given greater authority over the military departments of the Army, Navy, and Air Force. The Department of Defense is based in The Pentagon in Arlington County, Virginia outside Washington, DC, across the Potomac River. It was created by combining the War Department (founded in 1789) with the Navy Department (founded in 1798; formerly the Board of Admiralty, founded in 1780), and the newly created Department of the Air Force. The department was formed in order to reduce interservice rivalry which was believed to have reduced military effectiveness during World War II. It includes the Army, Navy, Air Force, Marines, as well as non-combat agencies such as the National Security Agency and the Defense Intelligence Agency. In wartime, the Department of Defense also has authority over the Coast Guard; in peacetime, that agency is under the control of the Department of Homeland Security. Prior to the creation of DHS, the Coast Guard was under the control of the Department of Transportation. The Coast Guard has not been formally militarized since World War II, although it has participated in various military and law enforcement operations over the years. The DoD's annual budget is roughly $425 billion (~$1,600 per capita), which does not include tens of billions more in supplemental expenditures allotted by Congress throughout the year. The command structure of the Department of Defense is defined by the Goldwater-Nichols Act of 1986. Under the act, the chain of command runs from the President of the United States, through the Secretary of Defense, to the regional commanders within one of several commands who command all military forces within their area of operation. The Chairman of the Joint Chiefs of Staff and the several Chiefs of Staff are responsible for readiness of the U.S. military and serve as the President's military advisers, but are not in the chain of command. The Chairman of the Joint Chiefs of Staff is by law the highest ranking military officer in the United States. On February 22, 2002, the Department of Defense Office of the Inspector General has reported that DOD has not and will not account for $1.1 trillion of "undocumentable adjustments." In addition, there have been several high-profile Government Accountability Office investigations of the Department of Defense. As part of the September 11, 2001 attacks, terrorists crashed a plane into one of the sections of The Pentagon, causing part of it to collapse, killing 189 people.

Organization

- Office of the Secretary of Defense
- Defense Policy Board Advisory Committee
- Office of Net Assessment
- Office of Inspector General
- Defense Criminal Investigative Service
- Military Departments
- Department of the Army including the U.S. Army
- Department of the Navy including the U.S. Navy and U.S. Marine Corps
- Department of the Air Force including the U.S. Air Force
- Joint Chiefs of Staff
- United States Naval Observatory
- Unified Combatant Commands
- Central Command (CENTCOM)
- European Command (EUCOM)
- Joint Forces Command (JFCOM)
- Northern Command (NORTHCOM)
- Pacific Command (PACOM)
- Southern Command (SOUTHCOM)
- Special Operations Command (SOCOM)
- Strategic Command (STRATCOM)
- Transportation Command (TRANSCOM)
- Defense Agencies
- Defense Advanced Research Projects Agency
- Defense Commissary Agency
- Defense Contract Audit Agency
- Defense Contract Management Agency
- Defense Finance and Accounting Service
- Defense Information Systems Agency
- Defense Intelligence Agency
- Defense Legal Services Agency
- Defense Logistics Agency
- Defense Security Cooperation Agency
- Defense Security Service
- Defense Threat Reduction Agency
- Missile Defense Agency
- National Security Agency
- National Reconnaissance Office
- National Geospatial-Intelligence Agency
- Pentagon Force Protection Agency
- Department of Defense Field Activities
- American Forces Information Service
- Defense Prisoner of War/Missing Personnel Office
- Department of Defense Education Activity
- Department of Defense Dependents Schools
- DoD Human Resources Activity
- Office of Economic Adjustment
- Tricare Management Activity
- Washington Headquarters Services In 2003, the National Communications System was moved to the United States Department of Homeland Security. United States Department of Homeland Security

Related legislation

- 1947 - National Security Act of 1947
- 1958 - Department of Defense Reorganization Act PL 85-899
- 1963 - Department of Defense Appropriations Act PL 88-149
- 1963 - Military Construction Authorization Act PL 88-174
- 1967 - Supplemental Defense Appropriations Act PL 90-8
- 1984 - Department of Defense Authorization Act PL 98-525
- 1986 - Goldwater-Nichols Act of 1986 or Department of Defense Reorganization Act PL 99-433
- 1996 - Antiterrorism and Effective Death Penalty Act PL 104-132

External links

- [http://www.defenselink.mil/ United States Department of Defense website]
- Defense ko:미국 국방부 ja:アメリカ国防総省

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.

Project Management Body of Knowledge

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is a project management standard developed by the Project Management Institute (PMI). The PMBOK Guide is widely accepted to be the standard in project management, although it has its critics. The main thrust of the critique comes from the critical chain (vs. critical path) followers (e.g. Leach). Others consider the agile method Scrum to be a useful alternative. See also: ISO 10006, PRINCE2.

References

- Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition -- 2004 Edition. ISBN 1-930699-45-X
- Eliyahu M. Goldratt Critical Chain. ISBN 0884271536
- Lawrence P. Leach. Critical Chain Project Management (Artech House Professional Development Library). ISBN 1580530745

External link

- [http://www.pmi.org/ PMI's website]
- [http://www.interplansystems.com/pmbok-turnaround-management/ Applying PMBOK to Shutdowns, Turnarounds and Outages]. Category:Project management

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

Scrum (in management)

Scrum is an agile method for project management, first implemented by a team led by Jeff Sutherland at Easel Corporation in 1993. It has been called a "hyper-productivity tool", and has been documented to dramatically improve productivity in teams previously paralyzed by heavier methodologies. Scrum was first documented by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986). Its intended use is for management of software development projects, and it has been successfully used to "wrap" Extreme Programming and other development methodologies. However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding. Although scrum was intended to be for management of software development projects, it can be used in running maintenance teams, or as a program management approach: scrum of scrums.

Characteristics of scrum

- A living backlog of prioritised work to be done;
- Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
- A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
- A brief planning session in which the backlog items for the sprint will be defined.
- A brief heartbeat retrospective, at which all team members reflect about the past sprint. Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organising) but acts as a productivity buffer between the team and any destabilising influences. Scrum enables the creation of self-organising teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional "process control" manner. As such, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined, focusing instead on maximising the team's ability to respond in an agile manner to emerging challenges. Notably missing from scrum is the "cookbook" approach to project management exemplified in the Project Management Body of Knowledge - which has as its goal quality through application of a series of prescribed processes.

Simplified Scrum

Many organizations are resistant to methodologies introduced at a grass-roots level. Scrum is so adaptable that it is fairly easy to get around this and introduce it in "stealth" mode. There are three basic things to do:
- Schedule a demo of the software with the customer/client of the software for one month from now
- As a team, take a month to get your software ready for the demo - actually functioning, not just screen shots
- At the demo, get feedback then repeat using that feedback to guide the next month's development work With this process, which is just simple common sense, the essence of the Scrum patterns is implemented and can be built upon.

External links

- [http://www.controlchaos.com/ Information and Certification] -- seems to have been superseded by the [http://www.scrumalliance.org/ Scrum Alliance] site
- [http://jeffsutherland.com/scrum/ Jeff Sutherland's Scrum Blog]
- c2.com [http://c2.com/cgi/wiki?ScrumProcess Public Wiki]
- [http://groups.yahoo.com/group/scrumdevelopment/messages Discussion group]
- [http://bookshelved.org/cgi-bin/wiki.pl?AgileSoftwareDevelopmentWithScrum Agile Software Development with Scrum] by Ken Schwaber
- [http://www.agilealliance.org Agile Values]
- [http://scrumeducation.com International Certification Courses with a focus on outside USA]
- [http://groups.yahoo.com/group/scrumdevelopment/message/2116 Scrum Software Tools], plus a [http://scrumwiki.org/ Scrum Wiki], and now [http://www.scrumworks.com/ ScrumWorks]
- [http://www.mountaingoatsoftware.com/scrum/ Mountain Goat Software Scrum Page] A well illustrated and good definition of Scrum
- [http://www.methodsandtools.com/archive/archive.php?id=18 Adaptive Project Management Using Scrum] by Craig Murphy. This article provides a basic overview of Scrum.
- [http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_detail.jhtml?id=86116 The New New Product Development Game] by Takeuchi and Nonaka. The paper that started it all. Category:Management category:Production and manufacturing Category:Project management

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]

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

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

倒A高达

∀ Gundam 又稱 Turn-A Gundam，是於1999年為了慶祝 Gundam 系列誕生 25 週年而製作的一套 TV版作品。由原作富野由悠季（富野孝喜）身任製作人。目前沒有被正式代理，翻譯的名稱有逆A或是倒A都有。

∀的意義

∀的形狀就像是一個倒著的Ａ，在數學上這個符號代表著For All，也就是對於所有的的意思。這代表著本作品試著把之前所有的 Gundam 作品結合在同一個時空下。也因此在此作品裡會出現之前在不同鋼彈作品以及世界觀出現的不同機械。

故事概要

故事舞台是在遙遠的未來，人類在地球上重新建立起文明，而科技再度發展到類似工業革命的時代。而被留在月球上的居民Moonrace則是保存了以前人類文明所發展的高科技。留在月球上的居民想要重回地球居住，而派遣了先鋒部隊Dianna Counter來到了Ameria（原來的美洲），想為月球人的移民做預備。而這個舉動惹怒了Ameria上的各領地。於是在地球跟月球的戰爭就開始了。

特色

本次 Gundam 的美術風格跟以往的完全不同，由安田朗（原街頭霸王人物設定）設定的人物們有很強烈的世界名作劇場風格，而由美國的 Syd Meed 重新設計的 Gundam 還有其他的機械也有很異於傳統 Gundam 的外表。劇情方面整體上則缺少以往富野作品中常常出現的悲劇。主角的個性很乖巧，不同以往富野作品裡主角擁有青少年叛逆行為。

機械設定

由著名美國科幻設定大師 Syd Meed 設定的機械一反日式科幻的美形風，讓原 Gundam 的觀眾大吃一驚。 category:鋼彈 ja:∀ガンダム

teksty luxury hotel prague Kwiaciarnia ��d� praca w anglii cheap london hotels

:: RELATED NEWS ::

Koss Hybrid
The term Koss Hybrid refers to the modification of Koss' The Plug or Spark Plug in which the OEM black memory foam tips are replaced with better ones. The replacement tips are often Etymotic ER-14's or even regular earplugs. The recent availablity of Koss Hybrids on eBay have made them a popular alternative to the expensive high-end noise isolation earphones offered by Shure and Etymotic.

General information

Creator, company, license, etc.

Operating system support

The