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 .
It's all about timing, then...
By Brett Brennan
Posted Thursday 7th June 2007 18:46 GMT
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?
drawing the wrong conclusions
By Maria
Posted Thursday 7th June 2007 18:46 GMT
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.
Scope creep
By Dillon Pyron
Posted Thursday 7th June 2007 19:19 GMT
Subject says it all. Numbers one through three.
hiring moe inexperienced staff doesn't help
By Anonymous Coward
Posted Thursday 7th June 2007 19:24 GMT
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'
Swedes?
By Henry Wertz
Posted Thursday 7th June 2007 21:36 GMT
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.
Apply Scotty logic
By Andrew Moore
Posted Thursday 7th June 2007 22:32 GMT
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.
sounds very familiar
By Finnbar
Posted Thursday 7th June 2007 23:21 GMT
"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...
Plan for Public Sector IT projects
By Anonymous Coward
Posted Thursday 7th June 2007 23:25 GMT
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.....
Documentation
By Kris
Posted Friday 8th June 2007 01:08 GMT
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?!?
To Qualify
By Martin Owens
Posted Friday 8th June 2007 04:45 GMT
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.
"...Swedish managers are properly educated... "
By Anonymous Coward
Posted Friday 8th June 2007 07:59 GMT
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...
Resource
By Mark
Posted Friday 8th June 2007 08:29 GMT
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.
Prodjects are always finished on time
By Anonymous Coward
Posted Friday 8th June 2007 08:56 GMT
If not, then the deadline was wrong.
Now, seriously, during my 35 years as a programmer / systems analyst I have found that all deadlines are based on "wishfull" thinking bye those who are not doing any of the job. Often bye those who sell or bye.
A long time ago I had a boss who used to say "Just do it as fast as you can".
That worked very well and systems where delivered, probably, faster than with some random dealine.
The real problems start when systems are delivered to "customers" as half made due to some deadline and then finished as hacks upon hacks to the customers.
Swedes?
By Evil Graham
Posted Friday 8th June 2007 09:01 GMT
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?
Open source
By Anonymous Coward
Posted Friday 8th June 2007 10:01 GMT
I am not surprised that open source attracts programmers around the world as that seems to be the only place where a programmer is allowed to do good programming.
Mad deadlines will kill the quality of any IT prodject.
Re. Evil Graham
By Ishkandar
Posted Friday 8th June 2007 10:39 GMT
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 !!
Amen...
By Anonymous Coward
Posted Friday 8th June 2007 12:01 GMT
----
All too often the sweetcorn within the resource turd is left to be overwhelmed.
----
Amen to that.
swedes
By Anonymous Coward
Posted Friday 8th June 2007 14:18 GMT
"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.
Swedes have a different world view
By John Dickson
Posted Friday 8th June 2007 15:28 GMT
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.
Swedes and On Time Projects
By Anonymous Coward
Posted Friday 8th June 2007 17:57 GMT
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.
The period for commenting on this story has finished
Find out how Trolltech has made it easy for developers to implement web content directly into their native applciations through the integration of the WebKit rendering engine.