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 ...
Bootstrap Market Research: Master Data Management (Results)
As
previously noted, I've been doing a lot of discussion and data crunching around "Master Data Management" lately - so I've "bootstrapped" a little market research project. It's still a work in process - responses are trickling in - but I thought I might take some time to summarize what I am hearing to date. A document is
available for download here ... the super summary follows below.
Survey MethodologyPlease note: I am obviously not a professional market research firm, so this is is an understandably limited sample. Still, I am hearing some interesting things that may put your own Master Data work in a bit more context.
- I've put together a little survey (download from here) which is intended to take about 15 minutes to complete - that should give you an indication into the amount of rigor and depth I am looking for.
- Please fill it out and email the result to BMRMDM@cazh1.com
I've received input from ten companies so far - large and small, with all sorts of ERP systems. If you care to add some information, I'll thank you in advance, and add it (sufficiently anonymized) to the summary results document (
download from here).
Here are some of the findings / observations from the summary ...
Master Data DomainsThe types of Master Data called out included the usual suspects - Customers, Vendors, Finished Goods, Employees. Others mentioned include Metadata, Packaging / Tooling (components), and Indirect customers (like Payors in managed care, or Buying Groups in B2B). The primary systems in scope included SAP, Oracle, JDEdwards, and QAD, joined by an eclectic mix of legacy systems and point solutions. Secondary systems called out included Siebel, JDA/Manugistics, and ADP (payroll) - plus more legacy / home grown / departmental apps.
Master Data initiatives varied, based on where the "current pain" is - R&D / engineering, CRM / Customers / Contracts / Pricing, and Finished Goods / Logistics were named by different companies as their particular focus areas. Other important considerations were things like geography (North America vs. ROW), and business structure (Enterprise vs. business unit vs. local plant).
A significant determinant of how folks thought about this problem was how their ERP is implemented - in a fully integrated "enterprise" (Finance, Order Management, Supply Chain, etc.) - and/or how the instances are divided (all enterprise, by location (geography) or by business unit).
Note, however, that relatively few respondents are concerned with synchronizing data across multiple instances - a popular callout / feature of some MDM solutions. they will speak of "integration", but a focus of the conversations were all around quality and process, not synchronization.
An interesting frustration from some of the respondees; the ERP system(s) do not capture all of the required attributes for an item, so these additional details are kept in a separate, siloed system. Easy examples would be specific attributes (like shipping material specifications), but there were multiple instances where [so-called] Master Data is calculated with complex formulas / rationale, so an Excel component is required (typically in the area of pricing / quoting details).
Note: I believe we should consider computation of pricing as a (potentially) complex process that occurs in it's own transactional / analytical system (aka "the magic gonkulator"). The output is master data - but the calculations don't belong in an MD system.
Size & Scope of Master DataPredictably, there was a great variation in the responses - 100s to 1000s of customer, vendors, finished goods. However, the interesting trend was the notation that 10s of people (relatively large numbers, based on size of the company), were "responsible" (i.e. "did some of the data entry"). Could this be why there is interest in MDM and an MDM organization? Apparently, Master Data is often managed like a wiki - everybody is an editor.
Note This is not always "out of control" - companies that have reasonably sized groups are the same ones that speak of metrics and controls. However, few report the existence of a centralized data governance organization (see below).
Most organizations have no metrics in place; a few can speak to "data police", folks that actively monitor the data looking for issues. Best examples cited included "Health Check measures" (does data fit set of established guidelines / tolerances); vendor audits, and [results of] scrubbing (ex. Name And Address data against external sources).
When asked about the business benefits of a Master Data Management effort, most companies left this blank or said "none". I generally got the sense that hard benefits are difficult to quantify; notable exceptions seem to come from past pain. Some organizations spoke to inventory reductions and transportation savings - both derived from more accurate supply chain data, which is facilitated by clean, consistent, complete Master Data.
Master Data in the OrganizationMany companies keep control / accountability at the functional area. However, companies with "enterprise ERP" implementations (full integration of Finance, Order Management, Supply Chain) typically call out ownership at the Enterprise level. It's not about the size of the company or the recency of their implementation - it's the degree of integration within the primary ERP.
Organizational specifics were tougher to get at - depending on how the company managed their master data. Generally speaking, companies that manage Master Data at a functional level (Customer Service, Purchasing, Finance) have organizational clarity. However, folks that say they manage at the Enterprise level had the wispier definitions for Title and Accountability
Of note: centralized MDM teams rarely manage the bigger projects (implementations, acquisitions, or special projects with large MD components) - but they will (out of necessity) participate. None of the respondents look to these organizations / people for project management skills. However, there were some good callouts for the communication / change management skills required for the role, especially where the group has to review implications of adds / updates [of Master Data items] with multiple groups that will/may be impacted.
Scope of ResponsibilitiesAn interesting, consistent set of answers in this area; "Yes, we take ownership and accountability - but no, we can't measure it". To be fair, not all companies had that clarity of ownership, but the lack of sharp, clear quality metrics is noticeable. Content, Quality, and Governance are consistent in all of these companies … consistently not-well defined, not well measured.
Positives & ChallengesFunny how best practices in one company are challenges in another. There are two recurring themes throughout the responses; Quality and Complexity. The latter is interesting; this was the first point in the survey where the difficulties of Finished Goods Master Data were raised. Many companies call it out as a large challenge; all of them cite the complexity, the multiple facets (manufacturing, packaging, warehousing, transportation, pricing, costing) and the cross-functional nature
Full ResultsThe summary results document is available for download from here; I will add a version date on the page and keep it up to date as additional surveys come in.
Questions? Comments? Suggestions? Let me know ...
Previously ...- Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
- Five More Realities for Driving Business Value from Technology (January 30, 2008)
- 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)
- The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
- Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
- Location, Location, Location: Terminology Confusion in ERP Projects (April 11, 2009)
- Who owns Master Data in your company? (May 30, 2009)
- Bootstrap Market Research: Master Data Management (What, Who, How) (November 30, 2009)
Technorati Tags: best practice, collaboration, CRM, documentation, ERP, hands on, Knowledge Management, SAP, supply chain, tech management, wiki
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: application development, business value of IT, collaboration, design, development, documentation, ERP, hands on, Knowledge Management, project management, SAP, supply chain, tech management, wiki
Real Business Users and SharePoint
Introducing buzzword-compliant technology like a wiki, or integrated collaboration spaces like SharePoint, will typically go well with a motivated audience like your internal IT department. But if you really want to understand how this stuff works, try it with "real people" - line employees in sales and marketing, operations, and finance.
Sure, you've heard complaints from these folks (they have better PCs at home, the SAP/Oracle UI is brutal compared to Amazon and AT&T U-Verse, and why can't they just connect their new iPhone to the corporate mail server?). Be warned; demanding users are not necessarily technically savvy when it comes to groupware.
Case in point; we are working a rather large project (many months in length, over 100 people throughout the business) using SharePoint as our collaboration space - and learning an awful lot about what we
thought we understood about ease-of-use and intuitive user interfaces. Our collaboration space is a basic SharePoint project site, featuring the usual suspects - a Shared Document library, an Issues list, and an Announcements section. Simple right? Well, maybe not ...
Documents Check In, but they Don't Check OutJust kidding, the actual check-in / check-out mechanism works fine. It's just very interesting that this basic concept of version control is lost on most end-users.
But let's start with the document library itself - it looks like a really nice version of File Explorer, but becomes very frustrating to folks when they try basic tasks like drag-and-drop. Yes, we found the simple solution - there is an option to open the folder in Windows Explorer, but since this menu option is buried right above the file list, it's hard to find - certainly not "intuitively obvious".
Version control was a difficult thing to explain - thank goodness for the tight integration with Office 2007. We found it easier to show folks how to edit documents with a simple double-click - that works just like their shared folders on the old file server! You can explain the concepts of version control quite easily, but the whole check-in / check-out, keep-a-copy-on-your-local-drive thing just gets too complicated. We did have to deal with the one-time task of checking in a new document after you upload it, but after that, they just open the files directly, and that's it.
There is one feature of Shared Document libraries that I really like - the ability to add custom attributes to documents that can appear as columns in the view. Makes it easier to sort / select / search on documents, and people "get it" relatively quickly. Just go easy on the version control.
... Here's a SharePoint TissueI think the most powerful and elegant feature of SharePoint is the flexibility you have with basic list management - even with WSS. Truly, this stuff should cover over half of the "fancy" automation tasks that folks are are asking for. However, I'm still surprised / dismayed by the fact that SharePoint doesn't include a standard graphical indicator - you know, the classic "stoplight" (green is good, yellow warning, red means um, er...). I've written about this one
before - why can't I have a simple datatype (vs. putting together a
sneaky little script to make it work).
I also have a significant warning / insight about trying to do too much with your Lists. Do you realize that most end-users in a typical SMB have older CRTs? I'll bet you still have a large number of 15" CRTs with slightly foggy tubes, on their last legs (but too expensive to change out for all but the executive staff) (ok, and IT too, sorry). In addition - well, let's just say that I'm not the only one whose eyesight is
beginning to fail them; I can't tell you how often I've tried to talk folks into moving their screen resolution higher than 800x600 - but it just doesn't work.
What's my point? Before you put too many columns in your Lists, or too many gadgets on your Site, check with the average user to make sure that it looks okay on their Screen. Heck, before you even begin your design, use SMS or a simple script to poll the user community and find out what kind of screen resolutions have been set. Catering to the lowest common denominator is not a cop-out, especially when the point of a collaboration site is to get people to actually participate!
Push vs. Pull Messaging(Another opinion:) I think most powerful aspect of collaboration sites is the aggregation of all knowledge about a project into a single, searchable repository. When people send project updates or resolve issues / hold discussions over e-mail, all that knowledge is buried and quickly lost inside people's inboxes. In SharePoint, a typical Announcements web part (yes, I know it's just another kind of List) is quite practical as a messaging medium, because folks can sign up for e-mail alerts.
Don't underestimate the attraction of the e-mail. People are used to getting information delivered to them in their inboxes - it's expected! All I'm saying with my Announcements list is that you have to subscribe to the information and pull it towards yourself (versus expecting me, the project manager, to remember to push it to you - and everybody else that might be interested).
Real-world learning: this concept didn't take long to grab hold in our project. It makes sense, people understand it relatively quickly.
On The Good SideDon't get me wrong, there is lots of good that's going on. Now that the larger project is getting used to this new collaboration space ...
- ... our issue tracking list gets better every time someone touches it - and now we have consistent consolidated issue lists for all aspects of the project
- ... we are advancing our state-of-the-art for shared authorship; there is a lot more visibility to who is working on what, and we're getting more participation than a normal project
- ... the combination of all these different pieces - shared documents, issues, announcements, and other things - are massively facilitating communication, and it is noticed by the folks on the team
Yes - these collaboration tools will definitely will bring huge value and streamline communications to your project. Just don't think it's easy or obvious.
Previously ...- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
- Butting In to the Conversation: PM Communication Tools (February 26, 2008)
- The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
- Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
- The Innovation Generation and User Interfaces (April 9, 2008)
- The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
- Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
- Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
- Is SharePoint WSS dangerous to SharePoint contractors? (February 4, 2009)
- Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Technorati Tags: collaboration, hands on, Knowledge Management, people management, PMO, project management, technology, Web 2.0, wiki,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: collaboration, communication, design, documentation, hands on, Knowledge Management, people management, PMO, project management, SharePoint, Social Networks, tech management, technology, Web 2.0, wiki
Business Benefits of Social Networks Exist, but ...
When I see / read articles like
this, or hear the breathless claims of vendors,
pundits, and
True Believers, I'll privately chuckle to myself. All of this stuff - social networking, collaboration, and innovation - are 21st century takes on good old Knowledge Management (KM), circa 1998.
Do these sound like presentations from your recent Enterprise 2.0 conference?
- Managing Cultural Change to Create a Knowledge Sharing Environment
- Effectively Managing Information Overload in the Information Age
- Information Content and Security in Document Management Systems
- Using Technology and the Project Management Workbench to Accelerate Product Development Efforts
- Shifting the Burden of Knowledge Sharing to All Employees
I dug up an old copy of the proceedings from a KM conference from 1998; if I did a global replace on "Innovation" for "Knowledge", I could probably get a bunch of folks to sign up today!
Ok, a little sarcasm is fun, but once you realize the similarities, there are other parallels with 1990's KM efforts - not the least of which is the identification of
business benefits. Anyone involved with projects back then can testify to the
difficulty in predicting hard benefits - clearly quantifiable impact on top line or bottom line, derived in a predictable, measurable manner. Sorry, it just didn't work out that way for KM - and it won't for Social Networks, either! The
hype cycle will prevail ...
Hard Benefits of Social Networks Do Not Exist, but ...Why do people insist on expecting a hard business benefit from social networks, or a payback from a project to implement a funny-sounding technology (wiki/blog/tweet) inside the enterprise? Has anyone
ever gotten a quantifiable business benefit from participating on Facebook, LinkedIn, mySpace?
Well, yes, actually - plenty of folks have connected with friends / colleagues, collaborated on business ideas, come up with innovative new approaches - actually monetized all the goofy sounding tools. I myself have written about successes, and have made
connections I could never have
anticipated. Heck, the old KM conference guide has a couple of case studies as well.
Ah, but do you see the pattern? Business benefits are not predictable, they are always opportunistic and anecdotal. Success is characterized by stories of the home runs (rarely accompanied by comparable stats on strikeouts, by the way). You can't implement a social network within a company or a group, and predict how much and when the profits / savings / growth with start rolling in. You are setting up an
environment of opportunity - nothing more.
When I hear people talk about business value or business return of social networks as if they could predict it, I cringe. They're trying to apply financial controls on something that's governed by chance - you can't do it. The incorrect assumption is that you can
control good luck - but you can tweak your chances.
Active networkers know - I'm talking about people that have been networking for years, when connections were made face to face. Career coaches would exhort us to get out there and build our professional network - make the office visits, get on their calendar, develop some connections. You have no idea what could happen from any one connection or conversation - nothing might happen or something might happen - you trying to make your own luck.
What is it they say, luck is 10% inspiration and 90% perspiration? Social networking is just
automation for some of that 90%. And benefits will happen - just don't ask me when.
Previously ...Technorati Tags: business value of IT, collaboration, innovation, Knowledge Management, LinkedIn, Social Networks, twitter, Web 2.0, wiki
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: business value of IT, collaboration, facebook, innovation, Knowledge Management, LinkedIn, SharePoint, Social Networks, twitter, Web 2.0, wiki
Zodiac of Knowledge Capture
The start of a new year gives me a rare chance to measure my knowledge capture output over time. I maintain electronic
journals for the various projects I am driving, business units and functional areas I support, and people I work with. This results in a hundred or so separate MS Word documents, with generally the same format - still, it would be quite tedious to take a word count each week to check my outout.
However, at the beginning of the year, I start a new folder and a new set of Word files - which means that after week 1, I have the easiest scenario for figuring out how much data entry for the week. And, since last week was typical, I set out to total up my data entry - starting with tthe personal journal files, but including other media:
Format Words
===== ======
MS Word 15,300 in 22 documents
Notes 3,000 in 4 documentsBlogs 3,100 in 6 entries in 4 blogs
MS Excel 500 in 5 spreadsheets
Notepad 500 in 4 text files
Mind Maps 300 in 7 maps
Twitter 900
Power Point 700 in 5 presentations
Wiki 500 in 2 wikis, 2 different dialects
------
24,800 words in 1 week
Hmm, that sounds like a lot - accoprding to
this guy, I could / should be writing eight books per year ...
But then I though of all of the other formats that I was
not counting ... texting via phone, IM over eight different accounts (thanks, Pidgin!), emails over four different accounts (and four different clients). And what about the code? That wiki item at the end got me thinking; most
wiki syntax is faux-HTML, right? But I've also had to do work just this week in HTML, CSS, ASP, SharePoint, VBA, dokuwiki, TiddlyWiki ...
This whole exercise conjured a series of images in my mind, avatars for a new
Zodiac of Knowledge Capture ...
Sisyphus: The
never ending task of documentation. At times, my "backlog" gets so big, I just file a big chunk away under Future Projects ...
Hercules:
Prodigious output should be the expectation, not the exception. The world / your work group is ever-hungry for more structured knowledge, and they don't want to wait thru the backlog - they want stuff now!
Job:
Patience is a must - you will write stuff and get no response for months ... but every once in a while, a glimmer of hope. Had a conversation this week with someone who noted my
Emotional Intelligence post from 14 months back (!). They had seen a class offering at a local college, and we ended up talking about how applicable the skills are to our jobs.
Mandelbrot: You need to be facile when plotting and navigating many
levels of abstraction. The reader needs to absorb slowly, peel the onion one layer at a time ... but they better be able to drill to the required level of detail!
Pavlov:
Repetition - Don't be surprised when you have to repeat, repeat, repeat, over and over, until you get folks used to the idea of going to the wiki, searching the portal, reading the manual.
Deming: Constant Improvement must be in your mind all the time. There is always a better way to get an idea across (which relates to ...)
Xerox:
Imitation is the sincerest form of flattery. Let's not lose sight of the goal - capture and transfer knowledge . So, if you see a more effective method of communicating - learn from it!
Tufte:
Clarity in communication is everything. You might think this one should be
Strunk, but Tufte drives for clear and effective communication graphically / pictorially, as well as in the written word.
Muse: Don't rule out
creativity; you are competing in the market of attention, and you need to capture the mind before it's ready to receive. You also can't always rely on the Same Old Stuff when capturing knowledge; keep experimenting with different tools, take the best, leave the rest.
Cthulhu (
CNZ?): Develop skills at multi-tasking, maintaining many threads at once (or
multiple arms). Multi-platform, multi-editor, multi-laungauge, multi-markup, etc.
Heisenburg: Be aware that documenting processes can be like measuring them - you will probably introduce some
change. This is "stealth process improvement", and might even be manifest laziness (it's easier to document a simplified process ...)
This zodiac needs a twelfth sign - any ideas?
Previously ...Technorati Tags: design, documentation, hands on, innovation, Knowledge Management,
Web 2.0, wiki,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: collaboration, design, documentation, innovation, Knowledge Management, presentations, visualizations, Web 2.0, wiki
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
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
