Support the cause!

Previous:

Responsibilities

Philosophies

The correct philosophies to drive success seem to be missing in companies;

  • Encourage mistakes to be reported

A place to look to is hospitals, here they cant afford to make mistakes, so the management team is actively encouraged to highlight mistakes, so they can be resolved. This is not the case in IT and mistakes are often frowned upon, so they are buried and the root cause never resolved.

  • Listen to estimates

By way of an analogy: If I am a respected construction firm, and was to build you a motorway bridge and I told you that it would cost $100M and take 2 years, would you then cut the budget and tell me to still deliver on time?

This happens all the time in IT and it is both IT and the business' fault. IT needs to stand up more and the business needs to trust IT more. It is totally a cost quality time relationship.

  • Reward on successful ROI

Projects should not be measured on delivery date, but many months, possibly years after delivery. And also based on alignment to the business strategy. Too often it is just “on time and on budget”. I haven’t heard a PM say to me that they delivered “on Quality” [fit for purpose]

  • Spending effort up front saves a lot of time

This is possibly a repeat on the quality theme, but Henry Ford had it right, put the quality checks up front, don’t check a finished car at the end of a production line for a bent chassis. It is not just checking, but ensuring that shortcuts aren’t taken at the start of a project, again to shrink time and cost.

  • Break large projects up

IT projects are complicated and the business changes rapidly. Ensure that projects are broken into smaller parts so that business change can be built in as the project evolves, and that users can get a handle on what they have requested. A business does not stand still while a project is being delivered.

  • Don’t do too much at once

Keep focussed on the task at hand and put more energy in to doing a few things very well than many poorly.

  • Reward staff appropriately to get the right behaviour, e.g. quality, time and cost, not just time and cost.

How many times have you heard about a project on (or off) time and budget? What about quality?

  • Keep the authority-responsibility-capability triangle balanced when assigning large tasks to people and teams. Success comes from the lowest denominator of these.

This is a great tool to get the best out of people. It works best once you have found the lowest common denominator, e.g. if a person has low authority, then you can only expect low responsibility and capability.

What’s your opinion?

What do you think of Philosophies? Is there anything you think we have missed?

Liz Schoff says:

Hi, Scott - How about this a radical thought - what if we were to 'NEVER CALL IT AN I.T. PROJECT AGAIN' - these are all business delivery projects. In early days, maybe Henry called it a 'MOTOR' project, because the motor bit was new and shiny and people had been putting wheels and chassis together for buggies, so that didn't seem as hard. But surely Ford doesn't call it a 'MOTOR' project when they build a new car today? Maybe it is time for us to all look at the technology as one bit of the whole package.

In reply...

Scott Groombridge says:

Great idea and totally in line with Getting IT Right. Henry has so much to teach us, e.g. check the chassis at the start of the production line, not after we have put all the other components on.

Scott Groombridge says:

Great article by John Holley around IT and Strategy

Want to have your say?

Click here to skip right to the bottom and give us your opinion.

Post A Comment
Fields marked with an * are required

We will never display your email address on the site.