Category Archives: Academically speaking

Video teaching in Shanghai (from Oslo)

Class photo….

I have just finished teaching a four-day course in Strategic Technology and Innovation Management in the BI-Fudan MBA program. This is the second time I teach this way – the last time was in June, where we divided the course up in two two-day modules and everyone was on Zoom. This time about half the students were in the classroom in Shanghai, the rest on videoconference.

Last time I did this, it was an enormous amount of work. This time it was easier – not so much because of routine (though that helps) but because my strategy of building up a library of video classes has helped me reduce the workload in later courses. Normal teaching hours when videoteaching to China is from 0700-1400 Oslo time, which is 1400-2100 for the students. This has meant, for me, that I have had to be in my office (where my fast computer is) at about 0630. So how to bridge the time difference productively?

My strategy has been to have the students work on case analysis in their mornings, and to make 5-minute videos where they present their case analysis. So, when I get up at 0500, I watch their videos, grade and comment on them. Then I get to work, where we start the day with discussing the case. For some of the mornings, I have also asked them to watch videos of presentations (the airline series, in particular). I have also used other videos where the students have either watched them on their computers or on a large screen in the classroom, instead of me talking into the camera. And when I am talking into the camera myself, I have made sure that I capture sound, picture (with a good webcam) and the slides for future videos.

The upshot: I now have about 10 hours of videos which I can reuse. They are decent quality, in English, and will allow me to teach by having the students watch the video, then meet with me to discuss the content. This is much less tiring for both parties – the experience for the students is a presentation (which can be paused, speeded up, and watched when they want to) and a discussion with me, the experience for me is an interesting discussion with prepared and interested students. Having the presentation recorded allows time-shifting, and avoids all kinds of trouble with videoconferencing.

I am a very lazy person, so I have been working very hard to create a library of teaching material which will allow me to work less (or, perhaps, teach more but work the same) in the future.

We’ll see how that works. The students seem to like it. And it would not be China if it did not include a group shot with the professor…

How to do a research interview

Here is a little video I did on how to do a research interview.

30 minutes long, fairly straightforward, I now have the technology sorted that I can make videos like this fairly easy and with decent quality. Might have used a better microphone, but what the heck, it works and only took me about four hours, including writing the outline.

As usual with these things: Caveat emptor. But this approach works for me.

Outline posted below the fold.

Continue reading →

Getting dialogue online

Bank in the nineties, I facilitated a meeting with Frank Elter at a Telenor video meeting room in Oslo. There were about 8 participants, and an invited presenter: Tom Malone from MIT.

The way it was set up, we first saw a one hour long video Tom had created, where he gave a talk and showed some videos about new ways of organizing work (one of the more memorable sequences was (a shortened version of) the four-hour house video.) After seeing Tom’s video, we spent about one hour discussing some of the questions Tom had raised in the video. Then Tom came on from a video conferencing studio in Cambridge, Massachusetts, to discuss with the participants.

The interesting thing, to me, was that the participants experienced this meeting as “three hours with Tom Malone”. Tom experienced it as a one hour discussion with very interested and extremely well prepared participants.

A win-win, in other words.

I was trying for something similar yesterday, guest lecturing in Lene Pettersen‘s course at the University of Oslo, using Zoom with early entry, chat, polling and all video/audio enabled for all participants. This was the first videoconference lecture for the students and for three of my colleagues, who joined in. In preparation, the students had read some book chapters and articles and watched my video on technology evolution and disruptive innovations.

For the two hour session, I had set up this driving plan (starting at 2 pm, or 14:00 as we say over here in Europe…):

Image may contain: Espen Andersen, eyeglasses

Leading the discussion. Zoom allows you to show a virtual background, so I chose a picture of the office I would have liked to have…

14:00 – 14:15 Checking in, fiddling with the equipment and making sure everything worked. (First time for many of the users, so have the show up early so technical issues don’t eat into the teaching time.)
14:15 – 14:25 Lene introduces the class, talks about the rest of the course and turns over to Espen (we also encouraged the students to enter questions they wanted addressed in the chat during this piece)
14:25 – 14:35 Espen talking about disruption and technology-driven strategies.
14:35 – 14:55 Students into breakout rooms – discussing whether video what it would take for video and digital delivery to be a disruptive innovation for universities. (Breaking students up into 8 rooms of four participants, asking them to nominate a spokesperson to take notes and paste them into the chat when they return, and to discuss the specific question: What needs to happen for COVID-19 to cause a disruption of universities, and how would such a disruption play out?
14:55 – 15:15 Return to main room, Espen sums up a little bit, and calls on spokesperson from each group (3 out of 8 groups) based on the notes posted in the chat (which everyone can see). Espen talks about the Finn.no case and raises the next discussion question.
15:15 – 15:35 Breakout rooms, students discuss the next question: What needs to happen for DNB (Norway’s largest bank) to become a data-driven, experiment-oriented organization like Finn.no? What are the most important obstacles and how should they be dealt with?
15:35 – 15:55 Espen sums up the discussion, calling on some students based on the posts in the chat, sums up.
15:55 – 16:00 Espen hand back to Lene, who sums up. After 16:00, we stayed on with colleagues and some of the students to discuss the experience.

zoom dashboard

The dashboard as I saw it. Student names obscured.

Some reflections (some of these are rather technical, but they are notes to myself):

  • Not using Powerpoint or a shared screen is important. Running Zoom in Gallery view (I had set it up so you could see up to 49 at the same time) and having the students log in to Zoom and upload a picture gave a feeling of community. Screen and/or presentation sharing breaks the flow for everyone – When you do it in Zoom, the screen reconfigures (as it does when you come back from a breakout room) and you have to reestablish the participant panel and the chat floater. Instead, using polls and discussion questions and results communicated through the chat was easier for everyone (and way less complicated).

  • No photo description available.

    Satisfactory results, I would say.

    I used polls on three occasions: Before each discussion breakout, and in the end to ask the students what the experience was like. They were very happy about it and had good pointers on how to make it better

  • We had no performance issues and rock-steady connection the whole way through.
  • It should be noted that the program is one of the most selective in Norway and the students are highly motivated and very good. During the breakout sessions I jumped into each room to listen in on the discussion (learned that it was best to pause recording to avoid a voice saying “This session is being recorded” as I entered. The students were actively discussing in every group, with my colleagues (Bendik, Lene, and Katja) also participating. I had kept the groups to four participants, based on feedback from a session last week, where the students had been 6-7 and had issues with people speaking over each other.
  • Having a carefully written driving plan was important, but still, it was a very intense experience, I was quite exhausted afterwards. My advice on not teaching alone stands – in this case, I was the only one with experience, but that will change very fast. But I kept feeling rushed and would have liked more time, especially in the summary sections, would have liked to bring more students in to talk.
  • I did have a few breaks myself – during the breakout sessions – to go to the bathroom and replenish my coffee – but failed to allow for breaks for the students. I assume they managed to sneak out when necessary (hiding behind a still picture), but next time, I will explicitly have breaks, perhaps suggest a five minute break in the transition from main room to breakout rooms.

Conclusion: This can work very well, but I think it is important to set up each video session based on what you want to use it for: To present something, to run an exercise, to facilitate interaction. With a small student group like this, I think interaction worked very well, but it requires a lot of presentation. You have to be extremely conscious of time – I seriously think that any two-hour classroom session needs to be rescheduled to a three hour session just because the interaction is slower, and you need to have breaks.

As Winston Churchill almost said (he said a lot, didn’t he): We make our tools, and then our tools make us. We now have the tools, it will be interesting to see how the second part of this transition plays out.

Dealing with cheating

At BI Norwegian Business School, we are (naturally and way overdue, but a virus crisis helps) moving all exams to digital. This means a lot of changes for people who have not done that before. One particular anxiety is cheating – normally not a problem in the subjects I teach (case- and problem oriented, master/executive, small classes) but certainly is an issue in large classes at the bachelor level, where many answers are easily found online, the students are many, and the subjects introductory in nature.

Here are some strategies to deal with this:

  • Have an academic honesty policy and have the students sign it as part of the exam. This to make them aware of they risk if they cheat.
  • Keep the exam time short – three hours at the max – and deliberately ask more questions than usual. This makes for less time for cheating (by collaborating) because collaboration takes time. It also means introducing more differentiation between the students – if just a few students manage to answer all questions, those are the A candidates. Obviously, you need to adjust the grade scale somewhat (you can’t expect all to answer everything) and there is an issue of awarding students that are good at taking exams at the expense of deep learning, but that is the way of all exams.
  • Don’t ask the obvious questions, especially not those asked on previous exams. Sorry, no reuse. Or perhaps a little bit (it is a tiring time.)
  • Tell the students that all answers will be subjected to an automated plagiarism check. Whether this is true or not, does not matter – plagiarism checkers are somewhat unreliable, have many false positives, and require a lot of afterwork – but just the threat will eliminate much cheating. (Personally, I look for cleverly crafted answers and Google them, amazing what shows up…).
  • Tell the students that after the written exam, they can be called in for an oral exam where they will need to show how they got their answers (if it is a single-answer, mathematically oriented course) or answer more detailed questions (if it is a more analysis- or literature oriented course). Who gets called in (via videoconference) will be partially random and partially based on suspicion. Failing the orals results in failing the course.
  • When you write the questions: If applicable, Google them, look at the most common results, and deliberately reshape the questions so that the answer is not one of those.
  • Use an example for the students to discuss/calculate, preferably one that is fresh from a news source or from a deliberately obscure academic article they have not seen before.
  • Consider giving sub-groups of students different numbers to work from – either automatically (different questions allocated through the exam system) or by having questions like “If your student ID ends in an even number (0,2,4,6,8) answer question 2a, otherwise answer question 2b” (use the student ID, not “birthday in January, February, March…” as this will be the only marker you have.) The questions may have the same problem, but with small, unimportant differences such as names, coefficients or others. This makes it much harder to collaborate for the students. (If you do multiple questions in an electronic context, I assume a number of the tools will have functionality for changing the order of the questions – it would, frankly, astonish me if they did not – but I don’t use multiple choice myself, so I don’t know.
  • Consider telling the students they will all get different problems (as discussed above) but not doing it. It still will prevent a lot of cheating simply because the students believe they all have different problems and act accordingly.
  • If you have essay questions, ask the students to pick a portion of them and answer them. I do this on all my exams anyway – give the students 6 questions with short (150 words) answers and ask them to pick 4 and answer only those, and give them 2 or 3 longer questions (400 words or so) and ask them to answer only one. (Make it clear that answering them all will result in only the first answered will be considered.) Again, this makes cheating harder.

Lastly: You can’t eliminate cheating in regular, physical exams, so don’t think you can do it in online exams. But you certainly can increase the disincentives to do so, and that is the most you can hope for.

Department for future ideas
I have always wanted to use machine learning for grading exams. At BI, we have some exams with 6000 candidates writing textual answers. Grading this surely must constitute cruel and unusual punishment. With my eminent colleague Chandler Johnson I tried to start a project where we would have graders grade 1000 of these exams, then use text recognition and other tools, build an ML model and use that to grade the rest. Worth an experiment, surely. The project (like many other ideas) never took off, largely because of difficulties of getting the data, but perhaps this situation will make it possible.

And that would be a good thing…

A teaching video – with some reflections

Last Thursday, I was supposed to teach a class on technology strategy for a bachelor program at the University of Oslo. That class has been delayed for a week and (obviously) moved online. I thought about doing it video conference, but why not make a video, ask the students to see it before class? Then I can run the class interactively, discussing the readings and the video rather than spending my time talking into a screen. Recording a video is more work, but the result is reusable in other contexts, which is why I did it in English, not Norwegian. The result is here:

To my teaching colleagues: The stuff in the middle is probably not interesting – see the first two and the last five minutes for pointers to teaching and video editing.

For the rest, here is a short table of contents (with approximate time stamps):

  • 0:00 – 2:00 Intro, some details about recording the video etc.
  • 2:00 – 27:30 Why technology evolution is important, and an overview of technology innovation/evolution processes
    • 6:00 – 9:45 Standard engineering
    • 9:45 – 12:50 Invention
    • 12:50 – 15:50 Structural deepening
    • 15:50 – 17:00  Emerging (general) technology
      • 17:00 – 19:45 Substitution
      • 19:45 – 25:00 Expansion, including dominant design
      • 25:00 – 27:30 Structuration
  • 27:30 – 31:30 Architectural innovation (technology phases)
  • 31:30 –  31:45 BREAK! (Stop the video and get some coffee…)
  • 31:45 – 49:40 Disruption
    • 31:45 – 38:05 Introduction and theory
    • 38:05 – 44:00 Excavator example
    • 44:00 – 46:00 Hairdresser example
    • 47:00 – 47:35 Characteristics of disruptive innovations
    • 47:35 – 49:40 Defensive strategies
  • 49:40 – 53:00 Things take time – production and teaching…
  • 53:00 – 54:30 Fun stuff

This is not the first time I have recorded videos, by any means, but it is the first time I have created one for “serious” use, where I try to edit it to be reasonably professional. Some reflections on the process:

  • This is a talk I have given many times, so I did not need to prepare the content much – mainly select some slides. for a normal course, I would use two-three hours to go through the first 30 minutes of this video – I use much deeper examples and interact with the students, have them come up with other examples and so on. The disruption part typically takes 1-2 hours, plus at least one hour on a specific case (such as the steel production). Now the format forces me into straight presentation, as well as a lot of simplification – perhaps too much. I aim to focus on some specifics in the discussion with the students.
  • I find that I say lots of things wrong, skip some important points, forget to put emphasis on other points. That is irritating, but this is straight recording, not a documentary, where I would storyboard things, film everything in short snippets, use videos more, and think about every second. I wanted to do this quickly, and then I just have to learn not to be irritated at small details.
  • That being said, this is a major time sink. The video is about 55 minutes long. Recording took about two hours (including a lot of fiddling with equipment and a couple of breaks). Editing the first 30 minutes of the  video took two hours, another hour and a half for the disruption part (mainly because by then I was tired, said a number of unnecessary things that I had to remove.)
  • Using the iPad to be able to draw turned out not to be very helpful in this case, it complicated things quite a bit. Apple’s SideCar is still a bit unpredictable, and for changing the slides or the little drawing on the slides I did, a mouse would have been enough.
  • Having my daughter as audience helps, until I have trained myself to look constantly into the camera. Taping a picture of her or another family member to the camera would probably work almost as well, with practice. (She has heard all my stories before…)
  • When recording with a smartphone, put it in flight mode so you don’t get phone calls while recording (as I did.) Incidentally, there are apps out there that allow you to use the iPhone as a camera connected to the PC with a cable, but I have not tested them. It is easy to transfer the video with AirPlay, anyway.
  • The sound is recorded in two microphones (the iPhone and a Røde wireless mic.) I found that it got “fatter” if I used both the tracks, so I did that, but it does sometime screw up the preview function in Camtasia (though not the finished product). That would also have captured both my voice and my daughter’s (though she did not ask any questions during the recording, except on the outtakes.)
  • One great aspect of recording a video is that you can fix errors – just pause and repeat whatever you were going to say, and the cut it in editing. I also used video overlays to correct errors in some slides, and annotations to correct when I said anything wrong (such as repeatedly saying “functional deepening” instead of “structural deepening”.) It does take, time, however…

My excellent colleague Ragnvald Sannes pointed out that this is indicative of how teaching will work in the future, from a work (and remuneration) perspective. We will spend much more time making the content, and less time giving it. This, at the very least, means that teachers can no longer be paid based on the number of hours spent teaching – or that we need to redefine what teaching means…

Five tips for better video teaching

In these viral times, a lot of universities will need to switch to video teaching, and for many teachers, this is a new experience. Here is a short (and fast) video I made with five – non-technical – tips for better video conferencing and teaching.

To sum it up:

1. Sound is more important than picture.
2. Look into the camera!
3. Don’t make the obvious mistakes: Background, lighting, and clothing.
4. Be lively! The medium consumes energy, you need to compensate.
5. Get to know the tools.

Good luck!

Clay in memoriam

IMG_2252Clayton M. Christensen, 1952-2020 (WSJ, NYT)

You think of many things when a friend dies.

When I was about 16, I went into the forest with some friends to watch the 50-km cross-country race at the Holmenkollen ski festival. One of the stars that year was Juha Mieto, an enormous (more than two meter) Finn who had to be careful with his strength, as he tended to break his ski poles. One of my friends decided to try to keep up with Mieto, just to see how long he could do it. My friend was a reasonably good skier, and managed to keep up for about 300 meters. Mieto, of course, kept going for 50 kilometers.

Sometimes I had the same feeling when interacting with Clay. Not because he was an imposing giant in the physical sense, but because of his incredible work capacity and ability to follow things through. I felt I could keep up with him for a while, enjoy it – and he would then go on, endlessly doing so much more than I was capable of. Clay was so many things: A famous scholar, a life-changing teacher, an adviser, a church leader, husband, father of five – and seemed to do it, if not effortlessly, at least conclusively, with a degree of self-discipline hard to imagine. For me, he was a friend.

We met as students at Harvard Business School in 1990 (he started one year before me), in an Organizational Psychology course with 140 papers on the reading list. Doing that alone just wasn’t possible, so we formed study groups of 5-6 people, writing summaries of papers for each other and occasionally meeting to discuss them before class. I still have the notes. Clay was different in that he added vry observations to his summaries, showing an ability to reflect and a degree of irreverence that wasn’t much visible elsewhere.

We became friends of a sort, spending much time studying in the cramped basement of the doctoral student house at HBS. Like me, Clay had a family and biked to work, but he would be in much earlier than me. After lunch, he would take a nap in his carrel, lying on the floor with his feet on the office chair. I remember him coming to school one day, shaking his head: His son had dunked a basketball – and he was twelve years old.

Clay’s research was on the evolution of technologies, specifically on generations of hard disks, a project that eventually became the The Innovator’s Dilemma. I got to see how his theory developed through seminars, papers and discussions, including some blind alleys. I was in a different field, but was more interested in technology than most of my peers and think I was one of the people outside his department who early on thought his work interesting and understood the implications, though I do not think I contributed in any meaningful fashion aside from encouragement.

Clay graduated in record time and became a professor, and I needed a friendly face on my thesis committee – so I asked him. Eventually I graduated and moved back to Norway, but kept my consulting job in Boston and travelled there quite often. Clay became famous, and, cashing in a favor, I invited him over to Oslo to speak at BI Norwegian Business School. He came in January, on his way home from the World Economic Forum in Davos. It was cold and dark and he gave a lecture the audience referred to as “life-changing”. I asked him if there was anything he wanted to do in Norway. There was one town – Drammen – he had always wanted to visit, since his great grandfather had been repeatedly arrested there for being a Mormon missionary. (To put this in context: Coming to Oslo and wanting to see Drammen is equal to landing in New York and asking to see New Jersey.) So we went there, in my colleague Øystein Fjeldstad’s car. It was foggy and bitterly cold and Drammen was every bit as dreary as you can imagine. We went back to Oslo, dropped off Clay at the luxurious hotel we had booked for him and urged him to try the gourmet restaurant. When his expenses came in, it turned out he had gone to McDonald’s. Our CFO solemnly informed me that I was free to invite this guy anytime I wanted.

In 2007 I thought I had come up with a way to redeem myself and my country and arranged a “Disruptive Cruise” – a weeklong trip on Hurtigruten with Clay’s family. The idea was to create a nice experience for execs from interesting companies and for Clay to have a great vacation with his family and some good discussions. Economically it just did not work – a combination of an economic downturn, Norwegian executives’ unwillingness to spend a week away during what for them was summer vacation, and my listless performance as a salesperson meant that the whole thing became a highly personal, rather low-budget thing – but Clay and his large family liked it. Clay spent much of the time typing on his computer, but found time to see the midnight sun from the ship’s hot tub, and experience both the bridge and the machine room (where passengers are not normally allowed), in addition, of course, to the coasts and mountains of western and northern Norway.

IMG_2679

My partner in crime for this trip was Trond Østgaard, who was chairman of the Hurtigruten Appreciation Society as well as a prominent citizen of Drammen. Hence, Clay and family could visit Drammen in style this time, being shown around the old City Hall (where his great-grandfather had been imprisoned) by the Vice-Mayor and have his photograph taken next to the portrait of the sheriff who had done the arrests.

We stayed friends, though we did not spend much time together. I would occasionally pop into his office at HBS, where we swapped anecdotes and talked about technology. I tended to come up with examples, he would think about how they would play out. We would discuss processor modularity, telecommunications competition, hospital management and (a lot) the coming disruption of business schools. Again, I don’t think I contributed much to his research, aside from coming up with a few examples and suggesting ways to communicate things (not that Clay needed any help there). Perhaps my main contribution was to introduce him to Øystein Fjeldstad (the third guy in the picture on top here), whose “value configurations” made it into a couple of Clay’s articles and books. The way to talk to Clay was not to explain things, but to state examples and wait (not long) for him to work out the consequences himself.

I would occasionally see him when he swung by Oslo for a talk, once or twice being the MC myself. But Clay was incredibly busy with audiences constantly demanding his disruption stories (“I am becoming my own theory here,” he would comment, ruefully), I stopped travelling so much to the US, so we saw less of each other. In one sense we were very different: Clay was deeply religious, I am an ateist, and I could never reconcile his scientific mind with his religious views. We talked about it on a few occasions, agreeing to disagree. Mostly, we would talk about our families and our job experiences, stepping back and seeing what it all meant. For all his fame, Clay was invariably down to earth, a great support for me when two of my children became seriously ill – and I believe I played at least a small part like that for him, too. Clay’s health was not good – diabetes, cancer, heart problems and a stroke that made it difficult for him to form words, but he never complained and kept working – a bit much if you ask me (and his family).

I learned a lot from Clay, and he (politely) said he had learned from me. I learned about how to think critically and clearly, and how to be principled and persistent when you believe in your analysis. In my career this has helped me understand that I should build my career on what I am good at and what I can and want to do, not what the organisations I work for see as the correct career path. His way of thinking has enabled me on a number of occasions to listen to what job the customer want done – not a very intellectual concept, but one that is surprisingly effective – and apply that both to offerings I have developed myself and to my analyses of various companies and industries. In my teaching, he has influenced me enormously – when I finally felt secure enough to teach technology in a business school through cases, and cases only, it was his course I started with.

I keep judging my ideas up against what he would have thought. Just a few days ago, I discussed an idea for a paper with Chandler Johnson, a colleague at BI: Is machine learning disruptive to traditional management research (or traditional research in general)? We swapped some ideas back and forth, and I suggested we type it up as a short outline and send it off to Clay to hear what he thought about it.

And now he is no more.

In addition to his management books, Clay wrote and spoke about how to evaluate your life – and said that in posterity, he would not be judged for being a famous business school professor, but for how he had helped other people.

I don’t believe in an afterlife, but I do think that as a person, you exist as long as somebody remembers you, how you were, and what you did for them. For me, at least, Clay will exist for the rest of my life, and, I am sure, for many of my students.

And my thoughts go to Christine, and to her and Clay’s children and grandchildren, who have lost infinitely more than the rest of us have and for whom that form of remembrance is a small consolation – but hopefully, a consolation nevertheless.

How to write a teaching case

Since I sometimes give classes on how to do case teaching and have written a book on the subject with Bill Schiano, I am sometimes asked how to write a teaching case. The following blog post is a quick tips & tricks collection (essentially an update of this post.)

Why are you writing this case?
First and foremost: Cases are written for a teaching purpose – and to write a teaching case, you need to have a teaching objective in mind. It is not enough to have an interesting company. Even the best company story needs to have a pedagogical point, a theory or dilemma to illustrate. So don’t write a teaching case just because you happen to know someone in a really interesting company – it does need to be a good story, but it also need to have a purpose.

The standard outline
Cases – particularly the standard HBS case – follow an outline that can seem rather trite, but which is very effective. It is something like this:

  • 0.5 page: Intro: The protagonist is introduced, typically pondering a question of some importance. The idea is to tell the students from which perspective the case is written, to set the scene – and that is all there is to it.
  • 1 – 1.5 pages: Description of the company – not the whole history, but the relevant details, explaining what the company is doing, how they make their money. Most companies are to a very large degree formed by their history, so the relevant parts need to be told.
  • 1 page: Industry. Companies exist within a context, and you need to set it. Explain the industry, its evolution, and the company’s position within it. Do it succinctly, but leave more detail in than what is strictly necessary.
  • 1 – 5 pages: Specific issue. This is the meat of the case, the issue at hand, the story to ponder. Make sure you tell it logically and cooly, not leaving anything out, but also conveying the complexity of the situation.
  • 0.5 page: Conclusion, typically with the protagonist wondering what to do, often with some sort of event (board meeting, etc.) where he or she has to present a solution to the problem.

Most cases are just that – one case. You can have a B case and even a C case, but keep them short, since they have to be handed out and read in class. The B case should explain what the company did and perhaps introduce a new problem, the C case, if necessary, should bring some sort of closure, explaining what eventually happened. In my experience, it is very hard to get discussion after a C case – the students become exhausted. As a novice case writer, especially if you are writing about a company with a long history, it can be tempting to create a long string of small cases, but in practice this seldom works well – for one thing, it forces the discussion into a very predictable path.

The no-nos
No theory. A good case should be a description of an interesting situation, frequently a decision point – and nothing else. This means that there should be no theory and no discussion of the case in the case itself. Save that for the teaching note, or write a separate academic article about it. Not only does this make the case more realistic, it also means it can be used for more purposes than the one initially envisioned. This can be quite challenging for the traditional academic writer – but it is actually good practice to only present the facts (though, of course, which facts you choose to present constitute a discussion of sorts).

No hero, no villain. When teaching students how to analyze a case, I always start by saying that for most business situations, if is useful to begin the analysis with the assumption that people are not stupid and not evil. Consequently, when you write a case, make sure it has no heroes and no villains. If a case has a clear-cut hero or villain, it is a sign that you have not done enough research. Write things so that the students can see the issue from many perspectives.

No judgement. I frequently find, when reading prospective teaching cases, especially if written with the help of the communications department of a company, that judgements tend to be embedded in the text itself, though it is supposed to be as neutral and purely descriptive as possible. Do not write that a company is “leading” – instead, describe what they do, perhaps adding a bit of industry numbers for comparison, and let the decision about how leading the company is be up to the student. Do not write “Smith was a highly accomplished manager, leading a successful technology implementation.” Instead, write “Smith, at 29, was promoted to be the youngest vice president in company history after conceiving and overseeing the introduction of the first machine learning platform in the industry.”

No consultingese. Be very careful of weasel terms – is the company embarking on a strategic alliance or merely collaborating with another company for a specific purpose? (As a friend of mine said: “I buy all my socks at Marks and Spencer. That does not mean I have a strategic alliance with them.”) Avoid terms that are not well defined, and be precise in your language. Remember, a teaching case has the longest legs when it describes a human situation (since humans change slowly) and to not tie the narrative to specifically to a technology or a situation. (See the example of Fabritek below.) I quite often use old technology cases, and when the students complain, ask them to take out a pen and change the dates mentioned to current times, update the technology capabilities accordingly – and see if anything else changes.

Dramatic structure
A really well written case has dramatic structure – there is a beginning, a middle that builds up the story, and a really compelling issue at the end. The best cases are almost like a detective story, where you have to dig deep into the analysis to find surprising and sometimes counter-intuitive conclusions. One example of a “detective story” case is Fabritek 1992*, a very old (first published 1969, rewritten by Jan Hammond) case about a quality control issue in a small mechanical workshop. (Hat tip to Robert D. Austin, eminent case teacher, for making me aware of this case and showing me how to teach it.) The case is excellent because it starts with the company (strategic level), proceeds to describe a new situation and a new process (organizational or business logic level) and then introduces the problem (operational level.) Analyzing the operational details leads to one conclusion, which then can be discussed in terms of the organization and its business logic, which can then be placed into a strategic context. The case is excellent because it allows links between these levels – and also teaches the students that the devil indeed resides in the details, and that you as a manager better be very close to how the business you are leading works and makes money.

iPremier-front-pageA second case which shows quality and innovation is iPremier, written by Robert D. Austin and Jeremy C. Short, the first and only graphic novel (cartoon) case I am aware of. The story is about a small online gift company being attacked by hackers, exposing glaring gaps in their security procedures and forcing managers at various levels to make some really hard decisions. The graphic format is excellent in making the various characters real (though they, on average, tend to be way too good-looking for a normal business situation), illustrates technical issues in a way that is very understandable even by non-technology students, and has a cracking good storyline with a B and a C case. I like to introduce a few technical cases in my courses because, well, I don’t think there is enough technology in business schools, and this cases answers very well because it illustrates that certain technical decisions very much require top management attention – ignore (or mindlessly delegate) technology understanding and responsibility at your peril. The graphic format also provides a welcome break from the standard case verbiage, which can be a trifle dour on occasion.

Details, details, details!
Research cases – the kind that is published in refereed journals – tend to be written from a very specific viewpoint, and only facts pertaining to that perspective is included, often in a very abstract format. A teaching case is the direct opposite: It needs lots of details, frequently made available as exhibits (graphs, pictures, documents, tables, etc.) placed at the end, after the main text. A teaching case writer, when visiting a company to write about it, needs to notice the small details, much like a really good journalist does. I tell my students that they should prepare each case so well that they feel like they have worked in the case company – and to allow them to do that, you need to provide the operational details necessary. (Incidentally, having more details than strictly necessary has the added benefit of making the case realistic – in the real world, you have to decide what is important and what is not.)

Doing it – and reading about it.
grandongillI am not aware of many books about how to write a good teaching case, with one exception: Grandon Gill (pictured), professor at University of South Florida and an excellent case teacher, has written a book called Informing with the case method, which is available for free download in PDF, MOBI and EPUB format from his web site. It has lots of details, tips and tricks, not just about case writing, but also about case teaching and course planning. (For the latter, of course, I am duty bound to recommend Bill Schiano’s and my book Teaching with Cases: A Practical Guide.)

Last but definitely not least: Don’t underestimate how much work writing a proper business case is. Getting the details right, describing the dramatis personae, and making the storyline compelling is quite a challenge, in many dimensions different from the traditional academic article. On the other hand, should you get it right, you will have a very effective teaching tool for many years to come.

Good luck!

Summer reading for the diligent digital technology student

eivindgEivind Grønlund, one of my students at the Informatics: Digital Business and Leadership program at the University of Oslo sent me an email asking about what to read during the summer to prepare for the fall.

Well, I don’t believe in reading textbooks in the summer, I believe in reading things that will excite you and make you think about what you are doing and slightly derail you in a way that will make you a more interesting person when Fall comes. In other words, read whatever you want.

That being said, the students at DigØk have two business courses next year – one on organization and leadership, one on technology evolution and strategy. Both will have a a focus on basics, with a flavor of high tech and the software business. What can you read to understand that, without having to dig into textbooks or books that may be on the syllabus, like Leading Digital, The Innovator’s Solution, Enterprise Architecture as Strategy, or Information Rules?

Here are four books that are entertaining and wise and will give you an understanding of how humans and technology interact and at least some of the difficulties you will run into trying to manage them – but in a non-schoolbook context. Just the thing for the beach, the mountain-top, the sailboat.

  • 816Neal Stephenson: Cryptonomicon. The ultimate nerd novel. A technology management friend of mine re-reads this book every summer. It involves history, magic reality (the character of Enoch Root), humor, startup lore, encryption and, well, fun. Several stories in one: About a group of nerds (main protagonist: Randy Waterhouse) doing a startup in Manila and other places 1999, his grandfather, Randall P. Waterhouse, running cryptographic warfare against the Germans and Japanese during WWII, and how the stories gradually intersect and come together towards the end. The gallery of characters is hilarious and fascinating, and you can really learn something about startups, nerd culture, programming, cryptography and history along the way. Highly recommended.
  • 7090Tracy Kidder: The Soul of a New Machine. This 1981 book describes the development process of a Data General minicomputer as a deep case study of the people in it. It could just as well have been written about any really advanced technology project today – the characters, the challenges, the little subcultures that develop within a highly focused team stretching the boundaries for what is possible. One of the best case studies ever written. If you want to understand how advanced technology gets made, this is it.
  • 24113Douglas Hofstadter: Gödel, Escher, Bach. This book (aficionados just call it GEB) was recommended to me by one of my professors in 1983, and is responsible for me wanting to be in academia and have time and occasion to read books such as this one. It is also one of the reasons I think The Matrix is a really crap movie – Hofstadter said it all before, and I figured out the plot almost at once and thought the whole thing a tiresome copycat. Hofstader writes about patterns, abstractions, the concept of meta-phenomena, but mostly the book is about self-referencing systems, but as with any good book that makes you think it is breath-taking in what it covers, pulling together music, art, philosophy and computer science (including a bit on encryption, always a favorite) and history. Not for the faint-hearted, but as Erling Iversen, my old boss and an extremely well-read man, said: You can divide techies into two kinds: Those who have read Hofstadter, and those who haven’t.
  • 34017076Tim O’Reilly: WTF? What’s the Future and Why It’s Up to Us. Tim is the founder of O’Reilly and Associates (the premier source of hands-on tech books for me) and has been a ringsider and a participant in anything Internet and digital tech since the nineties. This fairly recent book provides a good overview of the major evolutions and battles during the last 10-15 years and is a great catcher-upper for the young person who has not been been part of the revolution (so far.)

And with that – have a great summer!

The history of software engineering

grady_booch2c_chm_2011_2_cropped

The History of Software Engineering
an ACM webinar presentation by
ACM Fellow Grady Booch, Chief Scientist for Software Engineering, IBM Software
(PDF slides here.)

Note: These are notes taken while listening to this webinar. Errors, misunderstandings and misses aplenty…

(This is one of the perks of being a member of ACM – listening to legends of the industry talking about how it got started…)

Trust is fundamental – and we trust engineering because of licensing and certification. This is not true of software systems – and that leads us to software engineering. Checks and balances important – Hammurabi code of buildings, for instance. First licensed engineer was Charles Bellamy, in Wyoming, in 1907, largely because of former failures of bridges, boilers, dams, etc.

Systems engineering dates back to Bell labs, early 1940s, during WWII. In some states you can declare yourself a software engineer, in others licensing is required, perhaps because the industry is young. Computers were, in the beginning, human (mostly women). Stibitz coined digital around 1942, Tukey coined software in 1952. 1968-69 conference on software engineering coined the term, but CACM letter by Anthony Oettinger used the term in 1966, but the term was used before that (“systems software engineering”), most probably originated by Margaret Hamilton in 1963, working for Draper Labs.

Programming – art or science? Hopper, Dijkstra, Knuth, sees them as practical art, art, etc. Parnas distinguished between computer science and software engineering. Booch sees it as dealing with forces that are apparent when designing and building software systems. Good engineering based on discovery, invention, and implementation – and this has been the pattern of software engineering – dance between science and implementation.

Lovelace first programmer, algorithmic development. Boole and boolean algebra, implementing raw logic as “laws of thought”.

First computers were low cost assistants to astronomers, establishing rigorous processes for acting on data (Annie Cannon, Henrietta Leavitt.) Scaling of problems and automation towards the end of the 1800s – rows of (human) computers in a pipeline architecture. The Gilbreths created process charts (1921). Edith Clarke (1921) wrote about the process of programming. Mechanisation with punch cards (Gertrude Blanch, human computing, 1938; J Presper Eckert on punch car methods (1940), first methodology with pattern languages.

Digital methods coming – Stibitz, Von Neumann, Aitken, Goldstein, Grace Hopper with machine-independent programming in 1952, devising languages and independent algorithms. Colossus and Turing, Tommy Flowers on programmable computation, Dotthy du Boisson with workflow (primary operator of Colossus), Konrad Zuse on high order languages, first general purpose stored programs computer. ENIAC with plugboard programming, dominated by women, (Antonelli, Snyder, Spence, Teitelbaum, Wescoff). Towards the end of the war: Kilburn real-time (1948), Wilson and Gill subroutines (1949), Eckert and Mauchly with software as a thing of itself (1949). John Bacchus with imperative programming (Fortran, 1946), Goldstein and von Neumann flowcharts (1947). Commercial computers – Leo for a tea company in England. John Pinkerton creating operating system, Hoper with ALGOL and COBOL, reuse (Bener, Sammet). SAGE system important, command and control – Jay Forrester and Whirlwind 1951, Bob Evans (Sage, 1957), Strachey time sharing 1959, St Johnson with the first programming services company (1959).

Software crisis – not enough programmers around, machines more expensive than the humans, priesthood of programming, carry programs over and get results, batch. Fred Brooks on project management (1964), Constantin on modular programming (1968), Dijkstra on structured programming (1969). Formal systems (Hoare and Floyd) and provable programs; object orientation (Dahl and Nygaard, 1967). Main programming problem was complexity and productivity, hence software engineering (Margaret Hamilton) arguing that process should be managed.

Royce and the waterfall method (1970), Wirth on stepwise refinement, Parnas on information hiding, Liskov on abstract data types, Chen on entity-relationship modelling. First SW engineering methods: Ross, Constantine, Yourdon, Jackson, Demarco. Fagin on software inspection, Backus on functional programming, Lamport on distributed computing. Microcomputers made computing cheap – second generation of SW engineering: UML (Booch 1986), Rumbaugh, Jacobsen on use cases, standardization on UML in 1997, open source. Mellor, Yourdon, Worfs-Brock, Coad, Boehm, Basils, Cox, Mills, Humphrey (CMM), James Martin and John Zachman from the business side. Software engineering becomes a discipline with associations. Don Knuth (literate programming), Stallman on free software, Cooper on visual programming (visual basic).

Arpanet and Internet changed things again: Sutherland and SCRUM, Beck on eXtreme prorgamming, Fowler and refactoring, Royce on Rational Unified Process. Software architecture (Kruchten etc.), Reed Hastings (configuration management), Raymond on open source, Kaznik on outsourcing (first major contract between GE and India).

Mobile devices changed things again – Torvalds and git, Coplien and organiational patterns, Wing and computational thinking, Spolsky and stackoverflow, Robert Martin and clean code (2008). Consolidation into cloud: Shafer and Debois on devops (2008), context becoming important. Brad Cox and componentized structures, service-oriented architectures and APIs, Jeff Dean and platform computing, Jeff Bezos.

And here we are today: Ambient computing, systems are everywhere and surround us. Software-intensive systems are used all the time, trusted, and there we are. Computer science focused on physics and algorithms, software engineering on process, architecture, economics, organisation, HCI. SWEBOK first 2004, latest 2014, codification.

Mathematical -> Symbolic -> Personal -> Distributed & Connected -> Imagined Realities

Fundamentals -> Complexity -> HCI -> Scale -> Ethics and morals

Scale is important – risk and cost increases with size. Most SW development is like engineering a city, you have to change things in the presence of things that you can’t change and cannot change. AI changes things again – symbolic approaches and connectionist approaches, such as Deepmind. Still a lot we don’t know what to do – such as architecture for AI, little rigorous specification and testing. Orchestration of AI will change how we look at systems, teaching systems rather than programming them.

Fundamentals always apply: Abstraction, separation, responsibilities, simplicity. Process is iterative, incremental, continuous releases. Future: Orchestrating, architecture, edge/cloud, scale in the presence of untrusted components, dealing with the general product.

“Software is the invisible writing that whispers the stories of possibility to our hardware…” Software engineering allows us to build systems that are trusted.

Sources: https://twitter.com/Grady_Booch, https://computingthehumanexperience.com/

Neural networks – explained

As mentioned here a few times, I teach an executive course called Analytics for strategic management, as well as a short program (three days) called Decisions from Data: Driving an Organization on Analytics. We have just finished the first version of both of these courses, and it has been a very enjoyable experience. The students (in both courses) have been interested and keen to learn, bringing relevant and interesting problems to the table, and we have managed do what it said on the tin (I think) – make them better consumers of analytics, capable of having a conversation with the analytics team, employing the right vocabulary and being able to ask more intelligent questions.

Of course, programs of this type does not allow you do dive deep into how things work, though we have been able to demonstrate MySQL, Python and DataRobot, and also give the students an understanding of how rapidly these things are evolving. We have talked about deep learning, for instance, but not how it works.

But that is easy to fix – almost everything about machine learning is available on Youtube and in other web channels, once you are into a little bit of the language. For instance, to understand how deep learning works, you can check out a series of videos from Grant Sanderson, who produces very good educational videos on the web site 3 blue one brown.

(There are follow-up videos: Chapter 2, Chapter 3, and Chapter 3 (formal calculus appendix). This Youtube channel has a lot of other math-related videos, too, including a great explanation of how Bitcoin works, which I’ll have to get into at some points, since I keep being asked why I don’t invest in Bitcoin all the time.)

Of course, you have to be rather interested to dive into this, and it certainly is not required read for an executive who only wants to be able to talk intelligently to the analytics team. But it is important (and a bit reassuring) to note the mechanisms employed: Breaking a very complex problem up into smaller problems, breaking those up into even smaller problems. solving the small problems by programming, then stepping back up. For those of you with high school math: It really isn’t that complicated. Just complicated in layers.

And it is good to know that all this advanced AI stuff really is rather basic math. Just applied in an increasingly complex way, really fast.

A tour de Fry of technology evolution

There are many things to say about Stephen Fry, but enough is to show this video, filmed at Nokia Bell Labs, explaining, amongst other things, the origin of microchips, the power of exponential growth, the adventure and consequences of performance and functionality evolution. I am beginning to think that “the apogee, the acme, the summit of human intelligence” might actually be Stephen himself:

(Of course, the most impressive feat is his easy banter on hard questions after the talk itself. Quotes like: “[and] who is to program any kind of moral [into computers ]… If [the computer] dives into the data lake and learns to swim, which is essentially what machine learning is, it’s just diving in and learning to swim, it may pick up some very unpleasant sewage.”)

Big Data and analytics – briefly

DFDDODData and data analytics is becoming more and more important for companies and organizations. Are you wondering what data and data science might do for your company? Welcome to a three-day ESP (Executive Short Program) called Decisions from Data: Driving an Organization with Analytics. It will take place at BI Norwegian Business School from December 5-7 this year. The short course is an offshoot from our very popular executive programs Analytics for Strategic Management, which are fully booked. (Check this list (Norwegian) for a sense of what those students are doing.)

Decisions from Data is aimed at managers who are curious about Big Data and data science and wants an introduction and an overview, without having to take a full course. We will talk about and show various forms of data analysis, discuss the most important obstacles to becoming a data driven organization and how to deal with data scientists, and, of course, give lots of examples of how to compete with analytics. The course will not be tech heavy, but we will look at and touch a few tools, just to get an idea of what we are asking those data scientists to do.

The whole thing will be in English, because, well, the (in my humble opinion) best people we have on this (Chandler Johnson og Alessandra Luzzi) are from the USA and Italy, respectively. As for myself, I tag along as best I can…

Welcome to the data revolution – it start’s here!

After Moore: Landauer

Very interesting blog by the very readable Ted: Is computing in reverse the next big thing?

As Moore’s law continues, it will reach certain physical limitations, such as electrons behaving less dependently the thinner the conduits become (think individual electrons instead of a more predictable stream. Another (they are linked, I suspect) is Landauer’s principle, which dictates that there is a certain lower limit on how much power that is necessary to flip a bit, and that forms a hard stop in terms of how much you can lower power consumption (and with it, heat dissipation.) (See Denning, P. J. and T. G. Lewis (2016). “Exponential laws of computing growth.” Communications of the ACM 60(1): 54-65, for an excellent discussion of Moore’s law and its remaining life.)

Turns out computing capability as a function of electric power consumption might be the next big obstacle (or at least measurement.) The BitCoin miners certainly know that.

Reverse, computing, which Ted writes about, is essentially computing where the power can be reversed, recreating the initial state. While difficult technically, it certainly would reduce power consumption to almost nothing.

To learn how, read the article. Recommended!

Made my day!

digøkskjermI just got the message that the new bachelor program Informatikk: Digital Økonomi og Ledelse (Informatics: Digital Economics and Management) is now the most sought-after study program in Norway, with 19 applicants per available place (514 first-priority applicants for 27 available places).

Since I have taken the initiative to this program and developed it with colleagues at the University of Oslo (where I have an adjunct position, this definitely made my day. Week, actually.

Just sayin’…

Notes from ACM Webinar on blockchain (etc.)

The Next Radical Internet Transformation: How Blockchain Technology is Transforming Business, Governments, Computing, and Security Models

Speaker: Mark Mueller-Eberstein, CEO & Founder at Adgetec Corporation, Professor at Rutgers University, Senior Research Fellow at QIIR

Moderator: Toufi Saliba, CEO, PrivacyShell and Chair of the ACM PB Conference Committee

Warning: These are notes taken live. Errors and omissions will occur. No responsibility whatsoever.

  • intro: old enough to remember the discussions in the early 90s about how the internet would change mail services – completely forgetting shopping, entertainment and others
  • Blockchain solves the problem of transferring value between Internet users without a third party
  • goes beyond the financial industry, can handle any kind of transaction
  • most of the world has access to a mobile phone, only about 20% has access to the banking system
  • Blockchain is the banking industry’s Uber movement
  • Blockchain much wider than Bitcoin, will facilitate new business models.
  • Blockchain transfers rather than copies digital assets, making sure there is only one instance of it.
    • settlement process: no clearing houses or central exchanges
    • peer-to-peer transfers, validation by network
  • Example: WeChat taking over payments in China, no link to banks
  • many commercial or government services are basically “databases” that are centrally managed, with one central point of failure
  • Blockchain allows a distributed ledger, information put in cannot be changed
    • Estonia thinking about a Blockchain in case of hacking or occupation
  • public (open), private and government blockchainsxx1
  • allows new services to existing customers, lots of inefficiencies up for grabs
    • estate records, voting, domain control, escrow, etc…
    • iPayYou allows use of Bitcoin
    • Walt Disney looking at Blockchain (DragonChain) for internal transfers, also use it for tracking supply chain to their cruise ships. Opensourced it.
  • 80% of Bitcoin mining done in China
  • regulation comes with a cost
  • Shenzhen want to be Blockchain Tech capital
  • 6-level security model, developed by William Mougayar (goes through it in detail: transaction, account, programming, distributed organizations, network (51% attacks, perhaps as low as 30%, smaller blockchains more vulnerable), governance)
  • Ethereum blockchain focusing on smart contracts: Hard forked in 2016, DAO issue where somebody hacked DAO code to siphon off money, hacking the program using the blockchain (not the blockchain),
  • credit card transaction can take up to 30 days, with disputes and everthing, Blockchain is almost instant
  • How “real” is blockchain technology
    • Goldman-Sachs invested $500m+
    • 15% of top global banks intend to roll out full-scale, commercial blockchain
    • etc.
  • what is holding it back?
    • difficult to use, understand, buy in; perception of risk and legality
    • difficult to see value for the individual
  • questions:
    • what are the incentives and adoption models?
      • different philosophies: computing power must be made available in the network: industrial mining vs. BitTorrent model, the amount of computing provided will be important, if we can find a model where just a little bit from every mobile phone is required
    • what are the hard costs of Blockchain?
      • you can google the costs. There are other approaches being developed, will post some links
    • can Blockchain be compromized by a virus?
      • theoretically, yes. Bitcoin is 10 years without, open source means verification (change is happening slowly because of code inspection)
      • comes back to incentive and governance model
  • and that was that…recording will be at webinar.acm.org in a few days.

Case teaching in Vienna

quantI have been asked to give a keynote speech at a conference on case teaching in Vienna, at the The University of Applied Sciences BFI. This is quite an honor, and I am very much looking forward to it.

Should you happen to want to be in Vienna and focus on case teaching on May 19 – well, I hope to see you there!

Key myths about analytics

My excellent colleagues Alessandra Luzzi and Chandler Johnson have pointed me to this video, a keynote speech from 2015 by Ken Rudin, head of analytics at Facebook:

This is a really good speech, and almost an advertisement for our course Analytics for Strategic Management, which starts in two days (and, well, sorry, it is full, but will be arranged again next year.)

In the talk (starting about 1:30 in), Ken breaks down four common myths surrounding Big Data:

  1. Big Data does not necessarily imply use of certain tools, in particular Hadoop. Hadoop can sift through mountains of data, but other tools, such as relational databases, are better at ad hoc analysis once you have structured the data and determined what of the data that is interesting and worth analyzing.
  2. Big Data does not always provide better answers. Big Data will give you more answers, but, as Rudin says, can give you “brilliant answers to questions that no one cares about.” He stated the best way to better answers to formulate better question, which requires hiring smart people with “business savvy” who will ask how to solve real business problems. Also, you need to place the data analysts out in the organization, so they understand how the business runs and what is important. He advocates an embedded model – centrally organized analysts sitting geographically with the people they are helping.
  3. Data Science is not all science. A lot of data science has an “art” to it, and you have to have a balance. Having a common language between business and analytics is important here – and Facebook sends its people to a two-week “Data Camp” to learn that. You ned to avoid the “hippo” problem – the highest paid person’s opinion – essentially, not enough science. The other side is the “groundhog” issue – based on the movie – where the main character tries to win the girl by gradual experimentation. Data is like sandpaper – it cannot create a good idea, but it can shape it after it has been created.
  4. The goal of analytics is not insights, but results. To that end, data scientists have to help making sure that people act on the analysis, not just inform them. “An actionable insight that nobody acts on has no value.”

To the students we’ll meet on Tuesday: This is not a bad way of gearing up for the course. To anyone else interested in analytics and Big Data: This video is recommended.

(And if you think, like I do, that his sounds like the discussion of what IT should be in an organization 20 years ago – well, fantastic, then we know what problems to expect and how to act on them.)

Cases: How to prepare for and learn from them

My versatile and creative colleague Hanno Roberts and I have made a series of five videos on case learning and preparation, originally for students at the BI/Fudan MBA program. This teaching method is difficult both for teacher and student, but highly rewarding provided you give it proper attention – which means effective preparation. Hanno and I talk about the goal of case teaching, how students can prepare individually, how to prepare as a group, how to go through the case discussion in the classroom, and then we sum up with some strategies for how to retain what you have learned.

Hanno and I did these videos against a green-screen, with little preparation – we basically met, outlined a structure with some keywords, decided broadly on who should say what, and dove right into it. Most of the videos were shot once, and then the very capable Milosz Tuszko edited them, added background, logos and keywords.

The updated videos are a less wooden than the previous version, methinks, and available in high resolution and with better sound. We clarified the differences between my version of case teaching and Hanno’s (both work, by the way). Over the years the original videos have been much watched – hopefully, our students (and others) will watch them carefully, and the result will be better case teaching, more learning, and an even more enjoyable experience teaching.

Details about each video below the fold…

Continue reading →

Teaching in China – some reflections

I am just back from teaching a four-day module (called IT management and eBusiness, though I might change that title somewhat) at the BI-Fudan MBA program.

R0012024

picture2017This is just about the 15th time I teach in China, all of it in cooperation with Fudan University, which gives me some cause to reflect on how teaching in China has changed – all seen from my rather narrow perspective, of course, but still. Just as the Shanghai Bund view has changed (the pictures are from 1990 to 2010) so have the participants, contents and business environment of my courses.

The students have changed: In 2004, the age range and English proficiency of the students varied much more. About two thirds of the class had rather rudimentary English skills, I had to simplify the language, and the Chinese co-teacher spent a lot of time explaining concepts and partially translating what I did. This is not any longer – gone are the days when Chinese students would sit quietly and avoid your gaze. Now they participate more or less like students anywhere in the world. English skills still vary, but not any more than they do in any European country. The co-teacher (this time the very capable Dr. Wei Xueqi, left of me in the picture) still has one hour of Chinese teaching every day after I am done, but spends more time discussing and less time translating.

The course has changed: I used to lecture much more, focus more on basic concepts and methods. Now I use cases (five in this course, plus one for the in-class exam) and the students analyze and present, challenging each others’ conclusions. I now basically use the same teaching method (heavy on case teaching) in this course as I do in any other course at a M.Sc. or MBA level I teach.

The business environment of Shanghai and China has changed. In 2004, China’s business environment was firmly divided into FDI (foreign direct investment) and SOE (state owned enterprises) and the management culture, measures and methods were very different. Copying was rampant and you sometimes felt as if you were introducing capitalism to an audience where a sizable portion of the students were unsure whether it was a good idea. Not so any more: The students now all have experience with international business, frequently with much more experience than my Norwegian students, particularly when it comes to production and industrial planning. A larger and larger portion of the class works in service industries and in online enterprises, something which I have reflected in choice of cases and examples.

I used to go to China because it was different and therefore interesting. Now I go there because it is interesting – but not so different. At least not in the classroom.