Is an intranet the last resort of the dis-connected?

An interesting discussion going on in AOK about people'#s preferences for seeking information.

John Maloney wrote:
> I found a reference in Rob Cross's book, "The Hidden Power of Social
> Networks." People are FIVE TIMES more likely to turn to a colleague
> for knowledge than any portal, Intranet, system or Website. That is
> not a tendency, or even twice or three times as likely, it is five-
> times!

I replied: "Although I agree with the spirit of what you're saying about the need to
support the people-to-people side of organisations, I wonder if you're over-extrapolating from the evidence? Cross cites Tom Allen's work from 1977 (see e.g. page 2). The implications are limited about the technology and habits at the time. Cross goes on to say "Our own research and that of many others also continues to emphasize the point that who you know has a great deal to
do with what you come to know over time." I therefore can't find any data presented by Cross on the impact of portals or intranets per se. This isn't to say that it's no longer true that people prefer asking somebody else, only that I'd like to see a more recent study to support it."

"Secondly, just because in '77 people had that habit, it doesn't mean it isn't changing - or that there's resistance to change. People are lazy. Rooting through a paper filing cabinet is much harder than asking Nellie (as the archetypical colleague). Searching Google, now it exists, may be easier than asking Nellie. Older generations may have an ingrained expectation that databases rarely have the right answer; teenagers seem to assume Google can answer everything. If you wanted to know film times at the local cinema, would you ask Nellie first or use the net?"

"Thirdly, Allen's study was of scientists and engineers. This may not map onto business situations. One reason why portals are attractive is if they reduce internal service costs. You may not want your world-class expert answering the phone all day for routine queries, no matter how much the caller may prefer that mode. You want to keep them free for the
high-value, non-routine calls that are ideal for people-people interactions. Each query has a cost, but asking Nellie doesn't expose the requester to that cost. Would you be 5 times as likely to call a premium rate helpdesk if the alternative was to get the answer from a portal for
free? Organisations need to manage this."

Dennis Pearce, from Lexmark, then added:
"in addition to his "five times" result, Allen also found that the engineers he surveyed got their knowledge from the sources that were easiest and most familiar to them, not the ones that were most reliable or accurate, even when they themselves were aware of this. In other words, they
knowingly sacrificed accuracy for expediency." [my emphasis]

"I find this to be a much more interesting finding than the "five times" result, and one that seems (in my mind) to be more likely to be still true today. People have jobs to do, and sometimes you have to make do with the info you've got, given the time constraints you're under. Those who are developing new KM technologies are going to have to keep in mind that it's not just "better," but "faster and easier" that will be the big selling points. And it's a challenge to create something that's faster and easier than the way we've always done things."

Quite right - its so easy to forget that making something quicker doesn't just save time, it can also completely change how people work. When electrical appliances for cleaning first became popular (e.g. vacuum cleaners), commentators foresaw the liberation of the housewife. In reality, it just upped expectations of how clean a house should be.

Real Work, Necessary Friction, Optional Chaos

Philip Armour in The business of software rejects the notion of estimting software by effort and advocates looking at the social component instead. WHat he has to say has implications way beyond the software industry though. He makes a good case for why putting pressure on teams can exponentially increase the cost fo the final deliverable.

Traditional estimating tools aren't effective, he argues. Lines of Code, for example, is inaccurate because in reality it's non-linear (1000 people can't do 1 line each). Indeed adding people can just create further delay (as set out in the classic "The Mythical Man-Month"). Armour attributes total project time to:
1) "the time it takes to factor our knowledge into an executable product" - this is what things like 'lines of code' measure.
2) Know-we-don't-Know situatuations where exploration required. Spiral (iterative) methodologies acknowledge that not everything we do goes into the end product, but instead goes into creating knowledge to make the product. i.e. fillling the knowledge gaps to the point where you've learned how to make it. Armour calls this "necessary friction".
3) "Optional Chaos" is co-ordination overhead, bickering and stress-induced chaos. Anything that does NOT disclose knowledge.

1) is a function on Know-We-Know and Know-we-Don't-Know factors
2) is a function of don't-know-what-we-don't-know, team capability and experience, team size and 'pressure', but the variability in the impact of this low.
3) is a function of team size and 'pressure' and highly variable in impact.
"When we attempt to accelerate projects, we introduce a high lelvel of [optional chaos]. High-stress projects put pressure on people to make quick, sometimes unvalidated decisions" [whose impact can then be catastophic].

Adding more people: "large numbers of people...increases the levels of both communication and mis-communication." More people means less equally distributed knowledge, so more chance for mis-understanding, and more time spent sharing knowledge that already 'known' rather than tackling learning gaps.

Outside of software, the implications are very similar: if you want a deliverable quickly, be aware that doublign the team size is unlikely to reduce the time to delivery that much, and in fact may make the deliverable cost far more than double. As a project manager, Armour offers a useful set of questions about how your team is spending its time. I particularly like that it clearly sets out that "knowledge work" is both 1 & 2, and that pressure just amplifies what takes most of the fun out of being a knowledge worker. Not the pressure per-se, but the side-effects it creates.

Mapping Collaboration Maturity

TechUpdate - ZDNet article:
* "Procurement of collaboration technology and services is not well managed and is introduced without centralized guidance (e.g., business units subscribing to Web conferencing providers; end users using public IM networks; departments using teamware).
* Effective collaboration requires behavior change on the part of users as well as examination of information sharing and process structures. Collaboration strategies are less successful when not aligned with human capital management (HCM; e.g., rewards, incentives) and knowledge management efforts to improve performance and innovation. "

Presents a 'maturity model' of collaboration that emphasises the human angle too. ALso sounds a dire warning that if not controlled, overlapping systems will put significant stress on users. Lets hope IT and leadership can get it right this time. Otherwise yet again we spend $millions on technology and change that doesn't work and 'collaboraration' will be dismissed as the last failed fad.