Please enable JavaScript.
Coggle requires JavaScript to display documents.
Digital Change Management: Week 10 - Change Nexus (A design theory nexus…
Digital Change Management: Week 10 - Change Nexus
A design theory nexus is a set of constructs and methods that enable the construction of models that connect numerous design theories with alternative solutions.
Pries-Heje and Baskerville 2008
This is focussed on "ill-structured or wicked problems"
What do they do in this paper? We develop a general method for constructing a design theory nexus and illustrate its utility using two field studies
Weak conclusion: We conclude that the design theory nexus provides a viable conceptualisation that enables the construction of effective problem-solving artefacts.
Two types of decision making:
Structured decisions
are repetitive and routine.
Unstructured decisions
defy programmed decision making because they are novel, complex, or value-laden
Wicked problems
share certain characteristics. For example, they can only be formulated in terms of a solution. Their solutions are value-laden, and cannot be denoted true or false, only good or bad.
There are differing opinions about what constitutes design theories for information technology artefacts. Walls et al. (1992) specify two major components of IT design theories: a product component and a development process component.
Goals are “what the system is for” (Gregor and Jones 2007, p. 32)
Contingency theory
arises from a broad array of studies, for example, as a model explaining the high failure rate for information systems in developing countries (Heeks 2002)
Contingency theory has been criticised for having a too static view of the relationship between structure and technology
The design theory nexus
originated in a project aimed at the discovery of ideal approaches to organizational change for specific organizational settings
There are many different foundational theories for organisational change. The process by which an organisation selects the appropriate approach to organisational change is often ad hoc. Each approach has its advocates and adherents, and there is little comparative research for choosing among such approaches. These approaches are so varied that com- parisons are usually drawn between only two (e.g., Beer and Nohria 2000), three, or four alternatives (e.g., Huy 2001).
The clients in this case were from four larger organisations in the financial sector.
You can also have
commanding
or
optionality
change. Plus, there are
six factors which influence the COMPLEXITY of the change you are implementing
: (1) The first factor leading to complexity is the degree of knowledge held by the developers in the domain in which the users work. (2) The second factor is task complexity. Where tasks are structured at the operational level, the demand for user involvement is minimal. (3) Size is the third factor we found that influences complexity.(4) The fourth influence factor on complexity was knowledge of the technology. (5) The fifth influence factor is perceived change for stakeholders. (6) Finally the sixth influence factor is the type of system.
There are also
three factors which impact the resources of the project
(1) The first factor was management support, which will increase the prospect of user involvement (2) The second factor involves resources in the form of adequate budget and staff for the project (3) The third factor is time, especially with regard to whether the project has a hard or a soft deadline.
Your users can also be User identity is classified as named or nameless users
.
Conclusions
: Our experiences have been with a relatively small number of organisations, each involving a relatively small number of people. It takes a great deal of planning and time to exercise an instance of a design theory nexus.
Pries-Heje and Vinter 2008
In this paper
they describe a framework which combines several models for organisational change
Means and Approaches belong to the operational level. The selection of a change strategy, however, belongs to the top level of the organisation. It is heavily influenced by the vision or goals for the change as well as by issues in the organisational culture.
We developed a framework that binds together ten well-known organisational change strategies into a prescriptive recommendation for a cohesive and suitable change strategy for a particular organisation’s unique situation. The change strategies to be prescribed develop from a list-of-fit that indicates the relative suitability of each of the ten strategies to the organisation’s vision and setting.
Jan Pries-Heje and Jørn Johansen (2015)
How can you identify the overall change strategy ‘from among a myriad of available change models? One is called ‘commanding’, another is ‘optionality’, yet another is ‘learning-driven’, and so on.
As part of our (the authors) work with the ImprovAbility model, we designed this framework of how to select change strategy with the addition of a tool to guide managers in evaluating and choosing which of the ten change strategies would be the most appropriate in an actual organisational setting for a defined organisational change.
The organisational change framework was used in 16 different companies as structured workshops.
A conclusion from these organisational change strategy assessments is that all participants (of magnitude 100 managers), without exception, were positive and could understand and accept the result.
What did they do
: In this paper, we have looked at the newly published ISO/IEC 33014 standard in which there is a strategic activity called ‘identify the overall change strategy’, which includes selecting a change strategy ‘from among a myriad of available change models
Main conclusions and overview of what they did
: The book on the ImprovAbility model [2] describes a framework of how to select among 10 distinctly different change strategies. We looked at the details of the framework, and we phrased the research question: which ones are chosen in practice? The answer that was found in a study of 134 assessments in 129 organisations that applied the framework was that optionality was a clear number one followed closely by three other strategies: specialist-driven, production organised, and learning-driven
Wienberg (1993)
Main thesis
: Measurement is everything (when starting something new)
Where to start
: (1) Identify your customers (of change) (2) Identify what those customers value (3) Select positive and achievable goals (4) State the goals in a measurable way (5) State the goals with minimum constraints on the project (6) Check for obstacles (to do that, you often need to hire external consultants) (7) Check for resources.
Other advice
: Plan, but don't plan too much (not everything will go to plan).
Key conclusions
: you should start measuring software before you do anything else.