This lecture will deal with issues that are (at least superficially) boring but eminently practical: How to avoid systems disasters, and how to deliver IT services within a company. The system disaster we will talk about is CONFIRM, an ambitious project to try to replicate the success of the SABRE reservation system in the hotel and rental car industries. In my experience, it is a real career helper to a) be able to understand when a project is beginning to acquire a whiff of disasterhood, and b) how IT services are provided inside large companies, whether you want to work there of sell your services to either the company or the IT department. The latter you can learn in two hours in a classroom or in two years in a company.
Read and be prepared to discuss:
- "The Collapse of CONFIRM: What went wrong?", p. 534 in Laudon & Laudon: Management Information Systems, Fourth edition, Prentice-Hall, 1996
(You might want to go back and revisit Max Hopper’s article on "Rattling SABRE", note the role of CONFIRM in it)
- Oz, E. (1994). When Professional Standards are Lax: The CONFIRM Failure and its Lessons.Communications of the ACM, 37(10), 29-36.
- Various other notes, see Blackboard.
- Langewische, W. (1998). "The Lessons of ValuJet 592." Atlantic Monthly (March).
- The Concours Group (2004): Service-centric IT (in Blackboard). A consulting report on how to organize an IT department.
- Weill, P. and R. Woodham (2002). Don’t Just Lead, Govern: Implementing Effective IT Governance. Cambridge, Massachusetts, MIT Center for Information Systems Research. Available (number 326) from CISR’s paper web page
- Weill, P. and S. Aral (2004). IT Savvy Pays Off. Cambridge, Massachusetts, MIT Center for Information Systems Research. Available (number 353) from CISR’s paper web page
- Weill, P. and M. Broadbent (1998). Leveraging the New Infrastructure. Boston, MA, Harvard Business School Press. Good book on IT management.
- Looking at the CONFIRM disaster – what were the technical reasons for the failure, the organizational (management) reasons, and the strategic (business) reasons?
- How is running an IT shop (inside an organization), an outsourcing company, and an IT consulting company different – and similar – to each other?
Some years ago I talked with a Berkeley professor who first was shocked when Arnold Schwarzenegger was elected guvenor of California – then, a year later, had to grudgingly concede that he wasn’t all that bad – especially in that he took on the State Assembly, which is incredibly conservative in its vested-interest radicalism. The following message recently sent to the State Assembly shows that he (or someone on his staff) has a sense of humor, too:
How I wish the underlying messages of other political emissions where equally clear…
(Via boingboing, which, true to form, spends most of the comments on calculating whether this was a coincidence or not…)
October 30, 2009, 0800-1045
(This is a temporary entry – there will be more description and perhaps more literature later….)
Creating technology is far from easy – specifically, creating software involves a number tools and techniques that are crucial to overcome the fact that systems are complicated, abstract, and involves interdependencies with many other systems. To understand this we will hear from some of the most experienced software engineers and software project managers in Norway.
Our guest lecturers on October 30 will be Dalip Dewan, Senior Vice President of Technology, and Rune Steinberg. Both work at Visma, one of the largest software companies in Norway.
Dalip Dewan has a very interesting background, has built large systems and been responsible for the design and building of software platforms to facilitate consolidation and integration of acquired software companies under the Visma umbrella. He is an excellent speaker and a very demanding discussant – come prepared!
With Dalip will be Rune Steinberg, a computer scientist who has collaborated with Dalip on the development of software engineering and management methods for more than 10 years.
I can promise an exciting class on how to manage software development, particularly integration of many systems, as well as real-world experience on how to manage the people that make the systems.
Read the following:
- if you do not have experience with computer programming, systems development or software engineering, read the appropriate Wikipedia entries and progress from there. Checking out entries on C, C++, Java, Ruby on Rails, client-server computing, object oriented programming, agile software development and extreme programming (not to mention SCRUM, very popular in Norway) may also be a useful exercise. Or read a book. There are plenty around.
- Dive into Neal Stephenson’s In the beginning was … the command line, probably the best piece on humans’ relationship with technology (and use of metaphors to understand it) ever written.
(The full text of this assignment can be found here)
This assignment is intended to teach you something about collaborative software – and what better way to learn that than to use it? (A side benefit may be to improve the quality and quantity of information available in the English or Norwegian version of Wikipedia.) Wikipedia is an on-line encyclopedia, written collaboratively (that is, by the readers). It uses wiki technology, and everybody can update everything. Order is maintained by common goals and common behavioral norms.
Assignment: (The following can be done in either the Norwegian or the English version of Wikipedia.) Be advised that this assignment takes time, so a good idea is to start early and work on it consistently over the time of the course.
- Register yourself as a user, read some of the documentation about what Wikipedia is and how it is to be used. You will find links to it on the main page. (The material in the English version is most rich here, of course.)
- While logged in, start editing and writing articles – anything you do will be tracked. Write on whatever you want, but make sure that you follow the intention of the Wikipedia. (The Norwegian version is probably the easiest to do this in, since many more articles there either are missing or in need of further development).
- Go to the course Wikipedia page (English or Norwegian version) and add yourself to the list of students, making sure you use the correct format (for an idea, see the 2005 list). (The intent here is that I should be able to click on each student, and then see what articles the student has worked on.)
- Write me a memo, marked with both your student number and your Wikipedia user name, and whether you used the Norwegian or English Wikipedia version. For a total of less than 600 words, answer these questions:
- What, if anything, surprised you the most about the Wikipedia?
- What uses can you see for this technology in a corporate setting? What does it take for it to be successful?
- For which kind of businesses and technologies can Wikis be a disruptive technology?
The Norwegian School of Management is starting a large research project called "A Knowledge-based Norway" ("Et kunnskapsbasert Norge"), where the goal is to study Norwegian "knowledge hubs" – knowledge-intensive industries and how they create and distribute knowledge. The project is led by Torger Reve and Amir Sasoon, and will encompass 10 different industries.
I have been tasked with one of these industries – the Norwegian IT industry, and is therefore seeking M.Sc. students who wants to write their theses under this topic. This will involve studying individual companies (such as, for instance, EDB Business Partner, Accenture or Opera Software) or groups of companies (say, the Norwegian IT services sector, or software companies supporting the oil industry) to understand how they develop knowledge, interact with each other and their customers, evolve their markets and their services, and so on.
The upshot for students, of course, is that they get to learn something that is very relevant both from a research and a practical (read: career) perspective. The study starts these days and will finish in about two years, which will make it ideal for M.Sc. students starting their thesis work this or (to a lesser extent) next Fall.
Please contact me at firstname.lastname@example.org if you are interested.
(October 23, 2009, 0800-1045, C2-040)
Disruptive technologies (later changed to disruptive innovations) has become something of a buzzword – you can hardly hear of a new technology or service that isn’t branded as disruptive these days, especially if it also makes use of other spiffy technologies and concepts such as cloud computing and Web 2.0.
In this lecture, we will look into the practicalities of disruptive innovation, in the context of a case of a company – Sonosite, which produces a technology that can be brought to market in several different ways – each with its own set of possibilities and difficulties. Technology strategy can be simple in theory and very hard to do in practice, as you will see when you read and analyze the case.
On a more administrative note – this is the date when I expect you to start thinking, in writing, about your term project and the paper it is supposed to result in. I have made available a Google document where you can write in your suggested term paper topic and group – and make comments on your colleagues’ efforts. Please edit this document before 2000 on October 22.
Please read and be prepared to discuss:
- Chapter 7 (versioning) in Shapiro and Varian
- Utterback, J. M. (1994). “Chapter 7: Invasion of a stable business by radical innovation” Mastering the Dynamics of Innovation. Boston, MA, Harvard Business School Press.
- Most of the Christensen & Raynor book
- Clayton M. Christensen, Stephen P. Kaufman, and Willy C. Shih: Innovation Killers: How Financial Tools Destroy Your Capacity to Do New Things, Harvard Business Review, January 2008
- Case: Sonosite: A View Inside
- The whole of Utterback’s book
- Watch this video from MIT, seeing Clayton Christensen teaching live.
Henrik Ibsen by Robert Ferguson
My rating: 4 of 5 stars Found this in my bookshelf when looking for Ibsen’s collected for one of my daughters. Good, mostly based on correspondence, traditional chronological discussion, underscores Ibsen’s very secluded nature and tendency to write himself into every play. Not to mention his love-hate relationship with his home country, keen eye on sales figures, vanity, callousness towards his family and monomanical focus on his work. Not a very pleasant man – all his humanity came out in his plays, apparently. (Based on the Norwegian version of the book.) View all my reviews >>