September 30, 2010

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.

September 27, 2010

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.

September 19, 2010

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 :-)

September 7, 2010

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.


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.