Archive for February, 2010

bpr model

February 28th, 2010

http://www.kmbook.com/bpr.htm
kmbook.com

What is Business Process Redesign?

Business Process Redesign is “the analysis and design of workflows and processes within and between organizations” (Davenport & Short 1990). Teng et al. (1994) define BPR as “the critical analysis and radical redesign of existing business processes to achieve breakthrough improvements in performance measures.”

How Does BPR Differ from TQM?

Teng et al. (1994) note that in recent years, increased attention to business processes is largely due to the TQM (Total Quality Movement). They conclude that TQM and BPR share a cross-functional orientation. Davenport observed that quality specialists tend to focus on incremental change and gradual improvement of processes, while proponents of reengineering often seek radical redesign and drastic improvement of processes.

Davenport (1993) notes that Quality management, often referred to as total quality management (TQM) or continuous improvement, refers to programs and initiatives that emphasize incremental improvement in work processes and outputs over an open-ended period of time. In contrast, Reengineering, also known as business process redesign or process innovation, refers to discrete initiatives that are intended to achieve radically redesigned and improved work processes in a bounded time frame. Contrast between the two is provided by Davenport (1993):

Process Improvement (TQM) versus Process Innovation (BPR)
From Davenport (1993, p. 11)

Improvement                Innovation

Level of Change                        Incremental                   Radical
Starting Point                         Existing Process           Clean Slate
Frequency of Change      One-time/Continuous         One-time
Time Required                               Short                           Long
Participation                             Bottom-Up                  Top-Down
Typical Scope                Narrow, within functions   Broad, cross-functional
Risk                                              Moderate                      High
Primary Enabler                  Statistical Control         Information Technology
Type of Change                       Cultural                     Cultural/Structural

What is a Business Process?

Davenport & Short (1990) define business process as “a set of logically related tasks performed to achieve a defined business outcome.” A process is “a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization” (Davenport 1993). In their view processes have two important characteristics: (i) They have customers (internal or external), (ii) They cross organizational boundaries, i.e., they occur across or between organizational subunits. One technique for identifying business processes in an organization is the value chain method proposed by Porter and Millar (1985).

Processes are generally identified in terms of beginning and end points, interfaces, and organization units involved, particularly the customer unit. High Impact processes should have process owners. Examples of processes include: developing a new product; ordering goods from a supplier; creating a marketing plan; processing and paying an insurance claim; etc.

Processes may be defined based on three dimensions (Davenport & Short 1990):

. Entities: Processes take place between organizational entities. They could be Interorganizational (e.g. EDI, i.e., Electronic Data Interchange), Interfunctional or Interpersonal (e.g. CSCW, i.e., Computer Supported Cooperative Work).

. Objects: Processes result in manipulation of objects. These objects could be Physical or Informational.

. Activities: Processes could involve two types of activities: Managerial (e.g. develop a budget) and Operational (e.g. fill a customer order).

What are the Myths about BPR Created by the Popular Literature?

The popular management literature has created more myth than practical methodology reengineering. The concept of BPR has been with us since about 1990, however it is widely misunderstood and has been equated to downsizing, client/server computing, quality, ABC, and several other management nostrums of the past several years. Based on interviews and conversations with more than 200 companies, and 35 reengineering initiatives, Davenport & Stoddard (1994) identify seven reengineering myths.

. The Myth of Reengineering Novelty: Reengineering, although about familiar concepts, is new in that these concepts are combined in a new synthesis. These key components have never been together before.

. The Myth of the Clean Slate: Regardless of Hammer’s (1990) exhortation: “Don’t automate, obliterate!” clean slate change is rarely found in practice. Or, as Davenport and Stoddard (1994) state: A “blank sheet of paper” used in design usually requires a “blank check” for implementation. Hence, a more affordable approach for most companies is to use Clean Slate Design which entails a detailed vision for a process without concern for the existing environment. However, the implementation is done over several phased projects. Also supported by preliminary findings of Stoddard & Jarvenpaa 1995: their findings ran contrary to Hammer (1990): “although reengineering can deliver radical designs, it does not necessarily promise a revolutionary approach to change. Moreover, a revolutionary change process might not be feasible given the risk and cost of revolutionary tactics.”

. The Myth of Information Systems Leadership: In contrast to the much touted leadership role, Information Systems (IS) is generally viewed as a partner within a cross- functional team that is generally headed by a non-IS project leader and a non-IS business sponsor who have better control over the processes that are being redesigned.

. The Myth of Reengineering vs. Quality: Unlike Hammer & Champy’s (1993) call for all out “radical change,” most companies have a portfolio of approaches to organizational change including reengineering, continuous improvement, incremental approaches, and restructuring techniques.

. The Myth of Top-Down Design: The implementation and execution of the redesigned processes depends upon those who do the work. Hence, the participation, and more importantly, acceptance and ownership, at the grass roots level is essential for successful BPR.

. The Myth of Reengineering vs. Transformation: BPR is a process that contributes to organizational transformation (OT), however it is not synonymous with transformation. OT is defined as, “Profound, fundamental changes in thought and actions, which create an irreversible discontinuity in the experience of a system” (Adams 1984). OT is generally about the emergence of a new belief system and necessarily involves reframing, which is a discontinuous change in the organization’s or group’s shared meaning or culture. It also involves broad changes in other organizational dimensions besides the work processes: such as organizational structure, strategy, and business capabilities.

. The Myth of Reengineering’s Permanence: Davenport & Stoddard (1994) speculate that reengineering has peaked in the US in 1994 and would probably become integrated with much broader organizational phenomena: such as another synthesis of ideas that includes the precepts of reengineering; its integration into existing change methods; or its combination with quality and other process-oriented improvement approaches into an integrated process management approach.

What is the Relation between BPR & Information Technology?

Hammer (1990) considers information technology (IT) as the key enabler of BPR which he considers as “radical change.” He prescribes the use of IT to challenge the assumptions inherent in the work processes that have existed since long before the advent of modern computer and communications technology. He argues that at the heart of reengineering is the notion of “discontinuous thinking — or recognizing and breaking away from the outdated rules and fundamental assumptions underlying operations… These rules of work design are based on assumptions about technology, people, and organizational goals that no longer hold.” He suggests the following “principles of reengineering”: (a) Organize around outcomes, not tasks; (b) Have those who use the output of the process perform the process; (c) Subsume information processing work into the real work that produces the information; (d) Treat geographically dispersed resources as though they were centralized; (e) Link parallel activities instead of integrating their results; (f) Put the decision point where the work is performed, and build control into the process; and (g) Capture information once and at the source.

Davenport & Short (1990) argue that BPR requires taking a broader view of both IT and business activity, and of the relationships between them. IT should be viewed as more than an automating or mechanizing force: to fundamentally reshape the way business is done.

Business activities should be viewed as more than a collection of individual or even functional tasks: in a process view for maximizing effectiveness. IT and BPR have recursive relationship. IT capabilities should support business processes, and business processes should be in terms of the capabilities IT can provide. Davenport & Short (1990) refer to this broadened, recursive view of IT and BPR as the new industrial engineering.

Business processes represent a new approach to coordination across the firm; IT’s promise — and its ultimate impact — is to be the most powerful tool for reducing the costs of coordination (Davenport & Short 1990). Davenport & Short (1990) outline the following capabilities that reflect the roles that IT can play in BPR: Transactional, Geographical, Automatical, Analytical, Informational, Sequential, Knowledge Management, Tracking, and Disintermediation.

Teng et al. (1994) argue that the way related functions participate in a process – - i.e., the functional coupling of a process — can be differentiated along two dimensions: degree of mediation and degree of collaboration. They define the Degree of Mediation of the process as the extent of sequential flow of input and output among participating functions. They define the Degree of Collaboration of the process is the extent of information exchange and mutual adjustment among functions when participating in the same process. In their framework, information technology is instrumental in Reducing the Degree of Mediation and Enhancing the Degree of Collaboration. Also, innovative uses of IT would inevitably lead many firms to develop new, coordination-intensive structures, enabling them to coordinate their activities in ways that were not possible before. Such coordination-intensive structures may raise the organization’s capabilities and responsiveness, leading to potential strategic advantages.

What is the Role of the IS Function in BPR?

Although, BPR has its roots in IT management, it is primarily a Business Initiative that has broad consequences in terms of satisfying the needs of customers and the firm’s other constituents (Davenport & Stoddard 1994). The IS group may need to play a behind-the-scenes advocacy role, convincing senior management of the power offered by IT and process redesign. It would also need to incorporate the skills of process measurement, analysis, and redesign. The CIGNA IS group had to develop a new set of basic values that reflected a change in focus from technology to a focus on business processes and results (Caron et al. 1994). The specific business divisions led the BPR initiatives; IS groups served as partners in enabling the radical changes.

Is there a BPR Methodology?

Davenport and Short (1990) prescribe a five-step approach to BPR:

. Develop the Business Vision and Process Objectives: BPR is driven by a business vision which implies specific business objectives such as Cost Reduction, Time Reduction, Output Quality improvement, QWL (Quality of Work Life)/Learning/Empowerment. (cf: Shared Vision of Senge 1990, Ikujiro & Nonaka 1995).

. Identify the Processes to be Redesigned: Most firms use the High- Impact approach which focuses on the most important processes or those that conflict most with the business vision. Lesser number of firms use the Exhaustive approach that attempts to identify all the processes within an organization and then prioritize them in order of redesign urgency.

. Understand and Measure the Existing Processes: For avoiding the repeating of old mistakes and for providing a baseline for future improvements.

. Identify IT Levers: Awareness of IT capabilities can and should influence process design.

. Design and Build a Prototype of the New Process: The actual design should not be viewed as the end of the BPR process. Rather, it should be viewed as a prototype, with successive iterations. The metaphor of prototype aligns the BPR approach with quick delivery of results, and the involvement and satisfaction of customers.

BPR: All or Nothing?: Insights from CIGNA

At CIGNA BPR meant “breakthrough innovation focused on customer needs” (Caron et al. 1994). BPR was essentially driven by the senior management’s strategic planning process that had concluded that the mix of business in its portfolio needed to change. It was viewed as a vehicle to realign strategy, operations, and systems to deliver significantly increased financial results. Caron et al. (1994) argue that the real life story of BPR at CIGNA represents a contrast to the general prescriptions of “radical” “all-or-nothing” organizational transformation. At CIGNA, BPR started out as an experimental pilot. The knowledge from the success of this initiative was disseminated for implementing other BPR projects. The BPR initiative was sustained “from the bottom up, with learning transferred “across.”" At CIGNA, the prerequisite for BPR success was a corporate environment that promotes learning, especially learning from failure. Although, the process was initiated from the top, the ownership was moved down to the people who actually had to implement the changes and were affected by those changes. The BPR effort took into consideration the differences in management cultures in different countries. The BPR initiative started at the operational levels and was later moved to “higher forms” (strategic) of reengineering over time.

Why BPR Projects Fail? What Can be Done about it?

70% of the BPR projects fail. Biggest obstacles that reengineering faces are: (i) Lack of sustained management commitment and leadership; (ii) Unrealistic scope and expectations; and (iii) Resistance to Change.

Based on the BPR consultants’ interviews, Bashein et al. (1994) outline the positive preconditions for BPR success as: Senior Management Commitment and Sponsorship; Realistic Expectations; Empowered and Collaborative Workers; Strategic Context of Growth and Expansion; Shared Vision; Sound Management Practices; Appropriate People Participating Full-Time (cf: CIGNA: BPR as a way of life); and Sufficient Budget. They also identify negative preconditions related to BPR as: The Wrong Sponsor; A “Do It to Me” Attitude; Cost-Cutting Focus; and, Narrow Technical Focus. The negative preconditions relating to the Organization include: Unsound Financial Condition; Too Many Projects Under Way; Fear and Lack of Optimism; and, Animosity Toward and By IS and Human Resource (HR) Specialists. To turn around negative conditions, firms should: Do Something Smaller First (CIGNA’s pilot); Conduct Personal Transformation (CIGNA’s change of mindset); and Get IS and HR Involved (CIGNA’s CIO initiated the change and HR factors were given due emphasis).

King (1994) views the primary reason of BPR failure as overemphasis on the tactical aspects and the strategic dimensions being compromised. He notes that most failures of reengineering are attributable to the process being viewed and applied at a tactical, rather than strategic, levels. He discusses that there are important strategic dimensions to BPR, notably, Developing and Prioritizing Objectives; Defining the Process Structure and Assumptions; Identifying Trade-Offs Between Processes; Identifying New Product and Market Opportunities; Coordinating the Reengineering Effort; and, Developing a Human Resources Strategy. He concludes that the ultimate success of BPR depends on the people who do it and on how well they can be motivated to be creative and to apply their detailed knowledge to the redesign of business processes (cf: Davenport & Stoddard 1994, Markus et al. 1994).

Where is BPR Headed?

Over the last few years, the reengineering concept has evolved from a “radical change” to account for the contextual realism (Caron et. al 1994, Earl 1994), and to reconcile with more incremental process change methods such as TQM, towards a broader, yet more comprehensive process management concept (Davenport 1995).

Based upon a theoretical analysis and survey of literature relevant to reengineering, Kettinger & Grover (1995) outline some propositions to guide future inquiry into the phenomenon of BPR. Their propositions center around the concepts of knowledge management, employee empowerment, adoption of new IT’s, and a shared vision. Earl et al. (1995) have proposed a “process alignment model” that comprises four lenses of enquiry: process, strategy, MIS (Management Information Systems, and change management and control, and used it for developing an inductive taxonomy of BPR strategies. Malhotra (1996) has developed the key emphasis on these issues based primarily on an integrative synthesis of the recent literature from organization theory, organization control, strategy, and MIS.

King (1994) believes that although the current fadism of BPR may end, however, process reengineering, in some form or known by some other name (cf: Davenport & Stoddard 1994) would be of enduring importance.

Selected References

Bashein, B.J., Markus, M.L., & Riley, P. (1994 Spring). “Preconditions for BPR Success: And How to Prevent Failures,” Information Systems Management, 11(2), pp. 7-13.

Caron, M., Jarvenpaa, S.L. & Stoddard, D.B. (1994, September). “Business Reengineering at CIGNA Corporation: Experiences and Lessons Learned From the First Five Years,” MIS Quarterly, pp. 233-250.

Davenport, T.H. & Short, J.E. (1990 Summer). “The New Industrial Engineering: Information Technology and Business Process Redesign,” Sloan Management Review, pp. 11-27.

Davenport, T.H. (1993). Process Innovation, Harvard Business School Press, Boston, MA.

Davenport, T.H. (1994 July). “Reengineering: Business Change of Mythic Proportions?” MIS Quarterly, pp. 121-127.

Davenport, T.H. & Beers, M.C. (1995). “Managing Information About Processes,” Journal of Management Information Systems, 12(1), pp. 57-80.

Earl, M.J., Sampler, J.L. & Short, J.E. (1995). “Strategies for Business Process Reengineering: Evidence from Field Studies,” Journal of Management Information Systems, 12(1), pp. 31-56.

Grover, V., Jeong, S.R., Kettinger, W.J. & Teng, J.T.C. (1995). “The Implementation of Business Process Reengineering,” Journal of Management Information Systems, 12(1), pp. 109-144.

Hammer, M. (1990, July-August). “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review, pp. 104-112.

Kettinger, W.J. & Grover, V. (1995). “Special Section: Toward a Theory of Business Process Change Management,” Journal of Management Information Systems, 12(1), pp. 9-30.

King, W.R. (1994 Spring). “Process Reengineering: The Strategic Dimensions,” Information Systems Management, 11(2), pp. 71-73.

Stoddard, D.B. & Jarvenpaa, S.L. (1995). “Business Process Redesign: Tactics for Managing Radical Change,” Journal of Management Information Systems, 12(1), pp. 81-107.

Diversity and Organizational Change – A Working Framework

February 28th, 2010

http://www.getdiversity.com/articles-publications/framework-a&s-1998.html
getdiversity.com
by Adrienne S. Chan & Sandy Berman Vancouver, B.C. Canada 1998

Diversity – refers to the unique and identifiable characteristics that distinguish us as individuals, and identify us as belonging to a group or groups. Diversity therefore includes class, race, religion, ethnicity, gender, sexual orientation and abilities/ disabilities. Diversity offers strength and richness to the whole. (Hastings Institute 1994)   Diversity may also include ancestry, age, colour, political belief, marital status, and family status. Diversity is an inclusive approach to all people that recognizes the diversity we may have in any given time, even among groups that appear to be homogeneous.
Organizational change – is a process

Organizational change is usually built around the activities of change agents or change teams, who seek to bring about changes in human resources, organizational systems, and the programs, products, and services of an institution or organization.

Administrators and managers are responsible for serving as change agents, as well as union representatives and other members of the organization. Change agents and change committees have a special concern for resolving any gaps and discrepancies between the desired state, and the actual state of affairs. Organizational change is the process by which the goal of an inclusive, multicultural, anti-racist, anti-discriminatory organization may be achieved. (Lower Mainland Multicultural Education Consortium -1997)

1. Social justice is a perspective that is fundamental to our work in diversity and organizational change. This includes the view that injustice must be corrected, as well as addressing and dealing with discrimination and oppression actively. It is not enough to say that we value diversity or cultural pluralism. Analysis of group experiences and addressing issues of power, privilege and equity shapes this work. This means recognizing and critically assessing the systems which exclude and exploit people.

Social justice is about transformation. We are attempting to change the way that systems are structured, organized and managed. This means moving from improving the existing system to radically changing it.

Radical change requires a moving away from the continued dominance and control of the current power elite. It means challenging situations and becoming informed about the myriad of ways the system maintains itself (the status quo — those in power retain control) in economic, social, educational and political contexts.

To address issues of power is to identify the imbalances and the nature of oppression. Naming oppression and power through a process of dialogue, brings about an awareness of how these factors affect our lives. This awareness results in a shift in how we relate to the system and our place in it. It is in this shift that we need to create actions that lead to change.

Our work towards change cannot be segmented or isolated from the way in which society is organized. Ultimately we must deal with the issues of social justice in an integrated way both within organizations and society as a whole.
2. Diversity is inclusive of race, gender, class, sexual orientation, dis/ability, religion, ethnicity, age and any other aspects in which an individual or groups may be subject to marginalization, discrimination and oppression. Diversity takes into account that we are not one identity at any one time. The intersections of identities is acknowledged as complex and has a relationship to power and experiences of oppression, hierarchy and patriarchy.

3. Diversity and organizational change has a personal, social and political context. These contexts influence and affect individual and group responses to the issues. These contexts are recognized as key influences in how any work on change can be achieved. Every day activities and events can become socialized and politicized.

4. Our position as workers, consultants, organizers, teachers and researchers, is something that we acknowledge and work with. Our position affects our stance with the groups and organizations we are in relationship with. We cannot assume that people come from similar positions or places, and this is also linked to our own personal, social and political context.

5. People’s stories shape their lives and their responses. Our stories shape our motivation and intention in doing this work. We come in contact with people who will tell us their stories and this informs us about their place in the organization and gives us a greater understanding of that organization.

6. Addressing organizational culture(s) is a key element to the change process. Critical assessment and reflection on the culture of the organization is essential. Power is socially and culturally constructed in the organization. Organizational culture includes norms, beliefs, values, symbols and patterns of behaviour.

7. Entry into an organization does not guarantee influence or change. Our position as “insiders” or “outsiders” is assessed in terms of how we can influence the process. If small changes are achieved they are seen within a view to the macro goal of inclusive, welcoming, non-discriminatory, non-oppressive organizations.

We cannot pre-design the end result. We need to build action upon action to bring about the shifts and changes. So if the vision is social justice, the path is one that we create together.

References:
Hastings Institute (1994). Valuing Diversity Training. Vancouver, B.C.
Lower Mainland Multicultural Education Consortium (1997). Organizational Change Training. Vancouver, B.C.

© Copyright Adrienne S. Chan and Sandy Berman,
1998 Vancouver, BC, Canada
Developed for the Training of Trainers

The 5-Step Strategic Cultural Framework For Organizational Proficiency

February 28th, 2010

http://www.evancarmichael.com/Work-Life/4432/The-5Step-Strategic-Cultural-Framework-For-Organizational-Proficiency.html
evancarmichael.com
Jo Romano

There are 5 Steps to creating a diverse and culturally competent organization.

Step 1) Assessment and Cultural Competence:

Do your client and stakeholder assessments include information about the major cultural groups in your community? Who’s here and who is accessing our services and products? What’s changing in our community?

Service and Product Selection and Cultural Competence:

Who conducted the research, developed the service or product?

How did the researchers/program developers control for cultural competency in the program design? What groups were included in the studies? Have any replications been done in diverse communities? Are materials available in languages other than English? Who did the translation? Were they tested? Are management and team leaders willing to work with others to adapt the service, or product?

Strategy:

Hold focus groups and informant interviews to reach all populations in the company’s community. Data=Numbers (Quantitative) + Opinions (Qualitative)

Produce Qualitative Data, which are the opinions and ideas of all members of the community and include with the numbers gained through surveys and assessments.

Strategy:

Have members of diverse groups assisted the organization in analyzing and interpreting the data? Values and lifeways? Religious, philosohical, and spiritual beliefs? Economic Factors? Educational Factors? Technological Factors? Kinships and social ties? Political and Legal Factors?

Step 2) Building Organizational Capacity (resources and readiness) and Cultural Competence:

Does your organization engage all sectors of your workforce and community? Are some groups not adequately represented or “at the table?” What cultural groups are you recognizing in your clients and workforce i.e., socioeconomic – the big rift between have and have nots, races, religions, geographic -urban, rural, locals, out of towners, ethnic; People who work and live in institutionalized system; People in corrections, exoffenders.

Strategy:

Consider not just the norms but all people’s needs and wants. What do we need to know and learn about them? Think comprehensively about what their life experiences are and how to integrate them into the services and products we provide.

Step 3) Planning and Cultural Competence:

Does your organizational strategic plan address needs of diverse people in your organization and clients and stakeholders in your community? Does your strategic plan incorporate cultural competence concepts and language?

We must recognize the “ism” that impacts our thinking, being and doing. How will we as an organization respond to these “ism” forces: racism, sexism, and classism? There are conscious and unconscious prejudices in our organization and among our clients, stakeholders and community.

Strategy:

Develop within your Strategic Plan very clear written systems addressing issues that promote an organizational culture of diversity, sensitivity and competency.

Strategy:

Develop a strategic plan on how YOU WILL respond to and develop relationships with colleagues, clients, and stakeholders and become an advocate and share how your interventions will work because you are taking into consideration individual needs.

Step 4) Implementation and Cultural Competence:

Have you determined who is to do what by when? Is the who able to adapt to meet the needs of diverse groups?

Step 5) Evaluation and Cultural Competence:

Have you defined the team, the organization’s culture and clients precisely? Have you developed collaborations with the stakeholders and targeted populations? Have you planned for and encouraged buy-in? Have you provided timely feedback and results in clear, useful formats conveyed through culturally appropriate methods?

Organizational Framework

February 28th, 2010

http://envisionthenew.com/?p=135
envisionthenew.com
By Brett Hutchinson

An organization’s personality is heavily influenced by the “above the line” decision-making. In order to tease out the personality of an organization you have to understand what allows it to exist and how decisions get made. I start by creating an organizational framework to describe what the organization does, why it does it, and who this matters to. The framework describes in detail these seven areas:

1. Office building on a background of the blue skyPhilosophy – why the organization exists and what it does
2. Structure – how its organizes groups of people to get something done
3. Process – how the people get things done
4. Products – what the organization makes and what it accomplishes
5. Planning – how the people in the organization make decisions
6. Allocation of resources – how the organizations puts time, talent and treasure to work and how it gets paid back
7. Practice – what people in the organization do to be effective

Research is done by surveying the leadership instruments that define and control how you accomplish your mission, fulfill your purpose and pursue your vision, through face-to-face meetings with stakeholders, interviews, surveys and other tools. I start at the conceptual and work my way down to the concrete outlining the logic progressing from ideas to implementation.

Here is a sampling of the leadership instruments to review in creating your own organizational framework:

* Constitution
* Articles of Incorporation
* Bylaws
* Charter
* Statement of Vision/Purpose
* Manifesto or Declaration
* Business Logic
* Brand Logic
* Governing Board
* Board of Trustees
* Organizational Chart
* Job/Role Descriptions
* Business Model
* Policy and Procedure Manuals
* Process Flowcharts, Diagram: Management, Operations, Administration
* Program Logic
* Product/Service Offerings
* Master/Business Plan: Leadership, Communications, Operations, Management, Administrations
* Implementation Plans: 30-60-90, 12 month, 2-5 year

Your next step is to organize your leadership documents and answer these questions:

1. Do these make the case for why our business or non-profit is needed?
2. Do these work to guide our thinking, decision making and preserving our values, processes and brand?
3. What is missing?

As you build your framework you will discover the gaps in decision making and leadership communication that will impede or aide the process of defining your personality.

Earned Value Management Explained

February 28th, 2010

http://www.projectsmart.co.uk/earned-value-management-explained.html
projectsmart.co.uk
By Umesh Dwivedi, PMP

Earned Value Management (EVM) helps project managers to measure project performance. It is a systematic project management process used to find variances in projects based on the comparison of worked performed and work planned. EVM is used on the cost and schedule control and can be very useful in project forecasting. The project baseline is an essential component of EVM and serves as a reference point for all EVM related activities. EVM provides quantitative data for project decision making.
EVM Rewards and Recognition

According to the NASA Headquarters Library, the first version of Earned Value Management (EVM) was developed by the Defence Department (DoD) to track its programmes during the sixties. Since 2005, EVM has been a part of general federal project risk management. Today EVM is a mandatory requirement of the US government. The Office of Management and Budget (OMB) promotes use of EVM as a preferred performance-based management system to manage software projects. EVM is also used in the private sector by companies in a variety of industries, consulting firms and educational establishments.

Some of the most well known organisations practicing EVM are:

* NASA
* Project Management Institute (PMI)
* Society of Cost Estimating and Analysis
* Defence Acquisition University
* Federal Acquisition Institute
* Acquisition Management (UK)

Based on reports of the General Accounting Office (GAO) in August 1996 a memorandum of understanding concerning common cost and schedule management for acquisitions was signed by Australia, Canada, and the United States. This gives international recognition to EVM worldwide.

The NASA Office of Chief Engineer is sponsoring an “Earned Value Management EVM Award of Excellence” to be presented at the NASA PM Challenge Conference. More information is available on the NASA Earned Value Management (EVM) Award of Excellence External Link site.
EVM Measures

EVM consists of the following primary and derived data elements. Each data point value is based on the time or date an EVM measure is performed on the project.
Primary Data Points

* Budget At Completion (BAC)
* Total cost of the project.
* Budgeted Cost for Work Scheduled (BCWS) / Planned Value (PV)
* The amount expressed in Pounds (or hours) of work to be performed as per the schedule plan.
* PV = BAC * % of planned work.
* Budgeted Cost for Work Performed (BCWP) / Earned Value (EV)
* The amount expressed in Pounds (or hours) on the actual worked performed.
* EV = BAC * % of Actual work
* Actual Cost of Work Performed (ACWP) / Actual Cost (AC)
* The sum of all costs (in Pounds) actually accrued for a task to date

For example say we should have completed £800 pounds of work by today. We completed £600 worth of work. The BCWP is £600. The BCWS is £800. And if we actually paid £700 then (ACWP) = £700.
Derived Data Points

Cost Forecasting:

* Estimate At Completion (EAC)
* The expected TOTAL cost required to finish complete work.
* EAC = BAC / CPI
o = AC + ETC
o = AC + ((BAC – EV) / CPI) (typical case)
o = AC + (BAC – EV) (atypical case)

Here atypical means it is assumed that similar variances will not occur in the future.

* Estimate to complete (ETC)
* The expected cost required to finish all the REMAINING work.
* ETC = EAC – AC
o = (BAC / CPI) – (EV/CPI)
o = (BAC – EV) / CPI

Variances:

* Cost Variances (CV)
* How much under or over budget.
* CV = EV-AC
* NEGATIVE is over budget, POSITIVE is under budget.
* Schedule Variances (SV)
* How much ahead or behind schedule.
* SV = EV-PV
* NEGATIVE is behind schedule, POSITIVE is ahead of schedule.
* Variance At Completion (VAC)
* Variance of TOTAL cost of the work and expected cost.
* VAC = BAC – EAC

Performance Indices:

* Cost Performance Index
* CPI = EV / AC
* Over (< 1) or under (> 1) budget.
* Schedule Performance Index
* SPI = EV / PV
* Ahead (> 1) or behind (< 1) schedule.

EVM Example

The best way to understand an EVM example is to solve it.

Problem: A project has a budget of £10M and schedule for 10 months. It is assumed that the total budget will be spent equally each month until the 10th month is reached. After 2 months the project manager finds that only 5% of the work is finished and a total of £1M spent.

Solution:
PV = £2M
EV = £10M * 0.05 = £0.5M
AV = £1M

CV = EV-AC = 0.5-1 = -0.5M
CV% = 100 * (CV/EV) = 100*(-0.5/0.5) = -100% overrun

SV = EV-PV = 0.5-2 = -1.5 months
SV% = 100 * (SV/PV) = 100*(-1.5/2) = -75% behind

CPI = EV/AC = 0.5/1 = 0.5
SPI = EV/PV = 0.5/2 = 0.25

EAC = BAC/CPI = 10/0.5 = £20M
ETC = (BAC-EV) / CPI = (10-0.5)/0.5 = £19M

Time to compete = (10-0.5)/0.25 = 38 Months

This project will take TOTAL £20M (19+1) and 40 (38+2) Months to complete.
EVM Benefits

EVM contributes to:

* Preventing scope creep
* Improving communication and visibility with stakeholders
* Reducing risk
* Profitability analysis
* Project forecasting
* Better accountability
* Performance tracking

EVM Tools

There are many tools available on the market to measure earned value. The most common are:

* Microsoft Office Project (http://office.microsoft.com/en-us/project. External Link)
* Primavera Cost Manager (http://www.primavera.com. External Link)
* PlanView MPM (http://www.Planview.com. External Link)
* iPursuit (http://www.dekkerltd.com/evm.aspx. External Link)
* Deltek Cobra (http://www.deltek.com. External Link)

Integrating systems engineering with earned value management

February 28th, 2010

http://findarticles.com/p/articles/mi_m0QMG/is_3_33/ai_n6126614/
findarticles.com
by Paul J. Solomon

Program managers (PMs) expect their supplier’s earned value management system (EVMS) to accurately report the program’s integrated cost, schedule, and technical performance. However, EVM data will be reliable and accurate only if the right base measures of technical performance are selected and if progress is objectively assessed. If you are measuring the wrong things or not measuring the right way, then EVM may be more costly to administer and may provide less management value.

[ILLUSTRATION OMITTED]

During my experience monitoring EVM on many programs. I often observed programs that were behind schedule in terms of validating requirements, completing the preliminary design, meeting weight targets, or delivering software releases that met the requirements baseline. Yet 100 percent of earned value was taken and reported, in compliance with the industry standard for EVMS, because the EV completion criteria were not based on technical performance or were not defined clearly and unambiguously. Furthermore, during technical reviews, some of these adverse conditions were not described as problems or issues. They were classified as risks towards achieving subsequent objectives.

EVM can be more effective as a program management tool if it is integrated with technical performance and if the EVM processes are augmented with a rigorous systems engineering process. The recommendations that follow are based on lessons learned from major programs and on observing the processes of major contractors and subcontractors. Guidance is provided for PMs to ensure that reported EV is a valid indicator of technical performance. Pre-contract and post-contract actions are recommended to implement performance-based earned value that is quantitatively linked with:

* Technical performance measurement (TPM)

* Progress against requirements

* Development maturity

* Exit criteria of life cycle phases

* Significant work packages and work products.

Guidance for getting more value out of earned value is consistent with the Department of Defense (DoD) Risk Management Guide (Guide), the Interim Defense Acquisition Guidebook (IDAG), and with industry standards that have been adopted by the DoD:

* Processes for Engineering a System (EIA 632)

* Standard for Application and Management of the Systems Engineering Process (IEEE 1220)

* EVMS (ANSI/EIA-748-A-1998).

Additional guidance is consistent with the Capability Maturity Model[R]-Integration (CMMISM).

Better integration of systems engineering, risk management, and EVM will benefit the PMs of both the acquisition and supplier organizations.

EVM Limitations

With regard to a PM’s needs, there are several limitations of EVMS that can be overcome by integrating EVM with robust systems engineering. First, EVM is perceived to be a risk management tool. However, EVMS was not designed to manage risk and does not even mention the subject.

Unfavorable cost or schedule variances result from past events. They are already problems or issues. A cost overrun indicates that, with 100 percent probability, subsequent cost objectives will not be achieved unless the plan for remaining work is revised.

Second, earned value is a derived measure. Consequently, its effectiveness to integrate technical and cost performance depends on its base measures and on the capabilities of the systems engineering processes that are employed on a program.

[FIGURE 1 OMITTED]

Third, EVMS does not require precise, quantifiable measures. It states that objective earned value methods are preferred but it also states that management assessment (subjective) may be used to determine the percentage of work completed.

Finally, EVMS states that EV is a measurement of the quantity, not quality, of work accomplished. A PM should ensure that EV also measures the quality and technical maturity of technical work products instead of just the quantity of work. Robust systems engineering processes should provide TPM and exit criteria for assessing technical maturity that are quantitatively linked to EV.

The following guidance will help a PM overcome EVM’s limitations.

Risk Management Guide and TPM

Per the Guide, risk management is concerned with future events whose outcome is unknown and with how to deal with these uncertainties. That guidance is in contrast to risk-handling actions that should be reflected in integrated program planning, scheduling, and work packages. In other words, risk handling actions become part of the EV performance measurement baseline (PMB).

In my opinion, the Guide’s statement that “periodic EV data can provide indications of risk” is misleading. As discussed above, by the time a cost overrun is reported, the unfavorable event has occurred and there is a problem or issue, not simply a risk.

The same premise–that deviations from a plan are issues, not risks–should apply to TPM. Per the Guide:

* Technical … parameter values to be achieved … are forecast in the form of planned performance profiles.

* Achieved values for these parameters are compared with the expected values.

* Events, tasks, and schedule resulting from the integrated planning are linked with … techniques, such as TPM.

* Linkage provides a significant monitoring tool, giving specific insights into the relationships among cost. schedule, and performance risks.

An example of a TPM planned performance profile that also shows achieved values and a tolerance band is shown in Figure 1.

However, some PMs classify TPM as a risk management technique and do not integrate the planned performance profile into the schedules and work packages. Later, if achieved values for these parameters fall short of the expected values, neither the schedules nor the earned value show a behind-schedule condition.

Mike Ferraro describes DCMA research and pilot tests for integrating TPM and EVM (”TPM, a PM’s Barometer,” PM, November-December 2002). The earliest research, published in 1995, found that there was not clear linkage between technical parameters and work packages. Ferraro concluded that this continues to be an issue.

So how can a PM obtain contractual commitment to integrate TPM and EVM? Fortunately, there are two industry standards that provide specific guidance for TPM that are consistent with the Guide: IEEE 1220 and EIA 632. Both standards provide guidance for TPM planning and measurement (Figure 2) and for integrating TPMs with EVM. The DoD has adopted both standards.

A PM may require compliance with the TPM components of either of these standards in the solicitation. Another approach is to provide financial incentives for contractor compliance. After contract award, the PM may use the integrated baseline review (IBR) to verify that the integrated planning includes TPMs and that the EVM is quantitatively linked to achieved values in appropriate work packages. If the PM uses simulation-based acquisition and modeling & simulation as discussed in IDAG, then the achieved values should be credible. Finally, the PM should address TPM achievement and reporting during technical assessment reviews.

Other Systems Engineering Best Practices

IEEE 1220 and EIA 632 provide additional guidance for systems engineering process improvement regarding progress, planning, and measurement. It may be used to select performance-based earned value measures. A PM may choose to mandate compliance with pertinent components of the standards in the solicitation or to provide other incentives for compliance.

Progress Against Requirements

Master schedules and PMBs often reflect the tasks that were proposed, estimated, and negotiated. However, tasks that formed a basis of estimate for negotiation are not necessarily those that should be planned and tracked during program execution. The PM should select base measures of progress for EV that indicate objective progress towards development, implementation, and testing of the requirements.

The Guide discusses product-related metrics that include requirements traceability and requirements stability. Progress against requirements, including the percentage of requirements that are traced upwards and downwards and those that are validated, would be a highly effective base measure of earned value. It is especially important to validate the requirements baseline early in development and prior to the start of design by the prime and subcontractors.

The industry standards’ guidance for assessing progress against requirements is shown in Figure 3 (page 46).

Design Maturity

The Guide discusses design maturity as a product-related metric and provides examples of design maturity measures. Adherence to the standards will support the requirement in DoD Instruction (DoDI) 5000.2 for a design readiness review during system development and demonstration. The design readiness review assesses design maturity as evidenced by such measures as:

* Number of subsystem and system design reviews successfully completed

* Percentage of drawings completed

* Planned corrective actions to hardware/software deficiencies

* Adequate development testing.

Objective assessment of a system’s design maturity, in compliance with the standards, would also be a sound basis for earned value.

Exit Criteria

The standards discuss the importance of holding technical reviews at the end of a stage of development or a life-cycle phase to assure that all exit criteria have been met. IEEE 1220 is especially helpful by providing exit criteria for a preliminary design review (PDR) and a detailed design review. Some of the exit criteria for a PDR are:

* Prior completion of subsystem reviews

* Determination whether total system approach to detailed design satisfies the system baseline

* Mitigation of unacceptable risks

* Resolution of issues for all subsystems, products, and life cycle processes

* Definition of exit criteria in a systems engineering management plan or other technical plan.

A PM should review these plans with the supplier and reach agreement on the validity and sufficiency of the exit criteria during the IBR. It is also recommended that the work packages that measure progress against requirements and development maturity be reviewed to understand the time-phased plan for meeting the exit requirements, the related EV techniques, and the base measures.

[ILLUSTRATION OMITTED]

Systems Engineering Work Products

The systems engineering process generates significant work products that should be included in integrated planning and measured with earned value.

The process products of IEEE 1220 are:

* Requirements baseline

* Validated requirements baseline

* Functional architecture

* Verified functional architecture

* Physical architecture

* Verified physical architecture.

The process products of EIA 632 are:

* System technical requirements

* Logical solution representations

* Physical solution representations

* Specified requirements

* Validated system technical requirements

* Validated logical solution representation

* Verified design solution.

Depending on the selected standard, these work products should be included in the master schedule and in work packages. Additional recommendations for work products are provided below in a discussion of the CMMI.

Bad Rap for Level of Effort (LOE)

Many PMs expect that the percentage of LOE budget should not exceed a certain level. I believe that setting an arbitrary maximum threshold for LOE can increase contract costs and cause management to waste time by focusing on the wrong things. It costs money to measure processes and progress. But as Navy Rear Adm. Dave Antanitus wrote in PM, “Be careful here–just because you can measure something does not mean it is a useful metric!” (”The Business of Metrics,” March-April 2003).

Many tasks that are measurable are not indicators of technical performance. Examples are technical assessment meetings and recurring reports, such as cost performance reports (CPR). If a CPR is delivered late, there is no schedule impact on a subsequent activity and no impact on final costs. So why incur the costs to measure CPRs discretely or to analyze schedule variances?

The same is true for technical assessment reviews, such as technical interchange meetings (TIMs), PDRs, and final design reviews. Per IEEE 1220 and EAI 632, a purpose of the reviews is to assess progress and development maturity. However, it is common practice to base earned value on completion of the milestone event (TIM or PDR was held) instead of on the quantified assessment of progress and maturity. For a PDR, if earned value were based on the event instead of the assessment and if the preliminary design did not meet the exit criteria, then earned value would mask a behind-schedule condition. Likewise, the master schedule would be misleading if the PDR event showed completion despite a shortfall in technical performance.

It would be cheaper to designate non-technical tasks as LOE, to manage LOE cost performance, and to apply more management attention to technical performance. Both EIA 632 and IEEE 1220 focus on technical progress. The budget for non-technical tasks, such as preparing for and conducting a PDR, could be planned as LOE even if the LOE percentage exceeded arbitrary limits. The EVMS standard discusses that LOE is supportive work that is impracticable to measure. Non-technical work may fit this definition.

A PM should be careful when analyzing summary earned value information. A summary of only the discrete tasks that measure technical performance should be prepared. The performance-based earned value will show schedule and cost variances that are not distorted by LOE content. Also, the related cost performance index will be a truer indicator of future costs. LOE should be summarized and analyzed separately.

Additional Resources

The industry standards provide information as to what to do, and they provide a basis for acquisition management. Process models like CMMI provide information for implementing processes. The CMMI provides a framework for process improvement towards integrating systems engineering and EVM.

The Carnegie Mellon Software Engineering Institute’s publication Using CMMI to Improve EVM (<www.sei.cmu.edu/>) provides information on the following processes and topics:

* Requirements development

* Requirements management

* Measurement and analysis

* Process and product quality assurance

* Risk management

* Typical work products

* Performance-based earned value.

Guidance for requirements-based planning is provided in “Practical Software Measurement, Performance-Based Earned Value” (CrossTalk: The Journal of Defense Software Engineering, Sept. 2001, <www.stsc.hill.af.mil/crosstalk>).

A contractor may be compliant with EVMS but fail to truly integrate measurement of cost, schedule, and technical performance. A PM should ensure that integrated plans, schedules, and the earned value PMB are linked with the contract requirements, TPMs, and unambiguous exit criteria. By requiring or encouraging suppliers to adhere to industry standards for systems engineering or engineering processes, EVM will provide more reliable information.

FIGURE 2. TPM Planning and Measurement

IEEE 1220: 6.8.1.5                   EIA-632: Glossary

Performance-based progress
measurement
TPMs are key to progressively        Predict future value of key
assess technical progress            technical parameters of the end
system based on current
assessments
* Track relative to time with dates  * Planned Value profile is time-
established as to when:              phased achievement projected
– Progress will be checked        * Achievement to date
– Full conformance will be met    * Technical Milestone where
* Use to assess conformance to         TPM evaluation is reported
requirements

FIGURE 3. Progress Against Requirements

IEEE 1220                        EIA 632

6.8.1.5 Performance-based        4.2.1 Planning process,
progress measurement             Req. 10: Progress against
6.8.6 Track Product … Metrics  requirements

6.8.1.5 d) Assess:               *  Assess Progress … comparing
* Development maturity to date      currently defined system
* Product’s ability to satisfy      definition against requirements
requirements                   a) Identify product metrics and
6.8.6 Product metrics … at        expected values:
pre-established control points
enable:                        *  Quality of product
* Overall system quality
evaluation                     *  Progress towards satisfying
* Comparison to planned goals       requirements
and targets                    d) Compare results against
requirements

Editor’s note: The author welcomes comments and questions and can be reached at SolomonPBEV@msn.com.

Solomon manages EVMS within the Northrop Grumman Corp., and is a visiting scientist at the Software Engineering Institute. He won the DoD David Packard Award with the team that wrote EVMS. He holds a bachelor’s degree and a master’s in business administration from Dartmouth College and is a project management professional (PMP).

Paul J. Solomon “Integrating systems engineering with earned value management”. Defense AT&L. FindArticles.com. 28 Feb, 2010. http://findarticles.com/p/articles/mi_m0QMG/is_3_33/ai_n6126614/
COPYRIGHT 2004 Defense Acquisition University Press
COPYRIGHT 2004 Gale Group

Forcefield Analysis and the Three-Stage Model of Change

February 28th, 2010

http://www.improvementandinnovation.com/features/articles/forcefield-analysis-and-three-stage-model-change
improvementandinnovation.com

An introduction to two of the concepts that social scientist Kurt Lewin introduced to organisational change management…

An introduction to two of the concepts that social scientist Kurt Lewin introduced to organisational change management…Kurt Lewin, the consummate applied social scientist, is responsible for giving us three of the ten concepts that support effective OC practice: Forcefield Analysis, The Three-Stage Model of Change, and the Action Research Model. I will cover the first two concepts in this article

Lewin’s first concept, and practice tool, is called Forcefield Analysis. Lewin believed every organizational situation, no matter how dysfunctional, benefits someone. I have found this concept and tool to be very effective in Organizational Change practice.

Lewin believed the status quo is a result of driving forces and resisting forces. Driving forces are pushing or “driving” for change. Resisting forces exist because some parties benefit from the current situation, or status quo. Thus, the status quo is the result of the strengths of the two opposing forces.

In practice, Lewin recommended working to reduce the resisting forces, instead of increasing the driving forces. He believed simply increasing the driving forces would result in an escalation in the resisting forces against the change. The parties resisting change (supporting the status quo) are usually highly motivated.

Another concept closely associated with Forcefield Analysis is what Lewin called the Three-Step Model of Change. He believed change required three steps: unfreezing the current situation, moving, and then refreezing the new situation (a new status quo). At first glance, this may appear to be obvious and simplistic. But the steps are very important.

The OC consultant must first help the organization to see the dysfunctionality (ineffectiveness) of the current situation. Remember, we are dealing with some organizational members who benefit from the current status quo.

To move the organization or the unit (to change behavior) requires a planned intervention. This will be a time of insecurity and fear for many organizational members. Fortunately, there are many structured interventions available to OC consultants. I cover interventions in Part II of my book, “Strategic Organizational Change.”

In step three, Lewin said we must “refreeze” the situation. In practice, I have found this step to be essential. In order to get the change to hold, there must be a supportive environment for the change. This means management must commit resources and reward desired behaviors; otherwise, the organizational members will slip back into their old, comfortable ways of doing things.

Anthony Buono has correctly added, “There is a significant difference between dealing with the type of episodic, discontinuous change that Lewin referred to in 1947, when he created this model (dealing, in essence, with organizational inertia), and the type of ongoing, overlapping, continuous change that is happening today.” I expound on Professor Buono’s comments in my chapter on Leading Change.

change management – force field analysis & Lewin’s change model

February 28th, 2010

http://tutor2u.net/business/strategy/change-management-force-field-analysis.html
tutor2u.net

change-management-force-field-analysis_clip_image002
Lewin’s Force Field Analysis

*  There are forces driving change and forces restraining it
* Where there is equilibrium between the two sets of forces there will be no change
* In order for change to occur the driving force must exceed the restraining force

The analysis can be used to:

* Investigate the balance of power involved in an issue
* Identify the key stakeholders on the issue
* Identify opponents and allies
* Identify how to influence the target groups

Lewin’s change model

This model defines three stages in the process of change:
(1) Unfreezing
(2) Change
(3) Refreezing

It assists organisation change by:

* Allowing the process to be understood
* Providing milestones for evaluating progress towards the change

Unfreezing
This is the shake up phase perhaps triggered by declining sales or profits. The result is an acceptance that the existing structures and ways are not working
To get people ready for change it is necessary to develop an awareness of the:

* Necessity of change
* Nature of change needed
* Methods planned to achieve the change
* Needs of those affected
* Ways that progress will be planned and monitored

Changing
This is the process of devising and implementing the change:

* Define the problem
* Identify solutions
* Devise appropriate strategy to implement change
* Implement solutions

Refreezing
This is the process of maintaining the momentum of change:

* Locking in the changes
* Stabilising the situation
* Building relationships
* Consolidating the system
* Evaluation and support
* Preventing any going back to the old ways

Refreezing is complete when the new patterns are accepted and followed willingly

Force Field Analysis – Lewin, Kurt

February 28th, 2010

http://www.valuebasedmanagement.net/methods_lewin_force_field_analysis.html
valuebasedmanagement.net

picture_lewin_force_field_diagram
Kurt Lewin was an American social psychologist and having contributed to science group dynamics and  action research, he  is regarded one of the founders of modern psychology. But Lewin is perhaps best-known for developing Force Field Analysis, using  Force Field Diagrams.

According to Kurt Lewin “An issue is held in balance by the interaction of two opposing sets of forces – those seeking to promote change (driving forces) and those attempting to maintain the status quo (restraining forces)”. Lewin viewed organizations as systems in which the present situation was not a static pattern, but a dynamic balance (”equilibrium”) of forces working in opposite directions. In order for any change to occur, the driving forces must exceed the restraining forces, thus shifting the equilibrium.

The Force Field Diagram is a model built on this idea that forces – persons, habits, customs, attitudes – both drive and restrain change. It can be used at any level (personal, project, organizational, network) to visualize the forces that may work in favor and against change initiatives. The diagram helps its user picture the “tug-of-war” between forces around a given issue. Usually, there is a planned change issue described at the top, and two columns below. Driving forces are listed in the left column, and restraining forces in the right column. Arrows are drawn towards the middle. Longer arrows indicate stronger forces. The idea is to understand and make explicit all the forces acting on a given issue.

The Force Field Analysis is a method to:
- investigate the balance of power involved in an issue
- identify the most important players (stakeholders) and target groups for a campaign on the issue
- identify opponents and allies
- identify how to influence each target group

How to conduct a Force Field Analysis? Typically the following steps are taken:
1. Describe the current situation
2. Describe the desired situation
3. Identify where the current situation will go if no action is taken
4. List all the forces driving change toward the desired situation
5. List all the forces resisting change toward the desired situation
6. Discuss and interrogate all of the forces: are they valid? can they be changed? which are the critical ones?
7. Allocate a score to each of the forces using a numerical scale e.g. 1=extremely weak and 10=extremely strong
8. Chart the forces by listing (to strength scale) the driving forces on the left and restraining forces on the right.
9. Determine whether change is viable and progress can occur
10. Discuss how the change can be affected by decreasing the strength of the restraining forces or by increasing the strength of driving forces.
11. Keep in mind that increasing the driving forces or decreasing the restraining forces may increase or decrease other forces or even create new ones.

Resistence to Change – Approaches of Kotter and Schlesinger

February 28th, 2010

http://managementaccountant.wordpress.com/2008/04/26/resistence-to-change-approaches-of-kotter-and-schlesinger-2/
managementaccountant.wordpress.com

The Six (6) Change Approaches of Kotter and Schlesinger is a model to prevent, decrease or minimize resistance to change in organizations.

According to Kotter and Schlesinger (1979), there are four reasons that certain people are resisting change:

* Parochial self-interest (some people are concerned with the implication of the change for themselves ad how it may effect their own interests, rather than considering the effects for the success of the business)
* Misunderstanding (communication problems; inadequate information)
* Low tolerance to change (certain people are very keen on security and stability in their work)
* Different assessments of the situation (some employees may disagree on the reasons for the change and on the advantages and disadvantages of the change process)

Kotter and Schlesinger set out the following six (6) change approaches to deal with this resistance to change:

1. Education and Communication – Where there is a lack of information or inaccurate information and analysis. One of the best ways to overcome resistance to change is to educate people about the change effort beforehand. Up-front communication and education helps employees see the logic in the change effort. this reduces unfounded and incorrect rumors concerning the effects of change in the organization.
2. Participation and Involvement – Where the initiators do not have all the information they need to design the change and where others have considerable power to resist. When employees are involved in the change effort they are more likely to buy into change rather than resist it. This approach is likely to lower resistance and those who merely acquiesce to change.
3. Facilitation and Support – Where people are resisting change due to adjustment problems. Managers can head-off potential resistance by being supportive of employees during difficult times. Managerial support helps employees deal with fear and anxiety during a transition period. The basis of resistance to change is likely to be the perception that there some form of detrimental effect occasioned by the change in the organization. This approach is concerned with provision of special training, counseling, time off work.
4. Negotiation and Agreement – Where someone or some group may lose out in a change and where that individual or group has considerable power to resist. Managers can combat resistance by offering incentives to employees not to resist change. This can be done by allowing change resistors to veto elements of change that are threatening, or change resistors can be offered incentives to leave the company through early buyouts or retirements in order to avoid having to experience the change effort. This approach will be appropriate where those resisting change are in a position of power.
5. Manipulation and Co-option – Where other tactics will not work or are too expensive. Kotter and Schlesinger suggest that an effective manipulation technique is to co-opt with resisters. Co-option involves the patronizing gesture in bringing a person into a change management planning group for the sake of appearances rather than their substantive contribution. This often involves selecting leaders of the resisters to participate in the change effort. These leaders can be given a symbolic role in decision making without threatening the change effort. Still, if these leaders feel they are being tricked they are likely to push resistance even further than if they were never included in the change effort leadership.
6. Explicit and Implicit Coercion – Where speed is essential and to be used only as last resort. Managers can explicitly or implicitly force employees into accepting change by making clear that resisting to change can lead to losing jobs, firing, transferring or not promoting employees.