Managing IT Projects

Managing IT Projects

The project manager tells you the project is done. You ask to see the finished product. You get whizzed through a few screens on your laptop and there it is - the product of a £10M investment.

But how do you know there is anything behind the facade of the screens you just saw? In a construction project you can see the building, touch it, walk around inside it. In an engineering project you can see the shiny new line in operation. But in a software project the actual stuff produced by the team is a million lines of gobbledegook and even if you did see them you'd have no idea if it was your million lines of gobbledegook.

Who was the project manager? At the outset you thought that since it was an IT project some guy from IT should manage it and IT should get on and do it. But then the IT guy said he needed twenty of your business people to work on the project as well as thirty of his people plus ten contractors - and it would take 2 years to do! So you decided to have one of your business managers take over the project: John Smart, one of your top go-getting sales guys - he knew how to motivate people and how to get things done.

Indeed John Smart had said if IT said it would take 2 years he reckoned he could get it done in a year if he was in charge - and he'd get IT to do the work rather than dump a lot of it onto your business guys.

And it had all seemed to be going so well. A nice system design document had been produced which looked great, work had started on the coding (whatever that is) much earlier than the IT guys had said was possible and all was on track for completion at the end of the year.

Everything's Going Fine

But then you had received reports from your people that they were being continually pestered by the IT guys with hundreds - thousands - of questions. You soon put a stop to that.

And then John Smart left for a better job with a rival firm, though it didn't look like a better job to you. And you found that none of your business guys wanted to take over the project. And the original IT project manager - who had been second-in-command to John Smart - was on sick leave due to stress, and none of the other IT guys seemed to know what was going on. So you brought in a firm of consultants to look at it.

They concluded that despite the fact the project had been running for 10 months and was supposedly only a couple of months from delivery, the thing was actually a shambles and the team were "running around like headless chickens". Reluctantly you signed up for a team of six of the consultants to come in and sort it out for you.

It looked to you as though they were almost starting the project again, specially when they told you it would take 18 months to get the project finished.

And their first act - once their contract was signed - had been to give you and the other execs a grilling about what the project was for (wasn't that clear?). Then they had insisted on taking several key business guys out of the front line for weeks to set out in crazy detail what it was the system was supposed to do (what are IT guys for?).

Then a month or two later they had taken those business guys away again and had them do some of the system design work, and then had them spend ages playing "what if?" games with the design - "testing" what the system would do given various inputs. All things you thought IT guys were supposed to do. But again you weren't going to argue with the consultants given how much you were paying them.

Shortly after that, during the programming stage, the consultants became even more unpopular as they refused point blank to accept improvements that were recommended by your business people. Their claim that even the tiniest change would delay the project and cost an awful lot didn't seem plausible, but nevertheless you backed them - which didn't make you particularly popular either.

In the end the project took just over 2 years - plus the wasted 10 months - and it cost three times as much as originally estimated once the consultants' bill and the cost of backfilling for the business guys while they were swanning around on the project were included - not to mention the lost business opportunities because key people where away from the front line.

Still, at least the original IT manager recovered from his stress and by common consent had played a key role in getting the thing delivered. He now has a job at twice the salary with the consultants.

Managing Future IT Projects

The Board realised that company expansion would mean several more IT projects in the future and gave you the job of ensuring the company had the capacity to get those projects done.

You hired a consultant to advise you. You were fortunate enough to find someone with good project management skills, an understanding of IT and knowledge of your company. Your old IT manager.

He set up a programme of training for business people. For the execs a one day session explaining what IT projects were all about (and interestingly the similarities between designing and building software and designing and building houses which for the first time made everyone realise why changing things half way through the build is so expensive), and the key role the "project sponsor" (you) and other execs should play in IT projects. Then a 3 day session for all business people who were going to be involved in IT projects and the same 3 day session for the IT guys. In fact each session was a mix of business and IT to break down some of the barriers and show them how to work together on projects. A slim book of rules was produced setting out the basics of what various role players (eg the sponsor, the business project manager) should do, and things like how project progress should be reported (ie not just John Smart's "it's fine don't worry").

A couple of projects have been done since then and they have both cost more than originally estimated but both finished more or less on time and both worked. So we're getting there. Oh, and we don't have IT projects any more. We just call them projects, recognising that they are business endeavours which just happen to involve IT people.

Managing IT Projects - Read All About It

This Project Management Book sets out how businesses should run IT projects. Project Management Book.

Project Management Articles:

Making Companies Project Friendly

Quality Management in Software Development Projects

Project Management Proverbs, Saying, Laws and Jokes

Free Online Project Management Book

So You Want To Be A Project Manager?

Risk Management

The Tale of Three Project Managers

Project Management in the Public Sector

Managing IT Projects

Privacy Policy and Cookies