Wow.  This is a heavy read.  And lots to think about.  

I don't know why I thought Simon was from Britain.  I was halfway through Chapter 3 when I checked out the back cover and saw the man's credentials.  Pretty interesting.  He's a professor of Computer Science and Psychology with a Nobel Prize in Economics.  That's what I call a Renaissance Man.  

I have been most impressed with Chapter 3 so far.  The comparison of human activity with those of an ant trying to get back into the anthill gave me pause for reflection.  I'm not sure if I would completely agree with Simon on that one point, but it is an interesting point of view.  

Tomorrow (Monday), I'm going to be teaching a little lesson on encryption in my CalPoly Extension class – at the request of the students.  I think I'm going to use his DONALD+GERALD=ROBERT cryptarithmetic example to confound the class – both of them!  That was a really interesting little exercise in testing one's problem solving creativity.  

I find it also interesting in Chapter 4, where Simon is approaching Short Term Memory and Long Term Memory  challenges like he is designing a new chip!  There are obvious parallels in the architectures and I believe, perhaps wrongly, that we tend to design machines that act like we do, if they don't always look like we do.  So perhaps eventually we (humans) will design and build CPUs that behave more and more like the real human mind.  

I just hope we give them a nice personality;-)  

This is a pretty interesting subject that Gee-Woo Bock, Robert Zmud, Young-Gul Kim, and Jae-Nam Lee have studied empirically for us.  How is knowledge transferred from person to person within an organization?  What motivates the transference and the transferors?  

Bock et al have used the Theory of Reasoned Action (TRA) as the framework for their investigation.  I had to look this one up, as usual for me.  TRA, as it turns out, is a way of studying behaviors in terms of the attitudes towards behaviors. The current TRA framework was developed by a couple of guys named Fishbein and Ajzen in the late 1960s.  From my research, it looks like TRA has been used for a lot of behavioral prediction and control work, including marketing.  Fancy that.  

Another thing I found interesting that I need to validate, is Bock's (et al) definition of knowledge management as "the process of capturing, storing, sharing, and using knowledge", where Bock et al reference Davenport and Prusak's work from 1998.  

Since this is a holiday weekend, I'll make this pretty short.  

The unexpected result of Bock's (et al) study is that extrinsic motivators, like pay raises or promotions, actually impede the transfer of knowledge from person to person within organizations that they studied.  So, the willingness of an individual to transfer knowledge to his or her colleagues comes essentially from within, depending on how it makes them feel about themselves and how they perceive their colleagues feel about them.  I realize that the culture they conducted the study in was Korean, but I think it might translate pretty well to nearly everywhere else in the world.  

I think Bock et al could have included some graphical data representations for their data.  LIsts of numbers are not really meaningful for me.  I like to see charts and graphs, especially when a data analysis method like Partial Least Squares is used.  

Overall, I thought it was a pretty interesting study.  It contradicted what I would intuitively would believe motivates transference of knowledge within an organization.  

I really got into this article.  It has a lot of things going for it, including the authors letting us know up front what kind of article we were dealing with:  exploratory, interpretive case study research.  No guessing here!

Suzanne Pawlowski of LSU and Daniel Robey of Georgia State went into a company they call ManDisCo to investigate the phenomenon of knowledge brokering by IT professionals.  They conduct interviews among the IT management, primarily.  There are 23 interviewees (contributors) of which only 4 are “front line troops”.  The grunts are never quoted in the case review, either.  It’s only Managers, Sr. Managers, Directors, and VPs.  The problem I have with that is the skewdness of the perspective that the investigators are receiving.  Let’s face it, upper management folks are pretty political.  Otherwise, they don’t last very long in their position.  I’m sure that since they knew the information from the interviews was going to become public knowledge, they wanted to ensure that their company and their job functions were presented in the best light.  It’s also amusing that the last question in the interview guide is asking the interviewee for other people in the organization the should be interviewed.  

Another reason the responses of the contributors is suspect is because early on in the study, it is reported that IT people become business people in order to perform their jobs.  This is a very idealized state, if it really occurs at ManDisCo.  From the early days of Yourdon and DeMarco’s analysis and design methodologies, IT people have been encouraged to participate in the day to day activities of their end users.  However, two things have often prevented this:  IT people don’t like business processes and business people don’t understand IT people very well (Moss, 1984).  The description of the Environmental Information System is more typical.  You get managers who depend on one system (Boundary Object) for their departments and they can not communicate, and in some cases, they will not communicate.  

I also find it difficult to believe that IT professionals are the source of knowledge for business rules for the rest of the enterprise.  The authors state that knowledge transfer of business rules and processes emanates from IT because the turnover rate in the business is so high.  It has also been my experience that business workers are more prone to remain in their jobs than IT folks.  IT turnover has been notorious since the 80s (that I know of) for programmers, analysts, and even managers leaving for greener pastures on a moment’s notice.  I believe that the longevity of an IT staffer’s employment was a little over 2 years up until very recently.  Contrast this with business people that stay in their jobs five, ten, or twenty years at a time.  

Other than the above stuff to pick at, I did find the study interesting.  Although, as I said, I would prefer to concentrate on the “worm’s eye view” as opposed to the Ivory Tower of upper management.  

A subtitle for this entry might be "Truth in Advertising:  Does It Exist Anywhere?"  

I've had second thoughts about posting this, but in the interest of saving my classmates and their families any unnecessary grief, I'm going to do it anyway.  

I just had an interesting and disturbing experience with my son, Andrew, and the U.S. Army Recruiters stationed at CalState Fullerton.  Andrew is 20 and a junior at CSUF.  Somehow, he met one of the Army Recruiters on campus and began the "sales cycle" of the modern Army.  Within a couple of days, Andrew had been convinced to go in for a physical and sign up for an 8 year obligation with the Army ROTC.  And here's where it gets disturbing....

Andrew was told repeatedly that he was only going to be signing on for 4 years, even after the recruiting sergeant, who came over to visit with us at the house on Saturday night, admitted that it was not 4 years, but actually 8 years that he was fully obligated to do the bidding of Uncle Sam.  

Not only term of service, but other distortions surfaced after we mentioned that Andrew was joining ROTC.  

The Sergeant told us that if you have a change of heart between the time you swear in and the time you ship out that you can simply file a paper and get out of the commitment.  Not according to Army documents that are available to the public.  You have to ship out unless you have a verifiable medical or mental condition, become a conscientious objector, or declare yourself to be homosexual.  It's not just a piece of paper.  

Andrew was promised that his education would not be interrupted, even if he opted for grad school after receiving his bachelor's degree.  Not true.  ROTC cadets will probably be deployed after undergraduate graduation, regardless of their graduate school acceptance.  

ROTC cadets are guaranteed the job of their choice in the Army or Reserves.  Well, almost.  There is a finite possibility that if you sign up to be a computer technician, you might wind up carrying an M-16 and hunting for Osama or detonating IEDs in Baghdad.  It depends on where Uncle Sam decides you're needed most.  

The list goes on, but the most important and disturbing fact is that the Army will not allow you to see the "contract" that you will sign at your swearing in until after you have sworn the Oath of Service.  In other words, you make a commitment in front of witnesses and then you get to see what it is exactly you committed to.  I found that to be the most frightening and disturbing situation of all.  I won't even buy cookies without being able to read the label.  How can they expect someone to make a life-altering decision like joining  ROTC and possibly being sent tot he front lines without reading the contract?  

Andrew had the good sense to decline the swearing in once he had been presented with all the facts by both sides.  And I don't see this as a matter of being patriotic or not.  I see it as a matter of having someone apply high-pressure, used car sales-like techniques in a situation that is quite literally life or death.  This whole experience has just been very disturbing.  It gives caveat emptor a whole new importance.  

E. Burton Swanson and Neil C. Ramiller, hereinafter referred to as 'Swanson et al', have written a research essay with the purpose of mindfully directing the discipline away from mindlessly researching IT innovation.  Swanson et al seem to have exercised their know-who to enable the contextual know-when of the publication.  I have no clue as to whether or not what I just wrote makes any sense, but that's kind of how I felt while reading most of this article.  

I get their point(s).  I would like to research some of the propositions they have suggested, myself.  But I obviously think that some of the language in this paper is needlessly jargonistic.  Now that I've gotten that off my chest, the matter of content comes to the fore.

Swanson et al explore two concepts in depth with an incredible amount of supporting literature: Mindfulness and mindlessness.  They approach these concepts in the context of an organization.  Mindful and mindless companies both appear to behave with a herd mentality.  It just depends on which herd they belong to at any particular time.  

Mindfulness, it seems, is the terminology that Swanson et al have coined for what I term prudent management of Information Systems.  Mindful organizations are cautious.  Swanson et al seem to imply that mindfulness goes beyond caution into the realm of pessimism.  

Swanson et al characterize mindlessness, on the other hand, as the other extreme attitude.  Mindless organizations throw caution to the wind and "jump on the bandwagon" for every IT fad that comes along.  

In actuality, there is a mix of mindfulness and mindlessness that are needed to allow organizations to begin innovating with IT.  Just as there is a cyclical pattern in fashion (for instance – never throw away a tie; that width will be back in a few years!), technology and the attitudes toward technology, especially among technologists, is cyclical.  These cycles are driven by alternating enthusiasm and caution.  

Lastly, I want to also explore the subject of Computer Assisted Software Engineering (CASE) that Swanson et al raised in the paper.  I remember the CASE craze very well.  I never saw it as being abandoned.  CASE was transformed by a paradigm shift (!) from Structured Software Development Methodologies into Object Orientation's Unified Modeling Language (UML) with a new set of tools.  Those tools include Rational Rose (now owned by IBM), MagicDraw (by a company called No Magic, Inc.), among many others.  Even Oracle has added UML elements to its Developer 2000 product.  While it's true that many companies bought into the CASE mystique during the '90s, and many companies did so because they felt they were behind the times with modernizing their software development know-how, it was my experience that CASE, in knowledgeable hands, did indeed add efficiencies to the development process.  CASE was no magic bullet (ergo 'No Magic, Inc.'), though.  I never saw a system developed entirely with a CASE tool with no manual intervention, as was claimed by several CASE tool vendors.  However, to say that CASE was abandoned is incorrect.  

Being mindful of the know-when-to-quit-while-you're-ahead context, I believe it is time to end this mindless monologue!

I'm actually trying to capture some of my "fond" memories of past projects before my memory turns to mush!  I find that reading the articles and books assigned for IS360, as well as IS328, tends to churn some of those memories as I connect with the cases that the authors are reporting.  Kind of an interesting phenomenon.  

Ok, I'm going to bore you with some more memories of my first paid IT job in Munich.  I actually found the URL for the company:  http://www.tns-infratest.com/index.asp  It looks like they're still in the same building in Munich where I worked from '73 - '75.  Of course, the company has grown considerably, with branches in five other cities in Germany.  The TNS in the URL also stands for Taylor Nelson Sofres, another research company in London that Infratest is somehow affiliated with.  That, of course, means that the website has most of the material translated to English, too!  Anyway, I'll figure that out eventually.  

The important thing is that reading Robson reminds me so much of my time at Infratest!  I never, never would have dreamed that I would be contemplating designing and running my own research studies.  (To refresh all our memories, I was hired by Infratest's EDP department as a computer operator trainee.  My first task was to translate documentation for a newly purchased computer system from English to German as best I could so that the programmers and supervisors would have reference material to work with.  I got that taken care of and started work on the technical portion of my job description when the effects of the Oil Crisis cost me my job.  I think it worked out ok, but it didn't seem that way at first;-)  So back to Robson.  I'm reading about the design of questionnaires and how to interview subjects and how to code open-ended questions when I'm reminded about how I tried to score some brownie points with the Boss.  (Turns out, that's not something anyone does in Germany – or at least not back then.)  I took a sampling of some completed questionnaires home to work on – about fifty, I think.  I was supposed to make a list of common responses to the free response questions and the frequency of the responses.  Then I was supposed to pick out the top six answers and assign number values to them.  Anyway, it turned into a disaster.  I either didn't have the cultural background to make the correct choices or we picked up the wrong samples out of the returned questionnaires.  Whatever happened, it was a mess.  The study's PM was upset with my boss and he was upset with me.  That was the last time I tried that!  I do remember that the study was about the acceptability of something brand new that resembled a wine cooler!  Nobody like it :-  It was shortly thereafter that I was laid off because our customers were reducing their research into the desires of their customers.  Thank you, OPEC!  

So, this little bit of reverie has elements of Robson and Walsham in it with the culture clash, work ethic differences, some project management, coding, etc.  

Well, like I said, just writing it up before I forget stuff.  I should probably do this in SISATSpace, too, huh?  

This article was authored by Geoff Walsham of the Judge Institute of Management at Cambridge.  That at first struck me as a bit unusual, until I remembered that I'm in the Information Systems discipline, which is involved in the management of Information Technology as well as its creation.  

Geoff is using a sociological theory called Structuration to explain the behavior of software developers and users on a couple of implementations where there has been something of a culture shock wave rippling through the developer and end user communities.  Or perhaps Geoff is using the cases to support and confirm Structuration theory?  Even with a second read, I haven't really been able to establish which way it is meant to be in my own mind.  

In the first case, Geoff has found probably the most interesting software implementation project ever:  software development in Jamaica using a combination of indigenous developers and personnel "imported" from India.  What a contrast! (Pardon any semblance of political incorrectness in what I am about to post;-)  Indian programmers are some of the most diligent workers in the IT discipline.  And the Jamaicans that I have known – no IT types among them, unfortunately – have been so-o-o laid back that I look like I'm working hard.  

The second case was about an American team trying to implement a Geographical Information System for mapping natural resources for the Indian Ministry of Environment and Forests (MOEF).  This was an attempt at technology transfer from the U.S. to Indian scientists who could have used a GIS mapping system.  

In addition to the "been there, done that" stuff that I could definitely write here, I have a couple of burning questions that I would like to pose rhetorically.  The first question is,  where did Geoff learn about Structurational Analysis and the potential for applying it to failed software projects?  Secondly, how did Geoff get the idea to write up a couple of cases that (from what I read) had already been reported on before using analyses other than Structurational Analysis?  

I remember a rather facetious classroom discussion of multiple publications of the same studies with slight modifications or an additional phase of data collection or whatever could make it different.  The creativity essentially became figuring out how to use the same "stuff" and get it published again.  This article might qualify for that category!  

I also had a discussion with some of our esteemed classmates about whether or not, based on the classroom discussion of criteria, this article qualifies as IS research.  After contemplating the conundrum on the drive home, I now answer with a qualified yes.  While it is true that most of the culture clashes reported here could have occurred with the installation of new curtains (anything!), there are certain personality types that are involved in IT development projects that render them special.  I believe that the IT artifact is in fact the combination of IT workers from very different cultures.  This combination is something that IT must now deal with on an every day basis.  

If there's anything to pick at so far in this book (and I am by no stretch of imagination quite caught up with my reading;-), it is that the mathematics is glossed over for the most part.  I have looked ahead to see how the math is dealt with in later chapters and, as a former math/physics/stats nerd,  I really think Robson needs to at least show the math relationships a little more than putting a curve into a figure and saying, essentially, "There it is!"  

Well, I was going to launch into a lecture on figuring out the sample size, but I dragged out the old books and found everything I needed on page 334, right there... But explaining the "z-number" calculation, the Standard Deviation, and the Confidence Interval turned out to be more than I'm prepared to do tonight:-\  If anyone needs assistance with this, I would love to review it with them.  I obviously could use a refresher!  

BTW, my book is "Elementary Statistics, Fifth Edition", by Allan G. Bluman, published by McGraw-Hill.  I rarely dispose of books dealing with Math.  They seem to always come to the rescue down the line!

This book also talks about the Hawthorne effect, discovered in 1924, at the Western Electric Company in Hawthorne, New York.  The author didn't go into much more detail than Robson.  He just mentions that "subjects who knew they were participating in an experiment actually changed their behavior in ways that affected the results..."  Who says Junior Colleges aren't any good?!!  (Just kiddin', folks!)

Well, hopefully, I haven't stuck my foot too far into my mouth.  Thankfully, they are low carb!  Good night, all....