Concept Management Quarter

Change Management Quarter (hereinafter, the Quarter) is a lecture introducing the learners to portfolio implementations primarily through key topics related to iterative development. The Quarter is the last of four lectures of Portfolio Quadrivium, which is the first of seven modules of Septem Artes Administrativi (hereinafter, the Course). The Course is designed to introduce the learners to general concepts in business administration, management, and organizational behavior.

Outline

Enterprise Architecture Quarter is the predecessor lecture. In the enterprise design series, the previous lecture is Organizational Culture Quarter.

Portfolio implementation is the enterprise implementation of the enterprise portfolio. This lecture concentrates on iterative development because this development is the main technique to do that.

Concepts

1. Change management. (1) The management of change and development within an enterprise; (2) The controlled identification and implementation of required changes within a computer system.
   • Enterprise change management. Practice and a set of concepts based on that practice of preparing and supporting of enterprises, their stakeholders and technology in making enterprise change.
2. Enterprise goal. A desired outcome towards which the enterprise effort is directed.
   • Goal (objective). Desired outcome or target.
   • Real goal. A goal that an organization actually pursues, as defined by the actions of its members.
   • Means-end chain. An integrated network of goals in which the accomplishment of goals at one level serves as the means for achieving the goals, or ends, at the next level.
   • Stated goal. An official statement of what an organization says, and what it wants its various stakeholders to believe, its goals are.
3. Vision statement. A formal articulation of an organization's vision or mission.
   • Business goal. A state or condition the business must satisfy to reach its vision.
   • Business policy. A business policy is a non-actionable directive that supports a business goal.
   • Business rule(s). A business rule is a specific, actionable, testable directive that is under the control of the business and supports a business policy.
   • Business plan. A written document that interprets the strategic plan for enterprise stakeholders, for instance, financial or governmental institutions with regard to a business opportunity and articulation of how the identified opportunity is to be seized and exploited.
4. Enterprise administration. Practice and a set of concepts, based on that practice, that define culture of administering all enterprise efforts from identifying business opportunities and up to getting of all enterprise outcomes and/or achieving enterprise impacts.
   • Administration. The process or activity of running a business, organization, etc. or the officials who executive that process or activity.
   • Management. The process or activity of dealing with or controlling things or people.
5. Strategic management. What managers do to develop the enterprise's strategies, policies, and operative rules.
   • Enterprise objective. A measureable step taken in order to achieve the enterprise goal.
   • Objective. A target or metric that an individual, group, and/or enterprise seeks to meet in order to progress towards a goal.
   • Strategic management process. A six-step process that encompasses strategic planning, implementation, and evaluation.
6. Planning. Management function and administrative process that involves defining goals, setting objectives based on those goals, establishing strategies for achieving those objectives, and developing plans in order to integrate and coordinate those activities that would implement the strategies.

   Breath of plan	Portfolio	Project			Operations
   		Product	Solution	Procurement
   Time frame	Long-term plan		Short-term plan	Vary
   Specificity	Directional plan		Vary	Specific plan
   Frequency of use	Single-use plan				Standing plan

   • Sprint plan. The tangible outcome of a Sprint planning meeting. The Sprint plan is a written document assembled by the development team and includes 1) the goal for the sprint—a brief description of the product or deliverable to be completed by the end of the sprint, and 2) a detailed list of the Product Backlog Items (PBIs) or user stories the team has committed to completing by the end of the sprint, based on the team’s availability and velocity. Each PBI or user story is broken down into tasks according to the priority set by the product owner and assigned to a team member.
   • Specific plan. A plan that is clearly defined and leaves no room for interpretation.
   • Standing plan. An ongoing plan that provides guidance for activities performed repeatedly.
   • Short-term plan. A plan covering one year or less.
   • Single-use plan. A one-time plan specifically designed to meet the needs of a unique situation.
   • Directional plan. A plan that is flexible and sets out general guidelines.
   • Formal planning department. A group of planning specialists whose sole responsibility is helping to write organizational plans.
   • Long-term plan. A plan with a time frame beyond three years.
   • Release plan. The plan that outlines the features to be included in an upcoming release and provides an estimated date for the release. The plan should include responsibilities, resources, and activities required to complete the release.
7. Procurement plan.
   • Commercial-off-the-shelf software (COTS). Software developed and sold for a particular market.
   • Make or buy (or build vs buy). The act of choosing between manufacturing a product in-house or purchasing it from an external supplier.
   • Total cost of ownership.
8. Impediment. Any obstacle that prevents an individual or team from completing a task or project. Unscheduled meetings, technical issues, lack of knowledge or expertise, a distracting workplace, and office conflict are all examples of impediments.
   • Impediment backlog. A visible or nonvisible list of impediments in a priority order according to how seriously they are blocking the team from productivity.
   • Feature creep. The tendency to add additional requirements or features to a project after development is already underway. Feature creep can occur on either a project or sprint level.
9. Risk management. A process of identifying what can go wrong and making plans that will enable a system to achieve its goals.
   • Risk response plan. A document detailing identified risks, including description, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status. The proposed responses may utilize risk-response techniques such as avoidance, avoidance, avoidance, and acceptance that are designed to enhance opportunities and reduce threats to the project's objectives. The tools include .
   • Contingency planning. The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.
   • Workaround. A response to a negative risk event. Distinguished from contingency plan in that a workaround is not planned in advance of the occurrence of the risk event.
10. Change resistance source.

    Category	Change resistance source
    Individual change-resistance source	Habit. Personal security. Economic factor. Fear of the unknown. Selective information processing.
    Enterprise change-resistance source	Structural inertia. Limited focus of change. Group inertia. Threat to expertise. Threat to established power relationships.

11. Configuration management. Enterprise efforts undertaken in order to establish and further manage consistency of a product's or system's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
    • Version control. The task of organizing a system or product containing many versions.
    • Continuous integration (CI). A software engineering practice that involves continual integration of new development code into the existing codebase.
12. Continuous improvement. A process of improving quality and efficiency by making small, incremental changes over time. In Kanban, continuous improvement refers specifically to the process of optimizing workflow and reducing cycle time, resulting in increased productivity.
    • Requirements management. The activities that control requirements development, including requirements change control, requirements attributes definition, and requirements traceability.
    • Requirements risk mitigation strategy. An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.
    • Kaizen. In Japanese, the word means "improvement". This is the philosophy of continuous process improvement using analytical tools and methods.
    • Paradox theory. The theory that the key paradox in management is that there is no final status for an enterprise.

Roles

1. Task force (ad hoc committee). A temporary committee or team formed to tackle a specific short-term problem affecting several departments.
2. Document management specialist. A professional who implements and administers enterprise-wide document management systems and related procedures that allow enterprises to capture, store, retrieve, share, and destroy electronic records and documents.

Methods

1. Change-promoting technique.
   • Change education.
   • Change communication.
   • Change participation.
   • Change-support building.
   • Change-commitment acquiring.
   • Change-promoting relationship.
   • Change manipulation.
   • Change cooptation.
   • Change-agent development.
   • Change coercion.
2. Development methodology.
   • Methodology. A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context.
   • Plan-driven methodology. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Plan-driven methodologies emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.
   • Change-driven methodology. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.
3. Make-or-buy decision. The act of choosing between manufacturing a product in-house or purchasing it from an external supplier.

Instruments

1. Change implementation model.

   Step	Objective	Suggested actions
   1	Sense of urgency	Consider possible change agents and resisting forces. Create a compelling reason for why change is needed. Communicate the reason to the entire enterprise or potential change agents.
   2	Coalition	Form a coalition with enough power to lead the change.
   3	Vision	Using the created coalition, formulate a new vision to direct change and strategies for achieving the vision.
   4	Official announcement	Make the vision official. Communicate both the vision and, possibly, its reasoning and achieving strategies. Enlist a volunteer army.
   5	Coalition empowerment	Empower others to act on the vision by removing barriers to change and encouraging risk taking and creative problem solving.
   6	First results	Plan for, create, and reward short-term "wins: that move the enterprise toward the new vision.
   7	Meeting challenges	Consolidate improvements. Reassess changes. Make necessary adjustments in the new programs. Sustain acceleration.
   8	Change institutionalization	Reinforce the changes by demonstrating the relationship between new behaviors and enterprise success.

2. 

   Change process model
   Change process model.
   • 

     Status quo
     Status quo.
3. 

   DADI pattern
   DADI (or DADI pattern). The enterprise development pattern that divides enterprise administration in four batches: Discovery (D), Analysis (A), Design (D), and Implementation (I). Although the batches tend to be both consecutive and complete, this statement is rarely true. Most frequently, Discovery can occur at any time and the newly discovered data re-starts the process.
   • Deductive DADI.
   • Inductive DADI.

Results

1. Strategic plan. A plan that applies to the entire enterprise, formalizes its enterprise portfolio, and establishes the enterprise's overall goals. This plan also defines its business models and may or may not include related competitive strategies.
   • Strategy. The plan for how the organization will do what it's in business to do, how it will compete successfully, and how it will attract and satisfy its customers in order to achieve its goals.
   • Commitment concept. Plans should extend for enough to meet those commitments made when the plans were developed.
   • Roadmap. A strategic plan to create a product or complete a project. A roadmap describes the individual steps required to meet a set of goals or objectives.

Practices

• Some practitioners believe that business plans have no value for the business itself.

  No business plan survives first contact with customers -- Steve Blank, entrepreneur

  Indeed, it is impossible or almost impossible to predict revenues with no historical data. Furthermore, every bank asks about a business plan, but no real bank provides a business with external funding based on a business plan alone. Taking into consideration these observations, business plans may be considered as documents that banks need in order to report to the government and to use in their public relations that the banks support business.

Validated Learning Quarter is the successor lecture. In the enterprise implementation series, the next lecture is Project Management Quarter.