Strategic Management: The Impact of New Technologies III (Checking the Vital Signs)

An organization which went through a major change, like the replacement of a strategic system (e.g. ERP/BI implementations), needs to go through a period of attentive supervision to address the inherent issues that ideally need to be handled as they arise, to minimize their future effects. Some organizations might even go through a convalescence period, which risks to prolong itself if the appropriate remedies aren’t found. Therefore, one needs an entity, who/which has the skills to recognize the symptoms, understand what’s happening and why, respectively of identifying the appropriate actions.

Given technologies’ multi-layered complexity and the volume of knowledge for understanding them, the role of the doctor can be seldom taken by one person. Moreover, the patient is an organization, each person in the organization having usually local knowledge about the patient. The needed knowledge is dispersed trough the organization, and one needs to tap into that knowledge, identify the people close to technologies and business area, respectively allow such people exchange information on a regular basis.

The people who should know the best the organization are in theory the management, however they are usually too far away from technologies and often too busy with management topics. IT professionals are close to technologies, though sometimes too far away from the patient. The users have a too narrow overview, while from logistical and economic reasons the number of people involved should be kept to a minimum. A compromise is to designate one person from each business area who works with any of the strategic systems, and assure that they have the technical and business knowledge required. It’s nothing but the key-user concept, though for it to work the key-users need not only knowledge but also the empowerment to act when the symptoms appear.

Big organizations have also a product owner for each application who supervises the application through its entire lifecycle, and who needs to coordinate with the IT, business and service providers. This is probably a good idea in order to assure that the ROI is reached over time, respectively that the needs of the system are considered within the IT operation context. In small organizations, the role can be taken by a technical or a business resource with deeper skills then the average user, usually a key-user. However, unless joined with the key-user role, the product owner’s focus will be the product and seldom the business themes.

The issues that need to be overcome after major changes are usually cross-functional, being imperative for people to work together and find solutions. Unfortunately, it’s also in human nature to wait until the issues are big enough to get the proper attention. Unless the key-users have the time allocated already for such topics, the issues will be lost in the heap of operational and tactical activities. This time must be allocated for all key-users and the technical resources needed to support them.

Some organizations build temporary working parties (groups of experts working together to achieve specific goals) or similar groups. However, the statute of such group needs to be permanent if the organization wants to continuously have its health in check, to build the needed expertize and awareness about occurred or potential issues. Centers of excellence/expertize (CoE) or competency centers (CC) are such working groups with permanent statute, having defined roles, responsibilities, and processes for supporting and promoting the effective use of technologies within the organization, respectively of monitoring and systematically addressing the risks and opportunities associated with them.

There’s also the null hypothesis, doing nothing, relying solely on employees’ professionalism, though without defined responsibility, accountability and empowerment, it can get messy.

Previous Post <<||>> Next Post

Data Migrations (DM): Quality Acceptance Criteria I

Data Migrations Series

Introduction

When designing a Data Migration (DM), respectively any software solution, it’s important to take inventory of project’s requirements, evaluate, document, communicate and monitor them accordingly. Each of them can have an important impact on the solution, as a solution’s success will be validated and judged upon them. Therefore, the identified requirements must be considered as baseline for conceptualization, design, implementation and sign-off, and should go through same procedures and rigor as other projects requirements. The existence of a standardized Requirements Management process can facilitate their management through project’s lifecycle. 

The requirements are usually driven by the source and target systems (e.g. data import/export features, data models and their constraints), the environments they are hosted on (e.g. cloud vs. on-premise), respectively the layers in between (e.g. network, firewalls), project and business aspects that need to be considered (e.g. freeze window for the Go-Live, data availability dates, data quality, external dependencies, etc.). They resume to the solution itself as well to the data and processes involved, and are reflected but not limited to the following important aspects, that can be considered upon case also as quality acceptance criteria: 

Accessibility

Accessibility is the degree to which the data are available for a solution so it can be processed when needed, in the form, by resources, or means intended for processing. It’s critical for a DM solution to access or have available the master, transaction, parameter and further data when needed. The team must make sure that the data become easily accessible. 

Unavailability of data can impact the DM and can easily lead to delays in the project. This also means that the various project activities (parametrization, cleansing, enrichment, development) need to be synchronized with the migration activities. 

Upon case, accessibility can involve the solution itself expressed as the degree to which it’s available to the resources supposed to use it. Certain architectural decisions can have impact on the carried activities. As the solution is usually deployed on a server, it can happen that only a limited number of people is able to access it concurrently. Moreover, a DM’s complexity makes the involvement of multiple developers challenging.  

Accountability

Accountability is the degree to which accountability is enforced for the various resources involved in DM processes and related activities. As multiple resources are involved for parametrization, cleaning, processing, validation, software development, each resource needs to be aware about the extent they are accountable for. Without accountability made explicit, there’s the danger that the activities are neglected, with all the implications deriving from it – quality deviations, delays, data unavailability, etc. 

Adaptability

Adaptability is the degree to which a solution can be adapted to environment or requirement changes. Even if typically, the environments don’t change, it doesn’t mean that this will not happen as the IT infrastructure goes through continuous changes that can affect directly or indirectly a migration.  Same can be said about requirements, which however have higher probability to change even late in the process as new knowledge is acquired and needs to be integrated in the solution. 

Atomicity 

Atomicity is the degree to which data entities can be processes at the required level of abstraction in an atomic manner. Even if transformations occur during the various stages, the data belonging to an entity need to be kept and processed together (e.g. Customers and their Addresses). This can involve processing attributes in advance even if the data might be required later. There can be situations in which the data belonging to the same entity need to be processed on different paths, though in the end it’s important to keep the data together, when the processing logic allows it. 

Next Post

Governance: Responsibility (Just the Quotes)

"Weak character coupled with honored place, meager knowledge with large plans, limited powers with heavy responsibility, will seldom escape disaster." ("I Ching" ["Book of Changes"], cca. 600 BC)

"The only way for a large organization to function is to decentralize, to delegate real authority and responsibility to the man on the job. But be certain you have the right man on the job." (Robert E Wood, 1951)

"[...] authority - the right by which superiors are able to require conformity of subordinates to decisions - is the basis for responsibility and the force that binds organization together. The process of organizing encompasses grouping of activities for purposes of management and specification of authority relationships between superiors and subordinates and horizontally between managers. Consequently, authority and responsibility relationships come into being in all associative undertakings where the superior-subordinate link exists. It is these relationships that create the basic character of the managerial job." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"[...] authority for given tasks is limited to that for which an individual may properly held responsible." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"If charts do not reflect actual organization and if the organization is intended to be as charted, it is the job of effective management to see that actual organization conforms with that desired. Organization charts cannot supplant good organizing, nor can a chart take the place of spelling out authority relationships clearly and completely, of outlining duties of managers and their subordinates, and of defining responsibilities." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Responsibility cannot be delegated. While a manager may delegate to a subordinate authority to accomplish a service and the subordinate in turn delegate a portion of the authority received, none of these superiors delegates any of his responsibility. Responsibility, being an obligation to perform, is owed to one's superior, and no subordinate reduces his responsibility by assigning the duty to another. Authority may be delegated, but responsibility is created by the subordinate's acceptance of his assignment." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Viewed internally with respect to the enterprise, responsibility may be defined as the obligation of a subordinate, to whom a superior has assigned a duty, to perform the service required. The essence of responsibility is, then, obligation. It has no meaning except as it is applied to a person." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"You can delegate authority, but you can never delegate responsibility by delegating a task to someone else. If you picked the right man, fine, but if you picked the wrong man, the responsibility is yours - not his." (Richard E Krafve, The Boston Sunday Globe, 1960)

"Modern organization makes demands on the individual to learn something he has never been able to do before: to use organization intelligently, purposefully, deliberately, responsibly [...] to manage organization [...] to make [...] his job in it serve his ends, his values, his desire to achieve." (Peter F Drucker, The Age of Discontinuity, 1968)

"[Management by objectives is] a process whereby the superior and the subordinate managers of an enterprise jointly identify its common goals, define each individual's major areas of responsibility in terms of the results expected of him, and use these measures as guides for operating the unit and assessing the contribution of each of its members." (Robert House, "Administrative Science Quarterly", 1971)

"'Management' means, in the last analysis, the substitution of thought for brawn and muscle, of knowledge for folkways and superstition, and of cooperation for force. It means the substitution of responsibility for obedience to rank, and of authority of performance for authority of rank. (Peter F Drucker, "People and Performance", 1977)

"[...] the first criterion in identifying those people within an organization who have management responsibility is not command over people. It is responsibility for contribution. Function rather than power has to be the distinctive criterion and the organizing principle." (Peter F Drucker, "People and Performance", 1977)

"The productivity of work is not the responsibility of the worker but of the manager." (Peter F Drucker, "Management in Turbulent Times", 1980)

"By assuming sole responsibility for their departments, managers produce the very narrowness and self-interest they deplore in subordinates. When subordinates are relegated to their narrow specialties, they tend to promote their own practical interests, which then forces other subordinates into counter-advocacy. The manager is thereby thrust into the roles of arbitrator, judge, and referee. Not only do priorities become distorted, but decisions become loaded with win/lose dynamics. So, try as the manager might, decisions inevitably lead to disgruntlement and plotting for the next battle." (David L Bradford & Allan R Cohen, "Managing for Excellence", 1984)

"The man who delegates responsibilities for running the company, without knowing the intimate details of what is involved, runs the enormous risk of rendering himself superfluous." (Harold Geneen, "Managing", 1984)

"Leadership is the total effect you have on the people and events around you. This effect is your influence. Effective leading is being consciously responsible for your organizational influence. [...] The essence of leadership is knowing that YOU CAN NEVER NOT LEAD. You lead by acts of commission and acts of omission." (Kenneth Schatz & Linda Schatz, "Managing by Influence", 1986)

"Looking for differences between the more productive and less productive organizations, we found that the most striking difference is the number of people who are involved and feel responsibility for solving problems." (Michael McTague, "Personnel Journal", 1986)

"Management has a responsibility to explain to the employee how the routine job contributes to the business's objectives. If management cannot explain the value of the job, then it should be eliminated and the employee reassigned." (Douglas M Reid, Harvard Business Review, 1986)

"A systematic effort must be made to emphasize the group instead of the individual. [...] Group goals and responsibilities can usually overcome any negative reactions to the individual and enforce a standard of cooperation that is attainable by persuasion or exhortation." (Eugene Raudsepp, MTS Digest, 1987)

"An individual without information cannot take responsibility; an individual who is given information cannot help but take responsibility." (Jan Carlzon, "Moments of Truth", 1987)

"Executives have to start understanding that they have certain legal and ethical responsibilities for information under their control." (Jim Leeke, PC Week, 1987)

"If responsibility - and particularly accountability - is most obviously upwards, moral responsibility also reaches downwards. The commander has a responsibility to those whom he commands. To forget this is to vitiate personal integrity and the ethical validity of the system." (Roger L Shinn, "Military Ethics", 1987)

[...] quality assurance is the job of the managers responsible for the product. A separate group can't 'assure' much if the responsible managers have not done their jobs properly. [...] Managers should be held responsible for quality and not allowed to slough off part of their responsibility to a group whose name sounds right but which cannot be guaranteed quality if the responsible managers have not been able to do so." (Philip W. Metzger, "Managing Programming People", 1987)

"Responsibility is a unique concept [...] You may share it with others, but your portion is not diminished. You may delegate it, but it is still with you. [...] If responsibility is rightfully yours, no evasion, or ignorance or passing the blame can shift the burden to someone else. Unless you can point your finger at the man who is responsible when something goes wrong, then you have never had anyone really responsible." (Hyman G Rickover, "The Rickover Effect", 1992)

"If you treat people as though they are responsible, they tend to behave that way." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"You can’t delegate responsibility without giving a person authority commensurate with it." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"What do people do today when they don’t understand 'the system'? They try to assign responsibility to someone to fix the problem, to oversee 'the system', to coordinate and control what is happening. It is time we recognized that 'the system' is how we work together. When we don’t work together effectively putting someone in charge by its very nature often makes things worse, rather than better, because no one person can understand 'the system' well enough to be responsible. We need to learn how to improve the way we work together, to improve 'the system' without putting someone in charge, in order to make things work." (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)

"In order to cultivate a culture of accountability, first it is essential to assign it clearly. People ought to clearly know what they are accountable for before they can be held to it. This goes beyond assigning key responsibility areas (KRAs). To be accountable for an outcome, we need authority for making decisions, not just responsibility for execution. It is tempting to refrain from the tricky exercise of explicitly assigning accountability. Executives often hope that their reports will figure it out. Unfortunately, this is easier said than done." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Any software project must have a technical leader, who is responsible for all technical decisions made by the team and have enough authority to make them. Responsibility and authority are two mandatory components that must be present in order to make it possible to call such a person an architect." (Yegor Bugayenko, "Code Ahead", 2018)

"Responsibility means an inevitable punishment for mistakes; authority means full power to make them." (Yegor Bugayenko, "Code Ahead", 2018)

Governance: Accountability (Definitions)

"The obligation to answer for a responsibility conferred. It is a relationship based on the obligation to demonstrate and take responsibility for performance in light of agreed expectations, whether or not those actions were within your direct control." (Paul C Dinsmore et al, "Enterprise Project Governance", 2012)

"The ability to trace activities on information resources to unique individuals who accept responsibility for their activities on the network." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

"The obligation to answer for a responsibility that has been conferred. It presumes the existence of at least two parties: one who allocates responsibility and one who accepts it with the undertaking to report upon the manner in which it has been discharged." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"A component of a work relationship between two people wherein one accepts the requirement to provide an account to the other of the following three questions relating to work. What did you do? How did you do it? Why did you do it that way? The most common application of the concept of accountability is that which applies as a function of a contract of employment within an organisation and though in our experience this requirement to accept accountability is rarely articulated clearly in the contract; it should be. An effective accountability discussion includes a discussion of the three questions above including how and why the person used particular processes to turn inputs into required outputs. Accountability is not a collective noun for tasks, as in ‘your accountabilities are …’. Too often this is used in employment, contracts and in role descriptions, which confuses work and accountability. A role may describe work but we are still to discover if the person is actually held to account for that work. Accountability as a concept applying within coherent social groups is brought to the fore for society in general by the process of the courts wherein people in the witness box are required to answer, in public, questions as to what, how and why something was, or was not, done and judgement is passed as an outcome of this process." (Catherine Burke et al, "Systems Leadership", 2nd Ed., 2018)

"A security principle indicating that individuals must be identifiable and must be held responsible for their actions." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide" 8th Ed., 2018)

"Assuming a transparent and appropriate level of responsibility for data assets that are under one’s care, which includes honoring obligations associated with good practice." (Kevin J Sweeney, "Re-Imagining Data Governance", 2018)

"The property of a system or system resource which ensures that the actions of a system entity may be traced uniquely to that entity, which can then be held responsible for its actions." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"Responsibility of data processing actors to put in place appropriate and effective measures to ensure compliance with the GDPR and be able to demonstrate so." (Yordanka Ivanova, "Data Controller, Processor, or Joint Controller: Towards Reaching GDPR Compliance in a Data- and Technology-Driven World", 2020)

"Principle that an individual is entrusted to safeguard and control equipment, keying material, and information and is answerable to proper authority for the loss or misuse of that equipment or information." (CNSSI-4009)

"The security goal that generates the requirement for actions of an entity to be traced uniquely to that entity. This supports nonrepudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal action." (SP 800-27)

Governance: Delegation (Just the Quotes)

"Failure to delegate causes managers to be crushed and fail under the weight of accumulated duties that they do not know and have not learned to delegate." (James D Mooney, "Onward Industry!", 1931)

"Delegation means the conferring of a specified authority by a higher authority. In its essence it involves a dual responsibility. The one to whom responsibility is delegated becomes responsible to the superior for doing the job. but the superior remains responsible for getting the Job done. This principle of delegation is the center of all processes in formal organization. Delegation is inherent in the very nature of the relation between superior and subordinate. The moment the objective calls for the organized effort of more than one person, there is always leadership with its delegation of duties." (James D Mooney, "The Principles of Organization", 1947)

"The only way for a large organization to function is to decentralize, to delegate real authority and responsibility to the man on the job. But be certain you have the right man on the job." (Robert E Wood, 1951)

"You can delegate authority, but you can never delegate responsibility by delegating a task to someone else. If you picked the right man, fine, but if you picked the wrong man, the responsibility is yours - not his." (Richard E Krafve, The Boston Sunday Globe, 1960)

"Centralized controls are designed to ensure that the chief executive can find out how well the delegated authority and responsibility are being exercised." (Ernest Dale, "Management: Theory and practice", 1965)

"Guidelines for bureaucrats: (1) When in charge, ponder. (2) When in trouble, delegate. (3) When in doubt, mumble." (James Boren, New York Times, 1970)

"We find that the manager, particularly at senior levels, is overburdened with work. With the increasing complexity of modern organizations and their problems, he is destined to become more so. He is driven to brevity, fragmentation, and superficiality in his tasks, yet he cannot easily delegate them because of the nature of his information. And he can do little to increase his available time or significantly enhance his power to manage. Furthermore, he is driven to focus on that which is current and tangible in his work, even though the complex problems facing many organizations call for reflection and a far-sighted perspective." (Henry Mintzberg, "The structuring of organizations", 1979)

"Do not delegate an assignment and then attempt to manage it yourself - you will make an enemy of the overruled subordinate." (Wess Roberts, "Leadership Secrets of Attila the Hun", 1985)

"Surround yourself with the best people you can find, delegate authority, and don't interfere." (Ronald Reagan, Fortune, 1986)

"People and organizations don't grow much without delegation and completed staff work because they are confined to the capacities of the boss and reflect both personal strengths and weaknesses." (Stephen Covey, "Principle Centered Leadership", 1992)

"Responsibility is a unique concept [...] You may share it with others, but your portion is not diminished. You may delegate it, but it is still with you. [...] If responsibility is rightfully yours, no evasion, or ignorance or passing the blame can shift the burden to someone else. Unless you can point your finger at the man who is responsible when something goes wrong, then you have never had anyone really responsible." (Hyman G Rickover, "The Rickover Effect", 1992)

"We accomplish all that we do through delegation - either to time or to other people." (Stephen Covey, "Daily Reflections for Highly Effective People", 1994)

"The inability to delegate is one of the biggest problems I see with managers at all levels." (Eli Broad, "The Art of Being Unreasonable: Lessons in Unconventional Thinking", 2012)

"Delegation of authority is one of the most important functions of a leader, and he should delegate authority to the maximum degree possible with regard to the capabilities of his people. Once he has established policy, goals, and priorities, the leader accomplishes his objectives by pushing authority right down to the bottom. Doing so trains people to use their initiative; not doing so stifles creativity and lowers morale." (Thornas H Moorer)

Governance: Accountability (Just the Quotes)

"To hold a group or individual accountable for activities of any kind without assigning to him or them the necessary authority to discharge that responsibility is manifestly both unsatisfactory and inequitable. It is of great Importance to smooth working that at all levels authority and responsibility should be coterminous and coequal." (Lyndall Urwick, "Dynamic Administration", 1942)

"Complete accountability is established and enforced throughout; and if there there is any error committed, it will be discovered on a comparison with the books and can be traced to its source." (Alfred D Chandler Jr, "The Visible Hand", 1977)

"If responsibility - and particularly accountability - is most obviously upwards, moral responsibility also reaches downwards. The commander has a responsibility to those whom he commands. To forget this is to vitiate personal integrity and the ethical validity of the system." (Roger L Shinn, "Military Ethics", 1987)

"Perhaps nothing in our society is more needed for those in positions of authority than accountability." (Larry Burkett, "Business By The Book: Complete Guide of Biblical Principles for the Workplace", 1990)

"Corporate governance is concerned with holding the balance between economic and social goals and between individual and communal goals. The governance framework is there to encourage the efficient use of resources and equally to require accountability for the stewardship of those resources. The aim is to align as nearly as possible the interests of individuals, corporations and society." (Dominic Cadbury, "UK, Commission Report: Corporate Governance", 1992)

"Accountability is essential to personal growth, as well as team growth. How can you improve if you're never wrong? If you don't admit a mistake and take responsibility for it, you're bound to make the same one again." (Pat Summitt, "Reach for the Summit", 1999)

"Responsibility equals accountability equals ownership. And a sense of ownership is the most powerful weapon a team or organization can have." (Pat Summitt, "Reach for the Summit", 1999)

"There's not a chance we'll reach our full potential until we stop blaming each other and start practicing personal accountability." (John G Miller, "QBQ!: The Question Behind the Question", 2001)

"Democracy is not about trust; it is about distrust. It is about accountability, exposure, open debate, critical challenge, and popular input and feedback from the citizenry." (Michael Parenti, "Superpatriotism", 2004)

"No individual can achieve worthy goals without accepting accountability for his or her own actions." (Dan Miller, "No More Dreaded Mondays", 2008)

"In putting together your standards, remember that it is essential to involve your entire team. Standards are not rules issued by the boss; they are a collective identity. Remember, standards are the things that you do all the time and the things for which you hold one another accountable." (Mike Krzyzewski, "The Gold Standard: Building a World-Class Team", 2009)

"Nobody can do everything well, so learn how to delegate responsibility to other winners and then hold them accountable for their decisions." (George Foreman, "Knockout Entrepreneur: My Ten-Count Strategy for Winning at Business", 2010)

"Failing to hold someone accountable is ultimately an act of selfishness." (Patrick Lencioni, "The Advantage, Enhanced Edition: Why Organizational Health Trumps Everything Else In Business", 2012)

"We cannot have a just society that applies the principle of accountability to the powerless and the principle of forgiveness to the powerful. This is the America in which we currently reside." (Chris Hayes, "Twilight of the Elites: America After Meritocracy", 2012)

"Artificial intelligence is a concept that obscures accountability. Our problem is not machines acting like humans - it's humans acting like machines." (John Twelve Hawks, "Spark", 2014)

"In order to cultivate a culture of accountability, first it is essential to assign it clearly. People ought to clearly know what they are accountable for before they can be held to it. This goes beyond assigning key responsibility areas (KRAs). To be accountable for an outcome, we need authority for making decisions, not just responsibility for execution. It is tempting to refrain from the tricky exercise of explicitly assigning accountability. Executives often hope that their reports will figure it out. Unfortunately, this is easier said than done." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Some hierarchy is essential for the effective functioning of an organization. Eliminating hierarchy has the frequent side effect of slowing down decision making and diffusing accountability." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Accountability makes no sense when it undermines the larger goals of education." (Diane Ravitch, "The Death and Life of the Great American School System", 2016)

"[...] high-accountability teams are characterized by having members that are willing and able to resolve issues within the team. They take responsibility for their own actions and hold each other accountable. They take ownership of resolving disputes and feel empowered to do so without intervention from others. They learn quickly by identifying issues and solutions together, adopting better patterns over time. They are able to work without delay because they don’t need anyone else to resolve problems. Their managers are able to work more strategically without being bogged down by day-to-day conflict resolution." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"In a workplace setting, accountability is the willingness to take responsibility for one’s actions and their outcomes. Accountable team members take ownership of their work, admit their mistakes, and are willing to hold each other accountable as peers." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Low-accountability teams can be recognized based on their tendency to shift blame, avoid addressing issues within the team, and escalate most problems to their manager. In low-accountability teams, it is difficult to determine the root of problems, failures are met with apathy, and managers have to spend much of their time settling disputes and addressing performance. Members of low-accountability teams believe it is not their role to resolve disputes and instead shift that responsibility up to the manager, waiting for further direction. These teams fall into conflict and avoidance deadlocks, unable to move quickly because they cannot resolve issues within the team."

Strategic Management: Stakeholder (Definitions)

"In the CMMI Product Suite, a group or individual that is affected by or is in some way accountable for the outcome of an undertaking. Stakeholders may include project members, suppliers, customers, end users, and others." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"Individuals and organizations that are involved in or possibly affected by the data warehouse project activities." (Margaret Y Chu, "Blissful Data ", 2004)

"Someone with an interest in the outcome of a project, either because he or she has funded it, will use it, or will be affected by it." (Ken Schwaber, "Agile Project Management with Scrum", 2004)

"A group or individual affected by, or in some way accountable for, the outcome of an activity or process. Stakeholders may include the project team, suppliers, customers, purchasers, end users, and others." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"a role that is concerned with the quality and content of a work product." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"Anyone who has a stake in technical training, is affected by technical training or the problem it will address, or can assist with technical training." (Bettina M Davis & Wendy L Combsand, "Demystifying Technical Training: Partnership, Strategy, and Execution", 2009)

"Person or organization (e.g., customer, sponsor, performing organization, or the public) that is actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"An organization, person, process, or system that can be affected by a change to a system or process." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"An individual participant or member of a business function, department, or group charged with, and responsible for, performing tasks or activities as part of a business process." (Carl F Lehmann, "Strategy and Business Process Management", 2012)

"An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio." (Project Management Institute, "The Standard for Portfolio Management" 3rd Ed., 2012)

"Any individual, group, or organization that can affect, be affected by, or perceive itself to be affected by an initiative (program, project, activity, risk)." (Paul C Dinsmore et al, "Enterprise Project Governance", 2012)

"Any person with a vested interest in the project. Project stakeholders include the project sponsor, project manager, team members, and end users of the project result." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"Anyone with an interest in your project – whether affected by its outcome or process, or with an ability to affect its outcome or process." (Mike Clayton, "Brilliant Project Leader", 2012)

"Individuals who have varying levels of commitment to a project or program for a given community or setting." (Carol A Brown, "Using Logic Models for Program Planning in K20 Education", 2013)

"Any individual or entity that has an influence on or is being impacted upon (directly or indirectly) by the project." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development, 5th Ed.", 2014)

"Any party who affects, or is affected by, a project or activity (within and external to an organization). For an internal audit function, stakeholders include the board and audit committee, chief executive office, senior management, audit clients, and the external auditors." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"Individual, team, or organization that has an interest in or is affected by the result of architectural change." (Gilbert Raymond & Philippe Desfray, "Modeling Enterprise Architecture with TOGAF", 2014)

"Someone that has a vested interest in a project. Stakeholders are often high-level managers or executives with authority to resolve problems within a project." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"A stakeholder is someone with an interest in the future of a business, enterprise, or organization, and usually includes individual customers, borrowers, depositors, investors, employees, shareholders, regulators, and the public." (Christopher Donohue et al, "Foundations of Financial Risk: An Overview of Financial Risk and Risk-based Financial Regulation, 2nd Ed", 2015)

"Someone who has a stake in the outcome of the project. Typically, this includes users, customers (if those are different from users), sponsors, managers, and development team members." (Rod Stephens, "Beginning Software Engineering", 2015)

"Any person or organization who is affected by the opportunity and who can affect the shape of the opportunity itself." (Paul H Barshop, "Capital Projects", 2016)

"A person in the organization who has a vested interest in a project or activity and the outcomes." (Jonathan Ferrar et al, "The Power of People: Learn How Successful Organizations Use Workforce Analytics To Improve Business Performance", 2017)

"A person, a group, or an organization that has interest or concern in an organization. Stakeholders can affect or be affected by an organization’s actions, objectives, and policies. Some examples of key stakeholders are creditors, directors, employees, government (and its agencies), owners (shareholders), suppliers, unions, and the community from which the business draws its resources." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"An individual, group, or organization that may affect or be affected by project work, including decisions, activities, and outcome or deliverables. This applies to a project, program, and portfolio." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)

"In software development, a stakeholder is a person who has a vested interest in the software being developed. For example customers and users are stakeholders." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

"a person or organisation that can affect, be affected by, or perceive themselves to be affected by a decision or activity" (ISO Guide 73:2009)

"all people who have interest in an organization, project, service, etc." (ITIL)

"Any person who has an interest in an IT project. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. Stakeholders can exercise control over both the immediate system operational characteristics, as well as over long-term system lifecycle considerations (such as portability, lifecycle costs, environmental considerations, and decommissioning of the system)." (IQBBA)

Project Management: Project Planning (Just the Quotes)

"Planning starts usually with something like a general idea. For one reason or another it seems desirable to reach a certain objective, and how to reach it is frequently not too clear. The first step then is to examine the idea carefully in the light of the means available. Frequently more fact-finding about the situation is required. If this first period of planning is successful, two items emerge: namely, an 'over-all plan' of how to reach the objective and secondly, a decision in regard to the first step of action. Usually this planning has also somewhat modified the original idea. The next period is devoted to executing the first step of the original plan." (Kurt Lewin, "Action research and minority problems", 1946)

"Every company has beloved projects on which if prices had held up, if the contractors had finished on time (or finished at all), if the plans hadn't been altered, if the thing had actually worked, the planned return would have been earned. But since some or all of these calamities [things that don't go as expected] usually happen, any manager who neglects to allow for them is not planning - merely thinking wishfully. Desire for the project has, as usual, overtaken desire for profit." (Ernest Dale, "Planning and developing the company organization structure", 1952)

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

"Since software construction is inherently a systems effort - an exercise in complex interrelationships - communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning [increasing the workers]. Adding more people then lengthens, not shortens, the schedule." (Frederick Brook, "The Mythical Man-Month", 1975)

"Because one has to be an optimist to begin an ambitious project, it is not surprising that underestimation of completion time is the norm." (Fernando J Corbató, "On Building Systems That Will Fail", 1991)

"If we decide to plan not to lose, we take a defensive posture in which we expend huge amounts of effort trying to prevent and track errors. This will lead us to a very heavyweight planning process in which we try to plan everything up front in a much detail as possible. Such a process will have many review steps, sign-offs, authorizations, and phase gates. Such a planning process is highly adept at making sure that blame can be assigned when something fails; but takes no direct steps towards making sure that the right system is delivered at a reasonable cost." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"One of the purposes of planning is we always want to work on the most valuable thing possible at any given time. We can’t pick features at random and expect them to be most valuable. We have to begin development by taking a quick look at everything that might be valuable, putting all our cards on the table. At the beginning of each iteration the business (remember the balance of power) will pick the most valuable features for the next iteration." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time software gets there, the customers don’t want what was planned, they want something different." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"Projects sometimes fail long before they deliver anything. At some point they may be determined to be too expensive to continue. Or perhaps they took too long to develop and the business need evaporated. Or perhaps the requirements change so often that the developers can never finish one thing without having to stop and start all over on something new. Certainly these are planning failures." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"There are two ways to approach prevention of these planning failures. We can plan not to lose, or we can plan to win. The two are not identical. Planning not to lose is defensive; while planning to win is aggressive. [...] the problem that planning is supposed to solve is simply, to build the right system at the right cost. If we take a defensive posture by planning not to lose, we will be able to hold people accountable for any failures; but at an enormous cost. If we take an aggressive posture and plan to win, we will be unafraid to make errors, and will continuously correct them to meet our goals." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"We plan because: We need to ensure that we are always working on the most important thing we need to do. We need to coordinate with other people. When unexpected events occur we need to understand the consequences for the first two." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"When we plan to win we take direct steps to ensure that we are building the right system at the best possible cost. Every action we take goes towards that end. Instead of trying to plan everything up front, we plan just the next few steps; and then allow customer feedback to correct our trajectory. In this way, we get off the mark quickly, and then continuously correct our direction. Errors are unimportant because they will be corrected quickly." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"If you have no plan, you cannot have control, by definition, because it is your plan that tells where you are supposed to be in the first place. Further, if you don’t know where you are, you can’t have control. This comes from your information system. Most organizations have difficulties with both of these." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"No project can succeed when the team members have no commitment to the plan, so the first rule of project planning is that the people who must do the work should help plan that part of the project. You will not only gain their commitment to the plan, but also most likely cover all of the important issues that you may individually have forgotten."(James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"The big fallacy in our assumptions is that the world will stand still while we execute our project plan." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Project planning is the key to effective project management. Detailed and accurate planning of a project produces the managerial information that is the basis of project justification (costs, benefits, strategic impact, etc.) and the defining of the business drivers (scope, objectives) that form the context for the technical solution. In addition, project planning also produces the project schedules and resource allocations that are the framework for the other project management processes: tracking, reporting, and review." (Rob Thomsett, "Radical Project Management", 2002)

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

"The pathology of setting a deadline to the earliest articulable date essentially guarantees that the schedule will be missed." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"Ending up somewhere entirely different from where you expected to go is the norm in this world. Software projects are prime illustrations of the law of unintended consequences, and their innovations and breakthroughs are more often side effects than planned outcomes." (Scott Rosenberg, "Dreaming in Code", 2007)

"[…] in software development, as in all things, plans get dodgier the farther into the future one looks. Any developer who has been around the block will admit that the cavalcade of methodologies over three decades of software history has left the field richer and given programmers useful new tools and ways of thinking about their work. But finding a developer or team that actually subscribes to a particular methodology isn’t easy." (Scott Rosenberg, "Dreaming in Code", 2007)

"The picture of digital progress that so many ardent boosters paint ignores the painful record of actual programmers’ epic struggles to bend brittle code into functional shape. That record is of one disaster after another, marking the field’s historical time line like craters. Anyone contemplating the start of a big software development project today has to contend with this unfathomably discouraging burden of experience. It mocks any newcomer with ambitious plans, as if to say, What makes you think you’re any different?" (Scott Rosenberg, "Dreaming in Code", 2007)

"Users may be annoyed by bugs, and software developers may be disappointed by their inability to perfect their work, and managers may be frustrated by the unreliability of their plans. But in the end, none of that matters as much as the simple fact that software does not work the way we think, and until it does, it is not worth trying to perfect." (Scott Rosenberg, "Dreaming in Code", 2007)

"And even if we make good plans based on the best information available at the time and people do exactly what we plan, the effects of our actions may not be the ones we wanted because the environment is nonlinear and hence is fundamentally unpredictable. As time passes the situation will change, chance events will occur, other agents such as customers or competitors will take actions of their own, and we will find that what we do is only one factor among several which create a new situation." (Stephen Bungay, "The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results", 2010)

"A project plan is a prediction. It predicts that a team of N people will complete X amount of work by Y date." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Development is a design process. Design processes are generally evaluated by the value they deliver rather than a conformance to plan. Therefore, it makes sense to move away from plan-driven projects and toward value-driven projects. […] The realization that the source code is part of the design, not the product, fundamentally rewires our understanding of software." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"The planning fallacy is the systematic tendency for project plans and budgets to undershoot. […] The reasons for the planning fallacy are partly psychological, partly cultural, and partly to do with our limited ability to think probabilistically." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"An effort estimate is not complete without including its assumptions. Estimate assumptions include any and all underlying factors the estimate relies upon. Assumptions are especially important in more rigid estimation environments, but they are a good practice even where expectations are more flexible. Explicitly listing all assumptions helps to remove ambiguity and avoid misunderstandings during project delivery." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Plans allow us to think through objectives beforehand in the hope of being prepared for delivery. Plans are useful when they preempt conflict, direct efforts in harmony, and align expectations. Plans are not useful when they waste valuable build time or provide a false sense of security, for example, by missing unknown unknowns." (Morgan Evans, "Engineering Manager's Handbook", 2023)

Project Management: Project Governance (Definitions)

"Systems and methods by which a program is monitored, managed, and supported by its sponsoring organization." (Project Management Institute, "The Standard for Program Management" 3rd Ed.., 2013)

"A document that describes the systems and methods to be used to monitor, manage, and support a given program, and the responsibilities of specific individuals for ensuring the timely and effective use of those systems and methods." (Project Management Institute, "The Standard for Program Management" 3rd Ed. 2013)

"The alignment of project objectives with the strategy of the larger organization by the project sponsor and project team. A project’s governance is defined by and is required to fit within the larger context of the program or organization sponsoring it, but is separate from organizational governance." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"Project governance helps make sure that a project is executed according to the standards of the organization performing the project. Governance keeps all project activities above board and ethical, and also creates accountability." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"The framework, functions, and processes that guide project management activities in order to create a unique product, service, or result to meet organizational, strategic, and operational goals." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK Guide)", 2017)

"Governance is the framework by which an organization is directed and controlled. Project governance includes, but is not limited to, those areas of organizational governance that are specifically related to project activities." (ISO 21500:2012)