This is actually an old story, from a previous life, but I need to get back on the posting bandwagon. Way back in the day... ... there was a site on the public Internet with Company Confidential Information out there. The site was put together by an ambitious sales rep with some time on his hands, a few technical books, and a yen for something interesting to do. It was a nice little site, too - even had user ID…
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.
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…
Here's an interesting phenomenon I've encountered before ... When analyzing a specific section of a business, people seem to naturally focus attention and conversation on the top two or three customers/products/vendors that together represent (say) 20% of the revenues/costs/contracts. Our objective is to look at the data and identify opportunities (increase revenues, cut COGS, aggregate contracts); unfortunately, processing the data for these customers/products/vendors is currently a 100% manual task. Of course; this is why there is apparently so much "opportunity"…
I've been IM'g in a work atmosphere for over a year now, with internal and external folks, and still actively networking for tech info, support, etc. That peer group has a fairly well-defined set of etiquette, jargon, and style. In my new company, we are rolling out enterprise IM, and for most folks (including IT!), this is a "foreign language". (I'm "jpm1234" in the conversations below ...) Challenge #1: I think faster than I type, so I get a bit…
Why do some folks insist on answering questions with questions? Or, answering questions with roadblocks? It's not surprising when you hear IT complain about their inability to connect with the business, of not being included, etc. - and then demonstrate a style of investigation / requirements gathering / support / feedback that is a bit antagonistic. Business: How long would it take you to do X? IT: Why X? Why not Y? ... or IT: Why X? What are the…