2010-06-14 1300 Project Management Broad Spectrum Overview Wikibook - PDFCOFFEE.COM (2024)

Project Management Broad spectrum Overview

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Mon, 14 Jun 2010 10:25:38 UTC

Contents Articles Project management

1

Project planning

13

Scope (project management)

14

Scope creep

16

Design structure matrix

17

Systems Development Life Cycle

19

Enterprise resource planning

27

Project slippage

36

Project charter

36

Software bloat

37

Megaprojects and Risk

40

Megaproject

41

Feature creep

42

Instruction creep

44

Creep (project management)

44

Cost overrun

45

Mission creep

48

Waterfall model

49

IBM Rational Unified Process

54

Requirements management

62

Critical Chain Project Management

67

Cone of Uncertainty

70

Problem solving

71

Resource leveling

79

Theory of Constraints

80

Agile management

87

Extreme programming

88

Scrum (development)

98

Event chain methodology

106

Human interaction management

110

Process modeling

111

Event chain diagram

119

Gantt chart

120

PRINCE2

123

Process-based management

128

ISO/IEC 15504

128

Capability Maturity Model Integration

135

Research and development

140

Stage-Gate model

143

Financial analysis

149

Stakeholder analysis

151

Deliverable

154

Budget

155

New product development

157

Risk

163

Audit

174

Consultant

177

Strategy

178

Project manager

180

Project management triangle

185

Work breakdown structure

189

Contract

195

United States Department of Veterans Affairs

209

A Guide to the Project Management Body of Knowledge

214

Capability Maturity Model

215

ISO 9000

221

ISO 10006

236

Total cost management

237

The International Association of Project and Program Management

238

V-Model

239

Project portfolio management

243

Glossary of project management

247

List of project management topics

257

Comparison of project management software

259

Timeline of project management

262

Portfolio management

264

Systems engineering

264

Portfolio manager

275

IT portfolio management

275

Human factors

279

Earned value management

292

Project governance

299

Virtual project management

301

Software development process

302

Process architecture

308

Project

309

Critical path method

311

Agile software development

313

Program Evaluation and Review Technique

323

Computer software

330

Software engineering

336

Construction

342

Engineering

350

Iterative and incremental development

362

Project Management Institute

365

Requirement

367

Operations research

371

Risk management

379

International Organization for Standardization

391

Change control

398

Project management software

400

Business

404

Goal

410

Dynamic Systems Development Method

413

Product (business)

426

Marketing

429

System

437

Change management

442

Software development

443

Management

446

Requirements analysis

454

Program management

461

Software development methodology

465

Organization

474

Strategic management

480

References Article Sources and Contributors

501

Image Sources, Licenses and Contributors

514

Article Licenses License

517

Project management

1

Project management Project management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives. It is sometimes conflated with program management, however technically a program is actually a higher level construct: a group of related and somehow interdependent projects. A project is a temporary endeavor, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables[1] ), undertaken to meet unique goals and objectives[2] , usually to bring about beneficial change or added value. The temporary nature of projects stands in contrast to business as usual (or operations)[3] , which are repetitive, permanent or semi-permanent functional work to produce products or services. In practice, the management of these two systems is often found to be quite different, and as such requires the development of distinct technical skills and the adoption of separate management. The primary challenge of project management is to achieve all of the project goals[4] and objectives while honoring the preconceived project constraints.[5] Typical constraints are scope, time, and budget.[1] The secondary—and more ambitious—challenge is to optimize the allocation and integration of inputs necessary to meet pre-defined objectives.

History Project management has been practiced since early civilization. Until 1900 civil engineering projects were generally managed by creative architects and engineers themselves, among those for example Vitruvius (1st century BC), Christopher Wren (1632–1723) , Thomas Telford (1757-1834) and Isambard Kingdom Brunel (1806–1859) [6] It was in the 1950s that organizations started to systematically apply project management tools and techniques to complex projects.[7]

Roman Soldiers Building a Fortress, Trajan's Column 113 AD

As a discipline, Project Management developed from several fields of application including construction, engineering, and defense activity.[8] Two forefathers of project management are Henry Gantt, called the father of planning and control techniques[9] , who is famous for his use of the Gantt chart as a project management tool; and Henri Fayol for his creation of the 5 management functions which form the foundation of the body of knowledge associated with project and program management.[10] Both Gantt and Fayol were students of Frederick Winslow Taylor's theories of scientific management. His work is the forerunner to modern project management tools including work breakdown structure (WBS) and resource allocation. Henry Gantt (1861-1919), the father of planning and control techniques.

The 1950s marked the beginning of the modern Project Management era. Project management became recognized as a distinct discipline arising from the management discipline.[11] In the United States, prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt Charts, and

informal techniques and tools. At that time, two mathematical project-scheduling models were developed. The "Critical Path Method" (CPM) was developed as a joint venture between DuPont Corporation and Remington Rand

Project management

2

Corporation for managing plant maintenance projects. And the "Program Evaluation and Review Technique" or PERT, was developed by Booz-Allen & Hamilton as part of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris missile submarine program;[12] These mathematical techniques quickly spread into many private enterprises. At the same time, as project-scheduling models were being developed, technology for project cost estimating, cost management, and engineering economics was evolving, with pioneering work by Hans Lang and others. In 1956, the American Association of Cost Engineers (now AACE International; the Association for the Advancement of Cost Engineering) was formed by early practitioners of project management and the associated specialties of planning and scheduling, cost estimating, and cost/schedule control (project control). AACE continued its pioneering work and in 2006 released the first integrated process for portfolio, program and project management (Total Cost Management Framework).

PERT network chart for a seven-month project with five milestones

The International Project Management Association (IPMA) was founded in Europe in 1967,[13] as a federation of several national project management associations. IPMA maintains its federal structure today and now includes member associations on every continent except Antarctica. IPMA offers a Four Level Certification program based on the IPMA Competence Baseline (ICB).[14] The ICB covers technical competences, contextual competences, and behavioral competences. In 1969, the Project Management Institute (PMI) was formed in the USA.[15] PMI publishes A Guide to the Project Management Body of Knowledge (PMBOK Guide), which describes project management practices that are common to "most projects, most of the time." PMI also offers multiple certifications. The AAPM American Academy of Project Management International Board of Standards 1996 was the first to institute post-graduate certifications such as the MPM Master Project Manager, PME Project Management E-Business, CEC Certified-Ecommerce Consultant, and CIPM Certified International project Manager. The AAPM also issues the post-graduate standards body of knowledge for executives.

Approaches There are a number of approaches to managing project activities including agile, interactive, incremental, and phased approaches. Regardless of the methodology employed, careful consideration must be given to the overall project objectives, timeline, and cost, as well as the roles and responsibilities of all participants and stakeholders.

The traditional approach A traditional phased approach identifies a sequence of steps to be completed. In the "traditional approach", we can distinguish 5 components of a project (4 stages plus control) in the development of a project:

Project management

3

• Project initiation stage; • Project planning or design stage; • Project execution or production stage; • Project monitoring and controlling systems; • Project completion . Typical development phases of a project

Not all the projects will visit every stage as projects can be terminated before they reach completion. Some projects do not follow a structured planning and/or monitoring stages. Some projects will go through steps 2, 3 and 4 multiple times. Many industries use variations on these project stages. For example, when working on a brick and mortar design and construction, projects will typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. In software development, this approach is often known as the waterfall model[16] , i.e., one series of tasks after another in linear sequence. In software development many organizations have adapted the Rational Unified Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend this practice. Waterfall development works well for small, well defined projects, but often fails in larger projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as the planning made on the initial phase of the project suffers from a high degree of uncertainty. This becomes especially true as software development is often the realization of a new or novel product. In projects where requirements have not been finalized and can change, requirements management is used to develop an accurate and complete definition of the behavior of software that can serve as the basis for software development[17] . While the terms 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."

Critical Chain Project Management Critical Chain Project Management (CCPM) is a method of planning and managing projects that puts more emphasis on the resources (physical and human) needed in order to execute project tasks. It is an application of the Theory of Constraints (TOC) to projects. The goal is to increase the rate of throughput (or completion rates) of projects in an organization. Applying the first three of the five focusing steps of TOC, the system constraint for all projects is identified as are the resources. To exploit the constraint, tasks on the critical chain are given priority over all other activities. Finally, projects are planned and managed to ensure that the resources are ready when the critical chain tasks must start, subordinating all other resources to the critical chain. Regardless of project type, the project plan should undergo Resource Leveling, and the longest sequence of resource-constrained tasks should be identified as the critical chain. In multi-project environments, resource leveling should be performed across projects. However, it is often enough to identify (or simply select) a single "drum" resource—a resource that acts as a constraint across projects—and stagger projects based on the availability of that single resource.

Project management

4

Extreme Project Management 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 Agile Project Management methods including Extreme Programming for software development and Scrum techniques.

Planning and feedback loops in Extreme Programming (XP) with the time frames of the multiple loops.

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.

Event chain methodology Event chain methodology is another method that complements critical path method and critical chain project management methodologies. Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology helps to mitigate the negative impact of psychological heuristics and biases, as well as to allow for easy modeling of uncertainties in the project schedules. Event chain methodology is based on the following principles. • Probabilistic moment of risk: An activity (task) in most real life processes is not a continuous uniform process. Tasks are affected by external events, which can occur at some point in the middle of the task. • Event chains: Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project. Quantitative analysis is used to determine a cumulative effect of these event chains on the project schedule. • Critical events or event chains: The single events or the event chains that have the most potential to affect the projects are the “critical events” or “critical chains of events.” They can be determined by the analysis. • Project tracking with events: Even if a project is partially completed and data about the project duration, cost, and events occurred is available, it is still possible to refine information about future potential events and helps to forecast future project performance. • Event chain visualization: Events and event chains can be visualized using event chain diagrams on a Gantt chart.

Project management

5

PRINCE2 PRINCE2 is a structured approach to project management, released in 1996 as a generic project management method.[18] It combined the original PROMPT methodology (which evolved into the PRINCE methodology) with IBM's MITP (managing the implementation of the total project) methodology. PRINCE2 provides a method for managing projects within a clearly defined framework. PRINCE2 describes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it does not develop as planned.

The PRINCE2 process model

In the method, each process is specified with its key inputs and outputs and with specific goals and activities to be carried out. This allows for automatic control of any deviations from the plan. Divided into manageable stages, the method enables an efficient control of resources. On the basis of close monitoring, the project can be carried out in a controlled and organized way. PRINCE2 provides a common language for all participants in the project. The various management roles and responsibilities involved in a project are fully described and are adaptable to suit the complexity of the project and skills of the organization.

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 - Software Process Improvement and Capability Estimation). Agile Project Management approaches based on the principles of human interaction management are founded on a process view of human collaboration. This contrasts sharply with the traditional approach. In the agile software development or flexible product development Capability Maturity Model, predecessor of the CMMI Model approach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process.

Project management

6

Processes Traditionally, project management includes a number of elements: four to five process groups, and a control system. Regardless of the methodology or terminology used, the same basic project management processes will be used. Major process groups generally include: • • • • •

Initiation Planning or development Production or execution Monitoring and controlling Closing

In project environments with a significant exploratory element (e.g., Research and development), these stages may be supplemented with decision points (go/no go decisions) at which the project's continuation is debated and decided. An example is the Stage-Gate model. [19] The project development stages

Initiation

[19] Initiating Process Group Processes

The initiation processes determine the nature and scope of the project. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’ needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a

recommendation should be made to fix them. The initiation stage should include a plan that encompasses the following areas: • • • • •

Analyzing the business needs/requirements in measurable goals Reviewing of the current operations Financial analysis of the costs and benefits including a budget Stakeholder analysis, including users, and support personnel for the project Project charter including costs, tasks, deliverables, and schedule

Project management

7

Planning and design After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals. Project planning generally consists of • determining how to plan (e.g. by level of detail or rolling wave); • developing the scope statement; • selecting the planning team;

[19]

Planning Process Group Activities

• identifying deliverables and creating the work breakdown structure; • identifying the activities needed to complete those deliverables and networking the activities in their logical sequence; • estimating the resource requirements for the activities; • estimating time and cost for activities; • developing the schedule; • developing the budget; • risk planning; • gaining formal approval to begin work. Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable. For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities.

Executing Executing consists of the processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan. Executing Process Group Processes

[19]

Monitoring and controlling

Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan.

Project management

8

Monitoring and Controlling includes: • Measuring the ongoing project activities ('where we are'); • Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline (where we should be); • Identify corrective actions to address issues and risks properly (How can we get on track again); • Influencing the factors that could circumvent integrated change control so only approved changes are implemented

[19] Monitoring and Controlling Process Group Processes

In multi-phase projects, the monitoring and controlling process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. Project Maintenance is an ongoing process, and it includes: • Continuing support of end users • Correction of errors • Updates of the software over time In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope may change. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be Monitoring and Controlling cycle documented to show what was actually constructed. This is referred to as Change Management. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents – usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, “as built.” The requirement for providing them is a norm in construction contracts. When changes are introduced to the project, the viability of the project has to be re-assessed. It is important not to lose sight of the initial goals and targets of the projects. When the changes accumulate, the forecasted result may not justify the original proposed investment in the project.

Closing

Project management

9

Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. This phase consists of: • Project close: Finalize all activities across all of the process groups to formally close the project or a project phase

[19]

Closing Process Group Processes.

• Contract closure: Complete and settle each contract (including the resolution of any open items) and close each contract applicable to the project or project phase

Project control systems Project control is that element of a project that keeps it on-track, on-time and within budget. Project control begins early in the project with planning and ends late in the project with post-implementation review, having a thorough involvement of each step in the process. Each project should be assessed for the appropriate level of control needed: too much control is too time consuming, too little control is very risky. If project control is not implemented correctly, the cost to the business should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for cost, risk, quality, communication, time, change, procurement, and human resources. In addition, auditors should consider how important the projects are to the financial statements, how reliant the stakeholders are on controls, and how many controls exist. Auditors should review the development process and procedures for how they are implemented. The process of development and the quality of the final product may also be assessed if needed or requested. A business may want the auditing firm to be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An auditor can serve as a controls consultant as part of the development team or as an independent auditor as part of an audit. Businesses sometimes use formal systems development processes. These help assure that systems are developed successfully. A formal process is more effective in creating strong controls, and auditors should review this process to confirm that it is well designed and is followed in practice. A good formal systems development plan outlines: • • • • •

A strategy to align development with the organization’s broader objectives Standards for new systems Project management policies for timing and budgeting Procedures describing the process Evaluation of quality of change

Topics Project managers A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, engineering, architecture, computing, or telecommunications. Many other fields in the production, design and service industries also have project managers. A project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which is cost, time, and scope. A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key

Project management

10

issues of cost, time, quality and above all, client satisfaction, can be realized.

Project Management Triangle Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost".[1] These are also referred to as the "Project Management Triangle," where each side represents a constraint. One side of the triangle cannot be changed without affecting the others. A further refinement of the constraints separates product "quality" or "performance" from scope, and turns quality into a fourth constraint. The time constraint refers to the amount of time available The Project Management Triangle. to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope. The discipline of Project Management is about providing the tools and techniques that enable the project team (not just the project manager) to organize their work to meet these constraints. Interestingly, a study conducted by Besner and Hobbs [20] of 1,000 project managers (PMs) in 2004, found that of the 40 different tools that fit within the project management umbrella, the number one feature PM's needed for both small and large projects, was getting a progress report.

Work Breakdown Structure The Work Breakdown Structure (WBS) is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. The WBS may be hardware, product, service, or process oriented.

Example of a Work breakdown structure applied in a NASA [21] reporting structure.

A WBS can be developed by starting with the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages), which include all steps necessary to achieve the objective.[17]

The Work Breakdown Structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established.[21]

Project management

Project Management Framework The Program (Investment) Life Cycle integrates the project management and system development life cycles with the activities directly associated with system deployment and operation. By design, system operation management and related activities occur after the project is complete and are not documented within this guide.[19] For example, see figure, in the US United States Department of Veterans Affairs (VA) the program management life cycle is depicted and describe in the overall VA IT Project Management Framework to address the integration [19] Example of an IT Project Management Framework. of OMB Exhibit 300 project (investment) management activities and the overall project budgeting process. The VA IT Project Management Framework diagram illustrates Milestone 4 which occurs following the deployment of a system and the closing of the project. The project closing phase activities at the VA continues through system deployment and into system operation for the purpose of illustrating and describing the system activities the VA considers part of the project. The figure illustrates the actions and associated artifacts of the VA IT Project and Program Management process.[19]

International standards There have been several attempts to develop Project Management standards, such as: • Capability Maturity Model from the Software Engineering Institute. • GAPPS, Global Alliance for Project Performance Standards- an open source standard describing COMPETENCIES for project and program managers. • A Guide to the Project Management Body of Knowledge • HERMES method, Swiss general project management method, selected for use in Luxembourg and international organizations. • The ISO standards ISO 9000, a family of standards for quality management systems, and the ISO 10006:2003, for Quality management systems and guidelines for quality management in projects. • PRINCE2, PRojects IN Controlled Environments. • Team Software Process (TSP) from the Software Engineering Institute. • Total Cost Management Framework, AACE International's Methodology for Integrated Portfolio, Program and Project Management) • V-Model, an original systems development method. • The Logical framework approach, which is popular in international development organizations. • IAPPM, The International Association of Project & Program Management, guide to Project Auditing and Rescuing Troubled Projects.

11

Project management

12

Project portfolio management An increasing number of organizations are using, what is referred to as, project portfolio management (PPM) as a means of selecting the right projects and then using project management techniques[22] as the means for delivering the outcomes in the form of benefits to the performing private or not-for-profit organization. Project management methods are used 'to do projects right' and the methods used in PPM are used 'to do the right projects'. In effect PPM is becoming the method of choice for selection and prioritising among resource inter-related projects in many industries and sectors.

See also Lists

Related fields

Related subjects

• • • •

• • • • • • • • •

• • • • • • • • • •

Glossary of project management List of project management topics List of project management software Timeline of project management

Architectural engineering Construction management Cost engineering Industrial engineering Project management software Project workforce management Portfolio management Systems engineering Software project management

Human factors Earned value management Project+ Project accounting Project governance Program management Process architecture Software development process Systems Development Life Cycle (SDLC) Virtual Project Management

External links • Max Wideman's "Open Source" Comparative Glossary of Project Management Terms [23] • Open Source Project Management manual [24] • Guidelines for Managing Projects [25] from the UK Department for Business, Enterprise and Regulatory Reform (BERR)

References [1] Chatfield, Carl. "A short course in project management" (http:/ / office. microsoft. com/ en-us/ project/ HA102354821033. aspx). Microsoft. . [2] *The Definitive Guide to Project Management. Nokes, Sebastian. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007. ISBN 978 0 273 71097 4 [3] Paul C. Dinsmore et al (2005) The right projects done right! John Wiley and Sons, 2005. ISBN 0787971138. p.35 and further. [4] Lewis R. Ireland (2006) Project Management. McGraw-Hill Professional, 2006. ISBN 007147160X. p.110. [5] Joseph Phillips (2003). PMP Project Management Professional Study Guide. McGraw-Hill Professional, 2003. ISBN 0072230622 p.354. [6] Dennis Lock (2007) Project management (9e ed.) Gower Publishing, Ltd., 2007. ISBN 0566087723 [7] Young-Hoon Kwak (2005). "A brief history of Project Management". In: The story of managing projects. Elias G. Carayannis et al. (9 eds), Greenwood Publishing Group, 2005. ISBN 1567205062 [8] David I. Cleland, Roland Gareis (2006). Global project management handbook. "Chapter 1: "The evolution of project management". McGraw-Hill Professional, 2006. ISBN 0071460454 [9] Martin Stevens (2002). Project Management Pathways. Association for Project Management. APM Publishing Limited, 2002 ISBN 190349401X p.xxii [10] Morgen Witzel (2003). Fifty key figures in management‎. Routledge, 2003. ISBN 0415369770. p. 96-101. [11] David I. Cleland, Roland Gareis (2006). Global project management handbook. McGraw-Hill Professional, 2006. ISBN 0071460454. p.1-4 states: "It was in the 1950s when project management was formally recognized as a distinct contribution arising from the management discipline." [12] Booz Allen Hamilton - History of Booz Allen 1950s (http:/ / www. boozallen. com/ about/ history/ history_5) [13] Bjarne Kousholt (2007). Project Management‎ –. Theory and practice.. Nyt Teknisk Forlag. ISBN 8757126038. p.59. [14] http:/ / www. ipma. ch/ publication/ Pages/ ICB-IPMACompetenceBaseline. aspx [15] F. L. Harrison, Dennis Lock (2004). Advanced project management: a structured approach‎. Gower Publishing, Ltd., 2004. ISBN 0566078228. p.34.

Project management [16] Winston W. Royce (1970). "Managing the Development of Large Software Systems" (http:/ / www. cs. umd. edu/ class/ spring2003/ cmsc838p/ Process/ waterfall. pdf) in: In: Technical Papers of Western Electronic Show and Convention (WesCon) August 25-28, 1970, Los Angeles, USA. [17] Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management (http:/ / www. stellman-greene. com/ aspm/ ). O'Reilly Media. ISBN978-0-596-00948-9. . [18] OGC - PRINCE2 - Background (http:/ / www. ogc. gov. uk/ methods_prince_2__background. asp) [19] VA Office of Information and Technology (2003) Project Management Guide (http:/ / www. ppoe. oit. va. gov/ docs/ VA_IT_PM_Guide. pdf) US DEPARTMENT OF VETERANS AFFAIRS. March 3, 2005. [20] http:/ / www. pmi. org/ PDF/ Besner%20and%20Hobbs%20Practices%20Survey%20Report%20Phase%202. pdf [21] NASA (2001). NASA NPR 9501.2D (http:/ / nodis3. gsfc. nasa. gov/ displayDir. cfm?Internal_ID=N_PR_9501_002D_& page_name=Chp2& format=PDF). May 23, 2001. [22] Albert Hamilton (2004). Handbook of Project Management Procedures. TTL Publishing, Ltd. ISBN 07277-3258-7 [23] http:/ / www. maxwideman. com/ [24] http:/ / www. projectmanagement-training. net/ book/ [25] http:/ / www. berr. gov. uk/ files/ file40647. pdf

Project planning Project planning is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment.[1] Initially, the project scope is defined and the appropriate methods for completing the project are determined. Following this step, the durations for the various tasks necessary to complete the work are listed and grouped into a work breakdown structure. The logical dependencies between tasks are defined using an activity network diagram that enables identification of the critical path. Float or slack time in the schedule can be calculated using project management software[2] . Then the necessary resources can be estimated and costs for each activity can be allocated to each resource, giving the total project cost. At this stage, the project plan may be optimized to achieve the appropriate balance between resource usage and project duration to comply with the project objectives. Once established and agreed, the plan becomes what is known as the baseline. Progress will be measured against the baseline throughout the life of the project. Analyzing progress compared to the baseline is known as earned value management.[3] The inputs of the project planning phase include Project Charter and the Concept Proposal. The outputs of the Project Planning phase include the Project Requirements, the Project Schedule, and the Project Management Plan.[4]

See also • • • • • • • • • •

Cost overrun Project stakeholders Project management software Dependency Structure Matrix Project Management Institute Kitchen sink syndrome Megaproject PRINCE2 Enterprise resource planning Project slippage

13

Project planning

External links • • • •

International Project Management Association [5] Association for Project Managers (UK) [6] Prince2 site from OGC (UK Office of Government Commerce) [7] Critical path web calculator [8]

References [1] Harold Kerzner (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th Ed. ed.). Wiley. ISBN0-471-22577-0. [2] Richard H. Thayer, Edward Yourdon (2000). Software Engineering Project Management (2nd Ed. ed.). Wiley-IEEE Computer Society Press. ISBN0-8186-8000-8. [3] Fleming, Quentin (2005). Earned Value Project Management (Third Edition ed.). Project Management Institute. ISBN1-930699-89-1. [4] Filicetti, John, Project Planning Overview (http:/ / www. pmhut. com/ project-management-process-phase-2-planning-overview), PM Hut (Last accessed 8 November 2009). [5] http:/ / www. ipma. ch/ [6] http:/ / www. apm. org. uk/ [7] http:/ / www. ogc. gov. uk/ methods_prince_2. asp [8] http:/ / sporkforge. com/ sched/ critical_path. php

Scope (project management) In project management, the term scope has two distinct uses: Project Scope and Product Scope. Project Scope "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions." [1] Product Scope "The features and functions that characterize a product, service, or result." [2] Notice that Project Scope is more work-oriented, (the hows,) while Product Scope is more oriented toward functional requirements. (the whats.) If requirements are not completely defined and described and if there is no effective change control in a project, scope or requirement creep may ensue. Scope creep management is important for effective project management. Projects are expected to meet strict deadlines with resource restraints, and an unvetted and unapproved change in the scope can affect the success of the project. Scope creep sometimes causes cost overrun. Scope creep is a term which refers to the incremental expansion of the scope of a project, which may include and introduce more requirements that may not have been a part of the initial planning of the project, while nevertheless failing to adjust schedule and budget. There are two distinct ways to separate scope creep management. The first is business scope creep, and the second is called features (also technology) scope creep. The type of scope creep management is always dependent upon on the people who create the changes. Business scope creep management occurs when decisions that are made with reference to a project are designed to solve or meet the requirements and needs of the business. Business scope creep changes may be a result of poor requirements definition early in development, or the failure to include the users of the project until the later stage of the systems development life cycle. Scope management plan is one of the major Scope communication documents. The Project Scope Management Plan documents how the project scope will be defined, managed, controlled, verified and communicated to the project team and stakeholders/customers. It also includes all work required to complete the project. The documents are used to control what is in and out of the scope of the project by the use of a Change Management system. Items deemed out of scope go directly through the change control process and are not automatically added to the project

14

Scope (project management) work items. The Project Scope Management plan is included in as one of the sections in the overall Project Management plan. It can be very detailed and formal or loosely framed and informal depending on the communication needs of the project. Features (Technology) scope creep occurs when the scope creep is introduced by technologists adding features not originally contemplated. Customer-pleasing scope creep occurs when the desire to please the customer through additional product features adds more work to the current project rather than to a new project proposal. Gold-plating scope creep occurs when technologists augment the original requirements because of a bias toward "technical perfectionism" or because the initial requirements were insufficiently clear or detailed.

See also • Project management • Cost overrun

External links • Article identifying the primary causes and solutions for business and technological scope creep management [3] • Article identifying a number of reasons for the development of scope creep [4] • Articles on Project Scope Management [5] • Article on Managing Scope Creep in Web Project Development [6]

References [1] A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition. Project Management Institute, 2008. ISBN 978-1-933890-51-7 [2] A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition. Project Management Institute, 2008. ISBN 978-1-933890-51-7 [3] http:/ / www. projectperfect. com. au/ info_scope_creep_mgmt. php [4] http:/ / www. chacocanyon. com/ pointlookout/ 020904. shtml [5] http:/ / www. pmhut. com/ category/ scope-management/ project-scope-management/ [6] http:/ / www. macronimous. com/ resources/ managing_scope_creep_in_web_project_development. asp

15

Scope creep

Scope creep Scope creep (also called focus creep, requirement creep, feature creep, function creep) in project management refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided. Typically, the scope increase consists of either new products or new features of already approved product designs, without corresponding increases in resources, schedule, or budget. As a result, the project team risks drifting away from its original purpose and scope into unplanned additions. As the scope of a project grows, more tasks must be completed within the budget and schedule originally designed for a smaller set of tasks. Thus, scope creep can result in a project team overrunning its original budget and schedule. If the budget and schedule are increased along with the scope, the change is usually considered an acceptable addition to the project, and the term “scope creep” is not used. Scope creep can be a result of: • disingenuous customer with a determined value for free policy • poor change control • lack of proper initial identification of what is required to bring about the project objectives • weak project manager or executive sponsor • poor communication between parties • Agile software development based on subjective quantifications. Scope creep is a risk in most projects. Most megaprojects fall victim to scope creep (see Megaprojects and risk). Scope creep often results in cost overrun. A value for free strategy is difficult to counteract and remains a difficult challenge for even the most experienced project managers.

See also • • • • • • • • •

Project management Cost overrun Creep (project management) Instruction creep Featuritis Megaproject Megaprojects and risk Mission creep Software bloat

16

Scope creep

References • Wideman Comparative Glossary of Project Management Terms [1] by R. Max Wideman P.Eng. FCSCE, FEIC, FICE, Fellow PMI

External links • A Comprehensive Series on Scope Creep [2] • The Creeping Scope - How Accurate can Project Documentation be? [3]

References [1] http:/ / maxwideman. com/ pmglossary/ PMG_S01. htm [2] http:/ / www. pmhut. com/ ?s=%22Scope+ Creep+ Part%22 [3] http:/ / www. visionarytools. com/ decision-making/ incomplete-contracts-scope-creep. htm

Design structure matrix The design structure matrix (DSM) (also referred to as dependency structure method, dependency structure matrix, problem solving matrix (PSM), incidence matrix, n-square matrix or design precedence matrix) is a compact, matrix representation of a system or project. The approach can be used to model complex systems in systems engineering or systems analysis, and in project planning and project management.

Overview A design structure matrix lists all constituent subsystems/activities and the corresponding information exchange and dependency patterns. In other words, it details what pieces of information are needed to start a particular activity, and shows where the information generated by that activity leads. In this way, one can quickly recognise which other tasks are reliant upon information outputs generated by each activity. It has two main strengths. First, it can represent a large number of system elements and their relationships in a compact way that highlights important patterns in the data (such as feedback loops and modules). Second, it is amenable to matrix-based analysis techniques, which can be used to improve the structure of the system. DSM analysis provides insights into how to manage complex systems or projects, highlighting information flows, task sequences and iteration. It can help teams to streamline their processes based on the optimal flow of information between different interdependent activities. DSM analysis can also be used to manage the effects of change. For example, if the specification for a component had to be changed, it would be possible to quickly identify all processes or activities which had been dependent on that specification, reducing the risk that work continues based on out-of-date information.

Design A DSM is a square matrix. The cells along the diagonal represent the system elements, which are often labeled in the rows to the left of the matrix and/or in the columns above the matrix. The off-diagonal cells are used to indicate relationships between the elements. Reading across a row reveals what other elements the element in that row provides outputs to, and scanning a column reveals what other elements the element in that column receives inputs from. Alternatively, the rows and columns may be switched (without a change of meaning). Two main categories of DSMs have been proposed: static and time-based. Static DSMs represent systems where all of the elements exist simultaneously, such as components of a machine or groups in an organization. Static DSMs are usually analyzed with clustering algorithms. In time-based DSMs, the ordering of the rows and columns indicates

17

Design structure matrix a flow through time: earlier activities in a process appear in the upper-left of the DSM and later activities appear in the lower-right. Terms like “feedforward” and “feedback” become meaningful when referring to interfaces. Time-based DSMs are typically analyzed using sequencing algorithms. DSMs stem from diverse roots. A static DSM is equivalent to an N-square diagram or an incidence matrix. A time-based DSM is akin to a precedence diagram or the matrix representation of a directed graph. The time-based DSM (and the "DSM" term itself) originated with Don Steward, who coined the term “design structure matrix” in the 1960s. Steward's DSM grew from the use of matrices to solve mathematical systems of equations. Christopher Alexander presented a similar matrix-based design method in his 1964 book Notes on the Synthesis of Form.

Use The use of DSMs in both research and industrial practice increased greatly in the 1990s. DSMs have been applied in the building construction, real estate development, semiconductor, automotive, photographic, aerospace, telecom, small-scale manufacturing, factory equipment, and electronics industries, to name a few, as well as in many government agencies. A small number of computer software applications incorporate dependency structure matrices. The leaders in this field include BIW Technologies' PlanWeaver (employed in aerospace, defense and construction projects), Lattix, Inc. LDM (used to manage software architecture), DeMAID/GA, Acclaro [1] and Problematics [2], NDepend (for analysis of .NET applications). The latest version of the Java IDE IntelliJ IDEA 7.0 includes project dependency structure management since v7.0 Milestone 2. There is an open source DSM application dtangler [3] for analyzing java code. There is also a free DSM plugin [4] for .NET Reflector.

References • Control Component Dependencies, TheServerSide.net article [5] • Innovation at the Speed of Information [6] • Using Dependency Models to Manage Complex Software Architecture [7]

External links • • • • • • • • • • • • • •

www.dsmweb.org [8] www.problematics.com [2] www.planweaver.com [9] www.ndepend.org [10] www.lattix.com [11] www.teamport.com [12] www.axiomaticdesign.com [1] www.adeptmanagment.com [13] www.headwaysoftware.com [14] www.teseon.com [15] www.dsm-conference.org [16] tcdev.free.fr [4] www.complexworks.eu [17] www.dtangler.org [3]

18

Design structure matrix

19

References [1] http:/ / www. dfss-software. com/ default. asp [2] http:/ / www. problematics. com/ [3] http:/ / www. dtangler. org [4] http:/ / tcdev. free. fr [5] http:/ / www. theserverside. net/ tt/ articles/ showarticle. tss?id=ControllingDependencies [6] http:/ / hbswk. hbs. edu/ archive/ 1979. html [7] http:/ / sdg. csail. mit. edu/ pubs/ 2005/ oopsla05-dsm. pdf [8] http:/ / www. dsmweb. org/ [9] http:/ / www. planweaver. com [10] http:/ / www. NDepend. org/ [11] http:/ / www. lattix. com/ [12] http:/ / www. teamport. com/ [13] http:/ / www. adeptmanagement. com [14] http:/ / www. headwaysoftware. com [15] http:/ / www. teseon. com [16] http:/ / www. dsm-conference. org [17] http:/ / www. complexworks. eu/

Systems Development Life Cycle The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system[1] : the software development process.

Overview Model of the Systems Development Life Cycle with the

Systems Development Life Cycle (SDLC) is a process Maintenance bubble highlighted. used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.[2] Computer systems are complex and often (especially with the recent rise of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize". SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative

Systems Development Life Cycle methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results . Other models, such as Anamorphic Development, tend to focus on a form of development that is guided by project scope and adaptive iterations of feature development. Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software.[3] [4]

In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".[5]

History The systems development lifecycle (SDLC) is a type of methodology used to describe the process for building information systems, intended to develop information systems in a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The systems development life cycle, according to Elliott & Strachan & Radford (2004), "originated in the 1960s to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines".[6] Several systems development frameworks have been partly based on SDLC, such as the Structured Systems Analysis and Design Method (SSADM) produced for the UK government Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the traditional life cycle approaches to systems development have been increasingly replaced with alternative approaches and frameworks, which attempted to overcome some of the inherent deficiencies of the traditional SDLC".[6]

Systems development phases A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. Several Systems Development Life Cycle Models exist, the oldest of which — originally regarded as "the Systems Development Life Cycle" — is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps, but many different waterfall methodologies give the steps different names and the number of steps seems to vary between four and seven. There is no one correct Systems Development Life Cycle model.

20

Systems Development Life Cycle

The SDLC can be divided into ten phases during which defined IT work products are created or modified. The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The tasks and work products for each phase are described in subsequent chapters. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon [7] the size and complexity of the project, phases may be combined or may overlap.

Initiation/planning To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational or organizational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team.[8] The MIS is also a complement of those phases. This phase is also called as analysis phase.....

Requirements gathering and analysis The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves "breaking down" the system in different pieces to analyze the situation, analyzing project goals, "breaking down" what needs to be created and attempting to engage users so that definite requirements can be defined (Decomposition computer science). Requirements Gathering sometimes requires individuals/teams from client as well as service provider sides to get detailed and accurate requirements.

21

Systems Development Life Cycle

Design In systems design functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems. The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudocode, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input.

Build or coding Modular and subsystem programming code will be accomplished during this stage. Unit testing and module testing are done in this stage by the developers. This stage is intermingled with the next in that individual modules will need testing before integration to the main project.

Testing The code is tested at various levels in software testing. Unit, system and user acceptance testings are often performed. This is a grey area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs. Iteration is not generally part of the waterfall model, but usually some occur at this stage. Below are the following types of testing: • • • • • • • • • •

Data set testing. Unit testing System testing Integration testing Black box testing White box testing Regression testing Automation testing User acceptance testing Performance testing

22

Systems Development Life Cycle

Operations and maintenance The deployment of the system includes changes and enhancements before the decommissioning or sunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel change positions in the organization, new changes will be implemented, which will require system updates.

Systems development life cycle topics Management and control The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to project activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of the project. Each of the SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives during each [9] SDLC phase while executing projects. SDLC Phases Related to Management Controls. Control objectives help to provide a clear statement of the desired result or purpose and should be used throughout the entire SDLC process. Control objectives can be grouped into major categories (Domains), and relate to the SDLC phases as shown in the figure.[9] To manage and control any SDLC initiative, each project will be required to establish some degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project. The WBS and all programmatic material should be kept in the “Project Description” section of the project notebook. The WBS format is mostly left to the project manager to establish in a way that best describes the project work. There are some key areas that must be defined in the WBS as part of the SDLC policy. The following diagram describes three key areas that will be addressed in the WBS in a manner established by the project manager.[9]

Work breakdown structure organization

23

Systems Development Life Cycle

The upper section of the Work Breakdown Structure (WBS) should identify the major phases and milestones of the project in a summary fashion. In addition, the upper section should provide an overview of the full scope and timeline of the project and will be part of the initial project description effort leading to project approval. The middle section of the [9] Work Breakdown Structure. WBS is based on the seven Systems Development Life Cycle (SDLC) phases as a guide for WBS task development. The WBS elements should consist of milestones and “tasks” as opposed to “activities” and have a definitive period (usually two weeks or more). Each task must have a measurable output (e.g. document, decision, or analysis). A WBS task may rely on one or more activities (e.g. software engineering, systems engineering) and may require close coordination with other tasks, either internal or external to the project. Any part of the project needing support from contractors should have a Statement of work (SOW) written to include the appropriate tasks from the SDLC phases. The development of a SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by external resources such as contractors.[9]

Baselines in the SDLC Baselines are an important part of the Systems Development Life Cycle (SDLC). These baselines are established after four of the five phases of the SDLC and are critical to the iterative nature of the model [10] . Each baseline is considered as a milestone in the SDLC. • • • •

Functional Baseline: established after the conceptual design phase. Allocated Baseline: established after the preliminary design phase. Product Baseline: established after the detail design and development phase. Updated Product Baseline: established after the production construction phase.

Complementary to SDLC Complementary Software development methods to Systems Development Life Cycle (SDLC) are: • • • • • • •

Software Prototyping Joint Applications Design (JAD) Rapid Application Development (RAD) Extreme Programming (XP); extension of earlier work in Prototyping and RAD. Open Source Development End-user development Object Oriented Programming

24

Systems Development Life Cycle

25

Comparison of Methodologies (Post, & Anderson 2006)[11] SDLC

RAD

Open Source

Objects

JAD

Control

Formal

MIS

Weak

Standards Joint

Time Frame

Long

Short

Medium

Users

Many

Few

MIS staff

Many

Few

Transaction/DSS

Transaction Both

Interface

Minimal

Documentation and training

Prototyping

End User

User

User

Any

Medium Short

Short

Few

Varies

Few

One or Two

One

Hundreds

Split

Few

One or Two

None

Both

Both

DSS

DSS

DSS

Minimal Weak

Windows

Crucial

Crucial

Crucial

Vital

Limited

Internal

In Objects

Limited Weak

None

Integrity and security

Vital

Vital

Unknown

In Objects

Limited Weak

Weak

Reusability

Limited

Some

Maybe

Vital

Limited Weak

None

Strengths and weaknesses Few people in the modern computing world would use a strict waterfall model for their Systems Development Life Cycle (SDLC) as many modern methodologies have superseded this thinking. Some will argue that the SDLC no longer applies to models like Agile computing, but it is still a term widely in use in Technology circles. The SDLC practice has advantages in traditional models of software development, that lends itself more to a structured environment. The disadvantages to using the SDLC methodology is when there is need for iterative development or (i.e. web development or e-commerce) where stakeholders need to review on a regular basis the software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is far more important to take the best practices from the SDLC model and apply it to whatever may be most appropriate for the software being designed. A comparison of the strengths and weaknesses of SDLC:

Strength and Weaknesses of SDLC Strengths

Weaknesses

Control.

Increased development time.

Monitor Large projects.

Increased development cost.

Detailed steps.

Systems must be defined up front.

Evaluate costs and completion targets. Rigidity. Documentation.

Hard to estimate costs, project overruns.

Well defined user input.

User input is sometimes limited.

Ease of maintenance. Development and design standards. Tolerates changes in MIS staffing.

An alternative to the SDLC is Rapid Application Development, which combines prototyping, Joint Application Development and implementation of CASE tools. The advantages of RAD are speed, reduced development cost, and active user involvement in the development process.

Systems Development Life Cycle It should not be assumed that just because the waterfall model is the oldest original SDLC model that it is the most efficient system. At one time the model was beneficial mostly to the world of automating activities that were assigned to clerks and accountants. However, the world of technological evolution is demanding that systems have a greater functionality that would assist help desk technicians/administrators or information technology specialists/analysts.

See also • • • • • • • • • •

Application Lifecycle Management P-Modeling Framework Product lifecycle management Software development process Software Lifecycle Processes Systems design Design review Systems engineering process System Requirements Specification System requirements (spacecraft system)

• Unified Process • Work systems

Further reading • Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey: Prentice Hall. • Cummings, Haag (2006). Management Information Systems for the Information Age. Toronto, McGraw-Hill Ryerson • Beynon-Davies P. (2009). Business Information Systems. Palgrave, Basingstoke. ISBN: 978-0-230-20368-6 • Computer World, 2002 [12], Retrieved on June 22, 2006 from the World Wide Web: • Management Information Systems, 2005 [13], Retrieved on June 22, 2006 from the World Wide Web: • This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

External links • US Department of Education - Lifecycle Management Document [14] • System Development Lifecycle (SDLC) Review Document G23 from the Information Systems Audit and Control Association (ISACA) [15] • The Agile System Development Lifecycle [16] • Software as a Service Application Service Provider Systems Development Lifecycle [17] • Pension Benefit Guaranty Corporation - Information Technology Solutions Lifecycle Methodology [18] • SDLC Industry Interest Group [19] • State of Maryland SDLC [20] • HHS Enterprise Performance Life Cycle Framework [21] • CMS Integrated IT Investment & System Life Cycle Framework [22] • Collection of All SDLC Models in One Place With External Good Resources [23]

26

Systems Development Life Cycle

References [1] SELECTING A DEVELOPMENT APPROACH (http:/ / www. cms. hhs. gov/ SystemLifecycleFramework/ Downloads/ SelectingDevelopmentApproach. pdf). Retrieved 27 October 2008. [2] "Systems Development Life Cycle" (http:/ / foldoc. org/ foldoc. cgi?Systems+ Development+ Life+ Cycle). In: Foldoc(2000-12-24) [3] Abrahamsson, et al. (2003) "New Directions on Agile Methods: A Comparative Analysis" [4] Morkel Theunissen, et.al.(2003). "Standards and Agile Software Development" [5] James Taylor (2004). Managing Information Technology Projects. p.39.. [6] Geoffrey Elliott & Josh Strachan (2004) Global Business Information Technology. p.87. [7] US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT (http:/ / www. usdoj. gov/ jmd/ irm/ lifecycle/ ch1. htm) Chapter 1. Introduction. [8] (Post & Anderson, 2006) [9] U.S. House of Representatives (1999). Systems Development Life-Cycle Policy (http:/ / www. house. gov/ cao-opp/ PDFSolicitations/ SDLCPOL. pdf). p.13. [10] Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey: Prentice Hall. p.31 [11] Post, G., & Anderson, D., (2006). Management information systems: Solving business problems with information technology. (4th ed.). New York: McGraw-Hill Irwin. [12] http:/ / www. computerworld. com/ developmenttopics/ development/ story/ 0,10801,71151,00. html [13] http:/ / www. cbe. wwu. edu/ misclasses/ MIS320_Spring06_Bajwa/ Chap006. ppt [14] http:/ / www. ed. gov/ fund/ contract/ about/ acs/ acsocio1106. doc [15] http:/ / www. isaca. org/ Template. cfm?Section=Home& Template=/ ContentManagement/ ContentDisplay. cfm& ContentID=18676 [16] http:/ / www. ambysoft. com/ essays/ agileLifecycle. html [17] [18] [19] [20] [21] [22] [23]

http:/ / www. SaaSSDLC. com http:/ / www. pbgc. gov/ docs/ ITSLCM%20V2007. 1. pdf http:/ / www. gantthead. com/ gig/ gigDisplay. cfm?gigID=234& profileID= http:/ / doit. maryland. gov/ policies/ Pages/ sdlc. aspx http:/ / www. hhs. gov/ ocio/ eplc/ eplc_framework_v1point2. pdf http:/ / www. cms. hhs. gov/ SystemLifecycleFramework/ 01_overview. asp http:/ / eclecticcolors. blogspot. com/ 2010/ 01/ sdlc-models. html

Enterprise resource planning Enterprise resource planning (ERP) is an Integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources. It is a software architecture whose purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Built on a centralized database and normally utilizing a common computing platform, ERP systems consolidate all business operations into a uniform and enterprise wide system environment.[1] An ERP system can either reside on a centralized server or be distributed across modular hardware and software units that provide "services" and communicate on a local area network. The distributed design allows a business to assemble modules from different vendors without the need for the placement of multiple copies of complex, expensive computer systems in areas which will not use their full capacity[2] .

Origin of the term The initialism ERP was first employed by research and analysis firm Gartner Group in 1990 [3] as an extension of MRP (Material Requirements Planning; later manufacturing resource planning[4] ) and CIM (Computer Integrated Manufacturing), and while not supplanting these terms, it has come to represent a larger whole. It came into use as makers of MRP software started to develop software applications beyond the manufacturing arena.[5] ERP systems now attempt to cover all core functions of an enterprise, regardless of the organization's business or charter. These systems can now be found in non-manufacturing businesses, non-profit organizations and governments.[6] To be considered an ERP system, a software package should have the following traits:

27

Enterprise resource planning • • • •

Should be integrated and operate in real-time with no periodic batch updates. All applications should access one database to prevent redundant data and multiple data definitions. All modules should have the same look and feel. Users should be able to access any information in the system without needed integration work on the part of the IS department.[7]

Components • Transactional Backbone • • • •

Financials Distribution Human Resources Product lifecycle management

• Advanced Applications • Customer Relationship Management (CRM) • Supply chain management • Purchasing • Manufacturing • Distribution • Warehouse Management System • Management Portal/Dashboard • Decision Support System These modules can exist in a system or utilized in an ad-hoc fashion.[8]

Commercial applications Manufacturing Engineering, bills of material, scheduling, capacity, workflow management, quality control, cost management, manufacturing process, manufacturing projects, manufacturing flow Supply chain management Order to cash, inventory, order entry, purchasing, product configurator, supply chain planning, supplier scheduling, inspection of goods, claim processing, commission calculation Financials General ledger, cash management, accounts payable, accounts receivable, fixed assets Project management Costing, billing, time and expense, performance units, activity management Human resources Human resources, payroll, training, time and attendance, rostering, benefits Customer relationship management Sales and marketing, commissions, service, customer contact and call center support Data services Various "self-service" interfaces for customers, suppliers, and/or employees Access control Management of user privileges for various processes

28

Enterprise resource planning

History The term "Enterprise resource planning" originally derived from manufacturing resource planning (MRP II) that followed material requirements planning (MRP).[9] MRP evolved into ERP when "routings" became a major part of the software architecture and a company's capacity planning activity also became a part of the standard software activity. ERP systems typically handle the manufacturing, logistics, distribution, inventory, shipping, invoicing, and accounting for a company. ERP software can aid in the control of many business activities, including sales, marketing, delivery, billing, production, inventory management, quality management, and human resource management. ERP systems saw a large boost in sales in the 1990s as companies faced the Y2K problem in their legacy systems. Many companies took this opportunity to replace such information systems with ERP systems. This rapid growth in sales was followed by a slump in 1999, at which time most companies had already implemented their Y2K solution.[10] ERP systems are often incorrectly called back office systems indicating that customers and the general public are not directly involved. This is contrasted with front office systems like customer relationship management (CRM) systems that deal directly with the customers, or the eBusiness systems such as eCommerce, eGovernment, eTelecom, and eFinance, or supplier relationship management (SRM) systems. ERP systems are cross-functional and enterprise-wide. All functional departments that are involved in operations or production are integrated in one system. In addition to areas such as manufacturing, warehousing, logistics, and information technology, this typically includes accounting, human resources, marketing and strategic management. ERP II, a term coined in the early 2000s, is often used to describe what would be the next generation of ERP software. This new generation of software is web-based and allows both employees and external resources (such as suppliers and customers) real-time access to the system's data. EAS— Enterprise Application Suite is a new name for formerly developed ERP systems which include (almost) all segments of business using ordinary Internet browsers as thin clients. Though traditionally ERP packages have been on-premise installations, ERP systems are now also available as Software as a Service. Best practices are incorporated into most ERP vendor's software packages. When implementing an ERP system, organizations can choose between customizing the software or modifying their business processes to the "best practice" function delivered in the "out-of-the-box" version of the software. Prior to ERP, software was developed to fit individual processes of an individual business. Due to the complexities of most ERP systems and the negative consequences of a failed ERP implementation, most vendors have included "Best Practices" into their software. These "Best Practices" are what the Vendor deems as the most efficient way to carry out a particular business process in an Integrated Enterprise-Wide system.[11] A study conducted by Ludwigshafen University of Applied Science surveyed 192 companies and concluded that companies which implemented industry best practices decreased mission-critical project tasks such as configuration, documentation, testing and training. In addition, the use of best practices reduced over risk by 71% when compared to other software implementations.[12] The use of best practices can make complying with requirements such as IFRS, Sarbanes-Oxley, or Basel II easier. They can also help where the process is a commodity such as electronic funds transfer. This is because the procedure of capturing and reporting legislative or commodity content can be readily codified within the ERP software, and then replicated with confidence across multiple businesses who have the same business requirement.

29

Enterprise resource planning

Implementation Businesses have a wide scope of applications and processes throughout their functional units; producing ERP software systems that are typically complex and usually impose significant changes on staff work practices.[13] Implementing ERP software is typically too complex for "in-house" skill, so it is desirable and highly advised to hire outside consultants who are professionally trained to implement these systems. This is typically the most cost effective way. There are three types of services that may be employed for - Consulting, Customization, Support.[13] The length of time to implement an ERP system depends on the size of the business, the number of modules, the extent of customization, the scope of the change and the willingness of the customer to take ownership for the project. ERP systems are modular, so they don't all need be implemented at once. It can be divided into various stages, or phase-ins. The typical project is about 14 months and requires around 150 consultants.[14] A small project (e.g., a company of less than 100 staff) can be planned and delivered within 3–9 months; however, a large, multi-site or multi-country implementation can take years. The length of the implementations is closely tied to the amount of customization desired.[14] To implement ERP systems, companies often seek the help of an ERP vendor or of third-party consulting companies. These firms typically provide three areas of professional services: consulting; customization; and support. The client organization can also employ independent program management, business analysis, change management, and UAT specialists to ensure their business requirements remain a priority during implementation. Data migration is one of the most important activities in determining the success of an ERP implementation. Since many decisions must be made before migration, a significant amount of planning must occur. Unfortunately, data migration is the last activity before the production phase of an ERP implementation, and therefore receives minimal attention due to time constraints. The following are steps of a data migration strategy that can help with the success of an ERP implementation:[15] 1. 2. 3. 4. 5. 6.

Identifying the data to be migrated Determining the timing of data migration Generating the data templates Freezing the tools for data migration Deciding on migration related setups Deciding on data archiving

Process preparation ERP vendors have designed their systems around standard business processes, based upon best business practices. Different vendor(s) have different types of processes but they are all of a standard, modular nature. Firms that want to implement ERP systems are consequently forced to adapt their organizations to standardized processes as opposed to adapting the ERP package to the existing processes.[16] Neglecting to map current business processes prior to starting ERP implementation is a main reason for failure of ERP projects.[17] It is therefore crucial that organizations perform a thorough business process analysis before selecting an ERP vendor and setting off on the implementation track. This analysis should map out all present operational processes, enabling selection of an ERP vendor whose standard modules are most closely aligned with the established organization. Redesign can then be implemented to achieve further process congruence. Research indicates that the risk of business process mismatch is decreased by: • linking each current organizational process to the organization's strategy; • analyzing the effectiveness of each process in light of its current related business capability; • understanding the automated solutions currently implemented.[18] [19] ERP implementation is considerably more difficult (and politically charged) in organizations structured into nearly independent business units, each responsible for their own profit and loss, because they will each have different processes, business rules, data semantics, authorization hierarchies and decision centers.[20] Solutions include requirements coordination negotiated by local change management professionals or, if this is not possible, federated

30

Enterprise resource planning implementation using loosely integrated instances (e.g. linked via Master Data Management) specifically configured and/or customized to meet local needs. A disadvantage usually attributed to ERP is that business process redesign to fit the standardized ERP modules can lead to a loss of competitive advantage. While documented cases exist where this has indeed materialized, other cases show that following thorough process preparation ERP systems can actually increase sustainable competitive advantage.[21] [22]

Configuration Configuring an ERP system is largely a matter of balancing the way you want the system to work with the way the system lets you work. Begin by deciding which modules to install, then adjust the system using configuration tables to achieve the best possible fit in working with your company’s processes. Modules— Most systems are modular simply for the flexibility of implementing some functions but not others. Some common modules, such as finance and accounting are adopted by nearly all companies implementing enterprise systems; others however such as human resource management are not needed by some companies and therefore not adopted. A service company for example will not likely need a module for manufacturing. Other times companies will not adopt a module because they already have their own proprietary system they believe to be superior. Generally speaking the greater number of modules selected, the greater the integration benefits, but also the increase in costs, risks and changes involved. Configuration Tables– A configuration table enables a company to tailor a particular aspect of the system to the way it chooses to do business. For example, an organization can select the type of inventory accounting– FIFO or LIFO– it will employ or whether it wants to recognize revenue by geographical unit, product line, or distribution channel. So what happens when the options the system allows just aren't good enough? At this point a company has two choices, both of which are not ideal. It can re-write some of the enterprise system’s code, or it can continue to use an existing system and build interfaces between it and the new enterprise system. Both options will add time and cost to the implementation process. Additionally they can dilute the system’s integration benefits. The more customized the system becomes the less possible seamless communication between suppliers and customers.

Consulting services Many organizations do not have sufficient internal skills to implement an ERP project. This results in many organizations offering consulting services for ERP implementation. Typically, a consulting team is responsible for the entire ERP implementation including: 1. 2. 3. 4. 5. 6.

selecting planning training testing implementation delivery

of any customized modules. Examples of customization includes creating processes and reports for compliance, additional product training; creation of process triggers and workflow; specialist advice to improve how the ERP is used in the business; system optimization; and assistance writing reports, complex data extracts or implementing Business Intelligence. For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the

31

Enterprise resource planning cost of the user licenses—three to five times more is not uncommon for a multi-site implementation. Unlike most single-purpose applications, ERP packages have historically included full source code and shipped with vendor-supported team IDEs for customizing and extending the delivered code. During the early years of ERP the guarantee of mature tools and support for extensive customization was an important sales argument when a potential customer was considering developing their own unique solution in-house, or assembling a cross-functional solution by integrating multiple "best of breed" applications. "Core system" customization vs configuration Increasingly, ERP vendors have tried to reduce the need for customization by providing built-in "configuration" tools to address most customers' needs for changing how the out-of-the-box core system works. Key differences between customization and configuration include: • Customization is always optional, whereas some degree of configuration (e.g., setting up cost/profit centre structures, organisational trees, purchase approval rules, etc.) may be needed before the software will work at all. • Configuration is available to all customers, whereas customization allows individual customer to implement proprietary "market-beating" processes. • Configuration changes tend to be recorded as entries in vendor-supplied data tables, whereas customization usually requires some element of programming and/or changes to table structures or views. • The effect of configuration changes on the performance of the system is relatively predictable and is largely the responsibility of the ERP vendor. The effect of customization is unpredictable and may require time-consuming stress testing by the implementation team. • Configuration changes are almost always guaranteed to survive upgrades to new software versions. Some customizations (e.g. code that uses pre-defined "hooks" that are called before/after displaying data screens) will survive upgrades, though they will still need to be re-tested. More extensive customizations (e.g. those involving changes to fundamental data structures) will be overwritten during upgrades and must be re-implemented manually. By this analysis, customizing an ERP package can be unexpectedly expensive and complicated, and tends to delay delivery of the obvious benefits of an integrated system. Nevertheless, customizing an ERP suite gives the scope to implement secret recipes for excellence in specific areas while ensuring that industry best practices are achieved in less sensitive areas. Extensions In this context, "Extensions" refers to ways that an ERP environment can be "extended" (supplemented) with third-party programs. It is technically easy to expose most ERP transactions to outside programs that do other things, e.g.: • archiving, reporting and republishing (these are easiest to achieve, because they mainly address static data); • performing transactional data captures, e.g. using scanners, tills or RFIDs (also relatively easy because they touch existing data); However, because ERP applications typically contain sophisticated rules that control how data can be created or changed, some such functions can be very difficult to implement.

32

Enterprise resource planning

Advantages In the absence of an ERP system, a large manufacturer may find itself with many software applications that cannot communicate or interface effectively with one another. Tasks that need to interface with one another may involve: • ERP systems connect the necessary software in order for accurate forecasting to be done. This allows inventory levels to be kept at maximum efficiency and the company to be more profitable. • Integration among different functional areas to ensure proper communication, productivity and efficiency • Design engineering (how to best make the product) • Order tracking, from acceptance through fulfillment • The revenue cycle, from invoice through cash receipt • Managing inter-dependencies of complex processes bill of materials • Tracking the three-way match between purchase orders (what was ordered), inventory receipts (what arrived), and costing (what the vendor invoiced) • The accounting for all of these tasks: tracking the revenue, cost and profit at a granular level. ERP Systems centralize the data in one place. Benefits of this include: • Eliminates the problem of synchronizing changes between multiple systems - consolidation of finance, marketing and sales, human resource, and manufacturing applications • Permits control of business processes that cross functional boundaries • Provides top-down view of the enterprise (no "islands of information"), real time information is available to management anywhere, anytime to make proper decisions. • Reduces the risk of loss of sensitive data by consolidating multiple permissions and security models into a single structure. • Shorten production leadtime and delivery time • Facilitating business learning, empowering, and building common visions Some security features are included within an ERP system to protect against both outsider crime, such as industrial espionage, and insider crime, such as embezzlement. A data-tampering scenario, for example, might involve a disgruntled employee intentionally modifying prices to below-the-breakeven point in order to attempt to interfere with the company's profit or other sabotage. ERP systems typically provide functionality for implementing internal controls to prevent actions of this kind. ERP vendors are also moving toward better integration with other kinds of information security tools.[23]

Disadvantages Problems with ERP systems are mainly due to inadequate investment in ongoing training for the involved IT personnel - including those implementing and testing changes - as well as a lack of corporate policy protecting the integrity of the data in the ERP systems and the ways in which it is used. Disadvantages • Customization of the ERP software is limited... • Re-engineering of business processes to fit the "industry standard" prescribed by the ERP system may lead to a loss of competitive advantage. • ERP systems can be very expensive (This has led to a new category of "ERP light" solutions) • ERPs are often seen as too rigid and too difficult to adapt to the specific workflow and business process of some companies—this is cited as one of the main causes of their failure. • Many of the integrated links need high accuracy in other applications to work effectively. A company can achieve minimum standards, then over time "dirty data" will reduce the reliability of some applications. • Once a system is established, switching costs are very high for any one of the partners (reducing flexibility and strategic control at the corporate level).

33

Enterprise resource planning • The blurring of company boundaries can cause problems in accountability, lines of responsibility, and employee morale. • Resistance in sharing sensitive internal information between departments can reduce the effectiveness of the software. • Some large organizations may have multiple departments with separate, independent resources, missions, chains-of-command, etc, and consolidation into a single enterprise may yield limited benefits.

See also • • • • • • • • •

List of ERP software packages List of ERP vendors Accounting software Advanced Planning & Scheduling APICS Bill of materials (BOM) Business process management Configurable BOM (CBOM) Data migration

• • • • • • • • • • • • • • • • •

Enterprise Feedback Management (EFM) Enterprise system E-procurement ERP modeling ERP for IT ERP System Selection Methodology Information technology management List of project management software Management information system Manufacturing Operations Management Modular BOM (MBOM) Order to cash Service Management Software as a Service Supply chain management Warehouse management system Web management system

Further reading • Grant, David; Richard Hall, Nick Wailes, Christopher Wright (March 2006). "The false promise of technological determinism: the case of enterprise resource planning systems". New Technology, Work & Employment 21 (1): 2–15. doi:10.1111/j.1468-005X.2006.00159.x. • Loh, Tee Chiat; Lenny Koh Siau Ching (September 2004). "Critical elements for a successful ERP implementation in SMEs". International Journal of Production Research 42 (17): 3433–3455. doi:10.1080/00207540410001671679. • Head, Simon (2005). The New Ruthless Economy. Work and Power in the Digital Age. Oxford UP. ISBN0195179838. • Waldner, Jean-Baptiste (1992). Principles of Computer Integrated Manufacturing. Chichester: John Wiley & Sons Ltd. ISBN047193450X.

34

Enterprise resource planning • Waldner, Jean-Baptiste (1990). Les nouvelles perspectives de la production. Paris: DUNOD BORDAS. ISBN9782040198206. • Lequeux, Jean-Louis (2008). Manager avec les ERP, Architecture Orientée Services (SOA). Paris: EDITIONS D'ORGANISATION. ISBN9782212540949. • CIO Magazine's ABCs of ERP [24] • History Of ERP [25] • Clemons, E.K.; Kimborough (1986). "IS for Sustainable Competitive Advantage". Information & Management 11 (3): 131–136. doi:10.1016/0378-7206(86)90010-8.

References [1] [2] [3] [4] [5] [6]

Bidgoli, Hossein, (2004). The Internet Encyclopedia, Volume 1, John Wiley & Sons, Inc. p. 707. Khosrow-Puor, Mehdi. (2006). Emerging Trends and Challenges in Information Technology Management. Idea Group, Inc. p. 865. L. Wylie, "A Vision of Next Generation MRP II", Scenario S-300-339, Gartner Group, April 12, 1990 "ERP" (http:/ / www. erp. com/ component/ content/ article/ 324-erp-archive/ 4407-erp. html). . Retrieved 2009-10-07. Sheilds, Mureell G., E-Business and ERP: Rapid Implementation and Project Plannig. (2001) John Wiley and Sons, Inc. p. 9. Chang, SI; Guy Gable; Errol Smythe; Greg Timbrell (2000). "A Delphi examination of public sector ERP implementation issues" (http:/ / portal. acm. org/ citation. cfm?id=359640. 359793). International Conference on Information Systems. Atlanta: Association for Information Systems. pp.494–500. ISBNICIS2000-X. . Retrieved September 9, 2009. [7] Sheilds, Mureell G., E-Business and ERP: Rapid Implementation and Project Plannig. (2001) John Wiley and Sons, Inc. p. 9-10. [8] Sheilds, Mureell G., E-Business and ERP: Rapid Implementation and Project Plannig. (2001) John Wiley and Sons, Inc. p. 10. [9] Anderegg, Travis. "MRP/MRPII/ERP/ERM— Confusting Terms and Definitions for a Murkey Alphabet Soup" (http:/ / www. wlug. org. nz/ EnterpriseSpeak). . Retrieved 2007-10-25 [10] Monk, Ellen; Wagner, Bret (2006). Concepts in Enterprise Resource Planning (Second ed.). Boston: Thomson Course Technology. ISBN0619216638 [11] Monk, Ellen and Wagner, Brett."Concepts in Enterprise Resource Planning" 3rd.ed.Course Technology Cengage Learning.Boston, Massachusetts.2009 [12] "Enhanced Project Success Through SAP Best Practices – International Benchmarking Study". ISBN 1-59229-031-0. [13] What is ERP?, http:/ / www. tech-faq. com/ erp. shtml [14] CRITICAL ISSUES AFFECTING AN ERP IMPLEMENTATION, http:/ / carl. sandiego. edu/ gba573/ critical_issues_affecting_an_erp. htm [15] Ramaswamy V K (2007-09-27). "Data Migration Strategy in ERP" (http:/ / research. ittoolbox. com/ white-papers/ backoffice/ erp/ data-migration-strategies-in-erp-4620/ ). . Retrieved 2008-04-08. [16] Turban et al. (2008). Information Technology for Management, Transforming Organizations in the Digital Economy. Massachusetts: John Wiley & Sons, Inc., pp. 300-343. ISBN 978-0-471-78712-9 [17] Brown, C., and I. Vessey, "Managing the Next Wave of Enterprise Systems: Leveraging Lessons from ERP," MIS Quarterly Executive, 2(1), 2003. [18] King. W., "Ensuring ERP implementation success," Information Systems Management, Summer 2005. [19] Yusuf, Y., A. Gunasekaran, and M. Abthorpe, "Enterprise Information Systems Project Implementation: A Case Study of ERP in Rolls-Royce," International Journal of Production Economics, 87(3), February 2004. [20] "Requirements Engineering for Cross-organizational ERP Implementation: Undocumented Assumptions and Potential Mismatches" (http:/ / www. vital-project. org/ papers/ Daneva-Wieringa-Camera-Ready-RE-Paper. pdf) (PDF). University of Twente. . Retrieved 2008-07-12. [21] Turban et al. (2008). Information Technology for Management, Transforming Organizations in the Digital Economy. Massachusetts: John Wiley & Sons, Inc., p. 320. ISBN 978-0-471-78712-9 [22] Dehning,B. and T.Stratopoulos, 'Determinants of a Sustainable Competitive Advantage Due to an IT-enabled Strategy,' Journal of Strategic Information Systems, Vol. 12, 2003 [23] Walsh, Katherine (January 2008). "The ERP Security Challenge" (http:/ / www. csoonline. com/ article/ 216940/ The_ERP_Security_Challenge). CSOonline. CXO Media Inc. . Retrieved 2008-01-17. [24] http:/ / www. cio. com/ article/ 40323 [25] http:/ / opensourceerpguru. com/ 2009/ 02/ 25/ erp-history/

35

Project slippage

Project slippage In project planning, a slippage is the act of missing a deadline. It can be an arbitrary milestone put in place to help track progress. To avoid slippage, one must plan his or her projects (especially research) carefully to avoid delays in schedule. Using Gantt charts and timeline diagrams can help.[1]

References [1] Software Reality (http:/ / www. softwarereality. com/ lifecycle/ research_projects. jsp)

Project charter In project management, a project charter or project definition (sometimes called the terms of reference) is a statement of the scope, objectives and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project. The project charter is usually a short document that refers to more detailed documents such as a new offering request or a request for proposal. In Initiative for Policy Dialogue (IPD), this document is known as the project charter. In customer relationship management (CRM), it is known as the project definition report. Both IPD and CRM require this document as part of the project management process. The project charter establishes the authority assigned to the project manager, especially in a matrix management environment. It is considered industry best practice. The purpose of the project charter is to document: • • • •

Reasons for undertaking the project Objectives and constraints of the project Directions concerning the solution Identities of the main stakeholders

The three main uses of the project charter: • To authorize the project - using a comparable format, projects can be ranked and authorized by Return on Investment. • Serves as the primary sales document for the project - ranking stakeholders have a 1-2 page summary to distribute, present, and keep handy for fending off other project or operations runs at project resources. • As a focus point throughout the project - for example: project as people walk in to team meetings and use in change control meetings to ensure tight scope management.

External links • A Small Series of Articles on Creating the Project Charter [1]

References [1] http:/ / www. pmhut. com/ ?s=%22How+ to+ Write+ a+ Project+ Charter+ -+ Part%22

36

Software bloat

Software bloat Software bloat is a term used to describe the tendency of newer computer programs to have a larger installation footprint, or have many unnecessary features that are not used by end users, or just generally use more system resources than necessary, while offering little or no benefit to its users. Bloatware, or foistware, is also used to describe software that comes pre-installed on a computer when it's bought, mostly consisting of time-limited trials or feature-lacking basic or "beginner" versions.

Causes Software developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[1] In part, this is because technological advances have since multiplied processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available has led to tools which allow easier development of code, with less priority given to end efficiency. Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats. Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing. In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth[2] , Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to Netscape: "Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."[3] Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.

37

Software bloat

38

Examples Comparison of Microsoft Windows minimum hardware requirements (for 32-bit versions). Windows version

25MHz

4 MB

~50 MB

[5]

66MHz

16 MB

~200 MB

133MHz

32 MB

650 MB

233MHz

64 MB

1.5 GB

512 MB

15 GB

1 GB

16 GB

Windows 98

[6]

Windows 2000 [7]

(2001)

[8]

Windows Vista

[9]

Windows 7

Hard disk

[4]

Windows 95

Windows XP

Processor Memory

(2007) 800MHz

(2009)

1GHz

Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform[10] [11] , with former PC World editor Ed Bott accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.[12] Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." [13] [14] Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.[15] The minimum hardware requirements for 64-bit versions of Windows 7 are 2GB RAM and 20GB hard disk space, compared to 1GB RAM and 16GB hard disk space required for 32-bit versions of Windows 7.[16] CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated.[17] Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups. Apart from superfluous features, time constraints may result in remnants of old code being included when new versions of a program are built. A good example is Adobe's Acrobat Reader; long the standard in PDF readers, it has grown with each version, with the current installation package at 37 MB; in contrast, other PDF readers may have much smaller installation packages, such as Foxit Reader, whose installation package is 5.11 MB.

Alternatives to software bloat Some applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program. Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features. Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the obvious disadvantage that a user who

Software bloat wants a specific set of features must compile the program from source. Sometimes software becomes bloated because of "creeping featurism"[18] (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".

See also • • • • • • •

Code bloat Computing minimalism Feature creep Zawinski's Law of Software Envelopment Bullet-point engineering Foistware Enhanced remake

References [1] Eric S. Raymond The Art of Unix Programming, Addison-Wesley Professional, 1st edition (September 17, 2003) On-line HTML version (http:/ / www. catb. org/ ~esr/ writings/ taoup/ html/ why_not_c. html). Accessed 16 June 2007 [2] Strategy Letter IV: Bloatware and the 80/20 Myth - Joel on Software (http:/ / www. joelonsoftware. com/ articles/ fog0000000020. html) [3] "easter eggs." (http:/ / www. jwz. org/ doc/ easter-eggs. html) [4] "Microsoft KB: Windows 95 Installation Requirements" (http:/ / support. microsoft. com/ kb/ 138349/ ). . [5] "Microsoft KB: Minimum Hardware Requirements for a Windows 98 Installation" (http:/ / support. microsoft. com/ kb/ 182751/ ). . [6] "Windows 2000 Server Getting Started: Chapter 3 - Planning Your Windows 2000 Server Installation" (http:/ / www. microsoft. com/ technet/ prodtechnol/ windows2000serv/ proddocs/ srvgs/ sgsch03. mspx#EMD). . [7] "Microsoft KB: System requirements for Windows XP operating systems" (http:/ / support. microsoft. com/ kb/ 314865/ en-us). . [8] "Microsoft KB: System requirements for Windows Vista" (http:/ / support. microsoft. com/ kb/ 919183/ ). . [9] "Microsoft: System requirements for Windows 7" (http:/ / windows. microsoft. com/ en-us/ windows7/ products/ system-requirements). . [10] Steve Streza. "What happened to iTunes?" (http:/ / stevestreza. com/ 2007/ 03/ 07/ what-happened-to-itunes/ ). . [11] Buchanan, Matt (2009-10-12). "iTunes 9 Will Be a Bloated Social Monster" (http:/ / gizmodo. com/ 5335754/ itunes-9-will-be-a-bloated-social-monster). Gizmodo. . Retrieved 2010-01-14. [12] Bott, Ed (2008-10-03). "Slimming down the bloated iTunes installer" (http:/ / blogs. zdnet. com/ Bott/ ?p=554). ZDNet. . Retrieved 2010-01-14. [13] informationweek.com (http:/ / www. informationweek. com/ news/ showArticle. jhtml?articleID=205920302) [14] http:/ / www. zdnet. com/ blog/ bott/ is-minwin-really-the-new-windows-7-kernel/ 418 [15] Ed Bott. "Windows bloat? It’s always been that way" (http:/ / blogs. zdnet. com/ Bott/ ?p=18#more-18). . [16] http:/ / www. microsoft. com/ windows/ windows-7/ get/ system-requirements. aspx [17] Cassia, Fernando (2007-02-27). "'Nero Lite' and 'Nero Micro': smaller sometimes is better" (http:/ / www. theinquirer. net/ default. aspx?article=37873). The Inquirer. . Retrieved 2007-03-07. [18] "The Designer's Notebook" (http:/ / www. gamasutra. com/ features/ 20070501/ adams_01. shtml): "creeping featurism produces a bloated, complicated mess"

39

Megaprojects and Risk

Megaprojects and Risk Megaprojects and Risk: An Anatomy of Ambition (ISBN 0521009464) is a 2003 book by Bent Flyvbjerg, Nils Bruzelius, and Werner Rothengatter dealing with the risks and legalities of promotion, policy, planning, and construction of megaprojects. The book's central theme is that promoters of multibillion-dollar megaprojects may misinform lawmakers, the media, and the public in order to obtain construction approval for megaprojects.

Themes Megaprojects are multi-billion dollar infrastructure developments. The authors suggest that megaprojects, despite their actual and symbolic importance, ‘have strikingly poor performance records in terms of economy, environment and public support’.[1] This observation is backed up by empirical evidence showing that the studies used to justify transport megaprojects typically underestimate costs and overestimate benefits, sometimes by orders of magnitude. The authors investigate the processes behind the approval and implementation of megaprojects. The primary focus is on transport projects such as international transport links and urban passenger rail networks. Three case studies are offered: the Channel Tunnel; the Great Belt link between East Denmark and Continental Europe and the Øresund link between Sweden and Denmark.[2] The central thesis of the book may be summarised as follows: The typical ex ante evaluation of a large transport project is based on what the World Bank calls EGAP (Everything Going According to Plan). In practice, of course, things do not go according to plan. Occasionally, things go better than expected, as in the case of the Øresund road bridge, which experienced substantially more traffic than was expected. But, more often than not, things go worse than expected. Hence, the EGAP evaluation yields estimated benefit-cost ratios that are biased upwards. The authors find that real cost overruns of between 50 and 100 per cent are common, and overruns above 100 per cent are not uncommon, while demand is typically overestimated, with typical overestimates between 20 and 70 per cent. The tendency to overestimation is particularly severe in the case of urban rail projects. The core of the book is devoted to illustrating the central problem of over-optimism in ex ante evaluations, and discussing the characteristics of the policy process that generate systematic bias on the part of project proponents. The authors make a range of useful suggestions. In addition to the core point regarding overestimation of benefits, the book offers useful discussion of environmental aspects of the megaproject process, and of the costs and benefits of private provision of infrastructure. As regards environmental issues, little has changed since the introduction of environmental impact assessments in the 1970s. Typically, these occur in the middle of the process, after the design phase, and before construction begins. The authors argue for more consistent attention to environmental issues beginning in the design phase and ending with ex post assessments of actual, as compared to predicted, environmental impacts.[3] In the 1980s, the poor performance of infrastructure projects was commonly attributed to public ownership and the associated potential for political concerns to override economics. Privatisation was commonly presented as a panacea. As the authors, observe, however, private provision of infrastructure solves some problems and creates others. Moreover, the complexity of the issues raised by transport megaprojects, including environmental concerns, planning implications and international negotiations is such that the idea of getting politics out of the process is chimerical. Their balanced conclusion (p. 104) is that 'Whilst far from offering a panacea to the risk and accountability problems for megaprojects, given an appropriate and properly implemented institutional framework, private involvement may be helpful’.

40

Megaprojects and Risk

See also • • • • • •

Megaproject Cost overrun Optimism bias Reference class forecasting Risk Strategic misrepresentation

External links • Flyvbjerg, Bent, Nils Bruzelius, and Werner Rothengatter, 2003. Megaprojects and Risk: An Anatomy of Ambition (Cambridge: Cambridge University Press). [4] • What is a megaproject? [5]

References [1] Book Review: Megaprojects and Risk: An Anatomy of Ambition (http:/ / rational. ce. umn. edu/ Reviews/ Flyvbjerg. pdf) [2] Book Review (http:/ / www. trforum. org/ journal/ 2004spr/ article10. php) [3] Megaprojects and Risk: An Anatomy of Ambition (http:/ / www. josephcoates. com/ pdf_files/ 268_Megaprojects_and_Risk. pdf) [4] http:/ / books. google. com/ books?vid=ISBN0521009464& id=RAV5P-50UjEC& printsec=frontcover [5] http:/ / flyvbjerg. plan. aau. dk/ whatisamegaproject. php

Megaproject A megaproject (sometimes also called "major program") is an extremely large-scale investment project. Megaprojects are typically defined as costing more than US$1 billion and attracting a lot of public attention because of substantial impacts on communities, environment, and budgets.[1] Megaprojects can also be defined as "initiatives that are physical, very expensive, and public."[2] Care in the project development process may be needed to reduce any possible optimism bias and strategic misrepresentation.[1] Megaprojects include bridges, tunnels, highways, railways, airports, seaports, power plants, dams, wastewater projects, Special Economic Zones, oil and natural gas extraction projects, public buildings, information technology systems, aerospace projects, and weapons systems.

The Megaproject Paradox The megaproject paradox was first identified by Oxford professor Bent Flyvbjerg, in his book with Nils Bruzelius and Werner Rothengatter, Megaprojects and Risk[3] . The paradox consists in the fact that more and bigger megaprojects are being planned and built despite their poor performance record in terms of cost overruns, schedule delays, and benefit shortfalls. For the majority of megaprojects, performance is significantly and consistently below what could be called "best" – or "good" – practice, when measured in these terms. This has been the case for decades and existing data show no immediate end to this state of affairs.

41

Megaproject

See also • • • • •

Megaprojects and risk Megastructure Macro-engineering Optimism bias Reference class forecasting

External links • What is a megaproject? [5] • Borovoye-Biocity [4] — megaproject of Bionic City for Kazakhstan — S. Rastorguev, M. Kudryashov, 2008

References [1] Bent Flyvbjerg, Nils Bruzelius, and Werner Rothengatter, 2003. Megaprojects and Risk: An Anatomy of Ambition ISBN 0521009464 (Cambridge: Cambridge University Press). [2] Alan Altshuler and David Luberoff, Mega-Projects: The Changing Politics of Urban Public Investment (Washington, DC: Brookings Institution, 2003). ISBN 0815701292 [3] Bent Flyvbjerg with Nils Bruzelius and Werner Rothengatter, Megaprojects and Risk: An Anatomy of Ambition (Cambridge University Press, 2003). [4] http:/ / cih. ru/ kz/ e1. html

Feature creep Feature creep is the rapid expanding of features in a product such as computer software.[1] Extra features go beyond the basic function of the product and so can result in over-complication, or "featuritis", rather than simple design.

Causes The most common cause of feature creep is the desire to provide the consumer with a more useful or desirable product, in order to increase sales or distribution. However, once the product reaches the point at which it does everything that it is designed to do, the manufacturer is left with the choice of adding unneeded functions, sometimes at the cost of efficiency, or sticking with the old version, at the cost of a perceived lack of improvement.

Characteristics Feature creep is the most common source of cost and schedule overruns.[2] It thus endangers and can even kill products and projects. Apple's abandoned Copland operating system is an example of this.

Control Temptation of later feature creep may be avoided to some degree by basing initial design on strong software fundamentals, such as logical separation of functionality and data access. It can be actively controlled with rigorous change management and by delaying changes to later delivery phases of a project.[3]

42

Feature creep

See also • • • •

Mission creep Overengineering Second-system effect Software bloat

Mitigation • • • • •

Design document KISS principle Minimalism Plug-in (computing) Unix philosophy

External links • http://c2.com/cgi/wiki?CreepingFeaturitis (registered on October 23, 1995 [4] at the latest.)

References [1] J.M. Sullivan (8-10 June 2005), "Impediments to and incentives for automation in the Air Force" (http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all. jsp?arnumber=1452719), 2005 International Symposium on Technology and Society: 101–110, [2] Davis, F.D. and Venkatesh, V. (February 2004), Toward preprototype user acceptance testing of new information systems: implications for software project management (http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all. jsp?arnumber=1266852), 51 issue 1, IEEE Transactions on Engineering Management, ISSN0018-9391, [3] Kenneth S. Norton (2001), Applying Cross-Functional Evolutionary Methodologies to Web Development (http:/ / books. google. com/ ?id=Ak5slktYul8C), paper in Web Engineering: Managing Diversity and Complexity of Web published by Springer, ISBN3540421300, [4] http:/ / web. archive. org/ web/ 19961130075228/ http:/ / c2. com/ cgi/ wiki?CreepingFeaturitis

43

Instruction creep

Instruction creep Instruction creep occurs when instructions increase in number and size over time until they are unmanageable. It can be insidious and damaging to the success of large groups such as corporations, originating from ignorance of the KISS principle and resulting in overly complex procedures that are often misunderstood, followed with great irritation, or ignored. The fundamental fallacy of instruction creep is believing that people read instructions with the same level of attention and comprehension, regardless of the volume or complexity of those instructions. A byproduct is the advent of many new rules having the deliberate intent to control others via fiat, without considering consensus or collaboration. This tends to antagonize others, even when it appears to the instigators that they are acting with proper intent. Instruction creep is common in complex organizations, where rules and guidelines are created by changing groups of people over extended periods of time. The constant state of flux in such groups often leads them to add or modify instructions, rather than simplifying or consolidating existing ones. This can result in considerable overlap in the message of directives, at the expense of clarity, efficiency, and communication, or even of consistency.

See also • Scope creep • Creep (project management)

Creep (project management) Creep (as in functionality-creep, feature-creep, mission-creep and scope-creep) is a problem in project management where the initial objectives of the project are jeopardized by a gradual increase in overall objectives as the project progresses. The need to achieve the new objectives can overwhelm the capacity of the resources allocated to the project resulting in the project missing deadlines, budgets or failing completely.

See also • Instruction creep

44

Cost overrun

Cost overrun Cost overrun is defined as excess of actual cost over budget. Cost overrun is caused by cost underestimation and is sometimes called "cost escalation," "cost increase," or "budget overrun". However, cost escalation and increases do not necessarily result in cost overruns if cost escalation is included in the budget. Cost overrun is common in infrastructure, building, and technology projects. One of the most comprehensive studies [1] of cost overrun that exists found that 9 out of 10 projects had overrun, overruns of 50 to 100 percent were common, overrun was found in each of 20 nations and five continents covered by the study, and overrun had been constant for the 70 years for which data were available. For IT projects, an industry study by the Standish Group (2004) found that average cost overrun was 43 percent, 71 percent of projects were over budget, over time, and under scope, and total waste was estimated at US$55 billion per year in the US alone. Spectacular examples of cost overrun are the Sydney Opera House with 1,400 percent, and the Concorde supersonic aeroplane with 1,100 percent. The cost overrun of Boston's Big Dig was 275 percent, or US$11 billion. The cost overrun for the Channel tunnel between the UK and France was 80 percent for construction costs and 140 percent for financing costs. Three types of explanation of cost overrun exist: technical, psychological, and political-economic. Technical explanations account for cost overrun in terms of imperfect forecasting techniques, inadequate data, etc. Psychological explanations account for overrun in terms of optimism bias with forecasters. Finally, political-economic explanations see overrun as the result of strategic misrepresentation of scope and/or budgets. All of the explanations above can be considered a form of risk. A project's budgeted costs should always include cost contingency funds to cover risks (other than scope changes imposed on the project). As has been shown in cost engineering research [2] , poor risk analysis and contingency estimating practices account for many project cost overruns. Numerous studies have found that the greatest cause of cost growth was poorly defined scope at the time that the budget was established. The cost growth (overrun of budget before cost contingency is added) can be predicted by rating the extent of scope definition, even on complex projects with new technology. [3] Cost overrun is typically calculated in one of two ways. Either as a percentage, namely actual cost minus budgeted cost, in percent of budgeted cost. Or as a ratio, viz. actual cost divided by budgeted cost. For example, if the budget for building a new bridge was $100 million and the actual cost was $150 million then the cost overrun may be expressed as 50 percent or by the ratio 1.5.

List of projects with large cost overruns Australia • •

Sydney Olympic Park Sydney Opera House

Brazil •

Brasília

Denmark •

Great Belt railway tunnel

Egypt •

Suez Canal

45

Cost overrun

Japan •

Joetsu Shinkansen high-speed rail line

Malaysia •

Pergau Dam

North Korea •

Ryugyong Hotel

Panama •

Panama Canal

Sweden • •

Göta Canal Hallandsås Tunnel

United Kingdom • • • • •

Humber Bridge Millennium Dome National Programme for IT Scottish Parliament Building TAURUS (share trading)

United States • • • • • • •

Big Dig Denver International Airport Eastern span replacement of the San Francisco–Oakland Bay Bridge F-22 Raptor Joint Strike Fighter Program NPOESS V-22 Osprey

Multinational • • • • • • • • •

Airbus A380 Airbus A400M Channel Tunnel Cologne Cathedral Concorde Eurofighter Pickering Nuclear Generating Station Montreal Olympic Stadium Rogers Centre (formerly SkyDome)

46

Cost overrun

See also • • • • • • •

Admissible heuristic Benefit shortfall Cost underestimation Megaproject Optimism bias Reference class forecasting Strategic misrepresentation

Bibliography • Flyvbjerg, Bent, Nils Bruzelius, and Werner Rothengatter, Megaprojects and Risk: An Anatomy of Ambition (Cambridge University Press, 2003). [4] • Flyvbjerg, Bent, Mette K. Skamris Holm, and Søren L. Buhl, 2002, "Underestimating Costs in Public Works Projects: Error or Lie?" Journal of the American Planning Association, vol. 68, no. 3, 279-295. [1] • Standish Group, 2004. CHAOS Report (West Yarmouth, MA: Author) • UK Department for Transport, 2004. Procedures for Dealing with Optimism Bias in Transport Planning: Guidance Document (London). [5] • [6] Tunnel's cost may fool us all Seattle Times April 26, 2009 Seattle Times • Flyvbjerg, Bent, Mette K. Skamris Holm, and Søren L. Buhl, 2002, "Underestimating Costs in Public Works Projects: Error or Lie?" Journal of the American Planning Association, vol. 68, no. 3, 279-295. [1] • UK Department for Transport, 2004. Procedures for Dealing with Optimism Bias in Transport Planning: Guidance Document (London). [5]

External links • UK Department for Transport: [5] • UK Treasury [7]

References [1] http:/ / flyvbjerg. plan. aau. dk/ JAPAASPUBLISHED. pdf [2] Hackney, John W. (Kenneth H. Humprhies, Editor), Control and Management of Capital Projects, 2nd Edition, AACE International, 1997 [3] Merrow, Edward W., Kenneth E. Phillips, and Christopher W. Meyers, Understanding Cost Growth and Performance Shortfalls in Pioneer Process Plants, (R-2569-DOE), Rand Corporation, 1981 [4] http:/ / books. google. com/ books?vid=ISBN0521009464& id=RAV5P-50UjEC& pg=PA1& lpg=PA1& dq=Megaprojects+ and+ Risk:+ An+ Anatomy+ of+ Ambition& sig=tyt4h0TwEnf7NDKcG1WY8Qw2VQI [5] http:/ / www. dft. gov. uk/ stellent/ groups/ dft_localtrans/ documents/ downloadable/ dft_localtrans_029632. pdf [6] http:/ / seattletimes. nwsource. com/ html/ dannywestneat/ 2009123442_danny26. html [7] http:/ / www. hm-treasury. gov. uk/ economic_data_and_tools/ greenbook/ data_greenbook_index. cfm

47

Mission creep

Mission creep Mission creep is the expansion of a project or mission beyond its original goals, often after initial successes.[1] The term often implies a certain disapproval of newly adopted goals by the user of the term. Mission creep is usually considered undesirable due to the dangerous path of each success breeding more ambitious attempts, only stopping when a final, often catastrophic, failure occurs. The term was originally applied exclusively to military operations, but has recently been applied to many different fields, mainly the growth of bureaucracies.

Rediscovery The phrase "mission creep" appeared in articles concerning the UN Peacekeeping mission in Somalia in the Washington Post on April 15, 1993 and in the New York Times on October 10, 1993.

Headline news The first two articles to use the term in the Washington Post were both by columnist Jim Hoagland ("Prepared for Non-Combat", April 15, 1993 and Beware 'mission creep' In Somalia, July 20, 1993). The New York Times used the term for the first time in an article by correspondent John H. Cushman, Jr. written after the October 4, 1993 firefight in the capital of Somalia, Mogadishu, in which 16 Americans were killed. The U.S. and later UN Mission in Somalia (Restore Hope) would seem to be the classic example of mission creep. Begun in late 1992 as a U.S. humanitarian relief operation in the final months of the George H. W. Bush administration, the intervention was converted to a U.N. operation on June 4, 1993. While the initial Bush administration justification for entering Somalia focused on "humanitarian assistance," realities on the ground helped drive ever growing requirements. On June 5, 1993, Somali warlord Mohamed Farrah Aidid's clan forces killed 23 Pakistani peacekeepers who were part of the UNISOM II mission. This battle led to a UN Security Council decision seeking to capture those responsible for the deaths of the Pakistani peacekeepers. Along with growing objectives seeking longer term stability (rather than short-term humanitarian assistance), the search for Aidid fostered a more confrontational environment through summer 1993. In October 1993, 18 American soldiers died in the Battle of Mogadishu. This incident led to a much more defensive U.S. and UN presence in Somalia. U.S. forces withdrew in early 1994 and all UN forces were withdrawn at late February, early March 1995 via Operation United Shield.

Other examples An earlier example of mission creep, apparently from before the term was first used, is the Korean War.[2] It began as an attempt to save South Korea from invasion by the North, but after that initial success expanded to an attempt to reunite the peninsula, a goal that eventually proved unattainable. That attempt resulted in a long and costly retreat through North Korea after the intervention of the Chinese. NBC reporter David Gregory has cited the Vietnam War as an important example of mission creep, defining it as "the idea of, you know, gradually surging up forces, having nation-building goals, and running into challenges all along the way."[3] Although the term mission creep is relatively new, examples can be observed throughout military history. For instance, many of the wars of Louis XIV's France began with small limited goals, but quickly escalated to much larger affairs. When mission creep does not occur it can also bring criticism. After the defeat of the totalitarian powers of Germany, Italy, and Japan in World War II, some thought the Allies should build on their success and attack Francisco Franco's Spain or the Soviet Union. There are continued criticisms that the American led coalition should have ousted Saddam Hussein at the end of the first Gulf War after the ease with which the Iraqi forces were expelled from Kuwait, although the outcome of the Iraq War has to some degree reduced their vehemence.

48

Mission creep

See also • • • •

Feature creep is an analogous phenomenon in software engineering. Scope creep is an analogous phenomenon in project management. Ratchet effect is the inability of a system to reduce its scope once it expands. Bracket creep is the slow movement of lower income individuals to higher tax brackets as a result of inflation.

References [1] Three Decades of Mission Creep Loy: "The 'Do More With Less' Well Has Run Dry" last retrieved February 15, 2007. (http:/ / www. navyleague. org/ seapower/ three_decades_of_mission_creep. htm) [2] Exit Strategy Delusions last retrieved February 15, 2007. (http:/ / www. carlisle. army. mil/ usawc/ Parameters/ 01winter/ record. htm) [3] JCS Speech - Meet the Press (http:/ / www. jcs. mil/ speech. aspx?id=1235). Joint Chiefs of Staff website (http:/ / www. jcs. mil/ ). Accessed August 24, 2009.

Waterfall model The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and Maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce,[1] although Royce did not use the term "waterfall" in this article. The unmodified "waterfall model". Progress flows from the top to the bottom, like a Royce was presenting this model as an waterfall. example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.[2]

49

Waterfall model

Model In Royce's original Waterfall model, the following phases are followed in order: 1. 2. 3. 4. 5. 6. 7.

Requirements specification Design Construction (AKA implementation or coding) Integration Testing and debugging (AKA Validation) Installation Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a sequential manner. For example, one first completes requirements specification, which after sign-off are considered "set in stone." When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

Supporting arguments Time spent early in the software production cycle can lead to greater economy at later stages. It has been shown that a bug found in the early stages (such as requirements specification or design) is cheaper in terms of money, effort and time, to fix than the same bug found later on in the process. ([McConnell 1996], p.72, estimates that "a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.") To take an extreme example, if a program design turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design. This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent early on making sure that requirements and design are absolutely correct will save you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation. Program requirements should be set in stone before design is started (otherwise work put into a design based on incorrect requirements is wasted); the program's design should be perfect before people begin work on implementing the design (otherwise they are implementing the wrong design and their work is wasted), etc. A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. In less designed and documented methodologies, should team members leave, much knowledge is lost and may be difficult for a project to recover from. Should a fully working design document be present (as is the intent of Big Design Up Front and the waterfall model) new team members or even entirely new teams should be able to familiarize themselves by reading the documents. As well as the above, some prefer the waterfall model for its simple approach and argue that it is more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily markable milestones in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and

50

Waterfall model courses. It is argued that the waterfall model and Big Design up Front in general can be suited to software projects which are stable (especially those projects with unchanging requirements, such as with shrink wrap software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly.

Criticism The waterfall model is argued by many to be a bad idea in practice. This is mainly because of their belief that it is impossible for any non-trivial project to get one phase of a software product's lifecycle perfected, before moving on to the next phases and learning from them. For example, clients may not be aware of exactly what requirements they need before reviewing a working prototype and commenting on it; they may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front. Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas. Even without such changing of the specification during implementation, there is the option either to start a new project from scratch, "on a green field", or to continue some already existing, "a brown field" (from construction again). The waterfall methodology can be used for continuous enhancement, even for existing software, originally from another team. As well as in the case when the system analyst fails to capture the customer requirements correctly, the resulting impacts on the following phases (mainly the coding) still can be tamed by this methodology, in practice: A challenging job for a QA team. Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a "wicked problem" — a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase. David Parnas, in "A Rational Design Process: How and Why to Fake It", writes:[3] “Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.” The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to prepare the software for the update. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the software with respect to the design.

51

Waterfall model

Modified models In response to the perceived problems with the pure waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the pure waterfall model. Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules. While all software development models will bear some similarity to the waterfall model, as all software development models will incorporate at least some phases similar to those used within the waterfall model, this section will deal with those closest to the waterfall model. For models which apply further differences to the waterfall model, or for radically different models seek general information on the software development process.

Sashimi model The Sashimi model (so called because it features overlapping phases, like the overlapping fish of Japanese sashimi) was originated by Peter DeGrace. It is sometimes referred to as the "waterfall model with overlapping phases" or "the waterfall model with feedback". Since phases in the sashimi model overlap, information of problem spots can be acted upon during phases that would typically, in the pure waterfall model, precede others. For example, since the design and implementation phases will overlap in the sashimi model, implementation problems may be discovered during the design and implementation phase of the development process. This helps alleviate many of the problems associated with the Big Design Up Front philosophy of the waterfall model.

See also • • • • • • • • • • • •

Agile software development Big Design Up Front Chaos model Iterative and incremental development Iterfall development Rapid application development Software development process Spiral model System Development Methodology, V-model Dual Vee Model List of software development philosophies

Further reading This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL. • McConnell, Steve (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. ISBN0-7356-0535-1. • McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN1-55615-484-4. • McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN1-55615-900-5. • Parnas, David, A rational design process and how to fake it (PDF) [4] An influential paper which criticises the idea that software production can occur in perfectly discrete phases. • Royce, Winston (1970), "Managing the Development of Large Software Systems" [5], Proceedings of IEEE WESCON 26 (August): 1–9.

52

Waterfall model • "Why people still believe in the waterfall model" [6] • The standard waterfall model for systems development [7] NASA webpage, archived on Internet Archive March 10, 2005. • Parametric Cost Estimating Handbook [8], NASA webpage based on the waterfall model, archived on Internet Archive March 8, 2005.

External links • • • • •

Understanding the pros and cons of the Waterfall Model of software development [9] "Waterfall model considered harmful" [10] Project lifecycle models: how they differ and when to use them [11] Going Over the Waterfall with the RUP [12] by Philippe Kruchten CSC and IBM Rational join to deliver C-RUP and support rapid business change [13]

References [1] Wasserfallmodell > Entstehungskontext (http:/ / cartoon. iguw. tuwien. ac. at/ fit/ fit01/ wasserfall/ entstehung. html), Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007. [2] Conrad Weisert, Waterfall methodology: there's no such thing! (http:/ / www. idinews. com/ waterfall. html) [3] "A Rational Design Process: How and Why to Fake It" (http:/ / www. cs. tufts. edu/ ~nr/ cs257/ archive/ david-parnas/ fake-it. pdf), David Parnas (PDF file) [4] http:/ / users. ece. utexas. edu/ ~perry/ education/ SE-Intro/ fakeit. pdf [5] http:/ / www. cs. umd. edu/ class/ spring2003/ cmsc838p/ Process/ waterfall. pdf [6] http:/ / tarmo. fi/ blog/ 2005/ 09/ 09/ dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/ [7] http:/ / web. archive. org/ web/ 20050310133243/ http:/ / asd-www. larc. nasa. gov/ barkstrom/ public/ The_Standard_Waterfall_Model_For_Systems_Development. htm [8] http:/ / cost. jsc. nasa. gov/ PCEHHTML/ pceh. htm [9] http:/ / articles. techrepublic. com. com/ 5100-10878_11-6118423. html?part=rss& tag=feed& subj=tr [10] http:/ / www. it-director. com/ technology/ productivity/ content. php?cid=7865 [11] http:/ / www. business-esolutions. com/ islm. htm [12] http:/ / www-128. ibm. com/ developerworks/ rational/ library/ 4626. html [13] http:/ / www. ibm. com/ developerworks/ rational/ library/ 3012. html

53

IBM Rational Unified Process

IBM Rational Unified Process The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

History The Rational Unified Process (RUP) is a software process product, originally developed by Rational Software, which was acquired by IBM in February 2003. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process. By 1997, Rational had acquired Verdix, Objectory, Requisite, SQA, Performance Awareness, and Pure-Atria. Combining the experience base of these companies led to the articulation of six best practices for modern software engineering: 1. Develop iteratively, with risk as the primary iteration driver 2. 3. 4. 5. 6.

Manage requirements Employ a component-based architecture Model software visually Continuously verify quality Control changes

These best practices both drove the development of Rational's products, and were used by Rational's field teams to help customers improve the quality and predictability of their software development efforts. To make this knowledge more accessible, Philippe Kruchten, a Rational techrep, was tasked with the assembly of an explicit process framework for modern software engineering. This effort employed the HTML-based process delivery mechanism developed by Objectory. The resulting "Rational Unified Process" (RUP) completed a strategic tripod for Rational: • a tailorable process that guided development • tools that automated the application of that process • services that accelerated adoption of both the process and the tools.

Rational Unified Process topics RUP building blocks RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. The main building blocks, or content elements, are the following: • Roles (who) – A Role defines a set of related skills, competencies, and responsibilities. • Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process. • Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result. Within each iteration, the tasks are categorized into nine disciplines: six "engineering disciplines" (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment) and three supporting disciplines (Configuration and Change Management, Project Management, Environment).

54

IBM Rational Unified Process

55

Four Project Lifecycle Phases The RUP has determined a project lifecycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished. The visualisation of RUP phases and disciplines over time is referred to as the RUP hump chart.

RUP phases and disciplines.

Inception Phase The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria: • • • • •

Stakeholder concurrence on scope definition and cost/schedule estimates. Requirements understanding as evidenced by the fidelity of the primary use cases. Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype that was developed. Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria. Elaboration Phase The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. This phase must pass the Lifecycle Architecture Milestone by meeting the following deliverables: • A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete. • A description of the software architecture in a software system development process. • An executable architecture that realizes architecturally significant use cases. • Business case and risk list which are revised. • A development plan for the overall project. • Prototypes that demonstrably mitigate each identified technical risk. If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. However, after leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental

IBM Rational Unified Process when made. The key domain analysis for the elaboration is the system architecture. Construction Phase The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes. This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone. Transition Phase The primary objective is to 'transition' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If all objectives are met, the Product Release Milestone is reached and the development cycle ends.

Six Engineering Disciplines Business Modeling Discipline Business modeling explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities. Organizations are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organization. Businesses invest in IT when they understand the competitive advantage and value added by the technology. The aim of business modeling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization (the client), the current problems in the organization, and possible improvements. They must also ensure a common understanding of the target organization between customers, end users and developers. Requirements Discipline Requirements explain how to elicit stakeholder requests and transform them into a set of requirements work products that scope the system to be built and provide detailed requirements for what the system must do. Analysis and Design Discipline The goal of analysis and design is to show how the system will be realized. The aim is to build a system that: • Performs — in a specific implementation environment — the tasks and functions specified in the use-case descriptions. • Fulfills all its requirements. • Is easy to change when functional requirements change. Designs results into a design model and analysis optionally into an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. The design model consists of design classes structured into packages and subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases. Implementation Discipline

56

IBM Rational Unified Process The purposes of implementation are: • • • •

To define the organization of the code in terms of implementation subsystems that are organized in layers. To implement classes and objects in terms of components (source files, binaries, executables, and others). To test the developed components as units. To integrate the results produced by individual implementers (or teams) into an executable system. Systems are realized through the implementation of components. The process describes how to reuse existing components, or implement new components with well-defined responsibility, making the system easier to maintain and increasing the possibilities to reuse.

Test Discipline The purposes of test are: • • • • •

To verify the interaction between objects. To verify the proper integration of all components of the software. To verify that all requirements have been correctly implemented. To identify and ensure that defects are addressed prior to the deployment of the software. Ensure that all the defects are fixed, retested, and closed. The Rational Unified Process proposes an iterative approach, which means that testing occurs throughout the project. This allows the detection of defects as early as possible, which radically reduces the cost of fixing the defect. Tests are carried out along four quality dimensions: Reliability, Functionality, Application Performance, and System Performance. For each of these quality dimensions, the process describes how to go through the test lifecycle of planning, design, implementation, execution, and evaluation.

Deployment Discipline The purpose of deployment is to successfully produce product releases, and to deliver the software to its end users. It covers a wide range of activities including producing external releases of the software, packaging the software and business application, distributing the software, installing the software, and providing help and assistance to users. Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase. The Deployment and Environment workflows of the Rational Unified Process contain less detail than other workflows.

Three supporting disciplines Environment discipline The environment discipline focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team. If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. However a key concept within RUP was that the RUP process could and often should itself be refined. This was initially done manually, ie by writing a "Development case" document that specified the refined process to be used. Later the IBM Rational Method Composer product was created to help make this step simpler, so process engineers and project managers could more easily customize the RUP for their project needs. Many of the later variants of RUP, including OpenUP/Basic, the lightweight and open source version of RUP, are now presented as separate processes in their own right, and cater for different types and sizes of projects and trends and technologies in software development. Historically, as the RUP is often customized for each project by a RUP process expert, the project's overall success can be somewhat dependent on the abilities of this one person.

57

IBM Rational Unified Process Configuration and Change management discipline The Change Management discipline in RUP deals with three specific areas: configuration management, change request management, and Status and measurement management. • Configuration management: Configuration management is responsible for the systematic structuring of the products. Artifacts such as documents and models need to be under version control and these changes must be visible. It also keeps track of dependencies between artifacts so all related articles are updated when changes are made. • Change request management: During the system development process many artifacts with several versions exist. CRM keeps track of the proposals for change. • Status and measurement management: Change requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. These states and attributes are stored in database so useful reports about the progress of the project can be produced. Rational also has a product to maintain change requests called ClearQuest. This activity has procedures to be followed. Project management discipline The Project management discipline and project planning in the RUP occur at two levels. There is a coarse-grained or Phase plan which describes the entire project, and a series of fine-grained or Iteration plans which describe the iterations. This discipline focuses mainly on the important aspects of an iterative development process: Risk management, Planning an iterative project, through the lifecycle and for a particular iteration, and Monitoring progress of an iterative project, metrics. However, this discipline of the RUP does not attempt to cover all aspects of project management. For example, it does not cover issues such as: • Managing people: hiring, training, etc. • Managing budget: defining, allocating, etc. • Managing contracts: with suppliers, with customers, etc. The project management discipline contains a number of other Plans and Artifacts that are used to control the project and monitoring its performance. Such Plans are: • The Phase Plan (The Software Development Plan) • The Iteration Plan Phase plan Each Phase is treated as a project, controlled and measured by the Software Development Plan which is grouped from a subset of monitoring plans: • The Measurement Plan defines the measurement goals, the associated metrics, and the primitive metrics to be collected in the project to monitor its progress. • The Risk Management Plan details how to manage the risks associated with a project. It details the risk management tasks that will be carried out, assigned responsibilities, and any additional resources required for the risk management activity. On a smaller scale project, this plan may be embedded within the Software Development Plan. • The Risk list is a sorted list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions. • The Problem Resolution Plan describes the process used to report, analyze, and resolve problems that occur during the project. • The Product Acceptance Plan describes how the customer will evaluate the deliverable artifacts from a project to determine if they meet a predefined set of acceptance criteria. It details these acceptance criteria, and identifies

58

IBM Rational Unified Process the product acceptance tasks (including identification of the test cases that need to be developed) that will be carried out, and assigned responsibilities and required resources. On a smaller scale project, this plan may be embedded within the Software Development Plan. Iteration plan The iteration plan is a fine-grained plan with a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration. There are typically two iteration plans active at any point in time. • The current iteration plan is used to track progress in the current iteration. • The next iteration plan is used to plan the upcoming iteration. This plan is prepared toward the end of the current iteration. To define the contents of an iteration you need: • • • • •

the project plan the current status of the project (on track, late, large number of problems, requirements creep, etc.) a list of scenarios or use cases that must be completed by the end of the iteration a list of risks that must be addressed by the end of the iteration a list of changes that must be incorporated in the product (bug fixes, changes in requirements)

These lists must be ranked. The objectives of an iteration should be aggressive so that when difficulties arise, items can be dropped from the iterations based on their ranks. Therefore there is a set of supported Artifacts that help in measuring and building each iteration plan. Work Product (Artifact) IBM has replaced the term "Artifact" with the term "work product". The work products used are: • The Iteration Assessment captures the result of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes to be done. • The project measurements is the project's active repository of metrics data. It contains the most current project, resources, process, and product measurements at the primitive and derived level. • The periodic Status Assessment provides a mechanism for managing everyone's expectations throughout the project lifecycle to ensure that the expectations of all parties are synchronized and consistent. • The work order is the Project Manager's means of communicating with the staff about what is to be done and when it is to be completed. It becomes an internal contract between the Project Manager and those assigned responsibility for completion. • The Issues List is a way to record and track problems, exceptions, anomalies, or other incomplete tasks requiring attention.

The IBM Rational Method Composer product The IBM Rational Method Composer product is a tool for authoring, configuring, viewing, and publishing processes. See IBM Rational Method Composer and an open source version Eclipse Process Framework (EPF) project for more details.

Certification In January 2007, the new RUP certification examination for IBM Certified Solution Designer - Rational Unified Process 7.0 was released which replaces the previously called IBM Rational Certified Specialist - Rational Unified Process.[1] The new examination will not only test knowledge related to the RUP content but also to the process structure elements.[2]

59

IBM Rational Unified Process To pass the new RUP certification examination, a person must take IBM's Test 839: Rational Unified Process v7.0. You are given 75 minutes to take the 52 question exam. The passing score is 62%.[3]

Six Best Practices Six Best Practices as described in the Rational Unified Process is a paradigm in software engineering, that lists six ideas to follow when designing any software project to minimize faults and increase productivity . These practices are:[4] [5] Develop iteratively It is best to know all requirements in advance; however, often this is not the case. Several software development processes exist that deal with providing solution on how to minimize cost in terms of development phases. Manage requirements Always keep in mind the requirements set by users. Use components Breaking down an advanced project is not only suggested but in fact unavoidable. This promotes ability to test individual components before they are integrated into a larger system. Also, code reuse is a big plus and can be accomplished more easily through the use of object-oriented programming. Model visually Use diagrams to represent all major components, users, and their interaction. "UML", short for Unified Modeling Language, is one tool that can be used to make this task more feasible. Verify quality Always make testing a major part of the project at any point of time. Testing becomes heavier as the project progresses but should be a constant factor in any software product creation. Control changes Many projects are created by many teams, sometimes in various locations, different platforms may be used, etc. As a result it is essential to make sure that changes made to a system are synchronized and verified constantly. (See Continuous integration).

Other frameworks Refinements and variations • Unified Process - The generic Unified Process, and ... • Open Unified Process (OpenUP) - An open source software development process, created as part of the Eclipse Process Framework (EPF) project. Simplified subsets: • Agile Unified Process - a simplified RUP, featuring "Test Driven development" • Essential Unified Process (EssUP) - a model that simplifies The Agile Unified Process • OpenUP/Basic - The most agile and lightweight form of OpenUP, targets small and collocated teams interested in agile and iterative development. • UPEDU - The Unified Process for Education - a subset of RUP for presenting within the education system Expanded supersets: • Enterprise Unified Process - has wider scope, including software purchase, production operations and support, product retirement and replacement etc.

60

IBM Rational Unified Process Supporting Specific Commercial Development Products • IBM Tivoli Unified Process (ITUP) • Oracle Unified Method

Competing frameworks and methodologies The referenced methodologies and / or frameworks below do not necessarily compete with RUP on all fronts, but do so to differing degrees • • • • • • •

Cleanroom Software Engineering Dynamic Systems Development Method (DSDM) ICONIX Process is a lightweight, agile subset of the RUP practices Extreme Programming useful for small software projects with ultra low risk Microsoft Solutions Framework (MSF) Oracle Unified Method (OUM) OpenUP is an OpenSource lightweight agile version of RUP supported by IBM Rational, Number Six Software and others • Personal Software Process (PSP) is not a development process, it is a personal management process • Scrum is a lightweight, agile subset of the RUP practices

See also • • • • • • • • • • • •

Agile Modeling Agile Software Development Computer programming Extreme programming Feature Driven Development Project lifecycle Quality assurance Software Architecture Software component Software development process Software engineering Test-driven development

Further reading • • • • • •

Ivar Jacobson, Grady Booch, and James Rumbaugh (1999). The Unified Software Development Process Per Kroll (2003). Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP Per Kroll, Bruce MacIsaac (2006). Agility and Discipline Made Easy: Practices from OpenUP and RUP Philippe Kruchten (1998). The Rational Unified Process: An Introduction Ahmad Shuja, Jochen Krebs (2007). RUP Reference and Certification Guide Walker Royce, Software Project Management, A Unified Framework

61

IBM Rational Unified Process

External links • IBM Rational Unified Process Web Site [6]. • Rational Software at IBM [7]. • Global Rational User Group Community [8].

References [1] Krebs, Jochen (2007-01-15). "The value of RUP certification" (http:/ / www-128. ibm. com/ developerworks/ rational/ library/ jan07/ krebs/ index. html). IBM. . Retrieved 2008-05-13. [2] "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0" (http:/ / www-03. ibm. com/ certify/ certs/ 38008003. shtml). IBM. . Retrieved 2008-05-13. [3] "Test 839: Rational Unified Process v7.0" (http:/ / www-03. ibm. com/ certify/ tests/ ovr839. shtml). IBM. . Retrieved 2008-05-13. [4] Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004. [5] Rational Unified Process white paper (http:/ / www. augustana. ab. ca/ ~mohrj/ courses/ 2000. winter/ csc220/ papers/ rup_best_practices/ rup_bestpractices. html) [6] http:/ / www-306. ibm. com/ software/ awdtools/ rup/ ?S_TACT=105AGY59& S_CMP=WIKI& ca=dtl-08rupsite [7] http:/ / www. rational. com/ [8] http:/ / www. rational-ug. org/

Requirements management Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.

Overview The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders[1] . Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these. The traceabilities thus established are used in managing requirements to report back fulfillment of company and stakeholder interests, in terms of compliance, completeness, coverage and consistency. Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes.[2] Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project[3] . To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of.

62

Requirements management

Traceability Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable[4] . Requirements come from different sources, like the business person ordering the product, the marketing manager and the actual user. These people all have different requirements for the product. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation. This can, for example, be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment when user studies show that a feature is not used, to see why it was required in the first place.

Requirements activities At each stage in a development process, there are key requirements management activities and methods. To illustrate, consider a standard five-phase development process with Investigation, Feasibility, Design, Construction and Test, and Release stages.

Investigation In Investigation, the first three classes of requirements are gathered from the users, from the business and from the development team. In each area, similar questions are asked; what are the goals, what are the constraints, what are the current tools or processes in place, and so on. Only when these requirements are well understood can functional requirements be developed. A caveat is required here: no matter how hard a team tries, requirements cannot be fully defined at the beginning of the project. Some requirements will change, either because they simply weren’t extracted, or because internal or external forces at work affect the project in mid-cycle. Thus, the team members must agree at the outset that a prime condition for success is flexibility in thinking and operation. The deliverable from the Investigation stage is a requirements document that has been approved by all members of the team. Later, in the thick of development, this document will be critical in preventing scope creep or unnecessary changes. As the system develops, each new feature opens a world of new possibilities, so the requirements specification anchors the team to the original vision and permits a controlled discussion of scope change. While many organizations still use only documents to manage requirements, others manage their requirements baselines using software tools. These tools allow requirements to be managed in a database, and usually have functions to automate traceability (e.g., by allowing electronic links to be created between parent and child requirements, or between test cases and requirements), electronic baseline creation, version control, and change management. Usually such tools contain an export function that allows a specification document to be created by exporting the requirements data into a standard document application.

Feasibility In the Feasibility stage, costs of the requirements are determined. For user requirements, the current cost of work is compared to the future projected costs once the new system is in place. Questions such as these are asked: “What are data entry errors costing us now?” Or “What is the cost of scrap due to operator error with the current interface?” Actually, the need for the new tool is often recognized as these questions come to the attention of financial people in the organization. Business costs would include, “What department has the budget for this?” “What is the expected rate of return on the new product in the marketplace?” “What’s the internal rate of return in reducing costs of training and support if we

63

Requirements management make a new, easier-to-use system?” Technical costs are related to software development costs and hardware costs. “Do we have the right people to create the tool?” “Do we need new equipment to support expanded software roles?” This last question is an important type. The team must inquire into whether the newest automated tools will add sufficient processing power to shift some of the burden from the user to the system in order to save people time. The question also points out a fundamental point about requirements management. A human and a tool form a system, and this realization is especially important if the tool is a computer or a new application on a computer. The human mind excels in parallel processing and interpretation of trends with insufficient data. The CPU excels in serial processing and accurate mathematical computation. The overarching goal of the requirements management effort for a software project would thus be to make sure the work being automated gets assigned to the proper processor. For instance, “Don’t make the human remember where she is in the interface. Make the interface report the human’s location in the system at all times.” Or “Don’t make the human enter the same data in two screens. Make the system store the data and fill in the second screen as needed.” The deliverable from the Feasibility stage is the budget and schedule for the project.

Design Assuming that costs are accurately determined and benefits to be gained are sufficiently large, the project can proceed to the Design stage. In Design, the main requirements management activity is comparing the results of the design against the requirements document to make sure that work is staying in scope. Again, flexibility is paramount to success. Here’s a classic story of scope change in mid-stream that actually worked well. Ford auto designers in the early ‘80s were expecting gasoline prices to hit $3.18 per gallon by the end of the decade. Midway through the design of the Ford Taurus, prices had centered to around $1.50 a gallon. The design team decided they could build a larger, more comfortable, and more powerful car if the gas prices stayed low, so they redesigned the car. The Taurus launch set nationwide sales records when the new car came out, primarily because it was so roomy and comfortable to drive. In most cases, however, departing from the original requirements to that degree does not work. So the requirements document becomes a critical tool that helps the team make decisions about design changes.

Construction and test In the construction and testing stage, the main activity of requirements management is to make sure that work and cost stay within schedule and budget, and that the emerging tool does in fact meet requirements. A main tool used in this stage is prototype construction and iterative testing. For a software application, the user interface can be created on paper and tested with potential users while the framework of the software is being built. Results of these tests are recorded in a user interface design guide and handed off to the design team when they are ready to develop the interface. This saves their time and makes their jobs much easier.

64

Requirements management

Release Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again.

Tools There exist both desktop and Web-based tools for requirements management. A Web-based requirements tool can be installed at the customer′s datacenter or can be offered as an on-demand requirements management platform which in some cases is completely free.[5]

Modeling Languages The system engineering modeling language SysML incorporates a requirements diagram allowing the developer to graphically organize, manage, and trace requirements.

On-demand requirements management platforms An on-demand requirements management platform is a fully hosted requirements management solution, where the only system requirements would normally be Internet access and a standard Web browser. The service would normally include all special hardware and software. Other services may include technology and processes designed to secure your data against physical loss and unauthorized use, 24×7 data availability, and assurance that the service will scale as you add users, applications, and additional activities. Some on-demand requirements management platforms charge a fee while others are free to use. Further information about specific requirements management vendors can be found on the discussion page.

See also • • • • •

Requirement Requirements analysis Requirements engineering Requirements traceability Process area (CMMI):

• Requirements Development (RD) • Requirements Management (REQM) • Product requirements document • Sweet spot: Requirements Management

65

Requirements management

Further reading • CMMI Product Team (August 2006) (PDF). CMMI for Development, Version 1.2 [6]. Technical Report CMU/SEI-2006-TR-008. Software Engineering Institute. Retrieved 2008-01-22. • Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 354047689X

External links • Critical Issues in Requirements Management - Panel Discussion with Executives from IBM/Rational, Cognition Corporation, PTC, Chrysler, and Siemens. [7] • Web 2.0 Requirements Management - What does it look like and why is it relevant? [8] • Windchill RequirementsLink Helps ensure that customer and market requirements have been satisfied by designs and have been properly verified during development [9] • TraceCloud a FREE SAAS Requirements Management Solution [10] • Forbes Requirements Management Software Directory [11] • INCOSE Requirements Tools Survey [12] • Jiludwig Requirements Management Tools Directory [13] • Requirements Management Tool Resources [14] • Washington State Information Services Board (ISB)policy: CMM Key Practices for Level 2 - Requirements Management [15] • U.K. Office of Government Commerce (OGC) - Requirements management [16] • Requirement Writing 101 for Product Management [17] • Requirements Management [18]

References [1] Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management (http:/ / www. stellman-greene. com/ aspm/ ). O'Reilly Media. ISBN978-0-596-00948-9. . [2] "Requirements management" (http:/ / www. ogc. gov. uk/ delivery_lifecycle_requirements_management. asp). UK Office of Government Commerce. . Retrieved 2009-11-10. [3] A Guide to the Project Management Body of Knowledge (http:/ / www. pmi. org/ ) (4th ed.). Project Management Institute. 2008. ISBN978-1-933-89051-7. . [4] Gotel, O., Finkelstein, A. An Analysis of the Requirements Traceability Problem Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101 [5] "Requirements Management Tools Survey" (http:/ / www. incose. org/ ProductsPubs/ products/ rmsurvey. aspx). International Council on Systems Engineering. . Retrieved 2009-11-10. [6] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 06tr008. cfm [7] http:/ / www. cognition. us/ news/ industry_report_142845a. html [8] http:/ / www. cognition. us/ Presentations/ RequirementsManagementSite. html [9] http:/ / www. ptc. com/ products/ windchill/ requirementslink [10] http:/ / www. tracecloud. com [11] http:/ / software. forbes. com/ requirements-management-software [12] http:/ / www. paper-review. com/ tools/ rms/ read. php [13] http:/ / www. jiludwig. com/ Requirements_Management_Tools. html [14] http:/ / jonathanbabcock. com/ 2008/ 09/ 04/ requirements-management-tool-resources/ [15] http:/ / isb. wa. gov/ policies/ portfolio/ tr25/ tr25_l2a. html [16] http:/ / www. ogc. gov. uk/ delivery_lifecycle_requirements_management. asp [17] http:/ / www. nainil. com/ blog/ requirement-writing-for-product-management/ [18] http:/ / www. reqid. com

66

Critical Chain Project Management

Critical Chain Project Management Critical Chain Project Management (CCPM) is a method of planning and managing projects that puts the main emphasis on the resources required to execute project tasks. It was developed by Eliyahu M. Goldratt. This is in contrast to the more traditional Critical Path and PERT methods, which emphasize task order and rigid scheduling. A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule.

Origins Developed by Eliyahu M. Goldratt, Critical Chain Project Management is based on methods and algorithms derived from his Theory of Constraints. The idea of CCPM was introduced in 1997 in his book, Critical Chain. Application of CCPM has been credited with achieving projects 10% to 50% faster and/or cheaper than the traditional methods (i.e. CPM, PERT, Gantt, etc.) developed from 1910 to 1950's. From numerous studies by Standish Group and others ref [1] as of 1998 for traditional project management methods, only 44% of projects typically finish on time, projects usually complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion. These traditional statistics are mostly avoided through CCPM. Typically, CCPM case studies report 95% on-time and on-budget completion when CCPM is applied correctly. Mabin and Balderstone[2] , in their meta-analysis of seventy-eight published case studies, found that implementing Critical Chain resulted in mean reduction in lead-times of 69%, mean reduction of cycle-times of 66%, mean improvement in due date performance of 60%, mean reduction in inventory levels of 50% and mean increases in revenue / throughput of 68%.

Details With traditional project management methods, 30% of the lost time and resources are typically consumed by wasteful techniques such as bad multi-tasking, Student syndrome, In-box delays, and lack of prioritization.{[3] } 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: 1. 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. 2. Lack of search for an optimum solution. This means that a "good enough" solution is enough because: 1. As far as is known, there is no analytical method of finding an absolute optimum (i.e. having the overall shortest critical chain). 2. The inherent uncertainty in estimates is much greater than the difference between the optimum and near-optimum ("good enough" solutions). 3. The identification and insertion of buffers: • project buffer • feeding buffers • resource buffers. (Most of the time it is observed that companies are reluctant to give more resources) 4. Monitoring project progress and health by monitoring the consumption rate of the buffers rather than individual task performance to schedule.

67

Critical Chain Project Management CCPM 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, Parkinson's Law 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). Event chain methodology can be used to determine a size of project, feeding, and resource buffers.

Methodology Planning A project plan is created in much the same fashion as with critical path. The plan is worked backward from a completion date with each task starting as late as possible. Two durations are entered for each task: a "best guess," or 50% probability duration, and a "safe" duration, which should have higher probability of completion (perhaps 90% or 95%, depending on the amount of risk that the organization can accept). Resources are then assigned to each task, and the plan is resource leveled using the 50% estimates. The longest sequence of resource-leveled tasks that lead from beginning to end of the project is then identified as the critical chain. The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero. Recognizing that tasks are more likely to take more rather than less time due to Parkinson's law, Student syndrome, or other reasons, "buffers" are used to establish dates for deliverables and for monitoring project schedule and financial performance. The "extra" duration of each task on the critical chain—the difference between the "safe" durations and the 50% durations—is gathered together in a buffer at the end of the project. In the same way, buffers are gathered at the end of each sequence of tasks that feed into the critical chain. Finally, a baseline is established, which enables financial monitoring of the project. Alternatively, the project manager can use probability-based quantification of duration using Monte Carlo simulation. In 1999, a researcher applied simulation to assess the impact of risks associated with each component of project work breakdown structure on project duration, cost and performance. Using Monte Carlo simulation, the project manager can apply different probabilities for various risk factors that affect a project component. The probability of occurrence can vary from 0% to 100% chance of occurrence. The impact of risk is entered into the simulation model along with the probability of occurrence. The Monte Carlo simulation runs over 10,000 iterations and provides a density graph illustrating the overall probability of risk impact on project outcome. Execution When the plan is complete and the project ready to kick off, the project network is fixed and the buffers size is "locked" (i.e. their planned duration may not be altered during the project), because they are used to monitor project schedule and financial performance. With no slack in the duration of individual tasks, the resources on the critical chain are exploited by ensuring that they work on the critical chain task and nothing else; bad multitasking is eliminated. An analogy is drawn in the literature with a relay race. The critical chain is the race, and the resources on the critical chain are the runners. When they are running their "leg" of the project, they should be focused on completing the assigned task as quickly as possible, with no distractions or multitasking. In some case studies, actual batons are reportedly hung by the desks of people when they are working on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome the tendency to delay work or to do extra work when there seems to be time.

68

Critical Chain Project Management Because task durations have been planned at the 50% probability duration, there is pressure on the resources to complete critical chain tasks as quickly as possible, overcoming student's syndrome and Parkinson's Law. Monitoring Monitoring is, in some ways, the greatest advantage of the Critical Chain method. Because individual tasks will vary in duration from the 50% estimate, there is no point in trying to force every task to complete "on time;" estimates can never be perfect. Instead, we monitor the buffers that were created during the planning stage. A fever chart or similar graph can be easily created and posted to show the consumption of buffer as a function of project completion. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate where all of the buffer may be expected to be consumed before the end of the project, resulting in late completion), then those alternative plans need to be implemented.

Underpinnings of CCPM History and discussion of the underlying principles behind CCPM. Critical Sequence was originally identified in the 1960s.

Software that supports Critical Chain Project Management This section is intended to be a listing of the software available that companies use to support CCPM implementations. Software support is needed to manage resource contentions within single projects and across the pipeline of projects; to create and monitor buffers; and to provide task-level priority information. • • • • • •

Aurora-CCPM by Stottler-Henke [4] cc-Pulse and cc-MPulse by Spherical Angle [5] CCPM+ by Advanced Projects [6] Concerto by Realization [7] ProChain by ProChain Solutions [8] Lynx by A-Dato [9]

See also • List of project management software • Theory of Constraints • Event chain methodology

Further reading • • • • • •

Critical Chain, ISBN 0-88427-153-6 Project Management In the Fast Lane, ISBN 1-57444-195-7 Critical Chain Project Management, ISBN 1-58053-074-5 Projects in Less Time: A Synopsis of Critical Chain, by Mark Woeppel A critical look at critical chain project management [10] [11], "Lean, Agile and Six Sigma IT Management", by Peter Ghavami (2008), Amazon.com

69

Critical Chain Project Management

External links • An Online Guide To Theory Of Constraints [12] - Description of Project Buffering and Critical Chain Buffer Management

References [1] http:/ / www. pqa. net/ ProdServices/ ccpm/ W05002001. html [2] Mabin, Vicky; Steven Balderstone (1998), "A Review of Goldratt's Theory of Constraints - Lessons from the International Literature", Operational Research Society of New Zealand 33rd Annual Conference, Auckland, pp.205–214 [3] Harvey Maylor, Project Management [4] http:/ / www. stottlerhenke. com/ [5] http:/ / www. sphericalangle. com/ [6] http:/ / www. advanced-projects. com/ home. aspx [7] http:/ / www. realization. com/ index. html [8] http:/ / www. prochain. com/ [9] http:/ / www. a-dato. net [10] http:/ / www. allbusiness. com/ management/ 951030-1. html [11] http:/ / www. ITManagementResearch. com [12] http:/ / www. dbrmfg. co. nz/ Projects%20Project%20Buffers. htm

Cone of Uncertainty In project management, the Cone of Uncertainty describes the change of uncertainties during a project. It goes back to research done by NASA which came to the conclusion that in the beginning of the project life cycle (i.e. before gathering of requirements) estimations have in general an uncertainty of factor 4. This means that the actual duration can be 4 times or 1/4th of the first estimations. This factor can be quite different - depending on the character of the project. The more time the project spends on R&I the higher the factor. The name "Cone of Uncertainty" comes from the initially fast, but later slow decrease of the uncertainty curve. At the beginning of a project, comparatively little is known about the product or work results. As more research and development is done, more information is learned about the project and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group. The term Cone of Uncertainty comes from software development where the technical and business environments change very rapidly. Most environments change so slowly that they can be considered static for the duration of a typical project, and traditional project management methods therefore focus on achieving a full understanding of the environment through careful analysis and planning. Well before any significant investments are made, the uncertainty is reduced to a level where the risk can be carried comfortably. In this kind of environment the uncertainty level decreases rapidly in the beginning and the cone shape is less obvious. The software business however is very volatile and there is an external pressure to increase the uncertainty level over time. The project must actively and continuously work to reduce the uncertainty level.

70

Cone of Uncertainty

Consequences from the Cone of Uncertainty • • • •

Estimations (e.g. on duration, costs or quality) are very vague at the beginning of a project Estimations and project plans based on estimations are to be redone on a regular basis Uncertainties can be introduced in estimations and should be visible in project plans Assumption which has possibility of getting converted into risk are major factor in uncertainty,

External links • The NASA Software Engineering Laboratory: Manager's Handbook for Software Development [1] • The NASA Software Engineering Laboratory: Manager's Handbook for Software Development [2] • Reduced graphic of the Cone of Uncertainty on Microsoft.com [3]

References [1] http:/ / sel. gsfc. nasa. gov/ website/ documents/ online-doc. htm [2] http:/ / homepages. inf. ed. ac. uk/ dts/ pm/ Papers/ nasa-manage. pdf [3] http:/ / www. microsoft. com/ china/ technet/ images/ itsolutions/ techguide/ innsol/ images/ msfpmd07. gif

Problem solving Problem solving is a mental process and is part of the larger problem process that includes problem finding and problem shaping. Considered the most complex of all intellectual functions, problem solving has been defined as higher-order cognitive process that requires the modulation and control of more routine or fundamental skills.[1] Problem solving occurs when an organism or an artificial intelligence system needs to move from a given state to a desired goal state.

Overview The nature of human problem solving methods has been studied by psychologists over the past hundred years. There are several methods of studying problem solving, including; introspection, behaviorism, simulation, computer modeling and experiment. Beginning with the early experimental work of the Gestaltists in Germany (e.g. Duncker, 1935 [2] ), and continuing through the 1960s and early 1970s, research on problem solving typically conducted relatively simple, laboratory tasks (e.g. Duncker's "X-ray" problem; Ewert & Lambert's 1932 "disk" problem, later known as Tower of Hanoi) that appeared novel to participants (e.g. Mayer, 1992 [3] ). Various reasons account for the choice of simple novel tasks: they had clearly defined optimal solutions, they were solvable within a relatively short time frame, researchers could trace participants' problem-solving steps, and so on. The researchers made the underlying assumption, of course, that simple tasks such as the Tower of Hanoi captured the main properties of "real world" problems, and that the cognitive processes underlying participants' attempts to solve simple problems were representative of the processes engaged in when solving "real world" problems. Thus researchers used simple problems for reasons of convenience, and thought generalizations to more complex problems would become possible. Perhaps the best-known and most impressive example of this line of research remains the work by Allen Newell and Herbert Simon [4] . Simple laboratory-based tasks can be useful in explicating the steps of logic and reasoning that underlie problem solving; however, they omit the complexity and emotional valence of "real-world" problems. In clinical psychology, researchers have focused on the role of emotions in problem solving (D'Zurilla & Goldfried, 1971; D'Zurilla & Nezu, 1982), demonstrating that poor emotional control can disrupt focus on the target task and impede problem

71

Problem solving resolution (Rath, Langenbahn, Simon, Sherr, & Diller, 2004). In this conceptualization, human problem solving consists of two related processes: problem orientation, the motivational/attitudinal/affective approach to problematic situations and problem-solving skills, the actual cognitive-behavioral steps, which, if successfully implemented, lead to effective problem resolution. Working with individuals with frontal lobe injuries, neuropsychologists have discovered that deficits in emotional control and reasoning can be remediated, improving the capacity of injured persons to resolve everyday problems successfully (Rath, Simon, Langenbahn, Sherr, & Diller, 2003).

Europe In Europe, two main approaches have surfaced, one initiated by Donald Broadbent (1977; see Berry & Broadbent, 1995) in the United Kingdom and the other one by Dietrich Dörner (1975, 1985; see Dörner & Wearing, 1995) in Germany. The two approaches have in common an emphasis on relatively complex, semantically rich, computerized laboratory tasks, constructed to resemble real-life problems. The approaches differ somewhat in their theoretical goals and methodology, however. The tradition initiated by Broadbent emphasizes the distinction between cognitive problem-solving processes that operate under awareness versus outside of awareness, and typically employs mathematically well-defined computerized systems. The tradition initiated by Dörner, on the other hand, has an interest in the interplay of the cognitive, motivational, and social components of problem solving, and utilizes very complex computerized scenarios that contain up to 2,000 highly interconnected variables (e.g., Dörner, Kreuzig, Reither & Stäudel's 1983 LOHHAUSEN project; Ringelband, Misiak & Kluwe, 1990). Buchner (1995) describes the two traditions in detail. To sum up, researchers' realization that problem-solving processes differ across knowledge domains and across levels of expertise (e.g. Sternberg, 1995) and that, consequently, findings obtained in the laboratory cannot necessarily generalize to problem-solving situations outside the laboratory, has during the past two decades led to an emphasis on real-world problem solving. This emphasis has been expressed quite differently in North America and Europe, however. Whereas North American research has typically concentrated on studying problem solving in separate, natural knowledge domains, much of the European research has focused on novel, complex problems, and has been performed with computerized scenarios (see Funke, 1991, for an overview).

USA and Canada In North America, initiated by the work of Herbert Simon on learning by doing in semantically rich domains (e.g. Anzai & Simon, 1979; Bhaskar & Simon, 1977), researchers began to investigate problem solving separately in different natural knowledge domains – such as physics, writing, or chess playing – thus relinquishing their attempts to extract a global theory of problem solving (e.g. Sternberg & Frensch, 1991). Instead, these researchers have frequently focused on the development of problem solving within a certain domain, that is on the development of expertise (e.g. Anderson, Boyle & Reiser, 1985; Chase & Simon, 1973; Chi, Feltovich & Glaser, 1981). Areas that have attracted rather intensive attention in North America include such diverse fields as: • • • • • • • •

Problem Solving (Kepner& Tregoe, 1958) Reading (Stanovich & Cunningham, 1991) Writing (Bryson, Bereiter, Scardamalia & Joram, 1991) Calculation (Sokol & McCloskey, 1991) Political decision making (Voss, Wolfe, Lawrence & Engle, 1991) Managerial problem solving (Wagner, 1991) Lawyers' reasoning (Amsel, Langer & Loutzenhiser, 1991) Mechanical problem solving (Hegarty, 1991)

• Problem solving in electronics (Lesgold & Lajoie, 1991) • Computer skills (Kay, 1991) • Game playing (Frensch & Sternberg, 1991)

72

Problem solving • • • •

Personal problem solving (Heppner & Krauskopf, 1987) Mathematical problem solving (Polya, 1945; Schoenfeld, 1985) Social problem solving (D'Zurilla & Goldfreid, 1971; D'Zurilla & Nezu, 1982) Problem solving for innovations and inventions: TRIZ (Altshuller, 1973, 1984, 1994)

Characteristics of difficult problems As elucidated by Dietrich Dörner and later expanded upon by Joachim Funke, difficult problems have some typical characteristics that can be summarized as follows: • Intransparency (lack of clarity of the situation) • commencement opacity • continuation opacity • Polytely (multiple goals) • inexpressiveness • opposition • transience • Complexity (large numbers of items, interrelations and decisions) • enumerability • connectivity (hierarchy relation, communication relation, allocation relation) • heterogeneity • Dynamics (time considerations) • • • •

temporal constraints temporal sensitivity phase effects dynamic unpredictability

The resolution of difficult problems requires a direct attack on each of these characteristics that are encountered. In reform mathematics, greater emphasis is placed on problem solving relative to basic skills, where basic operations can be done with calculators. However some "problems" may actually have standard solutions taught in higher grades. For example, kindergarteners could be asked how many fingers are there on all the gloves of 3 children, which can be solved with multiplication.[5]

Problem-solving techniques • Abstraction: solving the problem in a model of the system before applying it to the real system • Analogy: using a solution that solved an analogous problem • Brainstorming: (especially among groups of people) suggesting a large number of solutions or ideas and combining and developing them until an optimum is found • Divide and conquer: breaking down a large, complex problem into smaller, solvable problems • Hypothesis testing: assuming a possible explanation to the problem and trying to prove (or, in some contexts, disprove) the assumption • Lateral thinking: approaching solutions indirectly and creatively • Means-ends analysis: choosing an action at each step to move closer to the goal • Method of focal objects: synthesizing seemingly non-matching characteristics of different objects into something new • Morphological analysis: assessing the output and interactions of an entire system • Reduction: transforming the problem into another problem for which solutions exist • Research: employing existing ideas or adapting existing solutions to similar problems

73

Problem solving • Root cause analysis: eliminating the cause of the problem • Trial-and-error: testing possible solutions until the right one is found

Problem-solving methodologies • • • • • • • •

Eight Disciplines Problem Solving GROW model How to solve it Kepner-Tregoe Southbeach Notation PDCA RPR Problem Diagnosis TRIZ (Teoriya Resheniya Izobretatelskikh Zadatch, "theory of solving inventor's problems")

Example applications Problem solving is of crucial importance in engineering when products or processes fail, so corrective action can be taken to prevent further failures. Perhaps of more value, problem solving can be applied to a product or process prior to an actual fail event ie. a potential problem can be predicted, analyzed and mitigation applied so the problem never actually occurs. Techniques like Failure Mode Effects Analysis can be used to proactively reduce the likelihood of problems occurring. Forensic engineering is an important technique of failure analysis which involves tracing product defects and flaws. Corrective action can then be taken to prevent further failures.

See also • • • • • • • • • • • • • • • • • •

Artificial intelligence C-K theory Creative problem solving Divergent thinking Educational psychology Executive function Forensic engineering Heuristics Innovation Intelligence amplification Inquiry Logical reasoning Problem statement Herbert Simon Thought Transdisciplinary studies Troubleshooting Wicked problem

74

Problem solving

References • Amsel, E., Langer, R., & Loutzenhiser, L. (1991). Do lawyers reason differently from psychologists? A comparative design for studying expertise. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 223-250). Hillsdale, NJ: Lawrence Erlbaum Associates. ISBN 978-0-8058-1783-6 • Anderson, J. R., Boyle, C. B., & Reiser, B. J. (1985). "Intelligent tutoring systems". Science 228 (4698): 456–462. doi:10.1126/science.228.4698.456. PMID17746875. • Anzai, K., & Simon, H. A. (1979) (1979). "The theory of learning by doing". Psychological Review 86 (2): 124–140. doi:10.1037/0033-295X.86.2.124. PMID493441. • Beckmann, J. F., & Guthke, J. (1995). Complex problem solving, intelligence, and learning ability. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 177-200). Hillsdale, NJ: Lawrence Erlbaum Associates. • Berry, D. C., & Broadbent, D. E. (1995). Implicit learning in the control of complex systems: A reconsideration of some of the earlier claims. In P.A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 131-150). Hillsdale, NJ: Lawrence Erlbaum Associates. • Bhaskar, R., & Simon, H. A. (1977). Problem solving in semantically rich domains: An example from engineering thermodynamics. Cognitive Science, 1, 193-215. • Brehmer, B. (1995). Feedback delays in dynamic decision making. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 103-130). Hillsdale, NJ: Lawrence Erlbaum Associates. • Brehmer, B., & Dörner, D. (1993). Experiments with computer-simulated microworlds: Escaping both the narrow straits of the laboratory and the deep blue sea of the field study. Computers in Human Behavior, 9, 171-184. • Broadbent, D. E. (1977). Levels, hierarchies, and the locus of control. Quarterly Journal of Experimental Psychology, 29, 181-201. • Bryson, M., Bereiter, C., Scardamalia, M., & Joram, E. (1991). Going beyond the problem as given: Problem solving in expert and novice writers. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 61-84). Hillsdale, NJ: Lawrence Erlbaum Associates. • Buchner, A. (1995). Theories of complex problem solving. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 27-63). Hillsdale, NJ: Lawrence Erlbaum Associates. • Buchner, A., Funke, J., & Berry, D. C. (1995). Negative correlations between control performance and verbalizable knowledge: Indicators for implicit learning in process control tasks? Quarterly Journal of Experimental Psychology, 48A, 166-187. • Chase, W. G., & Simon, H. A. (1973). Perception in chess. Cognitive Psychology, 4, 55-81. • Chi, M. T. H., Feltovich, P. J., & Glaser, R. (1981). "Categorization and representation of physics problems by experts and novices" [6]. Cognitive Science 5: 121–152. doi:10.1207/s15516709cog0502_2. • Dörner, D. (1975). Wie Menschen eine Welt verbessern wollten [How people wanted to improve the world]. Bild der Wissenschaft, 12, 48-53. • Dörner, D. (1985). Verhalten, Denken und Emotionen [Behavior, thinking, and emotions]. In L. H. Eckensberger & E. D. Lantermann (Eds.), Emotion und Reflexivität (pp. 157-181). München, Germany: Urban & Schwarzenberg. • Dörner, D. (1992). Über die Philosophie der Verwendung von Mikrowelten oder "Computerszenarios" in der psychologischen Forschung [On the proper use of microworlds or "computer scenarios" in psychological research]. In H. Gundlach (Ed.), Psychologische Forschung und Methode: Das Versprechen des Experiments. Festschrift für Werner Traxel (pp. 53-87). Passau, Germany: Passavia-Universitäts-Verlag. • Dörner, D., Kreuzig, H. W., Reither, F., & Stäudel, T. (Eds.). (1983). Lohhausen. Vom Umgang mit Unbestimmtheit und Komplexität [Lohhausen. On dealing with uncertainty and complexity]. Bern, Switzerland: Hans Huber.

75

Problem solving • Dörner, D., & Wearing, A. (1995). Complex problem solving: Toward a (computer-simulated) theory. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 65-99). Hillsdale, NJ: Lawrence Erlbaum Associates. • Duncker, K. (1935). Zur Psychologie des produktiven Denkens [The psychology of productive thinking]. Berlin: Julius Springer. • Ewert, P. H., & Lambert, J. F. (1932). Part II: The effect of verbal instructions upon the formation of a concept. Journal of General Psychology, 6, 400-411. • Eyferth, K., Schömann, M., & Widowski, D. (1986). Der Umgang von Psychologen mit Komplexität [On how psychologists deal with complexity]. Sprache & Kognition, 5, 11-26. • Frensch, P. A., & Funke, J. (Eds.). (1995). Complex problem solving: The European Perspective. Hillsdale, NJ: Lawrence Erlbaum Associates. • Frensch, P. A., & Sternberg, R. J. (1991). Skill-related differences in game playing. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 343-381). Hillsdale, NJ: Lawrence Erlbaum Associates. • Funke, J. (1991). Solving complex problems: Human identification and control of complex systems. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 185-222). Hillsdale, NJ: Lawrence Erlbaum Associates. • Funke, J. (1993). Microworlds based on linear equation systems: A new approach to complex problem solving and experimental results. In G. Strube & K.-F. Wender (Eds.), The cognitive psychology of knowledge (pp. 313-330). Amsterdam: Elsevier Science Publishers. • Funke, J. (1995). Experimental research on complex problem solving. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 243-268). Hillsdale, NJ: Lawrence Erlbaum Associates. • Funke, U. (1995). Complex problem solving in personnel selection and training. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 219-240). Hillsdale, NJ: Lawrence Erlbaum Associates. • Goldstein F. C., & Levin H. S. (1987). Disorders of reasoning and problem-solving ability. In M. Meier, A. Benton, & L. Diller (Eds.), Neuropsychological rehabilitation. London: Taylor & Francis Group. • Groner, M., Groner, R., & Bischof, W. F. (1983). Approaches to heuristics: A historical review. In R. Groner, M. Groner, & W. F. Bischof (Eds.), Methods of heuristics (pp. 1-18). Hillsdale, NJ: Lawrence Erlbaum Associates. • Halpern, Diane F. (2002).Thought & Knowledge. Lawrence Erlbaum Associates. Worldcat Library Catalog [7] • Hayes, J. (1980). The complete problem solver. Philadelphia: The Franklin Institute Press. • Hegarty, M. (1991). Knowledge and processes in mechanical problem solving. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 253-285). Hillsdale, NJ: Lawrence Erlbaum Associates. • Heppner, P. P., & Krauskopf, C. J. (1987). An information-processing approach to personal problem solving. The Counseling Psychologist, 15, 371-447. • Huber, O. (1995). Complex problem solving as multi stage decision making. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 151-173). Hillsdale, NJ: Lawrence Erlbaum Associates. • Hübner, R. (1989). Methoden zur Analyse und Konstruktion von Aufgaben zur kognitiven Steuerung dynamischer Systeme [Methods for the analysis and construction of dynamic system control tasks]. Zeitschrift für Experimentelle und Angewandte Psychologie, 36, 221-238. • Hunt, E. (1991). Some comments on the study of complexity. In R. J. Sternberg, & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 383-395). Hillsdale, NJ: Lawrence Erlbaum Associates. • Hussy, W. (1985). Komplexes Problemlösen - Eine Sackgasse? [Complex problem solving - a dead end?]. Zeitschrift für Experimentelle und Angewandte Psychologie, 32, 55-77.

76

Problem solving • Kay, D. S. (1991). Computer interaction: Debugging the problems. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 317-340). Hillsdale, NJ: Lawrence Erlbaum Associates. • Kluwe, R. H. (1993). Knowledge and performance in complex problem solving. In G. Strube & K.-F. Wender (Eds.), The cognitive psychology of knowledge (pp. 401-423). Amsterdam: Elsevier Science Publishers. • Kluwe, R. H. (1995). Single case studies and models of complex problem solving. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 269-291). Hillsdale, NJ: Lawrence Erlbaum Associates. • Kolb, S., Petzing, F., & Stumpf, S. (1992). Komplexes Problemlösen: Bestimmung der Problemlösegüte von Probanden mittels Verfahren des Operations Research ? ein interdisziplinärer Ansatz [Complex problem solving: determining the quality of human problem solving by operations research tools - an interdisciplinary approach]. Sprache & Kognition, 11, 115-128. • Krems, J. F. (1995). Cognitive flexibility and complex problem solving. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 201-218). Hillsdale, NJ: Lawrence Erlbaum Associates. • Lesgold, A., & Lajoie, S. (1991). Complex problem solving in electronics. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 287-316). Hillsdale, NJ: Lawrence Erlbaum Associates. • Mayer, R. E. (1992). Thinking, problem solving, cognition. Second edition. New York: W. H. Freeman and Company. • Müller, H. (1993). Komplexes Problemlösen: Reliabilität und Wissen [Complex problem solving: Reliability and knowledge]. Bonn, Germany: Holos. • Newell, A., & Simon, H. A. (1972). Human problem solving. Englewood Cliffs, NJ: Prentice-Hall. • Paradies, M.W., & Unger, L. W. (2000). TapRooT - The System for Root Cause Analysis, Problem Investigation, and Proactive Improvement. Knoxville, TN: System Improvements. • Putz-Osterloh, W. (1993). Strategies for knowledge acquisition and transfer of knowledge in dynamic tasks. In G. Strube & K.-F. Wender (Eds.), The cognitive psychology of knowledge (pp. 331-350). Amsterdam: Elsevier Science Publishers. • Riefer, D.M., & Batchelder, W.H. (1988). Multinomial modeling and the measurement of cognitive processes. Psychological Review, 95, 318-339. • Ringelband, O. J., Misiak, C., & Kluwe, R. H. (1990). Mental models and strategies in the control of a complex system. In D. Ackermann, & M. J. Tauber (Eds.), Mental models and human-computer interaction (Vol. 1, pp. 151-164). Amsterdam: Elsevier Science Publishers. • Schaub, H. (1993). Modellierung der Handlungsorganisation. Bern, Switzerland: Hans Huber. • Sokol, S. M., & McCloskey, M. (1991). Cognitive mechanisms in calculation. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 85-116). Hillsdale, NJ: Lawrence Erlbaum Associates. • Stanovich, K. E., & Cunningham, A. E. (1991). Reading as constrained reasoning. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 3-60). Hillsdale, NJ: Lawrence Erlbaum Associates. • Sternberg, R. J. (1995). Conceptions of expertise in complex problem solving: A comparison of alternative conceptions. In P. A. Frensch & J. Funke (Eds.), Complex problem solving: The European Perspective (pp. 295-321). Hillsdale, NJ: Lawrence Erlbaum Associates. • Sternberg, R. J., & Frensch, P. A. (Eds.). (1991). Complex problem solving: Principles and mechanisms. Hillsdale, NJ: Lawrence Erlbaum Associates. • Strauß, B. (1993). Konfundierungen beim Komplexen Problemlösen. Zum Einfluß des Anteils der richtigen Lösungen (ArL) auf das Problemlöseverhalten in komplexen Situationen [Confoundations in complex problem

77

Problem solving

• •

• •

solving. On the influence of the degree of correct solutions on problem solving in complex situations]. Bonn, Germany: Holos. Strohschneider, S. (1991). Kein System von Systemen! Kommentar zu dem Aufsatz "Systemmerkmale als Determinanten des Umgangs mit dynamischen Systemen" von Joachim Funke [No system of systems! Reply to the paper "System features as determinants of behavior in dynamic task environments" by Joachim Funke]. Sprache & Kognition, 10, 109-113. Van Lehn, K. (1989). Problem solving and cognitive skill acquisition. In M. I. Posner (Ed.), Foundations of cognitive science (pp. 527-579). Cambridge, MA: MIT Press. Voss, J. F., Wolfe, C. R., Lawrence, J. A., & Engle, R. A. (1991). From representation to decision: An analysis of problem solving in international relations. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 119-158). Hillsdale, NJ: Lawrence Erlbaum Associates. Wagner, R. K. (1991). Managerial problem solving. In R. J. Sternberg & P. A. Frensch (Eds.), Complex problem solving: Principles and mechanisms (pp. 159-183). Hillsdale, NJ: Lawrence Erlbaum Associates. Wisconsin Educational Media Association. (1993). "Information literacy: A position paper on information problem-solving." Madison, WI: WEMA Publications. (ED 376 817). (Portions adapted from Michigan State Board of Education's Position Paper on Information Processing Skills, 1992).

• Altshuller, Genrich (1973). Innovation Algorithm. Worcester, MA: Technical Innovation Center. ISBN0-9640740-2-8. • Altshuller, Genrich (1984). Creativity as an Exact Science. New York, NY: Gordon & Breach. ISBN0-677-21230-5. • Altshuller, Genrich (1994). And Suddenly the Inventor Appeared. translated by Lev Shulyak. Worcester, MA: Technical Innovation Center. ISBN0-9640740-1-X. • D’Zurilla, T. J., & Goldfried, M. R. (1971). Problem solving and behavior modification. Journal of Abnormal Psychology, 78, 107-126. • D'Zurilla, T. J., & Nezu, A. M. (1982). Social problem solving in adults. In P. C. Kendall (Ed.), Advances in cognitive-behavioral research and therapy (Vol. 1, pp.201–274). New York: Academic Press. • Rath J. F.; Langenbahn D. M.; Simon D.; Sherr R. L.; Fletcher J.; Diller L. (2004). The construct of problem solving in higher level neuropsychological assessment and rehabilitation. Archives of Clinical Neuropsychology, 19, 613-635. doi:10.1016/j.acn.2003.08.006 • Rath, J. F.; Simon, D.; Langenbahn, D. M.; Sherr, R. L.; Diller, L. (2003). Group treatment of problem-solving deficits in outpatients with traumatic brain injury: A randomised outcome study. Neuropsychological Rehabilitation, 13, 461-488.

External links • • • •

Computer Skills for Information Problem-Solving: Learning and Teaching Technology in Context [8] Problem solving-Elementary level [9] CROP (Communities Resolving Our Problems) [10] The Altshuller Institute for TRIZ Studies, Worcester, MA [11]

References [1] Goldstein F. C., & Levin H. S. (1987). Disorders of reasoning and problem-solving ability. In M. Meier, A. Benton, & L. Diller (Eds.), Neuropsychological rehabilitation. London: Taylor & Francis Group. [2] Duncker, K. (1935). Zur Psychologie des produktiven Denkens [The psychology of productive thinking]. Berlin: Julius Springer. [3] Mayer, R. E. (1992). Thinking, problem solving, cognition. Second edition. New York: W. H. Freeman and Company. [4] *Newell, A., & Simon, H. A. (1972). Human problem solving. Englewood Cliffs, NJ: Prentice-Hall. [5] 2007 Draft, Washington State Revised Mathematics Standard [6] http:/ / www. usabilityviews. com/ uv007206. html [7] http:/ / worldcat. org/ oclc/ 50065032& tab=holdings

78

Problem solving [8] http:/ / www. ericdigests. org/ 1996-4/ skills. htm [9] http:/ / moodle. ed. uiuc. edu/ wiked/ index. php/ Problem_solving-Elementary_level [10] http:/ / ceap. wcu. edu/ houghton/ Learner/ basicidea. html [11] http:/ / www. aitriz. org

Resource leveling Resource leveling is a project management process used to examine unbalanced use of resources (usually people or equipment) over time, and for resolving over-allocations or conflicts. When performing project planning activities, the manager will attempt to schedule certain tasks simultaneously. When more resources such as machines or people are needed than are available, or perhaps a specific person is needed in both tasks, the tasks will have to be rescheduled concurrently or even sequentially to manage the constraint. Project planning resource leveling is the process of resolving these conflicts. It can also be used to balance the workload of primary resources over the course of the project[s], usually at the expense of one of the traditional triple constraints (time, cost, scope). When using specially designed project software, leveling typically means resolving conflicts or over allocations in the project plan by allowing the software to calculate delays and update tasks automatically. Project management software leveling requires delaying tasks until resources are available. In more complex environments, resources could be allocated across multiple, concurrent projects thus requiring the process of resource leveling to be performed at company level. In either definition, leveling could result in a later project finish date if the tasks affected are in the critical path. Resource Leveling is also useful in the world of maintenance management. Many organizations have maintenance backlogs. These backlogs consist of work orders. In a "planned state" these work orders have estimates such as 2 electricians for 8 hours. These work orders have other attributes such as report date, priority, asset operational requirements, and safety concerns. These same organizations have a need to create weekly schedules. Resource-leveling can take the "work demand" and balance it against the resource pool availability for the given week. The goal is to create this weekly schedule in advance of performing the work. Without resource-leveling the organization (planner, scheduler, supervisor) is most likely performing subjective selection. For the most part, when it comes to maintenance scheduling, there are very few logic ties and therefore no need to calculate critical path and total float.

References Project Management Institute A Guide to the Project Management Body of Knowledge, Third Edition, 2004 Project Management Institute, Inc. ISBN 193069945X, ISBN 978-1930699458 Microsoft Office Online: Project 2003

See also • Resource Allocation • Project Management

79

Resource leveling

80

External links Project Management Institute (PMI) [1] Microsoft Office Project 2007 [2] Open Workbench, open source free project software [3] Project Management for Construction, by Chris Hendrickson [4] Resource-Constrained Project Scheduling: Past Work and New Directions, by Bibo Yang, Joseph Geunes, William J. O'Brien [5] • Petri Nets for Project Management and Resource Levelling, by V. A. Jeetendra, O. V. Krishnaiah Chetty, J. Prashanth Reddy [6] • • • • •

References [1] [2] [3] [4] [5] [6]

http:/ / www. pmi. org/ info/ default. asp http:/ / office. microsoft. com/ en-us/ project/ HA012316471033. aspx?pid=CH100667251033 http:/ / www. openworkbench. org/ http:/ / www. ce. cmu. edu/ pmbook/ 10_Fundamental_Scheduling_Procedures. html http:/ / www. dbcenter. cise. ufl. edu/ seek/ Publications/ RCPSP_YGO. pdf http:/ / www. springerlink. com/ index/ CAGPW559AX96QR0R. pdf

Theory of Constraints Part of a series of articles on

Industry

Manufacturing methods Batch production • Job production Continuous production Improvement methods LM • TPM • QRM TOC • Six Sigma • RCM Information & communication ISA-88 • ISA-95 • ERP SAP • IEC 62264 • B2MML Process control PLC • DCS

Theory of Constraints (TOC) is an overall management philosophy introduced by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal, that is geared to help organizations continually achieve their goal.[1] The title comes from the contention that any manageable system is limited in achieving more of its goal by a very small number of constraints, and that there is always at least one constraint. The TOC process seeks to identify the constraint and restructure the rest of the organization around it, through the use of the Five Focusing Steps.

Theory of Constraints

Basics Key assumption The underlying premise of Theory of Constraints is that organizations can be measured and controlled by variations on three measures: throughput, operating expense, and inventory. Throughput is money (or goal units) generated through sales. Inventory is money the system invests in order to sell its goods and services. Operating expense is all the money the system spends in order to turn inventory into throughput. [2]

The five focusing steps Theory of Constraints is based on the premise that the rate of goal achievement is limited by at least one constraining process. Only by increasing flow through the constraint can overall throughput be increased. [1] Assuming the goal of the organization has been articulated (e.g., "Make money now and in the future") the steps are: 1. Identify the constraint (the resource or policy that prevents the organization from obtaining more of the goal) 2. Decide how to exploit the constraint (make sure the constraint's time is not wasted doing things that it should not do) 3. Subordinate all other processes to above decision (align the whole system or organization to support the decision made above) 4. Elevate the constraint (if required or possible, permanently increase capacity of the constraint; "buy more") 5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint. The five focusing steps aim to ensure ongoing improvement efforts are centered around the organization's constraints. In the TOC literature, this is referred to as the "Process of Ongoing Improvement" (POOGI). These focusing steps are the key steps to developing the specific applications mentioned below.

Constraints A constraint is anything that prevents the system from achieving more of its goal. There are many ways that constraints can show up, but a core principle within TOC is that there are not tens or hundreds of constraints. There is at least one and at most a few in any given system. Constraints can be internal or external to the system. An internal constraint is in evidence when the market demands more from the system than it can deliver. If this is the case, then the focus of the organization should be on discovering that constraint and following the five focusing steps to open it up (and potentially remove it). An external constraint exists when the system can produce more than the market will bear. If this is the case, then the organization should focus on mechanisms to create more demand for its products or services. Types of (internal) constraints • Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods / services. • People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint. • Policy: A written or unwritten policy prevents the system from making more. The concept of the constraint in Theory of Constraints differs from the constraint that shows up in mathematical optimization. In TOC, the constraint is used as a focusing mechanism for management of the system. In optimization, the constraint is written into the mathematical expressions to limit the scope of the solution (X can be no greater than 5). Please note: Organizations have many problems with equipment, people, policies, etc. (A breakdown is just that - a breakdown - and is not a constraint in the true sense of the TOC concept) The constraint is the thing that is preventing the organization from getting more Throughput (typically, revenue through sales).

81

Theory of Constraints

Buffers Buffers are used throughout Theory of Constraints. They often result as part of the EXPLOIT and SUBORDINATE steps of the five focusing steps. Buffers are placed before the governing constraint, thus ensuring that the constraint is never starved. Buffers are also placed behind the constraint to prevent downstream failure to block the constraint's output. Buffers used in this way protect the constraint from variations in the rest of the system and should allow for normal variation of processing time and the occasional upset (Murphy) before and behind the constraint. Buffers can be a bank of physical objects before a work center, waiting to be processed by that work center. Buffers ultimately buy you time, as in the time before work reaches the constraint and are often verbalized as time buffers. There should always be enough (but not excessive) work in the time queue before the constraint and adequate offloading space behind the constraint. Buffers are not the small queue of work that sits before every work center in a Kanban system although it is similar if you regard the assembly line as the governing constraint. A prerequisite in Theory of Constraints is that with one constraint in the system, all other parts of the system must have sufficient capacity to keep up with the work at the constraint and to catch up if time was lost. In a balanced line, as espoused by Kanban, when one work center goes down for a period longer than the buffer allows, then the entire system must wait until that work center is restored. In a TOC system, the only situation where work is in danger, is if the constraint is unable to process (either due to malfunction, sickness or a "hole" in the buffer - if something goes wrong that the time buffer can not protect). Buffer management therefor represents a crucial attribute of the Theory of Constraints. There are many ways to do it, but the most often used is a visual system of designating the buffer in three colours: Green (OK), Yellow (Caution) and Red (Action required). Creating this kind of visibility enables the system as a whole to align and thus subordinate to the need of the constraint in a holistic manner. This can also be done daily in a central operations room that is accessible to everybody.

Plant types There are four primary types of plants in the TOC lexicon. Draw the flow of material from the bottom of a page to the top, and you get the four types. They specify the general flow of materials through a system, and they provide some hints about where to look for typical problems. The four types can be combined in many ways in larger facilities. • I-Plant: Material flows in a sequence, such as in an assembly line. The primary work is done in a straight sequence of events (one-to-one). The constraint is the slowest operation. • A-Plant: The general flow of material is many-to-one, such as in a plant where many sub-assemblies converge for a final assembly. The primary problem in A-plants is in synchronizing the converging lines so that each supplies the final assembly point at the right time. • V-Plant: The general flow of material is one-to-many, such as a plant that takes one raw material and can make many final products. Classic examples are meat rendering plants or a steel manufacturer. The primary problem in V-plants is "robbing" where one operation (A) immediately after a diverging point "steals" materials meant for the other operation (B). Once the material has been processed by A, it cannot come back and be run through B without significant rework. • T-Plant: The general flow is that of an I-Plant (or has multiple lines), which then splits into many assemblies (many-to-many). Most manufactured parts are used in multiple assemblies and nearly all assemblies use multiple parts. Customized devices, such as computers, are good examples. T-plants suffer from both synchronization problems of A-plants (parts aren't all available for an assembly) and the robbing problems of V-plants (one assembly steals parts that could have been used in another). For non-material systems, one can draw the flow of work or the flow of processes and arrive at similar basic structures. A project, for example is an A-shaped sequence of work, culminating in a delivered project.

82

Theory of Constraints

Applications The focusing steps, or this Process of Ongoing Improvement has been applied to Manufacturing, Project Management, Supply Chain / Distribution generated specific solutions. Other tools (mainly the TP) also led to TOC applications in the fields of Marketing and Sales, and Finance. The solution as applied to each of these areas are listed below.

Operations Within manufacturing operations and operations management, the solution seeks to pull materials through the system, rather than push them into the system. The primary methodology use is Drum-Buffer-Rope (DBR)[3] and a variation called Simplified Drum-Buffer-Rope (S-DBR)[4] . Drum-Buffer-Rope is a manufacturing execution methodology, named for its three components. The drum is the physical constraint of the plant: the work center or machine or operation that limits the ability of the entire system to produce more. The rest of the plant follows the beat of the drum. They make sure the drum has work and that anything the drum has processed does not get wasted. The buffer protects the drum, so that it always has work flowing to it. Buffers in DBR have time as their unit of measure, rather than quantity of material. This makes the priority system operate strictly based on the time an order is expected to be at the drum. Traditional DBR usually calls for buffers at several points in the system: the constraint, synchronization points and at shipping. S-DBR has a buffer at shipping and manages the flow of work across the drum through a load planning mechanism. The rope is the work release mechanism for the plant. Orders are released to the shop floor a "buffer time" before they are due. Pushing work into the system earlier than this buffer time is likely to generate too-high work-in-process and slow down the entire system.

Supply chain / logistics The solution for supply chain is to move to a replenishment to consumption model, rather than a forecast model. • TOC-Distribution • TOC-VMI (vendor managed inventory)

Finance and accounting The solution for finance and accounting is to apply holistic thinking to the finance application. This has been termed throughput accounting.[5] Throughput accounting suggests that one examine the impact of investments and operational changes in terms of the impact on the throughput of the business. It is an alternative to cost accounting. The primary measures for a TOC view of finance and accounting are: Throughput (T), Operating Expense (OE) and Investment (I). Throughput is calculated from Sales (S) - Totally Variable Cost (TVC). Totally Variable Cost usually considers the cost of raw materials that go into creating the item sold.

83

Theory of Constraints

Project management Critical Chain Project Management (CCPM) is utilized in this area.[6] CCPM is based on the idea that all projects look like A-plants: all activities converge to a final deliverable. As such, to protect the project, there must be internal buffers to protect synchronization points and a final project buffer to protect the overall project.

Marketing and sales While originally focused on manufacturing and logistics, TOC has expanded lately into sales management and marketing. Its role is explicitly acknowledged in the field of sales process engineering[7] . For effective sales management one can apply Drum Buffer Rope to the sales process similar to the way it is applied to operations (see Reengineering the Sales Process book reference below). This technique is appropriate when your constraint is in the sales process itself or you just want an effective sales management technique and includes the topics of funnel management and conversion rates.

The TOC thinking processes The Thinking Processes are a set of tools to help managers walk through the steps of initiating and implementing a project. When used in a logical flow, the Thinking Processes help walk through a buy-in process: 1. 2. 3. 4. 5.

Gain agreement on the problem Gain agreement on the direction for a solution Gain agreement that the solution solves the problem Agree to overcome any potential negative ramifications Agree to overcome any obstacles to implementation

TOC practitioners sometimes refer to these in the negative as working through layers of resistance to a change. Recently, the Current Reality Tree (CRT) and Future Reality Tree (FRT) have been applied to an argumentative academic paper [8] .

Development and practice TOC was initiated by Dr. Eliyahu M. Goldratt, who is still the main driving force behind the development and practice of TOC. There is a network of individuals and small companies loosely coupled as practitioners around the world. TOC is sometimes referred to as "Constraint Management". TOC is a large body of knowledge with a strong guiding philosophy of growth.

Criticism Criticisms that have been leveled against TOC include:

84

Theory of Constraints

Claimed Suboptimality of Drum-Buffer-Rope While TOC has been compared favorably to linear programming techniques[9] , D. Trietsch from University of Auckland argues that DBR methodology is inferior to competing methodologies. [10] [11] Linhares, from the Getulio Vargas Foundation, has shown that the TOC approach to establishing an optimal product mix is unlikely to yield optimum results, as it would imply that P=NP [12] .

Unacknowledged debt Duncan (as cited by Steyn) [13] says that TOC borrows heavily from systems dynamics developed by Forrester in the 1950s and from statistical process control which dates back to World War II. And Noreen Smith and Mackey, in their independent report on TOC, point out that several key concepts in TOC "have been topics in management accounting textbooks for decades." [14] People claim Goldratt's books fail to acknowledge that TOC borrows from more than 40 years of previous Management Science research and practice, particularly from PERT/CPM and JIT. A rebuttal to these criticisms is offered in Goldratt's "What is the Theory of Constraints and How Should it be Implemented?", and in his audio program, "Beyond The Goal". In these, Goldratt discusses the history of disciplinary sciences, compares the strengths and weaknesses of the various disciplines, and acknowledges the sources of information and inspiration for the Thinking Processes and Critical Chain methodologies. Articles published in the now-defunct Journal of Theory of Constraints referenced foundational materials. Goldratt published an article and gave talks[15] with the title "Standing on the Shoulders of Giants" in which he gives credit for many of the core ideas of Theory of Constraints. Goldratt has sought many times to show the correlation between various improvement methods. However, many Goldratt adherents often denigrate other methodologies as inferior to TOC.

See also • • • • • • • •

Linear programming List of Theory of Constraints topics Systems thinking — Critical systems thinking — Joint decision traps Twelve leverage points by Donella Meadows Constraint (disambiguation) Thinklets Throughput Model management

Further reading • Cox, Jeff; Goldratt, Eliyahu M. (1986). The goal: a process of ongoing improvement. [Great Barrington, MA]: North River Press. ISBN0-88427-061-0. • Dettmer, H. William. (2003). Strategic Navigation: A Systems Approach to Business Strategy. [Milwaukee, WI]: ASQ Quality Press. pp.302. ISBN0-87389-603-3. • Dettmer, H. William. (2007). The Logical Thinking Process: A Systems Approach to Complex Problem Solving. [Milwaukee, WI]: ASQ Quality Press. pp.413. ISBN978-0-87389-723-5. • Goldratt, Eliyahu M. (1994). It's not luck. [Great Barrington, MA]: North River Press. ISBN0-88427-115-3. • Goldratt, Eliyahu M. (1997). Critical chain. [Great Barrington, MA]: North River Press. ISBN0-88427-153-6. • Carol A. Ptak; Goldratt, Eliyahu M.; Eli Schragenheim. Necessary But Not Sufficient. [Great Barrington, MA]: North River Press. ISBN0-88427-170-6. • Goldratt, Eliyahu M.. Essays on the Theory of Constraints. [Great Barrington, MA]: North River Press. ISBN0-88427-159-5.

85

Theory of Constraints • Goldratt, Eliyahu M.. Theory of Constraints. [Great Barrington, MA]: North River Press. ISBN0-88427-166-8. • Goldratt, Eliyahu M.. Beyond the Goal : Eliyahu Goldratt Speaks on the Theory of Constraints (Your Coach in a Box). Coach Series. ISBN1-59659-023-8. • Dr Lisa Lang. Achieving a Viable Vision: The Theory of Constraints Strategic Approach to Rapid Sustainable Growth. Throughput Publishing, Inc. ISBN0-9777604-1-3. • Goldratt, Eliyahu M. (1990). The haystack syndrome: sifting information out of the data ocean. [Great Barrington, MA]: North River Press. ISBN0-88427-089-0. • Fox, Robert; Goldratt, Eliyahu M. (1986). The race. [Great Barrington, MA]: North River Press. ISBN0-88427-062-9. • Schragenheim, Eli. (1999). Management dilemmas. [Boca Raton, FL]: St. Lucie Press. pp.209. ISBN1-57444-222-8. • Schragenheim, Eli, and Dettmer, H. William. (2000). Manufacturing at warp speed: optimizing supply chain financial performance. [Boca Raton, FL]: St. Lucie Press. pp.342. ISBN1-57444-293-7. • Schragenheim, Eli, Dettmer, H. William, and Patterson, J. Wayne. (2009). Supply chain management at warp speed: integrating the system from end to end. [Boca Raton, FL]: CRC Press. pp.220. ISBN978-1-4200-7335-7. • John Tripp TOC Executive Challenge A Goal Game. ISBN 0-88427-186-2 • Goldratt, Eliyahu M.. Production the TOC Way with Simulator. North River Pr. ISBN0-88427-175-7. • Stein, Robert E.. Re-Engineering The Manufacturing System. Marcel Dekker. ISBN0-8247-4265-6. • Stein, Robert E.. The Theory Of Constraints. Marcel Dekker. ISBN0-8247-0064-3.

External links • What is TOC? [16] - In a video Dr. Eliyahu M. Goldratt Explains the definition of Theory of Constraints. • An Online Guide To The Theory Of Constraints [17] - Fundamentals, Thinking Process, Production, Projects, Supply Chain, • The Theory of Constraints in Plain English [18] - A simple example of constraint identification. Healthcare

References [1] Cox, Jeff; Goldratt, Eliyahu M. (1986). The goal: a process of ongoing improvement. [Croton-on-Hudson, NY]: North River Press. ISBN0-88427-061-0. [2] Goldratt, Eliyahu M.. Essays on the Theory of Constraints. [Great Barrington, MA]: North River Press. ISBN0-88427-159-5. [3] Goldratt, Eliyahu; Fox, Robert (1986). The Race. [Croton-on-Hudson, NY]: North River Press. pp.179. ISBN978-0884270621. [4] Eli Schragenheim and H. William Dettmer (2000) (PDF). Simplified Drum-Buffer-Rope: A Whole System Approach to High Velocity Manufacturing (http:/ / www. goalsys. com/ books/ documents/ S-DBRPaper. pdf). . Retrieved 2007-12-08. [5] Corbett, Thomas (1998). Throughput Accounting. North River Press. pp.160. ISBN978-0884271581. [6] Goldratt, Eliyahu M. (1997). Critical Chain. Great Barrington, MA: North River Press. ISBN0-88427-153-6. [7] Paul H. Selden (1997). Sales Process Engineering: A Personal Workshop. Milwaukee, WI: ASQ Quality Press. pp.33–35, 264–268. [8] See the annex of: Vidal, C. 2008. The Future of Scientific Simulations: from Artificial Life to Artificial Cosmogenesis (http:/ / arxiv. org/ abs/ 0803. 1087). In Death And Anti-Death , ed. Charles Tandy, 6: Thirty Years After Kurt Gödel (1906-1978) p. 285-318. Ria University Press.) [9] Qui, Mabel; Fredendall, Lawrence; Zhu, Zhiwei (2002). "TOC or LP? [production control]". Manufacturing Engineer 81 (4): 190–195. [10] http:/ / ac. aua. am/ trietsch/ web/ MBC_to_MBC_II. pdf D. Trietsch, From Management by Constraints (MBC) to Management By Criticalities (MBC II), Human Systems Management (24) 105-115, 2005 [11] http:/ / ac. aua. am/ trietsch/ web/ WorkingPaper281. pdf D. Trietsch, From the Flawed “Theory of Constraints” to Hierarchically Balancing Criticalities (HBC), Department of Information Systems and Operations Management, University of Auckland, Working Paper No. 281, May 2004. [12] http:/ / dx. doi. org/ 10. 1016/ j. ijpe. 2009. 04. 023 Linhares, Alexandre (2009). "Theory of constraints and the combinatorial complexity of the product-mix decision". International Journal of Production Economics 121 (1): 121–129. [13] Steyn, Herman (2000). "An Investigation Into the Fundamentals of Critical Chain Project Scheduling.". International Journal of Project Management (19): 363–369. [14] Eric Noreen; Debra Smith, James T. Mackey (1995). The Theory of Constraints and its implications for Management Accounting. North River Press. pp.149. ISBN0-88427-116-1.

86

Theory of Constraints [15] [16] [17] [18]

Standing on the Shoulders of Giants (http:/ / www. youtube. com/ watch?v=C3RPFUh3ePQ). . http:/ / www. toc. tv?id=166 http:/ / www. dbrmfg. co. nz/ http:/ / idoinfotech. com/ 1331/ management/ toc-theory-of-constraints-basics/

Agile management Agile Management or Agile Project Management is a variant of iterative life cycle[1] where deliverables are submitted in stages. The difference between Agile and iterative development is that the delivery time in Agile is in weeks rather than months. Since Agile Management derives from Agile software development, it follows the same standards defined in the Agile Manifesto when it comes to collaboration and documentation. Several software methods derive from Agile, including Scrum and Extreme Programming.

Comparison with Waterfall Waterfall, as a Project Management methodology, has been criticized for not being able to cope with constant changes in software projects. The iterative nature of Agile makes it an excellent alternative when it comes to managing software projects. Agile, however, has its disadvantages. Many believe that it doesn't scale well, hence large software projects are still being conducted in Waterfall. Additionally, since the strength and usefulness of Agile are both exhibited in projects with frequent changes, it does not offer any advantage over Waterfall when it comes to classical projects where requirements are nearly always constant and unknowns are rare (such as construction projects).

References [1] ExecutiveBrief, Which Life Cycle Is Best For Your Project? (http:/ / www. pmhut. com/ which-life-cycle-is-best-for-your-project), PM Hut. Accessed 23. Oct 2009.

87

Extreme programming

Extreme programming Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1] [2] [3] it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent Planning and feedback loops in extreme programming (XP) with communication with the customer and among the time frames of the multiple loops. programmers.[2] [3] [4] The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if some is good, more is better. It is unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate "death march" work schedules, but instead working at a sustainable pace.[5] Critics have noted several potential drawbacks,[6] including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design specification or document.

History Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.[6] Beck became the C3 project leader in March 1996 and began to refine the development method used in the project and wrote a book on the method (in October 1999, Extreme Programming Explained was published).[6] Chrysler cancelled the C3 project in February 2000, after the company was acquired by Daimler-Benz.[7] Although extreme programming itself is relatively new, many of its practices have been around for some time; the methodology, after all, takes "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s (Larman 2003). Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984.[8]

Origins Software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company-growth as competitive business factors. Rapidly-changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development.

88

Extreme programming The Chrysler Comprehensive Compensation System was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the data access layer. They brought in Kent Beck,[6] a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several problems they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham. Beck describes the early conception of the methods:[9] The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else. Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team. Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original Wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see agile software development). Also, XP concepts have been explained, for several years, using a hyper-text system map on the XP website at "http:/ / www. extremeprogramming. org" circa 1999. Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6), spreading his ideas to a much larger, yet very receptive, audience. Authors in the series went through various aspects attending XP and its practices. Even a book was written, critical of the practices.

Current state XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins. The high discipline required by the original practices often went by the wayside, causing some of these practices that were thought too rigid to be deprecated or left undone on individual sites. Agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field. In the second edition of Extreme Programming Explained, Beck added more values and practices and differentiated between primary and corollary practices.

Concept Goals Extreme Programming Explained describes Extreme Programming as a software development discipline that organizes people to produce higher quality software more productively. In traditional system development methods (such as SSADM or the waterfall model) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high. Like other agile software development methods, XP attempts to reduce the cost of change by having multiple short development cycles, rather than one long one. In this doctrine changes are a natural, inescapable and desirable aspect of software development projects, and should be planned for instead of attempting to define a stable set of requirements. Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming framework.

89

Extreme programming

Activities XP describes four basic activities that are performed within the software development process. Coding The advocates of XP argue that the only truly important product of the system development process is code software instructions a computer can interpret. Without code, there is no work product. Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests which solution is most suitable. Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Code, say the proponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts. Testing One can not be certain that a function works unless one tests it. Bugs and design errors are pervasive problems in software development. Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws. • Unit tests determine whether a given feature works as intended. A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature. • Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements. These occur in the exploration phase of release planning. A "testathon" is an event when programmers meet to do collaborative test writing, a kind of brainstorming relative to software testing. Listening Programmers must listen to what the customers need the system to do, what "business logic" is needed. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved. Communication between the customer and programmer is further addressed in the Planning Game. Designing From the point of view of simplicity, of course one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.

90

Extreme programming

Values Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of Extreme Programming Explained. The five values are: Communication Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback. Simplicity Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the "you ain't gonna need it" (YAGNI) approach.[5] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team. Feedback Within extreme programming, feedback relates to different dimensions of the system development: • Feedback from the system: by writing unit tests,[6] or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes. • Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development. • Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement. Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories.[6] To quote Kent Beck, "Optimism is an occupational hazard of programming, feedback is the treatment." Courage Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary.[6] This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are

91

Extreme programming persistent. Respect The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.

Rules The first version of XP rules was proposed by Ken Hauer[10] in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices (which are subject to more variation and ambiguity). He defined two categories: "Rules of Engagement" which dictate the environment in which software development can take place effectively, and "Rules of Play" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement. In the APSO workshop at ICSE 2008 Conference, Mehdi Mirakhorli proposed a new and more precise and comprehensive version of the Extreme Programming Rules, more independent of the practices, and intended to be more "agile". Rules of engagement According to Mehdi Mirakhorli, these are: • Business people and developers do joint work: Business people and developers must work together daily throughout the project. • Our highest priority is customer satisfaction: The customer must set and continuously adjust the objectives and priorities based on estimates and other information provided by the developers or other members of the team. Objectives are defined in terms of what not how. • Deliver working software frequently: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale (timeboxing). • Working software: Working software is the primary measure of progress. • Global awareness: At any point, any member of the team must be able to measure the team’s progress towards the customer’s objectives and the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. • The team must act as an effective social network, which means: • Honest communication leading to continuous learning and an emphasis on person-to-person interaction, rather than documentation. • Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs. • Alignment of authority and responsibility.

92

Extreme programming

Principles The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation. Feedback Extreme programming sees feedback as most useful if it is done rapidly and expresses that the time between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed. Unit tests also contribute to the rapid feedback principle. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production. Assuming simplicity This is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas. The advocates of extreme programming say that making big changes all at once does not work. Extreme programming applies incremental changes: for example, a system might have small releases every three weeks. When many little steps are made, the customer has more control over the development process and the system that is being developed. Embracing change The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.

Practices Extreme programming has been described as having 12 practices, grouped into four areas:

Fine scale feedback • • • •

Pair programming[6] Planning game Test-driven development Whole team

93

Extreme programming

Continuous process • Continuous integration • Refactoring or design improvement[6] • Small releases

Shared understanding • • • •

Coding standards Collective code ownership[6] Simple design[6] System metaphor

Programmer welfare • Sustainable pace

Coding • The customer is always available • • • •

Code the Unit test first Only one pair integrates code at a time Leave Optimization till last No Overtime

Testing • All code must have Unit tests • All code must pass all Unit tests before it can be released. • When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write) • Acceptance tests are run often and the results are published

Controversial aspects The practices in XP have been heavily debated[6] with strong opinions for or against using XP. Proponents of extreme programming claim that by having the on-site customer[6] request changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded. Change control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users. XP's expedited methodology is somewhat dependent on programmers being able to assume a unified client viewpoint so the programmer can concentrate on coding rather than documentation of compromise objectives and constraints. This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects. Other potentially controversial aspects of extreme programming include: • Requirements are expressed as automated acceptance tests rather than specification documents. • Requirements are defined incrementally, rather than trying to get them all in advance. • Software developers are usually required to work in pairs. • There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics compare this to "debugging a system into appearance" and fear this will result in more re-design effort

94

Extreme programming than only re-designing when requirements change. • A customer representative is attached to the project. This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of micro-management by a non-technical representative trying to dictate the use of technical software features and architecture. • Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way."[11]

Scalability Historically, XP only works on teams of twelve or fewer people. One way to circumvent this limitation is to break up the project into smaller pieces and the team into smaller groups. It has been claimed that XP has been used successfully on teams of over a hundred developers. ThoughtWorks has claimed reasonable success on distributed XP projects with up to sixty people. In 2004 Industrial Extreme Programming (IXP)[12] was introduced as an evolution of XP. It is intended to bring the ability to work in large and distributed teams. It now has 23 practices and flexible values. As it is a new member of the Agile family, there is not enough data to prove its usability, however it claims to be an answer to what it sees as XP's imperfections.

Severability and responses In 2003, Matt Stephens and Doug Rosenberg published Extreme Programming Refactored: The Case Against XP which questioned the value of the XP process and suggested ways in which it could be improved. This triggered a lengthy debate in articles, internet newsgroups, and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organizations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner. Certain aspects of XP have changed since the book Extreme Programming Refactored (2003) was published; in particular, XP now accommodates modifications to the practices as long as the required objectives are still met. XP also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down. RDP Practice is a technique for tailoring extreme programming. This practice was initially proposed as a long research paper in a workshop organized by Philippe Kruchten and Steve Adolph( See APSO workshop [13] at ICSE 2008 [14]) and yet it is the only proposed and applicable method for customizing XP. The valuable concepts behind RDP practice, in a short time provided the rationale for applicability of it in industries. RDP Practice tries to customize XP by relying on technique XP Rules. Other authors have tried to reconcile XP with the older methods in order to form a unified methodology. Some of these XP sought to replace, such as the waterfall method; example: Project Lifecycles: Waterfall, Rapid Application Development, and All That [15]. JPMorgan Chase & Co. tried combining XP with the computer programming methodologies of Capability Maturity Model Integration (CMMI), and Six Sigma. They found that the three systems reinforced each other well, leading to better development, and did not mutually contradict.[16]

95

Extreme programming

Criticism Extreme programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticisms, such as the ones coming from McBreen[17] and Boehm and Turner.[18] Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.[19] In particular, extreme programming is reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored.[20] Criticisms include: • • • • • • • •

A methodology is only as effective as the people involved, Agile does not solve this Often used as a means to bleed money from customers through lack of defining a deliverable Lack of structure and necessary documentation Only works with senior-level developers Incorporates insufficient software design Requires meetings at frequent intervals at enormous expense to customers Requires too much cultural change to adopt Can lead to more difficult contractual negotiations

• Can be very inefficient—if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once. • Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements • Can increase the risk of scope creep due to the lack of detailed requirements documentation • Agile is feature driven; non-functional quality attributes are hard to be placed as user stories

See also • • • • • • • • • •

Software engineering Software Craftsmanship Agile software development Extreme project management Extreme programming practices Pair Programming RDP technique Kai Zen List of software development philosophies Scrum (development)

Further reading • • • •

Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, Addison-Wesley. Kent Beck: Extreme Programming Explained: Embrace Change, Addison-Wesley. Kent Beck and Martin Fowler: Planning Extreme Programming, Addison-Wesley. Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change, Second Edition, Addison-Wesley. • Alistair Cockburn: Agile Software Development, Addison-Wesley. • Martin Fowler: Refactoring: Improving the Design of Existing Code, Addison-Wesley. • Harvey Herela (2005). Case Study: The Chrysler Comprehensive Compensation System [21]. Galen Lab, U.C. Irvine.

96

Extreme programming • Jim Highsmith. Agile Software Development Ecosystems, Addison-Wesley. • Ron Jeffries, Ann Anderson and Chet Hendrickson (2000), Extreme Programming Installed, Addison-Wesley. • Mehdi Mirakhorli (2008). RDP technique: a practice to customize xp, International Conference on Software Engineering, Proceedings of the 2008 international workshop on Scrutinizing agile practices or shoot-out at the agile corral, Leipzig, Germany 2008, Pages 23–32. • Craig Larman & V. Basili (2003). "Iterative and Incremental Development: A Brief History", Computer (IEEE Computer Society) 36 (6): 47-56. • Matt Stephens and Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against XP, Apress. • Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225-256.

External links • • • • • •

What is Extreme Programming [22] Extreme Programming A gentle introduction [23] Industrial eXtreme Programming [24] XP magazine [25] Problems and Solutions to XP implementation [26]

• Using an Agile Software Process with Offshore Development [27] - ThoughtWorks' experiences with implementing XP in large distributed projects

References [1] "Human Centred Technology Workshop 2005", 2005, PDF webpage: Informatics-UK-report-cdrp585 (ftp:/ / ftp. informatics. sussex. ac. uk/ pub/ reports/ csrp/ csrp585. pdf). [2] "Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns (http:/ / www. cis. upenn. edu/ ~matuszek/ cit591-2003/ Lectures/ 49-design-patterns. ppt). [3] "Extreme Programming" (lecture paper), USFCA.edu, webpage: USFCA-edu-601-lecture (http:/ / www. cs. usfca. edu/ ~parrt/ course/ 601/ lectures/ xp. html). [4] "Manifesto for Agile Software Development", Agile Alliance, 2001, webpage: Manifesto-for-Agile-Software-Dev (http:/ / agilemanifesto. org/ ) [5] "Everyone's a Programmer" by Clair Tristram. Technology Review, Nov 2003. p. 39 [6] "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92 (http:/ / www. computerworld. com/ softwaretopics/ software/ appdev/ story/ 0,10801,66192,00. html). [7] Extreme Programming Refactored: The Case Against XP. ISBN1590590961. [8] *Brodie, Leo (1984) (paperback). Thinking Forth (http:/ / thinking-forth. sourceforge. net). Prentice-Hall. ISBN0-13-917568-7. . Retrieved 2006-06-19. [9] http:/ / www. informit. com/ articles/ article. aspx?p=20972 [10] Ken Auer (http:/ / www. rolemodelsoftware. com/ moreAboutUs/ publications/ rulesOfXp. php) [11] The Case Against Extreme Programming: A Self-Referential Safety Net (http:/ / www. softwarereality. com/ lifecycle/ xp/ safety_net. jsp) [12] Cutter Consortium :: Industrial XP: Making XP Work in Large Organizations (http:/ / www. cutter. com/ content-and-analysis/ resource-centers/ agile-project-management/ sample-our-research/ apmr0502. html) [13] http:/ / www. lero. ie/ apso08/ introduction. html [14] http:/ / icse08. upb. de/ [15] http:/ / www. lux-seattle. com/ resources/ whitepapers/ waterfall. htm [16] Extreme Programming (XP) Six Sigma CMMI (http:/ / www. sei. cmu. edu/ library/ assets/ jarvis-gristock. pdf). [17] McBreen, P. (2003). Questioning Extreme Programming. Boston, MA: Addison-Wesley. ISBN0-201-84457-5. [18] Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN0-321-18612-5. [19] sdmagazine (http:/ / www. sdmagazine. com/ documents/ s=1811/ sdm0112h/ 0112h. htm) [20] Extreme Programming Refactored (http:/ / www. softwarereality. com/ ExtremeProgrammingRefactored. jsp), Matt Stephens and Doug Rosenberg, Publisher: Apress L.P. [21] http:/ / calla. ics. uci. edu/ histories/ ccc/ [22] http:/ / thekiransblog. blogspot. com/ 2010/ 02/ multithreading. html [23] http:/ / www. extremeprogramming. org

97

Extreme programming [24] [25] [26] [27]

http:/ / www. IndustrialXP. org/ http:/ / www. xprogramming. com http:/ / c2. com/ cgi/ wiki?ExtremeProgrammingImplementationIssues http:/ / www. martinfowler. com/ articles/ agileOffshore. html

Scrum (development) Scrum is an iterative, incremental framework for project management and agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.[1] The Scrum process. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.

History In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new holistic approach that would increase speed and flexibility in commercial new product development.[2] They compared this new holistic approach, in which the phases strongly overlap and the whole process is performed by one cross-functional team across the different phases, to rugby, where the whole team “tries to go to the distance as a unit, passing the ball back and forth”. The case studies came from the automotive, photo machine, computer and printer industries. In 1991, DeGrace and Stahl, in “Wicked Problems, Righteous Solutions,”[3] referred to this approach as Scrum, a rugby term mentioned in the article by Takeuchi and Nonaka. In the early 1990s, Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods. At the same time, Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and were the first to call it Scrum.[4] In 1995 Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA ’95 in Austin, TX, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001, Schwaber teamed up with Mike Beedle to describe the method in the book “Agile Software Development with Scrum.”

Characteristics Scrum is a “process skeleton” which contains sets of practices and predefined roles. The main roles in Scrum are: 1. the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager) 2. the “Product Owner”, who represents the stakeholders and the business 3. the “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc. During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog”, which is a prioritized set of high level requirements of work to be

98

Scrum (development) done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates how to use the software. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements. There are several implementations of systems for managing the Scrum process, which range from yellow stickers and whiteboards, to software packages. One of Scrum’s biggest advantages is that it is very easy to learn and requires little effort to start using.

Roles A number of roles are defined in Scrum. All roles fall into two distinct groups—pigs and chickens—based on the nature of their involvement in the development process. These groups get their names from a joke [5] about a pig and a chicken opening a restaurant:[6] A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.” So the “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken”—interested in the project but really indifferent because if it fails they’re not the pigs—that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.

“Pig” roles The Pigs are the ones committed to the project in the Scrum process—they are the ones with “their bacon on the line” and performing the actual work of the project. ScrumMaster (or Facilitator) Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand. Team The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.). Product Owner The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user

99

Scrum (development) stories), prioritizes them and then places them in the product backlog. A Product Owner can be a member of the Scrum Team but cannot be a ScrumMaster.[7] According to original Scrum, Product Owner is in a "pig" role. However, if the Product Owner does not have involvement regularly, he/she may be considered as a "chicken" .

“Chicken” roles Chicken roles are not part of the actual Scrum process, but must be taken into account. They are people for whom the software is being built. Stakeholders (customers, vendors) These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews. Managers People who will set up the environment for the product development organizations.

Meetings Daily Scrum Each day during the sprint, a project status meeting occurs. This is called a “daily scrum”, or “the daily standup”. This meeting has specific guidelines: • • • •

The meeting starts precisely on time. All are welcome, but only “pigs” may speak The meeting is timeboxed to 15 minutes The meeting should happen at the same location and same time every day During the meeting, each team member answers three questions:[8]

• What have you done since yesterday? • What are you planning to do today? • Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.) Scrum of scrums or Post-scrum Held each day, normally after the daily scrum. • These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. • A designated person from each team attends. The agenda will be the same as the Daily Scrum, plus the following four questions:[9] • • • •

What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting in their way? Are you about to put something in another team’s way?

Sprint Planning Meeting[10] [11] At the beginning of the sprint cycle (every 7–30 days), a “Sprint Planning Meeting” is held. • Select what work is to be done • Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team • Identify and communicate how much of the work is likely to be done during the current sprint

100

Scrum (development) • Eight hour limit • (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog • (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective” Sprint Review Meeting [12]

• • • •

Review the work that was completed and not completed Present the completed work to the stakeholders (a.k.a. “the demo”) Incomplete work cannot be demonstrated Four hour time limit

Sprint Retrospective [13]

• All team members reflect on the past sprint • Make continuous process improvements • Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? • Three hour time limit

Artifacts Product backlog The product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value. It is the “What” that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return On Investment) is higher. The product backlog is the property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.

Sprint backlog The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. The sprint backlog is the property of the Team. Estimations are set by the Team. Often an accompanying Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

101

Scrum (development)

Burn down The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the Release Burndown Chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the Alternative Release Burndown Chart[14] , which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline. It should not be confused with an earned value chart.

Adaptive project management The following are some general practices of Scrum: • "Working more hours" does not necessarily mean "producing more output" • "A happy team makes a tough task look simple"

Terminology The following terminology is used in Scrum:[15]

Roles Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Team A cross-functional group of people responsible for managing itself to develop the product. Scrum Team Product Owner, ScrumMaster and Team

Artifacts Sprint burn down chart Daily progress for a Sprint over the sprint’s length. Product backlog A prioritized list of high level requirements. Sprint backlog A prioritized list of tasks to be completed during the sprint.

102

Scrum (development)

Others Impediment Anything that prevents a team member from performing work as efficiently as possible. Sprint A time period (typically 2–4 weeks) in which development occurs on a set of backlog items that the Team has committed to. Sashimi A report that something is "done". The definition of "done" may vary from one Scrum Team to another, but must be consistent within one team. Abnormal Termination The team can cancel a Sprint if they feel they are unable to meet the Sprint Goal. Management can cancel a Sprint if external circumstances negate the value of the Sprint Goal. If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

Scrum modifications Scrum-ban Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way which allows for minimum completion time for each user story or programming error, and which on the other hand ensures that each team member is constantly employed. [16] To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. [17] In the case of decentralized teams stage illustration software, such as Assembla, ScrumWorks or (the combination of) JIRA and GreenHopper can be used to visualize each team’s use stories, defects and tasks divided into separate phases. In their simplest, the work stages are • Unstarted • Ongoing • Completed tasks or usage stories. If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work can not be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work. [18] There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times. [19] A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.[18] The major differences between Scrum and Kanban are derived from the fact that in Scrum work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum

103

Scrum (development) focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible. [20] Since Scrum-ban is such a new development model, there is not much reference material. Kanban, on the other hand, has been applied in software development at least by Microsoft and Corbis. [21]

Product development Scrum as applied to product development was first referred to in “The New Product Development Game [22]” (Harvard Business Review 86116:137–146, 1986) and later elaborated in “The Knowledge Creating Company [23]” both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Today there are records of Scrum used to produce financial products, Internet products, and medical products by ADM.

Others MODENA is also related to Scrum.

See also • Kaizen • List of software development philosophies Other Agile methods • • • •

Dynamic System Development Method Extreme programming (XP) Feature Driven Development Lean software development

Further reading • "The Scrum Software Development Process for Small Teams" [24]. 2000. Retrieved 2007-03-15. • Deemer, Pete; Benefield, Gabrielle; Larman, Craig; Vodde, Bas (2009). "The Scrum Primer" [25]. Retrieved 2009-06-01. • Kniberg, Henrik. "Scrum and XP from the Trenches" [26]. Retrieved 2010-01-20.

External links • • • •

Scrum Alliance [27] Agile Alliance’s Scrum library [28] A Scrum Process Asset Library [29] A Scrum Process Description [30] by the Eclipse Process Framework (EPF) Project [31]

104

Scrum (development)

Videos • Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google [32] Retrieved 2007-12-15 • Ken Schwaber in Scrum et al. [33] Retrieved 2008-01-19 • Jeff Sutherland in Hyperproductive Distributed Scrum Teams [34] • Hamid Shojaee in Scrum in 10 Minutes (High Quality HD Video) [35] • Jeff Sutherland in Self-Organization: The Secret Sauce for Improving your Scrum team [36] • Bruno Sbille and his team in Scrum applied on a real-world project (HD) [37] Retrieved 2009-05-19 • Scrum at Large: Managing 100 People and More [38]

References [1] Schwaber, Ken (1 February 2004). Agile Project Management with Scrum. Microsoft Press. ISBN978-0-735-61993-7. [2] Takeuchi, Hirotaka; Nonaka, Ikujiro (January-February 1986). "The New New Product Development Game" (http:/ / hbr. org/ product/ new-new-product-development-game/ an/ 86116-PDF-ENG) (PDF). Harvard Business Review. . Retrieved 2010-06-09. [3] DeGrace, Peter; Stahl, Leslie Hulet (1 October 1990). Wicked problems, righteous solutions. Prentice Hall. ISBN978-0-135-90126-7. [4] Sutherland, Jeff (October 2004). "Agile Development: Lessons learned from the first Scrum" (http:/ / www. scrumalliance. org/ resources/ 35) (PDF). . Retrieved 2008-09-26. [5] "The Classic Story of the Pig and Chicken" (http:/ / www. implementingscrum. com/ 2006/ 09/ 11/ the-classic-story-of-the-pig-and-chicken/ ). Implementing Scrum. 11 September 2006. . Retrieved 2010-04-03. [6] Schwaber, p. 7 [7] "Scrum, Scrum Developer Courses, Scrum Knowledge Assessment, Scrum Guide, Ken Schwaber - Scrum Guides" (http:/ / www. scrum. org/ scrumguides/ ). Scrum.org. 2009. . Retrieved 2010-04-03. [8] Schwaber, p. 135 [9] Cohn, Mike (May 2007). "Advice on Conducting the Scrum of Scrums Meeting" (http:/ / www. scrumalliance. org/ articles/ 46-advice-on-conducting-the-scrum-of-scrums-meeting). . Retrieved 2009-07-23. [10] Schwaber, p. 133 [11] Sprint, Planning (January-February 2009). Sprint Planning Rules (http:/ / www. sprintplanning. com/ SprintPlanningRules. aspx). . Retrieved 2009-03-30. [12] Schwaber, p. 137 [13] Schwaber, p. 138 [14] Invented by Mike Cohn, more info can be found here (http:/ / www. mountaingoatsoftware. com/ pages/ 19-an-alternative-release-burndown-chart) [15] Schwaber, pp. 141–143 [16] p.5 Crisp.se (http:/ / www. crisp. se/ henrik. kniberg/ Kanban-vs-Scrum. pdf) [17] Leansoftwareengineering.com (http:/ / leansoftwareengineering. com/ wp-content/ uploads/ 2008/ 04/ scrumban-001. jpg) [18] Leansoftwareengineering.com (http:/ / leansoftwareengineering. com/ ksse/ scrum-ban/ ) [19] p.18 - 19 Crisp.se (http:/ / www. crisp. se/ henrik. kniberg/ Kanban-vs-Scrum. pdf) [20] p.22 - 23 Crisp.se (http:/ / www. crisp. se/ henrik. kniberg/ Kanban-vs-Scrum. pdf) [21] Infoq.com (The video and the summary) (http:/ / www. infoq. com/ presentations/ kanban-for-software) [22] http:/ / harvardbusinessonline. hbsp. harvard. edu/ b01/ en/ common/ item_detail. jhtml?id=86116 [23] http:/ / books. google. ru/ books?hl=en& id=B-qxrPaU1-MC& dq=The+ Knowledge+ Creating+ Company& printsec=frontcover& source=web& ots=XfRLlzreeT& sig=B5tPPUD6s-hBTlmi4cQLVYosoWs [24] http:/ / members. cox. net/ risingl1/ Articles/ IEEEScrum. pdf [25] http:/ / scrumtraininginstitute. com/ home/ stream_download/ scrumprimer [26] http:/ / www. crisp. se/ henrik. kniberg/ ScrumAndXpFromTheTrenches. pdf [27] http:/ / www. scrumalliance. org/ [28] http:/ / www. agilealliance. org/ article/ articles_by_category/ 17 [29] http:/ / scrum. gem-up. com/ [30] http:/ / epf. eclipse. org/ wikis/ scrum/ [31] http:/ / www. eclipse. org/ epf [32] http:/ / video. google. com/ videoplay?docid=8795214308797356840 [33] http:/ / video. google. com/ videoplay?docid=2531954797594836634 [34] http:/ / www. youtube. com/ watch?v=Ht2xcIJrAXo [35] http:/ / www. youtube. com/ watch?v=Q5k7a9YEoUI& fmt=22 [36] http:/ / www. youtube. com/ watch?v=M1q6b9JI2Wc

105

Scrum (development)

106

[37] http:/ / www. vimeo. com/ 4587652 [38] http:/ / www. tvagile. com/ 2009/ 07/ 24/ scrum-at-large-managing-100-people-and-more/

Event chain methodology Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology is the next advance beyond critical path method and critical chain project management.[1] . Event chain methodology helps to mitigate effect motivational and cognitive biases in estimating and scheduling.[2] [3] . In many cases, project managers intentionally or Event chain diagram unintentionally create project schedules [4] [5] that are impossible to implement . The methodology also simplifies the process of defining risks and uncertainties in project schedules, particularly by improving the ability to provide reality checks and to visualize multiple events. Event chain methodology is used to perform more accurate quantitative analysis while taking into account such factors as relationships between different events and actual moments of the events.

Event Chain Methodology Principles Moment of risk and state of activity An activity (task) in most real life processes is not a continuous uniform procedure. Tasks are affected by external events, which transform an activity from one state to another. One of the important properties of an event is the moment when an event occurs during the course of an activity. This moment, when an event occurs, in most cases is probabilistic and can be defined using statistical distribution.

Moment of risk and state of activity

Event chain methodology

Event Chains Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project. For example, requirement changes can cause an activity to be delayed. To accelerate the activity, the project manager allocates a resource from another activity, which then leads to a missed deadline. Eventually, this can lead to the failure of the project.

Monte Carlo Simulations Once events and event chains are defined, quantitative analysis using Monte Carlo simulation can be performed to quantify the cumulative effect of the events. Probabilities and effects of risks are used as input data for Monte Carlo simulation of the project schedule[6] . In most real life projects, it is necessary to supplement the information regarding the uncertainties expressed as an event, with distributions related to duration, start time, cost, and other parameters.

Critical Event Chains The single events or the event chains that have the most potential to affect the projects are the “critical events” or “critical chains of events.” By identifying critical events or critical chains of events, we can mitigate their negative effects. These critical chains of events can be identified by analyzing the correlations between the main project parameters, such as project duration or cost, and the event chains.

Performance Tracking with Event Chains Monitoring the activity's progress ensures that updated information is used to perform the analysis. During the course of the project, the probability and time of the events can be recalculated based on actual data. The main issue with performance tracking is forecasting an activity’s duration and cost if an activity is partially completed and certain events are assigned to the activity. The simple heuristic approach to this problem is to analyze the moment of risk, which is defined as one of the event parameters. Advanced analysis can be performed using a Bayesian approach.

Event Chain Diagrams Event Chain Diagrams are visualizations that show the relationships between events and tasks and how the events affect each other. The simplest way to represent these chains is to depict them as arrows associated with certain tasks or time intervals on the Gantt chart. Different events and event chains can be displayed using different colors. Events can be global (for all tasks in the project) and local (for a particular task). By using Event Chain Diagrams to visualize events and event chains, the modelling and analysis of risks and uncertainties can be significantly simplified.

Event Chain Methodology Phenomena Repeated Activities

107

Event chain methodology

Sometimes events can cause the start of an activity that has already been completed. This is a very common scenario for real life projects; sometimes a previous activity must be repeated based on the results of a succeeding activity. Modeling of these scenarios using event chain Repeated Acitivity methodology is simple. The original project schedule does not need to be updated, as all that is required is to define the event and assign it to an activity that points to the previous activity. In addition, a limit to the number of times an activity can be repeated needs to be defined.

Event Chains and Risk Mitigation If event or event chain occurs during the course of a project, it may require some mitigation effort. In some cases, mitigation plans can be generated. Mitigation plans are an activity or group of activities (small schedule) that augment the project schedule if a certain event occurs. The solution is to assign the mitigation plan to an event or event chain. These small schedules will be triggered when an event chain occurs. The same mitigation plan can be used for different events.

Resource Allocation Based on Events One potential event is the reassignment of a resource from one activity to another, which can occur under certain conditions. For example, if an activity requires more resources to complete it within a fixed period, this will trigger an event to reallocate the resource from Mitigation plan another activity. Reallocation of resources can also occur when activity duration reaches a certain deadline or the cost exceeds a certain value. Events can be used to model different situations with resources, e.g. temporary leave, illness, vacations, etc.

See also • • • • • • •

Monte Carlo simulation List of project management topics Program Evaluation and Review Technique Project Project management Project planning Work breakdown structure

• List of project management software

108

Event chain methodology

Further reading • Arnaud Doucet, Nando de Freitas and Neil Gordon, Sequential Monte Carlo methods in practice, 2001, ISBN 0-387-95146-6. • Hammond, J.S. and Keeney, R.L. and Raiffa, H., Smart Choices: A Practical Guide to Making Better Decisions (1999). Harvard Business School Press • D. Kahneman and A. Tversky (ed.) (1982). Judgement under Uncertainty: Heuristics and Biases. Cambridge University Press. ISBN 0-521-28414-7 • Keeney, R.L.,Value-focused thinking -- A Path to Creative Decisionmaking (1992). Harvard University Press. ISBN 0-674-93197-1 • Matheson, David, and Matheson, Jim, The Smart Organization: Creating Value through Strategic R&D (1998). Harvard Business School Press. ISBN 0-87584-765-X • Raiffa, Howard, Decision Analysis: Introductory Readings on Choices Under Uncertainty (1997). McGraw Hill. ISBN 0-07-052579-X • Robert C.P. and G. Casella. "Monte Carlo Statistical Methods" (second edition). New York: Springer-Verlag, 2004, ISBN 0-387-21239-6 • Skinner, David, Introduction to Decision Analysis, 2nd Edition (1999). Probabilistic. ISBN 0-9647938-3-0 • Smith, J.Q., Decision Analysis: A Bayesian Approach (1988), Chapman and Hall. ISBN 0-412-27520-1

External links • • • • • • • •

Event Chain Methodology in Details [7] U.S. EPA's General Risk Management Program Guidance (April 2004) [8] NIST Special Publication 800-30 Risk Management Guide for Information Technology Systems (July 2002) [9] Project Management Using Event Chain Methodology [10] Project Planning Using Event Chain Methodology [11] Project Management for Construction, by Chris Hendrickson [4] Resource-Constrained Project Scheduling: Past Work and New Directions [5] Petri Nets for Project Management and Resource Levelling [6]

References [1] [2] [3] [4]

Virine, L. and Trumper M., Project Decisions: The Art and Science (2007). Management Concepts. Vienna, VA, ISBN 978-1567262179 Robyn M. Dawes and Bernard Corrigan, ‘‘Linear Models in Decision Making’’ Psychological Bulletin 81, no. 2 (1974): 93–106. Tversky, A., and D. Kahneman, ‘‘Judgment under uncertainty: heuristics and biases’’ Science 185 (1972): 1125-1130. Flyvbjerg, B. ‘‘From Nobel Prize to project management: getting risks right’’. Project Management Journal, (2006): pp 5-15. (http:/ / flyvbjerg. plan. aau. dk/ Publications2006/ Nobel-PMJ2006. pdf) [5] Flyvbjerg, B., M.K.S. Holm, and S.L. Buhl. ‘‘Underestimating costs in public works projects: Error or Lie?’’ Journal of the American Planning Association 68 no 3 (2002): 279-295 (http:/ / flyvbjerg. plan. aau. dk/ JAPAASPUBLISHED. pdf) [6] Williams, T. ‘‘Why Monte Carlo simulations of project networks can mislead’’. Project Management Journal, Vol 23. No 3, (2006): 53-61 [7] http:/ / www. projectdecisions. org/ paper/ Paper_EventChainMeethodology. pdf [8] http:/ / yosemite. epa. gov/ oswer/ ceppoweb. nsf/ content/ EPAguidance. htm#General [9] http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-30/ sp800-30. pdf [10] http:/ / www. intaver. com/ Articles/ RP_Art_EventChainMethodology. html [11] http:/ / www. planningengineers. org/ publications/ papers_download. aspx?id=20

109

Human interaction management

Human interaction management Human Interaction Management (HIM) is a set of management principles, patterns and techniques complementary to Business process management. HIM provides process-based support for innovative, adaptive, collaborative human work and allows it to be integrated in a structured way with more routinized work processes that are often largely automated. HIM has an associated methodology called Goal-Oriented Organization Design (GOOD). GOOD emphasizes effectiveness over efficiency, and combines various approaches: • Top-down: "Process Architecture" defines business strategy via a network of interacting high-level processes; • Middle-out: "Levels of Control" separate process governance into Strategic, Executive and Management; • Bottom-up: "Stories" represent collaborative work processes that the participants evolve on-the-fly as part of the work itself. The reference implementation of a Human Interaction Management System (HIMS) is the gratis software HumanEdj.

External links • Human Interaction Management website [1] • HumanEdj website [2] • SAP Netweaver Capabilities - Human Interaction Management [3] on SAP Developer Network (SDN)

See also • • • • • • • • •

Business Process Business Process Modeling Business process management Business rules approach Business intelligence Performance management Process management Total Quality Management Workflow

Bibliography • Keith Harrison-Broninski "Human Interactions: The Heart and Soul of Business Process Management" ISBN 0-929652-44-4 • Peter Fingar. "Extreme Competition: Innovation And The Great 21st Century Business Reformation". ISBN 0-929652-38-2

References [1] http:/ / www. human-interaction-management. info/ [2] http:/ / www. humanedj. com/ [3] http:/ / www. sdn. sap. com/ irj/ sdn/ nw-him

110

Process modeling

Process modeling The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.

Overview Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same [1] process model is used repeatedly for the Abstraction level for processes development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.[2] The goals of a process model are to be: • Descriptive • Track what actually happens during a process. • Takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently. • Prescriptive • Defines the desired processes and how they should/could/might be performed. • Lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance. • Explanatory • • • •

Provides explanations about the rationale of processes. Explore and evaluate the several possible courses of action based on rational arguments. Establish an explicit link between processes and the requirements that the model needs to fulfill. Pre-defines points at which data can be extracted for reporting purposes.

Purpose From a theoretical point of view, the Meta-Process Modeling explains the key concepts needed to describe what happens in the development process, on what, when it happens, and why. From an operational point of view, the Meta-Process Modeling is aimed at providing guidance for method engineers and application developers.[1] The activity of modeling a business process usually predicates a need to change processes or identify issues to be corrected. This transformation may or may not require IT involvement, although that is a common driver for the need to model a business process. Change management programmes are desired to put the processes into practice. With advances in technology from larger platform vendors, the vision of business process models (BPM) becoming fully executable (and capable of round-trip engineering) is coming closer to reality every day. Supporting technologies include Unified Modeling Language (UML), model-driven architecture, and service-oriented architecture.

111

Process modeling Process Modeling addresses the process aspects of an Enterprise Business Architecture, leading to an all encompassing Enterprise Architecture. The relationships of a business processes in the context of the rest of the enterprise systems, data, organizational structure, strategies, etc. create greater capabilities in analyzing and planning a change. One real world example is in corporate mergers and acquisitions; understanding the processes in both companies in detail, allowing management to identify redundancies resulting in a smoother merger. Process Modeling has always been a key aspect of business process reengineering, and continuous improvement approaches seen in Six Sigma.

Classification of process models Classification by coverage There are three types of coverage where the term process model has been defined differently[3] : • Activity-oriented: related set of activities conducted for the specific purpose of product definition; a set of partially ordered steps intended to reach a goal. [4] : • Product-oriented: series of activities that cause sensitive product transformations to reach the desired product. • Decision-oriented: set of related decisions conducted for the specific purpose of product definition. • Context-oriented: sequence of contexts causing successive product transformations under the influence of a decision taken in a context. • Strategy-oriented: allow building models representing multi-approach processes and plan different possible ways to elaborate the product based on the notion of intention and strategy [5] .

Classification by alignment Processes can be of different kinds.[2] These definitions “correspond to the various ways in which a process can be modelled”. • Strategic processes • investigate alternative ways of doing a thing and eventually produce a plan for doing it • are often creative and require human co-operation; thus, alternative generation and selection from an alternative are very critical activities • Tactical processes • help in the achievement of a plan • are more concerned with the tactics to be adopted for actual plan achievement than with the development of a plan of achievement • Implementation processes • are the lowest level processes • are directly concerned with the details of the what and how of plan implementation

Classification by granularity Granularity refers to the detail level of the process model and affects the kind of guidance, explanation and trace that can be provided. High granularity limits these to a rather coarse level of detail whereas fine granularity provides more detailed capability. The nature of granularity needed is dependent on the situation at hand.[2] Project manager, customer representatives, the general, top-level, or middle management require rather large-grained process description as they want to gain an overview over time, budget, and resource planning for their decisions. In contrast, software engineers, users, testers, analysts, or software system architects will prefer a fine-grained process model for the details of the model deliver them with instructions and important execution dependencies such as the dependencies between people.

112

Process modeling

113

While notations for fine-grained models exist, most traditional process models are large-grained descriptions. Process models should, ideally, provide a wide range of granularity. (e.g. Process Weaver)[6] [2]

Classification by flexibility It was found that while process models were prescriptive, in actual practice departures from the prescription can occur.[5] Thus, frameworks for adopting methods evolved so that systems development methods match specific organizational situations and thereby improve their usefulness. The development of such frameworks is also called Situational Method Engineering. Method construction approaches can be organized in a spectrum ranging from 'low' flexibility, to 'high'.[7]

Flexibility of Method construction approaches

[7]

Lying at the 'low' end of this spectrum are rigid methods, whereas at the 'high' end there are modular method construction. Rigid methods are completely pre-defined and leave little scope for adapting them to the situation at hand. On the other hand, modular methods can be modified and augmented to fit a given situation. Selecting a rigid methods allows each project to choose its method from a panel of rigid, pre-defined methods, whereas selecting a path within a method consists of choosing the appropriate path for the situation at hand. Finally, selecting and tuning a method allows each project to select methods from different approaches and tune them to the project's needs.” [8]

Quality of process modeling techniques As the quality of process models is being discussed in this paper, there is a need to elaborate quality of modelling techniques as an important essence in quality of process models. In most existing framework created for understanding the quality, the line between quality of modeling techniques and the quality of models as a result of the application of those techniques are not clearly drawn. This report will concentrate both on quality of process modelling techniques and quality of process models in order to clearly differentiate the two. Various framework was develop to help in understanding quality of process modelling techniques, one example is Quality based modelling evaluation framework or known as Q-Me framework which argued to provide set of well defined quality properties and procedures to make an objective assessment of this properties possible[9] . This framework also has advantages of providing uniform and formal description of the model element within one or different model types using one modelling techniques[9] In short this can make assessment of both the product quality and the process quality of modelling techniques with regard to a set of properties that have been defined before. Quality properties that relate to business process modelling techniques discussed in [9] .are: • Expressiveness- the degree to which a given modelling technique is capable of denoting the models of any number and kinds of application domains. • Arbitrariness- the degree of freedom one has when modelling one and the same domain • Suitability-the degree to which a given modelling technique is specifically tailored for a specific kind of application domain. • Comprehensibility- the ease with which the way of working and way of modelling are understood by participants. • Coherence--the degree to which the individual sub models of a way of modelling constitute a whole.

Process modeling • Completeness –the degree to which all necessary concepts of the application domain are represented in the way of modelling. • Efficiency- the degree to which the modelling process utilises resources such as time and people. • Effectiveness- the degree to which the modelling process achieves its goal. In order to asses the quality of Q-ME framework; it is used in illustrating the quality of the dynamic essentials modelling of the organisation (DEMO) business modelling techniques. It is stated that the evaluation of the Q-ME framework to the DEMO modelling techniques has brought up the shortcomings of Q-ME. One particular is that it does not include quantifiable metric to express the quality of business modelling technique which makes it hard to compare quality of different techniques in an overall rating. There is also a systematic approach for quality measurement of modelling techniques known as complexity metrics suggested by Rossi et al. (1996). Techniques of Meta model is used as a basis for computation of these complexity metrics. In comparison to quality framework proposed by Krogstie, quality measurement focus more on technical level instead of individual model level[10] . Authors (Cardoso, Mendling, Neuman and Reijers, 2006) used complexity metrics to measure the simplicity and understandability of a design. This is supported by later research done by Mendling et. al who argued that without utilizing the quality metrics to help question quality properties of a model, simple process can be modelled in a complex and unsuitable way. This in turn can lead to a lower understandability, higher maintenance cost and perhaps inefficient execution of the process in question[11] The quality of modelling technique is important in creating models that are of quality and contribute to the correctness and usefulness of models.

Quality of Process Models Earliest process models reflected the dynamics of the process with a practical process obtained by instantiation in terms of relevant concepts, available technologies, specific implementation environments, process constraints and so on[12] . Enormous number of research has been done on quality of models but less focus has been shifted towards the quality of process models. Quality issues of process models cannot be evaluated exhaustively however there are four main guidelines and frameworks in practice for such .These are : top-down quality frameworks, bottom-up metrics related to quality aspects, empirical surveys related to modeling techniques, and pragmatic guidelines[13] . Hommes quoted Wang et al (1994)[14] that all the main characteristic of quality of models can all be grouped under 2 groups namely correctness and usefulness of a model, correctness ranges from the model correspondence to the phenomenon that is modelled to its correspondence to syntactical rules of the modelling and also it is independent of the purpose to which the model is used. Whereas the usefulness can be seen as the model being helpful for the specific purpose at hand for which the model is constructed at first place. Hommes also makes a further distinction between internal correctness (empirical, syntactical and semantic quality) and external correctness (validity. A common starting point for defining the quality of conceptual model is to look at the linguistic properties of the modelling language of which syntax and semantics are most often applied. Also the broader approach is to be based on semiotics rather than linguistic as was done by Krogstie using the top-down quality framework known as SEQUAL[15] and [16] . It defines several quality aspects based on relationships between a model, knowledge Externalisation, domain, a modeling language, and the activities of learning, taking action, and modelling. The framework does not however provide ways to determine various degrees of quality but has been used extensively for business process modeling in empirical tests carried out [17] According to previous research done by

114

Process modeling Moody et al[18] with use of conceptual model quality framework proposed by Lindland et al(1994) to evaluate quality of process model, three levels of quality[19] were identified: • Syntactic quality: Asses extent to which the model conforms to the grammar rules of modelling language being used. • Semantic quality: whether the model accurately represents user requirements • Pragmatic quality: whether the model can be understood sufficiently by all relevant stakeholders in the modelling process. That is the model should enable its interpreters to make use of it for fulfilling their need. From the research it was noticed that the quality framework was found to be both easy to use and useful in evaluating the quality of process models however it had limitations in regards to reliability and difficult to identify defects. These limitations led to refinement of the framework through subsequent research done by Krogstie. This framework is called SEQUEL framework by Krogstie et al 1995(Refined further by Krogstie & Jørgensen, 2002) which included three more quality aspects. • Physical quality: whether the externalized model externalized model is persistent and available for the audience to make sense of it. • Empirical quality: whether the model is modelled according to the laid down regulations with regards to a particular language. • Social quality: This regards the agreement between the stakeholders in the modelling domain. Dimensions of Conceptual Quality framework [20] Modeling Domain is the set of all statements that are relevant and correct for describing a problem domain, Language Extension is the set of all statements that are possible given the grammar and vocabulary of the modeling languages used. Model Externalization is the conceptual representation of the problem domain. It is defined as the set of statements about the problem domain that are actually made. Social Actor Interpretation and Technical Actor Interpretation are the sets of statements that actors both human model users and the tools that interact with the model, respectively ‘think’ the conceptual representation of the problem domain contains. Finally, Participant Knowledge is the set of statements that human actors, who are involved in the modeling process, believe should be made to represent the problem domain. These quality dimensions were later divided into two groups that deal with physical and social aspects of the model. In later work , Krogstie et al.[15] stated that while the extension of the SEQUAL framework has fixed some of the limitation of the initial framework, however other limitation remain . In particular, the framework is too static in its view upon semantic quality, mainly considering models, not modelling activities, and comparing these models to a static domain rather than seeing the model as a facilitator for changing the domain. Also, the framework’s definition of pragmatic quality is quite narrow, focusing on understanding, in line with the semiotics of Morris, while newer research in linguistics and semiotics has focused beyond mere understanding, on how the model is used and impact its interpreters. The need for a more dynamic view in the semiotic quality framework is particularly evident when considering process models, which themselves often prescribe or even enact actions in the problem domain, hence a change to the model may also change the problem domain directly. This paper discusses the quality framework in relation to active process models and suggests a revised framework based on this. Further work by Krogstie et. al (2006) to revise SEQUAL framework to be more appropriate for active process models by redefining physical quality with a more narrow interpretation than previous research [15] . The other framework in use is Guidelines of Modeling (GoM) [21] based on general accounting principles include the six principles: Correctness, Clarity deals with the comprehensibility and explicitness (System description) of model systems. Comprehensibility relates to graphical arrangement of the information objects and, therefore, supports the understand ability of a model. Relevance relates to the model and the situation being presented. Comparability

115

Process modeling involves the ability to compare models that is semantic comparison between two models, Economic efficiency; the produced cost of the design process need at least to be covered by the proposed utilization of cost cuttings and revenue increases. Since the purpose of organizations in most cases is the maximization of profit, the principle defines the borderline for the modeling process. The last principle is Systematic design defines that there should be an accepted differentiation between diverse views within modeling. Correctness, relevance and economic efficiency are prerequisites in the quality of models and must be fulfilled while the remaining guidelines are optional but necessary. The two frameworks SEQUAL and GOM have a limitation of use in that they cannot be used by people who are not competent with modelling. They provide major quality metrics but are not easily applicable by non experts. The use of bottom-up metrics related to quality aspects of process models is trying to bridge the gap of use of the other two frameworks by non experts in modelling but it is mostly theoretical and no empirical tests have been carried out to support their use. Most experiments carried out relate to the relationship between metrics and quality aspects and these works have been done individually by different authors: Canfora et al. study the connection mainly between count metrics ( for example, the number of tasks or splits -and maintainability of software process models [22] ; Cardoso validates the correlation between control flow complexity and perceived complexity; and Mendling et al. use metrics to predict control flow errors such as deadlocks in process models [23] , [24] The results reveal that an increase in size of a model appears to have a negative impact on quality and their comprehensibility. Further work by Mendling et al. investigates the connection between metrics and understanding [25] and[26] While some metrics are confirmed regarding their impact, also personal factors of the modeller – like competence – are revealed as important for understanding about the models. Several empirical surveys carried out still do not give clear guidelines or ways of evaluating the quality of process models but it is necessary to have clear set of guidelines to guide modellers in this task. Pragmatic guidelines have been proposed by different practitioners even though it is difficult to provide an exhaustive account of such guidelines from practice. In [27] , 10 tips for process modeling are summarized, lots of technical definitions and rules are provided, but it does not teach you how to create process models that are effective in their primary mission maximizing shared understanding of the as-is or to-be process. Most of the guidelines are not easily put to practice but “label activities verb–noun” rule has been suggested by other practitioners before and analyzed empirically. From the research [28] . value of process models is not only dependent on the choice of graphical constructs but also on their annotation with textual labels which need to be analyzed. It was found that it results in better models in terms of understanding than alternative labelling styles. From the earlier research and ways to evaluate process model quality it has been seen that the process model's size, structure, expertise of the modeller and modularity have an impact on its overall understand ability [25] [29] . Based on these a set of guidelines was presented[30] 7 Process Modelling Guidelines (7PMG). This guideline uses the verb-object style, as well as guidelines on the number of elements in a model, the application of structured modeling, and the decomposition of a process model. The guidelines are as follows: • G1 Use as few elements in the model as possible • G2 Minimize the routing paths per element • G3 Use one start and one end event • G4 Model as structured as possible • G5 Avoid OR routing elements • G6 Use verb-object activity labels • G7 Decompose a model with more than 50 elements

116

Process modeling 7PMG still though has limitations with its use: Validity problem 7PMG does not relate to the content of a process model, but only to the way this content is organized and represented. It does suggest ways of organizing different structures of the process model while the content is kept intact but the pragmatic issue of what must be included in the model is still left out. The second limitation relates to the prioritizing guideline the derived ranking has a small empirical basis as it relies on the involvement of 21 process modellers only. This could be seen on the one hand as a need for a wider involvement of process modellers’ experience, but it also rises the question what alternative approaches may be available to arrive at a prioritizing guideline [30] .

See also • • • • • • •

Business process modeling Process Process architecture Process flow diagram Process (science) Process Specification Language Process ontology

External links • • • • •

Modeling processes regarding workflow patterns [31] "Abstraction Levels for Processes Presentation: Process Modeling Principles" [32] (PDF). How to model goal-oriented processes in WS-BPEL [33] "Abstraction Levels for Processes Presentation: Process Modeling Principles" [32] (PDF). American Productivity and Quality Center (APQC) [34], a worldwide organization for process and performance improvement

References [1] Colette Rolland (1993). Modeling the Requirements Engineering Process. 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases. [2] Colette Rolland and Pernici, C. Thanos (1998). A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE'98. B. Lecture Notes in Computer Science 1413. Springer. [3] M. Dowson (1998). Iteration in the Software Process, Proc 9th Int. Conf. on Software Engineering. [4] P.H. Feiler and W.S. Humphrey. (1993). Software Process Development and Enactment: Concepts and Definitions, Proc. 2nd Int. Conf. on "Software Process" [5] Colette Rolland (1994). A Multi-Model View of Process Modelling. Requirements Engineering. Vol 4, Nr 4. Springer-Verlag. [6] C. Fernström and L. Ohlsson (1991). Integration Needs in Process Enacted Environments, Proc. 1st Int. Conf. on the Software Process. IEEE computer Society Press. [7] A.F. Harmsen, Sjaak Brinkkemper and J.L.H. Oei (1994). Situational Method Engineering for information Systems Project Approaches. North Holland [8] Colette Rolland (1997). 'A Primer for Method Engineering. Proceedings of the INFORSID Conference. [9] BJ Hommes, V Van Reijswoud , Assessing the Quality of Business Process Modeling Techniques -Proceedings of the 33rd Hawaii International Conference on System Sciences – 2000 [10] Bart-Jan Hommes, The evaluation of business process modeling techniques, 2000 [11] J. Mendling, M. Moser, G. Neumann, H. Verbeek, B. Dongen, W. van der Aalst, A Quantitative Analysis of Faulty EPCs in the SAP Reference Model, BPM Center Report BPM-06-08, BPMCenter.org, 2006. [12] Proceedings of the 9th international conference on Software Engineering [13] J. Mendling, H.A. Reijers, W.M.P. van der Aalst.Seven process modeling guidelines (7PMG) Information and Software Technology, Volume 52, Issue 2, February 2010, Pages 127-136 [14] Bart-Jan Hommes, The evaluation of business process modeling techniques, 2000 [15] J. Krogstie, G. Sindre, H. Jorgensen, Process models representing knowledge for action: a revised quality framework, European Journal of Information Systems 15 (1) (2006) 91-102.

117

Process modeling [16] O. Lindland, G. Sindre and A. Sølvberg, Understanding quality in conceptual modeling, IEEE Software 11 (2) (1994), pp. 42–49 [17] D. Moody, G. Sindre, T. Brasethvik and A. Sølvberg, Evaluating the quality of process models: empirical testing of a quality framework. In: S. Spaccapietra, S.T. March and Y. Kambayashi, Editors, Conceptual Modeling – ER 2002, 21st International Conference on Conceptual Modeling, Tampere, Finland, October 7–11, 2002, Proceedings, Lecture Notes in Computer Science vol. 2503, Springer (2002), pp. 380–396. [18] Daniel L. Moody, G. Sindre, T. Brasethvik, A. Sølvberg. Evaluating the Quality of Process Models: Empirical Testing of a Quality Framework [19] Morris, C.W. (1970): Foundations of the Theory of Signs, Chicago: Chicago University Press [20] J. Krogstie, O. Lindland, G. Sindre, Defining quality aspects for conceptual models, in: Proc. IFIP8.1 Working Conference on Information Systems Concepts: Towards a Consolidation of Views, Marburg, Germany, 1995. [21] J. Becker, M. Rosemann and C. Uthmann, Guidelines of business process modeling. In: W. van der Aalst, J. Desel and A. Oberweis, Editors, Business Process Management. Models, Techniques, and Empirical Studies, Springer, Berlin (2000), pp. 30–49 [22] G. Canfora, F. Garcıa, M. Piattini, F. Ruiz and C. Visaggio, A family of experiments to validate metrics for software process models, Journal of Systems and Software 77 (2) (2005), pp. 113–129. [23] J. Mendling, M. Moser, G. Neumann, H. Verbeek, B. Dongen, W. van der Aalst, A Quantitative Analysis of Faulty EPCs in the SAP Reference Model, BPM Center Report BPM-06-08, BPMCenter.org, 2006. [24] J. Mendling, Detection and prediction of errors in epc business process models, Ph.D. thesis, Vienna University of Economics and Business Administration, http:/ / wi. wu-wien. ac. at/ home/ mendling/ publications/ Mendling%20Doctoral%20thesis. pdf, 2007. [25] J. Mendling, H.A. Reijers and J. Cardoso, What makes process models understandable?. In: G. Alonso, P. Dadam and M. Rosemann, Editors, Business Process Management, 5th International Conference, BPM 2007, Brisbane, Australia, September 24–28, 2007, Proceedings, Lecture Notes in Computer Science vol. 4714, Springer, Brisbane, Australia (2007), pp. 48–63. [26] J. Mendling and M. Strembeck, Influence factors of understanding business process models. In: W. Abramowicz and D. Fensel, Editors, Proceedings of the 11th International Conference on Business Information Systems (BIS 2008), Lecture Notes in Business Information Processing vol. 7, Springer-Verlag (2008), p. 142153. [27] B.Silver,Ten Tips for Effective Process Modeling,BPMInstitute.org, ,Wednesday January 30, 2008 [28] J. Mendling, H.A. Reijers, J. Recker, Activity Labeling in Process Modeling: Empirical Insights and Recommendations, Information Systems. URL: [29] H. A. Reijers, J. Mendling, Modularity in process models: Review and effects in: M. Dumas, M. Reichert, M.-C. Shan (Eds.), Business Process Management BPM 2008, Vol. 5240 of Lecture Notes in Computer Science, Springer, Milan, Italy, 2008, pp. 20-35 [30] J. Mendling, H. A. Reijers, W. M. P. van der Aalst, Seven process modeling guidelines (7pmg), QUT ePrints Report 12340, Queensland University of Technology (2008) [31] ftp:/ / ftp. informatik. uni-stuttgart. de/ pub/ library/ medoc. ustuttgart_fi/ STUD-2052/ STUD-2052. pdf [32] http:/ / www. modelingconcepts. com/ pdf/ BPM_V2. pdf [33] ftp:/ / ftp. informatik. uni-stuttgart. de/ pub/ library/ medoc. ustuttgart_fi/ DIP-2787/ DIP-2787. pdf [34] http:/ / www. apqc. org/

118

Event chain diagram

119

Event chain diagram Event Chain Diagrams are visualizations that show the relationships between events and tasks and how the events affect each other. Event chain diagram are introduced as a part of Event chain methodology. Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology is the next advance beyond critical path method and critical chain project management.

Event chain diagram

Rules Event chain diagrams are presented on the Gantt chart according to the specification. This specification is a set of rules, which can be understandable by anybody using this diagram: 1. All events are shown as arrows. Names and/or IDs of events are shown next to the arrow. 2. Events with negative impacts (risks) are represented by down arrows; events with positive impacts (opportunities) are represented by up arrows. 3. Individual events are connected by lines representing the event chain. 4. A sender event with multiple connecting lines to receivers represents multicasting. 5. Events affecting all activities (global events) are shown outside Gantt chart. Threats are shown at the top of the diagram. Opportunities are shown at the bottom of the diagram. Often event chain diagrams can become very complex. In these cases, some details of the diagram do not need to be shown.

Optional rules 1. Horizontal positions of the event arrows on the Gantt bar correspond with the mean moment of the event. 2. Probability of an event can be shown next to the event arrow. 3. Size of the arrow represents relative probability of an event. If the arrow is small, the probability of the event is correspondingly small. 4. Multiple diagrams may be required to represent different event chains for the same schedule. 5. Different colors can be use to represent different events (arrows) and connecting lines associated with different chains. The central purpose of event chain diagrams is not to show all possible individual events. Rather, event chain diagrams can be used to understand the relationship between events. Therefore, it is recommended the event chain diagrams be used only for the most significant events during the event identification and analysis stage. Event chain diagrams can be used as part of the risk identification process, particularly during brainstorming meetings. Members of project teams can draw arrows between associated with activities on the Gantt chart. Event chain diagrams can be

Event chain diagram

120

used together with other diagramming tools. The simplest way to represent these chains is to depict them as arrows associated with certain tasks or time intervals on the Gantt chart. Different events and event chains can be displayed using different colors. Events can be global (for all tasks in the project) and local (for a particular task). By using Event Chain Diagrams to visualize events and event chains, the modeling and analysis of risks and uncertainties can be significantly simplified.

See also • PERT Charts • Gantt Charts • Run Charts

External links • Event Chain Methodology whitepaper [1]

References [1] http:/ / www. intaver. com/ Articles/ Article_EventChainMethodology. pdf

Gantt chart A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e. precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line as shown here.

A Gantt chart showing three kinds of schedule dependencies (in red) and percent complete indications.

Although now regarded as a common charting technique, Gantt charts were considered revolutionary when they were introduced. In recognition of Henry Gantt's contributions, the Henry Laurence Gantt Medal is awarded for distinguished achievement in management and in community service. This chart is used also in Information Technology to represent data that have been collected.

Gantt chart

Historical development The first known tool of this type was reportedly developed in 1896 by Karol Adamiecki, who called it a harmonogram. Adamiecki did not publish his chart until 1931, however, and then only in Polish. The chart is commonly known after Henry Gantt (1861–1919), who designed his chart around the years 1910–1915.[1] [2] In the 1980s, personal computers allowed for widespread creation of complex and elaborate Gantt charts. The first desktop applications were intended mainly for project managers and project schedulers. With the advent of the internet and increased collaboration over networks at the end of the 1990s, Gantt charts became a common feature of web-based applications, including collaborative groupware.

Advantages and limitations Gantt charts have become a common technique for representing the phases and activities of a project work breakdown structure (WBS), so they can be understood by a wide audience. A common error made by those who equate Gantt chart design with project design is that they attempt to define the project work breakdown structure at the same time that they define schedule activities. This practice makes it very difficult to follow the 100% Rule. Instead the WBS should be fully defined to follow the 100% Rule, then the project schedule can be designed. [3] Although a Gantt chart is useful and valuable for small projects that fit on a single sheet or screen, they can become quite unwieldy for projects with more than about 30 activities. Larger Gantt charts may not be suitable for most computer displays. A related criticism is that Gantt charts communicate relatively little information per unit area of display. That is, projects are often considerably more complex than can be communicated effectively with a Gantt chart. Gantt charts only represent part of the triple constraints (cost, time and scope) of projects, because they focus primarily on schedule management. Moreover, Gantt charts do not represent the size of a project or the relative size of work elements, therefore the magnitude of a behind-schedule condition is easily miscommunicated. If two projects are the same number of days behind schedule, the larger project has a larger impact on resource utilization, yet the Gantt does not represent this difference. Although project management software can show schedule dependencies as lines between activities, displaying a large number of dependencies may result in a cluttered or unreadable chart. Because the horizontal bars of a Gantt chart have a fixed height, they can misrepresent the time-phased workload (resource requirements) of a project, which may cause confusion especially in large projects. In the example shown in this article, Activities E and G appear to be the same size, but in reality they may be orders of magnitude different. A related criticism is that all activities of a Gantt chart show planned workload as constant. In practice, many activities (especially summary elements) have front-loaded or back-loaded work plans, so a Gantt chart with percent-complete shading may actually miscommunicate the true schedule performance status.

121

Gantt chart

122

Some Examples In the following example there are seven tasks, labeled A through G. Some tasks can be done concurrently (A and B) while others cannot be done until their predecessor task is complete (C cannot begin until A is complete). Additionally, each task has three time estimates: the optimistic time estimate (O), the most likely or normal time estimate (M), and the pessimistic time estimate (P). The expected time (TE) is computed using the formula (O + 4M + P) ÷ 6. Activity Predecessor

Time estimates Opt. (O)

Expected time

Normal (M)

Pess. (P)

A

2

4

6

4.00

B

3

5

9

5.33

C

A

4

5

7

5.17

D

A

4

6

10

6.33

E

B, C

4

5

7

5.17

F

D

3

4

8

4.50

G

E

3

5

8

5.17

Once this step is complete, one can draw a Gantt chart or a network diagram.

See also • • • •

Critical path method List of project management software Program Evaluation and Review Technique (PERT) Event chain diagram

External links • Long-running discussion [4] regarding limitations of the Gantt chart format, and alternatives, on Edward Tufte's website

References [1] H.L. Gantt, Work, Wages and Profit, published by The Engineering Magazine, New York, 1910; republished as Work, Wages and Profits, Easton, Pennsylvania, Hive Publishing Company, 1974, ISBN 0879600489. [2] Peter W. G. Morris, The Management of Projects, Thomas Telford, 1994, ISBN 0727725939, Google Print, p.18 (http:/ / books. google. com/ books?id=5ekyoWaeZ1UC& pg=PA18-IA7& dq=Adamiecki+ Gantt& as_brr=3& sig=xe_RAipoqlvhnu0xLkIsxx-8OAQ) [3] Project Management Institute (2003). A Guide To The Project Management Body Of Knowledge (3rd ed. ed.). Project Management Institute. ISBN 1-930699-45-X. [4] http:/ / www. edwardtufte. com/ bboard/ q-and-a-fetch-msg?msg_id=000076& topic_id=1& topic=Ask%20E%2eT%2e

PRINCE2

123

PRINCE2 PRojects IN Controlled Environments (PRINCE) is a project management method. It covers the management, control and organisation of a project. "PRINCE2" refers to the second major version of this method and is a registered trademark of the Office of Government Commerce (OGC), an independent office of HM Treasury of the United Kingdom.

History PRINCE2 is derived from an earlier method called PROMPTII[1] , and from PRINCE project management method, which was initially developed in 1989 by the Central Computer and Telecommunications Agency (CCTA) as a UK Government standard for information systems (IT) project management; however, it soon became regularly applied outside the purely IT environment.[2] PRINCE2 was released in 1996 as a generic project management method.[3] PRINCE2 has become increasingly popular and is now a de facto standard for project management in the UK.[4] Its use has spread beyond the UK to more than 50 other countries. The most current revision was released in 2009 as part of the Prince2:2009 refresh project Government Commerce.

[5]

by the Office of

PRINCE2:2009 Refresh: Since 2006, the method has been revised and launched as "PRINCE2:2009 Refresh" on June 16th, 2009. The name "PRINCE2" (instead of "PRINCE3" or similar) is kept to indicate that the method remains faithful to its principles. Nevertheless, it is a fundamental revision of the method from 1996 to adapt it to the changed business environment, to make the method simpler and "lighter", to address current weaknesses or misunderstandings, and to better integrate it with other OGC methods (ITIL, P3O, P3M3, MSP, M_o_R etc.). The main difference between the 2009 version and earlier versions is that there will be two manuals: 'Managing Successful Projects with PRINCE2 - 2009 Edition' and 'Directing Successful Projects with PRINCE2 - 2009 Edition'. Both the Foundation and Practitioner Examinations will be based on the new 'Managing Projects' manual and will not include material from the new 'Directing Successful Projects' book. The pass mark for the Foundation exam will remain unchanged but the pass mark for the Practitioner exam will increase from the current 50% to 55%. The Practitioner exam will also shorten in length from 3 hours to 2.5 hours. Further info about the refresh is available here.[6]

Advantages PRINCE2 is a structured approach to project management. It provides a method for managing projects within a clearly defined framework. PRINCE2 describes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it doesn’t develop as planned. In the method each process is specified with its key inputs and outputs and with specific goals and activities to be carried out, which gives an automatic control of any deviations from the plan. Divided into manageable stages, the method enables an efficient control of resources. On the basis of close monitoring the project can be carried out in a controlled and organised way. Being a structured method widely recognised and understood, PRINCE2 provides a common language for all participants in the project. The various management roles and responsibilities involved in a project are fully described and are adaptable to suit the complexity of the project and skills of the organisation.

PRINCE2

124

Pitfalls PRINCE2 is sometimes incorrectly considered inappropriate for very small projects, due to the work required in creating and maintaining documents, logs and lists. However, this may often be because of a misunderstanding about which parts of PRINCE2 to apply: PRINCE2 is fully scalable.[7]

Overview of the method

Diagram showing PRINCE2 processes. The arrows represent flows of information.

PRINCE2 is a process-driven project management method[8] which contrasts with reactive/adaptive methods such as Scrum. PRINCE2 2009 defines 40 separate activities and organizes these into seven processes:

Starting up a project In this process the project team is appointed and a project brief (describing, in outline, what the project is attempting to achieve and the business justification for doing so) is prepared. In addition the overall approach to be taken is decided and the next stage of the project is planned. Once this work is done, the project board is asked to authorize the next stage, that of initiating the project. Key activities include: appointing an executive and a project manager; designing and appointing a project management team; preparing a project brief; defining the project approach; and planning the next stage (initiation).

Initiating a project This process builds on the work of the start up process, and the project brief is augmented to form a Business case. The approach taken to ensure quality on the project is agreed together with the overall approach to controlling the project itself (project controls). Project files are also created as is an overall plan for the project. A plan for the next stage of the project is also created. The resultant information can be put before the project board for them to authorize the project itself. Key activities include: planning quality; planning a project; refining the business case and risks; setting up project controls; setting up project files; and assembling a Project Initiation Document.

PRINCE2

Directing a project This process dictates how the Project Board (which comprises such roles as the executive sponsor or project sponsor) should control the overall project. As mentioned above, the project board can authorise an initiation stage and can also authorize a project. Directing a Project also dictates how the project board should authorize a stage plan, including any stage plan that replaces an existing stage plan due to slippage or other unforeseen circumstances. Also covered is the way in which the board can give ad hoc direction to a project and the way in which a project should be closed down. Key activities include: authorising initiation; authorising a project; authorising a stage or exception plan; giving ad-hoc direction; and confirming project closure.

Controlling a stage PRINCE2 suggests that projects should be broken down into stages and these sub-processes dictate how each individual stage should be controlled. Most fundamentally this includes the way in which work packages are authorised and received. It also specifies the way in which progress should be monitored and how the highlights of the progress should be reported to the project board. A means for capturing and assessing project issues is suggested together with the way in which corrective action should be taken. It also lays down the method by which certain project issues should be escalated to the project board. Key activities include: authorising work package; assessing progress; capturing and examining project issues; reviewing stage status; reporting highlights; taking corrective action; escalating project issues; and receiving a completed work package.

Managing stage boundaries The Controlling a Stage process dictates what should be done within a stage, Managing Stage Boundaries (SB) dictates what should be done towards the end of a stage. Most obviously, the next stage should be planned and the overall project plan, risk log and business case amended as necessary. The process also covers what should be done for a stage that has gone outside its tolerance levels. Finally, the process dictates how the end of the stage should be reported. Key activities include: planning a stage; updating a project plan; updating a project business case; updating the risk log; reporting stage end; and producing an exception plan.

Managing product delivery The Managing product delivery process has the purpose of controlling the link between the Project Manager and the Team Manager(s) by placing formal requirements on accepting, executing and delivering project work[9] . The Objectives of the Managing Product Delivery process are: - To ensure that work on products allocated to the team is authorised and agreed, - Team Manager(s), team members and suppliers are clear as to what is to be produced and what is the expected effort, cost and timescales, - The planned products are delivered to expectations and within tolerance, - Accurate progress information is provided to the Project Manager at an agreed frequency to ensure that expectations are managed. The key activities are: Accept a work package, execute a work package and deliver a work package.

125

PRINCE2

Closing a project This covers the things that should be done at the end of a project. The project should be formally de-commissioned (and resources freed up for allocation to other activities), follow on actions should be identified and the project itself be formally evaluated. Key activities include: decommissioning a project; identifying follow-on actions; and project evaluation review.

Techniques The PRINCE2 method works with most project management techniques but specifically describes the following: • Product based planning • Change Control Technique • Quality Review Technique

Quality Review Technique The quality review technique ensures a project's products are of the required standard (i.e. meet defined quality criteria). 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. The meeting brings together people who have an interest in the project's outputs (or products) and people on the project team able to address issues identified. There are defined roles including a Producer and Scribe. More about Quality Assurance.

Exams, accreditation and training Accreditation is governed by the passing of two exams – the Foundation and the Practitioner. The Foundation exam is a one-hour, multiple choice exam. The Practitioner exam lasts for 2.5 hours, and is an objective-testing multiple-choice exam. Around the world, exams are administered by the APM Group. The successful candidate register can be searched on the web.[10] It is possible for individuals with project management experience to self-study for the exams but a number of training organisations offer courses, many of which also include exam entry in the fee. There is a mandatory accreditation scheme for training providers, run by the APM Group, which provides them with access to the official PRINCE2 examinations. PRINCE2 Practitioners must retake the Practitioner exam every 5 years to remain accredited. This re-registration comprises a 1-hour examination set at the same standard as the Practitioner examination.[11] Trainers must be re-accredited every 3 years and undergo a surveillance check (either in the form of a visit by an assessor to a training course or a telephone interview of their professional knowledge by an assessor) every 12 months.

Scalability Project management is a complex discipline and it would be wrong to assume that blind application of PRINCE2 will result in a successful project. By the same token, it would be wrong to assume that every aspect of PRINCE2 will be applicable to every project. For this reason every process has a note on scalability. This provides guidance to the project manager (and others involved in the project) as to how much of the process to apply. The positive aspect of this is that PRINCE2 can be tailored to the needs of a particular project. The negative aspect is that many of the essential elements of PRINCE2 can be omitted sometimes resulting in a PINO project – Prince in Name Only. In order to counter this, APM Group have defined the concept of a PRINCE2 Maturity Model[12] .

126

PRINCE2

Adoption PRINCE2, as a method and a certification, is adopted in most of Western Europe and Australia. The PMI and its certification, the PMP, are highly dominant in the US.

See also List of project management topics

External links • • • •

Official website [7] The APM Group PRINCE2 website [13] The OGC officially recognised user group [14] Guidelines for Managing Projects (fully consistent with PRINCE2) [25] from the UK Department for Business, Enterprise and Regulatory Reform (BERR)

References [1] OGC (Office of Government Commerce) (2005). Managing Successful Projects with PRINCE2. TSO (The Stationery Office). ISBN9780113309467. [2] OGC - PRINCE2 - Background (http:/ / www. ogc. gov. uk/ methods_prince_2__background. asp) [3] Office of Government Commerce (2005-12-14). "OGC brings its shining quartet back into the limelight" (http:/ / www. ogc. gov. uk/ news_2005_4333. asp). Press release. . [4] APM Group - Official PRINCE2 website (http:/ / www. prince-officialsite. com/ ) [5] Office of Government Commerce (2009). Managing successful projects with PRINCE2 (5th ed.). The Stationery Office. pp.342. ISBN978-0113310593. [6] "Managing and Directing Successful Projects with PRINCE2" (http:/ / www. best-management-practice. com/ gempdf/ PRINCE2_2009_Overview_Brochure_June2009. pdf). Press release. June 2009. . Retrieved 2009-08-05. [7] OGC Best Management Practice - PRINCE2 (http:/ / www. best-management-practice. com/ Knowledge-Centre/ Best-Practice-Guidance/ PRINCE2/ ) [8] OGC - PRINCE2 - What is it? (http:/ / www. ogc. gov. uk/ methods_prince_2__whatisit. asp) [9] OGC Prince2 manual [10] APM Group - Successful Candidate Register (http:/ / www. apmgroup. co. uk/ examquery. asp) [11] PRINCE2 Re-Registration Examination (http:/ / www. apmgroup. co. uk/ PRINCE2/ Qualifications/ ReRegistrationExamination. asp) [12] PRINCE2 Maturity Model (http:/ / www. apmgroup. co. uk/ Accreditation/ MaturityAssessment/ PRINCE2MaturityModel. asp) [13] http:/ / www. apmgroup. co. uk/ PRINCE2/ PRINCE2Home. asp [14] http:/ / www. usergroup. org. uk/

127

Process-based management

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. Most companies are focused around organizational performance such as budgets, incentives, costs, and skill development. Process Based Management adds these performance measures but in an operational way that adds to the organizational measures. Over time, the process measures take a stronger role. The "Order to Cash" process for instance is what brings revenue into a company, but often, conventional companies are so focused on their individual departments that the cross functional process is an afterthought. Performance suffers because of this. CAM-I is currently performing research on this concept. (www.cam-i.org)

ISO/IEC 15504 ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), is a "framework for the assessment of processes" developed by the Joint Technical Subcommittee between ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission). ISO/IEC 15504 initially was derived from process lifecycle standard ISO 12207 and from maturity models like Bootstrap, Trillium and the CMM.

Overview ISO/IEC 15504 is an international standard. ISO/IEC 15504 is concerned about the many national maturity model proposals and establishes an international standard in this area. ISO/IEC 15504 presents a reference model as an international reference. ISO/IEC 15504 is the reference model for the maturity models (consisting of capability levels which in turn consist of the process attributes and further consist of generic practices) against which the assessors can place the evidence that they collect during their assessment, so that the assessors can give an overall determination of the organisation's capabilities for delivering products (software, systems, IT services).[1] ISO/IEC 15504 was developed by the Joint Technical Subcommittee between ISO (International Organization for Standardization) and IEC (International Electrotechnical Committee).

128

ISO/IEC 15504

History A working group was formed in 1993 to draft the international standard and used the acronym, SPICE. SPICE initially stood for "Software Process Improvement and Capability Evaluation", but French concerns over the meaning of the last word meant that SPICE now means "Software Process Improvement and Capability Determination". Even though the formal ISO standards number, ISO 15504, is now the correct reference, SPICE is still used for the user group of the standard, and the title for the annual conference. The first SPICE was held in Limerick, Ireland in 2000, "SPICE 2003" was hosted by ESA in Netherlands, "SPICE 2004" was hosted in Portugal, "SPICE 2005" in Austria, "SPICE 2006" in Luxembourg, "SPICE 2007" in South Korea, "SPICE 2008" in Nuremberg, Germany and SPICE 2009 in Helsinki, Finland. The first versions of the standard focused exclusively on software development processes. This was expanded to cover all related processes in a software business, for example, project management, configuration management, quality assurance, and so on. The list of processes covered, grew to cover six business areas: • organizational • management • engineering • acquisition supply • support • operations. In a major revision to the draft standard in 2004, the process reference model was removed and is now related to the ISO 12207 (Software Lifecycle Processes). The issued standard now specifies the measurement framework and can use different process reference models. There are five general and industry models in use. Part 5 specifies software process assessment and part 6 specifies system process assessment. The latest work in the ISO standards working group includes creation of a maturity model, which is planned to become ISO/IEC 15504 part 7.

The ISO/IEC 15504 standard The Technical Report (TR) document for ISO/IEC TR 15504 was divided into 9 parts. The initial International Standard was recreated in 5 parts. This was proposed from Japan when the TRs were published at 1997. The International Standard (IS) version of ISO/IEC 15504 now comprises 6 parts. The 7th part is currently in an advanced Final Draft Standard form[2] and work has started on part 8. Part 1 of ISO/IEC TR 15504 explains the concepts and gives an overview of the framework. Nationality of editors of ISO/IEC 15504 5 parts are below. • • • • •

Part 1, Japan, South Africa. Part 2, Japan, U.K. Part 3, U.S.A, Italy. Part 4, U.K., Israel. Part 5, France, Finland.

129

ISO/IEC 15504

130

Reference model ISO/IEC 15504 contains a reference model. The reference model defines a process dimension and a capability dimension. The process dimension in the reference model is not the subject of part 2 of ISO/IEC 15504, but part 2 refers to external process lifecycle standards including ISO/IEC 12207 and ISO/IEC 15288.[3] The standard defines means to verify conformity of reference models.[4] Processes The process dimension defines processes divided into the five process categories of: • • • • •

customer-supplier engineering supporting management organization

With new parts being published, the process categories will expand, particularly for IT service process categories and enterprise process categories. Capability levels and process attributes For each process, ISO/IEC 15504 defines a capability level on the following scale:[1] Level

Name

5

Optimizing process

4

Predictable process

3

Established process

2

Managed process

1

Performed process

Incomplete process

The capability of processes is measured using process attributes. The international standard defines nine process attributes: • • • • • • • • •

1.1 Process Performance 2.1 Performance Management 2.2 Work Product Management 3.1 Process Definition 3.2 Process Deployment 4.1 Process Measurement 4.2 Process Control 5.1 Process Innovation 5.2 Process Optimization.

Each process attribute consists of one or more generic practices, which are further elaborated into practice indicators to aid assessment performance. Each process attribute is assessed on a four-point (N-P-L-F) rating scale: • Not achieved (0 - 15%) • Partially achieved (>15% - 50%) • Largely achieved (>50%- 85%)

ISO/IEC 15504 • Fully achieved (>85% - 100%). The rating is based upon evidence collected against the practice indicators, which demonstrate fulfillment of the process attribute.[5]

Assessments ISO/IEC 15504 provides a guide for performing an assessment.[6] This includes: • the assessment process • the model for the assessment • any tools used in the assessment Assessment process Performing assessments is the subject of parts 2 and 3 of ISO/IEC 15504.[7] Part 2 is the normative part and part 3 gives a guidance to fulfill the requirements in part 2. One of the requirements is to use a conformant assessment method for the assessment process. The actual method is not specified in the standard although the standard places requirements on the method, method developers and assessors using the method.[8] The standard provides general guidance to assessors and this must be supplemented by undergoing formal training and detailed guidance during initial assessments. The assessment process can be generalized as the following steps: • initiate an assessment (assessment sponsor) • select assessor and assessment team • plan the assessment, including processes and organizational unit to be assessed (lead assessor and assessment team) • pre-assessment briefing • data collection • data validation • process rating • reporting the assessment result An assessor can collect data on a process by various means, including interviews with persons performing the process, collecting documents and quality records, and collecting statistical process data. The assessor validates this data to ensure it is accurate and completely covers the assessment scope. The assessor assesses this data (using their expert judgment) against a process's base practices and the capability dimension's generic practices in the process rating step. Process rating requires some exercising of expert judgment on the part of the assessor and this is the reason that there are requirements on assessor qualifications and competency. The process rating is then presented as a preliminary finding to the sponsor (and preferably also to the persons assessed) to ensure that they agree that the assessment is accurate. In a few cases, there may be feedback requiring further assessment before a final process rating is made.[9]

131

ISO/IEC 15504 Assessment model The process assessment model (PAM) is the detailed model that is used for an actual assessment. This is an elaboration of the process reference model (PRM) provided by the process lifecycle standards.[10] The process assessment model (PAM) in part 5 is based on the process reference model (PRM) for software: ISO/IEC 12207.[11] The process assessment model in part 6 is based on the process reference model for systems: ISO/IEC 15288.[12] The standard allows other models to be used instead, if they meet ISO/IEC 15504's criteria, which include a defined community of interest and meeting the requirements for content (i.e. process purpose, process outcomes and assessment indicators). Tools used in the assessment There exist several assessment tools. The simplest comprise paper-based tools that are manually used. In general, they are laid out to incorporate the assessment model indicators, including the base practice indicators and generic practice indicators. Assessors write down the assessment results and notes supporting the assessment judgment. There are a limited number of computer based tools that present the indicators and allow users to enter the assessment judgment and notes in formatted screens, as well as automate the collated assessment result (i.e. the process attribute ratings) and creating reports.

Assessor qualifications and competency For a successful assessment, the assessor must have a suitable level of the relevant skills and experience. These skills include: • • • •

personal qualities such as communication skills. relevant education and training and experience. specific skills for particular categories, e.g. management skills for the management category. ISO/IEC 15504 related training and experience in process capability assessments.

The competency of assessors is the subject of part 3 of ISO/IEC 15504. In summary, the ISO/IEC 15504 specific training and experience for assessors comprise: • completion of a 5 day lead assessor training course • performing at least one assessment successfully under supervision of a competent lead assessor • performing at least one assessment successfully as a lead assessor under the supervision of a competent lead assessor. The competent lead assessor defines when the assessment is successfully performed. There exist schemes for certifying assessors and guiding lead assessors in making this judgment.[8]

Uses of ISO/IEC 15504 ISO/IEC 15504 can be used in two contexts: • Process improvement, and • Capability determination (= evaluation of supplier's process capability). Process improvement ISO/IEC 15504 can be used to perform process improvement within a technology organization.[13] Process improvement is always difficult, and initiatives often fail, so it is important to understand the initial baseline level (process capability level), and to assess the situation after an improvement project. ISO 15504 provides a standard for assessing the organization's capacity to deliver at each of these stages.

132

ISO/IEC 15504 In particular, the reference framework of ISO/IEC 15504 provides a structure for defining objectives, which facilitates specific programs to achieve these objectives. Process improvement is the subject of part 4 of ISO/IEC 15504. It specifies requirements for improvement programmes and provides guidance on planning and executing improvements, including a description of an eight step improvement programme. Following this improvement programme is not mandatory and several alternative improvement programmes exist.[9] Capability determination An organization considering outsourcing software development needs to have a good understanding of the capability of potential suppliers to deliver. ISO/IEC 15504 (Part 4) can also be used to inform supplier selection decisions. The ISO/IEC 15504 framework provides a framework for assessing proposed suppliers, as assessed either by the organization itself, or by an independent assessor.[14] The organization can determine a target capability for suppliers, based on the organization's needs, and then assess suppliers against a set of target process profiles that specify this target capability. Part 4 of the ISO/IEC 15504 specifies the high level requirements and an initiative has been started to create an extended part of the standard covering target process profiles. Target process profiles are particularly important in contexts where the organization (for example, a government department) is required to accept the cheapest qualifying vendor. This also enables suppliers to identify gaps between their current capability and the level required by a potential customer, and to undertake improvement to achieve the contract requirements (i.e. become qualified). Work on extending the value of capability determination includes a method called Practical Process Profiles - which uses risk as the determining factor in setting target process profiles.[9] Combining risk and processes promotes improvement with active risk reduction, hence reducing the likelihood of problems occurring.

Acceptance of ISO/IEC 15504 ISO/IEC 15504 has been successful as: • • • • • •

ISO/IEC 15504 is publicly available through National Standards Bodies. It has the support of the international community. Over 4000 assessments have been performed to date. Major sectors are leading the pace such as automotive, space and medical systems with industry relevant variants. Domain-specific models like Automotive SPICE and SPICE 4 SPACE can be derived from it. There have been many international initiatives to support take-up such as SPICE for small companies.

On the other hand, ISO/IEC 15504 has not yet been as successful as the CMMI. This has been for several reasons: • ISO/IEC 15504 is not available as free download but must be purchased from the ISO (Automotive SPICE on the other hand can be freely downloaded from the link supplied below.) CMM and CMMI are available as free downloads from the SEI website. • The CMMI is actively sponsored (by the US Department of Defense). • The CMM was created first, and reached critical 'market' share before ISO 15504 became available. • The CMM has subsequently been replaced by the CMMI, which incorporates many of the ideas of ISO/IEC 15504, but also retains the benefits of the CMM. Like the CMM, ISO/IEC 15504 was created in a development context, making it difficult to apply in a service management context. But work has started to develop an ITIL-based process reference model that can serve as a basis for a process assessment model. This is planned to become part 8 to the standard. In addition there are methods available that adapt its use to various contexts.

133

ISO/IEC 15504

Further reading • ISO/IEC 15504-1:2004 Information technology Process assessment Part 1: Concepts and vocabulary • ISO/IEC 15504-2:2003 Information technology Process assessment Part 2: Performing an Assessment • ISO/IEC 15504-3:2004 Information technology Process assessment Part 3: Guidance on performing an assessment • ISO/IEC 15504-4:2004 Information technology Process assessment Part 4: Guidance on use for process improvement and process capability determination • ISO/IEC 15504-5:2006 Information technology Process Assessment Part 5: An exemplar Process Assessment Model • ISO/IEC PRF TR 15504-6 Information technology Process assessment Part 6: An exemplar system life cycle Process Assessment Model • ISO/IEC DTR 15504-7 Information technology Process assessment Part 7: Assessment of Organizational Maturity • van Loon, H. (2007a) Process Assessment and ISO 15504 Springer ISBN 9780387300481 • van Loon, H. (2007b) Process Assessment and Improvement Springer ISBN 9780387300443

External links • • • •

ISO 15504 News (isospice) [15] Página de la ISO/IEC 15504 SPICE en Castellano [16] Foro en Castellano de la ISO/IEC 15504 [17] Automotive SPICE [18]

References [1] ISO/IEC 15504-2 Clause 5 [2] DTR, meaning Draft Technical Report [3] ISO/IEC 15504-2 Clause 6 [4] ISO/IEC 15504-2 Clause 7 [5] ISO/IEC 15504 part 3 [6] ISO/IEC 15504 parts 2 and 3 [7] ISO/IEC 15504-2 Clause 4 and ISO/IEC 15504-3 [8] van Loon, 2007a [9] van Loon, 2007b [10] ISO 15504-2 Clause 6.2 [11] ISO/IEC 15504-2 Clause 6.3 and ISO/IEC 15504-5 [12] ISO/IEC 15504-6 [13] ISO/IEC 15504-4 Clause 6 [14] ISO/IEC 15504-4 Clause 7 [15] http:/ / www. isospice. com [16] http:/ / www. iso15504. es [17] http:/ / www. iso15504. es/ index. php?option=com_kunena& Itemid=81 [18] http:/ / www. automotivespice. com/

134

Capability Maturity Model Integration

135

Capability Maturity Model Integration Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. CMMI in software engineering and organizational development is a trademarked process improvement approach that provides organizations with the essential elements for effective process improvement. According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes."[2]

Characteristics of the Maturity levels.

[1]

Overview CMMI currently addresses three areas of interest: 1. Product and service development — CMMI for Development (CMMI-DEV), 2. Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and

Capability Maturity Model Integration.

3. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ). CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.[1] CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM (CMM, see below)...

Capability Maturity Model Integration

136

History CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association. CMMI is the successor of the capability maturity model (CMM) or software CMM. The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released. Version 1.2 followed in August 2006.

CMMI topics CMMI representation CMMI exists in two representations: continuous and staged.[1] The continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risk. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI.[1]

CMMI model framework Depending on the CMMI constellation (acquisition, services, development) used, the process areas it contains will vary. Key process areas are the areas that will be covered by the organization's processes. The table below lists the process areas that are present in all CMMI constellations. This collection of eight process areas is called the CMMI Model Framework, or CMF.

Capability Maturity Model Integration (CMMI) Model Framework (CMF) Abbreviation

Name

Area

Maturity Level

REQM

Requirements Management

Engineering

2

PMC

Project Monitoring and Control

Project Management

2

PP

Project Planning

Project Management

2

CM

Configuration Management

Support

2

MA

Measurement and Analysis

Support

2

PPQA

Process and Product Quality Assurance

Support

2

OPD

Organizational Process Definition

Process Management

3

CAR

Causal Analysis

Support

5

Capability Maturity Model Integration

CMMI models CMMI best practices are published in documents called models, each of which addresses a different area of interest. The current release of CMMI, version 1.2, provides models for three areas of interest: development, acquisition, and services. • CMMI for Development (CMMI-DEV [6]), v1.2 was released in August 2006. It addresses product and service development processes. • CMMI for Acquisition (CMMI-ACQ [3]), v1.2 was released in November 2007. It addresses supply chain management, acquisition, and outsourcing processes in government and industry. • CMMI for Services (CMMI-SVC [4]), v1.2 was released in February 2009. It addresses guidance for delivering services within an organization and to external customers. • CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is expected to be released in 2010. CMMI Version 1.3—Plans for the Next Version [5] Regardless of which model an organization chooses, CMMI best practices should be adapted by an organization according to its business objectives.

Appraisal An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile. Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons: 1. To determine how well the organization’s processes compare to CMMI best practices, and to identify areas where improvement can be made 2. To inform external customers and suppliers of how well the organization’s processes compare to CMMI best practices 3. To meet the contractual requirements of one or more customers Appraisals of organizations using a CMMI model[6] must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals, A, B and C, which focus on identifying improvement opportunities and comparing the organization’s processes to CMMI best practices. Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions. The appraisal results can then be used (e.g., by a process group) to plan improvements for the organization. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method that meets all of the ARC requirements.[7] A class A appraisal is more formal and is the only one that can result in a level rating. Results of an appraisal may be published (if the appraised organization approves) on the CMMI Web site of the SEI: Published SCAMPI Appraisal Results [8]. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), assessments etc.

Achieving CMMI compliance The traditional approach that organizations often adopt to achieve compliance with the CMMI involves the establishment of an Engineering Process Group (EPG) and Process Action Teams (PATs) [9] This approach requires that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM and

137

Capability Maturity Model Integration primarily using the traditional approach.[10] These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the CMMI. The Software Engineering Institute’s (SEI) Team Software Process methodology and the Capability Maturity Modeling framework have been successfully employed to accelerate progress from Maturity Level 1 to Maturity Level 4. They’ve demonstrated progressing from Level 1 to Level 4 in 30 months, which is less than half of the average time it has taken traditionally.[11]

Applications The SEI published that 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction.[12] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. These results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the process maturity profile [13] (page 10). Of the small organizations ( Entstehungskontext (http:/ / cartoon. iguw. tuwien. ac. at/ fit/ fit01/ wasserfall/ entstehung. html), Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007. [4] (Boehm, 1986) [5] (Boehm, 1986 and 1988) [6] (Boehm, 2000) [7] Georges Gauthier Merx & Ronald J. Norman (2006). Unified Software Engineering with Java. p.201. [8] Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration (http:/ / www. mel. nist. gov/ msidlibrary/ doc/ AMIS-Concepts. pdf) NIST 2003. [9] Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. (http:/ / www. osti. gov/ energycitations/ servlets/ purl/ 10160331-YhIRrY/ ) Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group. [10] Kuhn, D.L (1989). "Selecting and effectively using a computer aided software engineering tool". Annual Westinghouse computer symposium; 6-7 Nov 1989; Pittsburgh, PA (USA); DOE Project. [11] P.Loucopoulus and V. Karakostas. System Requirement Engineering. [12] CASE (http:/ / www. its. bldrdoc. gov/ projects/ devglossary/ _case. html) definition In: Telecom Glossary 2000 (http:/ / www. its. bldrdoc. gov/ projects/ devglossary/ ). Retrieved 26 Oct 2008. [13] K. Robinson (1992). Putting the Software Engineering into CASE. New York : John Wiley and Sons Inc. [14] Xiao He (2007). "A metamodel for the notation of graphical modeling languages". In: Computer Software and Applications Conference, 2007. COMPSAC 2007 - Vol. 1. 31st Annual International, Volume 1, Issue , 24–27 July 2007, pp 219-224. [15] http:/ / www. cms. hhs. gov/ SystemLifecycleFramework/ Downloads/ SelectingDevelopmentApproach. pdf [16] http:/ / www. techbookreport. com/ SoftwareIndex. html

473

Organization

Organization An organization (or organisation — see spelling differences) is a social arrangement which pursues collective goals, controls its own performance, and has a boundary separating it from its environment. The word itself is derived from the Greek word organon, itself derived from the better-known word ergon. In the social sciences, organizations are the object of analysis for a number of disciplines, such as sociology, economics, political science, psychology, management, and organizational communication. In more specific contexts, particularly for sociologists, the term "institution" may be preferred. The broader analysis of organizations is commonly referred to as organizational studies, organizational behavior or organization analysis. A number of different theories and perspectives exist, some of which are compatible, • Organization – process-related: an entity is being (re-)organized (organization as task or action). • Organization – functional: organization as a function of how entities like businesses or state authorities are used (organization as a permanent structure). • Organization – institutional: an entity is an organization (organization as an actual purposeful structure within a social context)

Organization in sociology Sociology can be defined as the science of the institutions of modernity; specific institutions serve a function, akin to the individual organs of a coherent body. In the social and political sciences in general, an "organization" may be more loosely understood as the planned, coordinated and purposeful action of human beings to reach a common goal or construct a tangible product. This action is usually framed by formal membership and form (institutional rules). Sociology distinguishes the term organization into planned formal and unplanned informal (i.e. spontaneously formed) organizations. Sociology analyzes organizations in the first line from an institutional perspective. In this sense, organization is a permanent arrangement of elements. These elements and their actions are determined by rules so that a certain task can be fulfilled through a system of coordinated division of labor. An organization is defined by the elements that are part of it (who belongs to the organization and who does not?), its communication (which elements communicate and how do they communicate?), its autonomy (Max Weber termed autonomy in this context: Autocephaly (which changes are executed autonomously by the organization or its elements?), and its rules of action compared to outside events (what causes an organization to act as a collective actor?). By coordinated and planned cooperation of the elements, the organization is able to solve tasks that lie beyond the abilities of the single elements. The price paid by the elements is the limitation of the degrees of freedom of the elements. Advantages of organizations are enhancement (more of the same), addition (combination of different features) and extension. Disadvantages can be inertness (through co-ordination) and loss of interaction.

474

Organization

Organization in management and organizational studies Management is interested in organization mainly from an instrumental point of view. For a company, organization is a means to an end to achieve its goals - which are to create value for its stakeholders (stockholders, employees, customers, suppliers, community).

Organization theories Among the theories that are or have been most influential are: • • • • • • • • •

Weberian organization theory (refer to Max Weber's chapter on Bureaucracy in his book 'Economy and Society') Marxist organization analysis Scientific management (mainly following Frederick W. Taylor) Human Relations Studies (going back to the Hawthorne studies, Maslow and Hertzberg) Contingency theory New institutionalism and new institutional economics Network analysis Economic sociology Organization ecology (or demography of organizations)

• • • • • • • • •

Agency theory (sometimes called principal - agent theory) Studies of organization culture Labour Process Theory Critical Management Studies Complexity Theory and Organizations Transaction cost theory/Transaction cost Economics (TCE) Garbage can model Actor-Network Theory social entrepreneurship

Organizational structures The study of organizations includes a focus on optimizing organizational structure. According to management science, most human organizations fall roughly into four types: • • • •

Pyramids or hierarchies Committees or juries Matrix organizations Ecologies

Pyramids or hierarchies A hierarchy exemplifies an arrangement with a leader who leads leaders. This arrangement is often associated with bureaucracy. Hierarchies were satirized in The Peter Principle (1969), a book that introduced hierarchiology and the saying that "in a hierarchy every employee tends to rise to his level of incompetence". These structures are formed on the basis that there are enough people under the leader to give him support. Just as one would imagine a real pyramid, if there are not enough stone blocks to hold up the higher ones, gravity would irrevocably bring down the monumental structure. So one can imagine that if the leader does not have the support of his lesser leaders, the entire structure will collapse. An extremely rigid, in terms of responsibilities, type of organization is exemplified by Führerprinzip.

475

Organization

Committees or juries These consist of a group of peers who decide as a group, perhaps by voting. The difference between a jury and a committee is that the members of the committee are usually assigned to perform or lead further actions after the group comes to a decision, whereas members of a jury come to a decision. In common law countries legal juries render decisions of guilt, liability and quantify damages; juries are also used in athletic contests, book awards and similar activities. Sometimes a selection committee functions like a jury. In the Middle Ages juries in continental Europe were used to determine the law according to consensus amongst local notables. Committees are often the most reliable way to make decisions. Condorcet's jury theorem proved that if the average member votes better than a roll of dice, then adding more members increases the number of majorities that can come to a correct vote (however correctness is defined). The problem is that if the average member is worse than a roll of dice, the committee's decisions grow worse, not better: Staffing is crucial. Parliamentary procedure, such as Robert's Rules of Order, helps prevent committees from engaging in lengthy discussions without reaching decisions.

Staff organization or cross-functional team A staff helps an expert get all his work done. To this end, a "chief of staff" decides whether an assignment is routine or not. If it's routine, he assigns it to a staff member, who is a sort of junior expert. The chief of staff schedules the routine problems, and checks that they are completed. If a problem is not routine, the chief of staff notices. He passes it to the expert, who solves the problem, and educates the staff – converting the problem into a routine problem. In a "cross functional team", like an executive committee, the boss has to be a non-expert, because so many kinds of expertise are required.

Organization: Cyclical structure A theory put forth by renowned scholar Stephen John has asserted that throughout the cyclical nature of one’s life organizational patterns are key to success. Through various social and political constraints within society one must realize that organizational skills are paramount to success. Stephen John suggests that emphasis needs to be put on areas such as individual/ group processes, functionality, and overall structures of institutions in order to maintain a proper organization. Furthermore, the individual's overall organizational skills are pre-determined by the processes undertaken.:

Matrix organization This organizational type assigns each worker two bosses in two different hierarchies. One hierarchy is "functional" and assures that each type of expert in the organization is well-trained, and measured by a boss who is super-expert in the same field. The other direction is "executive" and tries to get projects completed using the experts. Projects might be organized by regions, customer types, or some other schema.

Ecologies This organization has intense competition. Bad parts of the organization starve. Good ones get more work. Everybody is paid for what they actually do, and runs a tiny business that has to show a profit, or they are fired. Companies who utilize this organization type reflect a rather one-sided view of what goes on in ecology. It is also the case that a natural ecosystem has a natural border - ecoregions do not in general compete with one another in any way, but are very autonomous. The pharmaceutical company GlaxoSmithKline talks about functioning as this type of organization in this external article [1] from The Guardian.

476

Organization

"Chaordic" organizations The chaordic model of organizing human endeavors emerged in the 1990s. The idea is based on a blending of chaos and order (hence "chaordic"), and originated in the work of Dee Hock and the creation of the VISA financial network. Blending democracy, complex systems, consensus decision making, co-operation and competition, the chaordic approach attempts to encourage organizations to evolve from the increasingly nonviable hierarchical, command-and-control models. It can be compared to the similar principles of emergent organization and self-organization. See also group entity for an anarchist perspective on human organizations. Organizations that are legal entities: government, international organization, non-governmental organization, armed forces, corporation, partnership, charity, not-for-profit corporation, cooperative, university.

The organization of the artist The organization of the artist is a term first used by architect Frank Gehry to denote the organizational set-up he enforces in order to ensure that the architect/artist is in control of design through construction. The organization of the artist deliberately eliminates the influence of politicians and business people on design. The purpose of the organization of the artist is to ensure that it is the design of the architect/artist that is actually implemented and not some compromise decided by political and business interests. Gehry initially developed the concept of the organization of the artist as a reaction against what he calls the "marginalization of the architect/artist." Gehry explains: "There's a tendency to marginalize and treat the creative people like women are treated, 'sweetie, us big business guys know how to do this, just give us the design and we'll take it from there.' That is the worst thing that can happen. It requires the organization of the artist to prevail so that the end product is as close as possible to the object of desire [the design] that both the client and architect have come to agree on." (Flyvbjerg 2005, 53). Gehry argues that the organization of the artist, in addition to making possible artistic integrity, also helps keep his buildings on time and budget, which is rare for the type of innovative and complex designs that Gehry is known for. The organization of the artist thus serves the dual purpose of artistic freedom and economic prudence.

Leadership in organizations Leadership in formal organizations An organization that is established as an instrument or means for achieving defined objectives has been referred to as a formal organization. Its design specifies how goals are subdivided and reflected in subdivisions of the organization. Divisions, departments, sections, positions, jobs, and tasks make up this work structure. Thus, the formal organization is expected to behave impersonally in regard to relationships with clients or with its members. According to Weber's definition, entry and subsequent advancement is by merit or seniority. Each employee receives a salary and enjoys a degree of tenure that safeguards him from the arbitrary influence of superiors or of powerful clients. The higher his position in the hierarchy, the greater his presumed expertise in adjudicating problems that may arise in the course of the work carried out at lower levels of the organization. It is this bureaucratic structure that forms the basis for the appointment of heads or chiefs of administrative subdivisions in the organization and endows them with the authority attached to their position.[2] • “An effective leader must be able to develop people.”-R.Hewett

477

Organization

Leadership in informal organizations In contrast to the appointed head or chief of an administrative unit, a leader emerges within the context of the informal organization that underlies the formal structure. The informal organization expresses the personal objectives and goals of the individual membership. Their objectives and goals may or may not coincide with those of the formal organization. The informal organization represents an extension of the social structures that generally characterize human life — the spontaneous emergence of groups and organizations as ends in themselves.[2] In prehistoric times, man was preoccupied with his personal security, maintenance, protection, and survival. Now man spends a major portion of his waking hours working for organizations. His need to identify with a community that provides security, protection, maintenance, and a feeling of belonging continues unchanged from prehistoric times. This need is met by the informal organization and its emergent, or unofficial, leaders.[3] Leaders emerge from within the structure of the informal organization. Their personal qualities, the demands of the situation, or a combination of these and other factors attract followers who accept their leadership within one or several overlay structures. Instead of the authority of position held by an appointed head or chief, the emergent leader wields influence or power. Influence is the ability of a person to gain cooperation from others by means of persuasion or control over rewards. Power is a stronger form of influence because it reflects a person's ability to enforce action through the control of a means of punishment.[3]

Leader in organizations An individual who is appointed to a managerial position has the right to command and enforce obedience by virtue of the authority of his position. However, he must possess adequate personal attributes to match his authority, because authority is only potentially available to him. In the absence of sufficient personal competence, a manager may be confronted by an emergent leader who can challenge his role in the organization and reduce it to that of a figurehead. However, only authority of position has the backing of formal sanctions. It follows that whoever wields personal influence and power can legitimize this only by gaining a formal position in the hierarchy, with commensurate authority.[3]

Hybrid organizations A hybrid organization is a body that operates in both the public sector and the private sector, simultaneously fulfilling public duties and developing commercial market activities. As a result the hybrid organization becomes a mixture of both a part of government and a private corporation.

See also • • • • • • • • • • •

Affinity group Bureaucracy Business organization Charitable trust Coalition Collective Cooperative Hybrid organization International organization Mutual organization Non-governmental organization

• Organizational culture • Organization design

478

Organization • • • • • • • • • • • • • •

Organizational climate Organizational development Organization of the artist Organization studies Pacifist organization Requisite organization Service organization Size of groups, organizations, and communities Strategic management Strategic planning Terrorist organizations Umbrella organization Virtual organization Voluntary association

Related lists • List of environmental organizations • List of civic, fraternal, service, and professional organizations • List of professional organizations • List of trade unions

References • • • • • • • • • • • • • • •

Richard Scott. Organizations. ISBN 0-13-266354-6 Richard Scott. Organizations and Institutions Charles Handy.Understanding Organizations Laurence J. Peter and Raymond Hull. The Peter Principle Pan Books 1970 ISBN 0-330-02519-8 Ronald Coase (1937). "The Nature of the Firm" Economica, 4(16), pp.386–405. Julie Morgenstern (1998). Organizing from the Inside Out. Owl Books ISBN 0-8050-5649-1 Henry Mintzberg (1981). "Organization Design: Fashion or Fit" Harvard Business Review (January February), Thomas Marshak (1987). "organization theory," The New Palgrave: A Dictionary of Economics, v. 3, pp.757–60. Bent Flyvbjerg (2005). "Design by Deception: The Politics of Megaproject Approval." Harvard Design Magazine, no. 22, Spring/Summer issue, pp. 50-59. [4] Daniel Katz; Robert Louis Kahn (1966). The social psychology of organizations. New York: Wiley. OCLC255184. Daniel Katz; Robert Louis Kahn (1966). The social psychology of organizations. New York: Wiley. OCLC255184. Richard Arvid Johnson (1976). Management, systems, and society : an introduction. Pacific Palisades, Calif.: Goodyear Pub. Co.. ISBN0876205406 9780876205402. OCLC2299496. Virginia Satir (1967). Conjoint family therapy; a guide to theory and technique. Palo Alto, Calif.: Science and Behavior Books. OCLC187068. James G March; Herbert A Simon (1958). Organizations. New York: Wiley. ISBN0471567930 9780471567936. OCLC1329335. Carl R Rogers; Fritz Jules Roethlisberger (1990). Barriers and gateways to communication. Boston, Mass.: Harvard Business Review. OCLC154085959.

• Hewlett, Roderic. (2006). The Cognitive leader. Rowman & Littlefield Pub Inc.

479

Organization

External links • Research on Organizations: Bibliography Database and Maps [10] • TheTransitioner.org [5]: a site dedicated to collective intelligence and structure of organizations

References [1] http:/ / www. guardian. co. uk/ business/ story/ 0,3604,1294443,00. html [2] Cecil A Gibb (1970). Leadership (Handbook of Social Psychology). Reading, Mass.: Addison-Wesley. pp.884–89. ISBN0140805176 9780140805178. OCLC174777513. [3] Henry P. Knowles; Borje O. Saxberg (1971). Personality and Leadership Behavior. Reading, Mass.: Addison-Wesley. pp.884–89. ISBN0140805176 9780140805178. OCLC118832. [4] http:/ / flyvbjerg. plan. aau. dk/ HARVARDDESIGN63PRINT. pdf [5] http:/ / www. thetransitioner. org

Strategic management Strategic or institutional management is the conduct of drafting, implementing and evaluating cross-functional decisions that will enable an organization to achieve its long-term objectives.[1] It is the process of specifying the organization's mission, vision and objectives, developing policies and plans, often in terms of projects and programs, which are designed to achieve these objectives, and then allocating resources to implement the policies and plans, projects and programs. A balanced scorecard is often used to evaluate the overall performance of the business and its progress towards objectives. Strategic management is a level of managerial activity under setting goals and over Tactics. Strategic management provides overall direction to the enterprise and is closely related to the field of Organization Studies. In the field of business administration it is useful to talk about "strategic alignment" between the organization and its environment or "strategic consistency". According to Arieu (2007), "there is strategic consistency when the actions of an organization are consistent with the expectations of management, and these in turn are with the market and the context." “Strategic management is an ongoing process that evaluates and controls the business and the industries in which the company is involved; assesses its competitors and sets goals and strategies to meet all existing and potential competitors; and then reassesses each strategy annually or quarterly [i.e. regularly] to determine how it has been implemented and whether it has succeeded or needs replacement by a new strategy to meet changed circumstances, new technology, new competitors, a new economic environment., or a new social, financial, or political environment.” (Lamb, 1984:ix)[2]

Strategy formulation Strategic formulation is a combination of three main processes which are as follows: • Performing a situation analysis, self-evaluation and competitor analysis: both internal and external; both micro-environmental and macro-environmental. • Concurrent with this assessment, objectives are set. These objectives should be parallel to a time-line; some are in the short-term and others on the long-term. This involves crafting vision statements (long term view of a possible future), mission statements (the role that the organization gives itself in society), overall corporate objectives (both financial and strategic), strategic business unit objectives (both financial and strategic), and tactical objectives. • These objectives should, in the light of the situation analysis, suggest a strategic plan. The plan provides the details of how to achieve these objectives.

480

Strategic management

Strategy evaluation • Measuring the effectiveness of the organizational strategy, it's extremely important to conduct a SWOT analysis to figure out the strengths, weaknesses, opportunities and threats (both internal and external) of the entity in question. This may require to take certain precautionary measures or even to change the entire strategy. In corporate strategy, Johnson and Scholes present a model in which strategic options are evaluated against three key success criteria: • Suitability (would it work?) • Feasibility (can it be made to work?) • Acceptability (will they work it?)

Suitability Suitability deals with the overall rationale of the strategy. The key point to consider is whether the strategy would address the key strategic issues underlined by the organisation's strategic position. • Does it make economic sense? • Would the organization obtain economies of scale, economies of scope or experience economy? • Would it be suitable in terms of environment and capabilities? Tools that can be used to evaluate suitability include: • Ranking strategic options • Decision trees

Feasibility Feasibility is concerned with whether the resources required to implement the strategy are available, can be developed or obtained. Resources include funding, people, time and information. Tools that can be used to evaluate feasibility include: • cash flow analysis and forecasting • break-even analysis • resource deployment analysis

Acceptability Acceptability is concerned with the expectations of the identified stakeholders (mainly shareholders, employees and customers) with the expected performance outcomes, which can be return, risk and stakeholder reactions. • Return deals with the benefits expected by the stakeholders (financial and non-financial). For example, shareholders would expect the increase of their wealth, employees would expect improvement in their careers and customers would expect better value for money. • Risk deals with the probability and consequences of failure of a strategy (financial and non-financial). • Stakeholder reactions deals with anticipating the likely reaction of stakeholders. Shareholders could oppose the issuing of new shares, employees and unions could oppose outsourcing for fear of losing their jobs, customers could have concerns over a merger with regards to quality and support. Tools that can be used to evaluate acceptability include: • what-if analysis • stakeholder mapping

481

Strategic management

General approaches In general terms, there are two main approaches, which are opposite but complement each other in some ways, to strategic management: • The Industrial Organizational Approach • based on economic theory — deals with issues like competitive rivalry, resource allocation, economies of scale • assumptions — rationality, self discipline behaviour, profit maximization • The Sociological Approach • deals primarily with human interactions • assumptions — bounded rationality, satisfying behaviour, profit sub-optimality. An example of a company that currently operates this way is Google Strategic management techniques can be viewed as bottom-up, top-down, or collaborative processes. In the bottom-up approach, employees submit proposals to their managers who, in turn, funnel the best ideas further up the organization. This is often accomplished by a capital budgeting process. Proposals are assessed using financial criteria such as return on investment or cost-benefit analysis. Cost underestimation and benefit overestimation are major sources of error. The proposals that are approved form the substance of a new strategy, all of which is done without a grand strategic design or a strategic architect. The top-down approach is the most common by far. In it, the CEO, possibly with the assistance of a strategic planning team, decides on the overall direction the company should take. Some organizations are starting to experiment with collaborative strategic planning techniques that recognize the emergent nature of strategic decisions. Strategic decisions should focus on Outcome, Time remaining, and current Value/priority. The outcome comprises both the desired ending goal and the plan designed to reach that goal. Managing strategically requires paying attention to the time remaining to reach a particular level or goal and adjusting the pace and options accordingly. Value/priority relates to the shifting, relative concept of value-add. Strategic decisions should be based on the understanding that the value-add of whatever you are managing is a constantly changing reference point. An objective that begins with a high level of value-add may change due to influence of internal and external factors. Strategic management by definition, is managing with a heads-up approach to outcome, time and relative value, and actively making course corrections as needed.

The strategy hierarchy In most (large) corporations there are several levels of management. Strategic management is the highest of these levels in the sense that it is the broadest - applying to all parts of the firm - while also incorporating the longest time horizon. It gives direction to corporate values, corporate culture, corporate goals, and corporate missions. Under this broad corporate strategy there are typically business-level competitive strategies and functional unit strategies. Corporate strategy refers to the overarching strategy of the diversified firm. Such a corporate strategy answers the questions of "which businesses should we be in?" and "how does being in these businesses create synergy and/or add to the competitive advantage of the corporation as a whole?" Business strategy refers to the aggregated strategies of single business firm or a strategic business unit (SBU) in a diversified corporation. According to Michael Porter, a firm must formulate a business strategy that incorporates either cost leadership, differentiation or focus in order to achieve a sustainable competitive advantage and long-term success in its chosen areas or industries. Alternatively, according to W. Chan Kim and Renée Mauborgne, an organization can achieve high growth and profits by creating a Blue Ocean Strategy that breaks the previous value-cost tradeoff by simultaneously pursuing both differentiation and low cost. Functional strategies include marketing strategies, new product development strategies, human resource strategies, financial strategies, legal strategies, supply-chain strategies, and information technology management strategies. The emphasis is on short and medium term plans and is limited to the domain of each department’s functional

482

Strategic management responsibility. Each functional department attempts to do its part in meeting overall corporate objectives, and hence to some extent their strategies are derived from broader corporate strategies. Many companies feel that a functional organizational structure is not an efficient way to organize activities so they have reengineered according to processes or SBUs. A strategic business unit is a semi-autonomous unit that is usually responsible for its own budgeting, new product decisions, hiring decisions, and price setting. An SBU is treated as an internal profit centre by corporate headquarters. A technology strategy, for example, although it is focused on technology as a means of achieving an organization's overall objective(s), may include dimensions that are beyond the scope of a single business unit, engineering organization or IT department. An additional level of strategy called operational strategy was encouraged by Peter Drucker in his theory of management by objectives (MBO). It is very narrow in focus and deals with day-to-day operational activities such as scheduling criteria. It must operate within a budget but is not at liberty to adjust or create that budget. Operational level strategies are informed by business level strategies which, in turn, are informed by corporate level strategies. Since the turn of the millennium, some firms have reverted to a simpler strategic structure driven by advances in information technology. It is felt that knowledge management systems should be used to share information and create common goals. Strategic divisions are thought to hamper this process. This notion of strategy has been captured under the rubric of dynamic strategy, popularized by Carpenter and Sanders's textbook [3]. This work builds on that of Brown and Eisenhart as well as Christensen and portrays firm strategy, both business and corporate, as necessarily embracing ongoing strategic change, and the seamless integration of strategy formulation and implementation. Such change and implementation are usually built into the strategy through the staging and pacing facets.

Historical development of strategic management Birth of strategic management Strategic management as a discipline originated in the 1950s and 60s. Although there were numerous early contributors to the literature, the most influential pioneers were Alfred D. Chandler, Philip Selznick, Igor Ansoff, and Peter Drucker. Alfred Chandler recognized the importance of coordinating the various aspects of management under one all-encompassing strategy. Prior to this time the various functions of management were separate with little overall coordination or strategy. Interactions between functions or between departments were typically handled by a boundary position, that is, there were one or two managers that relayed information back and forth between two departments. Chandler also stressed the importance of taking a long term perspective when looking to the future. In his 1962 groundbreaking work Strategy and Structure, Chandler showed that a long-term coordinated strategy was necessary to give a company structure, direction, and focus. He says it concisely, “structure follows strategy.”[4] In 1957, Philip Selznick introduced the idea of matching the organization's internal factors with external environmental circumstances.[5] This core idea was developed into what we now call SWOT analysis by Learned, Andrews, and others at the Harvard Business School General Management Group. Strengths and weaknesses of the firm are assessed in light of the opportunities and threats from the business environment. Igor Ansoff built on Chandler's work by adding a range of strategic concepts and inventing a whole new vocabulary. He developed a strategy grid that compared market penetration strategies, product development strategies, market development strategies and horizontal and vertical integration and diversification strategies. He felt that management could use these strategies to systematically prepare for future opportunities and challenges. In his 1965 classic Corporate Strategy, he developed the gap analysis still used today in which we must understand the gap between where we are currently and where we would like to be, then develop what he called “gap reducing actions”.[6]

483

Strategic management Peter Drucker was a prolific strategy theorist, author of dozens of management books, with a career spanning five decades. His contributions to strategic management were many but two are most important. Firstly, he stressed the importance of objectives. An organization without clear objectives is like a ship without a rudder. As early as 1954 he was developing a theory of management based on objectives.[7] This evolved into his theory of management by objectives (MBO). According to Drucker, the procedure of setting objectives and monitoring your progress towards them should permeate the entire organization, top to bottom. His other seminal contribution was in predicting the importance of what today we would call intellectual capital. He predicted the rise of what he called the “knowledge worker” and explained the consequences of this for management. He said that knowledge work is non-hierarchical. Work would be carried out in teams with the person most knowledgeable in the task at hand being the temporary leader. In 1985, Ellen-Earle Chaffee summarized what she thought were the main elements of strategic management theory by the 1970s:[8] • Strategic management involves adapting the organization to its business environment. • Strategic management is fluid and complex. Change creates novel combinations of circumstances requiring unstructured non-repetitive responses. • Strategic management affects the entire organization by providing direction. • Strategic management involves both strategy formation (she called it content) and also strategy implementation (she called it process). • Strategic management is partially planned and partially unplanned. • Strategic management is done at several levels: overall corporate strategy, and individual business strategies. • Strategic management involves both conceptual and analytical thought processes.

Growth and portfolio theory In the 1970s much of strategic management dealt with size, growth, and portfolio theory. The PIMS study was a long term study, started in the 1960s and lasted for 19 years, that attempted to understand the Profit Impact of Marketing Strategies (PIMS), particularly the effect of market share. Started at General Electric, moved to Harvard in the early 1970s, and then moved to the Strategic Planning Institute in the late 1970s, it now contains decades of information on the relationship between profitability and strategy. Their initial conclusion was unambiguous: The greater a company's market share, the greater will be their rate of profit. The high market share provides volume and economies of scale. It also provides experience and learning curve advantages. The combined effect is increased profits.[9] The studies conclusions continue to be drawn on by academics and companies today: "PIMS provides compelling quantitative evidence as to which business strategies work and don't work" - Tom Peters. The benefits of high market share naturally lead to an interest in growth strategies. The relative advantages of horizontal integration, vertical integration, diversification, franchises, mergers and acquisitions, joint ventures, and organic growth were discussed. The most appropriate market dominance strategies were assessed given the competitive and regulatory environment. There was also research that indicated that a low market share strategy could also be very profitable. Schumacher (1973),[10] Woo and Cooper (1982),[11] Levenson (1984),[12] and later Traverso (2002)[13] showed how smaller niche players obtained very high returns. By the early 1980s the paradoxical conclusion was that high market share and low market share companies were often very profitable but most of the companies in between were not. This was sometimes called the “hole in the middle” problem. This anomaly would be explained by Michael Porter in the 1980s. The management of diversified organizations required new techniques and new ways of thinking. The first CEO to address the problem of a multi-divisional company was Alfred Sloan at General Motors. GM was decentralized into semi-autonomous “strategic business units” (SBU's), but with centralized support functions.

484

Strategic management One of the most valuable concepts in the strategic management of multi-divisional companies was portfolio theory. In the previous decade Harry Markowitz and other financial theorists developed the theory of portfolio analysis. It was concluded that a broad portfolio of financial assets could reduce specific risk. In the 1970s marketers extended the theory to product portfolio decisions and managerial strategists extended it to operating division portfolios. Each of a company’s operating divisions were seen as an element in the corporate portfolio. Each operating division (also called strategic business units) was treated as a semi-independent profit center with its own revenues, costs, objectives, and strategies. Several techniques were developed to analyze the relationships between elements in a portfolio. B.C.G. Analysis, for example, was developed by the Boston Consulting Group in the early 1970s. This was the theory that gave us the wonderful image of a CEO sitting on a stool milking a cash cow. Shortly after that the G.E. multi factoral model was developed by General Electric. Companies continued to diversify until the 1980s when it was realized that in many cases a portfolio of operating divisions was worth more as separate completely independent companies.

The marketing revolution The 1970s also saw the rise of the marketing oriented firm. From the beginnings of capitalism it was assumed that the key requirement of business success was a product of high technical quality. If you produced a product that worked well and was durable, it was assumed you would have no difficulty selling them at a profit. This was called the production orientation and it was generally true that good products could be sold without effort, encapsulated in the saying "Build a better mousetrap and the world will beat a path to your door." This was largely due to the growing numbers of affluent and middle class people that capitalism had created. But after the untapped demand caused by the second world war was saturated in the 1950s it became obvious that products were not selling as easily as they had been. The answer was to concentrate on selling. The 1950s and 1960s is known as the sales era and the guiding philosophy of business of the time is today called the sales orientation. In the early 1970s Theodore Levitt and others at Harvard argued that the sales orientation had things backward. They claimed that instead of producing products then trying to sell them to the customer, businesses should start with the customer, find out what they wanted, and then produce it for them. The customer became the driving force behind all strategic business decisions. This marketing orientation, in the decades since its introduction, has been reformulated and repackaged under numerous names including customer orientation, marketing philosophy, customer intimacy, customer focus, customer driven, and market focused.

The Japanese challenge By the late 70s, Americans had started to notice how successful Japanese industry had become. In industry after industry, including steel, watches, ship building, cameras, autos, and electronics, the Japanese were surpassing American and European companies. Westerners wanted to know why. Numerous theories purported to explain the Japanese success including: • • • • • •

Higher employee morale, dedication, and loyalty; Lower cost structure, including wages; Effective government industrial policy; Modernization after WWII leading to high capital intensity and productivity; Economies of scale associated with increased exporting; Relatively low value of the Yen leading to low interest rates and capital costs, low dividend expectations, and inexpensive exports; • Superior quality control techniques such as Total Quality Management and other systems introduced by W. Edwards Deming in the 1950s and 60s.[14] Although there was some truth to all these potential explanations, there was clearly something missing. In fact by 1980 the Japanese cost structure was higher than the American. And post WWII reconstruction was nearly 40 years

485

Strategic management in the past. The first management theorist to suggest an explanation was Richard Pascale. In 1981, Richard Pascale and Anthony Athos in The Art of Japanese Management claimed that the main reason for Japanese success was their superior management techniques.[15] They divided management into 7 aspects (which are also known as McKinsey 7S Framework): Strategy, Structure, Systems, Skills, Staff, Style, and Supraordinate goals (which we would now call shared values). The first three of the 7 S's were called hard factors and this is where American companies excelled. The remaining four factors (skills, staff, style, and shared values) were called soft factors and were not well understood by American businesses of the time (for details on the role of soft and hard factors see Wickens P.D. 1995.) Americans did not yet place great value on corporate culture, shared values and beliefs, and social cohesion in the workplace. In Japan the task of management was seen as managing the whole complex of human needs, economic, social, psychological, and spiritual. In America work was seen as something that was separate from the rest of one's life. It was quite common for Americans to exhibit a very different personality at work compared to the rest of their lives. Pascale also highlighted the difference between decision making styles; hierarchical in America, and consensus in Japan. He also claimed that American business lacked long term vision, preferring instead to apply management fads and theories in a piecemeal fashion. One year later, The Mind of the Strategist was released in America by Kenichi Ohmae, the head of McKinsey & Co.'s Tokyo office.[16] (It was originally published in Japan in 1975.) He claimed that strategy in America was too analytical. Strategy should be a creative art: It is a frame of mind that requires intuition and intellectual flexibility. He claimed that Americans constrained their strategic options by thinking in terms of analytical techniques, rote formula, and step-by-step processes. He compared the culture of Japan in which vagueness, ambiguity, and tentative decisions were acceptable, to American culture that valued fast decisions. Also in 1982, Tom Peters and Robert Waterman released a study that would respond to the Japanese challenge head on.[17] Peters and Waterman, who had several years earlier collaborated with Pascale and Athos at McKinsey & Co. asked “What makes an excellent company?”. They looked at 62 companies that they thought were fairly successful. Each was subject to six performance criteria. To be classified as an excellent company, it had to be above the 50th percentile in 4 of the 6 performance metrics for 20 consecutive years. Forty-three companies passed the test. They then studied these successful companies and interviewed key executives. They concluded in In Search of Excellence that there were 8 keys to excellence that were shared by all 43 firms. They are: • • • • • • • •

A bias for action — Do it. Try it. Don’t waste time studying it with multiple reports and committees. Customer focus — Get close to the customer. Know your customer. Entrepreneurship — Even big companies act and think small by giving people the authority to take initiatives. Productivity through people — Treat your people with respect and they will reward you with productivity. Value-oriented CEOs — The CEO should actively propagate corporate values throughout the organization. Stick to the knitting — Do what you know well. Keep things simple and lean — Complexity encourages waste and confusion. Simultaneously centralized and decentralized — Have tight centralized control while also allowing maximum individual autonomy.

The basic blueprint on how to compete against the Japanese had been drawn. But as J.E. Rehfeld (1994) explains it is not a straight forward task due to differences in culture.[18] A certain type of alchemy was required to transform knowledge from various cultures into a management style that allows a specific company to compete in a globally diverse world. He says, for example, that Japanese style kaizen (continuous improvement) techniques, although suitable for people socialized in Japanese culture, have not been successful when implemented in the U.S. unless they are modified significantly. In 2009, industry consultants Mark Blaxill and Ralph Eckardt suggested that much of the Japanese business dominance that began in the mid 1970s was the direct result of competition enforcement efforts by the Federal Trade Commission (FTC) and U.S. Department of Justice (DOJ). In 1975 the FTC reached a settlement with Xerox Corporation in its anti-trust lawsuit. (At the time, the FTC was under the direction of Frederic M. Scherer). The 1975

486

Strategic management Xerox consent decree forced the licensing of the company’s entire patent portfolio, mainly to Japanese competitors. (See "compulsory license".) This action marked the start of an activist approach to managing competition by the FTC and DOJ, which resulted in the compulsory licensing of tens of thousands of patent from some of America's leading companies, including IBM, AT&T, DuPont, Bausch & Lomb, and Eastman Kodak. Within four years of the consent decree, Xerox's share of the U.S. copier market dropped from nearly 100% to less than 14%. Between 1950 and 1980 Japanese companies consummated more than 35,000 foreign licensing agreements, mostly with U.S. companies, for free or low-cost licenses made possible by the FTC and DOJ. The post-1975 era of anti-trust initiatives by Washington D.C. economists at the FTC corresponded directly with the rapid, unprecedented rise in Japanese competitiveness and a simultaneous stalling of the U.S. manufacturing economy. [19]

Gaining competitive advantage The Japanese challenge shook the confidence of the western business elite, but detailed comparisons of the two management styles and examinations of successful businesses convinced westerners that they could overcome the challenge. The 1980s and early 1990s saw a plethora of theories explaining exactly how this could be done. They cannot all be detailed here, but some of the more important strategic advances of the decade are explained below. Gary Hamel and C. K. Prahalad declared that strategy needs to be more active and interactive; less “arm-chair planning” was needed. They introduced terms like strategic intent and strategic architecture.[20] [21] Their most well known advance was the idea of core competency. They showed how important it was to know the one or two key things that your company does better than the competition.[22] Active strategic management required active information gathering and active problem solving. In the early days of Hewlett-Packard (H-P), Dave Packard and Bill Hewlett devised an active management style that they called management by walking around (MBWA). Senior H-P managers were seldom at their desks. They spent most of their days visiting employees, customers, and suppliers. This direct contact with key people provided them with a solid grounding from which viable strategies could be crafted. The MBWA concept was popularized in 1985 by a book by Tom Peters and Nancy Austin.[23] Japanese managers employ a similar system, which originated at Honda, and is sometimes called the 3 G's (Genba, Genbutsu, and Genjitsu, which translate into “actual place”, “actual thing”, and “actual situation”). Probably the most influential strategist of the decade was Michael Porter. He introduced many new concepts including; 5 forces analysis, generic strategies, the value chain, strategic groups, and clusters. In 5 forces analysis he identifies the forces that shape a firm's strategic environment. It is like a SWOT analysis with structure and purpose. It shows how a firm can use these forces to obtain a sustainable competitive advantage. Porter modifies Chandler's dictum about structure following strategy by introducing a second level of structure: Organizational structure follows strategy, which in turn follows industry structure. Porter's generic strategies detail the interaction between cost minimization strategies, product differentiation strategies, and market focus strategies. Although he did not introduce these terms, he showed the importance of choosing one of them rather than trying to position your company between them. He also challenged managers to see their industry in terms of a value chain. A firm will be successful only to the extent that it contributes to the industry's value chain. This forced management to look at its operations from the customer's point of view. Every operation should be examined in terms of what value it adds in the eyes of the final customer. In 1993, John Kay took the idea of the value chain to a financial level claiming “ Adding value is the central purpose of business activity”, where adding value is defined as the difference between the market value of outputs and the cost of inputs including capital, all divided by the firm's net output. Borrowing from Gary Hamel and Michael Porter, Kay claims that the role of strategic management is to identify your core competencies, and then assemble a collection of assets that will increase value added and provide a competitive advantage. He claims that there are 3 types of capabilities that can do this; innovation, reputation, and organizational structure.

487

Strategic management The 1980s also saw the widespread acceptance of positioning theory. Although the theory originated with Jack Trout in 1969, it didn’t gain wide acceptance until Al Ries and Jack Trout wrote their classic book “Positioning: The Battle For Your Mind” (1979). The basic premise is that a strategy should not be judged by internal company factors but by the way customers see it relative to the competition. Crafting and implementing a strategy involves creating a position in the mind of the collective consumer. Several techniques were applied to positioning theory, some newly invented but most borrowed from other disciplines. Perceptual mapping for example, creates visual displays of the relationships between positions. Multidimensional scaling, discriminant analysis, factor analysis, and conjoint analysis are mathematical techniques used to determine the most relevant characteristics (called dimensions or factors) upon which positions should be based. Preference regression can be used to determine vectors of ideal positions and cluster analysis can identify clusters of positions. Others felt that internal company resources were the key. In 1992, Jay Barney, for example, saw strategy as assembling the optimum mix of resources, including human, technology, and suppliers, and then configure them in unique and sustainable ways.[24] Michael Hammer and James Champy felt that these resources needed to be restructured.[25] This process, that they labeled reengineering, involved organizing a firm's assets around whole processes rather than tasks. In this way a team of people saw a project through, from inception to completion. This avoided functional silos where isolated departments seldom talked to each other. It also eliminated waste due to functional overlap and interdepartmental communications. In 1989 Richard Lester and the researchers at the MIT Industrial Performance Center identified seven best practices and concluded that firms must accelerate the shift away from the mass production of low cost standardized products. The seven areas of best practice were:[26] • • • • • • •

Simultaneous continuous improvement in cost, quality, service, and product innovation Breaking down organizational barriers between departments Eliminating layers of management creating flatter organizational hierarchies. Closer relationships with customers and suppliers Intelligent use of new technology Global focus Improving human resource skills

The search for “best practices” is also called benchmarking.[27] This involves determining where you need to improve, finding an organization that is exceptional in this area, then studying the company and applying its best practices in your firm. A large group of theorists felt the area where western business was most lacking was product quality. People like W. Edwards Deming,[28] Joseph M. Juran,[29] A. Kearney,[30] Philip Crosby,[31] and Armand Feignbaum[32] suggested quality improvement techniques like total quality management (TQM), continuous improvement (kaizen), lean manufacturing, Six Sigma, and return on quality (ROQ). An equally large group of theorists felt that poor customer service was the problem. People like James Heskett (1988),[33] Earl Sasser (1995), William Davidow,[34] Len Schlesinger,[35] A. Paraurgman (1988), Len Berry,[36] Jane Kingman-Brundage,[37] Christopher Hart, and Christopher Lovelock (1994), gave us fishbone diagramming, service charting, Total Customer Service (TCS), the service profit chain, service gaps analysis, the service encounter, strategic service vision, service mapping, and service teams. Their underlying assumption was that there is no better source of competitive advantage than a continuous stream of delighted customers. Process management uses some of the techniques from product quality management and some of the techniques from customer service management. It looks at an activity as a sequential process. The objective is to find inefficiencies and make the process more effective. Although the procedures have a long history, dating back to Taylorism, the scope of their applicability has been greatly widened, leaving no aspect of the firm free from potential process improvements. Because of the broad applicability of process management techniques, they can be used as a

488

Strategic management basis for competitive advantage. Some realized that businesses were spending much more on acquiring new customers than on retaining current ones. Carl Sewell,[38] Frederick F. Reichheld,[39] C. Gronroos,[40] and Earl Sasser[41] showed us how a competitive advantage could be found in ensuring that customers returned again and again. This has come to be known as the loyalty effect after Reicheld's book of the same name in which he broadens the concept to include employee loyalty, supplier loyalty, distributor loyalty, and shareholder loyalty. They also developed techniques for estimating the lifetime value of a loyal customer, called customer lifetime value (CLV). A significant movement started that attempted to recast selling and marketing techniques into a long term endeavor that created a sustained relationship with customers (called relationship selling, relationship marketing, and customer relationship management). Customer relationship management (CRM) software (and its many variants) became an integral tool that sustained this trend. James Gilmore and Joseph Pine found competitive advantage in mass customization.[42] Flexible manufacturing techniques allowed businesses to individualize products for each customer without losing economies of scale. This effectively turned the product into a service. They also realized that if a service is mass customized by creating a “performance” for each individual client, that service would be transformed into an “experience”. Their book, The Experience Economy,[43] along with the work of Bernd Schmitt convinced many to see service provision as a form of theatre. This school of thought is sometimes referred to as customer experience management (CEM). Like Peters and Waterman a decade earlier, James Collins and Jerry Porras spent years conducting empirical research on what makes great companies. Six years of research uncovered a key underlying principle behind the 19 successful companies that they studied: They all encourage and preserve a core ideology that nurtures the company. Even though strategy and tactics change daily, the companies, nevertheless, were able to maintain a core set of values. These core values encourage employees to build an organization that lasts. In Built To Last (1994) they claim that short term profit goals, cost cutting, and restructuring will not stimulate dedicated employees to build a great company that will endure.[44] In 2000 Collins coined the term “built to flip” to describe the prevailing business attitudes in Silicon Valley. It describes a business culture where technological change inhibits a long term focus. He also popularized the concept of the BHAG (Big Hairy Audacious Goal). Arie de Geus (1997) undertook a similar study and obtained similar results. He identified four key traits of companies that had prospered for 50 years or more. They are: • • • •

Sensitivity to the business environment — the ability to learn and adjust Cohesion and identity — the ability to build a community with personality, vision, and purpose Tolerance and decentralization — the ability to build relationships Conservative financing

A company with these key characteristics he called a living company because it is able to perpetuate itself. If a company emphasizes knowledge rather than finance, and sees itself as an ongoing community of human beings, it has the potential to become great and endure for decades. Such an organization is an organic entity capable of learning (he called it a “learning organization”) and capable of creating its own processes, goals, and persona. There are numerous ways by which a firm can try to create a competitive advantage - some will work but many will not. In order to help firms avoid a hit and miss approach to the creation of competitive advantage Will Mulcaster [45] suggests that firms engage in a dialogue that centres around the question "Will the proposed competitive advantage create Perceived Differential Value?" The dialogue should raise a series of other pertinent questions, including:"Will the proposed competitive advantage create something that is different from the competition?" "Will the difference add value in the eyes of potential customers?" - This question will entail a discussion of the combined effects of price, product features and consumer perceptions. "Will the product add value for the firm?" - Answering this question will require an examination of cost effectiveness and the pricing strategy.

489

Strategic management

The military theorists In the 1980s some business strategists realized that there was a vast knowledge base stretching back thousands of years that they had barely examined. They turned to military strategy for guidance. Military strategy books such as The Art of War by Sun Tzu, On War by von Clausewitz, and The Red Book by Mao Zedong became instant business classics. From Sun Tzu, they learned the tactical side of military strategy and specific tactical prescriptions. From Von Clausewitz, they learned the dynamic and unpredictable nature of military strategy. From Mao Zedong, they learned the principles of guerrilla warfare. The main marketing warfare books were: • Business War Games by Barrie James, 1984 • Marketing Warfare by Al Ries and Jack Trout, 1986 • Leadership Secrets of Attila the Hun [46] by Wess Roberts, 1987 Philip Kotler was a well-known proponent of marketing warfare strategy. There were generally thought to be four types of business warfare theories. They are: • • • •

Offensive marketing warfare strategies Defensive marketing warfare strategies Flanking marketing warfare strategies Guerrilla marketing warfare strategies

The marketing warfare literature also examined leadership and motivation, intelligence gathering, types of marketing weapons, logistics, and communications. By the turn of the century marketing warfare strategies had gone out of favour. It was felt that they were limiting. There were many situations in which non-confrontational approaches were more appropriate. In 1989, Dudley Lynch and Paul L. Kordis published Strategy of the Dolphin: Scoring a Win in a Chaotic World. "The Strategy of the Dolphin” was developed to give guidance as to when to use aggressive strategies and when to use passive strategies. A variety of aggressiveness strategies were developed. In 1993, J. Moore used a similar metaphor.[47] Instead of using military terms, he created an ecological theory of predators and prey (see ecological model of competition), a sort of Darwinian management strategy in which market interactions mimic long term ecological stability.

Strategic change In 1968, Peter Drucker (1969) coined the phrase Age of Discontinuity to describe the way change forces disruptions into the continuity of our lives.[48] In an age of continuity attempts to predict the future by extrapolating from the past can be somewhat accurate. But according to Drucker, we are now in an age of discontinuity and extrapolating from the past is hopelessly ineffective. We cannot assume that trends that exist today will continue into the future. He identifies four sources of discontinuity: new technologies, globalization, cultural pluralism, and knowledge capital. In 1970, Alvin Toffler in Future Shock described a trend towards accelerating rates of change.[49] He illustrated how social and technological norms had shorter lifespans with each generation, and he questioned society's ability to cope with the resulting turmoil and anxiety. In past generations periods of change were always punctuated with times of stability. This allowed society to assimilate the change and deal with it before the next change arrived. But these periods of stability are getting shorter and by the late 20th century had all but disappeared. In 1980 in The Third Wave, Toffler characterized this shift to relentless change as the defining feature of the third phase of civilization (the first two phases being the agricultural and industrial waves).[50] He claimed that the dawn of this new phase will cause great anxiety for those that grew up in the previous phases, and will cause much conflict and opportunity in the business world. Hundreds of authors, particularly since the early 1990s, have attempted to explain what this means for business strategy.

490

Strategic management In 2000, Gary Hamel discussed strategic decay, the notion that the value of all strategies, no matter how brilliant, decays over time.[51] In 1978, Dereck Abell (Abell, D. 1978) described strategic windows and stressed the importance of the timing (both entrance and exit) of any given strategy. This has led some strategic planners to build planned obsolescence into their strategies.[52] In 1989, Charles Handy identified two types of change.[53] Strategic drift is a gradual change that occurs so subtly that it is not noticed until it is too late. By contrast, transformational change is sudden and radical. It is typically caused by discontinuities (or exogenous shocks) in the business environment. The point where a new trend is initiated is called a strategic inflection point by Andy Grove. Inflection points can be subtle or radical. In 2000, Malcolm Gladwell discussed the importance of the tipping point, that point where a trend or fad acquires critical mass and takes off.[54] In 1983, Noel Tichy wrote that because we are all beings of habit we tend to repeat what we are comfortable with.[55] He wrote that this is a trap that constrains our creativity, prevents us from exploring new ideas, and hampers our dealing with the full complexity of new issues. He developed a systematic method of dealing with change that involved looking at any new issue from three angles: technical and production, political and resource allocation, and corporate culture. In 1990, Richard Pascale (Pascale, R. 1990) wrote that relentless change requires that businesses continuously reinvent themselves.[56] His famous maxim is “Nothing fails like success” by which he means that what was a strength yesterday becomes the root of weakness today, We tend to depend on what worked yesterday and refuse to let go of what worked so well for us in the past. Prevailing strategies become self-confirming. In order to avoid this trap, businesses must stimulate a spirit of inquiry and healthy debate. They must encourage a creative process of self renewal based on constructive conflict. Peters and Austin (1985) stressed the importance of nurturing champions and heroes. They said we have a tendency to dismiss new ideas, so to overcome this, we should support those few people in the organization that have the courage to put their career and reputation on the line for an unproven idea. In 1996, Adrian Slywotzky showed how changes in the business environment are reflected in value migrations between industries, between companies, and within companies.[57] He claimed that recognizing the patterns behind these value migrations is necessary if we wish to understand the world of chaotic change. In “Profit Patterns” (1999) he described businesses as being in a state of strategic anticipation as they try to spot emerging patterns. Slywotsky and his team identified 30 patterns that have transformed industry after industry.[58] In 1997, Clayton Christensen (1997) took the position that great companies can fail precisely because they do everything right since the capabilities of the organization also defines its disabilities.[59] Christensen's thesis is that outstanding companies lose their market leadership when confronted with disruptive technology. He called the approach to discovering the emerging markets for disruptive technologies agnostic marketing, i.e., marketing under the implicit assumption that no one - not the company, not the customers - can know how or in what quantities a disruptive product can or will be used before they have experience using it. A number of strategists use scenario planning techniques to deal with change. The way Peter Schwartz put it in 1991 is that strategic outcomes cannot be known in advance so the sources of competitive advantage cannot be predetermined.[60] The fast changing business environment is too uncertain for us to find sustainable value in formulas of excellence or competitive advantage. Instead, scenario planning is a technique in which multiple outcomes can be developed, their implications assessed, and their likeliness of occurrence evaluated. According to Pierre Wack, scenario planning is about insight, complexity, and subtlety, not about formal analysis and numbers.[61] In 1988, Henry Mintzberg looked at the changing world around him and decided it was time to reexamine how strategic management was done.[62] [63] He examined the strategic process and concluded it was much more fluid and unpredictable than people had thought. Because of this, he could not point to one process that could be called

491

Strategic management strategic planning. Instead Mintzberg concludes that there are five types of strategies: • • • •

Strategy as plan - a direction, guide, course of action - intention rather than actual Strategy as ploy - a maneuver intended to outwit a competitor Strategy as pattern - a consistent pattern of past behaviour - realized rather than intended Strategy as position - locating of brands, products, or companies within the conceptual framework of consumers or other stakeholders - strategy determined primarily by factors outside the firm • Strategy as perspective - strategy determined primarily by a master strategist In 1998, Mintzberg developed these five types of management strategy into 10 “schools of thought”. These 10 schools are grouped into three categories. The first group is prescriptive or normative. It consists of the informal design and conception school, the formal planning school, and the analytical positioning school. The second group, consisting of six schools, is more concerned with how strategic management is actually done, rather than prescribing optimal plans or positions. The six schools are the entrepreneurial, visionary, or great leader school, the cognitive or mental process school, the learning, adaptive, or emergent process school, the power or negotiation school, the corporate culture or collective process school, and the business environment or reactive school. The third and final group consists of one school, the configuration or transformation school, an hybrid of the other schools organized into stages, organizational life cycles, or “episodes”.[64] In 1999, Constantinos Markides also wanted to reexamine the nature of strategic planning itself.[65] He describes strategy formation and implementation as an on-going, never-ending, integrated process requiring continuous reassessment and reformation. Strategic management is planned and emergent, dynamic, and interactive. J. Moncrieff (1999) also stresses strategy dynamics.[66] He recognized that strategy is partially deliberate and partially unplanned. The unplanned element comes from two sources: emergent strategies (result from the emergence of opportunities and threats in the environment) and Strategies in action (ad hoc actions by many people from all parts of the organization). Some business planners are starting to use a complexity theory approach to strategy. Complexity can be thought of as chaos with a dash of order. Chaos theory deals with turbulent systems that rapidly become disordered. Complexity is not quite so unpredictable. It involves multiple agents interacting in such a way that a glimpse of structure may appear.

Information- and technology-driven strategy Peter Drucker had theorized the rise of the “knowledge worker” back in the 1950s. He described how fewer workers would be doing physical labor, and more would be applying their minds. In 1984, John Nesbitt theorized that the future would be driven largely by information: companies that managed information well could obtain an advantage, however the profitability of what he calls the “information float” (information that the company had and others desired) would all but disappear as inexpensive computers made information more accessible. Daniel Bell (1985) examined the sociological consequences of information technology, while Gloria Schuck and Shoshana Zuboff looked at psychological factors.[67] Zuboff, in her five year study of eight pioneering corporations made the important distinction between “automating technologies” and “infomating technologies”. She studied the effect that both had on individual workers, managers, and organizational structures. She largely confirmed Peter Drucker's predictions three decades earlier, about the importance of flexible decentralized structure, work teams, knowledge sharing, and the central role of the knowledge worker. Zuboff also detected a new basis for managerial authority, based not on position or hierarchy, but on knowledge (also predicted by Drucker) which she called “participative management”.[68] In 1990, Peter Senge, who had collaborated with Arie de Geus at Dutch Shell, borrowed de Geus' notion of the learning organization, expanded it, and popularized it. The underlying theory is that a company's ability to gather, analyze, and use information is a necessary requirement for business success in the information age. (See organizational learning.) In order to do this, Senge claimed that an organization would need to be structured such

492

Strategic management that:[69] • • • •

People can continuously expand their capacity to learn and be productive, New patterns of thinking are nurtured, Collective aspirations are encouraged, and People are encouraged to see the “whole picture” together.

Senge identified five disciplines of a learning organization. They are: • Personal responsibility, self reliance, and mastery — We accept that we are the masters of our own destiny. We make decisions and live with the consequences of them. When a problem needs to be fixed, or an opportunity exploited, we take the initiative to learn the required skills to get it done. • Mental models — We need to explore our personal mental models to understand the subtle effect they have on our behaviour. • Shared vision — The vision of where we want to be in the future is discussed and communicated to all. It provides guidance and energy for the journey ahead. • Team learning — We learn together in teams. This involves a shift from “a spirit of advocacy to a spirit of enquiry”. • Systems thinking — We look at the whole rather than the parts. This is what Senge calls the “Fifth discipline”. It is the glue that integrates the other four into a coherent strategy. For an alternative approach to the “learning organization”, see Garratt, B. (1987). Since 1990 many theorists have written on the strategic importance of information, including J.B. Quinn,[70] J. Carlos Jarillo,[71] D.L. Barton,[72] Manuel Castells,[73] J.P. Lieleskin,[74] Thomas Stewart,[75] K.E. Sveiby,[76] Gilbert J. Probst,[77] and Shapiro and Varian[78] to name just a few. Thomas A. Stewart, for example, uses the term intellectual capital to describe the investment an organization makes in knowledge. It is composed of human capital (the knowledge inside the heads of employees), customer capital (the knowledge inside the heads of customers that decide to buy from you), and structural capital (the knowledge that resides in the company itself). Manuel Castells, describes a network society characterized by: globalization, organizations structured as a network, instability of employment, and a social divide between those with access to information technology and those without. Geoffrey Moore (1991) and R. Frank and P. Cook[79] also detected a shift in the nature of competition. In industries with high technology content, technical standards become established and this gives the dominant firm a near monopoly. The same is true of networked industries in which interoperability requires compatibility between users. An example is word processor documents. Once a product has gained market dominance, other products, even far superior products, cannot compete. Moore showed how firms could attain this enviable position by using E.M. Rogers five stage adoption process and focusing on one group of customers at a time, using each group as a base for marketing to the next group. The most difficult step is making the transition between visionaries and pragmatists (See Crossing the Chasm). If successful a firm can create a bandwagon effect in which the momentum builds and your product becomes a de facto standard. Evans and Wurster describe how industries with a high information component are being transformed.[80] They cite Encarta's demolition of the Encyclopedia Britannica (whose sales have plummeted 80% since their peak of $650 million in 1990). Encarta’s reign was speculated to be short-lived, eclipsed by collaborative encyclopedias like Wikipedia that can operate at very low marginal costs. Encarta's service was subsequently turned into an on-line service and dropped at the end of 2009. Evans also mentions the music industry which is desperately looking for a new business model. The upstart information savvy firms, unburdened by cumbersome physical assets, are changing the competitive landscape, redefining market segments, and disintermediating some channels. One manifestation of this is personalized marketing. Information technology allows marketers to treat each individual as its own market, a market of one. Traditional ideas of market segments will no longer be relevant if personalized marketing is

493

Strategic management successful. The technology sector has provided some strategies directly. For example, from the software development industry agile software development provides a model for shared development processes. Access to information systems have allowed senior managers to take a much more comprehensive view of strategic management than ever before. The most notable of the comprehensive systems is the balanced scorecard approach developed in the early 1990s by Drs. Robert S. Kaplan (Harvard Business School) and David Norton (Kaplan, R. and Norton, D. 1992). It measures several factors financial, marketing, production, organizational development, and new product development in order to achieve a 'balanced' perspective.

Knowledge-driven strategy Most current approaches to business "strategy" focus on the mechanics of management -- e.g., Drucker's operational "strategies" -- and as such are not true business strategy. In a post-industrial world these operationally focused business strategies hinge on conventional sources of advantage have essentially been eliminated: • Scale used to be very important. But now, with access to capital and a global marketplace, scale is achievable by multiple organizations simultaneously. In many cases, it can literally be rented. • Process improvement or “best practices” were once a favored source of advantage, but they were at best temporary, as they could be copied and adapted by competitors. • Owning the customer had always been thought of as an important form of competitive advantage. Now, however, customer loyalty is far less important and difficult to maintain as new brands and products emerge all the time. In such a world, differentiation, as elucidated by Michael Porter, Botten and McManus is the only way to maintain economic or market superiority (i.e., comparative advantage) over competitors. A company must OWN the thing that differentiates it from competitors. Without IP ownership and protection, any product, process or scale advantage can be compromised or entirely lost. Competitors can copy them without fear of economic or legal consequences, thereby eliminating the advantage. (For an explanation and elucidation of the "post-industrial" worldview, see George Ritzer and Daniel Bell.)

Strategic decision making processes Will Mulcaster [81] argues that while much research and creative thought has been devoted to generating alternative strategies, too little work has been done on what influences the quality of strategic decision making and the effectiveness with which strategies are implemented. For instance, in retrospect it can be seen that the financial crisis of 2008-9 could have been avoided if the banks had paid more attention to the risks associated with their investments, but how should banks change the way in which they make decisions in order to improve the quality of their decisions in the future? Mulcaster's Managing Forces framework addresses this issue by identifying 11 forces that should be incorporated into the processes of decision making and strategic implementation. The 11 forces are: Time; Opposing forces; Politics; Perception; Holistic effects; Adding value; Incentives; Learning capabilities; Opportunity cost; Risk; Style - which can be remembered by using the mnemonic 'TOPHAILORS'.

The psychology of strategic management Several psychologists have conducted studies to determine the psychological patterns involved in strategic management. Typically senior managers have been asked how they go about making strategic decisions. A 1938 treatise by Chester Barnard, that was based on his own experience as a business executive, sees the process as informal, intuitive, non-routinized, and involving primarily oral, 2-way communications. Bernard says “The process is the sensing of the organization as a whole and the total situation relevant to it. It transcends the capacity of merely intellectual methods, and the techniques of discriminating the factors of the situation. The terms pertinent to it are “feeling”, “judgement”, “sense”, “proportion”, “balance”, “appropriateness”. It is a matter of art rather than science.”[82]

494

Strategic management In 1973, Henry Mintzberg found that senior managers typically deal with unpredictable situations so they strategize in ad hoc, flexible, dynamic, and implicit ways. . He says, “The job breeds adaptive information-manipulators who prefer the live concrete situation. The manager works in an environment of stimulous-response, and he develops in his work a clear preference for live action.”[83] In 1982, John Kotter studied the daily activities of 15 executives and concluded that they spent most of their time developing and working a network of relationships from which they gained general insights and specific details to be used in making strategic decisions. They tended to use “mental road maps” rather than systematic planning techniques.[84] Daniel Isenberg's 1984 study of senior managers found that their decisions were highly intuitive. Executives often sensed what they were going to do before they could explain why.[85] He claimed in 1986 that one of the reasons for this is the complexity of strategic decisions and the resultant information uncertainty.[86] Shoshana Zuboff (1988) claims that information technology is widening the divide between senior managers (who typically make strategic decisions) and operational level managers (who typically make routine decisions). She claims that prior to the widespread use of computer systems, managers, even at the most senior level, engaged in both strategic decisions and routine administration, but as computers facilitated (She called it “deskilled”) routine processes, these activities were moved further down the hierarchy, leaving senior management free for strategic decions making. In 1977, Abraham Zaleznik identified a difference between leaders and managers. He describes leadershipleaders as visionaries who inspire. They care about substance. Whereas managers are claimed to care about process, plans, and form.[87] He also claimed in 1989 that the rise of the manager was the main factor that caused the decline of American business in the 1970s and 80s.The main difference between leader and manager is that, leader has followers and manager has subordinates. In capitalistic society leaders make decisions and manager usually follow or execute.[88] Lack of leadership is most damaging at the level of strategic management where it can paralyze an entire organization.[89] According to Corner, Kinichi, and Keats,[90] strategic decision making in organizations occurs at two levels: individual and aggregate. They have developed a model of parallel strategic decision making. The model identifies two parallel processes both of which involve getting attention, encoding information, storage and retrieval of information, strategic choice, strategic outcome, and feedback. The individual and organizational processes are not independent however. They interact at each stage of the process.

Reasons why strategic plans fail There are many reasons why strategic plans fail, especially: • Failure to execute by overcoming the four key organizational hurdles[91] • Cognitive hurdle • Motivational hurdle • Resource hurdle • Political hurdle • Failure to understand the customer • Why do they buy • Is there a real need for the product • inadequate or incorrect marketing research • Inability to predict environmental reaction • What will competitors do • Fighting brands • Price wars

495

Strategic management • Will government intervene • Over-estimation of resource competence • Can the staff, equipment, and processes handle the new strategy • Failure to develop new employee and management skills • Failure to coordinate • Reporting and control relationships not adequate • Organizational structure not flexible enough • Failure to obtain senior management commitment • Failure to get management involved right from the start • Failure to obtain sufficient company resources to accomplish task • Failure to obtain employee commitment • New strategy not well explained to employees • No incentives given to workers to embrace the new strategy • Under-estimation of time requirements • No critical path analysis done • Failure to follow the plan • No follow through after initial planning • No tracking of progress against plan • No consequences for above • Failure to manage change • Inadequate understanding of the internal resistance to change • Lack of vision on the relationships between processes, technology and organization • Poor communications • Insufficient information sharing among stakeholders • Exclusion of stakeholders and delegates

Limitations of strategic management Although a sense of direction is important, it can also stifle creativity, especially if it is rigidly enforced. In an uncertain and ambiguous world, fluidity can be more important than a finely tuned strategic compass. When a strategy becomes internalized into a corporate culture, it can lead to group think. It can also cause an organization to define itself too narrowly. An example of this is marketing myopia. Many theories of strategic management tend to undergo only brief periods of popularity. A summary of these theories thus inevitably exhibits survivorship bias (itself an area of research in strategic management). Many theories tend either to be too narrow in focus to build a complete corporate strategy on, or too general and abstract to be applicable to specific situations. Populism or faddishness can have an impact on a particular theory's life cycle and may see application in inappropriate circumstances. See business philosophies and popular management theories for a more critical view of management theories. In 2000, Gary Hamel coined the term strategic convergence to explain the limited scope of the strategies being used by rivals in greatly differing circumstances. He lamented that strategies converge more than they should, because the more successful ones are imitated by firms that do not understand that the strategic process involves designing a custom strategy for the specifics of each situation.[51] Ram Charan, aligning with a popular marketing tagline, believes that strategic planning must not dominate action. "Just do it!", while not quite what he meant, is a phrase that nevertheless comes to mind when combatting analysis paralysis.

496

Strategic management

The linearity trap It is tempting to think that the elements of strategic management – (i) reaching consensus on corporate objectives; (ii) developing a plan for achieving the objectives; and (iii) marshalling and allocating the resources required to implement the plan – can be approached sequentially. It would be convenient, in other words, if one could deal first with the noble question of ends, and then address the mundane question of means. But in the world in which strategies have to be implemented, the three elements are interdependent. Means are as likely to determine ends as ends are to determine means.[92] The objectives that an organization might wish to pursue are limited by the range of feasible approaches to implementation. (There will usually be only a small number of approaches that will not only be technically and administratively possible, but also satisfactory to the full range of organizational stakeholders.) In turn, the range of feasible implementation approaches is determined by the availability of resources. And so, although participants in a typical “strategy session” may be asked to do “blue sky” thinking where they pretend that the usual constraints – resources, acceptability to stakeholders , administrative feasibility – have been lifted, the fact is that it rarely makes sense to divorce oneself from the environment in which a strategy will have to be implemented. It’s probably impossible to think in any meaningful way about strategy in an unconstrained environment. Our brains can’t process “boundless possibilities”, and the very idea of strategy only has meaning in the context of challenges or obstacles to be overcome. It’s at least as plausible to argue that acute awareness of constraints is the very thing that stimulates creativity by forcing us to constantly reassess both means and ends in light of circumstances. The key question, then, is, "How can individuals, organizations and societies cope as well as possible with ... issues too complex to be fully understood, given the fact that actions initiated on the basis of inadequate understanding may lead to significant regret?"[93] The answer is that the process of developing organizational strategy must be iterative. It involves toggling back and forth between questions about objectives, implementation planning and resources. An initial idea about corporate objectives may have to be altered if there is no feasible implementation plan that will meet with a sufficient level of acceptance among the full range of stakeholders, or because the necessary resources are not available, or both. Even the most talented manager would no doubt agree that "comprehensive analysis is impossible" for complex problems[94] . Formulation and implementation of strategy must thus occur side-by-side rather than sequentially, because strategies are built on assumptions which, in the absence of perfect knowledge, will never be perfectly correct. Strategic management is necessarily a "repetitive learning cycle [rather than] a linear progression towards a clearly defined final destination."[95] While assumptions can and should be tested in advance, the ultimate test is implementation. You will inevitably need to adjust corporate objectives and/or your approach to pursuing outcomes and/or assumptions about required resources. Thus a strategy will get remade during implementation because "humans rarely can proceed satisfactorily except by learning from experience; and modest probes, serially modified on the basis of feedback, usually are the best method for such learning."[96] It serves little purpose (other than to provide a false aura of certainty sometimes demanded by corporate strategists and planners) to pretend to anticipate every possible consequence of a corporate decision, every possible constraining or enabling factor, and every possible point of view. At the end of the day, what matters for the purposes of strategic management is having a clear view – based on the best available evidence and on defensible assumptions – of what it seems possible to accomplish within the constraints of a given set of circumstances. As the situation changes, some opportunities for pursuing objectives will disappear and others arise. Some implementation approaches will become impossible, while others, previously impossible or unimagined, will become viable. The essence of being “strategic” thus lies in a capacity for "intelligent trial-and error"[97] rather than linear adherence to finally honed and detailed strategic plans. Strategic management will add little value -- indeed, it may well do harm -- if organizational strategies are designed to be used as a detailed blueprints for managers. Strategy should be seen, rather, as laying out the general path - but not the precise steps - by which an organization intends to create

497

Strategic management

498

value.[98] Strategic management is a question of interpreting, and continuously reinterpreting, the possibilities presented by shifting circumstances for advancing an organization's objectives. Doing so requires strategists to think simultaneously about desired objectives, the best approach for achieving them, and the resources implied by the chosen approach. It requires a frame of mind that admits of no boundary between means and ends.

See also •

Business model

Marketing

Morphological analysis

Value migration

Business plan

Marketing plan

Overall equipment effectiveness

Six Forces Model

Business Strategy Mapping

Marketing strategies

Proximity mapping

International strategic management

Cost overrun

Management

Revenue shortfall

Hoshin Kanri

Management consulting

Strategic planning

Integrated business planning •

Military strategy

Strategy visualization

External links • The Journal of Business Strategies [99] • Strategic Planning Society [100] • The Association of Internal Management Consultants [101]-The nationwide network of Strategic Management and Planning professionals

References [1] David, F Strategic Management, Columbus:Merrill Publishing Company, 1989 [2] Lamb, Robert, Boyden Competitive strategic management, Englewood Cliffs, NJ: Prentice-Hall, 1984 [3] http:/ / www. prenhall. com/ carpenter/ [4] Chandler, Alfred Strategy and Structure: Chapters in the history of industrial enterprise, Doubleday, New York, 1962. [5] Selznick, Philip Leadership in Administration: A Sociological Interpretation, Row, Peterson, Evanston Il. 1957. [6] Ansoff, Igor Corporate Strategy McGraw Hill, New York, 1965. [7] Drucker, Peter The Practice of Management, Harper and Row, New York, 1954. [8] Chaffee, E. “Three models of strategy”, Academy of Management Review, vol 10, no. 1, 1985. [9] Buzzell, R. and Gale, B. The PIMS Principles: Linking Strategy to Performance, Free Press, New York, 1987. [10] Schumacher, E.F. Small is Beautiful: a Study of Economics as if People Mattered, ISBN 0061317780 (also ISBN 0881791695) [11] Woo, C. and Cooper, A. “The surprising case for low market share”, Harvard Business Review, November–December 1982, pg 106–113. [12] Levinson, J.C. Guerrilla Marketing, Secrets for making big profits from your small business, Houghton Muffin Co. New York, 1984, ISBN 0-396-35350-5. [13] Traverso, D. Outsmarting Goliath, Bloomberg Press, Princeton, 2000. [14] Schonberger, R. Japanese Manufacturing Techniques, The Free Press, 1982, New York. [15] Pascale, R. and Athos, A. The Art of Japanese Management, Penguin, London, 1981, ISBN 0-446-30784-x. [16] Ohmae, K. The Mind of the Strategist McGraw Hill, New York, 1982. [17] Peters, T. and Waterman, R. In Search of Excellence, HarperCollins, New york, 1982. [18] Rehfeld, J.E. Alchemy of a Leader: Combining Western and Japanese Management skills to transform your company, John Whily & Sons, New York, 1994, ISBN 0-471-00836-2. [19] Blaxill, Mark & Eckardt, Ralph, "The Invisible Edge: Taking your Strategy to the Next Level Using Intellectual Property" (Portfolio, March 2009) [20] Hamel, G. & Prahalad, C.K. “Strategic Intent”, Harvard Business Review, May–June 1989. [21] Hamel, G. & Prahalad, C.K. Competing for the Future, Harvard Business School Press, Boston, 1994. [22] Hamel, G. & Prahalad, C.K. “The Core Competence of the Corporation”, Harvard Business Review, May–June 1990. [23] Peters, T. and Austin, N. A Passion for Excellence, Random House, New York, 1985 (also Warner Books, New York, 1985 ISBN 0-446-38348-1) [24] Barney, J. (1991) “Firm Resources and Sustainable Competitive Advantage”, Journal of Management, vol 17, no 1, 1991. [25] Hammer, M. and Champy, J. Reengineering the Corporation, Harper Business, New York, 1993.

Strategic management [26] Lester, R. Made in America, MIT Commission on Industrial Productivity, Boston, 1989. [27] Camp, R. Benchmarking: The search for industry best practices that lead to superior performance, American Society for Quality Control, Quality Press, Milwaukee, Wis., 1989. [28] Deming, W.E. Quality, Productivity, and Competitive Position, MIT Center for Advanced Engineering, Cambridge Mass., 1982. [29] Juran, J.M. Juran on Quality, Free Press, New York, 1992. [30] Kearney, A.T. Total Quality Management: A business process perspective, Kearney Pree Inc, 1992. [31] Crosby, P. Quality is Free, McGraw Hill, New York, 1979. [32] Feignbaum, A. Total Quality Control, 3rd edition, McGraw Hill, Maidenhead, 1990. [33] Heskett, J. Managing in the Service Economy, Harvard Business School Press, Boston, 1986. [34] Davidow, W. and Uttal, B. Total Customer Service, Harper Perennial Books, New York, 1990. [35] Schlesinger, L. and Heskett, J. "Customer Satisfaction is rooted in Employee Satisfaction," Harvard Business Review, November–December 1991. [36] Berry, L. On Great Service, Free Press, New York, 1995. [37] Kingman-Brundage, J. “Service Mapping” pp 148–163 In Scheuing, E. and Christopher, W. (eds.), The Service Quality Handbook, Amacon, New York, 1993. [38] Sewell, C. and Brown, P. Customers for Life, Doubleday Currency, New York, 1990. [39] Reichheld, F. The Loyalty Effect, Harvard Business School Press, Boston, 1996. [40] Gronroos, C. “From marketing mix to relationship marketing: towards a paradigm shift in marketing”, Management Decision, Vol. 32, No. 2, pp 4–32, 1994. [41] Reichheld, F. and Sasser, E. “Zero defects: Quality comes to services”, Harvard Business Review, Septemper/October 1990. [42] Pine, J. and Gilmore, J. “The Four Faces of Mass Customization”, Harvard Business Review, Vol 75, No 1, Jan–Feb 1997. [43] Pine, J. and Gilmore, J. (1999) The Experience Economy, Harvard Business School Press, Boston, 1999. [44] Collins, James and Porras, Jerry Built to Last, Harper Books, New York, 1994. [45] Mulcaster, W.R. "Three Strategic Frameworks", Business Strategy Series, Vol 10, No 1, pp 68 - 75, 2009. [46] http:/ / www. attilascamp. com/ [47] Moore, J. “Predators and Prey”, Harvard Business Review, Vol. 71, May–June, pp 75–86, 1993. [48] Drucker, Peter The Age of Discontinuity, Heinemann, London, 1969 (also Harper and Row, New York, 1968). [49] Toffler, Alvin Future Shock, Bantom Books, New York, 1970. [50] Toffler, Alvin The Third Wave, Bantom Books, New York, 1980. [51] Hamel, Gary Leading the Revolution, Plume (Penguin Books), New York, 2002. [52] Abell, Derek “Strategic windows”, Journal of Marketing, Vol 42, pg 21–28, July 1978. [53] Handy, Charles The Age of Unreason, Hutchinson, London, 1989. [54] Gladwell, Malcolm (2000) The Tipping Point, Little Brown, New York, 2000. [55] Tichy, Noel Managing Strategic Change: Technical, political, and cultural dynamics, John Wiley, New York, 1983. [56] Pascale, Richard Managing on the Edge, Simon and Schuster, New York, 1990. [57] Slywotzky, Adrian Value Migration, Harvard Business School Press, Boston, 1996. [58] Slywotzky, A., Morrison, D., Moser, T., Mundt, K., and Quella, J. Profit Patterns, Time Business (Random House), New York, 1999, ISBN 0-8129-31118-1. [59] Christensen, Clayton "The Innovator's Dilemma", Harvard Business School Press, Boston, 1997. [60] Schartz, Peter The Art of the Long View, Doubleday, New York, 1991. [61] Wack, Pierre “Scenarios: Uncharted Waters Ahead”, Harvard Business review, September October, 1985. [62] Mintzberg, Henry “Crafting Strategy”, Harvard Business Review, July/August 1987. [63] Mintzberg, Henry and Quinn, J.B. The Strategy Process, Prentice-Hall, Harlow, 1988. [64] Mintzberg, H. Ahlstrand, B. and Lampel, J. Strategy Safari : A Guided Tour Through the Wilds of Strategic Management, The Free Press, New York, 1998. [65] Markides, Constantinos “A dynamic view of strategy” Sloan Management Review, vol 40, spring 1999, pp55–63. [66] Moncrieff, J. “Is strategy making a difference?” Long Range Planning Review, vol 32, no2, pp273–276. [67] Schuck, Gloria “Intelligent Workers: A new predagogy for the high tech workplace”, Organizational Dynamics, Autumn 1985. [68] Zuboff, Shoshana In the Age of the Smart Machine, Basic Books, New York, 1988. [69] Senge, PeterThe Fifth Discipline, Doubleday, New York, 1990; (also Century, London, 1990). [70] Quinn, J.B. Intelligent Enterprise, The Free Press, New York, 1992. [71] Jarillo, J. Carlos Strategic Networks: Creating borderless organizations, Butterworth-Heinemann, Oxford, 1993. [72] Barton, D.L. Wellsprings of Knowledge, Harvard Business school Press, Boston, 1995. [73] Castells, Manuel The Rise of the Networked Society :The information age, Blackwell Publishers, Cambridge Mass, 1996. [74] Liebeskind, J. P. “Knowledge, Strategy, and the Theory of the Firm”, Strategic Management Journal, vol 17, winter 1996. [75] Stewart, Thomas Intellectual Capital, Nicholas Brealey, London, 1997, (also DoubleDay, New York, 1997). [76] Sveiby, K.E. The New Organizational Wealth : Managing and measuring knowledge-based assets, Berrett-Koehler Publishers, San Francisco, 1997. [77] Probst, Gilbert, Raub, S. and Romhardt K. Managing Knowledge, Wiley, London, 1999 (Exists also in other languages)

499

Strategic management [78] Shapiro, C. and Varian, H. (1999) Information Rules, Harard Business School Press, Boston, 1999. [79] Frank, R. and Cook, P. The Winner Take All Society, Free Press, New York, 1995. [80] Evens, P. and Wurster, T. “Strategy and the New Economics of Information”, Harvard Business Review, Sept/Oct 1997. [81] Mulcaster, W.R. "Three Strategic Frameworks", Business Strategy Series, Vol 10, No1, pp68 - 75, 2009. [82] Barnard, Chester The function of the executive, Harvard University Press, Cambridge Mass, 1938, page 235. [83] Mintzberg, Henry The Nature of Managerial Work, Harper and Roe, New York, 1973, page 38. [84] Kotter, John The general manager, Free Press, New York, 1982. [85] Isenberg, Daniel “How managers think”, Harvard Business Review, November–December 1984. [86] Isenberg, Daniel Strategic Opportunism: Managing under uncertainty, Harvard Graduate School of Business, Working paper 9-786-020, Boston, January 1986. [87] Zaleznik, Abraham “Managers and Leaders: Are they different?”, Harvard Business Review, May–June, 1977. [88] leadership vs. management [89] Zaleznik, Abraham The Managerial Mistique, Harper and Row, New York, 1989. [90] Corner, P. Kinicki, A. and Keats, B. “Integrating organizational and individual information processing perspectives on choice”, Organizational Science, vol. 3, 1994. [91] Kim and Mauborgne. Blue Ocean Strategy. Harvard Business Press. 2005 [92] Lindblom, Charles E., "The Science of Muddling Through," Public Administration Review, Vol. 19 (1959), No. 2 [93] Woodhouse, Edward J. and David Collingridge, "Incrementalism, Intelligent Trial-and-Error, and the Future of Political Decision Theory," in Redner, Harry, ed., An Heretical Heir of the Enlightenment: Politics, Policy and Science in the Work of Charles E. Limdblom, Boulder, C): Westview Press, 1993, p. 139 [94] Ibid, p. 140 [95] Elcock, Howard, "Strategic Management," in Farnham, D. and S. Horton (eds.), Managing the New Public Services, 2nd Edition, New York: Macmillan, 1996, p. 56. [96] Woodhouse and Collingridge, 1993. p. 140 [97] Ibid., passim. [98] Moore, Mark H., Creating Public Value: Strategic Management in Government, Cambridge: Harvard University Press, 1995. [99] http:/ / COBA. SHSU. edu/ jbs/ [100] http:/ / www. sps. org. uk/ [101] http:/ / www. aimc. org

500

Article Sources and Contributors

Article Sources and Contributors Project management Source: http://en.wikipedia.org/w/index.php?oldid=367906617 Contributors: 152.98.195.xxx, 1959frenchy, 62.158.194.xxx, 9Nak, ALargeElk, Aaronbrick, AbsolutDan, Achalmeena, Acheah, Aeon1006, Aitias, Ale jrb, Alessandro57, Alisha0512, Allstarecho, Alphamu57, Altrock78, Anakin101, Ancheta Wis, AndrewStellman, AndyBrandt, AngelOfSadness, Anitanandi, Anodynomine, Antillarum, Ap, Aranel, ArmadilloFromHell, Arsenikk, Asannuti, Asoucek, AstareGod, Atif673, Austinm, AxelBoldt, BSJWright, Bananaman68, Barek, BartaS, Bdouthwaite, Beano, Beetstra, Belovedfreak, Bendoly, Benfellows, Bento00, Bernd in Japan, Bertha32, Blanchardb, Blathnaid, Bmartel, Bmicomp, Bnorrie, Bob Bolin, Bobo192, Bonadea, Boxplot, Brentwills, Brion.finlay, Burner0718, Butrain, CALR, CFMWiki1, CPMTutor, Calvadosser, Calvin 1998, Camw, CarlGuass, Ccorpusa, Cerrol, Chadloder, ChemGardener, Chiefwhite, Chris Roy, ChrisG, Chrispreece2007, Christiebiehl, Christopherlin, Chuq, Clad2020, Claidheamohmor, Closedmouth, Cloud10pm, Cmaley, Colin Marquardt, Cometstyles, CommonsDelinker, ConstructionSoftwareExperts, Conversion script, Craigwb, Creacon, Cst17, Cybercobra, DVD R W, Dan Polansky, DanielDeibler, Danielhegglin, Dansedmonson, David.alex.lamb, Dbfirs, DeadEyeArrow, Deimos814, Delirium, DeltaOperator, Dendlai, Dennis.wittekind, Derek Ross, Deville, Dghutchinson, Dgmoran, DominikusH, Donreed, Doroli, DougsTech, Dougweller, Dr PDG, Drshields, Dtarver, Dycedarg, ESkog, Earthandfire, EdBever, Edward, Eeekster, Ehheh, Elena1234, Elvismcgrady, Englishman in Provence, Epbr123, Eric Pement, Erkan Yilmaz, EronMain, Escape Orbit, Eshirazi, Exir Kamalabadi, Fabricationary, FactsAndFigures, Faithlessthewonderboy, Falcon9x5, FalconZero, Fang Aili, Favonian, Firien, Forestsmith, Fpolack, Frankfshsu, Fred Bradstadt, Freeformer, Freeskies, Frontelo, Fullstop, Funatic, Fxsunny, Fæ, GAPPS, GESICC, Garrybooker, GeoffWilson, Geoffsauer, GerK, Gerritklaschke, Gfani, Ghaag, Giftlite, Globalprofessor, Goethean, Gop 62, Graeme Bartlett, GraemeL, Graibeard, Granite07, Greyskinnedboy, Gruffi, Gsaup, Gunnala, Gurch, Guy Van Hooveld, Gwernol, Hadal, Haikon, HamburgerRadio, HappyCamper, Herbythyme, Hirzel, Hongooi, Howardjp, Hroðulf, Hubbardaie, Hubertus, Hudec, Hux, ICSGlobal, ITServiceGuy, Ian Pitchford, Imroy, IngaRea, Inwind, Itgov, Ixfd64, J.delanoy, Jaberwocky6669, Jackaranga, Janbenes, Jburks97, Jcardinal, Jdtoellner, Jeff3000, Jeffmcneill, Jeltz, Jetojedno, Jgritz, Jiang, JimGleaves, Jkhcanoe, Jlao04, Jmciver, Jmi41, Jmlk17, Jnankivel, John Richard Parker, John Vandenberg, JohnManuel, Jojhutton, Jonpro, Josemoromelon, Jp361, Judy Payne, Just plain Bill, Kanags, Kanojia, Karl-Henner, Kbh3rd, Kcone, Kelemendani, Kenmckinley, Kenstandfield, Ketiltrout, Kevin B12, Khalid, Khalid hassani, Khusroks, Kilmer-san, Kim Kris, KimBecker, Kingpin13, Kinu, Kltownsend, Kokcharov, Krappie, Ktlonergan, Kubigula, Kuru, Kwertii, L3aa-cademy, LFaraone, LeaveSleaves, Lecard, Leonardo Aloi, Levana77, Levineps, Liao, LightAnkh, LilHelpa, Linkspamremover, Lmarinho, Longdongniner, Loren.wilton, Luk, Lumos3, Luna Santin, Lundholm, Lynbarn, MY2sense, Macoykolokoy, MagnaMopus, Maokart444, Mapador, Marco Krohn, Margeru, Mark Millard, Mark Renier, Mark.murphy, Matt Deres, Maurreen, Mav, Mbrylant, Mdd, Media lib, Meitar, Melashri, Merovingian, Mgillett, Michael Hardy, Mimihitam, Minesweeper, Mini.here, Mkoval, Mlavannis, Mmpubs, Mneser, Monkey Bounce, Moonriddengirl, MorrisRob, Mpleahy, Mr.Z-man, MrKris, MrOllie, Mudgen, Mugunth Kumar, Muminshawaf, Mummy34, Munazanjum, Mwanner, Mwfnwa, Mydogategodshat, Mywikiid99, NOKESS, Nankivel, NawlinWiki, Nazmanager, Ngoult, Nickg, Nighthawkx15, Nikai, Ninadelis, Nishalegend, Niteowlneils, Nixdorf, Norm, OSUKid7, Oberiko, Oblomoff, Ocrakate, Oicumayberight, Ojigiri, Oldschoolosama, Onevalefan, Overviewer, Owain.wilson, Padraig1888, Paltpappa, Paradoxic, Parent5446, PatrickWeaver, Paul W, Pavel Vozenilek, Pcremer2270, Pcremerfluno, Pepperpiggle, Peter Reusch, Peterbud, Pgauld, Pgreenfinch, PhilHibbs, PhilKnight, Phreed, Pigsonthewing, Pilgaard, Pinkadelica, Pixievamps, Plakhi24, Pm by day, Pm master, Pmtoolbox, Poli08, Porchcrop, PrestonH, Project mosaic, Projectmagic, Protr, Psaico, Pstansbu, Pstout, Pukivruki, Pythia90, Qatestdev, Quadell, RAM, RJASE1, RJBurkhart, RJaguar3, RSedor, Radagast83, Radavi, RainbowOfLight, Rami R, RandyKaelber, Raymundsy, Raywil, Rcannon100, Readysetpass, Reconsider the static, RedHillian, Redux, Reedy, Reliablesources, Renebach, Renesis, Rernst, Research2007, Rich Farmbrough, Rich257, Richard Allen, Richard Harvey, RichardF, Richardgush, Richi, Richman9, Rlolsen, Rmp80ind, Ron Richard, Ronhjones, Ronz, Royallarry, Rrburke, Rrjanbiah, Rror, Rspanton, RuM, Rubysixty6, Ruud Koot, Rwgreen1173, Rwil02, S.K., SE SME, SJP, Salliesatt, Sandymok, Sara050805, Sarah, Saros136, Scaevus, Scientizzle, Scjessey, Sean Whitaker, Seanieboy1974, Search4Lancer, Sebasanjuan, Securiger, Seraphim, Shadowjams, Shanes, Sharkface217, Shawn in Montreal, Shoeofdeath, Shoessss, Shoy, Sisalto, Skumar.rakesh, Sleepyhead81, Smartse, Smiker, Smpickens, Solipsist, SorenAndersen, SpaceFlight89, Spalding, Spangineer, Spartikus411, Steevm, Stevenwmccrary58, SueHay, Sutanumartand, TVBZ28, Tarquin, TastyPoutine, Technopat, Tephlon, Tetraedycal, TetsuoTheRob, That Guy, From That Show!, The Led, The manekin, Thebluemanager, Thingg, Thopper, Thrane, ThreePD, Tijuana Brass, Tmopkisn, Tobryant, Tohd8BohaithuGh1, Tom Harris, Tosblt, Toytoy, Transity, Traroth, Trewinpa, Trial, Triz231, Trout001, Truthbro, Tslocum, Tswelch, Turnstep, Twestgard, Tzartzam, Uqjwhitt, Urbanette, Utcursch, VARies, Vaceituno, Vald, [emailprotected], Van der Hoorn, Vanderzyden, Vcmohanonline, Versageek, Vgranucci, Vigo10, Vincehk, Vineetgandhi, Viokiori, Voyagerfan5761, WJBscribe, WKirschling, Wacko39, Weatherman90, Weregerbil, Weyes, Wgoetsch, Widefox, Wik, Wikid77, Wikke41, Wissons, Woohookitty, Wrduncan3, X201, Xavexgoem, Yamamoto Ichiro, Yendor1958, Ykimva, Ylebihan, Yongliang08, Zigger, Zscout370, Zzuuzz, 1320 anonymous edits Project planning Source: http://en.wikipedia.org/w/index.php?oldid=351818715 Contributors: A3RO, Achalmeena, Adanac06, Anca, Antonmind, Ap, AstareGod, Barth81, BozMo, CALR, CharlotteWebb, Cheese Sandwich, Co1Spain, Cometstyles, Dave steinberg, DavidCane, DougsTech, Drshields, Ehheh, Fitster, Gadfium, Gchinkle, Glenn, Graibeard, Gsaup, Henk Bulsink, Hu12, ICSGlobal, ITServiceGuy, Jcalogic, Jwestland, KF, Kernoz, Ketiltrout, Kingpin13, Krakfly, Kulnor, Kuru, Makingprogress19, Mapador, MarkBrooks, Mkoval, MrOllie, Mydogategodshat, Nils, Nixdorf, Nposs, Ot, Ouro.redux, PatrickWeaver, Paul August, Paul W, PhilKnight, Philip Trueman, Pm master, Pmtoolbox, Pstansbu, Shanes, SimonP, Stephenb, Technobadger, Tmatyashovsky, Vut, Wavelength, Zemoxian, 88 anonymous edits Scope (project management) Source: http://en.wikipedia.org/w/index.php?oldid=364840144 Contributors: 1exec1, Alluvia, Anca, Appraiser, Barras, Billdow, Bmeacham, CDN99, Chowbok, Chroniclev, DJ Clayworth, Dagordon01, Dcfleck, DerrickGillissie, Fiz, Fredrik, Gary King, Gsaup, JackDOden, Keno, Kuru, Meatballhat, Mfo321, Michael Hardy, Mkoval, Moonriddengirl, Nacho Librarian, Piano non troppo, Pm master, RexNL, Rholton, Rich Farmbrough, Steven X, Themainone, TigerShark, WereSpielChequers, 36 anonymous edits Scope creep Source: http://en.wikipedia.org/w/index.php?oldid=364492672 Contributors: Andrew Hampe, Andrewpmk, Antandrus, Antonrojo, Artw, Autumn Forrester, CanisRufus, Carlif, Chealer, Christopherlin, CobraA1, DPdH, Dagordon01, David Gerard, E=MC^2, Fluzwup, Fresheneesz, Gilliam, Gsaup, Heirpixel, Ingolfson, JQF, Jerry, John, Josemariasola, Jtm2112, JustinTSampson, Kku, Krakfly, Laurusnobilis, Lights, Mac Davis, Mfo321, Mig21bp, Mkoval, Myproject, Neelix, Nemo20000, OlEnglish, Pm master, Polyextremophile, RockMFR, Ronbo76, Shdon, Skysmith, SmartGuy, Sonderbro, Stephenboothuk, Stifle, SueHay, Theoldanarchist, Tony Sidaway, Tsilb, Wahrmund, Wickethewok, Woohookitty, 58 anonymous edits Design structure matrix Source: http://en.wikipedia.org/w/index.php?oldid=364250104 Contributors: Barneyboo, Benbulloch, Borgx, Gary King, Jurgenhomann, Kku, Kreimeyer, Mdd, Michael Hardy, Neerajsangal, PSmacchia, Paul W, Radagast83, Tonyfaull, TyBrown, Vaucouleur, 15 anonymous edits Systems Development Life Cycle Source: http://en.wikipedia.org/w/index.php?oldid=367908939 Contributors: ABF, Adamgibb, Ahoerstemeier, Aitias, Ajbrulez, Albanaco, AlephGamma, Allan McInnes, Allstarecho, Andaryj, Anonymous Dissident, Ansell, Arjun01, BasilBoom, Bfigura's puppy, Bobo192, BrianY, CFMWiki1, CalebNoble, Cbdorsett, Chris 73, Chrislk02, Closedmouth, Cochiloco, Cody574, Copyeditor22, Croepha, DGJM, Dandv, Danielphin, David.alex.lamb, DavidDouthitt, DeadEyeArrow, Djsasso, DrKranium, DuncanHill, ESkog, Eastlaw, Ebessman, Enauspeaker, Epbr123, Erkan Yilmaz, FiRe, GD 6041, Gaff, GarbagEcol, Gilliam, Hydrogen Iodide, HyperSonic X, Informatwr, IvanLanin, J.delanoy, J04n, JaGa, Jdg12345, Jeff G., Jeremy Visser, Jinian, Joe4210, John Vandenberg, John.stark, Jonverve, Josephedouard, Jpbowen, Kalai545, Kenyon, Kesla, Kevin, Khalid hassani, Kingpin13, KnowledgeOfSelf, Kr suraesh, Kuru, Kurumban, LAX, Latka, Lectonar, Liftarn, Little Mountain 5, Luna Santin, Maghnus, Marek69, Mark Renier, Mdd, Meisterflexer, Michael Hardy, Mick1990, Mikesc86, MrOllie, Mrwojo, Mummy34, Natkeeran, Natl1, Neurophyre, Niaz, Nkattari, NuclearWarfare, OMouse, Octahedron80, Oliverclews, Omicronpersei8, Paxsimius, Philip Trueman, Piano non troppo, Pikajedi3, Pingveno, Pip2andahalf, RadioFan2 (usurped), Raymondwinn, Recognizance, Rich Farmbrough, Rjwilmsi, Ronz, Rooseveltavi, Rwwww, Sam Hobbs, Sarloth, Satishshah123, SchmuckyTheCat, ScottWAmbler, Seth Ilys, Shadowjams, ShwetaCool, Sigma 7, SigmaJargon, Srushe, Steelchain, Strawny02, Swep01, Syrthiss, Tanvir Ahmmed, Tee Owe, Teohhanhui, The Anome, ThePointblank, TheProject, TheTallOne, Thomasjeffreyandersontwin, Throwaway85, Tide rolls, Tonyshan, Transcendence, TwilligToves, Vashtihorvat, VectorThorn, Versus22, WikHead, Wiki alf, Wimt, Wspencer11, Wtmitchell, Xphile2868, Xsmith, Yeng-Wang-Yeh, Yogi de, Zondor, 729 anonymous edits Enterprise resource planning Source: http://en.wikipedia.org/w/index.php?oldid=367514780 Contributors: Abhishek.cmath, Accountwiki2, Adam McMaster, Adi4094, Adnanbukhari, Afreytes, Agamemnon2, Aillema, AjeetKhurana, Akirn, AlMac, Alansohn, Amardesich, Amgadpasha, Amitapa, AndonicO, Andreas.ooijer, Andrewspencer, Andyjsmith, Anilswayin, Antonmind, Antonrojo, Ardafif, Arpabr, Asc99c, Ash, Ass12345, Asusean, Ba8inz, Baa, Baboons are cool, Barcelova, BarretBonden, Bellenion, Biblbroks, BinaryTed, Bjdehut, Black Falcon, Blanchardb, Bobdc, Bobo192, Boothy443, Boris.kirzner, Brianga, Brijadmin, Buzzcp02, Bwrs, CART fan, CIS601, Calliopejen1, Camw, Can't sleep, clown will eat me, CanadianLinuxUser, Capricorn42, Cattons, Ch'marr, Chanakal, Chery, Chessphoon, Chris 73, CiTrusD, Clayoquot, Cleared as filed, Closedmouth, Codetiger, Colonel Warden, Cometstyles, CommonsDelinker, Constructive editor, Conversion script, Corruptcopper, Cunac, Cureden, Cvcby, Cybercobra, CygnusPius, Cymbalta, D6, DStoykov, DanMS, Dangelow, Danielloh100, Darp-a-parp, David Schaich, DavidJ710, DavidLevinson, DerHexer, Derekcslater, Descendall, Deviator13, Dinarphatak, Dirkbb, Discospinster, Dmb, Dmozer1, Dogtanion, Donert, Doubrown, Dr.Soft, Earthlyreason, El C, Elambeth, Enviroboy, Epbr123, Eptin, Erpconsultantajay, Erpgenie, Espoo, Estherschindler, Euryalus, Evercat, Ezeu, Fabrictramp, Feldh, Feraudyh, Fergussa, Ferkelparade, Finell, Fish and karate, Flewis, Former user 2, Fred Bradstadt, Fsfgnu, Func, Fvilim, Gbenzie, Geoff Plourde, Gioto, Gladstone, Gnewf, Gogo Dodo, Gool930, Gracenotes, Graham Berrisford, Greensburger, Griot, Gunnala, Gurch, Hadal, Haham hanuka, HanH, Harold Hreem, Hdahlmo, HighKing, Hmains, Ikiroid, Ilovshuz, ImperatorExercitus, Imrehg, IndulgentReader, Interiot, Iridescent, Irimar, IvanLanin, J.delanoy, JDBravo, JVSN, JaGa, Jamelan, James 45uyh, Jasford, Jay, Jbrowning100, Jbw2, Jean lw lequeux, Jeannie Fung, Jeff G., Jennavecia, Jgritz, Jiddisch, Jmejedi, Jni, JoanneB, JoeSmack, Johndci, Johnmarkh, Jorge.baldeon, Jpbowen, Juanpdelat, Julieb1934, KHLehmann, KJDoran, KKramer, KMPLS, KamuiShirou, Kapil bathija, Karenjc, Kavehmz, Kbh3rd, Kenyon, Khalid hassani, Kku, Knguyeniii, KnowledgeOfSelf, Korg, Kozuch, Kubigula, Kuru, LOL, Lankiveil, Lbertybell, Lhsfb24, Limit0, LindaDavey, Linkspamremover, Lootzyne, Lootzyne12, Lootzyne21, Loren.wilton, LoveEncounterFlow, Lprice, [emailprotected], MER-C, Magnus.de, Mahyt, Maltesedog, MarkJeremy, Materialscientist, Matt Deres, Maurreen, Mboverload, Mdd, Meermaid, Mentifisto, Mfstutz, Mggreennc, Michael Hardy, Mikaey, Mikel Gómez, Mirage.maverick, Mitaphane, Mnemeson, Moa3333, Mohammadmorad, Momoricks, Mpanosh, MrArt, Mudgen, Mufka, Murattali, Mxn, Myanw, Mydogategodshat, Nahado, Nandssiib, Narayana vvss, NawlinWiki, Nazgul02, Ncw0617, Nelson50, NetManage, Nick1nildram, Nicolokyle, Ninc, Nino Gonzales, Njethwa, Nktrox, Nomadcowboy, Nva.openerp, Nzd, Oezdemir, Ohnoitsjamie, Oleg Alexandrov, Olivier, Omicronpersei8, Oxymoron83, PPGMD, Palecitrus, Park3r, Peter.m.ng, Petit.tigre, Pfeller, PhilHibbs, PhilipSmith, Piano non troppo, Picapica, Pinaghosh, Pink Bull, Pointillist, Polluxian, Porchcrop, Poromenos, Poweroid, Prari, Prasad123, Priyanka tripathi 1385, Prnay, Quarl, RM MARTIN, Random name, Ratsystem, Rchilakapati, Recurring dreams, Reedy, Renesis, Rgill, Rhobite, Richard D. LeCour, RichardVeryard, Rjwilmsi, Rodii, Ronz, S.K., Sam Hocevar, SamJohnston, Sanjiv swarup, Sarefo, Saros136, Saurabh.gupta12, Saxifrage, Schmei, Seanbw, Seanoduinneachair, SebastianHelm,

501

Article Sources and Contributors Sega381, Serag4000, Shahnavazkazi, Shanes, Shizane, SidP, Sivaraj, Skyezx, Skysmith, Sleepyhead81, Snowded, SpaceFlight89, Splash, Squirepants101, Steevm, Storm Rider, Sudhani, Svetovid, Svtuition2009, Swamiyogesh, T.J.V., Tbarr60, Tedickey, The Fifth Horseman, The Random Editor, The Thing That Should Not Be, ThinkERP, TigerShark, Tkreykes, Tmol42, Tom harrison, Tommy2010, UM 049, Ukexpat, Unyoyega, User27091, Vaishi1110, Van der Hoorn, Van helsing, Veinor, VeniWikiVici, Vercalos, Vidram01, Vinay R Pawar, Wayiran, WhiterRabbit, Wiki alf, Wikipkth, Wknight94, Wootah, WurkrB, Xezbeth, Yurik, Zedla, Zfr, Zoicon5, Zzuuzz, 1238 anonymous edits Project slippage Source: http://en.wikipedia.org/w/index.php?oldid=357366990 Contributors: Kevzspeare, PamD Project charter Source: http://en.wikipedia.org/w/index.php?oldid=364119325 Contributors: Binoyjoseph76, DARaynor, Dave6, Faller, Jazzy Diva, Joaodelvalle, Lanma726, Laterality, Myproject, Pm master, R'n'B, Sbugs, Steven Zhang, SueHay, 18 anonymous edits Software bloat Source: http://en.wikipedia.org/w/index.php?oldid=364739404 Contributors: Aerotive, Agnaramasi, Akuyume, AndrewWTaylor, Andrewpmk, Arganoid, Arrataz, Artw, AzaToth, BCube, Barrylb, Bearcat, Beland, Billy the Impaler, Boxstaa, Brian Kendig, Camahuetos, Cameron Scott, CanisRufus, Chris Chittleborough, Cyan, DanielPharos, Dario D., David Latapie, DavidFarmbrough, Davidhorman, Dekimasu, Dleonard, DocWatson42, Donarreiskoffer, Downstrike, Drakferion, Dysprosia, Eje211, EqualRights, Evercat, Evildeathmath, FT2, Fran z, Fredrik, Friday, Fuzzie, Geh, Gerbrant, Getonyourfeet, Gizzakk, Glaurung quena, Gracefool, Gwern, Gzornenplatz, Havarhen, Haz7po5, HelixJock, Huw Powell, Iamtheari, Illegal Operation, J.delanoy, JLaTondre, Jamelan, Jamyskis, Jclemens, Jibjibjib, JonHarder, Jonathan Drain, Joshua Issac, Katieh5584, Kietedan, KindOfBlue, Kittins floating in the sky yay, Komeil, Lacrimosus, Laudaka, Laurusnobilis, Leone ruggente, Light current, Little Professor, Lloeki, Lonesoldier, Lowellian, Luxdormiens, Lysdexia, Mardus, Martinwguy, Marudubshinki, Mas 18 dl, Master Thief Garrett, MattOates, Maximus Rex, Mh29255, Michael Hardy, MichaelBillington, Mikeblas, Minghong, Modemac, Monedula, Mukadderat, Nate1481, Navstar, Nmadhubala, Normankev, Nydigoveth, ONjA, Off!, Otvaltak, PRRfan, Pandamonia, Paranoid, Park3r, Pedant, Project2501a, Ptomes, Radagast83, Riagu, Rocket000, SJ2571, Sanremofilo, SchuminWeb, Shorne, Simxp, Smjg, Squash, Srleffler, Stephenchou0722, Stevenrasnick, Sverdrup, THEN WHO WAS PHONE?, Teryan2006, Therichdude, Timneu22, Towel401, Treknology, TurboForce, Tzler, Valce, Valiantineus, Venomlord99, Voidvector, Waffle, WalterGR, Warren, Wereon, Williamv1138, XX55XX, Yay unto the Chicken, Ynhockey, Zephalis, ZeroOne, Ziko, Zodon, Zweifel, 208 anonymous edits Megaprojects and Risk Source: http://en.wikipedia.org/w/index.php?oldid=301516733 Contributors: Acroterion, Alan Liefting, Albany NY, CanisRufus, Cate, Cheapskate08, DAJF, DavidLevinson, Gsaup, HResearcher, Henrygb, Jerem43, John Quiggin, Johnfos, Mangojuice, Miller52, Poli08, R00m c, Redvers, SB Johnny, Sbmehta, Sonderbro, TastyPoutine, Urbanette, Van helsing, Woohookitty, Wwoods, 7 anonymous edits Megaproject Source: http://en.wikipedia.org/w/index.php?oldid=367278042 Contributors: -Majestic-, Aditreeslime, Aiman abmajid, Alcuin, Andy Marchbanks, Anskas, Antonmind, Arnab1996, Atownballer, BD2412, BIL, Bistro-sidecar, Bleaney, Brahmanknight, By78, Caytruc, Cdcdoc, Charles Matthews, Cheapskate08, Chimesmonster, Closedmouth, CommonsDelinker, Cooljuno411, Crazym108, Dale Arnett, Daviessimo, Daxaius, Deamon138, Dewey Finn, Donteatyellowsnow, Dotdkay, Drbreznjev, Elipongo, Engi08, Engineman, Epicadam, Ewlyahoocom, FFLaguna, Fantasysquall, Ffbond, Fish and karate, Fred Stober, Gabz80, Geni-pmd, George Burgess, Gorillazfeelgoodinc, Grant65, Grosscha, Gsaup, Gspinoza, Helmandsare, Hibernian, Hyperdrunk83, Inwind, Isaabis, JCDenton2052, Jeedai, Jerem43, Jminthorne, Joe3600, Joostvandeputte, Jpbowen, Jrockley, Jruderman, Jthomas275, Kennethmac2000, Kevlar67, Kevptim, Krakfly, Ksyrie, Kuru, Kurykh, Lake Ontario, Laurielegit, LeadSongDog, Lucamauri, MER-C, Maestroka, Magog the Ogre, Majorprogramme, Manop, Mario1987, Martinp23, Mastrchf91, MathKnight, Mauricio Maluff, Maurreen, Mausy5043, Megaproject, Mhking, Miremare, MisterSheik, MoHasanie, Mongreilf, Moondyne, N328KF, Nadyes, Nebraska3, Nomi887, Nottheking, Onkl, Ont, Ordew, Paul W, Plasma east, Plumpurple, Poli08, Polylepsis, Publunch, Quidam65, R00m c, RJFJR, Radioheadhst, Raywil, RenJadahr, Richmond96, RobNS, Rolypolyman, Sahrin, Sandando, SchuminWeb, Sdeox, Sevilledade, Shalom Yechiel, Shin368, Shiplevelone, Signsolid, Sinolonghai, Soulvisionq1, Starbois, Stevertigo, Stypex, Subwayguy, Sulmac, The Anome, The wub, Thingg, Tierce, Timothyhouse1, Tuduser, Tunafish1990, Twang, Urbanette, Usergreatpower, Van helsing, Varnav, Vedant, Wikimastername, Willhsmit, X-4, Yahel Guhan, Ynhockey, Yourai, 279 anonymous edits Feature creep Source: http://en.wikipedia.org/w/index.php?oldid=367879872 Contributors: Aarktica, Abdull, Artw, Arvindn, BigSmoke, Bloodshedder, Bluemoose, Camembert, Chumbukket, Circeus, Clindhartsen, Colonel Warden, Dancter, David Latapie, DavidFarmbrough, Delirium, Dhaluza, Dionyziz, Ehheh, Evercat, Everything counts, Frap, Fredrik, Furrykef, Gargaj, GoodDay, Gracefool, Groyolo, Gunstar hero, Gwern, Iceberg3k, Jcrocker, Jevav, Joy, Jvhertum, KohanX, Koolabsol, Kwertii, Kylemcinnes, Legolas558, Lifefeed, Liftarn, Lost.goblin, LrdChaos, Lugiatm, Marudubshinki, MattOates, MaxEnt, Mcohurlids, Mernen, Mugunth Kumar, Neelix, Neilc, Nihiltres, Ningauble, Northgrove, Optim, Ortzinator, Paddu, Pengo, Prari, ProhibitOnions, Project2501a, Quest for Truth, Rbellin, Robert Brockway, Ronald S. Davis, RoySmith, SCEhardt, SarekOfVulcan, Segiddins, Sergey Moskalev, Simetrical, Sjc, Slady, Steggall, StuRat, Tabletop, Tb, TechPurism, The Red Hat of Pat Ferrick, Tjdw, Trickrick1985, Warren, WhisperToMe, Zanter, Zondor, 46 anonymous edits Instruction creep Source: http://en.wikipedia.org/w/index.php?oldid=364739269 Contributors: Altenmann, Arjun01, DCGeist, Dar-Ape, Dhaluza, Fresheneesz, Kaid100, Koweja, Mathmo, OlEnglish, Tractorkingsfan, UnitedStatesian, Wolf530, 6 anonymous edits Creep (project management) Source: http://en.wikipedia.org/w/index.php?oldid=364284822 Contributors: BlankVerse, Bluemask, Ceyockey, JustinTSampson, Mark.murphy, Mkoval, OlEnglish, SP-KP, ShelfSkewed, 3 anonymous edits Cost overrun Source: http://en.wikipedia.org/w/index.php?oldid=364249922 Contributors: Allstar86, BIL, Bachcell, Banaticus, Beland, Benlisquare, Brennanhay, Ceyockey, Cheapskate08, Cryptic star, Daniel Callegaro, Gsaup, Jkhcanoe, Kkmurray, Krakfly, Krashski35, Kuru, Latka, MaxEnt, Miller52, Pm master, Pnm, Publunch, R'n'B, SchuminWeb, Summit84, Tiresias BC, Wafulz, Wikimaguire, Xezbeth, 26 anonymous edits Mission creep Source: http://en.wikipedia.org/w/index.php?oldid=346964903 Contributors: A Siegel, Avocado, Bantman, Brien Clark, Consequentially, CzarB, Dave6, Davewho2, Dravecky, Fuhghettaboutit, Hmains, IvoShandor, Jeff3000, Jeffq, Kku, LeeHunter, Lockesdonkey, Mostlyharmless, Neelix, Octane, Pekinensis, Redeagle688, RexNL, Richard Weil, Robofish, Ronbo76, RoyGoldsmith, SimonP, SueHay, The Rambling Man, The Squicks, TheMadBaron, TigerShark, Trublu, Wereon, 23 anonymous edits Waterfall model Source: http://en.wikipedia.org/w/index.php?oldid=361639614 Contributors: Aamahdys, Ageekgal, Alarob, Alienus, Alitheg, Alksub, AnthonyQBachler, Ap, Arwel Parry, Averisk, BarretBonden, Benabomb1, BigC9heese, Binksternet, Binrapt, Bobo192, Brick Thrower, Brockert, Camw, Carlif, Ceyockey, Charles Matthews, Chris G, Cmdrjameson, Conversion script, Crinoidgirl, David.alex.lamb, Deep vnw, Deor, DhirajGupta, Donald Duck, DoubleBlue, Doulos Christos, Duminda1986, Dysprosia, Earlypsychosis, EatMyShortz, Ed Poor, Edward, Emperorbma, Emvee, Epbr123, Eric B. and Rakim, Erkan Yilmaz, Eugene van der Pijll, Faradayplank, Favonian, Feyandstrange, Folajimi, Frankenpuppy, Frankieroberto, Freedom to share, GFLewis, Gendut, GeorgeBills, Greghc, GregorB, Halcyon1234, Halmir, Hamtechperson, Harryboyles, Hendrik Brummermann, Hooperbloob, Hut 6.5, Huwr, I do not exist, IRKAIN2, Iftikharzafar, Ilario, Inteligente, Isaacdealey, J.delanoy, JCLately, Jackol, JayEsJay, Jeff G., JeremyA, Jerome Charles Potts, Jim Huggins, Jimmykaw, Jjhrogers, Jmabel, Jonnalagaddaharish, Joyous!, Jpgordon, K.Nevelsteen, K.lee, Karmona, Kbdank71, Kedarthatte, Kim Bruning, KimBecker, Kku, KnowledgeOfSelf, Koavf, Korny O'Near, Kthnxrick, Kuratowski's Ghost, Kuroboushi, Largestill, Learntruck, LeaveSleaves, Lerdthenerd, LiDaobing, Lvmeijer, MER-C, MIT Trekkie, Manop, Mark Foskey, Mdd, Mebden, Mentifisto, Merenta, MichaK, Michael Devore, Michael Hardy, Mikething, Nick UA, Niteowlneils, Nzeemin, OMouse, Oashi, Oicumayberight, Omicronpersei8, PanagosTheOther, Pascal.Tesson, PaulGarner, PaulHoadley, Paulsmith99, Pebkac, Pevernagie, Piano non troppo, Pinethicket, Pm master, Profdhiren, Qirtaiba, RadioFan2 (usurped), Razimantv, Rbrewer42, Red Thunder, Reyk, Rich Farmbrough, Rich257, Rick.G, Rjwilmsi, Rodney Boyd, Rollotomnasi, Ronz, Rrburke, Ryulong, Saaga, Salmar, Sardanaphalus, Schmiteye, Sean.cavanagh, Shanemcd, Slicing, Soup man, Spacepotato, Stumps, Tarmo, Technocratic, Tee Owe, Teoryn, TeunSpaans, That Guy, From That Show!, The Anome, Themfromspace, ThomasOwens, Thunderboltz, Titoxd, Tjamesjones, Trevor MacInnis, Trivialist, Tvarnoe, Ungoliant13, Veinor, Viento, Vincehk, Vinjosh, Viriditas, Wdyoung, Wikiuser183, William Avery, William Pietri, Xeolyte, Yangy0514, Yaronf, Yaxu, Yworo, Zaffman, 480 anonymous edits IBM Rational Unified Process Source: http://en.wikipedia.org/w/index.php?oldid=367380466 Contributors: 0612, AV3000, Ablackburn63, Adrianwilford, Ahoerstemeier, Akrasnoff, Allan McInnes, Alynna Kasmira, AmiDaniel, Andreas Kaufmann, Anoko moonlight, Antcore, Antonielly, Ashley Y, Bachrach44, BccThis, Ben Liblit, BenFrantzDale, Benoit rigaut, Bill37212, Binder520, Bobo192, Bogey97, Braiam, Brick Thrower, Brunoton, Bunnyhop11, Bushnate, Bwefler, Cecile Peraire, Chammy Koala, China Crisis, ChrisG, Claceriv, Coldacid, Crazycomputers, Cubslvr, DRogers, Davewampler, David.alex.lamb, DavidTangye, Dayaanjali, Desmay, Dethomas, Deville, Dhbernstein, Discospinster, DoubleBlue, Doug Bell, Dr sharad77, Duk, Dysprosia, Elpecek, Erkan Yilmaz, Erud, Evil Monkey, Excirial, Firebrandck, Flewis, Flity.flea, Foobar, Fred Bradstadt, FredThwaites, Func, GFLewis, Gazpacho, GeorgeStepanek, Gepwiki, Gflewis, Goblot, GregorB, Gwernol, Hadal, Hayk, Hede2000, IDefx, Ian Joyner, IanVaughan, Inter, IrisKawling, IvanLanin, Ixfd64, J Milburn, JPH-FM, Jasefisher, Jcarroll, Jcw69, Jdtruax, Jgritz, Jocoder, John Doe42, Karl Dickman, Kbdank71, Khalid hassani, Kirill Lokshin, Krappie, Kruchten, Kuratowski's Ghost, Kzollman, LarryBH, Lemming, Levin, Linearizer, Lurnid, MER-C, Mark Bergsma, Mark Renier, Matthew Stannard, Mdd, Meisam, Merenta, Michael Hardy, Mjchonoles, Mmxx, Mohamed Nabil, Mohamedosman, Nandesuka, NeilenMarais, Neonumbers, Nigosh, Nikhildhar, Nilmerg, Niteowlneils, Noisy, NotAbel, Oicumayberight, Olekva, Ondrejk, Paofkoi, Parhelia, PedroPVZ, Pinecar, Pippin K, Pseudopanax, PsychoSafari, Purgatory Fubar, R Mark Nolan, RG2, RHodnett, Rasbury, Rich Farmbrough, Richard R White, RichardVeryard, Ripe, Rogerd, Royboycrashfan, Royell, Rwwww, RxS, S3000, SQL, SWAdair, Sam Hocevar, SanGatiche, Sardanaphalus, ScottWAmbler, Sgaragan, Shell Kinney, Sidna, Srinivasbt, Stevenrhoffman, Suffusion of Yellow, SuprDude, Svdwatt, Ta bu shi da yu, Tcncv, Tedickey, TehBrandon, The Thing That Should Not Be, Tinman, Tree Biting Conspiracy, TriGen, Tv316, Tvarnoe, Uncle G, Uzume, Vortexrealm, Wapcaplet, Webagogue, Wernight, Wesleyidmaur, Will1604, Wolfling, Woohookitty, WpZurp, Xtier, Zoe, Zoicon5, Zundark, 965 anonymous edits Requirements management Source: http://en.wikipedia.org/w/index.php?oldid=360720113 Contributors: ALMGuru, Aagtbdfoua, AbsolutDan, Ajcheng, AlarmTripper, Andreas Kaufmann, Bapim, Beetstra, Cassbeth, Chowbok, Clayoquot, Colin Marquardt, ComputerGeezer, D1ma5ad, Ddenise, Delenburg, Douga, Dritzer, Dvansant, Ehheh, Ency, Fabrikant, Firetrap9254, Fpradier, Freeformer, Gaius Cornelius, Greyskinnedboy, Haakon, Hu12, JDBravo, JRose22033, Janiejones56, Jhaniotis, John5K35, Keilana, Khalid hassani, Kokoala, Krubin, Kuru, Lakeworks, Lars112, Lars12, Legolost, Madjidi, Man It's So Loud In Here, Mdd, Michael Hardy, Mjchonoles, MrTree, Nainil, Nopetro, OlEnglish, Owain.wilson, Pickerill, Programming Research,

502

Article Sources and Contributors Raghunathan.george, Rfortner, Rich Farmbrough, Rjwilmsi, Ronz, Ruud Koot, SEI Publications, Sabri76, Samiroy, Sfdan, Shambhaviroy, SoftwareDeveloper, Splash, Srogers74, Starrymessenger, Tevirselrahc, Tivedshambo, WiKiMan3L, Wimt, XqRG, 124 anonymous edits Critical Chain Project Management Source: http://en.wikipedia.org/w/index.php?oldid=367342560 Contributors: Ap, Barney Gumble, ChrisG, Cmprince, Dandv, Dirrival, Finereach, Firien, Fl, Gcjb, Gert4gt, Hartmanz, Hdsteyn, Ironwolf, JVT001, Jackollie, Jackvinson, Jaynelm, John of Reading, Joy, Kcone, Kenmckinley, Ketiltrout, Kevinalewis, Kuru, Maurreen, Mav, Michael Hardy, Mkoval, MrOllie, Mydogategodshat, Nikai, Notheruser, PhilHibbs, PigFlu Oink, Pm master, Profdb, Realization, Rick Block, Rjwilmsi, Ron Richard, Ronz, Silverpop81, Simbient Mike, Spalding, Sspecter, SunCreator, Svetovid, TOCExpert, Thopper, Tj.klaucke, Toddwill, Ve2dc, Ylebihan, 78 anonymous edits Cone of Uncertainty Source: http://en.wikipedia.org/w/index.php?oldid=354506901 Contributors: Dhananjay7, Diego Moya, Iridescent, Jandockx, Khalid hassani, Sebastian.Dietrich, 8 anonymous edits Problem solving Source: http://en.wikipedia.org/w/index.php?oldid=366552259 Contributors: 2D, 2spyra, AbsolutDan, Action potential, Adapt, AdjustShift, Agbormbai, Ahoerstemeier, Alex Kosorukoff, Ancheta Wis, AndriuZ, Angr, Anna512, Antaeus Feldspar, Ap, Arjun G. Menon, Astral, Ayda D, Bachcell, Beanary, Billfmsd, Bobblewik, Boxplot, BrotherGeorge, Bufar, Celestianpower, ChemGardener, Cielomobile, Clhtnk, Cmcurrie, Coachuk, Corza, Credible58, D. Tchurovsky, DBragagnolo, Dave6, Dawn Bard, Dbfirs, Ddr, Derekristow, Djcremer, Djdrew76, DoctorW, Download, Eric-Wester, Eve Teschlemacher, Everyking, Extremecircuitz, Facilitation Author, Ferris37, Forenti, Frazzydee, Fvw, Genegorp, Giftlite, Gioto, GlassCobra, Good Vibrations, Graham87, Guggenheim, Gunnar Hendrich, HGB, Harald.schaub, Hari, Heron, Houghton, Hu12, Hydrogen Iodide, IceCreamAntisocial, Iggynelix, Ingi.b, Inter, IvR, IvanLanin, JForget, JaGa, Jacopo, Jan Tik, Jaranda, Jd2718, Jeames, JimmyShelter, JoachimFunke, JoeC 4321, Johnkarp, Jon Awbrey, Jose Icaza, Jrmindlesscom, Jtneill, Juanscott, Kazooou, Keilana, KillerChihuahua, Kizor, Kku, Kosebamse, Ksyrie, LaurensvanLieshout, Laxerf, Leestubbs, Letranova, Leuko, Levineps, Liao, LilHelpa, Lord Bane, Lupin, MCrawford, MMSequeira, Majorclanger, Marc Venot, Marek69, Markstrom, Marsbound2024, Marx01, Mattisse, Matty Austwick, Mbonline, McGeddon, Merlion444, Mgret07, Michael Hardy, Michaeldeutch, Mild Bill Hiccup, Moeron, Mr.Z-man, Nesbit, New Thought, Nicearma, Nikolas Stephan, Novum, Oda Mari, Oleg Alexandrov, Ott, Paranomia, ParisianBlade, Pavel Vozenilek, Pedant17, Peter gk, Peterlewis, Philip Trueman, Pickledh, Pilgrim27, Pioneer-12, Possum, Ralphruyters, Rapdetty, RaseaC, Reinyday, Richard001, RichardF, Rick Sidwell, Rjwilmsi, Ronz, Rsrikanth05, Ruud Koot, SLcomp, Saga City, Samhere, Saxifrage, Scoutersig, Sengkang, Sg gower, Shanes, SheldonN, Shimgray, Shoessss, Sidaki, Spalding, Srikeit, Stifle, Stone, Suidafrikaan, Tagishsimon, Tarquin, TexasAndroid, The Evil IP address, TheEgyptian, Theresa knott, Thiseye, ThreePD, Vaughan, VodkaJazz, VoteFair, Whatfg, Wikilibrarian, Wimbojambo, Woohookitty, Yammy Yamathorn, YellowMonkey, Yhkhoo, ZimZalaBim, Ziphon, 254 anonymous edits Resource leveling Source: http://en.wikipedia.org/w/index.php?oldid=365323139 Contributors: Briankennemer, Crawdevil, Crystallina, D6, DmitryOsinovsky, Johndburger, Maria.staicovici, Mindmatrix, Neelix, Planschd, Pmberry, Xp54321, 7 anonymous edits Theory of Constraints Source: http://en.wikipedia.org/w/index.php?oldid=367304334 Contributors: Activplant, Alvestrand, Ampers&Amper&, Ancheta Wis, AndriuZ, Arrievn, Aweinstein, Bdelfield, Bill Levinson, Bob402, Bonadea, Camw, Cbhoov, Celique, Chewie103, ChrisCork, Cngoulimis, Colerichardcole, Craigburke, Dhollm, Diego Moya, Dupdegrove, ESkog, EagleFan, Ecksteing, Elwikipedista, EugeneZelenko, Facius, Gail, Garkbit, Gil mo, Gloucks, GraemeL, GregorB, H005, Henry Delforn, Hrbaptista, HumbertoRB, Ihcoyc, Innerlite, Ironicon, Ironwolf, Iskatel, JSambrook, JVT001, Jackvinson, Jagmore, Jctrabs, Jeffmcneill, Jenny MacKinnon, Jensbn, Jmuenzing, Jonahphile, Joy, Jschwa1, Kankan.paul, Kevinalewis, Khalid, Kuru, LeanImplementor, Lsisson, MJKazin, MarkProffitt, Maurreen, Mausy5043, Mbenna, Metacomet, Meyerkl, Michael Hardy, Mkoval, Mydogategodshat, Nhansencmg, Nickren, Notheruser, Nposs, Nskillen, Ocee, Oleg Alexandrov, OllieFury, Palvarezflores, Pegasus1138, Peterthorby, Philip Marris, Pmeisel, Pwilliams TOCH, RJBurkhart, RJBurkhart3, Rich Farmbrough, Rmptls, RogerR00, Ronhjones, Ronz, Shadowjams, Snowded, Soljaguar, Sonneborn, Sp3, Spalding, Steindl, Stevebushnell, Stumps, Surendra mohnot, Svetovid, Systemica, TOCExpert, Tedd, The Rambling Man, Tj.klaucke, Toddwill, Tresiden, Trevithj, TrojanBUFDriver, Unyoyega, Usually Right, Van der Hoorn, WVhybrid, Wik, William Avery, 351 anonymous edits Agile management Source: http://en.wikipedia.org/w/index.php?oldid=345897086 Contributors: Aamahdys, Aternity, Caerwine, Jeodesic, Joelpt, MCB, Mberteig, Mmpubs, MrOllie, Philip Trueman, Pm master, Psiphiorg, Siddhi, Srinicenthala, SteveLoughran, SueHay, The Evil Spartan, Thebluemanager, 22 anonymous edits Extreme programming Source: http://en.wikipedia.org/w/index.php?oldid=366886956 Contributors: 2004-12-29T22:45Z, 209.239.208.xxx, Aacool, Agentbla, Alfio, AllanBz, Amire80, Anderbubble, Anorthup, Anthony Appleyard, Arvin Schnell, Atreys, AxelBusch, BBB, Beland, BenAveling, Bernd in Japan, Bevo, Bfalese, BigBen212, Bookofjude, Breandandalton, Brownout, Bryan Derksen, CLAES, CYD, Cameltrader, Canderra, CarlManaster, ChrisSteinbach, Chrislk02, Chwu, Closeapple, CometGuru, Conversion script, Cverlinden, Cybercobra, DRogers, DarkseidX, David.alex.lamb, Debresser, Descender, Dharmabum420, Dharris, Di Stroppo, Djgandy, Dodoïste, ESkog, Ed Poor, Edward, ElinneaG, Empiric, Eric B. and Rakim, Ewlyahoocom, Frecklefoot, Gaius Cornelius, Gdavidp, Geni, Gigi fire, Gogo Dodo, Goodrone, Gruber76, Hao2lian, Hede2000, Hirzel, HolgerK, Holizz, Homerjay, Hritcu, Hzhbcl, Ilja Preuß, Introvert, Iterator12n, Jcarroll, Jensgb, Jezmck, Jittat, Jjsladek, Jmabel, JordanSamuels, Juanco, Jvale, Jwbecher, K.Nevelsteen, Kaniabi, Kbdank71, Kent Beck, KerryBuckley, Kgasso, Knutux, Kristof vt, Kurt Jansson, Kuru, Kurykh, LFaraone, LarsHolmberg, Laterality, Lews Therin, LiDaobing, LilHelpa, Littlesal, Looxix, Lumberjake, MCB, Malcohol, Malleus Fatuorum, Marijn, Mark Renier, MarkDilley, Martinig, Mathew Roberson, Mathmo, Matt Crypto, Matusz, MaxSem, Mboverload, McGeddon, Mdd, MementoVivere, Merenta, Mfdavies, Mhartl, Michael Hardy, Michig, Mike1234, MithrandirMage, Miyako, Mkoval, Mmeijeri, Mmpubs, Morphex, Mpeisenbr, MrOllie, Myasuda, N8mills, Neilc, Netsnipe, NigelR, Nightreaver, Nigosh, Ninja247, Ninly, Niteowlneils, Oicumayberight, Olexandr Kravchuk, On5deu, Oni king, Orborde, Oriondown, Osmodiar, Pak21, Patrickdepinguin, Pearle, Peashy, Pengo, Peripitus, Peterl, PhilipR, Piano non troppo, Picaroon, Plasticup, Pm master, PradeepArya1109, Primetime, Pweemeeuw, Quantum7, Quintote, R'n'B, RSaunders, Rajesh1981, Ram.nivas, Ramsyam, Rebroad, Rediahs, Renesis, Retired username, ReyBrujo, Richard R White, Rjwilmsi, Rmp, Rnickel, Ron Richard, Rookkey, Rscottfree, Ruud Koot, S.K., Sarah.cartwright, Sardanaphalus, SeanLegassick, Secretmessages, SensuiShinobu1234, Shannock9, Shepard, Sjc, Srinicenthala, Starwiz, SteveLoughran, Stevertigo, Stormie, Stumps, Susurrus, Sverdrup, Swasical, Taejo, TakuyaMurata, Teryx, TeunSpaans, The Thing That Should Not Be, TigerShark, Timwi, Tlroche, Tobias Bergemann, Tomb, Tree Biting Conspiracy, Tregoweth, Trusilver, Tsilb, Vary, Vincehk, Virgiltrasca, Wangi, Wapcaplet, Wdyoung, Webmaestro, Wesley, Wgiezeman, Whytehorse1413, Wikid77, William Pietri, Xiong Chiamiov, Yaninass2, Zedlik, Zsinj, Zundark, 526 anonymous edits Scrum (development) Source: http://en.wikipedia.org/w/index.php?oldid=367006263 Contributors: 4johnny, Aardvark92, Abhi3385, AbominableBob, Adi4094, Afternoon, Agile blog, Ajm661023, Alansohn, Alex43223, Ali Osmany, Alphachimp, Alphamage, Andreas Kaufmann, Andy Dingley, Annasw, Antialias, Avalon, Avec, Az944racer, Baa, Beland, Bernd in Japan, Bliong, Blueguybur, Bombe, Boomshadow, Brainix, Brevan, BrianWren, Brianski, Brick Thrower, Buddhikaeport, C.deepthi, Can't sleep, clown will eat me, Carlton.northern, Cat Parade, Cerrol, Cheny com, Chi11ken, Chrisc666, Chunkylover199, Clayoquot, Codeengage, CometGuru, CommonsDelinker, ComputerGeezer, ConchangoMaster, Corprew, Craig Stuntz, Cthart, Cybercobra, Daniel.Cardenas, DavidShepherdson, Debhart, Derek.munneke, Derekhuether, Discospinster, Diya batti, Dogaroon, Doroli, Dougluce, Dpcoka, DrBeard, Drunken Pirate, Dspectar, Dude4456dude, Echofloripa, Edddie, Edward, Eirik.midttun, Elecnix, Eliyahu S, EngineerScotty, EweC, Exemplar sententia, Faller, FeralDruid, Ficell, Firien, Fred Bradstadt, Freedomlinux, Garde, Gaurav, Gegonut, Gmathur2k, Guppie, Gwern, Gwernol, Hajatvrc, Heaths, Heron, Hhiroshi, Hondo77, Hooperbloob, Humu, Huygens 25, Hwsd, Hyad, Hydrogen Iodide, Iani, Immunize, Influent1, Ishi Gustaedr, Itairaz, Iterator12n, JaGa, Jamelan, Jared Hunt, Jaysweet, Jdpipe, Jed meyers, Jeff.Mortimer, Jesse Laanti, Jferman, Jhertel, Jmilunsky, Jmundo, Johannes.braunias, Johnchapman4, Jonducrou, Jordo ex, Jorfer, Julesd, Juraj.Kubelka, Jvstein, Jzylstra, Jérôme, KF9129, Kazvorpal, Kenimaru, Kevin Forsyth, Kirrages, Kmouly, Koustubh123, Kragelund, LOL, Lakeworks, Lastorset, Lerkey, Linusdalin, Littlesal, LokiClock, Loreleine1, Lotje, Lprichar, Luc Legay, Marcoshz, Martinig, Mathiastck, Matthew0028, Mckaysalisbury, Mdd, Mdubakov, Mesolimbo, Michael98101, Miranda, Mistercupcake, Moriori, Mottzo, MrOllie, Mrh30, Mutant, Nakon, NickVeys, Nmehta6, Obonicus, Oicumayberight, Oskilian, Ostraaten, PavelCurtis, Peterhundermark, Petritis, Psiphiorg, RJaguar3, Radagast83, [emailprotected], Reach Out to the Truth, Reconsider the static, Rich Farmbrough, Rich257, Rignac, Riki, Riordanmr, Rlliii, Robert.d.macdonald, Robjenssen, Rogerborg, Rubyuser, Runtime, S M Woodall, SAE1962, SDC, SMcCandlish, Saforcer, Salon Essahj, Sardanaphalus, Scbomber, Scottwilleke, Scrum2001, Scrumedge, Scrummaster, Scrumone, Sean D Martin, Shadowcat231, Shinmawa, Sirk390, Sky Diva, SlubGlub, Songrit, Stephanvaningen, Stephenb, Stephiee01, Tech vaibhav, Teckmx5, Tellyaddict, The Thing That Should Not Be, The Wild Falcon, ThomasOwens, Ticaro, Tiddly Tom, Timbertstc, Tjarrett, Tnxman307, Tobias Bergemann, Tobych, Torin the Chosen, Trevorjfitz, Tryevenharder, Tsemii, Tumma72, Unkei, Untruth, Van der Hoorn, Wainstead, Walter Görlitz, Wegra, William Avery, Willowrising, Winterstein, Wizmo, Wperdue, Zorakoid, Zycron, 630 anonymous edits Event chain methodology Source: http://en.wikipedia.org/w/index.php?oldid=327672881 Contributors: Alksub, CZmarlin, Cnbrb, Gail, Kenmckinley, Ketiltrout, Kuru, Mdd, Miller52, RHaworth, RichardVeryard, Skomorokh, 11 anonymous edits Human interaction management Source: http://en.wikipedia.org/w/index.php?oldid=350370821 Contributors: Adoble, Ammalu, Ansell, Bnorrie, Doug Bell, JasonLax, Joel Alcalay, Keith.harrison-broninski, Martin.ashcroft, Michael Hardy, Pgagge, Reinyday, Yandman, Zzuuzz, 16 anonymous edits Process modeling Source: http://en.wikipedia.org/w/index.php?oldid=367822992 Contributors: Ahybler, Alta.van.der.merwe, BPIResearch, Barkeep, Bartonitz, Bnorrie, Certus01, Ceyockey, Clarknova, Deicool, Dekimasu, Diveintobpm, Drrwebber, Ehheh, Fergus Cloughley, Fram, Frap, Goflow6206, Gryszkalis, Hhielscher, Iness it, JDBravo, Jajis, Jamelan, King of Hearts, Lindsey8417, MME, MairAW, Mdd, Michael Hardy, Mjchonoles, MrOllie, Obankston, Radagast83, Renesis, Richard R White, RichardVeryard, Rjwilmsi, S, Sean R Fox, SiobhanHansa, Smoothloader, Teammetz, Tmahfouz, Travis.a.buckingham, 86 anonymous edits Event chain diagram Source: http://en.wikipedia.org/w/index.php?oldid=255080727 Contributors: Atulr, Cnbrb, Kenmckinley, Kuru, Lockley, Mdd, Yapone, 1 anonymous edits Gantt chart Source: http://en.wikipedia.org/w/index.php?oldid=367349718 Contributors: Achalmeena, Agent007bond, Alansohn, Alex-golder, Alexandre Ilha, Andreviens, AndriuZ, Anna Lincoln, Archer3, Arthena, Atropus32, Bandeditor, Beatrice06, Big Bird, BillFlis, Biswalchinmayranjan, Black Butterfly, Bonkling, Bradjamesbrown, Bruno Unna, Buki ben Yogli, C i d, Can't sleep, clown will eat me, Capricorn42, Chandoo.d, Chartex, Chemical Engineer, Chrisirwin, Chuunen Baka, Clust4a, Crazycomputers, CycleTimeChart, Dadude3320, Dan D. Ric, Dead3y3, Den fjättrade ankan, Dhavelin, Don Gis, Drawn Some, Dream out loud, Eclipsed, Economist332, Ehn, Ellywa, Elm-39, Emrekenci, Enriketuned, Epharos, Etz Haim, Flewis, FlyingToaster, Gaius Cornelius, Garrybooker, GentlemanGhost, Georgewilliamherbert, Gilliam, Gimmetrow, Gogo Dodo, GraemeL, Graham87, Graibeard, Gramlin, Grant beest, Grotte, Gwernol, Haham hanuka,

503

Article Sources and Contributors Helfrich c, Hephaestos, HeronOfAlex, Horstvonludwig, Hu12, Ijon, Ioanapv, Itai, J.delanoy, JLK7476, Janus999, Jeff3000, Jeffreywherrmann, Jeltz, JidGom, Jmlk17, Johnenew, Jos.jong, Jpbowen, Karnesky, Kenmckinley, Khaled hosny, Kingboyk, Kmccoy, Koranjem, Kotasik, KrakatoaKatie, Kuru, Kzafer, Leesly, Ligulem, Lilmissdaughty, Lizzlizzlizz, Mac Davis, MagnaMopus, Mahjong33, Manfi, Manifredtellew, Manop, Mapperboy, MarkS, Maurreen, Mdd, Mecanismo, Melcombe, Michael Hardy, Mindmapmad, Mkoval, Montblanc2000, Mydogategodshat, Myleslong, Nascar1996, Naudefj, Ndyguy, Nevron, Nihil novi, NinjaOnFire58, Nixdorf, PMDrive1061, PatrickWeaver, Peachris, Pedroserafin, Pinethicket, Piotrus, Pm master, PookeyMaster, Preslethe, Proofreader77, Raindy, RedWolf, Redfirefly, Rememberme123, Renderpeterson, Requestion, Ronhjones, Ronz, Rrburke, Ryan Postlethwaite, S.K., SNIyer12, ST47, Salvio giuliano, Sbisolo, Sergio.ballestrero, Seriema, SimonP, Skybum, Snigbrook, SpaceFlight89, Spangineer, SpeedyGonsales, SusanB99, Susurrus, Svetovid, Tanetris, Tanár, TastyPoutine, Tbone55, Teenage wikian, The Thing That Should Not Be, Thorpe, Tomzi, Train78, Travis99, Tregoweth, Trialsanderrors, Triwbe, UNV, Uucp, VMS Mosaic, Va7sdf, Vipinhari, Wapcaplet, Whpq, Yamamoto Ichiro, Yettie0711, Zachlipton, Çalıştay, 440 anonymous edits PRINCE2 Source: http://en.wikipedia.org/w/index.php?oldid=366563711 Contributors: Akbradford, Alanpc1, Alimozcan, Alynex, Amakuha, Angela, Antidoter, Arnauldvm, Ash, Athirumurthi, BKRathke, Barinder hothi, Bethmanj, Bhadani, Binarygal, Bobrayner, Bonadea, Ccrichte, Chilin, China Crisis, ChrisG, Colonel.jrd, Danus, Database, Deb, Dibbler5, Dowm, Drbreznjev, Dysprosia, Eeekster, Ehheh, Erikko, Ezeu, Face, Fakelvis, Fernandosantucci, Fionaspence, Fish and karate, Freek Verkerk, FreplySpang, Gene Nygaard, Ghettolave, Greyskinnedboy, Guaka, Haham hanuka, Harry Wood, Heesoyuy, Hellfire81, Hughcharlesparker, IILMarketing, Igniz flameheart, Iness it, Inter, Itgov, JP du Preez, Jamelan, Jcamp, JmRay, Kaare, Khyron2008, KimMarello, Kku, Kolmigabrouil, Kuru, Lbk3918, Lonegroover, Lynbarn, MTr, Malcolmxl5, Mark Bush 29, Mark Tranchant, Marqoz, Mattisse, MaxPont, Mdd, Meredyth, Mgillett, Michael Snow, Mike0001, Millstream3, Mkoval, Mnorse, MrKris, MrTrev, Nelson50, Nico Mannaerts, Notreadbyhumans, Ntitsuit, Oblomoff, PRINCE2Andy, Peter Grey, Pinnecco, Pm master, Pmckeever, Pmtoolbox, Pnaybour, Polymorp, Poor Yorick, PorthosTyke, Pothoc, ProductBox, Prof Wrong, RHaworth, Rajan52s, Rellis1067, Retired username, Rich Farmbrough, Richard Allen, Rillian, Rkoster, Sbrumpton, Sean.sandys, Sietse Snel, Snarpel, Speck-Made, StephenAshurst, Steve wiki ppc, Stuartroebuck, SueHay, Syiem, Technobadger, The Anome, The undertow, Thebluemanager, Throxana, Thruxton, Tianyx159, Tim Boothby, Todo14, Tommy2010, Tony knowledge, Tthheeppaarrttyy, Vasiľ, Vlipper, Vortexrealm, WTF-tech, Wednesdaa, Wftbuts, Wiki alf, Wizard191, ZeroOne, 365 anonymous edits Process- based management Source: http://en.wikipedia.org/w/index.php?oldid=318721712 Contributors: CALR, Dcfleck, Gogo Dodo, Kjkolb, Kku, Loaferman, Radiant!, Rich Farmbrough, RichardF, RichardVeryard, Shajikv, 18 anonymous edits ISO/ IEC 15504 Source: http://en.wikipedia.org/w/index.php?oldid=356370324 Contributors: Aguila, Amayzed, Ash, Blchrist, Bouricot, Brenont, Daniel FR, DanielPenfield, Dblash, Ehheh, GregorB, Guroadrunner, Hanvanloon, Hongooi, IvanLanin, JHorn, Jamelan, Kku, M.e, Matthew Stannard, Mdd, Mitch Ames, Mysid, Next2u, Phil Boswell, Programming Research, Radagast83, Rjwilmsi, Roberto999, Sbowers3, TheoClarke, Versageek, 104 anonymous edits Capability Maturity Model Integration Source: http://en.wikipedia.org/w/index.php?oldid=367838894 Contributors: AHB1982, Aamahdys, Akris, Alcanzar, Amit.hole123, Ash, BenFrantzDale, Bethmanj, Bigpnut, Blchrist, Cander0000, Carlton.northern, Cemophora, Centrx, Chowbok, Chrzastek, Cmmiloveprocess, Conan, Cybercobra, Da Joe, DanielGuenther, David Biddulph, DePiep, Degsy99, Dirkbb, Discospinster, Dougluce, Długosz, Emurphy42, Espoo, Exleon, Favonian, Feťour, Flity.flea, Frap, Gaius Cornelius, Graham87, Greyskinnedboy, Gus W, Gyrofrog, Halmstad, Harriv, Hbachus, Hillelglazer, Hu12, Huberthofmann, IainB, Igoldste, Intray, IvanLanin, Jamelan, Jarl Friis, JavierMC, Jeffq, John.catalano, JonnyJD, Jrdalton, Kelemendani, KentAaronJohnson, Kjetil r, Lorezsky, Lurnid, Malte Foegen, Matias.Reccius, Mdd, MendipBlue, Mjrchaos, Murftown, NightFalcon90909, Nobunaga24, Oldgeez, Omarcheeseboro, On5deu, Pm master, Pne, Psoenen, Refins, Rfortner, Rich Farmbrough, Rikkitikki128, Rjwilmsi, Rmosler2100, Roberto999, Roesser, Ronz, Ruud Koot, SEI Publications, SRyll, Salliesatt, Sandys2000, Sandyshrum, Saxbryn, Sc147, SilentWarrior85, Srushe, Sspecter, Tedickey, Ticaro, Truthanado, Utuado, VMS Mosaic, Versus22, Walter Görlitz, Wmcrielaard, Xsmith, 223 anonymous edits Research and development Source: http://en.wikipedia.org/w/index.php?oldid=366656540 Contributors: 2D, AmoryHiggins, Ario, Ashchap, BD2412, Bukaj, Cestor, Chendy, Closedmouth, Courcelles is travelling, Coyote-37, Dancter, Danlev, Dduff, Delirium, DerHexer, Discospinster, Donahuepm, E Wing, Easternknight, Ehheh, Elapsed, Epbr123, Escape Orbit, Espoo, FDP1, FelixKaiser, Flowanda, Frecklefoot, Freed Maxick, GJeffery, Gadfium, Gh87, Gonfus, Governor Jerjerrod, Ground Zero, Harryzilber, Hmbr, Hu12, Ianmc, Ike9898, IvanLanin, J.delanoy, JPD, JWithing, JoeSmack, KEK, L Trezise, Lewinzhang, Lysdexia, MER-C, Mac, Malcolma, Malienlaf, Martpol, Materialscientist, Maurice Carbonaro, Maurreen, Mejor Los Indios, Michael Hardy, Mikeo, Mild Bill Hiccup, Mitch Ames, MrOllie, Mrdthree, Mydogategodshat, Naus, NawlinWiki, NewEnglandYankee, Nihil novi, No1lakersfan, Nopetro, Oiws, Oxymoron83, PGWG, Papercutbiology, Parabellum101, PaulHanson, Philip Trueman, Rd232, Rentaferret, Richard001, Robin48gx, Ronz, Rrburke, Ryulong, S h i v a (Visnu), Schenkeli, Schmiteye, Sciguy47, Searchanddevelop, Seraphim, Shoujun, SidP, Stormbay, Stormstrike, Swedish fusilier, Tastyfast, Technopat, ThaddeusB, Themfromspace, TheoClarke, Topgear23, Tregoweth, Troymarkz, Tushar ghodake, VRCOutreach, Waggers, WannabeAmatureHistorian, Wikifm1!2, Willsmith, 188 anonymous edits Stage- Gate model Source: http://en.wikipedia.org/w/index.php?oldid=366448504 Contributors: Crowne, DGG, Dorimedont, Giraffedata, Greyskinnedboy, Izabellalis, Jenarl, Manscher, Mba8125, Mdd, Minisarm, MrOllie, Mvellandi, Nsharif, R'n'B, RHaworth, Rgephart, Ronz, Teammanagement, TheLetterM, Therealprocrastinator, Uncle G, Zhuchu9605, 10 anonymous edits Financial analysis Source: http://en.wikipedia.org/w/index.php?oldid=364462151 Contributors: Ahoerstemeier, Amtiss, Angelbo, Antandrus, Arknave, Babetis, BadlyBlues, Bhadani, Bkell, Blake-, Borgx, Cheapskate08, Clecio, DocendoDiscimus, EagleOne, Feco, Financial-projections, Fxcxt, Glinos, Hu12, Hubbardaie, JForget, JPV, Jeff3000, Jenifan, Jerryseinfeld, Krakfly, Kuru, LilHelpa, Lodev, Modelwatcher, Moe Epsilon, Ohnoitsjamie, Pgreenfinch, RJN, Retail Investor, Ricata, Rinconsoleao, Rwil02, Sevela.p, SimonP, Spmcnamee, TheoClarke, Tide rolls, Tomas e, Treetopluvr, Versageek, 38 anonymous edits Stakeholder analysis Source: http://en.wikipedia.org/w/index.php?oldid=366785224 Contributors: Amalas, Choohan, Chowbok, Ckyliu, Corza, CzarB, Decker2, Djjrjr, Earthsummit2005, Fredmorcos, GRBerry, Gavin.collins, IrishInNY, JohnInDC, JonaYang, Kuru, Makewa, Mapador, Mdd, MrOllie, Mwfnwa, Paine Ellsworth, PatrickWeaver, Pm master, Rjwilmsi, Socraticscholar, SueHay, TobyJ, Tonycatman, Travelbird, TredWel, Unconnected, 40 anonymous edits Deliverable Source: http://en.wikipedia.org/w/index.php?oldid=356640889 Contributors: Alphamu57, CapitalR, Cfrjlr, Chrylis, Cnbrb, DAJF, DMCer, Dave steinberg, Flagman7, Fpolack, Geeperzcreeperz, IvanLanin, Jojo soprano, Khusroks, Mdd, Miguel Andrade, MrOllie, Pm master, Randhirreddy, Sbesselsen1984, Time Immemorial, 36 anonymous edits Budget Source: http://en.wikipedia.org/w/index.php?oldid=366605464 Contributors: A5b, Addihockey10, Adriaan, Aesopos, Alansohn, Aldaron, Aldo samulo, Alfonso13, Amandaxploradora, Anabus, Appraiser, Aranel, Avono, Bakabaka, Barek, Barticus88, Bharnish, Bobo192, Boleslav1, Canaima, Capricorn42, Captain-tucker, Cassandra 73, Chuck Marean, Ciphers, CliffC, Crocodile Punter, D-Rock, Da monster under your bed, Daniel I. Harris, Danny, DavidWBrooks, DeadEyeArrow, December21st2012Freak, Discospinster, Dragana666, Drbreznjev, ErikTheBikeMan, Everyking, Fan-1967, Fayenatic london, Folajimi, Fox, Francs2000, Fred Bradstadt, Fundamental metric tensor, Gec118, GeorgeStepanek, GerwynJames, Gogo Dodo, GoodbyeRosie, GraemeL, Gromlakh, Gsaup, Gurch, HalfShadow, Hammasvalas, Hariva, Hede2000, HenkvD, Ibcnet321, Ixfd64, J.delanoy, JForget, Jasper Chua, Jbgilm, Jctrabs, Jerzy, Jim.henderson, Jonathan de Boyne Pollard, Joonasl, Jpgordon, Kaihsu, Keegscee, Keith Edkins, Kingharald, Kjkolb, Kku, Kubieziel, Kuru, Kushboy, Lamro, Larrypaulb, Linktopast30, MBisanz, Maedin, Mahanga, Makawity, Mattisse, Meekohi, Meelar, Melsaran, Michael Hardy, Minority Report, Missshmu, Mmxx, Moriori, MrOllie, Mycomp, NicholasTurnbull, Nick Green, Nikhilpatlolla, Nk, NocturnalA6 2.7, Nomad2u001, Oh shizzle, Ohnoitsjamie, Ojigiri, OrbitOne, Pankajsingh.1, Paris By Night, Patrick, PaulHanson, Persian Poet Gal, Pm by day, PoeticVerse, Quantpole, Queenie Wandy, Quest for Truth, Qwert, R27182818, RapidR, Rettetast, Rhobite, Rich Farmbrough, Rinconsoleao, Rogper, Roninbk, Ryan Lanham, SQL, ST47, SchfiftyThree, Secretmessages, Shadygrove2007, Shanes, Shikhashrestha, SimonP, SiobhanHansa, SlamDiego, Sm8900, Smallman12q, Standpipe, Stevietheman, Storm Rider, SueHay, Summit84, Superzohar, Sycocowz, Tadkashadka, TastyPoutine, TenOfAllTrades, The Random Editor, The Rationalist, The Thing That Should Not Be, Thedjatclubrock, Theone00, Toastcard, Tomnelson17, Tony Sidaway, Trusilver, Ttmmblogger, Ugen64, Uncle G, Unint, Unionhawk, Vary, Versageek, WereSpielChequers, Wiwaxia, Wvfootball50, Xhosan, Xyzzyplugh, Zigmasta5, Zoop, Zyxw, 292 anonymous edits New product development Source: http://en.wikipedia.org/w/index.php?oldid=367274460 Contributors: Abraham70, Addicted2u2, Ahoerstemeier, Alexhorni, Alphajuliet, Ambitus, Anghualee, Anita Burr, Anthere, Arjun01, Bennose, Bexpertise, BigFatBuddha, Blathnaid, BlowToad, Bobo192, CBDunkerson, CharlesGillingham, Dancter, DarkFalls, Davemon, David Haslam, Davidullman, Davolson, Dejunior13, Dkrempa, Dorimedont, Download, Dylan Lake, Edgar181, Ehheh, Ericnutsch, Eugene van der Pijll, EvanYares, Excirial, Farosdaughter, Floquenbeam, Flyingember, Frank 1st, Frap, Freeformer, Futureobservatory, Gal Sivan, Galvanist, Gary King, Gizmotech, Gp trials, Guanaco, Gurch, HaGingi, Hadal, Highrool, Hu12, Interknit Pictures Ltd, Inwind, Ipigott, Irishguy, J. Nguyen, J04n, JMB376, Jazz360, Jeangjg, JeremyA, Jj137, Jonathan Drain, Joyous!, Just Another Dan, KF6KJG, Ketiltrout, Kozuch, Kuru, Lantzilla, LaurensvanLieshout, Lbeaumont, LeCire, Liface, LightAnkh, Lomn, Loren.wilton, Lradrama, MER-C, MaNeMeBasat, Mandala chakri, Manscher, Marcodecarvalho, Maurreen, Mausy5043, Mdd, Michael Hardy, MichaelHaeckel, Michaeldnorman, MidiUser, Midiwhale, Midoladido, Miller17CU94, Mind123, MrOllie, Mspraveen, Mydogategodshat, NawlinWiki, Needofthehour, Nobbyx4, Nzgabriel, Ojigiri, Oxymoron83, Patsar, Pawl Kennedy, Phillydesign, Plau, Prestonpdx, Prodman121, RSColley, Rentaferret, Rixs, Rjwilmsi, Rlsheehan, Robomaeyhem, Ronz, Ryulong, SE SME, Sander123, Sbechar, Seanose, Shadowjams, Shshshsh, Sjhaines, Slakr, Slapierre, Slashme, Spinacia, SteveLoughran, Subash.chandran007, Sunil Bechar, Tbonejoo, TechChina, [emailprotected], Tiddly Tom, Tivedshambo, Topbanana, Trendwolf, VSather, Veinor, Vpdvpd, Westendgirl, Woohookitty, Zigo1232, Zsinj, Zundark, 222 anonymous edits Risk Source: http://en.wikipedia.org/w/index.php?oldid=366714517 Contributors: -oo0(GoldTrader)0oo-, 1ForTheMoney, 4twenty42o, 927, Abheid, Actorstudio, AdjustShift, Ahoerstemeier, Aixroot, Al001, Alansohn, Aldaron, Alex S, Algorithme, Allanon97, Altenmann, Ancheta Wis, Andman8, Andycjp, Anneaholaward, Anon lynx, Apparition11, Arauzo, ArnoldReinhold, Avraham, BBird, Baartmns, Backvoods, Bart133, Beland, BenC7, Bhupinder.Kunwar, Bihco, Bill52270, Billy hentenaar, Bjp716, BlairZajac, Bob Burkhardt, Bonus Onus, Bovineone, Brick Thrower, BrokenSegue, Bruceporteous, Burntsauce, CALR, CDN99, COMPFUNK2, CSWarren, Caissa's DeathAngel, Calliopejen1, CambridgeBayWeather, Capricorn42, CaptainLexicon, Carax, CarolynLMM, Carrp, Caster23, Cate, Charles Matthews, Charles T. Betz, Cheapskate08, Chinsurance, Christian List, Ciphergoth, Cobaltbluetony, Coldmember, Colignatus, Commander Keane, Condrs01, Conversion script, Cretog8, CurranH, Cutler, Cyberdog, DCstats, DFLovett, Daguero, David w carraher, Davies69, Dean Armond, Derek Balsam, Dhartung, Dialectric, Dionisiofranca, Dkeditor, DocendoDiscimus, DomCleal, DonSiano, Doobliebop, DrWorld, Drivi86, Duoduoduo, Dylan Lake, EPM, ERosa, Editor1962, Eeekster, Eep², Emezei, Emvee,

504

Article Sources and Contributors Enchanter, Evil Monkey, Fieldday-sunday, Fjejsing, Former user, Freddie Coster, Frederic Y Bois, Fuhghettaboutit, Gaius Cornelius, Galoubet, Garion96, Geoff Leeming, Geoffr, Giftlite, Glinos, Gogo Dodo, Gomm, Gregorford, Gsaup, Gurch, Habiibi, HalJor, HalfShadow, Hayabusa future, He Who Is, Heiyuu, Helgus, Henrygb, Heron, Hgty, Hu12, Hubbardaie, Husond, Iam, Iamaav8r, Iamthesaju, Icewraithuk, Interik, J.delanoy, JForget, JIH3, JRR Trollkien, Jauricchio, Jaxl, Jeff3000, Jeronimo, Jerryseinfeld, Jheald, Jimmaths, Jjeeppyy, John Quiggin, Johnny Pez, Jon Lackow, Jpbowen, Jtneill, Kenmckinley, Kered77, Kku, Kpmiyapuram, Krakfly, Kuru, Kvdveer, Kwhitten, Larry V, LeadSongDog, Lear's Fool, Lee Daniel Crocker, Levineps, LilHelpa, Linuxlad, Lowellian, M-banker-212, MCTales, Mac, Marco Krohn, Martarius, Martinp, Mason3*, Matthew Blake, Maudonk, Max Neill, Mbc362, Mboverload, Melcombe, MementoVivere, Michael Hardy, Miller52, Mirv, Mnath, Monk Bretton, Moonriddengirl, MrOllie, MrQwag, Msngupta, My Cat inn, Myanw, Myrvin, NHRHS2010, Neelix, Nevcao, Nikai, Nurg, Oliverwyman, Omegapowers, Osias, Overix, OwenX, Oxymoron83, Pakoistinen, Panybour, Patrick, Pgan002, Pgr94, Pgreenfinch, PhilipMW, Pianoman23, Platothefish, Pm master, Pointergrl, RSStockdale, Razimantv, Rd232, Requestion, Rescherpa, RevRagnarok, Rgvandewalker, Rhobite, Rich Farmbrough, Rich257, Rimini, Risk Analyst, Riversider2008, Rjwilmsi, Roelzzz, Roni38, Ronz, SAE1962, SDC, Sam Hocevar, Satori Son, Scalene, Scott Sanchez, SebastianHelm, Seffer, Severa, Shoefly, SilkTork, Simesa, Simoes, Simon123, Sjforman, Sketchmoose, Snow555, SnowFire, Snowded, Snowmanradio, SocialNeuro, Sonderbro, SpeakerFTD, Spearhead, Spunch, Stemonitis, Stevenjones15, Stijn Vermeeren, Subsolar, Sugarfoot1001, Supergreg no1, Tedickey, Testbed, Texacali3d, The Anome, The Thing That Should Not Be, The-dissonance-reports, TheGrappler, Thfmax, Tlroche, Tony Fox, Tonytypoon, Treisijs, Tutmaster321, UninvitedCompany, Urbanette, Vald, Velho, Visual risk management, WadeLondon, Warpfactor, WaysToEscape, Wemlands, Wikiklrsc, Wikomidia, Wood Thrush, Woohookitty, Wordsmith, Wtmitchell, Xyzzyplugh, Yamamoto Ichiro, Z10x, Zaggernaut, Zara1709, Zodon, Zzyzx11, 343 anonymous edits Audit Source: http://en.wikipedia.org/w/index.php?oldid=366936902 Contributors: .digamma, 74s181, AACCAA 3-2, Adriaan, Afshinmanesh, Aikclaes, AlMac, Alansohn, Aleksd, Andrewa, Andy M. Wang, Angela, Anna Lincoln, Apparition11, At close range, Auditrix, Balloonman, Bbyluvzmee, Bobmack89x, Bobo192, Bookinvestor, Brigitte sim, Bryanhall, C mon, CALR, Can't sleep, clown will eat me, Charles T. Betz, Cjohnzen, ClaesG, Clicketyclack, Commander Keane, Corp Vision, Craig.parylo, Crzrussian, Cyberbytes, Czalex, DHN, DSRH, Da Joe, Danfredinburg, Dangherous, Danmagreen, David Gerard, Dendodge, DennisArter, Dherbinet, DirectEdge, Dpr, DragonFury, Drewwiki, Echuck215, Ed Fitzgerald, Ejjazaccountant, Eloquence, Ency, Faheem84, Fakhtar84, Famspear, Far Beyond, Filelakeshoe, Firsfron, Floridi, Flowanda, Fraudy, GazMan7, George Mel, GillesAuriault, Gilliam, Glennfcowan, Glennfitzpatrick, Gogo Dodo, Granpuff, Gregalton, HamburgerRadio, Hamtechperson, Haoie, Harimore, Helbit, Hu12, Inwind, Ixfd64, Jackson7, Jcoveney1, Jepulliam, Jmglee, Joseph Solis in Australia, Joy, Karl-Henner, Kazuhiro suzuki, Keilana, Kentmoraga, Kompere, Kuru, Kyng, Kzhang, Lewislams, Liftingbig309, Litoncd, Lsuacner, LtNOWIS, Lukobe, MER-C, Marek69, Marymary, Mcelmurry, Mhilvoorde001, Michael Hardy, Minimac, Mintleaf, Miquonranger03, Modelwatcher, Mohammed Tawfik, Mr. G. Williams, Mr.Z-man, Mtmelendez, Mulligan's Wake, Müslimix, N8rc, Nehrams2020, Neo-Jay, Nfhaqiqi, NicM, Nick C, Nikhilpatlolla, NilssonDenver, Nposs, Ntse, Nubiatech, Ohnoitsjamie, Paramountpublishing, Pleci, Postara, Powzhao, Ppntori, Quality advisor, RainbowOfLight, Reinyday, Rich Farmbrough, Richard D. LeCour, Rlevse, Ronabop, Ronz, Rsokhi, SPUI, SchnitzelMannGreek, Sean D Martin, Seattleu542, SebastianHelm, Shadowjams, Shantavira, Shedwidow, Sholto Maud, SirIsaacBrock, SivaneshR, Slp1, Spalding, Special-T, Srsaqib, Stumps, Subsolar, Superzohar, Swinnow16, Syyedzada, T4, THJames, Teetery, Template namespace initialisation script, TheNewPhobia, Thedjatclubrock, Themisterbungle, Thomasmack8, Twirligig, Urzadek, Vzambrano, Wallstreeter, Wiki Kedar, Wikipediatrix, Xandi, Xhosan, Yakudza, Yaxi, Yhabibzai, ‫دمحأ‬.‫يدماغ‬.24, ‫ينام‬, 334 anonymous edits Consultant Source: http://en.wikipedia.org/w/index.php?oldid=367615121 Contributors: 04182000trenton, 16@r, Abe Lincoln, AbsolutDan, Adrest4, Alansohn, Albertod4, Andrew sturdy, Andrewsurtees, Anlagan, AstroMark, Babbage, Banes, Barnetsl, Bobblehead, Bodnotbod, Borgx, Bozo888, Cash4187, Ccrawford, Cheerycopyeditor, Corpx, Corti, CountNihilismus, D.h, DDerby, DaniRoisman, DanielPenfield, Dave6, DavidWBrooks, Davidandrade, Ddlamb, DireWolf, DocJohnny, Dogah, Dominics Fire, Douggers, DrBob, Dub8lad1, Dysepsion, East wtch, Eekerz, Fabrictramp, Firien, Folajimi, G716, Gcorbaz, Gdifc, Gzkn, Howardjp, HtownTX, Ingolfson, JTN, Jmcc150, Jobshoppinfool, John24601, Johnlogic, Jonny-mt, Jpbowen, Just zis Guy, you know?, JzG, Katarina1, KingAlanI, Krallja, Kraybilr, Kuru, La goutte de pluie, Lbbzman, Lee J Haywood, Libcub, Luk, MCB, Maildheepak, Mamawrites, Maneau, MarkBrooks, Martarius, Mcengineer, Meelar, Melesse, Mellissah, Meltonkt, Michael Zimmermann, MikeLHenderson, Mondez Durden, Msundarraj, Muchness, Mwanner, Nakedjuice, Nixdorf, Olegwiki, PaulHanson, Pavel Vozenilek, Pgreenfinch, PhilKnight, Placebo overdose, Princeton, Priyatu, Purple Banana, Rayraytaylor, Rico402, Rje, Rjwilmsi, Rmosler2100, Roc, Saachconsultants, SchmuckyTheCat, Shahidshoaib, Shantavira, SimonP, Singhalawap, Soggydave, Steve Alvesteffer, TastyPoutine, Th1rt3en, TheBackpack, Thparkth, UberScienceNerd, Umesh1981, Valkian, Vandal!, Vinograd19, Vistadivine.com, Vortexrealm, Wgoetsch, WikiBizness, Yensin, 198 anonymous edits Strategy Source: http://en.wikipedia.org/w/index.php?oldid=363872300 Contributors: Aaron Kauppi, Addshore, Aff123a, Ahoerstemeier, Ailin82, Alansohn, Alberta74, Alexandru Stanoi, Allen Moore, Alynna Kasmira, Ancheta Wis, Andreas Kaufmann, Andrewpmk, AndriuZ, Andrus Kallastu, Antandrus, AntiWhilst, Appicharlask, Aree, Arjuna909, ArkinAardvark, Avalon, Avmanzo, AxelBoldt, Beyond My Ken, Boatearth, Bongwarrior, Borgx, Brick Thrower, Bryan Derksen, CALR, Calane83, Can't sleep, clown will eat me, Chewie, Chris Mason, Chris_mahan, Ckatz, Conversion script, Cretog8, Daniel11, Danielfarber, Darrel Stadlen, Davejblair, Doppelgangland, Dorit, Dreadstar, ElixirofLife, Elkadi, Elkadio1, EnSamulili, Enirac Sum, Exemplar sententia, Exeunt, Extar, Fbooth, Filos96, Firebird2k6, Frecklefoot, Frisco21, GOV, Gaslan2, Gdr, Glenn, Goodoldpolonius2, Greudin, Gökhan, Harvard85zx, Hashar, Hcberkowitz, Hu12, IW.HG, Ian Drysdale, Idegmcsa, Imacosta, Infarom, Ixfd64, Izno, JaGa, Jayantaism, Jayhands, Jaysweet, Jeff3000, Jim62sch, Jkhanfer, Johnwaterman, Joong-gun14, KeithD, Kevyn, Khalid hassani, Kirill Lokshin, Kl4m, Krator, Kuru, Lachambre, Ladii Kiima, LeaveSleaves, Lelapindore, LilHelpa, Loren.wilton, Lotje, MER-C, MacGyverMobile, Macguba, Manscher, Marek69, MartinTurner, Mats 718, Maxim0815, McGeddon, Michael Angelkovich, Mike Cline, Mkoval, Monishasarkar, Monkey Bounce, Mormegil, Mr. Billion, Muchness, Mydogategodshat, Namtiota, NawlinWiki, Nick-D, Old Moonraker, Omegapowers, Ooga Booga, Paradigm68, Passandid, PatrickFlaherty, Pearle, Prof 7, Prupitto69, RHaworth, RN, Ralfipedia, [emailprotected], Richphil, Rinconsoleao, Rockfang, Ronz, Royote, S0crates9, Sandstein, Sjö, Smalltalkman, Smmurphy, Spitfire, Stefano, Stevenwagner, Stevertigo, Stormj, SueHay, SummerWithMorons, Surfdachsie, SvenAERTS, Swaq, Tazmaniacs, The Rambling Man, TheGrza, Thseamon, Tide rolls, Timo Laine, Tobycat, TreasuryTag, Trident13, Truman Burbank, Ulflarsen, Van helsing, Veinor, Versageek, VictorAnyakin, Vivek.raja22, West81, William Avery, Wortafad, WpZurp, Yerpo, Zhenqinli, Zyaar, Александър, 264 anonymous edits Project manager Source: http://en.wikipedia.org/w/index.php?oldid=367294623 Contributors: Aff123a, Akalanaki, Alexolson, Antandrus, Bhalchandratk, Blair Sutton, BrainyBabe, Chowbok, Chris Roy, Cleduc, Cloud10pm, Co1Spain, Dandriani, Deville, Digitric, Dineshasewwandi, Discospinster, Dlohcierekim, Dogears, Eeekster, Ehheh, Enviroboy, Ff1959, Ft1, Globalprofessor, Graeme Bartlett, Haikon, Heron, Hgfernan, Hoof Hearted, Hubertus, Huffry94, IMsupersmith, Iridescent, Jagra, Jazzy Diva, Jcampsall, JensenDied, Karmona, Keith Biglin, Keith Richards UK, KimBecker, LeonMichaelSmith, Luna Santin, MQuinn, Mdd, Mentifisto, Mfo321, Michelle2mmb, Mkoval, MrOllie, Mtcedar, Muazen, Nankivel, Nazmanager, Od Mishehu, Oicumayberight, Ojophoyimbo, Piano non troppo, PingPongBoy, Ploum's, Pm master, RJFJR, Richi, Richieman, Rillian, Rundquist, S.K., Saber girl08, Sean Whitaker, Shanes, Sisalto, Stevenmitchell, Synique, The Thing That Should Not Be, Thebluemanager, Travis99, Vavilen, Vincehk, Voldemortuet, Wdyoung, Wik, Wiktoria, Wndola, Wtmitchell, Zigger, 156 anonymous edits Project management triangle Source: http://en.wikipedia.org/w/index.php?oldid=358070889 Contributors: Bahnemann, ChildofMidnight, EdHubertson, Gsmgm, Intgr, Mdd, Mr pand, 4 anonymous edits Work breakdown structure Source: http://en.wikipedia.org/w/index.php?oldid=366254295 Contributors: 0.39, A bit iffy, Addshore, Aeon1006, Agatlin, Ahoerstemeier, Ap, Art Carlson, Axxgreazz, Belovedfreak, Bluesguy, Bonadea, ChristopheS, Ciphers, ComputerGeezer, Conversion script, D, D6, Dekisugi, Dr PDG, Equendil, Erkan Yilmaz, Ewlyahoocom, Fld300b, GABaker, Garrybooker, Ghaag, Graham87, Greenmind, Greyskinnedboy, Hmains, Ixfd64, JCarlos, Jazzy Diva, Killiondude, Kku, Limejello, LizardWizard, Lotje, Lova Falk, Luftikusss, Lycurgus, Madvenu, Mario777Zelda, Mastercko, Mauriciojxs, Maurreen, Mbarker, Mdd, Michael Hardy, Mkoval, Mm2720, Mogsie, Monkey Bounce, Mydogategodshat, NathanBeach, Naudefj, Neelix, Nixdorf, Nixón, Plrk, Pm master, R'n'B, RTC, Rafael Pi, Reconsider the static, Rjwilmsi, Robomanx, RossPatterson, Rwflammang, Salvatore Ingala, Sarahbei, Seb az86556, Semperf, SimonP, SmartGuy, Spandrawn, Svick, Technoparkcorp, Thebluemanager, Thopper, Tojulius, Ukexpat, Verne Equinox, Viky m, Vincehk, Volphy, Woohookitty, Yamamoto Ichiro, 208 anonymous edits Contract Source: http://en.wikipedia.org/w/index.php?oldid=367353351 Contributors: 1sunflower, Acroterion, Adam Brink, Aesopos, Aitias, Aksingh11, Alansohn, Alex756, Alsee, Altenmann, An, Andres, Andrewttm, AndyJones, Andycjp, Angela, Angr, Antonielly, Anwar saadat, Appleboy, Arbeit Sockenpuppe, Arc Force, Aripap, Astronweb, Atosecond, Austenba, Australian law academic, B4hand, BD2412, Babadong, Baby Jenga, Bachrach44, Bamkin, Barek, Bbtommy, Bejnar, Bencherlite, Bernburgerin, Bhuston, BigHairRef, Bjslaws, Bkell, BlueGroup, Bluemoose, BobKeim, Bonadea, Bubbli 341, Bundas, Buzz-tardis, CRGreathouse, Cactus.man, Cadking3, Caltas, Can't sleep, clown will eat me, CanadianLinuxUser, CapitalR, CaseyPenk, Causa sui, Cburnett, Cdogsimmons, Centrx, Cgiakmoz, CharlotteWebb, Chart123, Chicken Wing, Chrisglew, Closedmouth, Complex01, Computer97, Conversion script, Coolcaesar, CrashingWave, Cretog8, Csamuels, Culverin, Cutler, CyborgTosser, DUBJAY04, DaGizza, Dale Arnett, Danamania7, Dantheman531, Darth Panda, David Newton, David91, Deror avi, Dgies, Discospinster, Dostal, Dreamword, Drilnoth, Dstebbins, Duffman, Dying, EECavazos, EagleFan, Earth, Eastlaw, Ed Fitzgerald, Ed g2s, Edcolins, Edward, Eep², EinB567, El C, El Zoof, Elliotreed, Enochlau, Espoo, Evilgeniusinblack, Fairview2008, Flewis, Fogster, Foofighter20x, Fortheloveofgob, Franamax, Francis Davey, Frans Fowler, Freechild, Funandtrvl, Funda62, Gaius Cornelius, Galestar, Gilliam, Gly, Gogo Dodo, GraemeL, Gragggtyh, GreenReaper, Greensburger, Guanaco, Gurch, Hairy Dude, Half japanese half french, Hraefen, Hu12, Hydrogen Iodide, Iainscott, Iamthenewno2, Ianwashere, Icarus3, Ichor trust, Ihope127, Imnotminkus, ImperfectlyInformed, Insanity Incarnate, Iridescent, Irish goat, IvanLanin, J.delanoy, JEG, JHMM13, JHVVax, JLMadrigal, JPG-GR, Jagged 85, Jeff3000, Jessica1994, Jfeckstein, Jhooversnyder, Jigordon, Jinnai, Jkcpop, Jklamo, JohnI, Jonathanstray, Josh.anders, Juliancolton, Jum-interw, Jusjih, Jwestland, Kara sutton, Katr67, KeithD, KickahaOta, Kms, L33th4x0rguy, LEENA23, Laganuk, Lambiam, Lawcatalog, Lawdroid, Lawlisaliu, Legis, Leuko, Levineps, LeyteWolfer, Lion for truth, Lisatwo, Lostinalaska, Lupin, MBisanz, Mac, Mallocks, Mandarax, Manu bcn, Marc Venot, Marcinjeske, Mark Ryan, Martynas Patasius, Matt Fitzpatrick, Matthew Proctor, Mayder529, Mcdennis13, Meegs, Meelar, Mentifisto, Mharki16, Michael Hardy, Michael Okolo, MichaelSchoenitzer, Minerva WM, Mladifilozof, Mmmbeer, Morshem, Mrdthree, Mrpex, Musiphil, Naddy, Nagyve, Naudefj, Nbarth, Netesq, Neutrality, NewEnglandYankee, Nibuod, Nichetas, Nick Levine, Nickofall, Nilmerg, Non Curat Lex, Nopetro, Nuance13x, NuclearWinner, Nudecline, Ocee, Ohnoitsjamie, Ojl, Olegwiki, Omicronpersei8, Otolemur crassicaudatus, OwenX, Patrick, Paul foord, Persian Poet Gal, PhJ, PhilKnight, Philstarkweather, Piano non troppo, Potet, Psycho Kirby, PullUpYourSocks, QuantumEngineer, R'n'B, RainbowOfLight, Rama, Rconnell, Rfc1394, Rfc26, Rich Farmbrough, Rjwilmsi, Rlsheehan, Roadrunner, Robb0082, Ron Ritzman, Rtiact, RussBlau, Ruth Baillie, Ryan, SWAdair, Sam Hocevar, Sardanaphalus, Sauve.d, Scarian, Scatchel, Scientizzle, Seba5618, Semigoth101, Shadowjams, Shanerobins, Simetrical, SiobhanHansa, Sjö, Sligocki, Smallman12q, Snaxorb, Snoyes, Speedoflight, SpeedyGonsales, Sroone89, Stephen G. Brown, Stronger03, Stwalkerster, SueHay, SuedInfo, Suto, TallMagic, Talltim2, Taxman, Thatdog, The Thing That Should Not Be, TheShadow94, Thunderbolt16, Tom, Tom harrison, Toytoy, Tragic Baboon, Trainra, Trotter, Txwikinger, Ukexpat, Unyoyega, Vald, Vanakaris, Vapier, Varbas, Velho, Vincent Vecera, WalterWolli, West Brom 4ever, Wiki-Man, Wikidea, Wikieditor1988, Wikirocks123321, Wknight94, Wmahan, Woer$, Woohookitty, XQx, Yedhulaprakash, Yeu Ninje, YusrSehl, ZachPruckowski, Zannah, Zorro CX, Île flottante, 631 anonymous edits

505

Article Sources and Contributors United States Department of Veterans Affairs Source: http://en.wikipedia.org/w/index.php?oldid=361917232 Contributors: AEMoreira042281, Adam Chlipala, Ageekgal, Akulo, AlbertHall, Aleenf1, Andy Marchbanks, Armadillot, Assed206, Avdo, Avram, Awg1010, Bdcheung, Bkonrad, Blehfu, Brainyiscool, Brandon39, Briaboru, Cander0000, CanyonChaser, CapitalR, Capricorn42, Chief of Staff, Chromatikoma, Closedsaturday, Closetfire, Coemgenus, Computerjoe, CoolGuy, CoolKid1993, Coolcaesar, Cvieg, Cybercobra, D6, DHeyward, DRosenbach, Dancter, Danlohaus, Davemcarlson, DavidLevinson, Diltsgd, Discospinster, Dmosher825, DragonflySixtyseven, Eastlaw, Echo927, Edivorce, Epolk, Evrik, Fanra, Fintler, Flewis, Flyguy33, Fraker, GearedBull, Glloq, Ground Zero, Gzuckier, HJ Mitchell, Hcheney, Hltarr01, Hoshie, Hughey, Hugo999, IPAddressConflict, JNW, Jaan513, Jen1026, Jengod, Jeronimo, Jfknrh, Jfruh, Jiang, Jmrider350, Johnron007, Js2081, Jsum, Jwyndelts, Kevlar67, Khoikhoi, Kingpin13, Kkmd, Knacksac, KristoferM, Levineps, Lightmouse, Looper5920, Lukobe, Markles, Minesweeper, Mkamensek, Motthoangwehuong, MrKIA11, MrOllie, Mt91403, NawlinWiki, Necrothesp, Neutrality, Nobunaga24, Ohconfucius, Parsecboy, Pearle, Perspectoff, Postdlf, Redthoreau, Rentaferret, Retanollo, Rich Farmbrough, Richard75, Rigadoun, Rlquall, Rougher07, RxS, Sardanaphalus, Shanes, Sidonuke, Sjrsimac, Slo-mo, Smking1, Smug Irony, Stephan Leeds, Steven Weston, SusanLesch, Symon Perriman, TCY, Tb, Template namespace initialisation script, Tggf1944, Thewinchester, Tim1965, TommyBoy, Tschow, VegasScorpion, Vet58, Wafulz, Wang65, WatchAndObserve, Wikibofh, Wikipelli, William Avery, Ybbor, Yellowdesk, Zereshk, 218 anonymous edits A Guide to the Project Management Body of Knowledge Source: http://en.wikipedia.org/w/index.php?oldid=354310241 Contributors: Akbradford, Amorymeltzer, AxelBoldt, Baser5nature, Bobo192, CALR, Chowbok, Cleancleaner, ComputerGeezer, Creaturosis, DSP-user, Darehauf, Davidjosparcom, Dichter, DoriSmith, Elainelazar, Elen of the Roads, Elena1234, Elwikipedista, Emadmust, Fredrick day, FreplySpang, Gloy, Goethean, Gpdemarco, Greyskinnedboy, Gunnala, Hady79, Ilee, Jc3, Jimiadegbite, JohnGardnerCMC, Jtblakely, Kaisersoze1, Karthikeyaans, Kcone, Ketiltrout, Khalid hassani, Kstarsinic, Kuru, MCB, Makingprogress19, Mbesaiso, Mdd, Mkoval, Mmpubs, Mr.microwave.omelette, MrOllie, Mydogategodshat, Ninadelis, Niteowlneils, Nunquam Dormio, OS2Warp, Oberobic, Oblomoff, Orangemike, Pink Bull, Pm master, Polyextremophile, Rabit gti, Randomtime, RedWolf, Rich Farmbrough, Richman9, Rjackchapman, Rugops, Rule 42 of the code, Sbullman, Sketch051, Skomorokh, Slant, SmartGuy, Solarapex, Spalding, Speck-Made, Tekkes, The Epopt, Toddwill, Weregerbil, Wspencer11, Y, 105 anonymous edits Capability Maturity Model Source: http://en.wikipedia.org/w/index.php?oldid=367467111 Contributors: 1yesfan, 209.239.198.xxx, AMackenzie, Adashiel, AlexAnglin, Altanevni, Ancheta Wis, AndriuZ, Anirudhjain22, Anshuman singh, Anthony Appleyard, Ap, Arthur Rubin, Ash, AutumnSnow, Beasposadas, Beetstra, Beland, Benandorsqueaks, BertK, Billcurtis33, Bjelleklang, Bjmurph, Bobbis, Bobo192, Boing! said Zebedee, Cander0000, Canterbury Tail, Charles T. Betz, Cherfr, ChrisGriswold, Colin Marquardt, Conan, Conversion script, Coolie 15, Cpl Syx, CuddlySteve, David Biddulph, Dcooper, Delldot, Dgies, Diberri, Djdaedalus, Dmccreary, E. Ripley, Ed Poor, Eigenwijze mustang, Espoo, Evil Monkey, Evkeel, Excirial, Favonian, Flamurai, Fuzheado, Gaius Cornelius, Ghorbanalibeik, Goltz20707, Gregbard, Greyskinnedboy, Gurch, Harald Hansen, Hardyplants, Hari, Hbachus, Hephaestos, Herbee, HiEv, Iain99, IainB, Intray, It afzal, IvanLanin, Jclemens, Jdlh, Jeff3000, Jeroen94704, JethroElfman, Jim McKeeth, JimYuill, John a s, JonnyJD, Jose Icaza, Joyous!, Jpbowen, Jsub, Keesiewonder, Kelemendani, KentAaronJohnson, Kernel.package, Khalid hassani, Kuru, Kurykh, Kwsn, Lcawiki, LeadSongDog, Ligulem, Losat, Loshsu, M.e, Madhero88, MarkMascolino, Matias.Reccius, MaxHund, Mcsboulder, Mdd, Merlion444, Michael Hardy, Michig, Mila.cridlig, Mipzter, Mkoval, Mondo, My7dream2002, Myanw, Nlu, OS2Warp, Overix, OwenX, Palica, Pangloss, Pearle, PhilHibbs, Pmtoolbox, PradeepArya1109, Pratheepps, Pwforaker, RainbowOfLight, Ralberts, Ray Van De Walker, Reedy, Rjwilmsi, Rodparkes, Ron Richard, Root1984, Rufus210, Ruud Koot, Ryjaz, S2000magician, SEI Publications, Sam Hocevar, Sandyshrum, Shryane, Sj, Smalljim, Snakeeee, SomeStranger, Station1, Struway, StuffOfInterest, TBrianJ, THEN WHO WAS PHONE?, Tagishsimon, Teryx, Texture, Tobias Bergemann, Tom.k, Truthanado, Tvarnoe, Twhoffman, TwoSeven, Unixxx, Unyoyega, VARies, VMS Mosaic, Vald, Vasanthdiggs, Vikraman23, Vishal1873, Walter Görlitz, Widgetkid, WikHead, Wikid77, WillMcKnight, Wugwug, Xodarap00, Xsmith, Zbeckman, Ziggurat, Zzuuzz, 792 anonymous edits ISO 9000 Source: http://en.wikipedia.org/w/index.php?oldid=367770314 Contributors: 199, 9000store, A D Monroe III, A12n, A8UDI, AEMoreira042281, AbsolutDan, Achromatic, Adamrush, Ahoerstemeier, Aitias, Ajb, Ajfoley, Al Silonov, Alansohn, Aledeniz, Alkazzi, Alm810, Andre Engels, Andrewpmk, Arauzo, Arendedwinter, Ashley Y, Ashwellthorpe, Atif.t2, Avs5221, BBird, Beefy SAFC, Beland, Bevo, Bill, Bletch, Bobo192, Bradjamesbrown, C'est moi, Cabmille, CatherineMunro, Cbuckley, Charles Matthews, ChinaUpdater, Chris 73, ChrisMorgan, Chrishomingtang, Closedmouth, Cometstyles, Cparis3, Createaccounttostartnewarticle, CreativeThinker, Crossmr, D6, Da monster under your bed, Dalric, Darrylv, David Gerard, David Humphreys, DavidSturt, Davidmack, Dbaabaa, DeadEyeArrow, Deed02392, Delldot, Deltaker, Dennisthe2, DetlevSchm, Discordian, DocWatson42, Dotx3, Doulos Christos, E-pen, E-shoq, ESkog, Ed Poor, Ehusman, Elwikipedista, Eraserhead1, Eric-Wester, Excirial, Explicit, Faithlessthewonderboy, FiggyBee, Fish and karate, Fuhghettaboutit, Fæ, Gail, Gcman105, Gejigeji, Geoff NoNick, Gerbrant, GermFree, Golan77, Gorman, Gpermant, GregorB, Gregzeng, Gurch, HBowie, Haeleth, HaiyaTheWin, Harish431, HerbFirestone, Hereticam, Hoponpop69, Hughch, Hultgreen, I already forgot, ILike2BeAnonymous, Ich, Inwind, Iridescent, J. Spencer, J.delanoy, J04n, JHunterJ, JIP, JNW, JRDarby, JaGa, JamesAM, Janebirk, JavierMC, Jaxad0127, Jayen466, Jeffmcneill, Jeffrey Sharkey, Jenny Wong, Jim Wade, Jj137, JmbYx13, JoanneB, John of Reading, Johnwalz, Jonysebastin, Juliamnaneeh, K-car, Kaihsu, Kale Weathers, Kjetil r, Kocio, Koochekhalvat, Kribbeh, Krsinghal, Kuru, Kvorakir, La Pianista, Lewis C Conquer, Lewis Conquer, Lockoom, Luckiesdaidai, Madir, MapsMan, Marc T Smith, Markhurd, Markus Kuhn, Martarius, Matt Whyndham, MaxHund, Mditto, Mean as custard, Meetjcm, Mehtalk, MementoVivere, MiNombreDeGuerra, Michael Hardy, Mike Schwartz, Mindzai, Mjpieters, Monkey Bounce, MosheMoshe, MrDrBob, MrOllie, Mxn, Mydogategodshat, Müslimix, Nasa-verve, Nchamcham, Neggiem01, Neilc, Newone, Ninly, Nixdorf, No1lakersfan, Noliver, Olivier, Oneiros, Orlady, PJLHowell, Paulius.sky, Paulthegadget, Paxsimius, Petya357, Phil Boswell, PhilKnight, Philip Trueman, PhilippeAntras, Phyzome, Piano non troppo, Piercetheorganist, Ploum's, Polkdots, Pps, Prainog, Qualitytimes, Qxz, R Ramamurthy, RJASE1, RTC, RadiantRay, Radon210, Rajendra p, Ratarsed, Reach Out to the Truth, RhondaCH, Rich Farmbrough, Rillian, Rjwilmsi, Rlsheehan, RobbWiki, Robfenn, Roderick A Munro, Ron Richard, Ronhjones, RoyBoy, Rrburke, Rror, Sabory, Salam32, Scarian, Skarebo, Smyth, Snydale, Spangineer, Species8473, Spitfire, Ssqmi, Stan J Klimas, Stevage, Stifle, Tbhotch, Tew, The wub, Thequality, Thirdgen, Thryduulf, Tide rolls, Tim Parenti, Tobias Conradi, Tordek ar, Tree99, Trenwith, Univer, UnneededAplomb, Vermooten, Warnborough, Wickifrank, Wiki alf, Wissons, Wtshymanski, Wuhwuzdat, Wwwwolf, Xkcd, Zatoichi26, Zaui, Zfr, 799 anonymous edits ISO 10006 Source: http://en.wikipedia.org/w/index.php?oldid=346832036 Contributors: A. B., BonsaiViking, Drbreznjev, Kate, Koochekhalvat, Meeples, Mkoval, Mxn, Nasa-verve, Oblomoff, Phil Boswell, RedWolf, Sam Korn, Tobias Conradi, Zundark, 15 anonymous edits Total cost management Source: http://en.wikipedia.org/w/index.php?oldid=350893770 Contributors: Jkhcanoe, Mdd, Pichpich, 2 anonymous edits The International Association of Project and Program Management Source: http://en.wikipedia.org/w/index.php?oldid=362893853 Contributors: Addere, Barticus88, Bobjeffbob, Dekisugi, [emailprotected], JIP, Jaypc6711, Rich Farmbrough, Widefox, 9 anonymous edits V- Model Source: http://en.wikipedia.org/w/index.php?oldid=361565746 Contributors: Abdull, Absentmindedprof, Andreas Kaufmann, Ben Standeven, Berny, Chilin, ComputerGeezer, Cybercobra, Download, Edliversidge, Ejs-80, Elwikipedista, Erkan Yilmaz, Farquaadhnchmn, Faught, Fordmadoxfraud, Frankie816, Gnusbiz, Greghc, Grenavitar, Guts0glory, Homebythesea, IMattUK, J04n, Jamelan, Joelm, Joyous!, Kevin1390, LilHelpa, Loren Architzel, M ajith, Maxberger, Mdd, Michig, Optimale, Radiant!, ShashClp, Slashme, Svick, Volphy, Vwm, Zash2k500, 61 anonymous edits Project portfolio management Source: http://en.wikipedia.org/w/index.php?oldid=363006156 Contributors: 1400degrees, Allan McInnes, Appraiser, Arunram, BinaryTed, Brad101, Clarkdd, Cliff2311, David.cote, Demiane, DivineAlpha, Dpm64, Edcolins, Edolee, Etackabery, Fbossuyt, Florent1024, Forestsmith, Franz D'Amato, Fuhghettaboutit, Gaius Cornelius, Haig, Hede2000, Hjassad, Hu12, Hubbardaie, Isismarketing, J.delanoy, JNW, Jaypc6711, Jpbowen, Kinu, Kuru, Lika2know, Mdd, Michael Hardy, MrOllie, Pearle, Pm master, Polyextremophile, Price666, Psmcguin, Rich Farmbrough, RichardDenney, Rinconsoleao, Rlolsen, Sandymok, Serein (renamed because of SUL), SurfAndSwim, Thadius856AWB, The Anome, Thesquire, Tilleyg, Welsh, Wrjbrown, Ylebihan, 47 anonymous edits Glossary of project management Source: http://en.wikipedia.org/w/index.php?oldid=356062915 Contributors: Alan Liefting, Chowbok, Edward, Grafen, J04n, JaGa, Jevansen, Mdd, Mild Bill Hiccup, Saighe, Sarich Bes, Whitelilacs, Woohookitty, Yendor1958, 9 anonymous edits List of project management topics Source: http://en.wikipedia.org/w/index.php?oldid=366048192 Contributors: 0.39, Alpha0, AndrewStellman, Aranel, Barticus88, Benaventeperezcarlos, Bonadea, Christopherlin, Cmprince, ComputerGeezer, DSP-user, Docu, Elementsoftware, Ernst.schnell, GFLewis, Garrybooker, Greyskinnedboy, Gsaup, Heirpixel, Hipocrite, [emailprotected], Ironwolf, James pj, JeffW, JesseW, John Richard Parker, Johnbibby, JonHarder, Jrugordon, Just Another Dan, Karl-Henner, Kenmckinley, Khentiamentiu, Kundankishor, Kuru, Lanoitarus, Manop, Markbassett, Mdd, Meelar, Mkoval, Mplemmons, Mugunth Kumar, Mydogategodshat, Neparis, Nikai, Niteowlneils, Nixdorf, NuclearWarfare, O18, Proliance, Quiddity, Raghunathan.george, RedWolf, Renebach, Retired username, Rossinglish, Rwil02, Saighe, Scjnsn, Semera, Siddhi, Simon South, SimonP, SmartWorks, Smartaccord, Stevenwmccrary58, The Transhumanist, TheRealFennShysa, Tirkfl, 60 anonymous edits Comparison of project management software Source: http://en.wikipedia.org/w/index.php?oldid=366977405 Contributors: 3thirdsawake, Aalbersberg, Abware, Activefocus, Adammetz, Aferistas, Agencius, Agerskov, Agujero Negro, Ahmerzaidi, Airtodo, Akisora33, Alexpb, Aliasd, Aliby, Almerica, Alpha0, Alphamu57, Als12171, Altenmann, Altonbr, AnandKumria, Anas2048, Andy.goryachev, AngellpPezzullo, Anon2, Anshu Banchhor, Antonmind, Antonyslumbers, Apotvin, Aqeeliz, Argey, Arkaydo, Arsm2, Artem Karimov, Asa1212, Asadabutarif, Ashiro, Ashleych, Assistancetubby, Astadev, Athani, Az944racer, Babynus, Balajikannan, Balkbalk, Barconati, Bathizte, Batsonjay, Beedub81, Biljana123, Bill Conner, Bjackal, Bkeech, Bkormoski, Blacksqr, Blanchardb, BlindzeroMUC, Bluesmangp, Bmcmichael, Bmg916, Bmwzpower, Bonadea, BorgQueen, Bphenry, Brewsterfl, Bruce aylward, Brucecarley, Bsanders246, Bsjut, Buraks78, Bvelasquez, CAkira, CSOWind, Calebgu, Captone, Caseydk, Cdamian, Celoxis, Cftopper, Chemuturi, Chillidemon, ChrisCork, Christopher Kraus, Ckkung, Clemparreira, Compulink, Corvus cornix, Cpetty-wiki, Craiggolby, Csh74, CyberSkull, Cyberguild, Cygnuz, D.scain.farenzena, Damir Zakiev, Dancter, Danielhegglin, Danielsten, Danmackey, Danroa, Darrelljon, Darth NormaN, Daxfdr, Deb4mail, Denistorres, Dheerajsingh9, Diaa Sami, Digitallattice, Digiteanalytics, Dinohung, Disarea, Dkg, Dneades, Doriancollier, Doroli, Dos2windows, Dougdclark, Drbreznjev, Dreadpal, Drilnoth, Drunisine, DuLithgow, Dvansant, E-cuellar, EasyProjectPlan, Edolee, Ejay2524, El C, Elementsoftware, Emar2410, Endeavour-mgmt, Enricolinder, Epimienta, Etackabery, FAdolfsson, Fgodbout, Filipe1976, Firien, Fj marcin, Flindgren1, Fplant333, Fraber, Francesco69, Fred Bradstadt, Freewind999, Ftiercel, Fvw, GabrielToader, GastonPowered, Gavin White, Geniusinside, Geometrixx, Geovanim, Gerardvschip, German.lutoff, Geschichte, Gheorghiu alex, Gil.shabtai, Gk07, Gkarapet8, Gmesaric, Goodespeler, Goran.radulovic, GraemeL, Greenman, Greenworldisbetter, Gtilley, Gulli, Guyjohnston, Haakon, HarveyKandola, Hatter87, Havlatm, Hchampoux, Heavy66, HeronOfAlex, Hhielscher, Hidachi, Hm2k, Hmwith, Hu12, IT249, Ian13, Ibroom, Ihreborn, Ilipner, Im nessie, Indon, Inightmare, Intersect, Invererth, Ioeth, Irishguy, IsmaelLuceno, Ivansanchez, JForget, JLBSD, Jack Merridew,

506

Article Sources and Contributors Jackdragon17, Jackvinson, Jainvinay04, Jakobam, Jandockx, Jasmineisten, Jasontrend, Jatkins, Jbolden1517, Jefersonsilveira, Jerryjacobson06, Jgw, Jiffy wu, JimHu, Jimdoria, Jlangos, Jlneto, Joe Ericsson, JohnCD, Johnbibby, Johnjreeve, Jonimueller, Jonny.dee, Joostvanwieringen, Jordiferrer, Josh Parris, Joshuafrappier, Jstride, Jusperstb, JzG, Kahlvin, Karkywo2008, KarsKormak, KasperTA, Kaster, Kbehzad, Keakealani, Kelapstick, Kenmckinley, Ketaros, Kevbo11, Khadimnaby, Khar khar, Khar khar78, Kimchi.sg, Kindrosker, Klandies, Korath, Kornovol, Kuramei, Kuru, Kvskumar, Kylekeller, LaurieA2, Lbecque, LeadWithoutTitle, Lectonar, Lerkey, Liao, Lionheart2007, Lmxu, Lofor, Longears, LuisWang, M shivaji, MADe, MaartenMostert, Macmillzy, Maconomy, Madhugr, Malon3r, Malt2007, Manop, MarcoTrevisan, MarkBrownlee, Martin.koehn, Master-zzz41, Mats Kindahl, Maxim, Maxis4132, Maxvoltar, Mbells, Mcurty, MeadeRubenstein, Menthepoivree13, Mercer66, Mercuryfrost, Metzgerr, Mhankiny, Michael tf, Michelle118, Michelle2mmb, Michelnass, Michokest, Midnightxp, Mikelito510, Millinet, Minghong, Mironcaius, Misterbojangles2, Mjolnir747, Mjstanton, Mkoval, Mlibby, Mmelchiorre, Mniinioj, Moa3333, MockSoul, MonicaRMiller, Moogsoftware, Mpearson65, MrOllie, Mreithinger, [emailprotected], Mtrompeta, MuffledThud, Myideaoforder, NachoCheez, Nakon, Natalija Trajchevska, Natalija123, Natebowler, Natekontny, Navendu shirali, NawlinWiki, Nbahi15, Nbcruz, Neustradamus, NevilleT, New Thought, Ngenialabs, Ngoult, Nilssondaniel77, Nima1981, Nothando25, Notopia, Oberiko, OdileB, Ojw, Omicronpersei8, On5deu, One2010, Openproj, Oscarguindzberg, Osorin, P4k, P6Manager, PAO33, PAStheLoD, PEZ, PIrish, Painter60, Pappu687, Paragliding2000, Paul M Weiss, Paul W, Paulkaye, Pavel Vozenilek, PepperPM, Perfecto, Peterg300, Peterpvw, Phaethousa, PhilKnight, Philipp-de, Pkchan, Plateforme Xerox, Pm expert, Pm master, Pmjones, Pmlive, Pmtoolbox, Ppmstudio, Ppolsinelli, Ppp extr, Prabhatfunny, Pradeeper, Premiero, Premil, Primasoftware, Priyanky, Projectinsight, Projistics, Proliance, Punklogic, Quelg, RAM WM, RANBerkeley, RHaworth, Rachnzl, Rafdua, Rahulzankar1, Rainerki, Rareview, Ravichandra thalluri, Rblakeney, Rchizzle, Rcrossvs, Renesis, Resurgent insurgent, Revelation8, Rgagne71, Rguillou, Rhallums, Rhayden, Ricky1981, Riverock, Rob Hinks, Roccasaurus, Roger.denton, Rohitsmallya, RossPatterson, Rossinglish, Rostrevor, Rudolf6, Rudrakshvyas, Rundquist, Ruudp, Rwil02, S.K., SOFTPUB, Saighe, Sam1064, Samnorman3, Sandrodc, Sbugs, SchuminWeb, Scjnsn, Scottb1978, Scoutwest, Seanbrokenshire, See7tee, Sequeller, Serge Toper, SharpeSoft, Shnout, Simway, Sir Nicholas de Mimsy-Porpington, Slant, Slapxdiho, Sleepyhead81, Smoldee, Snailshoes, Sndpl, Socrates.Vicente, Sokrates sf, SpaceFlight89, Spartaz, Splash, Stanberka, Standpipe, Starwiz, Sterotz, Stevewest9, Subbu, Suebe, Suhashpatil, Superzidanefighter, Sureshgidugu, SurfAndSwim, Surfinrhino, Suruena, SusanB99, Syedmquader, TC Black Belt, Tarake, Targetprocess, Targetskills, TaskPortal, Taskland, TastyPoutine, TeamDynamixHE, Terence.Hooi, Tfas, TheFlowerKing, TheMile, Thomas.R.Jaeger, Tierra, Tilleyg, TimSheehan, TimmyTreeFriends, Tinygnomesquilt, Tlow57, Tnorth, Tobiden, Tonyonetony, Toobsred, Toppmi, Tracysurf, Trans642, Travelrose, Travis99, Tripter, Truthbro, Tswelch, Tuyen.truong, Tysonb, Utsica, Utuado, VCSonline, Vachdane, ValerieSini, Valerieana, Valleyspeakinc, Vectro, Vikerbandt, Viking67, Viralcraig, Vklimko, WarthogDemon, Wassenama, Watcher in the Clouds, Wdevauld, Wernight, Wga22, Wiki bubble1973, Woodwardjames1, Wpidalamar, Xan2, XenLogic, Xzav, Ybbor, Yesveekey, Yitzle, Yitznewton, Ylebihan, Zacmaninc, Zamees, Zann13, Zannixen, Zeiden, Zeroverse, Zhadina, Zpeed, Zulllus, Zywxa, 856 anonymous edits Timeline of project management Source: http://en.wikipedia.org/w/index.php?oldid=324912687 Contributors: DavidLevinson, DavidWBrooks, Docu, JeffW, Mdd, Mkoval, ProductBox, Tony1, Welsh, Zigger, 8 anonymous edits Portfolio management Source: http://en.wikipedia.org/w/index.php?oldid=355378996 Contributors: Aayushmail007, Az1568, Boleyn3, Carlossuarez46, Centrx, Chocolatecoffee, DDerby, DocendoDiscimus, Escape Orbit, Jyhliang, LeonardoWeiss, Rishsk, Salliesatt, Shawnc, 6 anonymous edits Systems engineering Source: http://en.wikipedia.org/w/index.php?oldid=367162987 Contributors: 0, 208.187.134.xxx, AlephGamma, Alex.muller, Allan McInnes, AndrewHowse, Anger22, Atlasgemini, Attilios, Awotta, Beatrix25, BenBaker, Biblbroks, Bongwarrior, Brianga, Brighterorange, Bwefler, Canadian-Bacon, Cask05, CatherineMunro, Chowbok, Ciphers, CoderGnome, Commander Keane, ComputerGeezer, Conversion script, Ctlucca, DavidLevinson, DerHexer, DiegoTamburini, Digitalmoron, Dlohcierekim, DocWatson42, DwayneP, E.Keegstra, ERcheck, El C, Eleusis, Erkan Yilmaz, Escandeph, Espoo, Evans1982, EverGreg, Famiddleton, Fram, Freedomlinux, Gail, Gaius Cornelius, Giraffedata, Gnusbiz, GôTô, Haakon, Hannes Hirzel, Harzem, Hede2000, Hollnagel, Hongooi, I7s, IPSOS, Imecs, Imjustmatthew, Inbamkumar86, Iterator12n, J04n, Jdpipe, Jeff3000, Jfliu, JoseREMY, Jpbowen, Juren, Kalawsky, Ke4djt, Kelemendani, Kendrick Hang, Kevin.cohen, Kingpin13, Kjenks, Kuru, LarRan, LaughingOutLoudICON, Lexor, LightAnkh, Lightmouse, Louemon, Lttlalb277, LuMorehead, MDSL2005, MME, Mange01, Mark Renier, Mathiastck, Mathmanta, Maurizio.Cattaneo, MaxHund, Mdd, Mecanismo, Mfmoore, Michael Hardy, Mild Bill Hiccup, Mirwin, Misza13, Mjchonoles, Mr.Z-man, Myleslong, NOKESS, Neelix, Nick, Noisy, Normxxx, Patiwat, PaulHanson, Pjvpjv, Plasticup, RJBurkhart, Ravichandar84, Rhoeg, Rich Farmbrough, Rjwilmsi, Rmhermen, Ryan Roos, SE SME, SJP, Sbs9, Scarian, Scottchu, Seaneparker, Selket, Sheard, SlackerMom, Slipperyweasel, SoftwareDeveloper, Sterry2607, SunSw0rd, Super Mario, Susanmacphee, Svick, Sweerek, Swpb, Tarfu92, The Anome, Tintenfischlein, Tobias Hoevekamp, Tonyfaull, Truthanado, Unara, VARies, Veleros, Vincehk, WRK, Weblocutor, Whaa?, Wyatts, 280 anonymous edits Portfolio manager Source: http://en.wikipedia.org/w/index.php?oldid=362110981 Contributors: Cander0000, DanielRigal, Evans1982, Shawnc, Woohookitty, 9 anonymous edits IT portfolio management Source: http://en.wikipedia.org/w/index.php?oldid=365843858 Contributors: 1400degrees, Arpabr, Athaenara, Barrylb, Cbcurran, Charles T. Betz, Cireshoe, Corn Neck, DeadlyAssassin, Dnstrom, Dwbrockway, Edcolins, Forestsmith, Gurch, Haakon, Hervegirod, Hu12, Jainvinay04, Jkaplan143, Jmlk17, Jowanner, Jpbowen, Kukini, Kuru, LOL, Madhava 1947, Malcolma, Mdd, Mgillett, Mnbaqir, MrOllie, Nickmalik, Notinasnaid, Plrk, Pmollins, Poweroid, Reedy, Richard R White, Rlasky, Ronz, Salliesatt, Shajela, Sstaunb, Tedder, Titusmars, TreasuryTag, Yanksox, 62 anonymous edits Human factors Source: http://en.wikipedia.org/w/index.php?oldid=366556776 Contributors: Adam M. Gadomski, Adyar, Aelyan, Alainr345, Alfpooh, Altenmann, Ammalu, Arthurrohan, Benlisquare, BillFlis, Black Pullet, Ciphers, Cnj, Cswrye, DCDuring, DavidLevinson, Dkoya, DoctorW, Dominus, Dreamyshade, Dysprosia, Eagle1711, Eastlaw, Edward, Eptin, Ergolight, Eshaver, Frecklefoot, Fuhghettaboutit, Gary King, Gene Hobbs, Gepwiki, Gulshan12, HFiCS, Harald.schaub, Heimstern, Hugh McLoone, Jamelan, Jaroslavleff, Jj137, Jlstemp, Jomackiewicz, JteB, Just plain Bill, Jwphara, KJie.Neo, KMcGrane, KnockItOff, Kroede, Letranova, Levine2112, Mahanga, Martinevans123, Masoudsa, Mdd, Mel Etitis, Michshin387, Minglex, Motherh, Mtjs0, Myleslong, Nakon, NielsenGW, Nightscream, Nroubal, Oicumayberight, Oo64eva, Optakeover, PatGallacher, Paulmallon, Pavel Vozenilek, Peter Budnick, PetterEkhem, Pmjones, Pnikneja, Pzavon, RJBurkhart, Rani Lueder, Rdmoore, Rikipedia8, Rjwilmsi, Robinsuz, Ronz, RoodyAlien, Royalbroil, SaRSUK, Sandrouille, Saric, SeanGustafson, Sidna, Spalding, Spawnkie, StefanoC, Stephenb, Suilline, Swpb, Teratornis, Themoonisgreen, Thisisbossi, Thorkil9, Tiddly Tom, Tkalley, Tntdj, Tscud, Umeshghosh, Von Mario, Wfu, WhatamIdoing, Winslow Peck, Yamamoto Ichiro, Zian, 174 anonymous edits Earned value management Source: http://en.wikipedia.org/w/index.php?oldid=365771160 Contributors: 4johnny, AbsolutDan, Akerbeltz, Akwaku, Alphamu57, Anderix, Ap, Balloonguy, Beland, BoAman, Bone1213, Busy Stubber, Callophylla, Chowbok, Ckelloug, ComputerGeezer, Conversion script, Deltavictor, Dr PDG, Elwikipedista, Erik.van.ginneken, Espoo, Evolve75, Flowerpotman, Galleman, Garrybooker, Greyskinnedboy, Guilherme.ssilva, Hu12, Iterator12n, Jack4875, JackSchmidt, Jc3, Jluismarin, Jnankivel, Kakyeampong, Ketiltrout, Kundu.anupam, Kuru, Kurykh, LotR, MarshallRAM, Martinig, Matt Whyndham, Maurreen, Mdorohovich, Mindmatrix, Mkoval, Msmitchel, Mydogategodshat, Ojigiri, Owain.wilson, PMDrive1061, PabloStraub, PaulHanson, PerfectStorm, PhilKnight, Pisanond, Pm master, Pmtoolbox, Projectdoctor, RHaworth, Rakesh Poddar, Rami R, Rellis1067, Rfredian, Rjackchapman, S2000magician, Sarah, Sarahbei, Scjnsn, ScottWAmbler, SebastianHelm, Shanemcd, Solarapex, Solution2010, SusanB99, The Epopt, Thopper, Urhixidur, Vincehk, Vsabio, Waninge, WikiPedant, Wildtornado, Yendor1958, Zachpresnall, Zath42, ZeroOne, 159 anonymous edits Project governance Source: http://en.wikipedia.org/w/index.php?oldid=366602922 Contributors: Akihabara, BenTremblay, EurekaLott, GardmanVS, Gsaup, Jauerback, Joekor, Jujutacular, Khalid hassani, Krakfly, Ktlonergan, Kuru, Lumos3, Malke 2010, Mapador, Mmiriam, MrOllie, Pleclech, Projectsponsor, R'n'B, RichardVeryard, Schopi, Scrivener Scribe, Simple Bob, Tassedethe, 18 anonymous edits Virtual project management Source: http://en.wikipedia.org/w/index.php?oldid=326819104 Contributors: Eastlaw, Kltownsend, Kuru, Mdd, Spartikus411 Software development process Source: http://en.wikipedia.org/w/index.php?oldid=367931079 Contributors: 123admin, 146.227.71.xxx, AFFAN HASAN, AGK, Ab762, Acockrum, Adrian.walker, Ahoerstemeier, Alansohn, Aleenf1, AlephGamma, Alex.key, Allan McInnes, Amalas, Ancheta Wis, Andy1618, Angr, Ansell, Ap, Aront54, Ash zz, Axd, Ayonbd2000, Az1568, Bassbonerocks, Baygun, Beland, Belinrahs, BenAveling, Bensel, Biasoli, Boing! said Zebedee, Brighterorange, BryceHarrington, Bstpierre, Canderra, Capricorn42, CatWikiEdit, CattleGirl, Cburnett, Chairboy, Chanti naresh, Charles Sturm, Chiranthan, Choggo, Cholmes75, Chowbok, ChrisLoosley, ChrisSteinbach, Christian75, Closedmouth, Cmmiloveprocess, Conversion script, Cory Donnelly, Cpl Syx, Crickel, DRogers, DXBari, Darth Panda, David.alex.lamb, DavidBailey, Dawidl, Degger, Delimata, Demiane, Devilgate, Dfrg.msc, Discospinster, Dpbsmith, Dybdahl, Dysprosia, EatMyShortz, Ebde, Edward, Egbsystem, Ehheh, Elkman, Elockid, Ency, Ennetws, Epbr123, Eric B. and Rakim, Erkan Yilmaz, Frecklefoot, Freedomlinux, Furrykef, Gdavidp, Glenn4pr, Graham87, Guppie, Gökhan, Harald Hansen, Hdante, He Who Is, Hede2000, HienTau, Hsorbu, Hu12, Hzhbcl, IRP, Ian Bailey, Ilario, Intodevel, Isaacdealey, IvanLanin, J00tel, J04n, JLaTondre, Jaiquois, Jamestochter, Jaydec, John Broughton, Jojhutton, Jpbowen, Juliancolton, K.Nevelsteen, Kazvorpal, Kbdank71, Kchampcal, Keilana, Kenny sh, Kesla, Khalid hassani, Khsdrummer2001, KnightRider, Knownot, Kuru, Larry_Sanger, Leafyplant, Leebo, Leibniz, Leif, Leolaursen, Limbo socrates, M ajith, M.e, MER-C, Majkiw, Malcolm Farmer, Mannojshukla, Mark Renier, Martin451, MaxHund, Mboverload, Mcorazao, Mdd, Michig, Midoladido, Mild Bill Hiccup, Mk*, Mos3ab, MrOllie, Mrdempsey, Mrh30, Myasuda, Natkeeran, NatusRoma, Nefuchs, Neokilly, Nigosh, Niteowlneils, Nixdorf, OMouse, Octahedron80, Ohnoitsjamie, Oicumayberight, Paviagrawal, Petra.hegarty, Phil webster, Philip Trueman, Pmtoolbox, Psb777, Pstraton, Pvazteixeira, RekishiEJ, Richard R White, Ripogenus77, RonLichty, Rursus, Rwgreen1173, Safemariner, Sagaciousuk, Sardanaphalus, Shirik, SimonMorgan, SiobhanHansa, Skarebo, SkyWalker, Slayemin, Softtest123, Sourcejedi, Spinality, Stephen Gilbert, Stephen e nelson, SunSw0rd, Supersteve04038, Suruena, Tasc, Teryx, The Thing That Should Not Be, Theleftorium, Thowa, Tide rolls, Timneu22, Tobias Bergemann, Tommy2010, Tonyshan, Toothmarks1111, Turkishbob, Tvarnoe, Ukexpat, Ulric1313, Umapathy, Valafar, VanDingo, Vary, Versageek, Vicenarian, VoteLibertarian, Voyagerfan5761, Waggers, Walter Görlitz, WalterGR, Whitepaw, WikiNC, WikipedianYknOK, William Avery, Wykis, Yngvarr, Yop83, Ywarnier, Ziphon, Zondor, ZooFari, ‫ןרע‬, 611 anonymous edits Process architecture Source: http://en.wikipedia.org/w/index.php?oldid=326027728 Contributors: Creacon, J04n, JHunterJ, Rp Project Source: http://en.wikipedia.org/w/index.php?oldid=365653844 Contributors: 1141 me, 16@r, 3K3D, Actuarial disco boy, Ahoerstemeier, Aitambong, Aitias, Alisabzevari, AllyUnion, Alphamu57, Anca, AndriuZ, Ap, Astudent, Badgernet, BenFrantzDale, Blathnaid, Bomac, Brentwills, Brian0918, Bwefler, Catgut, Centrx, Chowbok, Chuanyong, Ckatz, Coffee, Corpx, Corti, DVD R W, Dagdu, Discospinster, Dmn, Dream land2080, Duck to swan, Eekerz, Egil, Ehheh, Electronic Community, Elkman, Eric4720, Fredrik, Freuga, Gabz80, Galoubet, Garrybooker,

507

Article Sources and Contributors Garyrendall, Geschichte, Glenn, Gogo Dodo, Gor, Gsaup, Gwernol, Hetar, Hu12, ICAPTCHA, Iordanis 777, J.delanoy, J04n, JForget, JWSchmidt, Jay Litman, Jayjg, Jeffrey Mall, John, Jojhutton, Jongrover, Jpbowen, Jéské Couriano, Keds0, Kierenj, Killerrabbitsontheloose, Kolotelo, Krakfly, Kuru, La goutte de pluie, Levineps, Lightmouse, Likeicecr3am, Lumos3, MER-C, Magog the Ogre, MarySpencer10, Mav, Mdd, Menchi, Mendaliv, Mercury McKinnon, Millstream3, Mkoval, MrOllie, Mrzaius, Mvtechies, Mydogategodshat, Nankivel, Nivix, Nixdorf, Nmyers, Obli, Ojigiri, OlEnglish, Orderinchaos, Paddles, PamD, Pedant17, Peterbud, Pharaoh of the Wizards, Philip Trueman, Phydeaux, Piano non troppo, Pmtoolbox, Polluxian, PsychoCola, Quarl, RHaworth, RainbowOfLight, Raymundsy, Remshad, S.K., SMC, Screw you, Shanes, Sionus, Sjö, Slash, SoWhy, SpikeToronto, StaticVision, Stephenb, SuperHamster, Suresh82, Swpb, Tarnas, The wub, Thebluemanager, Tivedshambo, Topory, Travis99, Uncle Dick, Unioneagle, VMS Mosaic, Vanakaris, Vdudau, Versageek, Versus22, Vincehk, Viridae, Wanderingatlarge, Wgoetsch, Wiccagav, Winston365, Wknight94, Wlievens, Zenlax, Zzuuzz, 221 anonymous edits Critical path method Source: http://en.wikipedia.org/w/index.php?oldid=366786784 Contributors: Achalmeena, Amarvk, Amgunite, Amientan, BBar, BlinderBomber, Blueboy96, CPMTutor, CTZMSC3, CallmeDrNo, Carolfrog, Chachrist, Cheese Sandwich, Cnbrb, Corpx, Darguz Parsilvan, Delaszk, Donreed, Dragmas, Elkinsra, Eubulides, Firien, G2opdtsl, George100, Graibeard, Harda, Hekerui, Hu12, Inwind, IrishInNY, Ivolution, Jamelan, Jbarmash, Jeltz, Kaihsu, Kenmckinley, Khoshino, Kuru, Kwhitten, Lindsay658, Lordkyl, MER-C, Mausy5043, Mdd, Michael Hardy, Mod.torrentrealm, Mr. Shoeless, NCurse, Nascar fan mx, NcSchu, Newman9997, Nixdorf, Nuggetkiwi, Oxymoron83, PatrickWeaver, PigFlu Oink, Pingveno, Pm master, Ppntori, Quuxplusone, RHaworth, SNIyer12, Shlomke, Sin-man, SkipHuffman, Stevenwmccrary58, Thesydneyknowitall, Theuniversalcynic, Tijuana Brass, Vincehk, Vincnet, Vvkvaranasi, Woood, Wrduncan3, Wsmith202, 96 anonymous edits Agile software development Source: http://en.wikipedia.org/w/index.php?oldid=367913764 Contributors: A Train, ABV, Aamahdys, Aardvark92, Aaronbrick, Abukhader, Aditya2k, Aeuoah, Agile blog, Agiledev, Aguanno, Alansohn, Aliaghatabar, Alienus, Allan McInnes, Amit Singh, Ancheta Wis, AndrasSzilard, Andreas Kaufmann, Android79, Anonymous Dissident, Ans, Apjordan, Ash, Aternity, Auderobinson, AutumnSnow, Badgettrg, BaldPark, BartVB, [emailprotected], Beetstra, Beland, Benjamin.booth, Bevo, Bmcmichael, Boing! said Zebedee, Bosef1, Boson, Bovineone, Brendanoconnor, Brick Thrower, Brighterorange, Bunchofgrapes, CL, Capricorn42, Carewolf, CatWikiEdit, Catgut, Cawel, Ceyockey, Chicken Wing, Chmod007, Chonglongchoo, ChristianEdwardGruber, Chunkylover199, Ciotog, Cliffu, Cochiloco, Cpm, Cruccone, Ctobola, Cybercobra, D'n, Daen, Damitchellvbcoach, Damon Poole, Dandv, Daniel.Cardenas, Danr7, DarkseidX, Davelane103, David Biddulph, David Newton, David Waters, David.alex.lamb, Davidparker9, Dbenson, Deathphoenix, Demiane, Designatevoid, Dethomas, Dingsoyr, Dirk Riehle, Dlazerka, Dogcow, Dordal, DouglasGreen, Download, Dprust, Draicone, Ed Poor, Edward, Ejvyas, Elf, Emvee, Eric B. and Rakim, Ericholmstrom, Erpingham, EuroPride, Euryalus, Exir Kamalabadi, Explicit, Ezani, Fail, Fastily, FatalError, Feigling, First.thesecond, FrancoGG, Frecklefoot, Fred Bradstadt, Friday, Furrykef, G5reynol, GADFLY46, Gary a mason, Gazpacho, GeorgeBills, Ggiavelli, Gogo Dodo, Graham Jones, Greyskinnedboy, Gronky, Gruffi, Gurubrahma, H10130, HalJor, Halmir, Harry4000, Hede2000, Heirpixel, HelloAnnyong, Hmains, Hooperbloob, Hu, Hu12, Hzhbcl, Ianneub, Iterator12n, J.delanoy, JPalonus, Jafet, JamesShore, Jdpipe, Jeffreydca, Jerzy, Jferman, Jjdawson7, Jmabel, Jmilunsky, Jon.strickler, Jonathan Drain, Jonkpa, Josh Parris, JoshRyan, Joshb, Joshkuo, Jovial Air, Jtowler, Julesd, Juliancolton, Jusdafax, Jóna Þórunn, Kazvorpal, Kbdank71, Kbh3rd, Kelovy, Kenyon, KerryBuckley, Ketiltrout, Kevinevans, Kgasso, Khalid hassani, Klazorik, Klemen Kocjancic, Knutux, Koavf, Kswaters, Kundu.anupam, Kuru, Laterality, Latha P Nair, Laughing Man, Lefty, Leonus, Leopedia2, Liao, Lightmouse, Ligulem, Littlesal, Liujiang, LizardWizard, Ljhenshall, Lsisson, Lumberjake, Lumos3, MER-C, Mario777Zelda, Markwaldin, Martin Hampl, Martinig, MartinsB, Mathmo, Matiasp, MaxGuernseyIII, MaxSem, Mbroooks, Mcsee, Mdd, Merenta, Michael Hardy, Michael Slone, Michig, Mike Field, Mindmatrix, Mmainguy, Mmpubs, Morendil, Mr Stephen, MrOllie, NathanLee, Natl1, NawlinWiki, Nearly Human, Neufusion, Niteowlneils, Nixeagle, Nnivi, Obiomap1, Oicumayberight, Okipage8p, Okivekas, Orangeumbrella, PCock, Papeschr, Patrickegan, Patsw, Pauli133, Peashy, Penneys79, Petri Krohn, Pgr94, Phansen, Pinar, Porao, Possum, Postdlf, Pratheepraj, Prestonpdx, PseudoSudo, Qst, RG2, RHaworth, Raand, Ramsyam, Rawler, Rddill, Rebroad, Renffeh, Rentaferret, Riana, Rich Farmbrough, Rich257, Richwil, Rickjpelleg, RobertoComoEsta, Rockpocket, Rodney Boyd, Rogermw, Ron Richard, Rothley, Rursus, SQGibbon, SamJohnston, Sampi, Samwilson, Sardanaphalus, Sarefo, ScottWAmbler, Sean Whitton, SebastianBreier, Semperf, Sgroupace, Shepard, Shinmawa, Shirik, Shoessss, Silvonen, Sir Nicholas de Mimsy-Porpington, Skarebo, Smalljim, SolBasic, SouthLake, SpaceFlight89, Specter01010, Spellmaster, Srayhan, Sri2001, Srinicenthala, SteveLoughran, Stevegallery, Stickee, Strazhce, Stumps, Sulfis, Swguy, Swillcox, Swtechwr, Tagishsimon, TakuyaMurata, Tarinth, Tarjei Knapstad, Teckmx5, Teknobo, Tempshill, Tgwizard, The Thing That Should Not Be, TheCoffee, Thejoshwolfe, Themfromspace, Themshow, Thingg, Thinkpod, Tiago simoes, Ticaro, Tisni, Tomb, Tommy2010, Tony Sidaway, Tsilb, UdayanBanerjee, Umofomia, Urrameu, Vald, Van der Hoorn, Vasemwant, Vyyjpkmi, WDavis1911, WTF-tech, Walter Görlitz, Wiki3 1415, William Pietri, Windowsvista2007, Wiretse, Wjbean, Xyad, Yath, YoavShapira, ZAD-Man, Zane McFate, Zenofile, Zigger, 981 anonymous edits Program Evaluation and Review Technique Source: http://en.wikipedia.org/w/index.php?oldid=366183476 Contributors: A Magician, Achalmeena, Alvinjmartinez, Amarvk, Avishek Barua, Benwu, Bhadani, Bjdehut, Cagnol, CanadianLinuxUser, Catgut, Cgs, Chachrist, Cvanhasselt, Cybersteel8, Dbsheajr, Delaszk, Djanke, E. Ripley, Enderminh, Former user, Gavin White, Georgia guy, Gilliam, Graham87, Graibeard, Guy Siedes, Harryboyles, Harsh.humtum.eng, Hooperbloob, Ironwolf, JEBBAH, JavierMC, Jeff G., Jeremykemp, JorgeGG, Karada, Kate, Kaushalarchana, Ketiltrout, Kstarsinic, Kuru, LaurensvanLieshout, Ligulem, Lindsay658, Maclir2001, MagnusA, Manofradio, Markhurd, Maurreen, MaxPont, Mdd, Minesweeper, Mkoval, Mydogategodshat, Niravsdesai, Nixdorf, Olaf2, Oubiwann, PatrickWeaver, Piano non troppo, Pm master, Pmtoolbox, RedWolf, RichardF, Rui Covelo, Saurabh13686, SeanDuggan, Secretmessages, SkipHuffman, Smjg, Sspecter, Stovl, Swpb, Tifoo, Tim Pritlove, Tomjenkins52, Tommy2010, Truthraj, TutterMouse, Wikisteff, 175 anonymous edits Computer software Source: http://en.wikipedia.org/w/index.php?oldid=367863873 Contributors: 12dstring, 16@r, 194.237.150.xxx, A Stop at Willoughby, A.K.R., ABF, AFriedman, ALargeElk, Aatayyab, Abby, Abufaisal65, Acroterion, Addshore, Ademsaykin, AdjustShift, Ah2190, Ahadrt, Ahoerstemeier, AlMac, Alan012, Alansohn, Alasdair, Aleemqureshi, Ali K, AlisonW, AlistairMcMillan, Allen4names, Alphachimp, Amalhotra124, Anabus, Andre Engels, Andrea105, Andrejj, Andrewspencer, Angela, Angela 2502, Antandrus, Aoratos, Ap, Aqeelbilal, ArchonMagnus, Arkrishna, Artem Karimov, Ashawley, Asiananimal, AuburnPilot, AussieLegend, Autocratique, Avono, Aweiredguy, Backslash Forwardslash, Bact, BalderV, Barek, Bean2thousand, Bearly541, Ben-Zin, Betterusername, Bevo, Big Bird, Big milsy, BigDunc, Binary TSO, Blarrrgy, Bobo192, Bonadea, Bongwarrior, Booyabazooka, Boriszex, Boxplot, Brat32, Brent Gulanowski, Brinnington, Brucevdk, Brusegadi, Bryan Derksen, Bubba73, Burnisk, Butros, CIreland, Can't sleep, clown will eat me, CanadianLinuxUser, Canaima, Canterbury Tail, Cargils02, Carl007, Casperdog2227, Cassandra 73, Catgut, Causa sui, Cburress, Centrx, Christian List, Chun-hian, Chuunen Baka, Chzz, Citypanther, CommonsDelinker, Conan, Conversion script, CoolD, Coolcaesar, Cpl Syx, Crazykr, Crossmr, Cst17, Cunya, Cyberstrike3000X, Cyrius, DBHunter, DJ Clayworth, DSP-user, Damian Yerrick, Dan Fuhry, Dan100, Danakil, Daniel5127, DanielEng, Darkevilfairy, Darrendeng, Darth Panda, Dave6, Davennmarr, Daveydweeb, DavidWBrooks, Davie4125, Dayewalker, Dbstommy, DeadEyeArrow, Deggalega, Delirium, Denny, DerHexer, Derek farn, Dethme0w, Dibcom, Dina, Discospinster, Dispenser, DivineAlpha, Dj stone, DmitTrix, Dominator09, Donald Duck, Dougofborg, Drawnman247, Dreamatalana, Drewster1829, Drmies, Dugmn, Dycedarg, E. Sn0 =31337=, EdBever, Edcolins, Edivorce, Edlin, Eeekster, Egbsystem, Ehheh, ElBenevolente, Ellenaz, Emana, Emvn, Epbr123, Equendil, Erdal Ronahi, Esoteric Rogue, Everyking, Excirial, Ezubaric, FJPB, Fang Aili, Favonian, Fazilati, Fctk, Feedmecereal, Felyza, Fenice, Fern80, Flarn2006, Flash man999, Flipjargendy, Flubeca, FlyingToaster, Frap, Fratrep, Fred Bradstadt, Fredrik, Fredtheflyingfrog, Freeeeeesoft, Friday, Frip1000, Frosted14, Fubar Obfusco, Funnysens, Fyyer, GDallimore, GSCC, GTBacchus, Gabecuevas, Gadfium, Gaius Cornelius, Galoubet, Gardar Rurak, Gary King, Gazpacho, Geneb1955, Georgia guy, Giftlite, GilbertoSilvaFan, Gilliam, Ginsengbomb, Gogo Dodo, Gordmoo, Greenrd, GregorB, Gronky, Gtg204y, Guanaco, Gueldenberg, Guppy, Gurch, Gwernol, Hadal, Harvester, Hauberk, Haunting The Better, Hayabusa future, Hectorthebat, Hello32020, Hellosandimas, HenryLi, Hmains, Hmcnally, Hno3, Howdoesthiswo, Howling wolf of the jungle, Hu12, Hutcher, Hydrogen Iodide, Iknowyourider, Imnotminkus, Imroy, IngerAlHaosului, Instinct, Intelligentsium, Into The Fray, Iridescent, Ishara665g, Itsmine, Ixfd64, J Di, J. Spencer, J.delanoy, JLaTondre, JMetzler, Jaan513, Jackaranga, Jacob.jose, Jacqueline7894y, Jam2k, Jamesiemiller, Japonca, Jarda-wien, Jay, Jcuadros, Jcw69, Jeff G., Jehochman, Jeremy Visser, JeremyA, JesseW, Jester7777, Jh51681, Jiang, Jiddisch, Jiy, Jmabel, JoanneB, Johan1298, JohnCD, JonHarder, Jonnabuz, Jop, Joy, Jpbowen, Jpgordon, Jreferee, Jsheadixon, Jtalledo, Jtbatalla, Jusdafax, Jusjih, Justin Eiler, Jóna Þórunn, K.Nevelsteen, K.lee, KFP, Kajasudhakarababu, Karol Langner, Kathmandu2007, Kc03, Keilana, Kelldall, Kelly Martin, Kenny sh, KevinCuddeback, Kingpin13, Kinneyboy90, Knownot, Knucmo2, Kornxi, Kostisl, Kozuch, KrakatoaKatie, Krawi, Ktanzer, Kuldeep06march, Kumioko, Kurowoofwoof111, Kuru, La Pianista, Lagalag, LaggedOnUser, Lajpatdhingra, Landroo, Lareina3656y, LauriO, Leandrod, LeoNomis, Liao, Liberty Miller, Liftarn, Ligulem, LinDrug, Lindberg G Williams Jr, Listlist, LittleOldMe, Livajo, Lookingchris, Lucianob, Luna Santin, Lunaumbrax, Luntrasul, Lupo, MC10, MD66, MER-C, Macy, Majorbrainy, Malcolm Farmer, Malcolma, Mandarax, Manik762007, Manionc, Maralia, Marek69, Markaci, Martarius, Master&Expert, Matt Britt, Matusz, Mav, Maximaximax, Maximus Rex, Mcdonald.ross5, Mdd, Mdebets, MeekSaffron, Meelar, Mendalus, Mentifisto, Mermaid from the Baltic Sea, Message From Xenu, Mgrand, Michael Drüing, Michael Hardy, Michal Jurosz, Miguel.mateo, Mild Bill Hiccup, Mindspillage, Minesweeper, Minghong, Mini-Geek, Miquonranger03, MithrandirAgain, Mjchonoles, Mkdw, Monobi, Mpete510, Mr Barndoor, MrDolomite, MrOllie, Muffhen, Murray Langton, Mwanner, Mwilso24, Mxn, Myanw, N n abc123, Nabeth, Naik5abhi, Nanshu, Narayana vvss, Nathanielrichards, Navstar, NawlinWiki, Nbarth, Neil916, Neurophyre, Nharipra, Nickels360, Nikai, Nike8, NinjaCross, Nixdorf, Nixeagle, Nk, Nmrd, Normxxx, Nosferatus2007, Nourybouraqadi, Nsaa, NuclearWarfare, Nunquam Dormio, NurAzije, Nurg, Oda Mari, Ohnoitsjamie, Oicumayberight, Old Moonraker, Oldwes, Oleg Alexandrov, Oliver Lineham, Omicronpersei8, One more night, OrgasGirl, Oxymoron83, P99am, PEH2, PIrish, Page Up, Paranoid, Park3r, Party, Passargea, Paul August, Paul Niquette, PeaceAnywhere, Perkinsleslie, Peruvianllama, Peter Winnberg, Pgk, Phatom87, PhilHibbs, PhilKnight, Philip Howard, Philip Trueman, Phillip Ca, Piano non troppo, Pilotguy, Pip2andahalf, Poccil, Pohatu771, Pohta ce-am pohtit, Pointillist, Poo1000, Pooryorick, Priyadarshi.pratyush, Programmer13, Prohlep, Psantora, Public Menace, Puchiko, Puneet1507, Purgatory Fubar, Pyfan, Quinobi, Quinsareth, QuintusQuill, R. S. Shaw, RHaworth, Ragha joshi, Ragib, Rainier3, RainierHa, Rajeshmagic, Random89, RandorXeus, Raul654, Ray Van De Walker, Raylu, Rbreen, Rebroad, Recnilgiarc, RedWolf, Reedy, Rehnn83, Remember the dot, Rettetast, RevRagnarok, Revised, Rgill, Rholton, Rhye123, Riana, Rich Farmbrough, Richard cocks, RickK, Ripogenus77, Rl, Rogger.Ferguson, Roland2, Ronhjones, RossPatterson, Roybb95, Rurik, Rwwww, Ryulong, S.K., SC979, SF007, ST47, Sadeq, Sadi Carnot, Safalra, Safarj, Saleem110, Salsa Shark, Sango123, SchfiftyThree, Scientus, Scrool, Seaphoto, Seb az86556, Seidenstud, Senator Palpatine, Setveen, Shadowjams, Shakya ind, Siggy28, Sigondronggondrong, Siliconov, SimonP, Sintonak.X, Sitarherophil, Sivaguru411, Sjö, Skarebo, Slingerjansen, Slowking Man, Slowmo1993, Smack, Smalljim, Snowmanradio, Sokrato, Soler97, Sorryranga94, South Bay, Speaksleft, Spectrogram, SpuriousQ, Starkiller88, Stephenb, Steven Zhang, Stewartadcock, StuffOfInterest, Supadawg, Super-Magician, Supersteve04038, Suruena, SusanLesch, SwirlBoy39, Syrthiss, T4tarzan, THEN WHO WAS PHONE?, TPK, TaintedMustard, Tangent747, Tasja, TastyPoutine, TechOutsider, Tejas81, Teryan2006, Th1rt3en, Tharcore, The Anome, The Earwig, The Rambling Man, The Thing That Should Not Be, The Transhumanist, The Transhumanist (AWB), TheBiaatch, Thelb4, Thingg, This acccount is 4 vandalism, Thumperward, Thurak13, Tide rolls, Tigershrike, Tim Q. Wells, Timhowardriley, Timothy Neilen, Tommy2010, Topbanana, Torc2, Torinor, Traroth, Trevor MacInnis, Triona, Triwbe, True Genius, Trueshow111, Trusilver, Turlo Lomon, Tuxide, Twsx, Uncle Milty, Unyoyega, Uriyan, Vbigdeli, Versageek, Versus22, Virtualsfera, Viskonsas, W Nowicki, WLU, Wavelength, Wayward, Werdna, Weregerbil, Wernher, Wexhammer, Weyes, Whitew123, Wiki alf, Wikicrazier2011, Wikidudeman, Wikieditor06, Wimt, Wireless friend, Wm, WojPob, Wshun, Wysprgr2005, Xdenizen, Xevious, Yamamoto Ichiro, Yidisheryid, Yoooder, Yworo, Zarkos, Zedlik, ZeroOne, Zerokewl, ZimZalaBim, Zybez, Александър, Евгени Симеонов, Петър Петров, 1498 anonymous edits

508

Article Sources and Contributors Software engineering Source: http://en.wikipedia.org/w/index.php?oldid=367614718 Contributors: -Barry-, 144.132.75.xxx, 152.98.195.xxx, 15lsoucy, 208.11.34.xxx, 212.153.190.xxx, 2xj, 3Nigma, 3S-consortium (defrag your mind), AKMask, APH, AVRS, AadaamS, Abrech, Abrio82, Academic Challenger, Adashiel, Addshore, AdjustShift, Adrian.benko, Adrius42, Adw2000, Ahmadmashhour, Ahoerstemeier, Aimaz, Aitias, Alansohn, Alex.muller, Alexf, Alhoori, Alisha0512, AllCalledByGod, Allan McInnes, Allstarecho, Ancheta Wis, Andre Engels, Andrei Stroe, Android79, Andycjp, Angela, AnthonyQBachler, Apanait, Apantomimehorse, ArielGold, Art LaPella, Arvindn, Avb, Axtools, B.dubbu, BFD1, Babirox, Bact, Baristarim, Bastun, Bcourchaine, Beetstra, BenjaminTsai, Bernd in Japan, Bevo, Bishonen, Blehfu, Bluemask, Bobo192, Boson, Bovlb, BrainyBroad, Bruce Esrig, Bryan Derksen, Bug, BurntSky, CIreland, CUSENZA Mario, Cabalamat, Can't sleep, clown will eat me, Canterbury Tail, Cavebear42, Cdaylin, Cdc, CesarB, Chancemill, Charles Matthews, CharlesC, Charlesverdon, Chendy, Chris Roy, Chris j wood, ChrisLoosley, Claygate, Clivehayward, CobaltBlue, Commander Keane, Coneslayer, Constantinescu, Conversion script, Corvus cornix, Craigwb, Crazynas, CryptoDerk, Cwalrad, DJ Clayworth, Da404lewzer, Damian Yerrick, Damithrajapakse, Danhicks, Dannypassusone, DarkSaber2k, Dave.killion, David Biddulph, DavidCBryant, DavidHOzAu, Davidlongstreet, Dcclark, Dcooper, DeadEyeArrow, Deliyurek, Demerzel, Dendodge, Denny, DeweyQ, Diggernet, Digitalme, Discospinster, Djmckee1, Dmaftei, Dominic, Doradus, Dori, Dougofborg, Dpbsmith, Dysprosia, EWS23, Earle Martin, Ed Poor, Ehheh, El C, Elm-39, Eloquence, Emmjoyit, EncMstr, Entgroupzd, Erkan Yilmaz, Esap, Esfdsfvfbfd, Esurnir, Evahala, Exert, Exit2DOS2000, Fadesga, Faethon387, Falcon9x5, Fatman002, Ferkelparade, Filippowiki, Freakofnurture, Frecklefoot, Furrykef, Fuzheado, Fvw, Gaius Cornelius, Galoubet, Gdr, Gencay, GenericBob, Ghaag, Giftlite, Gimboid13, Gin, Glane23, Glen, Gogo Dodo, GoldenTorc, Graham87, GreedyCapitalist, Gremlinn, Guehene, Guppie, Guybrush1979, Gwalla, Gwernol, Ham Pastrami, HamburgerRadio, HarisM, Harriv, He Who Is, Hemanshu, HenryJLaw, Heron, Hirzel, Hu, Hu12, Husond, Hyad, Icairns, Ikana, Imecs, Imroy, Ino5hiro, Instinct, Intangir, Intray, Iridescent, Isam, Islander, Iterator12n, Ivan Štambuk, Ivanivanovich, J.delanoy, JWBito, Jaberwocky6669, Jackol, JakeVortex, Jane023, JeLuF, Jeronimo, Jerryobject, JesseGarrett, Jfliu, Jim McKeeth, Jimgawn, JoanneB, Joe Jarzombek, John254, Johndci, Joshmatthews, JoshuaKuo, Jpbowen, Jpenix, Jrdioko, Julesd, Just Another Dan, Jóna Þórunn, K.Nevelsteen, Kanonkas, Katr67, Kbdank71, Ke4roh, Kemorgan, Kendrick Hang, Kenny sh, Kephnosanagennao, Keramida, KerryBuckley, Kevin, Kevins, Kingpin13, Kjetil r, Klelith, KnowledgeOfSelf, Kououken, Krallja, Kuru, L33th4x0rguy, La Pianista, Latiligence, Lawrancj, Lee Daniel Crocker, Leibniz, LightAnkh, LilHelpa, Limkl, Lmarinho, Lowellian, Luna Santin, Lwoodyiii, Lycurgus, M@sk, MER-C, MH, MIT Trekkie, MacMed, MacTire02, Mahanga, Malcohol, Mani1, Manik762007, Maria C Mosak, Mark Renier, Matacob, Mathias-S, Matithyahu, Mausy5043, Mbadri, Mbarkerwiki, Mbb94, Mdd, Michael Hardy, Michig, Miles, Milnivlek, Mirwin, Mjchonoles, Mmeri, Mobingo, Monkey Bounce, Moverton, Mpeisenbr, MrOllie, Mrdice, Mrwojo, Muriel Gottrop, Mxn, Myasuda, N3X15, NAT1V3, Nanshu, Narquise, Natkeeran, NawlinWiki, Nburden, Nealmcb, Nepenthes, Nevalex, NewEnglandYankee, Nickg, Nienlinhsueh, Nikai, Nisavid, Niteowlneils, Nixdorf, Nltheshadow, Noctibus, Noldoaran, Norm, Normxxx, Nsaa, Ntrolls, Oashi, Oceanm, Ohnoitsjamie, Oicumayberight, Olexandr Kravchuk, One more night, Ontopofthewall, PL290, Pablothegreat85, Palica, Pcb21, Perey, PeterisP, Pfuchs722, Phil Boswell, Philip Trueman, PhilipMW, PhilipO, Philosopher06, Pill, Pinecar, Pipedreamergrey, Pithecanthropus, Poccil, Poor Yorick, Project2501a, Ptk, Pvosta, Pyromanisdabest, R3m0t, RHB100, RHJesusFreak40, RJFJR, RTC, Rajquest, Randyaa, Raysecurity, Raysonho, Razorflame, RedWolf, Reisio, Rettetast, Revolution363, Rfc1394, Rfortner, Rhoeg, Rich Farmbrough, Rjwilmsi, Robertoalencar, Robin klein, Ron Richard, Ronz, RoyBoy, Royalbroil, Rror, RussBlau, Ruud Koot, RxS, S.K., SE SME, SEI Publications, SaRSUK, Saaga, Sagsaw, Sarakoth, Sarsaparilla, Scarian, Schwarzbichler, Sciurinæ, SeanFromIT, Sega381, Shadowjams, Shadowlynk, Shanes, SimonEast, SimonTrew, SiobhanHansa, SkerHawx, Skj492, Slady, Slyguy, Smogit, Snoyes, SoSaysChappy, Socratez, Spinster, Spsbe2004, Starrymessenger, Stemonitis, Stephen Macgregor, StevePotter, StevenFowler, Storm Rider, Suldanna, SunSw0rd, SwordAngel, Tablizer, Talon Artaine, Tannin, Tariqabjotu, Tbc, Teaearlygreyhot, Tedickey, Tekeek, Teryx, The Anome, The Divine Fluffalizer, The Transhumanist (AWB), TheCatalyst31, ThePedanticPrick, TheProject, Theprofessional1, Thowa, ThreePD, Thumperward, Timonthemove, Triskell, Trusilver, Turelankan, Tvarnoe, Umofomia, Usnadad05, Utcursch, UtherSRG, Vanuan, Vashtihorvat, Versus22, Vincehk, Vlpavlov, Vssun, Vsync, Wapcaplet, Wdfarmer, Webdev29, Wencyclo, Weylinp, WhAt, Wik, WikHead, Wiki corection, Wiki0709, Wikicsc123, Wikipaddn, Willtron, Wlievens, Wombleme, Wre2wre, Xiong Chiamiov, Yamamoto Ichiro, Yk Yk Yk, ZenOpie07, Zeno Gantner, Zoicon5, Zorabi, Zzuuzz, А.Минас, 1848 anonymous edits Construction Source: http://en.wikipedia.org/w/index.php?oldid=366512462 Contributors: -Majestic-, 119, 16@r, ABF, ACY.Man, Abrech, Acacpc, Acroterion, Ae bron, Ahead101, [emailprotected], Ahoerstemeier, Aids10, Aitias, Alan Liefting, Alan bron, Alansohn, Aled D, [emailprotected], Alkiviadis, All935thgfjbashbf43, Allallallworldworking, Allefant, Allldwjkfjkallajiwehfjb, Alnatour 2000, Alphachimp, Altenmann, Andycjp, Ann Stouter, Apelbaum, Aquilina, Aremith, Argon233, Argyriou, Arisofalaska, Arnaldouliana, Arpingstone, Ashdurbat, Austinm, Axlq, Backburner001, Barneca, Baronnet, Bean ed, Beetstra, Belovedfreak, Berendale, Bevo74, Beyond silence, Bill37212, Billy90210, Bmitchelf, Bobo192, Bookandcoffee, Bookworming, Borgx, Bossonova, Brain40, BrianGV, Brianga, Brianyoumans, CactusWriter, Callahan12, Calliopejen1, Caltas, Can't sleep, clown will eat me, CanadianLinuxUser, Caper13, Capricorn42, Casimir, Cathetus, Celarnor, Celestra, Chimeric Glider, Chmee2, Chris.campfield, Chrispreece2007, Civil Engineer III, Cobi, Cometstyles, Construction01, ConstructionSoftwareExperts, Coolslko, Correogsk, Crazy Boris with a red beard, Cxcarmany, Cyrius, DCAnderson, DJE, DVD R W, Danil K., David Gale, Dekisugi, Delicious carbuncle, Deor, Destinationthailand, Dfrg.msc, Diamond-blades, Dinolala, Discospinster, Don't give an Ameriflag, Donald Albury, Dontbfooled, Doraemonpaul, Dougie WII, Dougz1, Drnathanfurious, Dstric13, Dungodung, Dylansmrjones, E Wing, Eastlaw, Ebeing, Eclectick, Ecryder, Ed2damax, Efarley6, Electron, Entrant123, Epbr123, Erauch, Erebus555, EurekaLott, Evil saltine, Extra999, Fail, Famspear, Faradayplank, Femto, Fencingtim, Fetofs, Find100, Fir0002, Firien, Foxandpotatoes, FreplySpang, Fsiler, GDonato, Garzo, Ghirlandajo, Giftlite, Giveupfool21, Glacier Wolf, GraemeL, Gregalton, Gsaup, Gwernol, Hadal, Haham hanuka, Hajenso, Halmstad, Heather hope, Heimstern, Heron, HexaChord, Hiberniantears, Hiringtoolbox, Hu12, Hughcharlesparker, Hut 8.5, Hyacinth, Icairns, Imagist, Ixfd64, J.delanoy, JHunterJ, Jakolonian, Jannej, Jaychowrocksmysocks, Jdforrester, JeremyA, Jexxy5, Jim Flint, Jim Furtado, John of Reading, John254, Johnman239, Jorfer, Jossi, Jpalnow, Justanother, KVDP, Kafziel, Kashi0341, Kevin, Kevin Forsyth, Kilmer-san, Kinston eagle, Ksero, Kummi, Kylemcinnes, Kys951, L337 kybldmstr, LAX, LGagnon, Lacort, LeaveSleaves, Leslie Mateus, Levineps, LeyteWolfer, Lights, LinkSpamCop, Loft conversion, Loft conversions, Luckyluke, Lymtudor, MER-C, MIRight, MQuinn, Mac, MacMed, Magnus Manske, Mambg, Mariokempes, MathKnight, Matilda, Maurajbo, Maxí, Mbc362, Mcginnly, Mediaimages, Michael Hardy, Michael L. Kaufman, Miranda, Mkimemia, Momusufan, Mostlyharmless, Mostvaluableplanner, MrOllie, Mwanner, Mxn, NSLE, Nakon, NeilN, Neparis, Nevsal, NickW557, Nickythebricky, Nightscream, NocturnalA6 2.7, Nutiketaiel, O00XSHADYX00o, Ohnoitsjamie, Oleg Alexandrov, Organicjack, Oxymoron83, Pablo2garcia, Pacific1982, Pacman5, Patrick, Paxse, PeaceNT, Pearle, Peladu, Pharaoh of the Wizards, Pharos, Phearicle, PhilKnight, Philopp, Piano non troppo, Pilgaard, Pinar, Pinkadelica, Possum, Prashanthns, PrometheusX303, Punchmein, R.123, Ra-smit, RabbitKing, Rackabello, Raggiante, Rastrelli F, Rehman, Remi0o, Renan S2, Renobuild, Ricky81682, Rj, Rjwilmsi, Rmaul, Roastytoast, Rob santana, RockMFR, RoyBoy, Ruralbuildermag, Russellsnyder, SF007, Salmar, Samohyl Jan, SchuminWeb, Scientizzle, Secretlondon, SharpeSoft, Shawn Goodall, Signalhead, SimonP, SiobhanHansa, Sir Vicious, Skidude9950, Slathering, Slugojake1, Solipsist, SpookyMulder, Stephen B Streater, Stephenchou0722, Stev0, Stevenwmccrary58, Studerby, Sunray, Superfopp, Symbion Power, T griffen, TVBZ28, Teapotgeorge, Thaiio, TheOtherJesse, Theonlysilentbob, Theresa knott, Thingg, Tikiwont, Tiptoety, Tisdalepardi, Tnxman307, TonyTheTiger, Trusilver, Twestgard, Txlandlord, Ucla90024, Ultramandk, User1983, Utcursch, VK35, Van helsing, Vanka5, Vegaswikian, Versageek, Virago, Waggers, Waldir, Wavelength, Web4net, WhiteCat, WikiDon, Wikid77, Wikieditor06, Wil05036679, WinterSpw, Wuhwuzdat, Xiliquiern, YBeayf, YUL89YYZ, Yahel Guhan, Yamamoto Ichiro, Yidisheryid, Yippieyiyo, Yvwv, ZX81, Zath42, Zenithconstructions, Zs, Zzuuzz, Ævar Arnfjörð Bjarmason, 602 anonymous edits Engineering Source: http://en.wikipedia.org/w/index.php?oldid=367590190 Contributors: 0x6D667061, 10braunsteinc, 128.163.239.xxx, 130.159.254.xxx, 16@r, 205.188.198.xxx, 208.186.187.xxx, 212.153.190.xxx, 24.50.165.xxx, 4engr, 64.80.202.xxx, 6birc, 7, A bit iffy, ABF, AVand, Abraham70, AbsolutDan, Adam Bishop, Adolf Hi+ler the second, Ahoerstemeier, Aillema, Ajraddatz, Alansohn, Aldie, Alexmason14, Allan McInnes, Alnatour 2000, Alpha 4615, Ancheta Wis, Andre Engels, AndrewHowse, Andrewlp1991, Andrewpmk, AndriuZ, Angela, Anger22, AnnaFrance, Anonymous Dissident, Ant har05, Anterior1, Anthere, Anthonyhase, Anticent, Antiuser, Ap, Arindam.2011, Astudent, Av99, Avb, Awonsgay, Awotter, AzaToth, BAxelrod, Bakabaka, Balapuba, BalazsH, Baljitisgay, Barek, Barneca, Barneyboo, Basar, Beetstra, BenBreen2003, Bevo, BigFatBuddha, BigHairRef, Biolawyer, Blake-, Blaserules, Blue520, Bluemask, Bmeguru, Bob, Bobg1756, Bobo192, Boivie, Bookofjude, BookwormUK, Bradjamesbrown, Brandy Frisky, Brenont, Brion VIBBER, Brown480, BryXEng, Butko, CUSENZA Mario, Caknuck, Caltas, CambridgeBayWeather, Can't sleep, clown will eat me, CanadianLinuxUser, Canderson7, Cantus, Capricorn42, Caracaskid, Careercornerstone, Catdude, Cbdorsett, Cburnett, Cemalardil, Cessator, Chaos, CharlesC, Cheese86549, Chenzw, Chrispreece2007, Christopher Parham, Churchman6718, Cireshoe, Cjlim, Clyde frogg, Colonies Chris, Cometstyles, Commander Keane, Conversion script, Coolcaesar, Corti, CrazyCanuck, Cronholm144, Cryptic C62, CryptoDerk, Cschutte, Csyberblue, Cybercobra, DJ Clayworth, DVD R W, Da monster under your bed, Dancter, DanielCD, Darigan, Datheisen, Davandron, David.Monniaux, DavidLevinson, Dbl2010, Dekisugi, Delldot, DerHexer, Devin122, Dialectric, Diberri, Dicklyon, Diderot, Dieselman, Dina, Dmitri Lytov, DocWatson42, Docu, Donmu, Dori, Dr.K., DragonFly31, Drdestiny77, EALacey, EatMyShortz, Echo95, Egfiasee, Egmontaz, El C, Ela112, Elcielo917, Elipongo, Emanuelperez, Encephalon, Engineering fan, Engology, Epbr123, Ephebi, Eranjenes2, Eric Desart, Everyking, Excirial, FOK SD OA, FactsAndFigures, Fahsja, Fanman72, Farkas János, Femto, Fieldday-sunday, Finn-Zoltan, Floquenbeam, Footwarrior, Fplay, Freeformer, Friginator, Fubar Obfusco, Funandtrvl, Func, G Colwell, G. Campbell, Gabriel Kielland, Gail, Gaius Cornelius, Gakusha, Gatutigern, Gazpacho, Geeoharee, Genesis1155, Gergyl, Gerry Ashton, Giftlite, Gjd001, Glenn, Gogo Dodo, Golden0103, Goldleafblueautumn, GoodStuff, Gorockytop101, Graham87, GreatWhiteNortherner, Greglocock, Grendelkhan, Greyengine5, Grillo, Grimey, Gsaup, Guaca, Guanaco, Gun Powder Ma, Gurch, Gurchzilla, Gökhan, H2O, Hadal, Haenaroad, Haham hanuka, Hammack, Hammer1980, Hans-J. Wendt, Harryzilber, Hdt83, Hemant kumar, Heron, HexaChord, Hmains, Hu, Husainweb, Hwachang82, Hydrogen Iodide, HyperX, II MusLiM HyBRiD II, IRP, IanWills, Ideyal, Ike9898, Imecs, Imjustmatthew, Immunize, Indianw200i, Inkling, InternetHero, Ioeth, Iridescent, Ivan Štambuk, IvanLanin, J Di, J-Wiki, J.delanoy, JForget, JJ92780, JM Robert, JNW, JRR Trollkien, JYOuyang, Ja 62, Jabelufiroz, Jacj, Jacob1207, Jagged 85, Jaguarlaser, Jakob, JamesBWatson, JamesJohena, JamesTseng, Janet13, Jaysweet, Jc3s5h, Jd027, JerryTheShrimp, Jfdwolff, Jfliu, Jim, Jkkjjk, Jkstark, Jlburf, Jleedev, Jlinton, Jodema12, Johan Torbjörn Gustaf Wrede, JohnOwens, Johnreep, JonathanBuck IEC, Joostvandeputte, Jor70, Jose77, Joseph Solis in Australia, Jpbowen, Jth299, Julian Mendez, Jusdafax, Jusinjacob, Jusjih, K-UNIT, KOTHALAWELA, KaLogain, Kangie, Kanonkas, Karenjc, Kaszeta, Kchishol1970, Keegan, Kellenb, Kerotan, Kgranados, Khin007, Khukri, KieferFL, Kingturtle, Kjkolb, KnowledgeOfSelf, Korg, Kornfan71, Kotjze, Kps2, Krich, Ksd5, Kubigula, Kukini, Kungming2, KurtRaschke, Kuru, Kurykh, Lankiveil, Lapost, Lawrence Cohen, Ldonna, Lear's Fool, LeaveSleaves, Lent, Levineps, Lginger, Light current, LightAnkh, Lights, Linuxlad, LittleOldMe, LiuyuanChen, Lommer, Lone Isle, Luk, Lukenjoel, Luna Santin, LutzPrechelt, M.hayek, MCG, MKoltnow, MMuzammils, MONGO, Mac, MacMed, Malafaya, Mani1, Manionc, Manway, MarSch, Maralia, Martarius, Martinp23, Martinra, Masoudsa, Materialscientist, Matt Britt, Matthe20, Maurreen, MaxSem, Maximus Rex, Maxxicum, Mcrkramer, Mdd, Meaningful Username, Meelar, Megaboz, MementoVivere, Mentifisto, Mentisock, Merovingian, Mg2005, Michael Hardy, Michaelas10, Michagal, Mick8882003, Mightyblue, Miro modo, Mirwin, Mohammed Prince, Mongose8, Monster7823, Mostvaluableplanner, Mouradvt, Mr Grim Reaper, Mr Stephen, Mr. IP, MrOllie, Mrorvig UTexas Aerospace Engineering, Mudlock, Mwilso24, Mxn, Mytic789, Möchtegern, NCurse, NJBUDD, Nakon, Nathannae, NawlinWiki, NeD80, Nehrams2020, NeilN, Netalarm, Netoholic, Neurolysis, Neurovelho, NewEnglandYankee, Nexus Seven, Niclond23, Nikai, Nivix, Nixdorf, Nonamemark, Normxxx, Nposs, Nsaa, Numbo3, Nwk, Odiseo79, Oicumayberight, Oleg Alexandrov, Omegatron, Oops i killed the president, OrgasGirl, Orphan Wiki, Oscarthecat, Oxymoron83, PCStuff, Pacersfan999, PaePae, Pagingmrherman, Paleorthid, Parker2334, Passw0rd, Paul A, Paul Ruby, Paul-L, PaulHanson, Pavel Vozenilek, Pavlo Shevelo, Paxsimius, Per7, PeregrineAY, Persian Poet Gal, Peterlewis, Peterlin, Pethan, Pharaoh of the Wizards, Pheon, PhilKnight, Philip Trueman, Phoebe, Piano non troppo, Pinethicket, Pink!Teen, Pithecanthropus, Plasmarob, Pmetzger, Poa, Polluxian, Poor Yorick, Prasadga, Prashanthns, Prodego, Protonk, PseudoSudo, Pseudomonas, Purple Paint, Pythro, Q7946w, Quadell, Quadra23, Quercusrobur, Quickbeam, Qwazywabbit, Qwe, Racklever, Rafaelgarcia, Rajeevm1989, Ratiocinate, Recurring dreams, RedHillian, Reddi, Remi0o, Remshad, Requestion, RexNL, Rfortner, Rhoeg, Rich Farmbrough, Riomack, Rjsc, Rjwilmsi, Rmhermen, Robert Merkel, RobertG, Rodhullandemu, Rogper, Ronz, Roux-HG, Roygbiv666, Ryan Roos, Ryansdistrict, S, SE SME, SJP, ST47,

509

Article Sources and Contributors STHayden, Sadi Carnot, Salsa Shark, SamanthaPr, Sammyboss, Samuel, Saros136, Savant13, Scarian, ScottyXS, Secretmessages, Sengkang, Septagram, Seyer-odla, Shadowjams, Shadowlink1014, Shmilyshy, Shustov, SidP, Sigmundg, Skarebo, SkerHawx, Skittleys, Smeira, Smyth, Snoyes, SocratesJedi, Solipsist, SpaceFlight89, Spangineer, Specs112, SpiderJon, SpookyMulder, Sporkot, Springnuts, Srinivasasha, StaticGull, Station1, Stephane Simard, Stephen Burnett, Stevenwmccrary58, Stevertigo, Storm Rider, Student1980, Suruena, SyntaxError55, THEN WHO WAS PHONE?, THESHAN, Tabletop, Tackswright, Tangotango, Tanvir Ahmmed, Taraborn, Tartan, Tasoskessaris, Tbackstr, Tclose, Technion, Tetraedycal, Texture, Thatguyflint, The Anome, The Firewall, The Greatest Man That Ever Lived, The Thing That Should Not Be, The Transhumanist (AWB), The undertow, TheRanger, Theirrulez, Theon, Thomaswgc, ThreePD, Thryduulf, Thunder Krieg, Tim bates, Tinkerbell767, Tkn20, Tobias Hoevekamp, Tom harrison, Tom loves snatch, Tom-3124, TomS, Tony1, Tonyjohn84, Transkey, Traxs7, Treisijs, TrigWorks, Trlovejoy, Tshepang, Tunheim, TutterMouse, UberCryxic, Ufim, Useight, User A1, Variable, Vary, Vedhas hirwe, Vegaswikian, Vera Cruz, Versageek, Vikas1234, Villarinho, Vipinhari, Viriditas, Vivers, Vsmith, WadeSimMiser, Walor, Wamman11, Washburnmav, Waveguy, Waycool27, Wdwaltman, Webschem, Welsh, Wik, Wiki alf, Wiki libs, Wikiklrsc, William Avery, Willy, your mate, Wimt, Winengineer, Wispanow, Wizardman, Wknight94, Wstomv, Ww, XMog, Xvn, YahoKa, Yamamoto Ichiro, Yayay, Yerpo, Yhkhoo, Yidisheryid, Yug, Z H J G FR G People, Zlerman, Zuejay, Zulucoast, Zvika, Zzuuzz, Île flottante, ‫یدنقرمس‬, सुभाष राऊत, 1492 anonymous edits Iterative and incremental development Source: http://en.wikipedia.org/w/index.php?oldid=365340907 Contributors: Aamahdys, Aaronbrick, Adeio, Al guy, Alex.ryazantsev, Alistair Cockburn, Alopez6, Ancheta Wis, Antandrus, Bachrach44, Cbuckley, Ceyockey, Cmdrjameson, Cmichael, Conan, David.alex.lamb, Desmay, Domokato, Dutchguilder, Edward, Epbr123, Eric B. and Rakim, Fibula, Flewis, GFLewis, GeorgeBills, Gesslein, Glenn4pr, Guroadrunner, Hobart, Holnet, Jamelan, JimClark, Jj137, Kbdank71, KnightRider, MER-C, Mafutrct, Marek69, Mark Renier, Markyleong, MaxHund, Mboverload, Mdd, Merenta, Michig, Mikaey, Morendil, Moritz, Nawat, Nigosh, Niteowlneils, Offenbach, Oicumayberight, Paul August, Pearle, Radagast83, RedWolf, Rich Farmbrough, Rjwilmsi, Romaine, Sardanaphalus, Sephiroth BCR, Sergiy Kheylyk, Shanemcd, Srice13, Srushe, Stijn Vermeeren, Suruena, TakuyaMurata, Tobias Bergemann, Tslocum, Westerhoff, Whoda, Zhenqinli, 158 anonymous edits Project Management Institute Source: http://en.wikipedia.org/w/index.php?oldid=361524569 Contributors: 4G, Akbradford, Althena, Andanius, Ashwin3813, Centrx, Chowbok, CodeNaked, D6, Danielfhunt, Dead3y3, Dgmoran, Dogcow, DuKot, Eplanetlabs, Exit2DOS2000, Gaius Cornelius, Garrybooker, Gazamanx, Gloy, GraemeMcRae, Gurch, Ilee, Ishe13, JOEY HERNANDEZ, Jhans6135, JimOwensPMP, Kedgemon, Kisstoth, LegitimateAndEvenCompelling, Lundholm, Lwalt, Lwwalker, Lylelylecrocodile, Majorly, Makingprogress19, Martin Rizzo, Mdd, Mkoval, Mollyg3, Mwchicago04, Northstop, Oe1kenobi, Omicronpersei8, Paddy2009, Pegship, PgMP, Pm master, RadioKirk, Rjanag, Ronz, RxS, SNIyer12, Sebastian Wallroth, Seraphimblade, Suelibarroso, Superhuman, Taterbill, The Epopt, TheParanoidOne, Truthanado, TucoBlanco, Wmahan, Wumba, Zalewskimichal, 111 anonymous edits Requirement Source: http://en.wikipedia.org/w/index.php?oldid=364432921 Contributors: 16@r, 9Nak, Aaronbrick, AbsolutDan, Allan McInnes, Andreas Kaufmann, Beetstra, Bigglesjames, BirgitteSB, Bloodshedder, Cassbeth, Cheesy UK, Chocmah, Chris Howard, Danikolt, Dekisugi, Discospinster, Epbr123, Ewlyahoocom, Fernandoacorreia, Furrykef, H-b-g, HappySneezy, Herbee, Ijansch, Ilia Kr., Indon, Iridescent, Jadadad, Jamelan, Janiejones56, JathanBiddlecomb, Jc3, Jpbowen, Katalaveno, KelleyCook, Khalid hassani, Kuru, Lakeworks, Lcg.wda, MPerel, Magioladitis, Mark Renier, Martarius, Mdd, Michael Hardy, Michig, Mjchonoles, Mwfnwa, Nasrani, PedroLamarao, Ph4g3, Pnoble805, Project2501a, Qweedsa, Rich Janis, Robert Weemeyer, Salsb, Samiroy, Shahrome, Shambhaviroy, Shanemcd, Starrymessenger, Strellean, Struway2, Thoughtpod, ThreePD, TimBentley, Triddle, Useight, Vincehk, Wknight94, Wmahan, 124 anonymous edits Operations research Source: http://en.wikipedia.org/w/index.php?oldid=367435467 Contributors: Abkeshvari, Afluegel, Aleenf1, Altenmann, Alterrabe, Amcfreely, Amckern, Andrewpmk, Angus Lepper, AnmaFinotera, Anwar saadat, Arzel, Ask123, BDE, Baa, BarryList, Bdwilliamscraig, Beetstra, BenFrantzDale, Benjaminevans82, Bluezy, Boing! said Zebedee, Borgx, Brianhe, Bsimmons666, Btyner, CRGreathouse, Caliprincess, Canterbury Tail, Cheese Sandwich, Chrislk02, Clemwang, Czyl, D nath1, DXBari, David from Downunder, Deanlaw, Decora, Deor, Dominus, Dralbertomarquez, Dramaturgid, Dungodung, Dysprosia, Dúnadan, EdH, Eddie.willers, Eleusis, Elgrandragon, Encyclops, EnigmaMcmxc, Erkan Yilmaz, Erxnmedia, FTGHSmith, Fastfission, Fieldday-sunday, Formol, G Qian, Galoubet, Giftlite, Gracefool, Gracenotes, GraemeLeggett, Gwrede, Haham hanuka, HanPritcher, Henrygb, Hike395, Homarjun, Hu, Ian Dunster, Ibizzavic, Imajoebob, Isaac.holeman, Iwnbap, Ixfd64, JJL, JamieS93, Jay.Here, Jdpipe, Jimmaths, Jitse Niesen, Jon Awbrey, Joyous!, Jpo, Jredmond, Just Another Dan, Jyoti buet, KenKendall, Khendon, Kiefer.Wolfowitz, Knotwork, Knowledge Incarnate, Koczy, Krj373, Leonard G., LittleOldMe old, Lucidish, Manop, Masoudsa, Matforddavid, Maurreen, Maury Markowitz, Maxsonbd, Mdd, Melcombe, Michael Hardy, Mintleaf, Mnh, Monkeyman, Msh210, Mtrick, Muness, Mydogategodshat, Myleslong, Nelson50, NerdyNSK, Nilmerg, Nnhsky, NorthernCounties, Notreadbyhumans, Novacatz, Oberiko, Obladi, Ohnoitsjamie, Oxymoron83, Penfold, Petrus, Philip Baird Shearer, Philip ea, Pohta ce-am pohtit, Pol098, Protonk, Qwfp, R'n'B, Requestion, Rich Janis, Robin klein, Ronz, RoyBoy, S2000magician, Samansouri, SandyGeorgia, Saxifrage, Shuroo, Sidna, Slakr, Slambo, SueHay, Surendra mohnot, Tabletop, Tbackstr, That Guy, From That Show!, The Anome, TheTechieGeek63, Thewellman, Toddy1, Togo, Trekphiler, Tribaal, Vader07d, Vgy7ujm, VictorK1965, Vignaux, Vocaro, Wally Tharg, WebsterRiver, Welsh, Will Thomas, Williamsrus, Wshun, Wxm29, Wyckyd Sceptre, Xa4, Xn4, Yqwen, Zeno Gantner, Zvika, 278 anonymous edits Risk management Source: http://en.wikipedia.org/w/index.php?oldid=367811922 Contributors: AbsolutDan, Acidtekno, Actuarial disco boy, Actuary, Adang11, Adaveni, Adjusting, Adrius42, Akamad, Aktyagiipr, Alanpc1, Alexius08, Anikasavage, Anna Lincoln, Anon lynx, Anonymous anonymous, Antaeus Feldspar, Antandrus, Antur, Anubhavklal, Ap, Appraiser, Arcadian, ArnoldReinhold, Aschuster, Ash, Astudent, Audrius, Auntof6, Avb, Avraham, Awf206, AxelBoldt, BD2412, BIG4PAPA, Backburner001, Beland, Bill Coffin, Bill.albing, Biscuittin, Blanchardb, Blowdart, Bmi232, BoweryBleecker, Bradingrish, Breno, Brodger3, BrotherFlounder, Bryanhall, Btyner, Budgey99, C-M, CQPress, Carry Lesco, Cerebellum, Charles Matthews, Charlesbaldo, Charnwood, Chinsurance, Ck lostsword, Cliff2311, Codetiger, Collinsr, Conversion script, Corp Vision, Cpk, Craigb81, Craigwb, Crazypete101, Cretog8, Cxbrx, DFLovett, DKoenig, Damistmu, DanielDeibler, Dannyl50, David Smiles, DavidBelew, Davidwikipedia, DeadlyAssassin, Diazfrancisca, Dkeditor, Dkutcher, Dmccreary, DocendoDiscimus, Dolly1313, Donmapua, DoriSmith, Dozen, Dpr, Droll, Dukeofwulf, Dvandeventer, EcoMan, EdBever, Ekotkie, El C, Elizabethkudelasz, Engi08, Epolk, Erie4987, Espoo, Exarion, Excirial, FS riskmgmt, Fastfission, Favonian, Fieldday-sunday, Fijodor, Flyer22, Frankwightman, Frederic Y Bois, Frieda, G. Völcker, GESICC, Gatut, Ghaag, Glen, Gogo Dodo, Greenmars, Gregalton, Gsaup, Gurch, Gwandoya, Hactuary, Hadal, Hauskalainen, Hcpsyuak1, He Who Is, Heartfocus, Hede2000, Heds 1, Hetar, Hgdastoor, Hogayoga, Hu12, IRP, Ialencar, Icairns, Igfrace, Imroy, Inferno, Lord of Penguins, Itemuk, Itskoolman, IvanLanin, J.delanoy, J04n, JRaeside, Jaah21, Jaccowiki, Jafcbs, Jcdowney, JennJifsan, Jennnyyyp, Jerryseinfeld, Jessecisneros, John, John Carter, John Fader, Jonhol, Jons63, Jorgewiki, Jtneill, JubalHarshaw, Jvlock, Jwestland, JzG, Karlwiegand, Katapult99, Kbelltrium, Keilana, KeithJonsn, Kenmckinley, Kenstandfield, Khalid, Kokacola, Krakenflies, Krakfly, Ksyrie, Ktlonergan, Kudret abi, Kuru, Kylealanhale, Kyrriana, Laptopjack, Lawsie, LibLord, Lidram, Light current, Ligulem, Logicmanager, Lucianna8, LyallDNZ, Lyseong, MER-C, Makingprogress19, MansonP, Marek69, Matt.Chojecki, MattieTK, Mattomoran, Mattsmith86, Maurreen, Mbeychok, Mdd, Mdorohovich, MechBrowman, Megadeth186, Michael Hardy, Mikael Häggström, Mkoval, Molly747, MrJones, MrOllie, Muchness, Mwanner, Myasuda, Mydogategodshat, Möchtegern, Nagle, NawlinWiki, Neurolysis, Neutrality, Nicholas Cimini, Nick Green, OAG, Ohnoitsjamie, Olaf, Oleg Alexandrov, Oliverwyman, Open2universe, Overix, P4k, PM Poon, Pakoistinen, Pan Dan, Pcb21, PeterBoun, Pgillingwater, Pgreenfinch, Phaydock, Philip Trueman, PhilippeAntras, Phopkin, Piano non troppo, PigFlu Oink, Pm master, Pndt, PolarYukon, PracticalRiskManager, Proman1, Ps07swt, RMAhq, Radak, Rafael.costa.santos, RainbowOfLight, Raymond23, Rbaker22, Resolute, Riggwelter, Ringbark, RiskWise101, Riskex, Rjwilmsi, Rkitko, Robina Fox, Robinh, Ronz, Ryanmcdaniel, SEI Publications, SafetyTempsLimited, Sam Hocevar, Sandymok, Schwijker, Scientizzle, Seth Nimbosa, SevenSigma, Shadow1, Sharkford, Simesa, Simpleblob, Siroxo, Sjakkalle, Snurks, Sopoforic, Sox First, SpaceFlight89, Spalding, Srathi, Stankir, Supergreg no1, Sweerek, THEN WHO WAS PHONE?, Taxman, That Guy, From That Show!, The Anome, The undertow, Themfromspace, ThreeDee912, Thuja, Tilleyg, Tomisti, Topiarydan, Trivialist, Trout Fisher 03, Trusilver, Ulric1313, Urbanette, Utcursch, Versageek, Vina, Viriditas, Visual risk management, Wavelength, White Trillium, Wik, Wikichops, Wikimaguire, Winchelsea, Wizardman, Wmahan, Wmasterj, Wolfram.Tungsten, Woohookitty, Wtmitchell, Yaparla qatester, Ytiugibma, Yuriybrisk, ZK 41110, Zodon, 664 anonymous edits International Organization for Standardization Source: http://en.wikipedia.org/w/index.php?oldid=367938772 Contributors: -Majestic-, 137.112.129.xxx, 16@r, A-giau, A. B., Aaker, Abdull, Adamlaskey, Addshore, Adoniscik, Aeusoes1, Ahoerstemeier, Ahunt, Akamad, Alex1011, Alexbrn, Altermike, Anastasios, Ancheta Wis, Andycjp, Anjadrame, AnonyPussycat, Ansiansiansi, Ashishbhatnagar72, Autoterm, Azalia1225, BasicBaer, Bazzer palm, Bcordes, Bierstube Katzen Keller, Billdakelski, Binarygal, Binksternet, Blah0401, Bobo192, Bovlb, Brion VIBBER, C0N6R355, CALR, Capricorn42, CaribDigita, Charivari, Chinasaur, Cobi, Conversion script, Coolcaesar, Cprompt, Crazeman, Culverden, Cwass, Cybercobra, DHN, Danieldavidturner76, Danio, Bibliophylax, Dasani, David Gerard, DeadEyeArrow, Delicious carbuncle, Delirium, Denelson83, Denihilonihil, Derek farn, Discospinster, DropDeadGorgias, Dspakman, EEMIV, Eclecticology, Ed Fitzgerald, Egil, Environ1561, Erkan Yilmaz, Evlekis, Ewlyahoocom, Exor674, Finell, Frecklefoot, Frungi, G7046072, Ghakko, Gingekerr, Glenn, Guthardt, Guy Peters, HAl, Haemo, Harish431, Hayden120, Heron, Hervegirod, Hohum, IRbaboon, ISAN-IA, Icairns, Ichwan Palongengi, IndianCow, International Electrotechnical Commission, Irdepesca572, IstvanWolf, J.delanoy, JackLumber, Jacobolus, Jagged, Jbinder, Jeni, Jerry, Jflapointe, Jimp, Joeblakesley, John FitzGerald, John Larmouth, JohnCD, Jon Awbrey, JorgeGG, Joseph Solis in Australia, Jpatokal, Jrats, Jusjih, Justme89, Justwatchme, Jza84, K-car, KTC, Keichwa, Kit.macallister, Knuckles, Koavf, Kozuch, Kusma, Kwamikagami, Kwekubo, Law, Lazulilasher, LeadSongDog, Levic69, Liftarn, Lindum, Lockesdonkey, Looxix, LouI, Lquilter, Luxdormiens, MBisanz, MK, Mac, Mackan, Maikel, Malepheasant, Manop, Martarius, Maximaximax, Mbimmler, MiG, Mindgames11, Minghong, Mjb, Mkoval, Mleinart, Modulatum, MonstaPro, Mr. Billion, MuZemike, Mulligatawny, Nasa-verve, Nick knowles, Nixdorf, Notheruser, Ohconfucius, Olexandr Kravchuk, Olivier, Olrick, Outback the koala, Patrick, PaulHanson, Peter Horn, Plasticlax, Plasticup, Puckly, PuzzletChung, Qwanqwa, R4f, RP9, Ranveig, Rashev, RayGates, Revelian, Rick Jelliffe, Rjwilmsi, Rlsheehan, Rukaribe, SGBailey, Scepia, Sega381, Seidenstud, Shoujun, Sietse Snel, Silica-gel, Slathering, Snoopy99, SomeHuman, Spearhead, Stephan Leeds, Stepho-wrs, Stovetopcookies, Strait, Subversive, Suruena, Svick, The Anome, Thecurran, Theifynia, Thylacoleo, Timothy Cooper, Tinton5, Tobias Conradi, TreasuryTag, Truthanado, UnitedStatesian, Unmerklich, Vargklo, Verbose, VincentV, Vuong Ngan Ha, Wereon, White Cat, Whkoh, Whoisjohngalt, Winklerteen, WirelessMike, Writtenright, WurmWoode, Yamamoto Ichiro, Yaronf, Yk Yk Yk, Yworo, ZooFari, Zorro CX, Zundark, 378 anonymous edits Change control Source: http://en.wikipedia.org/w/index.php?oldid=352746822 Contributors: Alfie66, Alphamu57, Andreas Kaufmann, CharlotteWebb, Craigwb, DRogers, Ddxc, Deb, Folajimi, Gaius Cornelius, Gardar Rurak, GreatWhiteNortherner, Ground Zero, Hittjw, Hydrogen Iodide, Imroy, Jeepday, JonHarder, Josh Parris, Joshplusplus, Jpers36, Jwestland, Kuru, Melchoir, Melesse, Moink, Mollusk7c, Owain.wilson, Paul Richter, Pm master, RJFJR, Rjstott, Rjwilmsi, Rlsheehan, SJWells54, Sarah, Sgonyea, Solidified, Stillnotelf, Thechangegovernor, Voyaging, WECullen, Wleizero, 60 anonymous edits Project management software Source: http://en.wikipedia.org/w/index.php?oldid=364387271 Contributors: 16@r, 4johnny, Achalmeena, Alai, Alanmossman, Alanpc1, Altonbr, Antonmind, Austinm, Babynus, Barcelova, Batsonjay, Bebero22, Benfellows, Bonadea, CWY2190, Can't sleep, clown will eat me, CanisRufus, Captone, Cerrol, Chealer, Chris Roy, Craig t moore,

510

Article Sources and Contributors Cvanhasselt, Danielhegglin, DavidLevinson, Demiane, Denderick, Deville, Dhapp, EPM Enthusiast, EdHubertson, Ehheh, Elena1234, Elwikipedista, Epbr123, Fenevad, Fisherjs, Fishtron, GESICC, Gogo Dodo, GraemeL, Granite07, Hede2000, Hmains, Hu12, Jacktruman, Janbenes, Jeff3000, Jehoshua22, JerryTed, Jo9100, Kaster, Ketiltrout, Kevinmtrowbridge, Kuru, LaurensvanLieshout, Liao, Linkspamremover, Little Mountain 5, Louislong, MadDreamChant, Maurreen, Methossant, Mkoval, MrOllie, [emailprotected], Mwanner, Mydogategodshat, Nakon, Neelix, O18, Oicumayberight, Ojw, Orphan Wiki, Owain.davies, Pako, Paul W, Perfecto, Phelfe, Pm expert, Pm master, Pmtoolbox, Polyparadigm, Professional, Psmcguin, Rdh0930, RedWolf, Renesis, Ronjouch, Rossinglish, S.K., Sam Hocevar, Samaritan, Scjnsn, SharpeSoft, Signalhead, Silverhelm, Sleepyhead81, SpaceFlight89, Specious, Squirepants101, Stephan Leeds, Stevertigo, Stijn Vermeeren, SurfAndSwim, Surfinrhino, Tagishsimon, Tawker, Theo10011, Thingg, Thomas Brandstetter, Timshah, Trout001, Vikerbandt, Viking67, Wgoetsch, Wissons, Wrathchild, 265 anonymous edits Business Source: http://en.wikipedia.org/w/index.php?oldid=367072788 Contributors: -Kerplunk-, 10metreh, 334a, 4I7.4I7, 97parnellj, A8UDI, AaronEJ, Abdullais4u, AbsolutDan, Academic Challenger, Acegenesis, AdjustShift, Adochka, Adrest4, Aeden2, Againme, Agers, Aitambong, Ajeet, Akram1978, Al.locke, Alan Liefting, Alansohn, Alex earlier account, Alexius08, Aliyevramin, Alkiviadis, All Male Action, Allank6, Allen4names, Allstargold, Allthingstoallpeople, Altenmann, AnaLondon, Andoceo, Andre Engels, Andrewharold, Andrewpmk, Andycjp, Anetode, Angela, Angr, Anna Lincoln, Antandrus, Anthony, Anthony Appleyard, Arbitrarily0, Ardonik, Ariaconditzione, Arsene, Arthur Markham, Arthur Rubin, Aryawat, Asimnazar, Audriusa, Auroranorth, Avono, Azmax007, Azzix, BD2412, BSTemple, Bact, Balaam42, Barcelova, Bartledan, Battlecry, Beano, Bebestbe, Beetstra, Belinrahs, Belovedfreak, Bemoeial, BennyQuixote, Blake-, Blanchardb, Blue520, Bobby Ironsights, Bobo192, Bogdan08, Bongwarrior, Boreas231, Bradjamesbrown, Brian0918, Brocky9, Bruguiea, Bsadowski1, BusinessAsUnusual, Businesstopics, CUSENZA Mario, CactusWriter, Caknuck, Calidore Chase, Camw, Can't sleep, clown will eat me, Capricorn42, Capturetheworld, Careless hx, Carnildo, Caseylebaker, Casperdc, Cassandra 73, Catgut, Ccacsmss, Cenarium, Ceo, Chcknwnm, Chennaiseo, Chinneeb, Chuckiesdad, Ckatz, Closedmouth, Closermac, Computerjoe, Conquer 59, Cool Hand Luke, Coolhawks88, Cornellrockey, CorporationBuilder, Covington, Crimz2k8, Ctbolt, Cuecla, Curps, Cyktsui, DMacks, DVD R W, Da monster under your bed, DancingPenguin, Danielspencer91, Darkfight, David Underdown, Davidkazuhiro, Davisftaylor, Dbc06, Dcarafel, Dcoetzee, Ddr, Ddstretch, Degress, Delldot, DerHexer, Derob ecnirp, Deus Ex, DigsPeanuts, Discospinster, DocWatson42, Docu, Dreadstar, Drew R. Smith, Durkalurks, ESkog, Edgar181, Editerdude, Ehheh, El C, Enterprise Guru, Enviroboy, Enzo Aquarius, Epbr123, Eplekake, Eric Chang, Eric Larcher, Eric ausente, Esiegel3, Espen, Essjay, Etlsen, Eugene van der Pijll, Evalowyn, Everyking, Examtester, Excirial, FT2, Faithlessthewonderboy, Faradayplank, Felix116, FelixKaiser, FisherQueen, Fitzkie, Fitzkie1, Flewis, Flutterfly, FocusAndFinish, Foggy Morning, Fplay, Frank, Frankenpuppy, Frecklefoot, Fred Bauder, Fredouil, Frisco21, Fusionmix, Futerica, Fvasconcellos, Gail, Gaius Cornelius, Galoubet, Garfield226, Gavin Kettis!, Geneb1955, Geof, Georgiakatopodis, Georgieboi123, GetPhunk, Gilliam, Gimme danger, Girolamo Savonarola, Glenn, Gobonobo, Gogo Dodo, Goodoldpolonius2, GraemeL, Guy Peters, Gwernol, Gwyndon, Haakon, Hadal, Halojoe94, Haza-w, Hclim65, Hdt83, Heightwatcher, Hellraiser160791, Henning Wiekhorst, Henrik, Hephaestos, HereToHelp, Heron, Hezarfenn, Hhalladay, Hmrox, Hohoho1, Hojimachong, Hopiakuta, Houseofcosby, Hu12, IRP, Icairns, Imran, Imrek, Insanephantom, Insomanic, Interestingstuffadder, Iridescent, Ironholds, IslandHopper973, Istartfires, Iterator12n, J.delanoy, JAn Dudík, JD554, JForget, Ja 62, JaGa, Jackofwiki, Jackp, Jackp11213, James086, JamesWalker-ntu, Jamiemilbourne, Jareha, Jay, Jeffrey Mall, Jerryseinfeld, Jiang, Jim Douglas, JimVC3, Jj137, Jni, John, JohnCD, JohnDoe0007, JohnOwens, Joka, Jonny-mt, Jonovision, Jorunn, Jose77, Joshn3, JoshuaZ, Jossi, Jukcoder, Jummai, Jurusie, KFP, Kabad2008, Kaihsu, Kanehdian, Kangphil, Karl-Henner, Karnesky, Kashi0341, Kasschei, Kate GRERPLE, Kazun, Keilana, Kelly Martin, Kelvinwkw, KenKendall, Khan sumon, Khatru2, Khoikhoi, Khukri, Kiand, Killiondude, Kingpin13, KissL, Kotniski, Kozuch, Kpharvey1, Krakfly, Krawi, Krukouski, Krupo, Kubigula, Kungfuadam, Kuru, L0b0t, LZFVBNM, La Pianista, LaggedOnUser, Lamaar, Lamb99, Larry Lawrence, Lbunited, Ldklippert, Lear's Fool, LeeG, Levineps, Lewis-teck, Lights, Limimim, Limit0, Linkspamremover, Llamadog903, Logical8, Lolb^u, Longhair, Lordddraconius, Loren.wilton, LouGeorge, LouI, Lradrama, Luapnampahc, Luinwe, Luk, Luna Santin, MER-C, MONGO, Mac Davis, Madchester, Magnuschubb, Malo, MarceloB, MarkSutton, Martarius, Martin Jensen, Martin451, Matt Crypto, Matthew238, Maurreen, Maxim, Maximus Rex, Maxis ftw, Mayumashu, Mcbumnugit, Mejor Los Indios, MeltBanana, Mendaliv, Mendel, Meursault2004, Mic, Michael Snow, Midnightcomm, Mike 7, Mike Omaley, Miketear27, Millahnna, MisfitToys, Mkoval, Moonriddengirl, Moris43, Mr Stephen, MrOllie, Mthampi, Muchness, Muppet317, Muriel Gottrop, Mwalimu59, Mydogategodshat, Nagy, Nancylyy, NawlinWiki, Ndkartik, Nerijus valskis, Nerval, Netoholic, Neverquick, NewEnglandYankee, Nicholas Tam, Nigholith, Nightsturm, Nikai, Ninja43, Nmacpherson, Notinasnaid, Nsaa, NuclearWarfare, Nurg, Nuttycoconut, ObjectivityAlways, Oblomoff, Oda Mari, Ohnoitsjamie, Olathe, Old Moonraker, Oleg Alexandrov, Olegwiki, Olexandr Kravchuk, Omaha11, Omicronpersei8, Omm nom nom nom, Omoide, Oneiros, Onorem, OpenTheWindows, Optimale, Oraclelocal, Orgwiki, Oslolso, Otisjimmy1, Otolemur crassicaudatus, Owen, PGPirate, Paintman, Palladmial, PamD, Pamri, Parmarossa, Passportguy, Passw0rd, Patrick, PatrickFlaherty, Patstuart, Patxunan, Paul August, Pavel Vozenilek, Pax:Vobiscum, Paxse, Pb30, Pdogsi, Pedant17, Pedro, Pegship, Peshko, Ph.D.Nikki, Phantomsteve, Philip Trueman, Phoebe, PiMaster3, Piano non troppo, Pingpongkyle, Pinkadelica, Plinkit, Pmw1007, Pobably, Poeloq, Pol098, Poohpooh817, Poor Yorick, Poweroid, Ppntori, Ppokrie, Prolog, Prototime, Psy guy, Questionaire99, REDyellowGreenBLUE, RJII, RJN, RadioKirk, RanchoRosco, Ratherhaveaheart, RazorICE, Reconsider the static, RedHillian, Redsome, Remi0o, RexNL, Rfc1394, Rgvandewalker, Rhobite, Rich257, Richard D. LeCour, RichardF, Rick Block, Rm w a vu, RobLa, Rocket976, Roni you, Ronniefaron, Ronreed, Rossami, Royli57, RxS, SCEhardt, SUL, Sachindole, Salasks, Samwisedagr8, Sango123, Sanjaymca, Sannse, SarahJBull, Sarahviolin, Scaletrix man, SchfiftyThree, Scriberius, Secretlondon, Selmo, Sgtslash93, Shadowjams, Sharpsage, Shatrughan, Shishir.krs, Shlomke, Sid007, Silsor, SimonP, SineWave, Skidude9950, Sloose, Smallman12q, Smappy, Smilesfozwood, Smitty, Snowolf, Socs, Sokker30, Sophie, Sourabhchopra, Spersily, Spiritualism, Sprachpfleger, Spudmuffin, Srushe, StaticGull, Stepbigboss, Stephenb, Stevertigo, SueHay, Sumimu, SuperHamster, SvenAERTS, Svick, THEN WHO WAS PHONE?, TachyonP, Taggard, Tallcitikid, Tannin, TastyPoutine, Tbb9216, Ted Longstaffe, Tehsilvercock, Teleszczupak, Templarion, Tempodivalse, Tgv8925, Tharshman, Thatguyflint, The Nut, The Original Economist, The Rambling Man, The Thing That Should Not Be, The Transhumanist, The Transhumanist (AWB), TheBusinessCoach, Thebigpalooka, Thehappyjew, Tide rolls, Tim Song, Timmothias, Tiptopmovie, Tnxman307, Todd Vierling, Tombomp, Tony Fox, Transity, Traxs7, Trusilver, Twooars, Tyir, Tzartzam, USCFE, Uncemaster3000, Uncle Dick, Universalpayroll, Useight, Utcursch, Valerie Funderburg, Veinor, Versus22, Vipul pratap, Vman475, Walden, Walor, WarthogDemon, Wavelength, Weregerbil, Wgoetsch, Whatifound, Whiner01, Why Not A Duck, WikiGee, WikiLaurent, Wikidestroyer114, Wikihater114, Wikikiller65, Williambeaufoy, Willking1979, Windrunr, Wise Willie, Wizardman, Xhaoz, Yangyang2036, Yansa, Ybbor, Yhkhoo, Yidisheryid, Yintan, Zafiroblue05, ZimZalaBim, Zitie, Zragon, Zundark, Zvn, Zzuuzz, 百家姓之四, 1190 anonymous edits Goal Source: http://en.wikipedia.org/w/index.php?oldid=366772695 Contributors: 1945AlphaTeam, 2D, ABF, AdjustShift, Alansohn, Alexaangelo, AndonicO, Avnjay, Beetstra, Bhimaji, Bradeos Graphon, CHJL, Calmer Waters, Carabinieri, Catgut, Chldngur5, Closedmouth, Comm&emotion, DSParillo, Dreaded Walrus, Edmund1989, Ehheh, Eisfbnore, Enepunto, Epbr123, Faradayplank, Favonian, Fellowsmicroban, Fieldday-sunday, Fullofinformation, Galoubet, Geniac, Grandia01, Gwernol, Hqb, Hu12, Hubschrauber729, Isotelesis, J. Spencer, J.delanoy, J04n, Jminthorne, Killiondude, Komischn, La Pianista, Landon1980, Lotje, Love Krittaya, Luna Santin, MBisanz, MER-C, Malik Shabazz, Marccarter123, Marek69, Martin451, Materialscientist, Mdd, Mladifilozof, Mpfk, MrOllie, Noctibus, Overviewer, OwenBlacker, Parademan, Pedant17, Piano non troppo, Pinethicket, Pitlane02, Raysecurity, Rejectwater, Robykiwi, Rxever, Sdornan, ShelfSkewed, SlackerMom, Steven J. Anderson, Sue Gardner, The Transhumanist, The world deserves the truth, Tide rolls, Tiuks, Traxs7, TubularWorld, Veinor, Versus22, Vlad, Wavelength, With goodness in mind, XxTimberlakexx, Zemoxian, Zodon, Zzyzx11, 161 anonymous edits Dynamic Systems Development Method Source: http://en.wikipedia.org/w/index.php?oldid=364656708 Contributors: Andreas Kaufmann, Aternity, Attilios, Avant Guard, Babomb, Bbent, Bblackmoor, Bluemoose, Capricorn42, Chris Howard, ChrisG, Coherers, Debracaldow, Dekisugi, Dreadstar, Elwikipedista, Face, Fluffykryptonite, GFLewis, Gonzalezmorales, Greyskinnedboy, Gurch, Hyju, Ice-Soft-Eng, J.delanoy, Jaqen, JimD, Jpbowen, Kbdank71, Khalid hassani, Khargett dk, Kku, Littlesal, Lumos3, Mahanchian, Manushand, Mattmm, Mdd, Mercurysjm1, Moonriddengirl, Movito, N8mills, NetProphET, Nigosh, Niteowlneils, Palfrey, Paul Foxworthy, Peterhgregory, RJFJR, Redvers, Reecevdm, Rjwilmsi, Robertvan1, Rugops, Rwwww, Scottbell, Semafore, Simonbooth, Sky Diva, Smartse, Swijaya, TheTito, Ufinne, Van der Hoorn, Vgiralt, WereSpielChequers, Wx8, YordanGeorgiev, Zeno Gantner, 151 anonymous edits Product (business) Source: http://en.wikipedia.org/w/index.php?oldid=366666546 Contributors: 7, A3RO, AdnanSa, Agathoclea, Ahouseholder, Alania14, Alias777, Allstarecho, Alveolate, Amnesiac86, Appleseed, Beland, BiteComms, Bloodshedder, Blue Pixel, Bobo192, Busy Stubber, Bwithh, Carajou, Cfsenel, Cherylb, Chris the speller, Cnbrb, Comp8956, Coolcaesar, Devper94, Dom Padden, Dzied Bulbash, Egon Eagle, Epbr123, Fail, Ferengi, Fieldday-sunday, Fredsmith2, Fromedessa, Futureobservatory, GHe, Gidonb, Giraffedata, Glenn, Greudin, Greyskinnedboy, Gurch, Gurlukovich, Hakan Uğur, HammerHeadHuman, Henrymrx, Hohum, Hotcrocodile, Hyacinth, Ian Pitchford, IceKarma, Ikonoblast, Iterator12n, Ixfd64, J04n, JRHorse, JamesBWatson, Jim.henderson, KaiSeun, Kingpin13, Knuckles sonic8, Kozuch, Kwamikagami, Layonard, LeoNomis, Levineps, Lfratilla, MER-C, Magdach, Masterpiece2000, MauriceMB, Maurreen, Mikeo, Mkoval, Mr seo writer, MrOllie, Muchness, Mydogategodshat, Ncmvocalist, Nick UA, Nixeagle, Onevalefan, Periscope123, Peterlewis, Piano non troppo, Pion, Pizza Puzzle, Quoth, Qxz, Radiojon, Randommouse, Reconsider the static, Ricketgt, Rob Hooft, Ronz, Roscoe x, SJP, SRE.K.A.L.24, Sam mishra, Sarah777, Sectryan, Sesshomaru, Shoessss, Signalhead, Silsor, Sinuhe, Smsarmad, Softbiz, Spinacia, Stanislav87, Svenboatbuilder, TOR, Taka, The Thing That Should Not Be, Theleftorium, Tide rolls, TigerShark, Tinton5, VeryVerily, Vikas jain59, Washdivad, Wavelength, Wayiran, Welsh, West.andrew.g, Wiki alf, WikipedianMarlith, Windharp, Wine Guy, Wlodzimierz, Wossi, Xezbeth, ZimZalaBim, Zoe, Zundark, 244 anonymous edits Marketing Source: http://en.wikipedia.org/w/index.php?oldid=367917820 Contributors: 032gavmal, 16@r, 1B6, 7luigi7, A purple wikiuser, A. B., A3RO, A8UDI, ACDJ, AHAHA123, AJD, Aapo Laitinen, Abhigo86, Abhinav201, Abrech, Abritek, Academic Challenger, Accounting4Taste, Acewolf359, Ackees, Acpeacoc, AdjustShift, Adnandx, Adrianfleming, AeonicOmega, Aervanath, AgainErick, Agricmarketing, Ahoerstemeier, Ais.bul, Aitias, Akirn, Akol, Alan Au, Alansohn, AlefZet, Alex.g, Alex.muller, Alex43223, AlexandrDmitri, Allstarecho, Alsandro, Altenmann, Amatulic, Amberine, AmoebaMan, AndonicO, Andres, AndrewHowse, AndrewTLM, Andreworkney, Andrewpmk, Andrewspencer, AndriuZ, Android Mouse, Andycjp, Angela, Anita Burr, Anna Lincoln, AnnalisaShanghai, Antandrus, Antoncampos, Antonio Lopez, Anup1965, Aparcher, Apparition11, Aquatics, Ardavanv, ArglebargleIV, Artemis10000, Asboog, Ascobb, Aspireinernational, Atifk, Avernet, Avocado kebab, Azwhole, B1atv, Bangersandmash, Baraka bls, Barek, Bart133, Basawala, Batmunkh, Bcecka, Bearian, Beetstra, Bemoeial, Benauld345, Betelgeuse, Biguangying, Bijupillai, Bill.albing, Binary TSO, Birigogos, Bksikdar, Blainster, BlazerKnight, Blue520, Blueronin, Bobo192, Bobtrothphd, Bogdangiusca, Bogey97, Bonadea, BorgQueen, Borgx, Bovlb, Bradhenry, Bradley Holt, Brandalone, Breaker-One, Brian Norris, Budapestkave, Bullzeye, BusinessAssyst, Busy Stubber, Bwfoster, Byronsharp, CIreland, Cabanaman, Cacycle, CallamRodya, Caltas, Cameron Dewe, Can't sleep, clown will eat me, Cansem, CapitalR, Capricorn42, Careless hx, CarlFink, Carnildo, Carrie77, CaseyPenk, Cassman, Catgut, Cdc, Centrx, Chanakal, Changchih228, ChannelsGuy, Chanterele, Chapultepec, Charles KnNell, Charlesrwright, Chhatrasal007, ChildofMidnight, ChiragPatnaik, Chiragiscotha, Chistiana George, Chocolateboy, Chris 73, Chris G, Chris Ulbrich, Chrispreece2007, Chuq, Ck lostsword, Ckatz, ClaytonCL, Click23, CliffC, Closedmouth, CloudNine, Cloudtracer, Cmdrjameson, Coffee, Coju, Colonies Chris, Coltera, Cometstyles, CommodiCast, ConMan, Conorobradaigh, Conti, Coold00d, Corydobbs, Coutcin, CowHoe, Cpl Syx, Cquan, Crocodile Punter, Cronium, Cryout, CryptoDerk, Cst17, Cumulus (usurped), CyclePat, Cyfal, Cyrus Grisham, Czmtzc, DDerby, DJ Clayworth, DMG413, Da monster under your bed, DaGizza, Daf, Damicatz, Dana Mason, Dancefreak76, Danlev, Darkfrog24, DaveDuarte, Davemcarlson, Daveswagon, David Breth & Associates, David Massumi, David Scorpio, DavidMarciano, DavidMatthews44, Dballantyne, Dcesarini, Dcflyer, Dcheagle, Dcizk, Dean 785, DecklessChirag, Defekt7x, Dekisugi, Deli nk, Delicious carbuncle, Delldot, Delonline, Delpino, Denisutku, Dennywuh, DerHexer, Desiblah, Dev.budhiraja, Devil munna, Dezignr, Dian0111, Digimon14, Dilipcupstop, Dinosaurdarrell, Discospinster, Dividing, DocWatson42, Dorimedont, Douglaseberger, Dougofborg, Dq335514,

511

Article Sources and Contributors DragonflySixtyseven, Dreadstar, Dreftymac, Drucker1900, Drum guy, Dtodd, Durkalurks, Dylan620, E. Ripley, ERcheck, Earlkohn, Edconcarni, Editor br, Edward321, Egyptianholiday, Ek elwing, El C, Elassint, Eliza funk, Elwood64151, Emailgec, Encephalon, Epbr123, EsheleD, Euryalus, Eva kreienkamp, Everyking, Excirial, FX-6, Fairsing, Falcon8765, Fastfwdx2, FatalError, Fbooth, Feahl08, Feco, FelineAvenger, Finlay McWalter, FlavrSavr, Flewis, Flowerparty, FlyingToaster, Fnfd, Fourmiz59, Fourohfour, Franciscrot, Franco3450, Francs2000, Frankie0607, Freckles.10.6.2005, Fredrik, Frehley, FreplySpang, Futureobservatory, Fvw, Gary D, Garyruskin, Gen6k, Gene Lieb, Geni, Ggurumohan, Ghormax, Gilliam, Gimmetrow, Glenn, Glenn Koenig, Glisenti, Gogo Dodo, Gp93, GraemeL, Gravecat, Gregh, GregorAnton, GregorB, Greudin, Grochim, Grunt, Gscshoyru, Gunsmith, Gurch, GuyRo, Gwernol, Gyokomura, Gökhan, H Bruthzoo, H ackerman005, HR DORA, Haakon, Hadal, Hamiltro, Hayne, HelenGold, Hezink8, High Elf, Hiyaoooo, Hmwith, Hobartimus, Hollih, Horoshi1820, Hotlorp, Huntthetroll, Husond, Hut 8.5, Iamdalto, Ihcoyc, Ike9898, Ikonoblast, IncognitoErgoSum, Infoapex, Inwind, Iris lorain, Irjesusbiatch, Isabelking, Isogolem, Ixfd64, J Di, J. Nguyen, J.delanoy, JForget, JHMM13, JNW, JaGa, Jag100, Jake Wartenberg, Jamesontai, Jardinessardine, JarlaxleArtemis, Jason Leach, Jasviru, Jazzeur, Jbuddle, Jcbrd, Jdrewitt, Jeff G., Jeffnaz, Jehochman, JerLlo, JeremyA, Jersey Devil, Jim Sterne, JimSym, Jinxed, Jlao04, Joebloggs1234567, John Pretty 1, John Quiggin, John Reaves, JohnGriffinLatimer, JohnOwens, Jojit fb, Jon Shl, Jonas August, Joshua, Joveblue, Jowe84, Juggernaut316, Jusdafax, Just James, Justinfr, Jvdwalt, Jychao, Kaabi, Kablammo, Kameir, Kangphil, Kanonkas, Karto, Katalaveno, Kazrak, Kbh3rd, Kcnonfiction, Keilana, Kenneth M Burke, Khalid hassani, Kimbayne, Kingpin13, Klemen Kocjancic, Krawi, Krith23, Kruchka, Kuru, Kuyabribri, Kuzaar, Kuzmo, Kylie perry, Kyriakos, L'Aquatique, LaMenta3, Lafiedler, Lambertb, LazyFox, Lcb30075, Learningtousewiki, Leedeth, Lehi53, Leliro19, Lenor hesky, Leopoldogomez, LeroyWilkins, Leuko, Levineps, Lights, LittleDan, LittleOldMe, Livitup, LizardJr8, Lollerskates, Longhair, Lordmac, Loren.wilton, Louern, Lourdes0717, Lu Wunsch-Rolshoven, Luckyz, Lucyin, LuigiManiac, Lumos3, M3taphysical, MER-C, MZMcBride, MacMed, Macadon, MadAboutMarketing, Madhero88, Maksdo, Mallika nawal, MalwareSmarts, Mancunius, Mandelman, Maneuveringthought, Maniktushar, Mantality, Marcje, Mardus, Mariokempes, Markerting consultant, Marketing professor, Marketing64, MarketingWizard, Marketingman1, Masterpiece2000, MattieTK, Maurreen, Mav, Maven111, Max Naylor, Maybethisnamewontgetblockedall thetime, Mboverload, McSly, Mdebets, Meaghan, Mediathink, Meeples, Mephistophelian, Mg0314b, Michael Hardy, Michael Snow, Michaelfavia, Michaelmoran, MidgleyDJ, Mig21fishbed, Mike Rosoft, Million Moments, Mindmajick, Minghong, Mini-Geek, Mjwalshe, Mlease, Moenada, Monkeyman, Monotonehell, MoogleEXE, Mooreseo, Mosca, Mouse Nightshirt, MrOllie, Msharaiha, Munazanjum, Myanw, Mycatharsis, Mydogategodshat, Mykej, Mythdon, N2e, N5iln, Nabler, Nacres, Nakon, NarSakSasLee, Natewrite, NawlinWiki, Nburden, Needles27, Nemesis of Reason, Netsnipe, Nicholas Drayer, NickBarrowman, Nifky?, NightFalcon90909, Niloobushweller, Nivelh, No Parking, Noctibus, Notapennymore, Nrcjersey, Nubin wiki, Nuttycoconut, Odie5533, Ohnoitsjamie, Oicumayberight, Ojigiri, Oleg Alexandrov, Olly150, Omicronpersei8, Onorem, Operativem, Optakeover, Optimization, Orphan Wiki, Oscara, Otolemur crassicaudatus, OverlordQ, OwenX, Oxinabox, Oxymoron83, Paddles, Pandaplodder, Pankaj.multimedia, PapaWhitman, PaterMcFly, Patrick, PatrickFlaherty, Paul Magnussen, Paul1000, Paulinho28, Pavel Vozenilek, Pedapod, Pedro, Peschomd, Peter Lawless, PeterSymonds, Pezzzer, Phaedriel, Phantomsteve, PhilKnight, Philip Trueman, Philippe31, Piano non troppo, Pill, Pixelface, Plinkit, Pmauchard, Pnautilus, Poccil, Pogogunner, Poor Yorick, Populus, Portgame, Preetam purbia, Presario3000, ProcureNET, Prodman121, PromotionalCurrency, Ptdecker, Pulkit bajaj, Quadell, Qwerty Binary, Qxz, RUL3R, RadRafe, RadioFan2 (usurped), RainbowOfLight, Ramu50, Random contributor, Rasmus Faber, Realkyhick, Redvers, Reedy, Rege, Retinarow, Rettetast, ReviewDude, RexNL, Rfzaman, Riana, Rich Farmbrough, Richard D. LeCour, Richard0612, RichardF, Rick Block, Rintrah, Rjcain, Rjette, Rjwilmsi, Rkaminsky, Rlsheehan, Robertson-Glasgow, RoboAction, Robowurmz, Rogerthat, Rohan Jayasekera, Ron prince51, Ronz, Rotem Dan, Rrburke, Rrc2soft, Runewiki777, Ryan Postlethwaite, S3000, SJP, SMC, SNowwis, SWAdair, Sachintellusys, Saga City, Sakaa, Sam mishra, Sammie hou, Sandman888, Sanjeev.rbs.edu, Sanwar, Sarper, Sceptre, SchfiftyThree, Schlinkdizzle, SchubertCommunications, Sciurinæ, Scorpion agency, Sdbmaranello, Sdornan, Sdudah, Se91an, Semitransgenic, Sengkang, Sephiroth BCR, Serein (renamed because of SUL), Sesu Prime, SevDrape, Shadowjams, Shally87, Shanes, Shengii, Shirarae, Silverxxx, SimonP, SineSoftware, SiobhanHansa, SirTwitch, Skeezix1000, Skew-t, Skunkboy74, SkydiveMike, Slakr, Slaphappy, Smalljim, Smashville, Smucoxweb, Snezzy, Snghmiranda, So-eZ, SoLando, SoLxStephen, Softbiz, Solipsist, Somedoodfromtheqoob, Soosed, Sopher99, Soyweiser, Sp, Sp3, SpaceFlight89, Spellcast, Spencerk, Spinacia, Spitfire, Springnuts, Srleffler, Startist777, SteinbDJ, Stellis, Stephanspencer, Stephchristie, Stephen C. Carlson, Stephenb, Stephenbez, Stephenginns, Steve simple, Steven Zhang, Stevertigo, Stk006, Strongsauce, Studio1st, Studiobanks, Stui, Sturm55, Sunsfan1797, Super-Magician, SuperLuigi31, Suruena, Susan118, Svenceone, Svetovid, T2 studios, T5741, TAMilo, TFoxton, THEN WHO WAS PHONE?, TKD, Tabrez, Tainted Sausage, Tamás Kádár, Tao of tyler, Tarret, TastyPoutine, Tawker, Tbhotch, Tbonejoo, Tedder, Teejay17, Telenet, Tempodivalse, TenPoundHammer, TerryForsey, Tetracube, Thatguyflint, The Anome, The Gaffer, The Thing That Should Not Be, The Transhumanist (AWB), The undertow, TheGrimReaper NS, Thekohser, Themoose20, Thingg, Think outside the box, Thiseye, Thom0711, Tide rolls, Tiffany.Remo, Tilla, Tiptoety, Titansolaris, Toby Desforges, Tom, Tomayres, Tommy2010, Topspeedracer, TravisAF, Traxs7, Tregoweth, Trelawnie, Trevor MacInnis, Tricky Victoria, Triona, Tschick11, Tslocum, Tucaz, Twaz, TwinnedChimera, Tyw7, Tzartzam, USMarketingGuy, Ukexpat, Uncle G, VI, VISHAL DESAI, VMS Mosaic, Van helsing, Veinor, Velen117, Versageek, Versus22, VerticalDrop, Vikingstad, Violetriga, Vipinhari, Viridae, Vishnava, Vision Thing, Vodu, Vogue99, Vyceron, Wackymacs, WadeSimMiser, Wafulz, Wahoona, Walkerpercy, Wardizzy2, WarthogDemon, Washburnmav, Wavelength, WebRank, Weeliljimmy, Westendgirl, Wewe100, Wgardner, White Agent, Wik, Wiki Raja, Wiki World, Wiki alf, WikiLaurent, Wikiklrsc, Wikiman01, William Avery, Williamsrus, Wine Guy, WinterSpw, Wireweb, Wkoleszar, Wmahan, Woohookitty, Workman, Woz2, Wuhwuzdat, X!, Xenacn, Xyzzyplugh, Yamamoto Ichiro, Ydriuf, Yeajilike, Yhkhoo, Yidisheryid, Yintan, Ywimc, Zaid Ibrahim, Zdravko mk, Zigo1232, Zip3, Zundark, Zvika, Zzuuzz, 2531 anonymous edits System Source: http://en.wikipedia.org/w/index.php?oldid=367278088 Contributors: .:Ajvol:., 16@r, 64200a, 7195Prof, A Macedonian, AbsolutDan, Adam78, Aesopos, Aimak, Alansohn, Alerante, Alink, Altenmann, Amalas, Amayoral, AnakngAraw, Ancheta Wis, Anclation, AndonicO, AndriuZ, Antandrus, Anwar saadat, AprilSKelly, Arendedwinter, Arthur Rubin, Ashley Thomas, Bajjoblaster, Blazotron, Bobo192, Boccobrock, Bolan.Mike, Bomac, Bonadea, Bonaparte, BradBeattie, Brichcja, BrokenSegue, Bry9000, CJLL Wright, COMPATT, CX, Campjacob, Cenarium, Cerber, Charlesverdon, Chasingsol, Chris cardillo, Chung33, Ckatz, Compfun, Coppertwig, Countincr, Crissidancer88, D. Recorder, DSRH, DVD R W, DabMachine, Daniellemonkey64, Darth Panda, Denys, DerHexer, DocWatson42, Dominus, Dpv, EdC, Efe, Eliyak, Ely ely82, Epbr123, Equilibrioception, Erebus555, Erick.Antezana, Erkan Yilmaz, Evercat, Evilphoenix, Fanra, Feinoha, Fenice, Filemon, FlyHigh, Fresheneesz, Frongle, Frymaster, Fvw, GPHemsley, Galoubet, Giftlite, Glenn, Globalanarchist, Graham Berrisford, Grubber, Grunt, Headbomb, Helix84, Hetar, HisSpaceResearch, Husond, Hveziris, IZAK, Iancarter, Informatwr, Iwillgoslow3126, J.delanoy, J04n, Jackfork, Jcs2006, Jez104, Jgd9, Jiang, Jojhutton, Josh Parris, Jossi, Joymmart, Jpbowen, Jrgetsin, Jtneill, Justin1234345, Jwdietrich2, Kak Language, Kazakmike, Kazooou, Kevin B12, Kevin Baas, Khatru2, Klenod, KnowledgeOfSelf, La goutte de pluie, Lammidhania, LeaveSleaves, Levineps, Lexor, Lightmouse, LtNOWIS, Luckyz, Luna Santin, MGTom, Majimbulok, Mange01, Mani1, Manuelkuhs, Marc Venot, Marek69, Maxí, Mdd, MellifluousMelt, Mentifisto, Michael Hardy, MichaelBillington, Mike Cline, Miriel, Mkoval, Mkoyle, Nahtmmm, NatusRoma, Newscript, Niemeyerstein en, Nihil novi, Normxxx, Octahedron80, Oddeivind, OliviaGuest, Optikos, Ordermaven, Orgwiki, Orphic, Ott, Patho, Patrick, Pde, Phanerozoic, Phil Sandifer, Philwelch, Photouploadrr, Pmagrass, Qst, Quester67, R'n'B, Ram4eva, Ratjed, Rdsmith4, Reddi, Res2216firestar, RexNL, RichardF, Rjm at sleepers, RoyBoy, S Roper, ST47, Samuel Curtis, Schmei, SchnitzelMannGreek, ScierGuy, Scott Gall, Sevilledade, Sholto Maud, Sidna, Simoes, Simply south, Smjg, Snek01, Snowmanradio, Someguy1221, Soulwork, SpaceFlight89, SpikeToronto, SpookyMulder, StaticVision, Steven J. Anderson, Stevertigo, StradivariusTV, Strait, Sunray, Surfer2233, Thanatos666, The Anome, Thseamon, Tiddly Tom, Tide rolls, TobyJ, Tobyw87, TowerDragon, Tporter2010, Treisijs, Trevor MacInnis, Vapier, Vlaton, Wiccan Quagga, Wmahan, Wolfkeeper, Woohookitty, Xdcdx, Xtifr, Xyzzyplugh, Yidisheryid, Yixiel, Zachlipton, Zeneka, Zntrip, Zzuuzz, Александър, Милан Јелисавчић, 320 anonymous edits Change management Source: http://en.wikipedia.org/w/index.php?oldid=367677692 Contributors: ARUNKUMAR P.R, Alansohn, Alison9, Anto101211, Barek, Bduafala, ChristianBk, Giraffedata, Gsschweppe, Hu12, Jeremy Visser, Joshplusplus, KConWiki, Kku, Levineps, Linforest, Mantik1987, Misterx2000, Pilgaard, Pm master, Rick Wolfe, Rjwilmsi, Sabri76, Technobadger, Tema, VMS Mosaic, Vacio, 58 anonymous edits Software development Source: http://en.wikipedia.org/w/index.php?oldid=366523858 Contributors: 16@r, Abtract, Academic Challenger, Agile blog, Agileinfosystems, Al Lemos, Allan McInnes, Andreas Kaufmann, Anna Lincoln, Arupgarai2004, Ateso, Bart33, Belovedfreak, Boing! said Zebedee, Bonadea, BrainyBabe, Can You Prove That You're Human, Chonglongchoo, ChrisLoosley, Chzz, Ckatz, Cnbrb, Cotttho, DRogers, Dan Polansky, Derek farn, Diljaipur, Dinkd, Dobbin2000, Dv82matt, Eastlaw, EddyVanderlinden, Eneuron.in, FatalError, Fieldday-sunday, Galoubet, GeorgeBills, Glapu, Gogo Dodo, Gwernol, Hzhbcl, J.delanoy, J04n, Josh the Nerd, Kku, Korvin2050, Kwiki, Lababidi, Lichenliang86, MER-C, Magioladitis, Malviya.vinay, Matacob, Mausy5043, Mdd, Michig, MikeDogma, Mindmatrix, MrOllie, NeilN, Notheruser, NovaDog, NuclearWarfare, Ohnoitsjamie, Oicumayberight, OlEnglish, Onlygains, Paul.teag, Petra.hegarty, Piano non troppo, RHaworth, Rameek12, Randomalious, Raysecurity, Richard R White, Rodasmith, Root123, Rwwww, Samansouri, Sardanaphalus, SpikeToronto, Suruena, Tonyshan, TubbyCat, Unionhawk, Valafar, Versageek, Vinhtantran, Wiretse, Yosri, Zhenqinli, ZimZalaBim, 110 anonymous edits Management Source: http://en.wikipedia.org/w/index.php?oldid=367349664 Contributors: $nake420, 10metreh, 7195Prof, Abj1, Acerperi, Aedelcid, Aj.metcalf, AjaxSmack, Akanemoto, Alansohn, Alex Bakharev, Alexf, Alliance09, Alnokta, Altenmann, Alybongo, Amartyabag, Amire80, AnakngAraw, Ancheta Wis, AndonicO, AndriuZ, Andycjp, Aniu, Anna Lincoln, Anshuk, Antonrojo, Anuchit, Ap, Arthur Rubin, Arthuro, Astuishin, Backslash Forwardslash, Bagatelle, Baiter, Barras, Blanchardb, Blathnaid, Blaxthos, Bluerasberry, Bolan.Mike, Boringmondays, Borisblue, Brianga, Brossow, Brougham96, Bsca, Btilm, Bubba hotep, Burkhard, Bvsr prasad, COMPFUNK2, CUBJONES83, CUSENZA Mario, Cacycle, Cagarland, CambridgeBayWeather, Can't sleep, clown will eat me, Canterbury Tail, Captain-tucker, Caravaca, Carlamariek, Ceo, Cflm001, Champaign, Changchih228, ChangeManager, Chaos, Che y Marijuana, Cheapskate08, Cherry blossom tree, Chick Bowen, Chrislk02, ChristophMichel, Chuunen Baka, Ckatz, Clerks, Closedmouth, Closermac, Coaching Professional, Codetiger, Codrdan, Coffee, Cometstyles, CommodiCast, Conversion script, Curps, Czalex, D4nz, DMacks, Da monster under your bed, Daanj, Dan writerwiki, Danis, Dark Mage, David.Mestel, Dcarafel, DeadlyAssassin, December21st2012Freak, Deeptrivia, Deli nk, Denisutku, DerHexer, Dhollm, Discospinster, Doanmanhtung.sc, DocWatson42, DorisH, Dougiel, DouglasGreen, Doulos Christos, Dr Aaij, DrStrangeLove, Dragonjohann, Drbobr19, Dreadstar, Dreispt, Dtremenak, Dycedarg, E Wing, Edhubbard, Ehheh, El C, Enchanter, Enviroboy, Epbr123, Erfa, Erkan Yilmaz, Eskimospy, Estudiarme, Exert, Falcon8765, Fbooth, FelixKaiser, Finell, Finngall, Firien, Floridian06, Fluri, FrankTobia, Frankenpuppy, Frecklefoot, Fredrik, Fvasconcellos, GB fan, GJeffery, Ganeshnarasimhaninfo, GardmanVS, Gary A. LaBranche, CAE, Gary King, Gbradt, Gettingtoit, Ghaag, GraemeL, Graveyardparty, Gregory S. Waddell, Grodanbollen, GrooveyHenrik, Gzkn, Haagrachel, Hadal, Haldirams, Halosean, Hdegier, Hede2000, Helixweb, Hemant 17, Henning Wiekhorst, Hide&Reason, Himanshuking, Hippo43, Hkrug4281, Hokelvin, Holbe6, Hughcharlesparker, Icseaturtles, Ideal gas equation, Ilmari Karonen, Impaciente, Insanity Incarnate, Ironwolf, Istartfires, Iterator12n, Iwillgoslow3126, Ixfd64, J.delanoy, J00tel, JAn Dudík, JForget, Jackofwiki, Jackspar15486, Jakohn, Jaxl, Jayen466, Jbamb, Jeff G., Jeffey1234, Jeffhoy, Jeffowner3, Jeffrey Mall, JesseW, Jimjoe, Jmkim dot com, John, John Maynard Friedman, Jose Icaza, Jose77, Jotomicron, Jurema Oliveira, Just4ayaz, Kalanithe, Karavan-LP, Karimarie, Karthimuchlove, Katalaveno, Kateshortforbob, Kbh3rd, Kdau, Kgasso, Khalid, KnowledgeOfSelf, Kookyunii, Kozuch, Kraybilr, Kurieeto, Kurt Jansson, Kuru, Kvdveer, LT. Dunnigan, Lacrimosus, Lamro, Lbongaer, Leafyplant, LeaveSleaves, LedgendGamer, Leranedo, LesleyW, Leuko, Levineps, Liface, Life of Riley, Lightmouse, Lights, Lillingen, Lindsay.Ward, Lord of the Puns, Lova Falk, Lradrama, Luisdelafuente, Luna Santin, M3taphysical, MC MasterChef, MER-C, MacMed, Magnus Manske, Maj IIM, Majorly, Mamawrites, ManManager, Management Culture, Mani1, Marasmusine, Marilyn Haight, Mark Renier, Marketingman, MarsRover, Martinp23, Masterpiece2000, Maurreen, Maxis ftw, Mb22hk, Mberteig, Mdd, Mentifisto, Mesdaghi, Mgillett, Michaelrayw2, Mild Bill Hiccup, Misteror, Mjpieters, Mkoval, Mkubica, Mlaffs, Modeha,

512

Article Sources and Contributors Modernist, MonideepGupta, Moriori, MrOllie, Mrken30, Mydogategodshat, NAHID, NCS2004, NERIUM, NYCCommunity, Nakos2208, Nehrams2020, Neostarbuck, Neptune99, Netoholic, NewWikiMan, Nibuod, Nickypunk001, Nigholith, NighthawkY10K, Nikai, Nikoned, Niteowlneils, Nixdorf, Nnarayanann, No-Bullet, Noclevername, Notinasnaid, Noypi380, Nposs, Nsaa, NuclearWinner, Nurg, Ohnoitsjamie, Oleg Alexandrov, Omoc, OverlordQ, Overviewer, Oxymoron83, Oysterguitarist, P1cunnin, PGPirate, Pag, Page Up, Pak21, Pandaplodder, Paramountpublishing, Parhamr, Paxse, Pedant17, Pedro, Pendraco, Penfold, Phasedice, Phil Maslow, Philip Trueman, PhilipSmith, Philricci, Philwalker, Pigman, Pigsonthewing, Pilgaard, Pinethicket, Pixievamps, Pleckaitis, Popati ann, Pradyutroy, Preetam purbia, Privyet, Promd33, Pseudomonas, Psycho Kirby, Pundit, Puneetminda, Quaeler, R'n'B, RG2, RJHall, RJN, RTG, Radagast83, RadioKirk, Rajshekar.D.Rollakanti, Rastrelli F, Ravichandar84, Rawling, Rayhoughton, Rdsmith4, RedWolf, RexNL, Rice Cakez, Rj, Rlopez1605, Rmpugliese, Robertson-Glasgow, Rootbeer, RotaryAce, Rror, Ryan 4angelz, Ryan Lanham, SCEhardt, SGBailey, SSeanSSS, Saalstin, Sallym, Sanjaymca, Sanusi.husain, Scholzj, Seraphim, Serw, Shafitvohra, Shaunteale, Sheep2000, Shomroni, Shoy, ShrekOC, Simoes, SimonP, Simple Bob, SineWave, SiobhanHansa, Skidude9950, Skomorokh, SkyWalker, Smaccatino, Snowolf, Sommers, Sonal merchant, SpartanPhalanx, Spersily, Spitfire, Spliffy, SpyMagician, Squiddy, Staxoplax, Steamroller Assault, Stephenb, StopItTidyUp, Student317, SueHay, Suffusion of Yellow, Sugarmagnolia175, Sweet2, T@nn, Terrean, Tesakoff, The Anome, The Cunctator, The Font, The Thing That Should Not Be, The Transhumanist, The Transhumanist (AWB), Thedjatclubrock, Themanagementpractice, Theraraavis, Thseamon, Tim Long, Tim1357, Timb001, Tkjainbkn, Tlesher, TomPhil, Tombomp, Tradnor, Traroth, Trey314159, Triwbe, Truongvoky012345, Tyw7, Ucanlookitup, Uloggonitor, Ulric1313, Uriyan, V-squared, Vinsfan368, Wertuose, Wes!, Wiki4des, WikiTome, Wikidea, Willking1979, Withluvurs, Wknight94, Wookipedian, Workmanager, Worldeconomist, WpZurp, Xagent86, Xyzzyplugh, Yamamoto Ichiro, Yasmeen.naseem, YeahIKnow, Yhkhoo, Yidisheryid, Ykhwong, Yotwen, Zeev Grin, Zigger, ZimZalaBim, Zlerman, Zzuuzz, 1010 anonymous edits Requirements analysis Source: http://en.wikipedia.org/w/index.php?oldid=367463905 Contributors: 9Nak, Abdull, AhmadRaw, Ajcheng, Alan.ca, Albanaco, AliveFreeHappy, Allan McInnes, Andreas Kaufmann, Andrew Kay, AndrewStellman, Bact, Beetstra, BfMGH, Bootstoots, Boson, CalumH93, Can't sleep, clown will eat me, Chiswick Chap, Chris Howard, ChrisG, ChrisLoosley, Closedmouth, Coffeeflower, Cometstyles, Creacon, DRogers, DaL33T, Darth Mike, Davedx, Dbraasch, Dlmedici, Elendal, Ency, Enviroboy, Estherschindler, Eubulides, Furrykef, Gakusha, Giftlite, Goethean, Greyskinnedboy, Guybrush1979, Haakon, Harrigan, Haw81, Hede2000, Hmains, IRP, Ian Pitchford, Imjustmatthew, Irmtraining, Isfandhassan, Iterator12n, IvanLanin, Ixfd64, Javierito92, Jean.vivien.maurice, Jeffmartincg, Jpbowen, JulianSammy, Jérôme, Karpinski, Khalid hassani, Kmartin, Konradsa, Kuru, Lakeworks, Latha P Nair, Lcg.wda, Leemccance, Ligulem, LinguistAtLarge, M4gnum0n, MDE, MER-C, MParaz, MPerel, Magioladitis, Malcohol, Mark Renier, Mdd, Metrax, Michael Hardy, MichaelDarter, Mini-Geek, Mkorpela, MrStalker, Mwfnwa, Nainil, Natebailey, Natkeeran, NawlinWiki, Nicotin78, Nigosh, Ohio Mailman, Oicumayberight, PL290, Patstuart, Philosopher06, Piano non troppo, Pm master, Project2501a, Quatrinauta, Ramkoti, Randhirreddy, Richard R White, Rlexvold, Rob cowie, Rodasmith, Ronz, S.K., Sam Korn, Samansouri, Samiroy, Sardanaphalus, Saxifrage, Scarian, Shashang, Shepard, Shishirhegde, Slysplace, SoftwareDeveloper, SondraC, Stephen e nelson, Steve Easterbrook, SunSw0rd, Suruena, That Guy, From That Show!, The Rambling Man, Timo, Trjumpet, Willking1979, Yagood, Ykhwong, 378 anonymous edits Program management Source: http://en.wikipedia.org/w/index.php?oldid=367026493 Contributors: AbsolutDan, Alansohn, Amit Rathi (AR), Andyjsmith, Bernburgerin, Bruce aylward, Busy Stubber, Ccorpusa, Colorajo, Dandriani, Darren searson, Dawn Bard, Deville, Eltmon, Frap, Froodyguy, GMMF2008, Geoff Reiss, Gibsocol, Globalprofessor, Henriksepost, Hroðulf, Hu12, Interchange88, Into The Fray, JacobHodgson55, Jelsova, Jonein, Khalid, Kinu, Kku, Kotra, Kuru, LOL, LightAnkh, Makingprogress19, Maurreen, Mdorohovich, Meridies, Mkoval, Mydogategodshat, NOKESS, Nandhp, NawlinWiki, Nurg, Owain.wilson, Pm master, Pmtoolbox, Poa, Poweroid, Prenju, Radagast83, RedWolf, Rich Farmbrough, Rlolsen, Ronz, SE SME, Sandymok, Sarah, SoWhy, TastyPoutine, Tcncv, Thebluemanager, Thekohser, Tobyelson, Tomwhite, Tschind, Tyugar, Weimeranerman, Wikimaguire, Ykimva, 95 anonymous edits Software development methodology Source: http://en.wikipedia.org/w/index.php?oldid=367685270 Contributors: Beao, Beland, Bokaal, Borgx, Btyner, Carlesso, CodeCaster, Dekimasu, Ed Poor, Firsfron, Ignacio Icke, J04n, JamesBWatson, Johnshue, Ktpenrose, Lwoodyiii, Mark Renier, Materialscientist, Mdd, Msulis, Nakednous, OlEnglish, Oleg Alexandrov, Pohta ce-am pohtit, RJL Hartmans, Rdleon, Valafar, Watsonqai, Willking1979, Woohookitty, ‫ןרע‬, 55 anonymous edits Organization Source: http://en.wikipedia.org/w/index.php?oldid=366706350 Contributors: (, -Majestic-, 130.94.122.xxx, A8UDI, AJR, AdjustShift, Admiraljustin, AdultSwim, Afa86, Ahmed Deyaa', Alansohn, Alex756, Altenmann, Amillar, Ancheta Wis, Andycjp, Anna Lincoln, Antandrus, Ap, Apparition11, Assyria 90, Aurorism, Barrytilton, Beetstra, Belovedfreak, Black Falcon, Blanchardb, Bobo192, Bodnotbod, Bornintheguz, Branko, Brendand, Brett epic, Brianga, Bucketsofg, CKlunck, Casper2k3, Catskul, Celi0r, Chameleon, Clark89, Cncs wikipedia, Cobaltbluetony, Conversion script, Cool3, Coolcaesar, Counterfact, Cultural Freedom, D15724C710N, DancingPhilosopher, Darkildor, DavidLevinson, DavidSaff, Dina, Dissident, Dontbfooled, Downtownee, Dragana666, Eekerz, Elias Daemonwing, EncycloPetey, Fenice, Ferkelparade, Fortdj33, FrankBowe, Freechild, Fumama, Glenn, Gogo Dodo, Gregbard, Grubb, Gurlukovich, Heron, Hopeiamfine, Hut 8.5, Interrobamf, J Di, J.delanoy, JFNoubel, Jachin, Jamaicajan, JamesBWatson, Jaw959, Jeff3000, Jeffrey O. Gustafson, Jemmy Button, Jibbajabba, JohnOwens, Joseph Solis in Australia, Jpbowen, Kai a simon, Kajasudhakarababu, Karol Langner, Ken livsey, Kevin B12, Kharados, Kku, Klemen Kocjancic, Korg, KrakatoaKatie, Kurieeto, LegCircus, Lesgles, Levineps, Libcub, Lights, Lquilter, Luis Dantas, Lupin, MER-C, Mamawrites, Mandarax, Mark Renier, MartinRamos92, Maurreen, Mav, MaveenOlam, Mayumashu, Maziotis, Meco, Melsaran, MeltBanana, Mhking, Michael Hardy, Mkoval, Moink, Mr Adequate, Mr. Comodor, MrFizyx, Mrmrbeaniepiece, Muslimstr, Myleslong, Nanzilla, Naohiro19, Nate Silva, Newfoundglory, Nicolay Worren, Nightstallion, Nimbulan, Noraggingfoundation, Nurg, Octahedron80, Oliver moore, Onetonycousins, Organisationist, Orgwiki, Otto4711, OzDralex, Painintheneck, Paliku, Pascal.Tesson, Pasky, Patrick, Paul foord, Pawl Kennedy, Paxse, Pearle, Pekaje, Peterklevy, Pgk, Pharaoh of the Wizards, Philip1978, Pilgaard, Pknkly, Prince eagle, Pring, Priyatu, Prokopenya Viktor, Quest for Truth, R'n'B, Radiant!, Radiojon, Ranveig, Razorflame, RedHillian, Reedy, Reliable monkey, Retired username, Reyk, Rjd0060, Rl, Roaming, RockMFR, Rror, Rumping, SRRDES, Sazaedo, Scetoaux, Scholar33, Scott Wilson, Severa, Simguy, Simps81, SiobhanHansa, SirIsaacBrock, Sjakkalle, Skittleys, Slysplace, Smmalut, SorryGuy, SoulSlayer, SpNeo, Ste4k, Stephen Gilbert, Stephenb, Sueknaup, Sunray, Svetovid, Tagishsimon, Taylor5053, Tbonnie, Tesfatsion, The Anome, Thomasmeeks, Thseamon, Tide rolls, Timichal, Tkjainbkn, Tlrmq, Tomsega, Triwbe, Van helsing, Verbose, Versageek, Viridae, WWGB, WadeSimMiser, Waggers, Washburnmav, Wereon, WikiWebbie, Wikitomcat, Yidisheryid, Zigger, Александър, 360 anonymous edits Strategic management Source: http://en.wikipedia.org/w/index.php?oldid=366925379 Contributors: A More Perfect Onion, ABCD, Acontrada, AdjustShift, Alberta74, Alex.muller, Alexburnsdisinfo, Alfredxz, Alisabzevari, Alliance09, Allstar18, Alonlaudon, Amit A., Arpabr, Arthur Rubin, Baniasad, Barras, Bass fishing physicist, Big Brother 1984, Black Falcon, Bluesmoon, Boatearth, Bobblehead, Bobo192, Bowin, Brat32, Brian Mc Carron, Burkhard, Cacycle, CambridgeBayWeather, Canada Hky, Choster, Cmdrjameson, Coffee, Cokehabit, CommodiCast, Compaqevo, Condimentman, CountryMama27, Cretog8, Crocodile Punter, DDerby, DanMS, Dancter, Dave.excira, Davejblair, Deville, DickSummerfield, Digitalrituraj, Dmccreary, Dmr2, DorisH, Dzubint, Edcolins, Edward, Efe, Ehheh, Ekotkie, ElKevbo, Elonka, Enablerecip, Epbr123, Erud, Espoo, Excirial, Fastily, Fbooth, FinishFirst, Fintor, Fragma08, Franckgintrand, Fratrep, Freakofnurture, Friskis, Futureobservatory, GJeffery, GTBacchus, Ganeshraja.r, George Brower, Giraffedata, Glen, GlenPeterson, Goleby, Goodoldpolonius2, Griffinofwales, Gwernol, Gzornenplatz, Gökhan, [emailprotected], Hadal, Heili M., Henrygb, Himanshuking, Howardjp, Husond, If6was9, Ihcoyc, Irrbloss, IvanLanin, Ixfd64, J, J04n, JEH, JMK, Jackofwiki, Jcspender, JiE, Jlammens, Joel7687, Jpgordon, Judge999, Justray, Kelapstick, Kerilowery, Ketiltrout, Khalid, Khalid hassani, KittyRainbow, Klemen Kocjancic, Koavf, Kobinaaddo, Krakfly, Kuru, Kwenkbodenmiller, LEX XIV, Lar, Ldirwin, Lord of the Pit, Lupin, Maaajid, Mandelman, Manop, Manscher, Marcika, Marek69, Matt Whyndham, Mattbr, Maurreen, Mboverload, McSly, Mdz, MeltBanana, Mentifisto, Meredith.passaro, Merlion444, Michael Hardy, Mike Cline, Mike Rosoft, Mind quester, Minimac's Clone, Mitsuhirato, Monishasarkar, MrOllie, Mrmrbeaniepiece, Mschacter, Mydogategodshat, Nazrani, Neilc, Neutrality, Newsaholic, Nickg, Notinasnaid, NuclearWarfare, OEEGuru, Occlasty, Oda Mari, Ohnoitsjamie, Oleg Alexandrov, Oli Filth, Olivier, Oollee, Orgstrat, Ot, Otellozorina, Ottawa4ever, PGPirate, Paleorthid, Pamri, Pasquale, PatriceNeff, Paulshanley, Paxse, Pgreenfinch, Pinethicket, Pinnecco, Pkor43, Possum, Prof 7, Promethean, Psychobabble, Pvosta, Quadell, Qxz, RJBurkhart3, Radagast83, Reach Out to the Truth, Reinyday, Rjwilmsi, Rmptls, Robert Enchante, Robinstocks, Rollo44, Ronz, Roxyb, Rschmal, Rwarp, Rye1967, S.K., SCEhardt, Saligron, SalineBrain, Sam Hocevar, Sam mishra, Sandman, Sandstein, Scott Ritchie, Sengkang, Sfhl, ShelfSkewed, SkaTroma, SouthernNights, Stas3000, Stefano, Strateotu, Strorg, SueHay, Surfdachsie, Susvolans, THEN WHO WAS PHONE?, TRUGROUP, Tabletop, Tassedethe, TastyPoutine, Taxman, The Thing That Should Not Be, TheRedPenOfDoom, Thegn, Titoxd, Tom harrison, Travis.a.buckingham, Travis99, Truthanado, Tswelch, Vald, Vitaly.demin, Wk muriithi, Woohookitty, Wragge, YeahIKnow, Yhkhoo, Yomangani, Zahid Abdassabur, Zzuuzz, Петър Петров, 566 anonymous edits

513

Image Sources, Licenses and Contributors

Image Sources, Licenses and Contributors File:Trajan's Column (Roman Soldiers Building a Fortress).png Source: http://en.wikipedia.org/w/index.php?title=File:Trajan's_Column_(Roman_Soldiers_Building_a_Fortress).png License: GNU Free Documentation License Contributors: Fikret Yegul Image:Henri Gannt.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Henri_Gannt.jpg License: Public Domain Contributors: unknown Image:Pert chart colored.gif Source: http://en.wikipedia.org/w/index.php?title=File:Pert_chart_colored.gif License: Public Domain Contributors: Original uploader was Jeremykemp at en.wikipedia Image:Project Management (phases).png Source: http://en.wikipedia.org/w/index.php?title=File:Project_Management_(phases).png License: GNU Free Documentation License Contributors: User:Alphamu57 Image:Xp-loop with time frames.svg Source: http://en.wikipedia.org/w/index.php?title=File:Xp-loop_with_time_frames.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Mdd Image:Prince2 procces model .jpg Source: http://en.wikipedia.org/w/index.php?title=File:Prince2_procces_model_.jpg License: GNU Free Documentation License Contributors: Markavian, Throxana Image:Capability Maturity Model.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Capability_Maturity_Model.jpg License: Public Domain Contributors: Andrea O. Salas, Joanne L. Walsh, James C. Townsend File:Project development stages.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Project_development_stages.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology File:Initiating Process Group Processes.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Initiating_Process_Group_Processes.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology File:Planning Process Group Activities.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Planning_Process_Group_Activities.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology File:Executing Process Group Processes.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Executing_Process_Group_Processes.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology File:Monitoring and Controlling Process Group Processes.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Monitoring_and_Controlling_Process_Group_Processes.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology Image:Project Management (project control).png Source: http://en.wikipedia.org/w/index.php?title=File:Project_Management_(project_control).png License: GNU Free Documentation License Contributors: User:Alphamu57 File:Closing Process Group Processes.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Closing_Process_Group_Processes.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology Image:The triad constraints.jpg Source: http://en.wikipedia.org/w/index.php?title=File:The_triad_constraints.jpg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:JohnManuel Image:NASA NF 533 reporting structure.jpg Source: http://en.wikipedia.org/w/index.php?title=File:NASA_NF_533_reporting_structure.jpg License: Public Domain Contributors: NASA File:VA IT Project Management Framework.jpg Source: http://en.wikipedia.org/w/index.php?title=File:VA_IT_Project_Management_Framework.jpg License: unknown Contributors: DEPARTMENT OF VETERANS AFFAIRS Office of Information and Technology Image:SDLC-Maintenance-Highlighted.png Source: http://en.wikipedia.org/w/index.php?title=File:SDLC-Maintenance-Highlighted.png License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Dzonatas Image:Systems Development Life Cycle.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Systems_Development_Life_Cycle.jpg License: Public Domain Contributors: User:Mdd Image:SDLC Phases Related to Management Controls.jpg Source: http://en.wikipedia.org/w/index.php?title=File:SDLC_Phases_Related_to_Management_Controls.jpg License: Public Domain Contributors: U.S. House of Representatives Image:SDLC Work Breakdown Structure.jpg Source: http://en.wikipedia.org/w/index.php?title=File:SDLC_Work_Breakdown_Structure.jpg License: Public Domain Contributors: U.S. House of Representatives File:Flag of Australia.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Australia.svg License: Public Domain Contributors: Ian Fieggen File:Flag of Brazil.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Brazil.svg License: Public Domain Contributors: Brazilian Government File:Flag of Denmark.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Denmark.svg License: Public Domain Contributors: User:Madden File:Flag of Egypt.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Egypt.svg License: unknown Contributors: 16@r, Alnokta, Anime Addict AA, ArséniureDeGallium, BomBom, Denelson83, Dinsdagskind, Duesentrieb, F l a n k e r, Flad, Foroa, Fry1989, Herbythyme, Homo lupus, Iamunknown, Klemen Kocjancic, Kookaburra, Ludger1961, Lumijaguaari, Mattes, Moroboshi, Neq00, Nightstallion, OsamaK, Permjak, Reisio, Rimshot, Str4nd, ThomasPusch, Thyes, Vonvon, Wikiborg, Wikimedia is Communism, Überraschungsbilder, 27 anonymous edits File:Flag of Japan.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Japan.svg License: Public Domain Contributors: Various File:Flag of Malaysia.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Malaysia.svg License: Public Domain Contributors: User:SKopp File:Flag of North Korea.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_North_Korea.svg License: Public Domain Contributors: User:Zscout370 File:Flag of Panama.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Panama.svg License: Public Domain Contributors: -xfi-, Addicted04, Fadi the philologer, Fry1989, Klemen Kocjancic, Liftarn, Mattes, Nightstallion, Ninane, Pumbaa80, Reisio, Rfc1394, Thomas81, ThomasPusch, Zscout370, 17 anonymous edits File:Flag of Sweden.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Sweden.svg License: Public Domain Contributors: Hejsa, Herbythyme, J budissin, Jon Harald Søby, Klemen Kocjancic, Lefna, Mattes, Meno25, Odder, Peeperman, Quilbert, Reisio, Sir Iain, Str4nd, Tabasco, Tene, Thomas Blomberg, Thuresson, Wiklas, 31 anonymous edits File:Flag of the United Kingdom.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_the_United_Kingdom.svg License: Public Domain Contributors: User:Zscout370 File:Flag of the United States.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_the_United_States.svg License: Public Domain Contributors: User:Dbenbenn, User:Indolences, User:Jacobolus, User:Technion, User:Zscout370 File:Flag of France.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_France.svg License: Public Domain Contributors: User:SKopp, User:SKopp, User:SKopp, User:SKopp, User:SKopp, User:SKopp File:Flag of Germany.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Germany.svg License: Public Domain Contributors: User:Pumbaa80 File:Flag of Spain.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Spain.svg License: Public Domain Contributors: Pedro A. Gracia Fajardo, escudo de Manual de Imagen Institucional de la Administración General del Estado File:Flag of Italy.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Italy.svg License: Public Domain Contributors: see below File:Flag of Canada.svg Source: http://en.wikipedia.org/w/index.php?title=File:Flag_of_Canada.svg License: Public Domain Contributors: User:E Pluribus Anthony, User:Mzajac Image:Waterfall model.svg Source: http://en.wikipedia.org/w/index.php?title=File:Waterfall_model.svg License: Creative Commons Attribution 3.0 Contributors: Paul Smith Image:Development-iterative.gif Source: http://en.wikipedia.org/w/index.php?title=File:Development-iterative.gif License: Public Domain Contributors: Dutchguilder Image:Factory.svg Source: http://en.wikipedia.org/w/index.php?title=File:Factory.svg License: Public Domain Contributors: User:Howcheng File:Scrum_process.svg Source: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg License: GNU Free Documentation License Contributors: User:Lakeworks Image:EventChain.jpg Source: http://en.wikipedia.org/w/index.php?title=File:EventChain.jpg License: Public Domain Contributors: Original uploader was Kenmckinley at en.wikipedia Image:EventChainMethodology.jpg Source: http://en.wikipedia.org/w/index.php?title=File:EventChainMethodology.jpg License: Public Domain Contributors: Original uploader was Kenmckinley at en.wikipedia Image:RepeatedActivity.jpg Source: http://en.wikipedia.org/w/index.php?title=File:RepeatedActivity.jpg License: Public Domain Contributors: Original uploader was Kenmckinley at en.wikipedia Image:MitigationPlan.jpg Source: http://en.wikipedia.org/w/index.php?title=File:MitigationPlan.jpg License: Public Domain Contributors: Original uploader was Kenmckinley at en.wikipedia

514

Image Sources, Licenses and Contributors Image:meta-levels.png Source: http://en.wikipedia.org/w/index.php?title=File:Meta-levels.png License: unknown Contributors: Smoothloader Image:flexibility.png Source: http://en.wikipedia.org/w/index.php?title=File:Flexibility.png License: unknown Contributors: Smoothloader Image:GanttChartAnatomy.png Source: http://en.wikipedia.org/w/index.php?title=File:GanttChartAnatomy.png License: Public Domain Contributors: Original uploader was Garrybooker at en.wikipedia Later versions were uploaded by Abdull at en.wikipedia. Image:pert example gantt chart.gif Source: http://en.wikipedia.org/w/index.php?title=File:Pert_example_gantt_chart.gif License: GNU Free Documentation License Contributors: Dbsheajr, Jni, 5 anonymous edits Image:Prince2 diagram.png Source: http://en.wikipedia.org/w/index.php?title=File:Prince2_diagram.png License: Public Domain Contributors: Rellis1067, 4 anonymous edits Image:Characteristics_of_Capability_Maturity_Model.svg Source: http://en.wikipedia.org/w/index.php?title=File:Characteristics_of_Capability_Maturity_Model.svg License: Public Domain Contributors: Sally Godfrey File:Cycle_of_Research_and_Development.gif Source: http://en.wikipedia.org/w/index.php?title=File:Cycle_of_Research_and_Development.gif License: Public Domain Contributors: w:National Science FoundationNational Science Foundation Image:Emblem-money.svg Source: http://en.wikipedia.org/w/index.php?title=File:Emblem-money.svg License: GNU General Public License Contributors: perfectska04 File:Kate-at-fleshmarket.JPG Source: http://en.wikipedia.org/w/index.php?title=File:Kate-at-fleshmarket.JPG License: Creative Commons Attribution-Sharealike 2.5 Contributors: Original uploader was 2005biggar at en.wikipedia Image:Wiktionary-logo-en.svg Source: http://en.wikipedia.org/w/index.php?title=File:Wiktionary-logo-en.svg License: unknown Contributors: User:Brion VIBBER Image:WBS.png Source: http://en.wikipedia.org/w/index.php?title=File:WBS.png License: Public Domain Contributors: DoD File:Work Breakdown Structure of Aircraft System.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Work_Breakdown_Structure_of_Aircraft_System.jpg License: Public Domain Contributors: Original uploader was Mdd at en.wikipedia Image:WbsConstruction.png Source: http://en.wikipedia.org/w/index.php?title=File:WbsConstruction.png License: Public Domain Contributors: User:Garrybooker File:carbolic smoke ball co.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Carbolic_smoke_ball_co.jpg License: Public Domain Contributors: Carbolic Smoke Ball Company Transwiki details Original uploader was Dostal at en.wikipedia File:Parkingticketcontract.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Parkingticketcontract.jpg License: Public Domain Contributors: Bkell, Coolcaesar, Drilnoth, IgWannA, Mikemoral, 1 anonymous edits file:US-DeptOfVeteransAffairs-Seal.svg Source: http://en.wikipedia.org/w/index.php?title=File:US-DeptOfVeteransAffairs-Seal.svg License: Public Domain Contributors: U.S. Government Image:Paloaltoveteransaffairshospital.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Paloaltoveteransaffairshospital.jpg License: unknown Contributors: User:Coolcaesar. Original uploader was Coolcaesar at en.wikipedia. Later version(s) were uploaded by Ingolfson at en.wikipedia. Image:Lbva.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Lbva.jpg License: GNU Free Documentation License Contributors: user:Kkmd File:ISO 9001 in Tsukiji.jpg Source: http://en.wikipedia.org/w/index.php?title=File:ISO_9001_in_Tsukiji.jpg License: unknown Contributors: Chris 73, Jmabel Image:iappm.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Iappm.jpg License: unknown Contributors: [emailprotected], Mdd Image:Systems Engineering Process II.svg Source: http://en.wikipedia.org/w/index.php?title=File:Systems_Engineering_Process_II.svg License: Public Domain Contributors: User:Slashme Image:Systems Engineering and Verification.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Systems_Engineering_and_Verification.jpg License: Public Domain Contributors: Mdd Image:VPM3e Vee with detail.gif Source: http://en.wikipedia.org/w/index.php?title=File:VPM3e_Vee_with_detail.gif License: Creative Commons Attribution 3.0 Contributors: Kevin Forsberg and Hal Mooz Image:Project Investment Portfolio Occam s Tree.gif Source: http://en.wikipedia.org/w/index.php?title=File:Project_Investment_Portfolio_Occam_s_Tree.gif License: Public Domain Contributors: User:Fangz Image:UnifiedProcessProjectProfile20060708.png Source: http://en.wikipedia.org/w/index.php?title=File:UnifiedProcessProjectProfile20060708.png License: Creative Commons Attribution-Sharealike 2.5 Contributors: User:GFLewis Image:Systems engineering application projects collage.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Systems_engineering_application_projects_collage.jpg License: Creative Commons Attribution-Sharealike 2.5 Contributors: User:Betelgeuse Image:A1 House of Quality.png Source: http://en.wikipedia.org/w/index.php?title=File:A1_House_of_Quality.png License: Public Domain Contributors: Cask05, Madmedea, 3 anonymous edits Image:SE Activities.jpg Source: http://en.wikipedia.org/w/index.php?title=File:SE_Activities.jpg License: Public Domain Contributors: Mdd Image:Systems Engineering Process.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Systems_Engineering_Process.jpg License: Public Domain Contributors: Mdd Image:EVM Fig1.png Source: http://en.wikipedia.org/w/index.php?title=File:EVM_Fig1.png License: Public Domain Contributors: User:Garrybooker Image:EVM Fig2.png Source: http://en.wikipedia.org/w/index.php?title=File:EVM_Fig2.png License: Public Domain Contributors: Garrybooker, 1 anonymous edits Image:EVM Fig3.png Source: http://en.wikipedia.org/w/index.php?title=File:EVM_Fig3.png License: Public Domain Contributors: Garrybooker Image:EVM Fig4.png Source: http://en.wikipedia.org/w/index.php?title=File:EVM_Fig4.png License: Public Domain Contributors: Garrybooker Image:EVM Fig5.png Source: http://en.wikipedia.org/w/index.php?title=File:EVM_Fig5.png License: Public Domain Contributors: User:Garrybooker Image:Waterfall model.png Source: http://en.wikipedia.org/w/index.php?title=File:Waterfall_model.png License: Creative Commons Attribution-Sharealike 2.5 Contributors: Original uploader was PaulHoadley at en.wikipedia File:Jeff Sutherland.JPG Source: http://en.wikipedia.org/w/index.php?title=File:Jeff_Sutherland.JPG License: Creative Commons Attribution-Sharealike 3.0 Contributors: Anders Wegge Keller Image:Pair programming 1.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Pair_programming_1.jpg License: Creative Commons Attribution 2.0 Contributors: Lisamarie Babik Image:Pert example gantt chart.png Source: http://en.wikipedia.org/w/index.php?title=File:Pert_example_gantt_chart.png License: GNU Free Documentation License Contributors: Gavin White, 1 anonymous edits Image:pert example network diagram.gif Source: http://en.wikipedia.org/w/index.php?title=File:Pert_example_network_diagram.gif License: GNU Free Documentation License Contributors: Dbsheajr, 1 anonymous edits Image:pert example node legend.GIF Source: http://en.wikipedia.org/w/index.php?title=File:Pert_example_node_legend.GIF License: GNU Free Documentation License Contributors: Dbsheajr Image:pert example network diagram visio.gif Source: http://en.wikipedia.org/w/index.php?title=File:Pert_example_network_diagram_visio.gif License: GNU Free Documentation License Contributors: User:BotMultichill Image:Operating system placement.svg Source: http://en.wikipedia.org/w/index.php?title=File:Operating_system_placement.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Golftheman Image:Airbus A380 cockpit.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Airbus_A380_cockpit.jpg License: Creative Commons Attribution 2.0 Contributors: Aliosos, Apalsola, Ssolbergj, Thuresson, 1 anonymous edits Image:Sky scraper construction.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Sky_scraper_construction.jpg License: unknown Contributors: Bidgee, Edward, Fir0002, Samulili Image:BuildingSite.jpg Source: http://en.wikipedia.org/w/index.php?title=File:BuildingSite.jpg License: unknown Contributors: Achim Hering, Joanjoc, SCEhardt, Solipsist, Tttrung, Waldir Image:Unfinishedbuilding.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Unfinishedbuilding.jpg License: Creative Commons Attribution 2.5 Contributors: Bookworming Image:Trump International Hotel and Tower, Chicago (0837).JPG Source: http://en.wikipedia.org/w/index.php?title=File:Trump_International_Hotel_and_Tower,_Chicago_(0837).JPG License: Public Domain Contributors: Original uploader was Antonio Vernon at en.wikipedia (Original text : ) Image:20070914 Trump International Hotel & Tower - Chicago.JPG Source: http://en.wikipedia.org/w/index.php?title=File:20070914_Trump_International_Hotel_&_Tower_-_Chicago.JPG License: GNU Free Documentation License Contributors: TonyTheTiger at en.wikipedia Image:Havelock City, Sri Lanka, 003.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Havelock_City,_Sri_Lanka,_003.jpg License: Creative Commons Attribution 3.0 Contributors: User:Rehman

515

Image Sources, Licenses and Contributors Image:Havelock City, Sri Lanka, 004.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Havelock_City,_Sri_Lanka,_004.jpg License: Creative Commons Attribution 3.0 Contributors: User:Rehman Image:Shasta dam under construction edit.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Shasta_dam_under_construction_edit.jpg License: Public Domain Contributors: Russell Lee File:UnderConstruction-Apt.jpg Source: http://en.wikipedia.org/w/index.php?title=File:UnderConstruction-Apt.jpg License: Public Domain Contributors: User:Kys951 Image:Prefabricated house construction.gif Source: http://en.wikipedia.org/w/index.php?title=File:Prefabricated_house_construction.gif License: Creative Commons Attribution-Sharealike 2.0 Contributors: User:Vesta Image:Liberty Memorial 043.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Liberty_Memorial_043.jpg License: Public Domain Contributors: Pacman5, Videmus Omnia File:Construction Workers.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Construction_Workers.jpg License: Creative Commons Attribution 2.0 Contributors: photo taken by flickr Paul Keheler Image:Maquina vapor Watt ETSIIM.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Maquina_vapor_Watt_ETSIIM.jpg License: GNU Free Documentation License Contributors: Nicolás Pérez Image:Windmills D1-D4 - Thornton Bank.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Windmills_D1-D4_-_Thornton_Bank.jpg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Lycaon Image:Dampfturbine Montage01.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Dampfturbine_Montage01.jpg License: GNU Free Documentation License Contributors: D-Kuru, Markus Schweiss, MichaelDiederich, StraSSenBahn, Tetris L Image:CFD Shuttle.jpg Source: http://en.wikipedia.org/w/index.php?title=File:CFD_Shuttle.jpg License: Public Domain Contributors: Avron, Babucke, Hellisp, Infrogmation, Kozuch, TommyBee, 1 anonymous edits Image:Nrc-bri-bioprocess-lr.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Nrc-bri-bioprocess-lr.jpg License: unknown Contributors: Victor D Image:Leonardo self.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Leonardo_self.jpg License: Public Domain Contributors: Attributed to Leonardo da Vinci Image:Iterative development model V2.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Iterative_development_model_V2.jpg License: Public Domain Contributors: Mdd, 1 anonymous edits Image:PMI-logo.png Source: http://en.wikipedia.org/w/index.php?title=File:PMI-logo.png License: unknown Contributors: User:Cydebot, User:Gloy, User:Makingprogress19 File:Blackett-large.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Blackett-large.jpg License: Public Domain Contributors: Sosayso at en.wikipedia Image:Kammhuber Line Map - Agent Tegal.png Source: http://en.wikipedia.org/w/index.php?title=File:Kammhuber_Line_Map_-_Agent_Tegal.png License: unknown Contributors: User:Ian Dunster File:ISS impact risk.jpg Source: http://en.wikipedia.org/w/index.php?title=File:ISS_impact_risk.jpg License: Public Domain Contributors: National Aeronautics and Space Administration (NASA): NASA Johnson Space Center Orbital Debris Program Office Image:ISO english logo.svg Source: http://en.wikipedia.org/w/index.php?title=File:ISO_english_logo.svg License: unknown Contributors: Erachima, MBisanz, Vargklo Image:ISO Members.svg Source: http://en.wikipedia.org/w/index.php?title=File:ISO_Members.svg License: Public Domain Contributors: User:Ichwan Palongengi Image:Screengrab - Microsoft Project 9.0.2000.0224 - (simple Gantt chart) .png Source: http://en.wikipedia.org/w/index.php?title=File:Screengrab_-_Microsoft_Project_9.0.2000.0224_-_(simple_Gantt_chart)_.png License: unknown Contributors: User:Tagishsimon Image:Seer3.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Seer3.jpg License: Creative Commons Attribution 3.0 Contributors: EdHubertson, 1 anonymous edits File:View of Wall Street.jpg Source: http://en.wikipedia.org/w/index.php?title=File:View_of_Wall_Street.jpg License: GNU Free Documentation License Contributors: Sfoskett File:London.bankofengland.arp.jpg Source: http://en.wikipedia.org/w/index.php?title=File:London.bankofengland.arp.jpg License: Public Domain Contributors: Adrian Pingstone File:Downtownplazala.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Downtownplazala.jpg License: Public Domain Contributors: w:en:User:Pag293Pag293 File:Bolsa Mexicana de Valores.png Source: http://en.wikipedia.org/w/index.php?title=File:Bolsa_Mexicana_de_Valores.png License: Public Domain Contributors: Dabackgammonator (talk). Original uploader was Dabackgammonator at en.wikipedia Image:DSDM Development Process.svg Source: http://en.wikipedia.org/w/index.php?title=File:DSDM_Development_Process.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Mdd Image:processdata-DSDM.png Source: http://en.wikipedia.org/w/index.php?title=File:Processdata-DSDM.png License: Public Domain Contributors: User:Swijaya of the English Wikipedia Image:metadata-DSDM.png Source: http://en.wikipedia.org/w/index.php?title=File:Metadata-DSDM.png License: Public Domain Contributors: User:Swijaya of the English Wikipedia Image:processdata-FMI.png Source: http://en.wikipedia.org/w/index.php?title=File:Processdata-FMI.png License: Public Domain Contributors: User:Swijaya of the English Wikipedia Image:System boundary.svg Source: http://en.wikipedia.org/w/index.php?title=File:System_boundary.svg License: unknown Contributors: User:Stannered Image:SE Process.jpg Source: http://en.wikipedia.org/w/index.php?title=File:SE_Process.jpg License: Public Domain Contributors: Mdd, WikipediaMaster Image:Three software development patterns mashed together.svg Source: http://en.wikipedia.org/w/index.php?title=File:Three_software_development_patterns_mashed_together.svg License: Public Domain Contributors: User:Beao Image:Software Development Spiral.svg Source: http://en.wikipedia.org/w/index.php?title=File:Software_Development_Spiral.svg License: Public Domain Contributors: User:Beao File:TEAF Matrix of Views and Perspectives.jpg Source: http://en.wikipedia.org/w/index.php?title=File:TEAF_Matrix_of_Views_and_Perspectives.jpg License: Public Domain Contributors: Department of the Treasury Chief Information Officer Council Image:Process and data modeling.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Process_and_data_modeling.jpg License: Public Domain Contributors: Paul R. Smith. Redrawn by Marcel Douwe Dekker Image:Anjuta-2.0.0-2.png Source: http://en.wikipedia.org/w/index.php?title=File:Anjuta-2.0.0-2.png License: GNU General Public License Contributors: Original uploader was Deeahbz at en.wikipedia

516

License

License Creative Commons Attribution-Share Alike 3.0 Unported http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/

517

2010-06-14 1300 Project Management Broad Spectrum Overview Wikibook - PDFCOFFEE.COM (2024)

References

Top Articles
Latest Posts
Recommended Articles
Article information

Author: Gregorio Kreiger

Last Updated:

Views: 5743

Rating: 4.7 / 5 (57 voted)

Reviews: 80% of readers found this page helpful

Author information

Name: Gregorio Kreiger

Birthday: 1994-12-18

Address: 89212 Tracey Ramp, Sunside, MT 08453-0951

Phone: +9014805370218

Job: Customer Designer

Hobby: Mountain biking, Orienteering, Hiking, Sewing, Backpacking, Mushroom hunting, Backpacking

Introduction: My name is Gregorio Kreiger, I am a tender, brainy, enthusiastic, combative, agreeable, gentle, gentle person who loves writing and wants to share my knowledge and understanding with you.