I don't have much time to write blog posts here, but today I had the feeling the time is ripe to have another intellectual eruption. It's all Xing's fault with their new, aggressive News mailings as they try to keep up with LinkedIn that do alike. They notified me about a t3n.de article on Social Intranets mentioning Bitrix24 and Gartner's Magic Quadrant for Social Software in the Workplace.
The story of Bitrix24
The interesting part of the story is that I've been evaluating Bitrix24 actively for more than 10 months, and apart from the aspects that I love about their product, which mainly is the corporate-centric approach trying to capture more than just "projects" and "knowledge" (which is what the Atlassian strategy obviously is), the platform totally failed in the evaluation process due to missing software stability. Test coverage is what their platform is lacking and what severely torpedoes the success of any feature release they have. We had to migrate to the state-of-the-art, yet still inefficient albeit effective, JIRA-Confluence combo in the cloud to provide for a stable, reassuring environment for our newly established Agile software development practice at DACHCOM.DIGITAL AG. When you deal with massive change management you can't afford having discussions about the tools you've introduced.
Apart from that, sales representatives of Bitrix acknowledged to me that their organization doesn't know about SCRUM and Agile, and their approach is to let their local vendors come up with "customized flavors" or "profiles" of Bitrix Intranets, tailored towards the specific requirements of the industries you serve as a Bitrix Partner. Being a Bitrix Partner and a customer in despair at the same time, we couldn't afford waiting for the solution we'd have to come up with for Agile software development agencies running Bitrix24. I'd have loved to, but we had to decide which problem to solve first. And JIRA has Greenhopper, so unfortunately there was no real choice.
Is SharePoint a Social Intranet Platform?
The next thing I stumbled upon was Gartner seriously mentioning Microsoft in the leading quadrant for social software in the workplace. Let me assure you that I know the headaches and stomach aches that Microsoft SharePoint means for collaboration, document and knowledge management. And just because Microsoft bought Yammer doesn't make SharePoint the killer platform. Only because David Sacks is a Microsoft fanboy and happy about the 2012 acquisition, much like Mark Zuckerberg who revealed that Bill Gates was his role model, doesn't mean that Microsoft all of a sudden knows what went wrong with their platform in the past decade. This is much like thinking the acquisition of Skype alone means that all Microsoft products are automatically fully integrated with Skype communication technology over night. By magic.
I'm wondering what numbers Gartner uses to judge on the readiness of Social Software in the Workplace. It may certainly be true that CIOs "typically buy SharePoint for its breadth of capabilities as a platform" (i.e. the platform integrates the entire Microsoft office landscape including file shares and office document formats), and being "the most common platform supporting collaboration and related activities" may also mean something to Microsoft sales reps and executives, but a "preintegration between SharePoint and Yammer [which] is improving" doesn't actually tell that we talk about a leader in the technical and processual sense. Read: SharePoint is probably one of the worst choices you can make when introducing collaboration software.
Only safe choices are good choices, aren't they?
The inclusion and exclusion criteria of Gartner's report may be arguable as they make sure that big players will always be included in their report, no matter how bad their software is. After all they're right: Most CIOs are happy to make safe decisions based on global presence and market dominance. Don't get me wrong: Microsoft is not the only example as a vendor for this phenomenon. We also have Atlassian.
P.S.: For a similar, of course more established opinion on Gartner's rating of SharePoint & Yammer I recommend Dion Hinchcliffe on ZDnet.
Mittwoch, 13. November 2013
Donnerstag, 28. Oktober 2010
Write Access For Everyone!
I've been telling colleagues for years what's wrong with today's corporate intranets. Usually, they were shocked about my point of view: Write access for everyone! How, hell, could this fit with a corporate environment?
Wikis = Chaos!! Oh?
Typically, the first reaction to my call for égalité was, "We don't want Wikis, Wikis are chaos!" (Okay, you're a centralized person, and you don't know how to run a Wiki project. Acknowledged, thank you.) Of course, Wikis are fundamentally different to websites, including traditional intranet sites. Wikis are for encyclopedias (let's generalize!), we've heard of much more adequate technology.
Bottlenecks: 1997 The Webmaster, 2007 The Editorial Team
In the last 10-15 years information systems have advanced tremendously. In web publishing we're not dealing with HTML pages anymore which are manually linked to each other in a Spaghetti-like manner. We're working with content management systems (CMS), wow! And, because generating content has become so laborious, instead of a single webmaster we now have an "Editorial Team"! Sounds professional, ha?
Isn't that cool? What a wonderful advancement: Instead of a single webmaster we now have a whole team of webmasters! Finally, that costs real money!! (Go, and tell your CFO!) You may now start yelling at me. "Stop it, you jerk, of course it's much better replacing the bottleneck of a webmaster by ..." - By what? Several bottlenecks? Of course not! We can do better. That's where knowing and understanding CMS technology comes in.
Understand CMS Technology
Let's review what Wikipedia says about the definition of Content Management Systems:
We could have a workflow such that editors (= a role) could create, edit, and publish an article, all in one step - the editor is responsible for reviewing their own content during the time of creation. That's how most people use CMS today.
We could, however, define a workflow that would allow the editor-in-chief to create an (empty) article, and pass it on to a specific editor for completion (edit privilege); after completion the workflow could require the editor to hand in the article for review back to the editor-in-chief (publish privilege).
Even better, we could let everyone (and I mean everyone - the whole world) allow to create and edit articles, and have them request a review of their contribution in order to have their changes published by someone (this could be you). So you and only you had the power to decide what changes make it to the audience. You could either reject the article, giving a reason and have them retry, or quite frankly delete it right away, be impolite and ignore the contributors, and their content would never ever see any daylight at all! It's all in your hands.
Essentially, we could let users view articles only (which is how most corporate intranets work today), but that's only one possibility. We could give write access to all users without losing control over anything! If you were paranoid you could have your users request the addition of a new article to your intranet (which you could grant or deny). But most importantly, you can give them the perceived(!) freedom to change and contribute to anything without compromising any of your tight control you have established today. And have less work, happier employees, and more response to your intranet, because people start identifying themselves with the medium they contribute to. Yeah, good stuff! - You should read this paragraph once again!
Why Editorial Teams Suck
Editorial teams suck, because they work too much. - Did you get it? Read it again! - Yes, they work too much! They write articles for the whole company, about and in the name of everyone. They write as if they had the expertise of someone - someone who may have sent them an e-mail, a summary of something, or about a field of expertise of someone they had an interview with. That's bad, because information should be created where the knowledge resides.
And even worse, they take away the fun work that others (like me) have learned to be doing in the last 5-10 years. Creating and improving content.
Don't Trust Your Colleagues
Of course, it's not their fault. It's the intranet's fault. Since the intranet is read-only for all employees they have to do the work. And it's Corporate Communications' fault. Because Corporate Communications strongly believes that your company cannot trust it's own employees. Those hostile individuals may write articles that do not reflect the corporate opinion. And it's Corporate Communications' job to take care of that this never happens. So, of course, it is not their fault either! Okay, so it's the CEO's fault? (Actually, it must be HR's fault, because they hired only people you cannot trust!!)
Why Should Censors Write The Articles They Are Censoring?
In fact, just recently I had a discussion with a very open-minded CEO of a globally operating company. He believes in social software inside corporate boundaries. But when I said, "intranets done right - write access for everyone!", he defended the way current intranets work, and that it's okay that they (still) are operated with a fundamentally different goal in mind: Internal marketing, the CEO's megaphone, full control over content, censorship - if you want so. So I said: "Okay, but why - if you want censors - should those censors actually write their articles? Why don't they just censor?" In fact, they could censor and educate. Read on!
Content management systems of the early days had their very fundamental feature already built-in: roles and workflow. Articles are meant to be written by anyone, but published just by a few elected. That should be more than good enough for corporate intranet use. If and only if you make use of this feature.
Read-Only Intranets Are Bad
Read-only intranets should be abandoned. Intranets were introduced to share information. And when information is managed centrally what happens? Employees read these pieces of information and find errors (this is very probable as competence is spread equally in a firm, the central management can't know better than everyone - or they have done bad recruiting). Some employees don't care, some are turned off because of the perceived misquality, and some do care and send e-mails to the authors (if they are known):
What if John would have been able to edit the article himself, and fixed the error? What if William would have received a notification of the changes, checked for (formal? legal? consistency? what else?) adherence, and simply published the changes - or rejected them with a comment about why? Wouldn't that be a lot better? Yes!
What Editorial Teams Can Do Well
Admittedly, editors are not just morons. They are good journalists. They can do interviews and write (their subjective - as everyone else in the company) articles about facts and events. They can write insightful columns about how they see things happening. As in newspapers. The catch is - as with newspapers -, articles written about stuff that others know better will never really be to the point, let alone accurate. And, because they are journalists and (hopefully) have learned their business well, they know what a good and consistent writing style is about. So, why not have them teach others how to do that? Everyone would profit.
So, editorial teams are good at journalism. That's what they should do. If your company can afford fulltime journalists. In any case, 50% of their job description should be: review, publish, educate.
P.S.: I found this great presentation by Oscar Berg from Acando Consulting talking about Social Intranets as they should be. Editorial teams also get their part in the Bad Practices section on page 38.
Wikis = Chaos!! Oh?
Typically, the first reaction to my call for égalité was, "We don't want Wikis, Wikis are chaos!" (Okay, you're a centralized person, and you don't know how to run a Wiki project. Acknowledged, thank you.) Of course, Wikis are fundamentally different to websites, including traditional intranet sites. Wikis are for encyclopedias (let's generalize!), we've heard of much more adequate technology.
Bottlenecks: 1997 The Webmaster, 2007 The Editorial Team
In the last 10-15 years information systems have advanced tremendously. In web publishing we're not dealing with HTML pages anymore which are manually linked to each other in a Spaghetti-like manner. We're working with content management systems (CMS), wow! And, because generating content has become so laborious, instead of a single webmaster we now have an "Editorial Team"! Sounds professional, ha?
Isn't that cool? What a wonderful advancement: Instead of a single webmaster we now have a whole team of webmasters! Finally, that costs real money!! (Go, and tell your CFO!) You may now start yelling at me. "Stop it, you jerk, of course it's much better replacing the bottleneck of a webmaster by ..." - By what? Several bottlenecks? Of course not! We can do better. That's where knowing and understanding CMS technology comes in.
Understand CMS Technology
Let's review what Wikipedia says about the definition of Content Management Systems:
A content management system (CMS) is the collection of procedures used to manage work flow in a collaborative environment. [...]Okay, so it's about workflow and access control.
- Allow for a large number of people to contribute [...]
- Control access to data, based on user roles ([...] view, edit, publish, etc.)
- [...]
We could have a workflow such that editors (= a role) could create, edit, and publish an article, all in one step - the editor is responsible for reviewing their own content during the time of creation. That's how most people use CMS today.
We could, however, define a workflow that would allow the editor-in-chief to create an (empty) article, and pass it on to a specific editor for completion (edit privilege); after completion the workflow could require the editor to hand in the article for review back to the editor-in-chief (publish privilege).
Even better, we could let everyone (and I mean everyone - the whole world) allow to create and edit articles, and have them request a review of their contribution in order to have their changes published by someone (this could be you). So you and only you had the power to decide what changes make it to the audience. You could either reject the article, giving a reason and have them retry, or quite frankly delete it right away, be impolite and ignore the contributors, and their content would never ever see any daylight at all! It's all in your hands.
Essentially, we could let users view articles only (which is how most corporate intranets work today), but that's only one possibility. We could give write access to all users without losing control over anything! If you were paranoid you could have your users request the addition of a new article to your intranet (which you could grant or deny). But most importantly, you can give them the perceived(!) freedom to change and contribute to anything without compromising any of your tight control you have established today. And have less work, happier employees, and more response to your intranet, because people start identifying themselves with the medium they contribute to. Yeah, good stuff! - You should read this paragraph once again!
Why Editorial Teams Suck
Editorial teams suck, because they work too much. - Did you get it? Read it again! - Yes, they work too much! They write articles for the whole company, about and in the name of everyone. They write as if they had the expertise of someone - someone who may have sent them an e-mail, a summary of something, or about a field of expertise of someone they had an interview with. That's bad, because information should be created where the knowledge resides.
And even worse, they take away the fun work that others (like me) have learned to be doing in the last 5-10 years. Creating and improving content.
Don't Trust Your Colleagues
Of course, it's not their fault. It's the intranet's fault. Since the intranet is read-only for all employees they have to do the work. And it's Corporate Communications' fault. Because Corporate Communications strongly believes that your company cannot trust it's own employees. Those hostile individuals may write articles that do not reflect the corporate opinion. And it's Corporate Communications' job to take care of that this never happens. So, of course, it is not their fault either! Okay, so it's the CEO's fault? (Actually, it must be HR's fault, because they hired only people you cannot trust!!)
Why Should Censors Write The Articles They Are Censoring?
In fact, just recently I had a discussion with a very open-minded CEO of a globally operating company. He believes in social software inside corporate boundaries. But when I said, "intranets done right - write access for everyone!", he defended the way current intranets work, and that it's okay that they (still) are operated with a fundamentally different goal in mind: Internal marketing, the CEO's megaphone, full control over content, censorship - if you want so. So I said: "Okay, but why - if you want censors - should those censors actually write their articles? Why don't they just censor?" In fact, they could censor and educate. Read on!
Content management systems of the early days had their very fundamental feature already built-in: roles and workflow. Articles are meant to be written by anyone, but published just by a few elected. That should be more than good enough for corporate intranet use. If and only if you make use of this feature.
Read-Only Intranets Are Bad
Read-only intranets should be abandoned. Intranets were introduced to share information. And when information is managed centrally what happens? Employees read these pieces of information and find errors (this is very probable as competence is spread equally in a firm, the central management can't know better than everyone - or they have done bad recruiting). Some employees don't care, some are turned off because of the perceived misquality, and some do care and send e-mails to the authors (if they are known):
Hi, I've found an error on page x, paragraph y, sentence z: The word "foo" should say "bar" in "foo bar baz". Please fix that! John DoeEditorial member William "Web" Master goes into the article and changes foo to bar at the location he finds first. Because he is not an expert in the subject, however, he doesn't notice that he corrected the wrong foo (as there were two foo's in one and the same paragraph). Save - publish - and, wonderful, now we have two errors in the article instead of just one! Good job!
What if John would have been able to edit the article himself, and fixed the error? What if William would have received a notification of the changes, checked for (formal? legal? consistency? what else?) adherence, and simply published the changes - or rejected them with a comment about why? Wouldn't that be a lot better? Yes!
What Editorial Teams Can Do Well
Admittedly, editors are not just morons. They are good journalists. They can do interviews and write (their subjective - as everyone else in the company) articles about facts and events. They can write insightful columns about how they see things happening. As in newspapers. The catch is - as with newspapers -, articles written about stuff that others know better will never really be to the point, let alone accurate. And, because they are journalists and (hopefully) have learned their business well, they know what a good and consistent writing style is about. So, why not have them teach others how to do that? Everyone would profit.
So, editorial teams are good at journalism. That's what they should do. If your company can afford fulltime journalists. In any case, 50% of their job description should be: review, publish, educate.
P.S.: I found this great presentation by Oscar Berg from Acando Consulting talking about Social Intranets as they should be. Editorial teams also get their part in the Bad Practices section on page 38.
Abonnieren
Posts (Atom)