Charities can set up web TV on YouTube, with more space for their videos and making it easier for users to find them.
Available only in the US and UK at present, more details can be found at http://www.youtube.com/nonprofits.
Charities can set up web TV on YouTube, with more space for their videos and making it easier for users to find them.
Available only in the US and UK at present, more details can be found at http://www.youtube.com/nonprofits.
Mindful of how many IT projects go wrong*, specialist insurer Hiscox is now offering insurance to IT vendors, in case their customers sue them.
Hiscox’s advice for the start of the project? Make sure the specification is rock solid. If the specification is ambiguous, it’s like writing a blank cheque to the solicitors as client & vendor argue about whether or not the system does what it was supposed t o do.
And their advice for during the project? Manage changes. Any changes to the spec have to be documented and agreed, preferably under a formal change control process. Otherwise the process known as “scope creep” can derail the project and leave it never quite finished.
* A 2007 survey by Market Dynamics shows that 62% of IT project miss the deadlines, 49% go over budget and 41% fail to deliver the expected benefits…
Isn’t it interesting how a single word can have such different interpretations?
When a charity talks about a legacy, especially a large one, it is usually something that they are delighted to receive. But when an IT magazine publishes an article called “Living with Legacy”, you can be pretty sure that they are talking about something they see as a problem. In this case, old (or very old) computer systems that are often business-critical, but expensive to look after and to adapt to the changing needs of the business. Given half a chance, many IT managers would be delighted to be rid of their legacies…
Both types of legacy are something that has been “left” to a future generation. If not well planned, both can create all sorts of unforeseen problems.
For a charity, a legacy may be tied up in restrictions that can tie the hands of the charity in using it. If too many legacies are restricted (e.g. to preserve a particular building), there may be insufficient general funds to pay for a fundraiser for other needs. An extreme example, but it illustrates the point that it can be helpful to discuss and plan a legacy with the chosen charity.
With IT systems, one problem is the technology – systems can be written in obsolete languages, to run on ageing platforms. Over time, the number of people able to understand the programs, let alone change them without causing problems, gradually reduces. While, of course, the cost of maintaining them steadily rises.
Another big problem (not just for IT systems) is foreseeing the future! When a system is built, all sorts of assumptions can be made that later turn out to be false or unsustainable. When BT built its customer service systems (CSS), everyone just knew that telephone lines only had one end, the customer end – all lines went from BT to a customer end. So that was all that had to be recorded. Sadly, the introduction of new technology (leased lines) meant that lines now had two ends… When computer systems were built in the 1960s & 70s, no-one thought they still be around in the year 2000, so information about the year was often recorded using just 2 digits rather than 4. Which was why there were all the dire predictions about what might happen due to the “millennium bug”. It cost billions to update these long-standing legacy systems.
When you’re thinking about a new computer system to support your business (or charity, for that matter), it pays to think forward a wee bit when writing the requirements. It’s still guesswork but it’s worth considering at least a few questions about what might be. What do you expect the lifetime of the system to be? How might people want to use it in future? What assumptions might completely derail your business model or the design of your system? If BT had considered the question “what if… technology changes and lines have 2 ends in future?”, that would have saved them millions in building a completely new set of systems for private circuits. What are your “what if” questions?
On the train back to Glasgow last week, I was writing up some notes I’d taken at the Institute of Fundraising’s Scottish Conference and was struck again by some of the similarities between “customers” and “donors”.
In marketing what a business does, customers want to know about the benefits you provide, rather than the features of what you sell or do. For example, in my case, my clients don’t usually want to know the details of the process I use for selecting IT suppliers. They want to know that they can have a great deal more confidence about the decision they are about to make about their IT.
It’s the same with donors. Donors need to know what a donation does. They need to hear about the outcomes, not the “features” of what you do. When considering charities to support, I want to hear about the difference they make to (say) wild land, rather than the fact that they employ several land rangers. I want to know about the women in Ghana who have been able to start their own businesses and how that has changed the lives around them, not about the mechanics of micro-credit. It’s not that I don’t care about how these outcomes are achieved – I do – but that’s a secondary question for me, one that comes into play after I’ve bought into the outcomes.
Net: all the donor or fundraising management systems in the world won’t help increase the level of donations to a charity if there isn’t a clear understanding of what that charity achieves by its potential donors.
In an excellent interview with Information Age, Ministry of Justice CIO, Andrew Gay said “If you are going to deliver an IT project vaguely near budget, it would be far better to spend a huge amount of time working out exactly what you were trying to do with that programme rather than drift into it.”.
For smaller projects, that up-front preparation time doesn’t have to be “huge”, but it deserves more attention than it often gets. The more clarity there is – about what is needed, what’s a priority and what can be deferred, what the budget is, and exactly who is going to be involved in the project – the greater the chances of the project being a success and of the IT actually delivering what is needed. And when you are buying IT, it helps the suppliers too. As one said about a fairly large project I ran in 2008, “It was the most comprehensive Invitation To Tender ever but … it meant that no significant changes have arisen, therefore no additional cost – very smooth for everybody.”.
Net: time spent on setting out your requirements, priorities and constraints up front can save time, money and disappointment later on.
For a change, this post isn’t about information technology but another technology: renewable energy technology. There’s a mixed press for wind farms and the like, thanks to the intrusion of large wind “factories” on our hills, but here’s a story of a small-scale, community-based development that has made a big difference to a small island in Scotland: http://jmtcommunities.blogspot.com/2009/05/eiggs-green-revolution-guest.html.
An example of getting the right technology to meet the needs of the users…
Recent Comments