Joined-Up Collaboration

@inmagic 's Phil Green suggests an Enterprise 2.0 Best Practice: Unite Internal Collaboration with External Communication (CMS Wire Nov 29, 2010)



As he points out, internal and external are often disconnected. Clearly, different tools are appropriate for different kinds of collaboration. As Phil acknowledges, "external collaboration ... has usually taken the form of activities such as blogging, tweeting, Facebooking, Flickring, YouTubing, etc. with customers and communities outside the firewall".

In advocating unification, Phil appeals to the following two facts.

• Both internal and external collaboration are based on relationships.
• Each kind of collaboration should contribute to the organization’s collective goals.

However, these two facts alone are not sufficient to justify unification. The word "firewall" is a clue that there are still many barriers between internal and external, and we may also infer the presence of stakeholders who will resist efforts to dismantle these barriers. See my post on Enterprise 2.0 inside the firewall.

Phil describes a scenario where he thinks there is a plausible case for some kind of collaboration spanning internal and external.

• A business unit that is gearing up for a new product development cycle. 
• A list of possible product enhancements is maintained in an internal E 2.0 tool.
• The organization uses the E 2.0 tool "to seamlessly expose the top 50 internal product ideas to customers and receive feedback and reactions".
• The product management team analyses the customer feedback and initiates further investigation into features identified as high customer priority, including internal search for relevant R&D as well as focused research on competitor products.
• Following this investigation, they set the product strategy and start building a marketing campaign.

Frankly, I don't think this is a very good example. It looks to me like a highly conventional product development process, with a narrowly constrained chunk of customer consultation in the middle. I'm guessing that the customers are not given seamless access to all the internal product ideas and issues, merely to a top 50 list which is a separate knowledge artefact, possibly constructed solely for this purpose. In which case, the word "seamlessly" here merely refers to the fact that the top 50 list and the full list happen to reside in the same software tool. (A tool, by the way, which looks suspiciously like the one Phil's company sells.) A paper questionnaire might have been more trouble to administer, but it might have been just as effective in terms of customer feedback and customer relationships.



In order to create a more convincing example, one should start not from the desire to sell a particular software tool, but from the business desire to collaborate more intelligently and intensively with the customers all through the product development cycle. The product management process would probably need to be radically changed, and we might not even need a separate marketing campaign. We probably need to think about organizational unification (radically new kinds of collaboration) long before we bother with platform unification (Phil's Social Knowledge Network).

---

Places are still available for my Organizational Intelligence Workshop on December 8th.

Requisite Collaboration

My blogpost on The Startling Cost of Inefficient Collaboration started from the observation that "too much collaboration can be bad". But how much is too much?

Too Little

Barely Enough

Just Right

More Than Enough

Too Much

We often need to make a judgement about the appropriate quantity and quality of something. Such judgements can be difficult ones, because they need to be sensitive to who, why and where. Even something as basic as the right amount of food will vary between members of the same family and at different times. And there is no simple formula that will tell you whether to spend more time preparing for tomorrow's meeting or to get an early night.


So how much is a good amount of collaboration - just enough but not too much? Obviously this depends on many situational factors including purpose and context. We can talk about requisite collaboration - in other words, the quantity and quality of collaboration that is appropriate for a given situation. And although we should not expect a simple formula, this is nonetheless something we should expect to be able to reason about.


It's also important to remember that the quantity and quality of collaboration is not necessarily under the control of a single stakeholder. People who work in large organizations may be able to initiate some meetings and duck out of others, and may sometimes be able to unplug phones and ignore email (although many people experience guilt or anxiety when they do this), but the actual quantity of collaboration emerges from the interaction with everyone else. The bosses at Lehman Brothers had elaborate routines to prevent ordinary staff talking to them, and some commentators (e.g. @markfidelman What if Peter Drucker Taught Enterprise 2.0?) have suggested this could have contributed to the collapse of the firm, but I'm sure even Lehman bosses couldn't cut themselves off completely from urgent demands from important stakeholders.


So Lehman bosses may sometimes have had more communication with other people than they felt they wanted at the time, but with hindsight even they might admit that they didn't have enough of the right kind of communication. Such a judgement is always relative to a particular stakeholder position - other people such as junior staff or minor customers might complain that Lehman bosses didn't listen to them, but to put this complaint in terms of requisite collaboration would be to imply that Lehman bosses didn't do enough listening to serve their own interests and the interests of the firm as a whole.

In some domains, there is a body of knowledge that may help us to determine the right level of collaboration. For example, John Gattorna uses the concept of requisite collaboration within enterprise supply chains, suggesting that collaboration makes sense only with those who truly want to collaborate. (See John Gattorna, Supply Chain Collaboration, Supply Chain Digest June 2007. See also review of Dynamic Supply Chain Alignment by Jan Husdal.)

In any case, we need some whole-of-context view to determine the requisite level of collaboration, as my friend @tetradian points out. For Lehman Brothers, inadequate collaboration led to inadequate organizational intelligence, which led to organization failure. The organizational intelligence methodology should help us think about the appropriate collaboration levels of different scenarios by working backwards from the consequences.


Related posts: What are Silos Good for? (June 2010), Organizational Intelligence After Drucker (August 2010) 

The Startling Cost of Inefficient Collaboration

@BillIves @tetradian and @gagan_s point to some recently published research suggesting that "collaboration can exact heavy time costs if done inefficiently" [MIT Sloan November 2010]. Yes indeed, that is what the word "inefficiently" usually means. Specious arguments and poor journalism says @flowchainsensei; @tetradian agrees about the poor journalism but thinks there is a valid point about whole-of-context cost of collaboration.

The researchers measured the time cost of collaboration in terms of the amount of time people spend preparing for and engaging in collaboration with others. Undoubtedly there is considerable variation in the amount of time people devote to these activities, and also considerable variation in the benefits gained from these activities. In many situations there will be a trade-off between the amount of preparation and the effectiveness of the collaboration - poorly prepared people may not be able to collaborate effectively - and obviously the greater the number of people involved in a collaboration, the greater the cost of wasting people's time as a result of poor preparation.

If we want to know the efficiency of a particular activity, then we need to have a measure of output as well as input. It may be an interesting observation that some project managers devote more time to collaboration, and consume more collaboration time from their team members, but in order to draw useful conclusions about collaboration efficiency, either we must assume that all project managers ought to need exactly the same quantity of communication, or we must have some way of linking collaboration with the overall performance of the team. After all, there are some working practices requiring high quantities of collaboration, such as pair programming, that are thought to be associated with high levels of overall productivity, so we shouldn't always regard collaboration time as an unnecessary cost. I don't need researchers to tell me too much is too much; what I want to know is how much is too much, in other words some notion of requisite collaboration.

The researchers think "it is important to reduce network connectivity at points where collaboration fails to produce sufficient value". Well yes obviously, but the critical question is how to assess the value of collaboration in the first place. See my post on Collaboration Impact Zones.

Collaboration Impact Zones

In my previous post Collaboration Chasm, I looked at the adoption of collaboration technology in the enterprise, drawing on Collaboration Framework published by the CISCO community earlier this year [Insights from the Collaboration Consortium Year One]. In this post, I'm going to explore the CISCO concept of Impact Zones.

CISCO starts from the idea that the greatest payoff from an investment in collaboration comes where people and content intersect - whether in real time, asynchronously, or both. CISCO looks at three aspects of collaboration: interaction, expertise and information. Interaction includes in-person meetings, phone conversations and project teams; expertise includes tacit or professional knowledge, such as an executive, knowledge worker, or specialist might have; and information includes that found in databases, working documents, and archives. “Collaboration impact zones” are those junctures where interactions and the exchange of expertise and information are frequent, urgent, and complex: these may be focused on either internal or external collaboration. CISCO believes that identifying these zones helps an organization focus on the right areas of collaboration to ensure that the financial return of collaboration is greater that the associated opportunity and collaboration costs.

The CISCO definition of collaboration impact zone uses the present tense, and so appears to refer to the AS-IS model of the enterprise. But if we take this too literally, it might lead an organization to invest in those areas where excessive collaboration is already taking place today, instead of those areas where collaboration is weak.

Here's an example. Many organizations have the most intense and angry exchanges with the customers after something has gone wrong: John Seddon calls this failure demand, and points out the stupidity of focusing on managing customer complaints more efficiently, when it would be far better to focus on preventing the things that the customers are complaining about.

However, the examples cited in the CISCO community document don't fit the literal definition of collaboration impact zones. Instead, the investment is apparently focused not on areas where the collaboration is already frequent, urgent and complex, but where collaboration is both insufficient (not enough interaction and expertise where it is needed) and expensive (even limited interaction and delayed expertise incurring significant travel costs). In these examples, the business benefits come from building a platform to support frequent, urgent, complex and affordable collaboration. "Both companies identified part of a business process in which a high concentration of interaction, expertise, and information is required to deliver the business process outputs ... the collaboration tools are adapted to the requirements of the collaboration impact zones." "An organization can begin the process of identifying its impact zones by developing hypotheses about what parts of the processes need performance improvements, then taking “deeper dives” to validate whether collaboration at those points can drive business value." Thus it is in the TO-BE model where we need to look for the collaboration impact zones, not in the AS-IS model. (Which of course raises the question where the TO-BE model comes from.)

But we should also note another possibility. AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place. This method is also used for detecting inappropriate collusion between systems that are supposed to be completely independent.

This in turn suggests another way of thinking about collaboration impact zones - they may be anywhere where there is something problematic about the collaboration that may or may not be taking place. For example, there may be some interactions that are not particularly frequent or urgent or complex, and are not expensive to transact, but need to be controlled for some reason - perhaps to eliminate risk or fraud, or to guarantee compliance with some critical requirement, or just to make them visible and available because managers like things that way. ("This call may be recorded for training purposes.") There will also be collaborations whose participants wish to avoid control and interference by management, for whatever reason. So the identification of these zones is going to raise a lot of issues.

A business case for collaborative action

#SOA #insurance #govit @mcgoverntheory asked if anyone was interested in learning how insurance carriers partnered with state GOV to stand up SOA for online coverage verification?

Where is the business case for this initiative? There is certainly a demand, going back to this 2001 article on the Growing DMV Reporting Headache, and James points to a March 2004 document on the IICMVA website called Online Insurance Verification Using Web services to verify auto insurance coverage (pdf).

The IICMVA document outlines the problem - costs incurred by uninsured motorists, complicated and varied procedures for verifying insurance between different states - and so it makes clear that a web service solution might be a good idea. But a business case has to go further than this.

Firstly it must show that the benefits outweigh the costs (and risks). In a collaborative scheme, it isn't always obvious who is going to pay for the scheme, so there may be alternative options for funding the development followed by some kind of charge-back during operations. Each party that is investing in the scheme will presumably need a business case to justify its own investment. But if there aren't sufficient benefits to cover everyone's costs, then the scheme just isn't viable at all.

Searching the internet, I found a presentation by Loren McGlade and Jon Neiditz from the ACORD/LOMA Insurance Systems Forum (May 2009) mcglade_neiditz.pdf; mcglade_neiditz.mov; mcglade_neiditz.mp3. This presentation contains a lot more than the March 2004 document in terms of quantifying the potential benefits and cost-savings of the scheme.

And secondly, in a collaborative scheme like this, the viability depends on the number of people who join. In this case, how many insurance companies and how many states have to participate, in order for the scheme to deliver the benefits. Given that the benefits are largely dealing with the complication caused by the differences in regulation between states, this only makes sense if multiple states are involved. But how many?

I've done a number of business cases of this kind, where the viability of a multi-agent scheme depends critically on the rate of adoption, so I'd be very interested to see how this aspect of the business case for the IICMVA scheme is worked out.

More generally, there is a widespread belief in the potential benefits and cost savings of shared service provision, especially in the public sector. However, there is often a lack of realism in how these shared services are to be implemented. If the shared services are too inflexible, then people won't use them without some degree of coercion; thus the costs and risks are higher than expected, and the benefits lower. I'm looking at a number of situations in the UK where public sector agencies are being encouraged to use nationally provided services, and it's an extremely complex task to work out how these services can be fitted asymmetrically into a joined-up solution that delivers the best outcomes. (Please contact me if you are facing this kind of task.)

From Collaboration to Business Value?

#AIIM @noelrath @jmancini77 via @dhinchcliffe @skemsley .

Dion and Sandy retweeted a list of 8 Ways to Make Sure That Collaboration Adds Business Value on John Mancini's blog, possibly authored by Noel Rath of HP. I just wanted to add a few critical comments here.


1 -- Collaboration is part of a process.

One way of looking at this argument is to say that it is the business processes that deliver business value. Therefore the only way for collaboration to deliver business value is through the business processes - for example, helping people to communicate more efficiently and to make more effective decisions - or perhaps helping the supervisory level of management to control and audit what is going on.

But we can think of this in two ways. One is to think of "collaboration" as some stuff that gets plugged into an existing process, plus some additional control mechanisms to prevent people actually using this stuff in ways that might produce "adverse business consequences". This approach may well result in a more complicated and only slightly more effective process.

Alternatively, we can think of "collaborative" as a radically new way of architecting and regulating processes - based perhaps on a cybernetic paradigm (for example Stafford Beer's Viable Systems Model), with the potential to optimize the business value obtained from the transformation.


2 -- Control is essential. 
3 -- Records management is a discipline. 
8 -- Records management should be back-end driven. 

The article asserts that control of information processes is critical to reduce risk, and that it is the role of information specialists to ensure that collaborative technologies support the business and do not introduce unintended consequences. I suspect that this refers to a fairly narrow conception of risk, defined in terms of uncertainty of outcome, which is what people worry about in fairly simple business situations. For more complex situations, we also need to think about ambiguity (uncertainty of meaning) and ambivalence (uncertainty of intention). Collaborative intelligence can be extremely valuable in helping to address these higher uncertainties, but this kind of intelligence doesn't thrive in the wrong kind of control environment.

4 -- Consider content sources and types.
5 -- SharePoint collaboration.

These two points are more about technical design rather than business value, so I don't want to comment further.

6 -- Educate.
7 -- Consider the knowledge worker.

The article advocates "educating" the knowledge worker to get more productivity out of them, but doesn't want to overload the knowledge worker with the responsibility of deciding what is important for the business. Sounds like a Theory X management style to me.

---

Overall then, the article is mostly about records management. No doubt people who are scared by the idea of genuine collaboration and organizational intelligence will be attracted by this kind of half-hearted approach, but it doesn't have much to do with my notion of collaboration or my notion of business value.

Will Libraries Survive?

Following my post on Library Collaboration, Anders Jangbrand commented

"Book available on net do not have same limitation. No phys copies. Will libraries survive?"

That's an excellent question for two reasons. Anders always asks good questions, but another reason I like this one is because I am already working on an answer. But first a little history. 

In the dim and distant past when I first learned data modelling, one of the standard exercises in books and training courses was to model a library. These were of course models of the library as an information processing system. Before computing, libraries were managed with cabinets full of hand-written cards. There would be one or more cabinets containing the library catalog, there would be cabinets for members' names and addresses, outstanding loans, reservations, books awaiting repair, and so on. 

So it was an apparently straightforward task to model this lot; but there are some hidden traps for the beginner. For example, BOOK sometimes means the book title (as when you reserve a book) and sometimes means the physical copy (which is what you borrow and return). When I teach data modelling, I generally give students the freedom to fall into these traps so I can show them how to get out again. 

(Some libraries identify each physical copy individually, while other libraries merely count the physical copies of a given book title. The physical copies are distinct in the real world, but may be indistinguishable in the library's card or computer systems. Information strategy includes making this kind of choice. See Business Concepts and Business Types to see how this is handled in the CBDI SAE method.) 

The great advantage of using a library as a teaching example was that most people had used libraries and had some idea how they operate. However, some people started to think that the example was a bit old-fashioned, so they developed a Video Rental example instead. Video rental has pretty much the same information processing structure as a library, so all they needed to do was take the library example and change some of the words on the diagrams. And nothing much changed when video tapes were replaced by DVDs, although there were some minor complications if you wanted to handle both tapes and discs during the transition period. 

 The traditional library is indeed threatened, but it will probably outlive video rental, which is threatened by much the same forces to an even greater extent. If we want to manage these forces, we need to move away from an information processing model onto a different kind of model. 

Libraries and video rental operate a very similar information processing model. But if we want to think about the survival of libraries and video rental, we need a model that shows how libraries and video rental are different from one another, and to what extent libraries or video rental can play a valuable role in the service economy of the future. 

The first point to note here is that the book plays a much more varied role in people's lives than the video, even today. The vast majority of DVDs are either feature films or collections of TV programmes, consumed as entertainment, and video rental essentially caters for this market. Books are also consumed for entertainment, but they are also used for reference, study, research and other purposes, and most libraries support a broad range of purposes. If we want to forge a sustainable role for the library of the future, we need to engage with these purposes, and possibly explore some newly emerging purposes as well. 

Some people may argue that the business model should be technologically neutral. Anything you can do with a book, you can do with a DVD as well. For example, if you want to learn Spanish, it shouldn't matter whether you borrow a book from the library or rent a DVD. But until video rental gears itself up to support this kind of market, there will continue to be a real difference in the business model between books and DVDs. 

The next point to note is that we can open up the idea of the consumer. A lot of people like to read books in groups. The whole group reads the same book (see ambiguity of BOOK above), and then the members meet once a month to discuss the books. This represents an interesting opportunity for the librarian - to provide services to the whole reading group rather than to individual readers. For example, if the library has a dozen copies of a recent novel, then this novel can be offered to the local reading group for next month's meeting. 

Now suppose we have a network of a couple hundred libraries around the region, supporting a thousand reading groups between them. Recent novels can circulate around the libraries in sets, to support the needs and interests of the reading groups. 

 See what we've done here. All sorts of interesting business opportunities emerge by these two conceptual shifts. Firstly changing the concept of READER from individual to reading group (and creating a new composite service for the whole group). Secondly changing the concept of LIBRARY from single library to a network of libraries (and creating new kinds of collaborative process). 

Once we've identified these conceptual shifts, we can go back into the information processing model to work out the practical logistics. But the point I'm making here is that conceptual shifts of this kind (and the business opportunities that are associated with them) don't appear unless you step outside the information processing perspective and look at the business through a different lens. 

Of course I haven't quite answered Anders' question yet. But I'm working towards an answer ...

Library Collaboration

University libraries typically have a major resource scheduling problem, as I mentioned in my post on Collaboration and Context.

"Let's suppose that in the first week of February, sixty students suddenly want to read Kant. The university library possesses twenty copies of Kant's Critique of Pure Reason, so most of the students will have to wait or share. By the end of February, nobody wants to read Kant any more, and the twenty copies sit idle on the shelf until the same time the following year."

My first impractical idea for solving this problem was to get collaboration between the library and the teaching staff. Would it be possible to coordinate the teaching, so the students don't all need the same books at the same time? (Anyone who has worked in a university will know why I reckon this is impractical.)

My second idea might be a little more practical: to get collaboration between university libraries. Perhaps fifteen universities can share two hundred copies of Kant and ship them around as required. Possibly not as much scope for efficiency as my first idea, but it may be easier to implement, as it only involves librarians cooperating with other librarians rather than with professors.

However, the most plausible idea for solving the problem is to involve the paying customers - the students. In many countries higher education is subsidized by the state, but students and their parents are now being asked to pay a much higher contribution, and this makes them stakeholders in the economics of the university and the quality of its services.

So instead of thinking of this kind of business improvement purely as an optimization problem based on a series of information transactions, we need to think of it as a problem of power and influence - how can the interests of the students be mobilized to achieve better distribution of scarce resources.

Collaboration and Context

In responding to my latest post on Context-Aware Services, Paul Miller reiterates the concept of Collaborative Context-Aware Services, so let me expand on the collaborative aspects.

I'm going to stick with the library example, but I think these concepts have a lot of relevance for many other kinds of service organization.

One of the most important aspect of context is purpose. In the case of a library, what is the reader's purpose for browsing, borrowing and reading a particular book at a particular time? Is this purpose entirely private to the individual reader, or does it emerge from some semi-public activity?

In the case of a university library, the presumption is that most library use is somehow related to the broader purposes and activities of the university - teaching and research. When a student borrows a book, there is probably a tutor or lecturer in the background providing seminar assignments and/or reading lists. There is generally some implicit collaboration, but this collaboration may not be visible to the library.

Let's suppose that in the first week of February, sixty students suddenly want to read Kant. The university library possesses twenty copies of Kant's Critique of Pure Reason, so most of the students will have to wait or share. By the end of February, nobody wants to read Kant any more, and the twenty copies sit idle on the shelf until the same time the following year.

In a rational organization, the library would politely suggest to the philosophy lecturers that the teaching might possibly be reorganized, so that scarce library resources might be used more efficiently. Is it really necessary for all the students to read all the books in the same order? But universities are not rational organizations, and such a suggestion would probably be regarded as an outrageous invasion of academic independence.

We should not expect the library to dictate or constrain how philosophy should be taught to the undergraduates. But this is exactly what happens if there is a shortage of copies of Kant's Critique, since this shortage will have an inevitable effect on the learning outcomes of some of the students. However, if it is possible to negotiate an appropriate collaboration between the library and the teaching staff, then it may be possible to improve the learning outcomes of each student, as well as improving the economics of the library operation.

Since I don't wish to say anything unkind about the likelihood of effective collaboration in a university setting, let me talk about a town library instead. Even if we assume that most fiction is borrowed for the purposes of private enjoyment, a library generally contains large quantities of non-fiction material, which may be borrowed in some practical collaborative context.

Suppose thirty adult residents of Smartchester go into the Smartchester library and ask for elementary Ukranian phrase books. Would it not be reasonable for the Smartchester librarian to investigate the context in which so many people want to learn Ukranian at the same time? Are there perhaps some civic exchange visits planned for later in the year? Is a local travel agent offering a special deal, or is there an enterpreneur selling Ukranian property? How many of the people asking for Ukranian already speak Polish or Russian? Does it make sense for the library to acquire a large quantity of Ukranian phrase books, or is there a better way of satisfying the temporary demand (perhaps jointly with some other organization)?

In my previous post, I said I don't want libraries to sell nappies (or diapers). But I might be happy for the library to help organize language courses, because this seems a reasonable extension of the library's existing services.

---

From an analytical point of view, the problem starts with the false idea that an organization is a stand-alone enterprise, that can be described by a free-standing enterprise model. But a free-standing enterprise model of a library doesn't make complete sense, because there is no source of purpose or demand. These elements only come into the picture when we draw enterprise models that show the collaborative context. The crucial question for the service-oriented library is then the interoperability between the library, its users, and other organizations.

Collaboration Games

An intelligent and coordinated response to business change seems to assume a considerable level of trust between the collaborating parties. Many companies are not willing to share commercially valuable information with suppliers, and prefer to keep business partners at arms length. (This is of course another form of decoupling, and is also supported by web collaboration technologies.)

What these technologies also need to support are the various games that people play. One of the popular early forms of the booking problem was the diary synchronization problem. The idea was that everyone would publish their diary, and this would allow meetings to be scheduled automatically. It would also allow meetings to be dynamically rescheduled, and appropriate text messages sent to your mobile phone. Although applications of this sort have sometimes been successfully implemented, they are widely resisted in practice. People adopt all sorts of games to regain control of their own diary, including creating fake meetings to prevent other people booking them for real meetings.

With supply chain, the procurement game often involves placing more orders than you actually intend to take. This gives you a higher level of volume discounts, and some protection against the vagaries of supply. You can then cancel excess orders as late as possible, while trying to minimize any cancellation charges. Travel agents play similar games when they try to make provisional bookings and block bookings against anticipated demand. While such tactics may be regarded as antisocial, they may be perfectly well supported by web collaboration technologies.

Game-playing and other selfish behavior can be regarded in terms of a deficiency of trust between the collaborators. If we regard trust as a binary property (either you've got it or you haven't), then this results in seeing a large class of collaborations as only possible with perfect trust (which is a pretty restrictive condition when you think about it). But it is much more realistic to assume that most business collaborations involve imperfect levels of trust, with some conflicts of interest, and to find a way of building collaborations around this assumption.

Thus instead of designing a simple collaboration that assumes perfect cooperation between the collaborators, we can start to think about complex collaboration that allows for the possibility of selfish behavior and game-playing. This possibly requires more than one type of collaboration model. A single player may want a model that helps to determine the best (selfish) strategy to adopt. (Such a model could be used to build software that dynamically adjusts the strategy in real time, in order to exploit the observed behavior of the other players.) A self-regulating community or external regulator may want a model that helps to detect and prevent or mitigate anti-social behavior.

Amended extract from my article From Web Services to Web Collaborations (CBDI Journal, November 2002)