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 ...
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!
Previously ...
Technorati Tags:
best practice,
collaboration,
documentation,
Knowledge Management,
operations,
productivity,
tech management,
Web 2.0,
wiki,
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: collaboration, documentation, Knowledge Management, productivity, tech management, Web 2.0, wiki
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?
Previously ...
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
- Moving from Search to Find: Anticipate the Next Big Problem (April 16, 2007)
- More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
- Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
Technorati Tags:
blog,
collaboration,
documentation,
Knowledge Management,
people management,
Social Networks,
twitter,
Web 2.0,
wiki
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: blog, collaboration, documentation, Knowledge Management, Social Networks, twitter, Web 2.0, wiki
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 ...
2. Innovations in Materials: Another item made some interesting predictions on future impact of bioplastics.
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.
Previously ...
- Tracking patent submissions via RSS (June 1, 2005)
- Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
- Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
- More on (sic) experience with wikis (January 31, 2007)
- Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
- What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
- More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- Innovation That Matters - Substance Over Style (January 12, 2008)
- Butting In to the Conversation: PM Communication Tools (February 26, 2008)
- RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
- The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
Technorati Tags:
blog,
collaboration,
documentation,
innovation,
Knowledge Management,
PMO,
project management,
RSS,
Web 2.0,
wiki
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: blog, collaboration, Knowledge Management, project management, RSS, Web 2.0, wiki
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.
Previously ...
Technorati Tags:
best practice,
blog,
collaboration,
innovation,
Knowledge Management,
presentations,
productivity,
Web 2.0,
wiki,
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: blog, collaboration, innovation, Knowledge Management, presentations, supply chain, Web 2.0, wiki
Success, Failure, and Insights after 12 Months of Internal Web 2.0
Success, Failure, and Insights after 12 Months of Internal Web 2.0
Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:
Blogging is Easy ...
The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations - all are fully empowered to fix it.
Some find the blog to be an easier way of communicating because of the "immediacy" - a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day - but if you really understand what you can and should be writing about, you'll probably make multiple entries every day.
... but Empathizing (with the reader) is Difficult
I still get pushback on the blogs - even among the groups that are currently our "best demonstrated practitioners". These folks are generating a decent amount of participation and content - but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader - a skill that I'm surprised more folks don't have, because many like to complain about what they don't know, or should know, or wish they knew.
Always ask yourself, what did I do or learn today that others would find interesting? No, it's not that the world wants to understand how my day went, or how I'm feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the "beneficial assumption" ...
- Most people think the same way I do ...
- ... so I will anticipate what I'd like to hear about my organization, my projects, and my meetings ...
- ... and write about that
Self-Policing the Content
What about stuff that [possibly] doesn't belong in a blog - even though it's internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to "negative events'; sometimes the specifics aren't really relevant and don't add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool ... it's a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.
Of course, we note that content should not be limited to all that is sweetness and light. There's nothing wrong with fact-based bad news, but there's a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don't write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.
Communicating is Still an Art
Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge - most folks can write acceptably, but may feel they can't write well - they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.
Where Are the Comments?
Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can't judge themsleves based on numbers and responses that you mgiht see on the Internet - heck, it's taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].
Previously ...
- Heisenburg KM (July 13, 2004)
- I have nothing to say and I am saying it and that is poetry (April 6, 2005)
- Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
- What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
- More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- Communication is the responsibility of ... (August 19, 2007)
- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
Technorati Tags:
blog,
collaboration,
documentation,
Web 2.0,
wiki
Labels: blog, collaboration, Web 2.0, wiki
Rules of Golf - Project Prioritization Process Needs Clear Documentation
Success, Failure, and Insights after 12 Months of Internal Web 2.0
Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:
Blogging is Easy ...
The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations - all are fully empowered to fix it.
Some find the blog to be an easier way of communicating because of the "immediacy" - a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day - but if you really understand what you can and should be writing about, you'll probably make multiple entries every day.
... but Empathizing (with the reader) is Difficult
I still get pushback on the blogs - even among the groups that are currently our "best demonstrated practitioners". These folks are generating a decent amount of participation and content - but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader - a skill that I'm surprised more folks don't have, because many like to complain about what they don't know, or should know, or wish they knew.
Always ask yourself, what did I do or learn today that others would find interesting? No, it's not that the world wants to understand how my day went, or how I'm feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the "beneficial assumption" ...
- Most people think the same way I do ...
- ... so I will anticipate what I'd like to hear about my organization, my projects, and my meetings ...
- ... and write about that
Self-Policing the Content
What about stuff that [possibly] doesn't belong in a blog - even though it's internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to "negative events'; sometimes the specifics aren't really relevant and don't add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool ... it's a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.
Of course, we note that content should not be limited to all that is sweetness and light. There's nothing wrong with fact-based bad news, but there's a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don't write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.
Communicating is Still an Art
Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge - most folks can write acceptably, but may feel they can't write well - they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.
Where Are the Comments?
Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can't judge themsleves based on numbers and responses that you mgiht see on the Internet - heck, it's taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].
Previously ...
- Heisenburg KM (July 13, 2004)
- I have nothing to say and I am saying it and that is poetry (April 6, 2005)
- Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
- What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
- More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- Communication is the responsibility of ... (August 19, 2007)
- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
Technorati Tags:
blog,
collaboration,
Web 2.0,
wiki
Labels: PMO, presentations, project management, Web 2.0, wiki
Update on Blogs as PM Tools - Tales from the Front Lines
Update on Blogs as PM Tools - Tales from the Front LinesWe seem to be going through a second wave of focus (hype?) in the popular technology press, on the idea of using blogs as an important project management tool. The topic made the cover of CIO Magazine this week - Lynch made a number of interesting observations - interesting because I don't necessarily see the same things in practice:
-
The Reputation Hurdle: While I agree that blogs aren't fully understood by everyone, the folks that need to use them pick up on the concept very quickly. The beneficiaries of project-focused blogs are the folks participating directly on the project, plus other teams that are dependent on the resources or results involved. We still need to present project status to the management level using tried-and-true PowerPoints.
-
Start Small: The biggest reason to start small, and allow the popularity of PM blogs to spread virally, is that you don't have to devote time and energy to develop training material. Folks see how blogs work, eliminating e-mail threads that clutter up their inboxes, and they just get their neighbor to show them how it works. The real power in gras-roots process improvement like this: you don't have to invest in formal training. Time-pressed IT departments typically don't have time to develop
fancy training material - and they usually not good at it.
-
Curing the eMail Addicts: Lynch opens up a very interesting door when he connects importance of RSS to the relevance of blogs. I've had a couple of conversations now with folks who can only see blogs as yet another website I need to visit, more information overload to deal with. eMail is a mission-critical system for many companies, partially because people have learned to use it as an information aggregator. Only when folks see an RSS client in action do they really understand what's going on;
the blog/website is nothing, but collecting feeds from the 50 projects you want to keep tabs on, and seeing timely updates about them all in one place - that's powerful, and that's when they really "get it".
A Key Observation
We've been using the MS SharePoint template for a couple of different projects (single efforts) and programs (groups of projects in support of a strategic initiative). We've also had an IT wiki in place for almost two years now. It's fascinating to note how different the rate of adoption for these two technologies has been; getting content added to the wiki is sometimes like pulling teeth, but the blogs are taking off in some areas. Even in small teams that sit within 20 feet of each other; postings, comments
and responses are plentiful.
After talking with some of these folks, I've realized that using a blog and responding to a post is just like eMail - it's just stored in a database, accessed using the browser, and conveniently linked to the project. The wiki, on the other hand, is Yet Another piece of formal documentation - and who likes to do that?
More and Better Thoughts
I had a few posts on this topic last year, but Dennis McDonald has been consistently posting a bunch of interesting content in this area:
Previously …
-
Open Source as bargaining chip - driving business value of IT (October 30, 2005)
-
Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
-
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
-
Guidelines for Success with your Skunk Works project (June 19, 2006)
-
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
-
The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
-
More on (sic) experience with wikis (January 31, 2007)
-
Open Source Insights on Enterprise Software Business Models (March 14, 2007)
-
Buzzword Management ABCs (March 16, 2007)
-
Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
-
Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
-
What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
-
More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
-
Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
-
The Right Web2.0 Tool for The Job (July 16, 2007)
Labels: blog, PMO, project management, tech management, Web 2.0, wiki
Innovation That Matters - Substance Over Style
Innovation That Matters - Substance Over StyleThis the time of year when organizations (companies, departments, and teams) review their performance from the previous year. Breathless presentations are made to upper management and/or the Board of Directors, in late December or early January. Typically, the IT department will go through their projects and talk about how many significant chunks of work got done that helped move the company forward.
I've noticed when some folks talk about accomplishments for the last year, they'll make a point to mention all of the techno-buzzwords in vogue - for 2007, try Web 2.0, wikis, blogs, and collaboration - to illustrate how the company is innovating. Boy, are they missing the point!
If you're firm is not into consumer products or a direct-to-consumer sales, if you don't do professional services, pure research, or other knowledge-intense activities - how much does Web stuff really drive your bottom line? Ever since the Internet boom of the 90s, Web technology has tempted and teased many brick-and-mortar companies (and middle managers) with dreams of explosive stock valuations. But in reality, this technology has only chipped at the edges of how many of these organizations really make their
money, and how Wall Street really values them. The block-and-tackle ERP systems, supporting fundamental, value-adding processes like supply chain, order management, sales and marketing, and distribution, is the technology that's relevant and meaningful to the business.
So why not talk about the innovative stuff you've done with ERP? How about the make-to-stock company that wants to get into mass customization - you can configure most systems to handle make-to-order, but can you also change your product data, order management, manufacturing and distribution processes?
What about IT alignment with new management principles? If your company has committed to Lean Manufacturing principles, can you adapt Agile project management and software development techniques, and bring them into your IT organization?
I know - you did deliver on this (and more!) - so don't sell yourself short! That’s real innovation that actually means something.
-
Innovation with new investment (time and money) in tools and delivery mechanisms is "interesting" - maybe you're delivering productivity or cost reductions, delivering incremental benefit that's "appreciated"
-
Innovation that leverages existing investment (established systems) to deliver new business models and streamlined processes is "transformational" - delivering real step change benefits that are desperately needed!
Don't fall into the techno-marketing trap that the only way you can innovate is using the latest and greatest stuff. Words like wikis and blogs are fun to say, but I prefer terms like 30% annualized growth, category killer, lower inventories with higher customer service, and market outperform.
So does my boss … and the BoD …
Previously …
-
CIO Mag - Decision Evolution (October 11, 2004)
-
Sell your Boss - Some Tech Observations (January 30, 2005)
-
Communicating Complex Technical Concepts (March 21, 2005)
-
Customer DNA - A Different Take on Understanding Markets and Networks (June 11, 2005)
-
Gee, this social network - presence - IM - knowledge management - collaboration stuff really works (September 25, 2005)
-
Of course we can pay for that ... if it makes business sense (November 7, 2005)
-
Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
-
A great mission statement for Corporate IT (October 15, 2006)
-
Buzzword Management ABCs (March 16, 2007)
-
Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
-
Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
-
Deja Vu: Comparing Enterprise Software to Big Pharma from the 90's (May 19, 2007)
-
What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
-
Yet Another Discussion on IT Chargebacks (October 7, 2007)
-
Chargebacks Redux - Some Good May Come Of It (October 9, 2007)
-
Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
Technorati Tags: blog, business value, collaboration, CRM, knowledge management, marketing, supply chain, tech management, Web 2.0, wiki
Labels: blog, business value of IT, collaboration, CRM, Knowledge Management, marketing, supply chain, tech management, Web 2.0, wiki
Communication is the responsibility of ...
Communication is the responsibility of ...Corporate Knowledge Management (KM) is hard. Hard to introduce, hard to teach/coach, hard to require, hard to create. Which, added all up together, often make it hard to use.
It may sound like unfounded pessimism, as the Internet is loaded with examples of successful collaborative sites that aggregate and repackage knowledge - it's been doing that for years, ever since there were Compuserve forums and bulletin boards. Unfortunately (for the corporate environment), the Law of Large Numbers takes care of locating enough motivated authors with a knack for the written word, and thousands
/ millions reap major rewards. Internal, corporate KM doesn't benefit from the high traffic / exposure of the public intarweb.
I'm often surprised that I keep chasing this particular windmill; maybe I am truly lazy, and would love it if I could disintermediate myself from all of the project and system status updates. There is definite value for IT managers, even business managers, dealing with unmaintainable systems and an overdependency on a few key resources. There is also value for those who possess this knowledge; I've known many developers who couldn't shake free from their system support role with a obtuse system, simply because
they were the only one who knew the magic required to keep the thing running.
At a recent internal presentation, I tried to illustrate with a comparison between Then and Now. In the "old days", when cc:Mail, Lotus Notes workflow, and black & white HP LaserJets ruled the roost, "knowledge" flowed in one primary direction - in, to me.
Then
-
Information arrives in my in-box
-
Project leads, managers, supervisors, and trainers push information to folks who need to see it
-
If it’s not in my eMail, on my hard disk, or printed out on the shelf at my desk, I’m not aware of it
-
Communication is the responsibility of the communicator
In hindsight, I could disavow responsibility for knowing about stuff, because it wasn't adequately communicated to me.
Times are different now - even eMail is falling out of favor with those entering the work force in the next few years, and we are inundated with IM, SharePoint, RSS, Twitter, internal wikis & blogs ... a new tool every day. Even our "standard" publishing tools are under attack - note the rise of Linux and Macs as viable platforms for corporate desktops. Office 2007 has introduced a radically new UI, and Vista requires
a POS* on each desktop - so adoption won't be as quick and as pervasive as XP and O2K. The fight between OOXML / ODF and a host of other document formats just indicates the rising popularity of multiple authoring tools - it ain't all MS Office any more ...
Now (1 of 2)
-
Information is available in many formats, media …
-
… and there is no single “correct” format
-
Information is available inside and outside of my team / department / location / company
-
It is impossible for publishers to know all potential consumers
-
If it’s not “at my fingertips”, I suspect it’s out there somewhere …
-
Communication is the responsibility of the communicatee
It seems that the responsibility arrow now points to me - and I, being a bit of a technology geezer (if you believe my teen daughters), might correctly feel some pressure. However, it's not as simple as that - where does this content come from? In the past - project leads, managers, supervisors, and trainers were "publishers", but now, there is architectural pressure, in the form of Web 2.0 and collaboration tools, that level the playing field and make us all publishers.
Now (2 of 2)
-
Everyone is a [potential] publisher; everyone has knowledge/skills/experience to contribute / share
-
Information can be published and consumed in many formats, media …… and there is no single “correct” format
-
Information is desired / required inside and outside of my team / department / location / company
-
It is imperative for publishers to anticipate all potential searchers / “consumers”
-
Communication is the responsibility of the communicator
Hope springs eternal, and I prefer to see these challenges as opportunities; indeed, the message of my presentation tried to make this point. Of course, one could choose to watch it all go by, and decide not to participate ... but don't be surprised when the person next to you starts to change their effectiveness (and prospects) ...
Next ... all is not lost, some interesting new tools I've recently added to my set ...
* Piece of Skylab - originally, slang for large boombox, now refers to any sufficiently engadgeted / loaded desktop / notebook. AKA Cray Notebook or Cray desktop
Previously ...
-
The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
-
Thoughts on Why Tech Folks Hate Documentation (July 08, 2006)
-
Moving from Search to Find: Anticipate the Next Big Problem (April 16, 2007)
-
Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
-
The Joy of Programming, the Challenge of KM (May 05, 2007)
-
Consarned whippersnappers (Generational Diversity) (May 20, 2007)
-
Driving Participation and Contributions on Internal Blogs and Wikis (July 07, 2007)
-
The Right Web2.0 Tool for The Job (July 16, 2007)
Technorati Tags: blog, collaboration, knowledge management, SharePoint, tech management, Web 2.0, wiki
Labels: blog, Knowledge Management, presentations, Web 2.0, wiki
