Business Blogging goes Mainstream

Blogging seems to have all grown up, gotten serious, and become a business tool if BRW is this week (27/05/2005) reporting on business blogging and its effect on modern marketing.

Apparently it is the saviour of marketing (according to a marketing person), which will only be the case when marketing understands how it works and what the message really is.

Everything I ever needed to know, I learned from Wikipedia

If ever there is a topic you need to know about, the web's free encyclopaedia will likely have the answer for you: en.wikipedia.com

If you read up on how Wikipedia works, it seems anarchistic, it seems strange, and it seems somehow machiavellian in the extreme, but there is no doubt that it works. With all those authors contributing and, hopefully, not making stuff up, the peer review process means that it covers Fox Terriers to Robots with equal aplomb. However, when it is confronted with a contentious topic, it can all get a bit out of hand - as the Terri Schiavo entry's history shows.

SourceForge By The Numbers

At the presentation on Tuesday night (on the commercial issues of Open Source software) I was asked if it was possible to manipulate the Sourceforge rankings. Unfortunately the website was mostly down at the time, so it wasn't possible to answer immediately.

However, I have taken a quick look tonight and note that the Sourceforge.net rankings are able to be manipulated if one wanted to do so, as the formula is quite clear. However, as Sourceforge.net notes, those statistics are not the only way by which a project should be assessed. The ranking statistics are a good indicator of the project's activity level rather than the quality of that activity.

The point should be made that the incentive of an project author to manipulate the rankings process is fairly low given that, in general, the potential monetary gain would be fairly minimal.

Bespoke software? Take two tablets and call me in the morning.

So far this year I have been to see several clients to review their approach to information systems. Almost all have struggled with the in-house development of software - in many cases a lot of effort has been put into developing in-house software, and although it must have sounded like a good idea at the time, they have come to regret it eventually.

In my humble opinion (and I haven't really researched this one too much yet) there are usually several factors that end up ensuring that it all turns to tears:

• It's far too hard for internal software development staff to say "no" to any request for assistance from other areas within the business (and IT people are usually there to help, so they don't like disappointing people).
• Our natural optimism operates to say that to do the development work required will be much easier than it ever actually is. Eventually, we learn.
  
• Developing software is really, really interesting. Documenting it and writing down what you did isn't so easy - and besides, there's always a new project to get to.
• My final factor as to why an in-house development approach ends up giving corporate heartburn is that few organisations can afford to provide the real tools that are needed, and support the large development staff necessary to allow people to bounce ideas off each other. The natural evolutionary progression of this is that few good tools are available to the development staff - ergo, staff leave to go to more prosperous waters (and since it was never documented, it's time to cue the violin music for all that investment that sails into the sunset).

For my clients, I often say to have a Bex and a good lie down before you embark on an internal software development project. And if it still sounds like a good idea tomorrow morning, then you should see your GP (because those symptoms are still persisting).

It's not that all in-house software development goes to hell in a handbasket, but it is awfully difficult to do internal software development well on any large scale, and to have the discipline and the methodologies available is often beyond the capacity of a lot of my clients here. If you ever do think about writing substantial amounts of bespoke software, be sure to recognise the risks that come with that approach.

I am beginning to wonder if you aren't better off adapting sometimes an open-source solution that does 80% of what you need for a small commitment of work (and my presentation on Tuesday night, again, talked about some of the issues you might come across there).

Hmm. I suggest I'll need to write an article on this topic one of these days. Although, maybe I just did that.

Open Source Issues in Business

The presentation I gave on Tuesday night (regarding commercial issues with open source) touched somewhat on the legal issues around open source licencing, although not a great deal. I did, after all, only have an hour or so, and a legal issue is not always a commercial issue - until it all ends in tears and winds up in court, that is.

Part of my research found this paper on the web entitled "Open Source Issues in Business", which looks at the legal issues of using open source in your business. It does have a US-law approach, which anyone in Australia will tell you is "interesting and unique", which would not be a positive thing to hear if it was a first date. However, the US legal regime tends to want to impose itself wherever it can go, and is having a darn good go at it wherever a "free trade agreement" goes.

So, there it is - "Open Source Issues in Business". It's instructive to quote the conclusion for your information:

"Circling back to the two hypothetical scenarios posited at the beginning of this article of a company desiring to protect is proprietary software code and hoping to make a profitable distribution, and a company that simply wants to use open source software for its internal operations: in each case, the software may be “free” but free lunches usually come at some price and so does “free” or open source software. Both companies need to learn more before consuming their free meal, and to consider that various issues that we have discussed here."

As always, feedback is welcome.

Commercial Considerations with Open Source Software

Tonight was the night of my presentation to the IT Discussion Group for CPA Australia. It was a packed house - well, it would have been if it had actually been a house. And if there had been a few more people there.

Nonetheless, I'll claim it was delivered to great acclaim. I promised that I would upload the slides from the presentation, so here they are in PDF form - "Pits, Traps, and Windfalls of Open Source Software". I am happy to email the powerpoint (or OOo version) upon request.

As always, happy to have any feedback on the issues raised here.

Email Management and a Good Night's Sleep

I note (thanks Phillip Smith) a Hewlett Packard research item (reported at cnn.com) that indicates that emails and text messages create a greater loss in a person's IQ than smoking marijuana. At least, that's the headline - but the study also provides a comparison showing that being constantly interrupted by emails has the same impact on your IQ as missing a full night's sleep.

The study doesn't mention the long-term effects of email use, but one would think that the long-term "e-mail withdrawal" symptoms can't be good.

I suspect banning email won't be the answer for productivity increases (can you imagine receiving 120 phone calls a day instead?), but this is probably a reminder note to regularly schedule email-free time. If it is important, they'll call you. I suspect many people suffer from the symptom that the next email could be really interesting (even if the last five weren't).

I know I do, and if I find a good therapy group I'll post it on this website.

IT Governance and Shareholder Value

I note that the IT Governance Institute (it's chaired by Tony Hayes, my predecessor as Chair of the ITM COE for CPA Australia) has released a "Guide to IT Value @ Risk". The guide will be found here, while the IT Governance Institute can be found here.

IT Governance is about the way that the information technology business function is managed, particularly in the context of the board's responsibilities. IT Governance is one of the major work programs of the Information Technology & Management Centre of Excellence for 2005.

Pits, Traps and Windfalls of Open Source Software (For Business)

One of the things that I have often come across when consulting with clients is, obviously, the phenomenon of open-source software, and next week (17 May 2005) I will be presenting to the local CPA Australia IT discussion group on the topic of Pits, Traps and Windfalls of Open Source Software.

Now, I happen to think that open source software is better than the proverbial sliced bread on a picnic, but it does come with some real dangers hidden with its benefits. A real commercial issue is that, for software that is "free", no purchase order is required and a business can find itself heavily reliant upon the open source software (and the skills of the person who knows how to use it) without any of the usual gatekeeper controls to ensure people understand what it's all about (many businesses require a business case to purchase new software - but, no outlay means no business case means no commercial considerations are part of the decision).

And once you get out of the top five or ten open source projects in a particular software category, your ability to find someone that can actually use the software decreases markedly (which usually means that, once you find them, you've got to pay them quite well thanks very much). So fairly soon, and without any real red flags to indicate that it's happening, the business can become very reliant upon the skills of one single solitary person (who may or may not be a good bloke, but is still susceptible to the all-too-common "hit by a bus" problem).

But, I use Open Office at home (fairly seamlessly for most documents) and we do sponsor open-source software such as DotNetNuke to our clients, as it's a category killer in open source portal tools, and is based upon some standard technologies. I think it will always be interesting to run the numbers for clients and see which way they are better off. And this is exactly why I'm presenting next week on exactly this topic. So if you're in the Brisbane area, please feel free to drop in and say "hi" by registering and perhaps discuss the finer points or two of this topic in the business context.

Information Systems In The Old School Yard

In another life, I worked for independent schools (Anglican Church Grammar School and St Margaret's Anglican Girls' School), and in so doing I came to a good appreciation of what schools try to do with what they've got available (i.e. a lot with not much). In my post-school career, I have had occasion to visit schools and evaluate how the schools organise and run their information technology.

Each quarter my firm (BDO Kendalls) publishes a newsletter specifically to the education sector. In the autumn edition, I was asked to write an article entitled "Maximising Education Technology", and so here it is, published in all its glory.

As always, feedback welcome.

Could You Say That Again?

Going back through my old papers, I discovered this (rather more accessible, although it's still research) version of my thesis on Information Request Ambiguity. A riveting read? Probably not, but it's a good source for anyone wanting to take a look at the theoretical underpinnings of internal communication and its potential commercial effects.

In case you're wondering, information request ambiguity is when there is ambiguity in a request for a report to be written by a third party. Information Request Ambiguity is a mouthful, but it's probably more professional-sounding than calling it the "Are you sure that's what you want?" factor.

This paper was presented at the International Conference in Information Systems in 2001. We are repeating the experiment and hoping to publish in a first-tier journal "real soon now". The main rationale for the research was to identify the different types of ambiguity, and what their likely effects are (e.g. accuracy, mistaken reporting, etc).

Information Systems, Security, and Fraud

I note that John Halliday (a colleague at BDO Kendalls - Director IS Audit) has written an overview article on information systems security and fraud. This is a good short article raising the link between IS security, governance structures, and organisational fraud. John is promising a series of articles in this newsletter, so I am sure there is more to come here.

From what I understand, this article also dovetails nicely with a seminar that was run on 18th April 2005.

Password Security and Caffeine Addiction

I note a completely unscientific study (by Verisign) - but it's probably indicative - that indicates that 2 of every 3 San Francisco pedestrians were prepared to provide their passwords in exchange for a voucher for a Starbucks coffee. Which is a remarkably similar result to that found in a UK poll. I wonder whether you'd get the same results by offering a Caramello Koala here in Australia?

SME IT Health Checklist

One of the things I do in my "spare" time is chair the Information Technology & Management Centre of Excellence for CPA Australia (since 2002). This has responsibility for looking at over-the-horizon issues in information technology (as they relate to the accounting profession).

One of the interesting articles we published recently (thanks to Shauna Kelly who wrote it, I did review it before publishing although I think my most incisive comment was "I see" and "Great!") was an IT Health Checklist for SME's. A good starting point, at the very least - unfortunately you'll need to be an Australian CPA or know a CPA to get the actual PDF (hey, there must be a CPA around here somewhere)...

Due Care and Attention Before Sending That Document

Just saw this article on zdnet which talks about how the US Army kind of mucked up when it released a confidential report but didn't convert it to PDF properly. So the censor's pen wasn't quite black enough - easier to see than holding it up against the light, I guess.

Of relevance to those of us not in the US military though - never (well, almost never) send a document to a client or external party with track changes on or with dodgy metadata in it (you'll see dodgy metadata under /file/properties in your Microsoft documents - if you do that and it looks like something you don't want a client to see, then change your templates). Better yet, do what I do and send them as PDF documents (try CutePDF) - just be better at that than the US Army is.