Business Intelligence: Data Modeling (Part IV: From Data to Storytelling II)

Business Intelligence Series

Being snapshots in people and organizations’ lives, data arrive to tell a story, even if the story might not be worth telling or might be important only in certain contexts. In fact each record in a dataset has the potential of bringing a story to life, though business people are more interested in the hidden patterns and “stories” the data reveal through more or less complex techniques. Therefore, data are usually tortured until they confess something, and unfortunately people stop analyzing the data with the first confession(s). 

Even if it looks like torture, data need to be processed to reveal certain characteristics, trends or patterns that could help us in sense-making, decision-making or similar specific business purposes. Unfortunately, the volume of data increases with an incredible velocity to which further characteristics like variety, veracity, volume, velocity, value, veracity and variability may add up. 

The data in a dashboard, presentation or even a report should ideally tell a story otherwise the data might not be worthy looking at, at least from some people’s perspective. Probably, that’s one of the reason why man dashboards remain unused shortly after they were made available, even if considerable time and money were invested in them. Seeing the same dull numbers gives the illusion that nothing changed, that nothing is worth reviewing, revealing or considering, which might be occasionally true, though one can’t take this as a rule! Lot of important facts could remain hidden or not considered. 

One can suppose that there are businesses in which something important seldom happens and an alert can do a better job than reviewing a dashboard or a report frequently. Probably an alert is a better choice than reporting metrics nobody looks at! 

Organizations usually define a set of KPIs (key performance indicators) and other types of metrics they (intend to) review periodically. Ideally, the numbers collected should define and reflect the critical points (aka pain points) of an organization, if they can be known in advance. Unfortunately, in dynamic businesses the focus can change considerably from one day to another. Moreover, in systemic contexts critical points can remain undiscovered in time if the set of metrics defined doesn’t consider them adequately. 

Typically only one’s experience and current or past issues can tell what one should consider or ignore, which are the critical/pain points or important areas that must be monitored. Ideally, one should implement alerts for the critical points that require a immediate response and use KPIs for the recurring topics (though the two approaches may overlap). 

Following the flow of goods, money and other resources one can look at the processes and identify the areas that must be monitored, prioritize them and identify the metrics that are worth tracking, respectively that reflect strengths, weaknesses, opportunities, threats and the risks associated with them. 

One can start with what changed by how much, what caused the change(s) and what further impact is expected directly or indirectly, by what magnitude, respectively why nothing changed in the considered time unit. Causality diagrams can help in the process even if the representations can become quite complex. 

The deeper one dives and the more questions one attempts to answer, the higher the chances to find a story. However, can we find a story that’s worth telling in any set of data? At least this is the point some adepts of storytelling try to make. Conversely, the data can be dull, especially when one doesn’t track or consider the right data. There are many aspects of a business that may look boring, and many metrics seem to track the boring but probably important aspects. 

Previous Post <<||>> Next Post

Data Management: Master Data Management [MDM] (Notes)

Disclaimer: This is work in progress intended to consolidate information from various sources. 
Last updated: 28-Mar-2024

Master Data Management (MDM)

• {definition} the technologies, processes, policies, standards and guiding principles that enable the management of master data values to enable consistent, shared, contextual use across systems, of the most accurate, timely, and relevant version of truth about essential business entities [2],[3]
• {goal} enable sharing of information assets across business domains and applications within an organization [4]
• {goal} provide authoritative source of reconciled and quality-assessed master (and reference) data [4]
• {goal} lower cost and complexity through use of standards, common data models, and integration patterns [4]
• {driver} meeting organizational data requirements
• {driver} improving data quality
• {driver} reducing the costs for data integration
• {driver} reducing risks 
• {type} operational MDM 
• involves solutions for managing transactional data in operational applications [1]
• rely heavily on data integration technologies
• {type} analytical MDM
• involves solutions for managing analytical master data
• centered on providing high quality dimensions with multiple hierarchies [1]
• cannot influence operational systems
• any data cleansing made within operational application isn’t recognized by transactional applications [1]
• ⇒ inconsistencies to the main operational data [1]
• transactional application knowledge isn’t available to the cleansing process
• {type} enterprise MDM
• involves solutions for managing both transactional and analytical master data 
• manages all master data entities
• deliver maximum business value
• operational data cleansing
• improves the operational efficiencies of the applications and the business processes that use the applications
• cross-application data need
• consolidation
• standardization
• cleansing
• distribution
• needs to support high volume of transactions
• ⇒ master data must be contained in data models designed for OLTP
• ⇐ ODS don’t fulfill this requirement 
• {enabler} high-quality data
• {enabler} data governance
• {benefit} single source of truth
• used to support both operational and analytical applications in a consistent manner [1]
• {benefit} consistent reporting
• reduces the inconsistencies experienced previously
• influenced by complex transformations
• {benefit} improved competitiveness
• MDM reduces the complexity of integrating new data and systems into the organization
• ⇒ increased flexibility and improves competitiveness
• ability to react to new business opportunities quickly with limited resources
• {benefit} improved risk management
• more reliable and consistent data improves the business’s ability to manage enterprise risk [1]
• {benefit} improved operational efficiency and reduced costs
• helps identify business’ pain point
• by developing a strategy for managing master data
• {benefit} improved decision making
• reducing data inconsistency diminishes organizational data mistrust and facilitates clearer (and faster) business decisions [1]
• {benefit} more reliable spend analysis and planning
• better data integration helps planners come up with better decisions
• improves the ability to 
• aggregate purchasing activities
• coordinate competitive sourcing
• be more predictable about future spending
• generally improve vendor and supplier management
• {benefit} regulatory compliance
• allows to reduce compliance risk
• helps satisfy governance, regulatory and compliance requirements
• simplifies compliance auditing
• enables more effective information controls that facilitate compliance with regulations
• {benefit} increased information quality
• enables organizations to monitor conformance more effectively
• via metadata collection
• it can track whether data meets information quality expectations across vertical applications, which reduces information scrap and rework
• {benefit} quicker results
• reduces the delays associated with extraction and transformation of data [1]
• ⇒ it speeds up the implementation of application migrations, modernization projects, and data warehouse/data mart construction [1]
• {benefit} improved business productivity
• gives enterprise architects the chance to explore how effective the organization is in automating its business processes by exploiting the information asset [1]
• ⇐ master data helps organizations realize how the same data entities are represented, manipulated, or exchanged across applications within the enterprise and how those objects relate to business process workflows [1]
• {benefit} simplified application development
• provides the opportunity to consolidate the application functionality associated with the data lifecycle [1]
• ⇐ consolidation in MDM is not limited to the data
• ⇒ provides a single functional to which different applications can subscribe
• ⇐ introducing a technical service layer for data lifecycle functionality provides the type of abstraction needed for deploying SOA or similar architectures
• factors to consider for implementing an MDM:
• effective technical infrastructure for collaboration [1]
• organizational preparedness
• for making a quick transition from a loosely combined confederation of vertical silos to a more tightly coupled collaborative framework
• {recommendation} evaluate the kinds of training sessions and individual incentives required to create a smooth transition [1]
• metadata management
• via a metadata registry 
• {recommendation} sets up a mechanism for unifying a master data view when possible [1]
• determines when that unification should be carried out [1]
• technology integration
• {recommendation} diagnose what technology needs to be integrated to support the process instead of developing the process around the technology [1]
• anticipating/managing change
• proper preparation and organization will subtly introduce change to the way people think and act as shown in any shift in pattern [1]
• changes in reporting structures and needs are unavoidable
• creating a partnership between Business and IT
• IT roles
• plays a major role in executing the MDM program[1]
• business roles
• identifying and standardizing master data [1]
• facilitating change management within the MDM program [1]
• establishing data ownership
• measurably high data quality
• overseeing processes via policies and procedures for data governance [1]
• {challenge} establishing enterprise-wide data governance
• {recommendation} define and distribute the policies and procedures governing the oversight of master data
• seeking feedback from across the different application teams provides a chance to develop the stewardship framework agreed upon by the majority while preparing the organization for the transition [1]
• {challenge} isolated islands of information
• caused by vertical alignment of IT
• makes it difficult to fix the dissimilarities in roles and responsibilities in relation to the isolated data sets because they are integrated into a master view [1]
• caused by data ownership
• the politics of information ownership and management have created artificial exclusive domains supervised by individuals who have no desire to centralize information [1]
• {challenge} consolidating master data into a centrally managed data asset [1]
• transfers the responsibility and accountability for information management from the lines of business to the organization [1]
• {challenge} managing MDM
• MDM should be considered a program and not a project or an application [1]
• {challenge} achieving timely and accurate synchronization across disparate systems [1]
• {challenge} different definitions of master metadata 
  • different coding schemes, data types, collations, and more
  • ⇐ data definitions must be unified
• {challenge} data conflicts 
• {recommendation} resolve data conflicts during the project [5]
• {recommendation} replicate the resolved data issues back to the source systems [5]
• {challenge} domain knowledge 
• {recommendation} involve domain experts in an MDM project [5]
• {challenge} documentation
• {recommendation} properly document your master data and metadata [5]
• approaches
• {architecture} no central MDM 
• isn’t a real MDM approach
• used when any kind of cross-system interaction is required [5]
• e.g. performing analysis on data from multiple systems, ad-hoc merging and cleansing
• {drawback} very inexpensive at the beginning; however, it turns out to be the most expensive over time [5]
• {architecture} central metadata storage 
• provides unified, centrally maintained definitions for master data [5]
• followed and implemented by all systems
• ad-hoc merging and cleansing becomes somewhat simpler [5]
• does not use a specialized solution for the central metadata storage [5]
• ⇐ the central storage of metadata is probably in an unstructured form 
• e.g. documents, worksheets, paper
• {architecture} central metadata storage with identity mapping 
• stores keys that map tables in the MDM solution
• only has keys from the systems in the MDM database; it does not have any other attributes [5]
• {benefit} data integration applications can be developed much more quickly and easily [5]
• {drawback} raises problems in regard to maintaining master data over time [5]
• there is no versioning or auditing in place to follow the changes [5]
• ⇒ viable for a limited time only
• e.g. during upgrading, testing, and the initial usage of a new ERP system to provide mapping back to the old ERP system
• {architecture} central metadata storage and central data that is continuously merged 
• stores metadata as well as master data in a dedicated MDM system
• master data is not inserted or updated in the MDM system [5]
• the merging (and cleansing) of master data from source systems occurs continuously, regularly [5]
• {drawback} continuous merging can become expensive [5]
• the only viable use for this approach is for finding out what has changed in source systems from the last merge [5]
• enables merging only the delta (new and updated data)
• frequently used for analytical systems
• {architecture} central MDM, single copy 
• involves a specialized MDM application
• master data, together with its metadata, is maintained in a central location [5]
• ⇒ all existing applications are consumers of the master data
• {drawback} upgrade all existing applications to consume master data from central storage instead of maintaining their own copies [5]
• ⇒ can be expensive
• ⇒ can be impossible (e.g. for older systems)
• {drawback} needs to consolidate all metadata from all source systems [5]
• {drawback} the process of creating and updating master data could simply be too slow [5]
• because of the processes in place
• {architecture} central MDM, multiple copies 
• uses central storage of master data and its metadata
• ⇐ the metadata here includes only an intersection of common metadata from source systems [5]
• each source system maintains its own copy of master data, with additional attributes that pertain to that system only [5]
• after master data is inserted into the central MDM system, it is replicated (preferably automatically) to source systems, where the source-specific attributes are updated [5]
• {benefit} good compromise between cost, data quality, and the effectiveness of the CRUD process [5]
• {drawback} update conflicts
• different systems can also update the common data [5]
• ⇒ involves continuous merges as well [5]
• {drawback} uses a special MDM application

Acronyms:

MDM - Master Data Management

ODS - Operational Data Store

OLAP - online analytical processing

OLTP - online transactional processing

SOA - Service Oriented Architecture

References:
[1] The Art of Service (2017) Master Data Management Course 
[2] DAMA International (2009) "The DAMA Guide to the Data Management Body of Knowledge" 1st Ed.

[3] Tony Fisher 2009 "The Data Asset"

[4] DAMA International (2017) "The DAMA Guide to the Data Management Body of Knowledge" 2nd Ed.

[5] Dejan Sarka et al (2012) Exam 70-463: Implementing a Data Warehouse with Microsoft SQL Server 2012 (Training Kit)

Data Migrations (DM): Conceptualization II (Plan vs. Concept vs. Strategy)

Data Migrations Series

A concept is a document that describes at high level the set of necessary steps and their implications to achieve a desired result, typically making the object of a project. A concept is usually needed to provide more technical and nontechnical information about the desired solution, the context in which a set of steps are conducted, respectively the changes considered, how the changes will be implemented and the further aspects that need to be considered. It can include a high-level plan and sometimes also information that typically belong in a Business Case – goals,objectives, required resources, estimated effort and costs, risks and opportunities.

A concept is used primarily as basis for sign-off as well for establishing common ground and understanding. When approved, it’s used for the actual implementation and solution’s validation. The concept should be updated as the project progresses, respectively as new information are discovered.

Creating a concept for a DM can be considered as best practice because it allows documenting the context, the technical and organizational requirements and dependencies existing between the DM and other projects, how they will be addressed. The concept can include also a high-level plan of the main activities (following to be detailed in a separate document).

Especially when the concept has an exploratory nature (due to incomplete knowledge or other considerations), it can be validated with the help of a proof-of-concept (PoC), the realization of a high-level-design prototype that focuses on the main characteristics of the solution and allows thus identifying the challenges. Once the PoC implemented, the feedback can be used to round out the concept.

Building a PoC for a DM should be considered as objective even when the project doesn’t seem to meet any major challenges. The PoC should resume in addressing the most important DM requirements, ideally by implementing the whole or most important aspects of functionality (e.g. data extraction, data transformations, integrity validation, respectively the import into the target system) for one or two data entities. Once the PoC built, the team can use it as basis for the evolutive development of the solution during the iterations considered.

A strategy is a set of coordinated and sustainable actions following a set of well-defined goals, actions devised into a plan and designed to create value and overcome further challenges. A strategy has the character of a concept though it has a broader scope being usually considered when multiple projects or initiatives compete for the same resources to provide a broader context and handle the challenges, risks and opportunities. Moreover, the strategy takes an inventory of the current issues and architecture – the 'AS-IS' perspective and sketches the to 'TO-BE' perspective by devising a roadmap that bridges the gap between the two.

In the case of a DM a strategy might be required when multiple DM projects need to be performed in parallel or sequentially, as it can help the organization to better manage the migrations.

A plan is a high-level document that describes the tasks, schedule and resources required to carry on an activity. Even if it typically refers to the work or product breakdown structure, it can cover other information usually available in a Business Case. A project plan is used to guide both project execution and project control, while in the context of Strategic Management the (strategic) plan provides a high-level roadmap on how the defined goals and objectives will be achieved during the period covered by the strategy.

For small DM projects a plan can be in theory enough. As both a strategy and a concept can include a high-level plan, the names are in praxis interchangeable.

Previous Post <<||>> Next Post

ERP Implementations: It’s all about Planning

Ideally the total volume of work can be uniformly distributed for all project’s duration though in praxis the curve representing the effort has the form of a wave or aggregation of waves that tend to reach the peak shortly before or during the Go-Live(s). More important, higher fluctuations occur in the various areas of the project on whole project’s duration, as there are dependencies between the various functional areas, as one needs to wait for decisions to be made, people are not available, etc. Typically, the time wasted on waiting, researching or other non-value-added activities have the potential of leading to such peaks. Therefore, the knowledge must be available, and decisions must be taken when required, which can be challenging but not impossible to achieve. 

To bridge the time wasted on waiting, the team members need to work on other topics. If on customer’s side the resources can handle maybe other activities, on vendor’s side the costs can be high and proportional with the volume of waiting. Therefore, vendor’s resources must be involved at least in two projects or do work in other areas in advance, which is not always possible. However, when vendor’s resources are involved in two or more projects, unless the planning is perfect or each resource can handle the work as it comes, there are further waiting times added. The customer is then forced either to book the resources exclusively, or to wait and carry the costs associated with it. 

On the other side ERP Implementations tend to become exploration projects, especially when the team has only partial knowledge about the system, or the requirements have a certain degree of specialization that deviates from the standard processes. The more unknowns an ERP implementation has, the more difficult is to plan. To be able to plan one must know the activities ahead, how long they take, and of course, one must adhere to the delivery dates, because each delay can have a cascading effect that can impact project’s schedule considerably. 

Probably the best approach to planning is to group the activities into packages and plan the packages, being in each subteam’s duty to handle the planning for each package, following to manage at upper level only the open issues, risks or opportunities. This shifts the burden from Project Manager’s shoulders within the project. Moreover, even if in theory the plan can consider each activity, it will become obsolete as soon it’s updated given the considerable volume of work requested to maintain it. Periodically, one can still revise the whole plan to identify opportunities and risks. What the team can do is to plan for a certain time interval (e.g. 4-6 weeks) and build from there. This allows focusing on the most important activities. 

To further shift the burden, activities like Data Migration, Data Cleaning or the integrations with third party systems should be treated when possible as subprojects. Despite having interdependencies with the main project (e.g. parameters, master data, decisions) and share same resources, they have their own schedule whose deadlines need to be aligned with main project’s milestones. 

Unless the team and business put all effort to respect the plan and, as long the plan is realistic, the initial plan can seldom be respected – it’s anyway just a sketch of the road ahead that can change as the project progresses – and this aspect needs to be understood by the business otherwise will lead to false expectations. On the other side, the team must try respecting the deadlines and communicate in time inability to do so. It’s an interplay in which communication is more important than ever.

Previous Post <<||>> Next Post

ERP Implementations: It’s all about Partnership I

Unless the organization (customer) implementing an ERP system has a strong IT team and the knowledge required for the implementation is available already in-house, the resources need to be acquired from the market, and probably the right thing to do is to identify a certified implementer (partner) which can fill the knowledge and skillset gaps, respectively which can help splitting the risks associated with such an implementation.

In theory, the customer provides knowledge about its processes, while the partner comes with expertise about the system to be implemented and further technologies, industry best practices, project methodologies, etc. Further on, the mix is leveraged to harness the knowledge and reach project’s objectives. 

In praxis however finding an implementer which can act as partner might be more challenging than expected. This because the implementer needs to understand customer’s business and where it’s heading, bridge the gap between functional requirements and system’s functionality, advise on areas of improvement, prepare the customer for the project and lead the customer through the changes, respectively establish a basis for the future. Some of the implications are seldom made explicit even if they are implied by what is needed by the project. 

Technology is seldom the issue in an ERP implementation, the challenges residing in handing the change and the logistics required. There are so many aspects to be considered and handled, and this can be challenging for any implementer no matter how long has been on the market or how experienced the resources are. Somebody needs to lead the change and the customer seldom has the knowledge to handle the change. In some cases, the implementer must make the customer aware of the implications, while in others needs to take the initiative and lead the change, though the customer needs to play along, which can be challenging also. 

Many aspects need to be handled at management level from a strategical point of view on customer’s side. It starts with assuring that the most important aspects of the business where considered, that the goals and objectives are clear, that the proper environment is created, and ends with the timely decision-making, with assuring that the resources are available when needed, that the needed organization structures and roles are in place, that the required knowledge is available before, during and after implementation, that the potential brought by the ERP system is harnessed for the years to come. 

A partnership allows in theory splitting the implementation risks as ERP implementations have a high rate of failure. Quite often the outcomes of such projects don’t meet the expectations, the systems being in extremis unusable or a bottleneck for the organization. Ideally one should work with the partner(s) and attempt solving the issues, split eventually the incurred cost overruns, find a middle way. Most of the times it’s recommended to find a solution together rather than coming to a litigation. 

Given the complex dependencies existing between the various parts of the project, the causes that lead to poor implementations are difficult to prove, as there are almost always grey areas. Moreover, the litigations can require a considerable time and resources to settle. These can be just extreme situations, and as long one has a good partner, there’s no need to think that far. On the other side, even if undesirable, one must be prepared also for such outcomes, even if the countermeasures may involve an additional effort. Therefore, one must address such issues in contracts by establishing the areas of accountability/responsibilities for each party, document adequately the requirements and further (important) communication, make sure that the deliverables have the expected quality, etc.

Previous Post <<||>> Next Post

Project Management: Planning Correctly Misundersood IV

The relatively big number of Project Management (PM) methodologies considered nowadays makes it more and more difficult to understand the world of PM and make oneself understood, in the context in which terminology is used in explanations that defy the logic, in which people are stubborn in persisting that their understanding is the ultimate truth and, that between white and black there are no degrees of gray. Between all PM concepts project planning seems to be the most misunderstood, and this probably because all the activities revolve around it, while each methodology brings its own planning philosophy. Each methodology comes with its own story, its own imaginative description of what a perfect plan is about.

Independently of the methodology used there are three levels of planning. At highest level, the strategic one, the project is put in the context of other strategic activities – other projects and initiatives, as well business operations, competing altogether for the same financial and human resources.  At this level are the goals identified and put the basis for the successful execution of the project, including establishing the ground and integrating the main aspects of a project – risk, quality and communication. Here is decided which projects will be considered, in which sequence, how and when resources will be assigned. 

A project plan is typically written and further executed by having the tactical horizon in mind – the individual engagement of resources and actions, the actual means to reach the objectives set at strategic level. It’s the level where the actual project plan is detailed, where activities are sequenced and prioritized. Here each methodology has its own approach – whether the planning is done per deliverable, work package or any other approach used to partition the activities. It’s the level at which the various teams are coordinated toward specific targets. Thus the manageable unit is the team and not the individual, the deliverables or the work packages and not the individual tasks.

The operational level equates with the execution of a project’s activities. Even if the project manager oversights the activities, it’s in team’s duties to plan the activities having the set deliveries in mind. The project manager doesn’t need to know all the details, though he should be updated on a timely manner on the progress, the eventual risks and opportunities that arise in each area. This requires continuous coordination on vertical as well horizontal level.

The project manager typically oscillates between the strategic and tactical views of a project, while the operational level appears in the view only when operational themes are escalated or further coordination is needed. Even if this delimitation is clear in big projects, in the small projects the three levels melt into each other. Therefore the sprung from small to big projects and vice-versa can create issues when the approach is not tailored to project’s size and its further characteristics.

Attempting to plan each activity in the project at the lowest level of detail obscures the view, the complexity of the project kicking back sooner or later. Maintaining such a detailed plan can become a waste of time on the long term. In extremis a resource is used to update a plan, which easily can become obsolete by the time all activities were reviewed. This doesn’t mean that the project plan doesn’t need to be updated regularly, though the pace can be decided on each project’s specifics.

Therefore, one of the most important challenges in projects is finding the appropriate level of detail for planning, and there’s no general rule that works for all projects. Typically the choices alternate between work packages and deliverables. 

Information Security: Threat (Definitions)

"An imminent security violation that could occur at any time due to unchecked security vulnerabilities." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"Anything or anyone that represents a danger to an organization’s IT resources. Threats can exploit vulnerabilities, resulting in losses to an organization." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"The capabilities, intentions, and attack methods of adversaries to exploit or cause harm to assets." (Manish Agrawal, "Information Security and IT Risk Management", 2014)

"The potential cause of an unwanted incident, which may result in harm to a system or organisation." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"Any activity that represents a possible danger." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"The danger of a threat agent exploiting a vulnerability." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"A potential for violation of security that exists when there is a circumstance, a capability, an action, or an event that could breach security and cause harm. That is, a threat is a possible danger that might exploit vulnerability." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"A possible danger to a computer system, which may result in the interception, alteration, obstruction, or destruction of computational resources, or other disruption to the system." (NIST SP 800-28 Version 2)

"A potential cause of an unwanted incident." (ISO/IEC 13335)

"A potential cause of an unwanted incident, which may result in harm to a system or organisation."(ISO/IEC 27000:2014)

"An activity, deliberate or unintentional, with the potential for causing harm to an automated information system or activity." (NIST SP 800-16)

"Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a particular information system vulnerability." (FIPS 200)

"Any circumstance or event with the potential to cause harm to an information system in the form of destruction, disclosure, adverse modification of data, and/or denial of service." (NIST SP 800-32)

"An event or condition that has the potential for causing asset loss and the undesirable consequences or impact from such loss." (NIST SP 1800-17b)

"Anything that might exploit a Vulnerability. Any potential cause of an Incident can be considered to be a Threat." (ITIL)

"The potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability. "(NIST SP 800-47)

Project Management: Planning Correctly Misundersood II

Even if planning is the most critical activity in Project Management it seems to be also one of the most misunderstood concepts. Planning is critical because it charters the road ahead in terms of what, when, why and who, being used as a basis for action, communication, for determining the current status in respect to the initial plan, as well the critical activities ahead.

The misunderstandings derive maybe also from the fact that each methodology introduces its own approach to planning. PMI as traditional approach talks about baseline planning with respect to scope schedule and costs, about management plans, which besides the theme covered in the baseline, focus also on quality, human resources, risks, communication and procurement, and separate plans can be developed for requirements, change and configuration management, respectively process improvement. To them one can consider also action and contingency planning.

In Prince2 the product-based planning is done at three levels – at project, stage, respectively team level – while separate plans are done for exceptions in case of deviations from any of these plans; in addition there are plans for communication, quality and risk management. Scrum uses an agile approach looking at the product and sprint backlog, the progress being reviewed in stand-up meetings with the help of a burn-down chart. There are also other favors of planning like rapid application planning considered in Extreme Programming (XP), with an open, elastic and undeterministic approach. In Lean planning the focus is on maximizing the value while minimizing the waste, this being done by focusing on the value stream, the complete list of activities involved in delivering the end-product, value stream's flow being mapped with the help of visualization techniques such as Kanban, flowcharts or spaghetti diagrams.

With so many types of planning nothing can go wrong, isn’t it? However, just imagine customers' confusion when dealing with a change of methodology, especially when the concepts sound fuzzy and cryptic! Unfortunately, also the programmers and consultants seem to be bewildered by the various approaches and the philosophies supporting the methodologies used, their insecurity bringing no service for the project and customers’ peace of mind. A military strategist will more likely look puzzled at the whole unnecessary plethora of techniques. On the field an army has to act with the utmost concentration and speed, to which add principles like directedness, maneuver, unity, economy of effort, collaboration, flexibility, simplicity and sustainability. It’s what Project Management fails to deliver.

Similarly to projects, the plan made before the battle seldom matches the reality in the field. Planning is an exercise needed to divide the strategy in steps, echelon and prioritize them, evaluate the needed resources and coordinate them, understand the possible outcomes and risks, evaluate solutions and devise actions for them. With a good training, planning and coordination, each combatant knows his role in the battle, has a rough idea about difficulties, targets and possible ways to achieve them; while a good combatant knows always the next action. At the same time, the leader must have visibility over fight’s unfold, know the situation in the field and how much it diverged from the initial plan, thus when the variation is considerable he must change the plan by changing the priorities and make better use the resources available.

Even if there are multiple differences between the two battlefields, the projects follow the same patterns of engagement at different scales. Probably, Project Managers can learn quite of a deal by studying the classical combat strategists, and hopefully the management of projects would be more effective and efficient if the imperatives of planning, respectively management, were better understood and addressed.

Governance: Enterprise Risk Management (Definitions)

"A model for IT governance that is risk-based integrating internal control, the Sarbanes-Oxley Act mandates, and strategic planning." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed, 2011)

"Process of continuously identifying, assessing, mitigating, and monitoring relevant business risks in a comprehensive and integrated way." (Leslie G Eldenburg & Susan K Wolcott, "Cost Management" 2nd Ed, 2011)

"The process of planning, organizing, leading, and controlling the activities of an organization in order to minimize the effects of risk on its capital and earnings. ERM includes not only risks associated with accidental losses, but also financial, strategic, operational, and other risks." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The application of risk management approaches across an organization in a structured and disciplined manner." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"The governing process for managing risks and opportunities." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"Enterprise risk management is a framework for risk management, including organization and governance, internal controls, key processes, systems and information and risk culture. ERM begins by identifying events or circumstances relevant to the organization's objectives (risks and opportunities), assessing them in terms of likelihood and magnitude of impact, determining a response strategy and monitoring progress." (Thomas C Wilson, "Value and Capital Management", 2015)

Data Science: Correlation (Definitions)

[correlation coefficient:] "A measure to determine how closely a scatterplot of two continuous variables falls on a straight line." (Glenn J Myatt, "Making Sense of Data: A Practical Guide to Exploratory Data Analysis and Data Mining", 2006)

"A metric that measures the linear relationship between two process variables. Correlation describes the X and Y relationship with a single number (the Pearson’s Correlation Coefficient (r)), whereas regression summarizes the relationship with a line - the regression line." (Lynne Hambleton, "Treasure Chest of Six Sigma Growth Methods, Tools, and Best Practices", 2007)

[correlation coefficient:] "A measure of the degree of correlation between the two variables. The range of values it takes is between −1 and +1. A negative value of r indicates an inverse relationship. A positive value of r indicates a direct relationship. A zero value of r indicates that the two variables are independent of each other. The closer r is to +1 and −1, the stronger the relationship between the two variables." (Jae K Shim & Joel G Siegel, "Budgeting Basics and Beyond", 2008)

"The degree of relationship between business and economic variables such as cost and volume. Correlation analysis evaluates cause/effect relationships. It looks consistently at how the value of one variable changes when the value of the other is changed. A prediction can be made based on the relationship uncovered. An example is the effect of advertising on sales. A degree of correlation is measured statistically by the coefficient of determination (R-squared)." (Jae K Shim & Joel G Siegel, "Budgeting Basics and Beyond", 2008)

"A figure quantifying the correlation between risk events. This number is between negative one and positive one." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A mechanism used to associate messages with the correct workflow service instance. Correlation is also used to associate multiple messaging activities with each other within a workflow." (Bruce Bukovics, "Pro WF: Windows Workflow in .NET 4", 2010)

"Correlation is sometimes used informally to mean a statistical association between two variables, or perhaps the strength of such an association. Technically, the correlation can be interpreted as the degree to which a linear relationship between the variables exists (i.e., each variable is a linear function of the other) as measured by the correlation coefficient." (Herbert I Weisberg, "Bias and Causation: Models and Judgment for Valid Comparisons", 2010)

"The degree of relationship between two variables; in risk management, specifically the degree of relationship between potential risks." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A predictive relationship between two factors, such that when one factor changes, you can predict the nature, direction and/or amount of change in the other factor. Not necessarily a cause-and-effect relationship." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Organizing and recognizing one related event threat out of several reported, but previously distinct, events." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

"Association in the values of two or more variables." (Meta S Brown, "Data Mining For Dummies", 2014)

[correlation coefficient:] "A statistic that quantifies the degree of association between two or more variables. There are many kinds of correlation coefficients, depending on the type of data and relationship predicted." (K  N Krishnaswamy et al, "Management Research Methodology: Integration of Principles, Methods and Techniques", 2016)

"The degree of association between two or more variables." (K  N Krishnaswamy et al, "Management Research Methodology: Integration of Principles, Methods and Techniques", 2016)

"A statistical measure that indicates the extent to which two variables are related. A positive correlation indicates that, as one variable increases, the other increases as well. For a negative correlation, as one variable increases, the other decreases." (Jonathan Ferrar et al, "The Power of People: Learn How Successful Organizations Use Workforce Analytics To Improve Business Performance", 2017)

Strategic Management: Risk (Just the Quotes)

"The decision which achieves organization objectives must be both (1) technologically sound and (2) carried out by people. If we lose sight of the second requirement or if we assume naively that people can be made to carry out whatever decisions are technically sound - we run the risk of decreasing rather than increasing the effectiveness of the organization." (Douglas McGregor, "The Human Side of Enterprise", 1960)

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

"Management theory is obsessed with risks. Top executives bemoan the lack of risk-taking initiative among their young. Politicians and stockholders are advised (by directors) to make directors rich, so that they can afford to take risks. Theorists teach how to construct decision trees, heraldic devices of scientific management; and how to marry the trees with probability theory, so that the degree of risk along each branch (each branch and twig representing alternative results of alternative courses of action) can be metered. But the measuring is spurious, and, anyway, the best management doesn't take risks. It avoids them. It goes for the sure thing." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Taking no action to solve these problems is equivalent of taking strong action. Every day of continued exponential growth brings the world system closer to the ultimate limits of that growth. A decision to do nothing is a decision to increase the risk of collapse." (Donella Meadows et al, "The Limits to Growth", 1972) 

"Overly optimistic goals nearly always result in one of two extremes. If the goal is seen as a must, then the division manager must 'go for broke. This can result in reckless risk taking. More commonly [...] ultraconservative action. The reasoning is: "Why take any chances to achieve an unattainable goal."(Bruce Henderson, "Henderson on Corporate Strategy", 1979)

"Risk is a function of how poorly a strategy will perform if the 'wrong' scenario occurs." (Michael Porter, "Competitive Advantage: Creating and Sustaining Superior Performance", 1985)

"The risk of making a decision that's wrong is so enormous that sometimes it just crushes people so that they can't make any decision at all because they're afraid of making the wrong decision." (James M McPherson, "An Exchange With a Civil War Historian", 1995)

"Until we can distinguish between an event that is truly random and an event that is the result of cause and effect, we will never know whether what we see is what we'll get, nor how we got what we got. When we take a risk, we are betting on an outcome that will result from a decision we have made, though we do not know for certain what the outcome will be. The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us." (Peter L Bernstein, "Against the Gods: The Remarkable Story of Risk", 1996)

"Risk management is the explicit quantitative declaration of uncertainty. But in some corporate cultures, people aren’t allowed to be uncertain. They’re allowed to be wrong, but they can’t be uncertain. They are obliged to look their bosses and clients in the face and lie rather than show uncertainty about outcomes. Uncertainty is for wimps." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Risk mitigation is the set of actions you will take to reduce the impact of a risk should it materialize. There are two not-immediately-obvious aspects to risk mitigation: The plan has to precede materialization. Some of the mitigation activities must also precede materialization." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"According to the traditional distinction from economics, risk is measurable, whereas uncertainty is indefinite or incalculable. In truth, risk can never be measured precisely except in dice rolls and games of chance, called a priori probability. Risk can only be estimated from observations in the real world, but to do that, we need to take a sample, and estimate the underlying distribution. In a sense, our estimates of real-world volatility are themselves volatile. Failure to realize this fundamental untidiness of the real world is called the ludic fallacy from the Latin for games. […] However, when the term risk measurement is used as opposed to risk estimation, a degree of precision is suggested that is unrealistic, and the choice of language suggests that we know more than we do. Even the language '​​​​​​risk management'​​​​​​ implies we can do more than we can." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Change strategy is, by this definition, the way a business (1) manages the portfolio of change to make sure that the parts deliver the whole business strategy, (2) creates the context for change, and (3) monitors change risk and change performance across the entire business." (Paul Gibbons, "The Science of Successful Organizational Change", 2015)

"After you think, you act. After you act, you learn. Make decisions, but decisions will have risks of mistakes. But make sure you avoid disastrous mistakes and avoid making the same mistake twice." (Sukanto Tanoto, [Keynote speech] 2015)

"Governance and leadership are the yin and the yang of successful organisations. If you have leadership without governance you risk tyranny, fraud and personal fiefdoms. If you have governance without leadership you risk atrophy, bureaucracy and indifference." (Mark Goyder, "What Matters in Corporate Governance?", 2015)

"Our minds, especially our intuitions, are not equipped to deal with a probabilistic world. Risk and prediction are widely misunderstood, […] All decision making in a probabilistic world involves estimating the likelihood of an event and how much we will value it (affective forecasting). Humans are bad at both - ​​​​​ particularly at the former. […] In business, understanding the psychology of risk is more important than understanding the mathematics of risk." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Often greater risk is involved in postponement than in making a wrong decision." (Harry A Hopf)

Strategic Management: Risk Transfer/Transference (Definitions)

"Shifting currently or potentially risky activities to another company." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A form of risk treatment involving the agreed distribution of risk with other parties" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"A risk response strategy whereby the project team shifts the impact of a threat to a third party, together with ownership of the response." (Project Management Institute, "The Standard for Portfolio Management 3rd Ed.", 2012)

"Transferring all or part of the cost of a risk to a third party (most commonly an insurance provider)." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

"One of the risk treatment options is to transfer the risk to or to share it with a third party. Transferring or sharing the risk, however, does not change ownership of the risk, which remains with the organisation itself, regardless of who else shares the risk." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"Project team shifts the impact of a threat to a third party together with ownership of the response." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)

"A form of risk treatment involving the agreed distribution of risk with other parties." (ISO Guide 73:2009). 

Strategic Management: Risk Analysis (Definitions)

"The evaluation, classification, and prioritization of risks." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"The process of identifying, characterizing, and prioritizing risks." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood)." (Tilo Linz et al, "Software Testing Practice: Test Management", 2007)

"The process of measuring and analyzing the risks associated with financial and investment decisions. Risk refers to the variability of expected returns (earnings or cash flows)." (Jae K Shim & Joel G Siegel, "Budgeting Basics and Beyond", 2008)

"The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood)." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"A formal definition of risks based on asset identification, threat enumeration, and consequence evaluation." (Mark Rhodes-Ousley, "Information Security: The Complete Reference, Second Edition, 2nd Ed.", 2013)

"Systematic use of available information to determine how often specified events may occur and the magnitude of their likely consequences." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"The process to comprehend the nature of risk and to determine the level of risk." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"A process undertaken to comprehend the nature of risk and to determine the level of risk." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"The process to comprehend the nature of risk and to determine the level of risk" (ISO Guide 73:2009). 

"The process of assessing identified project or product risks to determine their level of risk, typically by estimating their impact and probability of occurrence (likelihood)" (ISTQB)

Strategic Management: Risk Register (Definitions)

"A record of a company’s risks." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"The document containing the results of the qualitative risk analysis, quantitative risk analysis, and risk response planning. The risk register details all identified risks, including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"Formal document and management tool that records all risks identified by the project team, along with the team’s assessment of the risks, plans to manage the risks, and progress against the plans." (Mike Clayton, "Brilliant Project Leader", 2012)

"A document in which the results of risk analysis and risk response planning are recorded." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A documented collection of the risks impacting an activity or organization." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"A record of information about identified risks." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"Formal record of identified risks." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"A repository in which outputs of risk management processes are recorded." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK® Guide )", 2017

"A component that captures details of individual project risks, including a list of identified risks, potential risk owners, and potential risk responses." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)

"A document in which the iterative results of the risk identification, risk analysis, and risk response planning processes are recorded." (H James Harrington & William S Ruggles, "Project Management for Performance Improvement Teams", 2018)

"A record of information about identified risks." (ISO Guide 73:2009)

Strategic Management: Risk Assessment (Definitions)

"An evaluation of the risks and possible bad outcomes an organization faces and the likelihood these may occur." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"identifying and aggregating the risks facing the organization." (Manish Agrawal, "Information Security and IT Risk Management", 2014)

"The overall process of risk identification, risk analysis, and risk evaluation." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"'analyze assets’ value, identify threats and evaluate their vulnerability to those threats" (ITIL)

"the overall process of risk identification, risk analysis and risk evaluation" (ISO Guide 73:2009) 

"The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis. (NIST SP 800-137)

"The process of identifying risks to agency operations (including mission, functions, image, or reputation), agency assets, or individuals by determining the probability of occurrence, the resulting impact, and additional security controls that would mitigate this impact. Part of risk management, synonymous with risk analysis, and incorporates threat and vulnerability analyses." (NIST SP 800-18)

"The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system." (NIST SP 800-171)

Strategic Management: Contingency Plan (Definitions)

"An identification of alternative strategies to be used to ensure project success if specified risk events occur." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

[contingency planning:] "A management process that analyses disaster risks and establishes arrangements in advance to enable timely, effective and appropriate responses." (ISDR, 2009)

"Specific planning designed to create a quick response after the occurrence of a risk event." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A plan that identifies alternative approaches to be used if the corresponding risk events occur." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"A plan developed to mitigate the outcome of a risk, once the risk has materialised." (Mike Clayton, "Brilliant Project Leader", 2012)

"Mitigation plan alternative course(s) of action devised to cope with project risks." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"A plan that allows an organization to respond appropriately to a specific type of unplanned event."(Rebecca Hamilton & Diane Brown, "Disaster Management and Continuity Planning in Libraries: Changes since the Year 2000", 2016)

"A plan for continued operation and execution of the most essential functions of a mission in the event of a disruptive failure, such as a natural disaster or a major cyberattack." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"A plan put in place before any potential emergencies, with the mission of dealing with possible future emergencies. It pertains to training personnel, performing backups, preparing critical facilities, and recovering from an emergency or disaster so that business operations can continue." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide" 8th Ed., 2018)

[contingency planning:] "Management policies and procedures designed to maintain or restore business operations, including computer operations, possibly at an alternate location, in the event of emergencies, system failures, or disasters." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"A plan that is maintained for disaster response, backup operations, and post-disaster recovery to ensure the availability of critical resources and to facilitate the continuity of operations in an emergency situation." (NIST SP 800-57 Part 1)

"Management policy and procedures used to guide an enterprise response to a perceived loss of mission capability. The Contingency Plan is the first plan used by the enterprise risk managers to determine what happened, why, and what to do. It may point to the continuity of operations plan (COOP) or disaster recovery plan (DRP) for major disruptions." (CNSSI 4009-2015)

Strategic Management: Risk Analysis (Definitions)

 "The evaluation, classification, and prioritization of risks." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"The process of identifying, characterizing, and prioritizing risks." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood)." (Tilo Linz et al, "Software Testing Practice: Test Management", 2007)

"The process of measuring and analyzing the risks associated with financial and investment decisions. Risk refers to the variability of expected returns (earnings or cash flows)." (Jae K Shim & Joel G Siegel, "Budgeting Basics and Beyond", 2008)

"A formal definition of risks based on asset identification, threat enumeration, and consequence evaluation." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

"Systematic use of available information to determine how often specified events may occur and the magnitude of their likely consequences." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"The process to comprehend the nature of risk and to determine the level of risk [3]" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"This is the part where we combine the impact and the likelihood (or probability) to calculate the level of risk and to plot it onto a risk matrix, which allows us to compare risks for their severity and to decide which are in greatest need of treatment." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"Determining the nature and likelihood of the risks to key data" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"A process undertaken to comprehend the nature of risk and to determine the level of risk." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood)." (IQBBA)

"The process to comprehend the nature of risk and to determine the level of risk" (ISO Guide 73:2009)

Strategic Management: Risk Matrix (Definitions)

"A graph that compares the likelihood and severity of risks from highest to lowest." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A common way to determine whether a risk is considered low, moderate, or high by combining the two dimensions of a risk: its probability of occurrence and its impact on objectives if it occurs." (Cynthia Stackpole, "PMP Certification All-in-One For Dummies", 2011)

"A grid for mapping the probability of each risk occurrence and its impact on project objectives if that risk occurs. " (Project Management Institute, "The Standard for Portfolio Management" 3rd Ed., 2012)

"A graphical representation of impact versus likelihood used to assist in the prioritisation of risks" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

[impact matrix:] "A method for assigning values to expected pressures from the macro-environment in order for an organisation to assess the future nature of its context for which it must design an effective strategy." (Duncan Angwin & Stephen Cummings, "The Strategy Pathfinder" 3rd Ed., 2017)

Strategic Management: Risk (Definitions)

"The probability of uncertain events occurring, causing positive or negative effects on the objectives of an endeavor." (Margaret Y Chu, "Blissful Data ", 2004)

"An adverse impact on the developer’s business organization due to the occurrence of a product or project risk. The business risk can arise directly from contract terms and conditions (e.g., warranties or consequential damages) or indirectly from loss of future business or reputation. Buyers use terms and conditions to protect their organizations in the event that the developer fails to deliver acceptable products and services on time. Thus, terms and conditions place the developer at risk." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"Potential loss that can be estimated by an analysis of threat and vulnerability; the casualty contemplated in a contract of insurance. Pure risk occurs from cost without benefit, such as from crime or natural disaster. Dynamic risk reflects calculated exposure that an enterprise may take that can lead to advancement or loss." (Robert McCrie, "Security Operations Management" 2nd Ed., 2006)

"A risk is an undesired event or potential problem which may occur with a certain probability sometime in the future. Risk occurrence is associated with damage; i.e., it has a negative effect on project goals. It may cause cost increases, schedule shifts, quality problems, or other damages." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"The consideration of a situation that might arise that would tend to prevent a strategy or objective from being successfully achieved." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"Possibility of suffering losses on an investment; the sources of risk include inflation, default, politics, etc." (Stefano Caselli, "Private Equity and Venture Capital in Europe", 2009)

"A predictable or unpredictable event that has an uncertain outcome." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"In general, risk is the probability that a threat agent will be able to exploit a defined vulnerability that would adversely impact the business." (Alex Berson & Lawrence Dubov, "Master Data Management and Data Governance", 2010)

"The possibility of incurring a liability or exposure to asset losses." (Sue Johnson & Gwen Moran, "The Complete Idiot's Guide To Business Plans", 2010)

"Refers to the possibility of occurrence of an event, whether uncertain or of undetermined term, which is not entirely under the control of the people involved and is contrary to their expectations or interest. Risk can be voluntary, when a person acts despite being aware of that possibility." (Humbert Lesca & Nicolas Lesca, "Weak Signals for Strategic Intelligence: Anticipation Tool for Managers", 2011)

"The possibility that an event could occur and interfere with an organization's ability to meet strategic goals or operating plans. Varies across organizations, industries, geographic regions, and time periods." (Leslie G Eldenburg & Susan K Wolcott, "Cost Management 2nd Ed", 2011)

"Risk is the possibility that something unpleasant or unwelcome will happen (NOAD). Risk to data is the possibility that something will negatively affect its quality and make it less fit for use." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The degree of uncertainty of realizing expected future returns of the business resulting from factors other than financial leverage." (Mark L Zyla, "Fair Value Measurement", 2012)

"In the context of business decisions, the cost of a particular outcome. When a set of outcomes are possible, this cost is often weighted by the probability, if known, of that particular outcome occurring. Not to be confused with uncertainty, a term often used incorrectly to communicate the level of risk." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"Probability, usually of an unwanted event." (Geoff Cumming, "Understanding The New Statistics", 2013)

"The consequences of a realized threat." (Mark Rhodes-Ousley, "Information Security: The Complete Reference, Second Edition, 2nd Ed.", 2013)

"A factor that could result in future negative consequences; usually expressed as impact and likelihood." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"A quantitative measure of the potential damage caused by a specified threat." (Manish Agrawal, "Information Security and IT Risk Management", 2014)

"The effect of uncertainty on objectives" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"The likelihood that a threat will exploit a vulnerability resulting in a loss. Organizations use risk mitigation techniques to reduce risk." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"In investment terms, risk is the uncertainty associated with an investment or asset. A high-risk investment, for example, may yield a high return; but if unsuccessful, it could cause the investor to lose everything. Operational risk is the risk of failure due to shortcomings in procedures, people, or systems." (DK, "The Business Book", 2014)

"A factor that could result in future negative consequences; usually expressed as impact and likelihood." (Tilo Linz et al, "Software Testing Foundations" 4th Ed", 2014)

"Risk is defined as the mathematical product of the loss or damage due to failure and the probability (or frequency) of failure resulting in such damage. Damage comprises any consequences or loss due to failure. The probability of occurrence of a product failure depends on the way the software product is used. The software’s operational profile must be considered here. Therefore, detailed estimation of risks is difficult. Risk factors to be considered may arise from the project (project risks) as well as from the product to be delivered (product risks)." (Andreas Spillner et al, "Software Testing Foundations: A Study Guide for the Certified Tester Exam" 4th Ed., 2014)

"Risk is the product of consequence or impact and likelihood or probability, and is not the same as a threat or hazard. In the context of information risk management, risk is usually taken to have negative connotations. In the wider context of risk, however, it can also bee seen in a positive light and referred to as ‘opportunity’." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"The possibility of an event occurring that will have an impact on the achievement of objectives. Risk is measured in terms of impact and likelihood." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"The likelihood that a threat will exploit a vulnerability resulting in a loss. Organizations use risk mitigation techniques to reduce risk." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"An uncertainty that might lead to a loss. Losses occur when a threat exploits vulnerability." (Weiss, "Auditing IT Infrastructures for Compliance, 2nd Ed", 2015)

"Business risk is the potential loss due to a weakening in the compet­itive position." (Christopher Donohue et al, "Foundations of Financial Risk" 2nd Ed, 2015)

"Defined as the possible failure to meet your desired and expected objectives due to future, uncertain events." (Thomas C Wilson, "Value and Capital Management", 2015)

"The possibility of suffering harm or loss; Usually, risk involves the statistical chance that an action would pose a threat, resulting in a failure of some kind." (Ken Sylvester, "Negotiating in the Leadership Zone", 2015)

"The probability of a threat agent exploiting a vulnerability and the associated impact." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"The possible failure to meet your desired and expected objectives due to future, uncertain events." (Thomas C Wilson, "Value and Capital Management", 2015)

"The likelihood of a negative impact event occurring over a period of time, not to be confused with exposure. Example: there is a 30% risk of tornadoes occurring tonight." (Gregory Lampshire, "The Data and Analytics Playbook", 2016)

"The chance of a negative thing happening." (Pamela Schure & Brian Lawley, "Product Management For Dummies", 2017)

"A characterization of harmful events and their associated probabilities with respect to a given system or mission." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of the adverse impacts that would arise if the circumstance or event occurs and the likelihood of occurrence." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"A factor that could result in future negative consequences; usually expressed as impact and likelihood." (ISTQB)

"A possible event that could cause harm or loss, or affect the ability to achieve objectives" (ITIL)

"The effect of uncertainty on objectives." (ISO Guide 73:2009)

"The effect of uncertainty on objectives, whether positive or negative." (ISO 31000) 

Strategic Management: Risk Management (Definitions)

"An organized, analytic process to identify what might cause harm or loss (identify risks); to assess and quantify the identified risks; and to develop and, if needed, implement an appropriate approach to prevent or handle causes of risk that could result in significant harm or loss." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement", 2003)

"The organized, analytic process to identify future events (risks) that might cause harm or loss, assess and quantify the identified risks, and decide if, how, and when to prevent or reduce the risk. Also includes the implementation of mitigation actions at the appropriate times." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"Identifying a situation or problem that may put specific plans or outcomes in jeopardy, and then organizing actions to mitigate it." (Teri Lund & Susan Barksdale, "10 Steps to Successful Strategic Planning", 2006)

"The process of identifying hazards of property insured; the casualty contemplated in a specific contract of insurance; the degree of hazard; a specific contingency or peril. Generally not the same as security management, but may be related in concerns and activities. Work is done by a risk manager." (Robert McCrie, "Security Operations Management" 2nd Ed., 2006)

"Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk." (Tilo Linz et al, "Software Testing Practice: Test Management", 2007)

"Risk management is a continuous process to be performed throughout the entire life of a project, and an important part of project management activities. The objective of risk management is to identify and prevent risks, to reduce their probability of occurrence, or to mitigate the effects in case of risk occurrence." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"A structured process for managing risk." (David G Hill, "Data Protection: Governance, Risk Management, and Compliance", 2009)

"The process organizations employ to reduce different types of risks. A company manages risk to avoid losing money, protect against breaking government or regulatory body rules, or even assure that adverse weather does not interrupt the supply chain." (Tony Fisher, "The Data Asset", 2009)

"Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"The process of identifying what can go wrong, determining how to respond to risks should they occur, monitoring a project for risks that do occur, and taking steps to respond to the events that do occur." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"Risk management is using managerial resources to integrate risk identification, risk assessment, risk prioritization, development of risk-handling strategies, and mitigation of risk to acceptable levels (ASQ)." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The process of identifying negative and positive risks to a project, analyzing the likelihood and impact of those risks, planning responses to higher priority risks, and tracking risks." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"A policy of determining the greatest potential failure associated with a project." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"Controlling vulnerabilities, threats, likelihood, loss, or impact with the use of security measures. See also risk, threat, and vulnerability." (Mark Rhodes-Ousley, "Information Security: The Complete Reference, Second Edition" 2nd Ed., 2013)

"A process to identify, assess, manage, and control potential events or situations to provide reasonable assurance regarding the achievement of the organization's objectives." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"Managing the financial impacts of unusual events." (Manish Agrawal, "Information Security and IT Risk Management", 2014)

"Systematic application of policies, procedures, methods and practices to the tasks of identifying, analysing, evaluating, treating and monitoring risk." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development, 5th Ed.", 2014)

"The coordinated activities to direct and control an organisation with regard to risk." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"The process of reducing risk to an acceptable level by implementing security controls. Organizations implement risk management programs to identify risks and methods to reduce it. The risk that remains after risk has been mitigated to an acceptable level is residual risk." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"Risk management is a structured approach to monitoring, meas­uring, and managing exposures to reduce the potential impact of an uncertain happening." (Christopher Donohue et al, "Foundations of Financial Risk: An Overview of Financial Risk and Risk-based Financial Regulation, 2nd Ed", 2015)

"Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk. " (ISTQB, "Standard Glossary", 2015)

"The practice of identifying, assessing, controlling, and mitigating risks. Techniques to manage risk include avoiding, transferring, mitigating, and accepting the risk." (Weiss, "Auditing IT Infrastructures for Compliance, 2nd Ed", 2015)

"The discipline and methods used to quantify, track, and reduce where possible various types of defined risk." (Gregory Lampshire, "The Data and Analytics Playbook", 2016)

"The process of identifying individual risks, understanding and analyzing them, and then managing them." (Paul H Barshop, "Capital Projects", 2016)

"Coordinated activities to direct and control an organization with regard to risk." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"Process of identifying and monitoring business risks in a manner that offers a risk/return relationship that is acceptable to an entity's operating philosophy." (Tom Klammer, "Statement of Cash Flows: Preparation, Presentation, and Use", 2018)

"Coordinated activities to direct and control an organisation with regard to risk." (ISO Guide 73:2009)

"Risk management is the identification, assessment and prioritisation of risks [...] followed by coordinated and economical application of resources to minimise, monitor and control the probability and/or impact of unfortunate events or to maximise the realisation of opportunities." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)