Thanks to TFPL, and especially John Davies, for inviting me to their 'Sharepoint Summit' last week. As I said previously, I came to this fighting against a degree of prejudice regarding Sharepoint. My own experience of Sharepoint 2003 had been fairly underwhelming, and the views expressed at Wiki Wednesday had been fairly negative, too.
In many ways my fears proved founded. During the eight or so presentations plenty of weaknesses and limitations were highlighted. I won't go into detail, as James Lappin of TFPL has listed them on Twitter already. Not too surprising, perhaps, as Sharepoint attempts to cover six major information management bases: collaboration, portal, enterprise search, ECM, business processes & forms, business intelligence. It would be pretty surpising if it were best of breed in all these. The trouble is (although not for Microsoft or their certified partners) that IT departments are choosing Sharepoint as the solution to whatever the problem might be, then trying to patch up the deficiencies with widgets, bespoke code, etc. This all takes time and costs money. And it can be very messy. If one message came across loud and clear from the presenters, it was that you must think and plan ahead before implementing Sharepoint. If you don't you can get into a right old pickle.
Call me old-fashioned (actually perhaps new-fashioned is better here), but I thought the new wave of Web 2.0 in the enterprise was about lightweight software, small pieces loosely joined, mashups, emergence and so on. Sharepoint doesn't much sound like any of that to me. Then again, to be fair, I have been focusing mainly on collaboration / knowledge-sharing, which is only one of the six Sharepoint segments. Most of the case studies at this summit involved something more formal - a major intranet, a public website, a hub for integrating information being entered in multiple geographies, a workflow system. But I was left wondering about the wisdom of using Sharepoint for everything instead of picking best-of-breed products. I suppose it's a bit like the old debate about Hi-Fi: do you buy separate speakers, amp and CD player, from different manufacturers, or do you plump for a package from one? The argument for the package was put by Sharon Richardson of Joining Dots. Sharon should know a fair bit about Sharepoint, as she worked for Microsoft from 2000-2006 as Lead Technology Specialist for Sharepoint products in the UK. She took us back to the early '90s - which I am certainly old enough to remember - when Wordperfect was the No 1 word processor and Lotus 123 was the spreadsheet of choice. Word and Excel, she claimed, weren't necessarily better, they just worked better together. And the same argument applies to all the bits of Sharepoint. Well, this is something that jars with me, for two reasons. First, I'm not sure the interoperability of the early Office products was all that stunning, and to the extent that it was, was there not a little issue of some Windows code being concealed from non-Microsoft developers? Second, we're not talking any longer about an office suite of desktop products. The new standard is www (something that Bill G took a little while to 'get', incidentally). It should not be necessary to buy a suite like Sharepoint to get the interoperability and integration you need.
Perhaps I'm being overly negative. As some speakers said, Sharepoint can be tolerably good out of the box for an SME with modest requirements. And if you are a bigger firm which is happy to invest time to customise and extend basic Sharepoint, and prefers to work from a pre-existing platform (ready-made foundations, if you like) rather than build an app. from scratch, it might make sense also. One thing is clear: the Microsoft marketing machine is ensuring that for many companies Sharepoint becomes the one and only migration path for those whose world currently only contains Office, shared drives and Exchange, to one that is Web 2.0 - ish, if not Web 2.0 proper. Whether you like Sharepoint or not, it's going to be hard to ignore it.
Thanks again to TFPL for arranging a great day, and letting us see the warts as well as the beauty.
Sunday, 19 October 2008
Friday, 3 October 2008
London Wiki Wednesday and Sharepoint
Wiki Wednesday yesterday was the first I have attended for about 9 months, I think, not least because they were put on ice for a while. Hosted jointly by the BCS North London Branch and Bearingpoint, the initial theme or hook was “Microsoft SharePoint as social media platform - Any chance to fight your IT department when they suggest it?”. This was a topic I did not want to miss, particularly as I shall be attending a one day seminar by TFPL later this month, which will be taking somewhat the opposing view.
David Terrar, organiser of London Wiki Wednesdays, had framed the proposal, and whilst he has his own competing product called Wordframe, I believe he's genuine in his desire to highlight the comparative benefits of not only his own product but of others of similar ilk.
A number of audience members who had had experience of Sharepoint implementations in their own organisations offered their views. There seemed to me to be a consensus that Sharepoint is touted by Microsoft as both 'free' and 'out-of-the-box', but isn't really either of those things. Firstly, a MOSS licence isn't free, and unless you upgrade to MOSS from entry-level Sharepoint you basically only have a document management system and miss out on Web 2.0 tools such as wikis and blogs. It needs a lot of customisation, which can take many man-hours of IT people's time. Someone described it as a toolset rather than a product for end-users. As (I think it was) Andreas Rindler argued, no product will be suitable for deployment in many organisations without any customisation. But with Sharepoint it is not possible for an end-user, for example, simply to add widgets by selecting from a tick-list, as they (allegedly) can with other products.
I must suspend my suspicion that this is all a typical Microsoft lock-in strategy, along the lines of "nobody ever got fired for choosing IBM, no wait, Microsoft", thus giving an easy choice to the IT procurement people, then nice employment for their folk, etc. I must also stop thinking that Sharepoint is a mediocre product, since I haven't touched it for 2 years. I'm looking forward to the TFPL day so I can hear the other side of the story.
For a write up of the rest of the 1st Oct Wiki Wednesday (and there was more good stuff), see here
David Terrar, organiser of London Wiki Wednesdays, had framed the proposal, and whilst he has his own competing product called Wordframe, I believe he's genuine in his desire to highlight the comparative benefits of not only his own product but of others of similar ilk.
A number of audience members who had had experience of Sharepoint implementations in their own organisations offered their views. There seemed to me to be a consensus that Sharepoint is touted by Microsoft as both 'free' and 'out-of-the-box', but isn't really either of those things. Firstly, a MOSS licence isn't free, and unless you upgrade to MOSS from entry-level Sharepoint you basically only have a document management system and miss out on Web 2.0 tools such as wikis and blogs. It needs a lot of customisation, which can take many man-hours of IT people's time. Someone described it as a toolset rather than a product for end-users. As (I think it was) Andreas Rindler argued, no product will be suitable for deployment in many organisations without any customisation. But with Sharepoint it is not possible for an end-user, for example, simply to add widgets by selecting from a tick-list, as they (allegedly) can with other products.
I must suspend my suspicion that this is all a typical Microsoft lock-in strategy, along the lines of "nobody ever got fired for choosing IBM, no wait, Microsoft", thus giving an easy choice to the IT procurement people, then nice employment for their folk, etc. I must also stop thinking that Sharepoint is a mediocre product, since I haven't touched it for 2 years. I'm looking forward to the TFPL day so I can hear the other side of the story.
For a write up of the rest of the 1st Oct Wiki Wednesday (and there was more good stuff), see here
Tuesday, 23 September 2008
Systemic risk and social media
Presumably there's nobody who hasn't heard of the recent, er, problems in the finance industry. Whilst the wailing and gnashing of teeth are going on, presumably the FSA, SEC and other regulators are pondering how to ensure it 'never happens again'. Targets in the firing line seem to include bonuses and shorting, plus that rather vague term 'transparency' (or rather, opacity, since that's the bogey).
But is there anything much that regulators can do, without throwing the baby out with the bathwater (ie over-regulating and thus stifling enterprise)? And if so is there any connection with social software in the enterprise, thus justifying this post?
I think there might be, but it's not a nice thought. Let me step back a moment. The credit crunch and recent investment bank failures stem from the fact that a duff security - sub-prime mortgages - was wrapped up into opaque financial instruments such as CDOs (collateralised debt obligations). If I understand it correctly, this opacity made these instruments easier to sell than the underlying assets alone would have been, and it became harder for banks to know the true systemic risk they were running. When the sh*t hit the fan, ie the mortgages became worthless because of falling property prices and consequent defaults, not only were the CDOs etc devalued but putting a price on the devaluation became very hard, as did knowing which bank was exposed to what. So the problem was a combination of devaluation and ignorance. It was the ignorance as much as the loss of value that led to the credit crunch and the failures of Bear Stearns, Lehmans and (nearly) Merrill Lynch.
So where am I going with this? The regulators need to get a better, and earlier, hold on systemic risk in future, no matter what gives rise to it. This is not easy to do. Theoretically it can be done by external observation of economic indicators. It might have been possible to deduce that property prices were about to crash and that mortgage-related securities would go with them. But it's always hard to guess when a market has reached its peak, otherwise we'd all be rich. And probability is only one element of risk, the other being consequences or impact. The latter was probably very hard to measure, again because of opacity of the instruments. It all reminds me a bit of the problems at Lloyd's of London in the 1980s with the so-called LMX Spiral: risk accumulated through a chain of reinsurance contracts and no-one knew (until the s*it hit the fan) that it had ended up with a small number of syndicates, who were left holding the parcel when the music stopped.
But is it really true that no-one knows? I emphatically think not. The people who know are those doing the business. You can bet that there were people who knew how potentially toxic those CDOs and what-have-you were. I'm not talking about fraud here, although that did happen also. I mean people doing a relatively honest (by investment banking standards) job, who could see the risk, but had no incentive to do anything about it. In fact they had a big incentive not to - their bonus.
So how does a regulator find out about these risks? S/he needs to tap into what the traders are saying. Once upon a time they just said it in pubs and on street corners. Then, when email came along, some indiscreetly wrote things down, thinking it would remain private. But the regulators could order discovery of it as evidence when something went wrong and it appeared that rules had been broken.
Finally I'm getting to the point. Just as young people often blab about everything they are doing and thinking on social networking sites, then get embarrassed (and maybe risk their employment prospects) when they realise who might be reading it, we can perhaps expect such indiscretion inevitably to occur on social media within the enterprise, when its use becomes widespread. It might come to include traders talking about the latest securitisation wheeze, and how it's gonna be a great little earner for a couple of years until the sh*t hits the fan when x happens. Regulators would be very interested in seeing this material. We may even come to see it as their duty to obtain it. And perhaps to obtain it not just after the horse has bolted, but on an ongoing basis. Not a nice thought, but perhaps inevitable?
But is there anything much that regulators can do, without throwing the baby out with the bathwater (ie over-regulating and thus stifling enterprise)? And if so is there any connection with social software in the enterprise, thus justifying this post?
I think there might be, but it's not a nice thought. Let me step back a moment. The credit crunch and recent investment bank failures stem from the fact that a duff security - sub-prime mortgages - was wrapped up into opaque financial instruments such as CDOs (collateralised debt obligations). If I understand it correctly, this opacity made these instruments easier to sell than the underlying assets alone would have been, and it became harder for banks to know the true systemic risk they were running. When the sh*t hit the fan, ie the mortgages became worthless because of falling property prices and consequent defaults, not only were the CDOs etc devalued but putting a price on the devaluation became very hard, as did knowing which bank was exposed to what. So the problem was a combination of devaluation and ignorance. It was the ignorance as much as the loss of value that led to the credit crunch and the failures of Bear Stearns, Lehmans and (nearly) Merrill Lynch.
So where am I going with this? The regulators need to get a better, and earlier, hold on systemic risk in future, no matter what gives rise to it. This is not easy to do. Theoretically it can be done by external observation of economic indicators. It might have been possible to deduce that property prices were about to crash and that mortgage-related securities would go with them. But it's always hard to guess when a market has reached its peak, otherwise we'd all be rich. And probability is only one element of risk, the other being consequences or impact. The latter was probably very hard to measure, again because of opacity of the instruments. It all reminds me a bit of the problems at Lloyd's of London in the 1980s with the so-called LMX Spiral: risk accumulated through a chain of reinsurance contracts and no-one knew (until the s*it hit the fan) that it had ended up with a small number of syndicates, who were left holding the parcel when the music stopped.
But is it really true that no-one knows? I emphatically think not. The people who know are those doing the business. You can bet that there were people who knew how potentially toxic those CDOs and what-have-you were. I'm not talking about fraud here, although that did happen also. I mean people doing a relatively honest (by investment banking standards) job, who could see the risk, but had no incentive to do anything about it. In fact they had a big incentive not to - their bonus.
So how does a regulator find out about these risks? S/he needs to tap into what the traders are saying. Once upon a time they just said it in pubs and on street corners. Then, when email came along, some indiscreetly wrote things down, thinking it would remain private. But the regulators could order discovery of it as evidence when something went wrong and it appeared that rules had been broken.
Finally I'm getting to the point. Just as young people often blab about everything they are doing and thinking on social networking sites, then get embarrassed (and maybe risk their employment prospects) when they realise who might be reading it, we can perhaps expect such indiscretion inevitably to occur on social media within the enterprise, when its use becomes widespread. It might come to include traders talking about the latest securitisation wheeze, and how it's gonna be a great little earner for a couple of years until the sh*t hits the fan when x happens. Regulators would be very interested in seeing this material. We may even come to see it as their duty to obtain it. And perhaps to obtain it not just after the horse has bolted, but on an ongoing basis. Not a nice thought, but perhaps inevitable?
Thursday, 28 August 2008
'Knowledge management' again
In a Google group related to content management I saw a post today about KM. Someone had been tasked with setting up a KM system but didn't know how to go about it. This prompted me to comment along the following lines.
It's possible to argue endlessly about what 'knowledge
management' means. I think what most organisations want (or should
want) is an information management system which includes not only
formal-ish documents like reports, but conversations. The latter is
where blogs come in. Old-style KM tried to make people enter
'knowledge' into separate systems - they didn't want to and didn't
have the time. A better approach is to have them write in blogs,
discussion groups and wikis as part of their work, so that the
information is captured and is accessible to all. This is in stark
contrast to information that resides on shared drives and email. You
can give it structure through tagging, enabling the creation of a
folksonomy. This is an ad hoc taxonomy, less controlled (and a bit
more hit-and-miss) but still useful and better than free-text
searching alone. Pop in an RSS feed and people can subscribe to the
subject areas or authors they are interested in. The hard bit is
weaning people off the tools they are used to - email, Word documents
and Powerpoints on shared drives. Old habits die hard.
Do you agree?
It's possible to argue endlessly about what 'knowledge
management' means. I think what most organisations want (or should
want) is an information management system which includes not only
formal-ish documents like reports, but conversations. The latter is
where blogs come in. Old-style KM tried to make people enter
'knowledge' into separate systems - they didn't want to and didn't
have the time. A better approach is to have them write in blogs,
discussion groups and wikis as part of their work, so that the
information is captured and is accessible to all. This is in stark
contrast to information that resides on shared drives and email. You
can give it structure through tagging, enabling the creation of a
folksonomy. This is an ad hoc taxonomy, less controlled (and a bit
more hit-and-miss) but still useful and better than free-text
searching alone. Pop in an RSS feed and people can subscribe to the
subject areas or authors they are interested in. The hard bit is
weaning people off the tools they are used to - email, Word documents
and Powerpoints on shared drives. Old habits die hard.
Do you agree?
Sunday, 10 August 2008
'Managing' email inbox
I used to work on the principle that my email inbox needed to be actively managed. Every message should (ideally at least) be read once then either replied to, filed or deleted. As volumes increased, and I used the Blackberry more and more for email - on which, with my set-up, I can't file - this process became too difficult. Now I set the Blackberry to delete all emails over 15 days old (on handheld and mailbox). The idea is that if the email matters, I'll attend to it. If it doesn't, it dies a natural death.
I no longer feel a burden of fear and guilt from contemplating a massive list of unprocessed messages.
Monday, 21 July 2008
Enterprise 2.0 in a downturn?
I haven't seen much mention on the Enterpise 2.0 blogs of the R word. Is that because Enterprise 2.0 evangelists are in denial, or are they just such eternal optimists that they shrug such matters off as trivialities?
Anyhow, I've been wondering what, specifically, might be the selling points for an Enterprise 2.0 programme during an economic downturn. Here are my 'top 5' suggestions. I'd like to know what you think - are these right, are there others?
1. In a tough business climate, you need all the tools you can lay your hands on to make yourself more effective. Especially if they are cheap. E2.0 tools are effective and cheap.
2. You'll save cash when you migrate to SaaS from home-grown LANs, data centres, client apps etc. Most E2.0 tools are available as SaaS (and possibly only so).
3. You'll save time and thus money by using email less, and blogs, wikis, RSS etc more. This is because you'll reduce information 'noise' and thus time lost looking for the 'signal'.
4. If it comes to lay-offs, you'll communicate well with your staff about the need for them, and about the process, because you know that everyone in the organisation will know if you don't - and if you do. No more 'disappearances'.
5. You might find that staff come up with creative ways of helping the business ride the trough of the wave.
Anyhow, I've been wondering what, specifically, might be the selling points for an Enterprise 2.0 programme during an economic downturn. Here are my 'top 5' suggestions. I'd like to know what you think - are these right, are there others?
1. In a tough business climate, you need all the tools you can lay your hands on to make yourself more effective. Especially if they are cheap. E2.0 tools are effective and cheap.
2. You'll save cash when you migrate to SaaS from home-grown LANs, data centres, client apps etc. Most E2.0 tools are available as SaaS (and possibly only so).
3. You'll save time and thus money by using email less, and blogs, wikis, RSS etc more. This is because you'll reduce information 'noise' and thus time lost looking for the 'signal'.
4. If it comes to lay-offs, you'll communicate well with your staff about the need for them, and about the process, because you know that everyone in the organisation will know if you don't - and if you do. No more 'disappearances'.
5. You might find that staff come up with creative ways of helping the business ride the trough of the wave.
Tuesday, 24 June 2008
Enterprise 2.0 tools for projects
I originally posted this as a comment on one of Andrew McAfee's blog posts, then realised I should be putting it on here, too.
I've been trying to get a project team to use E2.0 tools recently. It's been harder work than I expected. We've been using Google docs to hold project documentation. This includes a spreadsheet that is the project plan. I had to switch to Zoho for the plan, because it became too big to upload to Google Docs. So that made 2 places to look, and 2 applications to learn. I thought both Google Docs and Zoho would be 'no-brainers' to get the hang of, but some people found it difficult. And we've had glitches, both human (eg my forgetting to give the right people access to a document) and technical (a bug in Google preventing editing of access permissions).
However, despite all these issues I think we've begun to see some benefits, and no-one has refused to play ball out of our small team of half a dozen or so. It's also been interesting that, some sensitive customer data apart (which was kept off the system) there has not been too much concern about putting the project data onto third party servers.
Incidentally, the team comprises the customer for a system, the supplier, and myself as an independent project manager. The fact that we're from three different organisations made it beneficial to use SaaS platforms (no access problems), but it also meant I didn't have the power to make the choice of tools and methods a matter of diktat.
I've been trying to get a project team to use E2.0 tools recently. It's been harder work than I expected. We've been using Google docs to hold project documentation. This includes a spreadsheet that is the project plan. I had to switch to Zoho for the plan, because it became too big to upload to Google Docs. So that made 2 places to look, and 2 applications to learn. I thought both Google Docs and Zoho would be 'no-brainers' to get the hang of, but some people found it difficult. And we've had glitches, both human (eg my forgetting to give the right people access to a document) and technical (a bug in Google preventing editing of access permissions).
However, despite all these issues I think we've begun to see some benefits, and no-one has refused to play ball out of our small team of half a dozen or so. It's also been interesting that, some sensitive customer data apart (which was kept off the system) there has not been too much concern about putting the project data onto third party servers.
Incidentally, the team comprises the customer for a system, the supplier, and myself as an independent project manager. The fact that we're from three different organisations made it beneficial to use SaaS platforms (no access problems), but it also meant I didn't have the power to make the choice of tools and methods a matter of diktat.
Subscribe to:
Posts (Atom)