ICT AND YOU

The word ICT is an acronym for INFORMATION AND COMMUNICATION TECHNOLOGY. Many folks have mistake computer science for ICT this is not the case. Ict is the use of computers or ICT tools to achieve our different aims. we use computer as a machine in different ways to achieve what ever we want to achieve in our various professions. ability to use those tools like computer as a machine, printers, scanners, cameras, projectors, flah disks, PDAs, application softwares, internet, web design.etc makes you an Ict literate person.

You don't have to have a degree or go to school before you do this you only have to be able to move your mouse and lay your hand on the keyboard, there you go.

in subsequent publishing i shall be taking you through the use of some of the application softwares and hardwares.

keep a date with me on this site and it shall be the most interesting experience in you whole career.

Getting the Right ICT - a question of systems
Andy Dearden, Sheffield Hallam University

A big part of getting ICT right is getting the right ICT. As software becomes more important in the day to day operations of voluntary and community organisations, organisations are increasingly investigating new systems: management information systems to monitor their performance and impact; content managed websites to provide visitors with constant updates; dynamic web systems such as blogs and wikis to support collaboration and data sharing systems to support inter-agency working. But having decided that you might need a new software system, how do you go about getting what you need?

In the private sector, software procurement generally follows defined and structured processes. In the public sector, government guidelines control the process (National Audit Office, 2004; Cabinet Office, 2000). However recent examples such as the problems Sainsbury’s faced with their stock management systems or numerous examples in the public sector should alert us to how difficult and complex ICT procurement can be.

In the voluntary sector, it appears that many organisations find this aspect of handling ICT particularly problematic. Whilst there is widespread capacity in the voluntary sector for general ICT skills training, and a general awareness about the need to address issues of accessibility, there seems little discussion about how we manage the process of obtaining the software and services that are necessary for efficient and effective operations. In one project evaluation I was involved with, we discovered that the panel that originally selected the external contractor (supplier) for a software project worth £150,000 did not include a single member with experience of ICT project management! Of course, now you have read that, you will not make the same mistake – but what other mistakes might you have to watch out for?

Does your contractor understand (and share) your values?
Concern for accessibility is just one way that software reflects values, but it is not the only one. For example, in comparing the old Windows 98 operating system with the more recent Windows XP and Vista operating systems, one important change is that the newer systems allow the ICT department of an organisation to remotely control the software available on a user’s desktop. This has many benefits in terms of efficiency and security, but the approach also involves a degree of centralised control, reducing or restricting the autonomy and flexibility of individual users, e.g. to install a new piece of software that they need at a particular time. A website may be designed with lots of appealing graphics and multimedia emphasising a value of excitement and aesthetics, but making it very slow to load for less ‘tech-savvy’ users who may only have a 56k dial-up modem. The caching and image filtering website lo-band www.lo-band.org is an example of a system designed to support equality of access for users particularly for those in developing countries with limited bandwidth available. A contractor who understands and shares your values is more likely to find solutions that match your concerns.

How many chances do you have to get it right?
When selecting your contractor, remember that no one will get the design right first time. The best design will need multiple iterations. To get a good design, you will need to explore different options, find a good option, and modify it to suit your situation. Iteration is critical for good design. But some approaches to software design offer more iteration than others.

Examine the process that your contractor is suggesting. At what stages are they going to present their ideas to you? How will they present their ideas – as working prototypes, as sketches for discussion, as flashy ‘finished’ presentations? How much opportunity will you have to view their ideas and respond? How much chance do you get to suggest your own ideas or modify theirs to match your needs? How much iteration are they offering? How are your staff and system users going to be involved in the design process?

Do you know what you are actually buying?
There are many different contracts that you might strike with a contractor. For example, when you ‘buy Microsoft Word’ you do not actually own the software at all! What you own is a licence that allows you to install and use a copy of the software on your machine. You don’t own it like you own your car – for instance, you can’t modify the software in any way, nor are you legally permitted to re-sell the licence to someone else. For some pieces of software (e.g. the statistical package SPSS) it is only possible to buy a licence for a specified time period, after which another fee becomes due. Another option is to have software developed where you are permitted to modify the software for your own needs, but you are not permitted to copy it and sell it on to others. Open Source licences allow you to modify the software, and may allow you to sell it on to others – but only under specified conditions. And you always need to clarify the amount of technical support you are contracting for after the software is delivered. Some questions you need to ask are:

will we be permitted to make modifications to the code to suit our changing needs?
will we (or the contractor) be permitted to sell the same code to other organisations?
if we do not own the code, what will the licence arrangement be?
what kind of support will be available after delivery, and for how long?
How much of your time is budgeted for the project?
Software is made of decisions, lots of decisions. You may think you know exactly how you would like your software to work, but the software developers will need to know more and they will need you to be more precise. Over and over again they will find an issue and say ‘we could do it this way, or we could do it that way, which would match your situation best?’ – and you will be lucky when there are only two possible answers! The software developers can’t answer these questions. They can’t provide the person power to make these choices. To make progress, your organisation needs to identify someone who will get and give those answers. This means you need to budget this time and effort in advance. You could call the role ‘key design informant’.

What will be your lines of communication?
Of course, sometimes – perhaps quite often – you may not be sure of the right answer to the developers’ question. It may require a meeting. It may require some investigation or discussion. But from the developers’ perspective, there has to be a point that they can rely on the decision being taken. Some individual (or some group) must have the recognised status of ‘design authority’. Decisions by the ‘design authority’ should represent binding agreements with the contractors about when a design is approved.

Who is responsible for the logistics?
As software is developed, it becomes necessary to test it. Testing needs to start as soon as the first prototypes are available, and subsequently as the system becomes more detailed and more refined. The better the testing is organised, the more errors will be found, and the fewer errors will appear after you take delivery of the system. You need to be prepared with the facilities, the people and the data that are needed so that testing in your organisation goes as smoothly as possible. Someone needs to take the role of project manager to ensure that the resources needed are available in the right place at the right time. In a small project, the design informant, the project manager and the design authority could perhaps all be the same person – but be careful not to reach a point where the loss of one member of staff will derail your entire project!

What else do you need to do at the same time?
Don’t think that you are just buying software. Your project is creating an ‘information system’. You can think of an information system as being a bit like an onion. In the middle is the hardware and software that runs on the computers. But around this are many layers of organisation, paper systems, people, support arrangements, ways of working, contracts and expectations. As you design the software you should also be thinking about the rest of the information system and designing both systems together so that they match and work together as effectively as possible.

These questions are just a start and the details will be different for every project. These questions just reflect one person’s experience. For the sector to progress, we need to share our experiences. Tell us about your procurement experiences (good & bad). Would you recommend your contractor again? Did you get the best deal possible? Is your software really matching your needs? Where do you go for professional advice?

References
Cabinet Office, 2000. Successful IT: Modernising Government in Action.
National Audit Office, 2004. Improving IT Procurement. Available from: www.nao.org.uk/publications

About the author
Andrew Dearden is Reader in e-Social Action at Sheffield Hallam University and leads the Practical Design for Social Action (PRADSA) project, which is sponsored by the Arts & Humanities Research Council.