Some will be taken a bit by surprise to read the title of this post; we have implemented a wiki in our group at work, and I have the evangelist role in promoting the tool. Still, a recent "event" brought home the fact that wikis are not the silver bullets that some breathless articles may make them out to be. To be fair, Hickins' article does call out the "law of large numbers", although the idea is buried in the…
McDonald sent a nice comment on my last post - he's writing a lot about project management lately, and we even chatted about some research he's doing around boomer flight. Since I don't get a ton of comments, I thought I'd respond with a post, instead. He poses the question: I am wondering if documentation of the communications associated with coding and testing (emails, archiving of successive release of code, meeting recordings, archiving of test results, etc.) can in any…
I've had some flashes of insight on why technical folks don't like to document stuff. Currently, I'm thrashing thru a skunkworks project that is evolving into something that will need to be reasonably available, robust, etc. I'm also trying to lead by example; I ask my teams to build for sustainability and document so they can "walk away". Of course, I'm also lazy - I really don't want to explain things over and over again. However, the time crunch I…
Technical people are often engineers at heart, and really want to see controlled processes in and around their computer systems. We see source code control, configuration management, and process documentation as ways to manage long term maintenance costs and deliver repeatable, reliable results from our systems. In the realm of ERP systems, this would seem to be a common and well-regarded mind set; however, the businesses supported by these systems often demand information transparency, process flexibility, and quick turnaround of…
Conversations this week with folks in multiple, different organizations I have connections to, about formal change controls. The general rule, especially for the non-public companies, seems to be reasonable levels of process, but not as well documented, automated, and not as rigidly enforced as the more rigorous among us would prefer. It was interesting talking with the groups that were most frustrated; the developers will talk the talk, but find ways to get around the process when crunch time comes…
The outgoing intranet was nice, in that it gave content owners the ability to control what was visible / available. Unfortunately, we've come to discover that a number of corporate services areas (Safety, HR, Transportation, etc.) in our organization used the intranet but never took part of the content management (CM) - it all came "from above". Basically, these folks are about to get a "crash course" in CM and Knowledge Management (KM), albeit in small bites. When you read…
This week, we're kicking off a new project, implementing an intranet / portal for our newly independent company. I'm fascinated at how the "state of the art " has moved forward so much since the "old days" of the 90's. This is actually my third or fourth cut at an application like this (depending on how you define "portal"), and I'm sure it's going a bit faster simply because we're skipping over some portal design and admin process "dead ends"…