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…
I'm writing an email to my favorite SQL guru, about a pretty sticky little problem I'm working on, and I found myself making up words ... In the LotesDB, comments / notes are kept in a single field. Each comment is time and date stamped, with a uname, so that's pretty predictable. The data in the field looks like this: 02/15/2002 03:46 PM (Steve Manager): Capital was approved on 2/11. Project Number has been assigned in SAP and server hardware…
Stories make our ideas real and relevant, and are helpful tools when introducing change. This article has a few examples of stories - all around the topic of introducing change.
Everybody jokes about TLAs and the proliferation of consultant-speak. My favorites to date include: SPOC - Single Point of Contact: During integration meetings between two merging IT organizations, SPOCs were identified as the key connection points between groups. Panders to the trekkies, but sticks in your mind. WOMP - What's On My Plate: The name of a report we developed in a PMO, listing issues assigned, projects being managed, open programming requests, etc. - one page per person. The WOMP…
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…
I've been hearing the term skunk works a lot lately, in reference to off-plan projects that are moving forward in all that "free time" people have in the IT department. Sometimes the term sounds slightly perjorative, but I like it when a project I am involved with is referred to in this way. The term's origin is well documented, no need to repeat it here. The Lockheed Martin folks made it famous, when referring to technology projects "on the edge"…
This week I had to wade into the depths of a Large Project; well, actually a component of a Large Project, that was struggling a bit to find a path through the forest. Not my first time, certainly not my last, and (believe it or not) usually a pretty good time! <aside> Ok, by "large" I mean "amazingly high profile, visible to Upper Management, involving Lots of Talented, Busy People" </aside> <aside> Ok, by "Talented" I mean "terrific at their…
Ok, don't freak out now ... All I want to point out is that the apparent need for screen prints of every step in the process is a bit overdone, especially when we're talking about technical documents. Screen prints / images in the documentation typically means the electronic documents get unmanageably huge, even if you shrink the .JPGs, and few people know how to do that. Plus, you indirectly commit yourself / your organization to a huge maintenance burden. because…
Trying to provide a simple, flexible search capability for your organization's reams of historical documents? Using a project process that generates the typical stacks of documents, databases full of status reports and issues, and other "stuff"? It's important to think about the knowledge we are generating, and the best way to capture that knowledge – and not worry too much about how we’re going to search through those deliverables. There is no one way to capture / store different kinds…