The IT Leadership Deal

Simple - not easy

Few companies of any size do it effectively; some do it very well, some do not. Not just projects involving IT. Whether you do it in your company, is your choice. And, as with The Deal, you can either choose to run your company like that, or you can do choose to do something about it.

Here's what to do:

Nothing - OK - then keep doing what you are doing / not doing now - just stop pretending you want to do something about it

The Small step - Have a list of all projects across your organisation and put them into clusters, One, Two and Three - or Red, Amber or Green, or whatever. Upside it can happen fast, downside is everything gets put in category one.

The Big One - Have a list of all projects across your organisation and list them in importance. Only the Board can do this and they won't do it unless they are encouraged / provoked. Best way to do this is to take a list to them and say that is the one you will be using unless they do it.

...Never call a project an IT Project. Or, do, and continue to annoy the rest of your organisation. So, every project in your company is a company project, and if it happens to be started within IT, and owned by an IT leader, that IT leader is owning it as a business person first and foremost. And if they are owning only the IT element of it, there must be a non IT equivalent owner, and the two must form a close, trusted relationship...

...Just go to a Project Management Meeting - they are a complete waste of time - no-one raises the real issues, no real discusions take place, and they rarely reach true decisions.

Don't go to project management meetings unless you have time to waste, are a masochist or need to catch up on some much needed sleep.

They are for show, because everyone attending only has one item on their agenda, protection of their backs...So, what to do? Your project success comes down to three things - how empowered (read, free) the team feel (with clear boundaries), how clear the overall vision / deliver for the project is and most importantly the informal, trusted relationships that are formed...

...Are in this order - 1. They are very clear on what is to be achieved, the end result and benefit to the company, this is clear, concise and compelling and everyone involved in the project knows this outcome, and the role they are personally playing in making it happen. 2. The people who "own" the project are the people for whom the project is being done - customers, an internal department, and they buy into the benefits of why the project is being done, from day one and 3. Everyone on the project team respects, values and trusts each other - faced with the common enemy of potential failure (not delivering).

..."How does this event / problem / challenge help us complete this project on time?"

I used to write a column for CW - called Inside Track. So...?

For one week only I am revisiting a selection of the challenges - if you think it is still a problem, some ideas to stop history repeating itself. If you don't, go enjoy enjoy...

1st published in CW on 10th June 1999 - this is verbatim and I stand by the guidance today. By the way, that was the day on which this vital thing also took place...

So What?

We all know, but rarely admit, that most IT projects, packages and Software fails to deliver real business benefits.

IT departments are having to constantly justify their presence as a business asset. Projects that are late, over budget or fail to meet their aims do not help with this justification.

All business applications, packages and Software consist of:

Features
Advantages
Benefits

Features are those parts of a system that are never used. Perhaps the needs changed during the project, or additional specifications were added. Features are present in all systems; the problem comes when they dominate. For example, what percentages of PowerPoint or Freelance do most people use in every day work? Probably 20% at most. They do not need to use more, and do not have the time.

And so it is with many in-house systems. A relatively simple business need becomes a complex application, full of functionality that seemed a good idea at the time, but adds nothing to the organisation’s aims. Indeed, programs are often added later in a project, specifically to bypass code already written. Features add nothing to the bottom line, delay development, and cost more money.

Next time you develop a system, make sure you spot the features, and leave them out.

Advantages are the parts of packages and programmed developments that make life easier, are nice to have or used by very few, but cost far more to develop than their results can justify. Advantages are often justified as “non-tangible.” This is a cop-out, if it can’t be measured, don’t include it. On a pure cost v benefit basis, advantages add no bottom line gain to a company. Advantages are better than features, but not by much.

Corporate IT in business must focus on the delivery of tangible, measurable, and repeatable benefits. Benefits provide competitive and corporate advantage. They lie at the heart of successful projects.

All projects must be justified on the basis of the benefits they deliver. Forget the never used, or nice to have, we do not have time, resource and energy to waste. Be absolutely ruthless with all proposed projects, and in all reviews you carry out.

Benefits come from on time, or early delivery, so go live with something sooner rather than waiting for the complete picture later. They are measured against initial investment, so focus your spend on the core functionality your company needs.

Most of all, they come from staying ahead of the competition, and to do this every single IT project must put you ahead of your competition. Forget features, be aware of the cost of advantages, and deliver benefits.

Tomorrow : Perception