back to article Project over-runs make US IT workers scared for their jobs

The majority of European IT professionals say that a failure to finish projects on time would not pose a risk to their job. Under a quarter of IT workers in the US felt safe enough to say the same. The Economist Intelligence Unit (EIU) and Hewlett-Packard conducted an investigation into the delivery of large scale IT projects …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Why Swedes Complete Projects On Time..

    The vast majority of Swedish managers are properly educated ie have a science, engineering or technical degree, and the Swedish business ethos is about rational decision-making. Compare this to the UK, where only 34 % of managers are educated even to A-level, and you'll begin to understand why there's so many PHBs and so many irrational buzzword-based nonsense projects .

  2. Maria

    drawing the wrong conclusions

    The top three most common delays were outsourcing, a change in management priorities midway through a project, and poor co-ordination between managers.

    "Companies that succeed in accelerating IT project and service delivery have a significant advantage, while those that do not may suffer at the hand of the competition."

    Important to note that to "succeed in accelerating IT Project" you need to improve outsourcing and how management behaves.

    Too many companies will use this report to conclude they need to improve how IT staff is managed, or what software they use to manage projects. Neither of those things will improve the "top three most common delays".

    Also important to note that a change in management priorities might indicate a shift in business needs. This might be a legitimate reason that one proejct gets held up while another takes priority, or why project specs get changed. It would be stupid to insist on completing the original project/specs on time when this is not what the company needs.

  3. Brett Brennan

    It's all about timing, then...

    I have a -LOT- to say about this - however, it's too depressing to discuss. Suffice it to say: in most Fortune 100 companies, IT projects get a schedule and a budget BEFORE they get requirements. Period. And managers NEVER pay for failure. (Well almost never, but never above the Group Manager level.)

    I often have discussions on the lack of work ethic among younger IT workers (under 30) with my contemporaries (over 45). All I can do is point to these projects where whoever gets assigned to them is going to get crucified - so who is going to bust ass when all it will do is get them fired quicker?

  4. Dillon Pyron

    Scope creep

    Subject says it all. Numbers one through three.

  5. Anonymous Coward
    Anonymous Coward

    hiring moe inexperienced staff doesn't help

    I spent more time bringing temporary staff up to speed with projects and explaining our development cycles, methodologies and coding standards that i actually spend doing any work nowadays

    A lot of the time quotes for work are trimmed to make them more acceptable so more business is generated. After all the developers and analysts sit down and discuss exactly how long a project will really take and a manager applies that magic formula that inserts extra time for people to take a toilet break every so often, someone further along the line says 'theres no way a 14 month project will be accepted, this has to be ready in January, i'll just change this to 8 months instead and hire a couple of contractors to take up the slack'

  6. Henry Wertz

    Swedes?

    Well, if what you say about the Swedes is true, that would in fact explain it. The couple projects I've known about that went over budget or over time, well, basically, it didn't go over the *estimated* budget or time. A manager would have a conversation like "What's the quickest time this project can be done in?" "One month" "OK, finish it in two weeks". Shock! It took a month, so the project went 100% over on time.

  7. Andrew Moore

    Apply Scotty logic

    Multiply the true deliverable time by four and then deliver it on the original timescale. I do this all the time and get much praise from management for coming in under the deadline. When I'm asked to train up other departments on my unique skills- I tell them the same thing.

  8. Anonymous Coward
    Anonymous Coward

    sounds very familiar

    "How long will it take?"

    "X months"

    "Great! X minus 3 months!"

    "How long did they say it would take?"

    "X minus 6 months!"

    "Great! X minus 6 months!"

    ...etc...

    Sigh.

    I expect it will all be covered here and has been by Scott Adams many times, but here are my criticisms...

    1) Stop allowing well-paid managers with absolutely no clue about IT to make the buying decisions. They invariably go for the 3rd party with the cheapest option or the best presentation and they are invariably crap.

    2) DO NOT allow scope creep. Stick to what you want, not "Ooh can we have this as well? Free, if possible?" FFS

    3) If you bring in contractors to work on in-house systems which they've never seen before, don't be surprised when they deliver crap.

    4) When the project is behind, DO NOT bring in more managers - lack of managers is not your problem.

    5) When developers (lack of which IS your problem) tell you that there is no way the project will make the go-live date, don't implement [an unusable system] early to save your corporate arse and your fat bonus.

    Well, I'm sure others will fill in the bits I missed...

  9. Anonymous Coward
    Anonymous Coward

    Plan for Public Sector IT projects

    1) Someone has a vague idea, the vaguer the better, can't be questioned on it then.

    2) A budget is allocated according to what's available from central government ring fenced funds. £5 or £5mil, whatever we can grab with a barely plausible justification.

    3) Time-scales are imposed. Deadlines often based on retirement or potential promotion prospects at a given date.

    4) A project manager is assigned, usually in house promotion with no experience or ability. Often a Gym colleague. Qualifications considered a barrier to success.

    5) Design is cut short cause no one knows what the problem is, let alone the solution. Holidays booked.

    6) Panic sets in as 1/2 of the project time has now passed. Implementation begins of whatever has been bashed together as a best guess.

    5) Implementation completed however testing has to be cut short because the deadlines been brought forward and no one thought to tell the developers.

    6) Someone points out it solves a problem that didn't actually exist before the system was created.

    7) The developers all go on holiday stating the need for a 'break' away from it all. Project time-scales restored to previous values.

    8) One week to Project completion. The project can't be scrapped as too much time and money has been spent. Besides it might make the senior management team look silly. So the developers are told to make some quick and dirty alterations to solve some 'newly identified' problems so we can say its a success. Developers informed project needs to look the part, functionality not essential at this late stage.

    9) 3 months later...

    For some unknown reason It seems that the division using the new software found it necessary to employ additional staff to cope with the migration from paper based to electronic work flow. Outside consultants are brought in to evaluate the performance of this division, they recommend splitting into two groups, both need new customized software based on the original. A new project is started.....

  10. Kris

    Documentation

    I like how in house applications that run over suddenly 'loose' all sense of documentation... Help file *gone*... how to use the application *gone*... setup instructions *gone*... helpful comments in code *gone*...

    And I'm seriously tired of comments that look like "Doug said that this is the way to do it because of the error, hope it works." Doug?? error?? wt* are they talking about?!?

  11. Martin Owens

    To Qualify

    In order to become a manager you not only should be able to show true leadership skills (something no one bothers to teach any more) but you should spend 2 years under some of the worse idiots in simulated IT project VR games; then 5 years as an apprentice manager for someone who passed with flying colours.

    I know some good leaders and I know some brilliantly technical people. I know only one person with any amount of both enough to drive a project to date and he's Egyptian.

  12. Anonymous Coward
    Anonymous Coward

    "...Swedish managers are properly educated... "

    I'm sure they are, but I resent the implication that because I didn't take A-levels or go to university (I'm a completely self taught Oracle Certified Professional, with 22 years experience in IT) that I am somehow not "properly educated". When I started work in IT, their wasn't even an O-level course in programming (GCSE for the youngsters). All the programmers I know of from my generation taught themselves, on ZX81s and BBC micros etc.

    We frequently get so-called educated staff who have degrees coming out of their ears, but don't know an IF statement from a serial bus...

  13. Mark

    Resource

    I've worked in so many different companies and on different projects (as a contractor) and, looking-in as an external resource the problems are quite similar in every company.

    I think IT workers, be they proj managers, developers, testers etc should be treated a bit more harshly. There are so many of these people leeching off skilled staff - they only survive by draining the time and energies of people genuinely skilled in their jobs.

    Then there are people who've established a 'niche' skillset within their company, and they write some code or become specialised in a product etc. The problem is then that these people show aggression towards sharing their skillset/knowledge with others. For example, I worked at a place where new scripts for monitoring production servers could not be activated because the only resource in the company who could activate a middleware program they'd written (to pump data into netcool) decided to take holiday at very short notice. That delayed the project for a week!

    The thing that annoys me the most is outsourcing - to both UK contract resource and abroad - to people who really can't do the job. These people then come into a company and earn a significant margin over the permanent staff who they rely on to do the job for them. Another company I worked for (when I was a permie) opted for bringing in resource, in fact a flood of Test Analcysts. These people basically created spreadsheets of dates from existing mpp plans. And that was it. They didn't actually do any of the work. So the company increased its project load and the permie staff took a hammering, which is one of the reasons I left.

    Another is managers with political agendas. I was involved with interviewing outsourced staff for a certain project and, after about 9 interviews we had nothing. Then we found that the outsourcing company had an account manager on the interviews to 'coax' the interviewee's... then we also found that the candidates seemed to have pre-versed answers to our questions, so we changed the questions without informing our (Indian) manager and the candidates struggled like anything.

    Eventually I was taken out of the interview loop and, suprise suprise a week later outsourced resourced flooded in (Indian), and there have been complaints about them ever since.

    This post probably makes me sound like a right barsteward, but I'm just relaying my experiences!

    In my opinion companies seem to focus on the wrong things.

    To me the resource of a company is like a turd. A turd that contains gold nuggets on a small ratio of corn nuggets vs poo. A company should not focus on increasing the poo-matter, instead it should focus on digging the sweetcorn out of the turd and reducing the overall mass of the poo. In this way golden nuggets can achieve whilst the restraining poo can be chopped off.

    All too often the sweetcorn within the resource turd is left to be overwhelmed.

  14. This post has been deleted by its author

  15. Anonymous Coward
    Anonymous Coward

    Swedes?

    Is anyone else wondering - if Swedes are so good at delivering IT projects, why aren't they winning all the major IT contracts around the world?

  16. This post has been deleted by its author

  17. Ishkandar

    Re. Evil Graham

    The answer is simple !! They are _NOT_ foolish enough to bid for undeliverable projects based on politics and wishful thinking instead of logic and analysis and proper funding !!

    Take our Great British Shining Examples in the world of IT - the NHS project, the Home Office biometrics projects, the HMCR tax project, ad nauseum...

    Then again, it's not just in IT that these things happen. How about the Pride of London - the Millineum Dome !! Or, even better, Wembley Stadium !!

  18. Anonymous Coward
    Anonymous Coward

    Amen...

    ----

    All too often the sweetcorn within the resource turd is left to be overwhelmed.

    ----

    Amen to that.

  19. Anonymous Coward
    Anonymous Coward

    swedes

    "if Swedes are so good at delivering IT projects, why aren't they winning all the major IT contracts around the world?"

    Because not a single manger I have ever known would accept a realistic tender. They'll go for the quickest, the cheapest or the one their tennis parner is fronting.

  20. John Dickson

    Swedes have a different world view

    I've worked on projects in US and Sweden and I think they may be counting different things. In the situation where the project is going to over-run, and you get assigned new (longer) deadlines which you then meet, that counts as on time in Sweden. But in the US it counts as late.

  21. Anonymous Coward
    Anonymous Coward

    Swedes and On Time Projects

    My direct observations and experience with Swedish IT Projects

    1. Projects are planned with longer leadtimes to make sure they are completed on time.

    2. If problems come up in the scope of the project they plan a step 2, or step 3 which is considered another project. This way they don't miss the deadline on the original project.

    3. In most cases (not all, but most) they throw a lot of extra money into the project to get it done on time, and then add a step 2 or 3 as another project. Projects tend to always go over budget.

    {SIDEBAR} IT people don't get fired, if they are a consultant then their contract isn't renewed. If they are an employee then they are generally given several strikes before they are reassigned a job so tortuously unbearable they quit.

This topic is closed for new posts.

Other stories you might like