And now for something completely different...

I usually don't do posts that are simply links to other people's blogs, but I really need to make an exception for this one for two reasons:

1. This is one of the most romantic things I've ever seen (read), and not just what Sid did but also the song - which is free for download from the Heartless website (the movie is really lovely too.)
2. It not only has muppets in it but I have learnt from this post that it is possible to design and purchase your very own muppet Whatnot!!! Which I must say is a super-cool concept, even if the online store doesn't ship to Australia.

The post is about a wedding proposal with a difference, and it is lovely to think that after ten years together he would still go to so much trouble to propose. The cynical part of me thinks he wanted an excuse to make a muppet movie, but the effort to get it into a cinema belies that :-)

Maybe it is just the Krismas spirit, maybe it is the hopeless romantic in me, but I just had to share this one - enjoy.

Conference presentation on the information environment

I've been asked to present at an Ark Group conference on eDiscovery next April in Melbourne.  After considering it for a day or two I have suggested that I could talk about the information environment, documents and frameworks involved and how setting this up can assist in the eDiscovery processes.

I've started working on the presentation, and will hopefully get to use my current working environment as a case study, since we are progressing the artefacts for the information environment.  One of the things that it has reinforced for me is the importance of Security Access Models for all IT systems, which I presented at an information management policy conference three years ago. I have developed this further over the last few years and will be including this in the new presentation as well.

I've also come up with a much more refined image of the artefacts of an information environment. It's like a building blocks structure from bottom to top and I think it is a little more succinct and accessible to management. I'd be interested in any feedback on it.

Once I've done the new presentation I will post it up into Slideshare as well, unless of course I do decide to use Prezi for this one (I'm seriously toying with the idea but don't know if it will be too distracting).

Personal reflection

Do you ever have those days when you go into work and think "today will be the day they work out I'm a fraud"? I don't know why we do this, and I say we because I actually learned in a coaching training (don't ask) that this is an acknowledged condition (mainly in women not surprisingly).

I've been feeling a little overwhelmed at work this week, so much to do so little time, and so this feeling has been allowed to creep into my daily thoughts. This completely sucks, because usually it is when I have a really heavy workload that I'm more prone to these thoughts, but this is when I just need to kick in and get things done without any self-doubt.

Maybe this is just a little glimpse into my psyche that I shouldn't really share, but at the end of the day I am not a fraud, I know my job and I do it well - either that or I'm a much better bluffer than I ever thought possible. Next post will be more informative and not just about my mental processes - promise.

When not getting funding is better than getting funding - Project Series

So you've jumped the hurdle of the business case and your project has been given approval to proceed. You're patting yourself on the back and then you find out that the funding is conditional.  In my opinion, because I have had a rather important project that suffered this fate, you are better off having the project delayed or rejected than having someone say "we've approved the project and given you the $500K, but it's only for this financial year, so you've get to get it in by 30 June."

These artificial deadlines can set a project up for failure and don't allow projects to be run properly. But can you really say "thanks but no thanks" when you get this conditional approval? This depends on the business you work in but, having gone through the grief of this once before, I will push back if I am given an artificial deadline like this again.

If you have been very clear in the business case about how long the project will take, then you have a very clear position to push back on - basic project management theory will tell you that if you want to reduce the time taken for the project then you need to increase the money and/or decrease the scope.

But if you are undertaking a project that has a large cultural change component then, in my opinion, it is not possible to reduce the timeframe without significantly impacting the success of the project. People need time to be consulted, time to review, time to absorb and adjust to the changes - conditional funding or not.

As a side note to this, if you have minor upgrades/enhancements sitting on the shelf and funds have been made available (you know that end of financial year spend) then you can probably go for it and get the benefits of conditional funding - but it is not the way to fund an important business project (IT based or not).

Minor successes - major plans

I've blogged a couple of times about the information environment and how I may have a chance of finally being in an organisation where I can implement it.  Well good news, the organisation has agreed to proceed with implementing the Information Management Strategic Framework that I have developed for them. It is the beginning of a long process, but they seem willing to take the long journey of getting this sorted and doing it right.

There are two next steps to build the information environment, they are conducting an information audit to develop the Information Inventory and conducting a needs assessment with the business to develop the Needs Matrix.

It may take up to 6 months to get this process completely finished and get all of the documentation finished, but from there we can develop the Information Management Strategy, which will feed into the ICT and RIM plans.

While we go through this process we are still going to proceed with the Records and Information Management Improvement Program that I have developed. This is designed to sort out naming conventions, the shared drive and finally an EDRMS implementation - which can happen alongside the other development work.

So it is full steam ahead it would seem - I'll keep you posted on the progress as it goes along.

Problems with the Business Case - Project Series

This part of the project is very dependent on the internal processes within the business, so the things I say here may not be valid for some businesses.

Defining the Business Need

Business requirements have been covered in an earlier post, this is more about the need for the project, what will it achieve in the business.  Another earlier post addressed the requirement to not allow bosses wanting something bright and shiny or IT staff wanting to play with a new technology to drive the business need.

A good Business Case template will of course require you to define the Need, the Drivers for Change and how this project will add value to the business - and that is extremely positive, because if you can't define these qualitative features then the project should not be progressed beyond someone's bright idea.
But often times people look to a technological solution for business process problems.  This results in leaps of analysis, where the new system is the silver bullet that will resolve all of the businesses woes, streamline the processes to produce cost savings, bring about world peace and so on.

There is a saying "you can put lipstick on a pig, but it's still a pig" - you can put in a multi-million dollar IT system but if your business processes are broken they will not necessarily be resolved by an IT system.  If your project incorporates a significant change process and addresses the procedural shortfalls then it is likely to produce the improvements, but if you had undertaken the change activities without introducing the technology what would the outcome have been???

Defining Return on Investment

My biggest bug bear with Business Case templates is the financials, and not just because I get no joy from working with numbers.  The main problem is that the projects that I am usually involved in have a negative rate of return due to the inability to adequately capture and define the efficiency improvements per individual. How much money will the business save putting in enterprise search? Well I'm sure I can get some Gartner figures on time per day spent on search and average that out for the business, but what if you company requires you to actually deliver that as a direct cost saving?  If I am saving everyone in the business two hours a week of lost time I am making them more efficient, making them happier in their jobs and able to respond in a more timely manner, but I'm not actually saving tangible and definable dollars.

There needs to be a better way of defining qualitative ROI to the business that does not have to be delivered in actual cost reduction.  I've been thinking of something like a Goodwill Indicator. This would work along the lines of how beneficial the system will be to the staff - those qualitative results that cannot be easily measured and will not see clearly defined savings but will make it easier for people to do their job.  I think it has some merit as a method, but I need to flesh it out a little bit.

What else?

Whilst I understand the need to have a detailed business case it is very disheartening when everyone just reads the Executive Summary and the little bit that they are interested in.  Yes a detailed business case proves that analysis and thought have been put into the project and the need for it in the business, but there needs to be a better way of proving that this work has been done without the need for a 40-50 page document that virtually no one will read.

I think we need to come up with some smarter documents around all of this that make it simpler to create a well thought out business case.  Importantly, even if your business has good templates I think that it is extremely important to develop a clear instruction, a checklist even, about all of the hoops that people must ensure they go through to develop the business case.  Developing a good business case is hard enough without knowing exactly how to do it, who to engage and the standard process.

Functional Classification Presentation

I've been working on a presentation for a few weeks, starting to prepare for the inevitable discussions that will have to occur here on functional classification of documents.  I had a thought a few weeks ago, and a whole stream of explanation started making itself clear in my mind, so I thought I would spend some time at home coming up with a base presentation.

I complete it last night and its now loaded into Slideshare if you want to see it. Because they're having a contest I already ticked that box, not that I think this is one of my best presentations or because I think it's a sexy enough topic to win, but because the option was there in the list :-)

Not surprisingly, my closing advice is the same for everything I talk about in records and information management - train your staff on how to do their jobs and life will be so much easier.

Business Requirements - back to projects

When I worked in Defence we had an area of the organisation that would come to us every 6-12 months and say that they needed a system to support their work.  Usually this request came along with a solution, you guessed it they'd seen something bright and shiny, liked the way it solved someone else's problems and thought "that will work for us".

Our answer, for the five years I worked in that role, was the same every single time "write up your requirements and we will investigate the products that are available and work with you to get a system that meets your needs".  Since we dealt with this every 6-12 months, how often do you think they actually put in the work to write up their requirements? Once, when one of our team did it for them. So how many systems do you think we delivered for them? Zero (two versions of a system were delivered but it never went into service, don't ask!)

So why couldn't they just sit down and tell us what they wanted? We would have been happy to oblige, even with some of the tools they were suggesting, but we needed a requirements document to do anything about it (that was the process, and a good thing too I believe).

Getting Business Requirements out of the business
My opinion is that there are two things wrong with Business Requirements, or the way that we go about doing them for IT systems.  The first is that most people either don't really know what they need, or they don't really have a "need" it is more of a want (which can still be valid).  The second reason, and I think this is the main obstacle, is the Business Requirement document format.  I've had people say to me, "I can't do all that 'Shall' stuff, it makes no sense to me", and even people who have a business analyst at their disposal have been reticent because "last time I didn't understand the document and the system turned out to be all wrong".

The average person in an organisation doesn't care about all of the gumpf that has to go into a "proper" functional requirements or business requirements document.  They don't care about use cases and shall statements, they want something that in plain english captures what they need and want from the system.

Does the formal business requirement document need to exist? Yes, I believe it is probably the best mechanism for the business analyst to communicate with the technical staff who will be developing the system.

Should the people in the business who are requesting the document ever see it? No! The role of the business analyst is supposedly to be the conduit between the operational business elements and the technical staff, so make two documents.

Having been involved in a number of "requirements capturing" exercises over the last ten years, I believe that they are one of the most boring, drawn out and complicated experiences.  Sitting in rooms going through line by line of requirements gathered from workshops and prioritising them, categorising them, working out which ones contradict each other, which ones are a pipe dream and so on, should be against the Geneva convention.  It is cruel and unusual punishment, and I know why some people in business will just do without a system they desperately need, rather than being involved in these processes.

There needs to be a better way. I don't have an answer for this yet, I am trying to come up with something in my own mind, but I do have some suggestions:

• plain english must be used with the business, convert it later
• simple diagrams should be used to convey interaction with the system and information flows, but they must be simple and don't need to capture everything (we had one BA in defence who created flowcharts from hell, A3 pages that were interlinked, containing data feeds and processes. Every permeation was captured, it took about eight months to complete and by the time they were published they were incorrect.)
• it must be a rapid process that does not involve the staff wanting to kill themselves to get out of the meetings, this is why incorrect requirements go through to developers, the business have been numbed into submission
• ask them whether they have seen any other system that does what they are talking about, even if it is completely unrelated to their system. For example, if they ask for a way to pick dates ask them if they want it like an airline website. Most business people talk in this way anyway, I've lost count of the number of times I've been asked for a function to search "you know like Google".
• ultimately I think that there needs to be a better language for doing this, and better systems. Rapid prototyping, even if it just a visual representation that doesn't have all of the grunt behind it, is an absolute must.
• ask the right people about what they need (I'll talk about this in more detail in a later post about business representation on the project). If the business can spare someone to spend days or weeks to help you develop the requirements, you are talking to the wrong person!

A final note for BAs (for now)
Business analysts, especially consultants brought in to do this role, need to remember that everyone is not equal in the requirements gathering process and you have to keep it on track for what the business area who has initiated the system wants.  Scope creep kills projects, so you should focus on what the person paying you is asking for. By all means raise functionality that came up in workshops, but if you are told no, listen!

I had an extremely frustrating experience in my last role. The consultant had his own agenda about what we should be asking for, even though I had made is very clear to everyone that we had to draw the line with the requirements and a few features (namely the things he was pushing) were out of bounds for discussion at this stage.  He raised it in the meetings saying things like "and don't you think it would be good if it was accessible to people outside the organisation?", until I snapped in a meeting and told him off. We went toe-to-toe about these requirements, I told him they were not to be included in the documents or else the project would not get up. He was taken off our project, and had we not be tied to the organisation and on such a tight timeline, we would probably have gone in another direction entirely.

More on the Information Environment methodology

Ever since I've been doing corporate information management roles I've had this theory about how businesses could do all of this better.  It's been evolving over the years, and I think that I've finally got it sorted inside my own head now.  The exciting thing for me, as mentioned previously, is that my job is really a blank slate to trial this whole thing. I'm not sure yet how supportive the Executive will be with it all, but I'm hoping to convince them that we need to do this work so we can truly know where we are and plan to get to where we want to be.

I've fleshed the previous image a little more, and actually have some of the templates developed.

Proposed structure of the Information Environment methodology

As an aside, I hate methodologies, mainly because I've had some less than optimal experiences with people who seem incapable of operating without one, and blame any lack of progress in a project on the "methodology" and not their own inability to understand some extremely simple concepts. Maybe I should come up with a better term... I'll have a think about it.


So what is this and what do I hope to achieve with it?

In my experience, organisations make some less than optimal decisions about information systems, and therefore how they should be spending their time and money in the information space.  I've previously written about the problems with management and IT making decisions on these things, and my aim is that having this structure in place will reduce some of these problems (I know, I'm an optimist).

The diagram shows the elements that need to be in place to support good decision making, and an operating environment that is easily navigated by everyone involved.  How many times have you started a new job and not known where to look for the information you need to do said job? You ask the people around you and they say things like "you need to get access to the X system, but I don't know who does that?", or "I don't know the proper way, we just ask Mike to email us the report" or other such nonsense.

Wouldn't it be nice to walk into an organisation and have a roadmap of the information environment, what information is contained in which system, how to get access to that system and how that information might link up with other datasets? As an information manager that is my utopia! If I could do that for an organisation then I would feel like I had really done my job.

I think that the diagram is fairly self-explanatory at this stage, but in future posts I aim to flesh out each of the elements of the environment, to go into more detail on the role they will play in this utopia.  As I mentioned, this has been going through my head for over five years now, and I've really only just worked out how some of this hangs together and how the elements will support the business decisions.

I would really love any insights that other people might have on this, maybe it's time to put the blog into my LinkedIn and see if I can generate some traffic.

An interlude on information environments

This does have a lot to do with Information related projects, but it is not the next part that I intended on talking about.  In my current role I actually have a change to affect real change, or at the very least set up an information environment and have everything defined the right way. 

I'm going through the process of trying to work out how to achieve this at the moment and at a very basic level below is a diagram that I think covers the pieces of the puzzle:

Elements of the Information Environment

I know that this is very broad and contains no real descriptions, it is something that I hope to flesh out in more detail as I start trying to sort it out in this organisation.  I will update it as I move along, and who knows, it might end up being another ebook topic (complete with templates and the like).

Of course I do have to be careful with it, this document was created on my time, and my system.  So I am not sharing any of the organisation's IP for this.  But it will be an interesting challenge on where to draw the line, after all this stuff has been swimming through my brain for years now.  So is it anyone's IP but my own, regardless of who I work for when I finally write it all up?? 

But that's a whole other blog post...

Appropriate triggers for projects

These posts are not rocket science, I am not saying anything here that hundreds (or thousands) of other people working in organisations all of the world say.  I guess I'm just attempting to get it all in one place, provide other people with the sanity check that they are right in thinking things aren't right, and offering some advice or suggesting better ways.

So with the first real blog of context around IT related projects I've decided to start at the beginning - the trigger for a new or upgraded IT system to support the business.

Simplistically, there are only three appropriate triggers for commencing a project to implement or upgrade an IT system.  These are:

1. there are well defined requirements that the business has developed to justify an improvement to work processes through automating them with a system
2. there are compliance issues that are driving the requirement for a system that can better support the business processes involved
3. the current software/hardware can no longer be supported within the IT environment, or no longer supports the businesses needs

Now these are pretty huge categories, and can break down into very grey areas, but that is basically it in a nutshell.

Most importantly, there are two triggers for commencing an IT related project that are unacceptable and completely invalid - and these are the definite areas to avoid.

The Management Decision

Deep breath and let's go... It is never acceptable for people in management (even the CIO/CTO) to select a product for the business.  Most of these decisions are based on sales pitches, which show them lots of pretty graphics, customised workflows and reporting screens that make them ooh and aah.  They think that they are doing the right thing by asking whether it will allow their staff to X and Y, and of course the vendor says yes.  If the CIO/CTO is involved they might even ask if it is X database or runs on Y servers so they can tick the box that it is right for their space.  But this should be avoided at all costs!!!

I have been involved in implementing and using systems that have been "management" decisions.  They seemingly ticked the really important boxes in the requirements, if there were any, but were so far removed from the actual business processes, or were completely different technologies than anything else in the environment.  There was one product in Defence that everyone knew was a bad decision, the joke was that they put on the best entertainment when the boss went over to the States to review the products on offer.

So why shouldn't management choose products?  Please remember that I am talking generally here, this is not the case for everyone but in large organisations it is often the case.

1. They don't perform the tasks - if the Undercover Boss tv series has proven anything it is how people sitting at the top do not understand how the work is really done.  If they don't perform the tasks then regardless of whether "this product has been successfully deployed in X, Y and Z" they cannot know whether it will support the way their business works.  Now, I don't subscribe to maintaining status quo in all business processes through automation - as a matter of fact I think that these sorts of projects are a great way to identify the outdated processes and overhaul the thinking behind them.  But, you can't shoehorn an entire business into a piece of software just because it works for a related process in another business, even one in the same industry as yours.  
2. They don't know what else it may need to integrate with - this is a big one, and unfortunately for many organisations no one knows exactly how all of their systems hang together and how they are used by all areas in the business.  But management are even less likely to know.  Will the system need to get base data from another system? Does that other system have the capacity to talk to this one? Will some other data exchange need to be developed to make that happen? Is there any other system that will be reliant on the new one for data? How is reporting on this information done and will the new system support it?  An IT system for your warehouse is seldom a completely contained system that only needs to work with the processes inside your warehouse - it will usually have to link to point of sale systems or financial systems or even possibly staff rostering systems.
3. They don't know what technology their business supports - if your business has all Oracle databases and you decide to acquire a product that runs on Sybase what does that mean?  Generally it means getting a Sybase administrator (or two or three depending on availability required) and purchasing new licenses - was that factored into the vendors sales pitch?? Doubt it!  What about if all of your systems are on Microsoft servers and this requires Unix servers? Not only are you up for more administrators but also extra hardware and licensing again.  As much as the current technology should not drive all future decisions, the impacts of the technology on the business (personnel and costs) must be considered and incorporated into the consideration of any product.  A "bargain" $150,000 system could cost the business two to three times more in annual running costs.
4. Vendors are liberal with the whole truth - I am not going to say that they lie, but they do certainly paint an extremely positive and optimistic picture of how their product is the best one for your business and how it will help you.  It is not their job to point out to you where all of the hidden costs are, and how the software costs they are quoting you are likely to be the smallest cost in the whole project.  It is their job to get you to buy the software (or hardware) and hopefully hire them to integrate it into your environment, because that is generally where the big dollars are made.  One thing that anyone dealing with an IT systems vendor must remember is that a system can probably be configured/customised to do anything or integrate with anything - but there will always be a cost in time and money to make it happen.  So if you say "can it produce my monthly report?" the vendor will say "Of course it can" - the question you should have asked was "How much time and money will it take to configure the system to produce our monthly report in this format?", as you hand over an example.

The IT Department's Decision

So if management shouldn't pick the product because they don't know exactly how tasks are performed in the business then we have to examine the validity of the IT Department selecting any products.  They seldom know exactly how the business works, and unfortunately in my experience many people in these departments don't care - noting that people in finance or HR don't necessarily care how IT works either, so it is not a unique issue to them.  Whilst supportability of technology is valid it shouldn't drive all decision-making, but many IT departments believe that they should have the final say on all product selection.  And unfortunately, the current paradigm really lends itself to them having this control, as the minute a project will include an IT component it is usually handed over to the IT department.  There will be a later post about how ridiculous this is, but that's for later.

As an information manager I have strong objections to IT choosing and implementing systems.  My biggest problem is around the "throw it out there and just let them do what they want with it" technologies.  By this I mean things like Microsoft Access, Sharepoint, wiki software (like Confluence and the open source systems) and even standard intranet content management systems.  Whilst most of these can be implemented with strict creation controls which allow the business to manage their information repositories, they can also just be put out there for any team/individual to create a space and lock it down, making it almost impossible to manage in any way.

But onto the reasons why they shouldn't choose products:

1. They don't perform the tasks - for all the reasons mentioned above, but this is an even bigger issue than management in many ways.  There are a lot of IT departments that seemingly have no idea what the business does and what the most important functions are (many others do but we're talking general here).  And now I am really going to get some people's hackles up here, but in my experience many (not all) of the "Business Analysts" employed to ensure that the IT department does understand what the business does are not skilled.  Ok I will clarify here - I have worked with some exceptional business analysts who can walk into a business unit and really get down to the nitty gritty of it in a short time, but I have worked with many more who cannot grasp the workflows and terminology used, even after two years of close contact with the business (don't ask).  Maybe my experiences are the exception, but I've spoken to other people who also have the same opinions, so I don't think this point is invalid.
2. They don't know what it may need to integrate or comply with - the reasoning for this is nearly exactly the same as point 2 above.  I will add that for IT departments this can be a bigger issue because of the compliance requirements.  By this I mean if there are recordkeeping requirements, if there is a metadata standard that should be used, or if there are security compliance rules around logging and monitoring.  Management will usually have a better idea of these, especially the latter ones.  The people actually performing the tasks, and the governance and compliance specialists in the business that should be involved in the projects will always know.
3. They may have a personal interest in doing so - again let me start by saying I have a lot of friends in this industry, but... there is a chance that decisions are being made to support resume building or because there is a new toy to play with that they really want to get their hands on.  The business can also be to blame for this, I'm sure there were many wikis and blogs implemented as "must haves" in businesses throughout the world in the last few years that have now slid away into oblivion.  But the IT department will generally contain more Innovators (in the Technology Adoption Life Cycle model), so they are keen to get the toys and have a play, and if they can do that during work hours then all the better.

The next post will deal with Business Requirements, and some of these things will be addressed in more detail again.  I won't apologise any further for the content of these posts, I have put disclaimers in here all along the line and I will try to be a bit braver about it from now on.  This is my opinion, based on years of experience and talking with other people about their projects.  No group in this is entirely good or bad, I will try to be even handed here, and I will even bring up what information and records managers do wrong as well.  Before anyone takes offense to any of this and comments (which I would encourage - commenting not taking offence) take a breath and think about why you are offended, and whether anything I've said here is entirely wrong.

A metaphor for "IT Projects"

This goes along with the Project Series posts, but is not the next post I planned to make.  But, I was very happy with this metaphor, which I am going to use to try to explain some things to management in my organisation.

Basically, my organisation deals with assets, so I started thinking about building projects and how I might be able to explain the importance of the end part of "IT projects".  The problem is that there is a perception (which is not unique to my organisation) in management that when the system is turned on the project is complete.  Nothing could be further from the truth.

So what is my metaphor?

Building a House

When you commence a project to build a house you know that the project ends when the house is complete and can be occupied.  When a project to implement a system is "complete" is a little more difficult but...

If you think of the "go live" date as the house being in lock-up stage then I'm hoping this will help the managers.  Basically, when a house gets to lock up from the outside it looks like a house, but it is really just a shell that still needs a kitchen, bathroom(s), painting, floor coverings, services connected and everything else to have it fitted out.  You don't close the project and redirect you building project manager to another build at this stage.  They are required to stay on board until a Certificate of Occupation (or some such documentation) is received for the building - that is when the project is complete.

IT Projects, or specifically projects that have an IT component, are exactly the same.  Go live is like getting a house to lock up stage.  The project still has a long way to go until completion.  The system needs to be bedded down, bugs need to be fixed, tweaks done, documentation completed, integration completed, training undertaken, support procedures put in place and a number of other minor tasks.  Whilst many of these should have been planned for and commenced during the development phase of the project, it is not possible to have them all complete and implemented by Go live.  Therefore, the Project Manager and project team still need to exist, maybe in a different configuration, until there is a sign off that the business has accepted the system, or is deemed occupied.

So that's my metaphor, I may even do a brief about it and if I do I'll put it into Slideshare and link back.

Epiphanies

You know how sometimes you are sitting there talking about things and a thought comes into your head that you think is pretty cool, well I just had one of those. Very soon I will be briefing our Executive about improving our records and information management. I was thinking about some of the databases that we have and playing with words in my head about trying to get them to understand the importance of this data and how we can use it.


We're so used to thinking of documents as "unstructured data" but the thought I had was this:

Data is an unstructured document that is yet to be developed into a story.

I don't know whether this is any sort of revolutionary thought as yet, but I am hoping that I can develop it to make it something that will help the Executive understand the value of our analysts and reporting regimes.

I'll have to think about it a bit more...

Problems with IT Projects - Series

Okay, so a few days ago I mentioned that I was going to start writing a series of posts about the problem with IT projects. I've been trying to work out how to structure this series, and I've decided that I am probably just best off starting and working it out as I go along.

Is there really a problem?

I have been involved in a number of IT projects in the last ten years, whether as a project manager, business representative or a user within the organisation. Being an information manager, I am sometimes even asked to provide specialist advice on some of them. I also have friends in the IT industry and have spoken with many peers about projects in their organisations. From my experience and their experience I would have to say that there is a real problem with IT projects.

The general situation in the organisations I have worked in, and those of my friends and peers is that there is a high degree of cynicism about IT projects. The assumption is that IT projects will not deliver on time, that they will inevitably cost more than the proposal and probably the worst one, that they won't deliver what they promise.

Sadly though, my experience of the IT areas that are responsible for delivering these projects is that they don't seem aware of the reputation they have - either that or they have just accepted it and moved on.

An absolute classic example of the fact that IT projects are broken was on the news tonight - Aurora's massive blowout. The billing system that was supposed to cost $15 million to implement is now likely to cost $65 million. No I did not misquote this situation - that's a predicted a $50,000,000 overspend (not it isn't implemented yet!), more than four times what it was expected to cost!

Apparently they did not realise how complex this project would be. Someone needs to be sacked over this one - seriously! Who wrote the business case? Who did the scoping study? How did they select the product? What was the trigger to update the billing system in the first place if they had no comprehension of how involved the integration would be? How did it get this far without someone calling a stop to it? Where is the possible ROI on this?

I could go on with the questions, but the fact of the matter is that this is not an isolated incident. There would be hundreds, if not thousands of IT projects around the world that I could have used as an example here.

So since I've established that point next post will be the trigger for a new IT system - what is acceptable and what is not.

Problems with IT Projects

I've been thinking a lot lately about how few IT projects, within the organisations I have been part of, have been successful. They either end up going over time, over cost or not delivering the functionality that the users require. And yet, we continue to deliver IT projects the same way.

So I'm going to do a series of posts over the next few months about the issues as I see them and some suggestions. What I am thinking of doing is using this as a development mechanism for an ebook on the subject, but we'll see what comes from the posts first.

No one is to blame

Most importantly, this series will talk about the failings in IT and the business. This paradigm is not broken because of IT or because of the business, it is a mixture of practices that cause the problems. This is not about allocating blame, it is about trying to find a better way to deliver IT projects.

Some of the things I say here may put some noses out of joint and make people defensive. For this reason, each post will always try to present both sides of the issue. And if all else fails, people reading this should try to remember that whilst I am an information manager, my partner (and a few of our really good friends) is a systems engineer. So I'm not all about bashing the IT people, or else my home life won't be much fun :-)

Prezi presentations

From one of my favourite blogs (ilibrarian), I found Prezi the other night. It's a fantastic zooming presentation tool that I think I will have a lot of fun with. I was playing with it a bit yesterday and did a little presentation on designing systems that support information workers.

System to support information workers on Prezi

Like Wordle, there is a good chance this will become another standard toy. I'll have to think about buying the desktop app once I play with it a little more.