Personal Reflection - Amarantha Clairmont

Introduction

A major part of the scenario thinking course was to build scenarios for an IT related topic. This document will describe the process that I and my group went through from selecting a topic to presenting our final scenarios to the class.

I have decided to focus on this for my discussion as it incorporates lessons from all our lectures on scenario thinking. Selecting a topic We were asked to select an IT related topic during one of our lectures. There was an entire discussion about whether the class would focus on Web 2.0 or whether each group would select its own topic. This lead to a stalemate and brought to light a major problem with democratic systems where the rules are not clearly laid down and no one has the final say. The final decision was that groups could choose their own topics. However, this would not be last of our “fights”. My group ended up tossing a coin with another group for the same topic after prior discussion proved fruitless. After losing the coin toss, my group then decided to focus on Location Based Services. In retrospect, I would have liked a bit more time to pick a topic and also more freedom i.e. not limited to IT. However, we decided to do the best with the topic we’d selected.

Creating a systems diagram

The next step in building the scenarios was to create a systems diagram that would show the linkages between all the forces that were driving location based services. In order to do this however we required very extensive research into location based services. Without this research it would have been impossible to say what the driving forces were and go any further. Neither I nor my group members were very knowledgeable about location based services, so we had to pretty much start from scratch. But after many long hours on google, we finally managed to get enough research on location based services and their relationships to the environment, politics, society, economics and technology.

During one of our classes, we were asked to get a huge sheet of paper and some post-its and draw up a systems diagram. Although this was the first time we had to actually draw one of these, Daniel had given us an example with the “War on Drugs” so we knew basically what we had to do. However, it had all seemed so simple when Daniel did it. We ended up with a very messy diagram with driving forces we hadn’t actually researched and a feeling of helplessness. It didn’t make us feel any better when the only feedback we got from Daniel was “That’s nice and messy”. Building the scenarios Half a class later, we were informed that we had to build scenarios using our very messy and confused systems diagram. I can’t speak for my group members but I remember thinking, “Oh my god, I am so f&*^%d”. At that point in time, I really had no clue how it would be possible in 2 weeks to translate the systems diagram into any sort of scenarios.

My group then met for 5 hours to discuss how to proceed. We decided to select two key uncertainties and build our scenarios from that. Selecting these key uncertainties turned out to be a lot more difficult than we thought. We argued and argued and after 2 hours still could not come up with 2 issues that everyone agreed on. This could be as well because we had split up the research into the different PESTE factors and basically every team member was responsible for researching a particular factor. This meant that each person was an expert in one particular area and therefore was able to provide lots of arguments for why something was not a key issue. In the end, we decided to have each person describe a scenario. It turned out that the particular PESTE factor had a huge influence on the scenario described by the person who was an expert in it. But that worked out in our favor because then we could use those four scenarios and use the key issues that surfaced in each of them and then combine each of the other factors in each scenario. Each person was then assigned a scenario to work out in detail.

While working on my scenario, I quickly realized that in order to make it as plausible as possible I would need to do a lot more research. Every statement that I made in the scenario would have to be based on either facts or a visible trend that would make it believable to the reader. So I spent quite a few more hours on google and ended up having to research quite a few more driving forces in detail. But it was all worth it in the end. I came up with a scenario that was believable and I actually had a clearer vision on the process of using the systems diagram to build the scenario.

Presenting the scenarios

We finally had to present our scenarios to the class. I was a bit nervous because although I was pretty confident in the plausibility of our scenarios, we hadn’t received any feedback on it during the entire process. So I wasn’t 100% certain that it was what Daniel expected. But we presented them and got the following feedback from Daniel: “Like the clear differences between the scenarios. The scenarios are much better when they are stories, not bullet points. Interesting that you position the success of this technology and services, linked to issues outside the technology itself. Do not be normative about the scenarios that you prefer “this is a sad story”, “this is the best scenario”, “this is the worst scenario” the outcome of the scenario space is independent.”

So I was pretty chuffed because he liked them especially since we put quite a lot of blood and sweat into this.

Conclusion

In general, the process of building scenarios was a real learning experience. Totally confusing at first but totally satisfying after all the pieces finally fell into place and we ended up creating scenarios that our classmates and lecturer thought were good. I am now totally into this subject and I believe it can be useful to businesses and organizations everywhere.