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 ...
KM Overcomplicates: Heisenberg Impact on a VBA Quickie
Got a simple request from one of the folks in Operations; we're sending out Excel spreadsheets for some quick data gathering, might we do a little basic input validation before they send in garbage that needs to be scrubbed? This person is very sharp, knows a decent bit about what is possible, and this is definitely not something that is worth a major project engagement; "
throwaway technology", a particular fave of mine.
His request was simple - just want to make sure folks enter data into one or two required columns. I've done
plenty of
Excel VBA, and had figured out a simple approach while we were talking (it's all in the
Before_Save() event, naturally), but I couldn't really tell him how to do it - he'd never programmed VBA before. However, I do have some rather large projects coming this year, and this person's group will be very important in making timely decisions, implementing change - so I figured that a little
lagniappe here would pay big dividends down the road.
Of course, I knew there would be some I couldn't get all of his requirements right away - I've done many similar things in the past, and could anticipate a number of requests down the road. So, a few minutes of Q&A, and I got a decent set of requirements for future flexibility that, if I do a little extra coding now, I could make much simpler in the future.
you may want to jump to the bottom of this post for the lessons learned ... gets a bit tedious here ..."Teaching Event" Explodes ScopeOf course, I didn't want to become the maintainer of another
shadow system, so I need to keep this simple. And, I really think there is a lot of potential in quick-and-dirty Excel automation that would do great things for many companies - if more folks knew how to do it. So, I resolved to make the code as modular and self-documenting as I could; I will publish a generic version of the spreadsheet on my
code page, so it might be useful Out There as well.
Then again, I have written before about the
difficulties of
documentation, and I fully appreciate the fact that knowledge capture, while always valuable exercise, adds a lot of
overhead - time and complexity, and required concentration. So, I thought I could compound the complexity even more by journaling the programming exercise "real time", to get some measurements on how much of an impact "good" tech documentation can add. So, I'm composing this blog entry "real time", to capture a little data.
And, because I just can't seem to leave complex enough alone, I'll leave my Twitter client [current fave:
TweetDeck] up, and do a little play by play for the Twitterverse as well. Not that I expect much feedback, it's Saturday evening; had a nice steak dinner with the family, hopefully I'll stay up through the end of the experiment.
Time Line - Saturday8:55 pmHe gets a Bright Idea, and starts the blog entry.
9:15 pm The KM preamble (above) is done, start opening windows. Before I get going, I'll have four apps open: Excel and the Excel VBA editor, plus a Google Doc (this entry) and Tweetdeck.
I did grab a sample of the spreadsheet to be sent out, with the various columns, header rows already defined, so that's a nice start.
9:18 pm Fractal nature of KM - had an idea to #hash tag
all the tweets together, so had to go retroactively tag
first tweet. Maybe I can code soon ...
9:20 pmProof of concept / flow was just a message box in the BeforeSave event. Now, I'm off stealing code from old stuff - processing row/column arrays with somewhat predictable locations and dimensions. I need to make what are basically simple loops 99.99% driven with variables, no hard coding. This is the fundamental way to deliver flexibility.
I also will assume future applications that will have multiple tabs with a different data input table in each tab - so will need to build a master loop that runs thru all the tabs.
9:25 pm Coding finally starts, with a search thru old ssheets. 2-3 more windows opened up. I'm commenting the code while I'm writing it, so the coding time isn't just raw coding
9:50pmAll stolen code, but built basic structure to process multiple sheets, handle errors at dropout at the end. I think folks might read this source code and get intimidated by VBA - hmmm, might not be helping things. Ah well, on we go ...
10:00pmSome actual new code, still mostly cribbed from other projects - but I'm aggressively genericizing. Also, first comment from twitterverse (
@faseidl). Will have to Follow commenters later.
10:05pmGonna steal some ReDim syntax, rarely do that, always have to reuse
10:15pmBeen coding for 45 minutes since the last debug, never timed it like this before, kinda interesting
10:33pmCode is flying, flexible error checking loops all built - writing the magic line of code "If blank then error" now. Probably should structure this bit of code to allow for different types of error checks (<, >, limits, etc.)
10:45pm Aha, basic loop works, but I made a mistake in my assumption of how to control the thing. I need to specify a column that I will assume is always filled - when I see a blank there, I stop checking. I'll have to write the "end of check" to be a warning "
note: I am stopping here ..."
11:00pm Ok, it's all done, tested, working just fine. Code was about 140 lines, not a lot. Will do final documentation and code clean up tomorrow morning - kinda tired right now.
Time Line - Sunday9:45amOk, back to it - should be able to finish this up right quick, one would think. Some quick math on the time line above: Roughly 40 minutes (32%) of documentation, 85 minutes (68%) of coding. Not really quantifying how much longer the coding took because I was aggressively cloning (speedup), commenting (slowdown), and genericizing (slowdown).
The sheet works fine, but I do have some work left. Need to package it all up for the original requester, so he knows how to change things; also need to genericize the final thing, so I can publish it / share the knowledge. Again, I'm trying to capture the teaching moment opportunity.
First run throuught the code was to add comments / documentation so folks know how to extend it. The target audience ranges from technically savvy, but no VBA experience, to VBA hackers - I think it's all in how I structure the code.
9:59amGetting some additional coding in - trying to take out as many opportunities for typos and such as possible. Restructuring the code so I only have to code the name of the tab to be checked once. I'm actually doing a bunch of coding here, trying to make maintenance as easy as possible - I know these aren't the most elegant methods, but I am growing conscious of how much time this is all taking. Tradeoffs, always tradeoffs.
10:18amCode cleanup done - but in testing, noted something I forgot to add. Data checking loop ends with first blank in the "check column", but if that's a mistake, and there are data rows below, I should give them a chance to see that - so I'll let them know what I think has just happened. A bit more detail than just a "success" message - again, this is a data quality check based on my experience with similar spreadsheets.
10:31amFine, the actual programming request is done. An email to the requester to deliver, but then I need to finish the Distribution part of KM. Note how I am short cutting the knowledge transfer part of this exercise for the requester - in my email, I told him to let me know when I might drop by, to walk him through the editing / changing process.
Lazy? No, actually quite practical. I'll be walking him thru the process of making changes to VBA, and I'm not about to document that. Just show him how the basic sheet works, and give him hints on how he can read more , make simple changes if/when interested. I also need to make sure he understands this is not something that IT will "officially support" going forward - just a quick-and-dirty bit of macro coding for a friend.
10:37amNow, I'm carving out the code, prepping a sample ssheet for sharing ... to be posted on my
code page. Note that I'm doing some "documenting" by generating sample data, including an error!
10:52amHere's is the part of KM that really
drives tech folks nuts, methinks. It's "prep for final distribution", making everything digestible for a broad, unknown, unanticipated audience. Up until now, the total stands at 75 minutes (39%) documentation, 117 minutes (61%) coding - but from this point on, it's 100% documentation. Remember, if a tree falls in the forest, no one hears the sound; documentation won't help until the code is all checked in, text is cleaned up to be made readable, and everything is put where it can be indexed and found.
11:00amJust starting the editing pass on this blog post - typos, prose formatting When I'm documenting on the fly, I'm not trying to make it look and sound pretty, I'm trying to capture the ideas. However, must invest in the look/feel of final product, else folks won't read it, understand it, or believe it.
12:00 NoonI'll stop the timer on the documentation here - this is a ton of work compared to the size of the original. Just starting the editing pass on this blog post - typos, prose formatting. When I'm documenting on the fly, I'm not trying to make it look and sound pretty, I'm trying to capture the ideas. However, must invest in the look/feel of final product, else folks won't read it, understand it, or believe it.
Lessons Learned- Twitter definitely adds overhead - can't quantify it easily, and it was also difficult to keep remembering to post status updates there. Might be because it's still a new tool, I'm just getting used to it, but it's a different kind of overhead than the blog entry.
- There is a chunk of complexity added because I'm flipping between different windows. Two large monitors helps, but KM requires multi-tasking; if your teams can't actively, effectively juggle four threads at once, you'll never get good documentation out of them.
- Programming for speed? Hardcode, don't go for flexibility. The coding time was easily double since I was anticipating reuse, etc.
- Only the one comment from the Twitterverse while the project was underway - not sure if that was time of day, target audience, or what. Twitter is still opportunisitc, hit or miss communication - hence the interst (I think) in building up follow lists (ings and ers).
- Knowledge capture and sharing can be a relationship management and change management exercise as well. The ability to capture things in writing are important, but not everything
- Final time stats, rounded off: Coding 120 minutes (60%), Documentation 80 minutes (40%). I can speed up coding with reuse and practice, but I can also speed up documentation with practice! Don't give up on documentation because it's going to shave 40% from all of your effort estimates - unless you honestly track all of the lost time spent looking up definitions, requirements, previous art.
KM is not free, but I think the value is only seen retroactively; folks that have gotten burned with lost requirements, or forced to do rework because the framer's intent was lost - they seem to be the folks skilled at and committed to KM.
Previously ...Technorati Tags: best practice, blog, development, documentation, hands on, Knowledge Management, twitter
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: blog, documentation, Knowledge Management, twitter
Back to the Future: Twitter "microblogging"
"That's pretty good, Johnny, but that ain't the way I heerd it. . . ."I recall when all this "blogging" talk started, way back in 1999 or so (thanks to
Hallett for a decent history). The idea was to post thoughts and feelings, observations about technology, society, or whatever - anything from a daily diary to a project notebook.
Scoble and others became (in)famous for posting multiple times a day.
Time marches on, and the medium has morphed over the years. Blog post frequency (
BPF?)
stopped being the measure of success; sites became electronic versions of trade magazines, marketing slicks, talk radio .. along with the occasionally Really Good Blog (
couldn't resist), capturing knowledgable insights or technical tricks.
Then along comes
Twitter, which has made
little sense to me to date. Well, ok ... let's say my appreciation for the
applicability of this site has
slowly matured - along with their
ability to
avoid the
Fail Whale. And I've seen another recent burst of activity - mini-
Twitter apps,
breaking news source,
alternative interfaces, even metrics for
personal validation. When
talk turns to monetization and
open source competitors appear, I guess you've arrived.
I recently happened upon
Mr. Tweet, who has helpfully suggested a series of influential tweeters to follow. When
Kawasaki and
Scoble appeared on the list, it was like a flashback to the old days ...
... but this actually got me a bit more enthused. Posting multiple times per day makes a bit more sense when it's only a brief thought - and Twitter enforces brevity with the 140 character limit.
<aside> Sort of an electronic Strunk; I've had a few posts that took more than a few minutes to compose as I struggled to squeeze in the full thought. </aside>
So, now I'm trying to
post more frequently on Twitter during the day, like a blogging old-timer - encouraged, I will admit, by posting into a
tweetosphere more amenable to spontaneous connection; a
few thoughts during a Sharepoint presentation brought a quick
response from a SharePoint
guru and
author, with more than a few tech details on some of the finer [Share]Points (
aiw).
We'll see how long this lasts ...
Previously ...- Twitter (March 22, 2007)
- New Twitter features starting to make things more relevant (June 3, 2007)
- Thoughts During a Power Outage (March 27, 2008)
- The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
- Finally! Relevant Applications for YouTube and Twitter in the Enterprise! (July 11, 2008)
- Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
- On the Road: Business Travel, Fall 2008 (October 13, 2008)
Technorati Tags: blog, Knowledge Management, twitter, Web 2.0,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: blog, collaboration, Knowledge Management, twitter, Web 2.0
Dueling Collaboration Portals
I noticed an interesting phenomenon this afternoon; we are experimenting with SharePoint as our internal project management / collaboration portal. A nice platform to choose, because it's popularity is growing, and there are a wide selection of add-on products and development partners ready, willing, and able to help us spend our money to make it even better.
The interesting part is that we are running into other companies who are also working with SharePoint. Specifically, third-party consulting firms that want to work with us on projects - they have (wisely) set up outward-facing portals, so they can effectively connect and collaborate with the paying customers.
Basic training is clearly not an issue here - but after a few hours, some of the (ah, what's that word? oh yes ...) interesting issues come bubbling up ...
Mechanics
What's the protocol here? An internal project could start their own team site, and when the external partner is selected, we'll want to pull them into our collabora-party. Intuitively obvious, but most end-user firms do not regularly extend their intranet / SharePoint servers outside the firewall.
Of course, your external partner may be righteously convinced of the superiority of their portal-enabled project management process - leaving us with a new type of distributed version control problem. Even if we manually keep document libraries in sync - I'm to lazy to deal with dual entry of issues.
Intellectual Property
There may be an IP assumption that needs some clarity. I'd wager both parties have a certain interest in any intellectual property generated during the engagement - will this portal approach make it easier or more difficult to control? And what about the IP represented by the blogs, wikis, discussions, etc. embedded within - will the end of the project deliver an electronic version of all that stuff? You may need to revisit your Master Consulting Agreements.
Interoperability
Data sharing is straightfroward when both organizations are running SharePoint. It becomes problematic if different portal platforms are used. I'm currently not aware of any standard workflow or portal object API - possibly another great opportunity for some entrepreneur - portal synchronization over the Internet?
In Retrospect
None of these general concerns should surprise - it's just the latest iteration of a common problem when dealing with electronic meda. We've all seen engagements where organizations are on different e-mail systems, different versions of MS Office - even different platforms (Macintosh vs Windows, AutoCAD versus Pro-E). I'm sure more are on the way - Dokuwiki vs. MediaWiki? Et 2.0, Brute?
Previously ...
- Strategies for Fee Structures in Consulting Engagements (March 5, 2006)
- Strategies for Intellectual Property in Consulting Engagements (May 8, 2006)
- Strategies for Risk Sharing in Consulting Engagements (May 12, 2006)
- Strategies for Malware in Consulting Engagements (May 28, 2006)
- 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)
- Innovation That Matters - Substance Over Style (January 12, 2008)
Technorati Tags: best practice, collaboration, innovation, Knowledge Management, PMO, project management, Web 2.0, wiki,
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: blog, collaboration, innovation, Knowledge Management, project management, Web 2.0
A Plea for Empathetic Communication
It's impossible to over-communicate
Sounds a bit strong, but if you think through your real-world experiences, this shouldn't surprise anyone. No matter how hard you try, your message will be missed by someone ...
Problem: It's all their fault!
Rely on Web 2.0, and ...
- ... they won't subscribe to the RSS feed; they don't understand the concept, and have no other information sources that supply feeds
- ... they won't sign up for the email notifications; that feature is hidden, no one told them about it
- ... they won't read / browse / search the wiki; there are too many unfinished pages in there, and they don't consider it reliable
- ... they can't find it using intranet search - they don't know where this feature is located. And even if they did, the results aren't as targeted and "right-on" as Google
So, you try to rely on "first generation" electronic media, but ...
- ... they didn't read the email, it got lost in their inbox with 100 other new messages today
- ... they didn't see, therefore, didn't read the attachment
- ... they did not check their voice mail
Even the "old fasioned way" doesn't always work ...
- You are having a face to face conversation, but it's not sinking in because they are checking their Blackberry and thinking about the currently unfolding interruption ...
Solution: Don't jump on the latest communication bandwagon and expect a
Silver Bullet - you need to balance flexibility and focus. Different media work for different people, so work to communicate your message using a variety of methods. Of course, if you try to supply all media for all tastes, there won't be enough time to get any real work done. Just know that there is no one best way to get information out to all who need to hear your message - and adjust accordingly.
Problem: It's all your fault!
If you can get them to the electronic content, you still have to create content that actually communicates the correct information. Even if they are capable of subscribing to RSS feeds, or opening a document attachment - if the content does not convey with clarity, they won't catch your drift. Worse yet - if the first one or two samples don't convey
anything, they will stop listening to
everything.
Solution #1: Practice practice practice - The only way to get better at anything is to keep iterating.
Observation: It's no one's fault - it just is ...
Think about it - don't you receive messages in your inbox that are not clear / difficult to read, or hear about things after the fact or through the grapevine? And don't
you glance at your Blackberry during meetings? When you set your phone to vibrate, you avoid distracting others (good!) but you are invariably distracting yourself (who just called ....?)
Fact is, we are all swimming in a sea of information, bombarded with messages from all sides - and we're bombarding others as well. A little humility and a lot of empahty go a long way ...
- Get feedback - if your medium or your content are not effective, find out why. Ask your intended audience what works best for them. Majority rules, so if you have a few email holdouts that don't know how to set up an RSS reader, do it for them. Better yet, do it with them - and show them what else they can subscribe to!
- Understand what the current corporate / organizational / local culture is, and play to that. You don't have to accept the status quo - but don't tilt at windmills just because wiki is a cool sounding word that would look good on your resume. Introduce change judiciously, and don't let it override the goal at hand - you need to get the status of this project updated!
- Never undrestimate the power of face time. When you craft a beautiful, concise, complete summary of the upcoming meeting, and someone still insists on calling you up and talking about it - don't look on this with disdain - it's an opportunity! What was it about the email / document that was incomplete? Was I not clear? Also, since most recipients of project updates are getting them for a reason (stakeholders!!), it's a great opportunity to make sure they get the big picture, understand the original objectives, and are still in support of the initiative.
- Projects end, but relationshps go on. It's always good practice to improve your communications and connections with the various technology and business process teams, in and out of the company. These is always a "next time", and next time could be that much easier if you are consistently building your foundation of clarity, openness, completeness.
Effective communication is very difficult, and requires constant work. Realize this, model your actions accordingly, and your impact and influence will grow.
Previously ...- I have nothing to say and I am saying it and that is poetry (April 6, 2005)
- eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
- Gee, this social network - presence - IM - knowledge management - collaboration stuff really works (September 25, 2005)
- Success, Failure, and Insights after 12 Months of Internal Web 2.0 (March 10, 2008)
- Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
- RSS: Underappreciated Web 2.0 in the Enterprise (May 1, 2008)
- Opportunistic Insights from the RSS Stream (June 5, 2008)
Technorati Tags: blackberry, blog, documentation, Knowledge Management, people management, project management, Web 2.0, wiki,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: blog, documentation, Knowledge Management, people management, RSS, 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
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!
Previously ...
Technorati Tags:
blog,
collaboration,
innovation,
LinkedIn,
Social Networks,
Web 2.0,
Invisible Technorati Tags:
cazh1,
FEI,
Front End of Innovation,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: blog, collaboration, innovation, LinkedIn, Social Networks, Web 2.0
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).
That's all I know at this time ...
Technorati Tags:
best practice,
blackberry,
blog,
collaboration,
operations,
productivity,
tech management,
technology,
twitter
Labels: blackberry, blog, collaboration, tech management, technology, twitter
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
The Best Way to get Web 2.0 Into the Enterprise
The Best Way to get Web 2.0 Into the Enterprise
There are a few ideas circulating in the blogosphere as to what will bring Web 2.0 into the enterprise, including ...
The Influx of the Millennials; recent college graduates who have come to expect social networking, instant messaging and collaboration via the cloud. This groundswell of pressure will force IT to implement these new technologies.
Consumer High-Tech; populist technologies like Apple hardware and Google's suite of software has taken hold in our homes; folks who expect interoperability with their employer's network will create the demand.
The Innovation Imperative; apparently, the only way for IT to demonstrate relevance and appear innovative is to slap Ajax and some pastel colors into their enterprise projects.
I suppose these things will start some conversations, but there are entrenched forces within the business that are tough to overcome -
- The Millenials will be in the minority, with low positions on the corporate totem pole, for a few years still. There is still a critical mass of folks who only know how to communicate / collaborate via e-mail - folks who still own the decision-making power.
- Consumer gadgets change too fast, and sport an ever increasing array of connection technologies. Savvy corporate IT groups have standardized on a small number of technologies, so they can keep overall costs down. Few businesses will want to explode their IT costs just so folks can check corporate e-mail on their iPhones.
- Innovation based on a fancy look-feel probably delivers nothing to the bottom line. Words like wikis and blogs are fun to say, but most executive management teams prefer terms like 30% annualized growth, category killer, lower inventories with higher customer service, and market outperform.
Still, all is not lost. For those who dream of seeing more FOSS and Web 2.0 offerings on the corporate servers, the door is cracking open, due to the economic pressure we all feel. It gets tougher and tougher to justify increasing maintenance fees and license costs for the traditional software vendors, when competitive alternatives exist at little to no cost.
If you're trying to get Web 2.0 into your company, sell the economics - not the ergonomics.
Related readings ...
Previously ...
- Driving cost savings with packaged software vendors (February 23, 2005)
- What should "open source" really mean to me? (1/2) (October 22, 2005)
- What should "open source" really mean to me? (2/2) (October 24, 2005)
- Open Source as bargaining chip - driving business value of IT (October 30, 2005)
- Of course we can pay for that ... if it makes business sense (November 7, 2005)
- Who Pays for IT Infrastructure? Business projects! (March 16, 2006)
- Open Source Insights on Enterprise Software Business Models (March 14, 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)
- Consarned whippersnappers (Generational Diversity) (May 20, 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)
- Integrated Supply Chain Benefits Go Beyond the Internal Stuff (November 11, 2007)
Labels: blog, collaboration, Social Networks, Web 2.0
Butting In to the Conversation: PM Communication Tools
Butting In to the Conversation: PM Communication Tools
Dennis McDonald and Lee White are conducting an interesting experiment on their blogs, crossposting a conversation about project management and social media. I'll add my voice, with both input on the topic and observations on the method.
(Topic) The Right Tool for The Job - depends on the Job
The first part of the conversation talks about whether social media could replace classic project management tools, in terms of communicating project status. I agree with Dennis - you can never get rid of gantt charts, project budgets, and stoplight issue lists. It really depends on who the recipient of this information is; most of my project sponsors are busy executives who rose to the top in the era of e-mail and PowerPoints. Communication is uni-directional - you to them. Team members and external consultants, on the other hand, require bi-directional, collaborative tools, and most expect web-based environments accessible in and out of the corporate network, instant messaging for quick status checks, and blogs for general updates.
Truth be told, the most valuable tools in the project manager's communication kit is typically Ctrl+C and Ctrl+V.
(Topic) The Perfect Tool for The Job in Unlikely - but Opportunity Knocks ...
Another one of McDonald's posts lists features a wish list of features for the perfect collaboration environment. It reads like a feature list for MS SharePoint, and McDonald anticipates the reaction well (I, for one, welcome our new Comment overlord ... )
I KNOW that many of these features are already available in off the shelf products. Comments that are thinly disguised sales pitches without a sincere effort to contribute to this discussion will be mercilessly and gleefully deleted.
It must be that time of year - I've gotten a number of calls from vendors in the last few weeks, pushing any number of PMO environments that promise to manage my resources and solve all my prioritization woes. In these times of tight IT budgets, capital investment for new software like this rare - the dollars are better spent supporting the business.
However, all is not lost. The collaboration requirements of most PMOs can be delivered quite nicely with a collection of FOSS tools, MS Office automation, and a little ingenuity. Looking for a low risk project to throw at aspiring web 2.0 technicians and Millennials suffering from wanderlust? How about those developers trying to learn what makes effective user interfaces?
Every PMO I've ever worked with / built up relied all or in part on locally developed tools; the cobbler's children can usually hack up something serviceable. And to borrow a phrase from Lee White - most of the skills for project management and collaboration comes from creating the tools, not having the tools.
(Method) Not the Right Tool for the Job
I'm not sure I fully understand the technology that Dennis has used to combine the text from these blogs, as well as everyone's comments. My first reaction on reviewing the feed was less than positive; like a typical blog feed, it probably puts the most recent entry first - so if you want to follow the conversation, you must jump to the end of the list and page backwards. Of course, once I dove into the content, I got a bit lost. I'm not exactly sure of the order of the items in the feed, but best I can tell, the conversation starts in the middle and then sort of bounces around.
Discussion forum software does better at this task. The start of the conversation appears first; as I move down the page, I can scan the main conversation thread as well as any branches from the comments.
That's the other challenge with this method of capturing and displaying a conversation. There are a number of interesting comments, but I can't figure out how to comment on the comment, nor can I figure out how to add another voice to the conversation.
I've written about this previously; the best tool for the job depends on the type of collaboration you are trying to initiate ...
- Use an Announcement to make a statement, inform of an event, where you expect no comments or replies. The flow of information is in one direction only - out from you to the readers of the web page.
- Use a Blog to make an observation, deliver a status update - capture a well-formed thought. One or two folks may have question or want to add a follow up, but in general you expect a few comments at most.
- Use a Discussion Forum when you are asking a question, making a proposal, or establishing a new standard. Here, we expect a lot of discourse, with threaded conversations and branches and such.
- Use a Wiki when you are making a statement / documenting a fact. You should expect refinements, additions, and other edits - but not full-on discussions.
Authors Note: I officially despise ecto at this time. This is the second time that I've written this post - spent an hour and a half on it last night, only to have ecto mysteriously delete my work. I'm switching back to w.bloggar for now - gave up on it a long time ago, but it appears to have gone through some pretty extensive improvements.
Previously ...
- Implementing Intranet on Speed: The Beginning (July 27, 2004)
- Communicating Complex Technical Concepts (March 21, 2005)
- Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
- Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
- Guidelines for Success with your Skunk Works project (June 19, 2006)
- Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
- Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 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)
- Communication is the responsibility of ... (August 19, 2007)
- Five Simple Rules for Project Names, plus Four Sample Lists (January 7, 2008)
- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
Technorati Tags:
collaboration,
PMO,
blog,
Project Management,
PowerPoint,
Web 2.0,
tech management
Labels: blog, PMO, presentations, project management, tech management, Web 2.0
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
