I drove the three hours to get to there, only to get a “you gotta wait” message from my contact. I cooled my heels at the local Panera (WiFi access for free; all you gotta do is buy a coffee) for almost two hours before he finally called me up and met me.
Bad news: a powerplay by a competitor resulted in the work being lost. So maybe I don’t get everything that I ask for.
I’m not all that angry about it. I got a good listen to some CDs I’ve had for awhile, and I figured out a new take on why the Software Requirements Process almost always fails. I has to do with some basic knowledge concepts.
I was reading a response to Carr’s article by Fingar and Smith. Their discussion about how processes are tied up in applications and need to be set free struck a chord.
I put it together with Mike Hughes’s article on tech writers and knowledge management in Technical Communications. He cites Polyani, who describes the difference between tacit and explicit knowledge in The Tacit Dimension. Explicit knowledge is knowledge that is written down, codified, or even part of an oral tradition. It has been rationalized so that it can be put into words. Tacit knowledge, on the other hand, is the knowledge that comes from years of experience, so ingrained that you no longer have to consciously think about what you are doing to do it well.
The big “Aha!” for me was the these are all tied together. Since I’m putting together another article on it, I’ll not spill the beans here.
- Hughes, M. (2002) “Moving from information transfer to knowledge creation.” Technical Communication. Volume 49(3):275-285.
- Polanyi, M. (1966). The Tacit Dimension. London: Routledge and Keegan Paul.
- Howard Smith and Peter Fingar. IT Doesn’t Matter-Business Processes Do: A Critical Analysis of Nicholas Carr’s I.T. Article in the Harvard Business Review. [This is now book, but I found it as an article or excerpt, I can’t remember which.]