Sunday, October 29, 2006

Technology, great technology

Of course technology is important too. But the most important things about technology are clearly not the things that most IT people like. Lots of IT people like - the latest of the latest (why role out version 1 if version 1.1 has just been released?), high levels of complexity (why have a simple executable if we can have a multi-tier solution), and most of all they like things that are different from what we already have today ... (why keep going with Windows if we can have Linux?)

But clearly this is not what we need today. We need something that works now (reliability), something that's simple to use (no I don't want a 5 day training course, no I don't want another password) and something that saves me time (no I don't want to browse through a ten-level folder hierarchy before I can find where I can store my document and then be forced to add 25 mandatory attributes). On these three tests most system implementations fail.

And therefore I would like to publish here a few simple rules for implementing IT things:
1. start small and let it grow - this allows the system to be implemented quickly and adapt itselfs to the business while it grows. I am a great fan of iterative development.
2. think developing the applications from building blocks - and then use these building blocks by replicating the same gadget in different business process throughout the organisation. Building blocks can be functionality but also reusable information. Example: A document loader is a document loader, so why develop complete different things for different users. OK the user interface may differ, but the data model (supporting a common taxonomy) and the core functions should not.
3. think information before functionality - always remember that the application will be replaced in a few years time while the information stays behind, so don't make the information application dependent
4. keep it simple (but everybody always breaks this one ...)
5. only protect what needs to be protected (so keep security models to the simplest possible level if you can)
6. only share what needs to be shared (so don't overload the information warehouses with stuff that nobody needs)
7. Get as little as possible other people involved, but get the key people - this counts for both the userside as for the developers (better have one great developer, than 10 mediocre ..., by the way great developer also means somebody who can live up to all the other rules)
8. Avoid the latest technology, unless it has a > 100% advantage
9. Always stop people's private hobbies
10. Be prepared to have a fight about all of these rules.

Labels:

Monday, October 09, 2006

How to start dealing with the key problems

Practicing Information Management is a bit like trying to mop up water from the floor while the tap is running. More information will be created in the next ten years than has been created in human history before today and therefore pro-actively solving problems today is key to avoid even bigger ones tomorrow. But the issue is that you can start everywhere and where ever you start the information keeps on flowing in.

The risk assessment is already a way of finding the priorities (only if you think there will be fire you will buy a fire extinguisher), but apart from knowing the risks you need to have a clear Champion in place first before you can even try making a start. The Champion needs to be a pretty senior figure who is there to make things happen for you. As said before - a large part of IM is about changing behaviours - and this cannot be done without high level support. If the person signing your staff report at the end of the year is also pretty keen on getting basic issues with information sorted, then it is more likely IM will get attention (and money!)

This also brings me to the second point: IM elements need to be clearly stated in tasks and targets of all staff - especially if it is measurable then this can make an impact. It is important to describe the responsibilities w.r.t. data and documents and then make it possible to check if people actually met their targets (e.g. a contract is not closed out if the related documents have not been uploaded in the document management system, etc.)

In some cases it also helps to centralise roles into full time jobs. If handling data or documents is 5% of everybody's time, then it is very likely things go wrong. If 19 people have one IM person do the 'chores' for them, then they become more efficient, the IM person is more focused on getting the information sorted and at the end of the day he/she can be an ambassador for IM in the business process.

These things are all low tech, but vital to get to a higher maturity in IM processes in the organisation. And don't forget that only when these things are in place it can be useful to look into technology solutions, else don't even try.

Labels: ,