Development Arena in Project Management

From apppm
(Difference between revisions)
Jump to: navigation, search
(Introduction)
(Introduction)
Line 18: Line 18:
 
arenas - from desert sand to desert sand), in H. Fink (ed.), Arenaer - om politik &
 
arenas - from desert sand to desert sand), in H. Fink (ed.), Arenaer - om politik &
 
inscenesættelse (Arenas of politics and performance), Aarhus: Aarhus
 
inscenesættelse (Arenas of politics and performance), Aarhus: Aarhus
Universitetsforlag, pp. 7-22.</ref> <ref> Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001 </ref>
+
Universitetsforlag, pp. 7-22.</ref> <ref> Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001 </ref>.
  
 
So even though the actual mapping of the arena is static when creating it, you must understand that it is still changing and therefore dynamic.
 
So even though the actual mapping of the arena is static when creating it, you must understand that it is still changing and therefore dynamic.

Revision as of 00:25, 19 March 2022

Contents

Abstract

Today, project managers face a lot of different problems, when entering a project. These problems are often characterized by their complexity and the challenges of addressing the solution, since the solution is often defined by multiple, sometimes competing, perspectives and stakeholders. Since 1968, this kind of problem has been referred to as the so-called “wicked problem” [1]. Just as these problems are complex and entangled and difficult to navigate in, likewise are the networks by which they are surrounded and participate in. In order to navigate and manage complex problems and networks, it is beneficial for project- and program managers to use simple tools for creating structure. This is where the tool “Development Arena” by Jørgensen and Sørensen 1999 enters the picture. Using this tool, project, program, and portfolio managers perform as facilitators in the design- and management processes, where dialog and negotiations between different actors and stakeholders are key criteria for a successful project or program.

The development arena is a systematic and analytical framework that can be used as a tool to understand and analyze processes in which companies and other actors try to influence and control technologies, products, and markets [2]. Under the auspices of project management, the framework is firstly a unique tool to map the complex network of stakeholders, that the project team enters when working on a new project. Secondly, and most important of the use of the development arena is its ability to identify different stakeholders and their needs and dividing them into common grounds with their relevant activities and interests, which can help project managers to be more aware of the environment they are in and the operations that are involved.

This article will provide an insight into what defines a development arena, what elements the arena consists of, and finally how this framework can be used as a tool within management and more specifically its relation to project, program, and portfolio management.

Introduction

Before diving more into the development arena and its components, it is essential to understand how this method was developed, as this lays the foundation for the basic understanding of the method.

The concept of Develop Arena takes its most important theoretical inspiration from Bruno Latour, Michel Callon, and John Law’s community of ideas throughout the 1980s and 1990s – especially Actor-network theory [3] which was one of the outcomes. Some of us already know ANT as a theory that can be helpful in the description and understanding of complex, heterogeneous networks, in which both human and non-human actors are involved. These actors are described in the network through the relationships they are part of. Unlike actor-network theory, the concept of development arena focuses rather on how development and change can be created in the network by inviting new actors into the arena and thereby reconfiguring the network. It can be argued that the Arena concept is a response to a need for an improved theory that deals more with transition processes in project management [4].

Another important difference between the two concepts is that the Development Arena concept adds a “spatial dimension” to the theory. This dimension must be understood as a delimitation or division of the network - i.e., the network is divided into different spaces in which different actors interact [5]. We can now add another concept that better describes these boundaries and spaces in the network - namely "actor-worlds", developed by Callon in 1986. An actor-world represents different industries, organizations and stakeholders with different scientific background and is described by Jørgensen (2012), as; "An actor-world is developed around a certain set of situations and is thereby limited to what we here call a location in the space of a development arena." [6]. In other words, an actor-world only arises through actions of different actors present in the arena. If the actors do not take an active part in decision-making processes or the like, then they will be described as “spectators”, who are passive participating actors [7]. In this way, the Development Arena and the actor-worlds are strongly connected since the actor-world defines and identify different actions that take place in the network.

Finally, it is important to point out that development arenas are constantly evolving and changing, due to the continuous development in society, which the term itself also insinuates; "The word ‘arena’ comes from Arabic. It refers to sand both as the ground for activities and as the never settled character of this ground and its place - it is moving and the ground is thus eternally reshaped [8] [9].

So even though the actual mapping of the arena is static when creating it, you must understand that it is still changing and therefore dynamic.

In the following section, the development arena, and the various parts it consists of will be described in more detail.

Development Arenas and actor worlds

A development arena is generally characterized by four different parts;

  1. a number of elements such as actors, artefacts, and standards that populate the arena,
  2. one or more concerns which are shared by the arena’s actors, and which relate to a common problematization.
  3. a variety of locations for action, knowledge and visions that define the changes of this space, and
  4. a set of translations that has shaped and played out the stabilization and destabilization of relations and artefacts. (Jørgensen & Sørensen, 1999)

Elements

First, the development arena, as in actor-network theory, consists of various elements. The elements must be understood as the actors and actants (both human and non-human) that populate the arena. The elements and their actions help to define the arena and are distributed between different worlds of actors (Callon, 1986). The actor worlds represent different fields of knowledge and disciplines based on the actors involved in them. We thus see that it is the actors and their actions that define an actor world. This means that the different actor worlds problematize in different ways and that these worlds have their own individual interests. The problematizations that abound in the different actor worlds are described as the individual concerns or interests of the worlds.

Concerns

Concerns are, as mentioned earlier, the different problematizations that exist in the different actor-worlds. In the previous section, we mentioned actor worlds, as spaces where certain actions and interactions take place. The actor worlds are each supported by different problematizations of their current situation and their individual vision for future development and solutions. Concerns are thus all the individual challenges that the worlds of actors face in order to achieve their goals. These concerns are not necessarily one that the different worlds of actors share with each other. In connection with the mapping of the arena, there is also the so-called 'shared area of concern', which is the overall concern that all actors work towards - but often in different ways. But this we will get deeper into later.

Locations

In the development arena, there is no specific location where the actors are - this varies from arena to arena. In fact, there can be many different places where the actions in the arena take place. These locations depend entirely on the actors involved in the arena (Jørgensen & Sørensen, 1999).

Translation

The concept of translation originates from Michel Serres, who defines translation as a form of mediation that creates a connection between two things or views that were previously different (Elgaard Jensen, 2003). In that sense, a translation process has helped to shape the existing network and at the same time destabilize the previous one. It is this understanding of the concept of translation that must be transferred to the arena of development. In connection with project management, we, as design engineers, have an important role in being a translator / spokesperson / system builder, whereby we can bring different actors together for a common goal.

Now, one might wonder how the development arena can be actively used in management projects and not just as an expanded stakeholder network that provides a better overview. This will be discussed in the next section.

Development arena as a project management tool

Now we will discuss what our role as project managers is in the network and how we can use the development arena to actively create a desired change across the network.

A project often arises when a development project is generated internally in a company or a project team has received a task from an outside customer who wants to solve a problem they are facing. When a company creates a development project with an overall problematization, they simultaneously enter a development arena. The company has thereby, in the form of the project, created their own actor world, which, like the other actor worlds in the arena, works towards a specific concern. As Jørgensen & Sørensen also write so clearly in their text; "To manage innovation is to enter a development arena." (Jørgensen & Sørensen, 1999). When we as project managers or project teams take on a project, we want to lead innovation and development in a certain direction. However, this is easier said than done, because it requires that a lot of different nodes in the network are brought together and that the different stakeholders are interested in working towards a common concern. It is also important to point out that it is not necessarily certain that all the different stakeholders are equally interested in being part of the project. In such cases, the designteam must broaden their horizon and look at how to invite new and relevant actors into the arena.

Application

Using the development arena and its four elements; concerns, elements, locations, and translations, the project team must strive to identify where change can be enabled and how a reconstruction across relationships in the network can be made possible in the arena in order to create the desired change for the project. And now is the question – how do we do that? This is where the strategy comes into the picture.

The theory itself by Jørgensen & Sørensen 1999 does not mention any specific approach to the creation and use of a development arena. However, based on previous projects and use of the concept, I will still try to give an idea of the process that I myself, together with my design team have been through.

  1. First, the design team must identify their own role in the project. What is the overall concern that the design team seeks to impose on the other actor-worlds in the arenas?
  2. Next the actors relevant to the project must be identified and mapped in the network.
  3. Then, the different relationships need to be tied together across different actors and stakeholders. Here, a pattern usually begins to form, and one can begin to divide the small networks into actor world that thinks and act in the same way. Here it is important to be aware of whether the actors in their assigned arena are working together against the same concern. If not, it may be because the actor is part of another arena, or actively participating in several different arenas. These actors may have a special role in expanding their arena or pulling other actors together across the arenas.
  4. Lastly the design team must identify conditions and strategic actions from other actors that can re-configure the arena. This can both be actors that already exist as a part of the arena, but it can also be other actors who must be invited and translated into the network: “Companies may devise strategies to extend a local arena into the global sphere by making connections to other localities and translating them to be part of the arena. (Jørgensen & Sørensen, 1999)”

The next section provides an example where these steps are used in practice.

Casestory/Example

  • How to understand the framework and how not to
  • Challenges of using the method in practice

Reflections/Limitations

The discussion will include:

  • critically reflect on the tool/concept/theory and its application context. What can it do, what can it not do? (limitations)
  • Under what circumstances should it be used, and when not? How does it compare to the “status quo” of the standards – is it part of it, or does it extent them?
  • Discuss your article in the context of key readings / resources provided in class. Substantiate your claims with literature.
  • How does the method/theory relates to project, programs and portfolio? In which level is is operating?
  • How does the method related to people, purpose, complexity and uncertainty?

Conclusion

This article has introduced the reader to the concept of "development arena", which in short can be used to frame various complex and heterogeneous processes in the desire for a technological development and change. By using the development arena as a strategic tool, one can reconfigure the arena and the various networks towards a specific technological development. As a project team, you therefore seek to destabilize the stabilized network that we know as business as usual, by imposing on the arena a common concern that can be to the actors' own advantage.

To get a better overview of what a development arena can contribute to within project management, here is a short summary:

  1. It can provide managers to broaden their perspective in relation to the project and to get an overview of the context that the project operates in (Jørgensen & Sørensen, 1999).
  2. It estimates an idea of which stakeholders that could be potential partners but also which could be competitors and a threat to reach the goal of the project if they do not want to be part of the collaboration.
  3. Finally, the mapping of the development arena can help to understand the network that the design team operates within and in the future be a helpful tool to navigate the network when it comes to translating and inviting potential new actors into the network to create a negotiation between actors and hence a change.

Just as development arenas are only temporary due to constant change, so is the project. After the project is completed, the arena will still change even though the project has been stabilized in the arena. If we observe the development in the arena after the design team has stepped out of the arena, we will most likely, in the near future, experience that new actors will enter the arena and other actors will step out. This also symbolizes the big picture where different companies outcompete each other in the desire for growth and to keep up with the different trends in society.


  • How does Development Arena relate to project, program and portfolio management?

References

  1. Rittel, H. W., & Webber, M. M. (1992). Dilemmas in a General Theory of Planning. Washington Quarterly, 15(1), 157–168. https://doi.org/10.1080/01636609209550084
  2. Jørgensen, U., & Sørensen, O. H. (1999). Arenas of development - A space populated by actor-worlds, artefacts, and surprises. Technology Analysis and Strategic Management, 11(3), 409–429. https://doi.org/10.1080/095373299107438
  3. Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001
  4. Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001
  5. Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001
  6. Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001
  7. (Udviklingsarena – aktør verdner, Strategisk Konceptudvikling AAU, C. Clausen og S. Pedersen 2021)
  8. Fink, H. (1996), ‘Arenabegreber - mellem ørkensand & ørkensand’ (Notions of arenas - from desert sand to desert sand), in H. Fink (ed.), Arenaer - om politik & inscenesættelse (Arenas of politics and performance), Aarhus: Aarhus Universitetsforlag, pp. 7-22.
  9. Jørgensen, U. (2012). Mapping and navigating transitions - The multi-level perspective compared with arenas of development. Research Policy, 41(6), 996–1010. https://doi.org/10.1016/j.respol.2012.03.001
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox