15 February 2013

🔦Process Management: Process model (Definitions)

"A formal, detailed description of a process that covers policies, activities, work products, roles, and responsibilities. Typically contains standards and procedures and identifies methods and tools as well. Contrast with process architecture." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A formal description of a business process. The definition is performed via a process definition language (PDL), which in most cases is WfMS-dependent." (C Combi & G Pozzi, "Workflow Management Systems for Healthcare Processes", 2008)

"Any description of a process (not necessarily formal), that shows a series of steps aimed at accomplishing some goal." (Harry S Delugach, "Formal Analysis of Workflows in Software Development", 2009)

"A means of representing the interrelated processes of a system at any level of detail with a graphic network of symbols, showing data flows, data stores, data processes, and data sources/destinations. Process modeling techniques are used to represent processes graphically for clearer understanding, communication, and refinement." (Anthony D Giordano, "Data Integration Blueprint and Modeling", 2010)

"Processes models (PM) are processes of the same nature that are classified together into a model. It involves the description and/or prescription of processes by the instantiation of levels to define process procedures and fuzzes." (Oluwole A Olatunji & William D Sher, "The Applications of Building Information Modelling in Facilities Management", 2010)

"(1) A framework wherein processes of the same nature are classified into an overall model, e.g. a test improvement model. (2) A method-independent process description of development processes." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"A model of the functions, activities, and procedures performed in any organization. A business process model may consist of: 1.A context diagram showing the relationship of the overall process to those outside the model’s scope, along with the inputs to and outputs from the overall process, 2.One or more functional decomposition diagram showing how the overall process is made up of contributing processes at lower levels (a “vertical view”), 3.One or more process flow diagrams showing how the outputs of one process serve as the inputs to other process (a “horizontal view”). The process flow may be cross-functional or within a single function, 4.One or more business process model diagrams, each depicting the inputs, outputs, start and end events, component activities, roles, and metrics of a single process, 5.The business definition of each process, and 6.The value chain analysis of the process, identifying relationships to data, organizations, roles, and systems." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A detailed workflow diagram that expands upon a process map by including detailed descriptions of subprocesses, activities, and tasks including all input, output, decisions, and exceptions, as well as measurements of the resources consumed (such as time, FTEs, material, capital, systems, etc.) during the execution of the process. Supports analysis via drill-down examination and can provide the metrics necessary for use by software capable of process simulation and what-if scenario testing of alternative variables." (Carl F Lehmann, "Strategy and Business Process Management", 2012)

[Process Modeling and Analysis:] "The tools and techniques used to (1) map a workflow diagram illustrating the activities and tasks associated with a business process; (2) add complete detail necessary to identify and measure all the resources consumed during the execution of the processes; (3) measure performance outcomes; (4) simulate changes to activities, tasks, sequences, resources, assumptions, and so on using what-if scenarios to test and recalculate performance outcomes; (5) conclude the best combination of adjustments or changes necessary to optimize performance outcome of the process." (Carl F Lehmann, "Strategy and Business Process Management", 2012)

"A model showing the processes carried out by a system and the data interfaces between those processes; same as a data flow model." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

12 February 2013

🔦Process Management: Process Improvement (Definitions)

"A program of activities designed to improve the performance and maturity of the organization's processes, and the results of such a program." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"Continuous improvement of work processes to achieve project goals and stakeholder satisfaction efficiently and effectively." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"(1) A program of activities designed to improve the performance and maturity of an organization’s processes. (2) The results of such a program." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The organized activity of defining, infusing, and improving the processes used by individual projects and organizations to develop software." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

[internal process improvement (IPI):] "An appraisal mode of usage in which organizations appraise internal processes, generally to baseline their process capability, to establish or update a process improvement program, or to measure progress in implementing such a program." (Sally A Miller et al, "People CMM: A Framework for Human Capital Management" 2nd Ed., 2009)

"A business management strategy focusing on quality control testing and optimizing processes through reducing process variance." (Evan Stubbs, "Big Data, Big Innovation", 2014)

[business process improvement (BPI):] "Analyzing and redesigning business processes to streamline them and gain efficiencies, reduce cycle times, and improve auditability and worker productivity." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"A program of activities designed to improve the performance and maturity of the organization’s software processes and the results of such a program." (CMMI)

08 February 2013

🔦Process Management: Workflow (Definitions)

"Similar to a business process, a description of the activities or tasks that have to be done to fulfill a certain business need." (Nicolai M Josuttis, "SOA in Practice", 2007)

"A series of granular steps that are put together in proper sequence to execute some bit of logic." (Tony Fisher, "The Data Asset", 2009)

"A set of components and relations between them, used to define a complex process from simple building blocks. Relations may be in the form of data links which allow the output of one component to be used as the input of another, or control links which state some conditions on the execution of a component." (Mark Olive, "SHARE: A European Healthgrid Roadmap", 2009)

"The sequence of steps needed to carry out a business process." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"An ordered series of steps that accomplish some defined purpose according to a set of rules." (Bruce Bukovics, "Pro WF: Windows Workflow in .NET 4", 2010)

"Similar to a business process; a description of the activities or tasks that have to be done to fulfill a certain business need. Some people differentiate between workflows and business processes by stating that business processes describe more generally what has to be done, whereas workflows describe how activities or tasks should be carried out." (David Lyle & John G Schmidt, "Lean Integration", 2010)

"System process to manage the routing and approval of documents and transactions across multiple people and/or departments within an organization. Also, automating a business approval process that will notify the appropriate resources when activities/approvals need to be performed." (Janice M Roehl-Anderson, "IT Best Practices for Financial Managers", 2010)

"A predefined sequence of activities that complete a process." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Defines how people and tasks interact to create, update, manage, and deliver content. Workflow helps organizations perform tasks in an efficient and repeatable manner." (Charles Cooper & Ann Rockley, "Managing Enterprise Content: A Unified Content Strategy" 2nd Ed., 2012)

"This is a sequence of task-oriented steps needed to carry out a business process." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"The specification of actions, actors, sequencing of actions, and completion criteria that, taken together, accomplish a larger task." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

06 February 2013

🔦Process Management: Plan-Do-Check-Act (Definitions)

"The team first plans ('plan')who needs to know what information, how often they need it, and their preferred information format. Next the team uses ('do') the communications plan. Very quickly and repeatedly, the team should seek feedback ('check') on the quality and completeness of the information being transmitted through the communications plan. Finally the team should act ('act') on the feedback by improving the communications plan." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A basic technique for improving processes, created by Walter Shewhart. Also known as the Shewhart cycle or the Deming cycle (for W. Edwards Deming, who introduced the technique in Japan)." (Danette McGilvray, "Executing Data Quality Projects", 2008)

"Continuous improvement cycle originally developed by Walter Shewhart in the 1930s." (Bill Holtsnider & Brian D Jaffe, "IT Manager's Handbook" 3rd Ed., 2012)

"All refer to the process of improving quality through a defined series of steps." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement", 2012)

"Also Plan, Do, Study, Act the Shewhart Cycle or Deming Cycle. All refer to the process of improving quality through a defined series of steps." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"An iterative process for continuous improvement." (Weiss, "Auditing IT Infrastructures for Compliance, 2nd Ed", 2015)

"Plan = design/revise process, Do = implement the plan, Check = measure the process, ACT = plan & implement changes" (ITIL)

03 February 2013

🔦Process Management: Defined Process (Definitions)

"A managed process that is tailored from the organization's set of standard processes according to the organization's tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process improvement information to the organizational process assets." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

[managed process:] "A performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

[standard process:] "A standard process describes the fundamental process elements that are expected to be incorporated into any defined process. It also describes the relationships (e.g., ordering and interfaces) among these process elements." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"The process derived, documented, and adapted, if necessary (by means of 'tailoring'), from a standard process, and implemented in the project or elsewhere in the organization." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

[standard process:] "A standardized process that is applied across a particular section of the development organization. A standard process consists of fundamental process elements, such as process activities with their dependencies and interfaces, input and output work products, support tools, and facilities. It also includes information on which roles are involved in the activities." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"A managed process that documents a set of tasks, contributes to the production of a work product or the delivery of a service, and provides appropriate measurements of performance." (Sally A Miller et al, "People CMM: A Framework for Human Capital Management" 2nd Ed., 2009)

"A detailed description of how to produce a product, which includes policies, artifacts, activities, roles, and responsibilities. Another name for the defined process (model) is the organization’s standard process (OSP)." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

[standard process:] "An operational definition of the basic process that guides the establishment of a common process in an organization" (ISO/IEC 15504-9)

🔦Process Management: Business Process Outsourcing (Definitions)

"A form of outsourcing that involves transferring responsibilities for entire specific business functions or processes to a third party provider." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The process of hiring another company to handle business activities." (Linda Volonino & Efraim Turban, "Information Technology for Management 8th Ed", 2011)

"Contracting with a third party to perform specific business processes. One example could be using a customer service center taking inbound telephone calls from U.S. customers and handling customer requests and complaints from a service center located offshore, in locations such as India, where labor costs are lower." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"A process of delegating the back-office processes or noncore business functions to a third party service provider." (John H Higgins & Bryan L Smith, "10 Steps to a Digital Practice in the Cloud" 2nd Ed., 2017)

🔦Process Management: Process Map (Definitions)

"The Process Chart is a device for visualizing a process as a means of improving it. Every detail of a process is more or less affected by every other detail; therefore the entire process must be presented in such form that it can be visualized all at once before any changes are made in any of its subdivisions. In any subdivision of the process under examination, any changes made without due consideration of all the decisions and all the motions that precede and follow that subdivision will often be found unsuited to the ultimate plan of operation." (Frank B Gilbreth & Lillian M Gilbreth, "Process Charts", 1921) 

"A method used to examine the effectiveness of the approach currently used in completing a task." (Dale Furtwengler, "Ten Minute Guide to Performance Appraisals", 2000)

"A type of flowchart depicting the steps in a process, identifying its inputs outputs, and often assigning responsibility for each step and the key measures." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"A type of flow chart depicting the steps in a process, its inputs/outputs, and often identification of responsibility for each step and the key measures." (Lynne Hambleton, "Treasure Chest of Six Sigma Growth Methods, Tools, and Best Practices", 2007)

"A kind of data flow diagram used in business process engineering to represent the tasks performed in an enterprise and the links between them." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A high-level flowchart diagram illustrating the various activities, tasks, decisions, and relationships of participant functions, departments, or groups associated with the execution of a process. It is used as a starting point to be critical of the efficiency and effectiveness of business process execution." (Carl F Lehmann, "Strategy and Business Process Management", 2012)

"A workflow diagram is a graphic depiction of the steps, sequence of steps, and flow control that constitute a process using standard symbols and conventions." (Meredith Zozus, "The Data Book: Collection and Management of Research Data", 2017)

01 February 2013

🔦Process Management: Statistical Process Control (Definitions)

"Statistically based analysis of a process and measurements of process performance, which will identify common and special causes of variation in the process performance, and maintain process performance within limits." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement", 2003)

[statistically managed process:] "A process that is managed by a statistically based technique in which processes are analyzed, special causes of process variation are identified, and performance is contained within well-defined limits." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement", 2003)

"Statistical analysis of process performance to identify common and special causes of variation and to quantify the amount of variation in the process. Used to define operational limits on performance parameters to monitor and maintain process performance within limits. See also common cause of process variation, special cause of process variation." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"Statistical techniques used to monitor, control and improve process performance over time by studying variation and its source." (Atila Ertas, "Transdisciplinary Engineering Design Process", 2018)

16 January 2013

🔦Process Management: Business Process Modeling [BPM] (Definitions)

"A set of practices or tasks that companies can perform to visually depict or describe all the aspects of a business process, including its flow, control and decision points, triggers and conditions for activity execution, the context in which an activity runs, and associated resources." (Nicolai M Josuttis, "SOA in Practice", 2007)

"A technique for transforming how business operates into a codified source in code so that it can be translated into software." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies 2nd Ed.", 2009)

"An activity similar to drafting a blueprint for a house; it includes techniques and activities used as part of the larger business process management discipline." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed., 2011)

"A technique for transforming how business operates into a codified source so that it can be translated into software." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"Business process modeling (BPM) is the data visualization of companies’ workflows and business processes to provide insight and identify areas for improvement. The field focuses on creating detailed graphic representations of these processes to reduce waste, enhance cycle speed, improve upon existing workflows, uncover inefficiencies, and remove redundancies. Business process modeling focuses on representing business flows 'as-is' - in their current state, with no modifications - as well as predictive models that highlight potential improvements in the process." (Sisense) [source]

"Business process modeling (BPM) links business strategy to IT systems development to ensure business value. It combines process/workflow, functional, organizational and data/resource views with underlying metrics such as costs, cycle times and responsibilities to provide a foundation for analyzing value chains, activity-based costs, bottlenecks, critical paths and inefficiencies." (Gartner)

10 January 2013

🔦Process Management: Procedures

"A written description of actions to be taken to perform a given task. Usually expressed as a sequence of steps." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A method, process, or particular way that is established by an organization as the correct way of accomplishing a desired result. Adherence may be mandatory or optional, depending on the degree of impact or risk." (Tilak Mitra et al, "SOA Governance", 2008)

"A written description of a course of action to be taken in performing a task or workforce practice." (Sally A Miller et al, "People CMM: A Framework for Human Capital Management" 2nd Ed., 2009)

"1.Generally, a series of low-level steps or tasks in a process followed in a defined and repeatable order. 2.In data management, a set of instructions for human users of computer systems that augment the automated work flow." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A formal document that specifies the step-by-step instructions to perform tasks in accordance with security policies and standards." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

"An established method of accomplishing a consistent performance or result, a procedure typically can be described as the sequence of steps that will be used to execute a process." (For Dummies, "PMP Certification All-in-One For Dummies, 2nd Ed.", 2013)

"A document that provides step-by-step instructions for how standards and guidelines are put into practice." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A series of steps followed in a regular, definitive order to accomplish something." (Project Management Institute, "Practice Standard for Scheduling" 3rd Ed., 2019)

"Document containing steps that specify how to perform an activity" (ITIL)

03 January 2013

🔦Process Management: Process Owner (Definitions)

"The person (or team) responsible for defining and maintaining a process. At the organizational level, the process owner is the person (or team) responsible for the description of a standard process; at the project level, the process owner is the person (or team) responsible for the description of the defined process. A process may therefore have multiple owners at different levels of responsibility." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"The process owner (person or team) is responsible for process definition and maintenance. At the organizational level, the process owner is responsible for the description of the standard process. At the project level, the process owner is responsible for the defined process. A process may therefore have several process owners with varying levels of responsibility." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"The person responsible for defining and maintaining a process. At the organizational level, the process owner is the individual(s) responsible for the description of a standard process or set of related practices. Within a workforce competency, the process owner is the individual(s) responsible for defining and maintaining the competency-based processes associated with that workforce competency. A process may have multiple owners at different levels of responsibility." (Sally A Miller et al, "People CMM: A Framework for Human Capital Management" 2nd Ed., 2009)

"The person responsible for process definition, execution and control." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Role responsible for ensuring that a process is fit for purpose" (ITIL)

02 January 2013

🔦Process Management: Business Processes [BP] (Definitions)

"Major operational activities or processes supported by a source system, such as orders, from which data can be collected for the analytic purposes of the data warehouse. Choosing the business process is the first of four key steps in the design of a dimensional model." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit" 2nd Ed., 2002)

"The sequence of activities 'enclosing' the production process. These activities are common to all types of products and services, and include defining the job, negotiation with the customer, and reporting project status." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A structured description of the activities or tasks that have to be done to fulfill a certain business need. The activities or tasks might be manual steps (human interaction) or automated steps (IT steps)." (Nicolai M Josuttis, "SOA in Practice", 2007)

"The codification of rules and practices that constitute a business." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies 2nd Ed.", 2009)

"The defined method for a range of activities that organizations perform. A business process can include anything from the steps needed to make a product to how a supply is ordered or how an invoice is created." (Tony Fisher, "The Data Asset", 2009)

"A structured description of the activities or tasks that have to be done to fulfill a certain business need. The activities or tasks might be manual steps (human interaction) or automated steps (IT steps)." (David Lyle & John G Schmidt, "Lean Integration: An Integration Factory Approach to Business Agility", 2010)

"An activity as carried out by business people, including the mechanisms involved." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A collection of activities performed to accomplish a clearly defined goal." (Linda Volonino & Efraim Turban, "Information Technology for Management 8th Ed", 2011)

"A collection of activities designed to produce a specific output for a particular customer or market." (International Qualifications Board for Business Analysis, 2011)

"A business process is a series of steps required to execute a function that is important to an organization. Business processes include things like taking an order or setting up an account or paying a claim. In process analysis, business processes are the focus of opportunities for improvement. Organizations usually have a set of key processes that require support from other areas, like information technology." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The codification of rules and practices that constitute a business." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"A coordinated set of collaborative and transactional work activities carried out to complete work steps." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"A set of activities that teams within an organization carry out to accomplish a specific goal." (David K Pham, "From Business Strategy to Information Technology Roadmap", 2016)

"The business activities executed to deliver products or services to external customers. Business process is supported by and consumes IT-services to achieve their objectives." (by Brian Johnson & Leon-Paul de Rouw, "Collaborative Business Design", 2017)

[core business processes:] "These are the business processes that move an organization’s vision forward, such as sales, marketing, business development, and customer service. Core business processes are also referred to as front-office processes." (John H Higgins & Bryan L Smith, "10 Steps to a Digital Practice in the Cloud" 2nd Ed., 2017)

"Process owned and carried by the business" (ITIL)

01 January 2013

🔦Process Management: Processes (Definitions)

"A series of actions performed by people to bring about a result." (Margaret Y Chu, "Blissful Data ", 2004)

"A kind of activity performed by the enterprise to produce a specific output or achieve a goal. It may or may not be described in terms of the mechanisms used or the parties performing it. A set of processes is usually described in sequence." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"(1) Basic definition, a logical series of related activities that converts input to results or output. (2) Value-added extension, designed to create or deliver customer value or shareholder value through efficiency. (3) Asset extension, an asset that affects the quality of a product, service, or brand to uniquely satisfy customer needs and differentiate its executor from competitors." (Carl F Lehmann, "Strategy and Business Process Management", 2012)

"A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs (OGC1)." (Paul C Dinsmore et al, "Enterprise Project Governance", 2012)

"A high-level, end-to-end structure useful for decision making and normalizing how things get done in a company or organization." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"A systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs." (For Dummies, "PMP Certification All-in-One For Dummies, 2nd Ed.", 2013)

"In the context of this book, a necessary sequence of steps required to provide a desired result. That result can be tangible or intangible or a combination of both." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"The mechanism by which inputs are converted into the specified outputs." (Catherine Burke et al, "Systems Leadership, 2nd Ed,", 2018)

"A set of interrelated actions and activities performed to create a pre-specified product, service, or result. Each process is comprised of inputs, tools, and techniques (or activities), and outputs with constraints (environmental factors), guidance, and criteria (organizational process assets) taken into consideration. Select appropriate processes to meet project objectives, adapt a defined approach to meet requirements, communicate/engage stakeholders, meet needs, balance constraints." (H James Harrington & William S Ruggles, "Project Management for Performance Improvement Teams", 2018)

"A set of interrelated activities, which transform inputs into outputs [ISO 12207]

"A structured set of activities designed to accomplish a specific objective. It includes roles, responsibilities, tools and management controls required to reliably deliver the outputs." (ITIL)

25 December 2012

🚧Project Management: Project Management (Just the Quotes)

"Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools." (William Bengough, "Scene in the old Congressional Library", 1897) 

"Project management is becoming more important as equipment, systems, and projects become more complex." (Bud Porter-Roth, "Proposal Development", 1955)

"The classical vertical arrangement for project management is characterized by an inherent self-sufficiency of operation. It has within its structure all the necessary specialized skills to provide complete engineering capabilities and it also has the ability to carry on its own laboratory investigations, preparation of drawings, and model or prototype manufacture. (Penton Publishing Company, Automation Vol 2, 1955)

"The accuracy of estimates is a function of the stage of development (i.e. estimates improve as development of the item progress). This also means that estimates for development projects representing only 'modest advances' tend to be better than for more ambitious projects." (A W Marshall & W H Meckling, "Predictability of the Cost, Time and Success of Development", [Report P-1821] 1959)

"The difficulty in project management is how to apply competition between task efforts and between subtask efforts when such things as the task managers' work, schedules, and budgets are all different." (John S Baumgartner, "Project Management", 1963)

"If a given task depends on the completion of other assignments in other functional areas, and if it will, in turn, affect the cost or timing of subsequent tasks, project management is probably called for." (American Management Association, "Management Review", 1966)

"Basic to successful project management is recognizing when the project is needed - in other words, when to form a project, as opposed to when to use the regular functional organization to do the job." (David I Cleland & William R King, Systems Analysis and Project Management, 1968)

"Project management is not universally applicable. The utility of the idea depends on the magnitude of the effort, the complexity, the degree of unfamiliarity and interrelatedness, and the concern with the organization's reputation." (David I Cleland & William R King, "Systems Analysis and Project Management", 1968)

"Project management is needed only for situations which are out of the ordinary; but when the need exists, this may often be the only way by which the task may be handled successfully. These situations require a different attitude on the part of the top management, the undivided attention of a project manager and different methods for control and communications than those used in the normal routine business situation. […] Pure project management assigns complete responsibility for the task and resources needed for its accomplishment to one project manager. The organization of a large project, though it will be dissolved upon completion of the task, operates for its duration much like a regular division and is relatively independent of any other division or staff group." (Executive Sciences Institute, Operations Research/Management Science Vol 6, 1964)

"Project management is the process by which it is assured that the objective is achieved and resources are not wasted. Planning is one of the two parts of project management. Control is the other. [...] Each project must first be planned in detail. Control is involved with comparing actual progress with the plan and taking corrective action when the two do not correspond. Without the plan, true control is not possible; the need for corrective action, its nature, extent, and urgency cannot he accurately determined." (Robert D Carlsen & James A Lewis, "The Systems Analysis Workbook: A complete guide to project implementation and control", 1973)

"Project management is clearly a part of software engineering, and its effective employment plays a major role in reducing the problems associated with delivering software within estimated time and cost." (Richard H Thayer & John H. Lehman, Software Engineering Project Management, 1977)

"If a high degree of certainty exists concerning all major events, operations, and outcomes, project management is not essential." (John R. Adams et al, "Managing by Project Management", 1979)

"The acceptance of project management has not been easy, however. Many executives are not willing to accept change and are inflexible when it comes to adapting to a different environment." (Harold Kerzner, "Project Management", 1979)

"Generally, project management is distinguished from the general management of corporations by the mission- oriented nature of a project. A project organization will generally be terminated when the mission is accomplished." (Chris Hendrickson & Tung Au, "Project Management for Construction", 1989)

"An important part of project management is keeping track of thoughts, assumptions, suggestions, limitations, and the myriad related details of the project." (InfoWorld Vol. 12 (17), 1990)

"A methodology should be as simple as possible to get the job done. If you make the requirements a burden, rather than a help, then people will resist following them. You want to achieve a consistent, workable approach to managing projects, not hang a noose around the manager’s neck." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Getting project management to work in an organization requires a change in culture." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"The entire reason for managing a project is to make sure you get the results desired by the organization. This is commonly called being in control, and it is what is expected of a project manager." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Project management is the art of creating the illusion that any outcome is the result of a series of predetermined, deliberate acts when, in fact, it was dumb luck." (Harold Kerzner, "Project Management: A Systems Approach to Planning, Scheduling, and Controlling", 2009)

"Effective project and program management involves more than strict adherence to a prescriptive methodology. Leadership skills, judgement, common sense, initiative, effective communication, negotiation skills and a broad perspective on the surrounding environment are all essential. Project and program management is a creative and collaborative process." (Peter Shergold, "Learning from Failure", 2015)

🚧Project Management: Project Failure (Just the Quotes)

"Rushing into action, you fail.
Trying to grasp things, you lose them.
Forcing a project to completion,
you ruin what was almost ripe."
(Lao Tzu, "Tao Te Ching", cca. 6th-century BC)

"In many ways, project management is similar to functional or traditional management. The project manager, however, may have to accomplish his ends through the efforts of individuals who are paid and promoted by someone else in the chain of command. The pacing factor in acquiring a new plant, in building a bridge, or in developing a new product is often not technology, but management. The technology to accomplish an ad hoc project may be in hand but cannot be put to proper use because the approach to the management is inadequate and unrealistic. Too often this failure can be attributed to an attempt to fit the project to an existing management organization, rather than molding the management to fit the needs of the project. The project manager, therefore, is somewhat of a maverick in the business world. No set pattern exists by which he can operate. His philosophy of management may depart radically from traditional theory." (David I Cleland & William R King, "Systems Analysis and Project Management", 1968)

"But the greater the primary risk, the safer and more careful your secondary assumptions must be. A project is only as sound as its weakest assumption, or its largest uncertainty." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Faced with a decision, always ask one implacable question: If this project fails, if the worst comes to the worst, what will be the result? If the answer is total corporate disaster, drop the project. If the worst possible outcome is tolerable, say, break-even, the executive has the foundation of all sound decision making - a fail-safe position." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"The Eighth Truth of Management is: if you are doing something wrong, you will do it badly. The reverse of this truth is that, if your decision is blindingly right, you will execute it well - or appear to do so, which is much the same thing. But any executive can massacre his own nonsensical project." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Yet intelligent men plump for one project rather than another on the strength of a difference of a few decimal points in the rate of return calculated over the next decade. All such mind-stretching calculation comes under the lash of the Seventh Truth of Management: if you need sophisticated calculations to justify an action, it is probably wrong (the sophisticated calculations, anyway, are all too often based on simple false assumptions)." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs." (Barry Boehm, "Software Engineering Economics", 1981)

"[…] the longer one works on […] a project without actually concluding it, the more remote the expected completion date becomes. Is this really such a perplexing paradox? No, on the contrary: human experience, all-too-familiar human experience, suggests that in fact many tasks suffer from similar runaway completion times. In short, such jobs either get done soon or they never get done. It is surprising, though, that this common conundrum can be modeled so simply by a self-similar power law." (Manfred Schroeder, "Fractals, Chaos, Power Laws Minutes from an Infinite Paradise", 1990)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve C McConnell, "Software Project Survival Guide", 1997)

"Today, excellent companies realize that project failures have more to do with behavioral shortcomings - poor employee morale, negative human relations, low productivity, and lack of commitment." (Harold Kerzner, "In search of excellence in project management", 1998)

"Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%." (Barry Boehm, "Software Cost Estimation with Cocomo II", 2000)

"Choosing a proper project strategy can mean the difference between success and failure." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Note that a project always begins as a concept, and a concept is usually a bit fuzzy. Our job as a team is to clarify the concept, to turn it into a shared understanding that the entire team will accept. It is failure to do this that causes many project failures." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Project failures are not always the result of poor methodology; the problem may be poor implementation. Unrealistic objectives or poorly defined executive expectations are two common causes of poor implementation. Good methodologies do not guarantee success, but they do imply that the project will be managed correctly." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"Projects often fail at the beginning, not the end." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Success or failure of a project depends upon the ability of key personnel to have sufficient data for decision-making. Project management is often considered to be both an art and a science. It is an art because of the strong need for interpersonal skills, and the project planning and control forms attempt to convert part of the 'art' into a science." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"Today, most project management practitioners focus on planning failure. If this aspect of the project can be compressed, or even eliminated, then the magnitude of the actual failure, should it occur, would be diminished. A good project management methodology helps to reduce planning failure. Today, we believe that planning failure, when it occurs, is due in large part to the project manager’s inability to perform effective risk management." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"When unmeetable expectations are formed, failure is virtually assured, since we have defined failure as unmet expectations. This is called a planning failure and is the difference between what was planned to be accomplished and what was, in fact, achievable. The second component of failure is poor performance or actual failure. This is the difference between what was achievable and what was actually accomplished. […] Perceived failure is the net sum of actual failure and planning failure. […] Planning failure is again assured even if no actual failure occurs. In both of these situations (overplanning and underplanning), the actual failure is the same, but the perceived failure can vary considerably." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"You need to identify and terminate infeasible projects early. Sending a message to project managers that project termination threatens their career will tempt them to continue projects that should die” (Barry Bohem,"Project termination doesn't equal project failure", Computer, 34 (9),  2001)

"Projects fail because of context, not because of content.[...] the traditional emphasis in project management on the technical issues of the project (content) has led to a legacy of an extremely poor set of tools, techniques, and tips for managing the complex of people, political, and other 'softer' issues that make up the context of the project." (Rob Thomsett, "Radical Project Management", 2002)

"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses." (Barry Boehm & Richard Turner, "Observations on balancing discipline and agility", Agile Development Conference, 2003)

"A project is composed of a series of steps where all must be achieved for success. Each individual step has some probability of failure. We often underestimate the large number of things that may happen in the future or all opportunities for failure that may cause a project to go wrong. Humans make mistakes, equipment fails, technologies don't work as planned, unrealistic expectations, biases including sunk cost-syndrome, inexperience, wrong incentives, contractor failure, untested technology, delays, wrong deliveries, changing requirements, random events, ignoring early warning signals are reasons for delays, cost overruns and mistakes. Often we focus too much on the specific project case and ignore what normally happens in similar situations (base rate frequency of outcomes- personal and others)." (Peter Bevelin, "Seeking Wisdom: From Darwin to Munger", 2003)

"If you've been in the software business for any time at all, you know that there are certain common problems that plague one project after another. Missed schedules and creeping requirements are not things that just happen to you once and then go away, never to appear again. Rather, they are part of the territory. We all know that. What's odd is that we don't plan our projects as if we knew it. Instead, we plan as if our past problems are locked in the past and will never rear their ugly heads again. Of course, you know that isn't a reasonable expectation." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few. But it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. On the other hand, a good design can create opportunities to exploit those complex features." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"A fundamental reason for the difficulties with modern engineering projects is their inherent complexity. The systems that these projects are working with or building have many interdependent parts, so that changes in one part often have effects on other parts of the system. These indirect effects are frequently unanticipated, as are collective behaviors that arise from the mutual interactions of multiple components. Both indirect and collective effects readily cause intolerable failures of the system. Moreover, when the task of the system is intrinsically complex, anticipating the many possible demands that can be placed upon the system, and designing a system that can respond in all of the necessary ways, is not feasible. This problem appears in the form of inadequate specifications, but the fundamental issue is whether it is even possible to generate adequate specifications for a complex system." (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)

"The collapse of a particular project may appear to have a specific cause, but an overly high intrinsic complexity of these systems is a problem common to many of them. A chain always breaks first in one particular link, but if the weight it is required to hold is too high, failure of the chain is guaranteed."  (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)

"As hard as it is to find good ideas, it's even more difficult to manage them. While the project is humming along, vision document in place and a strong creative momentum moving forward, there is another level of thinking that has to occur: how will the designs and ideas translate into decisions? Even if good designs and ideas are being investigated, and people are excited about what they're working on, the challenge of convergence toward specifications remains. If a shift of momentum toward definitive design decisions doesn't happen at the right time and isn't managed in the right way, disaster waits. For many reasons, project failure begins here." (Scott Berkun, "The Art of Project Management", 2005)

"Failure usually results from a lack of a common approach to accomplish the work as a team. Inadequate leadership fails to create the environment in which teams can flourish. Furthermore, potential team members are seldom trained in how to share their efforts to accomplish team goals. The team may also assume they know more about teamwork than they actually do. So we need to be able to differentiate between superficial teamwork and the real thing." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)

"Project failures can frequently be traced to unrealistic technical, cost, or schedule targets. Such targets may be entirely arbitrary or based on bad assumptions - setting team members up for failure. Furthermore, the goals that motivate one team member may not motivate another member. All tasks don’t have to be inherently motivating - that’s not sensible. But there have to be motivating factors, if by nothing more than participating in goal determination. This also helps ensure adequate opportunity and risk identification, analysis, and management." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)

"Projects are complex non-linear systems and have significant inertia. If you wait to see acute problems before taking action, you will be too late and may make things worse." (Scott Berkun, "Making Things Happen: Mastering Project Management", 2005)

"The appropriate models help avoid costly errors that can lead to failure. One of the major sources of project failure is f lawed requirements and scope management. Models of the project environment, therefore, need to address the development and management of project requirements. Continuing to work on the project solution with an insufficient understanding of stakeholder requirements and a deficient requirements development process often leads to expensive time delays and redesigns. This doesn’t have to be the case. A strong requirements development and management process model can provide that ounce of prevention." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)

"Any effort at large-scale reorganization - that is, any project spanning more than two years and, more generally, anything that has not already been done - is inevitably doomed to failure." (Corinne Maier, "Bonjour Laziness: Why Hard Work Doesn't Pay", 2007)

"In software management, coordination is not an afterthought or an ancillary matter; it is the heart of the work, and deciding what tools and methods to use can make or break a project. But getting sidetracked in managing those tools is a potent temptation." (Scott Rosenberg, "Dreaming in Code", 2007)

"As a general rule, implementations do not just spontaneously combust. Failures tend to stem from the aggregation of many issues. Although some issues may have been known since the early stages of the project (for example, the sales cycle or system design), implementation teams discover the majority of problems during the middle of the implementation, typically during some form of testing." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Implementing new systems is not like baking a cake. Organizations cannot follow a recipe with the following ingredients: three consultants, six weeks of testing, two training classes, and a healthy dose of project management. Nor do projects bake for six months until complete, after which time everyone enjoys a delicious piece of cake. For all sorts of reasons, a well-conceived and well-run project may fail, whereas a horribly managed project may come in under budget, ahead of schedule, and do everything that the vendor promised at the onset." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Pre-implementation, post-implementation, and ongoing data audits are invaluable tools for organizations. Used judiciously by knowledgeable and impartial resources, audits can detect, avoid, and minimize issues that can derail an implementation or cause a live system to fail. Rather than view them as superfluous expenses, organizations would be wise to conduct them at key points throughout the system’s life cycle." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"The best managed project may fail, whereas a horribly managed project may come in under budget, ahead of schedule, and do everything that the vendor promised at the onset. In reality, however, organizations are unlikely to find themselves in one of these extreme scenarios. On a fundamental level, successfully activating and utilizing a new system is about minimizing risk from day one until the end of the project and beyond. The organization that can do this stands the best chance of averting failure." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Understanding the causes of system failures may help organizations avoid them, although there are no guarantees." 
(Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Stakeholder management to me is key, as success or failure is in the eye of the beholder. Time, cost and quality fall prey to the perceptions of the key stakeholders, who may have nothing to do with the running of the project." (Peter Parkes, "NLP for Project Managers", 2011)

"Projects fail from under-communicating, not over-communicating. Even if resource constraints preclude the dependency that you want from being delivered any sooner, clarifying priorities and expectations enables you to plan ahead and work through alternatives." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Reading reviews of failure can be a dispiriting exercise. It can also create a distorted perception of reality. Reform of the implementation of large programs and projects should not just be based on a litany of what has gone wrong. Many things go right and, for that very reason, go unnoticed." (Peter Shergold, "Learning from Failure", 2015)

"Complexity is one of the causes of failing projects; failing to split the project into smaller tasks also causes software quality issues or project failure. Complexity can also be caused by the size of the  project; if the project is too big, there is a huge possibility that the project may become complex and complicated." (Abu S Mahfuz,"Software Quality Assurance", 2016)

"A correct and sanity-checked judgment of both the financial and logistic feasibility of a project is absolutely critical to its eventual outcome; get it wrong and a failed project is almost guaranteed. In support of this statement we can refer to the contents of a number of serious ­academic studies which support the idea that two of the chief causes of the failure, particularly the financial failure, of major infrastructure ­projects are optimism bias and strategic misrepresentations. […] Optimism bias means that the original project sponsors and planners fooled themselves that the project would be easy and could be completed within a 'back-of-the-envelope' budget, perhaps because they didn’t have the experience to know it would be difficult and expensive, or perhaps they didn’t want to know. Strategic misrepresentations mean that even if they did know it would be more difficult and expensive than their published estimate, they lied about it so that the Public, the Banks, and Politicians, would support the idea." (Tony Martyr, "Why Projects Fail", 2018)

"No project should be allowed to proceed without clear specification and acceptance  criteria, that are understood by all participants." (Tony Martyr, "Why Projects Fail", 2018)

"[...] consistently good project results are hard to come by, yet most organisations continue to think they’re doing a great job. It’s got to the stage where project failure has become so commonplace that we’ve started to see it as success, or we just aren’t seeing clearly at all." (Tony Martyr, "Why Projects Fail", 2018)

"Every year more than two-thirds of projects are considered failures, and most organisations would not be surprised by this statistic. In most cases, however, failure was the result of not making a hard decision."  (Colin D Ellis, "The Project Book", 2019)

"Organisations whose IT projects failed usually deployed recognisable project management methodologies; the reasons for failure were invariably to do with failures of project governance rather than simply of operational management." (Alan Calder, "ISO/IEC 38500: A pocket guide" 2nd Ed, 2019)

"Part of the problem is that we take project failure personally, seeing it as a stain on our reputation. It’s worth remembering that while a project may fail, this doesn’t make you a failure as a leader. In fact, the research shows that those who embrace failure become much more resilient and make better decisions as a result, so in that sense failure can only be a good thing." (Colin D Ellis, "The Project Book", 2019)

"Remember, though, there are only two reasons for project failure: poor project sponsorship and poor project management. And given that the buck stops with you, you could argue there’s only one reason for project failure." (Colin D Ellis, "The Project Book", 2019)

"A project is usually considered a failure if it is late, is over budget, or does not meet the customer’s expectations. Without the control that project management provides, a project is more likely to have problems with one of these areas. A problem with only one constraint (scope, schedule, cost, resources, quality, and risk) can jeopardize the entire project." (Sandra F Rowe, "Project Management for Small Projects" 3rd Ed., 2020)
Related Posts Plugin for WordPress, Blogger...

About Me

My photo
Koeln, NRW, Germany
IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.