Showing posts with label plan. Show all posts
Showing posts with label plan. Show all posts

03 February 2021

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

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

10 April 2016

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)

08 April 2016

Strategic Management: Disaster Recovery Plan (Definitions)

"A plan that establishes technical and organizational measures in order to face events or incidents with potentially huge impact that could even lead to the unavailability of data centers. The DRP development defines and ensures IT emergency procedures that intervene and protect the data relevant for the company activities and services. DRP is usually considered as the only part of the BCP in banking business continuity initiatives." (Vincenzo Morabito & Gianluigi Viscusi, "Information Technology Business Continuity", 2009)

"Generally a plan for enabling an organization to move to alternate system, network, and operational facilities in the event of an incident making the primary facilities unusable." (C Warren Axelrod, "Responsibilities and Liabilities with Respect to Catastrophes", 2009)

"A contingency plan that goes into effect after a full disaster occurs, used to reestablish basic capabilities and resources." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A written plan that explains how a company will recover its IT operations after a natural or man-made disaster that causes data or hardware loss." (Faithe Wempen, "Computing Fundamentals: Introduction to Computers", 2015)

"A plan developed to help a company recover from a disaster. It provides procedures for emergency response, extended backup operations, and post-disaster recovery when an organization suffers a loss of computer processing capability or resources and physical facilities." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide" 8th Ed., 2018)

"Plans that document the steps you can take to replace damaged or destroyed components due to a disaster to restore the integrity of your IT infrastructure. " (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A written plan for processing critical applications in the event of a major hardware or software failure or destruction of facilities." (NIST SP 800-82 Rev. 2)

"A written plan for recovering one or more information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities." (NIST SP 800-34 Rev. 1)

"Management policy and procedures used to guide an enterprise response to a major loss of enterprise capability or damage to its facilities. The DRP is the second plan needed by the enterprise risk managers and is used when the enterprise must recover (at its original facilities) from a loss of capability over a period of hours or days." (CNSSI 4009-2015)

13 February 2014

Systems Engineering: Systems Theory (Just the Quotes)

"Linking the basic parts are communication, balance or system parts maintained in harmonious relationship with each other and decision making. The system theory include both man-machine and interpersonal relationships. Goals, man, machine, method, and process are woven together into a dynamic unity which reacts." (George R Terry, "Principles of Management", 1960)

"Industrial production, the flow of resources in the economy, the exertion of military effort in a war theater-all are complexes of numerous interrelated activities. Differences may exist in the goals to be achieved, the particular processes involved, and the magnitude of effort. Nevertheless, it is possible to abstract the underlying essential similarities in the management of these seemingly disparate systems." (George Dantzig, "Linear programming and extensions", 1963) 

"The aim of systems theory for business is to develop an objective, understandable environment for decision making; that is, if the system within which managers make the decisions can be provided as an explicit framework, then such decision making should be easier to handle." (Richard A Johnson et al, "Systems Theory and Management", Management Science Vol. 10 (2), 1964)

"System theory is basically concerned with problems of relationships, of structure, and of interdependence rather than with the constant attributes of objects. In general approach it resembles field theory except that its dynamics deal with temporal as well as spatial patterns. Older formulations of system constructs dealt with the closed systems of the physical sciences, in which relatively self-contained structures could be treated successfully as if they were independent of external forces. But living systems, whether biological organisms or social organizations, are acutely dependent on their external environment and so must be conceived of as open systems." (Daniel Katz, "The Social Psychology of Organizations", 1966)

"Clearly, if it is possible to have a self-regulating system that implicitly arranges its own stability, then this is of the keenest management interest." (Anthony S Beer, "Management Science", 1968) 

"The management of a system has to deal with the generation of the plans for the system, i. e., consideration of all of the things we have discussed, the overall goals, the environment, the utilization of resources and the components. The management sets the component goals, allocates the resources, and controls the system performance." (C West Churchman, "The Systems Approach", 1968)

"Perhaps the most important single characteristic of modern organizational cybernetics is this: That in addition to concern with the deleterious impacts of rigidly-imposed notions of what constitutes the application of good 'principles of organization and management' the organization is viewed as a subsystem of a larger system(s), and as comprised itself of functionally interdependent subsystems." (Richard F Ericson, "Organizational cybernetics and human values", 1969) 

"Organizationally what is required - and evolving - is systems management." (Peter Drucker, "MANAGEMENT: Tasks, Responsibilities, Practices", 1973)

"The subject of study in systems theory is not a 'physical object', a chemical or social phenomenon, for example, but a 'system': a formal relationship between observed features or attributes. For conceptual reasons, the language used in describing the behavior of systems is that of information processing and goal seeking (decision making control)." (Mihajlo D Mesarovic & Y Takahara, "Foundations for the mathematical theory of general systems", 1975)

"Systems theory looks at the world in terms of the interrelatedness and interdependence of all phenomena, and in this framework an integrated whole whose properties cannot be reduced to those of its parts is called a system. Living organisms, societies, and ecosystems are all systems." (Fritjof Capra, "The Turning Point: Science, Society, and the Turning Culture", 1982)

"The supposition is prevalent the world over that there would be no problems in production or service if only our production workers would do their jobs in the way that they we taught. Pleasant dreams. The workers are handicapped by the system, and the system belongs to the management." (W Edwards Deming, "Out Of The Crisis", 1982)

"A cardinal principle in systems theory is that all parties that have a stake in a system should be represented in its management." (Malcolm Knowles, "The Adult Learner: A Neglected Species", 1984)

"A manager of people needs to understand that all people are different. This is not ranking people. He needs to understand that the performance of anyone is governed largely by the system that he works in, the responsibility of management." (W Edwards Deming, "The New Economics: For Industry, Government, Education", 1993)

"The prevailing style of management must undergo transformation. A system can not understand itself. The transformation requires a view from outside." (W Edwards Deming, "The New Economics: For Industry, Government, Education", 1993)

More quotes on "Systems Theory" at the-web-of-knowledge.blogspot.com

15 April 2007

Software Engineering: Test Plan (Definitions)

"Test case scenarios written to test the different functionalities of the system and make sure it meets requirements." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A document describing the scope, approach, characteristics and features to be tested, necessary tasks, resources, task schedule, responsibilities, and risks." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

[engagement test plan:] "A plan designed to gather sufficient appropriate evidence to support an evaluation of how well the key controls function. This may be developed as part of an engagement work program or may replace the engagement work program." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

[level test plan:] "A plan for a specified level of testing. It identifies the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the associated risk(s). In the title of the plan, the word level is replaced by the organization’s name for the particular level being documented by the plan (e.g., Component Test Plan, Component Integration Test Plan, System Test Plan, and Acceptance Test Plan)." (Tilo Linz et al, "Software Testing Foundations" 4th Ed, 2014)

"It identifies, among other test items, the features to be tested, the testing tasks, who will do each task, the degree of tester independence, the test environment, the test design techniques, and the techniques for measuring results with a rationale for their choice. Additionally, risks requiring contingency planning are described. Thus, a test plan is a record of the test planning process. The document can be divided into a master test plan or a level test plan." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"A document that specifies how a program is to be tested" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process." (IEEE 829)

"A document that outlines the specific steps that will be performed for a particular test, including the required logistical items and expected outcome or response for each step." (NIST SP 800-84)

[level test plan:] "A test plan that typically addresses one test level." (ISTQB)

Related Posts Plugin for WordPress, Blogger...

About Me

My photo
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.