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 Project planning Scope (project management) Scope creep Design structure matrix Systems Development Life Cycle Enterprise resource planning Project slippage Project charter Software bloat Megaprojects and Risk Megaproject Feature creep Instruction creep Creep (project management) Cost overrun Mission creep Waterfall model IBM Rational Unified Process Requirements management Critical Chain Project Management Cone of Uncertainty Problem solving Resource leveling Theory of Constraints Agile management Extreme programming Scrum (development) Event chain methodology Human interaction management Process modeling Event chain diagram Gantt chart PRINCE2 1 13 14 16 17 19 27 36 36 37 40 41 42 44 44 45 48 49 54 62 67 70 71 79 80 87 88 98 106 110 111 119 120 123

Process-based management ISO/IEC 15504 Capability Maturity Model Integration Research and development Stage-Gate model Financial analysis Stakeholder analysis Deliverable Budget New product development Risk Audit Consultant Strategy Project manager Project management triangle Work breakdown structure Contract United States Department of Veterans Affairs A Guide to the Project Management Body of Knowledge Capability Maturity Model ISO 9000 ISO 10006 Total cost management The International Association of Project and Program Management V-Model Project portfolio management Glossary of project management List of project management topics Comparison of project management software Timeline of project management Portfolio management Systems engineering Portfolio manager IT portfolio management Human factors Earned value management Project governance

128 128 135 140 143 149 151 154 155 157 163 174 177 178 180 185 189 195 209 214 215 221 236 237 238 239 243 247 257 259 262 264 264 275 275 279 292 299

Virtual project management Software development process Process architecture Project Critical path method Agile software development Program Evaluation and Review Technique Computer software Software engineering Construction Engineering Iterative and incremental development Project Management Institute Requirement Operations research Risk management International Organization for Standardization Change control Project management software Business Goal Dynamic Systems Development Method Product (business) Marketing System Change management Software development Management Requirements analysis Program management Software development methodology Organization Strategic management

301 302 308 309 311 313 323 330 336 342 350 362 365 367 371 379 391 398 400 404 410 413 426 429 437 442 443 446 454 461 465 474 480

References
Article Sources and Contributors Image Sources, Licenses and Contributors 501 514

Article Licenses
License 517

Project management

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 secondaryand more ambitiouschallenge 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 (16321723) , Thomas Telford (1757-1834) and Isambard Kingdom Brunel (18061859) [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 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

Project initiation stage; Project planning or design stage; Project execution or production stage; Project monitoring and controlling systems; Project completion . 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."
Typical development phases of a project

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" resourcea resource that acts as a constraint across projectsand stagger projects based on the availability of that single resource.

Project management

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.

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.

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

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

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

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

[19] Initiating Process Group Processes

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

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;

Planning Process Group Activities

[19]

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

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

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
Closing Process Group Processes. [19]

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 organizations 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 issues of cost, time, quality and above all, client satisfaction, can be realized.

10

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

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

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

11

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.

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 Glossary of project management List of project management topics List of project management software Timeline of project management Related fields Architectural engineering Construction management Cost engineering Industrial engineering Project management software Project workforce management Portfolio management Systems engineering Software project management Related subjects 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

13

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

Project planning

14

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

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.

15

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

Scope creep

16

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

Scope creep

17

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

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.

18

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]

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
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
Model of the Systems Development Life Cycle with the

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]

20

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.

Systems Development Life Cycle

21

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.

Systems Development Life Cycle

22

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

Systems Development Life Cycle

23

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

Systems Development Life Cycle

24

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

Systems Development Life Cycle

25

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

SDLC RAD Open Source Weak Medium Few Hundreds Both Objects JAD Prototyping End User User Short One None DSS Crucial None

Control Time Frame Users MIS staff Transaction/DSS Interface Documentation and training Integrity and security

Formal Long Many Many

MIS Short Few Few

Standards Joint Any Varies Split Both Windows In Objects In Objects Vital

User

Medium Short Few Few DSS Crucial One or Two One or Two DSS Crucial

Transaction Both Minimal Vital

Minimal Weak Limited Internal

Limited Weak

Vital

Vital

Unknown

Limited Weak

Weak

Reusability

Limited

Some

Maybe

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 Control. Monitor Large projects. Detailed steps. Weaknesses Increased development time. Increased development cost. Systems must be defined up front.

Evaluate costs and completion targets. Rigidity. Documentation. Well defined user input. Ease of maintenance. Development and design standards. Tolerates changes in MIS staffing. Hard to estimate costs, project overruns. User input is sometimes limited.

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.

26

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]

Systems Development Life Cycle

27

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:

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]

28

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

Enterprise resource planning

29

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.

Enterprise resource planning

30

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 39 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

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]

31

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 companys 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 systems 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 systems 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

Enterprise resource planning cost of the user licensesthree 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

33

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 companiesthis 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).

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.

34

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): 215. 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): 34333455. 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.

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 Oriente 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): 131136. doi:10.1016/0378-7206(86)90010-8.

35

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.494500. 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/

Project slippage

36

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

Software bloat

37

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.

Software bloat

38

Examples
Comparison of Microsoft Windows minimum hardware requirements (for 32-bit versions). Windows version Processor Memory Hard disk ~50 MB ~200 MB 650 MB 1.5 GB 15 GB 16 GB

Windows 95 Windows 98

[4] [5] [6]

25MHz 66MHz 133MHz 233MHz

4 MB 16 MB 32 MB 64 MB 512 MB 1 GB

Windows 2000 Windows XP [7]

(2001)

Windows Vista Windows 7

[8]

(2007) 800MHz 1GHz

[9]

(2009)

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".

39

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? Its 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"

Megaprojects and Risk

40

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.

Megaprojects and Risk

41

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.

Megaproject

42

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]

Feature creep

43

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: 101110, [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

Instruction creep

44

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

Cost overrun

45

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
Braslia

Denmark
Great Belt railway tunnel

Egypt
Suez Canal

Cost overrun

46

Japan
Joetsu Shinkansen high-speed rail line

Malaysia
Pergau Dam

North Korea
Ryugyong Hotel

Panama
Panama Canal

Sweden
Gta Canal Hallandss 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 FranciscoOakland 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)

Cost overrun

47

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 Sren 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 Sren 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

Mission creep

48

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.

Mission creep

49

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 developmentas a way to criticize a commonly used software practice.[2]

Waterfall model

50

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

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.

51

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.

Waterfall model

52

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): 19.

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.

53

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 fr 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

IBM Rational Unified Process

54

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).

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.

56

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

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.

57

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.

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)

59

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]

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]

60

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.

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

61

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

IBM Rational Unified Process

62

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.

Requirements management

63

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 werent 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? Whats the internal rate of return in reducing costs of training and support if we

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, Dont make the human remember where she is in the interface. Make the interface report the humans location in the system at all times. Or Dont 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.

64

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. Heres 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.

Requirements management

65

Release
Requirements management does not end with product release. From that point on, the data coming in about the applications 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 customers 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, 247 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

Requirements management

66

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

Critical Chain Project Management

67

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.

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.

68

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 chainthe difference between the "safe" durations and the 50% durationsis 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.

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.

69

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

Critical Chain Project Management

70

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.205214 [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.

Cone of Uncertainty

71

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

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).

72

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 Drner (1975, 1985; see Drner & 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 Drner, 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., Drner, Kreuzig, Reither & Studel'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)

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)

73

Characteristics of difficult problems

As elucidated by Dietrich Drner 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

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

74

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

Problem solving

75

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): 456462. 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): 124140. 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., & Drner, 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: 121152. doi:10.1207/s15516709cog0502_2. Drner, D. (1975). Wie Menschen eine Welt verbessern wollten [How people wanted to improve the world]. Bild der Wissenschaft, 12, 48-53. Drner, D. (1985). Verhalten, Denken und Emotionen [Behavior, thinking, and emotions]. In L. H. Eckensberger & E. D. Lantermann (Eds.), Emotion und Reflexivitt (pp. 157-181). Mnchen, Germany: Urban & Schwarzenberg. Drner, 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 fr Werner Traxel (pp. 53-87). Passau, Germany: Passavia-Universitts-Verlag. Drner, D., Kreuzig, H. W., Reither, F., & Studel, T. (Eds.). (1983). Lohhausen. Vom Umgang mit Unbestimmtheit und Komplexitt [Lohhausen. On dealing with uncertainty and complexity]. Bern, Switzerland: Hans Huber.

Problem solving Drner, 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., Schmann, M., & Widowski, D. (1986). Der Umgang von Psychologen mit Komplexitt [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. Hbner, 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 fr 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 Problemlsen - Eine Sackgasse? [Complex problem solving - a dead end?]. Zeitschrift fr 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 Problemlsen: Bestimmung der Problemlsegte von Probanden mittels Verfahren des Operations Research ? ein interdisziplinrer 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. Mller, H. (1993). Komplexes Problemlsen: Reliabilitt 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 Problemlsen. Zum Einflu des Anteils der richtigen Lsungen (ArL) auf das Problemlseverhalten 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).

78

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. DZurilla, 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.201274). 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

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

79

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

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

81

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).

Theory of Constraints

82

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.

Theory of Constraints

83

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.

Theory of Constraints

84

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:

Theory of Constraints

85

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.

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.

86

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.3335, 264268. [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 Gdel (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): 190195. [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): 121129. [13] Steyn, Herman (2000). "An Investigation Into the Fundamentals of Critical Chain Project Scheduling.". International Journal of Project Management (19): 363369. [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.

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/

87

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.

Extreme programming

88

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.

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.

89

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.

Extreme programming

90

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.

Extreme programming

91

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

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.

92

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 teams progress towards the customers 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.

Extreme programming

93

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

Extreme programming

94

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

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]

95

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]

Extreme programming

96

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 inefficientif 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.

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 2332. 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.

97

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

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

98

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 Schwabers 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

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 approachaccepting that the problem cannot be fully understood or defined, focusing instead on maximizing the teams 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 Scrums biggest advantages is that it is very easy to learn and requires little effort to start using.

99

Roles
A number of roles are defined in Scrum. All roles fall into two distinct groupspigs and chickensbased 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 dont 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 dont we call it Ham and Eggs? I dont think so, says the pig, Id be committed, but youd only be involved. So the pigs are committed to building software regularly and frequently, while everyone else is a chickeninterested in the project but really indifferent because if it fails theyre not the pigsthat is, they werent 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 processthey 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 ScrumMasters 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 59 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

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" .

100

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 teams way?

Sprint Planning Meeting[10] [11] At the beginning of the sprint cycle (every 730 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

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]

101

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.

Scrum (development)

102

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 sprints length. Product backlog A prioritized list of high level requirements. Sprint backlog A prioritized list of tasks to be completed during the sprint.

Scrum (development)

103

Others
Impediment Anything that prevents a team member from performing work as efficiently as possible. Sprint A time period (typically 24 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 Scrums 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 teams 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 teams 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

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]

104

Product development
Scrum as applied to product development was first referred to in The New Product Development Game [22] (Harvard Business Review 86116:137146, 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 Alliances Scrum library [28] A Scrum Process Asset Library [29] A Scrum Process Description [30] by the Eclipse Process Framework (EPF) Project [31]

Scrum (development)

105

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. 141143 [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

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

106

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

107

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 activitys 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

Event chain methodology

108

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

Event chain methodology

109

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): 93106. 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

Human interaction management

110

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

Process modeling

111

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.

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.

112

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.

Process modeling 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]

113

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.

114

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

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 & Jrgensen, 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 frameworks 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 verbnoun 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] .

117

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. Fernstrm 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.

Process modeling
[16] O. Lindland, G. Sindre and A. Slvberg, Understanding quality in conceptual modeling, IEEE Software 11 (2) (1994), pp. 4249 [17] D. Moody, G. Sindre, T. Brasethvik and A. Slvberg, 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 711, 2002, Proceedings, Lecture Notes in Computer Science vol. 2503, Springer (2002), pp. 380396. [18] Daniel L. Moody, G. Sindre, T. Brasethvik, A. Slvberg. 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. 3049 [22] G. Canfora, F. Garca, 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. 113129. [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 2428, 2007, Proceedings, Lecture Notes in Computer Science vol. 4714, Springer, Brisbane, Australia (2007), pp. 4863. [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, <http://www.bpminstitute.org/articles/article/article/bpms-watch-ten-tips-for-effective-process-modeling.html>,Wednesday January 30, 2008 [28] J. Mendling, H.A. Reijers, J. Recker, Activity Labeling in Process Modeling: Empirical Insights and Recommendations, Information Systems. URL: <http://eprints.qut.edu.au/19625/> [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 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.

120

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.

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.

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

Gantt chart

121

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 (18611919), who designed his chart around the years 19101915.[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.

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 Opt. (O) Time estimates Normal (M) 4 5 5 6 5 4 5 6 9 7 10 7 8 8 Pess. (P) 4.00 5.33 5.17 6.33 5.17 4.50 5.17 Expected time

A B C D E F G

A A B, C D E

2 3 4 4 4 3 3

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 doesnt 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

125

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.

PRINCE2

126

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

PRINCE2

127

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/

Process-based management

128

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).

ISO/IEC 15504

129

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.

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 5 4 3 2 1 0 Name Optimizing process Predictable process Established process Managed process 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]

131

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]

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.

132

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.

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.

133

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.

ISO/IEC 15504

134

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] Pgina 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/

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 2 2 2 2 2 2

REQM PMC PP CM MA PPQA

Requirements Management Project Monitoring and Control Project Planning Configuration Management Measurement and Analysis Process and Product Quality Assurance Organizational Process Definition Causal Analysis

Engineering Project Management Project Management Support Support Support

OPD CAR

Process Management Support

3 5

Capability Maturity Model Integration

137

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.3Plans 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 organizations 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 organizations 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 organizations 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

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 Institutes (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. Theyve 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]

138

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 (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations with 10012000 employees are rated at the highest level (5: Optimizing). Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum and CMMI brings more adaptability and predictability than either one alone. David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner. Other viewpoints about using CMMI and Agile development are available on the SEI Web site [14]. The combination of the project management technique earned value management (EVM) with CMMI has been described (Solomon, 2002 [15]). To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, (which relies on oral communication), was evaluated as not compliant with CMMI. CMMI can be appraised using two different approaches: staged and continuous. The staged approach yields appraisal results as one of five maturity levels. The continuous approach yields one of six capability levels. The differences in these approaches are felt only in the appraisal; the best practices are equivalent and result in equivalent process improvement results.

See also
Process area (CMMI) Software Engineering Process Group

Official sources
SEI reports "CMMI for Development, Version 1.2" [6] (pdf). CMMI-DEV (Version 1.2, August 2006). Carnegie Mellon University Software Engineering Institute. 2006. Retrieved 22 August 2007. "CMMI for Acquisition, Version 1.2" [3] (pdf). CMMI-ACQ (Version 1.2, November 2007). Carnegie Mellon University Software Engineering Institute. 2007. Retrieved 19 December 2007.

Capability Maturity Model Integration "CMMI for Services, Version 1.2" [4] (pdf). CMMI-SVC (Version 1.2, February 2009). Carnegie Mellon University Software Engineering Institute. 2007. Retrieved 30 September 2009. "Process Maturity Profile (March 2007)" [16] (PDF). CMMI v1.1 SCAMPI v1.1 Class A Appraisal Results 2006 End-Year Update. Software Engineering Institute. Retrieved 31 March 2007. "Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2)" [17] (pdf). Carnegie Mellon University Software Engineering Institute. 2006. Retrieved 22 August 2006. "Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A Versiions 1.2: Method Definition Document" [18] (doc). Carnegie Mellon University Software Engineering Institute. 2006. Retrieved 22 August 2006. CMMI Guidebook Acquirer Team (2007). "Understanding and Leveraging a Supplier's CMMI Efforts: A Guidebook for Acquirers" [19] (pdf). CMU/SEI-2007-TR-004. Software Engineering Institute. Retrieved 23 August 2007. SEI web pages "CMMI Model Download" [20]. Software Engineering Institute. 2009. Retrieved 30 September 2009. "SEI Partner List" [21]. Software Engineering Institute. Retrieved 28 October 2006. SCAMPI Appraisal Results [22]. The complete SEI list of published SCAMPI appraisal results.

139

External links
Official website [23] Capability Maturity Model Integration [24] at the Open Directory Project Graphical comment by Scott Adams [25]

References
[1] Sally Godfrey (2008) What is CMMI ? (http:/ / software. gsfc. nasa. gov/ docs/ What is CMMI. ppt). NASA presentation. Accessed 8 dec 2008. [2] What is CMMI? (http:/ / www. sei. cmu. edu/ cmmi/ general/ index. html). Software Engineering Institute. Accessed 30 October 2008. [3] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 07tr017. cfm [4] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 09tr001. cfm [5] http:/ / www. sei. cmu. edu/ library/ abstracts/ news-at-sei/ cmmiinfocus200904. cfm [6] For the latest published CMMI appraisal results see the SEI Web site (http:/ / sas. sei. cmu. edu/ pars/ ). [7] "Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.2: Method Definition Document" (http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 06hb002. cfm). CMU/SEI-2006-HB-002. Software Engineering Institute. 2006. . Retrieved 23 September 2006. [8] http:/ / sas. sei. cmu. edu/ pars/ [9] "Getting Started with CMMI Adoption" (http:/ / www. sei. cmu. edu/ cmmi/ adoption/ cmmi-start. html). . Retrieved 4 January 2009. [10] "Process Maturity Profile" (http:/ / www. sei. cmu. edu/ library/ assets/ 2006marSwCMM. pdf). . Retrieved 4 January 2009. [11] Daniel S. Wall, James McHale, Marsha Pomeroy-Huff. Case Study: Accelerating Process Improvement by Integrating the TSP and CMMI. Software Engineering Institute special report CMU/SEI-2005-SR-012, December 2005. http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 05sr012. cfm [12] "CMMI Performance Results, 2005" (http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 06tr004. cfm). . Retrieved 2006-09-23. [13] http:/ / www. sei. cmu. edu/ library/ assets/ 2005sepCMMI. pdf [14] http:/ / www. sei. cmu. edu/ cmmi/ casestudies/ mappings/ comparisons. cfm [15] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 02tn016. cfm [16] http:/ / www. sei. cmu. edu/ library/ assets/ 2007marCMMI. pdf [17] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 06tr011. cfm [18] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 06hb002. cfm [19] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 07tr004. cfm [20] http:/ / www. sei. cmu. edu/ cmmi/ tools/ index. cfm [21] http:/ / www. sei. cmu. edu/ partners/ directory/ organization/ index. cfm [22] http:/ / sas. sei. cmu. edu/ pars/ pars. aspx [23] http:/ / www. sei. cmu. edu/ cmmi [24] http:/ / www. dmoz. org/ Computers/ Programming/ Methodologies/ Capability_Maturity_Model/

Capability Maturity Model Integration

[25] http:/ / dilbert. com/ dyn/ str_strip/ 000000000/ 00000000/ 0000000/ 000000/ 80000/ 4000/ 500/ 84510/ 84510. strip. gif

140

Research and development

The phrase research and development (also R and D or, more often, R&D), according to the Organization for Economic Co-operation and Development, refers to "creative work undertaken on a systematic basis in order to increase the stock of knowledge, including knowledge of man, culture and society, and the use of this stock of knowledge to devise new applications".[1]
Cycle of research and development

Overview
New product design and development is more often than not a crucial factor in the survival of a company. In an industry that is fast changing, firms must continually revise their design and range of products. This is necessary due to continuous technology change and development as well as other competitors and the changing preference of customers. A system driven by marketing is one that puts the customer needs first, and only produces goods that are known to sell. Market research is carried out, which establishes what is needed. If the development is technology driven then it is a matter of selling what it is possible to make. The product range is developed so that production processes are as efficient as possible and the products are technically superior, hence possessing a natural advantage in the market place. R&D has a special economic significance apart from its conventional association with scientific and technological development. R&D investment generally reflects a government's or organization's willingness to forgo current operations or profit to improve future performance or returns, and its abilities to conduct research and development. The top eight spenders in terms of percentage of GDP were Israel (4.53%), Sweden (3.73%), Finland (3.45%) Japan (3.39%), South Korea (3.23%), Switzerland (2.9%), Iceland (2.78%) and United States (2.62%).[2] In general, R&D activities are conducted by specialized units or centers belonging to companies, universities and state agencies. In the context of commerce, "research and development" normally refers to future-oriented, longer-term activities in science or technology, using similar techniques to scientific research without predetermined outcomes and with broad forecasts of commercial yield. Statistics on organizations devoted to "R&D" may express the state of an industry, the degree of competition or the lure of progress. Some common measures include: budgets, numbers of patents or on rates of peer-reviewed publications. Bank ratios are one of the best measures, because they are continuously maintained, public and reflect risk. In the U.S., a typical ratio of research and development for an industrial company is about 3.5% of revenues. A high technology company such as a computer manufacturer might spend 7%. Although Allergan (a biotech company) tops the spending table 43.4% investment, anything over 15% is remarkable and usually gains a reputation for being a high technology company. Companies in this category include pharmaceutical companies such as Merck & Co. (14.1%) or Novartis (15.1%), and engineering companies like Ericsson (24.9%).[3] Such companies are often seen as poor credit risks because their spending ratios are so unusual.

Research and development Generally such firms prosper only in markets whose customers have extreme needs, such as medicine, scientific instruments, safety-critical mechanisms (aircraft) or high technology military armaments. The extreme needs justify the high risk of failure and consequently high gross margins from 60% to 90% of revenues. That is, gross profits will be as much as 90% of the sales cost, with manufacturing costing only 10% of the product price, because so many individual projects yield no exploitable product. Most industrial companies get only 40% revenues. On a technical level, high tech organizations explore ways to re-purpose and repackage advanced technologies as a way of amortizing the high overhead. They often reuse advanced manufacturing processes, expensive safety certifications, specialized embedded software, computer-aided design software, electronic designs and mechanical subsystems. Research has shown that firms with a persistent R&D strategy outperform those with an irregular or no R&D investment programme.[4]

141

Pharmaceuticals
Research often refers to basic experimental research; development refers to the exploitation of discoveries. Research involves the identification of possible chemical compounds or theoretical mechanisms. In the United States, universities are the main provider of research level products. In the United States, corporations buy licences from universities or hire scientists directly when economically solid research level products emerge and the development phase of drug delivery is almost entirely managed by private enterprise. Development is concerned with proof of concept, safety testing, and determining ideal levels and delivery mechanisms. Development often occurs in phases that are defined by drug safety regulators in the country of interest. In the United States, the development phase can cost between $10 to $200 million and approximately one in ten compounds identified by basic research pass all development phases and reach market.

Business
Research and development is nowadays of great importance in business as the level of competition, production processes and methods are rapidly increasing. It is of special importance in the field of marketing where companies keep an eagle eye on competitors and customers in order to keep pace with modern trends and analyze the needs, demands and desires of their customers. Unfortunately, research and development are very difficult to manage, since the defining feature of research is that the researchers do not know in advance exactly how to accomplish the desired result. As a result, higher R&D spending does not guarantee "more creativity, higher profit or a greater market share".[5]

R&D alliance
An R&D alliance is a mutually beneficial formal relationship formed between two or more parties to pursue a set of agreed upon goals while remaining independent organisations, where acquiring new knowledge is a goal by itself. The different parties agree to combine their knowledge to create new innovative products. Thanks to funding from government organizations, like the European Union's Seventh Framework Programme (FP7), and modern advances in technology, R&D alliances have now become more efficient. Research and development is nowadays of great importance in business as the level of competition, production processes and methods are rapidly increasing. It is of special importance in the field of marketing where companies keep an eagle eye on competitors and customers in order to keep pace with modern trends and analyze the needs, demands and desires of their customers.

Research and development

142

See also
Basic research ERD3 (Energy research, development, demonstration and deployment) Demonstration Deployment Innovation List of business and finance abbreviations Research Science policy Technology Life Cycle

External links
U.S. Federal Investments in Energy R&D: 1961-2008 [6] R&D Magazine [7]: R&D 100 Awards [8]. DOE Funded Research Projects Win 30 R&D Awards for 2008 [9] USA Today May 2008 Q&A with Texas Instruments CEO about Bayh-Dole Act [10] OECD Science, Technology and Industry Outlook 2008 [11] 2010 Science and Engineering Indicators Research and Development: National Trends and International Linkages [12]

References
[1] OECD OECD Factbook 2008: Economic, Environmental and Social Statistics (http:/ / lysander. sourceoecd. org/ vl=5134145/ cl=23/ nw=1/ rpsv/ factbook/ 070101. htm) [2] http:/ / www. oecd. org/ dataoecd/ 17/ 53/ 41558958. pdf [3] All figures UK R&D Scoreboard (http:/ / www. innovation. gov. uk/ rd_scoreboard/ ) as of 2006. [4] Johansson; Lf (December 2008). "The Impact of Firms R&D Strategy on Profit and Productivity" (http:/ / cesis. abe. kth. se/ documents/ WP156. pdf). . [5] Aerospace and Defense: Inventing and Selling the Next Generation (http:/ / csis. org/ files/ publication/ 090520_diig_aerospace. pdf). Center for Strategic Internal Studies [6] http:/ / www. greentechhistory. com/ wp-content/ uploads/ 2009/ 07/ federal-investment-in-energy-rd-2008. pdf [7] http:/ / www. rdmag. com [8] http:/ / www. rdmag. com/ awards. aspx [9] http:/ / www. energy. gov/ news/ 6423. htm [10] http:/ / www. usatoday. com/ money/ companies/ management/ 2008-05-18-texas-instruments-rich-templeton_N. htm [11] http:/ / www. oecd. org/ document/ 36/ 0,3343,en_2649_33703_41546660_1_1_1_1,00. html [12] http:/ / www. nsf. gov/ statistics/ seind10/ c4/ c4h. htm

Stage-Gate model

143

Stage-Gate model
A stage-gate model is a technique in which a (product, process, system) development process is divided into stages separated by gates. At each gate, the continuation of the development process is decided by (typically) a manager or a steering committee. The decision is based on the information available at the time, including e.g. business case, risk analysis, availability of necessary resources (money, people with correct competencies) etc. The stage-gate model may also be known as stage-limited commitment or creeping commitment.

History
The stage-gate model was developed and first suggested by Robert G. Cooper in his book Winning at New Products, published in 1986.[1] The stage-gate model is based on empirical findings of numerous "NewProd" Studies conducted by R.G.Cooper (e.g. 1985, 1992, 1994).[2] , [3] , [4] The stage gate model refers to the use of funnel tools in decision making when dealing with new product development. Gates or decision points are placed at places in the product development process that are most beneficial to making decisions regarding continuance of product development. These production areas between the gates are idea generation, establishment of feasibility, development of capability, testing and validation and product launch. At the conclusion of each of these areas of development of a new product, it is the managers responsibility to make a decision as to whether or not the product should continue to be developed. The passing of gate to gate can be accomplished either formally, with some sort of documentation, or informally, decided upon based on the preferences and culture of the organization.

Stages
A common model is composed of the following stages: ideation, preliminary analysis, business case, development, testing, launch. A stage-gate model is a conceptual and operational road map for moving a new project from idea to launch -a blueprint for managing the new-product process to improve effectiveness and efficiency. The creator of Stage-Gate process was professor Robert G. Cooper, from McMaster University. The traditional Stage-Gate process has five stages and five gates.The stages are:[5] 1. 2. 3. 4. 5. Scoping Build Business Case Development Testing and Validation Launch

Conventionally, the gates between stages have the same number as the stage following them. In the front of process, there is a preliminary or ideation phase,called Discovery, and after the 5-th stage the process ends with the Post-Launch review.Major new product projects go through the full five-stage process.Moderate risk projects,including extensions,modification & improvements,use the short XPress version. Very minor changes (e.g. Sales-force& Marketing requests) may be executed using a lighter process (Stage-Gate Lite).Each stage consists of a set of prescribed,cross-functional,and parallel activities undertaken by a team of people from different functional areas. Stages have a common structure and consist of three main elements: a)Activities;b)Integrated Analysis;c)Deliverables. Activities consist mainly in information gathering by the project team to reduce key project uncertainties and risks. An integrated analysis of the results of the activities is undertaken by the project team. Deliverables of stages are the results of integrated analysis-and these are the input to the next Gate.

Stage-Gate model

144

Gates
Gates provide various points during the process where an assessment of the quality of an idea is undertaken. It includes three main issues: Quality of execution: Checks whether the previous step is executed in a quality fashion. Business rationale: Does the project continue to look like an attractive idea from an economic and business perspective. Action plan: The proposed action plan and the requested resources reasonable and sound. A gate meeting can lead to four results: go, kill, hold, recycle. Gates have a common structure and consist of three main elements: Deliverables, Criteria and Outputs. Deliverables: What the project manager and team deliver to the decision point.These deliverables are decided at the output of the previous gate,and are based on a standard menu of deliverables for each gate. Criteria: Questions or metrics on which the project is judged in order to make the Go/Kill/Hold/Recycle and prioritization decision. Outputs: Results of the gate review -a decision (Go/Kill/Hold/Recycle),along with an approved action plan for the next gate, and a list of deliverables and date for the next gate.

The stages in more detail

Discovery (stage 0)
The discovery stage is the first part of any product development, whether or not the stage gate model is being utilized. During this basic stage the development team is simply deciding what projects the company wants and is capable to pursue. During this stage it is common for companies to take part in idea generation activities such as brainstorming or other group thinking exercises. Once the idea generation team has selected a project that they would like to go forward with, it must be passed on to the first gate and therefore screened by the organizations decision makers. When searching for new product ideas it is beneficial for an organization to look to the outside world to suggest business opportunities. Using methods such as those found in empathic design can be quite helpful. Communicating with customers to understand how and why they use products can produce great strides in idea generation. Specifically, communicating with lead users can provide great feedback to the developers, as these customers are most likely to feel most passionately about the product. In addition to communication with lead users, it may be helpful for developers to communicate with suppliers. By understanding all of the types of business that their materials are being used for, developers may be able to act upon previously untapped possibilities.

Scoping (stage 1)
The second stage of the product development process is scoping. During this step the main goal is to evaluate the product and its corresponding market. The researchers must recognize the strengths and weaknesses of the product and what it is going to offer to the potential consumer. The competition must also be evaluated during this stage. It is important for the researchers to understand who and what is already in the market as well as what can potentially be developed. By determining the relative level of threat from competitors, the management team will be able to recognize whether or not they should go forward with the production of the product, whether or not they should pass the product onto the next stage.

Stage-Gate model

145

Building the Business Case and Plan (stage 2)

Once the new product passes through gate one after the scoping phase, the next phase in the stage-gate model is building the business case and plan. This stage is the last stage of concept development where it is crucial for companies to perform a solid analysis before they begin developing the product. In comparison to the other stages in the stage-gate model this phase is generally difficult, complex, and resource-intensive. However, companies must put forth a strong effort in this stage for it is directly related to the success and development of a new product. There are four main steps that comprise this stage: Product Definition and Analysis, Building the Business Case, Building the Project Plan, and Feasibility Review. Product Definition and Analysis The first step, Product Definition and Analysis, is composed of a series of activities that will give you the information to define and justify the development of a new product. One of the first of these activities is the user needs and wants study where you will try to determine what creates value for the consumer. This addresses questions about the product such as what benefits does the product provide and what features should the product have. During this time the company should conduct surveys and interviews with existing and potential customers, along with staff members. Next, the company must conduct a market analysis. They must determine the market size and segmentation, rate of growth, buyer trend and behavior, and what channels to reach these buyers. Once the market analysis is complete the company must then conduct a competitive analysis. It is important to know how your competitors operate in addition to their strengths and weaknesses. This will not only help you build a great product, but will also help in determining how and where to launch your new product. Together these activities will help define the product and provide a foundation for the marketing strategy. Next, the company must build a technically feasible product concept, which includes the substance and methods needed to produce the new product. Once this is completed the company can then produce a production and operations cost analysis along with a market and launch costs analysis. Next, the company can begin to test the concept they have developed. This is when early prototypes are developed then presented to staff and consumers to gain feedback and gauge customer reaction. From this the company can make the necessary changes and see the sales potential of the product. This feedback will also help the company build a solid product definition. Lastly, the company will then conduct the business analysis, risk analysis, and financial analysis of the new product. These activities collectively make up the Product Definition and Analysis, the first of four steps. Building the Business Case Now one can move on to the second step, Building the Business Case. The business case is a document that defines the product and provides the rationale for developing it. This document will vary in format amongst companies, but the primary components are the following: results of the activities of Product Definition and Analysis; legal and regulatory requirements; safety, health, and environmental considerations; assumptions made to draw the conclusions you have, and why you believe they are valid and reasonable; and out-of-bounds criteria that indicate certain changes/events which will mandate an emergency business case review. This document will be referred to throughout the development process and edited when necessary.

Stage-Gate model Building the Project Plan The third of the four steps is Building the Project Plan. This includes a scheduled list of tasks and events along with timelines for milestones throughout the development process. Also included in the project plan are the personnel, time, and financial resources needed to complete the project. The project plan includes an expected launch date for the release of the new product. Feasibility Review The last step of building the business case and plan is the Feasibility Review. This is when management, along with other departments of the company, reviews the rationale for pursuing the product. They analyze the information provided by the previous steps in this process to decide whether or not the product should move forward. If it is decided to be pursued then it passes through gate two and moves on to the Product Development stage.

146

Development (stage 3)
During the development phase of the stage-gate process, plans from previous steps are actually executed. The products design and development is carried out, including some early, simple tests of the product and perhaps some early customer testing. The product's marketing and production plans are also developed during this stage. It is important that the company adheres to their overall goal of the project, which is reflected in these production and marketing plans. Doing this will allow them to definitively decide who they will market their product to and how they will get the product to that target audience. The development team maps out a realistic timeline with specific milestones that are described as SMART: Specific, Measurable, Actionable, Realistic, and Time bound. The timeline is frequently reviewed and updated, helping the team stay on task and giving management information about the product's progress. The development stage is when the product truly builds momentum as the company commits more resources to the project and makes full use of cross-functional teamwork as the marketing, technical, manufacturing, and sales departments all come together to offer their expert opinions. Having a diverse development ensures that the product continues to meet the company's technical and financial goals. A diverse team also allows specific roles and leadership positions to develop as team members make contributions using their strongest attributes. With members having clearly defined roles, tasks can be performed concurrently ensuring a much more efficient development process. The ultimate deliverable of the development stage is the prototype, which will undergo extensive testing and evaluation in the next stage of the stage-gate process.

Testing and Validation (stage 4)

The fourth step in Stage-Gate processing is the testing and validation period. The purpose of this stage is to provide validation for the entire project. The areas that will be evaluated include: the product itself, the production/manufacturing process, customer acceptance, and the financial merit of the project. Testing and Validation is broken up into 3 phases of testing: Near Testing, Field Testing, and Market Testing. Again, the main point of these tests is to validate your product. Near Testing The main objective in the first phase, near testing, is to find any bugs or issues with a product. The key point to remember here is that the product is no longer a prototype anymore and that it has almost all the features of the commercial model. Testing will be done initially by in-house staff, customers, and partners who are close to the firm. It is important to remember those testing have an understanding of how the product should perform, so they know what it should or shouldnt be doing. Members of the research development team are usually present to observe the participants using the product and take any notes or data that may be useful.

Stage-Gate model Field Testing Field Testing, or beta testing, is done by those who can provide valuable feedback on the product. This usually lasts a long period of time and the participants can include customers, partners, or anyone who is not familiar with the producing company. At this juncture the product fully resembles its planned launch model in all aspects; therefore the participants interaction rate will be higher because they know all the features and benefits. During this segment there are three primary objectives to be achieved. The first objective is to see how much the participant is interested. It is also worthwhile to note which individual attribute they prefer and, obviously, if they would buy the product. Next, figure out how the customer uses the product and look at its durability. Take a look at what environment the customers will be using the item in. Recording and analyzing the feedback received will be the final step in the field testing stage. The feedback can be used as a tool to help adjust any minor design improvements that need to be made. The Sales and Marketing team will also be a beneficiary of this feedback. They can use the information to help with their sales presentation and make it easier when they are trying to market the product. Market Testing The last phase in the Testing and Validation stage is the market testing. Unlike the other two, this is completely optional. It all boils down to this: A solid marketing plan and launch plan along with a confidence in the products ability to sell: go to the launching stage. If there is a doubt in any of these plans there are two options to proceed with. One option is a simulated market test. Customers will be exposed to new products in a staged advertising and purchasing situation. The goal of this test is to obtain an early forecast of sales from the observations and making any necessary adjustments. The second option involves trial sells. This test is done through specific channels, regions, or consumer demographics.

147

Product Launch (stage 5)

The product launch is the fifth and final stage of the stage- gate process and is the culmination of the product having met the proper requirements of the previous stage-gates. The product launch stage is one of the most important, if not the most important stage of product development. Development teams must come up with a marketing strategy to generate customer demand for the product. The company must also have to decide how large scale they anticipate the market for a new product to be and thus determine the size of their starting volume production. In addition part of the launch stage is training sales personnel and support personnel who are very familiar with the product and that can assist in market sales of this product. Having a smooth launch process is an important part in the stage-gate process because it translates to faster time to profit, but if done thoroughly and well step by step, a smooth launch process should also result in more effective marketing, a knowledgeable and prepared sales force, and ideally early customer acceptance. Another aspect which companies often misjudge during the launch process is the topic of setting a product price. Companies must dedicate sufficient time to price setting during the launch process to avoid either undershooting or overpricing the potential market. Finally, distribution is a major decision making part of the launch process. Selecting a distributor or vender for a product must be done with careful though and potential sales in mind. Taking all of these factors of the launch process into consideration is key to a successful product launch and in general a successful product.

Advantages and disadvantages

There are many benefits to using the stage-gate model. The organization of a firms innovation process can provide competitive advantage for a company, in that other companies will not be able to come up with products at the same quickness and quality level. Poor projects are quickly rejected by the model, resulting in a fast paced track for those products which are going to prove to be more successful for a firm. When using the stage gate model in a larger company, the model can help to make what could potentially be a large and limiting innovation process into a simple, guideline lead approach which allows an organization to demonstrate prioritization and focus into their

Stage-Gate model development process. When a stage gate model uses cost and fiscal analysis tools such as net present value, the company can potentially be provided with quantitative information regarding the feasibility of going forth with potential products. Finally, the stage-gate model is a great opportunity to validate the updated business case by projects executive sponsors[6] . Another benefits of using Stage-Gate model are: -accelerates speed-to-market; -increases likelihood of product success; -introduces discipline into on ordinarily chaotic process; -reduces re-work; -achieves efficient and effective allocation of scarce resources. The main problem with the stage-gate process is the potential for structural organization to interfere with creativity. Some experts believe that overkill of structure can cause creativity and customization to be put on the back burner of importance in an organization. The process needs to be modified to include a top-down link to the business strategy if applied to IT and other non-product development projects.

148

External links
http://www.prod-dev.com/stage-gate.php http://www.melodiesinmarketing.com/2007/09/07/building-the-business-case-plan/ http://www.melodiesinmarketing.com/2008/02/22/testing-validation/ http://www.york.ac.uk/enterprise/cetle/meng/Stage-Gate%20Model.pdf http://www.12manage.com/methods_cooper_stage-gate.html http://www.stage-gate.eu/

References
[1] Cooper, Robert G. (1986) Winning at New Products, Addison-Wesley, 273 pages [2] Cooper, 1985).Cooper, Robert G. Selecting winning new product projects: Using the NewProd System, in: Journal of Product Innovation Management, 1985, Vol. 2, pp.34-44 [3] Cooper (1992) Cooper, Robert G. The NewProd System: The Industry Experience, in: Journal of Product Innovation Management, 1992, Vol.9, pp.113-127 [4] Cooper (1994) Cooper, Robert, G. New Products: The Factors that Drive Success, in: International Marketing Review, 1994, Vol.11, pp.60-76 [5] Cooper, Robert G. (1993). Winning at New Products: Accelerating the Process from Idea to Launch. 2nd Ed.,Cambridge, Mass: Addison-Wesley [6] Conducting Successful Gate Meetings (http:/ / www. pmhut. com/ conducting-successful-gate-meetings)

Financial analysis

149

Financial analysis
Accountancy

Key concepts Accountant Bookkeeping Trial balance General ledger Debits and credits Cost of goods sold Double-entry system Standard practices Cash and accrual basis GAAP / IFRS Fields of accounting Cost Financial Forensic Fund Management Tax Financial statements Balance sheet Income statement Cash flow statement Equity Retained earnings Auditing Financial audit GAAS Internal audit SarbanesOxley Act Professional Accountants CPA Chartered Accountant CGA CMA

Financial analysis (also referred to as financial statement analysis or accounting analysis) refers to an assessment of the viability, stability and profitability of a business, sub-business or project. It is performed by professionals who prepare reports using ratios that make use of information taken from financial statements and other reports. These reports are usually presented to top management as one of their bases in making business decisions. Based on these reports, management may: Continue or discontinue its main operation or part of its business; Make or purchase certain materials in the manufacture of its product; Acquire or rent/lease certain machineries and equipment in the production of its goods; Issue stocks or negotiate for a bank loan to increase its working capital; Make decisions regarding investing or lending capital; Other decisions that allow management to make an informed selection on various alternatives in the conduct of its business.

Goals
Financial analysts often assess the firm's: 1. Profitability - its ability to earn income and sustain growth in both short-term and long-term. A company's degree of profitability is usually based on the income statement, which reports on the company's results of operations; 2. Solvency - its ability to pay its obligation to creditors and other third parties in the long-term; 3. Liquidity - its ability to maintain positive cash flow, while satisfying immediate obligations; Both 2 and 3 are based on the company's balance sheet, which indicates the financial condition of a business as of a given point in time. 4. Stability- the firm's ability to remain in business in the long run, without having to sustain significant losses in the conduct of its business. Assessing a company's stability requires the use of both the income statement and the balance sheet, as well as other financial and non-financial indicators.

Financial analysis

150

Methods
Financial analysts often compare financial ratios (of solvency, profitability, growth, etc.): Past Performance - Across historical time periods for the same firm (the last 5 years for example), Future Performance - Using historical figures and certain mathematical and statistical techniques, including present and future values, This extrapolation method is the main source of errors in financial analysis as past statistics can be poor predictors of future prospects. Comparative Performance - Comparison between similar firms. These ratios are calculated by dividing a (group of) account balance(s), taken from the balance sheet and / or the income statement, by another, for example : n / equity = return on equity Net income / total assets = return on assets Stock price / earnings per share = P/E-ratio Comparing financial ratios is merely one way of conducting financial analysis. Financial ratios face several theoretical challenges: They say little about the firm's prospects in an absolute sense. Their insights about relative performance require a reference point from other time periods or similar firms. One ratio holds little meaning. As indicators, ratios can be logically interpreted in at least two ways. One can partially overcome this problem by combining several related ratios to paint a more comprehensive picture of the firm's performance. Seasonal factors may prevent year-end values from being representative. A ratio's values may be distorted as account balances change from the beginning to the end of an accounting period. Use average values for such accounts whenever possible. Financial ratios are no more objective than the accounting methods employed. Changes in accounting policies or choices can yield drastically different ratio values. They fail to account for exogenous factors like investor behavior that are not based upon economic fundamentals of the firm or the general economy (fundamental analysis) [1] . Financial analysts can also use percentage analysis which involves reducing a series of figures as a percentage of some base amount[2] . For example, a group of items can be expressed as a percentage of net income. When proportionate changes in the same figure over a given time period expressed as a percentage is known as horizontal analysis[3] . Vertical or common-size analysis, reduces all items on a statement to a common size as a percentage of some base value which assists in comparability with other companies of different sizes [4] . Another method is comparative analysis. This provides a better way to determine trends. Comparative analysis presents the same information for two or more time periods and is presented side-by-side to allow for easy analysis.[5] .

Financial analysis

151

See also
Business valuation Fundamental analysis

External links
[6] SFAF - the French Society of Financial Analysts [7] ACIIA - Association of Certified International Investment Analysts [8] EFFAS - European Federation of Financial Analysts Societies

References
[1] Financial Ratios (http:/ / www. netmba. com/ finance/ financial/ ratios/ ) [2] Kieso, D. E., Weygandt, J. J., & Warfield, T. D. (2007). Intermediate Accounting (12th ed.). Hoboken, NJ: John Wiley & Sons, p. 1320 ISBN 0-471-74955-9 [3] Kieso, et al., 2007, p. 1320 [4] Kieso, et al., 2007, p. 1320 [5] Kieso, et al., 2007, p. 1319 [6] http:/ / www. sfaf. com [7] http:/ / www. aciia. org [8] http:/ / www. effas. com

Stakeholder analysis
Stakeholder analysis is a term used in conflict resolution, project management, and business administration to describe a process where all the individuals or groups that are likely to be affected by a proposed action are identified and then sorted according to how much they can affect the action and how much the action can affect them. This information is used to assess how the interests of those stakeholders should be addressed in a project plan, policy, program, or other action. Stakeholder analysis is a key part of Stakeholder management.

Overview
Stakeholder analysis is a term that refers to the action of analyzing the attitudes of stakeholders towards something (most frequently a project). It is frequently used during the preparation phase of a project to assess the attitudes of the stakeholders regarding the incoming changes. Stakeholder analysis can be done one shot or on a regular basis to track how stakeholders changed their attitudes over time. A stakeholder is any person or organization, who can be positively or negatively impacted by, or cause an impact on the actions of a company, government, or organization. Types of stakeholders are: Primary stakeholders : are those ultimately affected, either positively or negatively by an organization's actions. Secondary stakeholders : are the intermediaries, that is, persons or organizations who are indirectly affected by an organization's actions. Key stakeholders : (who can also belong to the first two groups) have significant influence upon or importance within an organization. Therefore, stakeholder analysis has the goal of developing cooperation between the stakeholder and the project team and, ultimately, assuring successful outcomes for the project. A stakeholder analysis is performed when there is a need to clarify the consequences of envisaged changes, or at the start of new projects and in connection with organizational changes generally. It is important to identify all stakeholders for the purpose of identifying their success criteria and turning these into quality goals.

Stakeholder analysis

152

Methods of Stakeholder Mapping

The following list identifies some of the best known and most commonly used methods for stakeholder mapping: (Mitchell, Agle et al. 1997) proposed a classification of stakeholders based on power to influence, the legitimacy of each stakeholders relationship with the organisation, and the urgency of the stakeholders claim on the organization. The results of this classification may assess the fundamental question of which groups are stakeholders deserving or requiring managers attention, and which are not? This is salience - the degree to which managers give priority to competing stakeholder claims (Mitchell, Agle et al., 2007:854) (Fletcher, Guthrie et al. 2003) defined a process for mapping stakeholder expectations based on value hierarchies and Key Performance Areas (KPA), (Savage, Nix et al. 1991) offer a way to classify stakeholders according to potential for threat and potential for cooperation. (Turner, Kristoffer and Thurloway, 2002) have developed a process of identification, assessment of awareness, support, influence leading to strategies for communication and assessing stakeholder satisfaction, and who is aware or ignorant and whether their attitude is supportive or opposing. Mapping techniques include the following sub-set of results from a Web search of analysis techniques being used by aid agencies, governments or consultant groups: Influence-interest grid (Imperial College London) Power-impact grid (Office of Government Commerce UK 2003) Mendelow's Power-interest grid (Moorhouse Consulting 2007)
A=High Power & Low Interest B=High Power & High Interest C=Low Power & Low Interest D=Low Power & High Interest

Three-dimensional grouping of power, interest and attitude (Murray-Webster and Simon 2005) The Stakeholder Circle (Bourne 2007) The first step in building any stakeholder map is to develop a categorised list of the members of the stakeholder community. Once the list is reasonably complete it is then possible to assign priorities in some way, and then to translate the highest priority stakeholders into a table or a picture. The potential list of stakeholders for any project will always exceed both the time available for analysis and the capability of the mapping tool to sensibly display the results, the challenge is to focus on the right stakeholders who are currently important and to use the tool to visualise this critical sub-set of the total community. The most common presentation styles use a matrix to represent two dimensions of interest with frequently a third dimension shown by the colour or size of the symbol representing the individual stakeholders. Some of the commonly used dimensions include: Power (high, medium, low) Support (positive, neutral, negative) Influence (high or low)

Other Forms of Stakeholder Analysis

In Sweden, there is a data collected about stakeholders as maps tabular, graphical or pictorial has been adopted by researchers and consultants from the earliest studies. The key element of an effective mapping process is as far as possible to replace subjectivity with objective measures and to make the assessment process transparent. This transparency will allow the basis of any assessment to be clearly understood by others and will facilitate review and updating as appropriate. We would suggest there are three basic approaches used to help visualize, map and understand stakeholders.

Stakeholder analysis The approach with the highest profile in general business is the customer relationship management or CRM approach. This approach requires substantial data sets to be gathered about a key segment of the business stakeholder community (typically customers) followed by the use of data mining techniques allow trends and opportunities to be identified, graphed and communicated. These reports inform management decision making and help the business prosper. CRM works effectively in situations where the business is relatively stable and there are a large class of stakeholders interacting with the business in a reasonably common way. A second approach that cannot be ignored is the extensive body of work focusing on influence networks. This research focuses on the importance of relationships through the study of influence networks, social networks, social capital, viewing projects as temporary knowledge organizations (TKOs) and more recently the idea of CRPR (Complex Responsive Processes of Relating)(Weaver 2007). All of these theories emphasize the critical importance of the relationships between different stakeholders both within and around the project team. The strength and effectiveness of the internal relationships enable the project team to function effectively and allows the team (or the project) to interact and influence its surrounding stakeholder community. The difficulty in using these strands of research lies in building the influence/relationship maps; the work is difficult, time consuming and invasive requiring extensive interviews with the stakeholders. Consequently whilst an appreciation of these ideas is critical for effective stakeholder management, the opportunities to undertake a detailed analysis of a particular stakeholder community are very limited and typically only occur as part of an academic research assignment. The need for a practical, usable approach to visualizing many different stakeholder communities has led to the development of a range of listing and mapping techniques by academics, consultants and businesses over the years. These approaches trade the richness of data available under the CRM approach for a holistic view of the whole stakeholder community and largely ignore the complex network of relationships considered in CRPR and the other network theories outlined above for a simpler consideration of importance in some form. Obviously the importance of a stakeholder is directly associated with his or her ability to influence the project through their network of relationships; the difference in the analysis is in the way this is assessed. All of the mapping techniques discussed above use a qualitative perception of a stakeholders importance rather than a quantitative analysis of the influence networks and relationships surrounding the stakeholder to determine an absolute value for that persons importance. A more recent form of Stakeholder Analysis can be seen in Triple Task Method. An approach which seeks to blend three disciplines: psychoanalytic theory, systems analysis and action research.

153

Benefits
Stakeholder analysis helps with the identification of the following[1] : Stakeholders' interests Potential risks Key people to be informed about the project during the execution phase Negative stakeholders as well as their adverse effects on the project

Stakeholder analysis

154

Further reading
Fletcher, A., et al. (2003). "Mapping stakeholder perceptions for a third sector organization." in: Journal of Intellectual Capital 4(4): 505 527. Mitchell, R. K., B. R. Agle, and D.J. Wood. (1997). "Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What really Counts." in: Academy of Management Review 22(4): 853 - 888. Savage, G. T., T. W. Nix, Whitehead and Blair. (1991). "Strategies for assessing and managing orgnaizational stakeholders." In: Academy of Management Executive 5(2): 61 75. Turner, J. R., V. Kristoffer, et al., Eds. (2002). The Project Manager as Change Agent. London, McGraw-Hill Publishing Co. Weaver, P. (2007). A Simple View of Complexity in Project Management. Proceedings of the 4th World Project Management Week. Singapore. Hemmati, M., Dodds F., Enayti, J.,McHarry J. (2002) "Multistakeholder Procesess on Governance and Sustainability. London Earthscan

References
[1] What Is Stakeholder Analysis? (http:/ / www. pmhut. com/ what-is-stakeholder-analysis), S. Babou, 2008

Deliverable
Deliverable is a term used in project management to describe a tangible or intangible object produced as a result of the project that is intended to be delivered to a customer (either internal or external). A deliverable could be a report, a document, a server upgrade or any other building block of an overall project[1] . The word is considered corporate jargon. A deliverable may be composed of multiple smaller deliverables. It may be either an outcome to be achieved (as in "The corporation says that making a profit this year is a deliverable.") or a product to be provided (as in "The deliverable for the completed consists of a special-purpose electronic device and its controlling software."). A deliverable differs from a project milestone in that a milestone is a measurement of progress toward an outcome whereas the deliverable is the result of the process. For a typical project, a milestone might be the completion of a product design while the deliverable might be the technical diagram of the product. In technical projects, deliverables can further be classified as hardware, software, or design documents. In the US DoD, a deliverable is any item delivered to the government under a contract, whether it is a physical product or an item of data. A nonseverable deliverable means a deliverable item that is a single end product or undertaking, entire in nature, that cannot be feasibly subdivided into discrete elements or phases without losing its identity.[2]

References
[1] Cutting, Thomas Deliverable-based Project Schedules: Part 1 (http:/ / www. pmhut. com/ deliverable-based-project-schedules-part-1), PM Hut (Last accessed 8 November 2009). [2] DFARS 204.7101

Budget

155

Budget
A budget (from old French bougette, purse) is generally a list of all planned expenses and revenues. It is a plan for saving and spending.[1] A budget is an important concept in microeconomics, which uses a budget line to illustrate the trade-offs between two or more goods. In other terms, a budget is an organizational plan stated in monetary terms. In summary, the purpose of budgeting is to: 1. Provide a forecast of revenues and expenditures i.e. construct a model of how our business might perform financially speaking if certain strategies, events and plans are carried out. 2. Enable the actual financial operation of the business to be measured against the forecast.

Business start-up budget

The process of calculating the costs of starting a small business begins with a list of all necessary purchases including tangible assets (for example, equipment, inventory) and services (for example, remodeling, insurance), working capital, sources and collateral. The budget should contain a narrative explaining how you decided on the amount of this reserve and a description of the expected financial results of business activities. The assets should be valued with each and every cost. All other expenses are like labour factory overhead all freshmen expenses are also included into business budgeting

Corporate budget
The budget of a company is often compiled annually, but may not be. A finished budget, usually requiring considerable effort, is a plan for the short-term future, typically one year (see Budget Year). While traditionally the Finance department compiles the company's budget, modern software allows hundreds or even thousands of people in various departments (operations, human resources, IT etc) to list their expected revenues and expenses in the final budget. If the actual figures delivered through the budget period come close to the budget, this suggests that the managers understand their business and have been successfully driving it in the intended direction. On the other hand, if the figures diverge wildly from the budget, this sends an 'out of control' signal, and the share price could suffer as a result.

Event management budget

A budget is a fundamental tool for an event director to predict with reasonable accuracy whether the event will result in a profit, a loss or will break-even. A budget can also be used as a pricing tool.

Government budget
The budget of a government is a summary or plan of the intended revenues and expenditures of that government.

United States
The United States federal budget is prepared by the Office of Management and Budget, and submitted to Congress for consideration. Invariably, Congress makes many and substantial changes. Nearly all American states are required to have balanced budgets, but the federal government is allowed to run deficits.

Budget

156

Personal or family budget

In a personal or family budget all sources of income (inflows) are identified and expenses (outflows) are planned with the intent of matching outflows to inflows (making ends meet.) In consumer theory, the equation restricting an individual or household to spend no more than its total resources is often called the budget constraint.

Budget types
Sales budget: The sales budget is an estimate of future sales, often broken down into both units and dollars. It is used to create company sales goals. Production budget: Product oriented companies create a production budget which estimates the number of units that must be manufactured to meet the sales goals. The production budget also estimates the various costs involved with manufacturing those units, including labor and material. Cash Flow/Cash budget: The cash flow budget is a prediction of future cash receipts and expenditures for a particular time period. It usually covers a period in the short term future. The cash flow budget helps the business determine when income will be sufficient to cover expenses and when the company will need to seek outside financing. Marketing budget: The marketing budget is an estimate of the funds needed for promotion, advertising, and public relations in order to market the product or service. Project budget: The project budget is a prediction of the costs associated with a particular company project. These costs include labor, materials, and other related expenses. The project budget is often broken down into specific tasks, with task budgets assigned to each. Revenue budget: The Revenue Budget consists of revenue receipts of government and the expenditure met from these revenues. Tax revenues are made up of taxes and other duties that the government levies. Expenditure budget: A budget type which include of spending data items..

See also
Budget crisis Budget Day Budget overrun Budget surplus Budget theory Budget FY 2010-11 Pakistan Canadian federal budget Chancellor of the Exchequer (UK budget) Deficit Envelope System Film budgeting Personal finance Strategic misrepresentation United States budget process Union budget of India United Kingdom budget Variance analysis (accounting)

Zero-based budgeting

Budget

157

External links
Origin of the word [2]

References
[1] Sullivan, Arthur; Steven M. Sheffrin (2003). Economics: Principles in action (http:/ / www. pearsonschool. com/ index. cfm?locator=PSZ3R9& PMDbSiteId=2781& PMDbSolutionId=6724& PMDbCategoryId=& PMDbProgramId=12881& level=4). Upper Saddle River, New Jersey 07458: Pearson Prentice Hall. pp.502. ISBN0-13-063085-3. . [2] http:/ / www. worldwidewords. org/ topicalwords/ tw-bud1. htm

New product development

In business and engineering, new product development (NPD) is the term used to describe the complete process of bringing a new product or service to market. There are two parallel paths involved in the NPD process: one involves the idea generation, product design and detail engineering; the other involves market research and marketing analysis. Companies typically see new product development as the first stage in generating and commercializing new products within the overall strategic process of product life cycle management used to maintain or grow their market share.

The process
1. Idea Generation is often called the "fuzzy front end" of the NPD process Ideas for new products can be obtained from basic research using a SWOT analysis (Strengths, Weaknesses, Opportunities & Threats), Market and consumer trends, company's R&D department, competitors, focus groups, employees, salespeople, corporate spies, trade shows, or Ethnographic discovery methods (searching for user patterns and habits) may also be used to get an insight into new product lines or product features. Idea Generation or Brainstorming of new product, service, or store concepts - idea generation techniques can begin when you have done your OPPORTUNITY ANALYSIS to support your ideas in the Idea Screening Phase (shown in the next development step). 2. Idea Screening The object is to eliminate unsound concepts prior to devoting resources to them. The screeners should ask several questions: Will the customer in the target market benefit from the product? What is the size and growth forecasts of the market segment/target market? What is the current or expected competitive pressure for the product idea? What are the industry sales and market trends the product idea is based on? Is it technically feasible to manufacture the product? Will the product be profitable when manufactured and delivered to the customer at the target price? 3. Concept Development and Testing Develop the marketing and engineering details Investigate intellectual property issues and search patent data bases Who is the target market and who is the decision maker in the purchasing process? What product features must the product incorporate? What benefits will the product provide?

How will consumers react to the product? How will the product be produced most cost effectively? Prove feasibility through virtual computer aided rendering, and rapid prototyping

New product development What will it cost to produce it? Testing the Concept by asking a sample of prospective customers what they think of the idea. Usually via Choice Modelling. 4. Business Analysis Estimate likely selling price based upon competition and customer feedback Estimate sales volume based upon size of market and such tools as the Fourt-Woodlock equation Estimate profitability and breakeven point 5. Beta Testing and Market Testing Produce a physical prototype or mock-up Test the product (and its packaging) in typical usage situations Conduct focus group customer interviews or introduce at trade show Make adjustments where necessary Produce an initial run of the product and sell it in a test market area to determine customer acceptance 6. Technical Implementation New program initiation Finalize Quality management system Resource estimation Requirement publication Publish technical communications such as data sheets Engineering operations planning Department scheduling Supplier collaboration Logistics plan Resource plan publication Program review and monitoring Contingencies - what-if planning 7. Commercialization (often considered post-NPD) Launch the product Produce and place advertisements and other promotions Fill the distribution pipeline with product Critical path analysis is most useful at this stage 8. New Product Pricing Impact of new product on the entire product portfolio Value Analysis (internal & external) Competition and alternative competitive technologies Differing value segments (price, value, and need) Product Costs (fixed & variable) Forecast of unit volumes, revenue, and profit

158

These steps may be iterated as needed. Some steps may be eliminated. To reduce the time that the NPD process takes, many companies are completing several steps at the same time (referred to as concurrent engineering or time to market). Most industry leaders see new product development as a proactive process where resources are allocated to identify market changes and seize upon new product opportunities before they occur (in contrast to a reactive strategy in which nothing is done until problems occur or the competitor introduces an innovation). Many industry leaders see new product development as an ongoing process (referred to as continuous development) in which the entire organization is always looking for opportunities.

New product development For the more innovative products indicated on the diagram above, great amounts of uncertainty and change may exist, which makes it difficult or impossible to plan the complete project before starting it. In this case, a more flexible approach may be advisable. Because the NPD process typically requires both engineering and marketing expertise, cross-functional teams are a common way of organizing projects. The team is responsible for all aspects of the project, from initial idea generation to final commercialization, and they usually report to senior management (often to a vice president or Program Manager). In those industries where products are technically complex, development research is typically expensive, and product life cycles are relatively short, strategic alliances among several organizations helps to spread the costs, provide access to a wider skill set, and speeds the overall process. Also, notice that because engineering and marketing expertise are usually both critical to the process, choosing an appropriate blend of the two is important. Observe (for example, by looking at the See also or References sections below) that this article is slanted more toward the marketing side. For more of an engineering slant, see the Ulrich and Eppinger, Ullman references below.[1] [2] People respond to new products in different ways. The adoption of a new technology can be analyzed using a variety of diffusion theories such as the Diffusion of innovations theory. A new product pricing process is important to reduce risk and increase confidence in the pricing and marketing decisions to be made. Bernstein and Macias describe an integrated process that breaks down the complex task of new product pricing into manageable elements.[3]

159

Fuzzy Front End

The Fuzzy Front End is the messy "getting started" period of new product development processes. It is in the front end where the organization formulates a concept of the product to be developed and decides whether or not to invest resources in the further development of an idea. It is the phase between first consideration of an opportunity and when it is judged ready to enter the structured development process (Kim and Wilemon , 2002;[4] Koen et al., 2001).[5] It includes all activities from the search for new opportunities through the formation of a germ of an idea to the development of a precise concept. The Fuzzy Front End ends when an organization approves and begins formal development of the concept. Although the Fuzzy Front End may not be an expensive part of product development, it can consume 50% of development time (see Chapter 3 of the Smith and Reinertsen reference below),[6] and it is where major commitments are typically made involving time, money, and the products nature, thus setting the course for the entire project and final end product. Consequently, this phase should be considered as an essential part of development rather than something that happens before development, and its cycle time should be included in the total development cycle time. Koen et al. (2001, pp.4751)[5] distinguish five different front-end elements (not necessarily in a particular order): 1. 2. 3. 4. 5. Opportunity Identification Opportunity Analysis Idea Genesis Idea Selection Concept and Technology Development

The first element is the opportunity identification. In this element, large or incremental business and technological chances are identified in a more or less structured way. Using the guidelines established here, resources will eventually be allocated to new projects.... which then lead to a structured NPPD (New Product & Process Development)strategy. The second element is the opportunity analysis. It is done to translate the identified opportunities into implications for the business and technology specific context of the company. Here extensive efforts may be made to align ideas to target customer groups and do market studies and/or technical trials and

New product development research. The third element is the idea genesis, which is described as evolutionary and iterative process progressing from birth to maturation of the opportunity into a tangible idea. The process of the idea genesis can be made internally or come from outside inputs, e.g. a supplier offering a new material/technology, or from a customer with an unusual request. The fourth element is the idea selection. Its purpose is to choose whether to pursue an idea by analyzing its potential business value. The fifth element is the concept and technology development. During this part of the front-end, the business case is developed based on estimates of the total available market, customer needs, investment requirements, competition analysis and project uncertainty. Some organizations consider this to be the first stage of the NPPD process (i.e., Stage 0). The Fuzzy Front End is also described in literature as "Front End of Innovation", "Phase 0", "Stage 0" or "Pre-Project-Activities". A universally acceptable definition for Fuzzy Front End or a dominant framework has not been developed so far.[7] In a glossary of PDMA[8] , it is mentioned that the Fuzzy Front End generally consists of three tasks: strategic planning, concept generation, and, especially, pre-technical evaluation. These activities are often chaotic, unpredictible, and unstructured. In comparison, the subsequent new product development process is typically structured, predictable, and formal. The term Fuzzy Front End was first popularized by Smith and Reinertsen (1991)[9] R.G.Cooper (1988)[10] describes the early stages of NPPD as a four step process in which ideas are generated (I),subjected to a preliminary technical and market assessment(II) and merged to coherent product concepts(III) which are finally judged for their fit with existing product strategies and portfolios (IV). In a more recent paper, Cooper and Edgett (2008) [11] affirm that vital predevelopment activities include: 1. 2. 3. 4. 5. 6. 7. 8. Preliminary market assessment. Technical assessment. Source-of-supply-assessment:suppliers and partners or alliances. Market research : market size and segmentation analysis,VoC (voice of customer) research. Product concept testing Value-to-the customer assessment Product definition Business and financial analysis.

160

These activities yield vital information to make a Go/No-Go to Development decision. In the in-depth study by Khurana and Rosenthal[12] front-end activities include: product strategy formulation and communication, opportunity identification and assessment, idea generation, product definition, project planning, and executive reviews.

Economical analysis, benchmarking of competitive products,and modeling and prototyping are also important activities during the front-end activities. The outcomes of FFE are the mission statement customer needs details of the selected concept product definition and specifications economic analysis of the product

the development schedule project staffing and the budget, and a

New product development business plan aligned with corporate strategy. In a paper by Husig, Kohn and Huskela (2005)[13] was proposed a conceptual model of Front-End Process which includes early Phases of Innovation Process. This model is structured in three phases and three gates: Phase 1: Environmental screening or opportunity identification stage in which external changes will be analysed and translated into potential business opportunities. Phase 2: Preliminary definition of an idea or concept. Phase 3: Detailed product, project or concept definition, and Business planning. The gates are: Opportunity screening; Idea evaluation; Go/No-Go for development. The final gate leads to a dedicated new product development project . Many professionals and academics consider that the general features of Fuzzy Front End (fuzziness,,ambiguity, and uncertainty) make difficult to see the FFE as a structured process,but rather as a set of interdependent activities ( e.g.Kim and Wilemon ,2002).[14] However, Husig et al.,2005 [10] argue that front-end not need to be fuzzy,but can be handled in a structured manner. Peter Koen[15] argue that in the FFE for incremental,platform and radical projects,three separate strategies and processes are typically involved.[15] The traditional Stage Gate (TM) process was designed for incremental product development,namely for a single product.The FFE for developing a new platform must start out with a strategic vision of where the company wants to develop products and this will lead to a family of products. Projects for breakthrough products start out with a similar strategic vision,but are associated with technologies which require new discoveries.It is worth mentioning what are incremental,platform and breakthrough products. Incremental products are considered to be cost reductions, improvements to existing product lines,additions to existing platforms and repositioning of existing products introduced in markets. Breakthrough products are new to the company or new to the world and offer a 5-10 times or greater improvement in performance combined with a 30-50% or greater reduction in costs. Platform products establish a basic architecture for a next generation product or process and are substantially larger in scope and resources than incremental projects[15] .

161

NPD organizations
Product Development and Management Association (PDMA) Association of International Product Marketing & Management

NPD strategies
Design for six sigma Stage-Gate model Quality function deployment Flexible product development

New product development

162

Related fields
Marketing Engineering Brand management Product management Industrial design

See also
Product Conceptual economy Product lifecycle Choice Modelling Time to market (TTM) Social design Requirements management

References
[1] Ulrich, Karl T. and Eppinger, Steven D (2004) Product Design and Development, 3rd Edition, McGraw-Hill, New York, 2004 [2] Ullman, David G. (2009) The Mechanical Design Process, Mc Graw-Hill, 4th edition [3] Bernstein, Jerry and Macias, David (2001) " Engineering New Product Success: the New Product Pricing Process at Emerson Electric (http:/ / valuepg. com/ Articles/ EngineeringNew ProductSuccess. PDF)" [4] Kim, J. and Wilemon, D. (2002), Sources and assessment of complexity in NPD projects. R&D Management, 33 (1), pp. 16-30. [5] Koen et al. (2001), Providing clarity and a common language to the fuzzy front end. Research Technology Management, 44 (2), pp.46-55 [6] Smith, Preston G. and Reinertsen, Donald G. (1998) Developing Products in Half the Time, 2nd Edition, John Wiley and Sons, New York, 1998. [7] Husig and Kohn (2003), Factors influencing the Front End of the Innovation Process: A comprehensive Review of Selected empirical NPD and explorative FFE Studies ,Brusell,Juni 2003,p.14. [8] "The PDMA Glossary for New Product Development" (http:/ / www. pdma. org/ npd_glossary. cfm). Product Development & Management Association. 2006. . [9] Smith,Preston G., Reinertsen Donald G.(1991) Developing products in half the time, Van Nostrand Reinhold,New York [10] Cooper,R.G. Predevelopment activities determine new product success, in: Industrial Marketing Management,Vol.17 (1988), No 2,pp. 237-248 [11] Cooper R.G., Edgett, S.J.(2008), Maximizing productivity in product innovation, in: Research Technology Management,March 1, 2008 [12] Khurana, A; Rosenthal, S.R. (1998). "Towards Holistic "Front Ends" in New Product Development". Journal of Product Innovation Management 15 (1): 5775. [13] Husig, S; Kohn, S; Poskela, J (2005). "The Role of Process Formalisation in the early Phases of the Innovation Process". 12th Int. Prod. Development Conf. Copenhagen. [14] Kim,J., Wilemon,D.(2002) : Accelerating the Front End Phase in New Product Development (http:/ / www. iamot. org) [15] Koen, Peter A. (2004), "The Fuzzy Front End for Incremental,Platform,and Breakthrough Products", PDMA Handbook of New Product Development, 2nd Ed.: 8191

Risk

163

Risk
Risk concerns the deviation of one or more results of one or more future events from their expected value. Technically, the value of those results may be positive or negative. However, general usage tends focus only on potential harm that may arise from a future event, which may accrue either from incurring a cost ("downside risk [1]") or by failing to attain some benefit ("upside risk [1]").

Historical background
The term risk may be traced back to classical Greek rizikon (Greek , riza), meaning root, later used in Latin for "cliff". The term is used in Homer's Rhapsody M of Odyssey "Sirens, Scylla, Charybdee and the bulls of Helios (Sun)" Odysseus tried to save himself from Charybdee at the cliffs of Scylla, where his ship was destroyed by heavy seas generated by Zeus as a punishment for his crew killing before the bulls of Helios (the god of the sun), by grapping the roots of a wild fig tree. For the sociologist Niklas Luhmann the term 'risk' is a neologism that appeared with the transition from traditional to modern society.[2] "In the Middle Ages the term risicum was used in highly specific contexts, above all sea trade and its ensuing legal problems of loss and damage."[2] [3] In the vernacular languages of the 16th century the words rischio and riezgo were used,[2] both terms derived from the Arabic word "" ,"rizk", meaning 'to seek prosperity'. This was introduced to continental Europe, through interaction with Middle Eastern and North African Arab traders. In the English language the term risk appeared only in the 17th century, and "seems to be imported from continental Europe."[2] When the terminology of risk took ground, it replaced the older notion that thought "in terms of good and bad fortune."[2] Niklas Luhmann (1996) seeks to explain this transition: "Perhaps, this was simply a loss of plausibility of the old rhetorics of Fortuna as an allegorical figure of religious content and of prudentia as a (noble) virtue in the emerging commercial society."[4] Scenario analysis matured during Cold War confrontations between major powers, notably the United States and the Soviet Union. It became widespread in insurance circles in the 1970s when major oil tanker disasters forced a more comprehensive foresight. The scientific approach to risk entered finance in the 1960s with the advent of the capital asset pricing model and became increasingly important in the 1980s when financial derivatives proliferated. It reached general professions in the 1990s when the power of personal computing allowed for widespread data collection and numbers crunching. Governments are using it, for example, to set standards for environmental regulation, e.g. "pathway analysis" as practiced by the United States Environmental Protection Agency.

Risk

164

Definitions of risk
There are many definitions of risk that vary by specific application and situational context. The widely inconsistent and ambiguous use of the word is one of several current criticisms of the methods to manage risk.[5] In one definition, "risks" are simply future issues that can be avoided or mitigated, rather than present problems that must be immediately addressed.[6] In risk management, the term "hazard" is used to mean an event that could cause harm and the term "risk" is used to mean simply the probability of something happening. OHSAS defines risk as the product of the probability of a hazard resulting in an adverse event, times the severity of the event.[7] Mathematically, risk often simply defined as: One of the first major uses of this concept was at the planning of the Delta Works in 1953, a flood protection program in the Netherlands, with the aid of the mathematician David van Dantzig.[8] The kind of risk analysis pioneered here has become common today in fields like nuclear power, aerospace and the chemical industry. There are more sophisticated definitions, however. Measuring engineering risk is often difficult, especially in potentially dangerous industries such as nuclear energy. Often, the probability of a negative event is estimated by using the frequency of past similar events or by event-tree methods, but probabilities for rare failures may be difficult to estimate if an event tree cannot be formulated. Methods to calculate the cost of the loss of human life vary depending on the purpose of the calculation. Specific methods include what people are willing to pay to insure against death,[9] and radiological release (e.g., GBq of radio-iodine). There are many formal methods used to assess or to "measure" risk, considered as one of the critical indicators important for human decision making. Financial risk is often defined as the unexpected variability or volatility of returns and thus includes both potential worse-than-expected as well as better-than-expected returns. References to negative risk below should be read as applying to positive impacts or opportunity (e.g., for "loss" read "loss or gain") unless the context precludes. In statistics, risk is often mapped to the probability of some event seen as undesirable. Usually, the probability of that event and some assessment of its expected harm must be combined into a believable scenario (an outcome), which combines the set of risk, regret and reward probabilities into an expected value for that outcome. (See also Expected utility.) Thus, in statistical decision theory, the risk function of an estimator (x) for a parameter , calculated from some observables x, is defined as the expectation value of the loss function L,

In information security, a risk is written as an asset, the threats to the asset and the vulnerability that can be exploited by the threats to impact the asset - an example being: Our desktop computers (asset) can be compromised by malware (threat) entering the environment as an email attachment (vulnerability). The risk is then assessed as a function of three variables: 1. the probability that there is a threat 2. the probability that there are any vulnerabilities 3. the potential impact to the business. The two probabilities are sometimes combined and are also known as likelihood. If any of these variables approaches zero, the overall risk approaches zero.

Risk

165

Risk versus uncertainty

Risk: Combination of the likelihood of an occurrence of a hazardous event or exposure(s) and the severity of injury or ill health that can be caused by the event or exposure(s) In his seminal work Risk, Uncertainty, and Profit, Frank Knight (1921) established the distinction between risk and uncertainty.

... Uncertainty must be taken in a sense radically distinct from the familiar notion of Risk, from which it has never been properly separated. The term "risk," as loosely used in everyday speech and in economic discussion, really covers two things which, functionally at least, in their causal relations to the phenomena of economic organization, are categorically different. ... The essential fact is that "risk" means in some cases a quantity susceptible of measurement, while at other times it is something distinctly not of this character; and there are far-reaching and crucial differences in the bearings of the phenomenon depending on which of the two is really present and operating. ... It will appear that a measurable uncertainty, or "risk" proper, as we shall use the term, is so far different from an unmeasurable one that it is not in effect an uncertainty at all. We ... accordingly restrict the term "uncertainty" to cases of the non-quantitive type.

Thus, Knightian uncertainty is immeasurable, not possible to calculate, while in the Knightian sense risk is measureable. Another distinction between risk and uncertainty is proposed in How to Measure Anything: Finding the Value of Intangibles in Business and The Failure of Risk Management: Why It's Broken and How to Fix It by Doug Hubbard:[10] [11] Uncertainty: The lack of complete certainty, that is, the existence of more than one possibility. The "true" outcome/state/result/value is not known. Measurement of uncertainty: A set of probabilities assigned to a set of possibilities. Example: "There is a 60% chance this market will double in five years" Risk: A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome. Measurement of risk: A set of possibilities each with quantified probabilities and quantified losses. Example: "There is a 40% chance the proposed oil well will be dry with a loss of $12 million in exploratory drilling costs". In this sense, Hubbard uses the terms so that one may have uncertainty without risk but not risk without uncertainty. We can be uncertain about the winner of a contest, but unless we have some personal stake in it, we have no risk. If we bet money on the outcome of the contest, then we have a risk. In both cases there are more than one outcome. The measure of uncertainty refers only to the probabilities assigned to outcomes, while the measure of risk requires both probabilities for outcomes and losses quantified for outcomes.

Risk as a vector quantity

Hubbard also argues that that defining risk as the product of impact and probability presumes (probably incorrectly) that the decision makers are risk neutral.[11] Only for a risk neutral person is the "certain monetary equivalent" exactly equal to the probability of the loss times the amount of the loss. For example, a risk neutral person would consider 20% chance of winning $1 million exactly equal to $200,000 (or a 20% chance of losing $1 million to be exactly equal to losing $200,000). However, most decision makers are not actually risk neutral and would not consider these equivalent choices. This gave rise to Prospect theory and Cumulative prospect theory. Hubbard proposes instead that risk is a kind of "vector quantity" that does not collapse the probability and magnitude of a risk by presuming anything about the risk tolerance of the decision maker. Risks are simply described as an set or function of possible loss amounts each associated with specific probabilities. How this array is collapsed into a single value cannot be done until the risk tolerance of the decision maker is quantified. Risk can be both negative and positive, but it tends to be the negative side that people focus on. This is because some things can be dangerous, such as putting their own or someone elses life at risk. Risks concern people as they think

Risk that they will have a negative effect on their future.

166

Insurance and health risk

Insurance is a risk-reducing investment in which the buyer pays a small fixed amount to be protected from a potential large loss. Gambling is a risk-increasing investment, wherein money on hand is risked for a possible large return, but with the possibility of losing it all. Purchasing a lottery ticket is a very risky investment with a high chance of no return and a small chance of a very high return. In contrast, putting money in a bank at a defined rate of interest is a risk-averse action that gives a guaranteed return of a small gain and precludes other investments with possibly higher gain. Risks in personal health may be reduced by primary prevention actions that decrease early causes of illness or by secondary prevention actions after a person has clearly measured clinical signs or symptoms recognized as risk factors. Tertiary prevention reduces the negative impact of an already established disease by restoring function and reducing disease-related complications. Ethical medical practice requires careful discussion of risk factors with individual patients to obtain informed consent for secondary and tertiary prevention efforts, whereas public health efforts in primary prevention require education of the entire population at risk. In each case, careful communication about risk factors, likely outcomes and certainty must distinguish between causal events that must be decreased and associated events that may be merely consequences rather than causes.

Economic risk
Economic risks can be manifested in lower incomes or higher expenditures than expected. The causes can be many, for instance, the hike in the price for raw materials, the lapsing of deadlines for construction of a new operating facility, disruptions in a production process, emergence of a serious competitor on the market, the loss of key personnel, the change of a political regime, or natural disasters.[12]

In business
Means of assessing risk vary widely between professions. Indeed, they may define these professions; for example, a doctor manages medical risk, while a civil engineer manages risk of structural failure. A professional code of ethics is usually focused on risk assessment and mitigation (by the professional on behalf of client, public, society or life in general). In the workplace, incidental and inherent risks exist. Incidental risks are those that occur naturally in the business but are not part of the core of the business. Inherent risks have a negative effect on the operating profit of the business.

Risk-sensitive industries
Some industries manage risk in a highly quantified and numerate way. These include the nuclear power and aircraft industries, where the possible failure of a complex series of engineered systems could result in highly undesirable outcomes. The usual measure of risk for a class of events is then: R = probability of the event C The total risk is then the sum of the individual class-risks. In the nuclear industry, consequence is often measured in terms of off-site radiological release, and this is often banded into five or six decade-wide bands. The risks are evaluated using fault tree/event tree techniques (see safety engineering). Where these risks are low, they are normally considered to be "Broadly Acceptable". A higher level of risk (typically up to 10 to 100 times what is considered Broadly Acceptable) has to be justified against the costs of reducing it further and the possible benefits that make it tolerablethese risks are described as "Tolerable if ALARP". Risks beyond this level are classified as

Risk "Intolerable". The level of risk deemed Broadly Acceptable has been considered by regulatory bodies in various countriesan early attempt by UK government regulator and academic F. R. Farmer used the example of hill-walking and similar activities, which have definable risks that people appear to find acceptable. This resulted in the so-called Farmer Curve of acceptable probability of an event versus its consequence. The technique as a whole is usually referred to as Probabilistic Risk Assessment (PRA) (or Probabilistic Safety Assessment, PSA). See WASH-1400 for an example of this approach. In finance In finance, risk is the probability that an investment's actual return will be different than expected. This includes the possibility of losing some or all of the original investment. Some regard a calculation of the standard deviation of the historical returns or average returns of a specific investment as providing some historical measure of risk; see modern portfolio theory. Financial risk may be market-dependent, determined by numerous market factors, or operational, resulting from fraudulent behavior (e.g. Bernard Madoff). Recent studies suggest that testosterone level plays a major role in risk taking during financial decisions.[13] [14] In finance, risk has no one definition, but some theorists, notably Ron Dembo, have defined quite general methods to assess risk as an expected after-the-fact level of regret. Such methods have been uniquely successful in limiting interest rate risk in financial markets. Financial markets are considered to be a proving ground for general methods of risk assessment. However, these methods are also hard to understand. The mathematical difficulties interfere with other social goods such as disclosure, valuation and transparency. In particular, it is not always obvious if such financial instruments are "hedging" (purchasing/selling a financial instrument specifically to reduce or cancel out the risk in another investment) or "speculation" (increasing measurable risk and exposing the investor to catastrophic loss in pursuit of very high windfalls that increase expected value). As regret measures rarely reflect actual human risk-aversion, it is difficult to determine if the outcomes of such transactions will be satisfactory. Risk seeking describes an individual whose utility function's second derivative is positive. Such an individual would willingly (actually pay a premium to) assume all risk in the economy and is hence not likely to exist. In financial markets, one may need to measure credit risk, information timing and source risk, probability model risk, and legal risk if there are regulatory or civil actions taken as a result of some "investor's regret". Knowing one's risk appetite in conjunction with one's financial well-being are most crucial. A fundamental idea in finance is the relationship between risk and return (see modern portfolio theory). The greater the potential return one might seek, the greater the risk that one generally assumes. A free market reflects this principle in the pricing of an instrument: strong demand for a safer instrument drives its price higher (and its return proportionately lower), while weak demand for a riskier instrument drives its price lower (and its potential return thereby higher). "For example, a US Treasury bond is considered to be one of the safest investments and, when compared to a corporate bond, provides a lower rate of return. The reason for this is that a corporation is much more likely to go bankrupt than the U.S. government. Because the risk of investing in a corporate bond is higher, investors are offered a higher rate of return." The most popular, and also the most vilified lately risk measurement is Value-at-Risk (VaR). There are different types of VaR - Long Term VaR, Marginal VaR, Factor VaR and Shock VaR[15] The latter is used in measuring risk during the extreme market stress conditions.

167

Risk

168

In public works
In a peer reviewed study of risk in public works projects located in twenty nations on five continents, Flyvbjerg, Holm, and Buhl (2002, 2005) documented high risks for such ventures for both costs[16] and demand.[17] Actual costs of projects were typically higher than estimated costs; cost overruns of 50% were common, overruns above 100% not uncommon. Actual demand was often lower than estimated; demand shortfalls of 25% were common, of 50% not uncommon. Due to such cost and demand risks, cost-benefit analyses of public works projects have proved to be highly uncertain. The main causes of cost and demand risks were found to be optimism bias and strategic misrepresentation. Measures identified to mitigate this type of risk are better governance through incentive alignment and the use of reference class forecasting.[18]

In human services
Huge ethical and political issues arise when human beings themselves are seen or treated as 'risks', or when the risk decision making of people who use human services might have an impact on that service. The experience of many people who rely on human services for support is that 'risk' is often used as a reason to prevent them from gaining further independence or fully accessing the community, and that these services are often unnecessarily risk averse.[19]

Risk in psychology
Regret
In decision theory, regret (and anticipation of regret) can play a significant part in decision-making, distinct from risk aversion (preferring the status quo in case one becomes worse off).

Framing
Framing[20] is a fundamental problem with all forms of risk assessment. In particular, because of bounded rationality (our brains get overloaded, so we take mental shortcuts), the risk of extreme events is discounted because the probability is too low to evaluate intuitively. As an example, one of the leading causes of death is road accidents caused by drunk drivingpartly because any given driver frames the problem by largely or totally ignoring the risk of a serious or fatal accident. For instance, an extremely disturbing event (an attack by hijacking, or moral hazards) may be ignored in analysis despite the fact it has occurred and has a nonzero probability. Or, an event that everyone agrees is inevitable may be ruled out of analysis due to greed or an unwillingness to admit that it is believed to be inevitable. These human tendencies for error and wishful thinking often affect even the most rigorous applications of the scientific method and are a major concern of the philosophy of science. All decision-making under uncertainty must consider cognitive bias, cultural bias, and notational bias: No group of people assessing risk is immune to "groupthink": acceptance of obviously wrong answers simply because it is socially painful to disagree, where there are conflicts of interest. One effective way to solve framing problems in risk assessment or measurement (although some argue that risk cannot be measured, only assessed) is to raise others' fears or personal ideals by way of completeness.

Risk Neurobiology of Framing Framing involves other information that affects the outcome of a risky decision. The right prefrontal cortex has been shown to take a more global perspective[21] while greater left prefrontal activity relates to local or focal processing[22] From the Theory of Leaky Modules[23] McElroy and Seta proposed that they could predictably alter the framing effect by the selective manipulation of regional prefrontal activity with finger tapping or monaural listening.[24] The result was as expected. Rightward tapping or listening had the effect of narrowing attention such that the frame was ignored. This is a practical way of manipulating regional cortical activation to affect risky decisions, especially because directed tapping or listening is easily done.

169

Fear as intuitive risk assessment

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

Risk assessment and management

Because planned actions are subject to large cost and benefit risks, proper risk assessment and risk management for such actions are crucial to making them successful.[25] Since Risk assessment and management is essential in security management, both are tightly related. Security assessment methodologies like CRAMM contain risk assessment modules as an important part of the first steps of the methodology. On the other hand, Risk Assessment methodologies, like Mehari evolved to become Security Assessment methodologies. A ISO standard on risk management (Principles and guidelines on implementation) is currently being draft under code ISO 31000. Target publication date 30 May 2009.

Risk in auditing
The audit risk model expresses the risk of an auditor providing an inappropriate opinion of a commercial entity's financial statements. It can be analytically expressed as: AR = IR x CR x DR Where AR is audit risk, IR is inherent risk, CR is control risk and DR is detection risk.

See also
Applied information economics Adventure Ambiguity Ambiguity aversion

Risk Benefit shortfall Cindynics Civil defense Cost overrun Credit risk Crisis Cultural Theory of risk Early case assessment Emergency Ergonomics Event chain methodology Financial risk Fuel price risk management Hazard Hazard prevention Identity resolution Inherent risk Insurance industry Interest rate risk International Risk Governance Council Investment risk ISO 31000 ISO 28000 Legal risk Life-critical system Liquidity risk Loss aversion Market risk Megaprojects and risk Operational risk Optimism bias Political risk Preventive maintenance Preventive medicine Probabilistic risk assessment Reference class forecasting Reinvestment risk Reputational risk Risk analysis Risk aversion Riskbase Risk factor (finance) Risk homeostasis Risk management Risk-neutral measure

170

Risk perception Risk register

Risk Sampling risk Security risk Systemic risk Uncertainty Value at risk

171

Bibliography
Referred literature Bent Flyvbjerg, 2006: From Nobel Prize to Project Management: Getting Risks Right. Project Management Journal, vol. 37, no. 3, August, pp.515. Available at homepage of author [26] James Franklin, 2001: The Science of Conjecture: Evidence and Probability Before Pascal, Baltimore: Johns Hopkins University Press. Niklas Luhmann, 1996: Modern Society Shocked by its Risks (= University of Hongkong, Department of Sociology Occasional Papers 17), Hongkong, available via HKU Scholars HUB [27] Books Historian David A. Moss's book When All Else Fails [28] explains the U.S. government's historical role as risk manager of last resort. Peter L. Bernstein. Against the Gods ISBN 0-471-29563-9. Risk explained and its appreciation by man traced from earliest times through all the major figures of their ages in mathematical circles. Rescher, Nicholas (1983). A Philosophical Introduction to the Theory of Risk Evaluation and Measurement. University Press of America. Porteous, Bruce T.; Pradip Tapadar (December 2005). Economic Capital and Financial Risk Management for Financial Services Firms and Conglomerates. Palgrave Macmillan. ISBN1-4039-3608-0. Tom Kendrick (2003). Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project. AMACOM/American Management Association. ISBN978-0814407615. Flyvbjerg, Bent, Nils Bruzelius, and Werner Rothengatter, 2003. Megaprojects and Risk: An Anatomy of Ambition (Cambridge: Cambridge University Press). [4] David Hillson (2007). Practical Project Risk Management: The Atom Methodology. Management Concepts. ISBN978-1567262025. Kim Heldman (2005). Project Manager's Spotlight on Risk Management. Jossey-Bass. ISBN978-0782144116. Dirk Proske (2008). Catalogue of risks - Natural, Technical, Social and Health Risks. Springer. ISBN978-3540795544. Gardner, Dan, Risk: The Science and Politics of Fear [29], Random House, Inc., 2008. ISBN 0771032994 Articles and papers Clark, L., Manes, F., Antoun, N., Sahakian, B. J., & Robbins, T. W. (2003). "The contributions of lesion laterality and lesion volume to decision-making impairment following frontal lobe damage." Neuropsychologia, 41, 1474-1483. Drake, R. A. (1985). "Decision making and risk taking: Neurological manipulation with a proposed consistency mediation." Contemporary Social Psychology, 11, 149-152. Drake, R. A. (1985). "Lateral asymmetry of risky recommendations." Personality and Social Psychology Bulletin, 11, 409-417. Gregory, Kent J., Bibbo, Giovanni and Pattison, John E. (2005), "A Standard Approach to Measurement Uncertainties for Scientists and Engineers in Medicine", Australasian Physical and Engineering Sciences in Medicine 28(2):131-139.

Risk Hansson, Sven Ove. (2007). "Risk" [30], The Stanford Encyclopedia of Philosophy (Summer 2007 Edition), Edward N. Zalta (ed.), forthcoming [31]. Holton, Glyn A. (2004). "Defining Risk" [32], Financial Analysts Journal, 60 (6), 1925. A paper exploring the foundations of risk. (PDF file) Knight, F. H. (1921) Risk, Uncertainty and Profit, Chicago: Houghton Mifflin Company. (Cited at: [33], I.I.26.) Kruger, Daniel J., Wang, X.T., & Wilke, Andreas (2007) "Towards the development of an evolutionarily valid domain-specific risk-taking scale" [34] Evolutionary Psychology (PDF file) Metzner-Szigeth, A. (2009). "Contradictory Approaches? On Realism and Constructivism in the Social Sciences Research on Risk, Technology and the Environment." Futures, Vol. 41, No. 2, March 2009, pp.156170 (fulltext journal: [35]) (free preprint: [36]) Miller, L. (1985). "Cognitive risk taking after frontal or temporal lobectomy I. The synthesis of fragmented visual information." Neuropsychologia, 23, 359 369. Miller, L., & Milner, B. (1985). "Cognitive risk taking after frontal or temporal lobectomy II. The synthesis of phonemic and semantic information." Neuropsychologia, 23, 371 379. Neill, M. Allen, J. Woodhead, N. Reid, S. Irwin, L. Sanderson, H. 2008 "A Positive Approach to Risk Requires Person Centred Thinking" London, CSIP Personalisation Network, Department of Health. Available from: http:// networks.csip.org.uk/Personalisation/Topics/Browse/Risk/[Accessed 21 July 2008]

172

External links
The Wiktionary definition of risk Risk [30] - The entry of the Stanford Encyclopedia of Philosophy Risk Management magazine [37], a publication of the Risk and Insurance Management Society. Risk and Insurance [38] StrategicRISK, a risk management journal [39] "Risk preference and religiosity" [40] article from the Institute for the Biocultural Study of Religion [41]

References
[1] [2] [3] [4] [5] [6] [7] http:/ / pages. stern. nyu. edu/ ~adamodar/ pdfiles/ invphil/ ch2. pdf Luhmann 1996:3 James Franklin, 2001: The Science of Conjecture: Evidence and Probability Before Pascal, Baltimore: Johns Hopkins University Press, 274 Luhmann 1996:4 Douglas Hubbard The Failure of Risk Management: Why It's Broken and How to Fix It, John Wiley & Sons, 2009 E.g. "Risk is the unwanted subset of a set of uncertain outcomes." (Cornelius Keating) "Risk is a combination of the likelihood of an occurrence of a hazardous event or exposure(s) and the severity of injury or ill health that can be caused by the event or exposure(s)" (OHSAS 18001:2007). [8] Wired Magazine, Before the levees break (http:/ / www. wired. com/ science/ planetearth/ magazine/ 17-01/ ff_dutch_delta?currentPage=3), page 3 [9] Landsburg, Steven (2003-03-03). "Is your life worth $10 million?" (http:/ / www. slate. com/ id/ 2079475/ ). Everyday Economics (Slate). . Retrieved 2008-03-17. [10] Douglas Hubbard "How to Measure Anything: Finding the Value of Intangibles in Business" pg. 46, John Wiley & Sons, 2007 [11] Douglas Hubbard "The Failure of Risk Management: Why It's Broken and How to Fix It, John Wiley & Sons, 2009 [12] (http:/ / ssrn. com/ abstract=1012812) [13] Sapienza P., Zingales L. and Maestripieri D. 2009. Gender differences in financial risk aversion and career choices are affected by testosterone. Proceedings of the National Academy of Sciences. [14] Apicella C. L. and all. Testosterone and financial risk preferences. Evolution and Human Behavior. Vol 29. Issue 6. 384-390. abstract (http:/ / www. ehbonline. org/ article/ S1090-5138(08)00067-6/ abstract) [15] Value at risk [16] http:/ / flyvbjerg. plan. aau. dk/ JAPAASPUBLISHED. pdf [17] http:/ / flyvbjerg. plan. aau. dk/ Traffic91PRINTJAPA. pdf [18] http:/ / flyvbjerg. plan. aau. dk/ 0406DfT-UK%20OptBiasASPUBL. pdf

Risk
[19] A person centred approach to risk - Risk - Advice on Personalisation - Personalisation - Homepage - CSIP Networks (http:/ / networks. csip. org. uk/ Personalisation/ Topics/ Browse/ Risk/ ?parent=3151& child=3681) [20] Amos Tversky / Daniel Kahneman, 1981. "The Framing of Decisions and the Psychology of Choice." [21] Schatz, J., Craft, S., Koby, M., & DeBaun, M. R. (2004). Asymmetries in visual-spatial processing following childhood stroke. Neuropsychology, 18, 340-352. [22] Volberg, G., & Hubner, R. (2004). On the role of response conflicts and stimulus position for hemispheric differences in global/local processing: An ERP study. Neuropsychologia, 42, 1805-1813. [23] Drake, R. A. (2004). Selective potentiation of proximal processes: Neurobiological mechanisms for spread of activation. Medical Science Monitor, 10, 231-234. [24] McElroy, T., & Seta, J. J. (2004). On the other hand am I rational? Hemisphere activation and the framing effect. Brain and Cognition, 55, 572-580. [25] Flyvbjerg 2006 [26] http:/ / flyvbjerg. plan. aau. dk/ Publications2006/ Nobel-PMJ2006. pdf [27] http:/ / hub. hku. hk/ handle/ 123456789/ 38822 [28] http:/ / www. hup. harvard. edu/ catalog/ MOSWHE. html [29] http:/ / books. google. com/ books?id=5j_8xF8vUlAC& printsec=frontcover [30] http:/ / plato. stanford. edu/ entries/ risk/ [31] http:/ / plato. stanford. edu/ archives/ sum2007/ entries/ risk/ [32] http:/ / www. riskexpertise. com/ papers/ risk. pdf [33] http:/ / www. econlib. org/ library/ Knight/ knRUP1. html [34] http:/ / www. epjournal. net/ filestore/ ep05555568. pdf [35] http:/ / www. sciencedirect. com/ science?_ob=ArticleURL& _udi=B6V65-4TGS7JY-1& _user=10& _coverDate=04%2F30%2F2009& _rdoc=1& _fmt=high& _orig=search& _sort=d& _docanchor=& view=c& _acct=C000050221& _version=1& _urlVersion=0& _userid=10& md5=054fec1f03e9ec784596add85197d2a8 [36] http:/ / egora. uni-muenster. de/ ifs/ personen/ bindata/ metznerszigeth_contradictory_approaches_preprint. PDF [37] http:/ / www. rmmag. com/ [38] http:/ / www. riskandinsurance. com/ [39] http:/ / www. strategicrisk. co. uk/ [40] http:/ / ibcsr. org/ index. php?option=com_content& view=article& id=149:risk-preference-and-religiosity& catid=25:research-news& Itemid=59 [41] http:/ / ibcsr. org/ index. php

173

Audit

174

Audit
Accountancy

Key concepts Accountant Bookkeeping Trial balance General ledger Debits and credits Cost of goods sold Double-entry system Standard practices Cash and accrual basis GAAP / IFRS Fields of accounting Cost Financial Forensic Fund Management Tax Financial statements Balance sheet Income statement Cash flow statement Equity Retained earnings Auditing Financial audit GAAS Internal audit SarbanesOxley Act Professional Accountants CPA Chartered Accountant CGA CMA

The general definition of an audit is an evaluation of a person, organization, system, process, enterprise, project or product. The term most commonly refers to audits in accounting, but similar concepts also exist in project management, quality management, and for energy conservation.

Audits in accounting
Audits are performed to ascertain the validity and reliability of information; also to provide an assessment of a system's internal control. The goal of an audit is to express an opinion on the person / organization / system (etc) in question, under evaluation based on work done on a test basis. Due to practical constraints, an audit seeks to provide only reasonable assurance that the statements are free from material error. Hence, statistical sampling is often adopted in audits. In the case of financial audits, a set of financial statements are said to be true and fair when they are free of material misstatements - a concept influenced by both quantitative and qualitative factors. Audit is a vital part of accounting. Traditionally, audits were mainly associated with gaining information about financial systems and the financial records of a company or a business (see financial audit). However, recent auditing has begun to include other information about the system, such as information about security risks, information systems performance (beyond financial systems), and environmental performance. As a result, there are now professions conducting security audits, IS audits, and environmental audits. In financial accounting, an audit is an independent assessment of the fairness by which a company's financial statements are presented by its management. It is performed by competent, independent and objective person(s) known as auditors or accountants, who then issue an auditor's report based on the results of the audit. In Cost Accounting, it is a process for verifying the cost of manufacture or production of any article, on the basis of accounts as regards utilisation of material or labour or other items of costs, maintained by the company. In simple words the term cost audit means a systematic and accurate verification of the cost accounts and records and checking of adherence to the objectives of the cost accounting. As per ICWA London cost audit is the verification of the correctness of cost accounts and of the adherence to the cost accounting plan.

Audit Such systems must adhere to generally accepted standards set by governing bodies regulating businesses; these standards simply provide assurance for third parties or external users that such statements present a company's financial condition and results of operations "fairly." The Definition for Auditing and Assurance Standard (AAS) 1 by ICAI "Auditing is the independent examination of financial information of any entity, whether profit oriented or not, and irrespective of its size or legal form, when such an examination is conducted with a view to expressing an opinion thereon."

175

Integrated audits
In the US, audits of publicly-traded companies are governed by rules laid down by the Public Company Accounting Oversight Board (PCAOB), which was established by Section 404 of the Sarbanes Oxley Act of 2002. Such an audit is called an integrated audit, where auditors have the additional responsibility (other than to opine on the financial statements) of expressing an opinion on the effectiveness of company's internal control over financial reporting, in accordance with PCAOB Auditing Standard No. 5. There are also new types of integrated auditing becoming available. This uses unified compliance material - see the unified compliance section in Regulatory compliance. Due to the increasing number of regulations and need for operational transparency, organizations are adopting risk-based audits that can cover multiple regulations and standards from a single audit event. This is a very new but necessary approach in some sectors to ensure that all the necessary governance requirements can be met without duplicating effort from both audit and audit hosting resources.

Audits vs. Assessments

The difference between audits and assessments can be considerable or can be nothing at all. As a general rule, audits should always be an independent evaluation that will include some degree of quantitative and qualitative analysis whereas an assessment infers a less independent and more consultative approach.

Types of auditors
Auditors of financial statements can be classified into two categories: External auditor / Statutory auditor is an independent Public accounting firm engaged by the client subject to the audit, to express an opinion on whether the company's financial statements are free of material misstatements, whether due to fraud or error. For publicly-traded companies, external auditors may also be required to express an opinion over the effectiveness of internal controls over financial reporting. External auditors may also be engaged to perform other agreed-upon procedures, related or unrelated to financial statements. Most importantly, external auditors, though engaged and paid by the company being audited, are regarded as independent auditors. The most used external audit standards are the US GAAS of the American Institute of Certified Public Accountants; and the ISA International Standards on Auditing developed by the International Auditing and Assurance Standards Board of the International Federation of Accountants Internal auditors of internal control are employed by the organization they audit. Internal auditors perform various audit procedures, primarily related to procedures over the effectiveness of the company's internal controls over financial reporting. Due to the requirement of Section 404 of the Sarbanes Oxley Act of 2002 for management to also assess the effectiveness of their internal controls over financial reporting (as also required of the external auditor), internal auditors are utilized to make this assessment. Though internal auditors are not considered independent of the company they perform audit procedures for, internal auditors of publicly-traded companies are required to report directly to the board of directors, or a sub-committee of the board of directors, and not to management, so to reduce the risk that internal auditors will be pressured to produce favorable assessments. - The most used Internal Audit standards are those of the Institute of Internal Auditors.

Audit Consultant auditors are external personnel contracted by the firm to perform an audit following the firm's auditing standards. This differs from the external auditor, who follows their own auditing standards. The level of independence is therefore somewhere between the internal auditor and the external auditor. The consultant auditor may work independently, or as part of the audit team that includes internal auditors. Consultant auditors are used when the firm lacks sufficient expertise to audit certain areas, or simply for staff augmentation when staff are not available. Quality auditors may be consultants or employed by the organization.

176

Quality audits
Quality audits are performed to verify the effectiveness of a quality management system. This is part of certifications such as ISO 9001. Quality audits are essential to verify the existence of objective evidence of processes, to assess how successfully processes have been implemented, for judging the effectiveness of achieving any defined target levels, providing evidence concerning reduction and elimination of problem areas and are a hands-on management tool for achieving continual improvement in an organization. To benefit the organization, quality auditing should not only report non-conformances and corrective actions but also highlight areas of good practice. In this way, other departments may share information and amend their working practices as a result, also enhancing continual improvement.

In Project Management
Projects can undergo 2 types of audits[1] : Regular Health Check Audits: The aim of a regular health check audit is to understand the current state of a project in order to increase project success. Regulatory Audits: The aim of a regulatory audit is to verify that a project is compliant with regulations and standards.

Energy audits
An energy audit is an inspection, survey and analysis of energy flows for energy conservation in a building, process or system to reduce the amount of energy input into the system without negatively affecting the output(s).

See also
Accounting Comptroller, Comptroller General, and Comptroller General of the United States Continuous auditing COSO framework, Risk management Field work Financial audit, External auditor, Certified Public Accountant (CPA), and Audit risk Green Globe Information technology audit, Information technology audit process, History of information technology auditing, and Auditing information security Internal audit Lead Auditor, under the Chief Audit Executive, or Director of Audit Quality audit

Audit

177

References
[1] Cutting, Thomas (January 12, 2008). "How to Survive an Audit" (http:/ / www. pmhut. com/ how-to-survive-an-audit). PM Hut. . Retrieved December 13, 2009.

Consultant
A consultant (from the Latin consultare means "to discuss" from which we also derive words such as consul and counsel) is a professional who provides advice in a particular area of expertise such as management, accountancy, the environment, entertainment, technology, law (tax law, in particular), human resources, marketing, emergency management, food production, medicine, finance, life management, economics, public affairs, communication, engineering, sound system design, graphic design, or waste management. A consultant is usually an expert or a professional in a specific field and has a wide knowledge of the subject matter. A consultant usually works for a consultancy firm or is self-employed, and engages with multiple and changing clients. Thus, clients have access to deeper levels of expertise than would be feasible for them to retain in-house, and may purchase only as much service from the outside consultant as desired. It is generally accepted good corporate governance to hire consultants as a check to the Principal-Agent problem. 'Consultant' is also the term used to denote the most senior medical position in the United Kingdom, Australia and Ireland (e.g., a consultant surgeon).'

Ways in which consultants work

Some consultants are employed by a consult staffing company, a company that provides consultants to clients. This is particular common in the technology sector. Consultants are often called contractors in the technology sector in reference to their employment contract. Strategy consultants are common in upper management in many industries. There are also independent consultants who act as interim executives with decision-making power under corporate policies or statutes. They may sit on specially constituted boards or committees. Consultants work at client places on behalf of a consultancy or Billing company.

Criticism of Consultants and Consultancy

The term consultancy is sometimes used euphemistically to indicate the provision of services which might be termed meaningless or trivial by most individuals, but which reap significant profits and payments on behalf of the consultant. Criticism of consultancy often centres around the lack of transparency and understanding in what particular types of services it is that consultants actually provide (an ambiguity which undoubtedly centres upon the lack of understanding of both the work of consultants and also the actual commodity which they are paid for namely, advice). The perception of a disproportionately high degree of pay for consultants (with respect to the worth of the services provided for that pay) is common and prevalent and a recurring misunderstanding which undermines the ethical basis upon which consultants might otherwise suppose as a valid reason for their employment.

Consultant

178

See also
Expert
Related concepts Biotechnology consulting Contingent workforce Fourth-party logistics Human resource consulting Information technology consulting Interim Management IRS Reclassification Management consulting Permatemp Political consulting Public consultation Tax advisor Umbrella company Types of consultant Acoustical consultant Biotechnology consultant Consultant (medicine) Consultant pharmacist Creative consultant Educational consultant Elevator consultant Employment consultant Foreclosure consultant Fourth-party logistics providers Human Resources consultant Image consultant Independent contractor Interim Managers Information Technology consultant Lactation consultant Legal nurse consultant Loss control consultant Magic consultant Media consultant Political consultant Process consultant Statistical consultant Theatre consultant

Certified Management consultant

Strategy
Strategy refers to a plan of action designed to achieve a particular goal. The word is of military origin, deriving from the Greek word (stratgos), which roughly translates as "general".[1] In military usage strategy is distinct from tactics, which are concerned with the conduct of an engagement, while strategy is concerned with how different engagements are linked. How a battle is fought is a matter of tactics: the terms and conditions that it is fought on and whether it should be fought at all is a matter of strategy, which is part of the four levels of warfare: political goals or grand strategy, strategy, operations, and tactics.

Strategies in game theory

In game theory, a strategy refers to one of the options that a player can choose. That is, every player in a non-cooperative game has a set of possible strategies, and must choose one of the choices. A strategy must specify what action will happen in each contingent state of the gamee.g. if the opponent does A, then take action B, whereas if the opponent does C, take action D. Strategies in game theory may be random (mixed) or deterministic (pure). That is, in some games, players choose mixed strategies. Pure strategies can be thought of as a special case of mixed strategies, in which only probabilities 0 or 1 are assigned to actions.

Noted texts on strategy

Classic texts such as Chanakya's Arthashastra written in the 3rd century BC, Sun Tzu's The Art of War, written in China 2,500 years ago, the political strategy of Niccol Machiavelli's The Prince, written in 1513, or Carl von Clausewitz's On War, published in 1832, as with the Japanese classic The book of five rings by Miyamoto Mushashi written in 1645, are still well known, and highly influential. In the 20th century, the subject of strategic management has been particularly applied to organizations, most typically to business firms and corporations. Designing Organization for Higher Performance published in 1988; It is a good guide to develop higher levels of performance since it offers strategies that are viable in large organizations.

Strategy The nature of historic texts differs greatly from area to area, and given the nature of strategy itself, there are some potential parallels between various forms of strategynoting, for example, the popularity of The Art of War as a business book. Each domain generally has its own foundational texts, as well as more recent contributions to new applications of strategy. Some of these are: Political strategy The Prince, published in 1532 by Niccol Machiavelli Arthashastra, written in the 4th century BC by Chanakya The Book of the Courtier by Baldassare Castiglione Military strategy: The Art of War, written in the 6th century BC by Sun Tzu The Art of War, written in the 19th century AD by Baron Antoine-Henri Jomini Strategikon, written in the 6th century AD by the Byzantine emperor Maurice Taktikon, by the Byzantine emperor Leo VI the Wise On War, by Carl von Clausewitz (19th century) Strategy, by B.H. Liddell Hart On Guerrilla Warfare, by Mao Zedong The Influence of Sea Power upon History, by Alfred Thayer Mahan

179

The Air Campaign, by Colonel John A. Warden, III Makers of Modern Strategy, edited by Peter Paret Strategy, by Edward N. Luttwak OODA, by John Boyd Economic strategy General Theory of Employment, Interest and Money, published in 1936 by John Maynard Keynes Business strategy Demystifying Competitive Intelligence, Estelle Metayer, Ivey Business Journal, Nov 1999 Blue Ocean Strategy, by W. Chan Kim and Rene Mauborgne, 2005 Competitive Strategy, by Michael Porter Strategy Concept I: Five Ps for Strategy and Strategy Concept II: Another Look at Why Organizations Need Strategies, by Henry Mintzberg Winning In FastTime by John A. Warden, III and Leland A. Russell, 2002. Designing Organization for Higher Perfromance by David P. Hanna, 1988. Exploring Corporate Strategy by Gerry Johnson and Kevan Scholes, 2001. General strategy Strategy Safari, by Henry Mintzberg, Bruce Ahlstrand and Joseph Lampel. Strategic Studies-Intelligence and strategy, by Gagliano Giuseppe, Uniservice, Nov 2009 Others Marcel Dtienne and Jean-Pierre Vernant, Les Ruses de l'intelligence, Paris: Flammarion, 1993 (on the role of the Greek Metis)

See also

Strategy

180

American football strategy Business biomimetics Fabian strategy Mutually Assured Destruction Nuclear strategy Odds algorithm (Odds strategy) Plan

Poker strategy Strategic planning Strategy game Synergy Tactics Telesis

External links
Strategic Theories and Concepts [2] Strategy Definition and Fundamentals [3] Math Strategies [4]

References
[1] [2] [3] [4] Oxford English Dictionary (2 ed.). Oxford, England: Oxford University Press. 1989. http:/ / strategictheory. web. officelive. com/ default. aspx http:/ / www. easy-strategy. com/ strategy-definition. html http:/ / educationalblog. exploringchild. com/ learning/ math/ math-strategies

Project manager
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, architecture, computer networking, telecommunications or software development. Many other fields in the production, design and service industries also have project managers.

Overview
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 are cost, time, and quality (also known as 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 issues of cost, time, quality and above all, client satisfaction, can be realized. The term and title 'project manager' has come to be used generically to describe anyone given responsibility to complete a project. However, it is more properly used to describe a person with full responsibility and the same level of authority required to complete a project. If a person does not have high levels of both responsibility and authority then they are better described as a project administrator, coordinator, facilitator or expeditor.

Project manager

181

Project manager topics

Project management Project Management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and mutual interaction and tasks of various parties in such a way that reduces the risk of overall failure, maximizes benefits, and restricts costs. Products and services Any type of product or service pharmaceuticals, building construction, vehicles, electronics, computer software, financial services, etc. may have its implementation overseen by a project manager and its operations by a product manager. Project tools The tools, knowledge and techniques for managing projects are often unique to Project Management. For example: work breakdown structures, critical path analysis and earned value management. Understanding and applying the tools and techniques which are generally recognized as good practices are not sufficient alone for effective project management. Effective project management requires that the project manager understands and uses the knowledge and skills from at least four areas of expertise. Examples are PMBOK, Application Area Knowledge: standards and regulations set forth by ISO for project management, General Management Skills and Project Environment Management[1] Project teams When recruiting and building an effective team, the manager must consider not only the technical skills of each person, but also the critical roles and chemistry between workers. A project team has mainly three separate components: Project Manager, Core Team and Contracted Team. Risk Most of the project management issues that influence a project arise from risk, which in turn arises from uncertainty. The successful project manager focuses on this as his/her main concern and attempts to reduce risk significantly, often by adhering to a policy of open communication, ensuring that project participants can voice their opinions and concerns.

Types of project managers

Construction Project Manager
Construction project managers in the past were individuals, who worked in construction or supporting industries and were promoted to foreman. It was not until the late 20th century that construction and Construction management became distinct fields. Until recently, the American construction industry lacked any level of standardization, with individual States determining the eligibility requirements within their jurisdiction. However, several Trade associations based in the United States have made strides in creating a commonly-accepted set of qualifications and tests to determine a project manager's competency. The Project Management Institute has made some headway into being a standardizing body with its creation of the Project Management Professional (PMP) designation. The Constructor Certification Commission of the American Institute of Constructors holds semiannual nationwide tests. Eight American Construction Management programs require that students take these exams before they may receive their Bachelor of Science in Construction Management degree, and 15 other Universities actively encourage their students to consider the exams.

Project manager The Associated Colleges of Construction Education, and the Associated Schools of Construction have made considerable progress in developing national standards for construction education programs.The profession has recently grown to accommodate several dozen Construction Management Bachelor of Science programs. The US Navy Construction Battalion, nicknamed the SeaBees, puts their command through strenuous training and certifications at every level. To become a Chief Petty Officer in the SeaBees is equivalent to a BS in Construction Management with the added benefit of several years of experience to their credit. See ACE accreditation.

182

Architectural Project Manager

Architectural project manager are project managers in the field of architecture. They have many of the same skills as their counterpart in the construction industry. An architect will often work closely with the construction project manager in the office of the General contractor (GC), and at the same time, coordinate the work of the design team and numerous consultants who contribute to a construction project, and manage communication with the client. The issues of budget, scheduling, and quality-control are the responsibility of the Project Manager in an architect's office.

Software Project Manager

A Software Project Manager has many of the same skills as their counterparts in other industries. Beyond the skills normally associated with traditional project management in industries such as construction and manufacturing, a software project manager will typically have an extensive background in software development. Many software project managers hold a degree in Computer Science, Information Technology or another related field and will typically have worked in the industry as a software engineer. In traditional project management a heavyweight, predictive methodology such as the waterfall model is often employed, but software project managers must also be skilled in more lightweight, adaptive methodologies such as DSDM, SCRUM and XP. These project management methodologies are based on the uncertainty of developing a new software system and advocate smaller, incremental development cycles. These incremental or iterative cycles are timeboxed (constrained to a known period of time, typically from one to four weeks) and produce a working subset of the entire system deliverable at the end of each iteration. The increasing adoption of lightweight approaches is due largely to the fact that software requirements are very susceptible to change, and it is extremely difficult to illuminate all the potential requirements in a single project phase before the software development commences. The software project manager is also expected to be familiar with the Software Development Life Cycle (SDLC). This may require in depth knowledge of requirements solicitation, application development, logical and physical database design and networking. This knowledge is typically the result of the aforementioned education and experience. There is not a widely accepted certification for software project managers, but many will hold the PMP designation offered by the Project Management Institute, PRINCE2 or an advanced degree in project management, such as a MSPM or other graduate degree in technology management.

Project manager

183

Responsibilities
The specific responsibilities of the Project Manager vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers, noting[2] : Developing the project plan Managing the project stakeholders Managing the project team Managing the project risk Managing the project schedule Managing the project budget Managing the project conflicts

Education, certifications and networks

Individuals wishing to obtain professional certifications may take one or more of the offerings available from a variety of organizations: The Project Management Institute offers the following credentials to project managers:[3] Project Management Professional (PMP) Certified Associate in Project Management (CAPM), Program Management Professional (PgMP) PMI Risk Management Professional (PMI-RMP), and PMI Scheduling Professional (PMI-SP)

Other institutions and organizations: The University of Wisconsin's Masters Certificate in Project Management [4] CompTIA offers Project+ Certification The Canadian Construction Association (CCA) offers GSC as Project Manager. The UK Office of Government Commerce offers PRINCE2 certification. The Australian Institute of Project Management (AIPM) offers Registered Project Manager (RegPM) certification. The Defense Acquisition University (DAU) and its School of Program Management offers practitioner training in every element of project management for members of the Federal Government, Defense industry and allied nations. There are other graduate degrees in project and technology management, such as an MSPM. However, the majority of all project management skills may be developed through the completion of a Ph.D, D.Phil or other similar higher Doctorate. The IPMA is an international network of national project management societies such as Association for Project Management in the UK. IPMA serves as an umbrella organisation representing national societies which offer their certifications.

Project manager

184

Project Management training

Methods of Project Management training are very diverse. Much of the training received by most project managers is on the job training. Other sources of training include University degree programs in project management Business degree programs with some level of Project Management emphasis Certification preparatory classes and training Social media such as blogs and podcasts Books Seminars and conferences Local group meetings (I.E. local chapters)

See also
Event Planning and Production Master of Science in Project Management Project engineer Project management

Project planning

Further reading
US DoD (2003). Interpretive Guidance for Project Manager Positions [5]. August 2003.

External links
Project Management Institute [6]

References
[1] PMBOK Guide Third Edition 2004 p.12 [2] Berrie, Michele, Project Manager Responsibilities (http:/ / www. pmhut. com/ project-manager-responsibilities), PM Hut. Accessed 17. Oct 2009. [3] Project Management Institute Family of Credentials (http:/ / www. pmi. org/ CareerDevelopment/ Pages/ AboutPMIsCredentials. aspx) [4] http:/ / exed. wisc. edu/ cert/ projectmanagement/ info. asp [5] http:/ / www. opm. gov/ fedclass/ cg03-0001. pdf [6] http:/ / www. pmi. org

Project management triangle

185

Project management triangle

The Project Management Triangle is a model of the constraints of project management. It is often used to illustrate that project management success is measured by the project team's ability to manage the project, so that the expected results are produced while managing time and cost.[1] [2] [3]

Overview
Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as The Project Management Triangle "scope," "time," and "cost".[4] 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 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. Another approach to Project Management is to consider the three constraints as finance, time and human resources. If you need to finish a job in a shorter time, you can throw more people at the problem, which in turn will raise the cost of the project, unless by doing this task quicker we will reduce costs elsewhere in the project by an equal amount.

Project management triangle topics

Time
For analytical purposes, the time required to produce a deliverable is estimated using several techniques. One method is to identify tasks needed to produce the deliverables documented in a work breakdown structure or WBS. The work effort for each task is estimated and those estimates are rolled up into the final deliverable estimate. The tasks are also prioritized, dependencies between tasks are identified, and this information is documented in a project schedule. The dependencies between the tasks can affect the length of the overall project (dependency constrained), as can the availability of resources (resource constrained). Time is different from all other resources and cost categories. According to PMBOK the Project Time Management processes include : 1. Activity Definition 2. Activity Sequencing 3. Activity Resource Estimating 4. Activity Duration Estimating

Project management triangle 5. Schedule Development 6. Schedule Control Activity Definition (detail) 1a. Activity Definition Inputs Enterprise environmental factors, Organizational process assets, Project Scope statement, Work Breakdown Structure, WBS Dictionary, Project Management Plan 1b. Activity Definition Tools Decomposition, Activity Templates, Rolling Wave Planning, Expert Judgment Collection, Planning Components 1c. Activity Definition Outputs Activity list, Activity scope attributes, Milestones list, Change Requests Activity Sequencing (detail) 2a. Activity Sequencing Inputs Project Scope Statement, Activity List, Activity Attributes, Milestones List, Approved change requests 2b. Activity Sequencing Tools Procedure Diagram Method (PDM), Arrow Diagramming Method (ADM), Schedule Network templates, Dependency degeneration, Applying leads and lags 2c. Activity Sequencing Outputs Project Schedule Network diagrams, Activity List Updates, Activity Attributes Updates, Request Changes Activity Resource Estimating (detail) : 3a. Activity Resource Estimating Inputs Enterprise Environmental factoring, Organizational process assets, Activity list, Activity attributes, Resources Availability, Project Management Plan 3b. Activity Resource Estimating Tools Expert Judgment Collections, Alternative Analysis, Publishing estimating data, Project management software implementation, Bottom up estimating 3c. Activity Resource Estimating Outputs Activity resource requirements, Activity attributes, Resource breakdown structure, Resource calendars Request change updates. Activity Duration Estimating (detail): 4a. Activity Duration Estimating Inputs Enterprise environmental factors, organization process assets, Project scope statement, activity list, activity attributes, activity resource requirements, resource calendars, project management plan, risk register, activity cost estimates 4b. Activity Duration Estimating Tools Expert judgment collection, analogous estimating, parametric estimating, three point estimating, reserve analysis 4c. Activity Duration Estimating Outputs Activity duration estimates, activity attribute updates and estimates Schedule Development (detail): 5a. Schedule Development Inputs Organizational process assets, Project scope Statement, Activity list, Activity attributes, project Schedule Network diagrams, Activity resource requirements, Resource calendars, Activity duration estimates, project management plan, risk register 5b. Schedule Development Tools Schedule Network Analysis, Critical path method, schedule compression, what if scenario analysis, resources leveling, critical chain method, project management software , applying calendars, adjusting leads and lags, schedule

186

Project management triangle model 5c. Schedule Development Outputs Project schedule, Schedule model data, schedule baseline, resource requirements update, activity attributes, project calendar updates, request changes, project management plan updates, schedule management plan updates Schedule Control (detail): 6a. Schedule Control Inputs Schedule management plan, schedule baseline, performance reports, approved change requests 6b. Schedule Control Tools Progressive elaboration reporting, schedule change control system, performance measurement, project management software, variance, analysis, schedule comparison bar charts 6c. Schedule Control Outputs Schedule model data updates, schedule baseline. performance measurement, requested changes, recommended corrective actions, organizational process assets, activity list updates, activity attribute updates, project management plan updates Due to the complex nature of the Process Group called 'Time' the unique project management credential PMI-SP (PMI Scheduling Professional) was created.

187

Cost
To develop an approximation of a project cost depends on several variables including: resources, work packages such as labor rates and mitigating or controlling influencing factors that create cost variances tools used in cost are, risk management, cost contingency), cost escalation, and indirect costs . But beyond this basic accounting approach to fixed and variable costs, the economic cost that must be considered includes worker skill and productivity which is calculated using various project cost estimate tools. This is important when companies hire temporary or contract employees or outsource work. Cost Process Areas Cost Estimating is an approximation of the cost of all resources needed to complete activities. Cost budgeting aggregating the estimated costs of resources, work packages and activities to establish a cost baseline. Cost Control - factors that create cost fluctuation and variance can be influenced and controlled using various cost management tools. Project Management Cost Estimating Tools[5] Analogous Estimating Using the cost of similar project to determine the cost of the current project Determining Resource Cost rates The cost of goods and labor by unit gathered through estimates or estimation. Bottom Up estimating Using the lowest level of work package detail and summarizing the cost associated with it. Then rolling it up to a higher level aimed and calculating the entire cost of the project. Parametric Estimating Measuring the statistical relationship between historical data and other variable or flow. Vendor Bid Analysis taking the average of several bids given by vendors for the project. Reserve Analysis Aggregate the cost of each activity on the network path then add a contingency or reserve to the end result of the analysis by a factor determined by the project manager.

Project management triangle Cost of Quality Analysis Estimating the cost at the highest quality for each activity. Project managers often use project management software to calculate the cost variances for a project.

188

Scope
Requirements specified to achieve the end result. The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish. A major component of scope is the quality of the final product. The amount of time put into individual tasks determines the overall quality of the project. Some tasks may require a given amount of time to complete adequately, but given more time could be completed exceptionally. Over the course of a large project, quality can have a significant impact on time and cost (or vice versa). Together, these three constraints have given rise to the phrase "On Time, On Spec, On Budget." In this case, the term "scope" is substituted with "spec(ification)."

See also
Project triangle

References
[1] [2] [3] [4] Michael W. Newell, Marina N. Grashina (2004). The Project Management Question and Answer Book. p.8 Pamela McGhee, Peter McAliney (2007). Painless Project Management. p.74. Michael Gentile, Ronald D. Collette, Thomas D. August (2005). The CISO Handbook. p.172 (Chatfield, Carl. "A short course in project management" (http:/ / office. microsoft. com/ en-us/ project/ HA102354821033. aspx). Microsoft. .) [5] PMBOK Third Edition 2004 p.165

Work breakdown structure

189

Work breakdown structure

A work breakdown structure (WBS) in project management and systems engineering, is a tool used to define and group a project's discrete work elements (or tasks) in a way that helps organize and define the total work scope of the project[1] . A work breakdown structure element may be a product, data, a service, or any combination. A WBS also Example of a product work breakdown structure of an aircraft system. provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. Additionally the WBS is a dynamic tool and can be revised and updated as needed by the project manager.[1]

Overview
The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. [2] In a project or contract, the WBS is 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.

Example of Work breakdown structure applied in a NASA reporting structure.

[2]

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. [2] A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level parent tasks, materials, etc. For each element of the work breakdown structure, a description of the task to be performed is generated. [3] This technique (sometimes called a System Breakdown Structure [4] ) is used to define and organize the total scope of a project. The WBS is organised around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the WBS also helps map requirements from one level of system specification to another, for example a requirements cross reference matrix mapping functional requirements to high

Work breakdown structure level or low level design documents.

190

History
The concept of Work Breakdown Structure developed with the Program Evaluation and Review Technique (PERT) in the United States Department of Defense (DoD). PERT was developed by consulting giant Booz Allen Hamilton for the U.S. Navy in 1957 to support the development of its Polaris missile program. [5] While the term "work breakdown structure" was not used, this first implementation of PERT did organize the tasks into product-oriented categories.[6] By June 1962, DoD, NASA and the aerospace industry published a document for the PERT/COST system which described the WBS approach. [7] This guide was endorsed by the Secretary of Defense for adoption by all services.[8] In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MIL-STD-881), a military standard requiring the use of work breakdown structures across the DoD. [9] This standard established top-level templates for common defense materiel items along with associated descriptions (WBS dictionary) for their elements. The document has been revised several times, most recently in 2005. The current version of this document can be found in "Work Breakdown Structures for Defense Materiel Items" (MIL-HDBK-881A).[10] It includes instructions for preparing work breakdown structures, templates for the top three levels of typical systems, and a set of "common elements" that are applicable to all major systems and subsystems. Defense Materiel Item categories from MIL-HDBK-881A: Aircraft Systems Electronic/Automated Software Systems Missile Systems Ordnance Systems Sea Systems Space Systems Surface Vehicle Systems Unmanned Air Vehicle Systems Common Elements The common elements identified in MIL-HDBK-881A, Appendix I are: Example from MIL-HDBK-881, which illustrates the first three levels of a typical aircraft [11] system. Integration, assembly, test, and checkout; Systems engineering; Program management; Training; Data; System test and evaluation; Peculiar support equipment; Common support equipment; Operational and site activation; Industrial facilities; and Initial spares and repair parts In 1987, the Project Management Institute (PMI) documented the expansion of these techniques across non-defense organizations. The Project Management Body of Knowledge (PMBOK) Guide provides an overview of the WBS concept, while the "Practice Standard for Work Breakdown Structures" is comparable to the DoD handbook, but is intended for more general application.[12]

Work breakdown structure

191

WBS design principles

The 100% rule
One of the most important Work Breakdown Structure design principles is called the 100% Rule defined as follows:
[13]

. It has been

The 100% Rule...states that the WBS includes 100% of the work defined by the project scope and captures all deliverables internal, external, interim in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the child level must equal 100% of the work represented by the parent and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work It is important to remember that the 100% rule also applies to the activity level. The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. [14] Mutually exclusive elements Mutually exclusive: In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a Work Breakdown Structure. This ambiguity could result in duplicated work or mis-communications about responsibility and authority. Likewise, such overlap is likely to cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The WBS Dictionary describes each component of the WBS with milestones, deliverables, activities, scope, and sometimes dates, resources, costs, quality.

Planned outcomes, not planned actions

If the Work Breakdown Structure designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a product breakdown structure. Feature-driven software projects may use a similar technique which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS. Work breakdown structures that subdivide work by project phases (e.g. Preliminary Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a deliverable also used in defining Entry and Exit Criteria (e.g. an approved Preliminary Design Review document, or an approved Critical Design Review document).

Level of detail
A question to be answered in determining the duration of activities necessary to produce a deliverable defined by the WBS is when to stop dividing work into smaller elements. There are several heuristics or "rules of thumb" used when determining the appropriate duration of an activity or group of activities necessary to produce a specific deliverable defined by the WBS. The first is the "80 hour rule" which means that no single activity or group of activities to produce a single deliverable should be more than 80 hours of effort. The second rule of thumb is that no activity or series of activities should be longer than a single reporting period. Thus if the project team is reporting progress monthly, then no single activity or series of activities should be longer than one month long.

Work breakdown structure The last heuristic is the "if it makes sense" rule. Applying this rule of thumb, one can apply "common sense" when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS. A work package at the activity level is a task that: can be realistically and confidently estimated; makes no sense practically to break down any further; can be completed in accordance with one of the heuristics defined above; produces a deliverable which is measurable; and forms a unique package of work which can be outsourced or contracted out.

192

WBS coding scheme

It is common for Work Breakdown Structure elements to be numbered sequentially to reveal the hierarchical structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context[15] . A practical example of the WBS coding scheme is[16] : 1267.1 Systems Integration 1267.1.1 Requirements Definition 1267.1.2 Regulations 1267.1.3 Scheduling 1267.1.4 Monitoring & Control 1267.1.5 Procurement Management 1267.1.6 Closeout 1267.2 Design 1267.2.1 Conceptual Design 1267.2.2 Preliminary Design 1267.2.3 Final Design

Work breakdown structure

193

Terminal element
A terminal element is the lowest element (activity or deliverable) in a work breakdown structure; it is not further subdivided. Terminal elements are the items that are estimated in terms of resource requirements, budget and duration; linked by dependencies; and scheduled. A terminal element is sometimes called a work package, although the two terms are not synonymous.

Example
The figure on the right shows a Work Breakdown Structure construction technique that demonstrates the 100% Rule and the "progressive elaboration" technique. At WBS Level 1 it shows 100 units of work as the total scope of a project to design and build a custom bicycle. At WBS Level 2, the 100 units are divided into seven elements. The number of units allocated to each element of work can be based on effort or cost; it is not an estimate of task duration. The three largest elements of WBS The WBS Construction Technique employing the 100% Rule during WBS construction. Level 2 are further subdivided at Level 3. The two largest elements at Level 3 each represent only 17% of the total scope of the project. These larger elements could be further subdivided using the progressive elaboration technique described above. WBS design can be supported by software (e.g. a spreadsheet) to allow automatic rolling up of point values. Estimates of effort or cost can be developed through discussions among project team members. This collaborative technique builds greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity required to manage the project.

Pitfalls and misconceptions

A Work Breakdown Structure is not an exhaustive list of work. It is instead a comprehensive classification of project scope. A WBS is neither a project plan, a schedule, nor a chronological listing. It is considered poor practice to construct a project schedule (e.g. using project management software) before designing a proper WBS. This would be similar to scheduling the activities of home construction before completing the house design. Without concentrating on planned outcomes, it is very difficult to follow the 100% Rule at all levels of the WBS hierarchy. A WBS is not an organizational hierarchy. Some practitioners make the mistake of creating a WBS that shadows the organizational chart. While it is common for responsibility to be assigned to organizational elements, a WBS that shadows the organizational structure is not descriptive of the project scope and is not outcome-oriented. See also: responsibility assignment (RACI) matrix (also called a Staffing Matrix). WBS updates, other than progressive elaboration of details, require formal change control. This is another reason why a WBS should be outcome-oriented and not be prescriptive of methods. Methods can, and do, change frequently, but changes in planned outcomes require a higher degree of formality. If outcomes and actions are

Work breakdown structure blended, change control may be too rigid for actions and too informal for outcomes. A WBS is not a logic model. Nor is it a strategy map.

194

See also
List of project management topics Project planning Product breakdown structure Project management software Structure chart

Further reading
Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure. ISBN 1-890367-12-5 Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures, Second Edition (2006). ISBN 1-933890-13-4 (Note: The Second Edition is an extensive re-write of the Practice Standard.) Gregory T. Haugan. Effective Work Breakdown Structures (The Project Management Essential Library Series). ISBN 1-56726-135-3 Dennis P. Miller, PMP, "Building Your Project Work Breakdown Structure -- Visualizing Your Objectives, Deliverables, Activities and Schedule". ISBN 1-42006969-1 (Note: This new book is essentially a facilitator's guide for planning a project based on the WBS.)

References
[1] Booz, Allen & Hamilton Earned Value Management Tutorial Module 2: Work Breakdown Structure (http:/ / www. er. doe. gov/ opa/ pdf/ FinalModule2. ppt), Office of Project Assessment, doe.gov. Accessed 01. Dec 2008. [2] 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. [3] Electronic Industries Alliance Standard Systems Engineering Capability Model EIA-731.1 [4] Institute of Electrical and Electronics Engineers Standard for Application and Management of the Systems Engineering Process IEEE Std 1220-2005 [5] http:/ / www. stsc. hill. af. mil/ crosstalk/ 1998/ 07/ value. asp [6] Haugan, Gregory T., Effective Work Breakdown Structures, pp7-8 [7] DOD and NASA Guide, PERT/COST System Design, June 1962 [8] Hamilton, R. L., "Study of Methods for Evaluation of the PERT/Cost Management System", MITRE Corporation, June 1964 http:/ / handle. dtic. mil/ 100. 2/ AD603425 [9] MIL-STD-881, 1 November 1968 [10] MIL-HDBK-881A, http:/ / assist. daps. dla. mil/ quicksearch/ basic_profile. cfm?ident_number=202687 [11] Systems Engineering Fundamentals. (http:/ / www. dau. mil/ pubs/ pdf/ SEFGuide 01-01. pdf) Defense Acquisition University Press, 2001 [12] Haugan, Gregory T., The Work Breakdown Structure in Government Contracting, Management Concepts, 2003 ISBN 978-1567261202 [13] Effective Work Breakdown Structures By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN 1567261353, p.17 [14] Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute, ISBN 1933890134, page 8 [15] Several examples of standardized WBS structures for Construction are: CSI's Masterformat- http:/ / www. csinet. org/ s_csi/ sec. asp?TRACKID=& CID=1377& DID=11339 CSI's Uniformat- http:/ / www. csinet. org/ s_csi/ docs/ 15700/ 15694. pdf NORSOK Z-014 Offshore Petroleum WBS Example- http:/ / www. standard. no/ imaker. exe?id=1521 [16] Taylor, Michael, WBS Examples (http:/ / www. pmhut. com/ wbs-examples), PM Hut. Accessed 17. Oct 2009.

Contract

195

Contract
In law, a contract is an agreement between two or more parties, that if it contains the elements of a valid legal agreement is enforceable by law[1] or by binding arbitration. That is to say, a contract is an exchange of promises with a specific remedy for breach. Agreement is said to be reached when an offer capable of immediate acceptance is met with a "mirror image" acceptance (i.e., an unqualified acceptance). The parties must have the necessary capacity to contract and the contract must not be either trifling, indeterminate, impossible, or illegal. Contract law is based on the principle expressed in the Latin phrase pacta sunt servanda (usually translated "pacts must be kept", but more literally "agreements are to be kept").[2] Breach of contract is recognized by the law and remedies can be provided. As long as the good or service provided is legal, any oral agreement between two parties can constitute a binding legal contract. The practical limitation to this, however, is that generally only parties to a written agreement have material evidence (the written contract itself) to prove the actual terms uttered at the time the agreement was struck. In daily life, most contracts can be and are made orally, such as purchasing a book or a sandwich. Sometimes written contracts are required by either the parties, or by statutory law within various jurisdiction for certain types of agreement, for example when buying a house[3] or land. Contract law can be classified, as is habitual in civil law systems, as part of a general law of obligations (along with tort, unjust enrichment or restitution). According to legal scholar Sir John William Salmond, a contract is "an agreement creating and defining the obligations between two or more parties". As a means of economic ordering, contract relies on the notion of consensual exchange and has been extensively discussed in broader economic, sociological and anthropological terms (see "Contractual theory", below). In American English, the term extends beyond the legal meaning to encompass a broader category of agreements.[4] This article mainly concerns contract law in common law jurisdictions (approximately coincident with the English-speaking world and anywhere the British Empire once held sway). Common-law jurisdictions usually offer proceedings in the English language, which has become to an extent the lingua franca of international business. The common law retains a high degree of freedom of contract, with parties largely free to set their own terms, whereas civil-law systems typically apply certain over-arching principles to disputes arising out of contract (see, for example the French Civil Code). It is very common for businesses not located in common-law jurisdictions to opt in to the common law through "choice of law" clauses. However, contract is a form of economic ordering common throughout the world, and different rules apply in jurisdictions applying civil law (derived from Roman law principles), Islamic law, socialist legal systems, and customary or local law.

Contract formation
The eight key requirements for the creation of a contract are: Agreement (Offer & Acceptance) Capacity to contract Consideration Legal purpose Legality of form Intention to create legal relations

Consent to contract Vitiating factors:mistates,undue influence,misrepresentation,duress

Contract In civil-law systems, the concept of consideration is not central. In most systems of law, parties have freedom to choose whether or not they wish to enter into a contract, absent superseding duties. In American law, one early case exemplifying this proposition is Hurley v. Eddingfield (1901), in which the Supreme Court of Indiana ruled in favor of a physician who voluntarily decided not to help a patient whom the physician had treated on past occasions, despite the lack of other available medical assitance and the patient's subsequent death.[5] In addition, for some contracts formalities must be complied with under legislation sometimes called a statute of frauds (especially transactions in real property or for relatively large cash amounts).

196

Offer and acceptance

The most important feature of a contract is that one party makes an offer for an arrangement that another accepts. This can be called a 'concurrence of wills' or 'ad idem' (meeting of the minds) of two or more parties. The concept is somewhat contested. The obvious objection is that a court cannot read minds and the existence or otherwise of agreement is judged objectively, with only limited room for questioning subjective intention: see Smith v. Hughes.[6] Richard Austen-Baker has suggested that the perpetuation of the idea of 'meeting of minds' may come from a misunderstanding of the Latin term 'consensus ad idem', which actually means 'agreement to the [same] thing'.[7] There must be evidence that the parties had each from an objective perspective engaged in conduct manifesting their assent, and a contract will be formed when the parties have met such a requirement.[8] An objective perspective means that it is only necessary that somebody gives the impression of offering or accepting contractual terms in the eyes of a reasonable person, not that they actually did want to form a contract. The case of Carlill v. Carbolic Smoke Ball Co. (below) is an example of a 'unilateral contract', obligations are only imposed upon one party upon acceptance by performance of a condition. In the U.S., the general rule is that in "case of doubt, an offer is interpreted as inviting the offeree to accept either by promising to perform what the offer requests or by rendering the performance, as the offeree chooses."[9] Offer and acceptance does not always need to be expressed orally or in writing. An implied contract is one in which some of the terms are not expressed in words. This can take two forms. A contract which is implied in fact is one in which the circumstances imply that parties have reached an agreement even though they have not done so expressly. For example, by going to a doctor for a checkup, a patient agrees that he will pay a fair price for the service. If one refuses to pay after being examined, the patient has breached a contract implied in fact. A contract which is implied in law is also called a quasi-contract, because it is not in fact a contract; rather, it is a means for the courts to remedy situations in which one party would be unjustly enriched were he or she not required to compensate the other. For example, a plumber accidentally installs a sprinkler system in the lawn of the wrong house. The owner of the house had learned the previous day that his neighbor was getting new sprinklers. That morning, he sees the plumber installing them in his lawn. Pleased at the mistake, he says nothing, and then refuses to pay when the plumber delivers the bill. Will the man be held liable for payment? Yes, if it could be proven that the man knew that the sprinklers were being installed mistakenly, the court would make him pay because of a quasi-contract. If that knowledge could not be proven, he would not be liable. Such a claim is also referred to as "quantum meruit".[10] Invitation to Treat Where a product in large quantities is advertised in a newspaper or on a poster, it generally is not considered an offer but instead will be regarded as an invitation to treat, since there is no guarantee that the store can provide the item for everyone who might want one. This was the basis of the decision in Partridge v. Crittenden[11] a criminal case in which the defendant was charged with "offering for sale" bramblefinch cocks and hens. The court held that the newspaper advertisement could only be an invitation to treat, since it could not have been intended as an offer to the world, so the defendant was not guilty of "offering" them for sale. Similarly, a display of goods in a shop window is an invitation to treat, as was held in Fisher v. Bell[12] another criminal case which turned on the correct analysis of

Contract offers as against invitations to treat. In this instance the defendant was charged with "offering for sale" prohibited kinds of knife, which he had displayed in his shop window with prices attached. The court held that this was an invitation to treat, the offer would be made by a purchaser going into the shop and asking to buy a knife, with acceptance being by the shopkeeper, which he could withhold. (The law was later amended to "exposing for sale".) A display of goods on the shelves of a self-service shop is also an invitation to treat, with the offer being made by the purchaser at the checkout and being accepted by the shop assistant operating the checkout: Pharmaceutical Society of Great Britain v. Boots Cash Chemists (Southern) Ltd.[13] If the person who is to buy the advertised product is of importance, for instance because of his personality, etc., when buying land, it is regarded merely as an invitation to treat. In Carbolic Smoke Ball, the major difference was that a reward was included in the advertisement, which is a general exception to the rule and is then treated as an offer. One of the most famous cases on invitation to treat is Carlill v. Carbolic Smoke Ball Company,[14] decided in nineteenth-century England. A medical firm advertised that its new wonder drug, a smoke ball, would prevent those who used it according to the instructions from catching the flu, and if it did not, buyers would receive 100 and said that they had deposited 1,000 in the bank to show their good faith. When sued, Carbolic argued the ad was not to be taken as a serious, legally binding offer. It was merely an invitation to treat, and a gimmick (a 'mere puff'). But the court of appeal held that it would appear to a reasonable man that Carbolic had made a serious offer, primarily because of the reference to the 1000 deposited into the bank. People had given good "consideration" for it by going to the "distinct inconvenience" of using a faulty product. "Read the advertisement how you will, and twist it about as you will," said Lindley LJ, "here is a distinct promise expressed in language which is perfectly unmistakable".

197

The Carbolic Smoke Ball offer

Consideration and estoppel

Consideration is known as 'the price of a promise' and is a requirement for contracts under common law. The idea behind consideration is that both parties to a contract must bring something to the bargain. A party seeking to enforce a contract must show that it conferred some benefit or suffered some detriment (though it might be trivial, see below) that is recognized by law. For example, money is often recognized as consideration, but in some cases money will not suffice as consideration (for example, when one party agrees to make partial payment of a debt in exchange for being released from the full amount).[15] Some common-law and civil-law systems[16] do not require consideration, and some commentators consider it unnecessarythe requirement of intent by both parties to create legal relations by both parties performs the same function under contract. The reason that both exist in common law jurisdictions is thought by leading scholars to be the result of the combining by 19th century judges of two distinct threads: first the consideration requirement was at the heart of the action of assumpsit, which had grown up in the Middle Ages and remained the normal action for breach of a simple contract in England & Wales until 1884, when the old forms of action were abolished; secondly, the notion of agreement between two or more parties as being the essential legal and moral foundation of contract in all legal systems, promoted by the 18th century French writer Pothier in his Traite des Obligations, much read (especially after translation into English in 1805) by English judges and jurists. The latter chimed well with the fashionable will theories of the time, especially John Stuart Mill's influential ideas on free will, and got grafted on to the traditional common law requirement for consideration to ground an action in assumpsit.[17] Although several rules govern consideration, the following are the principal rules.

Contract Consideration must be "sufficient" (i.e., recognizable by the law), but need not be "adequate" (i.e., the consideration need not be a fair and reasonable exchange for the benefit of the promise). For instance, agreeing to buy a car for a penny may constitute a binding contract.[18] Consideration must not be from the past. For instance, in Eastwood v. Kenyon,[19] the guardian of a young girl obtained a loan to educate the girl and to improve her marriage prospects. After her marriage, her husband promised to pay off the loan. It was held that the guardian could not enforce the promise because taking out the loan to raise and educate the girl was past considerationit was completed before the husband promised to repay it. Consideration must move from the promisee. For instance, it is good consideration for person A to pay person C in return for services rendered by person B. If there are joint promisees, then consideration need only to move from one of the promisees. The promise to do something one is already contractually obliged to do is not, traditionally, regarded as good consideration. The classic instance is Stilk v. Myrick[20] , in which a captain's promise to divide the wages of two deserters among the remaining crew if they would sail home from the Baltic short-handed, was found unenforceable on the grounds that the crew were already contracted to sail the ship through all perils of the sea. (The case has been much criticized on grounds that the ship was in port at the time of the promise.) A very specific example is the "rule in Pinnel's Case"[21] , brought into the modern law of consideration by the House of Lords in Foakes v. Beer[22] . This rule is to the effect that a smaller sum of money cannot be good consideration for the release of a larger debt, though if the smaller sum is accompanied by something non-monetary in addition, for instance "a horse, a hawk or a robe", or payment is to be made early or in some special place or way, then there will be good consideration for the promise to discharge the debt. This rule has suffered some inroads recently. In Williams v. Roffey Bros & Nicholls (Contractors) Ltd[23] the English Court of Appeal held that a promise by a joiner to complete the contracted work on time, where this was falling behind, was good consideration for the contractor's promise to pay extra money. The reasoning adopted was that the strict rule of Stilk v. Myrick was no longer necessary, as English law now recognized a doctrine of economic duress to vitiate promises obtained when the promisor was "over a barrel" for financial reasons. Therefore, where the promise to pay extra could be seen as conferring a practical benefit on the promisor, that could be good consideration for a variation of the terms. The rule in Pinnel's Case has also been effectively sidestepped in England by the Court of Appeal in the case of Collier v. P & MJ Wright (Holdings) Ltd[24] which held that a promise to accept less in discharge of a pure debt (as opposed to, say, accepting reduced rent, which has long been recognized) could give rise to a promissory estoppel.[25] The promise must not be to do something one is already obliged by the general law to do - e.g., to give refrain from crime or to give evidence in court: Collins v. Godefroy.[26] However, a promise from A to do something for B if B will perform a contractual obligation B owes to C, will be enforceable - B is suffering a legal detriment by making his performance of his contract with A effectively enforceable by C as well as by A.[27] Civil law systems take the approach that an exchange of promises, or a concurrence of wills alone, rather than an exchange in valuable rights is the correct basis. So if you promised to give me a book, and I accepted your offer without giving anything in return, I would have a legal right to the book and you could not change your mind about giving me it as a gift. However, in common law systems the concept of culpa in contrahendo, a form of 'estoppel', is increasingly used to create obligations during pre-contractual negotiations.[28] Estoppel is an equitable doctrine that provides for the creation of legal obligations if a party has given another an assurance and the other has relied on the assurance to his detriment. A number of commentators have suggested that consideration be abandoned, and estoppel be used to replace it as a basis for contracts.[29] However, legislation, rather than judicial development, has been touted as the only way to remove this entrenched common law doctrine. Lord Justice Denning famously stated that "The doctrine of consideration is too firmly fixed to be overthrown by a side-wind."[30]

198

Contract

199

Intention to be legally bound

There is a presumption for commercial agreements that parties intend to be legally bound (unless the parties expressly state that they do not want to be bound, like in heads of agreement). On the other hand, many kinds of domestic and social agreements are unenforceable on the basis of public policy, for instance between children and parents. One early example is found in Balfour v. Balfour.[31] Using contract-like terms, Mr. Balfour had agreed to give his wife 30 a month as maintenance while he was living in Ceylon (Sri Lanka). Once he left, they separated and Mr. Balfour stopped payments. Mrs. Balfour brought an action to enforce the payments. At the Court of Appeal, the Court held that there was no enforceable agreement as there was not enough evidence to suggest that they were intending to be legally bound by the promise. The case is often cited in conjunction with Merritt v. Merritt.[32] Here the court distinguished the case from Balfour v. Balfour because Mr. and Mrs. Merritt, although married again, were estranged at the time the agreement was made. Therefore any agreement between them was made with the intention to create legal relations.

Third parties
The doctrine of privity of contract means that only those involved in striking a bargain would have standing to enforce it. In general this is still the case, only parties to a contract may sue for the breach of a contract, although in recent years the rule of privity has eroded somewhat and third party beneficiaries have been allowed to recover damages for breaches of contracts they were not party to. In cases where facts involve third party beneficiaries or debtors to the original contracting party have been allowed to be considered parties for purposes of enforcement of the contract .A recent advance has been seen in the case law as well as statutory recognition to the dilution of the doctrine of privity of contract .The recent tests applied by courts have beenthe test of benefit and the duty owed test .The duty owed test looks to see if the third party was agreeing to pay a debt for the original party[needs elaboration] and whereas the benefit test looks to see if circumstances indicate that the promisee intends to give the beneficiary the benefit of the promised performance. Any defense allowed to parties of the original contract extend to third party beneficiaries.[74] A recent example is in England, where the Contract (Rights of Third Parties) Act 1999 Contracts (Rights of Third Parties) Act 1999 was introduced.

Formalities and writing

A verbal exchange of promises may be binding and be as legally valid as a written contract. An unwritten, unspoken contract, also known as "a contract implied by the acts of the parties", which can be either implied in fact or implied in law, may also be legally binding. Most jurisdictions have rules of law or statutes which may render otherwise valid oral contracts unenforceable. This is especially true regarding oral contracts involving large amounts of money or real estate. For example, in the U.S., generally speaking, a contract is unenforceable if it violates the common law statute of frauds or equivalent state statutes which require certain contracts to be in writing. An example of the above is an oral contract for the sale of a motorcycle for US$5,000 in a jurisdiction which requires a contract for the sale of goods over US $500 to be in writing to be enforceable. The point of the Statute of frauds is to prevent false allegations of the existence of contracts that were never made, by requiring formal (i.e. written) evidence of the contract. However, a common remark is that more frauds have been committed through the application of the Statute of frauds than have ever been prevented. Contracts that do not meet the requirements of common law or statutory Statutes of frauds are unenforceable, but are not necessarily thereby void. However, a party unjustly enriched by an unenforceable contract may be required to provide restitution for unjust enrichment. Statutes of frauds are typically codified in state statutes covering specific types of contracts, such as contracts for the sale of real estate. In Australia and many, if not all, jurisdictions which have adopted the common law of England, for contracts subject to legislation equivalent to the Statute of frauds,[33] there is no requirement for the entire contract to be in writing. Although for property transactions there must be a note or memorandum evidencing the contract, which may come

Contract into existence after the contract has been formed. The note or memorandum must be signed in some way, and a series of documents may be used in place of a single note or memorandum. It must contain all material terms of the contract, the subject matter and the parties to the contract. In England and Wales, the common law Statute of frauds is only now in force for guarantees, which must be evidenced in writing, although the agreement may be made orally. Certain other kinds of contract must be in writing or they are void, for instance, for sale of land under s. 52, Law of Property Act 1925. If a contract is in a written form, and somebody signs the contract, then the person is bound by its terms regardless of whether they have read it or not,[34] provided the document is contractual in nature.[35] Furthermore, if a party wishes to use a document as the basis of a contract, reasonable notice of its terms must be given to the other party prior to their entry into the contract.[36] This includes such things as tickets issued at parking stations.

200

Bilateral and unilateral contracts

Contracts may be bilateral or unilateral. A bilateral contract is the kind of contract that most people think of when they think "contract." It is an agreement in which each of the parties to the contract makes a promise or promises to the other party. For example, in a contract for the sale of a home, the buyer promises to pay the seller $200,000 in exchange for the seller's promise to deliver title to the property. In a unilateral contract, only one party to the contract makes a promise. A typical example is the reward contract: A promises Unilateral contract of adhesion on timekeeping ticket dispensed by vending to pay a reward to B if B finds A's dog. B is machine at parking lot entrance not obliged to find A's dog, but A is obliged to pay the reward to B if B finds the dog. The consideration for the contract here is B's reliance on A's promise, or B giving up his legal right to do whatever he wanted at the time he was engaged in the finding of the dog. In this example, the finding of the dog is a condition precedent to A's obligation to pay, although it is not a legal condition precedent, because technically no contract here has arisen until the dog is found (because B has not accepted A's offer until he finds the dog, and a contract requires offer, acceptance, and consideration), and the term "condition precedent" is used in contract law to designate a condition of a promise in a contract. For example, if B promised to find A's dog, and A promised to pay B when the dog was found, A's promise would have a condition attached to it, and offer and acceptance would already have occurred. This is a situation in which a condition precedent is attached to a bilateral contract. Condition precedents can also be attached to unilateral contracts, however. This would require A to require a further condition to be met before he pays B for finding his dog. So, for example, A could say "If anyone finds my dog, and the sky falls down, I will give that person $100." In this situation, even if the dog is found by B, he would not be entitled to the $100 until the sky falls down. Therefore the sky falling down is a condition precedent to A's duty being actualized, even though they are already in a contract, since A has made an offer and B has accepted. An offer of a unilateral contract may often be made to many people (or 'to the world') by means of an advertisement. In that situation, acceptance will only occur on satisfaction of the condition (such as the finding of the offeror's dog). If the condition is something that only one party can perform, both the offeror and offeree are protected the offeror

Contract is protected because he will only ever be contractually obliged to one of the many offerees; and the offeree is protected, because if she does perform the condition, the offeror will be contractually obliged to pay her. In unilateral contracts, the requirement that acceptance be communicated to the offeror is waived. The offeree accepts by performing the condition, and the offeree's performance is also treated as the price, or consideration, for the offeror's promise. The offeror is master of the offer; it is he who decides whether the contract will be unilateral or bilateral. In unilateral contracts, the offer is made to the public at large. A bilateral contract is one in which there are duties on both sides, rights on both sides, and consideration on both sides. If an offeror makes an offer such as "If you promise to paint my house, I will give you $100," this is a bilateral contract once the offeree accepts. Each side has promised to do something, and each side will get something in return for what they have done.

201

Uncertainty, incompleteness and severance

If the terms of the contract are uncertain or incomplete, the parties cannot have reached an agreement in the eyes of the law.[37] An agreement to agree does not constitute a contract, and an inability to agree on key issues, which may include such things as price or safety, may cause the entire contract to fail. However, a court will attempt to give effect to commercial contracts where possible, by construing a reasonable construction of the contract.[38] Courts may also look to external standards, which are either mentioned explicitly in the contract[39] or implied by common practice in a certain field.[40] In addition, the court may also imply a term; if price is excluded, the court may imply a reasonable price, with the exception of land, and second-hand goods, which are unique. If there are uncertain or incomplete clauses in the contract, and all options in resolving its true meaning have failed, it may be possible to sever and void just those affected clauses if the contract includes a severability clause. The test of whether a clause is severable is an objective testwhether a reasonable person would see the contract standing even without the clauses.

Contractual terms
A contractual term is "[a]ny provision forming part of a contract".[41] Each term gives rise to a contractual obligation, breach of which can give rise to litigation. Not all terms are stated expressly and some terms carry less legal weight as they are peripheral to the objectives of the contract.

Boilerplate
As discussed in Tina L. Stark's Negotiating and Drafting Contract Boilerplate, when lawyers refer to a boilerplate provision, they are referring to any standardized, one size fits all contract provision. But lawyers also use the term in a more narrow context to refer to certain provisions that appear at the end of the contract. Typically, these provisions tell the parties how to govern their relationship and administer the contract. Although often thought to be of secondary importance, these provisions have significant business and legal consequences.[42] Common provisions include the governing law provision, venue, assignment and delegation provisions, waiver of jury trial provisions, notice provisions, and force majeure provisions.[43]

Contract

202

Classification of term
Condition or Warranty.[44] Conditions are terms which go to the very root of a contract. Breach of these terms repudiates the contract, allowing the other party to discharge the contract. A warranty is not so imperative so the contract will subsist after a warranty breach. Breach of either will give rise to damages. It is an objective matter of fact whether a term goes to the root of a contract. By way of illustration, an actress' obligation to perform the opening night of a theatrical production is a condition,[45] whereas a singers obligation to perform during the first three days of rehearsal is a warranty.[46] Statute may also declare a term or nature of term to be a condition or warranty; for example the Sale of Goods Act 1979 s15A[47] provides that terms as to title, description, quality and sample (as described in the Act) are conditions save in certain defined circumstances. Innominate term. Lord Diplock, in Hong Kong Fir Shipping Co Ltd v. Kawasaki Kisen Kaisha Ltd,[48] created the concept of an innominate term, breach of which may or not go to the root of the contract depending upon the nature of the breach. Breach of these terms, as with all terms, will give rise to damages. Whether or not it repudiates the contract depends upon whether legal benefit of the contract has been removed from the innocent party. Megaw LJ, in 1970, preferred the legal certainty of using the classic categories of condition or warranty.[49] This was interpreted by the House of Lords as merely restricting its application in Reardon Smith Line Ltd. v Hansen-Tangen.[50]

Status as a term
as a term is important as a party can only take legal action for the non fulfillment of a term as opposed to representations or mere puffery. Legally speaking, only statements that amount to a term create contractual obligations. There are various factor that a court may take into account in determining the nature of a statement. In particular, the importance apparently placed on the statement by the parties at the time the contract is made is likely to be significant. In Bannerman v. White[51] it was held a term of a contract for sale and purchase of hops that they had not been treated with sulphur, since the buyer made very explicit his unwillingness to accept hops so treated, saying that he had no use for them. The relative knowledge of the parties may also be a factor, as in Bissett v. Wilkinson[52] in which a statement that farmland being sold would carry 2000 sheep if worked by one team was held merely a representation (it was also only an opinion and therefore not actionable as misrepresentation). The reason this was not a term was that the seller had no basis for making the statement, as the buyer knew, and the buyer was prepared to rely on his own and his son's knowledge of farming.

Contract

203

Implied terms
A term may either be express or implied. An express term is stated by the parties during negotiation or written in a contractual document. Implied terms are not stated but nevertheless form a provision of the contract. Terms implied in fact Terms may be implied due to the facts of the proceedings by which the contract was formed. In the Australian case of BP Refinery Westernport v. Shire of Hastings[53] the UK Privy Council proposed a five stage test to determine situations where the facts of a case may imply terms (this only applies to formal contracts in Australia).[54] However, the English Court of Appeal sounded a note of caution with regard to the BP case in Philips Electronique Grand Public SA v. British Sky Broadcasting Ltd[55] in which the Master of the Rolls described the test as "almost misleading" in its simplicity.[56] The classic tests have been the "business efficacy test" and the "officious bystander test". The first of these was proposed by Lord Justice Bowen in The Moorcock.[57] This test requires that a term can only be implied if it is necessary to give business efficacy to the contract to avoid such a failure of consideration that the parties cannot as reasonable businessmen have intended. But only the most limited term should then be implied the bare minimum to achieve this goal. The officious bystander test derives its name from the judgment of Lord Justice Mackinnon in Shirlaw v. Southern Foundries (1926) Ltd[58] but the test actually originates in the judgment of Lord Justice Scrutton in Reigate v. Union Manufacturing Co (Ramsbottom) Ltd[59] This test is that a term can only be implied in fact if it is such a term that had an "officious bystander" listening to the contract negotiations suggested that they should include this term the parties would "dismiss him with a common 'Oh of course!'". It is at least questionable whether this is truly a separate test or just a description of how one might go about arriving at a decision on the basis of the business efficacy test. Some jurisdictions, notably Australia, Israel and India, imply a term of good faith into contracts. A final way in which terms may be implied due to fact is through a previous course of dealing or common trade practice. The Uniform Commercial Code of the United States also imposes a duty of good faith in performance and enforcement of contracts covered by the Code, which cannot be derogated from. Terms implied in law These are terms that have been implied into standardized relationships. Instances of this are quite numerous, especially in employment contracts and shipping contracts. Common law Liverpool City Council v. Irwin[60] established a term to be implied into all contracts between tenant and landlord in multi-storey blocks that the landlord is obliged to take reasonable care to keep the common areas in a reasonable state of repair. Wong Mee Wan v Kwan Kin Travel Services Ltd.[61] established that when a tour operator contracts to for the sale of goods. These terms will be implied into all contracts of the same nature as a matter of law. Statute law The rules by which many contracts are governed are provided in specialized statutes that deal with particular subjects. Most countries, for example, have statutes which deal directly with sale of goods, lease transactions, and trade practices. For example, most American states have adopted Article 2 of the Uniform Commercial Code, which regulates contracts for the sale of goods. The most important legislation implying terms under United Kingdom law are the Sale of Goods Act 1979, the Consumer Protection (Distance Selling) Regulations 2000 and the Supply of Goods and Services Act 1982 which imply terms into all contracts whereby goods are sold or services provided.

Contract Coercive vs voluntary contractive exchanges There are a few ways of determining whether a contract has been coerced or is voluntary: Moral consideration: Objective consideration of right or wrong outside of the objective cause, or the perceived cause. Example: X (event) occurs everyday at 5 pm. X is wrong. Anything that avoids X is good; allowing X, even if all parties agree, is bad. Phenomenological consideration - what models did the participants have which influenced the perception of what was to occur or what had occurred. Example: I observe X, Y (events) every day at 5 pm. I contract against X. Today I did / did not see Y occur. Statistical consideration - did the participants have a statistical prediction, likelihood of an event occurring which is covered by the contract. Example: X (event) happens every day at 5 pm, I enter a contract to avoid X. X does or does not occur.

204

Setting aside the contract

There can be four different ways in which contracts can be set aside. A contract may be deemed 'void', 'voidable', 'unenforceable'or 'ineffective'. Voidness implies that a contract never came into existence. Voidability implies that one or both parties may declare a contract ineffective at their wish. Unenforceability implies that neither party may have recourse to a court for a remedy. Ineffectiveness implies that the contract terminates by order of a court where a public body has failed to satisfy public procurement law. To rescind is to set aside or unmake a contract.

Misrepresentation
Misrepresentation means a false statement of fact made by one party to another party and has the effect of inducing that party into the contract. For example, under certain circumstances, false statements or promises made by a seller of goods regarding the quality or nature of the product that the seller has may constitute misrepresentation. A finding of misrepresentation allows for a remedy of rescission and sometimes damages depending on the type of misrepresentation. There are two types of misrepresentation in contract law, fraud in the factum and fraud in inducement. Fraud in the factum focuses on whether the party in question knew they were creating a contract. If the party did not know that they were entering into a contract, there is no meeting of the minds, and the contract is void. Fraud in inducement focuses on misrepresentation attempting to get the party to enter into the contract. Misrepresentation of a material fact (if the party knew the truth, that party would not have entered into the contract) makes a contract voidable. According to Gordon v. Selico[62] it is possible to make a misrepresentation either by words or by conduct, although not everything said or done is capable of constituting a misrepresentation. Generally, statements of opinion or intention are not statements of fact in the context of misrepresentation. Both an order for specific performance and an injunction are discretionary remedies, originating for the most part in equity. Neither is available as of right and in most jurisdictions and most circumstances a court will not normally order specific performance. A contract for the sale of real property is a notable exception. In most jurisdictions, the sale of real property is enforceable by specific performance. Even in this case the defenses to an action in equity (such as laches, the bona fide purchaser rule, or unclean hands) may act as a bar to specific performance. Related to orders for specific performance, an injunction may be requested when the contract prohibits a certain action. Action for injunction would prohibit the person from performing the act specified in the contract.

Contract

205

Procedure
In the United States, in order to obtain damages for breach of contract or to obtain specific performance or other equitable relief, the aggrieved injured party may file a civil (non-criminal) lawsuit in state court (unless there is diversity of citizenship giving rise to federal jurisdiction). If the contract contains an arbitration clause, the aggrieved party must submit an arbitration claim in accordance with the procedures set forth in the agreement. Many contracts provide that all disputes arising thereunder will be resolved by arbitration, rather than litigated in courts. Customer claims against securities brokers and dealers are almost always resolved by arbitration because securities dealers are required, under the terms of their membership in self-regulatory organizations such as the Financial Industry Regulatory Authority (formerly the NASD) or NYSE to arbitrate disputes with their customers. The firms then began including arbitration agreements in their customer agreements, requiring their customers to arbitrate disputes.[63] On the other hand, certain claims have been held to be non-arbitrable if they implicate a public interest that goes beyond the narrow interests of the parties to the agreement (i.e., claims that a party violated a contract by engaging in illegal anti-competitive conduct or civil rights violations). Arbitration judgments may generally be enforced in the same manner as ordinary court judgments. However, arbitral decisions are generally immune from appeal in the United States unless there is a showing that the arbitrator's decision was irrational or tainted by fraud. Virtually all states have adopted the Uniform Arbitration Act to facilitate the enforcement of arbitrated judgments. Notably, New York State, where a sizable portion of major commercial agreements are executed and performed, has not adopted the Uniform Arbitration Act.[64] In England and Wales, a contract may be enforced by use of a claim, or in urgent cases by applying for an interim injunction to prevent a breach. Likewise, in the United States, an aggrieved party may apply for injunctive relief to prevent a threatened breach of contract, where such breach would result in irreparable harm that could not be adequately remedied by money damages.

Other contract
Online contracts, which are easily made, are usually valid on a smaller scale for a period of one to three months, while on a larger scale can last about five years. As with all things legal, especially in regards to the ever-evolving internet, general rules like length of validity have many exceptions. All cases are evaluated on their own merits, and those merits are defined by the facts presented in each instance. It is up to the owner of the site to do what it can to guarantee enforceability of its contracts. Though 90% of people sign online contracts before reading the content, E-signature laws have made the electronic contract and signature as legally valid as a paper contract. It has been estimated that roughly one hundred and ten electronic contracts are signed every second.

Contract theory
Contract theory is the body of legal theory that addresses normative and conceptual questions in contract law. One of the most important questions asked in contract theory is why contracts are enforced. One prominent answer to this question focuses on the economic benefits of enforcing bargains. Another approach, associated with Charles Fried, maintains that the purpose of contract law is to enforce promises. This theory is developed in Fried's book, Contract as Promise. Other approaches to contract theory are found in the writings of legal realists and critical legal studies theorists. More generally, writers have propounded Marxist and feminist interpretations of contract. Attempts at overarching understandings of the purpose and nature of contract as a phenomenon have been made, notably 'relational contract theory' originally developed by U.S. contracts scholars Ian Roderick Macneil and Stewart Macaulay, building at least in part on the contract theory work of U.S. scholar Lon L. Fuller, while U.S. scholars have been at the forefront of developing economic theories of contract focussing on questions of transaction cost and so-called 'efficient breach' theory.

Contract Another dimension of the theoretical debate in contract is its place within, and relationship to a wider law of obligations. Obligations have traditionally been divided into contracts, which are voluntarily undertaken and owed to a specific person or persons, and obligations in tort which are based on the wrongful infliction of harm to certain protected interests, primarily imposed by the law, and typically owed to a wider class of persons. Recently it has been accepted that there is a third category, restitutionary obligations, based on the unjust enrichment of the defendant at the plaintiffs expense. Contractual liability, reflecting the constitutive function of contract, is generally for failing to make things better (by not rendering the expected performance), liability in tort is generally for action (as opposed to omission) making things worse, and liability in restitution is for unjustly taking or retaining the benefit of the plaintiffs money or work.[65] The common law describes the circumstances under which the law will recognise the existence of rights, privilege or power arising out of a promise.

206

National contract law See also

Contract (conflict) Document automation Contract of sale Contracting Contractual clauses (category) Design by contract Estoppel Ethical implications in contracts Force majeure Gentlemen's agreement Good faith Implicit contract Indenture Invitation to treat Memorandum of understanding Negotiation Option contract Order (business) Peppercorn (legal) Perfect tender rule Quasi-contract Remedy Restitution Specification (technical standard) Standard form contract Stipulation Tortious interference Unjust enrichment Voidable contract

References
Ewan McKendrick, Contract Law - Text, Cases and Materials (2005) Oxford University Press ISBN 0-19-927480-0 P.S. Atiyah, The Rise and Fall of Freedom of Contract (1979) Clarendon Press ISBN 0-19-825342-7 Randy E. Barnett, Contracts (2003) Aspen Publishers ISBN 0-7355-6535-2 Scott Fruehwald, "Reciprocal Altruism as the Basis for Contract," 47 University of Louisville Law Review 489 (2009).

Contract

207

External links
Australian Contract Law [66] Behavioral Contracting in the Classroom [67] Contract Law Lessons & Materials by Max Young [68] Cornell Law School [69] contracts: an overview Principles of European Contract Law [70] United Nations Convention on Contracts for the International Sale of Goods, Vienna, 11 April 1980 [71]

References
[1] Economics: Principles in action (http:/ / www. pearsonschool. com/ index. cfm?locator=PSZ3R9& PMDbSiteId=2781& PMDbSolutionId=6724& PMDbCategoryId=& PMDbProgramId=12881& level=4). Upper Saddle River, New Jersey 07458: Pearson Prentice Hall. 2003. pp.523. ISBN0-13-063085-3. . [2] Hans Wehberg, Pacta Sunt Servanda, The American Journal of International Law, Vol. 53, No. 4 (Oct., 1959), p.775. [3] e.g. In England, s. 52, Law of Property Act 1900 [4] 2008 Merriam-Webster online dictionary (http:/ / www. merriam-webster. com/ dictionary/ contract) [5] Journal of the American Medical Association, Vol. 36. (April 20, 1901). (http:/ / books. google. com/ books?id=ZOsBAAAAYAAJ& pg=PA1140& lpg=PA1140& dq=indiana+ intestate+ family+ physician& source=bl& ots=nAAuk12Q03& sig=A3hUDdoOjz1vrC1bWJ8V_7IHfak& hl=en& ei=HvQCTKCPEIP58AbLprz5DQ& sa=X& oi=book_result& ct=result& resnum=8& ved=0CCsQ6AEwBw#v=onepage& q=indiana intestate family physician& f=false) p. 1140. [6] (1870-71) LR 6 QB 597 [7] R. Austen-Baker, 'Gilmore and the Strange Case of the Failure of Contract to Die After All' (2002) 18 Journal of Contract Law 1 [8] e.g. Lord Steyn, 'Contract Law: Fulfilling the Reasonable Expectations of Honest Men' (1997) 113 LQR 433; c.f. 133 BGB in Germany, where "the actual will of the contracting party, not the literal sense of words, is to be determined" [9] Restatement (Second) of Contracts 32 (1981) (emphasis added) [10] law.com Law Dictionary (http:/ / 12. 170. 132. 252/ default2. asp?selected=1692& bold=||||) [11] [1968] 1 WLR 1204 [12] [1961] 1 QB 394 [13] [1953] 1 QB 401 [14] [1893] 2 QB 256 [15] The rule in Pinnel's Case - Foakes v Beer (1884) 9 App Cas 605 [16] e.g. In Germany, 311 BGB [17] For a detailed and authoritative account of this process, see A. W. B. Simpson, A History of the Common Law of Contract: The Rise of the Action of Assumpsit, (OUP: Oxford, 1975). [18] Chappell & Co Ltd v. Nestle Co Ltd [1959] 2 All ER 701 in which the wrappers from three chocolate bars was held to be part of the consideration for the sale and purchase of a musical recording. [19] Eastwood v. Kenyon (1840) 11 Ad&E 438 [20] (1809) 2 Camp. 317. [21] (1602) Co. Rep. 117a. [22] (1883) L.R. 9 App. Cas. 605. [23] [1991] 1 Q.B. 1. [24] [2007] E.W.C.A. Civ. 1329. For commentary, see R. Austen-Baker (2008) 71 Modern Law Review 611. [25] See, further, Estoppel in English Law. [26] (1831) 1 B. & Ad. 950. [27] See, e.g., Shadwell v. Shadwell (1860) 9 C.B.N.S. 159. [28] Austotel v. Franklins (1989) 16 NSWLR 582 [29] e.g. P.S. Atiyah, 'Consideration: A Restatement' in Essays on Contract (1986) p.195, Oxford University Press [30] Central London Property Trust Ltd. v. High Trees House Ltd. [1947] KB 130 [31] Balfour v. Balfour [1919] 2 KB 571 [32] Merritt v. Merritt [1970] 2 All ER 760; [1970] 1 WLR 1211; CA [33] in Australia it is known as the Sales of Goods Act in most states, and in Victoria the Goods Act 1958 [34] L'Estrange v. Graucob [1934] 2 KB 394 [35] Curtis v. Chemical Cleaning and Dyeing Co [1951] 1 KB 805 [36] Balmain New Ferry Company Ltd v. Robertson (1906) 4 CLR 379 [37] Fry v. Barnes (1953) 2 D.L.R. 817 (B.C.S.C) [38] Hillas and Co. Ltd. v. Arcos Ltd. (1932) 147 LT 503 [39] Whitlock v. Brew (1968) 118 CLR 445

Contract
[40] Three Rivers Trading Co., Ltd. v. Gwinear & District Farmers, Ltd. (1967) 111 Sol. J. 831 [41] Martin, E [ed] & Law, J [ed], Oxford Dictionary of Law, ed6 (2006, London:OUP). [42] Jamie Wodetzki, "Boilerplate that Bites: The Arbitration Clause", 2006 (http:/ / exari. blogspot. com/ 2006/ 07/ boilerplate-that-bites-arbitration. html) [43] Tina L. Stark, Negotiating and Drafting Contract Boilerplate, (ALM Publishing 2003, pp.5-7). ISBN 978-1-58852-105-7 [44] Not to be confused with a product warranty, which is always referred to as a 'guarantee' in law. [45] Poussard v. Spiers and Pond (1876) 1 QBD 410 [46] Bettini v. Gye (1876) 1 QBD 183 [47] As added by the Sale of Goods Act 1994 s4(1). [48] [1962] 1 All ER 474 [49] Maredelanto Compania Naviera SA v Bergbau-Handel GmbH. The Mihalis Angelos [1970] 3 All ER 125. [50] [1976] 3 All ER 570 [51] (1861) 10 CBNS 844 [52] [1927] AC 177 [53] (1977) 180 CLR 266 [54] Byrne and Frew v. Australian Airlines Ltd (1995) 185 CLR 410 [55] [1995] EMLR 472 [56] [1995] EMLR 472 at 481 [57] (1889) 14 PD 64 [58] [1939] 2 KB 206 [59] [1918] 1 KB 592 [60] [1976] 2 WLR 562 [61] [1995] 4 All ER 745 [62] Gordon v. Selico (1986) 18 HLR 219 [63] Introduction to Securities Arbitration - an Overview from SECLaw.com the online leader in securities law news, information and commentary (http:/ / www. seclaw. com/ arbover. htm) [64] New York Civil Procedure Law and Rules 7501, et seq. [65] Beatson, Ansons Law of Contract (1998) 27th ed. OUP, p.21 [66] http:/ / www. australiancontractlaw. com [67] http:/ / moodle. ed. uiuc. edu/ wiked/ index. php/ Behavioral_contracting [68] http:/ / www. legalmax. info [69] http:/ / www. law. cornell. edu/ topics/ contracts. html [70] http:/ / www. jus. uio. no/ lm/ eu. contract. principles. part1. 1995/ [71] http:/ / www. tititudorancea. com/ z/ united_nations_convention_international_sale_goods. htm

208

United States Department of Veterans Affairs

209

United States Department of Veterans Affairs

United States Department of Veterans Affairs

Seal of the Department of Veterans Affairs Agency overview Formed Preceding agency Jurisdiction Headquarters 21 July 1930 (Cabinet rank 15 March 1989) Veterans Administration Federal government of the United States 810 Vermont Avenue NW Washington, DC United States 38543.250N 7725.366W 278,565 (2008) $87.6 billion (2009)

Employees Annual budget

Agency executives Eric Shinseki, General USA, Ret., Secretary W. Scott Gould, Deputy Secretary Child agency Click Here Website www.va.gov
[1]

The United States Department of Veterans Affairs (VA) is a government-run military veteran benefit system with Cabinet-level status. It is the United States governments second largest department, after the United States Department of Defense.[2] With a total 2009 budget of about $87.6 billion, VA employs nearly 280,000 people at hundreds of Veterans Affairs medical facilities, clinics, and benefits offices and is responsible for administering programs of veterans benefits for veterans, their families, and survivors. The benefits provided include disability compensation, pension, education, home loans, life insurance, vocational rehabilitation, survivors benefits, medical benefits and burial benefits.[3] It is administered by the United States Secretary of Veterans Affairs.

United States Department of Veterans Affairs

210

History
The United States has the most comprehensive system of assistance for veterans of any nation in the world. This benefits system traces its roots back to 1636, when the Pilgrims of Plymouth Colony were at war with the Pequot Indians. The Pilgrims passed a law which stated that disabled soldiers would be supported by the colony. The Continental Congress of 1776 encouraged enlistments during the Revolutionary War by providing pensions for soldiers who were disabled. Direct medical and hospital care given to veterans in the early days of the Republic was provided by the individual States and communities. In 1811, the first domiciliary and medical facility for veterans was authorized by the Federal Government, but not opened until 1834. In the 19th century, the Nation's veterans assistance program was expanded to include benefits and pensions not only for veterans, but also their widows and dependents. After the Civil War, many State veterans homes were established. Since domiciliary care was available at all State veterans homes, incidental medical and hospital treatment was provided for all injuries and diseases, whether or not of service origin. Indigent and disabled veterans of the Civil War, Indian Wars, Spanish-American War, and Mexican Border period as well as discharged regular members of the Armed Forces were cared for at these homes. Congress established a new system of veterans benefits when the United States entered World War I in 1917. Included were programs for disability compensation, insurance for servicepersons and veterans, and vocational rehabilitation for the disabled. By the 1920s, the various benefits were administered by three different Federal agencies: the Veterans Bureau, the Bureau of Pensions of the Interior Department, and the National Home for Disabled Volunteer Soldiers. The establishment of the Veterans Administration came in 1930 when Congress authorized the President to "consolidate and coordinate Government activities affecting war veterans." The three component agencies became bureaus within the Veterans Administration. Brigadier General Frank T. Hines, who directed the Veterans Bureau for seven years, was named as the first Administrator of Veterans Affairs, a job he held until 1945. The VA health care system has grown from 54 hospitals in 1930, to include 171 medical centers; more than 350 outpatient, community, and outreach clinics; 126 nursing home care units; and 35 domiciliaries. VA health care facilities provide a broad spectrum of medical, surgical, and rehabilitative care. The responsibilities and benefits programs of the Veterans Administration grew enormously during the following six decades. World War II resulted in not only a vast increase in the veteran population, but also in large number of new benefits enacted by the Congress for veterans of the war. The World War II GI Bill, signed into law on June 22, 1944, is said to have had more impact on the American way of life than any law since the Homestead Act more than a century ago. Further educational assistance acts were passed for the benefit of veterans of the Korean War, the Vietnam Era, the introduction of the "All-Volunteer Force" in the 1970s (following the end of conscription in the United States in 1973), the Persian Gulf War, and those who served following the attacks of September 11, 2001. In 1973, the Veterans Administration assumed another major responsibility when the National Cemetery System (NCS) (except for Arlington National Cemetery) was transferred to the Veterans Administration from the Department of the Army. The VA was charged with the operation of the NCS, including the marking of graves of all persons in national and State cemeteries (and the graves of veterans in private cemeteries, upon request) as well and administering the State Cemetery Grants Program. The Department of Veterans Affairs (VA) was established as a Cabinet-level position on March 15, 1989. President George H.W. Bush hailed the creation of the new Department saying, "There is only one place for the veterans of America, in the Cabinet Room, at the table with the President of the United States of America."

United States Department of Veterans Affairs

211

Organization and Function

The Department of Veterans Affairs is headed by the Secretary of Veterans Affairs, appointed by the President with the advice and consent of the Senate. The current Secretary of Veterans Affairs is Ret. General Eric Shinseki. The primary function of the Department of Veterans Affairs is to help veterans by providing certain benefits and services. The Department has three main subdivisions, known as Administrations, each headed by an Undersecretary:
A VA medical center in Palo Alto

Veterans Health Administration - responsible for providing health care in all its forms, as well as for medical research, Community Based Outpatient Clinics (CBOCs), and Regional Medical Centers. Veterans Benefits Administration - responsible for initial veteran registration, eligibility determination, and five key lines of business (benefits and entitlements): Home Loan Guaranty, Insurance, Vocational Rehabilitation and Employment, Education (GI Bill), and Compensation & Pension National Cemetery Administration - responsible for providing burial and memorial benefits, as well as for maintenance of VA cemeteries

Costs for care

As is common in any time of war, recently there has been an increased demand for nursing home beds, injury rehabilitation, and mental health care. VA categorizes veterans into eight priority groups and several additional subgroups, based on factors such as service-connected disabilities, and ones income and assets (adjusted to local cost of living). Veterans with a 50% or higher service-connected disability as determined by a VA regional office rating board (e.g., losing a limb in battle, PTSD, etc) are provided Long Beach VA medical center comprehensive care and medication at no charge. Veterans with lesser qualifying factors who exceed a pre-defined income threshold have to make co-payments for care for non-service-connected ailments and pay $8 per 30-day supply for each prescription medication. VA dental and nursing home care benefits are more restricted. Reservists and National Guard personnel who served stateside in peacetime settings or have no service-related disabilities generally do not qualify for VA health benefits.[4] In recent years, the VA has opened hundreds of new convenient outpatient clinics in towns across the United States, while steadily reducing inpatient bed levels at its hospitals. VAs budget has been pushed to the limit in recent years by the War on Terrorism.[5] In December 2004, it was widely reported that VAs funding crisis had become so severe that it could no longer provide disability ratings to veterans in a timely fashion.[6] This is a problem because until veterans are fully transitioned from the active-duty TRICARE healthcare system to VA, they are on their own with regard to many healthcare costs. The VA has worked to cut down screening times for these returning combat vets (they are now often evaluated by VA personnel well before their actual discharge), and they receive first priority for patient appointments. VAs backlog of pending disability claims under review (a process known as adjudication) peaked at 421,000 in 2001,

United States Department of Veterans Affairs and bottomed out at 254,000 in 2003, but crept back up to 340,000 in 2005.[7] No copayment is required for VA services for veterans with military-related medical conditions. VA-recognized service-connected disabilities include problems that started or were aggravated due to military service. Veteran service organizations such as the American Legion, Veterans of Foreign Wars, and Disabled American Veterans, as well as state-operated Veterans Affairs offices and County Veteran Service Officers (CVSO), have been known to assist veterans in the process of getting care from the VA. In his budget proposal for fiscal year 2009, President George W. Bush requested $38.7 billion - or 86.5% of the total Veterans Affairs budget - for veteran medical care alone.

212

Security breach
In May 2006, a laptop computer containing in the clear (unencrypted) social security numbers of 26.5 million U.S. veterans was stolen from a Veterans Affairs analysts home. The analyst violated existing VA policy by removing the data from his workplace.[8] On 3 August 2006, a computer containing personal information in the clear on up to 38,000 veterans went missing. The computer has since been recovered and on 5 August 2006, two men were charged with the theft. In early August 2006, a plan was announced to encrypt critical data on every laptop in the agency using disk encryption software.[9] Strict policies have also been enacted that require a detailed description of what a laptop will be used for and where it will be located at any given time. Encryption for e-mail had already been in use for some time but is now the renewed focus of internal security practices for sending e-mail containing patient information.

Related legislation
1944 - Mustering-out Payment Act PL 78-225 1944 - Servicemens Readjustment Act PL 78-346 1944 - Veterans' Preference Act PL 78-359 1952 - Veterans' Readjustment Assistance Act PL 82-550 1974 - Vietnam Veterans' Readjustment Assistance Act 1988 - Department of Veterans Affairs Act PL 100-527

Related studies
In 1998, the Institute of Medicine began a series of studies to respond to requests from the U.S. Department of Veterans Affairs and Congress for an examination of the health effects of potentially harmful agents to which Gulf War veterans might have been exposed. [10] Jan. 1, 2000 - Gulf War and Health: Volume 1. Depleted Uranium, Sarin, Pyridostigmine Bromide, and Vaccines
[11]

Feb. 18, 2003 - Gulf War and Health Volume 2: Insecticides and Solvents [12] Aug. 20, 2004 - Gulf War and Health: Updated Literature Review of Sarin [13] Dec. 20, 2004 - Gulf War and Health: Volume 3. Fuels, Combustion Products, and Propellants [14] Sep. 12, 2006 - Gulf War and Health: Volume 4. Health Effects of Serving in the Gulf War [15] Oct. 16, 2006 - Gulf War and Health: Volume 5. Infectious Disease [16] Nov. 15, 2007 - Gulf War and Health: Volume 6. Physiologic, Psychologic, and Psychosocial Effects of Deployment-Related Stress [17]
[18]

Jul. 30, 2008 - Epidemiologic Studies of Veterans Exposed to Depleted Uranium: Feasibility and Design Issues Jul. 30, 2008 - Gulf War and Health: Updated Literature Review of Depleted Uranium [19] Dec. 4, 2008 - Gulf War and Health: Volume 7. Long-term Consequences of Traumatic Brain Injury [20]

United States Department of Veterans Affairs

213

See also
DD Form 214 List of veterans' organizations Old soldiers' home National Home for Disabled Volunteer Soldiers United States Department of Veterans Affairs Police Veterans Health Administration Department of Veterans Affairs Under Secretary's Award in Health Services Research Veterans Health Information Systems and Technology Architecture (VistA)

External links
United States Department of Veterans Affairs Official Website [21] A Brief History of the VA [22] from the Office of Facilities Management VA HyperFAQ [23] directory of top VA web pages. Proposed and final federal regulations from the Department Of Veterans Affairs [24] A Nation Repays Its Debt:The National Soldiers' Home and Cemetery in Dayton, Ohio, a National Park Service Teaching with Historic Places (TwHP) lesson plan [25] PBS NOW | Fighting the Army [26] Investing In Veterans [27] by Eric Shinseki

References
[1] http:/ / www. va. gov [2] http:/ / en. wikipedia. org/ wiki/ United_States_federal_executive_departments [3] Benefits: Links (http:/ / www. va. gov/ landing_vba. htm), U.S. Department of Veterans Affairs (http:/ / www. va. gov), Retrieved 26 May 2007 [4] Detailed list of VA eligibility criteria (http:/ / www. va. gov/ healtheligibility/ eligibility/ ) [5] Dennis Camire, New fees, limits face ailing veterans, Albany Times Union, 10 February 2003, A1. [6] Cheryl L. Reed, VA chief orders inspector to probe disability rating system, Chicago Sun-Times, 11 December 2004, A3. [7] Cory Reiss, VA fighting losing battle against backlog of veterans claims, Sarasota Herald-Tribune, 27 May 2005, A7. [8] http:/ / www. cnn. com/ 2006/ US/ 06/ 08/ vets. data/ | Agency chief: Data on stolen VA laptop may have been erased [9] Veterans Mortgage Blog (http:/ / www. 4syndication. com/ blog. do?blog=32), 25 May 2006, 9 August 2006, 16 August 2006. [10] Office of News and Public Information (20 December 2004). "Latest IOM Gulf War Report Confirms Link Between Lung Cancer and Combustion Products; Evidence on Other Health Problems Is Inconclusive" (http:/ / www8. nationalacademies. org/ onpinews/ newsitem. aspx?RecordID=11180). Press release. . [11] http:/ / www. iom. edu/ CMS/ 4683/ 5534. aspx [12] http:/ / www. iom. edu/ CMS/ 4683/ 5407. aspx [13] http:/ / www. iom. edu/ Reports/ 2004/ Gulf-War-and-Health-Updated-Literature-Review-of-Sarin. aspx [14] http:/ / www. iom. edu/ CMS/ 4683/ 24236. aspx [15] http:/ / www. iom. edu/ Reports/ 2006/ Gulf-War-and-Health--Volume-4-Health-Effects-of-Serving-in-the-Gulf-War. aspx [16] http:/ / www. iom. edu/ Reports/ 2006/ Gulf-War-and-Health-Volume-5-Infectious-Disease. aspx [17] http:/ / www. iom. edu/ CMS/ 4683/ 48534. aspx [18] http:/ / www. iom. edu/ CMS/ 4683/ 56996. aspx [19] http:/ / www. iom. edu/ CMS/ 4683/ 56994. aspx [20] http:/ / www. iom. edu/ en/ Reports/ 2008/ Gulf-War-and-Health-Volume-7-Long-term-Consequences-of-Traumatic-Brain-Injury. aspx [21] http:/ / www. va. gov/ [22] http:/ / www. va. gov/ facmgt/ historic/ Brief_VA_History. asp [23] http:/ / www. va. gov/ hyperfaq [24] http:/ / openregs. com/ agencies/ view/ 12/ [25] http:/ / www. nps. gov/ history/ NR/ twhp/ wwwlps/ lessons/ 115dayton/ 115dayton. htm [26] http:/ / www. pbs. org/ now/ shows/ 424/ index. html [27] http:/ / www. huffingtonpost. com/ hon-eric-e-shinseki/ investing-in-veterans_b_257725. html

A Guide to the Project Management Body of Knowledge

214

A Guide to the Project Management Body of Knowledge

A Guide to the Project Management Body of Knowledge (PMBOK Guide) is a project management guide, and an internationally recognized standard, that provides the fundamentals of project management as they apply to a wide range of projects, including construction, software, engineering, automotive, etc. The purpose of the PMBOK is to provide and promote a common vocabulary within the project management profession for discussing, writing, and applying project management concepts.[1]

History
A Guide to the Project Management Body of Knowledge (PMBOK Guide) was first published by the Project Management Institute (PMI) as a white paper in 1987 in an attempt to document and standardize generally accepted project management information and practices. The first edition was published in 1996 followed by the second edition in 2000.[2] In 2004 the PMBOK Guide - Third Edition was published with major changes from the first edition. The English-language PMBOK Guide - Fourth Edition was released on December 31, 2008.

Contents
The PMBOK Guide is process-based, meaning it describes work as being accomplished by processes. This approach is consistent with other management standards such as ISO 9000 and the Software Engineering Institute's CMMI. Processes overlap and interact throughout a project or its various phases. Processes are described in terms of: Inputs (documents, plans, designs, etc.) Tools and Techniques (mechanisms applied to inputs) Outputs (documents, products, etc.) The Guide recognizes 42 processes that fall into five basic process groups and nine knowledge areas that are typical of almost all projects. The five process groups are : Initiating, Planning, Executing, Controlling and Monitoring, and Closing. The nine knowledge areas are : Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, and Project Procurement Management. Each of the nine knowledge areas contains the processes that need to be accomplished within its discipline in order to achieve an effective project management program. Each of these processes also falls into one of the five basic process groups, creating a matrix structure such that every process can be related to one knowledge area and one process group. The PMBOK Guide is meant to offer a general guide to manage most projects most of the time. A specialized standard was developed as an extension to the PMBOK Guide to suit special industries, for example the Construction Extension to the PMBOK Guide and the Government Extension to the PMBOK Guide.

A Guide to the Project Management Body of Knowledge

215

See also
Association for Project Management - UK Professional Body for Project Professionals. Producer of APM BoK PMP - Project Management certification based on the PMBOK. PRINCE2 - Alternative project management methodology.

External links
Library of PMI Global Standards: Projects [3] PMBOK Guide Fourth Edition Changes [4] Project Management Resources [5] (includes link to PMBOK 1996]

References
[1] Chapter 1.1, 4th edition [2] A Guide to the Project Management Body of Knowledge, copyright page, edition 2 ISBN 1-880410-12-5 (free .pdf edition), and edition 3 2004 ISBN 1-930699-45-8, and edition 4 2008 ISBN 1933890517 [3] http:/ / www. pmi. org/ Resources/ Pages/ Library-of-PMI-Global-Standards-projects. aspx [4] http:/ / www. pmhut. com/ pmbok%c2%ae-guide-%e2%80%93-fourth-edition-changes [5] http:/ / www. tks. buffalo. edu/ pm/

Capability Maturity Model

The Capability Maturity Model (CMM) is a service mark owned by Carnegie Mellon University (CMU) and refers to a development model elicited from actual data. The data was collected from organizations that contracted with the U.S. Department of Defense, who funded the research, and they became the foundation from which CMU created the Software Engineering Institute (SEI). Like any model, it is an abstraction of an existing system. Unlike many that are derived in academia, this model is based on observation rather than on theory . When it is applied to an existing organization's software development processes, it allows an effective approach toward improving them. Eventually it became clear that the model could be applied to other processes. This gave rise to a more general concept that is applied to business processes and to developing people.

Overview
The Capability Maturity Model (CMM) was originally developed as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project. The CMM is based on the process maturity framework first described in the 1989 book Managing the Software Process by Watts Humphrey. It was later published in a report in 1993 (Technical Report CMU/SEI-93-TR-024 ESC-TR-93-177 February 1993, Capability Maturity Model SM for Software, Version 1.1) and as a book by the same authors in 1995. Though the CMM comes from the field of software development, it is used as a general model to aid in improving organizational business processes in diverse areas; for example in software engineering, system engineering, project management, software maintenance, risk management, system acquisition, information technology (IT), services, business processes generally, and human capital management. The CMM has been used extensively worldwide in government, commerce, industry and software development organizations.

Capability Maturity Model

216

CMM-rated organizations
An organization may be assessed by an SEI-Authorized Lead Appraiser, and will then be able to claim that they have been assessed as CMM level X, where X is from 1 to 5. Although sometimes called CMM-certification, the SEI doesn't use this term due to certain legal implications. The SEI maintains a list[1] of organizations assessed for CMM since 2006. Many India & Pakistan-based software offshoring companies were amongst the first organizations to receive the highest CMM rating.

History
The need for software processes prior to CMM
In the 1970s the use of computers became more widespread, flexible and less expensive. Organizations began to adopt computerized information systems, and the demand for software development grew significantly. The processes for software development were in their infancy, with few standard or "best practice" approaches defined. As a result, the growth was accompanied by growing pains: project failure was common, and the field of computer science was still in its infancy, and the ambitions for project scale and complexity exceeded the market capability to deliver. Individuals such as Edward Yourdon, Larry Constantine, Gerald Weinberg, Tom DeMarco, and David Parnas began to publish articles and books with research results in an attempt to professionalize the software development process. In the 1980s, several US military projects involving software subcontractors ran over-budget and were completed much later than planned, if they were completed at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI.

Precursor to CMM
The Quality Management Maturity Grid was developed by Philip Crosby in his book "Quality Is Free".[2] Note that the first application of a staged maturity model to IT was not by CMM/SEI, but rather by Richard L. Nolan, who, in 1973 published the Stages of growth model for IT organizations.[3] Watts Humphrey began developing his process maturity concepts during the later stages of his 27 year career at IBM. (References needed)

The development of CMM at SEI

Active development of the model by the US Department of Defense Software Engineering Institute (SEI) began in 1986 when Humphrey joined the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania after retiring from IBM. At the request of the U.S. Air Force he began formalizing his Process Maturity Framework to aid the U.S. Department of Defense in evaluating the capability of software contractors as part of awarding contracts. The result of the Air Force study was a model for the military to use as an objective evaluation of software subcontractors' process capability maturity. Humphrey based this framework on the earlier Quality Management Maturity Grid developed by Philip B. Crosby in his book "Quality Is Free".[2] However, Humphrey's approach differed because of his unique insight that organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently. The CMM has thus been used by different organizations as a general and powerful tool for understanding and then improving general business process performance.

Capability Maturity Model Watts Humphrey's Capability Maturity Model (CMM) was published in 1988[4] and as a book in 1989, in Managing the Software Process.[5] Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the Software Engineering Institute (SEI). The full representation of the Capability Maturity Model as a collection of defined process areas and practices at each of the five maturity levels was initiated in 1991, with Version 1.1 being completed in January 1993.[6] The CMM was published as a book[7] in 1995 by its primary authors, Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis.

217

CMM is superseded by CMMI

The CMM model proved useful to many organizations, but its application in software development has sometimes been problematic. Applying multiple models that are not integrated within and across an organization could be costly in terms of training, appraisals, and improvement activities. The Capability Maturity Model Integration (CMMI) project was formed to sort out the problem of using multiple CMMs. For software development processes, the CMM has been superseded by Capability Maturity Model Integration (CMMI), though the CMM continues to be a general theoretical process capability model used in the public domain.

CMM is adapted to processes other than software development

The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. Though it comes from the area of software development, it can be, has been, and continues to be widely applied as a general model of the maturity of processes (e.g., IT Service Management processes) in IS/IT (and other) organizations.

Capability Maturity Model topics

Maturity model
A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example : a place to start the benefit of a communitys prior experiences a common language and a shared vision a framework for prioritizing actions a way to define what improvement means for your organization.

A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes.

Capability Maturity Model

218

Capability Maturity Model structure

The Capability Maturity Model involves the following aspects: Maturity Levels: a 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement. Key Process Areas: a Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important. Goals: the goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area. Common Features: common features include practices that implement and institutionalize a key process area. There are five types of common features: commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation. Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.

Levels of the Capability Maturity Model

There are five levels defined along the continuum of the CMM[8] and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief." 1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process. 2. Managed - the process is managed according to the metrics described in the Defined stage. 3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). 4. Quantitatively managed 5. Optimized - process management includes deliberate process optimization/improvement. Within each of these maturity levels are Key Process Areas (KPAs) which characterise that level, and for each KPA there are five definitions identified: 1. 2. 3. 4. 5. Goals Commitment Ability Measurement Verification

The KPAs are not necessarily unique to CMM, representing as they do the stages that organizations must go through on the way to becoming mature. The CMM provides a theoretical continuum along which process maturity can be developed incrementally from one level to the next. Skipping levels is not allowed/feasible. N.B.: The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. It has been used for and may be suited to that purpose, but critics pointed out that process maturity according to the CMM was not necessarily mandatory for successful software development. There were/are real-life examples where the CMM was arguably irrelevant to successful software development, and these examples include many Shrinkwrap companies (also called commercial-off-the-shelf or "COTS" firms or software package firms). Such firms would have included, for example, Claris, Apple, Symantec, Microsoft, and Lotus. Though these companies may have successfully developed their software, they would not necessarily have

Capability Maturity Model considered or defined or managed their processes as the CMM described as level 3 or above, and so would have fitted level 1 or 2 of the model. This did not - on the face of it - frustrate the successful development of their software. Level 1 - Initial (Chaotic) It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes. Level 2 - Repeatable It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress. Level 3 - Defined It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Level 4 - Managed It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level. Level 5 - Optimized It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements. At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.

219

Software process framework for SEI's Capability Maturity Model

The software process framework documented is intended to guide those wishing to assess an organization/projects consistency with the CMM. For each maturity level there are five checklist types:
TypeSD Policy Standard Description Describes the policy contents and KPA goals recommended by the CMM. Describes the recommended content of select work products described in the CMM.

Capability Maturity Model

220

Process

Describes the process information content recommended by the CMM. The process checklists are further refined into checklists for: roles entry criteria inputs activities outputs exit criteria reviews and audits work products managed and controlled measurements documented procedures training tools

Procedure Level overview

Describes the recommended content of documented procedures described in the CMM. Provides an overview of an entire maturity level. The level overview checklists are further refined into checklists for: KPA purposes (Key Process Areas) KPA Goals policies standards process descriptions procedures training tools reviews and audits work products managed and controlled measurements

See also
Testing Maturity Model People Capability Maturity Model Capability Maturity Model Integration

External links
Official website [9] Capability Maturity Model [24] at the Open Directory Project

References
[1] "Published Appraisal Results" (http:/ / sas. sei. cmu. edu/ pars/ pars. aspx). SEI. . Retrieved 2009-11-26. [2] Crosby, Philip (1979). Quality is Free. McGraw Hill. ISBN0451622472. [3] Nolan, Richard (July 1973). "Managing the computer resource: a stage hypothesis" (http:/ / portal. acm. org/ citation. cfm?id=362284). Communications of the ACM (Association for Computing Machinery) 16 (7): 399405. doi:10.1145/362280.362284. . [4] Humphrey, Watts (March 1988). "Characterizing the software process: a maturity framework". IEEE Software 5 (2): 7379. doi:10.1109/52.2014. [5] Humphrey, Watts (1989). Managing the Software Process. Addison Wesley. ISBN0201180952. [6] Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (February 1993). "Capability Maturity ModelSM for Software, Version 1.1". Technical Report (Carnegie Mellon University / Software Engineering Institute). CMU/SEI-93-TR-024 ESC-TR-93-177. [7] Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. Boston: Addison Wesley. ISBN0201546647. [8] ( March 2002 edition of CMMI from SEI (http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 02tr012. cfm)), chapter 2 page 11.) [9] http:/ / www. sei. cmu. edu/ cmmi/ start/

ISO 9000

221

ISO 9000
ISO 9000 is a family of standards for quality management systems. ISO 9000 is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies. The rules are updated, as the requirements motivate changes over time. Some of the requirements in ISO 9001:2008 (which is one of the standards in the ISO 9000 family) include a set of procedures that cover all key processes in the business; monitoring processes to ensure they are effective; keeping adequate records; checking output for defects, with appropriate and corrective action where necessary; regularly reviewing individual processes and the quality system itself for effectiveness; and facilitating continual improvement

A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9001 standard does not guarantee any quality of end products and services; rather, it certifies that formalized business processes are being applied. Although the standards originated in manufacturing, they are now employed across several types of organizations. A "product", in ISO vocabulary, can mean a physical object, services, or software.

Contents of ISO 9001

ISO 9001:2008 Quality management systems Requirements is a document of approximately 30 pages which is available from the national standards organization in each country. Outline contents are as follows:. Page iv: Foreword Pages v to vii: Section 0 Intro Pages 1 to 14: Requirements Section 1: Scope Section 2: Normative Reference Section 3: Terms and definitions (specific to ISO 9001, not specified in ISO 9000) Pages 2 to 14 132 1 Section 4: Quality Management System Section 5: Management Responsibility Section 6: Resource Management Section 7: Product Realization Section 8: Measurement, analysis and improvement In effect, users need to address all sections 1 to 8, but only 4 to 8 need implementing within a QMS. Pages 15 to 22: Tables of Correspondence between ISO 9001 and other standards Page 23: Bibliography The standard specifies six compulsory documents: Control of Documents (4.2.3) Control of Records (4.2.4) Internal Audits (8.2.2)

ISO 9001 certification of a fish wholesaler in Tsukiji

ISO 9000 Control of Nonconforming Product / Service (8.3) Corrective Action (8.5.2) Preventive Action (8.5.3) In addition to these, ISO 9001:2008 requires a Quality Policy and Quality Manual (which may or may not include the above documents). ===Summary of ISO 9001:2008 === The quality policy is a formal statement from management, closely linked to the business and marketing plan and to customer needs. The quality policy is understood and followed at all levels and by all employees. Each employee needs measurable objectives to work towards. Decisions about the quality system are made based on recorded data and the system is regularly audited and evaluated for conformance and effectiveness. Records should show how and where raw materials and products were processed, to allow products and problems to be traced to the source. You need to determine customer requirements and create systems for communicating with customers about product information, inquiries, contracts, orders, feedback and complaints. When developing new products, you need to plan the stages of development, with appropriate testing at each stage. You need to test and document whether the product meets design requirements, regulatory requirements and user needs. You need to regularly review performance through internal audits and meetings. Determine whether the quality system is working and what improvements can be made. Deal with past problems and potential problems. Keep records of these activities and the resulting decisions, and monitor their effectiveness (note: you need a documented procedure for internal audits). You need documented procedures for dealing with actual and potential nonconformances (problems involving suppliers or customers, or internal problems). Make sure no one uses bad product, determine what to do with bad product, deal with the root cause of the problem seeking and keep records to use as a tool to improve the system. Practical Guide to Implementing ISO 9001:2008 [1]'

222

1.0 Scope
(Company Name) has developed and implemented this quality management system to demonstrate its ability to consistently provide product that meets customer and statutory and regulatory requirements, and to address customer satisfaction through the effective application of the system, including continual improvement and the prevention of nonconformity. (Company Name) has excluded section 7.3 Design and Development from the applicable requirements of ISO 9001:2008, due to the nature of (Company Name) and its products. All principal product characteristics are specified by the customers or their consultants. This exclusion does not affect (Company Name)s ability, or responsibility, to provide product that meets customer and applicable statutory and regulatory requirements.

2.0 Normative reference

The normative document contains provisions which, through reference in this text, constitute provisions of ISO 9001:2008. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on ISO 9001:2008 are encouraged to investigate the possibility of applying the most recent edition of the normative document indicated below. For undated references, the latest edition of the normative document referred to applies. ISO 9000: 2005 Quality Management System Fundamentals and Vocabulary.

ISO 9000

223

3.0 Terms and definitions

Supplier and Vendor are synonymous and refer to the external source used to acquire purchased products by (Company Name).

4.0 Quality management system

4.1 General requirements: The Company documents, implements, and maintains a quality management system and continually improves its effectiveness in accordance with the requirements of the ISO 9001:2008 International Standard. (BBS Holdings Limited):that comprises of; . Guard Dog Security Services Ltd a) determines the processes needed for the quality management system and their application throughout (Company Name), b) determines the sequence and interaction of these processes, c) determines criteria and methods needed to ensure that both the operation and control of these processes are effective, d) ensures the availability of resources and information necessary to support the operation and monitoring of these processes, e) monitors, measures where applicable and analyzes these processes, f) implements actions necessary to achieve planned results and continual improvement of these processes. These processes are managed by (Company Name) in accordance with the requirements of the ISO 9001:2008 International Standard. Where (Company Name) chooses to outsource any process that affects product conformity with requirements, (Company Name) ensures control over such processes. The type and extent of control of such outsourced processes are identified within the quality management system. NOTE: Processes needed for the quality management system referred to above include processes for management activities, provision of resources, product realization, measurement, analysis, and improvement. 4.2 Documentation requirements 4.2.1 General The quality management system documentation includes: a) documented statements of a quality policy and quality objectives, b) a quality manual, c) documented procedures and records required by the ISO 9001:2008 International Standard, and d) documents, including records determined by (Company Name) to be necessary to ensure the effective planning, operation and control of its processes NOTE 1: Where the term documented procedure appears within the ISO 9001:2008 International Standard, means that a procedure is established, documented, implemented and maintained. NOTE 2: Documentation can be in any form or type of medium. 4.2.2 Quality manual (Company Name) establishes and maintains a quality manual that includes a) the scope of the quality management system, including details of and justification for any exclusions, b) the documented procedures established for the quality management system, or reference to them, and c) a description of the interaction between the processes of the quality management system. 4.2.3 Control of documents Documents required by the quality management system are controlled. Records required by the quality management system are controlled according to the requirements given in 4.2.4. A documented procedure is established to define the controls needed: a) to approve documents for adequacy prior to issue, b) to review and update as necessary and re-approve documents,

ISO 9000 c) to ensure that changes and the current revision status of documents are identified, d) to ensure that relevant versions of applicable documents are available at points of use, e) to ensure that documents remain legible and readily identifiable, f) to ensure that documents of external origin determined by the organization to be necessary for the planning and operation of the quality management system are identified and their distribution controlled, and g) to prevent the unintended use of obsolete documents, and to apply suitable identification to them if they are retained for any purpose. Supporting Documentation QOP-42-01 Control of Documents 4.2.4 Control of records Records established to provide evidence of conformity to requirements and or the effective operation of the quality management system shall be controlled. (Company Name) will establish a documented procedure to define the controls needed for the identification, storage, protection, retrieval, retention time and disposition of records. Records will remain legible, readily identifiable, and retrievable. Supporting Documentation QOP-42-02 Control of Records

224

5.0 Management responsibility

5.1 Management commitment Top management is committed to the development and implementation of the quality management system and continually improves its effectiveness by: a) communicating to (Company Name) the importance of meeting customer as well as statutory and regulatory requirements, b) establishing a quality policy, c) establishing quality objectives, d) conducting management reviews, and e) ensuring the availability of resources. 5.2 Customer focus Top management ensures that customer requirements are determined and are met with the aim of enhancing customer satisfaction. (see 7.2.1 and 8.2.1) 5.3 Quality policy (Company Name) is committed to Exceeding Customer Expectations through Implementation and Continuous Improvement of our Quality Management System. Absolute Customer Satisfaction is the expectation and, will be achieved through supplying a Superior Product, On-time, at a Competitive Price. Top management ensures that the quality policy a) is appropriate to the purpose of the quality policy, b) includes a commitment to comply with requirements and continually improve the effectiveness of the quality management system, c) provides a framework for establishing and reviewing quality objectives, d) is communicated and understood within (Company Name), and e) is reviewed for continuing suitability. 5.4 Planning 5.4.1 Quality objectives Top management ensures that quality objectives, including those needed to meet requirements for product [see 7.1 a], are established at relevant functions and levels within (Company Name). The quality objectives are measurable and consistent with the quality policy. 1. Meet or exceed customer expectations by effective communication and review of customer requirements. 2. Provide our customers high quality products and services, on time delivery, and at a reasonable cost. 3. Effectively manage our products, processes, and services to provide superior customer satisfaction. 4. Promote the safety, awareness, and well being of employees through training and education. 5.4.2 Quality management system planning Top management ensures that: a) the planning of the quality management system is carried out in order to meet the requirements given in 4.1, as well as the quality objectives, and b) the integrity of the quality management system is maintained when changes to the quality management system are planned and implemented. 5.5 Responsibility, authority and communication

ISO 9000 5.5.1 Responsibility and authority Top management ensures that responsibilities and authorities are defined and communicated within (Company Name) to promote effective management of the quality system. An Organizational Chart illustrates the responsibility and relative authority of the personnel who manage, perform, and verify the activities affecting the QMS. Changes to the quality system are planned within the framework of management reviews. These changes may be in response to changing circumstances, such as product, process, capacity, or other operational or organizational changes; or to improve the effectiveness and efficiency of the quality system. Supporting Documentation Organizational Chart 5.5.2 Management representative Top management has appointed a member of the organizations management who, irrespective of other responsibilities, has the responsibility and authority that includes a) ensuring that processes needed for the quality management system are established, implemented and maintained, b) reporting to top management on the performance of the quality management system and any need for improvement, and c) ensuring the promotion of awareness of customer requirements throughout (Company Name). NOTE The responsibility of a management representative can include liaison with external parties on matters relating to the quality management system. 5.5.3 Internal communication Top management ensures that appropriate communication processes are established within (Company Name) and that communication takes place regarding the effectiveness of the quality management system. 5.6 Management Review 5.6.1 General Top management reviews (Company Name)s quality management system, at planned intervals, to ensure its continuing suitability, adequacy and effectiveness. The review includes assessing opportunities for improvement and the need for changes to the quality management system, including the quality policy and quality objectives. Records from management reviews are maintained (see 4.2.4). Supporting Documentation QOP-56-01 Management Review 5.6.2 Review input The input to management review includes information on: a) results of audits, b) customer feedback, c) process performance and product conformity, d) status of preventive and corrective actions, e) follow-up actions from previous management reviews, f) changes that could affect the quality management system, and g) recommendations for improvement. 5.6.3 Review output The output from the management review includes any decisions and actions related to: a) improvement of the effectiveness of the quality management system and its processes, b) improvement of product related to customer requirements, and c) resource needs.

225

6.0 Resource management

6.1 Provision of resources (Company Name) determines and provides the resources needed a) to implement and maintain the quality management system and continually improve its effectiveness, and b) to enhance customer satisfaction by meeting customer requirements. 6.2 Human resources 6.2.1 General Personnel performing work affecting conformity to product requirements are competent on the basis of appropriate education, training, skills and experience. 6.2.2 Competence, training, and awareness (Company Name) : a) determines the necessary competence for personnel performing work affecting conformity to product requirements, b) where applicable, provides training or takes other actions to achieve the necessary competence, c) evaluates the effectiveness of the actions taken, d) ensures that its personnel are aware of the relevance and importance of their activities and how they contribute to the achievement of the quality objectives, and e) maintains appropriate records of education, training, skills and experience (see 4.2.4). Supporting Documentation QOP-62-01 Competence, Training, and Awareness

ISO 9000 6.3 Infrastructure (Company Name) determines, provides for, and maintains the infrastructure needed to achieve conformity to product requirements. Infrastructure includes, as applicable: a) buildings, workspace and associated utilities, b) Process equipment (both hardware and software), and c) Supporting services (such as transport, communication or information systems). Supporting Documentation QOP-63-01 Equipment Maintenance 6.4 Work environment (Company Name) determines and manages the work environment needed to achieve conformity to product requirements.

226

7.0 Product realization

7.1 Planning of product realization (Company Name) plans and develops the processes needed for product realization. Planning of product realization is consistent with the requirements of the other processes of the quality management system (see 4.1). In planning product realization, (Company Name) determines the following, as appropriate: a) quality objectives and requirements for the product, b) the need to establish processes, and documents, and provide resources specific to the product, c) required verification, validation, monitoring, measurement, inspection and test activities specific to the product and the criteria for product acceptance, and d) records needed to provide evidence that the realization processes and resulting product meet requirements (see 4.2.4). The output of the planning is in a form suitable for (Company Name)s method of operations. NOTE 1 A document specifying the processes of the quality management system (including the product realization processes) and the resources to be applied to a specific product, project or contract, is referred to as the quality plan. NOTE 2 (Company Name) also applies the requirements given in 7.3 to the development of product realization processes. Supporting Documentation QOP-71-01 Planning of Product Realization 7.2 Customer- related processes 7.2.1 Determination of requirements related to the product (Company Name) determines: a) requirements specified by the customer, including the requirements for delivery and post-delivery activities, b) requirements not stated by the customer but necessary for specified or intended use, where known, c) statutory and regulatory requirements applicable to the product, and d) any additional requirements considered necessary by (Company Name). Supporting Documentation QOP-72-02 Order Processing & Review 7.2.2 Review of requirements related to the product (Company Name) reviews the requirements related to the product. This review is conducted prior to (Company Name)s commitment to supply a product to the customer (e.g. submission of tenders, acceptance of contracts or orders, acceptance of changes to contracts or orders) and ensures that: a) product requirements are defined, b) contract or order requirements differing from those previously expressed are resolved, and c) (Company Name) has the ability to meet the defined requirements. Records of the results of the review and actions arising from the review are maintained (see 4.2.4). Where the customer provides no documented statement of requirement, the customer requirements are confirmed by (Company Name) before acceptance. Where product requirements are changed, (Company Name) ensures that relevant documents are amended and that relevant personnel are made aware of the changed requirements.

ISO 9000 NOTE In some situations, a formal review is impractical for each order. Instead the review can cover relevant product information such as catalogues or advertising material. Supporting Documentation QOP-72-02 Order Processing & Review 7.2.3 Customer communication (Company Name) determines and implements effective arrangements for communicating with customers in relation to: a) product information, b) enquiries, contracts or order handling, including amendments, and c) customer feedback, including customer complaints. Supporting Documentation QOP-72-02 Order Processing & Review QOP-85-02 Customer Complaints 7.3 Design and development Excluded (See 1.0 Scope) 7.4 Purchasing 7.4.1 Purchasing process (Company Name) ensures that purchased product conforms to specified purchase requirements. The type and extent of control applied to the supplier and the purchased product is dependent upon the effect of the purchased product on subsequent product realization or the final product. Supporting Documentation QOP-74-01 Purchasing 7.4.2 Purchasing Information Purchasing information describes the product to be purchased, including where appropriate a) requirements for approval of product, procedures, processes and equipment, b) requirements for qualification of personnel, and c) quality management system requirements. (Company Name) ensures the adequacy of specified purchase requirements prior to their communication to the supplier. Supporting Documentation QOP-74-01 Purchasing 7.4.3. Verification of purchased product (Company Name) establishes and implements the inspection or other activities necessary for ensuring that purchased product meets specified purchase requirements. Where (Company Name) or its customer intends to perform verification at the suppliers premises, (Company Name) states the intended verification arrangements and method of product release in the purchasing information. Supporting Documentation QOP-74-02 Verification of Purchase Product 7.5 Production and service provision 7.5.1 Control of production and service provision As applicable, (Company Name) plans and carries out production and service provisions under controlled conditions. Controlled conditions include: a) the availability of information that describes the characteristics of the product, b) the availability of work instructions, as necessary, c) the use of suitable equipment, d) the availability and use of monitoring and measuring equipment,

227

ISO 9000 e) the implementation of monitoring and measurement activities, and f) the implementation of product release, delivery and post-delivery activities. Supporting Documentation QOP-75-01 Work Order and Production Records QOP-63-01 Equipment Maintenance QOP-76-01 Measuring and Monitoring Equipment QOP-84-02 Final Inspection QOP-75-06 Shipping 7.5.2 Validation of processes for production and service provision (Company Name) validates any processes for production and service provisions where the resulting output cannot be verified by subsequent monitoring or measurement and, as a consequence, deficiencies become apparent only after the product is in use or the service has been delivered. Validation demonstrates the ability of these processes to achieve planned results. As applicable, (Company Name) establishes arrangements for these processes including: a) defined criteria for review and approval of the processes, b) approval of equipment and qualification of personnel, c) use of specific methods and procedures, d) requirements for records (see 4.2.4), and e) revalidation. Note: (Company Name) has no Special Processes at this time. 7.5.3 Identification and traceability Where appropriate, (Company Name) identifies the product by suitable means throughout product realization. (Company Name) identifies the product status with respect to monitoring and measurement requirements throughout product realization. Where traceability is a requirement, (Company Name) controls the unique identification of the product an maintain records (4.2.4). Supporting Documentation QOP-75-04 Product Identification and Traceability 7.5.4 Customer property (Company Name) exercises care with customer property while it is under (Company Name)s control or being used by (Company Name). (Company Name) identifies, verifies, protects and safeguards customer property provided for use or incorporation into the product. If any customer property is lost, damaged or otherwise found to be unsuitable for use, (Company Name) will report this to the customer and maintain records (see 4.2.4). Note: Customer property can include intellectual property and personal date. Note: (Company Name) has no Customer Property at this time. 7.5.5 Preservation of product (Company Name) preserves the product during internal processing and delivery to the intended destination in order to maintain conformity to requirements. As applicable, preservation includes identification, handling, packaging, storage and protection. Preservation also applies to the constituent parts of a product. 7.6 Control of monitoring and measuring equipment (Company Name) determines the monitoring and measurement to be undertaken and the monitoring and measuring equipment needed to provide evidence of conformity of product to determined requirements. (Company Name) establishes processes to ensure that monitoring and measurement can be carried out, and is carried out in a manner that is consistent with the monitoring and measurement requirements. Where necessary to ensure valid results measuring equipment is: a)calibrated, verified or both at specified intervals, or prior to use, against measurement standards traceable to international or national measurement standards; where no such standards exist, the basis used for calibration or

228

ISO 9000 verification shall be recorded, b)adjusted or re-adjusted as necessary, c)have identification in order to determine its calibration status, d)safeguarded from adjustments that would invalidate the measurement result, and e)protected from damage and deterioration during handling, maintenance and storage. In addition, (Company Name) assesses and records the validity of the previous measuring results when the equipment is found not to conform to requirements. (Company Name) takes appropriate action on the equipment and any product affected. Records of the results of calibration and verification are maintained (see 4.2.4). Note: Confirmation of the ability of computer software to satisfy the intended application will typically include its verification and configuration management to maintain its suitability for use Supporting Documentation QOP-76-01 Monitoring and Measuring Equipment

229

8.0 Measurement, analysis and improvement

8.1 General (Company Name) plans and implements the monitoring, measurement, analysis and improvement processes needed: a)to demonstrate conformity to product requirements, b)to ensure conformity of the quality management system, and c)to continually improve the effectiveness of the quality management system. This includes determination of applicable methods, including statistical techniques, and the extent of their use. 8.2 Monitoring and measurement 8.2.1 Customer satisfaction As one of the measurements of the performance of the quality management system, (Company Name) monitors information relating to customer perception as to whether (Company Name) has met customer requirements. The methods for obtaining and using this information are determined. Supporting Documentation QOP-82-01 Customer Satisfaction 8.2.2 Internal Audits (Company Name) conducts internal audits at planned intervals to determine whether the quality management system: a)conforms to the planned arrangements (see 7.1), to the requirements of ISO 9001:2008 and to the quality management system requirements established by (Company Name), and b)is effectively implemented and maintained. An audit program is planned, taking into consideration the status and importance of the processes and areas to be audited, as well as the results of previous audits. The audit criteria, scope, frequency and methods are defined. The selection of auditors and conduct of audits ensure objectivity and impartiality of the audit process. Auditors do not audit their own work. The responsibilities and requirements for planning and conducting audits, and for reporting results and maintaining records (see 4.2.4) are defined in a documented procedure. The management responsible for the area being audited ensures that any necessary correction and corrective actions are taken without undue delay to eliminate detected nonconformities and their causes. Follow-up activities include the verification of the actions taken and the reporting of verification results (see 8.5.2). Supporting Documentation QOP-82-02 Internal Quality Audits 8.2.3 Monitoring and measurement of processes (Company Name) applies suitable methods for monitoring and where applicable, measurement of the quality management system processes. These methods demonstrate the ability of the processes to achieve planned results. When planned results are not achieved, correction and corrective action is taken, as appropriate. 8.2.4 Monitoring and measurement of product (Company Name) monitors and measures the characteristics of the product to verify that product requirements have been met. This is carried out at appropriate stages of the product realization process in accordance with the planned arrangements (see 7.1). Evidence of conformity with the acceptance criteria is maintained. Records indicate the person(s) authorizing release of product for delivery to the customer (see 4.2.4). The release of product and delivery of service to the customer does not proceed until the planned arrangements (see 7.1) have been satisfactorily completed, unless otherwise approved by a relevant authority and where applicable, by the customer. Supporting Documentation QOP-82-03 In Process Inspections QOP-82-04 Final Inspection

ISO 9000 8.3 Control of nonconforming product (Company Name) ensures that product which does not conform to product requirements is identified and controlled to prevent its unintended use or delivery. A documented procedure is established to define the controls and related responsibilities and authorities for dealing with nonconforming products. Where applicable (Company Name) deals with nonconforming product by one or more of the following ways: a)by taking action to eliminate the detected nonconformity, b)by authorizing its use, release or acceptance under concession by a relevant authority and, where applicable, by the customer, and c)by taking action to preclude its original intended use or application. d)by taking action appropriate to the effects, or potential effects, of the nonconformity when nonconforming product is detected after delivery or use has started. When nonconforming product is corrected the product is subject to re-verification to demonstrate conformity to the requirements. When nonconforming product is detected after delivery or use has started, (Company Name) takes action appropriate to the effects, or potential effects, of the nonconformity. Records of the nature of nonconformities and any subsequent actions taken, including concessions obtained, are maintained (see 4.2.4). Supporting Documentation QOP-83-01 Control of Nonconforming Product 8.4 Analysis of data (Company Name) determines, collects and analyzes appropriate data to demonstrate the suitability and effectiveness of the quality management system and to evaluate where continual improvement of the effectiveness of the quality management system can be made. This includes data generated as a result of monitoring and measurement and from other relevant sources. The analysis of data provides information relating to: a)customer satisfaction (see 8.2.1), b)conformity to product requirements (see 8.2.4), c)characteristics and trends of processes and products including opportunities for preventive action (see 8.2.3 and 8.2.4), d)suppliers (see 7.4), Supporting Documentation QOP-56-01 Management Review 8.5 Improvement 8.5.1 Continual improvement (Company Name) continually improves the effectiveness of the quality management system through the use of the quality policy, quality objectives, audit results, analysis of data, corrective and preventive actions and management reviews. Supporting Documentation QOP-85-01 Continual Improvement 8.5.2 Corrective action (Company Name) takes action to eliminate the causes of nonconformities in order to prevent recurrence. Corrective actions are appropriate to the effects of the nonconformities encountered. A documented procedure is established to define requirements for: a) reviewing nonconformities (including customer complaints), b) determining the causes of nonconformities, c) evaluating the need for action to ensure that nonconformities do not recur, d) determining and implementing action needed, e) records of the results of action taken (see 4.2.4), and f) reviewing the effectiveness of the corrective action taken. Supporting Documentation QOP-85-02 Customer Complaints QOP-85-03 Corrective and Preventive Actions 8.5.3 Preventive action (Company Name) determines actions to eliminate the causes of potential nonconformities in order to prevent their occurrence. Preventive actions are appropriate to the effects of the potential problems. A documented procedure is established to define requirements for: a) determining potential nonconformities and their causes, b) evaluating the need for action to prevent occurrence of nonconformities, c) determining and implementing action needed, d) records of results of action taken (see 4.2.4), and e) reviewing the effectiveness of the preventive action taken. Supporting Documentation QOP-85-03 Corrective and Preventive Actions

230

ISO 9000

231

1987 version
ISO 9000:1987 had the same structure as the UK Standard BS 5750, with three 'models' for quality management systems, the selection of which was based on the scope of activities of the organization: ISO 9001:1987 Model for quality assurance in design, development, production, installation, and servicing was for companies and organizations whose activities included the creation of new products. ISO 9002:1987 Model for quality assurance in production, installation, and servicing had basically the same material as ISO 9001 but without covering the creation of new products. ISO 9003:1987 Model for quality assurance in final inspection and test covered only the final inspection of finished product, with no concern for how the product was produced. ISO 9000:1987 was also influenced by existing U.S. and other Defense Standards ("MIL SPECS"), and so was well-suited to manufacturing. The emphasis tended to be placed on conformance with procedures rather than the overall process of managementwhich was likely the actual intent.

1994 version
ISO 9000:1994 emphasized quality assurance via preventive actions, instead of just checking final product, and continued to require evidence of compliance with documented procedures. As with the first edition, the down-side was that companies tended to implement its requirements by creating shelf-loads of procedure manuals, and becoming burdened with an ISO bureaucracy. In some companies, adapting and improving processes could actually be impeded by the quality system.

2000 version
ISO 9001:2000 combines the three standards 9001, 9002, and 9003 into one, called 9001. Design and development procedures are required only if a company does in fact engage in the creation of new products. The 2000 version sought to make a radical change in thinking by actually placing the concept of process management front and center ("Process management" was the monitoring and optimizing of a company's tasks and activities, instead of just inspecting the final product). The 2000 version also demands involvement by upper executives, in order to integrate quality into the business system and avoid delegation of quality functions to junior administrators. Another goal is to improve effectiveness via process performance metrics numerical measurement of the effectiveness of tasks and activities. Expectations of continual process improvement and tracking customer satisfaction were made explicit. The ISO 9000 standard is continually being revised by standing technical committees and advisory groups, who receive feedback from those professionals who are implementing the standard.[2] ISO 9001:2008 only introduces clarifications to the existing requirements of ISO 9001:2000 and some changes intended to improve consistency with ISO 14001:2004. There are no new requirements. Explanation of changes in ISO 9001:2008. A quality management system being upgraded just needs to be checked to see if it is following the clarifications introduced in the amended version. ISO Registrar for ISO 9001:2008 [3]

Certification
ISO does not itself certify organizations. Many countries have formed accreditation bodies to authorize certification bodies, which audit organizations applying for ISO 9001 compliance certification. Although commonly referred to as ISO 9000:2000 certification, the actual standard to which an organization's quality management can be certified is ISO 9001:2008. Both the accreditation bodies and the certification bodies charge fees for their services. The various accreditation bodies have mutual agreements with each other to ensure that certificates issued by one of the Accredited Certification Bodies (CB) are accepted worldwide. The applying organization is assessed based on an extensive sample of its sites, functions, products, services and processes; a list of problems ("action requests" or "non-compliance") is made known to the management. If there are

ISO 9000 no major problems on this list, or after it receives a satisfactory improvement plan from the management showing how any problems will be resolved, the certification body will issue an ISO 9001 certificate for each geographical site it has visited. An ISO certificate is not a once-and-for-all award, but must be renewed at regular intervals recommended by the certification body, usually around three years. In contrast to the Capability Maturity Model there are no grades of competence within ISO 9001. Marlin (USF)

232

Auditing
Two types of auditing are required to become registered to the standard: auditing by an external certification body (external audit) and audits by internal staff trained for this process (internal audits). The aim is a continual process of review and assessment, to verify that the system is working as it's supposed to, find out where it can improve and to correct or prevent problems identified. It is considered healthier for internal auditors to audit outside their usual management line, so as to bring a degree of independence to their judgments. Under the 1994 standard, the auditing process could be adequately addressed by performing "compliance auditing": Tell me what you do (describe the business process) Show me where it says that (reference the procedure manuals) Prove that this is what happened (exhibit evidence in documented records) The 2000 standard uses a different approach. Auditors are expected to go beyond mere auditing for rote "compliance" by focusing on risk, status and importance. This means they are expected to make more judgments on what is effective, rather than merely adhering to what is formally prescribed. The difference from the previous standard can be explained thus: Under the 1994 version, the question was broadly "Are you doing what the manual says you should be doing?", whereas under the 2000 version, the question is more "Will this process help you achieve your stated objectives? Is it a good process or is there a way to do it better?"

Industry-specific interpretations
The ISO 9001 standard is generalized and abstract. Its parts must be carefully interpreted, to make sense within a particular organization. Developing software is not like making cheese or offering counseling services; yet the ISO 9001 guidelines, because they are business management guidelines, can be applied to each of these. Diverse organizationspolice departments (US), professional soccer teams (Mexico) and city councils (UK)have successfully implemented ISO 9001:2000 systems. Over time, various industry sectors have wanted to standardize their interpretations of the guidelines within their own marketplace. This is partly to ensure that their versions of ISO 9000 have their specific requirements, but also to try and ensure that more appropriately trained and experienced auditors are sent to assess them. The TickIT guidelines are an interpretation of ISO 9000 produced by the UK Board of Trade to suit the processes of the information technology industry, especially software development. AS9000 is the Aerospace Basic Quality System Standard, an interpretation developed by major aerospace manufacturers. Those major manufacturers include AlliedSignal, Allison Engine, Boeing, General Electric Aircraft Engines, Lockheed-Martin, McDonnell Douglas, Northrop Grumman, Pratt & Whitney, Rockwell-Collins, Sikorsky Aircraft, and Sundstrand. The current version is AS9100. PS 9000 is an application of the standard for Pharmaceutical Packaging Materials. The Pharmaceutical Quality Group (PQG) of the Institute of Quality Assurance (IQA) has developed PS 9000:2001. It aims to provide a widely accepted baseline GMP framework of best practice within the pharmaceutical packaging supply industry. It applies ISO 9001: 2000 to pharmaceutical printed and contact packaging materials.

ISO 9000 QS 9000 is an interpretation agreed upon by major automotive manufacturers (GM, Ford, Chrysler). It includes techniques such as FMEA and APQP. QS 9000 is now replaced by ISO/TS 16949. ISO/TS 16949:2009 is an interpretation agreed upon by major automotive manufacturers (American and European manufacturers); the latest version is based on ISO 9001:2008. The emphasis on a process approach is stronger than in ISO 9001:2008. ISO/TS 16949:2009 contains the full text of ISO 9001:2008 and automotive industry-specific requirements. TL 9000 is the Telecom Quality Management and Measurement System Standard, an interpretation developed by the telecom consortium, QuEST Forum [4]. The current version is 4.0 and unlike ISO 9001 or the above sector standards, TL 9000 includes standardized product measurements that can be benchmarked. In 1998 QuEST Forum developed the TL 9000 Quality Management System to meet the supply chain quality requirements of the worldwide telecommunications industry. ISO 13485:2003 is the medical industry's equivalent of ISO 9001:2000. Whereas the standards it replaces were interpretations of how to apply ISO 9001 and ISO 9002 to medical devices, ISO 13485:2003 is a stand-alone standard. Compliance with ISO 13485 does not necessarily mean compliance with ISO 9001:2000. ISO/TS 29001 is quality management system requirements for the design, development, production, installation and service of products for the petroleum, petrochemical and natural gas industries. It is equivalent to API Spec Q1 without the Monogram annex.

233

Effectiveness
The debate on the effectiveness of ISO 9000 commonly centers on the following questions: 1. Are the quality principles in ISO 9001:2000 of value? (Note that the version date is important: in the 2000 version ISO attempted to address many concerns and criticisms of ISO 9000:1994). 2. Does it help to implement an ISO 9001:2000 compliant quality management system? 3. Does it help to obtain ISO 9001:2000 certification? Effectiveness of the ISO system being implemented depends on a number of factors, the most significant of which are: 1. Commitment of Senior Management to monitor, control, and improve quality. Organizations that implement an ISO system without this desire and commitment, often take the cheapest road to get a certificate on the wall and ignore problem areas uncovered in the audits. 2. How well the ISO system integrates into their business practices. Many organizations that implement ISO try to make their system fit into a cookie-cutter quality manual rather than create a manual the documents existing practices and only add new processes to meet the ISO standard when necessary. 3. How well the ISO system focuses on improving the customer experience. The broadest definition of quality is "Whatever the customer perceives good quality to be". This means that you don't necessarily have to make a product that never fails, some customers will have a higher tolerance for product failures if they always receive shipments on-time, or some other dimension of customer service. Your ISO system should take into account all areas of the customer experience, the industry expectations, and seek to improve them on a continual basis. This means taking into account all processes that deal with the three stakeholders (your customers, your suppliers, and your organization), only then will you be able to sustain improvements in your customer experience. For your reference, here's an article on "Sustainability and the Quality Professional" [5]. 4. How well the auditor finds and communicates areas of improvement. Now, ISO auditors may not provide consulting to the clients they audit, however, there is the potential for auditors to point out areas of improvement. Many auditors simply rely on submitting reports that indicate compliance or non-compliance with the appropriate section of the standard, however, to most executives, this is like speaking a foreign language. Auditors that can clearly identify and communicate areas of improvement in language and terms executive management understands allows the companies they audit to act on improvement initiatives. When management doesn't

ISO 9000 understand why they were non-compliant and the business implications, they simply ignore the reports and focus on what they do understand. Here's a link to a free thought piece on "How to Make a Good Audit Great" [5].

234

Advantages
It is widely acknowledged that proper quality management improves business, often having a positive effect on investment, market share, sales growth, sales margins, competitive advantage, and avoidance of litigation.The quality principles in ISO 9000:2000 are also sound, according to Wade and Barnes, who say that "ISO 9000 guidelines provide a comprehensive model for quality management systems that can make any company competitive implementing ISO often gives the following advantages: 1. 2. 3. 4. 5. 6. 7. 8. Create a more efficient, effective operation Increase customer satisfaction and retention Reduce audits Enhance marketing Improve employee motivation, awareness, and morale Promote international trade Increases profit Reduce waste and increases productivity.

Problems
A common criticism of ISO 9001 is the amount of money, time and paperwork required for registration.[6] According to Barnes, "Opponents claim that it is only for documentation. Proponents believe that if a company has documented its quality systems, then most of the paperwork has already been completed."[7] ISO 9001 is not in any way an indication that products produced using its certified systems are any good. A company can intend to produce a poor quality product and providing it does so consistently and with the proper documentation can put an ISO 9001 stamp on it. According to Seddon, ISO 9001 promotes specification, control, and procedures rather than understanding and improvement.[8] [9] Wade argues that ISO 9000 is effective as a guideline, but that promoting it as a standard "helps to mislead companies into thinking that certification means better quality, ... [undermining] the need for an organization to set its own quality standards." [10] Paraphrased, Wade's argument is that reliance on the specifications of ISO 9001 does not guarantee a successful quality system. While internationally recognized, most US consumers are not aware of ISO 9000 and it holds no relevance to them. The added cost to certify and then maintain certification may not be justified if product end users do not require ISO 9000. The cost can actually put a company at a competitive disadvantage when competing against a non ISO 9000 certified company. The standard is seen as especially prone to failure when a company is interested in certification before quality.[8] Certifications are in fact often based on customer contractual requirements rather than a desire to actually improve quality.[7] [11] "If you just want the certificate on the wall, chances are, you will create a paper system that doesn't have much to do with the way you actually run your business," said ISO's Roger Frost.[11] Certification by an independent auditor is often seen as the problem area, and according to Barnes, "has become a vehicle to increase consulting services." [7] In fact, ISO itself advises that ISO 9001 can be implemented without certification, simply for the quality benefits that can be achieved.[12] Another problem reported is the competition among the numerous certifying bodies, leading to a softer approach to the defects noticed in the operation of the Quality System of a firm. Abrahamson[13] argued that fashionable management discourse such as Quality Circles tends to follow a lifecycle in the form of a bell curve, possibly indicating a management fad.

ISO 9000

235

Summary
A good overview for effective use of ISO 9000 is provided by Barnes: "Good business judgment is needed to determine its proper role for a company... Is certification itself important to the marketing plans of the company? If not, do not rush to certification... Even without certification, companies should utilize the ISO 9000 model as a benchmark to assess the adequacy of its quality programs."

See also
Conformity assessmentContaining ISO published standards ISO 10006Quality managementGuidelines to quality management in projects ISO 14001Environmental management standards ISO 19011Guidelines for quality management systems auditing and environmental management systems auditing ISO/TS 16949Quality management system requirements for automotive-related products suppliers ISO/IEC 27001Information security management AS 9100 - aerospace industry implementation of ISO 9000/1 List of ISO standards

Quality management system Test management Verification and Validation

References
[1] [2] [3] [4] [5] [6] http:/ / www. icsworldcert. com/ index. jsp?resourceID=143#practical http:/ / iso9001-consultant. co. uk/ http:/ / www. bsigroup. com/ en/ Assessment-and-certification-services/ management-systems/ Standards-and-Schemes/ ISO-9001/ http:/ / www. questforum. org http:/ / www. icsworldcert. com/ index. jsp?resourceID=345 "So many standards to follow, so little payoff" (http:/ / www. inc. com/ magazine/ 20050501/ management. html). Stephanie Clifford. Inc Magazine, May 2005. [7] "Good Business Sense Is the Key to Confronting ISO 9000" (http:/ / www. allbusiness. com/ specialty-businesses/ 713376-1. html) Frank Barnes in Review of Business, Spring 2000. [8] "The 'quality' you can't feel" (http:/ / money. guardian. co. uk/ work/ story/ 0,,613363,00. html), John Seddon, The Observer, Sunday November 19, 2000 [9] "A Brief History of ISO 9000: Where did we go wrong?" (http:/ / www. lean-service. com/ 3-1-article. asp). John Seddon. Chapter one of "The Case Against ISO 9000", 2nd ed., Oak Tree Press. November 2000. ISBN 1-86076-173-9 [10] "Is ISO 9000 really a standard?" (http:/ / www. bin. co. uk/ IMS_May_2002. pdf) Jim Wade, ISO Management Systems May-June 2002 [11] "ISO a GO-Go." (http:/ / www. entrepreneur. com/ magazine/ entrepreneur/ 2001/ december/ 46342. html) Mark Henricks. Entrepreneur Magazine Dec 2001. [12] The ISO Survey 2005 (http:/ / www. iso. org/ iso/ en/ iso9000-14000/ pdf/ survey2005. pdf) (abridged version, PDF, 3 MB), ISO, 2005 [13] Abrahamson, E. (1996). "Managerial fashion." Academy of Management Review. 21(1):254-285.

http://www.iso.org/iso/survey2007.pdf - An abstract of the 2007's ISO survey of certificates http://www.iso.org/iso/survey2008.pdf - An abstract of the 2008's ISO survey of certificates

ISO 9000

236

Further reading
Bamford, Robert; Deibler, William (2003). ISO 9001: 2000 for Software and Systems Providers: An Engineering Approach (1st ed.). CRC-Press. ISBN 0849320631, ISBN 978-0849320637 Naveh. E., Marcus, A. (2004). "When does ISO 9000 Quality Assurance standard lead to performance improvement?", IEEE Transactions on Engineering Management, 51(3), 352363.

External links
Introduction to ISO 9000 and ISO 14000 (http://www.iso.org/iso/iso_catalogue/management_standards/ iso_9000_iso_14000.htm) ISO (http://www.iso.org) (International Organization for Standardization) ISO's Technical Committee 176 (http://www.tc176.org/) on Quality Management and Quality Assurance Technical Committee No. 176, Sub-committee No. 2 (http://www.iso.org/tc176/sc2), which is responsible for developing ISO 9000 standards. Basic info (http://www.tc176.org/About176.asp) on ISO 9000 development ISO 9000 FAQs (http://www.tc176.org/FAQ.asp)

ISO 10006
ISO 10006:2003, Quality management systems - Guidelines for quality management in projects, is an international standard developed by the International Organization for Standardization. ISO 10006:2003 gives guidance on the application of quality management in projects. It is applicable to projects of varying complexity, small or large, of short or long duration, in different environments, and irrespective of the kind of product or process involved. This can necessitate some tailoring of the guidance to suit a particular project. ISO 10006:2003 is not a guide to "project management" itself. Guidance on quality in project management processes is discussed in this International Standard. Guidance on quality in a project's product-related processes, and on the "process approach", is covered in ISO 9004. A new "Project Management - Guide to project Management" ISO 21500 is in preparation (2008). Since ISO 10006:2003 is a guidance document, it is not intended to be used for certification/registration purposes.

See also
Clinical trial List of ISO standards project management Quality management system

External links
Overview and discussion of the ISO 10006 Standard [1] Combining the ISO 10006 and PMBOK To Ensure Successful Projects [2] Scope of the ISO 10006 Standard [3](Link has been removed, please update)

ISO 10006

237

References
[1] http:/ / www. pmpartners. com/ resources/ iso10006. html [2] http:/ / www. bia. ca/ articles/ pj-combining-iso-10006-pmbok-to-ensure-successful-projects. htm [3] http:/ / www. sfs. fi/ standard/ scope10006. pdf

Total cost management

Total cost management (TCM) is the name given by AACE International to a process for applying the skills and knowledge of cost engineering. It is also the first integrated process or methodology for portfolio, program and project management. AACE first introduced the concept in the 1990s and published the full presentation of the process in the "Total Cost Management Framework" in 2006. [1]

Overview
Traditionally, the field of project management begins with the "initiation" of a project. The most well known treatment of the project management process is included in the Project Management Institute's Project Management Body of Knowledge (PMBOK). However, the PMBOK does not address what happens before a project is initiated; i.e., how does a project come into being?, how is the project identified and decided upon among other operating, maintenance, or investment options available to an enterprise. Total Cost Management maps the process upstream of project management. In TCM, what precedes project management is referred to as "strategic asset management" or more traditionally, "portfolio and program management". A unique element of the TCM process is that it integrates all the steps that an organization must take to deploy its business strategy. This includes monitoring and becoming aware of a performance issue with an asset in its asset portfolio (i.e., capital asset base), to completing a project and delivering a modified or new asset to the company's portfolio. It also addresses managing multiple projects as a program or project portfolio. TCM has found its widest audience in the companies that make large capital investments in fixed capital assets through construction projects (e.g., oil and gas, chemical, pharmaceuticals, utilities, etc.). However, the process is industry generic and is finding wider use in IT, software and other companies.

Total Cost Management Framework

In 2006, AACE published their Total Cost Management Framework- An Integrated Methodology for Portfolio, Program and Project Management.[2] In this tested and proven methodology, portfolios of assets are optimized through the use of portfolios of projects, using project management as a delivery system, to support and enhance large, strategic or operational programs [3] in support of the business and strategic objectives of the organization. The TCMF Methodology, while not available yet under open source licensing, is made freely available online for anyone to download at no cost through the AACE website.[4]

Total cost management

238

Further reading
The Total Cost Management Framework; A Process for Applying the Skills and Knowledge of Cost Engineering [5] - a free text (pdf)

External links
AACE International (AACE) [6]

References
[1] Hollmann, John K., Editor, Total Cost Management Framework, AACE International, Morgantown WV, 2006 [2] TCM Framework: An Integrated Approach to Portfolio, Program and Project Management, 2006, AACE, John K. Hollman, Editor, ISBN 1-885517-55-6 [3] See definition of Program, as developed by the Global alliance of Project Performance Standards, GAPPS (http:/ / www. globalpmstandards. org/ downloads/ program-manager-standards/ GAPPS_Program_Types. pdf) [4] (http:/ / www. aacei. org/ tcm) [5] http:/ / www. aacei. org/ tcm/ [6] http:/ / www. aacei. org

The International Association of Project and Program Management

The International Association of Project and Program Management (IAPPM), formed in 2003 through the active volunteers and established as a global project management professional organization and Association providing knowledge and useful content back to project managers and program managers. IAPPM is the publisher of the CPPGuide and the "CIPAGuide", currently in first draft format. Currently regular membership stands at $70 USD per year. You do not need a IAPPM certification to become a member of IAPPM. Furthermore if you apply for a certification that membership fees be paid in order to maintain certification status. IAPPM also provides four key certifications to business professionals; Certified Project Manager (CPM), the Certified International Project Auditor or CIPA, or Certified Project Director CPD to successful individuals meeting project experience and eligibility criteria. This also assists Professionals looking for a competitive advantage in their professional development.An online examination is also provided. No re-certification is currently needed. As an independent project organization, IAPPM is dedicated to helping individuals achieving success in the global project community, IAPPM has 15 chapters globally and continually seeks to assist project managers with standards development, documentation and work related knowledge. Recognized by numerous organization such as ALLPM.com, Columbia University project management, International Quality and Productivity Center (IQPC).

The International Association of Project and Program Management

239

External links
The International Association of Project & Program Management [1] Greater China Chapter [2] Middle East and North Africa Chapter [3]

References
[1] http:/ / www. iappm. org [2] http:/ / www. iappm. org. hk [3] http:/ / www. iappm-me. org

V-Model
The V-Model (or VEE model) is a systems development model designed to simplify the understanding of the complexity associated with developing systems.[2] [3] [4] In systems engineering it is used to define a uniform procedure for product or project development.

Overview
The V-model is a graphical [1] The V-model of the Systems Engineering Process. representation of the systems development lifecycle. It summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework. The VEE is a process that represents the sequence of steps in a project life cycle development. It describes the activities and results that have to be produced during product development. The left side of the VEE represents the decomposition of requirements, and creation of system specifications. The right side of the V represents integration of parts and their verification.[3] [4] [5] [6] [7] V stands for "Verification and Validation" 77. It is very similar to the Classic Waterfall model as it is quite rigid and it contains a lot of iteration.

Objectives
The V-Model provides guidance for the planning and realization of projects. The following objectives are intended to be achieved by a project execution: Minimization of Project Risks: The V-Model improves project transparency and project control by specifying standardized approaches and describing the corresponding results and responsible roles. It permits an early recognition of planning deviations and risks and improves process management, thus reducing the project risk. Improvement and Guarantee of Quality: As a standardized process model, the V-Model ensures that the results to be provided are complete and have the desired quality. Defined interim results can be checked at an early stage. Uniform product contents will improve readability, understandability and verifiability.

V-Model Reduction of Total Cost over the Entire Project and System Life Cycle: The effort for the development, production, operation and maintenance of a system can be calculated, estimated and controlled in a transparent manner by applying a standardized process model. The results obtained are uniform and easily retraced. This reduces the acquirers dependency on the supplier and the effort for subsequent activities and projects. Improvement of Communication between all Stakeholders: The standardized and uniform description of all relevant elements and terms is the basis for the mutual understanding between all stakeholders. Thus, the frictional loss between user, acquirer, supplier and developer is reduced.

240

V Model topics
Systems Engineering and verification
The Systems Engineering Process (SEP) provides a path for improving the cost effectiveness of complex systems as experienced by the system owner over the entire life of the system, from conception to retirement.[1] It involved early and comprehensive identification of goals, a concept of operations that describes user needs and the operating environment, thorough and testable system requirements, [8] Systems engineering and verification. detailed design, implementation, rigorous acceptance testing of the implemented system to ensure it meets the stated requirements (system verification), measuring its effectiveness in addressing goals (system validation), on-going operation and maintenance, system upgrades over time, and eventual retirement.[1] [3] [4] [7] The process emphasizes requirements-driven design and testing. All design elements and acceptance tests must be traceable to one or more system requirements and every requirement must be addressed by at least one design element and acceptance test. Such rigor ensures nothing is done unnecessarily and everything that is necessary is accomplished.[1] [3]

The specification stream

The specification stream mainly consists of: User Requirement Specifications Functional Requirement Specifications Design Specifications The testing stream generally consists of: Installation Qualification (IQ) Operational Qualification (OQ) Performance Qualification (PQ) The development stream can consist (depending on the system type and the development scope) of customization, configuration or coding.

V-Model

241

Applications
The V-model is used to regulate the software development process within the German federal administration. Nowadays it is still the standard for German federal administration and defense projects, as well as software developers within in the region. The concept of the V-Model was developed simultaneously, but independently, in Germany and in the United States in the late 1980s: The German V-Model was originally developed by IABG in Ottobrunn, near Munich, in cooperation with the Federal Office for Defence Off-Core alternatives (illustrating upward and downward iterations and Time and [3] [7] Technology and Procurement in Maturity dimension). Source - K. Forsberg and H. Mooz 2004 Koblenz, for the Federal Ministry of Defence. It was taken over by the Federal Ministry of the Interior for the civilian public authorities domain in summer 1992.[9] The US V-Model, as documented in the 1991 proceedings for the National Council on Systems Engineering (NCOSE; now INCOSE as of 1995),[7] was developed for satellite systems involving hardware, software, and human interaction. It has now found widespread application in commercial as well as defence programs. Its primary use is in Project Management[3] [4] and throughout the project lifecycle. One fundamental characteristic of the US V-Model is that time and maturity move from left to right and one cannot move back in time. All iteration is along a vertical line to higher or lower levels in the system hierarchy, as shown in the figure.[3] [4] [7] This has proven to be an important aspect of the model. The expansion of the model to a dual-Vee concept is treated in reference [3] . As the V-model is publicly available many companies also use it. In project management it is a method comparable to PRINCE2 and describes methods for project management as well as methods for system development. The V-Model while rigid in process, can be very flexible in application, especially as it pertains to the scope outside of the realm of the System Development Lifecycle normal parameters.

Advantages
These are the advantages V-Model offers in front of other systems development models: The users of The V-Model participate in the development and maintenance of The V-Model. A change control board publicly maintains the V-Model. The change control board meets once a year and processes all received change requests on The V-Model.[10] At each project start, the V-Model can be tailored into a specific project V-Model, this being possible because the V-Model is organization and project independent.[11] The V-Model provides concrete assistance on how to implement an activity and its work steps, defining explicitly the events needed to complete a work step: each activity schema contains instructions, recommendations and detailed explanations of the activity.[12]

V-Model

242

Limits
The following aspects are not covered by the V-Model, they must be regulated in addition, or the V-Model must be adapted accordingly [13] [14] : The placing of contracts for services is not regulated. The organization and execution of operation, maintenance, repair and disposal of the system are not covered by the V-Model. However, planning and preparation of a concept for these tasks are regulated in the V-Model. The V-Model addresses software development within a project rather than a whole organization.

See also
RUP (as a supporting software process) Systems analysis Systems design Dual Vee Model

External links
Vee Model of Systems Engineering Design and Integration [15] What is the V-model? [16] (in German) V-Model XT Documentation (1.3) [17] Types of Testing [18] Image [19] Software Processes (also the V-Modell) [20] Death of the V-Model [21] (small software projects but not large systems of systems?)

References
[1] Clarus Concept of Operations. (http:/ / www. itsdocs. fhwa. dot. gov/ jpodocs/ repts_te/ 14158. htm) Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005 [2] "Systems Engineering for Intelligent Transportation Systems" (http:/ / ops. fhwa. dot. gov/ publications/ seitsguide/ seguide. pdf). US Dept. of Transportation. p. 10. . Retrieved 2007-06-09. [3] Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360. [4] International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8 [5] Forsberg, K., Mooz, H. (1998). System Engineering for Faster, Cheaper, Better (http:/ / web. archive. org/ web/ 20030420130303/ http:/ / www. incose. org/ sfbac/ welcome/ fcb-csm. pdf). Center of Systems Management. . [6] "The SE VEE" (http:/ / www. gmu. edu/ departments/ seor/ insert/ robot/ robot2. html). SEOR, George Mason University. . Retrieved 2007-05-26. [7] Forsberg, K. and Mooz, H., " The Relationship of Systems Engineering to the Project Cycle (http:/ / www. csm. com/ repository/ model/ rep/ o/ pdf/ Relationship of SE to Proj Cycle. pdf)," First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991 [8] Systems Engineering Fundamentals. Defense Acquisition University Press, 2001. [9] V-Model Lifecycle Process Model (http:/ / www. v-modell. iabg. de/ kurzb/ vm/ k_vm_e. doc) [10] Further Development of the V-Model (http:/ / v-modell. iabg. de/ v-modell-xt-html-english/ db09fe25265517. html#toc34) [11] V-Model Tailoring (http:/ / v-modell. iabg. de/ v-modell-xt-html-english/ f3ffba5de1675. html#toc22) [12] Overview of the Activity Model of the V-Model (http:/ / v-modell. iabg. de/ v-modell-xt-html-english/ dbe1fba6c7da92. html#toc797) [13] Limits of the VModel (http:/ / v-modell. iabg. de/ v-modell-xt-html-english/ 446bfd42664fda. html#toc9) [14] Christian Bucanac, The V-Model (http:/ / www. bucanac. com/ documents/ The_V-Model. pdf) [15] http:/ / g2sebok. incose. org/ app/ qualsys/ view_by_id. cfm?ID=INCOSE%20G2SEBOK%203. 30& ST=F [16] http:/ / www. v-modell. iabg. de/ #WASIST [17] http:/ / v-modell. iabg. de/ v-modell-xt-html-english/ index. html [18] http:/ / www. coleyconsulting. co. uk/ testtype. htm [19] http:/ / www. glemser. com/ images/ misc/ VModel. gif

V-Model
[20] http:/ / www. the-software-experts. de/ e_dta-sw-process. htm [21] http:/ / www. harmonicss. co. uk/ index. php/ tutorials/ software-engineering/ 56?task=view

243

Project portfolio management

Project Portfolio Management (PPM) is a term used by project managers and project management (PM) organizations to describe methods for analyzing and collectively managing a group of current or proposed projects based on numerous key characteristics. The fundamental objective of the PPM process is to determine the optimal mix and sequencing of proposed projects to best achieve the organization's overall goals - typically expressed in terms of hard economic measures, business strategy goals, or technical strategy goals - while honoring constraints imposed by management or external real-world factors. Typical attributes of projects being analyzed in a PPM process include each project's total expected cost, consumption of scarce resources (human or otherwise) expected timeline and schedule of investment, expected nature, magnitude and timing of benefits to be realized, and relationship or inter-dependencies with other projects in the portfolio. The key challenge to implementing an effective PPM process is typically securing the mandate to do so. Many organizations are culturally inured to an informal method of making project investment decisions, which can be compared to political processes observable in the U.S. legislature. However this approach to making project investment decisions has led many organizations to unsatisfactory results, and created demand for a more methodical and transparent decision making process. That demand has in turn created a commercial marketplace for tools and systems which facilitate such a process. Some commercial vendors of PPM software emphasize their products' ability to treat projects as part of an overall investment portfolio. PPM advocates see it as a shift away from one-off, ad hoc approaches to project investment decision making. Most PPM tools and methods attempt to establish a set of values, techniques and technologies that enable visibility, standardization, measurement and process improvement. PPM tools attempt to enable organizations to manage the continuous flow of projects from concept to completion. Treating a set of projects as a portfolio would be, in most cases, an improvement on the ad hoc, one-off analysis of individual project proposals. The relationship between PPM techniques and existing investment analysis methods is a matter of debate. While many are represented as "rigorous" and "quantitative", few PPM tools attempt to incorporate established financial portfolio optimization methods like modern portfolio theory or Applied Information Economics, which have been applied to project portfolios, including even non-financial issues.[1] [2] [3] [4]

Controversy over the "investment discipline" of PPM

Developers of PPM tools see their solutions as borrowing from the financial investment world. However, other than using the word "portfolio", few can point to any specific portfolio optimization methods implemented in their tools. A project can be viewed as a composite of resource investments such as skilled labour and associated salaries, IT hardware and software, and the opportunity cost of deferring other project work. As project resources are constrained, business management can derive greatest value by allocating these resources towards project work that is objectively and relatively determined to meet business objectives more so than other project opportunities. Thus, the decision to invest in a project can be made based upon criteria that measures the relative benefits (eg. supporting business objectives) and its relative costs and risks to the organization. In principle, PPM attempts to address issues of resource allocation, e.g., money, time, people, capacity, etc. In order for it to truly borrow concepts from the financial investment world, the portfolio of projects and hence the PPM movement should be grounded in some financial objective such as increasing shareholder value, top line growth, etc. Equally important, risks must be computed in a statistically, actuarially meaningful sense. Optimizing resources and projects without these in mind fails to consider the most important resource any organization has and which is easily

Project portfolio management understood by people throughout the organization whether they be IT, finance, marketing, etc and that resource is money. While being tied largely to IT and fairly synonymous with IT portfolio management, PPM is ultimately a subset of corporate portfolio management and should be exportable/utilized by any group selecting and managing discretionary projects. However, most PPM methods and tools opt for various subjective weighted scoring methods, not quantitatively rigorous methods based on options theory, modern portfolio theory, Applied Information Economics or operations research. Beyond the project investment decision, PPM aims to support ongoing measurement of the project portfolio so each project can be monitored for its relative contribution to business goals. If a project is either performing below expectations (cost overruns, benefit erosion) or is no longer highly aligned to business objectives (which change with natural market and statutory evolution), management can choose to decommit from a project and redirect its resources elsewhere. This analysis, done periodically, will "refresh" the portfolio to better align with current states and needs. Historically, many organizations were criticized for focusing on "doing the wrong things well." PPM attempts to focus on a fundamental question: "Should we be doing this project or this portfolio of projects at all?" One litmus test for PPM success is to ask "Have you ever canceled a project that was on time and on budget?" With a true PPM approach in place, it is much more likely that the answer is "yes." As goals change so should the portfolio mix of what projects are funded or not funded no matter where they are in their individual lifecycles. Making these portfolio level business investment decisions allows the organization to free up resources, even those on what were before considered "successful" projects, to then work on what is really important to the organization.

244

Project portfolio management

245

Optimizing for payoff

One method PPM tools or consultants might use is the use of decision trees with decision nodes that allow for multiple options and optimize against a constraint. The organization in the following example has options for 7 projects but the portfolio budget is limited to $10,000,000. The selection made are the projects 1, 3, 6 and 7 with a total investment of $7,740,000 - the optimum under these conditions. The portfolio's payoff is $2,710,000.

Presumably, all other combinations of projects would either exceed the budget or yield a lower payoff. However, this is an extremely simplified representation of risk and is unlikely to be realistic. Risk is usually a major differentiator among projects but it is difficult to quantify risk in a statistically and actuarially meaningful manner (with probability theory, Monte Carlo Method, statistical analysis, etc.). This places limits on the deterministic nature of the results of a tool such as a decision tree (as predicted by modern portfolio theory).

Resource allocation
Resource allocation is a critical component of PPM. Once it is determined that one or many projects meet defined objectives, the available resources of an organization must be evaluated for its ability to meet project demand (aka as a demand "pipeline" discussed below). Effective resource allocation typically requires an understanding of existing labor or funding resource commitments (in either business operations or other projects) as well as the skills available in the resource pool. Project investment should only be made in projects where the necessary resources are available during a specified period of time. Resources may be subject to physical constraints. For example, IT hardware may not be readily available to support technology changes associated with ideal implementation timeframe for a project. Thus, a holistic understanding of all project resources and their availability must be conjoined with the decision to make initial investment or else projects may encounter substantial risk during their lifecycle when unplanned resource constraints arise to delay achieving project objectives.

Project portfolio management Beyond the project investment decision, PPM involves ongoing analysis of the project portfolio so each investment can be monitored for its relative contribution to business goals versus other portfolio investments. If a project is either performing below expectations (cost overruns, benefit erosion) or is no longer aligned to business objectives (which change with natural market and statutory evolution), management can choose to decommit from a project to stem further investment and redirect resources towards other projects that better fit business objectives. This analysis can typically be performed on a periodic basis (eg. quarterly or semi-annually) to "refresh" the portfolio for optimal business performance. In this way both new and existing projects are continually monitored for their contributions to overall portfolio health. If PPM is applied in this manner, management can more clearly and transparently demonstrate its effectiveness to its shareholders or owners. Implementing PPM at the enterprise level faces a challenge in gaining enterprise support because investment decision criteria and weights must be agreed to by the key stakeholders of the organization, each of whom may be incentivised to meet specific goals that may not necessarily align with those of the entire organization. But if enterprise business objectives can be manifested in and aligned with the objectives of its distinct business unit sub-organizations, portfolio criteria agreement can be achieved more easily. (Assadourian 2005) From a requirements management perspective Project Portfolio Management can be viewed as the upper-most level of business requirements management in the company, seeking to understand the business requirements of the company and what portfolio of projects should be undertaken to achieve them. It is through portfolio management that each individual project should receive its allotted business requirements (Denney 2005).

246

Pipeline management
In addition to managing the mix of projects in a company, Project Portfolio Management must also determine whether (and how) a set of projects in the portfolio can be executed by a company in a specified time, given finite development resources in the company. This is called pipeline management. Fundamental to pipeline management is the ability to measure the planned allocation of development resources according to some strategic plan. To do this, a company must be able to estimate the effort planned for each project in the portfolio, and then roll the results up by one or more strategic project types e.g., effort planned for research projects. (Cooper et al. 1998); (Denney 2005) discusses project portfolio and pipeline management in the context of use case driven development.

Organizational applicability
The complexity of PPM and other approaches to IT projects (e.g., treating them as a capital investment) may render them not suitable for smaller or younger organizations. An obvious reason for this is that a few IT projects doesn't make for much of a portfolio selection. Other reasons include the cost of doing PPMthe data collection, the analysis, the documentation, the education, and the change to decision-making processes.

Further reading
Cooper, Robert G.; Scott J. Edgett, and Elko J. Kleinschmidt (1998). Portfolio Management for New Products. Reading, Mass.: Addison-Wesley. ISBN0-201-32814-3. Denney, Richard (2005). Succeeding with Use Cases: Working Smart to Deliver Quality. Boston, Mass.: Addison-Wesley. ISBN0-321-31643-6. Rajegopal, Shan; Philip McGuin, and James Waller (2007). Project Portfolio Management: Leading the Corporate Vision [5]. Basingstoke: Palgrave Macmillan. ISBN978-0-230-50716-6. Sanwal, Anand (2007). Optimizing Corporate Portfolio Management: Aligning Investment Proposals with Organizational Strategy [6]. Wiley. ISBN978-0-470-12688-2.

Project portfolio management

247

See also
Document management system List of project management software Project management Project management software

References
[1] Douglas Hubbard "How to Measure Anything: Finding the Value of Intangibles in Business" John Wiley & Sons, 2007. [2] US Government Study on AIE (http:/ / www. cio. gov/ documents/ aie_report_final. pdf) [3] Federal CIO Council comparison of AIE and balanced scorecard (http:/ / www. cio. gov/ documents/ PM_Lessons_Learned_Final_Report. pdf) [4] Environmental Protection Agency AIE study about optimizing desktop replacement (http:/ / www. federalelectronicschallenge. net/ resources/ docs/ aie_desktop. pdf) [5] http:/ / www. palgrave. com/ products/ Catalogue. aspx?is=0230507166 [6] http:/ / www. wiley. com/ WileyCDA/ WileyTitle/ productCd-0470126884. html

Glossary of project management

A glossary of terms relating to Project management.
'' Top 09 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A
Agile software development is a set of fundamental principles about how software should be developed based on an agile way of working in contrast to previous heavy handed software development methodologies.[1] Aggregate planning is an operational activity which does an aggregate plan for the production process, in advance of 2 to 18 months, to give an idea to management as to what quantity of materials and other resources are to be procured and when, so that the total cost of operations of the organization is kept to the minimum over that period. Allocation is the assignment of available resources in an economic way.

B
Budget generally refers to a list of all planned expenses and revenues. Budgeted Cost of Work Performed (BCWP) measures the budgeted cost of work that has actually been performed, rather than the cost of work scheduled. Budgeted Cost of Work Scheduled (BCWS) the approved budget that has been allocated to complete a scheduled task (or Work Breakdown Structure (WBS) component) during a specific time period. Business model is a term used to describe a profit-producing system that has an important degree of independence from the other systems within an enterprise. Business analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change. Business operations are those ongoing recurring activities involved in the running of a business for the purpose of producing value for the stakeholders. They are contrasted with project management, and consist of business

Glossary of project management processes. Business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. There are three types of business processes: Management processes, Operational processes, and Supporting processes. Business Process Modeling (BPM) is the activity of representing processes of an enterprise, so that the current ("as is") process may be analyzed and improved in future ("to be").

248

C
Capability Maturity Model (CMM) in software engineering is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization's processes. Change control is a general term describing the procedures used to ensure that changes (normally, but not necessarily, to IT systems) are introduced in a controlled and coordinated manner. Change control is a major aspect of the broader discipline of change management.

Capability Maturity Model.

Change Management is a field of management focussed on organizational changes. It aims to ensure that methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimize the number and impact of any related incidents upon service. Case study is a research method which involves an in-depth, longitudinal examination of a single instance or event: a case. They provide a systematic way of looking at events, collecting data, analyzing information, and reporting the results. Constructability is a project management technique to review the construction processes from start to finish during pre-construction phrase. It will identify obstacles before a project is actually built to reduce or prevent error, delays, and cost overrun. Costs in economics, business, and accounting are the value of money that has been used up to produce something, and hence is not available for use anymore. In business, the cost may be one of acquisition, in which case the amount of money expended to acquire it is counted as cost. Cost Engineering is the area of engineering practice where engineering judgment and experience are used in the application of scientific principles and techniques to problems of cost estimating, cost control, business planning and management science, profitability analysis, project management, and planning and scheduling."[2] Construction, in the fields of architecture and civil engineering, is a process that consists of the building or assembling of infrastructure. Far from being a single activity, large scale construction is a feat of multitasking. Normally the job is managed by the project manager and supervised by the construction manager, design engineer, construction engineer or project architect. Cost overrun is defined as excess of actual cost over budget.

Glossary of project management

249

Critical Path Method (CPM) is a mathematically based modeling technique for scheduling a set of project activities, used in project management. Critical Chain Project Management (CCPM) is a method of planning and managing projects that puts more emphasis on the resources required to execute project tasks.

PERT chart with two critical paths.

Dependency in a project network is a link amongst a project's terminal elements. Dynamic Systems Development Method (DSDM) is a software development methodology originally based upon the Rapid Application Development methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement. Duration of a project's terminal element is the number of calendar periods it takes from the time the execution of element starts to the moment it is completed. Deliverable A contractually required work product, produced and delivered to a required state. A deliverable may be a document, hardware, software or other tangible product.

E
Earned Schedule (ES) is an extension to Earned Value Management (EVM), which renames two traditional measures, to indicate clearly they are in units of currency or quantity, not time. Earned Value Management (EVM) is a project management technique for measuring project progress in an objective manner, with a combination of measuring scope, schedule, and cost in a single integrated system. Effort management is a project management subdiscipline for effective and efficient use of time and resources to perform activities regarding quantity, quality and direction. Enterprise modeling is the process of understanding an enterprise business and improving its performance through creation of enterprise models. This includes the modelling of the relevant business domain (usually relatively stable), business processes (usually more volatile), and Information technology Estimation in project management is the processes of making accurate estimates using the appropriate techniques. Event chain diagram : diagram that show the relationships between events and tasks and how the events affect each other. 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. Extreme project management (XPM) refers to a method of managing very complex and very uncertain projects.
Event chain diagram

Glossary of project management

250

F
Float in a project network is the amount of time that a task in a project network can be delayed without causing a delay to subsequent tasks and or the project completion date. Focused improvement in Theory of Constraints is the ensemble of activities aimed at elevating the performance of any system, especially a business system, with respect to its goal by eliminating its constraints one by one and by not working on non-constraints. Fordism, named after Henry Ford, refers to various social theories. It has varying but related meanings in different fields, and for Marxist and non-Marxist scholars.

G
Henry Gantt was an American mechanical engineer and management consultant, who developed the Gantt chart in the 1910s. Gantt chart is a type of bar chart that illustrates a project schedule. It 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. Goal or objective consists of a projected state of affairs which a person or a system plans or intends to achieve or bring about a personal or organizational desired end-point in some sort of assumed development. Many people endeavor to reach goals within a finite time by setting deadlines Goal setting involves establishing specific, measurable and time targeted objectives Graphical Evaluation and Review Technique (GERT), is a network analysis technique that allows probabilistic treatment of both network logic and activity duration estimated.

A Gantt chart.

H
Hammock activity is a schedule (project management) or project planning term for a grouping of subtasks that "hangs" between two end dates it is tied to. (Or the two end-events it is fixed to.) HERMES is a Project Management Method developed by the Swiss Government, based on the German V-Modell. The first domain of application was software projects.

I
Integrated Master Plan (IMP) is an event-based, top level plan, consisting of a hierarchy of Program Events. ISO 10006 is a guidelines for quality management in projects, is an international standard developed by the International Organization for Standardization. Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between

Glossary of project management

251

K
Kickoff meeting is the first meeting with the project team and the client of the project.

L
Level of Effort (LOE) is qualified as a support type activity which doesn't lend itself to measurement of a discrete accomplishment. Examples of such an activity may be project budget accounting, customer liaison, etc. Linear scheduling method (LSM) is a graphical scheduling method focusing on continuous resource utilization in repetitive activities. It is believed that it originally adopted the idea of Line-Of-Balance method. Lean manufacturing or lean production, which is often known simply as "Lean", is the practice of a theory of production that considers the expenditure of resources for any means other than the creation of value for the presumed customer to be wasteful, and thus a target for elimination. In a more basic term,

M
Management in business and human organization activity is simply the act of getting people together to accomplish desired goals. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. Management process is a process of planning and controlling the performance or execution of any type of activity. Management science (MS), is the discipline of using mathematical modeling and other analytical methods, to help make better business management decisions. Megaproject is an extremely large-scale investment project. Motivation is the set of reasons that determines one to engage in a particular behavior.

N
Nonlinear Management (NLM) is a superset of management techniques and strategies that allows order to emerge by giving organizations the space to self-organize, evolve and adapt, encompassing Agile, Evolutionary and Lean approaches, as well as many others.

O
Operations management is an area of business that is concerned with the production of good quality goods and services, and involves the responsibility of ensuring that business operations are efficient and effective. It is the management of resources, the distribution of goods and services to customers, and the analysis of queue systems. Operations, see Business operations Operations Research (OR) is an interdisciplinary branch of applied mathematics and formal science that uses methods such as mathematical modeling, statistics, and algorithms to arrive at optimal or near optimal solutions to complex problems. Organization is a social arrangement which pursues collective goals, which controls its own performance, and which has a boundary separating it from its environment. Organization development (OD) is a planned, structured, organization-wide effort to increase the organization's effectiveness and health.

Glossary of project management

252

P
Planning in organizations and public policy is both the organizational process of creating and maintaining a plan; and the psychological process of thinking about the activities required to create a desired goal on some scale. Portfolio in finance is an appropriate mix of or collection of investments held by an institution or a private individual. PRINCE2 : PRINCE2 is a project management methodology. The planning, monitoring and control of all aspects of the project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance.[3] Process is an ungoing collection of activities, with an inputs, outputs and the energy required to transform inputs to outputs. Process architecture is the structural design of general process systems and applies to fields such as computers (software, hardware, networks, etc.), business processes (enterprise architecture, policy and procedures, logistics, project management, etc.), and any other process system of varying degrees of complexity. Process management is the ensemble of activities of planning and monitoring the performance of a process, especially in the sense of business process, often confused with reengineering. Product breakdown structure (PBS) in project management is an exhaustive, hierarchical tree structure of components that make up an item, arranged in whole-part relationship. Product description in project management is a structured format of presenting information about a project product Program Management is the process of managing multiple ongoing inter-dependent projects. An example would be that of designing, manufacturing and providing support infrastructure for an automobile manufacturer. Project : A temporary endeavor undertaken to create a unique product, service, or result.[4] Project accounting is the practice of creating financial reports specifically designed to track the financial progress of projects, which can then be used by managers to aid project management. Project management : The complete set of tasks, techniques, tools applied during project execution'. [5] Project Management Body of Knowledge (PMBOK) : The sum of knowledge within the profession of project management that is standardized by ISO.[6] Project management office: The Project management office in a business or professional enterprise is the department or group that defines and maintains the standards of process, generally related to project management, within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution. Project management process is the management process of planning and controlling the performance or execution of a project. Project Management Professional is a certificated professional in project management. Project Management Simulators are computer-based tools used in project management training programs. Usually, project management simulation is a group exercise. The computer-based simulation is an interactive learning activity. Project management software is a type of software, including scheduling, cost control and budget management, resource allocation, collaboration software, communication, quality management and documentation or administration systems, which are used to deal with the complexity of large projects.

Glossary of project management

253

Project Management Triangle is a model of the constraints of project management. Project manager : 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, architecture, computer networking, telecommunications or software development. Project network is a graph (flow chart) depicting the sequence in which a project's terminal elements are to be completed by showing terminal elements and their dependencies.
Project Management Triangle

Project plan is a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary or detailed.[7] 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.[8] Project stakeholders are those entities within or without an organization which sponsor a project or, have an interest or a gain upon a successful completion of a project. Project team is the management team leading the project, and provide services to the project. Projects often bring together a variety number of problems. Stakeholders have important issues with others. Proport refers to the combination of the unique skills of an organisation's members for collective advantage.

Q
Quality can mean a high degree of excellence (a quality product), a degree of excellence or the lack of it (work of average quality), or a property of something (the addictive quality of alcohol).[1] Distinct from the vernacular, the subject of this article is the business interpretation of quality. Quality, Cost, Delivery(QCD) as used in lean manufacturing measures a businesses activity and develops Key performance indicators. QCD analysis often forms a part of continuous improvement programs

R
Reengineering is radical redesign of an organization's processes, especially its business processes. Rather than organizing a firm into functional specialties (like production, accounting, marketing, etc.) and considering the tasks that each function performs; complete processes from materials acquisition, to production, to marketing and distribution should be considered. The firm should be re-engineered into a series of processes. Resources in project management terminology are required to carry out the project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition (usually other than labour) required for the completion of a project activity. Risk is a concept that denotes the precise probability of specific eventualities. Risk management is a management specialism aiming to reduce different risks related to a preselected domain to the level accepted by society. It may refer to numerous types of threats caused by environment, technology, humans, organizations and politics. Risk register is a tool commonly used in project planning and organisational risk assessments.

Glossary of project management

254

S
Schedules in project management consists of a list of a project's terminal elements with intended start and finish dates. Scientific management is a theory of management that analyzes and synthesizes workflow processes, improving labor productivity. Scope of a project in project management is the sum total of all of its products and their requirements or features. Scope creep 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. Scrum is an iterative incremental process of software development commonly used with agile software development. Despite the fact that "Scrum" is not an acronym, some companies implementing the process have been known to adhere to an all capital letter expression of the word, i.e. SCRUM. Six Sigma is a business management strategy, originally developed by Motorola, that today enjoys widespread application in many sectors of industry. Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.[9] Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user ownership. An SDLC should result in a high quality system that meets or exceeds customer expectations, within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is cheap to maintain and cost-effective to enhance.[10] Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed.
The Systems Development Life Cycle.

T
Task is part of a set of actions which accomplish a job, problem or assignment. Tasks in project management are activity that needs to be accomplished within a defined period of time. Task analysis is the analysis or a breakdown of exactly how a task is accomplished, such as what sub-tasks are required Timeline is a graphical representation of a chronological sequence of events, also referred to as a chronology. It can also mean a schedule of activities, such as a timetable.

Glossary of project management

255

U
Unified Process: The Unified process is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP).
The Unified Process.

V
Value engineering (VE) is a systematic method to improve the "value" of goods and services by using an examination of function. Value, as defined, is the ratio of function to cost. Value can therefore be increased by either improving the function or reducing the cost. It is a primary tenet of value engineering that basic functions be preserved and not be reduced as a consequence of pursuing value improvements. [11] Vertical slice is a type of milestone, benchmark, or deadline, with emphasis on demonstrating progress across all components of a project. Virtual Design and Construction (VDC) is the use of integrated multi-disciplinary performance models of design-construction projects, including the Product (i.e., facilities), Work Processes and Organization of the design - construction - operation team in order to support explicit and public business objectives.

W
Wideband Delphi is a consensus-based estimation technique for estimating effort. Work in project management is the amount of effort applied to produce a deliverable or to accomplish a task (a terminal element). Work Breakdown Structure (WBS) is a tool that defines a project and groups the projects discrete work elements in a way that helps organize and define the total work scope of the project. A Work breakdown structure element may be a product, data, a service, or any combination. WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control.

A work breakdown structure.

Work package is a subset of a project that can be assigned to a specific party for execution. Because of the similarity, work packages are often misidentified as projects. Workstream is a set of associated activities, focused around a particular scope that follow a path from initiation to completion.
'' Top 09 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Glossary of project management

256

Related lists
List of production topics List of project management topics List of management topics List of Theory of Constraints topics List of topics in industrial organization Timeline of project management

External links
Project Management Institute [6] Wideman Comparative Glossary of Project Management Terms [12] AACE International Cost Engineering Terminology [13] Tenrox Glossary of Project Management Terms [14] Project Management Dictionary (PM Hut) [15]

References
[1] Peter Schuh (2005). Integrating Agile Development in the Real World. ebrary, Inc. p.2. [2] AACE International's Recommended Practice 11R-88, Required Skills and Knowledge of Cost Engineering, provides some answers which are excerpted here. Beyond being a guiding document for AACE Internationals education and certification developments, 11R-88 is an excellent reference for industry core competency and career model development. [3] The PRINCE2 Guide - A to Z (http:/ / www. ruleworks. co. uk/ cgi-bin/ TUaz. exe?Guide=Prince2& XL=P& t=PRINCE2 Knowledgebase). [4] Project Management Institute (2004). A Guide to the Project Management Body of Knowledge: PMBOK Guide. 3rd Edition. Newtown Square, Pennsylvania, Project Management Institute, p. 5. [5] DIN 69901 [6] http:/ / www. pmi. org/ info/ PP_OPM3ExecGuide. pdf [7] Project Management Body of Knowledge (PMBOK), 2000 Edition [8] Harold Kerzner (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th Ed. ed.). Wiley. ISBN 0-471-22577-0. [9] IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990, quoted at the beginning of Chapter 1: Introduction to the guide "Guide to the Software Engineering Body of Knowledge" (http:/ / www. swebok. org/ swebokcontents-ch1. html#ch1). February 6, 2004. . Retrieved 2008-02-21. [10] "Systems Development Life Cycle" (http:/ / foldoc. org/ foldoc. cgi?Systems+ Development+ Life+ Cycle). In: Foldoc(2000-12-24) [11] Value Methodology Standard (http:/ / www. value-eng. org/ pdf_docs/ monographs/ vmstd. pdf) [12] http:/ / maxwideman. com/ pmglossary/ [13] http:/ / www. aacei. org/ technical/ rps/ 10s-90. pdf [14] http:/ / glossary. tenrox. com/ index. htm [15] http:/ / www. pmhut. com/ pmo-and-project-management-dictionary

List of project management topics

257

List of project management topics

This list of project management topics gives an overview of project management topics.

Project management activities

Project management is composed of several different types of activities such as: Analysis and design of objectives and events Planning the work according to the objectives Assessing and controlling risk (or Risk Management) Estimating resources Allocation of resources Organizing the work Acquiring human and material resources Assigning tasks Directing activities Controlling project execution Tracking and reporting progress (Management information system) Analyzing the results based on the facts achieved Defining the products of the project Forecasting future trends in the project Quality Management Issues management Issue solving Defect prevention Identifying, managing & controlling changes Project closure (and project debrief) Communicating to stakeholders

Project management artifacts

The following documents serve to clarify objectives and deliverables and to align sponsors, clients, and project team's expectations. Project Charter Preliminary Scope Statement/ Statement of work Business case/ Feasibility Study Scope Statement/ Terms of reference Project management plan/ Project Initiation Document Work Breakdown Structure Change Control Plan Risk Management Plan Risk Breakdown Structure Communications Plan Governance Model Risk Register

Issue Log Action Item List

List of project management topics Resource Management Plan Project Schedule Project Status Report Responsibility assignment (RACI) matrix Database of lessons learned Stakeholder Analysis Document Management

258

These documents are normally hosted on a shared resource (i.e., intranet web page) and are available for review by the project's stakeholders (except for the Stakeholder Analysis, since this document comprises personal information regarding certain stakeholders. Only the Project Manager has access to this analysis). Changes or updates to these documents are explicitly outlined in the project's configuration management (or change control plan).

Project Management tools

Project Management tools include following:

Financial tools
Earned value management Monte Carlo methods in finance

Risk Management tools

Cause-and-effect diagram Risk register SWOT analysis

General management tools

Online tools to run a Project Health Check (Ph-Check tool), take a baseline or checkpoint, or to generate highlight, or status reports.

Scheduling charts
PERT charts Gantt charts Event Chain Diagrams

Communication aids for teams

Responsibility assignment (RACI) matrix Run charts Project Cycle Optimisation (PCO) Participatory Impact Pathways Analysis (An approach for developing common understanding and consensus amongst project participants and stakeholders as to how the project will achieve its goal) Logical framework approach

List of project management topics

259

Related lists
Glossary of project management List of management topics List of production topics List of project management software List of Theory of Constraints topics Timeline of project management

External links
Wideman Comparative Glossary of Project Management Terms [12] AACE International Cost Engineering Terminology [13] Tenrox Glossary of Project Management Terms [14]

Comparison of project management software

A comparison of notable project management software.
Software Collaborative software Issue tracking system No Yes Yes No Yes Yes Yes Yes No No Yes Yes Scheduling Project Portfolio Management No Yes Yes No No No Yes No No No Yes No Resource Management Document Management Web-based License

24SevenOffice Assembla AtTask Basecamp Central Desktop Cerebro Clarizen codeBeamer Collabtive

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No

No No Yes No No Yes Yes No No No Yes No

No Yes Yes Yes No Yes Yes No No Yes Yes No

No Yes Yes Yes Yes Yes Yes Yes No No Yes Yes

Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes

Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Open source Proprietary Proprietary Open source Open source Proprietary Open source Proprietary Open source Proprietary

Contactizer Daptiv dotProject

Endeavour Software Project Management Easy Projects .NET eGroupWare

Yes Yes Yes No Yes Yes

Yes Yes Yes No No Yes

Yes Yes No Yes Yes Yes

Yes Yes Yes No Yes No

Yes Yes Yes Yes No Yes

Yes Yes Yes No Yes No

Yes Yes Yes No Yes Yes

FastTrack Schedule Feng Office Community Edition FogBugz

Comparison of project management software

260
Open source Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary

GanttProject

No Yes Yes Yes Yes Yes Yes Yes Yes Yes

No Yes Yes Yes No No Yes Yes Yes Yes

Yes Yes Yes No No No Yes No Yes No

No No Yes No No No No No Yes No

Yes Yes Yes No No No Yes No Yes No

No Yes Yes Yes Yes Yes Yes No Yes Yes

No Yes Yes Yes Yes Yes No Yes Yes Yes

Gemini Genius Inside Glasscubes Huddle Hyperoffice InLoox JIRA Journyx Kayako helpdesk software KForge

Yes Yes No

Yes No No

No No No

No No No

No No Yes

Yes Yes No

Yes Yes No

Open source Proprietary Open source Open source Proprietary Proprietary Proprietary Open source Proprietary

KKOOP KPlato

Launchpad

Yes Yes No No Yes

Yes No No No Yes

No Yes Yes Yes Yes

Yes Yes No No No

No Yes Yes Yes No

No Yes No No Yes

Yes Yes No No Yes

LiquidPlanner LisaProject MacProject MantisBT

MatchWare MindView 3 Business Merlin MicroPlanner X-Pert Microsoft Office Project Server Microsoft Project Mingle O3spaces OmniPlan Open Workbench

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes Yes Yes No Yes Yes No No

Yes Yes Yes No Yes No No No

Yes Yes Yes Yes No No Yes Yes

Yes Yes Yes No No No No No

Yes Yes Yes Yes No No Yes Yes

Yes No Yes No No Yes No No

Yes No Yes No Yes No No No

Proprietary Proprietary Proprietary

Proprietary Proprietary Proprietary Proprietary Open source Open source Proprietary

OpenProj

No

No

Yes

No

Yes

No

No

Oracle Project Portfolio Management phpGroupWare

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Open source

Comparison of project management software

261
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes No Yes No No Yes Proprietary Proprietary Proprietary

Planisware 5 Planner Suite Primavera Project Planner PRISM Project KickStart Project.net

Yes No Yes Yes No Yes

Yes No Yes No No Yes

Proprietary Proprietary Open source Open source Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary Open source Open source Proprietary Proprietary Open source Proprietary Open source Proprietary Proprietary Proprietary Proprietary Open source Proprietary Proprietary Proprietary Proprietary Proprietary

Project-Open

Yes Yes No Yes Yes Yes Yes Yes

Yes Yes No Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes Yes No Yes

Yes Yes Yes No Yes Yes Yes Yes

Yes No Yes No Yes Yes Yes No

Yes Yes No Yes Yes Yes Yes Yes

Yes Yes No Yes Yes Yes Yes Yes

Projectplace ProjectSim ProjectSpaces Projektron BCS PSNext QuickBase Redmine

Rachota

No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes

No Yes Yes No No Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes No Yes

No Yes Yes No Yes No Yes Yes Yes Yes No Yes No Yes Yes Yes Yes Yes No

No Yes Yes No Yes Yes Yes Yes Yes Yes No Yes No Yes Yes Yes Yes Yes No

No Yes Yes Yes Yes No No Yes Yes Yes No Yes Yes No Yes Yes Yes No No

No Yes Yes Yes Yes No No Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes

SAP RPM Severa SharpForge (Defunct) Smartsheet TaskJuggler

Teamcenter Teamwork Teamwork PM Tenrox Trac

TrackerSuite.Net Ubidesk VPMi WorkLenz WorkPLAN Enterprise workspace.com WebSPOC Wrike

Proprietary Proprietary Proprietary

Comparison of project management software

262
No Scheduling No Project Portfolio Management Yes Resource Management Yes Document Management Yes Web-based Proprietary License

Zoho Projects Softwares

Yes Collaborative software

Yes Issue tracking system

See also
Project management software Project management Project planning Project Portfolio Management Resource Management

Timeline of project management

Timeline of project management. There is a general understanding that the history of modern project management started around 1950. Until 1900 projects were generally managed by creative architects and engineers themself, among those for example Christopher Wren, Thomas Telford and Isambard Kingdom Brunel[1]

Early civilizations
2570 BC Great pyramid of Giza completed. Some records remain of how the work was managed: e.g. there were managers of each of the four faces of the pyramid, responsible for their completion (subproject managers). 208 BC The first major construction of the Great Wall of China.

15th - 19th century

Christopher Wren (16321723) was a 17th century English designer, astronomer, geometer, mathematician-physicist and one of the greatest English architects in history. Wren designed 55 of 87 London churches after the Great fire of London in 1666, including St Paul's Cathedral in 1710, as well as many secular buildings of note. Thomas Telford (1757-1834) was a Scotish stonemason, architect and civil engineer and a noted road, bridge and canal builder, who for example managed the Ellesmere Canal and Pontcysyllte Aqueduct. Isambard Kingdom Brunel (18061859) was a British engineer best known for the creation of the Great Western Railway, a series of famous steamships, including the first with a propeller, and numerous important bridges and tunnels.

20th century
1910s The Gantt Chart developed by Henry Laurence Gantt (18611919) 1950s 1950s The Critical path method (CPM) invented 1950s The US DoD used modern project management techniques in their Polaris project.[2] 1956 The American Association of Cost Engineers (now AACE International) formed 1958 The Program Evaluation and Review Technique (PERT) method invented

1960s

Timeline of project management 1965 International Project Management Association (IPMA) established as International Management Systems Association (IMSA) 1969 Project Management Institute (PMI) launched to promote project management profession 1970s 1975 PROMPTII methodology created by Simpact Systems Ltd (source: PRINCE2 manual) 1975 The Mythical Man-Month: Essays on Software Engineering by Fred Brooks published 1980s 1984 The Goal by Eliyahu M. Goldratt published 1986 Scrum was named as a project management style in the article The New New Product Development Game by Takeuchi and Nonaka 1987 First Project Management Body of Knowledge Guide published as a white paper by PMI 1989 PRINCE method derived from PROMPTII is published by the UK Government agency CCTA and becomes the UK standard for all government information projects 1990s 1996 PRINCE2 published by CCTA (now OGC) as a generic product management methodology for all UK government projects. 1997 Critical Chain by Eliyahu M. Goldratt published

263

21st century
2001 AgileAlliance formed to promote "lightweight" software development projects 2006 Total Cost Management Framework release by AACE

See also
List of project management topics

References
[1] Dennis Lock (2007) Project management (9e ed.) Gower Publishing, Ltd., 2007. ISBN 0566087723 [2] Young-Hoon Kwak (2005). "A brief history of Project Management". In: The story of managing projects. Elias G. Carayannis et al. 9eds, Greenwood Publishing Group, 2005. ISBN 1567205062

Portfolio management

264

Portfolio management
Portfolio Management may refer to: Portfolio manager, in investment management IT portfolio management Project management Project portfolio management

Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more difficult when dealing with large, complex projects. Systems engineering deals with work-processes and tools to handle such projects, and it overlaps with both technical and human-centered disciplines such as control engineering and project management.

Systems engineering techniques are used in complex projects: spacecraft design, computer chip design, robotics, software integration, and bridge building. Systems engineering uses a host of tools that include modeling and simulation, requirements analysis and scheduling to manage complexity.

Systems engineering

265

History
The term systems engineering can be traced back to Bell Telephone Laboratories in the 1940s.[1] The need to identify and manipulate the properties of a system as a whole, which in complex engineering projects may greatly differ from the sum of the parts' properties, motivated the Department of Defense, NASA, and other industries to apply the discipline.[2] When it was no longer possible to rely on design evolution to improve upon a system and the existing tools were not sufficient to meet growing demands, new methods began to be developed that addressed the complexity directly.[3] The evolution of systems engineering, which continues to this day, comprises the development and identification of new methods and modeling techniques. These methods aid in better comprehension of engineering systems as they grow more complex. Popular tools that are often used in the Systems Engineering context were developed during these times, including USL, UML, QFD, and IDEF0.

QFD House of Quality for Enterprise Product Development Processes

In 1990, a professional society for systems engineering, the National Council on Systems Engineering (NCOSE), was founded by representatives from a number of US corporations and organizations. NCOSE was created to address the need for improvements in systems engineering practices and education. As a result of growing involvement from systems engineers outside of the U.S., the name of the organization was changed to the International Council on Systems Engineering (INCOSE) in 1995.[4] Schools in several countries offer graduate programs in systems engineering, and continuing education options are also available for practicing engineers.[5]

Concept
Some definitions "An interdisciplinary approach and means to enable the realization of successful systems"
[6]

INCOSE handbook, 2004.

"System engineering is a robust approach to the design, creation, and operation of systems. In simple terms, the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets (or met) the goals."
[7]

NASA Systems engineering handbook, 1995.

"The Art and Science of creating effective systems, using whole system, whole life principles" OR "The Art and Science of creating optimal solution systems to complex issues and problems" INCOSE (UK), 2007. "The concept from the engineering standpoint is the evolution of the engineering scientist, i.e., the scientific generalist who maintains a broad outlook. The method is that of the team approach. On large-scale-system problems, teams of scientists and engineers, generalists as well as specialists, exert their joint efforts to find a solution and physically realize it...The technique has been variously called the systems approach or the team development method."
[9] [8]

Derek Hitchins, Prof. of Systems Engineering, former president of

Harry H. Goode & Robert E. Machol, 1957.

"The Systems Engineering method recognizes each system is an integrated whole even though composed of diverse, specialized structures and sub-functions. It further recognizes that any system has a number of objectives and that the balance between them may differ widely from system to system. The methods seek to optimize the overall system functions according to the weighted objectives and

Systems engineering
to achieve maximum compatibility of its parts."
[10]

266
Systems Engineering Tools by Harold Chestnut, 1965.

Systems Engineering signifies both an approach and, more recently, as a discipline in engineering. The aim of education in Systems Engineering is to simply formalize the approach and in doing so, identify new methods and research opportunities similar to the way it occurs in other fields of engineering. As an approach, Systems Engineering is holistic and interdisciplinary in flavour.

Origins and traditional scope

The traditional scope of engineering embraces the design, development, production and operation of physical systems, and systems engineering, as originally conceived, falls within this scope. "Systems engineering", in this sense of the term, refers to the distinctive set of concepts, methodologies, organizational structures (and so on) that have been developed to meet the challenges of engineering functional physical systems of unprecedented complexity. The Apollo program is a leading example of a systems engineering project. The use of the term "systems engineering" has evolved over time to embrace a wider, more holistic concept of "systems" and of engineering processes. This evolution of the definition has been a subject of ongoing controversy [11], and the term continues to be applied to both the narrower and broader scope.

Holistic view
Systems Engineering focuses on analyzing and eliciting customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, the system lifecycle. Oliver et al. claim that the systems engineering process can be decomposed into a Systems Engineering Technical Process, and a Systems Engineering Management Process. Within Oliver's model, the goal of the Management Process is to organize the technical effort in the lifecycle, while the Technical Process includes assessing available information, defining effectiveness measures, to create a behavior model, create a structure model, perform trade-off analysis, and create sequential build & test plan.[12] Depending on their application, although there are several models that are used in the industry, all of them aim to identify the relation between the various stages mentioned above and incorporate feedback. Examples of such models include the Waterfall model and the VEE model.[13]

Interdisciplinary field
System development often requires contribution from diverse technical disciplines.[14] By providing a systems (holistic) view of the development effort, systems engineering helps meld all the technical contributors into a unified team effort, forming a structured development process that proceeds from concept to production to operation and, in some cases, to termination and disposal. This perspective is often replicated in educational programs in that Systems Engineering courses are taught by faculty from other engineering departments which, in effect, helps create an interdisciplinary environment.[15] [16]

Managing complexity
The need for systems engineering arose with the increase in complexity of systems and projects. When speaking in this context, complexity incorporates not only engineering systems, but also the logical human organization of data. At the same time, a system can become more complex due to an increase in size as well as with an increase in the amount of data, variables, or the number of fields that are involved in the design. The International Space Station is an example of such a system.

Systems engineering The development of smarter control algorithms, microprocessor design, and analysis of environmental systems also come within the purview of systems engineering. Systems engineering encourages the use of tools and methods to better comprehend and manage complexity in systems. Some examples of these tools can be seen here:[17] Modeling and Simulation, Optimization, System dynamics, Systems analysis, Statistical analysis, Reliability analysis, and Decision making

267

Taking an interdisciplinary approach to engineering systems is inherently complex since the behavior of and interaction among system components is not always immediately well defined or understood. Defining and characterizing such systems and subsystems and the interactions among them is one of the goals of systems engineering. In doing so, the gap that exists between informal requirements from users, operators, marketing organizations, and technical specifications is successfully bridged.

Scope
One way to understand the motivation behind systems engineering is to see it as a method, or practice, to identify and improve common rules that exist within a wide variety of systems. Keeping this in mind, the principles of Systems Engineering holism, emergent behavior, boundary, et al. can be applied to any system, complex or otherwise, provided systems thinking is employed at all levels.[19] Besides defense and aerospace, many information and technology based companies, software development firms, and industries in the field of electronics & communications require Systems engineers as part of their

[18] The scope of Systems Engineering activities

team.[20] An analysis by the INCOSE Systems Engineering center of excellence (SECOE) indicates that optimal effort spent on Systems Engineering is about 15-20% of the total project effort.[21] At the same time, studies have shown that Systems Engineering essentially leads to reduction in costs among other benefits.[21] However, no quantitative survey at a larger scale encompassing a wide variety of industries has been conducted until recently. Such studies are underway to determine the effectiveness and quantify the benefits of Systems engineering.[22] [23] Systems engineering encourages the use of modeling and simulation to validate assumptions or theories on systems and the interactions within them.[24] [25] Use of methods that allow early detection of possible failures, in Safety engineering, are integrated into the design process. At the same time, decisions made at the beginning of a project whose consequences are not clearly understood can have enormous implications later in the life of a system, and it is the task of the modern systems

Systems engineering engineer to explore these issues and make critical decisions. There is no method which guarantees that decisions made today will still be valid when a system goes into service years or decades after it is first conceived but there are techniques to support the process of systems engineering. Examples include the use of soft systems methodology, Jay Wright Forrester's System dynamics method and the Unified Modeling Language (UML), each of which are currently being explored, evaluated and developed to support the engineering decision making process.

268

Education
Education in systems engineering is often seen as an extension to the regular engineering courses,[26] reflecting the industry attitude that engineering students need a foundational background in one of the traditional engineering disciplines (e.g. mechanical engineering, industrial engineering, computer engineering, electrical engineering) plus practical, real-world experience in order to be effective as systems engineers. Undergraduate university programs in systems engineering are rare. INCOSE maintains a continuously updated Directory of Systems Engineering Academic Programs worldwide.[5] As of 2006, there are about 75 institutions in United States that offer 130 undergraduate and graduate programs in systems engineering. Education in systems engineering can be taken as SE-centric or Domain-centric. SE-centric programs treat systems engineering as a separate discipline and all the courses are taught focusing on systems engineering practice and techniques. Domain-centric programs offer systems engineering as an option that can be exercised with another major field in engineering. Both these patterns cater to educate the systems engineer who is able to oversee interdisciplinary projects with the depth required of a core-engineer.[27]

Systems engineering topics

Systems engineering tools are strategies, procedures, and techniques that aid in performing systems engineering on a project or product. The purpose of these tools vary from database management, graphical browsing, simulation, and reasoning, to document production, neutral import/export and more.[28]

System
There are many definitions of what a system is in the field of systems engineering. Below are a few authoritative definitions: ANSI/EIA-632-1999: "An aggregation of end products and enabling products to achieve a given purpose."[29] IEEE Std 1220-1998: "A set or arrangement of elements and processes that are related and whose behavior satisfies customer/operational needs and provides for life cycle sustainment of the products."[30] ISO/IEC 15288:2008: "A combination of interacting elements organized to achieve one or more stated purposes."[31] NASA Systems Engineering Handbook: "(1) The combination of elements that function together to produce the capability to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose. (2) The end product (which performs operational functions) and enabling products (which provide life-cycle support services to the operational end products) that make up a system."[32] INCOSE Systems Engineering Handbook: "homogeneous entity that exhibits predefined behavior in the real world and is composed of heterogeneous parts that do not individually exhibit that behavior and an integrated configuration of components and/or subsystems."[33] INCOSE: "A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and

Systems engineering documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected."[34]

269

The systems engineering process

Depending on their application, tools are used for various stages of the systems engineering process:[18]

Using models
Models play important and diverse roles in systems engineering. A model can be defined in several ways, including:[35] An abstraction of reality designed to answer specific questions about the real world An imitation, analogue, or representation of a real world process or structure; or A conceptual, mathematical, or physical tool to assist a decision maker. Together, these definitions are broad enough to encompass physical engineering models used in the verification of a system design, as well as schematic models like a functional flow block diagram and mathematical (i.e., quantitative) models used in the trade study process. This section focuses on the last.[35] The main reason for using mathematical models and diagrams in trade studies is to provide estimates of system effectiveness, performance or technical attributes, and cost from a set of known or estimable quantities. Typically, a collection of separate models is needed to provide all of these outcome variables. The heart of any mathematical model is a set of meaningful quantitative relationships among its inputs and outputs. These relationships can be as simple as adding up constituent quantities to obtain a total, or as complex as a set of differential equations describing the trajectory of a spacecraft in a gravitational field. Ideally, the relationships express causality, not just

Systems engineering correlation.[35]

270

Tools for graphic representations

Initially, when the primary purpose of a systems engineer is to comprehend a complex problem, graphic representations of a system are used to communicate a system's functional and data requirements.[36] Common graphical representations include: Functional Flow Block Diagram (FFBD) Data Flow Diagram (DFD) N2 (N-Squared) Chart IDEF0 Diagram UML Use case diagram UML Sequence diagram USL Function Maps and Type Maps. Enterprise Architecture frameworks, like TOGAF, MODAF, Zachman Frameworks etc.

A graphical representation relates the various subsystems or parts of a system through functions, data, or interfaces. Any or each of the above methods are used in an industry based on its requirements. For instance, the N2 chart may be used where interfaces between systems is important. Part of the design phase is to create structural and behavioral models of the system. Once the requirements are understood, it is now the responsibility of a Systems engineer to refine them, and to determine, along with other engineers, the best technology for a job. At this point starting with a trade study, systems engineering encourages the use of weighted choices to determine the best option. A decision matrix, or Pugh method, is one way (QFD is another) to make this choice while considering all criteria that are important. The trade study in turn informs the design which again affects the graphic representations of the system (without changing the requirements). In an SE process, this stage represents the iterative step that is carried out until a feasible solution is found. A decision matrix is often populated using techniques such as statistical analysis, reliability analysis, system dynamics (feedback control), and optimization methods. At times a systems engineer must assess the existence of feasible solutions, and rarely will customer inputs arrive at only one. Some customer requirements will produce no feasible solution. Constraints must be traded to find one or more feasible solutions. The customers' wants become the most valuable input to such a trade and cannot be assumed. Those wants/desires may only be discovered by the customer once the customer finds that he has overconstrained the problem. Most commonly, many feasible solutions can be found, and a sufficient set of constraints must be defined to produce an optimal solution. This situation is at times advantageous because one can present an opportunity to improve the design towards one or many ends, such as cost or schedule. Various modeling methods can be used to solve the problem including constraints and a cost function. Systems Modeling Language (SysML), a modeling language used for systems engineering applications, supports the specification, analysis, design, verification and validation of a broad range of complex systems.[37] Universal Systems Language (USL) is a systems oriented object modeling language with executable (computer independent) semantics for defining complex systems, including software.[38]

Systems engineering

271

Closely related fields

Many related fields may be considered tightly coupled to systems engineering. These areas have contributed to the development of systems engineering as a distinct entity. Cognitive systems engineering Cognitive systems engineering (CSE) is a specific approach to the description and analysis of human-machine systems or sociotechnical systems.[39] The three main themes of CSE are how humans cope with complexity, how work is accomplished by the use of artefacts, and how human-machine systems and socio-technical systems can be described as joint cognitive systems. CSE has since its beginning become a recognised scientific discipline, sometimes also referred to as Cognitive Engineering. The concept of a Joint Cognitive System (JCS) has in particular become widely used as a way of understanding how complex socio-technical systems can be described with varying degrees of resolution. The experience with CSE has been described in two books that summarises the field after more than 20 years of work, namely[40] and [41] . Configuration Management Like Systems Engineering, Configuration Management as practiced in the defence and aerospace industry is a broad systems-level practice. The field parallels the taskings of Systems Engineering; where Systems Engineering deals with requirements development, allocation to development items and verification, Configuration Management deals with requirements capture, traceability to the development item, and audit of development item to ensure that it has achieved the desired functionality that Systems Engineering and/or Test and Verification Engineering have proven out through objective testing. Control engineering Control engineering and its design and implementation of control systems, used extensively in nearly every industry, is a large sub-field of Systems Engineering. The cruise control on an automobile and the guidance system for a ballistic missile are two examples. Control systems theory is an active field of applied mathematics involving the investigation of solution spaces and the development of new methods for the analysis of the control process. Industrial engineering Industrial engineering is a branch of engineering that concerns the development, improvement, implementation and evaluation of integrated systems of people, money, knowledge, information, equipment, energy, material and process. Industrial engineering draws upon the principles and methods of engineering analysis and synthesis, as well as mathematical, physical and social sciences together with the principles and methods of engineering analysis and design to specify, predict and evaluate the results to be obtained from such systems. Interface design Interface design and its specification are concerned with assuring that the pieces of a system connect and inter-operate with other parts of the system and with external systems as necessary. Interface design also includes assuring that system interfaces be able to accept new features, including mechanical, electrical and logical interfaces, including reserved wires, plug-space, command codes and bits in communication protocols. This is known as extensibility. Human-Computer Interaction (HCI) or Human-Machine Interface (HMI) is another aspect of interface design, and is a critical aspect of modern Systems Engineering. Systems engineering principles are applied in the design of network protocols for local-area networks and wide-area networks. Operations research Operations research supports systems engineering. The tools of operations research are used in systems analysis, decision making, and trade studies. Several schools teach SE courses within the operations research

Systems engineering or industrial engineering department, highlighting the role systems engineering plays in complex projects. operations research, briefly, is concerned with the optimization of a process under multiple constraints.[42] Reliability engineering Reliability engineering is the discipline of ensuring a system will meet the customer's expectations for reliability throughout its life; i.e. it will not fail more frequently than expected. Reliability engineering applies to all aspects of the system. It is closely associated with maintainability, availability and logistics engineering. Reliability engineering is always a critical component of safety engineering, as in failure modes and effects analysis (FMEA) and hazard fault tree analysis, and of security engineering. Reliability engineering relies heavily on statistics, probability theory and reliability theory for its tools and processes. Performance engineering Performance engineering is the discipline of ensuring a system will meet the customer's expectations for performance throughout its life. Performance is usually defined as the speed with which a certain operation is executed or the capability of executing a number of such operations in a unit of time. Performance may be degraded when an operations queue to be executed is throttled when the capacity is of the system is limited. For example, the performance of a packet-switched network would be characterised by the end-to-end packet transit delay or the number of packets switched within an hour. The design of high-performance systems makes use of analytical or simulation modeling, whereas the delivery of high-performance implementation involves thorough performance testing. Performance engineering relies heavily on statistics, queuing theory and probability theory for its tools and processes. Program management and project management. Program management (or programme management) has many similarities with systems engineering, but has broader-based origins than the engineering ones of systems engineering. Project management is also closely related to both program management and systems engineering. Safety engineering The techniques of safety engineering may be applied by non-specialist engineers in designing complex systems to minimize the probability of safety-critical failures. The "System Safety Engineering" function helps to identify "safety hazards" in emerging designs, and may assist with techniques to "mitigate" the effects of (potentially) hazardous conditions that cannot be designed out of systems. Security engineering Security engineering can be viewed as an interdisciplinary field that integrates the community of practice for control systems design, reliability, safety and systems engineering. It may involve such sub-specialties as authentication of system users, system targets and others: people, objects and processes. Software engineering From its beginnings Software engineering has helped shape modern Systems Engineering practice. The techniques used in the handling of complexes of large software-intensive systems has had a major effect on the shaping and reshaping of the tools, methods and processes of SE.

272

See also
Lists List of production topics List of systems engineers List of types of systems engineering List of systems engineering at universities Topics Management cybernetics Enterprise systems engineering System of systems engineering (SoSE)

Systems engineering

273

Further reading
Harold Chestnut, Systems Engineering Methods. Wiley, 1967. Harry H. Goode, Robert E. Machol System Engineering: An Introduction to the Design of Large-scale Systems, McGraw-Hill, 1957. David W. Oliver, Timothy P. Kelliher & James G. Keegan, Jr. Engineering Complex Systems with Models and Objects. McGraw-Hill, 1997. Simon Ramo, Robin K. St.Clair, The Systems Approach: Fresh Solutions to Complex Problems Through Combining Science and Practical Common Sense, Anaheim, CA: KNI, Inc, 1998. Andrew P. Sage, Systems Engineering. Wiley IEEE, 1992. Andrew P. Sage, Stephen R. Olson, Modeling and Simulation in Systems Engineering, 2001. Dale Shermon, Systems Cost Engineering [43], Gower publishing, 2009

External links
INCOSE [44] homepage. Systems Engineering Fundamentals. [45] Defense Acquisition University Press, 2001 Shishko, Robert et al. NASA Systems Engineering Handbook. [46] NASA Center for AeroSpace Information, 2005. Systems Engineering Handbook [47] NASA/SP-2007-6105 Rev1, December 2007. Derek Hitchins, World Class Systems Engineering [48], 1997. Parallel product alternatives and verification & validation activities [49].

References
[1] Schlager, J. (July 1956). "Systems engineering: key to modern development". IRE Transactions EM-3: 6466. doi:10.1109/IRET-EM.1956.5007383. [2] Arthur D. Hall (1962). A Methodology for Systems Engineering. Van Nostrand Reinhold. ISBN0442030460. [3] Andrew Patrick Sage (1992). Systems Engineering. Wiley IEEE. ISBN0471536393. [4] INCOSE Resp Group (11 June 2004). "Genesis of INCOSE" (http:/ / www. incose. org/ about/ genesis. aspx). . Retrieved 2006-07-11. [5] INCOSE Education & Research Technical Committee. "Directory of Systems Engineering Academic Programs" (http:/ / www. incose. org/ educationcareers/ academicprogramdirectory. aspx). . Retrieved 2006-07-11. [6] Systems Engineering Handbook, version 2a. INCOSE. 2004. [7] NASA Systems Engineering Handbook. NASA. 1995. SP-610S. [8] "Derek Hitchins" (http:/ / incose. org. uk/ people-dkh. htm). INCOSE UK. . Retrieved 2007-06-02. [9] Goode, Harry H.; Robert E. Machol (1957). System Engineering: An Introduction to the Design of Large-scale Systems. McGraw-Hill. p.8. LCCN56-11714. [10] Chestnut, Harold (1965). Systems Engineering Tools. Wiley. ISBN0471154482. [11] http:/ / citeseerx. ist. psu. edu/ viewdoc/ download?doi=10. 1. 1. 86. 7496& rep=rep1& type=pdf [12] Oliver, David W.; Timothy P. Kelliher, James G. Keegan, Jr. (1997). Engineering Complex Systems with Models and Objects. McGraw-Hill. pp.8594. ISBN0070481881. [13] "The SE VEE" (http:/ / www. gmu. edu/ departments/ seor/ insert/ robot/ robot2. html). SEOR, George Mason University. . Retrieved 2007-05-26. [14] Ramo, Simon; Robin K. St.Clair (1998) (PDF). The Systems Approach: Fresh Solutions to Complex Problems Through Combining Science and Practical Common Sense (http:/ / www. incose. org/ ProductsPubs/ DOC/ SystemsApproach. pdf). Anaheim, CA: KNI, Inc.. . [15] "Systems Engineering Program at Cornell University" (http:/ / systemseng. cornell. edu/ people. html). Cornell University. . Retrieved 2007-05-25. [16] "ESD Faculty and Teaching Staff" (http:/ / esd. mit. edu/ people/ faculty. html). Engineering Systems Division, MIT. . Retrieved 2007-05-25. [17] "Core Courses, Systems Analysis - Architecture, Behavior and Optimization" (http:/ / systemseng. cornell. edu/ CourseList. html). Cornell University. . Retrieved 2007-05-25. [18] Systems Engineering Fundamentals. (http:/ / www. dau. mil/ pubscats/ PubsCats/ SEFGuide 01-01. pdf) Defense Acquisition University Press, 2001 [19] Rick Adcock. "Principles and Practices of Systems Engineering" (http:/ / incose. org. uk/ Downloads/ AA01. 1. 4_Principles & practices of SE. pdf) (PDF). INCOSE, UK. . Retrieved 2007-06-07.

Systems engineering
[20] "Systems Engineering, Career Opportunities and Salary Information (1994)" (http:/ / www. gmu. edu/ departments/ seor/ insert/ intro/ introsal. html). George Mason University. . Retrieved 2007-06-07. [21] "Understanding the Value of Systems Engineering" (http:/ / www. incose. org/ secoe/ 0103/ ValueSE-INCOSE04. pdf) (PDF). . Retrieved 2007-06-07. [22] "Surveying Systems Engineering Effectiveness" (http:/ / www. splc. net/ programs/ acquisition-support/ presentations/ surveying. pdf) (PDF). . Retrieved 2007-06-07. [23] "Systems Engineering Cost Estimation by Consensus" (http:/ / www. valerdi. com/ cosysmo/ rvalerdi. doc). . Retrieved 2007-06-07. [24] Andrew P. Sage, Stephen R. Olson (2001). Modeling and Simulation in Systems Engineering (http:/ / intl-sim. sagepub. com/ cgi/ content/ abstract/ 76/ 2/ 90). SAGE Publications. . Retrieved 2007-06-02. [25] E.C. Smith, Jr. (1962) (PDF). Simulation in systems engineering (http:/ / www. research. ibm. com/ journal/ sj/ 011/ ibmsj0101D. pdf). IBM Research. . Retrieved 2007-06-02. [26] "Didactic Recommendations for Education in Systems Engineering" (http:/ / www. gaudisite. nl/ DidacticRecommendationsSESlides. pdf) (PDF). . Retrieved 2007-06-07. [27] "Perspectives of Systems Engineering Accreditation" (http:/ / sistemas. unmsm. edu. pe/ occa/ material/ INCOSE-ABET-SE-SF-21Mar06. pdf) (PDF). INCOSE. . Retrieved 2007-06-07. [28] Steven Jenkins. "A Future for Systems Engineering Tools" (http:/ / www. marc. gatech. edu/ events/ pde2005/ presentations/ 0. 2-jenkins. pdf) (PDF). NASA. pp. 15. . Retrieved 2007-06-10. [29] "Processes for Engineering a System", ANSI/EIA-632-1999, ANSI/EIA, 1999 (http:/ / webstore. ansi. org/ RecordDetail. aspx?sku=ANSI/ EIA-632-1999) [30] "Standard for Application and Management of the Systems Engineering Process -Description", IEEE Std 1220-1998, IEEE, 1998 (http:/ / standards. ieee. org/ reading/ ieee/ std_public/ description/ se/ 1220-1998_desc. html) [31] "Systems and software engineering - System life cycle processes", ISO/IEC 15288:2008, ISO/IEC, 2008 (http:/ / www. 15288. com/ ) [32] "NASA Systems Engineering Handbook", Revision 1, NASA/SP-2007-6105, NASA, 2007 (http:/ / education. ksc. nasa. gov/ esmdspacegrant/ Documents/ NASA SP-2007-6105 Rev 1 Final 31Dec2007. pdf) [33] "Systems Engineering Handbook", v3.1, INCOSE, 2007 (http:/ / www. incose. org/ ProductsPubs/ products/ sehandbook. aspx) [34] "A Consensus of the INCOSE Fellows", INCOSE, 2006 (http:/ / www. incose. org/ practice/ fellowsconsensus. aspx) [35] NASA (1995). "System Analysis and Modeling Issues". In: NASA Systems Engineering Handbook (http:/ / human. space. edu/ old/ docs/ Systems_Eng_Handbook. pdf) June 1995. p.85. [36] Long, Jim (2002) (PDF). Relationships between Common Graphical Representations in System Engineering (http:/ / www. vitechcorp. com/ whitepapers/ files/ 200701031634430. CommonGraphicalRepresentations_2002. pdf). Vitech Corporation. . [37] "OMG SysML Specification" (http:/ / www. sysml. org/ docs/ specs/ OMGSysML-FAS-06-05-04. pdf) (PDF). SysML Open Source Specification Project. pp. 23. . Retrieved 2007-07-03. [38] Hamilton, M. Hackler, W.R., A Formal Universal Systems Semantics for SysML, 17th Annual International Symposium, INCOSE 2007, San Diego, CA, June 2007. [39] Hollnagel E. & Woods D. D. (1983). Cognitive systems engineering: New wine in new bottles. International Journal of Man-Machine Studies, 18, 583-600. [40] Hollnagel, E. & Woods, D. D. (2005) Joint cognitive systems: The foundations of cognitive systems engineering. Taylor & Francis [41] Woods, D. D. & Hollnagel, E. (2006). Joint cognitive systems: Patterns in cognitive systems engineering. Taylor & Francis. [42] (see articles for discussion: (http:/ / www. boston. com/ globe/ search/ stories/ reprints/ operationeverything062704. html) and (http:/ / www. sas. com/ news/ sascom/ 2004q4/ feature_tech. html)) [43] http:/ / www. gowerpublishing. com/ isbn/ 978056688612 [44] http:/ / www. incose. org [45] http:/ / www. dau. mil/ pubscats/ PubsCats/ SEFGuide%2001-01. pdf [46] http:/ / ntrs. nasa. gov/ archive/ nasa/ casi. ntrs. nasa. gov/ 19960002194_1996102194. pdf [47] http:/ / education. ksc. nasa. gov/ esmdspacegrant/ Documents/ NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007. pdf [48] http:/ / www. hitchins. net/ WCSE. html [49] http:/ / www. inderscience. com/ search/ index. php?action=record& rec_id=25267

274

Portfolio manager

275

Portfolio manager
A ' team of analysts and researchers, and are ultimately responsible for establishing an investment strategy, selecting appropriate investments and allocating each investment properly for a fund- or asset-management vehicle. Portfolio managers are presented with investment ideas from internal buy-side analysts and sell-side analysts from investment banks. It is their job to sift through the relevant information and use their judgment to buy and sell securities. Throughout each day, they read reports, talk to company managers and monitor industry and economic trends looking for the right company and time to invest the portfolio's capital. Portfolio managers make decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against. performance. Portfolio management is about strengths, weaknesses, opportunities and threats in the choice of debt vs. equity, domestic vs. international, growth vs. safety, and other tradeoffs encountered in the attempt to maximize return at a given appetite for risk. In the case of mutual and exchange-traded funds (ETFs), there are two forms of portfolio management: passive and active. Passive management simply tracks a market index, commonly referred to as indexing or index investing. Active management involves a single manager, co-managers, or a team of managers who attempt to beat the market return by actively managing a fund's portfolio through investment decisions based on research and decisions on individual holdings. Closed-end funds are generally actively managed. That's what warren buffet says about investing in the market..."The basic ideas of investing are to look at stocks as business, use the market's fluctuations to your advantage, and seek a margin of safety"....

IT portfolio management
IT portfolio management is the application of systematic management to large classes of items managed by enterprise Information Technology (IT) capabilities. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios.

Overview
Debates exist on the best way to measure value of IT investment. As pointed out by Jeffery and Leliveld (2004) [1] , companies have spent billions of dollars on IT investments and yet the headlines of mis-spent money are not uncommon. Nicholas Carr (2003) has caused significant controversy in IT industry and academia by positioning IT as an expense similar to utilities such as electricity. IT portfolio management started with a project-centric bias, but is evolving to include steady-state portfolio entries such as application maintenance and support in portfolios is that IT budgets tend not to track these efforts at a sufficient level of granularity for effective financial tracking.[2] The concept is analogous to financial portfolio management, but there are significant differences. IT investments are not liquid, like stocks and bonds (although investment portfolios may also include illiquid assets), and are measured using both financial and non-financial yardsticks (for example, a balanced scorecard approach); a purely financial view is not sufficient. Financial portfolio assets typically have consistent measurement information (enabling accurate and objective comparisons), and this is at the base of the concepts usefulness in application to IT. However, achieving such universality of measurement is going to take considerable effort in the IT industry. (See Val IT.)

IT portfolio management IT Portfolio management is distinct from IT financial management in that it has an explicitly directive, strategic goal in determining what to continue investing in versus what to divest from. At its most mature, IT Portfolio management is accomplished through the creation of two portfolios: Application Portfolio - Management of this portfolio focuses on comparing spending on established systems based upon their relative value to the organization. The comparison can be based upon the level of contribution in terms of IT investments profitability. Additionally, this comparison can also be based upon the non-tangible factors such as organizations level of experience with a certain technology, users familiarity with the applications and infrastructure, and external forces such as emergence of new technologies and obsolescence of old ones. Project Portfolio - This type of portfolio management specially address the issues with spending on the development of innovative capabilities in terms of potential ROI and reducing investment overlaps in situations where reorganization or acquisition occurs. The management issues with the second type of portfolio management can be judged in terms of data cleanliness, maintenance savings, suitability of resulting solution and the relative value of new investments to replace these projects. Information Technology portfolio management as a systematic discipline is more applicable to larger IT organizations; in smaller organizations its concerns might be generalized into IT planning and governance as a whole.

276

Benefits of using IT portfolio management

Jeffery and Leliveld (2004) have listed several benefits of applying IT portfolio management approach for IT investments. They argue that agility of portfolio management is its biggest advantage over investment approaches and methods. Other benefits include central oversight of budget, risk management, strategic alignment of IT investments, demand and investment management along with standardization of investment procedure, rules and plans.

Implementing IT portfolio management

Jeffery and Leliveld (2004) have pointed out a number of hurdles and success factors that CIOs might face while attempting to implement IT portfolio management approach. To overcome these hurdles, simple methods such as proposed by Pisello (2001) can be used. -Planbuild retire Maintain Other implementation methods include (1) risk profile analysis (figure out what needs to be measured and what risks are associated with it), (2) Decide on the Diversification of projects, infrastructure and technologies (it is an important tool that IT portfolio management provides to judge the level of investments on the basis of how investments should be made in various elements of the portfolio), (3) Continuous Alignment with business goals (highest levels of organizations should have a buy-in in the portfolio) and (4) Continuous Improvement (lessons learned and investment adjustments). There is no single best way to implement IT portfolio approach and therefore variety of approaches can applied. Obviously the methods are not set in stone and will need altering depending upon the individual circumstances of

IT portfolio management different organizations.

277

IT portfolio management vs. balanced scorecard

The biggest advantage of IT portfolio management is the agility of the investment adjustments. While balanced scorecards also emphasize the use of vision and strategy in any investment decision, oversight and control of operation budgets is not the goal. IT portfolio management allows organizations to adjust the investments based upon the feedback mechanism built into the IT portfolio management.

History
One of the earliest uses of portfolio concepts is found in Gibson and Nolan's Managing the Four Stages of EDP Growth in 1973 [3] . Gibson and Nolan proposed that IT advances in observable stages driven by four "growth processes" of which the Applications Portfolio was key. Their concepts were operationalized at Nolan, Norton & Co. with measures of application coverage of business functions, applications functional and technical qualities, applications age and spending. McFarlan [4] proposed a different portfolio management approach to IT assets and investments. Further contributions have been made by Weill and Broadbent,[5] , Aitken,[6] Kaplan, [2] and Benson, Bugnitz, and Walton[7] . The ITIL version 2 Business Perspective[8] and Application Management[9] volumes and the ITIL v3 Service Strategy volume also cover it in depth. Various vendors have offerings explicitly branded as "IT Portfolio Management" solutions. ISACA's Val IT framework is perhaps the first attempt at standardization of IT portfolio management principles. In peer-reviewed research, Christopher Verhoef has found that IT portfolios statistically behave more akin to biological populations than financial portfolios.[10] Verhoef was general chair of the first convening of the new IEEE conference, "IEEE Equity," March 2007, which focuses on "quantitative methods for measuring, predicting, and understanding the relationship between IT and value."[11]

McFarlan's IT portfolio matrix

High ^ |---------------------------------------------------------------| |strategic Impact of IS/IT applications on future industry | | |Central Planning competitiveness | |Critical to achieving |future business strategy. (Developer) | | Turnaround |May be critical to |achieving future |business success (Entrepreneur) | | | | | | | | | |---------------------------------------------------------------|

|Leading Edge/Free Market

|---------------------------------------------------------------| |Critical to existing business |operations | | |Monopoly |Factory (Controller) | |Scarce Resource | Support | | |Valuable but not critical | | | | (Caretaker) |to success

|_______________________________|_______________________________|

IT portfolio management
|<---------------------------------------------------------------Low High Value to the business of existing applications.

278

Relationship to other IT disciplines

IT portfolio management is an enabling technique for the objectives of IT Governance. It is related to both IT Service Management and Enterprise Architecture, and might even be seen as a bridge between the two. ITIL v3 calls for Service Portfolio Management which appears to be functionally equivalent.

See also
Application Portfolio Management Enterprise Architecture Integrated Business Planning IT Governance Project Portfolio Management

Val IT

Further reading
Sanwal, Anand (2007). Optimizing Corporate Portfolio Management: Aligning Investment Proposals with Organizational Strategy [6]. Wiley. ISBN978-0-470-12688-2.

References
[1] Jeffery, M., & Leliveld, I. (2004). Best Practices in IT Portfolio Management. MIT Sloan Management Review. 45 (3), 41. http:/ / sloanreview. mit. edu/ the-magazine/ articles/ 2004/ spring/ 45309/ best-practices-in-it-portfolio-management [2] Kaplan, J. D. (2005). Strategic IT portfolio support, which consume the bulk of IT spending. The challenge for including application maintenance and suppofolio management : governing enterprise transformation. United States, Pittiglio Rabin Todd & McGrath Inc. [3] Managing the Four Stages of EDP Growth Publication date: Jan 01, 1974. Prod. #: 74104-PDF-ENG [4] McFarlan, F. W. (1981). Portfolio approach to information systems. Harvard Business Review (September-October 1981): 142-150 [5] Weill, P. and Broadbent, M. (1998). Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology. Cambridge, Massachusetts, Harvard Business School Press. [6] Aitken, I. (2003). Value-driven IT management. D. Remenyi, Computer Weekly Professional Series. Oxford, Butterworth Heinemann. [7] Benson, R. J., T. L. Bugnitz, et al. (2004). From business strategy to IT action : right decisions for a better bottom line. Hoboken, N.J., Wiley [8] Office of Government Commerce (2004). Business Perspective: The IS View on Delivering Services to the Business. OGC, ITIL Managing IT Services (IT Infrastructure Library). London, The Stationery Office. [9] Office of Government Commerce (2002). Application management. OGC, ITIL Managing IT Services (IT Infrastructure Library). London, The Stationery Office. [10] Verhoef, Christopher, "Quantitative IT portfolio management," Science of Computer Programming, Volume 45, Issue 1, pages 196 (October 2002). [11] http:/ / www. cs. vu. nl/ equity2007/ index. php?id=1

Human factors

279

Human factors
Human factors science or human factors technologies is a multidisciplinary field incorporating contributions from psychology, engineering, industrial design, statistics, operations research and anthropometry. It is a term that covers: The science of understanding the properties of human capability (Human Factors Science). The application of this understanding to the design, development and deployment of systems and services (Human Factors Engineering). The art of ensuring successful application of Human Factors Engineering to a program (sometimes referred to as Human Factors Integration). It can also be called ergonomics. In general, a human factor is a physical or cognitive property of an individual or social behavior which is specific to humans and influences functioning of technological systems as well as human-environment equilibriums. In social interactions, the use of the term human factor stresses the social properties unique to or characteristic of humans. Human factors involves the study of all aspects of the way humans relate to the world around them, with the aim of improving operational performance, safety, through life costs and/or adoption through improvement in the experience of the end user. The terms human factors and ergonomics have only been widely used in recent times; the field's origin is in the design and use of aircraft during World War II to improve aviation safety. It was in reference to the psychologists and physiologists working at that time and the work that they were doing that the terms "applied psychology" and ergonomics were first coined. Work by Elias Porter, Ph.D. and others within the RAND Corporation after WWII extended these concepts. "As the thinking progressed, a new concept developed - that it was possible to view an organization such as an air-defense, man-machine system as a single organism and that it was possible to study the behavior of such an organism. It was the climate for a breakthrough."[1] Specialisations within this field include cognitive ergonomics, usability, human computer/human machine interaction, and user experience engineering. New terms are being generated all the time. For instance, user trial engineer may refer to a human factors professional who specialises in user trials. Although the names change, human factors professionals share an underlying vision that through application of an understanding of human factors the design of equipment, systems and working methods will be improved, directly affecting peoples lives for the better. Human factors practitioners come from a variety of backgrounds, though predominantly they are psychologists (engineering, cognitive, perceptual, and experimental) and physiologists. Designers (industrial, interaction, and graphic), anthropologists, technical communication scholars and computer scientists also contribute. Though some practitioners enter the field of human factors from other disciplines, both M.S. and Ph.D. degrees in Human Factors Engineering are available from several universities worldwide.

The Formal History of American Human Factors Engineering

The formal history describes activities in known chronological order. This can be divided into 5 markers:
[2]

Developments prior to World War I Developments during World War I Developments between World War I and World War II Developments during World War II Developments after World War II

Developments prior to World War I: Prior to WWI the only test of human to machine compatibility was that of

Human factors trial and error. If the human functioned with the machine, he was accepted, if not he was rejected. There was a significant change in the concern for humans during the American civil war. The US patent office was concerned whether the mass produced uniforms and new weapons could be used by the infantry men. The next development was when the American inventor Simon Lake tested submarine operators for psychological factors, followed by the scientific study of the worker. This was an effort dedicated to improve the efficiency of humans in the work place. These studies were designed by F W Taylor. The next step was the derivation of formal time and motion study from the studies of Frank Gilbreth, Sr. and Lillian Gilbreth. Developments during World War I: With the onset of WWI, more sophisticated equipment was developed. The inability of the personnel to use such systems led to an increase in interest in human capability. Earlier the focus of aviation psychology was on the aviator himself. But as time progressed the focus shifted onto the aircraft, in particular, the design of controls and displays, the effects of altitude and environmental factors on the pilot. The war saw the emergence of aeromedical research and the need for testing and measurement methods. Still, the war did not create a Human Factors Engineering (HFE) discipline, as such. The reasons attributed to this are that technology was not very advanced at the time and America's involvement in the war only lasting for 18 months.[2] Developments between World War I and World War II: This period saw relatively slow development in HFE. Although, studies on driver behaviour started gaining momentum during this period, as Henry Ford started providing millions of Americans with automobiles. Another major development during this period was the performance of aeromedical research. By the end of WWI, two aeronautical labs were established, one at Brooks Airforce Base, Texas and the other at Wright field outside of Dayton, Ohio. Many tests were conducted to determine which characteristic differentiated the successful pilots from the unsuccessful ones. During the early 1930s, Edwin Link developed the first flight simulator. The trend continued and more sophisticated simulators and test equipment were developed. Another significant development was in the civilian sector, where the effects of illumination on worker productivity were examined. This led to the identification of the 'Hawthorne Effect', which suggested that motivational factors could significantly influence human performance.[2] Developments during World War II: With the onset of the WW II, it was no longer possible to adopt the Tayloristic principle of matching individuals to preexisting jobs. Now the design of equipment had to take into account human limitations and take advantage of human capabilities. This change took time to come into place. There was a lot of research conducted to determine the human capabilities and limitations that had to be accomplished. A lot of this research took off where the aeromedical research between the wars had left off. An example of this is the study done by Fitts and Jones (1947), who studied the most effective configuration of control knobs to be used in aircraft cockpits. A lot of this research transcended into other equipment with the aim of making the controls and displays easier for the operators to use. After the war, the Army Air Force published 19 volumes summarizing what had been established from research during the war.[2] Developments after World War II: In the initial 20 years after the WW II, most activities were done by the founding fathers: Alphonse Chapanis, Paul Fitts, and Small. The beginning of cold war led to a major expansion of Defense supported research laboratories. Also, a lot of labs established during the war started expanding. Most of the research following the war was military sponsored. Large sums of money were granted to universities to conduct research. The scope of the research also broadened from small equipments to entire workstations and systems. Concurrently, a lot of opportunities started opening up in the civilian industry. The focus shifted from research to participation through advice to engineers in the design of equipment. After 1965, the period saw a maturation of the discipline. The field has expanded with the development of the computer and computer applications.[2]

280

Human factors

281

The Cycle of Human Factors

Human Factors involves the study of factors and development of tools that facilitate the achievement of these goals. In the most general sense, the three goals of human factors are accomplished through several procedures in the human factors cycle, which depicts the human operator (brain and body) and the system with which he or she is interacting. First it is necessary to diagnose or identify the problems and deficiencies in the human-system interaction of an existing system. After defining the problems there are five different approaches that can be used in order to implement the solution. These are as follows: Equipment Design: changes the nature of the physical equipment with which humans work. Task Design: focuses more on changing what operators do than on changing the devices they use. This may involve assigning part or all of tasks to other workers or to automated components. Environmental Design: implements changes, such as improved lighting, temperature control and reduced noise in the physical environment where the task is carried out. Training the individuals: better preparing the worker for the conditions that he or she will encounter in the job environment by teaching and practicing the necessary physical or mental skills. Selection of individuals: is a technique that recognizes the individual differences across humans in every physical and mental dimension that is relevant for good system performance. Such a performance can be optimized by selecting operators who possess the best profile of characteristics for the job.

Human Factors Science

Human factors are sets of human-specific physical, cognitive, or social properties which either may interact in a critical or dangerous manner with technological systems, the human natural environment, or human organizations, or they can be taken under consideration in the design of ergonomic human-user oriented equipment. The choice or identification of human factors usually depends on their possible negative or positive impact on the functioning of human-organizations and human-machine systems.

The human-machine model

see also: human-machine system The simple human-machine model is a person interacting with a machine in some kind of environment. The person and machine are both modeled as information-processing devices, each with inputs, central processing, and outputs. The inputs of a person are the senses (e.g., eyes, ears) and the outputs are effectors (e.g., hands, voice). The inputs of a machine are input control devices (e.g., keyboard, mouse) and the outputs are output display devices (e.g., screen, auditory alerts). The environment can be characterized physically (e.g., vibration, noise, zero-gravity), cognitively (e.g., time pressure, uncertainty, risk), and/or organizationally (e.g., organizational structure, job design). This provides a convenient way for organizing some of the major concerns of human engineering: the selection and design of machine displays and controls; the layout and design of workplaces; design for maintainability; and the design of the work environment. Example: Driving an automobile is a familiar example of a simple man-machine system. In driving, the operator receives inputs from outside the vehicle (sounds and visual cues from traffic, obstructions, and signals) and from displays inside the vehicle (such as the speedometer, fuel indicator, and temperature gauge). The driver continually evaluates this information, decides on courses of action, and translates those decisions into actions upon the vehicle's controlsprincipally the accelerator, steering wheel, and brake. Finally, the driver is influenced by such environmental factors as noise, fumes, and temperature. No matter how important it may be to match an individual operator to a machine, some of the most challenging and complex human problems arise in the design of large man-machine systems and in the integration of human operators into these systems. Examples of such large systems are a modern jet airliner, an automated post office, an

Human factors industrial plant, a nuclear submarine, and a space vehicle launch and recovery system. In the design of such systems, human-factors engineers study, in addition to all the considerations previously mentioned, three factors: personnel, training, and operating procedures. Personnel are trained; that is, they are given appropriate information and skills required to operate and maintain the system. System design includes the development of training techniques and programs and often extends to the design of training devices and training aids. Instructions, operating procedures, and rules set forth the duties of each operator in a system and specify how the system is to function. Tailoring operating rules to the requirements of the system and the people in it contributes greatly to safe, orderly, and efficient operations.

282

Human Factors Engineering

Human Factors Engineering (HFE) is the discipline of applying what is known about human capabilities and limitations to the design of products, processes, systems, and work environments. It can be applied to the design of all systems having a human interface, including hardware and software. Its application to system design improves ease of use, system performance and reliability, and user satisfaction, while reducing operational errors, operator stress, training requirements, user fatigue, and product liability. HFE is distinctive in being the only discipline that relates humans to technology. Human factors engineering focuses on how people interact with tasks, machines (or computers), and the environment with the consideration that humans have limitations and capabilities. Human factors engineers evaluate "Human to Human," "Human to Group," "Human to Organizational," and "Human to Machine (Computers)" interactions to better understand these interactions and to develop a framework for evaluation. Human Factors engineering activities include: 1. Usability assurance 2. Determination of desired user profiles 3. Development of user documentation 4. Development of training programs.

Usability assurance
Usability assurance is an interdisciplinary concept, integrating system engineering with Human Factors engineering methodologies. Usability assurance is achieved through the system or service design, development, evaluation and deployment. User interface design comprises physical (ergonomic) design, interaction design and layout design. Usability development comprises integration of human factors in project planning and management, including system specification documents: requirements, design and testing. Usability evaluation is a continuous process, starting with the operational requirements specification, through prototypes of the user interfaces, through usability alpha and beta testing, and through manual and automated feedback after the system has been deployed.

Human factors User Interface Design Human-computer interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them. This is a well known subject of Human Factors within the Engineering field. There are many different ways to determine human computer interaction at the user interface by usability testing. Human Factors Evaluation Methods Human Factors evaluation methods are part of Human Factors methodology, which is part of Human Factors Engineering. Besides evaluation, Human Factors Engineering also deals with methods for usability assurance, for assessing desired user profiles, for developing user documentation and training programs, etc. Until recently, methods used to evaluate human factors ranged from simple questionnaires to more complex and expensive usability labs[3] . Recently, new methods were proposed, based on analysis of logs of the activity of the system users. Actually, the work in usability labs and that of the new methods is part of Usability Engineering, which is part of Human Factors Engineering. Brief Summary of Human Factors Evaluation Methods Ethnographic analysis: Using methods derived from ethnography, this process focuses on observing the uses of technology in a practical environment. It is a qualitative and observational method that focuses on "real-world" experience and pressures, and the usage of technology or environments in the workplace. The process is best used early in the design process.[4] Focus Groups: Focus groups are another form of qualitative research in which one individual will facilitate discussion and elicit opinions about the technology or process under investigation. This can be on a one to one interview basis, or in a group session. Can be used to gain a large quantity of deep qualitative data,[5] though due to the small sample size, can be subject to a higher degree of individual bias.[6] Can be used at any point in the design process, as it is largely dependent on the exact questions to be pursued, and the structure of the group. Can be extremely costly. Iterative design: Also known as prototyping, the iterative design process seeks to involve users at several stages of design, in order to correct problems as they emerge. As prototypes emerge from the design process, these are subjected to other forms of analysis as outlined in this article, and the results are then taken and incorporated into the new design. Trends amongst users are analyzed, and products redesigned. This can become a costly process, and needs to be done as soon as possible in the design process before designs become too concrete.[4] Meta-analysis: A supplementary technique used to examine a wide body of already existing data or literature in order to derive trends or form hypotheses in order to aid design decisions. As part of a literature survey, a meta-analysis can be performed in order to discern a collective trend from individual variables.[6] Subjects-in-tandem: Two subjects are asked to work concurrently on a series of tasks while vocalizing their analytical observations. This is observed by the researcher, and can be used to discover usability difficulties. This process is usually recorded. Surveys and Questionnaires: A commonly used technique outside of Human Factors as well, surveys and questionnaires have an advantage in that they can be administered to a large group of people for relatively low cost, enabling the researcher to gain a large amount of data. The validity of the data obtained is, however, always in question, as the questions must be written and interpreted correctly, and are, by definition, subjective. Those who actually respond are in effect self-selecting as well, widening the gap between the sample and the population further.[6]

283

Human factors Task analysis: A process with roots in activity theory, task analysis is a way of systematically describing human interaction with a system or process to understand how to match the demands of the system or process to human capabilities. The complexity of this process is generally proportional to the complexity of the task being analyzed, and so can vary in cost and time involvement. It is a qualitative and observational process. Best used early in the design process.[6] Think aloud protocol: Also known as "concurrent verbal protocol", this is the process of asking a user to execute a series of tasks or use technology, while continuously verbalizing their thoughts so that a researcher can gain insights as to the users' analytical process. Can be useful for finding design flaws that do not affect task performance, but may have a negative cognitive affect on the user. Also useful for utilizing experts in order to better understand procedural knowledge of the task in question. Less expensive than focus groups, but tends to be more specific and subjective.[7] User analysis: This process is based around designing for the attributes of the intended user or operator, establishing the characteristics that define them, creating a persona for the user. Best done at the outset of the design process, a user analysis will attempt to predict the most common users, and the characteristics that they would be assumed to have in common. This can be problematic if the design concept does not match the actual user, or if the identified are too vague to make clear design decisions from. This process is, however, usually quite inexpensive, and commonly used.[6] "Wizard of Oz": This is a comparatively uncommon technique but has seen some use in mobile devices. Based upon the Wizard of Oz experiment, this technique involves an operator who remotely controls the operation of a device in order to imitate the response of an actual computer program. It has the advantage of producing a highly changeable set of reactions, but can be quite costly and difficult to undertake. Problems with Human Factors Methods Problems in how usability measures are employed include: (1) measures of learning and retention of how to use an interface are rarely employed during methods and (2) some studies treat measures of how users interact with interfaces as synonymous with quality-in-use, despite an unclear relation.[8] Weakness of Usability Lab Testing Although usability lab testing is believed to be the most influential evaluation method, it does have some limitations. These limitations include: (1) Additional resources and time than other methods (2) Usually only examines a fraction of the entire market segment (3) Test scope is limited to the sample tasks chosen (4) Long term ease-of-use problems are difficult to identify (5) May reveal only a fraction of total problems (6) Laboratory setting excludes factors that the operational environment places on the products usability Weakness of Inspection Methods Inspection methods (expert reviews and walkthroughs) can be accomplished quickly, without resources from outside the development team, and does not require the research expertise that usability tests need. However, inspection methods do have limitations, which include: (1) Do not usually directly involve users (2) Often do not involve developers (3) Set up to determine problems and not solutions (4) Do not foster innovation or creative solutions (5) Not good at persuading developers to make product improvements

284

Human factors Weakness of Surveys, Interviews, and Focus Groups These traditional human factors methods have been adapted, in many cases, to assess product usability. Even though there are several surveys that are tailored for usability and that have established validity in the field, these methods do have some limitations, which include: (1) Reliability of all surveys is low with small sample sizes (10 or less) (2) Interview lengths restricts use to a small sample size (3) Use of focus groups for usability assessment has highly debated value (4) All of these methods are highly dependent on the respondents Weakness of Field Methods Although field methods can be extremely useful because they are conducted in the users natural environment, they have some major limitations to consider. The limitations include: (1) Usually take more time and resources than other methods (2) Very high effort in planning, recruiting, and executing than other methods (3) Much longer study periods and therefore requires much goodwill among the participants (4) Studies are longitudinal in nature, therefore, attrition can become a problem[9] .

285

Application of Human Factors Engineering

An Example: Human Factors Engineering Applied to the Military
Before World War II, HFE had no significance in the design of machines. Consequently, many fatal human errors during the war were directly or indirectly related to the absence of comprehensive HFE analyses in the design and manufacturing process. One of the reasons for so many costly errors was the fact that the capabilities of the human were not clearly differentiated from those of the machine. Furthermore, human performance capabilities, skill limitation, and response tendencies were not adequately considered in the designs of the new systems that were being produced so rapidly during the war. For example, pilots were often trained on one generation of aircraft, but by the time they got to the war zone, they were required to fly a newer model. The newer model was usually more complex than the older one and, even more detrimental, the controls may have had opposing functions assigned to them. Some aircraft required that the control stick be pulled back toward the pilot in order to pull the nose up. In other aircraft the exact opposite was required; namely, in order to ascend you would push the stick away from you. Needless to say, in an emergency situation many pilots became confused and performed the incorrect maneuver, with disastrous results. Along the same line, pilots were subject to substitution errors due mostly to lack of uniformity of control design, inadequate separation of controls, or the lack of a coding system to help the pilot identify controls by the sense of touch alone. For example, in the early days of retractable landing gear, pilots often grabbed the wrong lever and mistakenly raised the landing gear instead of the flaps. Sensory overload also became a problem, especially in cockpit design. The 1950s brought a strong program of standardizing control shapes, locations and overload management. The growth of human factors engineering during the mid- to late-forties was evidenced by the establishment of several organizations to conduct psychological research on equipment design. Toward the end of 1945, Paul Fitts established what came to be known as the Behavioral Sciences Laboratory at the Army Corps Aeromedical Laboratory in Dayton, Ohio. Around the same time, the U.S. Navy established the Naval Research Laboratory at Anacostia, Maryland (headed by Frank V. Taylor), and the Navy Special Devices Center at Port Washington, New York (headed by Leonard C. Mead). The Navy Electronics Laboratory in San Diego, California, was established about a year later with Arnold M. Small as head.

Human factors In addition to the establishment of these military organizations, the human factors discipline expanded within several civilian activities. Contract support was provided by the U.S. Navy and the U.S. Air Force for research at several noted universities, specifically Johns Hopkins, Tufts, Harvard, Maryland, Holyoke, and California (Berkeley). Paralleling this growth was the establishment of several private corporate ventures. Thus, as a direct result of the efforts of World War II, a new industry known as engineering psychology or human factors engineering was born.

286

Why is HFE important to the military?

Until today, many project managers and designers are still slow to consider Human Factors Engineering (HFE) as an essential and integral part of the design process. This is sometimes due to their lack of education on the purpose of HFE, in other instances it is due to others being perfectly capable of considering HFE related issues. Nevertheless, progress is being made as HFE is becoming more and more accepted and is now implemented in a wide variety of applications and processes. The U.S. military is particularly concerned with the implementation of HFE in every phase of the acquisition process of its systems and equipment. Just about every piece of gear, from a multi-billion dollar aircraft carrier to the boots that Servicemembers wear, goes at least in part through some HFE analyses before procurement and throughout its lifecycle. Lessons learned in the aftermath of World War II prompted the U.S. War Department (now U.S. Department of Defense) to take some steps in improving safety in military operations. U.S. Department of Defense regulations require a comprehensive management and technical strategy for human systems integration (HSI)[10] be initiated early in the acquisition process to ensure that human performance is considered throughout the system design and development process.[11]

HFE applications in the U.S. Army

In the U.S. Army, the term MANPRINT is used as the program designed to implement HSI.[12] [13] The program was established in 1984 with a primary objective to place the human element (functioning as individual, crew/team, unit and organization) on an equal footing with other design criteria such as hardware and software. The entry point of MANPRINT in the acquisition process is through requirements documents and studies. What is MANPRINT? MANPRINT (Manpower and Personnel Integration) is a comprehensive management and technical program that focuses attention on human capabilities and limitations throughout the systems life cycle: concept development, test and evaluation, documentation, design, development, fielding, post-fielding, operation and modernization of systems. It was initiated in recognition of the fact that the human is an integral part of the total system. If the human part of the system can't perform efficiently, the entire system will function sub-optimally. MANPRINT's goal is to optimize total system performance at acceptable cost and within human constraints. This is achieved by the continuous integration of seven human-related considerations (known as MANPRINT domains) with the hardware and software components of the total system and with each other, as appropriate. The seven MANPRINT domains are: Manpower (M), Personnel (P), Training (T), Human Factors Engineering (HFE), System Safety (SS), Health Hazards (HH), Soldier Survivability (SSv). They are each expounded on below: Manpower (M) Manpower addresses the number of military and civilian personnel required and potentially available to operate, maintain, sustain, and provide training for systems.[14] It is the number of personnel spaces (required or authorized positions) and available people (operating strength). It considers these requirements for peacetime, conflict, and low intensity operations. Current and projected constraints on the total size of the Army/organization/unit are also considered. The MANPRINT practitioner evaluates the manpower required and/or available to support a new system and subsequently considers these constraints to ensure that the human resource demands of the system do not exceed the projected supply.

Human factors Personnel (P) Manpower and personnel are closely related. While manpower looks at numbers of spaces and people, the domain of personnel addresses the cognitive and physical characteristics and capabilities required to be able to train for, operate, maintain, and sustain materiel and information systems. Personnel capabilities are normally reflected as knowledge, skills, abilities, and other characteristics (KSAOs). The availability of personnel and their KSAOs should be identified early in the acquisition process and may result in specific thresholds. On most systems, emphasis is placed on enlisted personnel as the primary operators, maintainers, and supporters of the system. Personnel characteristics of enlisted personnel are easier to quantify since the Armed Services Vocational Aptitude Battery (ASVAB) is administered to potential enlistees. While normally enlisted personnel are operators and maintainers; that is not always the case, especially in aviation systems. Early in the requirements determination process, identification of the target audience should be accomplished and used as a baseline for assessment. Cognitive and physical demands of the system should be assessed and compared to the projected supply. MANPRINT also takes into consideration personnel factors such as availability, recruitment, skill identifiers, promotion, and assignment. Training (T) Training is defined as the instruction or education, on-the-job, or self development training required to provide all personnel and units with their essential job skills, and knowledge. Training is required to bridge the gap between the target audiences' existing level of knowledge and that required to effectively operate, deploy/employ, maintain and support the system. The MANPRINT goal is to acquire systems that meet the Army's training thresholds for operation and maintenance. Key considerations include developing an affordable, effective and efficient training strategy (which addresses new equipment, training devices, institutional, sustainment, and unit collective tactical training); determining the resources required to implement it in support of fielding and the most efficient method for dissemination (contractor, distance learning, exportable packages, etc.); and evaluating the effectiveness of the training. Training is particularly crucial in the acquisition and employment of a new system. New tasks may be introduced into a duty position; current processes may be significantly changed; existing job responsibilities may be redefined, shifted, or eliminated; and/or entirely new positions may be required. It is vital to consider the total training impact of the system on both the individuals and the organization as a whole. Human Factors Engineering (HFE) The goal of HFE is to maximize the ability of an individual or crew to operate and maintain a system at required levels by eliminating design-induced difficulty and error. Human factors engineers work with systems engineers to design and evaluate human-system interfaces to ensure they are compatible with the capabilities and limitations of the potential user population. HFE is conducted during all phases of system development, to include requirements specification, design and testing and evaluation. HFE activities during requirements specification include: evaluating predecessor systems and operator tasks; analyzing user needs; analyzing and allocating functions; and analyzing tasks and associated workload. During the design phase, HFE activities include: evaluating alternative designs through the use of equipment mockups and software prototypes; evaluating software by performing usability testing; refining analysis of tasks and workload; and using modeling tools such as human figure models to evaluate crew station and workplace design and operator procedures. During the testing and evaluation phase, HFE activities include: confirming the design meets HFE specification requirements; measuring operator task performance; and identifying any undesirable design or procedural features. System Safety (SS) System Safety is the design features and operating characteristics of a system that serve to minimize the potential for human or machine errors or failures that cause injurious accidents. Safety considerations should be applied in system acquisition to minimize the potential for accidental injury of personnel and mission failure.

287

Human factors Health Hazards (HH) Health Hazards addresses the design features and operating characteristics of a system that create significant risks of bodily injury or death. Along with safety hazards, an assessment of health hazards is necessary to determine risk reduction or mitigation. The goal of the Health Hazard Assessment (HHA) is to incorporate biomedical knowledge and principles early in the design of a system to eliminate or control health hazards. Early application will eliminate costly system retrofits and training restrictions resulting in enhanced soldier-system performance, readiness and cost savings. HHA is closely related to occupational health and preventive medicine but gets its distinctive character from its emphasis on soldier-system interactions of military unique systems and operations. Health Hazard categories include acoustic energy, biological substances, chemical substances, oxygen deficiency, radiation energy, shock, temperature extremes and humidity, trauma, vibration, and other hazards. Health hazards include those areas that could cause death, injury, illness, disability, or a reduction in job performance. Organisational and Social The seventh domain addresses the human factors issues associated with the socio-technical systems necessary for modern warfare. This domain has been recently added to investigate issues specific to Network Enabled Capability (NEC) also known as Network Centric Warfare (NCW). Elements such as dynamic command and control structures, data assimilation across mulitple platforms and its fusion into information easily understood by distributed operators are some of the issues investigated. A soldier survivability domain was also proposed but this was never fully integrated into the MANPRINT model. Domain Integration Although each of the MANPRINT domains has been introduced separately, in practice they are often interrelated and tend to impact on one another. Changes in system design to correct a deficiency in one MANPRINT domain nearly always impact another domain.

288

Human Factors Integration

Areas of interest for human factors practitioners may include: training, staffing evaluation, communication, task analyses, functional requirements analyses and allocation, job descriptions and functions, procedures and procedure use, knowledge, skills, and abilities; organizational culture, human-machine interaction, workload on the human, fatigue, situational awareness, usability, user interface, learnability, attention, vigilance, human performance, human reliability, human-computer interaction, control and display design, stress, visualization of data, individual differences, aging, accessibility, safety, shift work, work in extreme environments including virtual environments, human error, and decision making.

Real World Applications of Human Factors - MultiModal Interfaces

Multi-Modal Interfaces In many real world domains, ineffective communication occurs partially because of inappropriate and ineffective presentation of information. Many real world interfaces both allow user input and provide user output in a single modality (most often being either visual or auditory). This single modality presentation can often lead to data overload in that modality causing the user to become overwhelmed by information and cause him/her to overlook something. One way to address this issue is to use multi-modal interfaces. Reasons to Use Multimodal Interfaces Time Sharing helps avoid overloading one single modality Redundancy providing the same information in two different modalities helps assure that the user will see the information Allows for more diversity in users (blind can use tactile input; hearing impaired can use visual input and output)

Human factors Error Prevention having multiple modalities allows the user to choose the most appropriate modality for each task (for example, spatial tasks are best done in a visual modality and would be much harder in an olfactory modality) Examples of Well Known Multi-Modality Interfaces Cell Phone The average cell phone uses auditory, visual, and tactile output through use of a phone ringing, vibrating, and a visual display of caller ID. ATM Both auditory and visual outputs Early Multi-Modal Interfaces by the Experts Bolts Put That There 1980 used speech and manual pointing Cohen and Oviatts Quickset multi user speech and gesture input

289

Worker Safety and Health

One of the most prevalent types of work-related injuries are musculoskeletal disorders. Work-related musculoskeletal disorders (WRMDs) result in persistent pain, loss of functional capacity and work disability, but their initial diagnosis is difficult because they are mainly based on complaints of pain and other symptoms.[15] Every year 1.8 million U.S. workers experience WRMDs and nearly 600,000 of the injuries are serious enough to cause workers to miss work.[16] Certain jobs or work conditions cause a higher rate worker complaints of undue strain, localized fatigue, discomfort, or pain that does not go away after overnight rest. These types of jobs are often those involving activities such as repetitive and forceful exertions; frequent, heavy, or overhead lifts; awkward work positions; or use of vibrating equipment.[17] The Occupational Safety and Health Administration (OSHA) has found substantial evidence that ergonomics programs can cut workers' compensation costs, increase productivity and decrease employee turnover.[18] Therefore, it is important to gather data to identify jobs or work conditions that are most problematic, using sources such as injury and illness logs, medical records, and job analyses.[17] Job analyses can be carried out using methods analysis, time studies, work sampling, or other established work measurement systems. Methods Analysis is the process of studying the tasks a worker completes using a step-by-step investigation. Each task in broken down into smaller steps until each motion the worker performs is described. Doing so enables you to see exactly where repetitive or straining tasks occur. Time studies determine the time required for a worker to complete each task. Time studies are often used to analyze cyclical jobs. They are considered event based studies because time measurements are triggered by the occurrence of predetermined events.[19] Work Sampling is a method in which the job is sampled at random intervals to determine the proportion of total time spent on a particular task.[19] It provides insight into how often workers are performing tasks which might cause strain on their bodies. Predetermined time systems are methods for analyzing the time spent by workers on a particular task. One of the most widely used predetermined time system is called Methods-Time-Measurement or MTM. Other common work measurement systems include MODAPTS and MOST.

Human factors

290

See also
Alphonse Chapanis Crew Resource Management Engineering psychology Ergonomics Experience design High velocity human factors Human-centered computing (discipline) Human computer interaction Human-in-the-Loop Human reliability Industrial Engineering Industrial Design Latent human error Maintenance Resource Management (MRM) Mockup Paul Fitts Single pilot resource management System Usability Scale (SUS) Systems engineering Ubiquitous computing Usability User-centered design User experience design

Additional Reading
Meister, D. (1999). The History of Human Factors and Ergonomics. Mahwah, N.J.: Lawrence Erlbaum Associates. ISBN0805827692. Oviatt, S. L.; Cohen, P. R. (2000, March). "Multimodal systems that process what comes naturally". Communications of the ACM (New York: ACM Press) 43: 4553. Sarter, N. B.; Cohen, P. R. (2002). "Multimodal information presentation in support of human-automation communication and coordination". Advances in Human Performance and Cognitive Engineering Research (Netherlands: JAI) 2: 1336. Wickens, C.D.; Lee J.D.; Liu Y.; Gorden Becker S.E. (1997). An Introduction to Human Factors Engineering, 2nd Edition. Prentice Hall. ISBN0321012291. Wickens, C. D.; Sandy, D. L.; Vidulich, M. (1983). "Compatibility and resource competition between modalities of input, central processing, and output". Human Factors (Santa Monica, CA, ETATS-UNIS: Human Factors and Ergonomics Society) 25 (2): 227248. ISSN00187208. PMID6862451.

Human factors

291

Related software
3D SSPP ErgoFellow

External links
Directory of Design Support Methods [20] Engineering Data Compendium of Human Perception and Performance [21] Index of Non-Government Standards on Human Engineering... [22] Index of Government Standards on Human Engineering... [23] Human Factors Engineering resources [24] MANPRINT [25] Human Factors in aviation [26]

References
[1] Porter, Elias H. (1964). Manpower Development: The System Training Concept. New York: Harper and Row, p. xiii. [2] The History of Human Factors and Ergonomics, David Meister [3] Stanton, N.; Salmon, P., Walker G., Baber, C., Jenkins, D. (2005). Human Factors Methods; A Practical Guide For Engineering and Design.. Aldershot, Hampshire: Ashgate Publishing Limited. ISBN0754646610. [4] Carrol, J.M. (1997). Human-Computer Interaction: Psychology as a Science of Design. Annu. Rev. Psyc., 48, 61-83. [5] http:/ / www. nedarc. org/ nedarc/ media/ pdf/ surveyMethods_2006. pdf [6] Wickens, C.D.; Lee J.D.; Liu Y.; Gorden Becker S.E. (1997). An Introduction to Human Factors Engineering, 2nd Edition. Prentice Hall. ISBN 0321012291. [7] Kuusela, H., Paul, P. (2000). A comparison of concurrent and retrospective verbal protocol analysis. The American Journal of Psychology, 113, 387-404. [8] Hornbaek, K (2006). Current Practice in Measuring Usability: Challenges to Usability Studies and Research, International Journal of Human-Computer Studies. [9] Dumas, J. S.; Salzman, M.C. (2006). Reviews of Human Factors and Ergonomics. 2. Human Factors and Ergonomics Society. [10] human systems integration (HSI) (https:/ / akss. dau. mil/ dag/ Guidebook/ IG_c6. 0. asp) [11] DoD 5000.2-R (http:/ / www. acq. osd. mil/ ie/ bei/ pm/ ref-library/ dodi/ p50002r. pdf) (Paragraph 4.3.8) [12] MANPRINT website (http:/ / www. manprint. army. mil/ ) [13] (https:/ / akss. dau. mil/ dag/ Guidebook/ IG_c6. 0. asp) [14] Title 10, U. S. Code Armed Forces, Sec. 2434 (http:/ / www. access. gpo. gov/ uscode/ title10/ subtitlea_partiv_chapter144_. html) [15] Isabel A P Walsh; Jorge Oishi; Helenice J C Gil Coury (February 2008). "Clinical and functional aspects of work-related musculoskeletal disorders among active workers". . Programa de Ps-graduao em Fisioterapia. Universidade Federal de So Carlos. So Carlos, SP, Brasil. Rev. Sade Pblica vol.42 no.1 So Paulo. [16] Charles N. Jeffress (October 27, 2000). "BEACON Biodynamics and Ergonomics Symposium". University of Connecticut, Farmington, Conn.. [17] "Workplace Ergonomics: NIOSH Provides Steps to Minimize Musculoskeletal Disorders" (http:/ / www. buildings. com/ articles/ detail. aspx?contentID=1563). 2003. . Retrieved 2008-04-23. [18] Charles N. Jeffress (October 27, 2000). BEACON Biodynamics and Ergonomics Symposium. University of Connecticut, Farmington, Conn.. [19] Thomas J. Armstrong (2007). Measurement and Design of Work. [20] http:/ / www. dtic. mil/ dticasd/ ddsm/ [21] http:/ / www. dtic. mil/ dticasd/ edc/ TOC/ EDCTOC. html [22] http:/ / hfetag. dtic. mil/ docs/ index_ngs. doc [23] http:/ / hfetag. dtic. mil/ docs/ index_govt_std. doc [24] http:/ / www. humanics-es. com/ recc-ergonomics. htm#humanfactorsergonomics [25] http:/ / www. manprint. army. mil/ [26] http:/ / www. skybrary. aero/ index. php/ Category:Human_Factors

Earned value management

292

Earned value management

Earned value management (EVM) is a project management technique for measuring project progress in an objective manner. EVM has the ability to combine measurements of scope, schedule, and cost in a single integrated system. When properly applied, EVM provides an early warning of performance problems. Additionally, EVM promises to improve the definition of project scope, prevent scope creep, communicate objective progress to stakeholders, and keep the project team focused on achieving progress.

Introduction to EVM
Essential features of any EVM implementation include 1. a project plan that identifies work to be accomplished, 2. a valuation of planned work, called Planned Value (PV) or Budgeted Cost of Work Scheduled (BCWS), and 3. pre-defined earning rules (also called metrics) to quantify the accomplishment of work, called Earned Value (EV) or Budgeted Cost of Work Performed (BCWP). EVM implementations for large or complex projects include many more features, such as indicators and forecasts of cost performance (over budget or under budget) and schedule performance (behind schedule or ahead of schedule). However, the most basic requirement of an EVM system is that it quantifies progress using PV and EV.

Project tracking without EVM

It is helpful to see an example of project tracking that does not include earned value performance management. Consider a project that has been planned in detail, including a time-phased spend plan for all elements of work. Figure 1 shows the cumulative budget for this project as a function of time (the blue line, labeled PV). It also shows the cumulative actual cost of the project (red line) through week 8. To those unfamiliar with EVM, it might appear that this project was over budget through week 4 and then under budget from week 6 through week 8. However, what is missing from this chart is any understanding of how much work has been accomplished during the project. If the project were actually completed at week 8, then the project would actually be well under budget and well ahead of schedule. If, on the other hand, the project is only 10% complete at week 8, the project is significantly over the budget and behind schedule. A method is needed to measure technical performance objectively and quantitatively, and that is what EVM accomplishes.

Project tracking with EVM

Consider the same project, except this time the project plan includes pre-defined methods of quantifying the accomplishment of work. At the end of each week, the project manager identifies every detailed element of work that has been completed, and sums the PV for each of these completed elements. Earned value may be accumulated monthly, weekly, or as progress is made.

Earned value management

293

Earned value (EV)

Figure 2 shows the EV curve (in green) along with the PV curve from Figure 1. The chart indicates that technical performance (i.e., progress) started more rapidly than planned, but slowed significantly and fell behind schedule at week 7 and 8. This chart illustrates the schedule performance aspect of EVM. It is complementary to critical path or critical chain schedule management. Figure 3 shows the same EV curve (green) with the actual cost data from Figure 1 (in red). It can be seen that the project was actually under budget, relative to the amount of work accomplished, since the start of the project. This is a much better conclusion than might be derived from Figure 1. Figure 4 shows all three curves together which is a typical EVM line chart. The best way to read these three-line charts is to identify the EV curve first, then compare it to PV (for schedule performance) and AC (for cost performance). It can be seen from this illustration that a true understanding of cost performance and schedule performance relies first on measuring technical performance objectively. This is the foundational principle of EVM.

History of EVM
See also: DoD/DSMC 1997 [1] Abba 2000 [2] Fleming 2005 [3] EVM emerged as a financial analysis specialty in United States Government programs in the 1960s, but it has since become a significant branch of project management and cost engineering. Project management research investigating the contribution of EVM to project success suggests a moderately strong positive relationship [4] . Implementations of EVM can be scaled to fit projects of all sizes and complexities. The genesis of EVM occurred in industrial manufacturing at the turn of the 20th century, based largely on the principle of "earned time" popularized by Frank and Lillian Gilbreth, but the concept took root in the United States Department of Defense in the 1960s. The original concept was called PERT/COST, but it was considered overly burdensome (not very adaptable) by contractors who were mandated to use it, and many variations of it began to

Earned value management proliferate among various procurement programs. In 1967, the DoD established a criterion-based approach, using a set of 35 criteria, called the Cost/Schedule Control Systems Criteria (C/SCSC). In 1970s and early 1980s, a subculture of C/SCSC analysis grew, but the technique was often ignored or even actively resisted by project managers in both government and industry. C/SCSC was often considered a financial control tool that could be delegated to analytical specialists. In the late 1980s and early 1990s, EVM emerged as a project management methodology to be understood and used by managers and executives, not just EVM specialists. In 1989, EVM leadership was elevated to the Undersecretary of Defense for Acquisition, thus making EVM an essential element of program management and procurement. In 1991, Secretary of Defense Dick Cheney canceled the Navy A-12 Avenger II Program because of performance problems detected by EVM. This demonstrated conclusively that EVM mattered to secretary-level leadership. In the 1990s, many U.S. Government regulations were eliminated or streamlined. However, EVM not only survived the acquisition reform movement, but became strongly associated with the acquisition reform movement itself. Most notably, from 1995 to 1998, ownership of EVM criteria (reduced to 32) was transferred to industry by adoption of ANSI EIA 748-A standard[5] . The use of EVM quickly expanded beyond the U.S. Department of Defense. It was adopted by the National Aeronautics and Space Administration, United States Department of Energy and other technology-related agencies. Many industrialized nations also began to utilize EVM in their own procurement programs. An overview of EVM was included in first PMBOK Guide in 1987 and expanded in subsequent editions. The construction industry was an early commercial adopter of EVM. Closer integration of EVM with the practice of project management accelerated in the 1990s. In 1999, the Performance Management Association merged with the Project Management Institute (PMI) to become PMIs first college, the College of Performance Management. The United States Office of Management and Budget began to mandate the use of EVM across all government agencies, and, for the first time, for certain internally-managed projects (not just for contractors). EVM also received greater attention by publicly-traded companies in response to the Sarbanes-Oxley Act of 2002.

294

Scaling EVM from simple to advanced implementations

The foundational principle of EVM, mentioned above, does not depend on the size or complexity of the project. However, the implementations of EVM can vary significantly depending on the circumstances. In many cases, organizations establish an all-or-nothing threshold; projects above the threshold require a full-featured (complex) EVM system and projects below the threshold are exempted. Another approach that is gaining favor is to scale EVM implementation according to the project at hand and skill level of the project team. [6] [7]

Simple implementations (emphasizing only technical performance)

There are many more small and simple projects than there are large and complex ones, yet historically only the largest and most complex have enjoyed the benefits of EVM. Still, lightweight implementations of EVM are achievable by any person who has basic spreadsheet skills. In fact, spreadsheet implementations are an excellent way to learn basic EVM skills. The first step is to define the work. This is typically done in a hierarchical arrangement called a work breakdown structure (WBS) although the simplest projects may use a simple list of tasks. In either case, it is important that the WBS or list be comprehensive. It is also important that the elements be mutually exclusive, so that work is easily categorized in one and only one element of work. The most detailed elements of a WBS hierarchy (or the items in a list) are called activities (or tasks). The second step is to assign a value, called planned value (PV), to each activity. For large projects, PV is almost always an allocation of the total project budget, and may be in units of currency (e.g., dollars or euros) or in labor hours, or both. However, in very simple projects, each activity may be assigned a weighted point value" which might not be a budget number. Assigning weighted values and achieving consensus on all PV quantities yields an

Earned value management important benefit of EVM, because it exposes misunderstandings and miscommunications about the scope of the project, and resolving these differences should always occur as early as possible. Some terminal elements can not be known (planned) in great detail in advance, and that is expected, because they can be further refined at a later time. The third step is to define earning rules for each activity. The simplest method is to apply just one earning rule, such as the 0/100 rule, to all activities. Using the 0/100 rule, no credit is earned for an element of work until it is finished. A related rule is called the 50/50 rule, which means 50% credit is earned when an element of work is started, and the remaining 50% is earned upon completion. Other fixed earning rules such as a 25/75 rule or 20/80 rule are gaining favor, because they assign more weight to finishing work than for starting it, but they also motivate the project team to identify when an element of work is started, which can improve awareness of work-in-progress. These simple earning rules work well for small or simple projects because generally each activity tends to be fairly short in duration. These initial three steps define the minimal amount of planning for simplified EVM. The final step is to execute the project according to the plan and measure progress. When activities are started or finished, EV is accumulated according to the earning rule. This is typically done at regular intervals (e.g., weekly or monthly), but there is no reason why EV cannot be accumulated in near real-time, when work elements are started/completed. In fact, waiting to update EV only once per month (simply because that is when cost data are available) only detracts from a primary benefit of using EVM, which is to create a technical performance scoreboard for the project team. In a lightweight implementation such as described here, the project manager has not accumulated cost nor defined a detailed project schedule network (i.e., using a critical path or critical chain methodology). While such omissions are inappropriate for managing large projects, they are a common and reasonable occurrence in many very small or simple projects. Any project can benefit from using EV alone as a real-time score of progress. One useful result of this very simple approach (without schedule models and actual cost accumulation) is to compare EV curves of similar projects, as illustrated in Figure 5. In this example, the progress of three residential construction projects are compared by aligning the starting dates. If these three home construction projects were measured with the same PV valuations, the relative schedule performance of the projects can be easily compared.

295

Intermediate implementations (integrating technical and schedule performance)

In many projects, schedule performance (completing the work on time) is equal in importance to technical performance. For example, some new product development projects place a high premium on finishing quickly. It is not that cost is unimportant, but finishing the work later than a competitor may cost a great deal more in lost market share. It is likely that these kinds of projects will not use the lightweight version of EVM described in the previous section, because there is no planned timescale for measuring schedule performance. A second layer of EVM skill can be very helpful in managing the schedule performance of these intermediate projects. The project manager may employ a critical path or critical chain to build a project schedule model. As in the lightweight implementation, the project manager must define the work comprehensively, typically in a WBS hierarchy. He/she will construct a project schedule model that describes the precedence links between elements of work. This schedule model can then be used to develop the PV curve (or baseline), as shown in Figure 2'. It should be noted that measuring schedule performance using EVM does not replace the need to understand schedule performance versus the project's schedule model (precedence network). However, EVM schedule performance, as illustrated in Figure 2 provides an additional indicator one that can be communicated in a single chart. Although it is theoretically possible that detailed schedule analysis will yield different conclusions than broad schedule analysis, in practice there tends to be a high correlation between the two. Although EVM schedule

Earned value management measurements are not necessarily conclusive, they provide useful diagnostic information. Although such intermediate implementations do not require units of currency (e.g., dollars), it is common practice to use budgeted dollars as the scale for PV and EV. It is also common practice to track labor hours in parallel with currency. The following EVM formulas are for schedule management, and do not require accumulation of actual cost (AC). This is important because it is common in small and intermediate size projects for true costs to be unknown or unavailable. Schedule variance (SV) EV-PV greater than 0 is good (ahead of schedule) Schedule performance index (SPI) EV/PV greater than 1 is good (ahead of schedule) See also earned schedule for a description of known limitations in SV and SPI formulas and an emerging practice for correcting these limitations.

296

Advanced implementations (integrating cost, schedule and technical performance)

In addition to managing technical and schedule performance, large and complex projects require that cost performance be monitored and reviewed at regular intervals. To measure cost performance, planned value (or BCWS - Budgeted Cost of Work Scheduled) and earned value (or BCWP - Budgeted Cost of Work Performed) must be in units of currency (the same units that actual costs are measured.) In large implementations, the planned value curve is commonly called a Performance Measurement Baseline (PMB) and may be arranged in control accounts, summary-level planning packages, planning packages and work packages. In large projects, establishing control accounts is the primary method of delegating responsibility and authority to various parts of the performing organization. Control accounts are cells of a responsibility assignment (RACI) matrix, which is intersection of the project WBS and the organizational breakdown structure (OBS). Control accounts are assigned to Control Account Managers (CAMs). Large projects require more elaborate processes for controlling baseline revisions, more thorough integration with subcontractor EVM systems, and more elaborate management of procured materials. In the United States, the primary standard for full-featured EVM systems is the ANSI/EIA-748A standard, published in May 1998 and reaffirmed in August 2002. The standard defines 32 criteria for full-featured EVM system compliance. As of the year 2007, a draft of ANSI/EIA-748B, a revision to the original is available from ANSI. Other countries have established similar standards. In addition to using BCWS and BCWP, prior to 1998 implementations often use the term Actual Cost of Work Performed (ACWP) instead of AC. Additional acronyms and formulas include: Budget at completion (BAC): The total planned value (PV or BCWS) at the end of the project. If a project has a Management Reserve (MR), it is typically in addition to the BAC. Cost variance (CV) EV - AC, greater than 0 is good (under budget) Cost Performance Index (CPI) EV/AC, greater than 1 is good (under budget) < 1 means that the cost of completing the work is higher than planned (bad) = 1 means that the cost of completing the work is right on plan (good) > 1 means that the cost of completing the work is less than planned (good or sometimes bad). Having a CPI that is very high (in some cases, very high is only 1.2) may mean that the plan was too conservative, and thus a very high number may in fact not be good, as the CPI is being measured against a poor baseline. Management or the customer may be upset with the planners as an overly conservative baseline ties up available funds for other purposes, and the baseline is also used for manpower planning.

Earned value management Estimate at completion (EAC) EAC is the manager's projection of total cost of the project at completion.

297

ETC is the estimate to complete the project.

To-complete performance index (TCPI) The To Complete Performance Index (TCPI) provides a projection of the anticipated performance required to achieve either the BAC or the EAC. TCPI indicates the future required cost efficiency needed to achieve a target BAC (Budget At Complete) or EAC (Estimate At Complete). Any significant difference between CPI, the cost performance to date, and the TCPI, the cost performance needed to meet the BAC or the EAC, should be accounted for by management in their forecast of the final cost. For the TCPI based on BAC (describing the performance required to meet the original BAC budgeted total):

or for the TCPI based on EAC (describing the performance required to meet a new, revised budget total EAC):

Independent estimate at completion (IEAC) The IEAC is a metric to project total cost using the performance to date to project overall performance. This can be compared to the EAC, which is the manager's projection.

Limitations of EVM
EVM has no provision to measure project quality, so it is possible for EVM to indicate a project is under budget, ahead of schedule and scope fully executed, but still have unhappy clients and ultimately unsuccessful results. In other words, EVM is only one tool in the project manager's toolbox. Because EVM requires quantification of a project plan, it is often perceived to be inapplicable to discovery-driven or Agile software development projects. For example, it may be impossible to plan certain research projects far in advance, because research itself uncovers some opportunities (research paths) and actively eliminates others. However, another school of thought holds that all work can be planned, even if in weekly timeboxes or other short increments. Thus, the challenge is to create agile or discovery-driven implementations of the EVM principle, and not simply to reject the notion of measuring technical performance objectively. (See the lightweight implementation for small projects, described above). Applying EVM in fast-changing work environments is, in fact, an area of project management research.[8] Traditional EVM is not intended for non-discrete (continuous) effort. In traditional EVM standards, non-discrete effort is called level of effort" (LOE). If a project plan contains a significant portion of LOE, and the LOE is intermixed with discrete effort, EVM results will be contaminated. This is another area of EVM research. Traditional definitions of EVM typically assume that project accounting and project network schedule management are prerequisites to achieving any benefit from EVM. Many small projects don't satisfy either of these prerequisites, but they too can benefit from EVM, as described for simple implementations, above. Other projects can be planned with a project network, but do not have access to true and timely actual cost data. In practice, the collection of true and timely actual cost data can be the most difficult aspect of EVM. Such projects can benefit from EVM, as

Earned value management described for intermediate implementations, above, and Earned Schedule. As a means of overcoming objections to EVM's lack of connection to qualitative performance issues, the Naval Air Systems Command (NAVAIR) PEO(A) organization initiated a project in the late 1990's to integrate true technical achievement into EVM projections by utilizing risk profiles. These risk profiles anticipate opportunities that may be revealed and possibly be exploited as development and testing proceeds. The published research resulted in a Technical Performance Management (TPM) methodology and software application that is still used by many DoD agencies in informing EVM estimates with technical achievement.[9] The research was peer-reviewed and was the recipient of the Defense Acquisition University Acquisition Research Symposium 1997 Acker Award for excellence in the exchange of information in the field of acquisition research.

298

See also
List of project management topics Earned schedule

Notes and References

[1] Defense Systems Management College (1997). Earned Value Management Textbook, Chapter 2. Defense Systems Management College, EVM Dept., 9820 Belvoir Road, Fort Belvoir, VA 22060-5565. [2] Abba, Wayne (2000-04-01). "How Earned Value Got to Prime Time: A Short Look Back and a Glance Ahead" (http:/ / www. pmi-cpm. org/ members/ library/ EVLook Back-Glance Ahead. abba. pdf). PMI College of Performance Management (www.pmi-cpm.org). . Retrieved 2006-10-31. [3] Fleming, Quentin; Joel Koppelman (2005). Earned Value Project Management (Third Edition ed.). Project Management Institute. ISBN1-930699-89-1. [4] Marshall, Robert A. (2006-11-09). "The contribution of earned value management to project success on contracted efforts: A quantitative statistics approach within the population of experienced practitioners" (http:/ / www. pmi. org/ PDF/ pp_marshall. pdf). PMI (www.pmi.org). . Retrieved 2006-11-09. [5] ANSI EIA-748A Standard (June1998 ed.). Electronic Industries Alliance. 1998. [6] Sumara, Jim; John Goodpasture (1997-09-29). "Earned Value -- The Next Generation -- A Practical Application for Commercial Projects" (http:/ / www. sqpegconsulting. com/ EV_Chi_97NP03. PDF). . Retrieved 2006-10-26. [7] Goodpasture, John C. (2004). Quantitative Methods in Project Management. J. Ross Publishing. pp.173178. ISBN1-932159-15-0. [8] Sulaiman, Tamara (2007-01-08). "AgileEVM -- Earned Value Management The Agile Way" (http:/ / www. agilejournal. com/ content/ view/ 210/ ). Agile Journal. . Retrieved 2007-03-07. [9] Pisano, Nicholas (1999). "Technical Performance Measurement, Earned Value, and Risk Management: An Integrated Diagnostic Tool for Program Management" (http:/ / www. pmi-cpm. org/ members/ library/ tpmackerawardacqsymposium1997(1). pdf). Defense Acquisition University Acquisition Research Symposium. .

Humphreys, Gary (2001). Project Management Using Earned Value. Humphreys and Associates. ISBN 0-9708614-0-0 Philipson, Erik and Sven Antvik (2009). Earned Value Management. Elanders Sverige AB. ISBN 978-91-977394-5-0 Project Management Institute (2005). Practice Standard for Earned Value Management. Project Management Institute. ISBN 1-930699-42-5 Solomon, Paul and Ralph Young (2006). Performance-Based Earned Value. Wiley-IEEE Computer Society. ISBN 978-0-471-72188-8 Stratton, Ray (2006). The Earned Value Maturity Model. Management Concepts. ISBN 1-56726-180-9 U.S. Air Force Materiel Command (1994). "Guide to Analysis of Contractor Cost Data". AFMCPAM 65-501

Earned value management

299

External links
EVM at NASA (http://evm.nasa.gov/) "DOE G 413.3-10, Earned Value Management System (EVMS)" (http://www.everyspec.com/DOE/DOE+ (General)/DOE_G413x3-10_15922/) (PDF). United States Department of Energy. 6 May 2008. U.S. Office of the Undersecretary of Defense for Acquisition, Technology and Logistics Earned Value Management website (http://www.acq.osd.mil/pm) Measuring Integrated Progress on Agile Software Development Projects (http://www.methodsandtools.com/ archive/archive.php?id=61) Monitoring Scrum Projects with AgileEVM and Earned Business Value (EBV) Metrics (http://www.danube. com/system/files/WP_AgileEVM_and_Earned_Business_Value_Metrics.pdf) UK MoD on-line training using Flash player (http://www.aof.mod.uk/aofcontent/tactical/ppm/downloads/ evm/flash/Engine.swf) U.S. DoD AT&L Acquisition Community Earned Value Management website (http://acc.dau.mil/ CommunityBrowser.aspx?id=17609&lang=en-US/) U.S. Defense Contract Management Agency Guidebook (http://guidebook.dcma.mil/)

Project governance
The term Project governance is used in industry, especially in the information technology (IT) sector (see Information technology governance), to describe the processes that need to exist for a successful project. Project Governance is an active rather than just a controlling role. While lack of senior management commitment is a consistent cause of project failure, this still occurs when governance structures are in place and operating. This is because Project Governance is not well understood and even less well executed. Formal methodologies do exist such as OGC (UK) Projects in a Controlled Environment (PRINCE2) or by the use other quality standards such as Six Sigma. Formal international accrediting organizations also exist such as PMI or the APM. The formal methodologies provide template structures and Terms of Reference as well as introductions to the more complex areas of Programme management.

Roles
Project Governance can be seen as consisting of nine key roles Establish the basis for project governance, approval and measurement including defining roles and accountabilities, policies and standards and associated processes Evaluate project proposals to select those that are the best investment of funds and scarce resources and are within the firms capability and capacity to deliver Enable, through resourcing of projects with staff and consultants, harnessing and managing of business support and the provision of the governance resources Define the desired business outcomes (end states), benefits and value the business measures of success and overall value proposition Control the scope, contingency funds, overall project value and so on Monitor the projects progress, stakeholders commitment, results achieved and the leading indicators of failure Measure the outputs, outcomes, benefits and value against both the plan and measurable expectations Act to steer the project into the organization, remove obstacles, manage the critical success factors and remediate project or benefit-realization shortfalls

Project governance Develop the organizations project delivery capability continually building and enhancing its ability to deliver more complex and challenging projects in less time and for less cost while generating the maximum value.

300

Elements
Project governance will: Outline the relationships between all internal and external groups involved in the project Describe the proper flow of information regarding the project to all stakeholders Ensure the appropriate review of issues encountered within each project Ensure that required approvals and direction for the project is obtained at each appropriate stage of the project.

Important specific elements of good project governance include: A compelling business case, stating the objects of the project and specifying the in-scope and out-of-scope aspects A mechanism to assess the compliance of the completed project to its original objectives Identifying all stakeholders with an interest in the project A defined method of communication to each stakeholder A set of business-level requirements as agreed by all stakeholders An agreed specification for the project deliverables The appointment of a project manager Clear assignment of project roles and responsibilities A current, published project plan that spans all project stages from project initiation through development to the transition to operations. A system of accurate upward status- and progress-reporting including time records. A central document repository for the project A centrally-held glossary of project terms A process for the management and resolution of issues that arise during the project A process for the recording and communication of risks identified during the project A standard for quality review of the key governance documents and of the project deliverables.

See also
Project Governance also managment systems Cost overrun Megaproject Megaprojects and risk

References
Patrick S. Renz: "Project Governance: Implementing Corporate Governance and Business Ethics in Nonprofit Organizations." Heidelberg: Physica-Verl., 2007. (Contributions to Economics) Ralf Mller: "Project Governance". Aldershot, UK: Gower Publishing, 2009. ISBN-10: 0566088665, ISBN-13: 9780566088667. WebSite: http://www.gowerpublishing.com/default.aspx?page=641&title_id=10377& edition_id=11545&calcTitle=1

Virtual project management

301

Virtual project management

Project Management (PM) is a complex and challenging task that strives for solutions and deliverables within time and budget. Virtual Project Management (VPM) is an even more daunting task. PM is the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives. VPM is attempting the same, except all project team members are not physically in a single location, possibly spanning different states and/or countries. VPM is the art of bringing together many diverse people to work towards a common shared goal. One can look at VPM as a new dimension of project management, in that it is a new way to manage projects that was influenced by the rise of the internet and the use of collaborative software tools that are used to facilitate projects. Project members can now be organizationally disbursed across the globe and come together as knowledge workers to complete the tasks. VPM has unique challenges. Since team members are often scattered in different locations around the world, they have different schedules, cultures and expectations. Managing a virtual team makes it difficult to micro manage which is a traditional concept in project management. Project Managers often need to manage people for whom they have no first-hand or personal experience with. Project members have to become acutely aware of their team members differences and somehow align them to work together. The entire team is dependent on technology to do its job in order for the project to be successful. Project Managers need tools tailored to the challenges of virtual project management.

Virtual Project Management Tools

The tools that are used in VPM need to accommodate teams in a global work environment. The key task that any VPM tool must accomplish is to allow team members to communicate with one another. Because team members are not physically in the same location, and may have no prior knowledge of each others work, communication becomes key. In addition, tools must have the ability to allow team members to collaborate in the virtual space, as that is the only venue open to them being from different locations. Tools need to be equipped with the capabilities to allow the project manager to manage the project scheduling resources and tracking progress on tasks. Being a project manager in a virtual setting does not allow the PM to micromanage the team, therefore the tool should be equipped so that the PM can manage, track and facilitate the projects with ease and stability. In order to accomplish full life cycle virtual project management, VPM tools were researched and compared. Software Tools must have the following features: Web based Creation of schedules and tasks Assigns resources and activities Reporting functionality Document management Collaborative software Notification feature

Virtual project management

302

See also
List of project management software Project+ Project governance Project management Program management

Software development process

A software development process is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a lifecycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral lifecycle model.

Overview
The large and growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207. A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking. Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.

Software development process

303

Software development activities

Planning
The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete,ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are The activities of the software development process represented in the waterfall model. There are several other models to represent this process. gathered from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that defects are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the writing of an API, be it external or internal. It is very important to document everything in the project.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important and a lot of developers fail to realize that. It would not matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality of at least one prior phase is poor. In that case, management should

Software development process consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.

304

Software Development Models

Several models exist to streamline the development process. Each one has its pros and cons, and it's up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more suitable.

Waterfall Model
The waterfall model shows a process, where developers are to follow these phases in order: 1. Requirements specification (Requirements Analysis)? 2. Software Design 3. Implementation (or Coding) 4. 5. 6. 7. Integration Testing (or Validation) Deployment (or Installation) Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by other more "flexible" models.

Spiral Model
The key characteristic of a Spiral model is risk management at regular stages in the development cycle. In 1988, Barry Boehm published a formal software system development "spiral model", which combines some key aspect of waterfall and rapid prototyping methodologies, but provided emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems. The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities: (1) formulate plans to: identify software targets, selected to implement the program, clarify the project development restrictions; (2) Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk; (3) the implementation of the project: the implementation of software development and verification; Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows: (1) spiral model emphasize risk analysis, but require customers to accept and believe that much of this analysis, and make the relevant response is not easy, therefore, this model is often adapted to large-scale internal software development.

Software development process (2) If the implementation of risk analysis will greatly affect the profits of the project, then risk analysis is meaningless, therefore, spiral model is only suitable for large-scale software projects. (3) Good software developers should look for possible risks, an accurate analysis of risk, otherwise it will lead to greater risk. First stage is to determine the stage of the goal of accomplishing these objectives, options and constraints, and then from the perspective of risk analysis program, development strategy, and strive to remove all potential risks, and sometimes necessary to achieve through the construction of the prototype. If some risk can not be ruled out, the program to end immediately, or else start the development of the next steps. Finally, evaluation results of the stage, and the design of the next phase.

305

Iterative and Incremental Development

Iterative development[1] prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.

Agile Development
Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. There are many variations of agile processes. XP (Extreme Programming) In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature merging design and code is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system. Rational Unified Process Scrum

Process Improvement Models

Capability Maturity Model Integration The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM. ISO 9000 ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards have been applied to software development as well. Like CMMI, certification with ISO

Software development process 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed. ISO 15504 ISO 15504, also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

306

Formal methods
Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, Automated theorem proving, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behavior by designing a system of finite state machines. Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine). Formal methods are most likely to be applied in avionics software, particularly where the software is safety critical. Software safety assurance standards, such as DO178B demand formal methods at the highest level of categorization (Level A). Formalization of software development is creeping in, in other places, with the application of Object Constraint Language (and specializations such as Java Modeling Language) and especially with Model-driven architecture allowing execution of designs, if not specifications. Another emerging trend in software development is to write a specification in some form of logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, is an example. There is also work on mapping some version of English (or another natural language) automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems that support bidirectional English-logic mapping and direct execution of the logic is that they can be made to explain their results, in English, at the business or scientific level. The Government Accountability Office, in a 2003 report on one of the Federal Aviation Administrations air traffic control modernization programs,[2] recommends following the agencys guidance for managing major acquisition systems by establishing, maintaining, and controlling an accurate, valid, and current performance measurement baseline, which would include negotiating all authorized, unpriced work within 3 months; conducting an integrated baseline review of any major contract modifications within 6 months; and preparing a rigorous life-cycle cost estimate, including a risk assessment, in accordance with the Acquisition System Toolsets guidance and identifying the level of uncertainty inherent in the estimate.

Software development process

307

See also
Some more development methods: Evolutionary Development model Model driven development User experience Top-down and bottom-up design Chaos model Evolutionary prototyping Prototyping ICONIX Process (UML-based object modeling with use cases) Unified Process V-model Extreme Programming Software Development Rhythms Specification and Description Language Incremental funding methodology Verification and Validation (software) Service-Oriented Modeling Framework Related subjects: Rapid application development Software design Software development Software Estimation Abstract Model Development stage IPO+S Model List of software engineering topics Performance engineering Process Programming paradigm Programming productivity Project Systems Development Life Cycle (SDLC) Software documentation Systems design List of software development philosophies Test effort Best Coding Practices Service-Oriented Modeling Framework Bachelor of Science in Information Technology

External links
Don't Write Another Process [3] No Silver Bullet: Essence and Accidents of Software Engineering [4]", 1986 Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design" [5], 2001 Lydia Ash: The Web Testing Companion: The Insider's Guide to Efficient and Effective Tests, Wiley, May 2, 2003. ISBN 0-471-43021-8 SaaSSDLC.com [6] Software as a Service Systems Development Life Cycle Project Software development life cycle (SDLC) [visual image], software development life cycle [7] Selecting an SDLC [8]", 2009

References
[1] ieeecomputersociety.org (http:/ / doi. ieeecomputersociety. org/ 10. 1109/ MC. 2003. 1204375) [2] Government Accountability Report (January 2003). Report GAO-03-343, National Airspace System: Better Cost Data Could Improve FAAs Management of the Standard Terminal Automation Replacement System. Retrieved from http:/ / www. gao. gov/ cgi-bin/ getrpt?GAO-03-343 [3] http:/ / www. methodsandtools. com/ archive/ archive. php?id=16 [4] http:/ / virtualschool. edu/ mon/ SoftwareEngineering/ BrooksNoSilverBullet. html [5] http:/ / l3d. cs. colorado. edu/ ~gerhard/ papers/ isfst2001. pdf [6] http:/ / SaaSSDLC. com/ [7] http:/ / www. notetech. com/ images/ software_lifecycle. jpg [8] http:/ / www. gem-up. com/ PDF/ SK903V0-WP-ChoosingSDLC. pdf

Process architecture

308

Process architecture
Process architecture is the structural design of general process systems and applies to fields such as computers (software, hardware, networks, etc.), business processes (enterprise architecture, policy and procedures, logistics, project management, etc.), and any other process system of varying degrees of complexity.[1] Processes are defined as having inputs, outputs and the energy required to transform inputs to outputs. Use of energy during transformation also implies a passage of time: a process takes real time to perform its associated action. A process also requires space for input/output objects and transforming objects to exist: a process uses real space. A process system is a specialized system of processes. Processes are composed of processes. Complex processes are made up of several processes that are in turn made up of several processes. This results in an overall structural hierarchy of abstraction. If the process system is studied hierarchically, it is easier to understand and manage; therefore, process architecture requires the ability to consider process systems hierarchically. Process systems are a dualistic phenomenon of change/no-change or form/transform and as such, are well-suited to being modelled by the bipartite Petri Nets modelling system and in particular, process-class Dualistic Petri nets where processes can be simulated and studied hierarchically.

See also
Complex system and Complexity Enterprise Information Security Architecture Flowchart General Systems Theory Petri nets, Dualistic Petri nets Process engineering Process management Process modeling Process theory Systems architecture Workflow

References
[1] Dawis, E. P., J. F. Dawis, Wei-Pin Koo (2001). Architecture of Computer-based Systems using Dualistic Petri Nets. Systems, Man, and Cybernetics, 2001 IEEE International Conference on Volume 3, 2001 Page(s):1554 - 1558 vol.3

Project

309

Project
A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.[1]

Overview
The word project comes from the Latin word projectum from the Latin verb proicere, "to throw something forwards" which in turn comes from pro-, which denotes something that precedes the action of the next part of the word in time (paralleling the Greek ) and iacere, "to throw". The word "project" thus actually originally meant "something that comes before anything else happens". When the English language initially adopted the word, it referred to a plan of something, not to the act of actually carrying this plan out. Something performed in accordance with a project became known as an "object".

Specific uses
School and university
At school and university, a project is a research assignment given to a student which generally requires a larger amount of effort and more independent work than is involved in a normal essay assignment. It requires students to undertake their own fact-finding and analysis, either from library/internet research or from gathering data empirically. The written report that comes from the project is usually in the form of a dissertation, which will contain sections on the project's inception, methods of inquiry, analysis, findings and conclusions.[2]

Engineering project
The engineering project is a particular type of technological system, embedded in the context of technological systems in general[3] . Engineering projects are, in many countries, specifically defined by legislation, which requires that such projects should be carried out by registered engineers and/or registered engineering companies. That is, companies with license to carry out such works as design and construction of buildings, power plants, industrial facilities, installation and erection of electrical grid networks, transportation infrastructure and the like. The scope of the project is specified on a contract between the owner and the engineering and construction parties. As a rule, an engineering project is broken down into design and construction phases. The outputs of the design process are drawings, calculations, and all other design documentation necessary to carry out the next phase. [4]

Project management
In project management a project consists of a temporary endeavor undertaken to create a unique product, service or result.[5] Another definition is a management environment that is created for the purpose of delivering one or more business products according to a specified business case[6] . Project objectives define target status at the end of the project, reaching of which is considered necessary for the achievement of planned benefits. They can be formulated as S.M.A.R.T[7] : Specific, Measurable (or at least evaluable) achievement, Achievable (recently Acceptable is used regularly as well), realistic (given the current state of organizational resources) and Time terminated (bounded). The evaluation (measurement) occurs at the project closure. However a continuous guard on the project progress should be kept by monitoring and evaluating. It is also worth noting that SMART is best applied for incremental type innovation projects. For radical type projects it does not apply as well. Goals for such projects tend to be broad, qualitative, stretch/unrealistic and success driven.

Project

310

Examples of notable projects

Human Genome Project which mapped the human genome Manhattan Project, which developed the first nuclear weapon Polaris missile project: an ICBM control-system Project Apollo, which landed humans on the moon Soviet atomic bomb project Soviet manned lunar projects and programs

See also
Megaproject Project governance Project Management Institute (PMI) Project management software Project planning Cone of Uncertainty

References
[1] [2] [3] [4] [5] [6] [7] Oxford English Dictionary Thomas, G: How to do your research project. Sage Publications Inc, 2009. Gene Moriarty, The Engineering Project:Its Nature, Ethics, and Promise, page 7. Penn State Press, 2008. civil A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management Institute. - APM Group - PRINCE2 (http:/ / www. apmgroup. co. uk/ PRINCE2) Carr, David, Make Sure Your Project Goals are SMART (http:/ / www. pmhut. com/ make-sure-your-project-goals-are-smart), PM Hut. Accessed 18. Oct 2009.

Critical path method

311

Critical path method

The critical path method (CPM) more properly called critical path analysis, is a mathematically based algorithm for scheduling a set of project activities. It is an important tool for effective project management.

History
The original Critical Path Method was developed in the 1950s by the PERT chart for a project with five milestones (10 DuPont Corporation at about the same time that Booz Allen Hamilton through 50) and six activities (A through F). The project has two critical paths: activities B and C, and the US Navy were developing the Program Evaluation and Review [1] or A, D, and F giving a minimum project time Technique Today, it is commonly used with all forms of projects, of 7 months with fast tracking. Activity E is including construction, software development, research projects, sub-critical, and has a float of 2 months. product development, engineering, and plant maintenance, among others. Any project with interdependent activities can apply this method of mathematical analysis. Although the original CPM program and approach is no longer used. The term is generally applied to any approach used to analyze a project network logic diagram.

Basic technique
The essential technique for using CPM [2] is to construct a model of the project that includes the following: 1. A list of all activities required to complete the project (typically categorized within a work breakdown structure), 2. The time (duration) that each activity will take to completion, and 3. The dependencies between the activities Using these values, CPM calculates the longest path of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer. This process determines which activities are "critical" (i.e., on the longest path) and which have "total float" (i.e., can be delayed without making the project longer). In project management, a critical path is the sequence of project network activities which add up to the longest overall duration. This determines the shortest time possible to complete the project. Any delay of an activity on the critical path directly impacts the planned project completion date (i.e. there is no float on the critical path). A project can have several, parallel, near critical paths. An additional parallel path through the network with the total durations shorter than the critical path is called a sub-critical or non-critical path. These results allow managers to prioritize activities for the effective management of project completion, and to shorten the planned critical path of a project by pruning critical path activities, by "fast tracking" (i.e., performing more activities in parallel), and/or by "crashing the critical path" (i.e., shortening the durations of critical path activities by adding resources).

Expansion
Originally, the critical path method considered only logical dependencies between terminal elements. Since then, it has been expanded to allow for the inclusion of resources related to each activity, through processes called activity-based resource assignments and resource leveling. A resource-leveled schedule may include delays due to resource bottlenecks (i.e., unavailability of a resource at the required time), and may cause a previously shorter path to become the longest or most "resource critical" path. A related concept is called the critical chain, which attempts to protect activity and project durations from unforeseen delays due to resource constraints.

Critical path method Since project schedules change on a regular basis, CPM allows continuous monitoring of the schedule, allows the project manager to track the critical activities, and alerts the project manager to the possibility that non-critical activities may be delayed beyond their total float, thus creating a new critical path and delaying project completion. In addition, the method can easily incorporate the concepts of stochastic predictions, using the Program Evaluation and Review Technique (PERT) and event chain methodology. Currently, there are several software solutions available in industry that use the CPM method of scheduling, see list of project management software. Ironically, the method currently used by most project management software is actually based on a manual calculation approach developed by Fondahl of Stanford University.

312

Flexibility
A schedule generated using critical path techniques often is not realised precisely, as estimations are used to calculate times: if one mistake is made, the results of the analysis may change. This could cause an upset in the implementation of a project if the estimates are blindly believed, and if changes are not addressed promptly. However, the structure of critical path analysis is such that the variance from the original schedule caused by any change can be measured, and its impact either ameliorated or adjusted for. Indeed, an important element of project postmortem analysis is the As Built Critical Path (ABCP), which analyzes the specific causes and impacts of changes between the planned schedule and eventual schedule as actually implemented.

Running time
Given a graph G=G(N,E) of N nodes and E edges, if we use Big O notation, the CPM algorithm takes O(E) to complete, since topological ordering of a graph takes O(E) and every edge is considered only twice, which means linear time in number of edges.

See also
Gantt chart List of project management software List of project management topics Program Evaluation and Review Technique (PERT) Project Project management Project planning Shifting bottleneck heuristic Work breakdown structure Backward induction

Further reading
Project Management Institute (2003). A Guide To The Project Management Body Of Knowledge (3rd ed.). Project Management Institute. ISBN1-930699-45-X. Klastorin, Ted (2003). Project Management: Tools and Trade-offs (3rd ed.). Wiley. ISBN978-0471413844. Heerkens, Gary (2001). Project Management (The Briefcase Book Series). McGrawHill. ISBN0-07-137952-5. Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th ed.). ISBN0-471-22577-0. Lewis, James (2002). Fundamentals of Project Management (2nd ed.). American Management Association. ISBN0-8144-7132-3.

Critical path method Milosevic, Dragan Z. (2003). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. ISBN978-0471208228. Woolf, Murray B. (2007). Faster Construction Projects with CPM Scheduling. McGraw Hill. ISBN978-0071486606.

313

External links
Critical path web calculator [8] A Few Critical Path Articles [3] A slide show explaining critical path concepts [4] Critical Path Java Applet [5]

References
[1] Newell, M; Grashina, M (2003). The Project Management Question and Answer Book. American Management Association. p.98. [2] Samuel L. Baker, Ph.D. "Critical Path Method (CPM)" (http:/ / hspm. sph. sc. edu/ COURSES/ J716/ CPM/ CPM. html) University of South Carolina, Health Services Policy and Management Courses [3] http:/ / www. pmhut. com/ category/ time-management/ critical-path/ [4] http:/ / www. slideshare. net/ dmdk12/ the-network-diagram-and-critical-path [5] http:/ / www. cut-the-knot. org/ Curriculum/ Combinatorics/ CriticalPath. shtml

Agile software development

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

History
The modern definition of agile software development evolved in the mid-1990s as part of a reaction against "heavyweight" methods, perceived to be typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software developers actually perform effective work. A case can be made that agile and iterative development methods mark a return to development practice from early in the history of software development.[1] Initially, agile methods were called "lightweight methods." An adaptive software development process was introduced in a paper by Edmonds Jeff Sutherland one of the (1974).[2] Notable early Agile methods include Scrum (1995), Crystal Clear, inventors of the Scrum agile Extreme Programming (1996), Adaptive Software Development, Feature Driven software development process Development, and Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as Agile Methodologies, after the Agile Manifesto published in 2001.[3]

Agile software development In 2001, 17 prominent figures[4] in the field of agile development (then called "light-weight methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.

314

Agile Manifesto principles

Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Some of the principles behind the Agile Manifesto[5] are: Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

The manifesto spawned a movement in the software industry known as agile software development. In 2005, Alistair Cockburn and Jim Highsmith gathered another group of peoplemanagement experts, this timeand wrote an addendum, known as the PM Declaration of Interdependence. The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Demings 14 points. These have been summarized in the seven points of lean software development.

Agile software development

315

Common characteristics of Agile methods

There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. Pair programming one of the agile software This helps minimize overall risk, and lets the project adapt to development techniques changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[6] Multiple iterations may be required to release a product or new features. Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements. Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called a bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams. No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems from being hidden. Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration. Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.

Agile software development

316

Comparison with other methods

Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methods. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". Further, agile teams may employ very highly disciplined formal methods. A more accurate distinction is that methods exist on a continuum from "adaptive" to "predictive".[7] Agile methods lie on the "adaptive" side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered. Formal methods, in contrast to adaptive and predictive methods focus on computer science theory with a wide array of types of provers. A formal method attempts to prove the absence of errors with some level of determinism. Some Formal methods are based on model checking and provide counter examples for code that cannot be proven. Generally, mathematical models (often supported through special languages see SPIN model checker) map to assertions about requirements. Formal method are heavily dependent on a tool driven approach, and may be combined with other development approaches. Some provers do not easily scale. Like agile methods, manifestos relevant to high integrity software have been proposed in Crosstalk [8] . Agile methods have much in common with the "Rapid Application Development" techniques from the 1980/90s as espoused by James Martin and others.

Contrasted with other iterative development methods

Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model, time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a timebox.

Contrasted with the Waterfall Methodology

Agile development has little in common with the waterfall model. The Waterfall methodology is the most structured of the methods, stepping through requirements, analysis, design, coding, and testing in a strict, pre-planned, "all at once" sequence. Progress is often measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like. A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.[9] Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early and continually improving it and/or adding further functionality throughout the life of the project. If a project

Agile software development being delivered under Waterfall is cancelled at any point up to the end, there is often nothing to show for it beyond a huge resources bill. With Agile, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation. Adaptations of Scrum[10] show how agile methods are augmented to produce and continuously improve a strategic plan. Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration.[11] Other teams, most notably Extreme Programming teams, work on activities simultaneously.

317

Contrasted with "cowboy coding"

"Cowboy coding" is the absence of a defined or structured method; i.e., team members do whatever they feel is right. The Agile approach is sometimes confused with cowboy coding due to its frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documentation. However, Agile teams follow clearly defined, even rigid processes and controls (e.g., deadlines for completion of coding/testing); it is likely the flexibility and adaptability of the overall methodology which causes the confusion. Further, Agile controls offer stronger levels of accountability. The degradation of such controls or procedures can lead to activities that are often categorized as cowboy coding.

Agile methods and method tailoring

In the literature, different terms refer to the notion of method adaptation, including method tailoring, method fragment adaptation and situational method engineering. Method tailoring is defined as: A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation.[12] Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context.[13] Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products that are part of a method framework. At a more extreme level, the philosophy behind the method, consisting of a number of principles, could be adapted (Aydin, 2004).[12] Extreme Programming (XP) makes the need for method adaptation explicit. One of the fundamental ideas of XP is that no one process fits every project, but rather that practices should be tailored to the needs of individual projects. Partial adoption of XP practices, as suggested by Beck, has been reported on several occasions.[14] A tailoring practice is proposed by Mehdi Mirakhorli [15] which provides sufficient roadmap and guideline for adapting all the practices. RDP Practice is designed for customizing XP. This practice first time proposed as a long research paper in APSO workshop at ICSE 2008 conference and yet it is the only proposed and applicable method for customizing XP. Although it is specifically a solution for XP, this practice has the capability of extending to other methodologies. At first glance, this practice seems to be in the category of static method adaptation but experiences with RDP Practice says that it can be treated like dynamic method adaptation. The distinction between static method adaptation and dynamic method adaptation is subtle.[16] The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This

Agile software development also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al., 2005).[16]

318

Agile methods
Some of the well-known agile software development methods: Agile Modeling Agile Unified Process (AUP) DSDM Essential Unified Process (EssUP) Extreme Programming (XP) Feature Driven Development (FDD) Open Unified Process (OpenUP) Scrum

Agile practices
Test Driven Development (TDD) Behavior Driven Development (BDD) Code refactoring Continuous Integration Pair Programming Planning poker RITE Method

Note: Although these are often considered methodologies in and of themselves, they are simply practices used in different methodologies.

Agile beyond software development

Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals. For more on them, see Flexible product development.

Measuring agility
While agility can be seen as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM)[17] score projects against a number of agility factors to achieve a total. The similarly-named Agility Measurement Index,[18] scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals.[19] Another study using fuzzy mathematics[20] has suggested that project velocity can be used as a metric of agility. There are agile self assessments to determine whether a team is using agile practices (Nokia test,[21] Karlskrona test,[22] 42 points test[23] ). While such approaches have been proposed to measure agility, the practical application of such metrics has yet to be seen.

Agile software development

319

Experience and reception

One of the early studies reporting gains in quality , productivity, and business satisfaction by using Agile methods was a survey conducted by Shine Technologies from November 2002 to January 2003.[24] A similar survey conducted in 2006 by Scott Ambler, the Practice Leader for Agile Development with IBM Rational's Methods Group reported similar benefits.[25] In a survey conducted by VersionOne in 2008, 55% of respondents answered that Agile methods had been successful in 90-100% of cases.[26] Others claim that agile development methods are still too young to require extensive academic proof of their success.[27]

Suitability of agile methods

There is little if any consensus on what types of software projects are best suited for the agile approach. Many large organizations have difficulty bridging the gap between the traditional waterfall method and an agile one. Large scale agile software development remains an active research area.[28] [29] Agile development has been widely documented (see Experience Reports, below, as well as Beck[30] pg. 157, and Boehm and Turner[31] ) as working well for small (<10 developers) co-located teams. Some things that can negatively impact the success of an agile project are: Large scale development efforts (>20 developers), though scaling strategies[32] and evidence to the contrary[33] have been described. Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance[34] and Using an Agile Software Process with Offshore Development[35] Forcing an agile process on a development team[36] Mission-critical systems where failure is not an option at any cost (software for surgical procedures). Several successful large scale agile projects have been documented. BT has had several hundred developers situated in the UK, Ireland and India working collaboratively on projects and using Agile methods. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success. Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods.[31] The authors suggest that each side of the continuum has its own home ground as follows: Agile home ground:[31] Low criticality Senior developers Requirements change often Small number of developers Culture that thrives on chaos

Plan-driven home ground:[31] High criticality Junior developers Requirements do not change often Large number of developers Culture that demands order

Formal Methods Extreme criticality Senior developers Limited requirements, limited features see Wirth's law

Agile software development Requirements that can be modeled Extreme quality

320

Experience reports
Agile development has been the subject of several conferences. Some of these conferences have had academic backing and included peer-reviewed papers, including a peer-reviewed experience report track. The experience reports share industry experiences with agile software development. As of 2006, experience reports have been or will be presented at the following conferences: XP (2000,[37] 2001, 2002, 2003, 2004, 2005, 2006,[38] 2010[39] ) XP Universe (2001[40] ) XP/Agile Universe (2002,[41] 2003,[42] 2004[43] ) Agile Development Conference[44] starting from 2003 to present (peer-reviewed; proceedings published by IEEE)

Criticism
Agile does not readily lend itself to traditional project accounting practices, therefore financial forecasting is less predictable with Agile development.[45] Agile is another Rapid Application Development or Iterative Development methodology that shares the same caveats in using such approaches. Agile's assumption of dedicated resources conflicts with Lean principles and organizational environments. Solutions built using Agile methodology often will lack scalability and cost effective maintainability. Agile is often used as an excuse to not plan and subsequently leads to many rebuilds of solution architectures when new functionality is required. Many techniques within Agile are similar to concepts within other methodologies. The concept of Sprints is synonymous with many Program and Project Management principles of Work Packaging and WBS elements. As with any methodology, one must perform due diligence by understanding how to effectively apply Agile practices and principles as a toolset of techniques and not a process. Assuming a scalable service oriented architecture is established with a commensurate development platform, Agile methodology as a toolset of techniques (again, not process) does hold merit and validity from a product management perspective in implementing enhancements to existing solutions within the context of a well planned release roadmap.

See also
Agile web development Code refactoring Collaborative software development model Continuous integration Extreme Programming (XP) Scrum (development) Lean software development List of software development philosophies Multi-stage continuous integration Systems Development Life Cycle Software Engineering Software Craftsmanship

Agile software development

321

Further reading
Fowler, Martin. Is Design Dead? [46]. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001. Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other [47]. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001. M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003. (ISBN 1-59059-096-1) Larman, Craig and Basili, Victor R. Iterative and Incremental Development: A Brief History IEEE Computer, June 2003 [48] Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478. Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp.166). New York: Elsevier Science. Rother, Mike (2009). Toyota Kata [49]. McGraw-Hill. ISBN0071635238

External links
Manifesto for Agile Software Development [50] The Agile Alliance [51] The Agile Executive [52] Article Two Ways to Build a Pyramid by John Mayo-Smith [53] The New Methodology [54] Martin Fowler's description of the background to agile methods Agile Journal [55] - Largest online community focused specifically on agile development Agile [56] at the Open Directory Project Agile Cookbook [57]

References
[1] Gerald M. Weinberg: We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBMs ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for software development. quoted in Larman, Craig; Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" (http:/ / www2. umassd. edu/ SWPI/ xp/ articles/ r6047. pdf) (PDF). Computer 36 (6): pp 4756. doi:10.1109/MC.2003.1204375. . Retrieved 2007-02-22. ( Permission note (http:/ / www. agilealliance. org/ show/ 1404)) [2] Edmonds, E. A. (1974). "A process for the development of software for non-technical users as an adaptive system". General Systems XIX: 215218. [3] Larman, Craig (2004). Agile and iterative development: a manager's guide. Addison-Wesley. p.27. ISBN9780131111554 [4] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas [5] "Agile Manifesto principles" (http:/ / www. agilemanifesto. org/ principles. html). Agilemanifesto.org. . Retrieved 2010-06-06. [6] Beck, Kent (1999). "Embracing Change with Extreme Programming". Computer 32 (10): 7077. doi:10.1109/2.796139. [7] Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN0-321-18612-5. Appendix A, pages 165-194 [8] http:/ / elsmar. com/ pdf_files/ A%20Manifesto%20for%20High-Integrity%20Software. pdf [9] Sommerville, Ian (2007) [1982]. "4.1.1. The waterfall model". Software engineering (8th ed.). Harlow: Addison Wesley. pp.66f. ISBN0-321-31379-8. [10] Ambler, S. (April 2008). ""Scaling Scrum - Meeting Real World Development Needs" (http:/ / www. ddj. com/ architect/ 207100381). Dr. Dobbs. . Retrieved 2009-12-27. [11] As reported (http:/ / heavylogic. com/ agile. php) by HeavyLogic (http:/ / heavylogic. com)

Agile software development

[12] Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138 [13] Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254 [14] Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478 [15] http:/ / portal. acm. org/ citation. cfm?id=1370143. 1370149& coll=ACM& dl=ACM& CFID=69442744& CFTOKEN=96226775, [16] Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information(Suren) Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24 [17] "David Bock's Weblog : Weblog" (http:/ / jroller. com/ page/ bokmann?entry=improving_your_processes_aim_high). Jroller.com. . Retrieved 2010-04-02. [18] "Agility measurement index" (http:/ / doi. acm. org/ 10. 1145/ 1185448. 1185509). Doi.acm.org. . Retrieved 2010-04-02. [19] Peter Lappo; Henry C.T. Andrew. "Assessing Agility" (http:/ / www. smr. co. uk/ presentations/ measure. pdf). . Retrieved 2010-06-06. [20] Kurian, Tisni (2006). "Agility Metrics: A Quantitative Fuzzy Based Approach for Measuring Agility of a Software Process" ISAM-Proceedings of International Conference on Agile Manufacturing'06(ICAM-2006), Norfolk, U.S. [21] Joe Little (2007-12-02). "Nokia test, A Scrum specific test" (http:/ / agileconsortium. blogspot. com/ 2007/ 12/ nokia-test. html). Agileconsortium.blogspot.com. . Retrieved 2010-06-06. [22] Mark Seuffert, Piratson Technologies, Sweden. "Karlskrona test, A generic agile adoption test" (http:/ / www. piratson. se/ archive/ Agile_Karlskrona_Test. html). Piratson.se. . Retrieved 2010-06-06. [23] "How agile are you, A Scrum specific test" (http:/ / www. agile-software-development. com/ 2008/ 01/ how-agile-are-you-take-this-42-point. html). Agile-software-development.com. . Retrieved 2010-06-06. [24] "Agile Methodologies Survey Results" (http:/ / www. shinetech. com/ attachments/ 104_ShineTechAgileSurvey2003-01-17. pdf) (PDF). Shine Technologies (http:/ / www. shinetech. com). 2003. . Retrieved 2010-06-03. "95% [stated] that there was either no effect or a cost reduction . . . 93% stated that productivity was better or significantly better . . . 88% stated that quality was better or significantly better . . . 83% stated that business satisfaction was better or significantly better"

322

[25] Ambler, Scott (August 3, 2006). [httphttp://www.drdobbs.com/architecture-and-design/191800169;jsessionid=2QJ23QRYM3H4PQE1GHPCKH4ATMY32JVN?queryText=agile+survey "Survey Says: Agile Works in Practice"]. Dr. Dobb's. httphttp://www.drdobbs.com/architecture-and-design/191800169;jsessionid=2QJ23QRYM3H4PQE1GHPCKH4ATMY32JVN?queryText=agile+survey. Retrieved 2010-06-03. "Only 6 percent indicated that their productivity was lowered . . . No change in productivity was reported by 34 percent of respondents and 60 percent reported increased productivity. . . . 66 percent [responded] that the quality is higher. . . . 58 percent of organizations report improved satisfaction, whereas only 3 percent report reduced satisfaction." [26] "The State of Agile Development" (http:/ / www. versionone. com/ pdf/ 3rdAnnualStateOfAgile_FullDataReport. pdf) (PDF). VersionOne, Inc.. 2008. . Retrieved 2010-07-03. "Agile delivers" [27] "Answering the "Where is the Proof That Agile Methods Work" Question" (http:/ / www. agilemodeling. com/ essays/ proof. htm). Agilemodeling.com. 2007-01-19. . Retrieved 2010-04-02. [28] Agile Processes Workshop II Managing Multiple Concurrent Agile Projects. Washington: OOPSLA 2002 [29] "Supersize Me" in Dr. Dobb's Journal, February 15, 2006. [30] Beck, K. (1999). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. ISBN0-321-27865-8. [31] Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp.5557. ISBN0-321-18612-5. [32] "Supersize Me" (http:/ / www. sdmagazine. com/ documents/ s=10020/ sdm0603g/ 0603g. html). Sdmagazine.com. . Retrieved 2010-06-06. [33] Schaaf, R.J. (2007). "Agility XL", Systems and Software Technology Conference 2007 (http:/ / www. sstc-online. org/ Proceedings/ 2007/ pdfs/ RJS1722. pdf), Tampa, FL [34] "Bridging the Distance" (http:/ / www. sdmagazine. com/ documents/ s=7556/ sdm0209i/ sdm0209i. htm). Sdmagazine.com. . Retrieved 2010-06-06. [35] Martin Fowler. "Using an Agile Software Process with Offshore Development" (http:/ / www. martinfowler. com/ articles/ agileOffshore. html). Martinfowler.com. . Retrieved 2010-06-06. [36] [The Art of Agile Development James Shore & Shane Warden pg 47] [37] 2000 (http:/ / ciclamino. dibe. unige. it/ xp2000/ ) [38] "2006" (http:/ / virtual. vtt. fi/ virtual/ xp2006/ ). Virtual.vtt.fi. . Retrieved 2010-06-06. [39] "2010" (http:/ / www. xp2010. org/ ). Xp2010.org. . Retrieved 2010-06-06. [40] 2001 (http:/ / www. xpuniverse. com/ 2001/ xpuPapers. htm) [41] 2002 (http:/ / www. xpuniverse. com/ 2002/ schedule/ schedule) [42] 2003 (http:/ / www. xpuniverse. com/ 2003/ schedule/ index) [43] 2004 (http:/ / www. xpuniverse. com/ 2004/ schedule/ index) [44] "Agile Development Conference" (http:/ / www. agile200x. org/ ). Agile200x.org. . Retrieved 2010-06-06. [45] Papadimoulis, Alex (2007-05-24). "The Great Pyramid of Agile" (http:/ / worsethanfailure. com/ Articles/ The-Great-Pyramid-of-Agile. aspx). Worsethanfailure.com. . Retrieved 2010-06-06.

Agile software development

[46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] http:/ / www. martinfowler. com/ articles/ designDead. html http:/ / www. riehle. org/ computer-science/ research/ 2000/ xp-2000. html http:/ / www2. umassd. edu/ SWPI/ xp/ articles/ r6047. pdf http:/ / books. google. com/ ?id=_1lhPgAACAAJ& dq=toyota+ kata http:/ / www. agileManifesto. org/ http:/ / www. agilealliance. org/ http:/ / theagileexecutive. com/ http:/ / www. informationweek. com/ news/ software/ development/ showArticle. jhtml?articleID=6507351 http:/ / martinfowler. com/ articles/ newMethodology. html http:/ / www. agilejournal. com/ http:/ / www. dmoz. org/ Computers/ Programming/ Methodologies/ Agile/ http:/ / agilecookbook. com/

323

Program Evaluation and Review Technique

The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project. It is commonly used in conjunction with the critical path method or CPM.

Overview
PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project.
PERT network chart for a seven-month project with five milestones (10 through 50) and six activities (A through F).

PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was developed by Bill Pocock of Booz Allen Hamilton and Gordon Perhson of the U.S. Navy Special Projects Office in 1957 to support the U.S. Navy's Polaris nuclear submarine project. It was able to incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in projects where time, rather than cost, is the major factor. It is applied to very large-scale, one-time, complex, non-routine infrastructure and Research and Development projects. This project model was the first of its kind, a revival for scientific management, founded by Frederick Taylor (Taylorism) and later refined by Henry Ford (Fordism). DuPont corporation's critical path method was invented at roughly the same time as PERT.

Program Evaluation and Review Technique

324

Conventions
A PERT chart is a tool that facilitates decision making; The first draft of a PERT chart will number its events sequentially in 10s (10, 20, 30, etc.) to allow the later insertion of additional events. Two consecutive events in a PERT chart are linked by activities, which are conventionally represented as arrows (see the diagram above). The events are presented in a logical sequence and no activity can commence until its immediately preceding event is completed. The planner decides which milestones should be PERT events and also decides their proper sequence. A PERT chart may have multiple pages with many sub-tasks. PERT is valuable to manage where multiple tasks are going simultaneously to reduce the redundancy

Terminology
PERT event: a point that marks the start or completion of one or more activities. It consumes no time, and uses no resources. When it marks the completion of one or more tasks, it is not reached (does not occur) until all of the activities leading to that event have been completed. predecessor event: an event that immediately precedes some other event without any other events intervening. An event can have multiple predecessor events and can be the predecessor of multiple events. successor event: an event that immediately follows some other event without any other intervening events. An event can have multiple successor events and can be the successor of multiple events. PERT activity: the actual performance of a task which consumes time and requires resources (such as labour, materials, space, machinery). It can be understood as representing the time, effort, and resources required to move from one event to another. A PERT activity cannot be performed until the predecessor event has occurred. Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes). Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal. Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time). TE = (O + 4M + P) 6 Float or Slack is the amount of time that a task in a project network can be delayed without causing a delay Subsequent tasks (free float) or Project Completion (total float) Critical Path: the longest possible continuous pathway taken from the initial event to the terminal event. It determines the total calendar time required for the project; and, therefore, any time delays along the critical path will delay the reaching of the terminal event by at least the same amount. Critical Activity: An activity that has total float equal to zero. Activity with zero float does not mean it is on the critical path. Lead [1] time: the time by which a predecessor event must be completed in order to allow sufficient time for the activities that must elapse before a specific PERT event reaches completion. Lag time: the earliest time by which a successor event can follow a specific PERT event. Slack: the slack of an event is a measure of the excess time and resources available in achieving this event. Positive slack would indicate ahead of schedule; negative slack would indicate behind schedule; and zero slack would indicate on schedule. Fast tracking: performing more critical activities in parallel

Program Evaluation and Review Technique Crashing critical path: Shortening duration of critical activities

325

Implementation
The first step to scheduling the project is to determine the tasks that the project requires and the order in which they must be completed. The order may be easy to record for some tasks (e.g. When building a house, the land must be graded before the foundation can be laid) while difficult for others (There are two areas that need to be graded, but there are only enough bulldozers to do one). Additionally, the time estimates usually reflect the normal, non-rushed time. Many times, the time required to execute the task can be reduced for an additional cost or a reduction in the quality. 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 Opt. (O) Time estimates Normal (M) 4 5 5 6 5 4 5 6 9 7 10 7 8 8 Pess. (P) 4.00 5.33 5.17 6.33 5.17 4.50 5.17 Expected time

A B C D E F G

A A B, C D E

2 3 4 4 4 3 3

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

A network diagram can be created by hand or by using diagram software. There are two types of network diagrams, activity on arrow (AOA) and activity on node (AON). Activity on node diagrams are generally easier to create and interpret. To create an AON diagram, it is recommended (but not required) to start with a node named start. This "activity" has a duration of zero (0). Then you draw each activity that does not have a predecessor activity (a and b in this example) and connect them with an arrow from start to each node. Next, since both c and d list a as a predecessor activity, their nodes are drawn with arrows coming from a. Activity e is listed with b and c as predecessor activities, so node e is drawn with arrows coming from both b and c, signifying that e cannot begin until both b and c have been completed. Activity f has d as a predecessor activity, so an arrow is drawn connecting the activities. Likewise, an arrow is drawn from e to g. Since there are no activities that come after f or g, it is recommended (but again not required) to connect them to a node labeled finish.

Program Evaluation and Review Technique

326

By itself, the network diagram pictured above does not give much more information than a Gantt chart; however, it can be expanded to display more information. The most common information shown is: 1. 2. 3. 4. 5. 6. 7. The activity name The normal duration time The early start time (ES) The early finish time (EF) The late start time (LS) The late finish time (LF) The slack

In order to determine this information it is assumed that the activities and normal duration times are given. The first step is to determine the ES and EF. The ES is defined as the maximum EF of all predecessor activities, unless the activity in question is the first activity, for which the ES is zero (0). The EF is the ES plus the task duration (EF = ES + duration). The ES for start is zero since it is the first activity. Since the duration is zero, the EF is also zero. This EF is used as the ES for a and b. The ES for a is zero. The duration (4 work days) is added to the ES to get an EF of four. This EF is used as the ES for c and d. The ES for b is zero. The duration (5.33 work days) is added to the ES to get an EF of 5.33. The ES for c is four. The duration (5.17 work days) is added to the ES to get an EF of 9.17. The ES for d is four. The duration (6.33 work days) is added to the ES to get an EF of 10.33. This EF is used as the ES for f. The ES for e is the greatest EF of its predecessor activities (b and c). Since b has an EF of 5.33 and c has an EF of 9.17, the ES of e is 9.17. The duration (5.17 work days) is added to the ES to get an EF of 14.34. This EF is used as the ES for g. The ES for f is 10.33. The duration (4.5 work days) is added to the ES to get an EF of 14.83. The ES for g is 14.34. The duration (5.17 work days) is added to the ES to get an EF of 19.51. The ES for finish is the greatest EF of its predecessor activities (f and g). Since f has an EF of 14.83 and g has an EF of 19.51, the ES of finish is 19.51. Finish is a milestone (and therefore has a duration of zero), so the EF is also 19.51. Barring any unforeseen events, the project should take 19.51 work days to complete. The next step is to determine the late start (LS) and late finish (LF) of each activity. This will eventually show if there are activities that have slack. The LF is defined as the minimum LS of all successor activities, unless the activity is the last activity, for which the LF equals the EF. The LS is the LF minus the task duration (LS = LF - duration). The LF for finish is equal to the EF (19.51 work days) since it is the last activity in the project. Since the duration is zero, the LS is also 19.51 work days. This will be used as the LF for f and g. The LF for g is 19.51 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of 14.34 work days. This will be used as the LF for e. The LF for f is 19.51 work days. The duration (4.5 work days) is subtracted from the LF to get an LS of 15.01 work days. This will be used as the LF for d. The LF for e is 14.34 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of 9.17 work days. This will be used as the LF for b and c.

A node like this one (from Microsoft Visio) can be used to display the activity name, duration, ES, EF, LS, LF, and slack.

Program Evaluation and Review Technique The LF for d is 15.01 work days. The duration (6.33 work days) is subtracted from the LF to get an LS of 8.68 work days. The LF for c is 9.17 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of 4 work days. The LF for b is 9.17 work days. The duration (5.33 work days) is subtracted from the LF to get an LS of 3.84 work days. The LF for a is the minimum LS of its successor activities. Since c has an LS of 4 work days and d has an LS of 8.68 work days, the LF for a is 4 work days. The duration (4 work days) is subtracted from the LF to get an LS of 0 work days. The LF for start is the minimum LS of its successor activities. Since a has an LS of 0 work days and b has an LS of 3.84 work days, the LS is 0 work days. The next step is to determine the critical path and if any activities have slack. The critical path is the path that takes the longest to complete. To determine the path times, add the task durations for all available paths. Activities that have slack can be delayed without changing the overall time of the project. Slack is computed in one of two ways, slack = LF - EF or slack = LS - ES. Activities that are on the critical path have a slack of zero (0). The duration of path adf is 14.83 work days. The duration of path aceg is 19.51 work days. The duration of path beg is 15.67 work days. The critical path is aceg and the critical time is 19.51 work days. It is important to note that there can be more than one critical path (in a project more complex than this example) or that the critical path can change. For example, let's say that activities d and f take their pessimistic (b) times to complete instead of their expected (TE) times. The critical path is now adf and the critical time is 22 work days. On the other hand, if activity c can be reduced to one work day, the path time for aceg is reduced to 15.34 work days, which is slightly less than the time of the new critical path, beg (15.67 work days). Assuming these scenarios do not happen, the slack for each activity can now be determined. Start and finish are milestones and by definition have no duration, therefore they can have no slack (0 work days). The activities on the critical path by definition have a slack of zero; however, it is always a good idea to check the math anyway when drawing by hand. LFa - EFa = 4 - 4 = 0 LFc - EFc = 9.17 - 9.17 = 0 LFe - EFe = 14.34 - 14.34 = 0 LFg - EFg = 19.51 - 19.51 = 0 Activity b has an LF of 9.17 and an EF of 5.33, so the slack is 3.84 work days. Activity d has an LF of 15.01 and an EF of 10.33, so the slack is 4.68 work days. Activity f has an LF of 19.51 and an EF of 14.83, so the slack is 4.68 work days. Therefore, activity b can be delayed almost 4 work days without delaying the project. Likewise, activity d or activity f can be delayed 4.68 work days without delaying the project (alternatively, d and f can be delayed 2.34 work days each).

327

Program Evaluation and Review Technique

328

Advantages
PERT chart explicitly defines and makes visible dependencies (precedence relationships) between the WBS elements PERT facilitates identification of the critical path and makes this visible PERT facilitates identification of early start, late start, and slack for each activity, PERT provides for potentially reduced project duration due to better understanding of A completed network diagram created using Microsoft Visio. Note the critical path is in dependencies leading to improved red. overlapping of activities and tasks where feasible. The large amount of project data can be organized & presented in diagram for use in decision making.

Disadvantages
There can be potentially hundreds or thousands of activities and individual dependency relationships The network charts tend to be large and unwieldy requiring several pages to print and requiring special size paper The lack of a timeframe on most PERT/CPM charts makes it harder to show status although colours can help (e.g., specific colour for completed nodes) When the PERT/CPM charts become unwieldy, they are no longer used to manage the project.

Uncertainty in project scheduling

During project execution, however, a real-life project will never execute exactly as it was planned due to uncertainty. It can be ambiguity resulting from subjective estimates that are prone to human errors or it can be variability arising from unexpected events or risks. And Project Evaluation and Review Technique (PERT) may provide inaccurate information about the project completion time for main reason uncertainty. This inaccuracy is large enough to render such estimates as not helpful. One possibility to maximize solution robustness is to include safety in the baseline schedule in order to absorb the anticipated disruptions. This is called proactive scheduling. A pure proactive scheduling is an utopia, incorporating safety in a baseline schedule that allows to cope with every possible disruption would lead to a baseline schedule with a very large make-span. A second approach, reactive scheduling, consists of defining a procedure to react to disruptions that cannot be absorbed by the baseline schedule.

Program Evaluation and Review Technique

329

See also
Activity diagram Beta distribution Critical Path Method Float (project management) Gantt chart Project network Project management Project planning Triangular distribution PRINCE2

Further reading
Project Management Institute (2003). A Guide To The Project Management Body Of Knowledge (3rd ed. ed.). Project Management Institute. ISBN1-930699-45-X. Klastorin, Ted (2003). Project Management: Tools and Trade-offs (3rd ed. ed.). Wiley. ISBN978-0471413844. Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th Ed. ed.). Wiley. ISBN0-471-22577-0. Milosevic, Dragan Z. (2003). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. ISBN978-0471208228.

External links
More explanation of PERT [2] 3 Point Estimating Tutorial on VisionaryTools.com [3]

References
[1] http:/ / en. wiktionary. org/ wiki/ lead#Verb_2 [2] http:/ / www. netmba. com/ operations/ project/ pert [3] http:/ / www. visionarytools. com/ decision-making/ 3-point-estimating. htm

Computer software

330

Computer software
Computer software, or just software, is the collection of computer programs and related data that provide the instructions telling a computer what to do. The term was coined to contrast to the old term hardware (meaning physical devices). In contrast to hardware, software is intangible, meaning it "cannot be touched".[1] Software is also sometimes used in a more narrow sense, meaning application software only. Sometimes the term includes data that has not traditionally been associated with computers, such as film, tapes and records.[2] Examples of computer software include: Application software includes end-user applications of computers such as word processors or Video games, and ERP software for groups of users. Middleware controls and co-ordinates distributed systems. Programming languages define the syntax and sematics of computer programs. For example, many mature banking applications were written in the COBOL language, originally invented in 1959. Newer applications are often written in more modern programming languages. System software includes operating systems, which govern computing resources. Today large applications running on remote machines such as Websites are considered to be system software, because the end-user interface is generally through a Graphical user interface (GUI), such as a web browser. Testware is software for testing hardware or a software package. Firmware is low-level software often stored on electrically programmable memory devices. Firmware is given its name because it is treated like hardware and run ("executed") by other software programs. Device drivers control parts of computers such as disk drives, printers, CD drives, or computer monitors. Programming tools help conduct computing tasks in any category listed above. For programmers, these could be tools for debugging, or reverse engineering older legacy systems in order to check source code compatibility.

History
The first theory about software was proposed by Alan Turing in his 1935 essay Computable numbers with an application to the Entscheidungsproblem (Decision problem).[3] Paul Niquette claims to have coined the term "software" in this sense in 1953,[4] and first used in print by John W. Tukey in 1958.[5] The academic fields studying software are computer science and software engineering. The history of computer software is most often traced back to the first software bug in 1946. As more and more programs enter the realm of firmware, and the hardware itself becomes smaller, cheaper and faster due to Moore's law, elements of computing first considered to be software, join the ranks of hardware. Most hardware companies today have more software programmers on the payroll than hardware designers, since software tools have automated many tasks of Printed circuit board engineers. Just like the Auto industry, the Software industry has grown from a few visionaries operating out of their garage with prototypes. Steve Jobs and Bill Gates were the Henry Ford and Louis Chevrolet of their times, who capitalized on ideas already commonly known before they started in the business. In the case of Software development, this moment is generally agreed to be the publication in the 1980's of the specifications for the IBM Personal Computer published by IBM employee Philip Don Estridge. Today his move would be seen as a type of crowd-sourcing. Until that time, software was bundled with the hardware by Original equipment manufacturers (OEMs) such as Data General, Digital Equipment and IBM. When a customer bought a minicomputer, at that time the smallest computer on the market, the computer did not come with Pre-installed software, but needed to be installed by engineers employed by the OEM. Computer hardware companies not only bundled their software, they also placed demands on the location of the hardware in a refrigerated space called a computer room. Most companies had their software on the books for 0 dollars, unable to claim it as an asset (this is similar to financing of popular music in those days).

Computer software When Data General introduced the Data General Nova, a company called Digidyne wanted to use its RDOS operating system on its own hardware clone. Data General refused to license their software (which was hard to do, since it was on the books as a free asset), and claimed their "bundling rights". The Supreme Court set a precedent called Digidyne v. Data General in 1985. The Supreme Court let a 9th circuit decision stand, and Data General was eventually forced into licensing the Operating System software because it was ruled that restricting the license to only DG hardware was an illegal tying arrangement.[6] Soon after, IBM 'published' its DOS source for free, and Microsoft was born. Unable to sustain the loss from lawyer's fees, Data General ended up being taken over by EMC Corporation. The Supreme Court decision made it possible to value software, and also purchase Software patents. The move by IBM was almost a protest at the time. Few in the industry believed that anyone would profit from it other than IBM (through free publicity). Microsoft and Apple were able to thus cash in on 'soft' products. It is hard to imagine today that people once felt that software was worthless without a machine. There are many successful companies today that sell only software products, though there are still many common software licensing problems due to the complexity of designs and poor documentation, leading to patent trolls. With open software specifications and the possibility of software licensing, new opportunities arose for software tools that then became the de facto standard, such as DOS for operating systems, but also various proprietary word processing and spreadsheet programs. In a similar growth pattern, proprietary development methods became standard Software development methodology.

331

Overview
Software includes all the various forms and roles that digitally stored data may have and play in a computer (or similar system), regardless of whether the data is used as code for a CPU, or other interpreter, or whether it represents other kinds of information. Software thus encompasses a wide array of products that may be developed using different techniques such as ordinary programming languages, scripting languages, microcode, or an FPGA configuration. The types of software include web pages developed in languages and frameworks like HTML, PHP, Perl, JSP, ASP.NET, XML, and desktop applications like OpenOffice, Microsoft Word developed in languages like C, C++, Java, C#, or Smalltalk. Application software usually runs on an underlying software operating systems such as Linux or Microsoft Windows. Software (or firmware) is also used in video games and for the configurable parts of the logic systems of automobiles, televisions, and other consumer electronics. Computer software is so called to distinguish it from computer A layer structure showing where operating hardware, which encompasses the physical interconnections and system is located on generally used software devices required to store and execute (or run) the software. At the systems on desktops lowest level, executable code consists of machine language instructions specific to an individual processor. A machine language consists of groups of binary values signifying processor instructions that change the state of the computer from its preceding state. Programs are an ordered sequence of instructions for changing the state of the computer in a particular sequence. It is usually written in high-level programming languages that are easier and more efficient for humans to use (closer to natural language) than machine language. High-level languages are compiled or interpreted into machine language object code. Software may also be written in an assembly language, essentially, a mnemonic representation of a machine language using a natural language alphabet. Assembly language must be assembled into object code via an assembler.

Computer software

332

Types of software
Practical computer systems divide software systems into three major classes: system software, programming software and application software, although the distinction is arbitrary, and often blurred.

System software
System software helps run the computer hardware and computer system. It includes a combination of the following: device drivers operating systems servers utilities windowing systems

The purpose of systems software is to unburden the applications programmer from the often complex details of the particular computer being used, including such accessories as communications devices, printers, device readers, displays and keyboards, and also to partition the computer's resources such as memory and processor time in a safe and stable manner. Examples are - Microsoft Windows, Linux, and Mac OS X.

Programming software
Programming software usually provides tools to assist a programmer in writing computer programs, and software using different programming languages in a more convenient way. The tools include: compilers debuggers interpreters linkers text editors

An Integrated development environment (IDE) is a single application that attempts to manage all these functions.

Application software
Application software allows end users to accomplish one or more specific (not directly computer development related) tasks. Typical applications include: industrial automation business software video games quantum chemistry and solid state physics software telecommunications (i.e., the Internet and everything that flows on it) databases educational software medical software military software molecular modeling software image editing spreadsheet simulation software Word processing

Decision making software Application software exists for and has impacted a wide variety of topics.

Computer software

333

Software topics
Architecture
Users often see things differently than programmers. People who use modern general purpose computers (as opposed to embedded systems, analog computers and supercomputers) usually see three layers of software performing a variety of tasks: platform, application, and user software. Platform software: Platform includes the firmware, device drivers, an operating system, and typically a graphical user interface which, in total, allow a user to interact with the computer and its peripherals (associated equipment). Platform software often comes bundled with the computer. On a PC you will usually have the ability to change the platform software. Application software: Application software or Applications are what most people think of when they think of software. Typical examples include office suites and video games. Application software is often purchased separately from computer hardware. Sometimes applications are bundled with the computer, but that does not change the fact that they run as independent applications. Applications are usually independent programs from the operating system, though they are often tailored for specific platforms. Most users think of compilers, databases, and other "system software" as applications. User-written software: End-user development tailors systems to meet users' specific needs. User software include spreadsheet templates and word processor templates. Even email filters are a kind of user software. Users create this software themselves and often overlook how important it is. Depending on how competently the user-written software has been integrated into default application packages, many users may not be aware of the distinction between the original packages, and what has been added by co-workers.

Documentation
Most software has software documentation so that the end user can understand the program, what it does, and how to use it. Without a clear documentation, software can be hard to useespecially if it is a very specialized and relatively complex software like the Photoshop or AutoCAD. Developer documentation may also exist, either with the code as comments and/or as separate files, detailing how the programs works and can be modified.

Library
An executable is almost always not sufficiently complete for direct execution. Software libraries include collections of functions and functionality that may be embedded in other applications. Operating systems include many standard Software libraries, and applications are often distributed with their own libraries.

Standard
Since software can be designed using many different programming languages and in many different operating systems and operating environments, software standard is needed so that different software can understand and exchange information between each other. For instance, an email sent from a Microsoft Outlook should be readable from Yahoo! Mail and vice versa.

Computer software

334

Execution
Computer software has to be "loaded" into the computer's storage (such as the hard drive or memory). Once the software has loaded, the computer is able to execute the software. This involves passing instructions from the application software, through the system software, to the hardware which ultimately receives the instruction as machine code. Each instruction causes the computer to carry out an operation moving data, carrying out a computation, or altering the control flow of instructions. Data movement is typically from one place in memory to another. Sometimes it involves moving data between memory and registers which enable high-speed data access in the CPU. Moving data, especially large amounts of it, can be costly. So, this is sometimes avoided by using "pointers" to data instead. Computations include simple operations such as incrementing the value of a variable data element. More complex computations may involve many operations and data elements together.

Quality and reliability

Software quality is very important, especially for commercial and system software like Microsoft Office, Microsoft Windows and Linux. If software is faulty (buggy), it can delete a person's work, crash the computer and do other unexpected things. Faults and errors are called "bugs." Many bugs are discovered and eliminated (debugged) through software testing. However, software testing rarely if ever eliminates every bug; some programmers say that "every program has at least one more bug" (Lubarsky's Law). All major software companies, such as Microsoft, Novell and Sun Microsystems, have their own software testing departments with the specific goal of just testing. Software can be tested through unit testing, regression testing and other methods, which are done manually, or most commonly, automatically, since the amount of code to be tested can be quite large. For instance, NASA has extremely rigorous software testing procedures for many operating systems and communication functions. Many NASA based operations interact and identify each other through command programs called software. This enables many people who work at NASA to check and evaluate functional systems overall. Programs containing command software enable hardware engineering and system operations to function much easier together.

License
The software's license gives the user the right to use the software in the licensed environment. Some software comes with the license when purchased off the shelf, or an OEM license when bundled with hardware. Other software comes with a free software license, granting the recipient the rights to modify and redistribute the software. Software can also be in the form of freeware or shareware.

Patents
Software can be patented; however, software patents can be controversial in the software industry with many people holding different views about it. The controversy over software patents is that a specific algorithm or technique that the software has may not be duplicated by others and is considered an intellectual property and copyright infringement depending on the severity.

Computer software

335

Design and implementation

Design and implementation of software varies depending on the complexity of the software. For instance, design and creation of Microsoft Word software will take much more time than designing and developing Microsoft Notepad because of the difference in functionalities in each one. Software is usually designed and created (coded/written/programmed) in integrated development environments (IDE) like Eclipse, Emacs and Microsoft Visual Studio that can simplify the process and compile the program. As noted in different section, software is usually created on top of existing software and the application programming interface (API) that the underlying software provides like GTK+, JavaBeans or Swing. Libraries (APIs) are categorized for different purposes. For instance, JavaBeans library is used for designing enterprise applications, Windows Forms library is used for designing graphical user interface (GUI) applications like Microsoft Word, and Windows Communication Foundation is used for designing web services. Underlying computer programming concepts like quicksort, hashtable, array, and binary tree can be useful to creating software. When a program is designed, it relies on the API. For instance, if a user is designing a Microsoft Windows desktop application, he/she might use the .NET Windows Forms library to design the desktop application and call its APIs like Form1.Close() and Form1.Show()[7] to close or open the application and write the additional operations him/herself that it need to have. Without these APIs, the programmer needs to write these APIs him/herself. Companies like Sun Microsystems, Novell, and Microsoft provide their own APIs so that many applications are written using their software libraries that usually have numerous APIs in them. Software has special economic characteristics that make its design, creation, and distribution different from most other economic goods.[8] [9] A person who creates software is called a programmer, software engineer, software developer, or code monkey, terms that all have a similar meaning.

Industry and organizations

A great variety of software companies and programmers in the world comprise the software industry . Software can be quite a profitable industry: Bill Gates, the founder of Microsoft was the richest person in the world in 2009 largely by selling the Microsoft Windows and Microsoft Office software products. The same goes for Larry Ellison, largely through his Oracle database software. Through time the software industry has become increasingly specialized. Non-profit software organizations include the Free Software Foundation, GNU Project and Mozilla Foundation. Software standard organizations like the W3C, IETF develop software standards so that most software can interoperate through standards such as XML, HTML, HTTP or FTP. Other well-known large software companies include Novell, SAP, Symantec, Adobe Systems, and Corel, while small companies often provide innovation.

References
[1] "Wordreference.com: WordNet 2.0" (http:/ / www. wordreference. com/ definition/ software). Princeton University, Princeton, NJ. . Retrieved 2007-08-19. [2] software..(n.d.). Dictionary.com Unabridged (v 1.1). Retrieved 2007-04-13, from Dictionary.com website: http:/ / dictionary. reference. com/ browse/ software [3] Hally, Mike (2005:79). Electronic brains/Stories from the dawn of the computer age. British Broadcasting Corporation and Granta Books, London. ISBN 1-86207-663-4. [4] Paul Niquette (1995). "Softword: Provenance for the Word 'Software'" (http:/ / www. niquette. com/ books/ softword/ tocsoft. html). . adapted from Sophisticated: The Magazine ISBN 1-58922-233-4 [5] "John Tukey, 85, Statistician; Coined the Word 'Software'" (http:/ / query. nytimes. com/ gst/ fullpage. html?res=9500E4DA173DF93BA15754C0A9669C8B63). New York Times. July 28, 2000. . [6] Tying Arrangements and the Computer Industry: Digidyne Corp. vs. Data General (http:/ / www. jstor. org/ pss/ 1372482) [7] MSDN Library (http:/ / msdn. microsoft. com/ en-us/ library/ default. aspx) [8] v. Engelhardt, Sebastian (2008): "The Economic Properties of Software", Jena Economic Research Papers, Volume 2 (2008), Number 2008-045. (http:/ / ideas. repec. org/ p/ jrp/ jrpwrp/ 2008-045. html) (in Adobe pdf format)

Computer software
[9] "Why Open Source Is The Optimum Economic Paradigm for Software" (http:/ / www. doxpara. com/ read. php/ core. html) by Dan Kaminsky 1999

336

Software engineering
Software engineering is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build. The term software engineering first appeared in the 1968 NATO Software Engineering Conference, and was meant to provoke thought regarding the perceived "software crisis" at the time.[1] [2] Since the field is still relatively young compared to its sister fields of engineering, there is still much debate around what software engineering actually is, and if it The Airbus A380 uses a substantial amount of software to create a "paperless" conforms to the classical definition of cockpit. Software engineering maps and plans the millions of lines of code engineering. Some people argue that constituting the plane's software development of computer software is more art than science [3] , and that attempting to impose engineering disciplines over a type of art is an exercise in futility because what represents good practice in the creation of software is not even defined.[4] Others, such as Steve McConnell, argue that engineering's blend of art and science to achieve practical ends provides a useful model for software development.[5] The IEEE Computer Society's Software Engineering Body of Knowledge defines "software engineering" as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.[6] Software development, a much used and more generic term, does not necessarily subsume the engineering paradigm. Although it is questionable what impact it has had on actual software development over the last more than 40 years,[7] [8] the field's future looks bright according to Money Magazine and Salary.com [9], who rated "software engineering" as the best job in the United States in 2006.[10]

History
When the first modern digital computers appeared in the early 1940s,[11] the instructions to make them operate were wired into the machine. Practitioners quickly realized that this design was not flexible and came up with the "stored program architecture" or von Neumann architecture. Thus the first division between "hardware" and "software" began with abstraction being used to deal with the complexity of computing. Programming languages started to appear in the 1950s and this was also another major step in abstraction. Major languages such as Fortran, ALGOL, and COBOL were released in the late 1950s to deal with scientific, algorithmic, and business problems respectively. E.W. Dijkstra wrote his seminal paper, "Go To Statement Considered Harmful",[12] in 1968 and David Parnas introduced the key concept of modularity and information hiding in 1972[13] to help programmers deal with the ever increasing complexity of software systems. A software system for managing the hardware called an operating system was also introduced, most notably by Unix in 1969. In 1967, the Simula language introduced the object-oriented programming paradigm.

Software engineering These advances in software were met with more advances in computer hardware. In the mid 1970s, the microcomputer was introduced, making it economical for hobbyists to obtain a computer and write software for it. This in turn led to the now famous Personal Computer (PC) and Microsoft Windows. The Software Development Life Cycle or SDLC was also starting to appear as a consensus for centralized construction of software in the mid 1980s. The late 1970s and early 1980s saw the introduction of several new Simula-inspired object-oriented programming languages, including Smalltalk, Objective-C, and C++. Open-source software started to appear in the early 90s in the form of Linux and other software introducing the "bazaar" or decentralized style of constructing software.[14] Then the World Wide Web and the popularization of the Internet hit in the mid 90s, changing the engineering of software once again. Distributed systems gained sway as a way to design systems, and the Java programming language was introduced with its own virtual machine as another step in abstraction. Programmers collaborated and wrote the Agile Manifesto, which favored more lightweight processes to create cheaper and more timely software. The current definition of software engineering is still being debated by practitioners today as they struggle to come up with ways to produce software that is "cheaper, better, faster".

337

Profession
Legal requirements for the licensing or certification of professional software engineers vary around the world. In the UK, the British Computer Society licenses software engineers and members of the society can also become Chartered Engineers (CEng), while in some areas of Canada, such as Alberta, Ontario,[15] and Quebec, software engineers can hold the Professional Engineer (P.Eng)designation and/or the Information Systems Professional (I.S.P.) designation; however, there is no legal requirement to have these qualifications. The IEEE Computer Society and the ACM, the two main professional organizations of software engineering, publish guides to the profession of software engineering. The IEEE's Guide to the Software Engineering Body of Knowledge - 2004 Version, or SWEBOK, defines the field and describes the knowledge the IEEE expects a practicing software engineer to have. The IEEE also promulgates a "Software Engineering Code of Ethics".[16]

Employment
In 2004, the U. S. Bureau of Labor Statistics counted 760,840 software engineers holding jobs in the U.S.; in the same time period there were some 1.4 million practitioners employed in the U.S. in all other engineering disciplines combined.[17] Due to its relative newness as a field of study, formal education in software engineering is often taught as part of a computer science curriculum, and as a result most software engineers hold computer science degrees.[18] Most software engineers work as employees or contractors. Software engineers work with businesses, government agencies (civilian or military), and non-profit organizations. Some software engineers work for themselves as freelancers. Some organizations have specialists to perform each of the tasks in the software development process. Other organizations require software engineers to do many or all of them. In large projects, people may specialize in only one role. In small projects, people may fill several or all roles at the same time. Specializations include: in industry (analysts, architects, developers, testers, technical support, managers) and in academia (educators, researchers). There is considerable debate over the future employment prospects for software engineers and other IT professionals. For example, an online futures market called the "ITJOBS Future of IT Jobs in America"[19] attempts to answer whether there will be more IT jobs, including software engineers, in 2012 than there were in 2002.

Software engineering

338

Certification
Professional certification of software engineers is a contentious issue, with some professional organizations supporting it,[20] and others claiming that it is inappropriate given the current level of maturity in the profession.[21] Some see it as a tool to improve professional practice; "The only purpose of licensing software engineers is to protect the public".[22] , however the fact that money changes hands in almost all certification schemes belies this absolute assertion. The ACM had a professional certification program in the early 1980s, which was discontinued due to lack of interest. The ACM examined the possibility of professional certification of software engineers in the late 1990s, but eventually decided that such certification was inappropriate for the professional industrial practice of software engineering.[21] As of 2006, the IEEE had certified over 575 software professionals as a Certified Software Development Professional (CSDP).[20] In 2008 they added an entry-level certification known as the Certified Software Development Associate (CSDA).[23] In the U.K. the British Computer Society has developed a legally recognized professional certification called Chartered IT Professional (CITP), available to fully qualified Members (MBCS). In Canada the Canadian Information Processing Society has developed a legally recognized professional certification called Information Systems Professional (ISP)[24] . In Israel a person with an appropriate engineering degree has the right to be listed in Israel's Registry of Engineers and Architects [25], and the engineering law [26] says that a person calling himself an engineer without the proper license / registration could be sentenced to up to 6 months in jail. The Software Engineering Institute offers certification on specific topic such as Security, Process improvement and Software architecture[27] . Most certification programs in the IT industry are oriented toward specific technologies, and are managed by the vendors of these technologies.[28] These certification programs are tailored to the institutions that would employ people who use these technologies.

Impact of globalization
Many students in the developed world have avoided degrees related to software engineering because of the fear of offshore outsourcing (importing software products or services from other countries) and of being displaced by foreign visa workers.[29] Although statistics do not currently show a threat to software engineering itself; a related career, computer programming does appear to have been affected.[30] [31] Often one is expected to start out as a computer programmer before being promoted to software engineer. Thus, the career path to software engineering may be rough, especially during recessions. Some career counselors suggest a student also focus on "people skills" and business skills rather than purely technical skills because such "soft skills" are allegedly more difficult to offshore.[32] It is the quasi-management aspects of software engineering that appear to be what has kept it from being impacted by globalization.[33]

Education
A knowledge of programming is the main pre-requisite to becoming a software engineer, but it is not sufficient. Most academics agree that Software Engineering is an integral part of Computer Science. Many software engineers have degrees in Computer Science due to the lack of software engineering programs in higher education. However, this has started to change with the introduction of new software engineering degrees, especially in post-graduate education. A standard international curriculum for undergraduate software engineering degrees was defined by the CCSE. Steve McConnell opines that because most universities teach computer science rather than software engineering, there is a shortage of true software engineers.[34] In 2004 the IEEE Computer Society produced the SWEBOK, which has been published as ISO/IEC Technical Report 19759:2004, describing the body of knowledge covered by a

Software engineering software engineer . The European Commission within the Erasmus Mundus Programme offers a European master degree called European Master on Software Engineering for students from Europe and also outside Europe[35] . This is a joint program (double degree) involving four universities in Europe.

339

Sub-disciplines
Software engineering can be divided into ten subdisciplines. They are:[6] Software requirements: The elicitation, analysis, specification, and validation of requirements for software. Software design: The design of software is usually done with Computer-Aided Software Engineering (CASE) tools and use standards for the format, such as the Unified Modeling Language (UML). Software development: The construction of software through the use of programming languages. Software testing Software maintenance: Software systems often have problems and need enhancements for a long time after they are first completed. This subfield deals with those problems. Software configuration management: Since software systems are very complex, their configuration (such as versioning and source control) have to be managed in a standardized and structured method. Software engineering management: The management of software systems borrows heavily from project management, but there are nuances encountered in software not seen in other management disciplines. Software development process: The process of building software is hotly debated among practitioners with the main paradigms being agile or waterfall. Software engineering tools, see Computer Aided Software Engineering Software quality

Related disciplines
Software engineering is related to the disciplines of computer science, management science, and systems engineering.[36] [37]

Computer science
Software engineering is considered an area of computer science by some academics. Many of the foundations of software engineering come from computer science.

Project management
The building of a software system is usually considered a project and the management of it borrows many principles from the field of Project management.

Systems engineering
Systems engineers have been dealing with the complexity of large systems for many decades and their knowledge is applied to many software engineering problems.

See also

Software engineering

340

Software Craftsmanship List of basic software engineering topics List of software engineering conferences List of software engineering publications List of software engineering topics Bachelor of Software Engineering Bachelor of Science in Information Technology

Further reading
Pressman, Roger S (2005). Software Engineering: A Practitioner's Approach (6th ed.). Boston, Mass: McGraw-Hill. ISBN0072853182. Sommerville, Ian (2007) [1982]. Software Engineering [38] (8th ed.). Harlow, England: Pearson Education. ISBN0-321-31379-8. Jalote, Pankaj (2005) [1991]. An Integrated Approach to Software Engineering [39] (3rd ed.). Springer. ISBN0-387-20881-X. Ghezzi, Carlo (2003) [1991]. Fundamentals of Software Engineering (2nd (International) ed.). Pearson Education @ Prentice-Hall.

External links
Computing Curricula 2005: The Overview Report [40] by The Joint Task Force for Computing Curricula ACM/AIS/IEEE-CS Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering [41] by The Joint Task Force on Computing Curricula ACM/IEEE-CS Guidelines for Associate-Degree Transfer Curriculum in Software Engineering [42] by The ACM Two-Year College Education Committee and The Joint Task Force on Software Engineering Association for Computing Machinery IEEE Computer Society Guide to the Software Engineering Body of Knowledge [43] Computer Software Engineers [44] - Definition and statistics from the U.S. Bureau of Labor Statistics A Student's Guide to Software Engineering Projects [45] - a free online guide for students taking SE project courses

References
[1] Peter, Naur; Brian Randell (711 October 1968). "Software engineering: Report of a conference sponsored by the NATO Science Committee" (http:/ / homepages. cs. ncl. ac. uk/ brian. randell/ NATO/ nato1968. PDF) (PDF). Garmisch, Germany: Scientific Affairs Division, NATO. . Retrieved 2008-12-26. [2] Randell, Brian (10 August 2001). "The 1968/69 NATO Software Engineering Reports" (http:/ / homepages. cs. ncl. ac. uk/ brian. randell/ NATO/ NATOReports/ index. html). Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University. . Retrieved 2008-10-11. "The idea for the first NATO Software Engineering Conference, and in particular that of adopting the then practically unknown term "software engineering" as its (deliberately provocative) title, I believe came originally from Professor Fritz Bauer." [3] Hey, Programmers, We Got No Theory! (http:/ / www. drdobbs. com/ open-source/ 224000375) Dr. Dobbs Journal, March 22, 2010 (Retrieved March 26, 2010) [4] Why We Need a Theory for Software Engineering (http:/ / www. drdobbs. com/ architecture-and-design/ 220300840), Ivar Jacobson and Ian Spence, Dr. Dobbs Journal, October 02, 2009 (Retrieved March 26, 2010) [5] McConnell, Steve (January/February 1998). "The Art, Science, and Engineering of Software Development" (http:/ / www. stevemcconnell. com/ ieeesoftware/ bp13. htm). IEEE Software (1). . [6] SWEBOK executive editors, Alain Abran, James W. Moore ; editors, Pierre Bourque, Robert Dupuis. (2004). Pierre Bourque and Robert Dupuis. ed. Guide to the Software Engineering Body of Knowledge - 2004 Version (http:/ / www. swebok. org). IEEE Computer Society. pp.11. ISBN0-7695-2330-7. . [7] The end of software engineering and the start of economic-cooperative gaming (http:/ / alistair. cockburn. us/ The+ end+ of+ software+ engineering+ and+ the+ start+ of+ economic-cooperative+ gaming)

Software engineering
[8] 35 years on: to what extent has software engineering design achieved its goals? (http:/ / cat. inist. fr/ ?aModele=afficheN& cpsidt=15417224) [9] http:/ / salary. com/ [10] Kalwarski, Tara; Daphne Mosher, Janet Paskin and Donna Rosato (2006). "Best Jobs in America" (http:/ / money. cnn. com/ magazines/ moneymag/ bestjobs/ 2006/ ). MONEY Magazine. CNN. . Retrieved 2006-04-20. [11] Leondes (2002). intelligent systems: technology and applications. CRC Press. ISBN9780849311215. [12] Dijkstra, E. W. (March 1968). "Go To Statement Considered Harmful" (http:/ / www. cs. utexas. edu/ users/ EWD/ ewd02xx/ EWD215. PDF). Communications of the ACM 11 (3): 147148. doi:10.1145/362929.362947. . Retrieved 2009-08-10. [13] Parnas, David (December 1972). "On the Criteria To Be Used in Decomposing Systems into Modules" (http:/ / www. acm. org/ classics/ may96/ ). Communications of the ACM 15 (12): 10531058. doi:10.1145/361598.361623. . Retrieved 2008-12-26. [14] Raymond, Eric S. The Cathedral and the Bazaar. ed 3.0. 2000. [15] Williams, N.S.W. (1921 February 2001). "Professional Engineers Ontario's approach to licensing software engineering practitioners". Software Engineering Education and Training, 2001 Proceedings. 14th Conference on. Charlotte, NC: IEEE. pp.7778. [16] Software Engineering Code of Ethics (http:/ / www. computer. org/ portal/ cms_docs_computer/ computer/ content/ code-of-ethics. pdf) [17] Bureau of Labor Statistics, U.S. Department of Labor, USDL 05-2145: Occupational Employment and Wages, November 2004 (ftp:/ / ftp. bls. gov/ pub/ news. release/ ocwage. txt), Table 1. [18] "Software Engineering" (http:/ / computingcareers. acm. org/ ?page_id=12). . Retrieved 2008-02-01. [19] Future of IT Jobs in America (http:/ / www. ideosphere. com/ fx-bin/ Claim?claim=ITJOBS) [20] IEEE Computer Society. "2006 IEEE computer society report to the IFIP General Assembly" (http:/ / www. ifip. org/ minutes/ GA2006/ Tab18b-US-IEEE. pdf) (PDF). . Retrieved 2007-04-10. [21] ACM (July 17, 2000). "A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession" (http:/ / www. cs. wm. edu/ ~coppit/ csci690-spring2004/ papers/ selep_main. pdf). Association for Computing Machinery (ACM). . Retrieved 2009-03-03. "At its meeting in May 2000, the Council further concluded that the framework of a licensed professional engineer, originally developed for civil engineers, does not match the professional industrial practice of software engineering. Such licensing practices would give false assurances of competence even if the body of knowledge were mature; and would preclude many of the most qualified software engineers from becoming licensed." [22] Kruchten, Philippe, "Licensing Software Engineers?", IEEE SOFTWARE nov/dec 2008 (http:/ / www. computer. org/ portal/ cms_docs_software/ software/ homepage/ 2008/ s6car. pdf) [23] IEEE. "CSDA" (http:/ / www. computer. org/ portal/ web/ certification/ csda). . Retrieved 2010-04-20. [24] Canadian Information Processing Society. "I.S.P. Designation" (http:/ / www. cips. ca/ standards/ isp). . Retrieved 2007-03-15. [25] http:/ / www. tamas. gov. il/ NR/ exeres/ DACD5881-70D5-463A-BDF2-AA363197FB2F. htm [26] http:/ / www. moit. gov. il/ NR/ exeres/ AACCF3CC-C47C-4D2F-BF49-FDB4185C6E55. htm [27] SEI certification page (http:/ / www. sei. cmu. edu/ certification/ ) [28] Wyrostek, Warren (March 14, 2008). "The Top 10 Problems with IT Certification in 2008" (http:/ / www. informit. com/ articles/ article. aspx?p=1180991). InformIT. . Retrieved 2009-03-03. [29] As outsourcing gathers steam, computer science interest wanes (http:/ / www. computerworld. com/ printthis/ 2006/ 0,4814,111202,00. html) [30] Computer Programmers (http:/ / www. bls. gov/ oco/ ocos110. htm#outlook) [31] Software developer growth slows in North America | InfoWorld | News | 2007-03-13 | By Robert Mullins, IDG News Service (http:/ / www. infoworld. com/ article/ 07/ 03/ 13/ HNslowsoftdev_1. html) [32] Hot Skills, Cold Skills (http:/ / www. computerworld. com/ action/ article. do?command=viewArticleTOC& specialReportId=9000100& articleId=112360) [33] Dual Roles: The Changing Face of IT (http:/ / itmanagement. earthweb. com/ career/ article. php/ 3523066) [34] McConnell, Steve (July 10, 2003. Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers. ISBN 978-0321193674. [35] http:/ / ec. europa. eu/ education/ programmes/ mundus/ index_en. html [36] Ian Sommerville (2004). Software Engineering. 7th edition. Chapter 1 (http:/ / www. cs. st-andrews. ac. uk/ ~ifs/ Books/ SE7/ Presentations/ PDF/ ch1. pdf). Bezien 20 Okt 2008. [37] Table 2 in Chapter 1, "Guide to the Software Engineering Body of Knowledge" (http:/ / www. swebok. org/ swebokcontents-ch1. html#ch1). February 6, 2004. . Retrieved 2008-02-21. [38] http:/ / www. pearsoned. co. uk/ HigherEducation/ Booksby/ Sommerville/ [39] http:/ / www. springer. com/ east/ home?SGWisbn=5-102-22-52090005-0& changeHeader=true [40] http:/ / www. acm. org/ education/ education/ curric_vols/ CC2005-March06Final. pdf [41] http:/ / sites. computer. org/ ccse/ [42] http:/ / www. acmtyc. org/ WebReports/ SEreport/ [43] http:/ / www. swebok. org [44] http:/ / www. bls. gov/ oco/ ocos267. htm [45] http:/ / StudentProjectGuide. info

341

Construction

342

Construction
In the fields of architecture and civil engineering, construction is a process that consists of the building or assembling of infrastructure. Far from being a single activity, large scale construction is a feat of multitasking. Normally the job is managed by the project manager and supervised by the construction manager, design engineer, construction engineer or project architect. For the successful execution of a project, effective planning is essential. Those involved with the design and execution of the infrastructure in question must consider the environmental impact of the job, the successful scheduling, budgeting, site safety, availability of materials, logistics, inconvenience to the public caused by construction delays, preparing tender documents, etc.

Types of construction projects

In general, there are three types of construction: 1. Building construction 2. Heavy/civil construction 3. Industrial construction Each type of construction project requires a unique team to plan, design, construct, and maintain the project.

Building construction

In large construction projects such as skyscrapers, cranes are essential.

Building construction for several apartment blocks. The blue material is insulation cladding, which will be covered later.

A large unfinished building Building construction is the process of adding structure to real property. The vast majority of building construction projects are small renovations, such as addition of a room, or renovation of a bathroom. Often, the owner of the property acts as laborer, paymaster, and design team for the entire project. However, all building construction projects include some elements in common - design, financial, and legal considerations. Many projects of varying sizes reach undesirable end results, such as structural collapse, cost overruns, and/or litigation reason, those with experience in the field make detailed plans and maintain careful oversight during the project to ensure a positive

Construction outcome. Building construction is procured privately or publicly utilizing various delivery methodologies, including hard bid, negotiated price, traditional, management contracting, construction management-at-risk, design & build and design-build bridging. Trump International Hotel and Tower (Chicago)

343

May 23, 2006

September 14, 2007 (3 months before completion) Residential construction practices, technologies, and resources must conform to local building authority regulations and codes of practice. Materials readily available in the area generally dictate the construction materials used (e.g. brick versus stone, versus timber). Cost of construction on a per square metre (or per square foot) basis for houses can vary dramatically based on site conditions, local regulations, economies of scale (custom designed homes are always more expensive to build) and the availability of skilled tradespeople. As residential (as well as all other types of construction) can generate a lot of waste, careful planning again is needed here. The most popular method of residential construction in the United States is wood framed construction. As efficiency codes have come into effect in recent years, new construction technologies and methods have emerged. University Construction Management departments are on the cutting edge of the newest methods of construction intended to improve efficiency, performance and reduce construction waste.

Construction of the Havelock City Project in Sri Lanka.

Construction Construction of Phase-1 of the Havelock City Project in Sri Lanka.

344

Industrial construction
Industrial construction, though a relatively small part of the entire construction industry, is a very important component. Owners of these projects are usually large, for-profit, industrial corporations. These corporations can be found in such industries as medicine, petroleum, chemical, power generation, manufacturing, etc. Processes in these industries require highly specialized expertise in planning, design, and construction. As in building and heavy/highway construction, this type of construction requires a team of individuals to ensure a successful project.

Construction processes
Design team
In the modern industrialized world, construction usually involves the translation of paper or computer based designs into reality. A formal design team may be assembled to plan the physical proceedings, and to integrate those proceedings with the other parts. The design usually consists of drawings and specifications, usually prepared by a design team including the client architects, interior designers, surveyors, civil engineers, cost engineers (or quantity surveyors), mechanical engineers, electrical engineers, structural engineers, and fire protection engineers. The design team is most commonly employed by (i.e. in Shasta Dam under construction contract with) the property owner. Under this system, once the design is completed by the design team, a number of construction companies or construction management companies may then be asked to make a bid for the work, either based directly on the design, or on the basis of drawings and a bill of quantities provided by a quantity surveyor. Following evaluation of bids, the owner will typically award a contract to the lowest responsible bidder. The modern trend in design is toward integration of previously separated specialties, especially among large firms. In the past, architects, interior designers, engineers, developers, construction managers, and general contractors were more likely to be entirely separate companies, even in the larger firms. Presently, a firm that is nominally an "architecture" or "construction management" firm may have experts from all related fields as employees, or to have an associated company that provides each necessary skill. Thus, each such firm may offer itself as "one-stop shopping" for a construction project, from beginning to Apartment is under counstruction in Daegu, South Korea. end. This is designated as a "design Build" contract where the contractor is given a performance specification, and must undertake the project from design to construction, while adhering to the performance specifications.

Construction

345 Several project structures can assist the owner in this integration, including design-build, partnering, and construction management. In general, each of these project structures allows the owner to integrate the services of architects, interior designers, engineers, and constructors throughout design and construction. In response, many companies are growing beyond traditional offerings of design or construction services alone, and are placing more emphasis on establishing relationships with other necessary participants through the design-build process.

The increasing complexity of construction projects creates the need for design professionals trained in all phases of the project's life-cycle and develop an appreciation of the building as an advanced technological system requiring close integration of many sub-systems and their individual components, including sustainability. Building engineering is an emerging discipline that attempts to meet this new challenge.

Construction of a pre-fabricated house

Financial advisors
Many construction projects suffer from preventable financial problems. Underbids ask for too little money to complete the project. Cash flow problems exist when the present amount of funding cannot cover the current costs for labour and materials, and because they are a matter of having sufficient funds at a specific time, can arise even when the overall total is enough. Fraud is a problem in many fields, but is notoriously prevalent in the construction field. Financial planning for the project is intended to ensure that a solid plan, with adequate safeguards and contingency plans, is in place before the project is started, and is required to ensure that the plan is properly executed over the life of the project. Mortgage bankers, accountants, and cost engineers are likely participants in creating an overall plan for the financial management of the building construction project. The presence of the mortgage banker is highly likely even in relatively small projects, since the owner's equity in the property is the most obvious source of funding for a building project. Accountants act to study the expected monetary flow over the life of the project, and to monitor the payouts throughout the process. Cost engineers apply expertise to relate the work and materials involved to a proper valuation. Cost overruns with government projects have occurred when the contractor was able to identify change orders or changes in the project resulting in large increases in cost, which are not subject to competition by other firm as they have already been eliminated from consideration after the initial bid.[1] Large projects can involve highly complex financial plans. As portions of a project are completed, they may be sold, supplanting one lender or owner for another, while the logistical requirements of having the right trades and materials available for each stage of the building construction project carries forward. In many English-speaking countries, but not the United States, projects typically use quantity surveyors.

Legal considerations
A construction project must fit into the legal framework governing the property. These include governmental regulations on the use of property, and obligations that are created in the process of construction. The project must adhere to zoning and building code requirements. Constructing a project that fails to adhere to codes will not benefit the owner. Some legal requirements come from malum in se considerations, or the desire to prevent things that are indisputably bad - bridge collapses or explosions. Other legal requirements come from malum prohibitum considerations, or things that are a matter of custom or expectation, such as isolating businesses to a business district and residences to a residential district. An attorney may seek changes or exemptions in the law governing the land where the building will be built, either by arguing that a rule is inapplicable (the bridge design won't collapse), or that the custom is no longer needed (acceptance of live-work spaces has grown in the

Construction community). A construction project is a complex net of contracts and other legal obligations, each of which must be carefully considered. A contract is the exchange of a set of obligations between two or more parties, but it is not so simple a matter as trying to get the other side to agree to as much as possible in exchange for as little as possible. The time element in construction means that a delay costs money, and in cases of bottlenecks, the delay can be extremely expensive. Thus, the contracts must be designed to ensure that each side is capable of performing the obligations set out. Contracts that set out clear expectations and clear paths to accomplishing those expectations are far more likely to result in the project flowing smoothly, whereas poorly drafted contracts lead to confusion and collapse. Legal advisors in the beginning of a construction project seek to identify ambiguities and other potential sources of trouble in the contract structure, and to present options for preventing problems. Throughout the process of the project, they work to avoid and resolve conflicts that arise. In each case, the lawyer facilitates an exchange of obligations that matches the reality of the project.

346

Interaction of expertise
Design, finance, and legal aspects overlap and interrelate. The design must be not only structurally sound and appropriate for the use and location, but must also be financially possible to build, and legal to use. The financial structure must accommodate the need for building the design provided, and must pay amounts that are legally owed. The legal structure must integrate the design into the surrounding legal framework, and enforces the financial consequences of the construction process.

Procurement
Procurement describes the merging of activities undertaken by the client to obtain a building. There are many different methods of construction procurement; however the three most common types of procurement are: 1. Traditional (Design-bid-build) 2. Design and Build 3. Management Contracting There is also a growing number of new forms of procurement that involve relationship contracting where the emphasis is on a co-operative relationship between the principal and contractor and other stakeholders within a construction project. New forms include partnering such as Public-Private Partnering (PPPs) aka Private Finance Initiatives (PFIs) and alliances such as "pure" or "project" alliances and "impure" or "strategic" alliances. The focus on co-operation is to ameliorate the many problems that arise from the often highly competitive and adversarial practices within the construction industry. Traditional This is the most common method of construction procurement and is well established and recognized. In this arrangement, the architect or engineer acts as the project coordinator. His or her role is to design the works, prepare the specifications and produce construction drawings, administer the contract, tender the works, and manage the works from inception to completion. There are direct contractual links between the architect's client and the main contractor. Any subcontractor will have a direct contractual relationship with the main contractor.

Construction Design and build This approach has become more common in recent years and includes an entire completed package, including fixtures, fittings and equipment where necessary, to produce a completed fully functional building. In some cases, the Design and Build (D & B) package can also include finding the site, arranging funding and applying for all necessary statutory consents. The owner produces a list of requirements for a project, giving an overall view of the project's goals. Several D&B contractors present different ideas about how to accomplish these goals. The owner selects the ideas he likes best and hires the appropriate contractor. Often, it is not just one contractor, but a consortium of several contractors working together. Once a contractor (or a consortium/consortia) has been hired, they begin building the first phase of the project. As they build phase 1, they design phase 2. This is in contrast to a design-bid-build contract, where the project is completely designed by the owner, then bid on, then completed. Kent Hansen, director of engineering for the National Asphalt Pavement Association (NAPA), pointed out that state departments of transportation (DOTs) usually use design build contracts as a way of getting projects done when states don't have the resources. In DOTs, design build contracts are usually used for very large projects.[2] Management procurement systems In this arrangement the client plays an active role in the procurement system by entering into separate contracts with the designer (architect or engineer), the construction manager, and individual trade contractors. The client takes on the contractual role, while the construction or project manager provides the active role of managing the separate trade contracts, and ensuring that they all work smoothly and effectively together. Management procurement systems are often used to speed up the procurement processes, allow the client greater flexibility in design variation throughout the contract, the ability to appoint individual work contractors, separate contractual responsibility on each individual throughout the contract, and to provide greater client control.

347

Authority having jurisdiction

In construction, the authority having jurisdiction (AHJ) is the governmental agency or sub-agency which regulates the construction process. In most cases, this is the municipality in which the building is located. However, construction performed for supra-municipal authorities are usually regulated directly by the owning authority, which becomes the AHJ. During the planning of a building, the zoning and planning boards of the AHJ will review the overall compliance of the proposed building with the municipal General Plan and zoning regulations. Once the proposed building has been approved, detailed civil, architectural, and structural plans must be submitted to the municipal building department (and sometimes the public works department) to determine compliance with the building code and sometimes for fit with existing infrastructure. Often, the municipal fire department will review the plans for compliance with fire-safety ordinances and regulations.

Construction

348 Before the foundation can be dug, contractors are typically required to notify utility companies, either directly or through a company such as Dig Safe to ensure that underground utility lines can be marked. This lessens the likelihood of damage to the existing electrical, water, sewage, phone, and cable facilities, which could cause outages and potentially hazardous situations. During the construction of a building, the municipal building inspector inspects the building periodically to ensure that the construction adheres to the approved plans and the local building code. Once construction is complete and a final inspection has been passed, an occupancy permit may be issued.

Construction on a building in Kansas City

An operating building must remain in compliance with the fire code. The fire code is enforced by the local fire department. Changes made to a building that affect safety, including its use, expansion, structural integrity, and fire protection items, usually require approval of the AHJ for review concerning the building code. For the UK rules, see Planning permission.

Construction careers
There are many routes to the different careers within the construction industry which vary by country. However, there are three main tiers of careers based on educational background which are common internationally: Unskilled and Semi-Skilled - General site labour with little or no construction qualifications. Skilled - On-site managers whom possess extensive knowledge and experience in their craft or profession. Technical and Management - Personnel with the greatest educational qualifications, usually graduate degrees, trained to design, manage and instruct the construction process. Skilled occupations in the UK require Further Education qualifications, often in vocational subject areas. These qualifications are either obtained directly after the completion of compulsory education or through "on the job" apprenticeship training. In the UK, 8500 construction-related apprenticeships were commenced in 2007.[3]

Ironworkers erecting the steel frame of a new building, at the Massachusetts General Hospital, USA

Technical and specialised occupations require more training as a greater technical knowledge is required. These professions also hold more legal responsibility. A short list of the main careers with an outline of the educational requirements are given below:[4] Architect - Typically holds at least a 4-year degree in architecture. To use the title "architect" the individual must hold chartered status with the Royal Institute of British Architects and be on the Architects Registration Board. Civil Engineer - Typically holds a degree in a related subject. The Chartered Engineer qualification is controlled by the Institution of Civil Engineers. A new university graduate must hold a masters degree to become chartered, persons with bachelors degrees may become an Incorporated Engineer. Building Services Engineer - Often referred to as an "M&E Engineer" typically holds a degree in mechanical or electrical engineering. Chartered Engineer status is governed by the Chartered Institution of Building Services

Construction Engineers. Project Manager - Typically holds a 2-year or greater higher education qualification, but are often also qualified in another field such as quantity surveying or civil engineering. Quantity Surveyor - Typically holds a masters degree in quantity surveying. Chartered status is gained from the Royal Institute of Chartered Surveyors. Structural Engineer - Typically holds a bachelors or masters degree in structural engineering, new university graduates must hold a masters degree to gain chartered status from the Institution of Structural Engineers.

349

History
The first buildings were huts and shelters, constructed by hand or with simple tools. As cities grew during the bronze age, a class of professional craftsmen like bricklayers and carpenters appeared. Occasionally, slaves were used for construction work. In the middle ages, these were organized into guilds. In the 19th century, steam-powered machinery appeared, and later diesel- and electric powered vehicles such as cranes, excavators and bulldozers.

See also
Architecture Building code Building officials Construction and demolition waste (C&D waste) Construction worker Civil engineering Construction engineering Deconstruction (building) International Building Code List of construction topics List of construction trades Project management

External links
/ Construction [5] at the Open Directory Project

References
[1] School districts increasingly seek alternate financing : North County Times - Californian (http:/ / www. nctimes. com/ articles/ 2007/ 05/ 27/ news/ top_stories/ 22_07_545_26_07. txt) [2] Cronin, Jeff (2005). "S. Carolina Court to Decide Legality of Design-Build Bids" (http:/ / www. cegltd. com/ story. asp?story=5592). Construction Equipment Guide. . Retrieved 2008-01-04. [3] http:/ / www. cskills. org/ workinconstr/ routesintoconstruction/ apprenticeships/ index. aspx [4] http:/ / careersadvice. direct. gov. uk/ helpwithyourcareer/ jobprofiles/ category11/ [5] http:/ / www. dmoz. org/ Business/ Construction_and_maintenance

Engineering

350

Engineering
Engineering is the discipline, art and profession of acquiring and applying technical, scientific, and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or invention. The American Engineers' Council for Professional Development (ECPD, the predecessor of ABET[1] ) has defined engineering as follows: [T]he creative application of scientific principles to design or develop The Watt steam engine, a major driver in the industrial revolution, underscores the structures, machines, importance of engineering in modern history. This model is on display at the main building of the ETSIIM in Madrid, Spain apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.[2] [3] [4] One who practices engineering is called an engineer, and those licensed to do so may have more formal designations such as Professional Engineer, Chartered Engineer, Incorporated Engineer, or European Engineer. The broad discipline of engineering encompasses a range of more specialized subdisciplines, each with a more specific emphasis on certain fields of application and particular areas of technology.

Engineering

351

History
The concept of engineering has existed since ancient times as humans devised fundamental inventions such as the pulley, lever, and wheel. Each of these inventions is consistent with the modern definition of engineering, exploiting basic mechanical principles to develop useful tools and objects. The term engineering itself has a much more recent etymology, deriving from the word engineer, which itself dates back to 1325, when an engineer (literally, one who operates an engine) originally referred to a constructor of military engines.[5] In this context, now obsolete, an engine referred to a military machine, i.e., a mechanical contraption used in war (for example, a catapult). The word engine itself is of even older origin, ultimately deriving from the Latin ingenium (c. 1250), meaning innate quality, especially mental power, hence a clever invention.[6] Later, as the design of civilian structures such as bridges and buildings matured as a technical discipline, the term civil engineering[4] entered the lexicon as a way to distinguish between those specializing in the construction of such non-military projects Offshore wind turbines represent a modern multi and those involved in the older discipline of military engineering disciplinary engineering problem. (the original meaning of the word engineering, now largely obsolete, with notable exceptions that have survived to the present day such as military engineering corps, e.g., the U.S. Army Corps of Engineers.

Ancient era
The Pharos of Alexandria, the pyramids in Egypt, the Hanging Gardens of Babylon, the Acropolis and the Parthenon in Greece, the Roman aqueducts, Via Appia and the Colosseum, Teotihuacn and the cities and pyramids of the Mayan, Inca and Aztec Empires, the Great Wall of China, among many others, stand as a testament to the ingenuity and skill of the ancient civil and military engineers. The earliest civil engineer known by name is Imhotep.[4] As one of the officials of the Pharaoh, Djosr, he probably designed and supervised the construction of the Pyramid of Djoser (the Step Pyramid) at Saqqara in Egypt around 2630-2611 BC.[7] He may also have been responsible for the first known use of columns in architecture. Ancient Greece developed machines in both the civilian and military domains. The Antikythera mechanism, the first known mechanical computer)[8] [9] and the mechanical inventions of Archimedes are examples of early mechanical engineering. Some of Archimedes' inventions as well as the Antikythera mechanism required sophisticated knowledge of differential gearing or epicyclic gearing, two key principles in machine theory that helped design the gear trains of the Industrial revolution, and are still widely used today in diverse fields such as robotics and automotive engineering.[10] Chinese, Greek and Roman armies employed complex military machines and inventions such as artillery which was developed by the Greeks around the 4th century B.C.,[11] the trireme, the ballista and the catapult. In the Middle Ages, the Trebuchet was developed.

Engineering

352

Renaissance era
The first electrical engineer is considered to be William Gilbert, with his 1600 publication of De Magnete, who was the originator of the term "electricity".[12] The first steam engine was built in 1698 by mechanical engineer Thomas Savery.[13] The development of this device gave rise to the industrial revolution in the coming decades, allowing for the beginnings of mass production. With the rise of engineering as a profession in the eighteenth century, the term became more narrowly applied to fields in which mathematics and science were applied to these ends. Similarly, in addition to military and civil engineering the fields then known as the mechanic arts became incorporated into engineering.

Modern era
Electrical engineering can trace its origins in the experiments of Alessandro Volta in the 1800s, the experiments of Michael Faraday, Georg Ohm and others and the invention of the electric motor in 1872. The work of James Maxwell and Heinrich Hertz in the late 19th century gave rise to the field of Electronics. The later inventions of the vacuum tube and the transistor further accelerated the development of electronics to such an extent that electrical and electronics engineers currently outnumber their colleagues of any other Engineering specialty.[4] The inventions of Thomas Savery and the Scottish engineer James Watt gave rise to modern Mechanical Engineering. The development of specialized machines and their maintenance tools during the industrial revolution led to the rapid growth of Mechanical Engineering both in its birthplace Britain and abroad.[4] Chemical Engineering, like its counterpart Mechanical Engineering, developed in the nineteenth century during the Industrial Revolution.[4] Industrial scale manufacturing demanded new materials and new processes and by 1880 the need for large scale production of chemicals was such that a new industry was created, dedicated to the development and large scale manufacturing of chemicals in new industrial plants.[4] The role of the chemical engineer was the design of these chemical plants and processes.[4] Aeronautical Engineering deals with aircraft design while Aerospace Engineering is a more modern term that expands the reach envelope of the discipline by including spacecraft design.[14] Its origins can be traced back to the aviation pioneers around the turn of the century from the 19th century to the 20th although the work of Sir George Cayley has recently been dated as being from the last decade of the 18th century. Early knowledge of aeronautical engineering was largely empirical with some concepts and skills imported from other branches of engineering.[15] Only a decade after the successful flights by the Wright brothers, the 1920s saw extensive development of aeronautical engineering through development of World War I military aircraft. Meanwhile, research to provide fundamental background science continued by combining theoretical physics with experiments. The first PhD in engineering (technically, applied science and engineering) awarded in the United States went to Willard Gibbs at Yale University in 1863; it was also the second PhD awarded in science in the U.S.[16] In 1990, with the rise of computer technology, the first search engine was built by computer engineer Alan Emtage.

Main branches of engineering

Engineering, much like other science, is a broad discipline which is often broken down into several sub-disciplines. These disciplines concern themselves with differing areas of engineering work. Although initially an engineer will be trained in a specific discipline, throughout an engineer's career the engineer may become multi-disciplined, having worked in several of the outlined areas. Historically the main Branches of Engineering are categorized as follows:[14] [17] Chemical engineering - The exploitation of chemical principles in order to carry out large scale chemical process, as well as designing new specialty materials and fuels.

Engineering Civil engineering - The design and construction of public and private works, such as infrastructure (roads, railways, water supply and treatment etc.), bridges and buildings. Electrical engineering - a very broad area that may encompass the design and study of various electrical & electronic systems, such as electrical circuits, generators, motors, electromagnetic/electromechanical devices, electronic devices, electronic circuits, optical fibers, optoelectronic devices, computer systems, telecommunications. Mechanical engineering - The design of physical or mechanical systems, such as engines, powertrains, kinematic chains, vacuum technology, and vibration isolation equipment. With the rapid advancement of technology many new fields are gaining prominence and new branches are developing such as materials engineering, computer engineering, software engineering, mechatronics, robotics, nanotechnology, agricultural engineering, tribology, molecular engineering, etc. These new specialties sometimes combine with the traditional fields and form new branches such as mechanical engineering and mechatronics and electrical and computer engineering. A new or emerging area of application will commonly be defined temporarily as a permutation or subset of existing disciplines; there is often gray area as to when a given sub-field becomes large and/or prominent enough to warrant classification as a new "branch." One key indicator of such emergence is when major universities start establishing departments and programs in the new field. For each of these fields there exists considerable overlap, especially in the areas of the application of sciences to their disciplines such as physics, chemistry and mathematics.

353

Methodology
Engineers apply the sciences of physics and mathematics to find suitable solutions to problems or to make improvements to the status quo. More than ever, engineers are now required to have knowledge of relevant sciences for their design projects, as a result, they keep on learning new material throughout their career. If multiple options exist, engineers weigh different design choices on their merits and choose the solution that best matches the requirements. The crucial and unique task of the engineer is to identify, understand, and interpret the constraints on a design in order to produce a successful result. It is usually not enough to build a technically successful product; it must also meet further requirements. Constraints may include available resources, physical, imaginative or technical limitations, flexibility for future modifications and additions, and other factors, such as requirements for cost, safety, marketability, productibility, and serviceability. By understanding the constraints, engineers derive specifications for the limits within which a viable object or system may be produced and operated.

Design of a turbine requires collaboration of engineers from many fields

Engineering

354

Problem solving
Engineers use their knowledge of science, mathematics, and appropriate experience to find suitable solutions to a problem. Engineering is considered a branch of applied mathematics and science. Creating an appropriate mathematical model of a problem allows them to analyze it (sometimes definitively), and to test potential solutions. Usually multiple reasonable solutions exist, so engineers must evaluate the different design choices on their merits and choose the solution that best meets their requirements. Genrich Altshuller, after gathering statistics on a large number of patents, suggested that compromises are at the heart of "low-level" engineering designs, while at a higher level the best design is one which eliminates the core contradiction causing the problem. Engineers typically attempt to predict how well their designs will perform to their specifications prior to full-scale production. They use, among other things: prototypes, scale models, simulations, destructive tests, nondestructive tests, and stress tests. Testing ensures that products will perform as expected. Engineers as professionals take seriously their responsibility to produce designs that will perform as expected and will not cause unintended harm to the public at large. Engineers typically include a factor of safety in their designs to reduce the risk of unexpected failure. However, the greater the safety factor, the less efficient the design may be. The study of failed products is known as forensic engineering, and can help the product designer in evaluating his or her design in the light of real conditions. The discipline is of greatest value after disasters, such as bridge collapses, when careful analysis is needed to establish the cause or causes of the failure.

Computer use
As with all modern scientific and technological endeavors, computers and software play an increasingly important role. As well as the typical business application software there are a number of computer aided applications (Computer-aided technologies) specifically for engineering. Computers can be used to generate models of fundamental physical processes, which can be solved using numerical methods. One of the most widely used tools in the profession is computer-aided design (CAD) software which enables engineers to create 3D models, 2D drawings, and schematics of their designs. CAD together with Digital mockup (DMU) A computer simulation of high velocity air flow around the and CAE software such as finite element method analysis or Space Shuttle during re-entry. analytic element method allows engineers to create models of designs that can be analyzed without having to make expensive and time-consuming physical prototypes. These allow products and components to be checked for flaws; assess fit and assembly; study ergonomics; and to analyze static and dynamic characteristics of systems such as stresses, temperatures, electromagnetic emissions, electrical currents and voltages, digital logic levels, fluid flows, and kinematics. Access and distribution of all this information is generally organized with the use of Product Data Management software.[18] There are also many tools to support specific engineering tasks such as Computer-aided manufacture (CAM) software to generate CNC machining instructions; Manufacturing Process Management software for production engineering; EDA for printed circuit board (PCB) and circuit schematics for electronic engineers; MRO applications for maintenance management; and AEC software for civil engineering. In recent years the use of computer software to aid the development of goods has collectively come to be known as Product Lifecycle Management (PLM).[19]

Engineering

355

Social context
Engineering is a subject that ranges from large collaborations to small individual projects. Almost all engineering projects are beholden to some sort of financing agency: a company, a set of investors, or a government. The few types of engineering that are minimally constrained by such issues are pro bono engineering and open design engineering. By its very nature engineering is bound up with society and human behavior. Every product or construction used by modern society will have been influenced by engineering design. Engineering design is a very powerful tool to make changes to environment, society and economies, and its application brings with it a great responsibility. Many engineering societies have established codes of practice and codes of ethics to guide members and inform the public at large. Engineering projects can be subject to controversy. Examples from different engineering disciplines include the development of nuclear weapons, the Three Gorges Dam, the design and use of Sport utility vehicles and the extraction of oil. In response, some western engineering companies have enacted serious corporate and social responsibility policies. Engineering is a key driver of human development.[20] Sub-Saharan Africa in particular has a very small engineering capacity which results in many African nations being unable to develop crucial infrastructure without outside aid. The attainment of many of the Millennium Development Goals requires the achievement of sufficient engineering capacity to develop infrastructure and sustainable technological development.[21] All overseas development and relief NGOs make considerable use of engineers to apply solutions in disaster and development scenarios. A number of charitable organizations aim to use engineering directly for the good of mankind: Engineers Without Borders Engineers Against Poverty Registered Engineers for Disaster Relief Engineers for a Sustainable World

Cultural presence
Engineering is a well respected profession. For example, in Canada it ranks as one of the public's most trusted professions.[22] In India, engineering is one of the most sought after undergraduate courses, inviting thousands of applicants to try their luck in highly competitive entrance examinations. Sometimes engineering has been seen as a somewhat dry, uninteresting field in popular culture, and has also been thought to be the domain of nerds. For example, the cartoon character Dilbert is an engineer. One difficulty in increasing public awareness of the profession is that average people, in the typical run of ordinary life, do not ever have any personal dealings with engineers, even though they benefit from their work every day. By contrast, it is common to visit a doctor at least once a year, the chartered accountant at tax time, and, occasionally, even a lawyer. This has not always been so most British school children in the 1950s were brought up with stirring tales of 'the Victorian Engineers', chief amongst whom were the Brunels, the Stephensons, Telford and their contemporaries. In science fiction engineers are often portrayed as highly knowledgeable and respectable individuals who understand the overwhelming future technologies often portrayed in the genre. The Star Trek characters Montgomery Scott, Geordi La Forge, Miles O'Brien, B'Elanna Torres, and Charles Tucker III are famous examples. Occasionally, engineers may be recognized by the "Iron Ring"--a stainless steel or iron ring worn on the little finger of the dominant hand. This tradition began in 1925 in Canada for the Ritual of the Calling of an Engineer as a symbol of pride and obligation for the engineering profession. Some years later in 1972 this practice was adopted by

Engineering several colleges in the United States. Members of the US Order of the Engineer accept this ring as a pledge to uphold the proud history of engineering. A Professional Engineer's name may be followed by the post-nominal letters PE or P.Eng in North America. In much of Europe a professional engineer is denoted by the letters IR, while in the UK and much of the Commonwealth the term Chartered Engineer applies and is denoted by the letters CEng.

356

Licensing and certification

In most Western countries, certain engineering tasks, such as the design of bridges, electric power plants, and chemical plants, must be approved by a licensed Professional Engineer, a Chartered Engineer, or an Incorporated Engineer. Engineering licensure in the United States remains largely optional for the vast majority of practicing engineers not directly working on projects deemed to implicate "public health and safety" (this typically covers civil engineers and government contractors). This is known as the "industry exemption." And even for such public-safety projects, it is often sufficient for only the supervising engineer to have a license.[23] Consequently, a relatively small minority of engineers in the United States are actually licensed; this is of growing concern to some engineering organizations who believe licensure is important for maintaining the status of engineering as an elite and learned profession like medicine and law. However, becoming a "Registered Professional Engineer" or "P.E." is still often pursued as a professional credential for prestige, even when not actually required for particular employment. Licensure in most states is generally attainable through combination of education, pre-examination (Fundamentals of Engineering exam), examination (Professional Engineering Exam)[24] , and engineering experience (typically in the area of 5+ years). In the United States, each state tests and licenses Professional Engineers. Currently most states do not license by specific engineering discipline, but rather provide generalized licensure, and trust engineers to use professional judgment regarding their individual competencies; this is the favored approach of the professional societies. Despite this, however, at least one of the examinations required by most states is actually focused on a particular discipline; candidates for licensure typically choose the category of examination which comes closest to their respective expertise. In much of Europe and the Commonwealth professional accreditation is provided by Engineering Institutions, such as the Institution of Civil Engineers from the UK. The engineering institutions of the UK are some of the oldest in the world, and provide accreditation to many engineers around the world. In the UK, the term "engineer" can be applied to non-degree vocations such as technologists, technicians, draftsmen, machinists, mechanics, plumbers, electricians, repair people, and semi-skilled occupations. In the US, the term practical engineer sometimes applies to technicians where specific experience and training are valued for detailed applications. It is generally a requirement in the United States to have at least a Bachelor of Science degree in an engineering discipline or related applied science to be considered an engineer and practice as such. In Canada the profession in each province is governed by its own engineering association. For instance, in the Province of British Columbia an engineering graduate with 4 or more years of post graduate experience in an engineering-related field, and passing exams in ethics and law will need to be registered by the Association for Professional Engineers and Geoscientists (APEGBC) [25] in order to become a Professional Engineer and be granted the professional designation of P.Eng. In Canada it is illegal to practice engineering or use the title "Engineer" without a Professional engineer license. The federal US government, however, supervises aviation through the Federal Aviation Regulations administrated by the Dept. of Transportation, Federal Aviation Administration. Designated Engineering Representatives approve data for aircraft design and repairs on behalf of the Federal Aviation Administration.

Engineering Even with strict testing and licensure, engineering disasters still occur. Therefore, the Professional Engineer, Chartered Engineer, or Incorporated Engineer adheres to a strict code of ethics. Each engineering discipline and professional society maintains a code of ethics, which the members pledge to uphold. Refer also to the Washington accord for international accreditation details of professional engineering degrees.

357

Relationships with other disciplines

Science
Scientists study the world as it is; engineers create the world that has never been. Theodore von Krmn There exists an overlap between the sciences and engineering practice; in engineering, one applies science. Both areas of endeavor rely on accurate observation of materials and phenomena. Both use mathematics and classification criteria to analyze and communicate observations. Scientists are expected to interpret their observations and to make expert recommendations for practical action based on those interpretations. Scientists may also Bioreactors for producing proteins, NRC Biotechnology Research Institute, have to complete engineering tasks, such as Montral, Canada designing experimental apparatus or building prototypes. Conversely, in the process of developing technology engineers sometimes find themselves exploring new phenomena, thus becoming, for the moment, scientists. In the book What Engineers Know and How They Know It,[26] Walter Vincenti asserts that engineering research has a character different from that of scientific research. First, it often deals with areas in which the basic physics and/or chemistry are well understood, but the problems themselves are too complex to solve in an exact manner. Examples are the use of numerical approximations to the Navier-Stokes equations to describe aerodynamic flow over an aircraft, or the use of Miner's rule to calculate fatigue damage. Second, engineering research employs many semi-empirical methods that are foreign to pure scientific research, one example being the method of parameter variation. As stated by Fung et al. in the revision to the classic engineering text, Foundations of Solid Mechanics: "Engineering is quite different from science. Scientists try to understand nature. Engineers try to make things that do not exist in nature. Engineers stress invention. To embody an invention the engineer must put his idea in concrete terms, and design something that people can use. That something can be a device, a gadget, a material, a method, a computing program, an innovative experiment, a new solution to a problem, or an improvement on what is existing. Since a design has to be concrete, it must have its geometry, dimensions, and characteristic numbers. Almost all engineers working on new designs find that they do not have all the needed information. Most often, they are limited by insufficient scientific knowledge. Thus they study mathematics, physics, chemistry, biology and mechanics. Often they have to add to the sciences relevant to their profession. Thus engineering sciences are born."[27]

Engineering

358

Medicine and biology

The study of the human body, albeit from different directions and for different purposes, is an important common link between medicine and some engineering disciplines. Medicine aims to sustain, enhance and even replace functions of the human body, if necessary, through the use of technology. Modern medicine can replace several of the body's functions through the use of artificial organs and can significantly alter the function of the human body through artificial devices such as, for example, brain implants and pacemakers.[29] [30] The fields of Bionics and medical Bionics are dedicated to the study of synthetic implants pertaining to natural systems. Conversely, some engineering disciplines view the human body as a biological machine worth studying, and are dedicated to emulating many of its functions by replacing biology with technology. This has led to fields such as artificial intelligence, neural networks, fuzzy logic, and robotics. There are also substantial interdisciplinary interactions between engineering and medicine.[31] [32] Both fields provide solutions to real world problems. This often requires moving forward before phenomena are completely understood in a more rigorous scientific sense and therefore experimentation and empirical knowledge is an integral part of both.

Leonardo da Vinci, seen here in a self-portrait, has been [28] described as the epitome of the artist/engineer. He is also known for his studies on human anatomy and physiognomy

Medicine, in part, studies the function of the human body. The human body, as a biological machine, has many functions that can be modeled using Engineering methods.[33] The heart for example functions much like a pump,[34] the skeleton is like a linked structure with levers,[35] the brain produces electrical signals etc.[36] These similarities as well as the increasing importance and application of Engineering principles in Medicine, led to the development of the field of biomedical engineering that uses concepts developed in both disciplines. Newly emerging branches of science, such as Systems biology, are adapting analytical tools traditionally used for engineering, such as systems modeling and computational analysis, to the description of biological systems.[33]

Art
There are connections between engineering and art;[37] they are direct in some fields, for example, architecture, landscape architecture and industrial design (even to the extent that these disciplines may sometimes be included in a University's Faculty of Engineering); and indirect in others.[37] [38] [39] [40] The Art Institute of Chicago, for instance, held an exhibition about the art of NASA's aerospace design.[41] Robert Maillart's bridge design is perceived by some to have been deliberately artistic.[42] At the University of South Florida, an engineering professor, through a grant with the National Science Foundation, has developed a course that connects art and engineering.[38] [43] Among famous historical figures Leonardo Da Vinci is a well known Renaissance artist and engineer, and a prime example of the nexus between art and engineering.[28] [44]

Engineering

359

Other fields
In Political science the term engineering has been borrowed for the study of the subjects of Social engineering and Political engineering, which deal with forming political and social structures using engineering methodology coupled with political science principles.

See also
Lists List of basic engineering topics List of engineering topics List of engineers Engineering society List of aerospace engineering topics List of basic chemical engineering topics List of electrical engineering topics List of genetic engineering topics List of mechanical engineering topics List of nanoengineering topics List of software engineering topics Related subjects Design Earthquake engineering Engineering economics Engineers Without Borders Forensic engineering Global Engineering Education Industrial design Open hardware Reverse engineering Science and technology Sustainable engineering Women in engineering

Further reading
Dorf, Richard, ed (2005). The Engineering Handbook (2 ed.). Boca Raton: CRC. ISBN0849315867. Billington, David P. (1996-06-05). The Innovators: The Engineering Pioneers Who Made America Modern. Wiley; New Ed edition. ISBN0-471-14026-0. Petroski, Henry (1992-03-31). To Engineer is Human: The Role of Failure in Successful Design. Vintage. ISBN0-679-73416-3. Petroski, Henry (1994-02-01). The Evolution of Useful Things: How Everyday Artifacts-From Forks and Pins to Paper Clips and Zippers-Came to be as They are. Vintage. ISBN0-679-74039-2. Lord, Charles R. (2000-08-15). Guide to Information Sources in Engineering. Libraries Unlimited. doi:10.1336/1563086999. ISBN1-563-08699-9. Vincenti, Walter G. (1993-02-01). What Engineers Know and How They Know It: Analytical Studies from Aeronautical History. The Johns Hopkins University Press. ISBN0-80184588-2. Hill, Donald R. (1973-12-31) [1206]. The Book of Knowledge of Ingenious Mechanical Devices: Kitb f ma'rifat al-hiyal al-handasiyya. Pakistan Hijara Council. ISBN969-8016-25-2.

External links
National Society of Professional Engineers article on Licensure and Qualifications for the Practice of Engineering
[45]

National Academy of Engineering (NAE) [46] American Society for Engineering Education (ASEE) [47] The US Library of Congress Engineering in History bibliography [48] ICES: Institute for Complex Engineered Systems, Carnegie Mellon University, Pittsburgh, PA [49] History of engineering bibliography [50] at University of Minnesota

Engineering

360

References
[1] ABET History (http:/ / www. abet. org/ history. shtml) [2] Science, Volume 94, Issue 2446, pp. 456: Engineers' Council for Professional Development (http:/ / adsabs. harvard. edu/ abs/ 1941Sci. . . . 94Q. 456. ) [3] Engineers' Council for Professional Development. (1947). Canons of ethics for engineers (http:/ / www. worldcatlibraries. org/ oclc/ 26393909& referer=brief_results) [4] Engineers' Council for Professional Development definition on Encyclopaedia Britannica (http:/ / www. britannica. com/ eb/ article-9105842/ engineering) (Includes Britannica article on Engineering) [5] Oxford English Dictionary [6] Origin: 12501300; ME engin < AF, OF < L ingenium nature, innate quality, esp. mental power, hence a clever invention, equiv. to in- + -genium, equiv. to gen- begetting; Source: Random House Unabridged Dictionary, Random House, Inc. 2006. [7] Barry J. Kemp, Ancient Egypt, Routledge 2005, p. 159 [8] " The Antikythera Mechanism Research Project (http:/ / www. antikythera-mechanism. gr/ project/ general/ the-project. html)", The Antikythera Mechanism Research Project. Retrieved 2007-07-01 Quote: "The Antikythera Mechanism is now understood to be dedicated to astronomical phenomena and operates as a complex mechanical "computer" which tracks the cycles of the Solar System." [9] Wilford, John. (July 31, 2008). Discovering How Greeks Computed in 100 B.C. (http:/ / www. nytimes. com/ 2008/ 07/ 31/ science/ 31computer. html?hp). New York Times. [10] Wright, M T. (2005). "Epicyclic Gearing and the Antikythera Mechanism, part 2". Antiquarian Horology 29 (1 (September 2005)): 5460. [11] Britannica on Greek civilization in the 5th century Military technology (http:/ / www. britannica. com/ EBchecked/ topic/ 244231/ ancient-Greece/ 261062/ Military-technology) Quote: "The 7th century, by contrast, had witnessed rapid innovations, such as the introduction of the hoplite and the trireme, which still were the basic instruments of war in the 5th." and "But it was the development of artillery that opened an epoch, and this invention did not predate the 4th century. It was first heard of in the context of Sicilian warfare against Carthage in the time of Dionysius I of Syracuse." [12] Merriam-Webster Collegiate Dictionary, 2000, CD-ROM, version 2.5. [13] Jenkins, Rhys (1936). Links in the History of Engineering and Technology from Tudor Times. Ayer Publishing. pp.66. ISBN0836921674. [14] Imperial College (http:/ / www3. imperial. ac. uk/ engineering/ teaching/ studying): Studying engineering at Imperial: Engineering courses are offered in five main branches of engineering: aeronautical, chemical, civil, electrical and mechanical. There are also courses in computing science, software engineering, information systems engineering, materials science and engineering, mining engineering and petroleum engineering. [15] Van Every, Kermit E. (1986). "Aeronautical engineering". Encyclopedia Americana. 1. Grolier Incorporated. pp.226. [16] Wheeler, Lynde, Phelps (1951). Josiah Willard Gibbs the History of a Great Mind. Ox Bow Press. ISBN1-881987-11-6. [17] University of Edinburgh (http:/ / www. chemeng. ed. ac. uk/ ) Welcome to Chemical Engineering, which is celebrating 50 years this academic year, is part of the School of Engineering and Electronics (SEE), which includes the other three main engineering disciplines of electrical and electronic engineering, civil engineering and mechanical engineering. [18] Arbe, Katrina (2001.05.07). "PDM: Not Just for the Big Boys Anymore" (http:/ / news. thomasnet. com/ IMT/ archives/ 2001/ 05/ pdm_not_just_fo. html). ThomasNet. . [19] Arbe, Katrina (2003.05.22). "The Latest Chapter in CAD Software Evaluation" (http:/ / news. thomasnet. com/ IMT/ archives/ 2003/ 05/ the_latest_chap. html). ThomasNet. . [20] PDF on Human Development (http:/ / www. ewb-uk. org/ system/ files?file=Hinton lecture text FINAL. pdf) [21] MDG info pdf (http:/ / www. sistech. co. uk/ media/ ICEBrunelLecture2006. pdf?Docu_id=1420& faculty=14) [22] Leger Marketing (2006). Sponsorship effect seen in survey of most-trusted professions: pollster (http:/ / www. canada. com/ montrealgazette/ news/ story. html?id=b7647f97-f370-451e-9506-2f116da2c6a1& k=38584& p=2). ., pg. 2, The occupations most-trusted by Canadians, according to a poll by Leger Marketing... Engineering 88 per cent of respondents... [23] (http:/ / www. tms. org/ pubs/ journals/ JOM/ matters/ matters-9506. html) Why Do Engineers Have to Take Registration Exams? [24] (http:/ / www. ncees. org/ ) NCEES is a national nonprofit organization dedicated to advancing professional licensure for engineers and surveyors. [25] APEGBC - Professional Engineers and Geoscientists of BC (http:/ / www. apeg. bc. ca) [26] Vincenti, Walter G. (1993). What Engineers Know and How They Know It: Analytical Studies from Aeronautical History. Johns Hopkins University Press. [27] Classical and Computational Solid Mechanics, YC Fung and P. Tong. World Scientific. 2001. [28] Bjerklie, David. The Art of Renaissance Engineering. MITs Technology Review Jan./Feb.1998: 54-9. Article explores the concept of the artist-engineer, an individual who used his artistic talent in engineering. Quote from article: Da Vinci reached the pinnacle of artist-engineer-dom, Quote2: It was Leonardo da Vinci who initiated the most ambitious expansion in the role of artist-engineer, progressing from astute observer to inventor to theoretician. (Bjerklie 58) [29] Ethical Assessment of Implantable Brain Chips. Ellen M. McGee and G. Q. Maguire, Jr. from Boston University (http:/ / www. bu. edu/ wcp/ Papers/ Bioe/ BioeMcGe. htm) [30] IEEE technical paper: Foreign parts (electronic body implants).by Evans-Pughe, C. quote from summary: Feeling threatened by cyborgs? (http:/ / ieeexplore. ieee. org/ Xplore/ login. jsp?url=/ iel5/ 2188/ 27125/ 01204814. pdf?arnumber=1204814)

Engineering
[31] Institute of Medicine and Engineering: Mission statement The mission of the Institute for Medicine and Engineering (IME) is to stimulate fundamental research at the interface between biomedicine and engineering/physical/computational sciences leading to innovative applications in biomedical research and clinical practice. (http:/ / www. uphs. upenn. edu/ ime/ mission. html) [32] IEEE Engineering in Medicine and Biology: Both general and technical articles on current technologies and methods used in biomedical and clinical engineering... (http:/ / ieeexplore. ieee. org/ xpl/ RecentIssue. jsp?punumber=51) [33] Royal Academy of Engineering and Academy of Medical Sciences: Systems Biology: a vision for engineering and medicine in pdf: quote1: Systems Biology is an emerging methodology that has yet to be defined quote2: It applies the concepts of systems engineering to the study of complex biological systems through iteration between computational and/or mathematical modelling and experimentation. (http:/ / www. acmedsci. ac. uk/ images/ pressRelease/ 1170256174. pdf) [34] Science Museum of Minnesota: Online Lesson 5a; The heart as a pump (http:/ / www. smm. org/ heart/ lessons/ lesson5a. htm) [35] Minnesota State University emuseum: Bones act as levers (http:/ / www. mnsu. edu/ emuseum/ biology/ humananatomy/ skeletal/ skeletalsystem. html) [36] UC Berkeley News: UC researchers create model of brain's electrical storm during a seizure (http:/ / www. berkeley. edu/ news/ media/ releases/ 2005/ 02/ 23_brainwaves. shtml) [37] Lehigh University project: We wanted to use this project to demonstrate the relationship between art and architecture and engineering (http:/ / www3. lehigh. edu/ News/ news_story. asp?iNewsID=1781& strBack=/ campushome/ Default. asp) [38] National Science Foundation:The Art of Engineering: Professor uses the fine arts to broaden students' engineering perspectives (http:/ / www. nsf. gov/ news/ news_summ. jsp?cntn_id=107990& org=NSF) [39] MIT World:The Art of Engineering: Inventor James Dyson on the Art of Engineering: quote: A member of the British Design Council, James Dyson has been designing products since graduating from the Royal College of Art in 1970. (http:/ / mitworld. mit. edu/ video/ 362/ ) [40] University of Texas at Dallas: The Institute for Interactive Arts and Engineering (http:/ / iiae. utdallas. edu/ ) [41] Aerospace Design: The Art of Engineering from NASAs Aeronautical Research (http:/ / www. artic. edu/ aic/ exhibitions/ nasa/ overview. html) [42] Princeton U: Robert Maillart's Bridges: The Art of Engineering: quote: no doubt that Maillart was fully conscious of the aesthetic implications... (http:/ / press. princeton. edu/ titles/ 137. html) [43] quote:..the tools of artists and the perspective of engineers.. (http:/ / www. chiefengineer. org/ content/ content_display. cfm/ seqnumber_content/ 2697. htm) [44] Drew U: user website: cites Bjerklie paper (http:/ / www. users. drew. edu/ ~ejustin/ leonardo. htm) [45] http:/ / www. nspe. org/ govrel/ gr2-ps1737. asp [46] http:/ / www. nae. edu/ [47] http:/ / www. asee. org/ [48] http:/ / www. loc. gov/ rr/ scitech/ SciRefGuides/ eng-history. html [49] http:/ / www. ices. cmu. edu [50] http:/ / www. tc. umn. edu/ ~tmisa/ biblios/ hist_engineering. html

361

Iterative and incremental development

362

Iterative and incremental development

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between. The iterative and incremental development is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks.

Overview
Incremental development is a scheduling and staging strategy, in which the various parts of the system are developed
An iterative development model

Development topics
The Basic idea
The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process are to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase. The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.

Iterative and incremental development

363

Iterative development
Iterative development slices the deliverable business value (system functionality) into iterations. In each iteration a slice of functionality is delivered through cross-discipline work, starting from the model/requirements through to the testing/deployment. The unified process groups iterations into phases: inception, elaboration, construction, and transition. Inception identifies project scope, risks, and requirements (functional Iterative development. and non-functional) at a high level but in enough detail that work can be estimated. Elaboration delivers a working architecture that mitigates the top risks and fulfills the non-functional requirements. Construction incrementally fills-in the architecture with production-ready code produced from analysis, design, implementation, and testing of the functional requirements. Transition delivers the system into the production operating environment. Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full.

Waterfall vs. Iterative Development

Waterfall development completes the project-wide work-products of each discipline in a single step before moving on to the next discipline in the next step. Business value is delivered all at once, and only at the very end of the project. Backtracking is possible in an iterative approach.

Implementation guidelines
Guidelines that drive the implementation and analysis include:
The unmodified "waterfall model". Progress flows from the top to the bottom, like a Any difficulty in design, coding and waterfall. testing a modification should signal the need for redesign or re-coding. Modifications should fit easily into isolated and easy-to-find modules. If they do not, some redesign is needed.

Modifications to tables should be especially easy to make. If any table modification is not quickly and easily done, redesign is indicated.

Iterative and incremental development Modifications should become easier to make as the iterations progress. If they are not, there is a basic problem such as a design flaw or a proliferation of patches. Patches should normally be allowed to exist for only one or two iterations. Patches may be necessary to avoid redesigning during an implementation phase. The existing implementation should be analysed frequently to determine how well it measures up to project goals. Program analysis facilities should be used whenever available to aid in the analysis of partial implementations. User reaction should be solicited and analysed for indications of deficiencies in the current implementation.

364

See also
Rapid application development Dynamic Systems Development Method Extreme Programming Kaizen Rational Unified Process Unified Process Microsoft Solutions Framework Interaction Design OpenUP/Basic Object-oriented analysis and design Goal-Driven Software Development Process Spiral model

Further reading
This page is extensively based on: Dr. Alistair Cockburn (May 2008). "Using Both Incremental and Iterative Development" [1]. STSC CrossTalk (USAF Software Technology Support Center) 21 (5): 2730. ISSNd0000089. Retrieved 2009-01-10. Craig Larman, Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" [2]. IEEE Computer (IEEE Computer Society) 36 (6): 4756. doi:10.1109/MC.2003.1204375. ISSN0018-9162. Retrieved 2009-01-10.

External links
Going round and round and getting nowhere eXtremely fast? Another look at incremental & iterative development [3] from www.methodsandtools.com The Case for Waterfall Development [4] from www.fromthetrench.com Iterative Development and The Leaning Tower of Pisa [5] from www.fromthetrench.com]

References
[1] [2] [3] [4] [5] http:/ / www. stsc. hill. af. mil/ crosstalk/ 2008/ 05/ 0805Cockburn. html http:/ / c2. com/ cgi/ wiki/ wiki?HistoryOfIterative http:/ / www. methodsandtools. com/ archive/ archive. php?id=14 http:/ / web. archive. org/ web/ 20080208120728/ http:/ / www. fromthetrench. com/ 2007/ 01/ 02/ the-case-for-waterfall-development/ http:/ / web. archive. org/ web/ 20080209142654/ http:/ / www. fromthetrench. com/ 2007/ 01/ 21/ iterative-development-and-the-leaning-tower-of-pisa/

Project Management Institute

365

Project Management Institute

Type Founded Key people

Professional Organization 1969 Gregory Balestrero, President and CEO

Area served Worldwide Focus Method Revenue Employees Members Website Project Management Certification, Industry standards, Conferences, Publications 80.4 MM (budget 2007) 51-200 employees 285,000+ www.pmi.org
[2] [1]

The Project Management Institute (PMI) is a non-profit professional organization for the project management profession with the purpose of advancing project management.[3]

Overview
The Project Management Institute (PMI) is offering a range of services to the Project Management profession such as the development of standards, research, education, publication, networking-opportunities in local chapters, hosting conferences and training seminars, and maintaining multiple credentials in project management. These credentials are:[4] Certified Associate in Project Management (CAPM) Project Management Professional (PMP) PMI Scheduling Professional (PMI-SP) PMI Risk Management Professional (PMI-RMP) Program Management Professional (PgMP)

In addition to career development credentials, PMI offers one certification: Organizational Project Management Maturity Model Certified Consultant (OPM3-CC) PMI has recruited volunteers to create industry standards, such as "A Guide to the Project Management Body of Knowledge", which has been recognized by the American National Standards Institute (ANSI).[5]

Project Management Institute

366

Certification
Launched in 1984, PMI's first certification was the PMP. Around 370,000 people now hold the PMP certification. In 2007, it earned the ANSI/ISO/IEC 17024 accreditation from the International Organization for Standardization (ISO). Credential holders do not have to be members of PMI. To maintain most PMI credentials, holders must earn Professional Development Units (PDUs) which can be earned in a variety of ways such as taking classes, attending PMI global congresses, contributing to professional research or writing and publishing papers on the subject.

Standards
PMI standards are targeted at projects, programs, people, organizations and the profession. Currently, some of the published standards are: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Construction Extension to the PMBOK Guide, Third Edition Government Extension to the PMBOK Guide, Third Edition The Standard for Program Management The Standard for Portfolio Management Practice Standard for Earned Value Management Organizational Project Management Maturity Model (OPM3) Practice Standard for Project Configuration Management Practice Standard for Work Breakdown StructuresSecond Edition Project Manager Competency Development FrameworkSecond Edition

According to PMI, standards are developed by volunteers in a three step process including an exposure draft process that allows the public to view the standard draft and include change suggestions.

External links
PMI official website [2]

References
[1] "PMI Board of Directors Meeting Minutes Summary" (http:/ / www. pmi. org/ PDF/ ap_meetingminutesoct06. pdf). Seattle. 19-20 October 2006. . [2] http:/ / www. pmi. org/ [3] Wickwire, Jon M.; et al. (2002). Construction Scheduling: Preparation, Liability, and Claims. p.289. [4] Nokes, Sebastian; Kelly, Sean (2007). The Definitive Guide to Project Management: The Fast Track to Getting. p.331. [5] Van Bon, Jan (2006). Frameworks for IT Management. Van Haren Publishing. p.206. ISBN9077212906.

Requirement

367

Requirement
In engineering, a requirement is a singular documented need of what a particular product or service should be or perform. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development. Requirements are also an important input into the verification process, since tests should trace back to specific requirements. Requirements show what elements and functions are necessary for the particular project. The requirements development phase may have been preceded by a feasibility study, or a conceptual analysis phase of the project. The requirements phase may be broken down into requirements elicitation (gathering, understanding, reviewing, and articulating the needs of the stakeholders)[1] , analysis (checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct)[2] [3] .

Product versus process requirements

Projects are subject to three sorts of requirements: Business requirements describe in business terms what must be delivered or accomplished to provide value. Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set business requirements.) Process requirements describe activities performed by the developing organization. For instance, processes requirements could specify specific methodologies to be followed, and constraints that the organization must obey. Product and process requirements are closely linked. Process requirements often specify the activities that will be performed to satisfy a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement for the product to be maintainable (a Product requirement) often is addressed by imposing requirements to follow particular development styles (e.g., object-oriented programming), style-guides, or a review/inspection process (process requirements).

Requirements in systems and software engineering

In systems engineering, a requirement can be a description of what a system must do, referred to as a Functional Requirement. This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called Non-functional requirements, or 'performance requirements' or 'quality of service requirements.' Examples of such requirements include usability, availability, reliability, supportability, testability, maintainability, and (if defined in a way that's verifiably measurable and unambiguous) ease-of-use. A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements generally avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Describing how the system should be implemented may be known as implementation bias or "solution engineering". However, implementation constraints (aka solution requirements) on the solution may be validly expressed by the future owner, for example for communality reasons with other owned products. In software engineering, the same meanings of requirements apply, except that the focus of interest is the software itself.

Requirement

368

Product requirements
Types of product requirements
Requirements are typically placed into these categories: Functional requirements describe the functionality that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities. Non-functional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as quality requirements or ilities. Constraint requirements are the ones that act to constrain the solution. No matter how the problem is solved the constraint requirements must be adhered to. Non-functional requirements can be further classified according to whether they are usability requirements, look and feel requirements, humanity requirements, performance requirements, maintainability requirements, operational requirements, safety requirements, reliability requirements, or one of many other types of requirements. In software engineering this categorization is useful because only functional requirements can be directly implemented in software. The non-functional requirements are controlled by other aspects of the system. For example, in a computer system reliability is related to hardware failure rates, and performance is controlled by CPU and memory. Non-functional requirements can in some cases be decomposed into functional requirements for software. For example, a system level non-functional safety requirement can be decomposed into one or more functional requirements. See FURPS. In addition, a non-functional requirement may be converted into a process requirement when the requirement is not easily measurable. For example, a system level maintainability requirement may be decomposed into restrictions on software constructs or limits on lines or code.

Characteristics of good requirements

The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged[4] .
Characteristic Unitary (Cohesive) The requirement addresses one and only one thing. Complete Consistent The requirement is fully stated in one place with no missing information. The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. The requirement is atomic, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes". The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented. The requirement has not been made obsolete by the passage of time. The requirement can be implemented within the constraints of the project. The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited. The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. An optional requirement is a contradiction in terms. The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis. Explanation

Non-Conjugated (Atomic)

Traceable Current Feasible Unambiguous

Mandatory

Verifiable

Requirement To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present geocoded information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture. Verification All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration or inspection or review of design). Certain requirements, by their very structure, are not verifiable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable. Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent; however they may traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming. Other non-functional requirements will trace to other system components and be verified at that level. For example system reliability is often verified by analysis at the system level. Avionics software with its complicated safety requirements must follow the DO-178B development process. Verifiability is necessary for a requirement but there are other important issues. A requirement can be verifiable yet incorrect; and assessing verifiability alone will not detect incorrect requirements. Moreover, verification is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized. Requirements analysis or requirements engineering Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspection have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues. There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they 1. take a long time to produce - sometimes to the point of being obsolete once completed 2. limit the implementation options available 3. are costly to produce

369

Requirement

370

Documenting requirements
Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system shall do. Example: 'The contractor shall deliver the product no later than xyz date.' Other ways include use cases and user stories.

Changes in requirements
Requirements generally change with time. Once defined and approved, requirements should fall under change control. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to requirements management studies and practices.

Disputes regarding the necessity of rigour in software requirements

Most agile software development methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, extreme programming for example describes requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies also typically capture requirements in a series of automated acceptance test.

See also
FURPS - acronym of key requirement categories Requirements analysis Requirements management Requirement prioritization Requirements traceability Specification (technical standard) Use case

External links
Discovering System Requirements [5] The International Institute for Business Analysis and The IIBA's Business Analysis Body of Knowledge [6] Writing Good Requirements [7]

References
[1] Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management (http:/ / www. stellman-greene. com/ aspm/ ). O'Reilly Media. p.98. ISBN978-0-596-00948-9. . [2] Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN0-7356-1879-8. [3] Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN978-0201709124. [4] Davis, Alan M. (1993). Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall. ISBN0-13-805763-X. [5] http:/ / www. sie. arizona. edu/ sysengr/ publishedPapers/ requirements. pdf [6] http:/ / theiiba. org [7] http:/ / www. reqid. com/ requirements-management/ writing-good-requirements-part1/

Operations research

371

Operations research
Operations research, also known as operational research, is an interdisciplinary branch of applied mathematics and formal science that uses advanced analytical methods such as mathematical modeling, statistical analysis, and mathematical optimization to arrive at optimal or near-optimal solutions to complex decision-making problems. It is often concerned with determining the maximum (of profit, performance, or yield) or minimum (of loss, risk, or cost) of some real-world objective. Originating in military efforts before World War II, its techniques have grown to concern problems in a variety of industries.[1]

Overview
Operations research encompasses a wide range of problem-solving techniques and methods applied in the pursuit of improved decision-making and efficiency.[2] Some of the tools used by operations researchers are statistics, optimization, probability theory, queuing theory, game theory, graph theory, decision analysis, mathematical modeling and simulation. Because of the computational nature of these fields, OR also has strong ties to computer science. Operations researchers faced with a new problem must determine which of these techniques are most appropriate given the nature of the system, the goals for improvement, and constraints on time and computing power. Work in operations research and management science may be characterized as one of three categories:[3] Fundamental or foundational work takes place in three mathematical disciplines: probability, optimization, and dynamical systems theory. Modeling work is concerned with the construction of models, analyzing them mathematically, implementing them on computers, solving them using software tools, and assessing their effectiveness with data. This level is mainly instrumental, and driven mainly by statistics and econometrics. Application work in operations research, like other engineering and economics' disciplines, attempts to use models to make a practical impact on real-world problems. The major subdisciplines in modern operations research, as identified by the journal Operations Research [4] , are: Computing and information technologies Decision analysis Environment, energy, and natural resources Financial engineering Manufacturing, service sciences, and supply chain management Policy modeling and public sector work Revenue management Simulation Stochastic models Transportation

History
As a formal discipline, operations research originated in the efforts of military planners during World War II. In the decades after the war, the techniques began to be applied more widely to problems in business, industry and society. Since that time, operations research has expanded into a field widely used in industries ranging from petrochemicals to airlines, finance, logistics, and government, moving to a focus on the development of mathematical models that can be used to analyze and optimize complex systems, and has become an area of active academic and industrial research. [1]

Operations research

372

Historical origins
In the World War II era, operations research was defined as "a scientific method of providing executive departments with a quantitative basis for decisions regarding the operations under their control."[5] Other names for it included operational analysis (UK Ministry of Defence from 1962)[6] and quantitative management.[7] Prior to the formal start of the field, early work in operations research was carried out by individuals such as Charles Babbage. His research into the cost of transportation and sorting of mail led to England's universal "Penny Post" in 1840, and studies into the dynamical behaviour of railway vehicles in defence of the GWR's broad gauge.[8] The modern field of operations research arose during World War II. Modern operations research originated at the Bawdsey Research Station in the UK in 1937 and was the result of an initiative of the station's superintendent, A. P. Rowe. Rowe conceived the idea as a means to analyse and improve the working of the UK's early warning radar system, Chain Home (CH). Initially, he analyzed the operating of the radar equipment and its communication networks, expanding later to include the operating personnel's behaviour. This revealed unappreciated limitations of the CH network and allowed remedial action to be taken. [9] Scientists in the United Kingdom including Patrick Blackett later Lord Blackett OM PRS, Cecil Gordon, C. H. Waddington, Owen Wansbrough-Jones, Frank Yates, Jacob Bronowski and Freeman Dyson, and in the United States with George Dantzig looked for ways to make better decisions in such areas as logistics and training schedules. After the war it began to be applied to similar problems in industry.

Second World War

During the Second World War close to 1,000 men and women in Britain were engaged in operational research. About 200 operational research scientists worked for the British Army.[10] Patrick Blackett worked for several different organizations during the war. Early in the war while working for the Royal Aircraft Establishment (RAE) he set up a team known as the "Circus" which helped to reduce the number of anti-aircraft artillery rounds needed to shoot down an enemy aircraft from an average of over 20,000 at the start of the Battle of Britain to 4,000 in 1941.[11] In 1941 Blackett moved from the RAE to the Navy, first to the Royal Navy's Coastal Command, in 1941 and then early in 1942 to the Admiralty.[12] Blackett's team at Coastal Command's Operational Research Section (CC-ORS) included two future Nobel prize winners and many other people who went on to be preeminent in their fields.[13] They undertook a number of Patrick Blackett crucial analyses that aided the war effort. Britain introduced the convoy system to reduce shipping losses, but while the principle of using warships to accompany merchant ships was generally accepted, it was unclear whether it was better for convoys to be small or large. Convoys travel at the speed of the slowest member, so small convoys can travel faster. It was also argued that small convoys would be harder for German U-boats to detect. On the other hand, large convoys could deploy more warships against an attacker. Blackett's staff showed that the losses suffered by convoys depended largely on the number of escort vessels present, rather than on the overall size of the convoy. Their conclusion, therefore, was that a few large convoys are more defensible than many small ones.[14] While performing an analysis of the methods used by RAF Coastal Command to hunt and destroy submarines, one of the analysts asked what colour the aircraft were. As most of them were from Bomber Command they were painted black for nighttime operations. At the suggestion of CC-ORS a test was run to see if that was the best colour to camouflage the aircraft for daytime operations in the grey North Atlantic skies. Tests showed that aircraft painted white were on average not spotted until they were 20% closer than those painted black. This change indicated that

Operations research 30% more submarines would be attacked and sunk for the same number of sightings.[15] Other work by the CC-ORS indicated that on average if the depth at which aerial delivered depth charges (DCs) was changed from 100 feet to 25 feet, the kill ratios would go up. The reason was that if a U-boat saw an aircraft only shortly before it arrived over the target then at 100 feet the charges would do no damage (because the U-boat wouldn't have time to descend to that depth), and if it saw the aircraft a long way from the target it had time to alter course under water so the chances of it being within the 20 feet kill zone of the charges was small. It was more efficient to attack those submarines close to the surface when these targets' locations were better known than to attempt their destruction at greater depths when their positions could only be guessed. Before the change of settings from 100 feet to 25 feet, 1% of submerged U-boats were sunk and 14% damaged. After the change, 7% were sunk and 11% damaged. (If submarines were caught on the surface, even if attacked shortly after submerging, the numbers rose to 11% sunk and 15% damaged). Blackett observed "there can be few cases where such a great operational gain had been obtained by such a small and simple change of tactics".[16] Bomber Command's Operational Research Section (BC-ORS), analysed a report of a survey carried out by RAF Bomber Command. For the survey, Bomber Command inspected all bombers returning from bombing raids over Germany over a particular period. All damage inflicted by German air defenses was noted and the recommendation was given that armour be added in the most heavily damaged areas. Their suggestion to remove some of the crew so that an aircraft loss would result in fewer personnel loss was rejected by RAF command. Blackett's team instead made the surprising and counter-intuitive recommendation that the armour be placed in the areas which were completely untouched by damage in the bombers which returned. They reasoned that the survey was biased, since it only included aircraft that returned to Britain. The untouched areas of returning aircraft were probably vital areas, which, if hit, would result in the loss of the aircraft. When Germany organised its air defences into the Kammhuber Line, it was realised that if the RAF bombers were to fly in a bomber stream they could overwhelm the night fighters who flew in individual cells directed to their targets by ground controllers. It was then a matter of calculating the statistical loss from collisions against the statistical loss from night fighters to calculate how close the bombers should fly to minimise RAF losses.[17] The "exchange rate" ratio of output to input was a characteristic feature of operations research. By comparing the number of flying hours put in by Allied aircraft to the number of U-boat sightings in a given area, it was possible to redistribute aircraft to more productive patrol areas. Comparison of exchange rates established "effectiveness ratios" useful in planning. The ratio of 60 mines laid per ship sunk was common to several campaigns: German mines in British ports, British mines on German routes, and United States mines in Japanese routes.[18]

373

Map of Kammhuber Line

Operations research doubled the on-target bomb rate of B-29s bombing Japan from the Marianas Islands by increasing the training ratio from 4 to 10 percent of flying hours; revealed that wolf-packs of three United States submarines were the most effective number to enable all members of the pack to engage targets discovered on their individual patrol stations; revealed that glossy enamel paint was more effective camouflage for night fighters than traditional dull camouflage paint finish, and the smooth paint finish increased airspeed by reducing skin friction.[18] On land, the operational research sections of the Army Operational Research Group (AORG) of the Ministry of Supply (MoS) were landed in Normandy in 1944, and they followed British forces in the advance across Europe. They analysed, among other topics, the effectiveness of artillery, aerial bombing, and anti-tank shooting.

Operations research

374

After World War II

With expanded techniques and growing awareness of the field at the close of the war, operations research was no longer limited to only operations, but was extended to encompass equipment procurement, training, logistics and infrastructure. Academic Denis Bouyssou describes the historical development of operations research from the 1940s to the 1970s as follows. "The historical development of Operational Research (OR) is traditionally seen as the succession of several phases: the 'heroic times' of the Second World War, the 'Golden Age' between the fifties and the sixties during which major theoretical achievements were accompanied by a widespread diffusion of OR techniques in private and public organisations, a 'crisis' followed by a 'decline' starting with the late sixties, a phase during which OR groups in firms progressively disappeared while academia became less and less concerned with the applicability of the techniques developed".[19] Individuals such as Stafford Beer and George Dantzig pioneered early academic efforts in operations research.

Problems addressed with operations research

critical path analysis or project planning: identifying those processes in a complex project which affect the overall duration of the project floorplanning: designing the layout of equipment in a factory or components on a computer chip to reduce manufacturing time (therefore reducing cost) network optimization: for instance, setup of telecommunications networks to maintain quality of service during outages allocation problems optimal search routing, such as determining the routes of buses so that as few buses are needed as possible supply chain management: managing the flow of raw materials and products based on uncertain demand for the finished products efficient messaging and customer response tactics automation: automating or integrating robotic systems in human-driven operations processes globalization: globalizing operations processes in order to take advantage of cheaper materials, labor, land or other productivity inputs transportation: managing freight transportation and delivery systems (Examples: LTL Shipping, intermodal freight transport) scheduling: personnel staffing manufacturing steps project tasks network data traffic: these are known as queueing models or queueing systems. sports events and their television coverage blending of raw materials in oil refineries determining optimal prices, in many retail and B2B settings, within the disciplines of pricing science Operations research is also used extensively in government where evidence-based policy is used.

Operations research

375

Management science
In 1967 Stafford Beer characterized the field of management science as "the business use of operations research".[20] However, in modern times the term management science may also be used to refer to the separate fields of organizational studies or corporate strategy. Like operations research itself, management science (MS), is an interdisciplinary branch of applied mathematics devoted to optimal decision planning, with strong links with economics, business, engineering, and other sciences. It uses various scientific research-based principles, strategies, and analytical methods including mathematical modeling, statistics and numerical algorithms to improve an organization's ability to enact rational and meaningful management decisions by arriving at optimal or near optimal solutions to complex decision problems. In short, management sciences help businesses to achieve their goals using the scientific methods of operations research. The management scientist's mandate is to use rational, systematic, science-based techniques to inform and improve decisions of all kinds. Of course, the techniques of management science are not restricted to business applications but may be applied to military, medical, public administration, charitable groups, political groups or community groups. Management science is concerned with developing and applying models and concepts that may prove useful in helping to illuminate management issues and solve managerial problems, as well as designing and developing new and better models of organizational excellence. [21] The application of these models within the corporate sector became known as Management science.[22]

Techniques
Some of the fields that are considered within Management Science include:
Data mining Decision analysis Engineering Forecasting Game theory Industrial engineering Logistics Mathematical modeling Optimization Probability and statistics Project management Simulation Social network/Transportation forecasting models Supply chain management

Applications of management science

Applications of management science are abundant in industry as airlines, manufacturing companies, service organizations, military branches, and in government. The range of problems and issues to which management science has contributed insights and solutions is vast. It includes:.[21] scheduling airlines, including both planes and crew, deciding the appropriate place to site new facilities such as a warehouse, factory or fire station, managing the flow of water from reservoirs, identifying possible future development paths for parts of the telecommunications industry, establishing the information needs and appropriate systems to supply them within the health service, and identifying and understanding the strategies adopted by companies for their information systems

Management science is also concerned with so-called soft-operational analysis, which concerns methods for strategic planning, strategic decision support, and Problem Structuring Methods (PSM). In dealing with these sorts of challenges mathematical modeling and simulation are not appropriate or will not suffice. Therefore, during the past 30 years, a number of non-quantified modelling methods have been developed. These include: stakeholder based approaches including metagame analysis and drama theory

Operations research morphological analysis and various forms of influence diagrams. approaches using cognitive mapping the Strategic Choice Approach robustness analysis

376

Societies and journals

Societies The International Federation of Operational Research Societies (IFORS)[23] is an umbrella organization for operations research societies worldwide, representing approximately 50 national societies including those in the US,[24] UK,[25] France,[26] Germany, Canada,[27] Australia,[28] New Zealand,[29] Philippines,[30] India,[31] , Japan and South Africa,[32] . The constituent members of IFORS form regional groups, such as that in Europe,[33] . Other important operations research organizations are Simulation Interoperability Standards Organization (SISO)[34] and Interservice/Industry Training, Simulation and Education Conference (I/ITSEC)[35] In 2004 the US-based organization INFORMS began an initiative to market the OR profession better, including a website entitled The Science of Better[36] which provides an introduction to OR and examples of successful applications of OR to industrial problems. This initiative has been adopted by the Operational Research Society in the UK, including a website entitled Learn about OR,[37] . Journals INFORMS publishes twelve scholarly journals about operations research, including the top two journals in their class, according to 2005 Journal Citation Reports.[38] They are: Decision Analysis[39] Information Systems Research INFORMS Journal on Computing INFORMS Transactions on Education[40] (an open access journal) Interfaces: An International Journal of the Institute for Operations Research and the Management Sciences Management Science: A Journal of the Institute for Operations Research and the Management Sciences Manufacturing & Service Operations Management Marketing Science Mathematics of Operations Research Operations Research: A Journal of the Institute for Operations Research and the Management Sciences Organization Science Transportation Science.

Other journals European Journal of Operational Research (EJOR): Founded in 1975 and is presently by far the largest operational research journal in the world, with its around 9,000 pages of published papers per year. In 2004, its total number of citations was the second largest amongst Operational Research and Management Science journals; INFOR Journal: published and sponsored by the Canadian Operational Research Society; Journal of Defense Modeling and Simulation (JDMS): Applications, Methodology, Technology: a quarterly journal devoted to advancing the science of modeling and simulation as it relates to the military and defense.[41] Journal of the Operational Research Society (JORS): an official journal of The OR Society; this is the oldest continuously published journal of OR in the world, published by Palgrave;[42] Journal of Simulation (JOS): an official journal of The OR Society, published by Palgrave;[42] Mathematical Methods of Operations Research (MMOR): the journal of the German and Dutch OR Societies, published by Springer;[43]

Operations research Military Operations Research (MOR): published by the Military Operations Research Society; Opsearch: official journal of the Operational Research Society of India; OR Insight: a quarterly journal of The OR Society, published by Palgrave;[42] TOP: the official journal of the Spanish Society of Statistics and Operations Research.[44]

377

See also
Operation research topics Assignment problem Decision Analysis Dynamic programming Linear programming Inventory theory Optimal Maintenance Optimization Real options analysis Stochastic processes Systems analysis Systems thinking Operation researchers Operations researcher category Russell L. Ackoff Anthony Stafford Beer Alfred Blumstein C. West Churchman George Dantzig Richard Karp Frederick W. Lanchester Thomas L. Magnanti Alvin E. Roth Related fields Behavioral operations research Database normalization Econometrics Industrial Engineering Industrial organization Management engineering Managerial economics Military simulation Modeling & Simulation Search Based Software Engineering Simulation System Dynamics System Safety Systems theory Wargaming

References
Kirby, M. W. (Operational Research Society (Great Britain)). Operational Research in War and Peace: The British Experience from the 1930s to 1970, Imperial College Press, 2003. ISBN 1860943667, 9781860943669

Further reading
C. West Churchman, Russell L. Ackoff & E. L. Arnoff, Introduction to Operations Research, New York: J. Wiley and Sons, 1957 Joseph G. Ecker & Michael Kupferschmid, Introduction to Operations Research, Krieger Publishing Co. Frederick S. Hillier & Gerald J. Lieberman, Introduction to Operations Research, McGraw-Hill: Boston MA; 8th. (International) Edition, 2005 Maurice W. Kirby, Operational Research in War and Peace, Imperial College Press, London, 2003 Michael Pidd, Tools for Thinking: Modelling in Management Science, J. Wiley & Sons Ltd., Chichester; 2nd. Edition, 2003 Hamdy A. Taha, Operations Research: An Introduction, Prentice Hall; 8th. Edition, 2006 Wayne Winston, Operations Research: Applications and Algorithms, Duxbury Press; 4th. Edition, 2003 Kenneth R. Baker, Dean H. Kropp (1985). Management Science: An Introduction to the Use of Decision Models Stafford Beer (1967). Management Science: The Business Use of Operations Research David Charles Heinze (1982). Management Science: Introductory Concepts and Applications Lee J. Krajewski, Howard E. Thompson (1981). "Management Science: Quantitative Methods in Context" Thomas W. Knowles (1989). Management science: Building and Using Models Kamlesh Mathur, Daniel Solow (1994). Management Science: The Art of Decision Making Laurence J. Moore, Sang M. Lee, Bernard W. Taylor (1993). Management Science William Thomas Morris (1968). Management Science: A Bayesian Introduction.

Operations research William E. Pinney, Donald B. McWilliams (1987). Management Science: An Introduction to Quantitative Analysis for Management Gerald E. Thompson (1982). Management Science: An Introduction to Modern Quantitative Analysis and Decision Making. New York : McGraw-Hill Publishing Co.

378

External links
INFORMS OR/MS Resource Collection [45]: a comprehensive set of OR links. International Federation of Operational Research Societies [46] Occupational Outlook Handbook, U.S. Department of Labor Bureau of Labor Statistics [47] "Operation Everything: It Stocks Your Grocery Store, Schedules Your Favorite Team's Games, and Helps Plan Your Vacation. The Most Influential Academic Discipline You've Never Heard Of." Boston Globe, June 27, 2004
[48]

"Optimal Results: IT-powered advances in operations research can enhance business processes and boost the corporate bottom line." Computerworld, November 20, 2000 [49]

References
[1] http:/ / www. hsor. org/ what_is_or. cfm [2] http:/ / www. bls. gov/ oco/ ocos044. htm [3] What is Management Science Research? (http:/ / www. jbs. cam. ac. uk/ programmes/ mphil_mgtscience/ mgtresearch. html) University of Cambridge 2008. Retrieved 5 June 2008. [4] http:/ / www3. informs. org/ site/ OperationsResearch/ index. php?c=10& kat=Forthcoming+ Papers [5] "Operational Research in the British Army 19391945, October 1947, Report C67/3/4/48, UK National Archives file WO291/1301 Quoted on the dust-jacket of: Morse, Philip M, and Kimball, George E, Methods of Operations Research, 1st Edition Revised, pub MIT Press & J Wiley, 5th printing, 1954. [6] UK National Archives Catalogue for WO291 (http:/ / www. nationalarchives. gov. uk/ catalogue/ displaycataloguedetails. asp?CATID=109& CATLN=2& Highlight=& FullDetails=True) lists a War Office organisation called Army Operational Research Group (AORG) that existed from 1946 to 1962. "In January 1962 the name was changed to Army Operational Research Establishment (AORE). Following the creation of a unified Ministry of Defence, a tri-service operational research organisation was established: the Defence Operational Research Establishment (DOAE) which was formed in 1965, and it absorbed the Army Operational Research Establishment based at West Byfleet." [7] http:/ / brochure. unisa. ac. za/ myunisa/ data/ subjects/ Quantitative%20Management. pdf [8] M.S. Sodhi, "What about the 'O' in O.R.?" OR/MS Today, December, 2007, p. 12, http:/ / www. lionhrtpub. com/ orms/ orms-12-07/ frqed. html [9] http:/ / www. britannica. com/ EBchecked/ topic/ 682073/ operations-research/ 68171/ History#ref22348 [10] Kirby, p. 117 (http:/ / books. google. co. uk/ books?id=DWITTpkFPEAC& lpg=PA141& pg=PA117) [11] Kirby, pp. 9194 (http:/ / books. google. co. uk/ books?id=DWITTpkFPEAC& lpg=PA141& pg=PA94) [12] Kirby, p. 96,109 (http:/ / books. google. co. uk/ books?id=DWITTpkFPEAC& lpg=PA141& pg=PA109) [13] Kirby, p. 96 (http:/ / books. google. co. uk/ books?id=DWITTpkFPEAC& lpg=PA141& pg=PA96) [14] "Numbers are Essential": Victory in the North Atlantic Reconsidered, MarchMay 1943 (http:/ / www. familyheritage. ca/ Articles/ victory1943. html) [15] Kirby, p. 101 (http:/ / books. google. co. uk/ books?id=DWITTpkFPEAC& lpg=PA141& pg=PA101) [16] (Kirby, pp. 102,103 (http:/ / books. google. co. uk/ books?id=DWITTpkFPEAC& lpg=PA141& pg=PA103)) [17] (http:/ / www. raf. mod. uk/ bombercommand/ thousands. html) [18] Milkman, Raymond H. (May 1968). Operations Research in World War II. United States Naval Institute Proceedings. [19] Bouyssou, Denis, Questioning the history of operational in order to prepare its future http:/ / hal. ccsd. cnrs. fr/ docs/ 00/ 02/ 86/ 41/ PDF/ cahierLamsade196. pdf [20] Stafford Beer (1967) Management Science: The Business Use of Operations Research [21] What is Management Science? (http:/ / www. lums. lancs. ac. uk/ departments/ ManSci/ DeptProfile/ WhatisManSci/ ) Lancaster University, 2008. Retrieved 5 June 2008. [22] What is Management Science? (http:/ / bus. utk. edu/ soms/ information/ whatis_msci. html) The University of Tennessee, 2006. Retrieved 5 June 2008. [23] IFORS (http:/ / www. ifors. org/ ) [24] INFORMS (http:/ / www. informs. org/ ) [25] The OR Society (http:/ / www. orsoc. org. uk) [26] http:/ / www. roadef. org/ content/ index. htm

Operations research
[27] CORS (http:/ / www. cors. ca) [28] ASOR (http:/ / www. asor. org. au) [29] ORSNZ (http:/ / www. orsnz. org. nz/ ) [30] ORSP (http:/ / www. orsp. org. ph/ ) [31] ORSI (http:/ / www. orsi. in/ ) [32] ORSSA (http:/ / www. orssa. org. za/ ) [33] EURO (http:/ / www. euro-online. org/ ) [34] SISO (http:/ / www. sisostds. org/ ) [35] I/ITSEC (http:/ / www. iitsec. org/ ) [36] The Science of Better (http:/ / www. scienceofbetter. org/ ) [37] Learn about OR (http:/ / www. learnaboutor. co. uk/ ) [38] INFORMS Journals (http:/ / www. informs. org/ index. php?c=31& kat=-+ INFORMS+ Journals) [39] Decision Analysis (http:/ / www. informs. org/ site/ DA/ ) [40] INFORMS Transactions on Education (http:/ / www. informs. org/ site/ ITE/ ) [41] JDMS (http:/ / www. scs. org/ pubs/ jdms/ jdms. html) [42] The OR Society (http:/ / www. orsoc. org. uk); [43] Mathematical Methods of Operations Research website (http:/ / www. springer. com/ mathematics/ journal/ 186) [44] TOP (http:/ / www. springer. com/ east/ home/ business/ operations+ research?SGWID=5-40521-70-173677307-detailsPage=journal|description) [45] http:/ / www. informs. org/ Resources/ [46] http:/ / www. ifors. org/ [47] http:/ / stats. bls. gov/ oco/ ocos044. htm/ [48] http:/ / www. boston. com/ news/ globe/ reprints/ 062704_postrel/ [49] http:/ / www. computerworld. com/ s/ article/ 54157/ Optimal_Results?taxonomyId=063/

379

Risk management
For non-business risks, see risk or the disambiguation page risk analysis. Risk is defined in ISO 31000 as the effect of uncertainty on objectives (whether positive or negative). Risk management can therefore be considered the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events[1] or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures, legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attacks from an Example of risk management: NASA's illustration showing high impact risk areas for adversary. Several risk management the International Space Station. standards have been developed including the Project Management Institute, the National Institute of Science and Technology, actuarial societies, and ISO standards.[2] [3] Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety.

Risk management The strategies to manage risk include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Certain aspects of many of the risk management standards have come under criticism for having no measurable improvement on risk even though the confidence in estimates and decisions increase.[1]

380

Introduction
This section provides an introduction to the principles of risk management. The vocabulary of risk management is defined in ISO Guide 73, "Risk management. Vocabulary."[2] In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled in descending order. In practice the process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss versus a risk with high loss but lower probability of occurrence can often be mishandled. Intangible risk management identifies a new type of a risk that has a 100% probability of occurring but is ignored by the organization due to a lack of identification ability. For example, when deficient knowledge is applied to a situation, a knowledge risk materializes. Relationship risk appears when ineffective collaboration occurs. Process-engagement risk may be an issue when ineffective operational procedures are applied. These risks directly reduce the productivity of knowledge workers, decrease cost effectiveness, profitability, service, quality, reputation, brand value, and earnings quality. Intangible risk management allows risk management to create immediate value from the identification and reduction of risks that reduce productivity. Risk management also faces difficulties in allocating resources. This is the idea of opportunity cost. Resources spent on risk management could have been spent on more profitable activities. Again, ideal risk management minimizes spending and minimizes the negative effects of risks.

Method
For the most part, these methods consist of the following elements, performed, more or less, in the following order. 1. 2. 3. 4. 5. identify, characterize, and assess threats assess the vulnerability of critical assets to specific threats determine the risk (i.e. the expected consequences of specific types of attacks on specific assets) identify ways to reduce those risks prioritize risk reduction measures based on a strategy

Principles of risk management

The International Organization for Standardization identifies the following principles of risk management:[4] Risk management should: create value. be an integral part of organizational processes. be part of decision making. explicitly address uncertainty. be systematic and structured. be based on the best available information. be tailored.

take into account human factors. be transparent and inclusive. be dynamic, iterative and responsive to change.

Risk management be capable of continual improvement and enhancement.

381

Process
According to the standard ISO 31000 "Risk management -- Principles and guidelines on implementation,"[3] the process of risk management consists of several steps as follows:

Establishing the context

Establishing the context involves: 1. Identification of risk in a selected domain of interest 2. Planning the remainder of the process. 3. Mapping out the following: the social scope of risk management the identity and objectives of stakeholders the basis upon which risks will be evaluated, constraints. 4. Defining a framework for the activity and an agenda for identification. 5. Developing an analysis of risks involved in the process. 6. Mitigation or Solution of risks using available technological, human and organizational resources.

Identification
After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself. Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport. Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government. When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties. The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are: Objectives-based risk identification Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk. Scenario-based risk identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk - see Futures Studies for methodology used by Futurists. Taxonomy-based risk identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.[5] Common-risk checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation.[6]

Risk management Risk charting[7] This method combines the above approaches by listing resources at risk, Threats to those resources Modifying Factors which may increase or decrease the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about.

382

Assessment
Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan. The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is: Rate of occurrence multiplied by the impact of the event equals risk

Composite Risk Index

The above formula can also be re-written in terms of a Composite Risk Index, as follows: Composite Risk Index = Impact of Risk event x Probability of Occurrence The impact of the risk event is assessed on a scale of 0 to 5, where 0 and 5 represent the minimum and maximum possible impact of an occurrence of a risk (usually in terms of financial losses). The probability of occurrence is likewise assessed on a scale from 0 to 5, where 0 represents a zero probability of the risk event actually occurring while 5 represents a 100% probability of occurrence. The Composite Index thus can take values ranging from 0 through 25, and this range is usually arbitrarily divided into three sub-ranges. The overall risk assessment is then Low, Medium or High, depending on the sub-range containing the calculated value of the Composite Index. For instance, the three sub-ranges could be defined as 0 to 8, 9 to 16 and 17 to 25. Note that the probability of risk occurrence is difficult to estimate since the past data on frequencies are not readily available, as mentioned above. Likewise, the impact of the risk is not easy to estimate since it is often difficult to estimate the potential financial loss in the event of risk occurrence. Further, both the above factors can change in magnitude depending on the adequacy of risk avoidance and prevention measures taken and due to changes in the external business environment. Hence it is absolutely necessary to periodically re-assess risks and intensify/relax mitigation measures as necessary.

Risk management

383

Risk Options
Risk mitigation measures are usually formulated according to one or more of the following major risk options, which are: 1. Design a new business process with adequate built-in risk control and containment measures from the start. 2. Periodically re-assess risks that are accepted in ongoing processes as a normal feature of business operations and modify mitigation measures. 3. Transfer risks to an external agency (e.g. an insurance company) 4. Avoid risks altogether (e.g. by closing down a particular high-risk business area) Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed. In business it is imperative to be able to present the findings of risk assessments in financial terms. Robert Courtney Jr. (IBM, 1970) proposed a formula for presenting risks in financial terms.[8] The Courtney formula was accepted as the official risk analysis method for the US governmental agencies. The formula proposes calculation of ALE (annualised loss expectancy) and compares the expected loss value to the security control implementation costs (cost-benefit analysis).

Potential risk treatments

Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:[9] Avoidance (eliminate, withdraw from or not become involved) Reduction (optimise - mitigate) Sharing (transfer - outsource or insure) Retention (accept and budget)

Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions. Another source, from the US Department of Defense, Defense Acquisition University, calls these categories ACAT, for Avoid, Control, Accept, or Transfer. This use of the ACAT acronym is reminiscent of another ACAT (for Acquisition Category) used in US Defense industry procurements, in which Risk Management figures prominently in decision making and planning. Risk avoidance This includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the Legal liability that comes with it. Another would be not be flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits.

Risk management Hazard Prevention Hazard prevention refers to the prevention of risks in an emergency. The first and most effective stage of hazard prevention is the elimination of hazards. If this takes too long, is too costly, or is otherwise impractical, the second stage is mitigation. Risk reduction Risk reduction or "optimisation" involves reducing the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy. Acknowledging that risks can be positive or negative, optimising risks means finding a balance between negative risk and the benefit of the operation or activity; and between risk reduction and effort applied. By an offshore drilling contractor effectively applying HSE Management in its organisation, it can optimise risk to achieve levels of residual risk that are tolerable.[10] Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration. Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks.[11] For example, a company may outsource only its software development, the manufacturing of hard goods, or customer support needs to another company, while handling the business management itself. This way, the company can concentrate more on business development without having to worry as much about the manufacturing process, managing the development team, or finding a physical location for a call center. Risk sharing Briefly defined as "sharing with another party the burden of loss or the benefit of gain, from a risk, and the measures to reduce a risk." The term of 'risk transfer' is often used in place of risk sharing in the mistaken belief that you can transfer a risk to a third party through insurance or outsourcing. In practice if the insurance company or contractor go bankrupt or end up in court, the original risk is likely to still revert to the first party. As such in the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage. Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group.

384

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

385

Create a risk management plan

Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For instance, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks. The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions. According to ISO/IEC 27001, the stage immediately after completion of the risk assessment phase consists of preparing a Risk Treatment Plan, which should document the decisions about how each of the identified risks should be handled. Mitigation of risks often means selection of security controls, which should be documented in a Statement of Applicability, which identifies which particular control objectives and controls from the standard have been selected, and why.

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

Review and evaluation of the plan

Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced. Risk analysis results and management plans should be updated periodically. There are two primary reasons for this: 1. to evaluate whether the previously selected security controls are still applicable and effective, and 2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.

Limitations
If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur but if the risk is unlikely enough to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur. Qualitative risk assessment is subjective and lacks consistency. The primary justification for a formal risk assessment process is legal and bureaucratic.

Risk management Prioritizing the risk management processes too highly could keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete. It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured by impacts x probability.

386

Areas of risk management

As applied to corporate finance, risk management is the technique for measuring, monitoring and controlling the financial or operational risk on a firm's balance sheet. See value at risk. The Basel II framework breaks risks into market risk (price risk), credit risk and operational risk and also specifies methods for calculating capital requirements for each of these components.

Enterprise risk management

In enterprise risk management, a risk is defined as a possible event or circumstance that can have negative influences on the enterprise in question. Its impact can be on the very existence, the resources (human and capital), the products and services, or the customers of the enterprise, as well as external impacts on society, markets, or the environment. In a financial institution, enterprise risk management is normally thought of as the combination of credit risk, interest rate risk or asset liability management, market risk, and operational risk. In the more general case, every probable risk can have a pre-formulated plan to deal with its possible consequences (to ensure contingency if the risk becomes a liability). From the information above and the average cost per employee over time, or cost accrual ratio, a project manager can estimate: the cost associated with the risk if it arises, estimated by multiplying employee costs per unit time by the estimated time lost (cost impact, C where C = cost accrual ratio * S). the probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs = P * S): Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest risks to the project to be attempted first so that risk is minimized as quickly as possible. This is slightly misleading as schedule variances with a large P and small S and vice versa are not equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the wrong time). the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P*C = P*CAR*S = P*S*CAR) sorting on this value puts the highest risks to the budget first. see concerns about schedule variance as this is a function of it, as illustrated in the equation above. Risk in a project or process can be due either to Special Cause Variation or Common Cause Variation and requires appropriate treatment. That is to re-iterate the concern about extremal cases not being equivalent in the list immediately above.

Risk management

387

Risk management activities as applied to project management

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

Risk management techniques in petroleum and natural gas

For the offshore oil and gas industry, operational risk management is regulated by the safety case regime in many countries. Hazard identification and risk assessment tools and techniques are described in the international standard ISO 17776:2000, and organisations such as the IADC (International Association of Drilling Contractors) publish guidelines for HSE Case development which are based on the ISO standard. Further, diagrammatic representations of hazardous events are often expected by governmental regulators as part of risk management in safety case submissions; these are known as bow-tie diagrams. The technique is also used by organisations and regulators in mining, aviation, health, defence, industrial and finance.[12]

Risk management and business continuity

Risk management is simply a practice of systematically selecting cost effective approaches for minimising the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks. Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented to deal with the consequences of realised residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc.). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk management's preemptive approach and assumes that the disaster will happen at some point.

Risk communication
Risk communication is a complex cross-disciplinary academic field. Problems for risk communicators involve how to reach the intended audience, to make the risk comprehensible and relatable to other risks, how to pay appropriate respect to the audience's values related to the risk, how to predict the audience's response to the communication, etc. A main goal of risk communication is to improve collective and individual decision making. Risk communication is somewhat related to crisis communication.

Risk management

388

Bow tie diagrams

A popular solution to the quest to communicate risks and their treatments effectively is to use bow tie diagrams. These have been effective, for example, in a public forum to model perceived risks and communicate precautions, during the planning stage of offshore oil and gas facilities in Scotland. Equally, the technique is used for HAZID (Hazard Identification) workshops of all types, and results in a high level of engagement. For this reason (amongst others) an increasing number of government regulators for major hazard facilities (MHFs), offshore oil & gas, aviation, etc. welcome safety case submissions which use diagrammatic representation of risks at their core. Communication advantages of bow tie diagrams: [12] Visual illustration of the hazard, its causes, consequences, controls, and how controls fail. The bow tie diagram can be readily understood at all personnel levels. "A picture paints a thousand words."

Seven cardinal rules for the practice of risk communication

(as first expressed by the U.S. Environmental Protection Agency and several of the field's founders[13] ) Accept and involve the public/other consumers as legitimate partners. Plan carefully and evaluate your efforts with a focus on your strengths, weaknesses, opprtunities, and threats. Listen to the public's specific concerns. Be honest, frank, and open. Coordinate and collaborate with other credible sources. Meet the needs of the media. Speak clearly and with compassion.

See also
Chief risk officer Environmental Risk Management Authority Event chain methodology Financial risk management Fuel price risk management Hazard and operability study International Risk Governance Council International Swaps and Derivatives Association ISO 31000 List of finance topics List of project management topics Managerial risk accounting Operational risk management Optimism bias Precautionary principle Process Safety Management Public Entity Risk Institute Reference class forecasting RiskAoA Risk homeostasis

Risk Management Agency Risk Management Authority Risk Management Information Systems

Risk management Risk Management Programme Risk management tools Risk register Roy's safety-first criterion Society for Risk Analysis Social risk management Social vulnerability Substantial equivalence Supply Chain Risk Management Vulnerability assessment

389

Further reading
Alberts, Christopher; Audrey Dorofee, Lisa Marino (March 2008). Mission Diagnostic Protocol, Version 1.0: A Risk-Based Approach for Assessing the Potential for Success [14]. Software Engineering Institute. Retrieved 2008-05-26. Alexander, Carol and Sheedy, Elizabeth (2005). The Professional Risk Managers' Handbook: A Comprehensive Guide to Current Theory and Best Practices. PRMIA Publications. ISBN0-9766097-0-3. Altemeyer, Lynn (2004). An Assessment of Texas State Government: Implementation of Enterprise Risk Management, Applied Research Project [15]. Texas State University. Borodzicz, Edward (2005). Risk, Crisis and Security Management. New York: Wiley. ISBN0-470-86704-3. Flyvbjerg, Bent (August 2006). "From Nobel Prize to Project Management: Getting Risks Right" [26] (PDF). Project Management Journal (Project Management Institute) 37 (3): 515. Retrieved 2008-05-26. Gorrod, Martin (2004). Risk Management Systems : Technology Trends (Finance and Capital Markets). Basingstoke: Palgrave Macmillan. ISBN1-4039-1617-9. Hutto, John (2009). Risk Management in Law Enforcement, Applied Research Project [16]. Texas State University. Institute of Risk Management/AIRMIC/ALARM (2002). A Risk Management Standard [17]. London: Institute of Risk Management. Moteff, John (2005) Risk Management and Critical Infrastructure Protection: Assessing, Integrating, and Managing Threats, Vulnerabilities and Consequences [18]. Washington DC: Congressional Research Service. (Report). Standards Association of Australia (1999). Risk management. North Sydney, N.S.W: Standards Association of Australia. ISBN0-7337-2647-X. Stoneburner, Gary; Goguen, Alice and Feringa, Alexis (July 2002) (PDF). Risk Management Guide for Information Technology Systems [9]. Gaithersburg, MD: National Institute of Standards and Technology. United States Environmental Protection Agency (April 2004). General Risk Management Program Guidance [19]. United State Environmental Protection Agency. Ward, Dan; Quaid, Chris (March/April 2007). "The Pursuit of Courage, Judgment and Luck" [20] (PDF). Defense AT&L (Defense Acquisition University): 2830. Retrieved 2008-05-26. Airmic / Alarm / IRM (2010) "A structured approach to Enterprise Risk Management (ERM) and the requirements of ISO 31000" http://www.theirm.org/documents/SARM_FINAL.pdf Hopkin, Paul "Fundamentals of Risk Management" Kogan-Page (2010) ISBN 978 0 7494 5942 0

Risk management

390

External links
Risk management [21] at the Open Directory Project Annotated Bibliography on Risk Management [22]

References
[1] Hubbard, Douglas (2009). The Failure of Risk Management: Why It's Broken and How to Fix It. John Wiley & Sons. p.46. [2] ISO/IEC Guide 73:2009 (2009). Risk management Vocabulary (http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_ics/ catalogue_detail_ics. htm?csnumber=44651). International Organization for Standardization. . [3] ISO/DIS 31000 (2009). Risk management Principles and guidelines on implementation (http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_tc/ catalogue_detail. htm?csnumber=43170). International Organization for Standardization. . [4] "Committee Draft of ISO 31000 Risk management" (http:/ / www. nsai. ie/ uploads/ file/ N047_Committee_Draft_of_ISO_31000. pdf) (PDF). International Organization for Standardization. . [5] CMU/SEI-93-TR-6 Taxonomy-based risk identification in software industry (http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 93tr006. cfm) [6] Common Vulnerability and Exposures list (http:/ / cve. mitre. org) [7] Crockford, Neil (1986). An Introduction to Risk Management (2 ed.). Cambridge, UK: Woodhead-Faulkner. p.18. ISBN0859413322. [8] Disaster Recovery Journal (http:/ / www. drj. com/ index. php?option=com_content& task=view& id=605& Itemid=450) [9] Dorfman, Mark S. (2007). Introduction to Risk Management and Insurance (9 ed.). Englewood Cliffs, N.J: Prentice Hall. ISBN0-13-224227-3. [10] IADC HSE Case Guidelines for MODUs 3.2, section 4.7 [11] Roehrig, P (2006). "Bet On Governance To Manage Outsourcing Risk" (http:/ / www. btquarterly. com/ ?mc=bet-governance& page=ss-viewresearch). Business Trends Quarterly. . [12] http:/ / www. bowtiexp. com. au/ bowtiexp. asp#aboutBowTies [13] Covello, Vincent T.; Allen., Frederick H. (April 1988). Seven Cardinal Rules of Risk Communication. Washington, DC: U.S. Environmental Protection Agency. OPA-87-020. [14] http:/ / www. sei. cmu. edu/ library/ abstracts/ reports/ 08tr005. cfm [15] http:/ / ecommons. txstate. edu/ arp/ 14/ [16] http:/ / ecommons. txstate. edu/ arp/ 301/ [17] http:/ / www. theirm. org/ publications/ PUstandard. html [18] http:/ / opencrs. com/ document/ RL32561/ 2005-02-04 [19] http:/ / www. epa. gov/ OEM/ content/ rmp/ rmp_guidance. htm#General [20] http:/ / www. dau. mil/ pubs/ dam/ 03_04_2007/ war_ma07. pdf [21] http:/ / www. dmoz. org/ Business/ Financial_Services/ Insurance/ Risk_Management/ [22] http:/ / www. daemon. be/ maarten/ riskannbib. html

International Organization for Standardization

391

International Organization for Standardization

International Organization for Standardization Organisation internationale de normalisation

Logo of ISO in English

list of members Formation Type Purpose/focus Headquarters Membership Officiallanguages Website 23 February 1947 NGO International standardization Geneva, Switzerland 165 members English, French and Russian www.iso.org
[1]

The International Organization for Standardization (French: Organisation internationale de normalisation), widely known as ISO (pronounced /aso/ EYE-soe), is an international-standard-setting body composed of representatives from various national standards organizations. Founded on 23 February 1947, the organization promulgates worldwide proprietary industrial and commercial standards. It has its headquarters in Geneva, Switzerland.[2] While ISO defines itself as a non-governmental organization, its ability to set standards that often become law, either through treaties or national standards, makes it more powerful than most non-governmental organizations. In practice, ISO acts as a consortium with strong links to governments.

Name and abbreviation

The organization's logos in two of its official languages, English and French, include the word ISO (pronounced /aso/), and it is usually referred to by this short-form name. ISO is not an acronym or initialism for the organization's full name in either official language. Rather, the organization adopted ISO based on the Greek word isos (), meaning equal. Recognizing that the organizations initials would be different in different languages, the organization's founders chose ISO as the universal short form of its name. This, in itself, reflects the aim of the organization: to equalize and standardize across cultures.[3] [4]

International Organization for Standardization

392

International Standards and other publications

ISO's main products are the International Standards. ISO also publishes Technical Reports, Technical Specifications, Publicly Available Specifications, Technical Corrigenda, and Guides.[5] [6] International Standards are identified in the format ISO[/IEC][/ASTM] [IS] nnnnn[:yyyy] Title, where nnnnn is the number of the standard, yyyy is the year published, and Title describes the subject. IEC for International Electrotechnical Commission is included if the standard results from the work of ISO/IEC JTC1 (the ISO/IEC Joint Technical Committee). ASTM (American Society for Testing and Materials) is used for standards developed in cooperation with ASTM International. The date and IS are not used for an incomplete or unpublished standard, and may under some circumstances be left off the title of a published work. Technical Reports are issued when "a technical committee or subcommittee has collected data of a different kind from that which is normally published as an International Standard".[5] such as references and explanations. The naming conventions for these are the same as for standards, except TR prepended instead of IS in the report's name. Examples: ISO/IEC TR 17799:2000 Code of Practice for Information Security Management ISO/TR 19033:2000 Technical product documentation Metadata for construction documentation Technical Specifications can be produced when "the subject in question is still under development or where for any other reason there is the future but not immediate possibility of an agreement to publish an International Standard". Publicly Available Specifications may be "an intermediate specification, published prior to the development of a full International Standard, or, in IEC may be a 'dual logo' publication published in collaboration with an external organization".[5] Both are named by convention similar to Technical Reports, for example: ISO/TS 16952-1:2006 Technical product documentation Reference designation system Part 1: General application rules ISO/PAS 11154:2006 Road vehicles Roof load carriers ISO sometimes issues a Technical Corrigendum. These are amendments to existing standards because of minor technical flaws, usability improvements, or to extend applicability in a limited way. Generally, these are issued with the expectation that the affected standard will be updated or withdrawn at its next scheduled review.[5] ISO Guides are meta-standards covering "matters related to international standardization".[5] They are named in the format "ISO[/IEC] Guide N:yyyy: Title", for example: ISO/IEC Guide 2:2004 Standardization and related activities General vocabulary ISO/IEC Guide 65:1996 General requirements for bodies operating product certification

Standardization process
A standard published by ISO/IEC is the last stage of a long process that commonly starts with the proposal of new work within a committee. Here are some abbreviations used for marking a standard with its status:[7] [8] [9] [10] [11]
[12] [13]

PWI - Preliminary Work Item NP or NWIP - New Proposal / New Work Item Proposal (e.g. ISO/IEC NP 23007) AWI - Approved new Work Item (e.g. ISO/IEC AWI 15444-14) WD - Working Draft (e.g. ISO/IEC WD 27032) CD - Committee Draft (e.g. ISO/IEC CD 23000-5) FCD - Final Committee Draft (e.g. ISO/IEC FCD 23000-12) DIS - Draft International Standard (e.g. ISO/IEC DIS 14297)

FDIS - Final Draft International Standard (e.g. ISO/IEC FDIS 27003) PRF - Proof of a new International Standard (e.g. ISO/IEC PRF 18018)

International Organization for Standardization IS - International Standard (e.g. ISO/IEC 13818-1:2007) Abbreviations used for amendments :[7] [8] [9] [10] [11] [12] [13] [14] NP Amd - New Proposal Amendment (e.g. ISO/IEC 15444-2:2004/NP Amd 3) AWI Amd - Approved new Work Item Amendment (e.g. ISO/IEC 14492:2001/AWI Amd 4) WD Amd - Working Draft Amendment (e.g. ISO 11092:1993/WD Amd 1) CD Amd / PDAmd - Committee Draft Amendment / Proposed Draft Amendment (e.g. ISO/IEC 13818-1:2007/CD Amd 6) FPDAmd / DAM (DAmd) - Final Proposed Draft Amendment / Draft Amendment (e.g. ISO/IEC 14496-14:2003/FPDAmd 1) FDAM (FDAmd) - Final Draft Amendment (e.g. ISO/IEC 13818-1:2007/FDAmd 4) PRF Amd - (e.g. ISO 12639:2004/PRF Amd 1) Amd - Amendment (e.g. ISO/IEC 13818-1:2007/Amd 1:2007

393

Other abbreviations :[12] [11] [15] [14] TR - Technical Report (e.g. ISO/IEC TR 19791:2006) DTR - Draft Technical Report (e.g. ISO/IEC DTR 19791) TS - Technical Specification (e.g. ISO/TS 16949:2009) DTS - Draft Technical Specification (e.g. ISO/DTS 11602-1) PAS - Publicly Available Specification TTA - Technology Trends Assessment (e.g. ISO/TTA 1:1994) IWA - International Workshop Agreement (e.g. IWA 1:2005) Cor - Technical Corrigendum (e.g. ISO/IEC 13818-1:2007/Cor 1:2008) Guide - a guidance to technical committees for the preparation of standards

International Standards are developed by ISO technical committees (TC) and subcommittees (SC) by a process with six steps:[9] [16] Stage 1: Proposal stage Stage 2: Preparatory stage Stage 3: Committee stage Stage 4: Enquiry stage Stage 5: Approval stage Stage 6: Publication stage

The TC/SC may set up working groups (WG) of experts for the preparation of a Working Drafts. Subcommittees may have several working groups, which can have several Sub Groups (SG).[17]

Stages in the development process of an ISO standard[8] [9] [10] [13] [16] [14]
Stage code 00 Stage Associated document name Abbreviations Description

Preliminary stage Proposal stage Preparatory stage

Preliminary work item

PWI

10 20

New work item proposal Working draft(s)

NP or NWIP, NP Amd/TR/TS/IWA AWI, AWI Amd/TR/TS, WD, WD Amd/TR/TS

30 40

Committee stage Committee draft(s) Enquiry stage Enquiry draft

CD, CD Amd/Cor/TR/TS, PDAmd (PDAM), PDTR, PDTS DIS, FCD, FPDAmd, DAmd (DAM), FPDISP, DTR, DTS (CDV in IEC)

International Organization for Standardization

394
FDIS, FDAmd (FDAM), PRF, PRF Amd/TTA/TR/TS/Suppl, FDTR ISO TR, TS, IWA, Amd, Cor ISO TR, TS, IWA, Amd, Cor

50

Approval stage

final draft International Standard

60 90 95

Publication stage International Standard Review stage Withdrawal stage

It is possible to omit certain stages, if there is a document with a certain degree of maturity at the start of a standardization project - for example a standard developed by another organization. ISO/IEC Directives allow also the so-called "Fast-track procedure". In this procedure a document is submitted directly for approval as a draft International Standard (DIS) to the ISO member bodies or as a final draft International Standard (FDIS) if the document was developed by an international standardizing body recognized by the ISO Council.[9] The first step - a proposal of work (New Proposal) is approved at the relevant subcommittee or technical committee (e.g. SC29 and JTC1 respectively in the case of Moving Picture Experts Group - ISO/IEC JTC1/SC29/WG11). A working group (WG) of experts is set up by the TC/SC for the preparation of a Working Draft. When the scope of a new work is sufficiently clarified, some of the working groups (e.g. MPEG) usually make open request for proposals - known as "Call for proposals". The first document that is produced for example for audio and video coding standards is called a Verification Model (VM) (previously also called a Simulation and Test Model). When a sufficient confidence in the stability of the standard under development is reached, a Working Draft (WD) is produced. This is in the form of a standard but is kept internal to working group for revision. When a Working Draft is sufficiently solid and the working group is satisfied that it has developed the best technical solution to the problem being addressed, it becomes Committee Draft (CD). If it is required, it is then sent to the P-members of the TC/SC (National Bodies) for ballot. The CD becomes Final Committee Draft (FCD) if the number of positive votes is above the quorum. Successive committee drafts may be considered until consensus is reached on the technical content. When it is reached, the text is finalized for submission as a draft International Standard (DIS). The text is then submitted to National Bodies for voting and comment within a period of five months. It is approved for submission as a final draft International Standard (FDIS) if a two-thirds majority of the P-members of the TC/SC are in favour and not more than one-quarter of the total number of votes cast are negative. ISO will then hold a ballot with National Bodies where no technical changes are allowed (yes/no ballot), within a period of two months. It is approved as an International Standard (IS) if a two-thirds majority of the P-members of the TC/SC is in favour and not more than one-quarter of the total number of votes cast are negative. After approval, only minor editorial changes are introduced into the final text. The final text is sent to the ISO Central Secretariat which publishes it as the International Standard.[7] [9]

ISO document copyright

ISO documents are copyrighted and ISO charges for copies of most. ISO does not, however, charge for most draft copies of documents in electronic format. Although useful, care must be taken using these drafts as there is the possibility of substantial change before it becomes finalized as a standard. Some standards by ISO and its official U.S. representative (and the International Electrotechnical Commission's via the U.S. National Committee) are made freely available.[18] [19]

International Organization for Standardization

395

Members
ISO has 163 national members,[20] out of the 203 total countries in the world. ISO has three membership categories: Member bodies are national bodies that are considered to be the most representative standards body in each country. These are the only members of ISO that have voting rights. Correspondent members are Key: countries that do not have their own members correspondent members subscriber members other places with an ISO 3166-1 code who aren't members of ISO standards organization. These members are informed about ISO's work, but do not participate in standards promulgation. Subscriber members are countries with small economies. They pay reduced membership fees, but can follow the development of standards. Participating members are called "P" members as opposed to observing members which are called "O" members.
A map of standards bodies who are ISO members

Products named after ISO

The fact that many of the ISO-created standards are ubiquitous has led, on occasion, to common use of "ISO" to describe the actual product that conforms to a standard. Some examples of this are: CD images end in the file extension "ISO" to signify that they are using the ISO 9660 standard filesystem as opposed to another file system - hence CD images are commonly referred to as "ISOs". Virtually all computers with CD-ROM drives can read CDs that use this standard. Some DVD-ROMs also use ISO 9660 filesystems. Photographic film's sensitivity to light, its "film speed," is described by ISO 5800:1987. Hence, the film's speed is often referred to as its "ISO number."

ISO/IEC Joint Technical Committee 1

To deal with the consequences of substantial overlap in areas of standardization and work related to information technology, ISO and IEC formed a Joint Technical Committee known as the ISO/IEC JTC1. It was the first such joint committee. The second joint committee was created in 2009 - Joint Project Committee - Energy efficiency and renewable energy sources - Common terminology (ISO/IEC/JTC 2).[21]

IWA document
Like ISO/TS, International Workshop Agreement (IWA) is another armoury of ISO for providing rapid response to requirements for standardization in areas where the technical structures and expertise are not currently in place . The utility harmonizes technical urgency industrial wide.

International Organization for Standardization

396

Criticism
With the exception of a small number of isolated standards,[22] ISO standards are normally not available free of charge, but for a purchase fee,[23] which has been seen by some as too expensive for small Open source projects.[24] The ISO/IEC JTC1 fast-track procedures ("Fast-track" as used by OOXML and "PAS" as used by OpenDocument) have garnered criticism in relation to the standardization of Office Open XML (ISO/IEC 29500). Martin Bryan, outgoing Convenor of ISO/IEC JTC1/SC34 WG1, is quoted as saying: I would recommend my successor that it is perhaps time to pass WG1s outstanding standards over to OASIS, where they can get approval in less than a year and then do a PAS submission to ISO, which will get a lot more attention and be approved much faster than standards currently can be within WG1. The disparity of rules for PAS, Fast-Track and ISO committee generated standards is fast making ISO a laughing stock in IT circles. The days of open standards development are fast disappearing. Instead we are getting 'standardization by corporation'.[25] Computer security entrepreneur and Ubuntu investor, Mark Shuttleworth, commented on the Standardization of Office Open XML process by saying I think it de-values the confidence people have in the standards setting process, and Shuttleworth alleged that ISO did not carry out its responsibility. He also noted that Microsoft had intensely lobbied many countries that traditionally had not participated in ISO and stacked technical committees with Microsoft employees, solution providers and resellers sympathetic to Office Open XML. When you have a process built on trust and when that trust is abused, ISO should halt the process ... ISO is an engineering old boys club and these things are boring so you have to have a lot of passion then suddenly you have an investment of a lot of money and lobbying and you get artificial results. The process is not set up to deal with intensive corporate lobbying and so you end up with something being a standard that is not clear.[26]

See also
American National Standards Institute (ANSI) ISO divisions Deutsches Institut fr Normung, German Institute for Standardization (DIN) British Standards Institution (BSI) Countries in International Organization for Standardization Canadian Standards Association European Committee for Standardization (CEN) Commonwealth of Independent States (CIS) set of standards (GOST) International Classification for Standards International Electrotechnical Commission (IEC) and ISO/IEC standards International healthcare accreditation International Telecommunication Union (ITU) ISO A4 ISO country code ISO/TC 37 ISO/TC 68 TC 46/SC 9 ISO/TC 211 ISO/TC 215 ISO/TC 223

Standardization Standards Australia Standards organization Terminology planning policy The International Customer Service Institute (TICSI) CARICOM Regional Organisation for Standards and Quality (CROSQ) AP Stylebook (Associated Press Style) Interface 2010 (Interface Marketing Supplier Integration Institute)

International Organization for Standardization

List of ISO standards List of ISO guides

397

External links
Official website [27] (free access to the catalogue of standards only, not to the contents) Publicly Available Standards [28] (free access to a small subset of the standards) ISO/TC 37 "Terminology and other language and content resources", a fundamental committee for all ISO standardization projects ISO/IEC JTC1 [29] ISO Advanced search for standards and/or projects [30] ISO Concept Database [31] (terminology database of ISO standards)

References
[1] [2] [3] [4] http:/ / www. iso. org/ "Discover ISO Meet ISO" (http:/ / www. iso. org/ iso/ about/ discover-iso_meet-iso. htm). ISO. 2007. . Retrieved 7 September 2007. "ISO's name" (http:/ / www. iso. org/ iso/ en/ networking/ pr/ isoname/ isoname. html). ISO. 2007. . Retrieved 7 September 2007. "Discover ISO ISO's name" (http:/ / www. iso. org/ iso/ about/ discover-iso_meet-iso/ discover-iso_isos-name. htm). ISO. 2007. . Retrieved 7 September 2007. [5] The ISO directives are published in two distinct parts: * "ISO Directives, Part 2: Rules for the structure and drafting of International Standards. 5th Edition" (http:/ / www. iec. ch/ tiss/ iec/ Directives-Part2-Ed5. pdf) (pdf). ISO/IEC. 2004. . Retrieved 7 September 2007. [6] ISO. "ISO/IEC Directives and ISO supplement" (http:/ / www. iso. org/ directives). . Retrieved 1 January 2010. [7] "About MPEG" (http:/ / mpeg. chiariglione. org/ about_mpeg. htm). chiariglione.org. . Retrieved 13 December 2009. [8] ISO. "International harmonized stage codes" (http:/ / www. iso. org/ iso/ standards_development/ processes_and_procedures/ stages_description/ stages_table. htm#s90). . Retrieved 31 December 2009. [9] ISO. "Stages of the development of International Standards" (http:/ / www. iso. org/ iso/ standards_development/ processes_and_procedures/ stages_description. htm). . Retrieved 31 December 2009. [10] "The ISO27k FAQ - ISO/IEC acronyms and committees" (http:/ / www. iso27001security. com/ html/ faq. html#Acronyms). IsecT Ltd.. . Retrieved 31 December 2009. [11] ISO (2007). "ISO/IEC Directives Supplement Procedures specific to ISO" (http:/ / www. astm. org/ COMMIT/ 1st_Supplement. pdf) (PDF). . Retrieved 31 December 2009. [12] ISO (2007). "List of abbreviations used throughout ISO Online" (http:/ / www. iso. org/ iso/ support/ faqs/ faqs_list_abbreviations. htm). . Retrieved 31 December 2009. [13] "US TAG COMMITTEE HANDBOOK" (http:/ / www. sae. org/ exdomains/ standardsdev/ global_resources/ US TAG Committe Handbook 6March2008. doc) (DOC). 2008-03. . Retrieved 1 January 2010. [14] ISO/IEC JTC1 (2 November 2009), Letter Ballot on the JTC 1 Standing Document on Technical Specifications and Technical Reports (http:/ / isotc. iso. org/ livelink/ livelink/ JTC001-N-9876. pdf?func=doc. Fetch& nodeId=8498789& docTitle=JTC001-N-9876), , retrieved 1 January 2010 [15] ISO. "ISO deliverables" (http:/ / www. iso. org/ iso/ standards_development/ processes_and_procedures/ deliverables. htm). . Retrieved 9 April 2010. [16] ISO (2008) (PDF), ISO/IEC Directives, Part 1 - Procedures for the technical work, Sixth edition, 2008 (http:/ / www. iec. ch/ tiss/ iec/ Directives-Part1-Ed6. pdf), , retrieved 1 January 2010 [17] ISO, IEC (5 November 2009). "ISO/IEC JTC 1/SC 29, SC 29/WG 11 Structure (ISO/IEC JTC 1/SC 29/WG 11 - Coding of Moving Pictures and Audio)" (http:/ / www. itscj. ipsj. or. jp/ sc29/ 29w12911. htm). . Retrieved 7 November 2009. [18] "Freely Available ISO Standards" (http:/ / isotc. iso. org/ livelink/ livelink/ fetch/ 2000/ 2489/ Ittf_Home/ PubliclyAvailableStandards. htm). ISO. Last updated 2007-08-08. . Retrieved 7 September 2007. [19] "Free ANSI Standards" (http:/ / webstore. ansi. org/ ansidocstore/ free_standards. asp). . Retrieved 19 June 2007. [20] "General information on ISO" (http:/ / www. iso. org/ iso/ support/ faqs/ faqs_general_information_on_iso. htm). ISO. 2009. . Retrieved 29 January 2009. [21] "ISO/IEC/JTC 2 - Joint Project Committee - Energy efficiency and renewable energy sources - Common terminology" (http:/ / www. iso. org/ iso/ standards_development/ technical_committees/ list_of_iso_technical_committees/ iso_technical_committee. htm?commid=585141). . Retrieved 1 January 2010. [22] "Freely Available Standards" (http:/ / standards. iso. org/ ittf/ PubliclyAvailableStandards/ index. html). ISO. . Retrieved 26 April 2008. [23] "Shopping FAQs" (http:/ / www. iso. org/ iso/ store/ shopping_faqs. htm). ISO. . Retrieved 26 April 2008.

International Organization for Standardization

[24] Jelliffe, Rick (1 August 2007). "Where to get ISO Standards on the Internet free" (http:/ / www. oreillynet. com/ xml/ blog/ 2007/ 08/ where_to_get_iso_standards_on. html). oreillynet.com. . Retrieved 26 April 2008. "The lack of free online availability has effectively made ISO standard irrelevant to the (home/hacker section of the) Open Source community" [25] "Report on WG1 activity for December 2007 Meeting of ISO/IEC JTC1/SC34/WG1 in Kyoto" (http:/ / www. jtc1sc34. org/ repository/ 0940. htm). iso/jtc1 sc34. 29 November 2007. . [26] "Ubuntus Shuttleworth blames ISO for OOXMLs win" (http:/ / blogs. zdnet. com/ open-source/ ?p=2222). ZDNet.com. 1 April 2008. . [27] http:/ / www. iso. org [28] http:/ / standards. iso. org/ ittf/ PubliclyAvailableStandards/ index. html [29] http:/ / www. jtc1. org/ [30] http:/ / www. iso. org/ iso/ search/ extendedsearchstandards. htm?formKeyword=& displayForm=true& published=true [31] http:/ / cdb. iso. org

398

Change control
Change control within Quality management systems (QMS) and Information Technology (IT) systems is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change. Change control is currently used in a wide variety of products and systems. For Information Technology (IT) systems it is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating systems, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure. Certain portions of the Information Technology Infrastructure Library cover change control.

The process
There is considerable overlap and confusion between change management, configuration management and change control. The definition below is not yet integrated with definitions of the others. Certain experts describe change control as a set of six steps: 1. 2. 3. 4. 5. 6. Record / Classify Assess Plan Build / Test Implement Close / Gain Acceptance

Record/classify
The client initiates change by making a formal request for something to be changed. The change control team then records and categorizes that request. This categorization would include estimates of importance, impact, and complexity.

Assess
The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and to the process, and follow this by making a judgment on who should carry out the change. If the change requires more than one type of assessment, the head of the change control team will consolidate these. Everyone with a stake in the change then must meet to determine whether there is a business or

Change control technical justification for the change. The change is then sent to the delivery team for planning.

399

Plan
Management will assign the change to a specific delivery team, usually one with the specific role of carrying out this particular type of change. The team's first job is to plan the change in detail as well as construct a regression plan in case the change needs to be backed out.

Build/test
If all stakeholders agree with the plan, the delivery team will build the solution, which will then be tested. They will then seek approval and request a time and date to carry out the implementation phase.

Implement
All stakeholders must agree to a time, date and cost of implementation. Following implementation, it is usual to carry out a post-implementation review which would take place at another stakeholder meeting.

Close/gain acceptance
When the client agrees that the change was implemented correctly, the change can be closed.

Regulatory environment
In a Good Manufacturing Practice regulated industry, the topic is frequently encountered by its users. Various industrial guidances and commentaries are available for people to comprehend this concept.[1] [2] [3] As a common practice, the activity is usually directed by one or more SOPs.[4] From the information technology perspective for clinical trials, it has been guided by another USFDA document.[5]

See also
Documentation Identifier Revision control Living Document Specification (technical standard) Standard

External links
Change control minimizes outages [6] Change Control related diagrams [7] Example of change control [8] How to Control Change Requests (Project Management) [9]

References
[1] "Guidance for Industry: Quality Systems Approach to Pharmaceutical CGMP Regulations" (http:/ / www. fda. gov/ downloads/ Drugs/ GuidanceComplianceRegulatoryInformation/ Guidances/ UCM070337. pdf) (PDF). U.S. Food and Drug Administration. September 2006. . Retrieved 12 July 2009. [2] Infusion. "Challenges of Change Control in a Regulated Industry" (http:/ / www. infinityqs. com/ asset-library/ articles/ ChangeControlChallenges. pdf). . Retrieved 28 April 2009.

Change control
[3] ICH. "Q7: Good Manufacturing Practice Guide for Active Pharmaceutical Ingredients" (http:/ / www. ich. org/ cache/ compo/ 363-272-1. html#Q7A). . Retrieved 28 April 2009. [4] GMP Online Consultancy. "Change control system: Standard Operating Procedure" (http:/ / www. gmp-online-consultancy. com/ e/ html/ 301_direct_order/ 210_standard-operation-procedures_detail. php?docIndex=60). . Retrieved 28 April 2009. [5] "Guidance for Industry: Computerized Systems Used in Clinical Trials" (http:/ / www. fda. gov/ downloads/ ICECI/ EnforcementActions/ BioresearchMonitoring/ UCM133749. pdf) (PDF). U.S. Food and Drug Administration. April 1999. . Retrieved 12 July 2009. [6] http:/ / www. networkworld. com/ news/ tech/ 2006/ 091806-tech-update-change-control. html?page=1 [7] http:/ / mwiki. kostigoff. net/ index. php?title=Methodology::_Change_Control [8] http:/ / www. vidbob. com/ qa-info/ change-control-process. html [9] http:/ / www. pmhut. com/ how-to-control-change-requests

400

Project management software

Project management software is a term covering many types of software, including scheduling, cost control and budget management, resource allocation, collaboration software, communication, quality management and documentation or administration systems, which are used to deal with the complexity of large projects.

Tasks or activities of project management software

Scheduling
One of the most common purposes is to schedule a series of events or tasks and the complexity of the schedule can vary considerably depending on how the tool is used. Some common challenges include: Events which depend on one another in different ways or dependencies Scheduling people to work on, and resources required by, the various tasks commonly termed resource scheduling Dealing with uncertainties in the estimates of the duration of each task

Microsoft Project 2000, showing a Gantt chart

Calculating critical path

SEER-SEM, entering project parameters In many complex schedules, there will be a critical path, or series of events that depend on each other, and whose durations directly determine the length of the whole project (see also critical chain). Some software applications (for example, Dependency Structure Matrix solutions) can highlight these tasks, which are often a good candidate for any optimization effort.

Project management software

401

Providing information
Project planning software can be expected to provide information to various people or stakeholders, and can be used to measure and justify the level of effort required to complete the project(s). Typical requirements might include: Tasks lists for people, and allocation schedules for resources Overview information on how long tasks will take to complete Early warning of any risks to the project Information on workload, for planning holidays Evidence Historical information on how projects have progressed, and in particular, how actual and planned performance are related Optimum utilization of available resource

Approaches to project management software

Desktop
Project management software can be implemented as a program that runs on the desktop of each user. This typically gives the most responsive and graphically-intense style of interface. Desktop applications typically store their data in a file, although some have the ability to collaborate with other users (see below), or to store their data in a central database. Even a file-based project plan can be shared between users if it's on a networked drive and only one user accesses it at a time. Desktop applications can be written to run in a heterogeneous environment of multiple operating systems, although it's unusual.

Web-based
Project management software can be implemented as a Web application, accessed through an intranet, or an extranet using a web browser. This has all the usual advantages and disadvantages of web applications: Can be accessed from any type of computer without installing software on user's computer Ease of access-control Naturally multi-user Only one software version and installation to maintain Centralized data repository Typically slower to respond than desktop applications Project information not available when the user (or server) is offline Some solutions allow the user to go offline with a copy of the data

Project management software

402

Personal
A personal project management application is one used at home, typically to manage lifestyle or home projects. There is considerable overlap with single user systems, although personal project management software typically involves simpler interfaces. See also non-specialised tools below.

Single user
A single-user system is programmed with the assumption that only one person will ever need to edit the project plan at once. This may be used in small companies, or ones where only a few people are involved in top-down project planning. Desktop applications generally fall into this category.

Collaborative
A collaborative system is designed to support multiple users modifying different sections of the plan at once; for example, updating the areas they personally are responsible for such that those estimates get integrated into the overall plan. Web-based tools, including extranets, generally fall into this category, but have the limitation that they can only be used when the user has live Internet access. To address this limitation, some software tools using clientserver architecture provide a rich client that runs on users' desktop computer and replicate project and task information to other project team members through a central server when users connect periodically to the network. Some tools allow team members to check out their schedules (and others' as read only) to work on them while not on the network. When reconnecting to the database, all changes are synchronized with the other schedules.

Integrated
An integrated system combines project management or project planning, with many other aspects of company life. For example, projects can have bug tracking issues assigned to each project, the list of project customers becomes a customer relationship management module, and each person on the project plan has their own task lists, calendars, and messaging functionality associated with their projects. Similarly, specialised tools like SourceForge integrate project management software with source control (CVS) software and bug-tracking software, so that each piece of information can be integrated into the same system.

Criticisms of project management software

The following may apply in general, or to specific products, or to some specific functions within products. May not be derived from a sound project management method. For example, displaying the Gantt chart view by default encourages users to focus on timed task scheduling too early, rather than identifying objectives, deliverables and the imposed logical progress of events (dig the trench first to put in the drain pipe). May be inconsistent with the type of project management method. For example, traditional (e.g. Waterfall) vs. agile (e.g. Scrum). Focuses primarily on the planning phase and does not offer enough functionality for project tracking, control and in particular plan-adjustment. There may be excessive dependency on the first paper print-out of a project plan, which is simply a snapshot at one moment in time. The plan is dynamic; as the project progresses the plan must change to accommodate tasks that are completed early, late, re-sequenced, etc. Good management software should not only facilitate this, but assist with impact assessment and communication of plan changes. Does not make a clear distinction between the planning phase and post planning phase, leading to user confusion and frustration when the software does not behave as expected. For example, shortening the duration of a task when an additional human resource is assigned to it while the project is still being planned. Offer complicated features to meet the needs of project management or project scheduling professionals, which must be understood in order to effectively use the product. Additional features may be so complicated as to be of

Project management software no use to anyone. Complex task prioritization and resource leveling algorithms for example can produce results that make no intuitive sense, and overallocation is often more simply resolved manually. Some people may achieve better results using simpler technique, (e.g. pen and paper), yet feel pressured into using project management software by company policy (discussion [1]). Similar to PowerPoint, project management software might shield the manager from important interpersonal contact. New types of software are challenging the traditional definition of Project Management. Frequently, users of project management software are not actually managing a discrete project. For instance, managing the ongoing marketing for an already-released product is not a "project" in the traditional sense of the term; it does not involve management of discrete resources working on something with a discrete beginning/end. Groupware applications now add "project management" features that directly support this type of workflow-oriented project management. Classically-trained Project Managers may argue whether this is "sound project management." However, the end-users of such tools will refer to it as such, and the de-facto definition of the term Project Management may change. When there are multiple larger projects, project management software can be very useful. Nevertheless, one should probably not use management software if only a single small project is involved, as management software incurs a larger time-overhead than is worthwhile.

403

See also
Comparison of project management software Program Evaluation and Review Technique Project planning Project accounting Project Portfolio Management RiskAoA

Books
Eric Uyttewaal: Dynamic Scheduling With Microsoft(r) Project 2000: The Book By and For Professionals, ISBN 0-9708276-0-1 George Suhanic: Computer-Aided Project Management, ISBN 0-19-511591-0 Richard E. Westney: Computerized Management of Multiple Small Projects, ISBN 0-8247-8645-9

References
[1] http:/ / www. edwardtufte. com/ bboard/ q-and-a-fetch-msg?msg_id=00008c& topic_id=1& topic=

Business

404

Business
A business (company, enterprise or firm) is a legally recognized organization designed to provide goods and/or services to consumers, businesses and governmental entities.[1] Businesses are predominant in capitalist economies. Most businesses are privately owned. A business is typically formed to earn profit that will increase the wealth of its owners and grow the business itself. The owners and operators of a business have as one of their main objectives the receipt or generation of a financial return in exchange for work and acceptance of risk. Notable exceptions include cooperative enterprises and state-owned enterprises. Businesses can also be formed not-for-profit or be state-owned. The etymology of "business" relates to the state of being busy either as an individual or society as a whole, doing commercially viable and profitable work. The term "business" has at least three usages, depending on the scope the singular usage (above) to mean a particular company or corporation, the generalized usage to refer to a particular market sector, such as "the music business" and compound forms such as agribusiness, or the broadest meaning to include all activity by the community of suppliers of goods and services. However, the exact definition of business, like much else in the philosophy of business, is a matter of debate and complexity of meanings.

Basic forms of ownership

Although forms of business ownership vary by jurisdiction, there are several common forms: Sole proprietorship: A sole proprietorship is a business owned by one person. The owner may operate on his or her own or may employ others. The owner of the business has personal liability of the debts incurred by the business. Partnership: A partnership is a form of business in which two or more people operate for the common goal which is often making profit. In most forms of partnerships, each partner has personal liability of the debts incurred by the business. There are three typical classifications of partnerships: general partnerships, limited partnerships, and limited liability partnerships. Corporation: A corporation is either a limited or unlimited liability entity that has a separate legal personality from its members. A corporation can be organized for-profit or not-for-profit. A corporation is owned by multiple shareholders and is overseen by a board of directors, which hires the business's managerial staff. In addition to privately owned corporate models, there are state-owned corporate models. Cooperative: Often referred to as a "co-op", a cooperative is a limited liability entity that can organize for-profit or not-for-profit. A cooperative differs from a corporation in that it has members, as opposed to shareholders, who share decision-making authority. Cooperatives are typically classified as either consumer cooperatives or worker cooperatives. Cooperatives are fundamental to the ideology of economic democracy. For a country-by-country listing of legally recognized business forms, see Types of business entity.

Business

405

Classifications
There are many types of businesses, and because of this, businesses are classified in many ways. One of the most common focuses on the primary profit-generating activities of a business: Agriculture and mining businesses are concerned with the production of raw material, such as plants or minerals. Financial businesses include banks and other companies that generate profit through investment and management of capital. Information businesses generate profits primarily from the resale of intellectual property and include movie studios, publishers and packaged software companies. Manufacturers produce products, from raw materials or component parts, which they then sell at a profit. Companies that make physical goods, such as cars or pipes, are considered manufacturers.

Wall Street, Manhattan is the location of the New York Stock Exchange and is often used as a symbol for the world of business.

Real estate businesses generate profit from the selling, renting, and development of properties, homes, and buildings. Retailers and Distributors act as middle-men in getting goods produced by manufacturers to the intended consumer, generating a profit as a result of providing sales or distribution services. Most consumer-oriented stores and catalogue companies are distributors or retailers. See also: Franchising Service businesses offer intangible goods or services and typically generate a profit by charging for labor or other services provided to government, other businesses, or consumers. Organizations ranging from house decorators to consulting firms, restaurants, and even entertainers are types of service businesses. Transportation businesses deliver goods and individuals from location to location, generating a profit on the transportation costs Utilities produce public services, such as heat, electricity, or sewage treatment, and are usually government chartered. There are many other divisions and subdivisions of businesses. The authoritative list of business types for North America is generally considered to be the North American Industry Classification System, or NAICS. The equivalent European Union list is the NACE.

Management
The efficient and effective operation of a business, and study of this subject, is called management. The main branches of management are financial management, marketing management, human resource management, strategic management, production management, service management and information technology management.

Reforming State Enterprises

In recent decades, assets and enterprises that were run by various states have been modeled after business enterprises. In 2003, the People's Republic of China reformed 80% of its state-owned enterprises and modeled them on a company-type management system.[2] Many state institutions and enterprises in China and Russia have been transformed into joint-stock companies, with part of their shares being listed on public stock markets.

Business

406

Government regulation
Most legal jurisdictions specify the forms of ownership that a business can take, creating a body of commercial law for each type.

Organizing
The major factors affecting how a business is organized are usually: The size and scope of the business, and its anticipated management and ownership. Generally a smaller business is more flexible, while larger businesses, or those with wider ownership or more formal structures, will usually tend to be organized as partnerships or (more commonly) corporations. In addition a business that wishes to raise money on a stock market or to be owned by a wide range of people will often be required to adopt a specific legal form to do so. The sector and country. Private profit making businesses are different from government owned bodies. In some countries, certain businesses are legally obliged to be organized in certain ways.

The Bank of England in Threadneedle Street, London, England.

Limited liability. Corporations, limited liability partnerships, and other specific types of business organizations protect their owners or shareholders from business failure by doing business under a separate legal entity with certain legal protections. In contrast, unincorporated businesses or persons working on their own are usually not so protected. Tax advantages. Different structures are treated differently in tax law, and may have advantages for this reason. Disclosure and compliance requirements. Different business structures may be required to make more or less information public (or reported to relevant authorities), and may be bound to comply with different rules and regulations. Many businesses are operated through a separate entity such as a corporation or a partnership (either formed with or without limited liability). Most legal jurisdictions allow people to organize such an entity by filing certain charter documents with the relevant Secretary of State or equivalent and complying with certain other ongoing obligations. The relationships and legal rights of shareholders, limited partners, or members are governed partly by the charter documents and partly by the law of the jurisdiction where the entity is organized. Generally speaking, shareholders in a corporation, limited partners in a limited partnership, and members in a limited liability company are shielded from personal liability for the debts and obligations of the entity, which is legally treated as a separate "person." This means that unless there is misconduct, the owner's own possessions are strongly protected in law, if the business does not succeed. Where two or more individuals own a business together but have failed to organize a more specialized form of vehicle, they will be treated as a general partnership. The terms of a partnership are partly governed by a partnership agreement if one is created, and partly by the law of the jurisdiction where the partnership is located. No paperwork or filing is necessary to create a partnership, and without an agreement, the relationships and legal rights of the partners will be entirely governed by the law of the jurisdiction where the partnership is located. A single person who owns and runs a business is commonly known as a sole proprietor, whether he or she owns it directly or through a formally organized entity. A few relevant factors to consider in deciding how to operate a business include:

Business 1. General partners in a partnership (other than a limited liability partnership), plus anyone who personally owns and operates a business without creating a separate legal entity, are personally liable for the debts and obligations of the business. 2. Generally, corporations are required to pay tax just like "real" people. In some tax systems, this can give rise to so-called double taxation, because first the corporation pays tax on the profit, and then when the corporation distributes its profits to its owners, individuals have to include dividends in their income when they complete their personal tax returns, at which point a second layer of income tax is imposed. 3. In most countries, there are laws which treat small corporations differently than large ones. They may be exempt from certain legal filing requirements or labor laws, have simplified procedures in specialized areas, and have simplified, advantageous, or slightly different tax treatment. 4. To "go public" (sometimes called IPO) -- which basically means to allow a part of the business to be owned by a wider range of investors or the public in generalyou must organize a separate entity, which is usually required to comply with a tighter set of laws and procedures. Most public entities are corporations that have sold shares, but increasingly there are also public LLCs that sell units (sometimes also called shares), and other more exotic entities as well (for example, REITs in the USA, Unit Trusts in the UK). However, you cannot take a general partnership "public."

407

Commercial law
Most commercial transactions are governed by a very detailed and well-established body of rules that have evolved over a very long period of time, it being the case that governing trade and commerce was a strong driving force in the creation of law and courts in Western civilization. As for other laws that regulate or impact businesses, in many countries it is all but impossible to chronicle them all in a single reference source. There are laws governing treatment of labor and generally relations with employees, safety and protection issues (Health and Safety), anti-discrimination laws (age, gender, disabilities, race, and in some jurisdictions, sexual orientation), minimum wage laws, union laws, workers compensation laws, and annual vacation or working hours time. In some specialized businesses, there may also be licenses required, either due to special laws that govern entry into certain trades, occupations or professions, which may require special Offices in the Los Angeles Downtown Financial education, or by local governments. Professions that require District special licenses range from law and medicine to flying airplanes to selling liquor to radio broadcasting to selling investment securities to selling used cars to roofing. Local jurisdictions may also require special licenses and taxes just to operate a business without regard to the type of business involved. Some businesses are subject to ongoing special regulation. These industries include, for example, public utilities, investment securities, banking, insurance, broadcasting, aviation, and health care providers. Environmental regulations are also very complex and can impact many kinds of businesses in unexpected ways.

Business

408

Capital
When businesses need to raise money (called 'capital'), more laws come into play. A highly complex set of laws and regulations govern the offer and sale of investment securities (the means of raising money) in most Western countries. These regulations can require disclosure of a lot of specific financial and other information about the business and give buyers certain remedies. Because "securities" is a very broad term, most investment transactions will be potentially subject to these laws, unless a special exemption is available. Capital may be raised through private means, by public offer (IPO) on a stock exchange, or in many other ways. Major stock exchanges include the Shanghai Stock Exchange, Singapore Exchange, Hong Kong Stock Exchange, New York Stock Exchange and Nasdaq (USA), the London Stock Exchange (UK), the Tokyo Stock Exchange (Japan), and so on. Most countries with capital markets have at least one.

Business that have gone "public" are subject to extremely detailed and complicated regulation about their internal governance (such as how executive officers' compensation is determined) and when and how information is disclosed to the public and their shareholders. In the United States, these regulations are primarily implemented and enforced by the United States Securities and Exchange Commission (SEC). Other Western nations have comparable regulatory bodies. The regulations are implemented and enforced by the China Securities Regulation Commission (CSRC), in China. In Singapore, the regulation authority is Monetary Authority of Singapore (MAS), and in Hong Kong, it is Securities and Futures Commission (SFC). As noted at the beginning, it is impossible to enumerate all of the types of laws and regulations that impact on business today. In fact, these laws have become so numerous and complex, that no business lawyer can learn them all, forcing increasing specialization among corporate attorneys. It is not unheard of for teams of 5 to 10 attorneys to be required to handle certain kinds of corporate transactions, due to the sprawling nature of modern regulation. Commercial law spans general corporate law, employment and labor law, healthcare law, securities law, M&A law (who specialize in acquisitions), tax law, ERISA law (ERISA in the United States governs employee benefit plans), food and drug regulatory law, intellectual property law (specializing in copyrights, patents, trademarks and such), telecommunications law, and more. In Thailand, for example, it is necessary to register a particular amount of capital for each employee, and pay a fee to the government for the amount of capital registered. There is no legal requirement to prove that this capital actually exists, the only requirement is to pay the fee. Overall, processes like this are detrimental to the development and GDP of a country, but often exist in "feudal" developing countries.

Mexican Stock Exchange in Paseo de la Reforma, Mexico City

Intellectual property
Businesses often have important "intellectual property" that needs protection from competitors for the company to stay profitable. This could require patents or copyrights or preservation of trade secrets. Most businesses have names, logos and similar branding techniques that could benefit from trademarking. Patents and copyrights in the United States are largely governed by federal law, while trade secrets and trademarking are mostly a matter of state law. Because of the nature of intellectual property, a business needs protection in every jurisdiction in which they are concerned about competitors. Many countries are signatories to international treaties concerning intellectual property, and thus companies registered in these countries are subject to national laws bound by these treaties.

Business

409

Exit plans
Businesses can be bought and sold. Business owners often refer to their plan of disposing of the business as an "exit plan." Common exit plans include IPOs, MBOs and mergers with other businesses. Businesses are rarely liquidated, as it is often very unprofitable to do so.

See also
Accounting List of accounting topics Government ownership Human Resources Big business Business acumen Business broker Business ethics List of business ethics, political economy, and philosophy of business topics Social responsibility International trade Business mediator Business schools Business trip Capitalism List of international trade topics List of human resource management topics Franchising

Advertising Banking

Industry Insurance Intellectual property Interim Management

Business hours

Investment Limited liability List of oldest companies Management List of management topics

Change management analyst

Management information systems List of information technology management topics

Commerce List of business law topics

Manufacturing List of production topics

Company

Marketing List of marketing topics

Corporate law Corporation Cooperative Cost overrun

Money Organizational studies Partnership Real Estate List of real estate topics

Economics Economic democracy Financial economics List of economics topics

Renewable Energy

Electronic commerce E-business

Revenue shortfall

Entrepreneurship Finance List of finance topics

Small business Sole proprietorship

Strategic Management Strategic Planning Types of business entity

Business

410

External links
Better Business Bureau [3] US & Canada Business Current Events [4] Open Directory Doing Business project - World Bank/IFC [5] OECD Business Demography Statistics [6] Business.gov - Small Business Resources from the US Small Business Administration [7] Business Questions And Answers [8]

References
[1] Sullivan, arthur; Steven M. Sheffrin (2003). Economics: Principles in action (http:/ / www. pearsonschool. com/ index. cfm?locator=PSZ3R9& PMDbSiteId=2781& PMDbSolutionId=6724& PMDbCategoryId=& PMDbProgramId=12881& level=4). Upper Saddle River, New Jersey 07458: Pearson Prentice Hall. pp.29. ISBN0-13-063085-3. . [2] People.com (http:/ / english. people. com. cn/ data/ China_in_brief/ Economy/ Major Industries. html) [3] http:/ / www. bbb. org/ [4] http:/ / www. dmoz. org/ News/ Current_Events/ Business_and_Economy/ [5] http:/ / www. doingbusiness. org/ [6] http:/ / stats. oecd. org/ Index. aspx?DataSetCode=SDBS_BDI [7] http:/ / business. gov/ [8] http:/ / startups. com/

Goal
A goal or objective is a projected state of affairs that a person or a system plans or intends to achievea personal or organizational desired end-point in some sort of assumed development. Many people endeavor to reach goals within a finite time by setting deadlines. It is roughly similar to purpose or aim, the anticipated result which guides action, or an end, which is an object, either a physical object or an abstract object, that has intrinsic value.

Goal
Goal-setting ideally involves establishing specific, measurable, attainable, realistic and time-targeted objectives. Work on the goal-setting theory suggests that it can serve as an effective tool for making progress by ensuring that participants have a clear awareness of what they must do to achieve or help achieve an objective. On a personal level, the process of setting goals allows people to specify and then work towards their own objectives most commonly financial or career-based goals. Goal-setting comprises a major component of Personal development.

Short-term goals
Short-term goals expect accomplishment in a short period of time, such as trying to get a bill paid in the next few days. The definition of a short-term goal need not relate to any specific length of time. In other words, one may achieve (or fail to achieve) a short-term goal in a day, week, month, year, etc. The time-frame for a short-term goal relates to its context in the overall time line that it is being applied to. For instance, one could measure a short-term goal for a month-long project in days; whereas one might measure a short-term goal for someones lifetime in months or in years. Planners usually define short-term goals in relation to a long-term goal or goals.

Goal

411

Personal goals
Individuals can set personal goals. A student may set a goal of a high mark in an exam. An athlete might walk five miles a day. A traveler might try to reach a destination-city within three hours. Financial goals are a common example, to save for retirement or to save for a purchase. Managing goals can give returns in all areas of personal life. Knowing precisely what one wants to achieve makes clear what to concentrate and improve on, and often subconsciously prioritizes that goal. Goal setting and planning ("goal work") promotes long-term vision and short-term motivation. It focuses intention, desire, acquisition of knowledge, and helps to organize resources. Efficient goal work includes recognizing and resolving all guilt, inner conflict or limiting belief that might cause one to sabotage one's efforts. By setting clearly-defined goals, one can subsequently measure and take pride in the achievement of those goals. One can see progress in what might have seemed a long, perhaps impossible, grind.

Achieving personal goals

Achieving complex and difficult goals requires: focus, long-term diligence and effort. Success in any field requires forgoing excuses and justifications for poor performance or lack of adequate planning; in short, success requires emotional maturity. The measure of belief that people have in their ability to achieve a personal goal also affects that achievement. Long term achievements rely on short-term achievements. Emotional control over the small moments of the single day makes a big difference in the long term. One formula for achievement reads A=I M where A = achievement, I = intelligence, and M = motivation. When motivation equals zero, achievement always equals zero, no matter the degree of intelligence. Similarly for intelligence: if intelligence equals zero, achievement always equals zero. The higher the combination of both intelligence and the motivation, the higher the achievement.

Goal management in organizations

Organizationally, goal management consists of the process of recognizing or inferring goals of individual team-members, abandoning no longer relevant goals, identifying and resolving conflicts among goals, and prioritizing goals consistently for optimal team-collaboration and effective operations. For any successful commercial system, it means deriving profits by making the best quality of goods or the best quality of services available to the end-user (customer) at the best possible cost. Goal management includes: Assessment and dissolution of non-rational blocks to success Time management Frequent reconsideration (consistency checks) Feasibility checks Adjusting milestones and main-goal targets

Morten Lind and J.Rasmussen distinguish three fundamental categories of goals related to technological system management: 1. Production goal 2. Safety goal 3. Economy goal An organizational goal-management solution ensures that individual employee goals and objectives align with the vision and strategic goals of the entire organization. Goal-management provides organizations with a mechanism to effectively communicate corporate goals and strategic objectives to each person across the entire organization. The key consists of having it all emanate from a pivotal source and providing each person with a clear, consistent

Goal organizational-goal message. With goal-management, every employee understands how their efforts contribute to an enterprise's success. An example of goal types in business management: Consumer goals: this refers to supplying a product or service that the market/consumer wants Product goals: this refers to supplying a product outstanding compared to other productsperhaps due to the likes of quality, design, reliability and novelty Operational goals: this refers to running the organization in such a way as to make the best use of management skills, technology and resources Secondary goals: this refers to goals which an organization does not regard as priorities

412

See also
Big Hairy Audacious Goal Decision making software Direction of fit GOAL Agent Programming Language Goal modeling Goal Programming Goal Theory Goal-Question-Metric (GQM) Goal-Setting Theory Life planning Management by objectives Polytely Regulatory Focus Theory Strategic management Strategic planning SWOT Analysis The Jackrabbit Factor: Why You Can (book)

Further reading
Robert F. Mager Goal Analysis, 3rd. edition, 1997. Eliyahu M. Goldratt, Jeff Cox. The Goal: A Process of Ongoing Improvement. ISBN 0-88427-061-0

Dynamic Systems Development Method

413

Dynamic Systems Development Method

Dynamic Systems Development Method (DSDM) is a software development methodology originally based upon the Rapid Application Development methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement. Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

Model of the DSDM software development process.

Overview
As an extension of rapid application development, DSDM focuses on Information Systems projects that are characterised by tight schedules and budgets. DSDM addresses the most common failures of information systems projects, including exceeding budgets, missing deadlines, and lack of user involvement and top-management commitment. By encouraging the use of RAD, however, careless adoption of DSDM may increase the risk of cutting too many corners. DSDM consists of Three phases: pre-project phase, project life-cycle phase, and post-project phase. A project life-cycle phase subdivided into 5 stages: feasibility study, business study, functional model iteration, design and build iteration, and implementation. In some circumstances, there are possibilities to integrate practices from other methodologies, such as Rational Unified Process (RUP), Extreme Programming (XP), and PRINCE2, as complements to DSDM. Another agile method that has some similarity in process and concept to DSDM is Scrum. DSDM was developed in the United Kingdom in the 1990s by the DSDM Consortium, an association of vendors and experts in the field of software engineering created with the objective of "jointly developing and promoting an independent RAD framework" by combining their best practice experiences. The DSDM Consortium is a not-for-profit, vendor-independent organisation which owns and administers the DSDM framework. The first version was completed in January 1995 and was published in February 1995. The current version in use (as of April 2006) is Version 4.2: Framework for Business Centered Development, and was released in May 2003. In July 2006, DSDM Public Version 4.2[1] was made available for individuals to view and use; however, anyone reselling DSDM must still be a member of the not-for-profit consortium.

Dynamic Systems Development Method

414

The DSDM approach

Principles
There are nine underlying principles consisting of four foundations and five starting-points. User involvement is the main key in running an efficient and effective project, where both users and developers share a workplace, so that the decisions can be made accurately. The project team must be empowered to make decisions that are important to the progress of the project without waiting for higher-level approval. A focus on frequent delivery of products, with assumption that to deliver something "good enough" earlier is always better than to deliver everything "perfectly" in the end. By delivering product frequently from an early stage of the project, the product can be tested and reviewed where the test record and review document can be taken into account at the next iteration or phase. The main criteria for acceptance of a "deliverable" is delivering a system that addresses the current business needs. Delivering a perfect system which addresses all possible business needs is less important than focusing on critical functionalities. Development is iterative and incremental and driven by users feedback to converge on an effective business solution. All changes during the development are reversible. The high level scope and requirements should be base-lined before the project starts. Testing is carried out throughout the project life-cycle. (See Test-driven development for comparison). Communication and cooperation among all project stakeholders is required to be efficient and effective.

Prerequisites for using DSDM

In order for DSDM to be a success, a number of prerequisites need to be realised. First, there needs to be interactivity between the project team, future end users and higher management. This addresses well known failures of IS development projects due to lack of top management motivation and/or user involvement. The second prerequisite for DSDM projects is that the project can be decomposed in to smaller parts enabling the use of an iterative approach. Two examples of types of projects for which DSDM is not considered well-suited are: Safety-critical projects - the extensive testing and validation found in safety-critical projects conflict with DSDM goals of being on time and on budget. Projects that aim to produce re-usable components - the demands on perfection are often too high and conflict with the 80%/20% principle described earlier.

DSDM Project Life-cycle

Overview : three phases of DSDM
The DSDM framework consists of three sequential phases, namely the pre-project, project life-cycle and post-project phases. The project phase of DSDM is the most elaborate of the three phases. The project life-cycle phase consists of 5 stages that form an iterative step-by-step approach in developing an IS. The three phases and corresponding stages are explained extensively in the subsequent sections. For each stage/phase, the most important activities are addressed and the deliverables are mentioned. Phase 1 - The Pre-Project In the pre-project phase candidate projects are identified, project funding is realised and project commitment is ensured. Handling these issues at an early stage avoids problems at later stages of the project.

Dynamic Systems Development Method Phase 2 - The Project life-cycle The process overview in the figure below shows the project life-cycle of this phase of DSDM. It depicts the 5 stages a project will have to go through to create an IS. The first two stages, the Feasibility Study and Business Study are sequential phases that complement to each other. After these phases have been concluded, the system is developed iteratively and incrementally in the Functional Model Iteration, Design & Build Iteration and Implementation stages. The iterative and incremental nature of DSDM will be addressed further in a later section. Phase 3 - Post-project The post-project phase ensures the system operating effectively and efficiently. This is realised by maintenance, enhancements and fixes according to DSDM principles. The maintenance can be viewed as continuing development based on the iterative and incremental nature of DSDM. Instead of finishing the project in one cycle usually the project can return to the previous phases or stages so that the previous step and the deliverable products can be refined. Below is the process-data diagram of DSDM as a whole Project life-cycle with all of its four steps. This diagram depicts the DSDM iterative development, started on functional model iteration, design and build iteration, and implementation phase. The description of each stage will be explained later in this entry.

415

The process-data diagram of DSDM Project Life-cycle

Dynamic Systems Development Method

416

The four steps of the DSDM Project Life-cycle

Activity Study Sub activity Feasibility Study Description Stage where the suitability of DSDM is assessed. Judging by the type of project, organisational and people issues, the decision is made, whether to use DSDM or not. Therefore it will generate a FEASIBILITY REPORT, a FEASIBILITY PROTOTYPE, and a GLOBAL OUTLINE PLAN which includes a DEVELOPMENT PLAN and a RISK LOG. Stage where the essential characteristics of business and technology are analysed. Approach to organise workshops, where a sufficient number of the customers experts are gathered to be able to consider all relevant facets of the system, and to be able to agree on development priorities. In this stage, a PRIORITISED REQUIREMENTS LIST, a BUSINESS AREA DEFINITION, a SYSTEM ARCHITECTURE DEFINITION, and an OUTLINE PROTOTYPING PLAN are developed. Determine the functionalities to be implemented in the prototype that results from this iteration. In this sub-stage, a FUNCTIONAL MODEL is developed according to the deliverables result of business study stage.

Business Study

Functional Model Identify Iteration functional prototype Agree schedule Create functional prototype Review functional prototype Design and Build Identify Iteration design prototype Agree schedule Create design prototype Review design prototype Implementation

Agree on how and when to develop these functionalities.

Develop the FUNCTIONAL PROTOTYPE, according to the agreed schedule and FUNCTIONAL MODEL.

Check correctness of the developed prototype. This can be done via testing by end-user and/or reviewing documentation. The deliverable is a FUNCTIONAL PROTOTYPING REVIEW DOCUMENT.

Identify functional and non-functional requirements that need to be in the tested system. And based on these identifications, an IMPLEMENTATION STRATEGY is involved. If there is a TEST RECORD from the previous iteration, then it will be also used to determine the IMPLEMENTATION STRATEGY. Agree on how and when to realise these requirements.

Create a system (DESIGN PROTOTYPE) that can safely be handed to end-users for daily use, also for testing purposes. Check the correctness of the designed system. Again testing and reviewing are the main techniques used. An USER DOCUMENTATION and a TEST RECORD will be developed.

User approval End users approve the tested system (APPROVAL) for implementation and guidelines with respect to the and implementation and use of the system are created. guidelines Train users Train future end user in the use of the system. TRAINED USER POPULATION is the deliverable of this sub-stage. Implement the tested system at the location of the end users, called as DELIVERED SYSTEM. Review the impact of the implemented system on the business, a central issue will be whether the system meets the goals set at the beginning of the project. Depending on this the project goes to the next stage, the post-project or loops back to one of the preceding stages for further development. This review is will be documented in a PROJECT REVIEW DOCUMENT.

Implement Review business

Dynamic Systems Development Method

417

Four stages of the Project life-cycle

Stage 1A: The Feasibility Study During this stage of the project, the feasibility of the project for the use of DSDM is examined. Prerequisites for the use of DSDM are addressed by answering questions like: Can this project meet the required business needs?, Is this project suited for the use of DSDM? and What are the most important risks involved?. The most important techniques used in this phase are the Workshops. The deliverables for this stage are the Feasibility Report and the Feasibility Model of the DSDM software development process. Prototype that address the feasibility of the project at hand. It is extended with a Global Outline Plan for the rest of the project and a Risk Log that identifies the most important risks for the project. Stage 1B: The Business Study The business study extends the feasibility study. After the project has been deemed feasible for the use of DSDM, this stage examines the influenced business processes, user groups involved and their respective needs and wishes. Again the workshops are one of the most valuable techniques, workshops in which the different stakeholders come together to discuss the proposed system. The information from these sessions is combined into a requirements list. An important property of the requirements list is the fact that the requirements are (can be) prioritised. These requirements are prioritised using the MoSCoW approach. Based on this prioritisation, a development plan is constructed as a guideline for the rest of the project. An important project technique used in the development of this plan is timeboxing. This technique is essential in realising the goals of DSDM, namely being on time and on budget, guaranteeing the desired quality. A system architecture is another aid to guide the development of the IS.The deliverables for this stage are a business area definition that describes the context of the project within the company, a system architecture definition that provides an initial global architecture of the IS under development together with a development plan that outlines the most important steps in the development process. At the base of these last two documents there is the prioritised requirements list. This list states all the requirements for the system, organised according to the MoSCoW principle. And last the Risk Log is updated with the facts that have been identified during this phase of DSDM. Stage 2: Functional Model Iteration The requirements that have been identified in the previous stages are converted to a functional model. This model consists of both a functioning prototype and models. Prototyping is one of the key project techniques within this stage that helps to realise good user involvement throughout the project. The developed prototype is reviewed by different user groups. In order to assure quality, testing is implemented throughout every iteration of DSDM. An important part of testing is realised in the Functional Model Iteration. The Functional Model can be subdivided into four sub-stages: Identify Functional Prototype: Determine the functionalities to be implemented in the prototype that results from this iteration.

Dynamic Systems Development Method Agree Schedule: Agree on how and when to develop these functionalities. Create Functional Prototype: Develop the prototype. Investigate, refine, and consolidate it with the combined Functional prototype of previous iterations. Review Prototype: Check the correctness of the developed prototype. This can be done via testing by end-user, then use the test records and users feedbacks to generate the functional prototyping review document. The deliverables for this stage are a Functional Model and a Functional Prototype that together represent the functionalities that could be realised in this iteration, ready for testing by users. Next to this, the Requirements List is updated, deleting the items that have been realised and rethinking the prioritisation of the remaining requirements. The Risk Log is also updated by having risk analysis of further development after reviewing the prototyping document. Stage 3: Design and Build Iteration The main focus of this DSDM iteration is to integrate the functional components from the previous phase into one system that satisfies user needs. It also addresses the non-functional requirements that have been set for the IS. Again testing is an important ongoing activity in this stage. The Design and Build Iteration can be subdivided into four sub-stages: Identify Design Prototype: Identify functional and non-functional requirements that need to be in the tested system. Agree Schedule: Agree on how and when to realise these requirements. Create Design Prototype: Create a system that can safely be handed to end-users for daily use. They investigate, refine, and consolidate the prototype of current iteration within prototyping process are also important in this sub-stage. Review Design Prototype: Check the correctness of the designed system. Again testing and reviewing are the main techniques used, since the test records and users feedbacks are important to generate the user documentation. The deliverables for this stage are a Design Prototype during the phase that end users get to test and at the end of the Design and Build Iteration the Tested System is handed over to the next phase. In this stage, the system is mainly built where the design and functions are consolidated and integrated in a prototype. Another deliverable for this stage is a User Documentation. Stage 4: Implementation In the Implementation stage, the tested system including user documentation is delivered to the users and training of future users is realised. The system to be delivered has been reviewed to include the requirements that have been set in the beginning stages of the project. The Implementation stage can be subdivided into four sub-stages: User Approval and Guidelines: End users approve the tested system for implementation and guidelines with respect to the implementation and use of the system are created. Train Users: Train future end user in the use of the system. Implement: Implement the tested system at the location of the end users. Review Business: Review the impact of the implemented system on the business, a central issue will be whether the system meets the goals set at the beginning of the project. Depending on this the project goes to the next phase, the post-project or loops back to one of the preceding phases for further development. The deliverables for this stage are a Delivered System on location, ready for use by the end users, Trained Users and detailed Project Review Document of the system.

418

Dynamic Systems Development Method

419

DSDM Functional Model Iteration

Meta-data model
The associations between concepts of deliverables in Functional Model Iteration stage are depicted in the meta-data model below. This meta-data model will be combined with the meta-process diagram of Functional Model Iteration phase in the next part.

Meta-data model of Functional Model Iteration

Concept RISK LOG

Definition Log of identified risk. Important since the next stage onward, encountered problem will be more difficult to address. This risk log will need to be updated continuously. (VTT Publication 478) List of requirements based on its prioritisation. The prioritisation process is based on MoSCoW technique, to determine which requirements must be implemented first into the system (the ones that meet the business needs), and so on. List of non-functional requirements is mainly to be dealt in the next stage. (VTT Publication 478)

PRIORITISED REQUIREMENTS LIST

NON-FUNCTIONAL REQUIREMENTS LIST FUNCTIONAL REQUIREMENT FUNCTIONAL MODEL

Function that is used to build the model and prototyping according to its priority. Model that is built according to the functional requirements. It will be used in order to develop the functional prototype in the next sub-stage. This concept will be used to develop a PROTOTYPING PLAN. The process of quickly putting together a working model (a prototype) in order to test various aspects of the design, illustrate ideas or features and gather early user feedback. The list of available times to do certain activities in order to perform the plan according to the schedule. Activities plan within prototyping process that will be performed in available time slots according to the schedule.

PROTOTYPING

TIME SLOT PROTOTYPING PLAN

Dynamic Systems Development Method

420

SCHEDULE

A set of activities plan with the related time agreed by the developers. This concept will be used to support the implementation of FUNCTIONAL PROTOTYPE. A prototype of the functions the system should perform and how it should perform them. A preparation of activities to implement the functional prototyping according to the schedule and the prioritised requirements list. Function of prototype that is being refined within current iteration before it is combined to the others and tested. Function of prototyped that is combined with the other functional prototypes of previous iteration. The new combination functional prototype will be tested in the next stage. Record set of testing where the test script, test procedure, and test result are included. This test record is used to develop the FUNCTIONAL PROTOTYPING REVIEW DOCUMENT, and is also used indirectly to update the PRIORITISED REQUIREMENTS LIST. It collects the users comments about the current increment, working as input for subsequent iterations (VTT Publication 478). This review document will be used to update the RISK LOG and PRIORITISED REQUIREMENTS LIST.

FUNCTIONAL PROTOTYPE IMPLEMENTATION PLAN

REFINED FUNCTION

COMBINED FUNCTION

TEST RECORD

FUNCTIONAL PROTOTYPING REVIEW DOCUMENT

Process-data model
Identify functional prototype activity is to identify the functionalities that would be in the prototype of current iteration. Recall that both, analysis and coding are done; prototypes are built, and the experiences gained from them are used in improving the analysis models (based also on updated prioritised requirements list and updated risk log). The built prototypes are not to be entirely discarded, but gradually steered towards such quality that they can be included in the final system. Agree schedule is to determine when and how the prototyping will be implemented; it extends the scope to the available timetable and prototyping plan. And since testing is implemented throughout the whole process, its also an essential part of this phase, and therefore it is included in the Review Prototype activity right after the functional prototype is built and the test record will eventually be used in the review prototype process and generates the review document. Below is the process-data diagram of Functional Model Iteration stage.

Dynamic Systems Development Method

421

Model of the Functional Model Iteration.

Activity Identify functional prototype

Sub activity Analyse the requirements

Description The requirements of current prototype are analysed according to the prioritised requirements list that is previously developed (in previous iteration and/or in previous phase which is business study phase).

List requirements of Select the functional requirements that would be implemented in the current iterations prototype, and list current iteration them in the FUNCTIONAL REQUIREMENT. List non-functional requirements Create functional model List the non-functional requirements of the system that is being developed in NON-FUNCTIONAL REQUIREMENTS LIST. Analysis model and prototype codes are included in this sub-activity to develop the FUNCTIONAL MODEL. Identify possible timetable (TIME SLOT) to perform the prototyping activities according to the prototyping plan and prototyping strategy.

Agree schedule

Determine time

Design development The PROTOTYPING PLAN, including all prototyping activities that will be performed on available TIME SLOT. Agreement Create functional prototype Investigate The agreement SCHEDULE of when and how the prototyping activities should be performed. Investigate the requirements; analyse the FUNCTIONAL MODEL that has been built in earlier activity, and set the IMPLEMENTATION PLAN according to the analysis model, and will be used to build the prototype in the next sub-activity. Implement the FUNCTIONAL MODEL and IMPLEMENTATION PLAN to build a FUNCTIONAL PROTOTYPE. This prototype will be then refined before it is combined to the other functions. This prototype will be gradually steered towards such quality that it can be included in the final system (through refining process). Consolidate the refined FUNCTIONAL PROTOTYPE with the other prototype of previous iteration. The new combination FUNCTIONAL PROTOTYPE will be tested in the next activity.

Refine

Consolidate

Dynamic Systems Development Method

422

Review prototype

Test prototype

The essential part of DSDM that needs to be included throughout the whole process of DSDM. The TEST RECORD will be used together with users comments to develop the PROTOTYPING REVIEW DOCUMENT in the next activity of FMI phase. Collects the user comments and documentation. The test records will play an important role to develop this review report. Based on this FUNCTIONAL PROTOTYPING REVIEW DOCUMENT, the prioritised requirements list and risk log will be updated, and decide to set the next course whether or not to do another iteration of FMI phase.

Review prototype

Further DSDM topics

Core Techniques of DSDM
Timeboxing Timeboxing is one of the project techniques of DSDM. It is used to support the main goals of DSDM to realise the development of an IS on time, within budget and with the desired quality. The main idea behind timeboxing is to split up the project in portions, each with a fixed budget and a delivery date. For each portion a number of requirements are selected that are prioritised according to the MoSCoW principle. Because time and budget are fixed, the only remaining variables are the requirements. So if a project is running out of time or money the requirements with the lowest priority are omitted. This does not mean that an unfinished product is delivered, because of the pareto principle that 80% of the project comes from 20% of the system requirements, so as long as those most important 20% of requirements are implemented into the system, the system therefore meets the business needs and that no system is built perfectly in the first try. MoSCoW MoSCoW represents a way of prioritising items. In the context of DSDM the MoSCoW technique is used to prioritise requirements. It is an acronym that stands for: MUST have this requirement to meet the business needs. SHOULD have this requirement if at all possible, but the project success does not rely on this. COULD have this requirement if it does not affect the fitness of business needs of the project. WOULD have this requirement at later date if there is some time left (or in the future development of the system). Prototyping This technique refers to the creation of prototypes of the system under development at an early stage of the project. It enables the early discovery of shortcomings in the system and allows future users to test-drive the system. This way good user involvement is realised, one of the key success factors of DSDM, or any System Development project for that matter. Testing A third important aspect of the goal of DSDM is the creation of an IS with good quality. In order to realise a solution of good quality, DSDM advocates testing throughout each iteration. Since DSDM is a tool and technique independent method, the project team is free to choose its own test management method, for example TMap [2]. Workshop One of DSDMs project techniques that aims at bringing the different stakeholders of the project together to discuss requirements, functionalities and mutual understanding. In a workshop the stakeholders come together and discuss the project. Modeling This technique is essential and purposely used to visualise the diagrammatic representation of a specific aspect of the system or business area that is being developed. Modelling gives a better understanding for DSDM project team over

Dynamic Systems Development Method a business domain. Configuration Management A good implementation of this configuration management technique is important for the dynamic nature of DSDM. Since there is more than one thing being handled at once during the development process of the system, and the products are being delivered frequently at a very fast rate, the products therefore need to be controlled strictly as they achieve (partial) completion.

423

Roles in DSDM
There are some roles introduced within DSDM environment. It is important that the project members need to be appointed to different roles before they start to run the project. Each role has its own responsibility. The roles are: Executive Sponsor So called the Project Champion. An important role from the user organisation who has the ability and responsibility to commit appropriate funds and resources. This role has an ultimate power to make decisions. Visionary The one who has the responsibility to initialise the project by ensuring that essential requirements are found early on. Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track. Ambassador User Brings the knowledge of user community into the project, ensures that the developers receive enough amount of users feedbacks during the development process. Advisor User Can be any user that represents an important viewpoint and brings the daily knowledge of the project. Project Manager Can be anyone from user community or IT staff who manages the project in general. Technical Co-ordinator Responsible in designing the system architecture and control the technical quality in the project. Team Leader Leads his team and ensures that the team works effectively as a whole. Developer Interpret the system requirements and model it including developing the deliverable codes and build the prototypes. Tester Checks the correctness in a technical extents by performing some testings. Tester will have to give some comments and documentation. Scribe Responsible to gather and record the requirements, agreements, and decisions made in every workshop. Facilitator Responsible in managing the workshops progress, acts as a motor for preparation and communication. Specialist Roles Business Architect, Quality Manager, System Integrator, etc.

Iterative and Incremental Nature

Next to timeboxing and prioritising of requirements, the DSDM also provides an iterative and incremental approach to IS development. This can be seen in the figure depicting the Process Overview above. The Functional Model Iteration, Design & Build Iteration and Implementation stages can go over their sub stages several times before entering the next stage. Each iteration addresses a set of new functionalities, and every iteration builds on a working predecessor. Each iteration can be undone if needed. The Process Overview figure also shows arrows going back to previous stages. For example, there is an arrow from Implementation to the Business Study. If a big functionality has been discovered during development that couldnt be implemented, it might be possible to start all over by defining new requirements in a Business Study. Similarly, there is an arrow from Implementation to the Functional Model Iteration. Functionality might be omitted during a previous Functional Model Iteration because of time or budget constraints. The project should proceed into the post-project phase only when it meets all the requirements defined by the project and business goals. Because of the iterative nature of DSDM, it is essential to maintain good requirements management and configuration management throughout the entire project. This ensures that the project does implement the

Dynamic Systems Development Method requirements that were decided in the early phases of the project.

424

Meta-model (Meta-Modeling)
As explained in the Wikipedia item, Meta-Modeling takes a higher level look at methods and techniques. In doing so it offers possibilities for comparing similar methods and techniques and engineering new methods from existing ones. The Meta data model, depicted below, identifies the concepts and associations between these concepts within DSDM. As can be seen from the figure, two main concepts can be identified, namely the Phase and the Flow concept. Each Flow originates from a Phase within DSDM. Flows can be divided up in the sub concepts Data and Product. This subdivision is denoted with a C, which means that the subdivision is disjoint and complete. In other words, a Flow is always either a Data Flow or a Product Flow, but never both. In the situation of DSDM a Data Flow can be an arc returning to one of the preceding phases. Product Flows are tangible goods that result from one of the Phases and are the input of the next Phase, for example reports and prototypes. Then there is the second concept Phase that is also be divided two sub concepts with a complete and disjoint ordering. These sub concepts are the Sequential and the Iterative Phases. As was explained in an earlier section, DSDM starts with two sequential phases, The Feasibility and Business Study. Next a number of Iterative phases follow, i.e. Functional Model, Design & Build and Implementation phases. The picture also mentions a number of rules and issues that are not included in the model, but that are important for this meta-model. First there are the rules that concerns the behavior of the Flows. These rules restrict the freedom of the flows so that they correspond to the Phase transitions within DSDM. Next to the rules a number of important issues are addressed that ensure that the DSDM project life-cycle is guaranteed.

Critical Success Factors of DSDM

Within DSDM a number of factors are identified as being of great importance to ensure successful projects. Factor 1: First there is the acceptance of DSDM by senior management and other employees. This ensures that the different actors of the project are motivated from the start and remain involved throughout the project. Factor 2: The second factor follows directly from this and that is the commitment of management to ensure end-user involvement. The prototyping approach requires a strong and dedicated involvement by end user to test and judge the functional prototypes. Factor 3: Then there is the project team. This team has to be composed of skillful members that form a stable union. An important issue is the empowerment of the project team. This means that the team (or one or more of its members) has to possess the power and possibility to make important decisions regarding the project without having to write formal proposals to higher management, which can be very time-consuming. In order for the project team to be able to run a successful project, they also need the right technology to conduct the project. This means a development environment, project management tools, etc. Factor 4: Finally DSDM also states that a supportive relationship between customer and vendor is required. This goes for both projects that are realised internally within companies or by outside contractors. An aid in ensuring a supporting relationship could be ISPL.

Dynamic Systems Development Method

425

Comparison to other IS Development Methods

Over the years a great number of Information System Development methods have been developed and applied, divided in Structured Methods, RAD methods and Object-Oriented Methods. Many of these methods show similarities to each other and also to DSDM. For example Extreme Programming(XP) also has an iterative approach to IS development with extensive user involvement. The Rational Unified Process is a method that probably has the most in common with DSDM in that it is also a dynamic form of Information System Development. Again the iterative approach is used in this development method. Like XP and RUP there are many other development methods that show similarities to DSDM, but DSDM does distinguish itself from these methods in a number of ways. First there is the fact that it provides a tool and technique independent framework. This allows users to fill in the specific steps of the process with their own techniques and software aids of choice. Another unique feature is the fact that the variables in the development are not time/resources, but the requirements. This approach ensures the main goals of DSDM, namely to stay within the deadline and the budget. And last there is the strong focus on communication between and the involvement of all the stakeholders in the system. Although this is addressed in other methods, DSDM strongly believes in commitment to the project to ensure a successful outcome.

See also
Agile software development Extreme Programming Lean software development Iterative and incremental development MoSCoW Method IBM Rational Unified Process Rapid application development Pareto principle (80/20 rule) PRINCE2 Scrum Structured Systems Analysis and Design Method

Further reading
Coleman and Verbruggen: A quality software process for rapid application development, Software Quality Journal 7, p. 107-1222 (1998) Beynon-Davies and Williams: The diffusion of information systems development methods, Journal of Strategic Information Systems 12 p. 29-46 (2003) Sjaak Brinkkemper, Saeki and Harmsen: Assembly Techniques for Method Engineering, Advanced Information Systems Engineering, Proceedings of CaiSE'98, Springer Verlag (1998) Abrahamsson, Salo, Ronkainen, Warsta Agile Software Development Methods: Review and Analysis [3], VTT Publications 478, p. 61-68 (2002) Tuffs, Stapleton, West, Eason: Inter-operability of DSDM with the Rational Unified Process, DSDM Consortium, Issue 1, p. 1-29 (1999) Rietmann: DSDM in a birds eye view, DSDM Consortium, p. 3-8 (2001) iSDLC [4] integrated Systems Development Life Cycle

Dynamic Systems Development Method

426

External links
The DSDM Consortium [5] Dynamic System Development Method [6] by Benjamin J. J. Voigt, Zurich, 2004.

References
[1] [2] [3] [4] [5] [6] ( www.dsdm.org (http:/ / www. dsdm. org)) http:/ / eng. tmap. net/ Home/ http:/ / www. vtt. fi/ inf/ pdf/ publications/ 2002/ P478. pdf http:/ / sdlc. bobstewart. com http:/ / www. dsdm. org http:/ / www. ifi. uzh. ch/ rerg/ fileadmin/ downloads/ teaching/ seminars/ seminar_ws0304/ 14_Voigt_DSMD_Ausarbeitung. pdf

Product (business)
The noun product is defined as a "thing produced by labor or effort"[1] or the "result of an act or a process",[2] and stems from the verb produce, from the Latin prdce(re) '(to) lead or bring forth'. Since 1575, the word "product" has referred to anything produced.[3] Since 1695, the word has referred to "thing or things produced". The economic or commercial meaning of product was first used by political economist Adam Smith.[4] In marketing, a product is anything that can be offered to a market that might satisfy a want or need.[5] In retailing, products are called merchandise. In manufacturing, products are purchased as raw materials and sold as finished goods. Commodities are usually raw materials such as metals and agricultural products, but a commodity can also be anything widely available in the open market. In project management, products are the formal definition of the project deliverables that make up or contribute to delivering the objectives of the project. In general, product may refer to a single item or unit, a group of equivalent products, a grouping of goods or services, or an industrial classification for the goods or services. A related concept is subproduct, a secondary but useful result of a production process. Dangerous products, particularly physical ones, that cause injuries to consumers or bystanders may be subject to product liability.

Product groups
Tangible and intangible products
Products can be classified as tangible or intangible.[6] A tangible product is any physical product that can be touched like a computer, automobile, etc. An intangible product is a non-physical product like an insurance policy. In its online product catalog, retailer Sears, Roebuck and Company divides its products into departments, then presents products to shoppers according to (1) function or (2) brand.[7] Each product has a Sears item number and a manufacturer's model number. The departments and product groupings that Sears uses are intended to help customers browse products by function or brand within a traditional department store structure.[8]

Product (business)

427

Sizes and colors

A catalog number, especially for clothing, may group sizes and colors. When ordering the product, the customer specifies size, color and other variables.[9]

Product line
A product line is "a group of products that are closely related, either because they function in a similar manner, are sold to the same customer groups, are marketed through the same types of outlets, or fall within given price ranges."[10] Many businesses offer a range of product lines which may be unique to a single organization or may be common across the business's industry. In 2002 the US Census compiled revenue figures for the finance and insurance industry by various product lines such as "accident, health and medical insurance premiums" and "income from secured consumer loans".[11] Within the insurance industry, product lines are indicated by the type of risk coverage, such as auto insurance, commercial insurance and life insurance.[12]

National and international product classifications

Various classification systems for products have been developed for economic statistical purposes. The North American Industry Classification System (NAICS) classifies companies by their primary product [this is not even close to true, NAICS is a production-oriented classification system, not a product-oriented classification system the NAFTA signatories are working on a system that classifies products called NAPCS as a companion to NAICS [13]. The European Union uses a "Classification of Products by Activity" among other product classifications.[14] The United Nations also classifies products for international economic activity reporting.[15] The Aspinwall Classification System (Leo Aspinwall, 1958) classifies and rates products based on five variables: 1. 2. 3. 4. 5. Replacement rate (How frequently is the product repurchased?) Gross margin (How much profit is obtained from each product?) Buyer goal adjustment (How flexible are the buyers' purchasing habits with regard to this product?) Duration of product satisfaction (How long will the product produce benefits for the user?) Duration of buyer search behavior (How long will consumers shop for the product?)

The National Institute of Governmental Purchasing (NIGP)[16] developed a commodity and services classification system for use by state and local governments, the NIGP Code.[17] The NIGP Code is used by 33 states within the United States as well as thousands of cities, counties and political subdivisions. The NIGP Code is a hierarchical schema consisting of a 3 digit class, 5 digit class-item, 7 digit class-item-group and an 11 digit class-item-group-detail.[18] Applications of the NIGP Code include vendor registration, inventory item identification, contract item management, spend analysis and strategic sourcing.

Product (business)

428

See also
Product teardown

Footnotes
[1] Random House Dictionary, 1975 [2] Glossary of the terms related to quality assurance (http:/ / www. unizg. hr/ tempusprojects/ glossary. htm) from the Tempus Joint European Project for the Development of Quality Assurance [3] Etymology of product (http:/ / www. etymonline. com/ index. php?term=product), etymonline.com. [4] Etymology of produce (http:/ / www. etymonline. com/ index. php?term=produce) [5] Kotler, P., Armstrong, G., Brown, L., and Adam, S. (2006) Marketing, 7th Ed. Pearson Education Australia/Prentice Hall. [6] upenn.edu (http:/ / docs. google. com/ gview?a=v& q=cache:ZbQD7QYmcrkJ:knowledge. wharton. upenn. edu/ papers/ 840. pdf+ tangible+ products& hl=en& gl=us,) [7] Sears online (http:/ / www. sears. com), sears.com. [8] When an online Sears customer goes to the "Parts and accessories" section of the website to find parts for a particular Sears item, the "model number" field actually requires a Sears item number, not a manufacturer's model number. This is a typical problem with product codes or item codes that are internally assigned by a company but do not conform to an external standard. [9] L.L. Beans webpage for ordering men's "Dress Chinos, Classic Fit Pleated", catalog number TA55203 (http:/ / www. llbean. com/ webapp/ wcs/ stores/ servlet/ CategoryDisplay?page=dress-chinos& categoryId=35346& storeId=1& catalogId=1& langId=-1& parentCategory=3511& cat4=6352& shop_method=pp& feat=3511-tn). llbean.com. Accessed 2007-07-01. [10] Kotler, Philip; Gary Armstrong (1989). Principles of Marketing, fourth edition (Annotated Instructor's Edition). Prentice-Hall, Inc.. pp.639 (glossary definition). ISBN0137061293. [11] "2002 Economic Census, Finance and Insurance" (http:/ / www. census. gov/ prod/ ec02/ ec0252slls. pdf) US Census Bureau, 2002, p.14. [12] Insurance carrier product lines (http:/ / www. dmoz. org/ Business/ Financial_Services/ Insurance/ Carriers/ ) at the Open Directory Project [13] http:/ / www. census. gov/ eos/ www/ napcs/ napcs. htm [14] Eurostat classifications (http:/ / ec. europa. eu/ eurostat/ ramon/ nomenclatures/ index. cfm?TargetUrl=LST_NOM& StrGroupCode=CLASSIFIC& StrLanguageCode=EN), ec.europa.eu. [15] United Nations product classifications (http:/ / unstats. un. org/ unsd/ cr/ registry/ regcst. asp?Cl=16), unstats.un.org. [16] National Institute of Governmental Purchasing (http:/ / www. nigp. org), nigp.org [17] NIGP Code (http:/ / www. nigp. com) [18] NIGP Code sample (http:/ / www. nigp. com/ nigp-code-sample-01. jsp)

Kallas Mark

Marketing

429

Marketing
Marketing Key concepts Product Pricing Distribution Service Retail Brand management Account-based marketing Marketing ethics Marketing effectiveness Market research Market segmentation Marketing strategy Marketing management Market dominance Promotional content Advertising Branding Underwriting Direct marketing Personal Sales Product placement Publicity Sales promotion Sex in advertising Promotional media Printing Publication Broadcasting Out-of-home Internet marketing Point of sale Promotional items Digital marketing In-game In-store demonstration Brand Ambassador Word of mouth

Marketing is the process by which companies determine what products or services may be of interest to customers, and the strategy to use in sales, communication and business development.[1] It is an integrated process through which companies create value for customers and build strong customer relationships in order to capture value from customers in return.[1] Marketing is used to identify the customer, to keep the customer, and to satisfy the customer. With the customer as the focus of its activities, it can be concluded that marketing management is one of the major components of business management. Marketing evolved to meet the stasis in developing new markets caused by mature markets and overcapacities in the last 2-3 centuries. The adoption of marketing strategies requires businesses to shift their focus from production to the perceived needs and wants of their customers as the means of staying profitable. The term marketing concept holds that achieving organizational goals depends on knowing the needs and wants of target markets and delivering the desired satisfactions.[2] It proposes that in order to satisfy its organizational objectives, an organization should anticipate the needs and wants of consumers and satisfy these more effectively than competitors.[2]

Marketing

430

Further definitions
Marketing is defined by the American Marketing Association (AMA) as "the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large."[3] The term developed from the original meaning which referred literally to going to a market to buy or sell goods or services. Seen from a systems point of view, sales process engineering views marketing as "a set of processes that are interconnected and interdependent with other functions,[4] whose methods can be improved using a variety of relatively new approaches." The Chartered Institute of Marketing defines marketing as "the management process responsible for identifying, anticipating and satisfying customer requirements profitably."[5] A different concept is the value-based marketing which states the role of marketing to contribute to increasing shareholder value.[6] In this context, marketing is defined as "the management process that seeks to maximise returns to shareholders by developing relationships with valued customers and creating a competitive advantage."[6] Marketing practice tended to be seen as a creative industry in the past, which included advertising, distribution and selling. However, because the academic study of marketing makes extensive use of social sciences, psychology, sociology, mathematics, economics, anthropology and neuroscience, the profession is now widely recognized as a science, allowing numerous universities to offer Master-of-Science (MSc) programmes. The overall process starts with marketing research and goes through market segmentation, business planning and execution, ending with pre and post-sales promotional activities. It is also related to many of the creative arts. The marketing literature is also adept at re-inventing itself and its vocabulary according to the times and the culture.

Evolution of marketing
An orientation, in the marketing context, relates to a perception or attitude a firm holds towards its product or service, essentially concerning consumers and end-users. Throughout history marketing has changed considerably as consumer tastes are changing faster.[7]

Earlier approaches
The marketing orientation evolved from earlier orientations namely the production orientation, the product orientation and the selling orientation.[7] [8]
Orientation Profit driver Western European timeframe until the 1950s Description

Production

[8]

Production methods

A firm focusing on a production orientation specializes in producing as much as possible of a given product or service. Thus, this signifies a firm exploiting economies of scale, until the minimum efficient scale is reached. A production orientation may be deployed when a high demand for a product or service exists, coupled with a good certainty that consumer tastes do not rapidly alter (similar to the sales orientation). A firm employing a product orientation is chiefly concerned with the quality of its own product. A firm would also assume that as long as its product was of a high standard, people would buy and consume the product. A firm using a sales orientation focuses primarily on the selling/promotion of a particular product, and not determining new consumer desires as such. Consequently, this entails simply selling an already existing product, and using promotion techniques to attain the highest sales possible. Such an orientation may suit scenarios in which a firm holds dead stock, or otherwise sells a product that is in high demand, with little likelihood of changes in consumer tastes diminishing demand.

Product

[8]

Quality of the product

until the 1960s

Selling

[8]

Selling methods

1950s and 1960s

Marketing
[8]

431
Needs and wants of customers 1970 to present day The 'marketing orientation' is perhaps the most common orientation used in contemporary marketing. It involves a firm essentially basing its marketing plans around the marketing concept, and thus supplying products to suit new consumer tastes. As an example, a firm would employ market research to gauge consumer desires, use R&D to develop a product attuned to the revealed information, and then utilize promotion techniques to ensure persons know the product exists.

Marketing

Contemporary approaches
Recent approaches in marketing is the relationship marketing with focus on the customer, the business marketing or industrial marketing with focus on an organization or institution and the social marketing with focus on benefits to the society.[9] New forms of marketing also use the internet and are therefore called internet marketing or more generally e-marketing, online marketing, search engine marketing, desktop advertising or affiliate marketing. It tries to perfect the segmentation strategy used in traditional marketing. It targets its audience more precisely, and is sometimes called personalized marketing or one-to-one marketing.
Orientation Profit driver Western European timeframe 1960s to present day Description

Relationship marketing / Relationship [9] management Business marketing / Industrial marketing

Building and keeping good customer relations Building and keeping relationships between organizations

Emphasis is placed on the whole relationship between suppliers and customers. The aim is to give the best possible attention, customer services and therefore build customer loyalty. In this context marketing takes place between businesses or organizations. The product focus lies on industrial goods or capital goods than consumer products or end products. A different form of marketing activities like promotion, advertising and communication to the customer is used. Similar characteristics as marketing orientation but with the added proviso that there will be a curtailment on any harmful activities to society, in either product, production, or selling methods.

1980s to present day

Social marketing

[9]

Benefit to society

1990s to present day

Customer orientation
A firm in the market economy survives by producing goods that persons are willing and able to buy. Consequently, ascertaining consumer demand is vital for a firm's future viability and even existence as a going concern. Many companies today have a customer focus (or market orientation). This implies that the company focuses its activities and products on consumer demands. Generally there are three ways of doing this: the customer-driven approach, the sense of identifying market changes and the product innovation approach. In the consumer-driven approach, consumer wants are the drivers of all strategic marketing decisions. No strategy is pursued until it passes the test of consumer research. Every aspect of a market offering, including the nature of the product itself, is driven by the needs of potential consumers. The starting point is always the consumer. The rationale for this approach is that there is no point spending R&D funds developing products that people will not buy. History attests to many products that were commercial failures in spite of being technological breakthroughs.[10] A formal approach to this customer-focused marketing is known as SIVA[11] (Solution, Information, Value, Access). This system is basically the four Ps renamed and reworded to provide a customer focus. The SIVA Model provides a demand/customer centric version alternative to the well-known 4Ps supply side model (product, price, placement, promotion) of marketing management.

Marketing

432

Product

Solution Information Value Access

Promotion Price

Placement

If any of the 4Ps had a problem or were not there in the marketing factor of the business, the business could be in trouble and so other companies may appear in the surroundings of the company, so the consumer demand on its products will become less. Organizational orientation In this sense, a firm's marketing department is often seen as of prime importance within the functional level of an organization. Information from an organization's marketing department would be used to guide the actions of other departments within the firm. As an example, a marketing department could ascertain (via marketing research) that consumers desired a new type of product, or a new usage for an existing product. With this in mind, the marketing department would inform the R&D department to create a prototype of a product/service based on consumers' new desires. The production department would then start to manufacture the product, while the marketing department would focus on the promotion, distribution, pricing, etc. of the product. Additionally, a firm's finance department would be consulted, with respect to securing appropriate funding for the development, production and promotion of the product. Inter-departmental conflicts may occur, should a firm adhere to the marketing orientation. Production may oppose the installation, support and servicing of new capital stock, which may be needed to manufacture a new product. Finance may oppose the required capital expenditure, since it could undermine a healthy cash flow for the organization. Herd behavior Herd behavior in marketing is used to explain the dependencies of customers' mutual behavior. The Economist reported a recent conference in Rome on the subject of the simulation of adaptive human behavior.[12] It shared mechanisms to increase impulse buying and get people "to buy more by playing on the herd instinct." The basic idea is that people will buy more of products that are seen to be popular, and several feedback mechanisms to get product popularity information to consumers are mentioned, including smart card technology and the use of Radio Frequency Identification Tag technology. A "swarm-moves" model was introduced by a Florida Institute of Technology researcher, which is appealing to supermarkets because it can "increase sales without the need to give people discounts." Other recent studies on the "power of social influence" include an "artificial music market in which some 14,000 people downloaded previously unknown songs" (Columbia University, New York); a Japanese chain of convenience stores which orders its products based on "sales data from department stores and research companies;" a Massachusetts company exploiting knowledge of social networking to improve sales; and online retailers who are increasingly informing consumers about "which products are popular with like-minded consumers" (e.g., Amazon, eBay).

Marketing Further orientations An emerging area of study and practice concerns internal marketing, or how employees are trained and managed to deliver the brand in a way that positively impacts the acquisition and retention of customers, see also employer branding. Diffusion of innovations research explores how and why people adopt new products, services and ideas. With consumers' eroding attention span and willingness to give time to advertising messages, marketers are turning to forms of permission marketing such as branded content, custom media and reality marketing.

433

Marketing research
Marketing research involves conducting research to support marketing activities, and the statistical interpretation of data into information. This information is then used by managers to plan marketing activities, gauge the nature of a firm's marketing environment and attain information from suppliers. Marketing researchers use statistical methods such as quantitative research, qualitative research, hypothesis tests, Chi-squared tests, linear regression, correlations, frequency distributions, poisson distributions, binomial distributions, etc. to interpret their findings and convert data into information. The marketing research process spans a number of stages including the definition of a problem, development of a research plan, collecting and interpretation of data and disseminating information formally in form of a report. The task of marketing research is to provide management with relevant, accurate, reliable, valid, and current information. A distinction should be made between marketing research and market research. Market research pertains to research in a given market. As an example, a firm may conduct research in a target market, after selecting a suitable market segment. In contrast, marketing research relates to all research conducted within marketing. Thus, market research is a subset of marketing research.

Market segmentation
Market segmentation pertains to the division of a market of consumers into persons with similar needs and wants. As an example, if using Kellogg's cereals in this instance, Frosties are marketed to children. Crunchy Nut Cornflakes are marketed to adults. Both goods aforementioned denote two products which are marketed to two distinct groups of persons, both with like needs, traits, and wants. The purpose for market segmentation is conducted for two main issues. First, a segmentation allows a better allocation of a firm's finite resources. A firm only possesses a certain amount of resources. Accordingly, it must make choices (and appreciate the related costs) in servicing specific groups of consumers. Furthermore the diversified tastes of the contemporary Western consumers can be served better. With more diversity in the tastes of modern consumers, firms are taking noting the benefit of servicing a multiplicity of new markets. Market segmentation can be defined in terms of the STP acronym, meaning Segment, Target and Position.

Types of marketing research

Marketing research, as a sub-set aspect of marketing activities, can be divided into the following parts: Primary research (also known as field research), which involves the conduction and compilation of research for the purpose it was intended. Secondary research (also referred to as desk research), is initially conducted for one purpose, but often used to support another purpose or end goal. By these definitions, an example of primary research would be market research conducted into health foods, which is used solely to ascertain the needs/wants of the target market for health foods. Secondary research, again according to the above definition, would be research pertaining to health foods, but used by a firm wishing to develop an unrelated product.

Marketing Primary research is often expensive to prepare, collect and interpret from data to information. Nonetheless, while secondary research is relatively inexpensive, it often can become outdated and outmoded, given it is used for a purpose other than for which is was intended. Primary research can also be broken down into quantitative research and qualitative research, which as the labels suggest, pertain to numerical and non-numerical research methods, techniques. The appropriateness of each mode of research depends on whether data can be quantified (quantitative research), or whether subjective, non-numeric or abstract concepts are required to be studied (qualitative research). There also exists additional modes of marketing research, which are: Exploratory research, pertaining to research that investigates an assumption. Descriptive research, which as the label suggests, describes "what is". Predictive research, meaning research conducted to predict a future occurrence. Conclusive research, for the purpose of deriving a conclusion via a research process.

434

Marketing planning
The area of marketing planning involves forging a plan for a firm's marketing activities. A marketing plan can also pertain to a specific product, as well as to an organization's overall marketing strategy. Generally speaking, an organization's marketing planning process is derived from its overall business strategy. Thus, when top management are devising the firm's strategic direction or mission, the intended marketing activities are incorporated into this plan. There are several levels of marketing objectives within an organization. The senior management of a firm would formulate a general business strategy for a firm. However, this general business strategy would be interpreted and implemented in different contexts throughout the firm.

Marketing strategy
The field of marketing strategy encompasses the strategy involved in the management of a given product. A given firm may hold numerous products in the marketplace, spanning numerous and sometimes wholly unrelated industries. Accordingly, a plan is required in order to manage effectively such products. Evidently, a company needs to weigh up and ascertain how to utilize effectively its finite resources. As an example, a start-up car manufacturing firm would face little success, should it attempt to rival immediately Toyota, Ford, Nissan or any other large global car maker. Moreover, a product may be reaching the end of its life-cycle. Thus, the issue of divest, or a ceasing of production may be made. With regard to the aforesaid questions, each scenario requires a unique marketing strategy to be employed. Below are listed some prominent marketing strategy models, which seek to propose means to answer the preceding questions.

Marketing specializations
With the rapidly emerging force of globalization, the distinction between marketing within a firm's home country and marketing within external markets is disappearing very quickly. With this occurrence in mind, firms need to reorient their marketing strategies to meet the challenges of the global marketplace, in addition to sustaining their competitiveness within home markets.[13]

Buying behaviour
A marketing firm must ascertain the nature of the customers buying behaviour, if it is to market its product properly. In order to entice and persuade a consumer to buy a product, marketers try to determine the behavioural process of how a given product is purchased. Buying behaviour is usually split in two prime strands, whether selling to the consumer, known as business-to-consumer (B2C) or another business, similarly known as business-to-business (B2B).

Marketing

435

B2C buying behaviour

This mode of behaviour concerns consumers, in the purchase of a given product. As an example, if one pictures a pair of sneakers, the desire for a pair of sneakers would be followed by an information search on available types/brands. This may include perusing media outlets, but most commonly consists of information gathered from family and friends.If the information search is insufficient, the consumer may search for alternative means to satisfy the need/want. In this case, this may be buying leather shoes, sandals, etc. The purchase decision is then made, in which the consumer actually buys the product. Following this stage, a post-purchase evaluation is often conducted, comprising an appraisal of the value/utility brought by the purchase of the sneakers. If the value/utility is high, then a repeat purchase may be bought. This could then develop into consumer loyalty, for the firm producing the pair of sneakers.

B2B buying behaviour

Relates to organizational/industrial buying behavior.[14] B2C and B2B behavior are not exact, as similarities and differences exist. Some of the key differences are listed below: In a straight re-buy, the fourth, fifth and sixth stages are omitted. In a modified re-buy scenario, the fifth and sixth stages are precluded. In a new buy, all aforementioned stages are conducted.

Use of technologies
Marketing management can also note the importance of technology, within the scope of its marketing efforts. Computer-based information systems can be employed, aiding in a better processing and storage of data. Marketing researchers can use such systems to devise better methods of converting data into information, and for the creation of enhanced data gathering methods. Information technology can aid in improving an MKIS' software and hardware components, to improve a company's marketing decision-making process. In recent years, the netbook personal computer has gained significant market share among laptops, largely due to its more user-friendly size and portability. Information technology typically progress at a fast rate, leading to marketing managers being cognizant of the latest technological developments. Moreover, the launch of smartphones into the cellphone market is commonly derived from a demand among consumers for more technologically advanced products. A firm can lose out to competitors, should it refrain from noting the latest technological occurrences in its industry. Technological advancements can facilitate lesser barriers between countries and regions. Via using the World Wide Web, firms can quickly dispatch information from one country to another, without much restriction. Prior to the mass usage of the Internet, such transfers of information would have taken longer to send, especially if via snail mail, telex, etc.

Services marketing
Services marketing,[15] as the label suggests, relates to the marketing of services, as opposed to tangible products (in standard economic terminology, a tangible product is called a good). A typical definition of a service (as opposed to a good) is thus: The use of it is inseparable from its purchase (,i.e. a service is used and consumed simultaneously) It does not possess material form, and thus cannot be smelt, heard, tasted, or felt. The use of a service is inherently subjective, in that due to the human condition, all persons experiencing a service would experience it uniquely. As examples of the above points, a train ride can be deemed as a service. If one buys a train ticket, the use of the train is typically experienced concurrently with the purchase of the ticket. Moreover, a train ride cannot be smelt,

Marketing heard, tasted or felt as such. Granted, a seat can be felt, and the train can be evidently heard, nonetheless one is not paying for the permanent ownership of the tangible components of the train. Services (by comparison with goods) can also be viewed as a spectrum. Not all products are pure goods, nor are all pure services. The aforementioned example of a train ride can be deemed a pure service, whilst a packet of potato chips can be deemed a pure good. An intermediary example may be a restaurant (as the waiter service is intangible, and the food evidently is tangible in form).

436

See also
Outline of marketing Marketing acronyms Consumer behaviour Category:Types of marketing Advertising Product Pricing Promotion Distribution (Placement)

Segmentation Positioning Targeting

References
[1] Kotler, Philip; Gary Armstrong, Veronica Wong, John Saunders (2008). "Marketing defined" (http:/ / books. google. com/ books?id=6T2R0_ESU5AC& lpg=PP1& pg=PA7#v=onepage& q=& f=true). Principles of marketing (5th ed.). p.7. . Retrieved 2009-10-23. [2] Kotler, Philip; Gary Armstrong, Veronica Wong, John Saunders (2008). "Marketing defined" (http:/ / books. google. com/ books?id=6T2R0_ESU5AC& lpg=PP1& pg=PA7#v=onepage& q=& f=true). Principles of marketing (5th ed.). p.17. . Retrieved 2009-10-23. [3] "Definition of Marketing" (http:/ / www. marketingpower. com/ AboutAMA/ Pages/ DefinitionofMarketing. aspx). American Marketing Association. . Retrieved 2009-10-30. [4] Paul H. Selden (1997). Sales Process Engineering: A Personal Workshop. Milwaukee, WI. p.23. [5] "Definition of marketing" (http:/ / www. cim. co. uk/ resources/ understandingmarket/ definitionmkting. aspx). Chartered Institute of Marketing. . Retrieved 2009-10-30. [6] Paliwoda, Stanley J.; John K. Ryans. "Back to first principles" (http:/ / books. google. com/ books?id=dwZz2eHBCjUC& lpg=PP1& pg=PA25#v=onepage& q=& f=false). International Marketing: Modern and Classic Papers (1st ed.). p.25. . Retrieved 2009-10-15. [7] Kotler, Philip; Kevin Lane Keller (2009). "1". A Framework for Marketing Management (4th ed.). Pearson Prentice Hall. ISBN0136026605. [8] Adcock, Dennis; Al Halborg, Caroline Ross (2001). "Introduction" (http:/ / books. google. com/ books?id=hQ8XfLd1cGwC& lpg=PP1& pg=PA15#v=onepage& q=& f=true). Marketing: principles and practice (4th ed.). p.15. . Retrieved 2009-10-23. [9] Adcock, Dennis; Al Halborg, Caroline Ross (2001). "Introduction" (http:/ / books. google. com/ books?id=hQ8XfLd1cGwC& lpg=PP1& pg=PA16#v=onepage& q=& f=true). Marketing: principles and practice (4th ed.). p.16. . Retrieved 2009-10-23. [10] "Marketing Management: Strategies and Programs", Guiltinan et al., McGraw Hill/Irwin, 1996 [11] Dev, Chekitan S.; Don E. Schultz (January/February 2005). "In the Mix: A Customer-Focused Approach Can Bring the Current Marketing Mix into the 21st Century". Marketing Management 14 (1). [12] "Swarming the shelves: How shops can exploit people's herd mentality to increase sales?". The Economist. 2006-11-11. p.90. [13] Joshi, Rakesh Mohan, (2005) International Marketing, Oxford University Press, New Delhi and New York ISBN 0195671236 [14] "Chapter 6: ORGANIZATIONAL MARKETS AND BUYER BEHAVIOR" (http:/ / www-rohan. sdsu. edu/ ~renglish/ 370/ notes/ chapt06/ index. htm). Rohan.sdsu.edu. . Retrieved 2010-03-06. [15] "Services Marketing" (http:/ / www. marketingteacher. com/ Lessons/ lesson_services_marketing. htm). Marketingteacher.com. . Retrieved 2010-03-06.

System

437

System
System (from Latin systma, in turn from Greek systma, "whole compounded of several parts or members, system", literary "composition"[1] ) is a set of interacting or interdependent entities forming an integrated whole. The concept of an 'integrated whole' can also be stated in terms of a system embodying a set of relationships which are differentiated from relationships of the set to other elements, and from relationships between an element of the set and elements not a part of the relational regime. The scientific research field which is engaged in the study of the general properties of systems include A schematic representation of a closed system and its boundary systems theory, cybernetics, dynamical systems and complex systems. They investigate the abstract properties of the matter and organization, searching concepts and principles which are independent of the specific domain, substance, type, or temporal scales of existence. Most systems share common characteristics, including: Systems have structure, defined by parts and their composition; Systems have behavior, which involves inputs, processing and outputs of material, energy or information; Systems have interconnectivity: the various parts of a system have functional as well as structural relationships between each other. Systems have by themselves functions or groups of functions The term system may also refer to a set of rules that governs behavior or structure.

History
The word system in its meaning here, has a long history which can be traced back to Plato (Philebus), Aristotle (Politics) and Euclid (Elements). It had meant "total", "crowd" or "union" in even more ancient times, as it derives from the verb sunstemi, uniting, putting together. In the 19th century the first to develop the concept of a "system" in the natural sciences was the French physicist Nicolas Lonard Sadi Carnot who studied thermodynamics. In 1824 he studied what he called the working substance (system), i.e. typically a body of water vapor, in steam engines, in regards to the system's ability to do work when heat is applied to it. The working substance could be put in contact with either a boiler, a cold reservoir (a stream of cold water), or a piston (to which the working body could do work by pushing on it). In 1850, the German physicist Rudolf Clausius generalized this picture to include the concept of the surroundings and began to use the term "working body" when referring to the system. One of the pioneers of the general systems theory was the biologist Ludwig von Bertalanffy. In 1945 he introduced models, principles, and laws that apply to generalized systems or their subclasses, irrespective of their particular kind, the nature of their component elements, and the relation or 'forces' between them.[2] Significant development to the concept of a system was done by Norbert Wiener and Ross Ashby who pioneered the use of mathematics to study systems [3] [4] .

System In the 1980s the term complex adaptive system was coined at the interdisciplinary Santa Fe Institute by John H. Holland, Murray Gell-Mann and others.

438

System concepts
Environment and boundaries Systems theory views the world as a complex system of interconnected parts. We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside - part of the environment. We then make simplified representations (models) of the system in order to understand it and to predict or impact its future behavior. These models may define the structure and/or the behavior of the system. Natural and man-made systems There are natural and man-made (designed) systems. Natural systems may not have an apparent objective but their outputs can be interpreted as purposes. Man-made systems are made with purposes that are achieved by the delivery of outputs. Their parts must be related; they must be designed to work as a coherent entity - else they would be two or more distinct systems Theoretical Framework An open system exchanges matter and energy with its surroundings. Most systems are open systems; like a car, coffeemaker, or computer. A closed system exchanges energy, but not matter, with its environment; like Earth or the project Biosphere2 or 3. An isolated system exchanges neither matter nor energy with its environment; a theoretical example of which would be the universe. Process and transformation process A system can also be viewed as a bounded transformation process, that is, a process or collection of processes that transforms inputs into outputs. Inputs are consumed; outputs are produced. The concept of input and output here is very broad. E.g., an output of a passenger ship is the movement of people from departure to destination. Subsystem A subsystem is a set of elements, which is a system itself, and a part of a larger system.

Types of systems
Evidently, there are many types of systems that can be analyzed both quantitatively and qualitatively. For example, with an analysis of urban systems dynamics, [A.W. Steiss] [5] defines five intersecting systems, including the physical subsystem and behavioral system. For sociological models influenced by systems theory, where Kenneth D. Bailey [6] defines systems in terms of conceptual, concrete and abstract systems; either isolated, closed, or open, Walter F. Buckley [7] defines social systems in sociology in terms of mechanical, organic, and process models. Bela H. Banathy [8] cautions that with any inquiry into a system that understanding the type of system is crucial and defines Natural and Designed systems. In offering these more global definitions, the author maintains that it is important not to confuse one for the other. The theorist explains that natural systems include sub-atomic systems, living systems, the solar system, the galactic system and the Universe. Designed systems are our creations, our physical structures, hybrid systems which include natural and designed systems, and our conceptual knowledge. The human element of organization and activities are emphasized with their relevant abstract systems and representations. A key consideration in making distinctions among various types of systems is to determine how much freedom the system has to select purpose, goals, methods, tools, etc. and how widely is the freedom to select itself distributed (or concentrated) in the system. George J. Klir [9] maintains that no "classification is complete and perfect for all purposes," and defines systems in terms of abstract, real, and conceptual physical systems, bounded and unbounded systems, discrete to continuous,

System pulse to hybrid systems, et cetera. The interaction between systems and their environments are categorized in terms of relatively closed, and open systems. It seems most unlikely that an absolutely closed system can exist or, if it did, that it could be known by us. Important distinctions have also been made between hard and soft systems.[10] Hard systems are associated with areas such as systems engineering, operations research and quantitative systems analysis. Soft systems are commonly associated with concepts developed by Peter Checkland and Brian Wilson through Soft Systems Methodology (SSM) involving methods such as action research and emphasizing participatory designs. Where hard systems might be identified as more "scientific," the distinction between them is actually often hard to define.

439

Cultural system
A cultural system may be defined as the interaction of different elements of culture. While a cultural system is quite different from a social system, sometimes both systems together are referred to as the sociocultural system. A major concern in the social sciences is the problem of order. One way that social order has been theorized is according to the degree of integration of cultural and social factors.

Economic system
An economic system is a mechanism (social institution) which deals with the production, distribution and consumption of goods and services in a particular society. The economic system is composed of people, institutions and their relationships to resources, such as the convention of property. It addresses the problems of economics, like the allocation and scarcity of resources.

Application of the system concept

Systems modeling is generally a basic principle in engineering and in social sciences. The system is the representation of the entities under concern. Hence inclusion to or exclusion from system context is dependent of the intention of the modeler. No model of a system will include all features of the real system of concern, and no model of a system must include all entities belonging to a real system of concern.

Systems in information and computer science

In computer science and information science, system could also be a method or an algorithm. Again, an example will illustrate: There are systems of counting, as with Roman numerals, and various systems for filing papers, or catalogues, and various library systems, of which the Dewey Decimal System is an example. This still fits with the definition of components which are connected together (in this case in order to facilitate the flow of information). System can also be used referring to a framework, be it software or hardware, designed to allow software programs to run, see platform.

System

440

Systems in engineering and physics

In engineering and physics, a physical system is the portion of the universe that is being studied (of which a thermodynamic system is one major example). Engineering also has the concept of a system that refers to all of the parts and interactions between parts of a complex project. Systems engineering refers to the branch of engineering that studies how this type of system should be planned, designed, implemented, built, and maintained.

Systems in social and cognitive sciences and management research

Social and cognitive sciences recognize systems in human person models and in human societies. They include human brain functions and human mental processes as well as normative ethics systems and social/cultural behavioral patterns. In management science, operations research and organizational development (OD), human organizations are viewed as systems (conceptual systems) of interacting components such as subsystems or system aggregates, which are carriers of numerous complex processes and organizational structures. Organizational development theorist Peter Senge developed the notion of organizations as systems in his book The Fifth Discipline. Systems thinking is a style of thinking/reasoning and problem solving. It starts from the recognition of system properties in a given problem. It can be a leadership competency. Some people can think globally while acting locally. Such people consider the potential consequences of their decisions on other parts of larger systems. This is also a basis of systemic coaching in psychology. Organizational theorists such as Margaret Wheatley have also described the workings of organizational systems in new metaphoric contexts, such as quantum physics, chaos theory, and the self-organization of systems.

Systems applied to strategic thinking

In 1988, military strategist, John A. Warden III introduced his Five Ring System model in his book, The Air Campaign contending that any complex system could be broken down into five concentric rings. Each ringLeadership, Processes, Infrastructure, Population and Action Unitscould be used to isolate key elements of any system that needed change. The model was used effectively by Air Force planners in the First Gulf War.[11] ,[12] ,[13] . In the late 1990s, Warden applied this five ring model to business strategy[14] .

See also
Examples of systems List of systems (WikiProject) Complex system Formal system Information system Meta-system Solar System Systems in human anatomy Theories about systems Chaos theory Cybernetics Systems ecology Systems engineering Systems psychology Systems theory Related topics Glossary of systems theory Complexity theory and organizations Network (disambiguation) System of systems (engineering) Systems art

System

441

Further reading
Alexander Backlund (2000). "The definition of system". In: Kybernetes Vol. 29 nr. 4, pp.444451. Kenneth D. Bailey (1994). Sociology and the New Systems Theory: Toward a Theoretical Synthesis. New York: State of New York Press. Bela H. Banathy (1997). "A Taste of Systemics" [15], ISSS The Primer Project. Walter F. Buckley (1967). Sociology and Modern Systems Theory, New Jersey: Englewood Cliffs. Peter Checkland (1997). Systems Thinking, Systems Practice. Chichester: John Wiley & Sons, Ltd. Robert L. Flood (1999). Rethinking the Fifth Discipline: Learning within the unknowable. London: Routledge. George J. Klir (1969). Approach to General Systems Theory, 1969. Brian Wilson (1980). Systems: Concepts, methodologies and Applications, John Wiley Brian Wilson (2001). Soft Systems MethodologyConceptual model building and its contribution, J.H.Wiley. Beynon-Davies P. (2009). Business Information + Systems. Palgrave, Basingstoke. ISBN 978-0-230-20368-6

External links
Definitions of Systems and Models [16] by Michael Pidwirny, 1999-2007. Definitionen von "System" (1572-2002) [17] by Roland Mller, 2001-2007 (most in German).

References
[1] (http:/ / www. perseus. tufts. edu/ hopper/ text?doc=Perseus:text:1999. 04. 0057:entry=su/ sthma), Henry George Liddell, Robert Scott, A Greek-English Lexicon, on Perseus Digital Library [2] 1945, Zu einer allgemeinen Systemlehre, Bltter fr deutsche Philosophie, 3/4. (Extract in: Biologia Generalis, 19 (1949), 139-164. [3] 1948, Cybernetics: Or the Control and Communication in the Animal and the Machine. Paris, France: Librairie Hermann & Cie, and Cambridge, MA: MIT Press.Cambridge, MA: MIT Press. [4] 1956. An Introduction to Cybernetics (http:/ / pespmc1. vub. ac. be/ ASHBBOOK. html), Chapman & Hall. [5] Steiss 1967, p.8-18. [6] Bailey, 1994. [7] Buckley, 1967. [8] Banathy, 1997. [9] Klir 1969, pp. 69-72 [10] Checkland 1997; Flood 1999. [11] Warden, John A. III (1988). The Air Campaign: Planning for Combat. Washington, D.C.: National Defense University Press. ISBN9781583481004. [12] Warden, John A. III (September 1995). "Chapter 4: Air theory for the 21st century" (http:/ / www. airpower. maxwell. af. mil/ airchronicles/ battle/ chp4. html) (in Air and Space Power Journal). Battlefield of the Future: 21st Century Warfare Issues. United States Air Force. . Retrieved December 26, 2008. [13] Warden, John A. III (1995). "Enemy as a System" (http:/ / www. airpower. maxwell. af. mil/ airchronicles/ apj/ apj95/ spr95_files/ warden. htm). Airpower Journal Spring (9): 4055. . Retrieved 2009-03-25. [14] Russell, Leland A.; Warden, John A. (2001). Winning in FastTime: Harness the Competitive Advantage of Prometheus in Business and in Life. Newport Beach, CA: GEO Group Press. ISBN0971269718. [15] http:/ / www. newciv. org/ ISSS_Primer/ asem04bb. html [16] http:/ / www. physicalgeography. net/ fundamentals/ 4b. html [17] http:/ / www. muellerscience. com/ SPEZIALITAETEN/ System/ System_Definitionen. htm

Change management

442

Change management
Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. The field of change management grew from the recognition that organizations are composed of people. And the behaviors of people make up the outputs of an organization.

Types of Organizational Change

1. 2. 3. 4. Strategic changes Technological changes Structural changes Changing the attitudes and behaviors of personnel

As a multidisciplinary practice, Organizational Change Management requires for example: creative marketing to enable communication between change audiences, but also deep social understanding about leaderships styles and group dynamics. As a visible track on transformation projects, Organizational Change Management aligns groups expectations, communicates, integrates teams and manages people training. It makes use of metrics, such as leaders commitment, communication effectiveness, and the perceived need for change to design accurate strategies, in order to avoid change failures or solve troubled change projects. An effective change management plan needs to address all above mentioned dimensions of change. This can be achieved in following ways: 1. Putting in place an effective Communication strategy which would bridge any gap in the understanding of change benefits and its implementation strategy. 2. Devise an effective skill upgradation scheme for the organization. Overall these measures can counter resistance from the employees of companies and align them to overall strategic direction of the organization. 3. Personnel counselling of staff members (if required) to alleviate any change related fears.

Software development

443

Software development
Software development is the act of working to produce/create software. This software could be produced for a variety of purposes - the three most common purposes are to meet specific needs of a specific client/business, to meet a perceived need of some set of potential users (the case with commercial and open source software), or for personal use (e.g. a scientist may write software to automate a mundane task). The term software development is often used to refer to the activity of computer programming, which is the process of writing and maintaining the source code, whereas the broader sense of the term includes all that is involved between the conception of the desired software through to the final manifestation of the software. Therefore, software development may include research, new development, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.[1] For larger software systems, usually developed by a team of people, some form of process is typically followed to guide the stages of production of the software. Especially the first phase in the software development process may involve many departments, including marketing, engineering, research and development and general management.[2]

Overview
There are several different approaches to software development, much like the various views of political parties toward governing a country. Some take a more structured, engineering-based approach to developing business solutions, whereas others may take a more incremental approach, where software evolves as it is developed piece-by-piece. Most methodologies share some combination of the following stages of software development: Market research Gathering requirements for the proposed business solution Analyzing the problem Devising a plan or design for the software-based solution Implementation (coding) of the software Testing the software Development Maintenance and bug fixing

These stages are often referred to collectively as the software development lifecycle, or SDLC. Different approaches to software development may carry out these stages in different orders, or devote more or less time to different stages. The level of detail of the documentation produced at each stage of software development may also vary. These stages may also be carried out in turn (a waterfall based approach), or they may be repeated over various cycles or iterations (a more "extreme" approach). The more extreme approach usually involves less time spent on planning and documentation, and more time spent on coding and development of automated tests. More extreme approaches also promote continuous testing throughout the development lifecycle, as well as having a working (or bug-free) product at all times. More structured or waterfall based approaches attempt to assess the majority of risks and develop a detailed plan for the software before implementation (coding) begins, and avoid significant design changes and re-coding in later stages of the software development lifecycle. There are significant advantages and disadvantages to the various methodologies, and the best approach to solving a problem using software will often depend on the type of problem. If the problem is well understood and a solution can be effectively planned out ahead of time, the more "waterfall" based approach may work the best. If, on the other hand, the problem is unique (at least to the development team) and the structure of the software solution cannot be easily envisioned, then a more "extreme" incremental approach may work best. A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities

Software development that take place during the process.

444

Software development topic

Marketing
The sources of ideas for software products are legion.[2] These ideas can come from market research including the demographics of potential new customers, existing customers, sales prospects who rejected the product, other internal software development staff, or a creative third party. Ideas for software products are usually first evaluated by marketing personnel for economic feasibility, for fit with existing channels distribution, for possible effects on existing product lines, required features, and for fit with the company's marketing objectives. In a marketing evaluation phase, the cost and time assumptions become evaluated. A decision is reached early in the first phase as to whether, based on the more detailed information generated by the marketing and development staff, the project should be pursued further.[2] In the book "Great Software Debates", Alan M. Davis states in the chapter "Requirements", subchapter "The Missing Piece of Software Development":

Students of engineering learn engineering and are rarely exposed to finance or marketing. Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to the development [3] success and absolutely requires knowledge of multiple disciplines.

Because software development may involve compromising or going beyond what is required by the client, a software development project may stray into less technical concerns such as human resources, risk management, intellectual property, budgeting, crisis management, etc. These processes may also cause the role of business development to overlap with software development.

Software development methodology

A software development methodology is a framework that is used to structure, plan, and control the process of developing information systems. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.[4]

Recent trends in the sector

The end of the 1990 provided W3C standards[5] which enabled ontologies to unite 4 modelling functions in 1 knowledge model: the knowledge representation (in RDF(S) and OWL), the knowledge generation through inferences, the conceptual model through ontologies and the physical model through triple stores. The latest developments allow to generate applications straight from the knowledge systems (ontologies)[6] . This approach finds its justification in the use of semantic technologies with substitution of www data with verified production data. One business case for this development method is available at the finance ontology website [7].

Software development

445

See also
Alliances between product software firms Application software Aspect-Oriented Software Development Bachelor of Science in Information Technology Computer programmer Consulting software engineer Custom software development Incremental funding methodology Functional specification Marketing strategies for product software Offshore software development Search Based Software Engineering Service-Oriented Modeling Framework Software blueprint Software company Software design Software developer Software development effort estimation Software development process Software distribution Software engineer CMM Programming language Software engineering economics Software industry Software project management Software publisher Software user experience design System software Video game development Web application development Web development

Further reading
Jim McCarthy (1995). Dynamics of Software Development. Dan Conde (2002). Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales. A.M. Davis (2005). Just enough requirements management: where software development meets marketing. Edward Hasted. (2005). Software That Sells : A Practical Guide to Developing and Marketing Your Software Project. Luke Hohmann (2003). Beyond Software Architecture: Creating and Sustaining Winning Solutions. John W. Horch (2005). "Two Orientations On How To Work With Objects." In: IEEE Software. vol. 12, no. 2, pp.117118, Mar., 1995. John Rittinghouse (2003). Managing Software Deliverables: A Software Development Management Methodology. Karl E. Wiegers (2005). More About Software Requirements: Thorny Issues and Practical Advice. Robert K. Wysocki (2006). Effective Software Project Management.

References
[1] [2] [3] [4] DRM Associates (2002). "New Product Development Glossary" (http:/ / www. npd-solutions. com/ glossary. html). . Retrieved 2006-10-29. Joseph M. Morris (2001). Software Industry Accounting. p.1.10 Alan M. Davis. Great Software Debates (October 8, 2004), pp:125-128 Wiley-IEEE Computer Society Press Selecting a development approach (http:/ / www. cms. hhs. gov/ SystemLifecycleFramework/ Downloads/ SelectingDevelopmentApproach. pdf). Revalidated: March 27, 2008. Retrieved 27 Oct 2008. [5] Standards on RDF (http:/ / www. w3. org/ RDF/ ) and recommendations on OWL (http:/ / www. w3. org/ 2004/ OWL/ ) [6] See the finance semantic web application (http:/ / www. fadyart. com/ applications. html) [7] http:/ / www. fadyart. com/ businesscase. html

Management

446

Management
Management in all business areas and organizational activities are the acts of getting people together to accomplish desired goals and objectives. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. Resourcing encompasses the deployment and manipulation of human resources, financial resources, technological resources, and natural resources. Because organizations can be viewed as systems, management can also be defined as human action, including design, to facilitate the production of useful outcomes from a system. This view opens the opportunity to 'manage' oneself, a pre-requisite to attempting to manage others Management can also refer to the person or people who perform the act(s) of management.

History
The verb manage comes from the Italian maneggiare (to handle especially tools), which in turn derives from the Latin manus (hand). The French word mesnagement (later mnagement) influenced the development in meaning of the English word management in the 17th and 18th centuries.[1] Some definitions of management are: Organisation and coordination of the activities of an enterprise in accordance with certain policies and in achievement of clearly defined objectives. Management is often included as a factor of production along with machines, materials, and money. According to the management guru Peter Drucker (19092005), the basic task of a management is twofold: marketing and innovation. Directors and managers who have the power and responsibility to make decisions to manage an enterprise. As a discipline, management comprises the interlocking functions of formulating corporate policy and organizing, planning, controlling, and directing the firm's resources to achieve the policy's objectives. The size of management can range from one person in a small firm to hundreds or thousands of managers in multinational companies. In large firms the board of directors formulates the policy which is implemented by the chief executive officer.

Theoretical scope
Mary Parker Follett (18681933), who wrote on the topic in the early twentieth century, defined management as "the art of getting things done through people". She also described management as philosophy.[2] One can also think of management functionally, as the action of measuring a quantity on a regular basis and of adjusting some initial plan; or as the actions taken to reach one's intended goal. This applies even in situations where planning does not take place. From this perspective, Frenchman Henri Fayol[3] considers management to consist of seven functions: 1. 2. 3. 4. 5. 6. 7. planning organizing leading coordinating controlling staffing motivating

Some people, however, find this definition, while useful, far too narrow. The phrase "management is what managers do" occurs widely, suggesting the difficulty of defining management, the shifting nature of definitions, and the connection of managerial practices with the existence of a managerial cadre or class.

Management One habit of thought regards management as equivalent to "business administration" and thus excludes management in places outside commerce, as for example in charities and in the public sector. More realistically, however, every organization must manage its work, people, processes, technology, etc. in order to maximize its effectiveness. Nonetheless, many people refer to university departments which teach management as "business schools." Some institutions (such as the Harvard Business School) use that name while others (such as the Yale School of Management) employ the more inclusive term "management." English speakers may also use the term "management" or "the management" as a collective word describing the managers of an organization, for example of a corporation. Historically this use of the term was often contrasted with the term "Labor" referring to those being managed.

447

Nature of managerial work

In for-profit work, management has as its primary function the satisfaction of a range of stakeholders. This typically involves making a profit (for the shareholders), creating valued products at a reasonable cost (for customers), and providing rewarding employment opportunities (for employees). In nonprofit management, add the importance of keeping the faith of donors. In most models of management/governance, shareholders vote for the board of directors, and the board then hires senior management. Some organizations have experimented with other methods (such as employee-voting models) of selecting or reviewing managers; but this occurs only very rarely. In the public sector of countries constituted as representative democracies, voters elect politicians to public office. Such politicians hire many managers and administrators, and in some countries like the United States political appointees lose their jobs on the election of a new president/governor/mayor.

Historical development
Difficulties arise in tracing the history of management. Some see it (by definition) as a late modern (in the sense of late modernity) conceptualization. On those terms it cannot have a pre-modern history, only harbingers (such as stewards). Others, however, detect management-like-thought back to Sumerian traders and to the builders of the pyramids of ancient Egypt. Slave-owners through the centuries faced the problems of exploiting/motivating a dependent but sometimes unenthusiastic or recalcitrant workforce, but many pre-industrial enterprises, given their small scale, did not feel compelled to face the issues of management systematically. However, innovations such as the spread of Arabic numerals (5th to 15th centuries) and the codification of double-entry book-keeping (1494) provided tools for management assessment, planning and control. Given the scale of most commercial operations and the lack of mechanized record-keeping and recording before the industrial revolution, it made sense for most owners of enterprises in those times to carry out management functions by and for themselves. But with growing size and complexity of organizations, the split between owners (individuals, industrial dynasties or groups of shareholders) and day-to-day managers (independent specialists in planning and control) gradually became more common.

Early writing
While management has been present for millennia, several writers have created a background of works that assisted in modern management theories.[4] Sun Tzu's The Art of War Written by Chinese general Sun Tzu in the 6th century BC, The Art of War is a military strategy book that, for managerial purposes, recommends being aware of and acting on strengths and weaknesses of both a manager's organization and a foe's.[4]

Management Niccol Machiavelli's The Prince Believing that people were motivated by self-interest, Niccol Machiavelli wrote The Prince in 1513 as advice for the leadership of Florence, Italy.[5] Machiavelli recommended that leaders use fearbut not hatredto maintain control. Adam Smith's The Wealth of Nations Written in 1776 by Adam Smith, a Scottish moral philosopher, The Wealth of Nations aims for efficient organization of work through Specialization of labor.[5] Smith described how changes in processes could boost productivity in the manufacture of pins. While individuals could produce 200 pins per day, Smith analyzed the steps involved in manufacture and, with 10 specialists, enabled production of 48,000 pins per day.[5]

448

19th century
Classical economists such as Adam Smith (1723 - 1790) and John Stuart Mill (1806 - 1873) provided a theoretical background to resource-allocation, production, and pricing issues. About the same time, innovators like Eli Whitney (1765 - 1825), James Watt (1736 - 1819), and Matthew Boulton (1728 - 1809) developed elements of technical production such as standardization, quality-control procedures, cost-accounting, interchangeability of parts, and work-planning. Many of these aspects of management existed in the pre-1861 slave-based sector of the US economy. That environment saw 4 million people, as the contemporary usages had it, "managed" in profitable quasi-mass production. By the late 19th century, marginal economists Alfred Marshall (1842 - 1924), Lon Walras (1834 - 1910), and others introduced a new layer of complexity to the theoretical underpinnings of management. Joseph Wharton offered the first tertiary-level course in management in 1881.

20th century
By about 1900 one finds managers trying to place their theories on what they regarded as a thoroughly scientific basis (see scientism for perceived limitations of this belief). Examples include Henry R. Towne's Science of management in the 1890s, Frederick Winslow Taylor's The Principles of Scientific Management (1911), Frank and Lillian Gilbreth's Applied motion study (1917), and Henry L. Gantt's charts (1910s). J. Duncan wrote the first college management textbook in 1911. In 1912 Yoichi Ueno introduced Taylorism to Japan and became first management consultant of the "Japanese-management style". His son Ichiro Ueno pioneered Japanese quality assurance. The first comprehensive theories of management appeared around 1920. The Harvard Business School invented the Master of Business Administration degree (MBA) in 1921. People like Henri Fayol (1841 - 1925) and Alexander Church described the various branches of management and their inter-relationships. In the early 20th century, people like Ordway Tead (1891 - 1973), Walter Scott and J. Mooney applied the principles of psychology to management, while other writers, such as Elton Mayo (1880 - 1949), Mary Parker Follett (1868 - 1933), Chester Barnard (1886 1961), Max Weber (1864 - 1920), Rensis Likert (1903 - 1981), and Chris Argyris (1923 - ) approached the phenomenon of management from a sociological perspective. Peter Drucker (1909 2005) wrote one of the earliest books on applied management: Concept of the Corporation (published in 1946). It resulted from Alfred Sloan (chairman of General Motors until 1956) commissioning a study of the organisation. Drucker went on to write 39 books, many in the same vein. H. Dodge, Ronald Fisher (1890 - 1962), and Thornton C. Fry introduced statistical techniques into management-studies. In the 1940s, Patrick Blackett combined these statistical theories with microeconomic theory and gave birth to the science of operations research. Operations research, sometimes known as "management science" (but distinct from Taylor's scientific management), attempts to take a scientific approach to solving management problems, particularly in the areas of logistics and operations.

Management Some of the more recent developments include the Theory of Constraints, management by objectives, reengineering, Six Sigma and various information-technology-driven theories such as agile software development, as well as group management theories such as Cog's Ladder. As the general recognition of managers as a class solidified during the 20th century and gave perceived practitioners of the art/science of management a certain amount of prestige, so the way opened for popularised systems of management ideas to peddle their wares. In this context many management fads may have had more to do with pop psychology than with scientific theories of management. Towards the end of the 20th century, business management came to consist of six separate branches, namely: Human resource management Operations management or production management Strategic management Marketing management Educational management Financial management Information technology management responsible for management information systems

449

21st century
In the 21st century observers find it increasingly difficult to subdivide management into functional categories in this way. More and more processes simultaneously involve several categories. Instead, one tends to think in terms of the various processes, tasks, and objects subject to management. Branches of management theory also exist relating to nonprofits and to government: such as public administration, public management, and educational management. Further, management programs related to civil-society organizations have also spawned programs in nonprofit management and social entrepreneurship. Note that many of the assumptions made by management have come under attack from business ethics viewpoints, critical management studies, and anti-corporate activism. As one consequence, workplace democracy has become both more common, and more advocated, in some places distributing all management functions among the workers, each of whom takes on a portion of the work. However, these models predate any current political issue, and may occur more naturally than does a command hierarchy. All management to some degree embraces democratic principles in that in the long term workers must give majority support to management; otherwise they leave to find other work, or go on strike. Despite the move toward workplace democracy, command-and-control organization structures remain commonplace and the de facto organization structure. Indeed, the entrenched nature of command-and-control can be seen in the way that recent layoffs have been conducted with management ranks affected far less than employees at the lower levels of organizations. In some cases, management has even rewarded itself with bonuses when lower level employees have been laid off.[6]

Management

450

Management topics
Basic functions of management
Management operates through various functions, often classified as planning, organizing, leading/directing, and controlling/monitoring. Planning: Deciding what needs to happen in the future (today, next week, next month, next year, over the next 5 years, etc.) and generating plans for action. Organizing: (Implementation) making optimum use of the resources required to enable the successful carrying out of plans. Staffing: Job Analyzing, recruitment, and hiring individuals for appropriate jobs. Leading/Directing: Determining what needs to be done in a situation and getting people to do it. Controlling/Monitoring: Checking progress against plans. Motivation : motivation is also a kind in basic functions of management.. because without motivation employee cannot work effectively.. if motivation doesn't takes place in any organization planning,organizing,staffing,directing,monitoring may not follow perfectly by employees which is given by top level management.

Formation of the business policy

The mission of the business is its most obvious purpose -- which may be, for example, to make soap. The vision of the business reflects its aspirations and specifies its intended direction or future destination. The objectives of the business refers to the ends or activity at which a certain task is aimed. The business's policy is a guide that stipulates rules, regulations and objectives, and may be used in the managers' decision-making. It must be flexible and easily interpreted and understood by all employees. The business's strategy refers to the coordinated plan of action that it is going to take, as well as the resources that it will use, to realize its vision and long-term objectives. It is a guideline to managers, stipulating how they ought to allocate and utilize the factors of production to the business's advantage. Initially, it could help the managers decide on what type of business they want to form. How to implement policies and strategies All policies and strategies must be discussed with all managerial personnel and staff. Managers must understand where and how they can implement their policies and strategies. A plan of action must be devised for each department. Policies and strategies must be reviewed regularly. Contingency plans must be devised in case the environment changes. Assessments of progress ought to be carried out regularly by top-level managers. A good environment and team spirit is required within the business. The missions, objectives, strengths and weaknesses of each department must be analysed to determine their roles in achieving the business's mission. The forecasting method develops a reliable picture of the business's future environment. A planning unit must be created to ensure that all plans are consistent and that policies and strategies are aimed at achieving the same mission and objectives. All policies must be discussed with all managerial personnel and staff that is required in the execution of any departmental policy. Organizational change is strategically achieved through the implementation of the eight-step plan of action established by John P. Kotter: Increase urgency, get the vision right, communicate the buy-in, empower action, create short-term wins, don't let up, and make change stick.

Management
[7]

451

Where policies and strategies fit into the planning process They give mid- and lower-level managers a good idea of the future plans for each department in an organization. A framework is created whereby plans and decisions are made. Mid- and lower-level management may add their own plans to the business's strategic ones.

multi-divisional management hierarchy

The management of a large organization may have about five levels: 1. 2. 3. 4. 5. Senior management (or "top management" or "upper management") Middle management Low-level management, such as supervisors or team-leaders Foreman Rank and File

Top-level management Require an extensive knowledge of management roles and skills. They have to be very aware of external factors such as markets. Their decisions are generally of a long-term nature Their decisions are made using analytic, directive, conceptual and/or behavioral/participative processes They are responsible for strategic decisions. They have to chalk out the plan and see that plan may be effective in the future. They are executive in nature.

Middle management Mid-level managers have a specialized understanding of certain managerial tasks. They are responsible for carrying out the decisions made by top-level management. finance,marketing etc are comes under middle level management Lower management This level of management ensures that the decisions and plans taken by the other two are carried out. Lower-level managers' decisions are generally short-term ones. Foreman / lead hand They are people who have direct supervision over the working force in office factory, sales field or other workgroup or areas of activity. Rank and File The responsibilities of the persons belonging to this group are even more restricted and more specific than those of the foreman.

Areas and categories and implementations of management

Management

452

Accounting management Agile management Applied Engineering (field) Association management Capability Management Change management Conflict management Communication management Constraint management Cost management Crisis management Critical management studies Customer relationship management Decision making styles Design management Disaster management Distributed management Earned value management Educational management Engineering Management Environmental management Facility management Financial management

Forecasting Human resources management Hospital management Hospitality management Hotel management Information technology management Innovation management Interim management Inventory management Knowledge management Land management Leadership Logistics management Lifecycle management Marine fuel management Marketing management Materials management Office management Operations management Organization development Perception management Practice management Program management Project management

Process management Performance management Product management Public administration Public management Quality management Records management Relationship management Resource management Restaurant management Risk management Rural management Skills management Social entrepreneurship Spend management Strategic management Stress management Supply chain management Systems management Talent management Time management Technology Management Work Management

Commercial operations management

Management

453

See also
Articles Adhocracy Administration Certified Business Manager Collaboration Collaborative method Corporate governance Design management Engineering management Evidence-based management Forecasting Futures studies Growth Knowledge visualization Leadership Management consulting Management control Management cybernetics Management development Management fad Managerial Psychology Management science Management styles Management system Managerialism Micromanagement Macromanagement Middle management Music management Organizational Behavior Management Organizational studies Predictive analytics Project management Public administration Risk Risk management Team building Scientific management Senior management Social entrepreneurship Virtual management Peter Drucker's management by objectives Eliyahu M. Goldratt's Theory of Constraints Pointy Haired Boss a negative stereotype of managers Lists List of basic management topics List of management topics List of marketing topics List of human resource management topics List of economics topics List of finance topics List of accounting topics List of information technology management topics List of production topics List of business law topics List of business ethics, political economy, and philosophy of business topics List of business theorists List of economists Timeline of management techniques

External links
Management Courses [8] at MIT Sloan, OpenCourseWare Management Studies [9] A free tutorial for Management Students Research on Organizations: Bibliography Database and Maps [10] ATMAE [11] The Association for Technology, Management, and Applied Engineering

References
[1] [2] [3] [4] Oxford English Dictionary Vocational Business: Training, Developing and Motivating People by Richard Barrett - Business & Economics - 2003. - Page 51. Administration industrielle et gnrale - prvoyance organisation - commandment, coordination contrle, Paris : Dunod, 1966 Gomez-Mejia, Luis R.; David B. Balkin and Robert L. Cardy (2008). Management: People, Performance, Change, 3rd edition. New York, New York USA: McGraw-Hill. pp.19. ISBN978-0-07-302743-2. [5] Gomez-Mejia, Luis R.; David B. Balkin and Robert L. Cardy (2008). Management: People, Performance, Change, 3rd edition. New York, New York USA: McGraw-Hill. pp.20. ISBN978-0-07-302743-2. [6] Craig, S. (2009, January 29). Merrill Bonus Case Widens as Deal Struggles. Wall Street Journal. (http:/ / online. wsj. com/ article/ SB123318892645426723. html?mod=googlenews_wsj) [7] Kotter, John P. & Dan S. Cohen. (2002). The Heart of Change. Boston: Harvard Business School Publishing. [8] http:/ / ocw. mit. edu/ OcwWeb/ Sloan-School-of-Management/ index. htm [9] http:/ / www. managementstudyguide. com [10] http:/ / ot. cavarretta. com [11] http:/ / atmae. org

Requirements analysis

454

Requirements analysis
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Requirements analysis is critical to the success of a development project.[2] Requirements must be documented, actionable, measurable, testable, related to identified business needs or Requirements analysis is the first stage in the systems engineering process and software [1] opportunities, and defined to a level of development process. detail sufficient for system design. Requirements can be functional and non-functional.

Overview
Conceptually, requirements analysis includes three types of activity: Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications. Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.

Requirements analysis

455

Requirements engineering
Systematic requirements analysis is also known as requirements engineering.[3] It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance. Requirements Engineering can be divided into discrete chronological steps: Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modeling, Requirements validation, Requirements management.

Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems."[4] In some life cycle models, the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggests that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized.

Requirements analysis topics

Stakeholder identification
See Stakeholder analysis for a discussion of business uses. Stakeholders (SH) are persons or organizations (legal entities such as companies, standards bodies) which have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: anyone who operates the system (normal and maintenance operators) anyone who benefits from the system (functional, political, financial and social beneficiaries) anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product organizations which regulate aspects of the system (financial, safety, and other regulators) people or organizations opposed to the system (negative stakeholders; see also Misuse case) organizations responsible for systems which interface with the system under design those organizations who integrate horizontally with the organization for whom the analyst is designing the system

Requirements analysis

456

Stakeholder interviews
Stakeholder interviews are a common technique used in requirement analysis. These interviews may reveal requirements not previously envisioned as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.

Joint Requirements Development (JRD) Sessions

Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator, wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe and Business Analyst should be present to document the discussion. Utilizing the skills of a trained facilitator to guide the discussion frees the Business Analyst to focus on the requirements definition process. JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.

Contract-style requirement lists

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages. An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day. Strengths Provides a checklist of requirements. Provide a contract between the project sponsor(s) and developers. For a large system can provide a high level description. Weaknesses Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system. Such requirements lists abstract all the requirements and so there is little context This abstraction makes it impossible to see how the requirements fit or work together. This abstraction makes it difficult to prioritize requirements properly; while a list it does make it easy to prioritize each individual item, removing one item out of context can render an entire use case or business requirement useless. This abstraction increases the likelihood of misinterpreting the requirements; as more people read them, the number of (different) interpretations of the envisioned system increase. This abstraction means that it's extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil, as they say, is in the details. These lists create a false sense of mutual understanding between the stakeholders and developers. These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers can use these discovered requirements to renegotiate the terms and conditions in their favour.

Requirements analysis These requirements lists are no help in system design, since they do not lend themselves to application. Alternative to requirement lists As an alternative to the large, pre-defined requirement lists Agile Software Development uses User stories to define a requirement in every day language.

457

Measurable goals
Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.

Prototypes
In the mid-1980s, prototyping was seen as the best solution to the requirements analysis problem. Prototypes are Mockups of an application. Mockups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably. However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem: Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time. Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again. Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were. Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process. Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations. Prototypes can be flat diagrams (often referred to as Wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.

Requirements analysis

458

Use cases
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders. Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.

Software requirements specification

A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints). Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.

Types of Requirements
Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management:[1] Customer Requirements Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:[1] Operational distribution or deployment: Where will the system be used? Mission profile or scenario: How will the system accomplish its mission objective? Performance and related parameters: What are the critical system parameters to accomplish the mission? Utilization environments: How are the various system components to be used? Effectiveness requirements: How effective or efficient must the system be in performing its mission? Operational life cycle: How long will the system be in use by the user? Environment: What environments will the system be expected to operate in an effective manner?

Functional Requirements Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.[1] Non-functional Requirements Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. Performance Requirements

Requirements analysis The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.[1] Design Requirements The build to, code to, and buy to requirements for products and how to execute requirements for processes expressed in technical data packages and technical manuals.[1] Derived Requirements Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.[1] Allocated Requirements A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.[1] Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard.

459

Requirements analysis issues

Stakeholder issues
Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering: Users do not understand what they want or users don't have a clear idea of their requirements Users will not commit to a set of written requirements Users insist on new requirements after the cost and schedule have been fixed Communication with users is slow Users often do not participate in reviews or are incapable of doing so Users are technically unsophisticated Users do not understand the development process Users do not know about present technology

This may lead to the situation where user requirements keep changing even when system or product development has been started.

Engineer/developer issues
Possible problems caused by engineers and developers during requirements analysis are: Technical personnel and end users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied. Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client. Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly.

Requirements analysis

460

Attempted solutions
One attempted solution to communications problems has been to employ specialists in business or system analysis. Techniques introduced in the 1990s like prototyping, Unified Modeling Language (UML), use cases, and Agile software development are also intended as solutions to problems encountered with previous methods. Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer: electronic whiteboards to sketch application flows and test alternatives ability to capture business logic and data needs ability to generate high fidelity prototypes that closely imitate the final application interactivity capability to add contextual requirements and other comments ability for remote and distributed users to run and interact with the simulation

See also
Business analysis Business Analysis Body of Knowledge (BABOK) Business process reengineering Creative brief Design brief Information technology Data modeling Functional requirements Model-driven engineering Model Transformation Language Non-functional requirements Process architecture Process modeling Requirements elicitation Requirements management Requirements Traceability Search Based Software Engineering Software prototyping Software Requirements Specification Systems analysis System requirements

Further reading
Laplante, Phil (2009). Requirements Engineering for Software and Systems [5] (1st ed.). Redmond, WA: CRC Press. ISBN1-42006-467-3. McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules [6] (1st ed.). Redmond, WA: Microsoft Press. ISBN1-55615-900-5. Wiegers, Karl E. (2003). Software Requirements [7] (2nd ed.). Redmond, WA: Microsoft Press. ISBN0-7356-1879-8. Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management [8]. Cambridge, MA: O'Reilly Media. ISBN0-596-00948-8. Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer (2009). Software & Systems Requirements Engineering: In Practice [9]. New York: McGraw-Hill Professional. ISBN0-07-1605479. Walter Sobkiw (2008). Sustainable Development Possible with Creative System Engineering [10]. New Jersey: CassBeth. ISBN0615216307.

Requirements analysis

461

External links
Requirements Engineering Process "Goodies" [11] Requirements Engineering: A Roadmap [12] (PDF) article by Bashar Nuseibeh and Steve Easterbrook, 2000.

References
[1] Systems Engineering Fundamentals. (http:/ / www. dau. mil/ pubscats/ PubsCats/ SEFGuide 01-01. pdf) Defense Acquisition University Press, 2001 [2] Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, ed (March 2005). "Chapter 2: Software Requirements" (http:/ / www. swebok. org/ ch2. html). Guide to the software engineering body of knowledge (http:/ / www. swebok. org) (2004 ed.). Los Alamitos, CA: IEEE Computer Society Press. ISBN0-7695-2330-7. . Retrieved 2007-02-08. "It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly." [3] Wiegers, Karl E. (2003). Software Requirements (http:/ / www. processimpact. com) (2nd ed.). Redmond, WA: Microsoft Press. ISBN0-7356-1879-8. . [4] Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44. [5] http:/ / beta. crcpress. com/ product/ isbn/ 9781420064674 [6] http:/ / www. stevemcconnell. com/ [7] http:/ / www. processimpact. com [8] http:/ / www. stellman-greene. com [9] http:/ / www. mhprofessional. com [10] http:/ / books. google. com/ books?id=7WJppXs-LzEC [11] http:/ / www. processimpact. com/ goodies. shtml#reqs [12] http:/ / www. cs. toronto. edu/ ~sme/ papers/ 2000/ ICSE2000. pdf

Program management
Program management or programme management is the process of managing several related projects, often with the intention of improving an organization's performance. In practice and in its aims it is often closely related to Systems engineering. There are two different views of how programs differ from projects. On one view, projects deliver outputs, discrete parcels or "chunks" of change.[1] . ; programs create outcomes.[2] . On this view, a project might deliver a new factory, hospital or IT system. By combining these projects with other deliverables and changes, their programs might deliver increased income from a new product, shorter waiting lists at the hospital or reduced operating costs due to improved technology. The other view[3] is that a program is nothing more than either a large project or a set (or portfolio) of projects. On this second view, the point of having a program is to exploit economies of scale and to reduce coordination costs and risks. The project manager's job is to ensure that their project succeeds. The programme manager, on the other hand, may not care about individual projects, but is concerned with the aggregate result or end-state. For example, in a financial institution a programme may include one project that is designed to take advantage of a rising market, and another to protect against the downside of a falling market. These projects are opposites with respect to their success conditions, but they fit together in the same programme. According to the view that programs deliver outcomes but projects deliver outputs, program management is concerned with doing the right projects. The programme manager has been described as 'playing chess' and keeping the overview in mind. The pieces to be used or sacrificed being the projects.[4] Whereas project management is about doing projects right. And also according to this view, successful projects deliver on time, to budget and to specification, whereas successful programmes deliver long term improvements to an organization. Improvements are usually identified through benefits. An organization should select the group of programs that most take it towards its strategic aims whilst remaining within its capacity to deliver the changes. On the other hand, the view that programs are simply large projects or a set of projects allows that a program may need to deliver tangible benefits quickly.

Program management Consider the following set of projects: design of the new product - this delivers a design specification, modifications to the production line or factory - delivers a manufacturing capability, marketing - delivers advertisements, brochures and pamphlets, staff training - delivers staff trained to sell and support the new product.

462

One view has it that these are different projects within a program. But in practice they can just as well be managed as sub-projects within a single project. Which approach to choose? Programme and project management are both practical disciplines, and the answer to such a question must be "whatever works." What works depends very much on the nature of the organization in which the project or program is run. Typically a program is broken down into projects that reflect the organization's structure. The design project will be run by the design team, the factory will manage the modifications to the production line, and so on. Organizational structure and organizational culture are key factors in how to structure a program. The distinction between the terms "outcome" and "output" is far from clear, except in a trivial sense. Each of the projects listed in the example above is designed to deliver some 'thing', known as a 'deliverable' or an 'output', and together they improve the organization. Where one draws the line between the complete single benefit that causes the improvement and its component parts is partly a matter of preference and partly a matter of the culture and structure of the organization. Either way, benefits will normally be enjoyed long after the end of the program and all of its component projects. The point is that to achieve maximum benefits, there must be an integration of parts into a whole. Whether this integration is managed in something that is called a project or a programme is of secondary importance to understanding the benefits and managing the process of integration well. Many programs are concerned with delivering a capability to change. Only when that capability is transferred to the line management and utilized by the host organization will the benefits actually be delivered. On this view, a program team cannot, on their own, deliver benefits. Benefits can only be delivered through the utilization of a new capability. Programs are normally designed to deliver the organization's strategy, such as an ambition to be the fourth biggest supermarket in a region by 2015 or reduce wastage by 5% in two year's time. Program management also emphasises the coordinating and prioritizing of resources across projects, managing links between the projects and the overall costs and risks of the program. Program management may provide a layer above the management of projects and focuses on selecting the best group of projects, defining them in terms of their objectives and providing an environment where projects can be run successfully. Program managers should not micromanage, but should leave project management to the project managers. The UK government, through the Office of Government Commerce, has invested heavily in program management. In public sector work in Europe, the term normally refers to multiple change projects: projects that are designed to deliver benefits to the host organization. An alternative to the Office of Government Commerce's methodology for program management is that of the private sector Project Management Institute. Many organizations only run one program at a time, a program containing all their projects. In Project Management Institute terminology, this is more likely to be a project portfolio than a program. Some larger organizations may have multiple programs each designed to deliver a range of improvements. Some organizations use the concept of Systems Engineering where others use program management.

Program management

463

Key factors
Governance The structure, process, and procedure to control operations and changes to performance objectives. Governance must include a set of metrics to indicate the health and progress of the Programme in the most vital areas. Alignment The program must support a higher level vision, goals and objectives. Assurance Verify and validate the program, ensuring adherence to standards and alignment with the vision. Management Ensure there are regular reviews, there is accountability, and that management of projects, stakeholders and suppliers is in place. Integration Ensure that component parts fit together properly to make the intended whole. Optimize performance across the program value chain, functionally and technically. Finances Track basic costs together with wider costs of administering the program. Infrastructure Allocation of resources influences the cost and success of the program. Infrastructure might cover offices, version control, and IT. Planning Develop the plan bringing together the information on projects, resources, timescales, monitoring and control.[5] Improvement Continuously assess performance; research and develop new capabilities; and systemically apply learning and knowledge to the program.

Differences from project management

The key difference between a program and a project is the finite nature of a project[6] - a project must always have a specific end date, else it is an ongoing program. One view of the differences between an program and a project in business is that: 1. A project is unique and is of definite duration. A program is ongoing and implemented within a business to consistently achieve certain results for the business. 2. A project is designed to deliver an output or deliverable and its success will be in terms of delivering the right output at the right time and to the right cost. 3. Program management includes management of projects which, together, improve the performance of the organization. A program's success will be measured in terms of benefits. 4. Benefits are the measures of improvement of an organization and might include increased income, increased profits, decreased costs, reduced wastage or environmental damage, more satisfied customers. In central or local government organizations, benefits might include providing a better service to the community. 5. In the course of achieving required results, business programs will normally understand related business constraints and determine the processes required to achieve results based on resources allocated. Improvement of

Program management processes is a continuous operation that very much contrasts a program from a project. 6. At the lowest level project managers co-ordinate individual projects. They are overseen by the program manager who accounts to the program sponsor (or board). 7. There will normally be a process to change the predetermined scope of a project. Programs often have to react to changes in strategy and changes in the environment in which the organization changes. Another view and another successful way of managing does not see any of the factors listed above as distinguishing projects from programs, but rather sees the program as being about portfolio management. On this view, program management is about selecting projects, adjusting the speed at which they run, and adjusting their scope, in order to maximize the value of the portfolio as a whole, and as economic or other external conditions change. Yet another view is that a program management is nothing more than a large, complex project, where the integration aspect of project management is more important than in smaller projects. Integration management is a key feature of the Project Management Institute's approach to project management. In practice it is not clear that there is such a clear-cut distinction. Projects (or programs) vary from small and simple to large and complex, what needs to be a managed as a program in one culture or organization may be managed as a project in another.

464

See also
Cost overrun List of project management topics Project Management Institute Systems engineering

Further reading
APM Introduction to Programme Management. ISBN: 978-1-903494-63-9 The Definitive Guide to Project Management. Nokes, Sebastian. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007. ISBN: 978 0 273 71097.[7] The Standard for Program ManagementSecond Edition. Project Management Institute. ISBN 978 1 933 89052 4.[8] Reiss, Geoff; Malcolm Anthony, John Chapman, Geof Leigh, Adrian Pyne and Paul Rayner. Gower Handbook of Programme Management. ISBN: 978-0-566-08603-8 Managing Successful Programmes. The Stationery Office. ISBN: 9780113310401 Putting Strategy to Work Eddie Obeng. Financial Times Publishing ISBN: 0 273 60265 9 The open source chapter on Program management DANS. ISBN 90 6984 496 6.[9]

Program management

465

External links
The International Association of Project & Program Management [1] PMI Program Management Professional (PgMP) credential [10]

References
[1] [2] [3] [4] [5] [6] All Change Eddie Obeng Financial Times Publishing 1994 The Gower Handbook of Programme Management The Definitive Guide to Project Management. Nokes, Sebastian. London (Financial Times / Prentice Hall): 2007 Putting Strategy to Work Eddie Obeng Financial Times Publishing 1996 Managing Successful Programmes, Rob Sowden et al. (TSO, 2007), p156 Prieto, Robert, How Program Management Differs from Project Management (http:/ / www. pmhut. com/ how-program-management-differs-from-project-management), PM Hut. Accessed 17. Oct 2009. [7] http:/ / www. amazon. com/ dp/ 0273710974 [8] http:/ / www. pmi. org/ Marketplace/ Pages/ ProductDetail. aspx?GMProduct=00101095601 [9] http:/ / www. projectmanagement-training. net/ book/ chapter7. html [10] http:/ / www. pmi. org/ CareerDevelopment/ Pages/ Our-Credentials. aspx#pgmp

Software development methodology

A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.[1]

Overview
A software development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.[1] The framework of a software development methodology consists of: A software development philosophy, with the approach or approaches of the software development process
The three basic patterns in software development methodologies.

Multiple tools, models and methods, to assist in the software development process. These frameworks are often bound to some kind of organization, which further develops, supports the use, and promotes the methodology. The methodology is often documented in some kind of formal documentation.

Software development methodology

466

History
One of the oldest software development tools is flowcharting, which has its roots in the 1920s. The software development methodology didn't emerge until the 1960s. According to Elliott (2004) the Systems development life cycle (SDLC) can be considered to be the oldest formalized methodology for building information systems. The main idea of the SDLC has been "to pursue the development of information systems in a very deliberate, structured and methodical way, requiring each stage of the life cycle from inception of the idea to delivery of the final system, to be carried out in rigidly and sequentially".[2] The main target of this methodology in the 1960s has been "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".[2]

Specific software development methodologies

1970s Structured programming since 1969 Cap Gemini SDM, originally from PANDATA, the first English translation was published in 1974. SDM stands for System Development Methodology 1980s Structured Systems Analysis and Design Methodology (SSADM) from 1980 onwards 1990s Object-oriented programming (OOP) has been developed since the early 1960s, and developed as the dominant programming methodology during the mid-1990s. Rapid application development (RAD) since 1991. Scrum (development), since the late 1990s Team software process developed by Watts Humphrey at the SEI 2000s Rational Unified Process (RUP) since 1998. Extreme Programming since 1999 Agile Unified Process (AUP) since 2005 by Scott Ambler Integrated Methodology (QAIassist-IM) since 2007

Software development approaches

Every software development methodology has more or less its own approach to software development. There is a set of more general approaches, which are developed into several specific methodologies. These approaches are:[1] Waterfall: linear framework type. Prototyping: iterative framework type Incremental: combination of linear and iterative framework type Spiral: combination of linear and iterative framework type Rapid Application Development (RAD): Iterative Framework Type Extreme Programming.

Software development methodology

467

Waterfall model
The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The first formal description of the waterfall model is often cited to be an article published by Winston W. Royce[3] in 1970 although Royce did not use the term "waterfall" in this article. Basic principles of the waterfall model are:[1] Project is divided into sequential phases, with some overlap and splashback acceptable between phases. Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time. Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase.

Prototyping
Software prototyping, is the framework of activities during software development of creating prototypes, i.e., incomplete versions of the software program being developed. Basic principles of prototyping are:[1] Not a standalone, complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology (i.e. Incremental, Spiral, or Rapid Application Development (RAD)). Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. User is involved throughout the process, which increases the likelihood of user acceptance of the final implementation. Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users requirements. While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem. Mainframes have a lot to do with this sort of thing that consist of: PB&J

Incremental
Various methods are acceptable for combining linear and iterative systems development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. Basic principles of incremental development are:[1] A series of mini-Waterfalls are performed, where all phases of the Waterfall development model are completed for a small part of the systems, before proceeding to the next incremental, or Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of the system, or The initial software concept, requirements analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final prototype (i.e., working system).

Software development methodology

468

Spiral
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Basic principles:[1] Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle. "Each cycle involves a progression through the same sequence of steps, for each portion of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individual program."[4]

The spiral model.

Each trip around the spiral traverses four basic quadarants: (1) determine objectives, alternatives, and constrainst of the iteration; (2) Evaluate alternatives; Identify and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration.[5] Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment.[6]

Rapid Application Development (RAD)

Rapid Application Development (RAD) is a software development methodology, which involves iterative development and the construction of prototypes. Rapid application development is a term originally used to describe a software development process introduced by James Martin in 1991. Basic principles:[1] Key objective is for fast development and delivery of a high quality system at a relatively low investment cost. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques. Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance. Project control involves prioritizing development and defining delivery deadlines or timeboxes. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline. Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction. Active user involvement is imperative. Iteratively produces production software, as opposed to a throwaway prototype. Produces documentation necessary to facilitate future development and maintenance. Standard systems analysis and design techniques can be fitted into this framework.

Software development methodology

469

Other software development approaches

Other method concepts are: Object oriented development methodologies, such as Grady Booch's Object-oriented design (OOD), also known as object-oriented analysis and design (OOAD). The Booch model includes six diagrams: class, object, state transition, interaction, module, and process.[7] Top-down programming: evolved in the 1970s by IBM researcher Harlan Mills (and Niklaus Wirth) in developed structured programming. Unified Process (UP) is an iterative software development methodology approach, based on UML. UP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development: Inception, Elaboration, Construction, and Guidelines. There are a number of tools and products available designed to facilitate UP implementation. One of the more popular versions of UP is the Rational Unified Process (RUP). Agile Software Development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Integrated Methodology Software Development refers to a group of software development practices and deliverables that can be applied in a multitude (iterative, waterfall, spiral, agile) of software development environments, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

Software development methodology topics

View model
A View model is framework which provides the viewpoints on the system and its environment, to be used in the software development process. It is a graphical representation of the underlying semantics of a view. The purpose of viewpoints and views is to enable human engineers to comprehend very complex systems, and to organize the elements of the problem and the solution around domains of expertise. In the engineering of physically-intensive systems, viewpoints often correspond to capabilities and responsibilities within the engineering organization.[8]

The TEAF Matrix of Views and Perspectives.

Most complex system specifications are so extensive that no single individual can fully comprehend all aspects of the specifications. Furthermore, we all have different interests in a given system and different reasons for examining the system's specifications. A business executive will ask different questions of a system make-up than would a system implementer. The concept of viewpoints framework, therefore, is to provide separate viewpoints into the specification of a given complex system. These viewpoints each satisfy an audience with interest in a particular set of aspects of the system. Associated with each viewpoint is a viewpoint language that optimizes the vocabulary and

Software development methodology presentation for the audience of that viewpoint.

470

Business process and data modelling

Graphical representation of the current state of information provides a very effective means for presenting information to both users and system developers. A business model illustrates the functions associated with the process being modeled and the organizations that perform these functions. By depicting activities and information flows, a foundation is created to visualize, define, understand, and validate the nature of a process. A data model provides the details of information to be stored, and is of primary use when the final product is the generation of computer software code for an application or the preparation of a functional specification to aid a computer [9] example of the interaction between business process and data models. software make-or-buy decision. See the figure on the right for an example of the interaction between business process and data models.[9] Usually, a model is created after conducting an interview, referred to as business analysis. The interview consists of a facilitator asking a series of questions designed to extract required information that describes a process. The interviewer is called a facilitator to emphasize that it is the participants who provide the information. The facilitator should have some knowledge of the process of interest, but this is not as important as having a structured methodology by which the questions are asked of the process expert. The methodology is important because usually a team of facilitators is collecting information cross the facility and the results of the information from all the interviewers must fit together once completed.[9] The models are developed as defining either the current state of the process, in which case the final product is called the "as-is" snapshot model, or a collection of ideas of what the process should contain, resulting in a "what-can-be" model. Generation of process and data models can be used to determine if the existing processes and information systems are sound and only need minor modifications or enhancements, or if reengineering is required as corrective action. The creation of business models is more than a way to view or automate your information process analysis can be used to fundamentally reshape the way your business or organization conducts its operations.[9]

Computer-aided Software Engineering

Computer-Aided Software Engineering (CASE), in the field software engineering is the scientific application of a set of tools and methods to a software which results in high-quality, defect-free, and maintainable software products.[10] It also refers to methods for the development of information systems together with automated tools that can be used in the software development process.[11] The term "Computer-aided software engineering" (CASE) can refer to the software used for the automated development of systems software, i.e., computer code. The CASE functions include analysis, design, and programming. CASE tools automate methods for designing, documenting, and producing

Software development methodology structured computer code in the desired programming language.[12] Two key ideas of Computer-aided Software System Engineering (CASE) are:[13] The harboring of computer assistance in software development and or software maintenance processes, and An engineering approach to the software development and or maintenance. Some typical CASE tools are Configuration management tools, Data modeling tools, Model transformation tools, Refactoring tools, Source code generation tools, and Unified Modeling Language.

471

Integrated development environment

An integrated development environment (IDE) also known as integrated design environment or integrated debugging environment is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of a: source code editor, compiler and/or interpreter, build automation tools, and debugger (usually). IDEs are designed to maximize Anjuta, a C and C++ IDE for the GNOME environment programmer productivity by providing tightly-knit components with similar user interfaces. Typically an IDE is dedicated to a specific programming language, so as to provide a feature set which most closely matches the programming paradigms of the language.

Modeling language
A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. A modeling language can be graphical or textual.[14] Graphical modeling languages use a diagram techniques with named symbols that represent concepts and lines that connect the symbols and that represent relationships and various other graphical annotation to represent constraints. Textual modeling languages typically use standardised keywords accompanied by parameters to make computer-interpretable expressions. Example of graphical modelling languages in the field of software engineering are: Business Process Modeling Notation (BPMN, and the XML form BPML) is an example of a Process Modeling language. EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data modeling language. Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across a number of layers. Flowchart is a schematic representation of an algorithm or a stepwise process, Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems. IDEF is a family of modeling languages, the most notable of which include IDEF0 for functional modeling, IDEF1X for information modeling, and IDEF5 for modeling ontologies.

Software development methodology LePUS3 is an object-oriented visual Design Description Language and a formal specification language that is suitable primarily for modelling large object-oriented (Java, C++, C#) programs and design patterns. Specification and Description Language(SDL) is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems. Unified Modeling Language (UML) is a general-purpose modeling language that is an industry standard for specifying software-intensive systems. UML 2.0, the current version, supports thirteen different diagram techniques, and has widespread tool support. Not all modeling languages are executable, and for those that are, the use of them doesn't necessarily mean that programmers are no longer required. On the contrary, executable modeling languages are intended to amplify the productivity of skilled programmers, so that they can address more challenging problems, such as parallel computing and distributed systems.

472

Programming paradigm
A programming paradigm is a fundamental style of computer programming, in contrast to a software engineering methodology, which is a style of solving specific software engineering problems. Paradigms differ in the concepts and abstractions used to represent the elements of a program (such as objects, functions, variables, constraints...) and the steps that compose a computation (assignation, evaluation, continuations, data flows...). A programming language can support multiple paradigms. For example programs written in C++ or Object Pascal can be purely procedural, or purely object-oriented, or contain elements of both paradigms. Software designers and programmers decide how to use those paradigm elements. In object-oriented programming, programmers can think of a program as a collection of interacting objects, while in functional programming a program can be thought of as a sequence of stateless function evaluations. When programming computers or systems with many processors, process-oriented programming allows programmers to think about applications as sets of concurrent processes acting upon logically shared data structures. Just as different groups in software engineering advocate different methodologies, different programming languages advocate different programming paradigms. Some languages are designed to support one particular paradigm (Smalltalk supports object-oriented programming, Haskell supports functional programming), while other programming languages support multiple paradigms (such as Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, Python, Ruby and Oz). Many programming paradigms are as well known for what techniques they forbid as for what they enable. For instance, pure functional programming disallows the use of side-effects; structured programming disallows the use of the goto statement. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles. Avoiding certain techniques can make it easier to prove theorems about a program's correctnessor simply to understand its behavior.

Software framework
A software framework is a re-usable design for a software system or subsystem. A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API.

Software development process

A Software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

Software development methodology A largely growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207. A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking.

473

See also
Lists List of software engineering topics List of software development philosophies Related topics Domain-specific modeling Lightweight methodology Object modeling language Structured programming

External links
Selecting a development approach [15] at cms.hhs.gov. Software Methodologies Book Reviews [16] An extensive set of book reviews related to software methodologies and processes

References
[1] SELECTING A DEVELOPMENT APPROACH (http:/ / www. cms. hhs. gov/ SystemLifecycleFramework/ Downloads/ SelectingDevelopmentApproach. pdf). Revalidated: March 27, 2008. Retrieved 27 Oct 2008. [2] Geoffrey Elliott (2004) Global Business Information Technology. p.87. [3] Wasserfallmodell > Entstehungskontext (http:/ / cartoon. iguw. tuwien. ac. at/ fit/ fit01/ wasserfall/ entstehung. html), Markus Rerych, Institut fr 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 , 2427 July 2007, pp 219-224. [15] http:/ / www. cms. hhs. gov/ SystemLifecycleFramework/ Downloads/ SelectingDevelopmentApproach. pdf [16] http:/ / www. techbookreport. com/ SoftwareIndex. html

Organization

474

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.

Organization

475

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 Fhrerprinzip.

Organization

476

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 ones 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.

Organization

477

"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

Organization

478

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

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

479

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.386405. 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.75760. 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.

Organization

480

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.88489. ISBN0140805176 9780140805178. OCLC174777513. [3] Henry P. Knowles; Borje O. Saxberg (1971). Personality and Leadership Behavior. Reading, Mass.: Addison-Wesley. pp.88489. 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.

Strategic management

481

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

Strategic management

482

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 Rene 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 departments functional

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.

483

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]

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.

484

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.

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 companys 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.

485

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

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. Dont 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.

486

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

Strategic management Xerox consent decree forced the licensing of the companys 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]

487

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.

Strategic management The 1980s also saw the widespread acceptance of positioning theory. Although the theory originated with Jack Trout in 1969, it didnt 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

488

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

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

489

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.

Strategic management

490

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.

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.

492

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

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.

493

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). Encartas 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

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.

494

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]

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.

495

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

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

496

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.

Strategic management

497

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. Its probably impossible to think in any meaningful way about strategy in an unconstrained environment. Our brains cant process boundless possibilities, and the very idea of strategy only has meaning in the context of challenges or obstacles to be overcome. Its 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

Strategic management 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.

498

See also
Business model Business plan Business Strategy Mapping Cost overrun Hoshin Kanri Marketing Marketing plan Marketing strategies Management Management consulting Military strategy Morphological analysis Overall equipment effectiveness Proximity mapping Revenue shortfall Strategic planning Strategy visualization Value migration Six Forces Model International strategic management

Integrated business planning

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, NovemberDecember 1982, pg 106113. [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, MayJune 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, MayJune 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, NovemberDecember 1991. [36] Berry, L. On Great Service, Free Press, New York, 1995. [37] Kingman-Brundage, J. Service Mapping pp 148163 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 432, 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, JanFeb 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, MayJune, pp 7586, 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 2128, 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, pp5563. [66] Moncrieff, J. Is strategy making a difference? Long Range Planning Review, vol 32, no2, pp273276. [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, NovemberDecember 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, MayJune, 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

501

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, Hroulf, 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, [email protected], 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, [email protected], MER-C, Magnus.de, Mahyt, Maltesedog, MarkJeremy, Materialscientist, Matt Deres, Maurreen, Mboverload, Mdd, Meermaid, Mentifisto, Mfstutz, Mggreennc, Michael Hardy, Mikaey, Mikel Gmez, 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,

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, Dodoste, 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, Jrme, 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, [email protected], 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 Grlitz, 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 fjttrade 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, Tanr, 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, altay, 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, Dugosz, Emurphy42, Espoo, Exleon, Favonian, Feour, 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 Grlitz, 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, [email protected], 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, Mslimix, 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, 433 , ,42..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, Gkhan, 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, [email protected], 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, Nixn, 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 Grlitz, 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, Mslimix, 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, [email protected], 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, [email protected], 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, [email protected], 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, GT, 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, Gkhan, 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 Grlitz, WalterGR, Whitepaw, WikiNC, WikipedianYknOK, William Avery, Wykis, Yngvarr, Yop83, Ywarnier, Ziphon, Zondor, ZooFari, 116 ,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, Jsk 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, [email protected], 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, Jna 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 Grlitz, 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, Jna 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 Dring, 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, Jna 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, [email protected], Ahoerstemeier, Aids10, Aitias, Alan Liefting, Alan bron, Alansohn, Aled D, [email protected], 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 Arnfjr 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 Jnos, 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, Gkhan, 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 Torbjrn 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, Mchtegern, 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, Dnadan, 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. Vlcker, 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 Hggstrm, Mkoval, Molly747, MrJones, MrOllie, Muchness, Mwanner, Myasuda, Mydogategodshat, Mchtegern, 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, [email protected], 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 Dudk, 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 Uur, 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, Gkhan, 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, Tams Kdr, 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 Dudk, 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, Jrme, 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, Hroulf, 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, Gkhan, [email protected], 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

514

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, ArsniureDeGallium, 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 Sby, 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 Administracin 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

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: [email protected], 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: Nicols Prez 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

517

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