1. Re-engineering the Design Phase of
Appreciative Inquiry
Workshop paper explaining the theoretical background of replicable practices for the
design-phase of Appreciative Inquiry
Johannesburg, WAIC 2015
Author : Jan De Winter
DWT Consulting bvba

2. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
2
Abstract
In projects dealing with large-scale enterprise transformation, including business, organizational and technological changes,
finding solutions to the following challenges is critical to success. How to keep these transformations intellectually
manageable? How to design technology and organizations so that they support the business goals? How to keep all the
partners on track? A key factor in delivering successful transformations is the quality of the preparatory phase.
In this paper we present possible innovations to the classic AI-summit that can improve the quality of the results of this
preparatory phase. Studying generic system design and engineering processes reveals interesting possibilities for innovation.
These include the use of conceptual modelling and guiding principles, the iterative approach of the design phase and the
overall aim to reduce complexity in order to keep the design process intellectually manageable. For each of these options an
innovative approach is presented in the paper.
An important mechanism behind these new ways of working is related to the shift in individual and shared mental models
during the preparatory phase that allows the transformation to take place.
The proposed innovations have been applied in different cases in practice and the first results are promising.
In this paper the proposed innovations are presented as design propositions for practitioners that are reusable and adaptable
in future instances involving similar problems in similar contexts. Using a structured description, explaining first the problem
in context (c), then the proposed intervention (i), then the mechanism behind it (m) and finally the expected outcome (o), the
practitioner can easily deduce whether this type of intervention will help in a given situation.
Introduction
Context of this paper
Jan De Winter, the author of this paper, is active in a field of management consulting that specializes in large or important
projects or programs that include changes at a business, organizational and/or technological level. In this paper we will call
them ‘change projects’. Changes at the business level are typically changes in products and services that the organization
offers to its clients. Examples can be an HRM department offering new types of personal development activity such as e-
learning to the organization’s own employees; or a confectionery company offering web-based services for personalizing T-
shirts to its clients.
Changes at the organizational level have to do with changes in processes, in organizational structures, in procedures. These
support the realization of the changes at the business level. Examples can be the creation of a new position in the HR
department dealing with the content management of the e-courses or the changes in the organizational process needed to
deal with personalized printing.
Just like the changes at the organizational level, the changes at the technological level support the realization of the business
goals. These changes can be related to information technology (e-learning software, drawing software, etc), but also to
infrastructure (servers) or machinery (textile printing).
At the moment Jan is also working on PhD research in which he combines Appreciative Inquiry (AI) with methods that are
derived from system engineering and are applied to social systems such as enterprises or government institutions.(1) This is
the reason why this research domain is called ‘Enterprise Engineering’ (EE).(2) Since both domains, AI and EE, often use the
same terminology but with different meanings, it will be important from time to time to deal with some definitions.
In this paper, which in the first instance is intended for an audience familiar with AI, we will apply the terminology that is
common in the organizational development body of knowledge.
Jan’s PhD research and also this paper focus on the preparatory phase of a change project. The preparation typically starts at
the moment that the first ideas or concepts regarding the project are defined. Often it is not much more than the statement
that something needs to be done regarding a problem. The preparatory phase ends when a final-go/no-go decision is taken
based on a well-elaborated project plan. Figure 1 shows that the start of the preparatory phase is characterized as a situation
with low clarity about what needs to be done in the given project combined with a high freedom of choice.

3. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
3
Figure 1 (3)
In contrast, at the end of the preparatory phase it has become clear what needs to be done in the change project, which
means that choices have been made and the remaining freedom of choice has become limited.
Some authors, for instance Jan Hoogervorst, define a project as ‘a carefully planned and organized set of activities for
realizing a specific, one-time objective’ (Hoogervorst 2009, 229, 321).(4) A key requirement in this view on projects is the a
priori definition of all activities and their timing. The mainstream definitions, however, of project management (APM, IPMA,
Prince2, …) include an initiation and planning phase or a concept and feasibility phase in the project, mostly called the
preparatory phase. In this preparatory phase a lot of choices need to be made in order to achieve the definition of all future
project activities and their timing.
Of greater importance is the fact that the nature and characteristics of the preparatory phase are completely different from
those of the execution and control phase. By definition, the preparatory phase is characterized by the emergence, based on a
creative group process of reflection and inquiry, of results (new ideas), that could not have been known in advance. The fact
that the two main parts of a project are so completely different opens up an urge to separate them. The important question
is this: Is it possible to combine all the necessary competences in one (group of) person(s) in order to be successful in both
parts? This paper focuses specifically on the preparatory activities of projects, regardless of the fact that they are part of the
project or not.
Objective and structure of this paper
The goal of this paper is to give the reader a first insight into possible improvements to the preparation of change projects by
using AI and EE approaches.
In the first section we will explain the importance of the problem of failing IT and change projects. Often the cause of failure
can be found in the preparatory phase of these projects, which emphasizes the importance of this type of research.

4. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
4
In the second section we will explain the possible improvements based on the use of AI. Afterwards, we will do the same for
EE, focusing on the following aspects: conceptual modelling, the use of architecture and the iterative nature of designing.
In a brief intermezzo we will then explain the role that individual and shared mental models play in the success of change
projects.
Finally we will describe the changed way of working as possible templates or design propositions.
Findings from practice
We defined change projects as projects or programs that include changes at a business, organizational and/or technological
level. Given the ever-increasing importance of information technology (IT) in all of our organizations, change at the
technological level is often related to IT.
There is overwhelming evidence for the fact that many change projects fail. A simple search in Google on ‘facts & figures,
why projects fail?’ shows an endless list of hits with appalling figures of the rate of failure in IT as well as change projects. For
this paper we take only three studies as examples, two from the website www.calleam.com(5) and a third from the findings
of the Standish Group.
The first example is a study in 2012 carried out by McKinsey & Company in collaboration with Oxford University and is based
on 5,400 large IT projects. The key findings are that (a) 17% of the projects go so badly that they can threaten the very
existence of the company; (b) 45% are over budget, 7% over time and 56% deliver less value than predicted.(6)
A second example is even more interesting for this research. It is a study carried out by a company called Geneca in
2010/2011 and it is based on interviews with 600 people who played an IT-oriented role in projects. When interviewed at the
start of the project 75% of the people indicate they lack confidence that their projects will succeed because of fuzzy business
objectives and out-of-sync stakeholders; and 78% of them reported ‘that business is usually or always out of sync with
project requirements’.(7)
The Standish Group is doing intensive primary research on software projects all over the world and has a research database
with information on thousands of projects each year.(8) The results of this research for large government projects were
presented to the ‘Dutch committee on government ICT projects’. This committee was officially mandated by the Dutch House
of Representatives to investigate the failure of several large government ICT projects in the Netherlands between 2012 and
2014.(9) In a recent article, Mulder and Kontakis commented on the conclusion of the committee and argued that the failure
of large ICT projects is not a Dutch problem but a worldwide phenomenon.(10)
Figure 2 (11)

5. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
5
The results in Figure 2 are based on the CHAOS database of the Standish Group. They show the results for large government
projects; only 13% of these projects are on time, on budget and on target.
It needs no further argumentation to show that the cost of failing projects on our societies worldwide is way too high and
that further research is needed in order to find ways to improve these results.
Why do so many projects fail? What are the reasons behind these failures? The number of lists on the internet of common
reasons why projects fail, or mistakes that lead to failure, is very long. These reasons range from a lack of common goals and
vision, no involvement of users, no support at executive level, over-planning issues and requirement issues, to a lack of
knowledge and expertise, and so on and so forth.
Also, the Standish Group reports on the reasons for project failure regularly and the following reasons – considered to be
very important(12) – are almost always present in the reports:
- Lack of executive business support
- Lack of user involvement
- No clear vision and objectives
- Project milestones are too large
Not all of the reasons why projects fail are situated in the preparatory phase of the project, but a lot of them are. This is
consistent with the findings in my consulting business in which half of the projects I’m involved in are those that have failed
or are about to fail. In those cases most often insufficient preparation for the project is part of the reason why the project is
in crisis. Especially the lack of shared vision and shared understanding of the objectives – shared between all of the
stakeholders involved – is an important reason why things go wrong later.
Concluding these findings from practice, I want to make three important remarks about the preparatory phase of change
projects. First of all, there is the characteristic of emergence. In other words, it is important during the preparatory phase to
allow and stimulate creative reflection and inquiry in order to establish the necessary shared understanding about the
project. This means shared understanding not only on what the project should deliver but also on how these results can be
realized. Given the fact that AI is an approach that emphasizes reflection and inquiry, I propose to introduce it in the
preparatory phase of change projects.
Secondly, in order to be able to make a go/no-go decision and to start the carefully planned and organized set of activities, it
is imperative to know what needs to be built during the project. This is impossible without the necessary design activities
during the preparatory phase. EE looks at the enterprise from a constructional point of view, which is essential when talking
about changing the enterprise. Therefore we believe that it important to introduce some EE activities in the preparatory
phase of change projects.
The third remark is not further elaborated on in this paper but it is too important not to mention. It deals with the question
of what products (results) the preparatory phase should deliver in order to be able to take the go/no go decision mentioned
earlier.
AI in the preparation of projects?
AI was introduced by Cooperrider and Srivastva as an alternative to the dominant problem-solving approach in organizational
development practice.(13) In the past two decades, AI has shown a phenomenal worldwide growth. The AI approach is used
to support change at all possible levels: individual, team, organization, and even communities. Several cases have been
described in the literature in which AI has delivered the successful transformation of organizations. In the Appreciative
Inquiry Handbook (2nd edition) Cooperrider, Whitney and Stravos use material from dozens of successful transformation
projects in different organizations.(14) Other authors (Bushe & Kassam (2005); Fry & Others (2002)) have also reported on
successful cases in which AI has been used in order to transform organizations.(15,16)
How can AI be introduced in the preparation of change projects? The classic approach of AI consists of four phases, better
known as the 4-D cycle, and can already be an important improvement (Figure 3). It starts with ‘Discovery’ in which
participants discover and appreciate the existing strengths. Phase 2 is about the ‘Dream’ in which the focus is on imagining
the best that can be. After that comes the ‘Design’ phase in which the participants design what is necessary to be able to
realize the dream. In the fourth phase, ‘Destiny’, the realization of the dream takes place.

6. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
6
Figure 3
In order to have the right impact, the following aspects of AI are also very important. First, the choice of the affirmative topic
is crucial to the success of the inquiry. This needs to be done before the discovery phase begins because it will be guiding the
reflections and brainstorming. Often a small 4-D cycle is used with a smaller group to define the affirmative topic and thus
create an iterative process (see Figure 3).
Secondly, the right participants have to be invited. In order to be successful the right knowledge and expertise needs to be
present in the brainstorming sessions. Depending on the objectives, it is important to decide which people to invite in order
to bring the whole system into the room.
Thirdly, the gathering, also called the AI summit, where the brainstorming sessions take place, needs to be designed in a
particular way. Most important is that the summit starts with the discovery phase based on individual storytelling about
positive experiences. This is a crucial step in the creation of the atmosphere of the meeting and the mutual trust between
participants.
Given any kind of change project, the steering group of the project can be made responsible for defining the affirmative topic
of the inquiry. They can also take on the preparation of the AI summit. During this summit, all those who are directly involved
or who have relevant knowledge or expertise (the whole system) are invited to participate in the brainstorming sessions in a
very structured way.
The AI summit starts with discovery of the best of the past – in other words, the strengths of the actual organization on
which the transformation will be built.
In the second part of the AI summit the participants dream about the possibilities (all that could be), but keep in mind the
strengths of today’s organization. Once the ideal images of the future have become a shared vision of the future, the
participants can start the design.
In the design, the translation is made from the ‘what’ question (the result of the dreaming) to the ‘how’ question. How will
we realize the dream? What do we need to build in order to be able to realize the dream? Depending on the dream, these

7. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
7
artefacts can be processes, competencies, culture or IT systems. The end of the AI summit is the start of the destiny phase in
which the realization takes place. During the destiny phase, the shared image of the dream and the shared understanding of
how this dream can be realized (descriptions of the design) lead to the creation of the new artefacts.
Based on intensive research on 20 cases in which AI was reported to be successful, Bushe and Kassam (2005) came to the
conclusion that the largest transformations are achieved when the people involved change the way they think during the
process rather than the way they act.
A second conclusion of this interesting research is the fact that, given the changed way of thinking of the participants, it is
better to let go of control and planning during the destiny phase and adhere to a more improvisational approach.(15)
Some critical remarks need to be made regarding the classic approach of AI in the preparation of change projects. As already
mentioned, the variety of artefacts that need to be designed is very large in change projects and often they are also related
to complex technical systems. Is it possible to really re-design these technical artefacts during the AI summit?
The second remark is related to the improvisational approach and the duration of change projects. Large and especially long
change projects tend to experience quite a staff turnover during the realization of the project. How will we manage to keep
the participants on the right track (meaning in the right direction) in the case of high staff turnover?
EE in the preparation of projects?
The premise underlying EE is the statement that any enterprise is a goal-oriented, deliberately designed social system and
thus any enterprise change requires a certain level of redesign or re-engineering of the enterprise.
In order to explain this point of view, we first have to explain the notion ‘system’ and, secondly, the ‘generic system
engineering’ process. After that we will explain three characteristics of engineering that we believe are of value to improving
the preparation of change projects.
So, first of all, a clear picture is needed of the notion ‘system’. Therefore we describe a system in terms of its main
characteristics:(17)
C = system composition (the set of elements of the system)
E = environment (the elements in the environment with which the system interacts)
P = production (the products or services that the system delivers to the environment)
S = structure (the interactions between the elements internally and with the environment)
There are several definitions of the notion ‘system’ but, given the topic of this paper, the definition most suitable is the one
used by system engineers when referring to engineered systems that contain combinations of technology and people created
to achieve a goal or purpose of value to one or more stakeholders (Hitchins 2009).(18) In this definition the orientation of a
system towards a goal is very important, which is also the case in enterprises, social organizations and government
institutions.
Two very important perspectives of systems can be distinguished: functional and constructional. The functional perspective
emphasizes the relationship of the system to its environment, the function of the system, and the products and services it
delivers to or receives from the environment.
The constructional perspective emphasizes the internal structure of the system, that is, the way the elements and their
interaction are organized within the system.
In order to be able to redesign, an enterprise engineer will look for both functional and constructional requirements in
relation to the changed functional and/or constructional goals. Next to the goals and the requirements, an important input in
the redesign process is the areas of concern that are related to the system. They have to be addressed during the redesign
process. Typical areas of concern in the design of cars, for example, are energy consumption, driver safety, and maintenance.
In order to make this terminology more meaningful or real, we will apply it to the example of the confectionery company that
wants to provide online printing facilities to its customers:
- Functional goal: the ability to deliver personalized T-shirts (i.e. T-shirts with an image uploaded by the customer)

8. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
8
- Constructional goal: deliver personalized T-shirts without manual interference by employees
- Functional requirement: allow customers to adapt the size of the picture after uploading
- Constructional requirement: allow automatic upload from internet server to cotton printer after validation
- Areas of concern: logistical feasibility; user-friendly interface; complaint management.
Given the long history of system engineering in general, a large body of knowledge has been generated regarding the generic
system engineering process. One example is the System Engineering Body of Knowledge or SEBoK, a wiki that is monitored by
three important scientific organizations in the world of system engineering: SERC, INCOSE and IEEE-CS.(19) According to
SEBoK, system engineering unravels in a sequence of steps:
 Step 1 concept definition
 Step 2 system definition
 Step 3 system realization
 Step 4 system deployment and use.
Given the topic of this paper, we will elaborate only on steps 1 and 2.
During the first step, the definition of the concept, the engineer inquires about the business or mission analysis and the
needs and requirements of the stakeholders. This inquiry will mainly deliver the functional and constructional goals, the
functional requirements and also the areas of concern.
In the second step, the definition of the system, the engineer will first establish the constructional requirements in order to
arrive at a complete set of system requirements. Then he or she can start designing, which is mostly split up into logical and
physical phases. During this part of the process, the engineer will create a logical model of the future system. This will help to
reduce the complexity and to keep the whole engineering activity intellectually manageable. The result of the design process
is, in the first place, a logical architecture design describing the functionality and behavior of the future system. Afterwards,
in the physical architecture design of the system, specific physical elements will be allocated to the logical architecture.
The last stage of the system definition step is the system analysis in which the engineer will check whether the systems meet
all the requirements. Typical of the system definition step is its iterative nature. It starts over and over until the analysis
shows that all the requirements are met.
Three characteristics of the generic system engineering process were chosen in order to investigate whether they can
improve the preparation of change projects:
- the use of conceptual modelling
- the use of architecture
- the iterative nature of the design and engineering process.
In the following paragraphs we will explain how they are operationalized in the context of change projects.
Conceptual modelling
A model is a representation that can help the group of people involved in the change project in different ways: from
analyzing concepts to specifying and validating the future system. In order to be able to communicate properly about a
model, it is important to choose one that is supported by a well-defined modelling language. Some important reasons for
using conceptual models are: (a) the possibility of reducing complexity in the preparation of change projects; (b) the precise
and concise notation of the shared vision and understanding of the future; (c) the possibility of using the model as a summary
of the created knowledge during the preparatory phase; (d) the possibility of using the model as the reference framework
with which to plan future activities in the change project.
In the case of change projects, we propose to use the construction model of the Design and Engineering Methodology for
Organization (DEMO), because of its focus on the responsibilities of organizations.
The construction model of DEMO gives us insight into the responsibilities and communications that have to be organized
inside the organization in order to be able to realize the commitments the organization has made with the environment. In
this way it is a representation of the organization that needs to be built.

9. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
9
For a full explanation of DEMO and the underlying theory and methodology we refer to the books on Enterprise Ontology by
Jan Dietz (2006) and Hans Mulder (2006).(17, 20)
Architecture
The architecture of a system can be defined as the concepts or properties of a system in its environment as embodied in its
elements and relationships, and in the principles guiding its design and evolution (SEBoK, 2015).(19) From the point of view
of EE, architecture needs to have a more normative nature. At the CIAO-network website architecture is defined as the
normative restriction of design freedom. As we will discuss further in this paper, architecture is operationalized by means of
principles that guide the design of systems.
The most important function of architecture is the guidance it offers while designing and using the system. Therefore
architecture consists of a set of guiding principles that have been predefined in order to achieve a certain set of goals, taking
into consideration a number of areas of concern. Architecture is the result of the activity called ‘architecturing’, namely, the
activity of defining the abovementioned set of guiding principles. In Figure 4 the reference context of architecturing is
illustrated as it was defined by Jan Hoogervorst (2009, 2011).(4,21) The input for architecturing is the system goals, the areas
of concern and the design domains that are involved. Typical design domains for enterprises are the organization (structure,
processes, people, procedures), the information (data, documents) and the technological infrastructure (applications,
databases, railways).
A guiding principle should address an area of concern and at the same time apply to a certain design domain.
Figure 4 (22)
The architecture (if it exists and it takes into account the changing goals) as the activity of architecturing is also of real
interest during the preparation of change projects. Why?
Successful realization of change projects is strongly affected by the capability of senior management to consistently change
bad habits. Consistent, that is, over a long period of time, but also consistent between the different individual members of
senior management. A good set of guiding principles that all managers agree on is an interesting tool to use to achieve this
consistency.
Iterative process
In the design system, there is no one-to-one relationship between a requirement and a solution. Designing and engineering
are not based on linear deductive or even inductive reasoning processes. Design thinking is also about intellectually jumping
over existing gaps in the knowledge in order to find unique solutions to several different problems at the same time. And it is
about testing whether a newly defined solution is still consistent with decisions taken earlier in the reasoning process. So by
definition we can say that the design and engineering process is iterative, meaning that the same share of reasoning will be
gone through different times until the whole of the system is rendered coherent.

10. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
10
This iterative characteristic of design and engineering does not fit very well with the idea of an AI summit at which the design
phase is one part of a two- or three-day gathering. The literature on AI does not state that the design activities should never
be organized in an iterative way; but, on the other hand, the AI summit is advocated as a best practice. It is difficult for us to
accept the idea that the design of complex organizational changes can be realized within the limitations that are typical of an
AI summit.
Therefore we introduced the idea of an AI summit with an enlarged design phase in which design as an iterative process of
creative reflection can find the necessary space. The AI summit starts traditionally with two days of discussions that end with
clear instructions for smaller task forces. These task forces further elaborate the domain that has been assigned to them.
After three meetings in smaller groups, the whole system is brought together in a large group meeting to share ideas and
give new directions and impulses to the small task forces. These iterations continue until all of the groups have achieved the
necessary level of depth that enables them to proceed to the destiny phase.
Ground = shared mental models
We have already mentioned the research of Bushe and Kassam in which they compared 20 successful AI cases. Bushe and
Kassam claim that an important difference between classic organizational development approaches and the AI approach is
the fact that AI creates new ground for the collaborators to base their future actions on:
‘Ground is about the substructure that influences what people think and do. In organizations this can range from
physical space to mental maps, from emotional fields to semantic fields.’ (Bush & Kassam, 2005; 7)(15)
This is a very important notion because, if, indeed, new ground needs to be created during the AI intervention to achieve
transformational change, then it is important to figure out how we have to design our interventions in order to make this
happen.
Therefore we want to make the link between the notion of ‘ground’ as it is defined by Bushe and Kassam, on the one hand,
and the notion of a shared mental model as it is defined by Kim (1993), on the other.(23) In his investigation of the
interaction between individual learning and organizational learning, Kim integrated several theories of individual and
organizational learning in one model. The advantage of this model is that it explains the role of the individual in the process
of organizational learning and it gives handles with which to operationalize the process of organizational learning. A shared
mental model is a way of working, an organizational routine, or a way of thinking, a strong belief about the organization or
the environment, that is widely shared among the collaborators in an organization.
It is our belief that certain shared mental models are blocking certain organizational changes. In the case of the Belgian
FedGov Institute there existed a strong belief that the institution would always be subsidized by the Belgian government as it
had been for more than 180 years. And even if the signs in the environment say something else, there is no ground for
change if this shared mental model directs the way collaborators think. So it is important to find out what the blocking shared
mental models are, given a certain change. But even more important is finding out what the mechanisms are that we need in
order to challenge or change a shared mental model. And here also Kim’s theory can help us.
Kim states that an existing shared mental model, which is a part of the active memory of an organization, can be altered only
through interaction with the active memory of a member of the organization. In practice this means that only the sharing of
individual mental models that challenge the existing shared mental models can lead to changes in the shared mental models
and thus to breaking new ground. And it also means that individuals first need to be convinced and change their individual
mental models, because only when enough individuals have changed their individual mental models can we start to speak of
a new shared mental model. This is probably not extraordinarily new for most readers, but is has some important
consequences when it comes to designing interventions in organizations.
We have to design our interventions is such a way that new ideas can be shared so that they can challenge existing ones. This
takes time – lots of time – because individuals will not change their mental model just by listening to the speech of a CEO.
They have to talk and reason about these new ideas themselves, all of them.
We also have to make sure that people with new ideas have the necessary confidence and trust to challenge the existing
ideas, because it demands courage and support to swim upstream.

11. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
11
One big moment of sharing new ideas and challenging old ideas will help, but we all know that the name of the game is
rehearsal and repetition. Only repetition will make it stick.
Some shared mental models are built on years of experience and carry a load of reasons why they are right. So probably
these kinds of shared mental model will need more details to be elaborated upon in order to withstand the resistance.
In itself, the AI approach offers many of these elements, so it is an interesting approach to build on, as we will explain in the
following design propositions.
Four design propositions for change projects
A design science approach
Enterprise engineers and more particularly the colleagues from EE who are working on business process modelling and IT
systems are mostly interested in a design science approach. They are not really interested in describing existing artefacts and
systems. No, they want to design and engineer new artefacts and solutions in order to improve the as-is and are more
interested in the world that can be.
According to Van Aken,
‘the mission of a design science is to develop knowledge for the design and realization of artefacts, i.e. to solve
construction problems, or to be used in the improvement of the performance of existing entities, i.e. to solve
improvement problems.’ (Van Aken, 2004: 224) (24)
Most of the time when we talk about designed generic and reusable artefacts we think about a suspension bridge, an electric
engine for cars, the wings of an airplane, or a satellite. All of these are perfect examples of generic artefacts that we now not
only understand, but that we can design for a particular river, type of car, airplane or function. Why? Because during the
design science research we developed the design knowledge (the knowledge that we need in order to design one instance
for one particular application) and this design knowledge was thoroughly tested.
In my opinion, the AI summit is also a generic and reusable artefact which we now know how to design for a specific
application in a specific organization. And it has been applied hundreds of times in different organizations with different
affirmative topics. Probably not always with the same degree of success, but many times with a very positive result.
Were David, Ron, Gervash, and all the other researchers in AI deliberately acting according the design science research
approach? Probably not, because design science research has been very much limited to artefacts that are not influenced by
human or social interaction. Why? Because it is almost impossible to test the real effect of the designed artefact if the result
is influenced by human or social interaction.
One Dutch researcher, Van Aken, tried to overcome this issue and created an approach for design science research in the
social world.(25) He claims that it is possible to test the ‘designed artefacts’ at an academic level through objective and
systematic experiential social learning. This action learning is based on a series of case studies with detailed descriptions and
analyses of all the parameters of the cases. The results of this new form of design science are design templates, called ‘design
propositions’, that can be used by other researchers and practitioners in order to tackle a similar problem in their practice.
A design proposition is a template solution for a problem in a given context. It proposes a way of working that should lead to
a predictable outcome. In order to be able to decide as a practitioner whether this solution might work in the practitioner’s
situation, the solutions are written in the CIMO logic.
In the next paragraphs four design propositions are elaborated using the CIMO logic introduced earlier, first the problem is
described in context (C), then the proposed intervention (I) explains the mechanism behind it (M) and, finally, the expected
outcome (O) is presented.
The four replicable practices that we have developed based on our research are presented in the following paragraphs as
design propositions for change projects.

12. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
12
For the professional who wants to use a design proposition, the following way of thinking is applicable: ‘If you have a
problem X (in a certain context) and you want to reach a certain outcome Y, then you might use the following design
proposition because, given the context, it will deliver your desired outcome. Be aware that the design proposition is a generic
solution that you as a professional need to adapt so that it fits in your particular project.’
None of the design propositions (except AI, of course) have been used in practice or by another researcher so far. So they are
not yet tested through objective and systematic experiential social learning.
Get the crucial knowledge on the table
Problem in context:
Organizations are not free from politics, nor from organizational or personal history. Politics and personal experiences largely
influence the behavior of people in organizations. Therefore it is not enough to bring the people with the right knowledge
around the table to start preparing a new change project. There is a good chance that some of these people will not express
their true knowledge. The big question is, then: What needs to be done to get this crucial knowledge on the table? How can
these people feel confident enough to express their real worries?
Intervention:
Start the preparation using the AI approach. Although all of the AI approach can be an advantage in the preparation of
change projects, for this particular problem it is important to emphasize the following aspects of AI: the ‘affirmative topic
choice’, the ‘stars (positive story telling)’ and the ‘whole system in the room’.
Mechanism:
AI starts with appreciation, appreciation for what is good in a given context and appreciation for the people who are involved
in the enquiry process. But most of all AI is about enquiry, the search for solutions that will help us to get out of the actual
(perhaps problematic) situation. (14)
The ‘affirmative topic choice’ is a mechanism that will help the whole group involved in the enquiry to direct the dialogue
towards the chosen and affirmatively stated research topic. It will prevent the people around the table from dwelling on the
problem situation but will open their minds towards possible solutions.
The ‘stars (positive story telling)’ is perhaps the most important exercise in this intervention. It builds up trust among the
participants using the intimacy of very small groups at first and building up the dialogue towards the whole group at the end.
But not only the group setting is crucial; the content of the dialogue also has to be strictly monitored by using appreciative
questions that probe for positive examples of the affirmative topic in the ‘as-is’ organization.
The ‘whole system in the room’ doesn’t mean the whole organization, but a well-elaborated list of attendees to make sure
that all the knowledge necessary to make the change happen is present from the first meeting.
Outcome:
Using AI, and more specifically the three aspects of it mentioned above, at the start of the preparatory phase will lead to:
- open, honest and real dialogue between all the parties involved
- a first step in teambuilding of the group, leading to the necessary willingness to continue participation in the process
- competing participants coming to a ‘normal’ exchange of opinions again
- the first steps in changing ‘ways of thinking’ thanks to the trust and openness that have been created in the process.
Reduce complexity by essential modelling
Problem in context:
Change projects are very complex situations in which a great deal of information comes together. On top of that, the
information can be very confusing for participants because of the ambiguity between the ‘as is’ and the ‘to be’ that is always
present in change projects. As a consequence, it is possible that these projects are simply too complex to be intellectually
manageable for the people involved. The fact that participants can’t get a cognitive grip on what they are dealing with makes
them anxious and less open to change.
People involved in change projects often have different backgrounds and may have an appropriate vocabulary that they
share with people from the same background. So people from different backgrounds may use similar words but with
different meanings. This is one of the reasons why so-called ‘finished discussions’ are reopened because there was a

13. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
13
difference in interpretation of the words used in the discussion. These fallbacks are very bad for the participants’ confidence
in the process.
Intervention:
In the first part of the preparatory phase it is important to reduce the complexity and focus on the essentials to make sure
that the participants develop a shared understanding and a consensus at this higher level. Do not allow the participants to
dig into too much detail at the start of the process.
To do so, create ‘essential models’ of the ‘to be’ situation so that the participants are obliged to come to a consensus on
what this future really means. Depending on the scope of the project, the following essential models for different design
domains are of interest:
- The business domain explaining the different actors in the environment and the way these actors interact with each
other, using, for instance a, method called ‘board of innovation’.(26)
- The organizational domain explaining the internal responsibilities that need to be organized in order to be able to
retain the ‘to-be’ organization’s commitments externally, using, for instance, the DEMO construction model.(17)
- The information domain explaining what information objects need to be managed to support the commitments
explained in the business model, using, for instance, the existence dependency model of Merode.(27)
Mechanism:
Modelling – the activity leading to a new model – is a very challenging activity for most people. It obliges people to express
their ideas in a formal way (the modelling language) and name each activity in the model properly. Modelling in a group
obliges the participants to share their ideas and the names with the group. Finally, they have to reach consensus because
only one final model is accepted.
The dialogue that is started in the group this way opens the minds of the participants and allows them to challenge the actual
way of thinking (existing mental models) and to create new ways of thinking (mental models about the ‘to-be’ way of
working). Since functional as well as constructional models are created, the dialogue will focus not only on functional aspect.
This way the discussion on how the change will be realized will also be started in the preparatory phase.
The models that are created will serve as the reference models in the change project and are the starting point for further
detailed work. Since they describe only the essential level of the ‘to be’, the chances are greater that they will be
intellectually manageable for all participants in the change project.
Outcome:
Creating the essential models of the ‘to be’ activities will deliver the following outcomes:
- Several ‘to-be’ models regarding different aspects (business, organization and information) of the future activities
- A shared understanding of these models within the project group, including new shared mental models about the
change at hand
- A shared meaning of the vocabulary used in the project group
- Consensus on these models within the project group.
Install a well-designed iterative meeting structure
Problem in context:
Change projects are very complex situations in which much information comes together. This complexity calls for detailed
analysis by specialists while at the same moment there is a need for all parties involved in the process to have a global
understanding of the details. This would apply also to those not specialized in this particular area.
This is one of the reasons why change projects often struggle with the way they have to set up meeting structures.
Sometimes a choice is made for a series of meetings with a large heterogeneous group, which is good for the participation of
all stakeholders at each moment in time. But this choice hinders the detailed elaboration of ideas in one specific area
because too many people are involved who can provide no added value in the detailed elaboration of ideas.
Sometimes a choice is made for more specialized task forces that are working on specific domains for a longer period (often
responsible to a program manager). These separated task forces risk losing focus on the bigger picture and delivering
solutions that are very good within the problem area but which have no connection with the other problem areas, and this
often leads to conflict between the different task forces.

14. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
14
Intervention:
Design an iterative meeting approach in which meetings with the whole group involved alternate with meetings of more
specific task forces working on more detailed topics. Make sure that there is a small overlap among participants between the
different task forces. Start the process with one or more ‘whole system’ meetings so that a first version of a shared vision can
be developed by the whole group. This vision will give direction to further elaboration on the different design topics, which
are probably the meeting topics for the task forces to introduce.
When the task forces have reached a shareable level of results, then a second whole system meeting is organized so that the
different results of the different task forces can be shared. These three steps – start-up meeting with whole system, several
task force meetings, and consolidation in whole system meetings – form one iteration of the meeting process.
Mechanism:
The design of the meeting structure is based on a know-how of social constructionism.(13) New know-how and know-why
that is created within a certain group of people exists only for this group. This is a plea to discuss everything within the whole
group, but the experience with discussions in large groups isn’t that positive either.
Discussions in large groups often change into discussions with a few people involved and a lot of bystanders not being
involved. Therefore it is better to switch between large groups to consolidate knowledge and smaller, more specialized
groups for elaborating on more details. The overlap between the small groups makes sure that the know-how and know-why
of one group is shared with other groups when necessary without the different groups losing their focus.
Outcome:
The iterative meeting structure with ‘whole system’ meetings and smaller dedicated groups offers an efficient way of
working, ensuring that every decision is taken by the whole system (in the consolidation meetings) but allowing smaller
groups to prepare the decisions based on thorough reflection.
Thanks to the built-in mechanisms (overlap) to prevent small groups wandering off in irrelevant discussions or interpreting
aspects totally different than other groups, the iterative meeting structure offers a solid and goal-oriented way to involve as
many stakeholders as possible in the preparation of change projects.
Guiding principles for steering implementation and coordination
Problem in context:
Even with a shared vision, supported by the essential models of the ‘to be’ business, organization and information structure,
there is an important risk that the change project is not delivering the expected results because of incorrect decisions made
during implementation or during the first period of execution. Why? Because no clear commitments are made in the
preparatory phase on how the future change should be implemented and on how the changed organization should be guided
once the implementation has been completed.
Intervention:
Parallel to the development of the essential models, a task force should work on the development of two sets of guiding
principles. The first set of guiding principles should focus on implementation rules. These rules should guide decisions taken
during the implementation phase of the change project.
The second set of guiding principles should focus on coordination rules. These rules should guide decisions taken during the
usage of the new changed system, therefore after the implementation.
Mechanism:
The development of guiding principles, also called architecturing, works somehow like the proof of the modelling.(4,21)
During the architecturing, the people involved have to reflect on future decisions that have to be made and therefore they
have to foresee what might happen when implementing these ideas in the real world. How should a decision be taken, then,
given a certain situation at hand? Given the necessary generalization, these examples will lead to an implementation rule. In
the same way, people have to foresee what might happen once the whole change has been completed. What managerial
action will be needed in a certain situation at hand? Based on these examples, possible coordination rules can be derived.
In this way the act of architecturing obliges the participants to leave behind the pure conceptual level and reflect on the
more practical aspects of implementation and management. In doing so, it is very likely that some decisions made during the
modelling will be challenged and perhaps changed.

15. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
15
Again, the whole process of architecturing is a process of dialogue between the participants, one that helps to install the new
way of thinking needed to realize the change in the organization.
Outcome:
The intervention of architecturing will lead to the following outcomes:
- A set of accepted guiding principles that will be used during implementation
- A set of guiding principles that will help future management to realize the change
- Some new shared mental models on how to realize the change
- More support from participants for mental models that had previously been defined.
Conclusion
This article supports the need for continuous improvement of AI tools and methods. These improvements emerge from self-
reflection, evaluation and critique by scholars as well as practitioners, and new ideas that are stimulated by the openness for
knowledge and expertise from other scientific domains. Especially in the domain of EE, a promising body of knowledge that is
complementary to AI has been developed over the last two decades. The fact that one school of authors from the EE domain,
the CIAO-Network, looks at the engineering and design activities from a social constructionist perspective, just the way AI
does, makes it even more interesting.
Three improvements have been presented in this article, all three stemming from the EE research. AI projects dealing with
complex changes in enterprise domains (business, organization, and IT) will especially benefit from these improvements.
The first improvement is called ‘conceptual modelling’. Conceptual modelling stands for the creation of high-level graphical
models in which the proposed situation of an organization is represented. The modelling (= the activity) as well as the models
(= the results of the modelling) prove to have substantial value for the people involved in the change process. The models
capture the ideas that emerged during the dream and design phase and they serve as a map, a lead-out for future activities
in the destiny phase.
The second improvement is called ‘architecturing’. Architecturing stands for the creation of the architecture, which is a set of
guiding principles. The architecture will guide the decision-making process during and after the implementation of the to be
system. The architecture consists of implementation rules and operational rules. These rules help the implementation groups
to keep track of the initial standpoints that have been agreed upon. In large and long projects with, for instance, third-party
participants (IT suppliers) these rules help especially to implement the necessary subsystems correctly.
The third improvement is related to the iterative nature of design and engineering. Via a well-designed series of whole
system meetings and task force meetings more insight is created in how the dream needs to be designed.
The application of conceptual modeling, architecturing, and the iterative meeting approach in AI projects is still work in
progress as we try to evaluate these improvements in new AI-driven change projects. The first results are promising but
further research is necessary. The combination of AI and EE will continue to provide fruitful contributions for scholars as well
as practitioners who deal with organizations in transformation.
Another promising result of this case is the way certain shared mental models were shifted in order to create ‘ground’ for the
change. Further research should be organized in order to find out how and when is taken place and how we can influence
this process.
Most important references
(1) For more general information on appreciative inquiry, see the website ‘appreciative inquiry commons’.
https://appreciativeinquiry.case.edu/
(2) For more general information on enterprise engineering, see the website of the CIAO Network:
www.ciaonetwork.org
(3) The figure was taken over from the course ‘project management based on Prince2 methodology’ from NIMO, the
Netherlands.
(4) Hoogervorst, J.A.P. Enterprise Governance and Enterprise Engineering. Berlin Heidelberg, Springer 2009

16. Re-engineering the Design Phase of Appreciative Inquiry
WAIC - Johannesburg, July 8, 2015
16
(5) Calleam Consulting Ltd, ‘Why projects fail?’; http://calleam.com/WTPF/?page_id=1445; August 2014.
(6) Bloch, M., Blumberg, S. & Laartz, J. ‘Delivering large scale IT-projects on time, on budget, and on value’;
www.mckinsey.com/insights/business_technology; August 2014.
(7) Basgall, J. ‘Up to 75% of business and IT executives anticipate their software projects will fail’: www.geneca.com;
August 2014.
(8) For more general information about The Standish Group, see the website:
www.standishgroup.com/about
(9) Recommendations of the Dutch Research Committee: http://www.houseofrepresentatives.nl/news/committee-
presents-report-failures-government-ict-projects
(10) Mulder, H. & Kontakos, I. ‘Rethinking the Public Spending on ICT projects’; The Standish Group;
http://www.standishgroup.com/sample_research_files/Dutch4.pdf ; May 2015.
(11) This figure was taken over form the article in reference 10 (p. 1) with permission of the author.
(12) Example of the first Chaos report of 1994 on failure of IT projects:
http://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf
(13) Cooperrider, D. & Srivastva, S. ‘Appreciative Inquiry in Organizational Life.’ In W.A. Pasmore & R.W. Woodman (eds),
Research in Organizational Change and Development (Vol.1), pp. 3–27. Greenwich, CT:JAI Press, 1987.
(14) Cooperrider, D.L.; Whitney, D. & Stravos, J.M. Appreciative Inquiry Handbook, For Leaders of Change. Crown Custom
Publishing, 2008.
(15) Bushe, G.R. & Kassam, A.F. ‘When is Apprecative Inquiry Transformational? A Meta-Case Analysis’. Journal of
Applied Behavioral Science, 2005, 21(2): 161–181.
(16) Fry, R., Barrett, F., Seiling, J. & Whitney, D. (eds) ‘Appreciative Inquiry and Organizational Transformation: Reports
From The Field’. Westport, CT: Quorum, 2002.
(17) Dietz, J.L. Enterprise Ontology, Theory and Methodology. Springer, 2006.
(18) Hitchins, D. 2009. ‘What Are the General Principles Applicable to Systems?’ INCOSE Insight, 2008, 12(4)
(19) For more general information on the System Engineering Body of Knowledge, see the website ‘SEBoK’:
http://sebokwiki.org/wiki/Main_Page
(20) Mulder, J.B.F. ‘Rapid Enterprise Design’. Delft, Dissertatie 2006.
(21) Hoogervorst, J.A.P. ‘A Framework for Enterprise Engineering’. International Journal for Internet and Enterprise
Management, 2011, 7(1): 5–40.
(22) This figure was taken over form the book in reference 4 (p.298) with permission of the author.
(23) Kim, D.H. ‘The Link between Individual and Organizational Learning’; Sloan Management Review, 1993, 35(1): 37–
50.
(24) Van Aken, J.E. (2004). ‘Management Research on the Basis of the Design Paradigm: the Quest for Field-tested and
Grounded Technological Rules’. Journal of Management Studies, 41(2), pp. 219–246.
(25) Van Aken, J.E (2013). ‘Design Science: valid knowledge for socio-technical system design’ in Helfert, M. and
Donnellan, B. (eds) Proceedings of the European Design Science Symposium 2012. Heidelberg: Springer
(26) For more general information on ‘Board of Innovation’ see the website : http://www.boardofinnovation.com/
(27) Snoeck, M., Dedene, G., Verhelst, M. and Depuydt, A-M. ‘Object-Oriented Enterprise Modelling with MERODE’. s.l.:
Leuven University Press, 1999.