Use the window below to chat with me (if I'm online ...)
Use the edit nick field above to let me see your name.
cazh1: on Business, Information, and Technology
Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Tuesday, August 05, 2008
Where to Start? (1 of 2) Process & Procedure
Where to Start? (1 of 2) Process & Procedure
If you need a one-slide, three-bullet, PowerPoint special for describing the basic tactics for "How to Achieve Operational Excellence", try these:
Process and Procedures
Metrics and Measurements
Continuous Improvement
The first two are nicely alliterative, but you might consider substituting Standards and Processes as your lead-off if we're talking about an IT, Finance, or Engineering department.
Now What?
Of course, now you have to generate the details; the "motherhood and apple pie" routine only lasts thru the first meeting. Here's where many organizations discover that it's hard to know where to start. Most people find a blank sheet of paper intimidating; they prefer editing to creating. Also, folks are easily overcome by the volume and complexity of all of the processes they go through every day.
<aside> And for some reason, people seem to gravitate to the most difficult thing to document - "experience". It's like whistling - hard to describe on paper, but easy to demonstrate, with multiple variations and endless complexities. How can I possibly convey my thought processes when I'm debugging a system, triaging a set of problems, or pulling together those first few critical design elements?
Well okay then - let's not think about that right now. We'll talk ourselves out of any process documentation before we even start! <aside>
Start Simple
For every job, there is a recurring list of "stuff" that folks do every day - administrative and busywork tasks that must be done, just to keep the wheels turning. This is the kind of "process" that lends itself very easily to documentation (and, afterwards, automation, but that's another post). It's the little things that you do, unnoticed until you take a vacation day or call in sick. All of a sudden, things stop working or start breaking, because you weren't there to reboot the server first thing in the morning, or clear a cache, or check a job queue for stuck items ...
So a great place for your team to start is to build a ToDo list of repeating tasks. It can be a simple text file, a Word document with nice formatting, a spreadsheet with convenient rows and columns - it really doesn't matter. My personal favorite is the spreadsheet - I use tabs to break up the lists into nice sized chunks ...
Click on the picture for a full-size image!
I've posted a few simple files on my Source Code page:
There are some nice features in the spreadsheets - like color coding for when a task is done (x) or undone (o). Also, the current day, week, month are highlighted automatically.
Collaboration Suggestion
If this idea makes sense, consider skipping the documents / spreadsheets, and create this as a wiki page (or collection of pages). Then, the entire group can add their recurring tasks - and the group will develop a shared master list. This makes it much easier to encourage shared tasks, standardization of work, etc.
Note: Does this structure remind you of 43 Folders and Getting Things Done? Well, that's definitely in the ballpark, but GTD focuses more on personal productivity. Daily / Weekly / Monthly Process Lists add structure and enhance productivity for a group. If you can scale the ideas in David Allen's book to help an entire group - and make it easy for folks to join and leave the group - go for it!
Some Task List Best Practices
Tasks on the lists should be one-liners. "Reboot the Server" or "Empty a Job Queue" are great, but if a single task actually has a series of process steps involved, best make that a separate, more detailed task list
Continuous improvement and ongoing documentation are themselves recurring tasks; consider putting a task to start each day thinking about items that are on your plate today that could/should make this list
The sample spreadsheet features the color-coded "checkmarks" that indicate when a task is complete. If you use a wiki (like TiddlyWiki), there may be plug-ins / extensions (like this one) that allow you to put checkboxes in the wiki itself. Checking the box when something is complete makes you think through each process step-by-step; if you just scan the lines every day, it's easy to slough them off. Plus, it's psychologically satisfying to see all those unchecked items get crossed off the list!
posted by James P. MacLennan at 9:51 PM
| Permalink
|
|
Tuesday, July 22, 2008
Enterprise 2.1: Exiting the Trough of Disillusionment
Enterprise 2.1: Exiting the Trough of Disillusionment
"What will you do with that car if you actually catch it?"
-- what the cat asked the dog (from the Chicago Reader, circa 1989)
So you've gone all "Enterprise 2.0", spinning up a wiki, a blog, and a SharePoint or Drupal server inside your firewall. Now what happens?
The groundswell of interest in "cool tools" brings a wave of users and a burst of feed reader activity - for a few weeks. Before long, however, the organization will get some rush orders, a month-end close, a project deadline, and/or a few vacations on the team ... and the same old excuses begin to weasel their way into the conversations. Folks begin to realize that collaboration and participation is more than reading (I actually have to type something into this thing?). Management styles are tested, and we find out if KM can be pushed on or pulled from the group. The questions start on a familiar note ...
Why?
The classic pushback against documentation; we see no immediate value added. When I'm programming or implementing a system, I'm making stuff happen; when I'm documenting, I'm only creating files that no one reads (and some ambient white noise for my cube neighbors). Of course, if there's only one person in the department that knows how the system works, and if they happen to be out on vacation when a problem arises, it's all hands on deck and a general scramble to figure out how things work. Imagine your consternation when you find out it's a five-minute fix ... if only they had written something down ...
There's also the career flexibility issue; if you're the only one that knows how something works, you'll never be able to move to the next interesting technology - stuck maintaining the Unknown System. Unfortunately, a plea to the value of Future Flexibility doesn't help when you're dealing with someone who likes to maintain control over the Predictable Present. Sooner or later, the benefit of getting rid of their inflexibility far outweighs the cost of reengineering anything ... it's just delayed pain.
Who?
Another classic question (who is supposed to write this stuff? Not Me!), with a contemporary twist ... the collaborative tools allow us to quickly broaden our audience/author pool, including folks outside of IT. In fact, this is a significant difference from fads gone by - non-IT folks are getting exposed to collaborative documents on publicly available, open environments like Wikipedia and Google; it's getting easier to talk to a growing number of people about interacting in a collaborative environment; the team isn't limited to the techies any more!
Which?
A much more important question - which platform should we use to capture this knowledge? When do you use a blog versus a discussion forum? Will I wiki, or should I SharePoint? Choosing IM over eMail is easy, but when should I tweet instead?
If you're working on this question, it's actually a good sign - folks have enough hands-on to understand the good and the bad about a variety of collaboration media. Experience is your best guide here; wiki's are great for fast entry and immediate distribution, but (IMHO) it's difficult to maintain a table of contents, index, or any multi-chapter / multipage chunk of knowledge. At home, I'm building the fifth generation of my home software development environment, and I've already passed over my personal wiki tool as unsatisfactory. Too many processes and interlocking technologies surrounding the servers, development environments, and push-to-production processes. It's much easier to create an actual Administrator's Guide (sample); a formal document with table of contents, chapters, diagrams, even page headers and footers. If I bothered to print it out, it'll look great - but I don't care about the paper. I like the structure that a book gives me - this is broad collection of information about a set of technologies and processes required to do one basic thing.
Each of the different Web 2.0 / KM tools has different strengths and weaknesses - flexible info structures, formatting efficiencies, ease of distribution, and support for collaboration / version control. The light will come on when you understand your biggest problem is collecting the knowledge; presentation, distribution, search, and sharing are covered nicely by the various intranet technologies, but the magic is in the making.
Doom and Gloom - and a Silver Lining
Disruptive technologies come and go, there are no silver bullets, and there's always a problem somewhere. If the environment is user friendly, it won't scale. If users accept the concept, they won't have the time to create content. If you can get all of these budding authors to write prose that is readable, you'll struggle with making it findable.
But hey - we're trying to pull out of this "trough of disillusionment" - so focus on the things that Web 2.0 does well ...
Lowers the technology bar for collaboration - all you need is a browser!
You're not introducing new ideas, you're just making them work within your company
Widens the author pool (and experience base!) for knowledge capture
... and focus your attention on the "next version" (2.1) - practical questions of why? who? which?
posted by James P. MacLennan at 8:46 PM
| Permalink
|
|
Friday, July 11, 2008
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
If you are involved with manufacturing these days, you've no doubt heard about Lean Manufacturing. I'll not go deep into this area here, but one fascinating (for me) aspect is the thread (in some quarters) that ERP and computer systems are the enemy of Lean. On the whole, I don't disagree - process improvement, kanbans, and attacking muda are typically very physical exercises; roaming the floor, walking through the processes (gemba walks), reorganizing workspaces for flow, designing and simplifying standard work - all very visual, participatory efforts that continue over time (constant improvement). Computer systems can just get in the way - metrics and measurements that require extra data entry, or inflexible processes that can't be changed quickly. Much of Lean thinking is common sense and practical, applied thought - computers can over-complicate things!
However, it's that visual, participatory nature of process improvement that can be something of an obstacle, especially if you're working in an extended organization with many locations. It's difficult to gain insight over the assembly process unless you're standing at the bench, twisting and turning to reach for components. It's hard to design practical speed improvements for changeovers if you aren't there handling the tools / molds. And it's often extremely difficult to get the folks who know how to do this stuff (operators) to effectively document their work!
Enter the YouTube idea (which I freely admit is not my own, but the originator has no problem sharing his insights). Travel budgets are shrinking, time away from the shop is tough - but all I need is a 5 minute show-and-tell of a process. Why not a quick video? It's hard to describe how I can easily, visually manage WIP until you stand in that one key spot on the floor, and see how the sight lines to the various workstations all line up perfectly. Why don't I just show you ...
What about Twitter? Well, eMails, blogs, and wikis are really just fancied-up documentation tools, and nobody likes to create documentation. But Twitter can be terse, instant, and informal - not too intimidating for the itinerant author. Heck, sending tweets about ideas and observations on the job would be very much like sending text messages from your cell phone, an increasingly common, popular, and non-threatening task. The bonus, however, is that Twitter traffic can be broadcast (unlike your typical point-to-point text) and saved to a database for further review and insight.
Now, the public YouTube and Twitter sites are probably not the way you want to implement these ideas; much of what we're Tube-ing and Tweet-ing is company confidential. Corporate IT should get involved - either host it yourselves or properly vet a third party site for access & availability, storage & security.
... finally, a chance to walk into the COO's office and say "tweet" with a straight face ...
Interested in more Lean Manufacturing resources? Here's the best of what I've found on the 'net ... check 'em out!
posted by James P. MacLennan at 1:58 PM
| Permalink
|
|
Sunday, July 06, 2008
Don't Accept Snap Answers Too Quickly
Don't Accept Snap Answers Too Quickly
A few years ago, I was working on an interface project, and wanted to have the ERP system send copies of any and all transactions that have changed over the past few days. I've done this before on other platforms, so I asked the lead developer what I thought was a no-brainer request:
Do the transaction files capture a date/time stamp somewhere in the record, each time the record is modified - DateLastUpdated, something like that?
His answer came back almost immediately ... No. Well, I guess this is possible, but we're working with a fairly up-to-date ERP, and I've worked with enough systems and data bases to know that many/most applications timestamp their records when updating, or maybe write changes to a log file of some sort. And the answer came back just a tad too quickly ... so I asked the question again, but this time I took some time to preface my question with an apology (of sorts) ...
I mean no disrespect, I am fully aware of your experience and skill on this particular platform - but I need to be clear, because I think I'm asking for something that's fairly basic.
I just need you to be a tad more specific when you say 'the system doesn't do that'.
Is it more accurate to say 'I have never seen the system do that' or do you know for a fact that that the system cannot do that?
It's a subtle difference, but it's important to drill into this level of detail. Most of us are pushed for time and quick to come up with the fast answers, so we can move on to the next item in the todo list. Answering off the top of our head is a pretty normal response, I do it a lot myself, but this was a pretty important feature request because the lack of it meant a ton of additional work in other areas. Besides, I'm humble enough to know there are many features and functions in any platform I've ever worked on that I don't fully understand - never had the need. Plus, I don't see a ton of wildly original thought and unique features in many of these system that we work with. In cases like this, I'm asking for something that I've seen in another platform, assuming that the author of this platform was a reason intelligent person and has added that same basic functionality.
Truth be told - in this instance, the transaction file in question did not have a DateLastUpdated field, and we had to look at transaction logs to get the information we needed. Still, the developer in question had little problem with my pushback; he readily acknowledged that he did not have the layout of this particular table memorized, and had never heard of such functionality - but the concept made sense, and he was happy to look. Besides, if his snap answer was wrong, it would have saved him a ton of work ...
Drilling into the specifics like this (do you know No, or do you Not Know?) applies to more than just software developers. Engineers lawyers, accountants, sales reps - many folks from across the business are faced with questions that they try to answer from their Experience, hoping for the Quick Answer. It takes some confidence to question the "local expert" - but if the right questions saves a ton of effort, searching for a workaround - well, that's an excellent question to ask.
posted by James P. MacLennan at 9:53 PM
| Permalink
|
|
Thursday, June 05, 2008
Opportunistic Insights from the RSS Stream
Opportunistic Insights from the RSS Stream
I've written about using RSS for internal as well as external information sources. This past week, I found a couple of interesting tidbits in my feed reader (behind the firewall) ...
1. Eyes on the Skies: It's that time of year again; oil price volatility will continue if any big storms create problems for refineries in the Gulf - something new to keep an eye on. Never fear - our friends at NOAA kindly put out an RSS feed for storm details - here's the latest graphic on Tropical Storm Arthur, the first of the season. You can keep track of incoming storms using this RSS feed - at the very least, you can be first on your block to know the name of the next storm ...
Some of the responses to this original item pointed out the need to watch the tornado forecast as well put and potential impact on manufacturing plants and/or shipping lanes. There are many different ways that weather can impact the supply chain ...
New applications in the automotive and electronics sectors will drive the growth, although packaging will remain the dominant market. This is despite its share forecast to fall from 65% in 2007 to 40% in 2025.
I took this to mean that packaging is the dominant application of bioplastics, and will remain so. However, the future will see multiple other applications for this material emerge. More applications means larger markets, more innovation in the basic material - which is better for all plastics manufacturers.
3. From Rumor to Fact: One of the project managers recently added (1234) Project XYZ to our PMO database - I found out when the items popped up in my feed reader. That's how it's supposed to work ... Actually, my first reaction to the project was that the description (jpm note: we call it a "mini_charter") was a bit thin. But then I read the first comment, and there's definitely more meat there. At this time, Project XYZ is a multi-headed mystery monster - there are initiatives, teams, projects and such in multiple areas of the company. Clearly, more details to follow - but now we have a validated source of information for at least one of the BU's!
Show vs. Tell
These were my insights for the week, but a number of folks have told me of their own Aha! moments, watching project updates aggregate on their desktop via RSS. I suspect most folks reading this would think little of my "insights" - but that's because we understand how RSS works. To the rest of the world, websites are proactive (I have to go to them) while e-mail inboxes are reactive (the information comes to me). RSS and feed readers turn that paradigm around; once you see it in action, you get it immediately. But it's enough of a phase shift that sometimes explanations and PowerPoints aren't enough. Timely, relevant, in-context examples such as these just click.
posted by James P. MacLennan at 10:42 PM
| Permalink
|
|
Thursday, May 01, 2008
RSS: Underappreciated Web 2.0 in the Enterprise
RSS: Underappreciated Web 2.0 in the Enterprise
We added RSS capabilities to our internal PMO systems this past month, and traffic & content is already building up to become a valuable resource. Some have [correctly] noted that this increased visibility puts a bit more pressure on project managers and team members, to keep updating project blogs with pertinent information. This "time shifting" of communication should develop into the most effective way to let the rest of IT know what is happening in all areas.
There are some very interesting threads and conversations going on ... for example:
One Supply Chain systems team informs us of process improvements in product development - nothing to do with IT, but interesting nonetheless
Another team is putting together ideas that will take some significant IT costs out - that's a very active thread
The SAP application team is debating with the Basis team on the merits of a Unicode upgrade - and onlookers from Supply Chain Planning and Data Warehousing are noting dependencies on Unicode in their platforms
These spontaneous, organic, and very impactful "conversations", between people still experimenting with a new technology, show me real potential for spontaneous innovation and idea sharing. More evidence of the value of [judicious] experimentation with new technology - no silver bullet, but just enough spark to start a few fires.
Interested in learning more about RSS? There's lots of good reading out on the Internet ...
Voyage is an imaginative RSS-feader which displays the latest news in the "gravity area". Interesting navigation - I don't think this is practical for internal use, but it sure looks good!
Newsmap translates news feeds and frequeny to a variable bar graph approach.
Universe DayLife is, well, spacey. Translates the universe of news and connections to stars ...
posted by James P. MacLennan at 7:48 PM
| Permalink
|
|
Tuesday, April 22, 2008
No Silver Bullet for Group Collaboration over Distance?
No Silver Bullet for Group Collaboration over Distance?
Lots of organizations have to deal with the challenge of implementing standard work and best practices over physical distances. With sales offices, distribution centers, and manufacturing locations scattered across the country, what's the best way to get people who know their stuff to collaborate on process improvement - and then take that knowledge back to their home office?
While wrestling with this challenge, one executive I know preemptively ruled out videoconferencing. It's a common suggestion, but the general feeling was that it's just not useful, has never proven itself in practice.
I happened to agree with the idea that videoconferencing wouldn't help in this situation. The team was talking about productivity improvements for an assembly process - workstation layout and hands-on participation was required to effectively work out the wasted movements. However, when defending the No Webcams position to some gadget freaks around the table, we came up with a/the fundamental flaw with remote video: it lacks spontaneity.
Historically, videoconferencing was set up in specific rooms that had to be reserved in advance. For higher quality connections, equipment is expensive, and the expense had to be pre-approved. Advances in digital cameras brought devices mounted on desktops, but this tied you to that specific location. Today's nifty notebooks have built-in cameras, but these can be tough to use with a group of people (crowding around).
Yes it's possible to use videoconferencing, but the physical limitations tend to quickly dim the excitement of all but the most diehard tech fans. In practice, local process improvement teams would just walk over to the workstation in question, skull out the best way to do something, and take a break for some coffee by the time we had the webcam hooked up ...
Lack of spontaneity is probably why the vast majority of PowerPoints are delivered with printed decks, and not overhead projectors. It's still more time efficient to quickly print off a few copies than it is to chase down a projector, lug it and your notebook computer into a conference room, get everything hooked together, and try to remember how to switch to the external monitor. (Hmmm, good thing they added all those cool slide transition effects ...)
Truth is, having paper copies isn't all that bad. Some folks like to take notes on their handouts and file them away for future reference. The medium of communication has its own utility, a sort of residual value that most people understand how to use. The same is true for fancy collaborative technology like videoconferencing. The magic is in the actual conversation, but that can get lost in the struggle to get the technology working before you can actually use it.
Does this mean that collaboration technology is doomed to failure? Of course not - knowledge capture and reuse, and differences in physical location and time zones, are still problems for organizations that rely on the "old way of doing things". You just need to pick your tools judiciously, and build up to the fancy stuff over time.
Wiki's will not work if people don't already have an interest / desire / skill / method for creating documentation. Wikis solve distribution and access problems, but they don't make people suddenly want to write.
Blogs will not work if people don't already have the need to communicate while competing for people's attention. Blogs solve time and distance chanllenges and facilitate simple Q&A, but they don't automagically endow authors with reader empathy.
Collaboration Spaces will not work if people don't already have the need to share documents and edit them within a group. Collaboration Spaces solve version control and tracking hassles, but they don't help groups create impactful documents where none existed before.
We needed to see productivity improvements in component assembly within 60 days, so flying a couple of key people around the country was a small price to pay for the quality of work that we got. We took a small step forward - getting process experts to a different location, to put faces to names, and empathize over common challenges, experience the satisfaction of defining a workable solution - and experience the joy of business travel. Maybe next time we could look into videoconferencing, because interpersonal relationships and understanding of the power of shared best practice has already been established.
posted by James P. MacLennan at 10:59 PM
| Permalink
|
|
Friday, April 04, 2008
Branching Out: Writing for the FEI Blog
Branching Out: Writing for the FEI Blog
Yet another interesting way that the Internet has broadened my connections and collaborations ...
After connecting over LinkedIn and exchanging common interests via e-mail and blog post, the fine folks over at The Front End of Innovation blog asked me to do some posting there as well. They have a different posting style - shorter, a bit more volume than I can generate, and definitely focused on innovation (I know that I wander across many different areas of IT and business). However, I've got a series of post ideas I'm working on in the area of "innovation" - defintely a buzzword for 2008. I should easily be able to cross-post between the two.
Be sure to check out the other authors at FEI - interesting stuff, definitely worth adding to your blog roll!
posted by James P. MacLennan at 9:55 PM
| Permalink
|
|
Tuesday, April 01, 2008
The Innovation Generation - Communication Styles
The Innovation Generation - Communication Styles
There've been many articles in recent weeks about the tech-savvy Millennials and their impact on future work. I concede, even welcome the changes that business will need to introduce in response to these new expectations, but I don't see the massive change that some writers seem to think is inevitable. The world will not change to accommodate the Millennials, but relevant and effective new working styles will definitely be adopted where they make business sense.
I will certainly agree that communication styles will change. For example, there will be a greater reliance on (and expectations of) instant and ubiquitous connections - with people, information and technology. IM is already on the way out, and texting is the way to go; my high-school-aged daughters think nothing of racking up thousands of text mails every month.
Unfortunately, this kind of freewheeling message content is going to run headlong into the litigious real-world. Many companies are still struggling over records retention standards and expectations. Public companies will need to maintain some control over messages that could contain proprietary or inside information. Corporate survival and protection from liability are clearly not on the minds of students as they post embarrassing pictures on Facebook pages, and even adults get trapped by unfortunate text messages that come back to haunt them.
Don't get me wrong - I'm a huge believer in alternative messaging styles and flexible collaboration. I've managed and/or participated on multiple "collaborative" teams - people from different companies, zip codes, time zones and countries. Separation by time and space has been a business challenge for years, but you could set up a shared FTP folder, or swap e-mails about projects, as long as I've been working. The teams that succeeded understood the differences between working across the hall and working across town, and moderated their communication styles accordingly, using the best tools available.
The value the Millennials bring is a de facto openness to collaboration tools. To them it's not something new that they need to learn; they expect the rest of us to already be there. Their rude awakening will come when they need to invest some change management time getting us "old folks" to catch up to their fast twitch messaging style; they won't be able to pass us by because we've got the organizational and process knowledge. (that's why we're on the team, right?)
posted by James P. MacLennan at 9:38 PM
| Permalink
|
|
Friday, March 28, 2008
Power Outage Follow Up - Observations
Power Outage Follow Up - Observations
A couple of hours after my last post, the power came back on in the building and all was right with the world. My dissatisfaction with Dell battery life was confirmed - I only got in about an hour of work before everything died away. It's clear that my current choice of notebook precludes me from a great amount of truly roaming activity.
On the other hand, I am finally switching from hardwired to wireless connections when in the office - even at my desk. I can switch buildings, work from home, etc. and never change my basic startup process for getting connected. It's a small thing, but I'm all about continuous improvement and the cumulative effect of multiple processs changes over time.
My most interesting insight came a bit later in the morning. After a few more folks got to the office, and there was nothing else electronically to do (thanks to the weak batteries), a small group launched into conversation on a project that was experiencing some issues. I noticed a palpable sense of relaxation while talking - driven, I think, by a unstated assumption that we had no nothing else to do. However, I think the fact that we had no pending distractions (meeting in 15 minutes, other work to get done) plus a severely limited potential for interruption (by phone calls or e-mails), and no diversion of attention (ie. typing on the keyboard while taking part in the meeting) was a significant productivity boost. The conversation was fairly robust and free-flowing - the ideas came easier, the alternatives made more sense.
For team productivity, there is definite value in getting away from the office and shutting off all connections. Freedom plus focus makes a difference.
posted by James P. MacLennan at 10:36 AM
| Permalink
|
|
Thursday, March 27, 2008
Thoughts During a Power Outage
Thoughts During a Power Outage
I am sitting in the cube outside my office, connected by wireless to our corporate network in an otherwise darkened office. The power is out - started around 3AM, and it is apparently affecting a large area, not just this building.
Kudos to the infrastructure team that strung up the wireless access points here - thanks for plugging them into the same circuit that is powering the emergency lights. not sure if that was by design or a happy accident, but coupled with notebooks running on their batteries, we have the ability to get some communication of status out to the world.
Some concerns about battery life, however - I use a Dell Latitude D620, and it is (in my opinion) really poor at power management. I expect to get about 60 total minutes of work out of the thing - kinda sad if you ask me.
No affect on my Blackberry - I am sending and receiving just fine. If you haven't checked out Blackberry Messenger, I'd look into it - definitely useful for sending out quick updates to key folks.
Not sure if it would do any good to call folks on my teams re: working from home - zero insight as to when the power will come back on. I just made an entry into my internal blog, so I suppose if they happen to catch that post (or this one!) before they come in, they can give me a shout on the cell phone to let me know if they are coming in. Use best judgement - if you had a meeting scheduled, for example, I would definitely come in, just in case.
I just spoke to someone who did make it in - another early bird like me. He heard on the radio coming in that this is affecting a big part of the area.
I tried to Google for a status update, but am not able to find anything. That might be something nice for Commonwealth Edison / Exelon to set up - definitely a shortcut that I would set up on my Blackberry.
This is definitely a case for Twitter - unfortunately, that's blocked by our network policy.
I'm having a bit of fun here, blogging at near-real time to capture thoughts. Part of continuous improvement and innovation is capturing learnings from any situation, so this is my great experiment on blogs as news delivery (as opposed to spouting opinions / capturing deep thoughts - my regular meme / schtick).
