With maths and syntax like that
Nearly 40? I'm nearly 40. 40 what? Projects, percent, people??
Is it any wonder they're failing?!
One-third of Brit IT projects on track to fail
Nearly 40 per cent of IT projects in the UK are on course to fail, according to a survey of 182 project managers. That is according to the research commissioned by Axelos, the joint venture set up in 2014 by the government and Capita, to develop, manage and operate qualifications in the project management methodology PRINCE2 …
-
-
Monday 3rd July 2017 17:56 GMT Ian Michael Gumby
@Rocket Rabbit ... Re: With maths and syntax like that
The flame is because as you say you're nearing 40 you still have issues with reading comprehension.
The story is a bit self explanatory with the sources of the numbers.
I would say that the inability to pay attention to details is a major cause of failure, however this is probably under reported or grouped in with one of the other categories like staffing.
Seriously... all of the reasons provided are valid reasons for project failure in some cases all of the above.
-
Monday 3rd July 2017 22:30 GMT MarkSitkowski
Re: @Rocket Rabbit ... With maths and syntax like that
"...all of the reasons provided are valid reasons for project failure in some cases all of the above."
I think they can all be summarised in one reason: the project manager didn't understand the technology.
If you're from a development background, then you know the approximate time a given task should take, and you can qualify the estimates given by the staff. If a developer gives you an excessively long estimate, this tells you something about either his technical competence, or his level of commitment.
When you're given the timeframe, you can compare it with your own estimate of project duration and have the management amend theirs. If they won't, you ask for confirmation that they take responsibility for the overrun.
When the marketing people decide to add features in mid-project, you submit a new project schedule, with revised costs, and a request for the confirmation mentioned above.
I'm not saying that all this will guarantee that you run to time and to budget, but it may help your bosses to eventually understand what factors should be taken into account before they say things like "Here's the job, you have five guys and three months to do it".
-
Tuesday 4th July 2017 06:50 GMT Guus Leeuw
Re: @Rocket Rabbit ... With maths and syntax like that
Dear Mr Sitkowski,
As a trained-software-developer-turned-project-manager, I can say that you are quite wrong.
You see, before something is a project that is being executed, there's a bit that is called "sales". Very often there are market pressure that sales people have to adhere to, and that means that often enough that a service is sold for less than what is effectively necessary to come in on budget. This is called "discounts". You then see that the end result of the discounting process is the project budget. This is incorrect accounting, however the project manager is then ultimately responsible for cost overruns, even though it was the business who decided to give the customer a large discount.
There's also unrealistic expectations set by clients, whereby clients cause project starts to be delayed (due to contract negotiation or holidays), but the same clients forget that that automagically means that the end date is shifting as well. Such clients are then normally very adamant that the end date stays the same, even though we're now 3 or 4 months delayed from a project start point of view only of themselves.
Only then are we starting to get into the game where a project manager can really influence the course of action.
And even if a project manager understands the technology (because he is / was a software developer), I've seen some very very bad examples, and I'll give you two:
1) Shit is hitting the fan, project manager states: I knew this was going to happen; yet "this" failed to registered on any risk log and was never mentioned to senior / programme management - so there never was adequate risk management. But clearly "I knew this was going to happen" means that the project manager understood very well what problems could arise
2) Multiple 3rd parties involved where the customer is not efficiently participating in multi-vendor management. This may mean that delays by one of the 3rd parties causes budget overruns for another 3rd party, as the customer still wants to stick to the project schedule. This might come to play when you *think* the other 3rd party is going to respond within 3 business days, you confirm this with the client, and the other 3rd party turns around and says that their contract stipulates 2 business weeks... Lots of delays, nothing to do with understanding technology...
So your statement is a bit sporty, and not always correct.
Best regards,
Guus
-
Tuesday 4th July 2017 11:10 GMT Anonymous Coward
Re: @Rocket Rabbit ... With maths and syntax like that
"Talk about the blind leading the blind!"
Not surprising, considering the person apparently in charge (one Ms. Jane O'Stockphoto) doesn't even have any glass in her spectacles.
-
-
-
-
-
-
-
Monday 3rd July 2017 18:52 GMT Anonymous Coward
Re: "But it is expensive"...
That is the problem. If it breaks at work, then it's not because the manager buys the cheapest thing out of the Argos* catalogue, but because, obviously, staff broke it.
When it comes to replacing it, just 1 month later, when everyone bemoans the build quality... what do they do? Complain both that the staff attitude is bad AND the staff should not have broken the item...
... proceeding to buy an even cheaper product (this time out of a similar but worse category, hence why it was not purchased first time), and why? Because "we cannot afford to keep replacing these", not because the budget won't cover it, but because "it keeps breaking". Well, of cause it will, you won't stretch the extra couple of quid (£100 this time though) to get a decent one.
Do the staff complain this time? Nope, they just let it continue broken unreported, because they don't want to be labelled as "trouble makers". I'd not know the reasons for picking cheap crap every time. As buying double or triple is not saving them anything!
*add your required store/supplier/industry of choice.
-
Tuesday 4th July 2017 12:45 GMT Anonymous Coward
Re: In other news
Pretty much every project I work on has this issue. Time and time again the powers that be decide to ignore hardware and software requirements written in black and white from the manufacturer and do something cheaper instead. Of course they decide this without the technical lead there as they don't want anyone to challenge this decision, or to be accountable, and they always look mystified when the project does fail.
-
-
Monday 3rd July 2017 12:24 GMT Tom Paine
Re: In other news
Or indeed the incomprehensibly little-known Tony Collins. My copy of this went to as PM who never returned it, I should pick up another second hand copy really...
https://www.abebooks.com/servlet/BookDetailsPL?bi=19747550976&searchurl=tn%3DCrash%26sortby%3D17%26an%3DTony%2BCollins
-
Monday 3rd July 2017 21:54 GMT Roland6
Re: In other news
>It's almost as if nobody bothered to read Mr. Brooks excellent book on this subject.
Probably because they take one look at the date (1975) and decide that as 'computing' is such a fast moving field (it isn't, but it's repeated so often that people think it is so), something that old can't be relevant to today's IT delivery methodologies...
-
-
-
-
Monday 3rd July 2017 10:28 GMT Pete 2
Re: Definition of fail
> What does failure mean
Well, that's the key.
As far as the client goes, failure should mean not doing what it says on the tin, OR costing more than was expected. But in the real world a project is really only a failure if the IT director gets sacked or misses their bonus.
But to the contractor it only means not getting paid. Whereas success means upselling a whole load more stuff that the client didn't know they wanted until a salesperson told them so. A variant on that is getting another contract to fix all the problems in the original piece of work.
-
Monday 3rd July 2017 10:52 GMT big_D
Re: Definition of fail
More like, it doesn't do what the customer thought the tin said...
Customers often sign off on projects, where they have little or no understanding of what they have signed off on (fault lays on both sides) or they thought they understood what they had ordered, only to have it not do what they thought they had asked for, but not defined in writing.
-
Monday 3rd July 2017 12:16 GMT Alan Brown
Re: Definition of fail
"A variant on that is getting another contract to fix all the problems in the original piece of work."
I know a couple of companies that _specialise_ in going into sites where a specific other company has failed(*) and fixing the project to work properly (despite never being able to work off the original design)
They do it quickly and cheaply, which results in very happy customers and an almost guaranteed stream of future work.
(*) "SOC" specialises in large glossy advertising, telling customers that they need things they don't, moving goalposts, contacts through the old boys network and eye watering charges for both the initial project and any variations from it. The projects will never work as specified, resulting in mountains of extra-contract work to make it run (badly). This company bounces from victim to victim and because it avoids tech-savvy customers, the warnings about them are never seen until too late.
-
-
Monday 3rd July 2017 13:02 GMT Christian Berger
In deed
I'd say that 60-70% of all software projects get to something somehow usable. Perhaps 10% of that are usable and work, and 10% of those are good.
The problems typically lie in bad design. Software architects build castles in the sky which then are impossible to implement, and even if they get implemented, they turn out to be terribly inflexible, as any change will have to be made in layer uppon layer of software.
The solution is to make things as simple as possible. Think before you add complexity. Do you really need SQL for that particular project or would simple text files be sufficient? Do you really need XML or would a simple line-based text file be good enough?
You won't win a prize for solving a problem in a complicated manner, but you will gain respect when you have software that's easy to work with and fix.
-
-
Monday 3rd July 2017 17:16 GMT Christian Berger
Re: In deed
"bad design + poor specs + not checking with users + no agreed test procedures"
That's why you build prototypes. Hack something together which works a bit, just enough so people can try it out and give you input on how they like it. Ideally you write something you'd like to use yourself. Even if it's a bit non-intuitive, as long as it's fun to use and efficient, you can lure people into behaviour they are not used to.
-
Monday 3rd July 2017 18:44 GMT Anonymous Coward
Re: In deed
That's why you build prototypes. Hack something together which works a bit, just enough so people can try it out and give you input on how they like it.
And then, a whole lot of the time, for a whole range of reasons that you don't agree with, your Friday afternoon cobble becomes the core of the "permanent solution", baking in everything you knew was quick and dirty, along with all the short cuts and rough edges you'd never willingly use on a real production system.....
-
-
-
Monday 3rd July 2017 15:36 GMT Tim 11
Re: Definition of fail
Also it's very dependent on the definition of project. Small projects amending existing systems are much more likely to succeed than big greenfield ones so the percentage of failures depends very much on where you draw the line at what constitutes a project for inclusion in this list.
-
-
Monday 3rd July 2017 09:19 GMT Anonymous Coward
Goalpost Shifting and Timeframes
My two biggest bugbears.
I don't think project management is to blame though a lot of the time, I think investors desperate to get crap out of the door are to blame.
They generally want their money back before they've invested it.
I think the R&D credit system is flawed as well. It shouldn't be something the investors get back, it should be something the talent gets back.
Ive known a lot of "investors" that have abused the R&D credit system.
The way it should work, is that the talent puts in a bill for X and y% of that is covered by the investor with the remainder being paid out to the talent by the Gov or the remainder paid out as a tax break for the talent in lieu of working for a lower rate to get the project off the ground.
This keeps the labour cost down for the investor, prevents sheisters ripping off the system and increases interest in innovation.
This woukd also force investors into rethinking their importance. Just because your contractors arent putting up money, doesnt mean they arent investors. They often work at cut rates to get through the start up phase and are regularly discarded when the investors know the rates are about to rise.
Money can't build and market products, people build and market products.
-
Monday 3rd July 2017 09:22 GMT Steve Davies 3
Failure...
Is delivering one day late according to some people.
However, in my book failure is not delivering anything that remotely works by the agreed date/time. This seems to be the norm for government projects (not only IT...).
One Government Auditor once told me
"Those who can do, those that can't teach, those that can't teach become project managers for the government".
Seems just as acurate today as it was in the 1990's.
-
Monday 3rd July 2017 10:24 GMT PickledAardvark
Re: Failure...
I'm not a PRINCE2 fan by any measure, but success can be defined as delivering some of the objectives. The whole point of project stage reports and reviews is to check how the project is going. They're not about rewriting the thing completely. If the review team determines -- at an early stage -- that 3/4 of the objectives can be met after some late running, it might still be a success.
-
Monday 3rd July 2017 16:56 GMT Anonymous Coward
Re: Failure...
"Is delivering one day late according to some people."
"Quality late is not quality," one manager (a decent former ICL bloke) told me early in my career. To be fair, I think it was him threatened with the sack on that particular occasion.
Never forget we're all, ultimately, someone else's bitch. Put a character like Fred The Shred at the top, and the shit will spread downwards.
-
-
Monday 3rd July 2017 09:34 GMT Only me!
I am yet to work on any project that has not had all of these factors in play......
1. Significant changes to the project brief
2. Unrealistic timeframes
3. A incomplete understanding of the risks
4. Projects not resourced with the right people
5. Lack of a clearly defined goals
6. Overrun budgets
On the bright side, it keeps me in work. As I type I am just about to commence on yet another "Please help us fix it" gig.....only after points 1 to 6 do you any form of reality on a project.
-
Monday 3rd July 2017 09:35 GMT Your alien overlord - fear me
I used to be an IT project manager. Never had a failure to deliver. Why? Because you set everything up before hand (budget, people etc) and stay on top of things continually, not waiting for weekly/monthly meetings for someone to raise an issue.
However, in the same company, I've seen massive failures purely by putting the wrong IT PMs in charge of projects they have no idea about (internal politics, brown nosing for promotions etc) so before PMs start blaming others for project creep, budgets etc. they should look a themselves. Taking a course and becoming a PRINCE2 practitioner does not magically make anyone a project manager.
-
Monday 3rd July 2017 09:58 GMT Hollerithevo
PMs - mostly bad
Dear Feared Overlord, I have been involved in many projects as a worker bee and agree that the project manager makes or breaks a project. If you have a fabulous PM (and I have had, once or twice), all the other problems are held in check and he has delivered as close to on time, on budget and the functionality actually required (as opposed to what was thought was needed). Most PMs can't string A, B, and C into the right order, and even trailing Prince 2 and other certificates, they can't organise the proverbial brewery piss-up.
There are being who are 'doers' and they can achieve anything. They are the 1%. The rest are bleaters, and they are mostly in charge.
-
Monday 3rd July 2017 11:48 GMT TonyJ
Re: PMs - mostly bad
Mr Overlord you're spot on.
But in my experience it's not just the PM - I've worked with some truly excellent ones and I've worked with some who've required their job doing for them.
I believe it's actually a combination of the PM and the lead on the project. You need a lead who is not afraid to do just that - lead. To take accountability and to be vocal enough to push things through and argue a point.
Real world example: I started a new role and my very first day on site, I walked in to be dragged into a major incident call.
It turned out that we (the company I was working for) had rolled out patches to the customers' two primary SQL servers.
At 9am on a Wednesday.
And forgotten to untick the reboot on completion box.
So fast forward a week or so when I am now the architect on the change calls and I instantly make a bunch of enemies by rejecting another change for following week where they wanted to roll out some more patches. In working hours.
When I pushed for an answer as to why in working hours I was eventually told because they didn't like to pay the overtime to do it out of hours.
Funny but when I reminded them all there and then that this approach had cost them a £15k fine just a week before and that they were frankly insane to take that approach, a different one was suddenly agreed on.
The CTO of the customer wanted to be informed of every change in the shared data centre - not to veto them as we made it quite clear he hadn't the power for that - but to at least know up front if there might be any outages.
When he (literally) shouted at me for wasting his time with trivia, I quite calmly reminded him that I was doing him the courtesy of informing him of changes to OUR data centre which HE had requested we do but from that point onwards, if he rose his voice to me or my team without a damn good reason then in future he would be told post-implementation.
All too often I've seen projects if not outright fail, then at least get into difficulty because no one was prepared to be a thorn in the side.
-
Monday 3rd July 2017 12:30 GMT Sir Runcible Spoon
Re: PMs - mostly bad
@TonyJ - it seems we went to the same school on handing dingbats :)
The problem is that I don't see very many people who graduated from that particular school of thought - most people are too afraid to lose their job. As the saying goes - "it's the proud nail that gets the hammer".
I try and stick out, but not to indulge in pride - everything I say and do *has* to be backed up by evidence & logic if challenged - otherwise I probably *would* lose my job :)
-
Monday 3rd July 2017 13:14 GMT Anonymous Coward
Never do this
Fear of losing job is not the only reason to avoid getting into arguments with PM. More often than not I've been in engagements where you can see that the level of idiocy is just uniform from PM to the highest levels of management.
You start learning what are the battles you can win (i.e. actually make a positive difference for your company and/or for the client), and which ones you should just drop, because no amount of reason will overcome their reality distortion fields. Any reasonable argumentation can be easily dismantled by management and marketing Doublespeak - and if you think I'm wrong, you haven't been in enough management meetings.
So look at your PM and look at the management. If you see they're on the wrong side of crazy, just nod while you polish your CV and find your next assignment.
-
-
-
-
Monday 3rd July 2017 12:31 GMT Anonymous Coward
"I used to be an IT project manager. Never had a failure to deliver."
"and stay on top of things continually"
That sounds exhausting and pointless, how many people turned up at your summer BBQ?
Delivering on time and delivering as per the spec are not synonymous.
I have never delivered a 100% complete project on time, at least not that I was pleased with. I always deliver within budget though. Time and money are a trade off in projects, if you want it delivered faster you need to throw more money at it to get more hands on deck. The reverse applies if you give more time. The major difference being it costs less to give extra time than it does to bring in extra hands.
Delivering to a bananas timeline always means compromise. Whether you realise it or not. Im always wary of delivering on time, because it makes me wonder if my team has been cutting corners or made a dodgy compromise that might come back to bite me.
Will.I.Am delivers products in record time. They're all crap though.
Remember the timescale handed to you reflects the will of the investor not the requirement of the developers. Sometimes a middle ground is agreed upon, but its usually just as bats.
-
-
Monday 3rd July 2017 09:51 GMT Andy Non
Lack of end user input.
I found that lack of end user input was often a major contributor to late projects or projects that never got off the ground. Senior management tended to be the ones driving and specifying what they wanted for their departments but they often lacked day to day working knowledge of how their department functioned at its basic level; so you could end up developing software that did 90% of what was actually required. It was only by sitting down and spending time with the future end users that you discovered what that project killing 10% was; usually special cases or scenarios that the management hadn't considered but the people at the sharp end had to deal with day to day and had to be incorporated into the software for it to function effectively. It wasn't unusual for this 10% to need a substantial amount of coding or a complete re-think of the entire project rather than trying to shoe-horn it in.
-
Monday 3rd July 2017 12:25 GMT Anonymous Coward
Re: Lack of end user input.
I've been the caught-in-the-middle manager for various IT programmes over the years. And most of them have gone badly, in the sense that success can be counted as good enough to get on with our jobs with the result.
Consistently there have been the same issues; No one knows or bothers to ask what we actually do with the computers - they just sort of assume. Software that is madly complicated to use,and for no good reason. The things we ask the suits for are automatically treated with suspicion as if they were the IT equivalent of gold plated bath taps. Any serious estimate of cost is likewise treated as being improbably expensive while the cost of not implementing them is ignored so that the budget is never within 90% of what is actually needed. The corners that get cut are almost always the things that the new system is needed for so that the new functionality isn't much different to the old, and the failures of the old are still there. One of the worse ones, years ago, was that we were told our stand alone machines could be networked. Brilliant we thought. I was overjoyed. I'd been pointing out for years that we needed a shared drive ( of some sort) so that we could share and collaborate on documents, use shared templates and record keeping, share assessment materials etc etc.( the key word is "share")
When we went in to use the shiny new PCs for the first time there was no shared area. When I asked where it was we were told it had been taken out of the system because they didn't see why we would need it - we all worked individually on our own case load didn't we. Total cost of this several thousand pounds. Total gain in functionality, apart from newer machines, zero. (Eventually they created a shared partition on one PC and we used that for years).
-
Monday 3rd July 2017 12:27 GMT royprime
Re: Lack of end user input.
I have had the other extreme, mostly due to staff turnover we had a project that morphed over the years that is still supposedly on track to succeed. It's had plenty of staff and money thrown at it over the years, however the people that actually use it have had very little say in the design and layout, so it's disliked by most. With just the senior management giving it a big thumbs up
So, there is a new Project Dev starting next month and I'm almost looking forward to the decision soon that we will start from scratch, as had the three previous Project Devs since 2009.
-
Monday 3rd July 2017 16:26 GMT Anonymous Coward
Re: Lack of end user input.
A remarkably stupid, small scale example of this. Years ago we were told that we needed to record our case data on computer ( Hooray). Instead of asking us what we needed and how we worked someone came along looked at our job descriptions and drew up a new database. It didn't recognise that some case loads over lapped, or that some didn't fit into neat categories. But worse, it didn't start with asking what information we needed out - so that the only queries that came out were the ones the managers up at the top were interested in. Good for throughput, but lousy for case notes, that sort of thing. And staff became disillusioned with a system that took longer to use than our manual system, but with absolutely no benefit to the job. So it rapidly became unused, ( starting with data that was largely invented as staff typed in whatever was easiest).
That being said, long before computerisation I did a few months work in a mail order company. Our job was to file little slips of paper back into tiny plastic wallets that had been packed as tightly as they could go to minimise space used. That must have sounded good to whoever designed the system. The reality was that it probably had never worked. The slips were so tightly packed into the wallets, which were so tightly packed into the drawers that our fingers got cut to shreds. Until we'd done the job for a couple of weeks. And then just slapped the things in anywhere they'd fit. You could see the files were in layers of order and randomness as a new team started, and eventually, as we did, got fired and replaced.
-
-
-
-
Monday 3rd July 2017 10:40 GMT keithpeter
Re: 257%
@JimC and all
What we want is a Venn diagram or similar showing the percentages of projects that where judged to have failed for various combinations of factors.
A similar diagram showing the percentages of projects that were judged to have succeeded despite various combinations of the factors would be of interest as well. Might be interestingly similar to the first diagram.
Off out to Lidl for croissants
-
Monday 3rd July 2017 12:04 GMT Anonymous Coward
Re: 257%
@JimC - No, I wouldn't have expected that. Whilst I would agree that if there's just one unforeseen problem with a project then there might be a good chance of salvaging it but as soon as you have more than one problem things can become much more difficult.
Even with just two problems it's possible that the solution to one of the problems is incompatible with the solution to the other. And even then, you may not even be able to start addressing the second problem without having first solved the first.
Overall, it suggests to me that typically two or three major problems will be overlooked in 40% of projects during design, planning and management. I find this worrying and far worse than I would have expected.
-
Monday 3rd July 2017 12:35 GMT Sir Runcible Spoon
Project Manager (the software)
This is the cause of a lot of time & resource issues.
Almost every single PM I've seen use this tool ends up with a fairly accurate estimation of the amount of effort (in terms of man-days) to complete each area of the project. What they totally fail to factor in is *elapsed* time - especially if you have one resource responsible for a number of parallel tasks etc.
And don't get me started on dependencies - I recently tried pointing out crucial missing dependencies from the plan that was being developed but the info was constantly ignored . Why? Because it pushed the timelines out too much!! Seriously, these people should just paint their noses brown and at least be honest about their priorities.
-
-
-
-
Monday 3rd July 2017 13:21 GMT Anonymous Coward
Re: 257%
Hmm poor maths on the part of el reg.
Ok ill step in as project manager.
I think we need to set up a project task group and organise a meeting to discuss this. Ill put together a spreadsheet with all outstanding tasks and assign responsibilities and ill make sure I save it in a folder nobody can access that i'll tell nobody about. Ill also ensure I email it to the higher ups so they can ignore it but give me a reasonable alibi further down the road.
It looks like im only free 6am on Wednesday and 7pm on Friday next week them im full. Are you all free then? Let me know when you're all free and ill set up a meeting in Outlook. Don't worry if youbdon'tvreply, i'll simply add that to my list of excuses for further down the road and make sure I mention it in your appraisal even though its my responsibility to chase you.
If not, we'll have to roll this on to August. Are any of you free second Tuesday of the month? We'll have to be quick though as I only have 30 minutes before lunch.
By Christ im going to get to the bottom of these project delays.
-
-
Monday 3rd July 2017 10:14 GMT WibbleMe
When you build an extension onto your house do not wait until its almost built that you want it somewhere else and a different size. Things can be changed in a project but it makes one hell of a complex mess.
There's always an arrogant prick in management with no training that f's things up
-
Monday 3rd July 2017 10:17 GMT Doctor Syntax
For at least one PM I ran up against the key to success was to ignore him as far as possible (coming up to a developer concentrating on a complex task and insisting on talking to him is something difficult to ignore). No amount of Gantt charts, schedules to be checked or whatever will get a task done; it's finished when it's finished and not before.
The last straw was spending the day before he went on holiday over between who should be assigned a particular program. After a late meeting it had been assigned to me (good). By the time I got home he'd changed his mind again and assigned it to the inept. The stress was too much. I took the next day off sick and emailed in an announcement of my retirement. Before finally retiring I wrote the program in question myself.
-
Monday 3rd July 2017 10:47 GMT PickledAardvark
Picking the wrong platform
I'm surprised that nobody has mentioned picking the wrong software or hardware platform as a reason for failure.
I once worked on a project which was dependent on another project... Yeah, dependencies like that are horrible. The other project was to be built using a toolkit and there were three from which to choose: two that developers hated but had success reports and a third which had been recently acquired by a big vendor with no track record. Naturally, the third was chosen and project failure was only noted after 18 months. The product had to be in place within another six months for "my" project to start. Thanks to some brilliant consultants and internal staff, one of the rejected toolkits was deployed sufficiently for us to build on the other project.
The IT manager who drove the first choice came close to being asked to leave. His choice cost a lot of money and much embarrassment.
-
-
Monday 3rd July 2017 16:39 GMT Anonymous Coward
Re: Picking the wrong platform
Been there too. Every shop ive load tested .NET APIs at.
You can spank the average .NET API to death with just Apache Bench.
Pretty much every .NET Dev ive worked with thats built an API manages to rate limit the authenticated bits of the API but not the error messages.
"But why would anyone request the errors millions of times"
*facepalm* doh.
-
-
-
Monday 3rd July 2017 10:49 GMT Anonymous Coward
I find that for a project to succeed you need to include the following in the project brief,
Blue Sky Thinking.
Interchangeability
and my favourite, paradigm shift.
It also helps if the project is not about making people redundant or outsourcing because they aren't really going to cooperate when the final result is the loss of their job.
A good tip is to always keep a "Lessons Learnt" log so you know which companies to avoid.
-
Monday 3rd July 2017 12:25 GMT Alan Brown
"A good tip is to always keep a "Lessons Learnt" log so you know which companies to avoid."
It's also a good idea to name names in that log.
Having the same sonofabitch who caused project N to fail when you were using X supplier show up on supplier Y when you're about to start project P should be a BIG RED WARNING.
In such a case going back and having a quiet chat with supplier X may find a cultural shift.
On the other hand having raging sucesses with AngelicType who moves from company W to company V may mean that company W is about to start failing badly.
-
Monday 3rd July 2017 11:06 GMT Steve K
Why is there a PRINCE2?
The fact that projects fail with or without PRINCE2 or other methodologies (as evidenced by Axelos' own numbers) shows that methodologies don't/cannot address all of the human/subject matter/corporate/political factors in projects.
A thought though. Why is there a PRINCE 2...what was wrong with PRINCE1...
-
Monday 3rd July 2017 12:41 GMT Sir Runcible Spoon
Re: Why is there a PRINCE2?
I don't have PRINCE2 training, but I have had a lot of success with IT projects and working out project plans etc.
The key is to simply imagine doing the task you are documenting and writing down all the factors that go into it. Once you have that, think of all the things that you need to be able to complete all those tasks.
Rinse & Repeat until you have something that looks like a plan. *Then* start putting in how long each task will take and who will *actually* do it - factor in 20% overhead for meetings - if it goes beyond that at any time during the project then cancel *all* meetings for 1 week before resuming normal service.
Keeping it sensible and cutting out the BS makes for very efficient projects in my experience. ymmv :)
-
Tuesday 4th July 2017 07:21 GMT Anonymous Coward
Re: Why is there a PRINCE2?
@ Sir Runcible Spoon
You sir manage projects using your knowledge and implementation experience and sadly that is not a requirement for PRINCE2 certification.
If it was then the BS PM would not get a job and PRINCE2 would actually mean something.
BS PM keep their jobs because of blameless working environments where any fault is down to everyone except the management. If anyone actually wanted to stop failed projects then make the client and the project company responsible but no one wants that so fail is the norm.
-
Tuesday 4th July 2017 07:27 GMT Sir Runcible Spoon
Re: Why is there a PRINCE2?
@AC, You're right of course, but there is nothing to stop me asking someone else how *they* would do it and so come up with a viable list of tasks & dependencies - a PM should be capable of this at the very least. Unfortunately in my experience the vast majority see that as some kind of threat, so they don't ask, and then they fail. Ah well.
-
Tuesday 4th July 2017 07:31 GMT Anonymous Coward
Re: Why is there a PRINCE2?
BS PM rely upon blending with the crowd, they are not going to draw attention to the fact they they do not belong.
The sad thing is that the BS PM is seen as being equal to real PM because otherwise the management would have to accept that you hold abilites they cannot easily replace and would not be able to claim responsibility for your sucesses.
Blame is shared but responsibility is always theirs when it goes well
-
-
-
-
-
Monday 3rd July 2017 11:27 GMT Gordon Pryra
Good
If any part of IT worked as expected then none of the people reading this forum would have jobs.
I for one LOVE it when CSC or Capita get involved, this means that at some point down the line I will get some employment helping to either fix or try to extend the time between massive loss in service
Luckily Gov.Uk tend not to want to spend the time to actually fix things, just spend to cash to not let it die on their watch.
Thank god for idiots with their princes and for a general lack of decent oversight in the industry
-
Monday 3rd July 2017 11:34 GMT chivo243
Two things
1. The contractor/vendor the project is outsourced to has too many layers manglement for the blame of to reach anybody that gives a shit or is affected by a black mark.
2. The company/organization does not know what they should ask for until the project is well underway and changes cost time and money. As well as grey or loss of hair...
-
-
Tuesday 4th July 2017 09:11 GMT chrispymo
Re: How long will it take...
best post in this trail.
The others completely failed to realise this concept and were simply saying how the (inappropriate from the start) approach, was not being carried out properly. Probably they are, on the whole, apologists for doing stuff "80's style", and there's the real problem - there's a lot of people who think that way out there.
-
-
Monday 3rd July 2017 12:29 GMT Paul Johnson 1
Why I am always skeptical about surveys like this.
These are not the reasons why the projects failed, they are the reasons why project managers *said* they failed. I notice that 0% of the failures are attributed to "poor project management", and that 11% are attributed to "over-run budget", which is a symptom not a cause.
Its all very well attributing causes of failure after the fact, but nobody (AFAIK) has ever done the obvious experiment, which is to rate projects on attributes such as "clearly defined goals" and "right staff allocated to project" at the start, and then see if any of these things have predictive power. Until we do that the question "why do projects fail?" remains nothing more than folklore.
-
Monday 3rd July 2017 13:09 GMT kmac499
IT people vs Brickies
Comparing IT people and Brickies,
Brickies tend to be better at delivering because, They are doing the same damn thing repeatedly within a fairly limited set of designs and paradigm ( lay brick, put next brick on top, repeat) with a small set of standardised components. A brickie will know that a wall 10m* 3m will need so many thousand bricks and take so many days plus-minus a fairly standard percentage
IT continually reinvents the designs the paradigm and the components. The IT bods, given a sketch of a 30 form system, will have no idea how many tables or how many thousand lines of code, but will be asked for a precise budget estimate within 15 minutes of being given the 'specification'
What I've never seen is an honest analysis of any common reason why IT projects fail. Is it over ambitious goals, overblown promises by sales staff, ambiguous specifications, amateur developers, crap hardware or what?
Answers on a punched card please....
-
Tuesday 4th July 2017 09:11 GMT chrispymo
Re: IT people vs Brickies
Well there you have it - 'precise estimate'
Given a spec, within 15 minutes I can usually tell you that it will take more than a day, and less than 10 years. Given more time and information I can usually make that estimate more precise - possibly even more accurate, but only time will tell.
But, regardless of what range I give back to the project manager they will likely take the smallest (sometimes, to be fair, the mid-point) and put that on a Gantt chart - and call it a commitment,
When my best guess turns out to not be 100% accurate the project fails. Frankly it's amazing they don't all fail. Or maybe they do?
-
-
Monday 3rd July 2017 19:42 GMT Anonymous Coward
I walked out on job after a month . It was a complete cluster fuck with no one to to take responsibility. This was a a multinational company that made semiconductors. They went from NT 4.0 server to windows 2003 server. From Netscape communicator to exchange. Going from windows 95 and in some cases windows 3.11 to xp. Now this is were the fun begins. Not all of the computers could run XP so we had to schedule users to replace the PC. Of course user balked at the down time. We told them after a certain date they would not be able to log on and then they would have to schedule a time at IT's convince. Some told them that exchange would not work with soloris so unix users would have to use web mail. They turned on all of the domain servers and exchanges serves at the same time and the replication made the network ground to a halt. Oh did I mention we were an out sourced IT firm and they wait two weeks into the project to give us PC and access to their network ? Oh if think things could not got more pear shape you are wrong. We sat on asses for two weeks because delays. Forced to use that bastard shit called share point. Oh and the cherry on top was this. We were an IT specialist company brought in to do all of this change over. The company for some insane reason out sourced their IT to 2 other companies which made us the third company in the mix. Fingers were pointed every were when things went to shit.
Oh and just to let you know the mind set of the other IT companies one perm employee would bring in cookies and would not share with one IT guy. So one day out of spite he changed her password. SO when she complained about her password not working he said did you try using cookies as your password.
Oh did I mention that they only used 2 T1 lines and a back up ISDN line that was never tested ?
-
Monday 3rd July 2017 20:44 GMT Anonymous Coward
I can spot those coming a mile down the road. If the proposed project doesn't have a sponsor in the business side with enough muscle to crack the whip, if they won't provide resources and time, and if they can' t really explain what they want and why: I tell them "No".
And If they outrank me enough, they can shove it down my throat and watch things crash and burn. It rarely happens, but it's nice to have the email string spelling out why we declined the project in the first place.
-
Tuesday 4th July 2017 09:10 GMT Anonymous Coward
Why are they projects?
Many projects fail because they are projects.
Many managers lack the wit or experience to realise that not all work needs to be wrapped up as a project - other structures exist and may be a better fit for some, not all, work.
Wrapping work in the wrong governance structure condemns it to poor results.
When then only tool you have is a hammer everything looks like a nail. In a world where the managers think everything has to be a project - then the ones where that approach is a bad fit are indeed doomed to fail - from the very beginning.
-
Tuesday 4th July 2017 09:11 GMT chrispymo
Did I read this (between the lines) right?
So, if I have this right, in 2014, the gov & Capita set up a join venture called Axelos to develop training materials in project management and to operate said training. 3 years later they polled a small number of their alumni to see how successful they are in project management. Feedback is good right?
40% admitted to being a failure in the activities that Axelos supposedly trained them to do (how many didn’t admit to it?)
When attempting to pass on the blame…
45% said that they failed to manage the inevitable changes, despite that being at the core of good governance
41% failed to manage expectations on timeframes
48% didn’t manage risk successfully
49% said they didn’t ensure that the goals were set properly
32% said they didn’t manage the scope such that they blew the budget
Sound’s like 40 % of the people who responded to the survey need better training?
-
Tuesday 4th July 2017 10:08 GMT CheesyTheClown
So 60%+ are expected to succeed?
That's really not bad.
Consider that most IT projects are specced on a scale to large to achieve.
Consider that most IT projects are approved by people without the knowledge to select contractors based on criteria other than promised schedules and lowest bids.
Consider that most IT people lack enough business knowledge to prioritize business needs and that most business people lack the IT experience to specify meaningful requirements.
To be fair, 60% success is an amazing number.
Now also consider that most IT projects would do better if companies stopped running IT projects and instead made use of turn-key solutions.
How much better are the odds of success when IT solutions are delivered by firms with a specific focus on the vertical markets they are delivering to?
-
Tuesday 4th July 2017 12:11 GMT Andy Non
Nepotism and the old school tie can also be problems
Early in my IT career I'd developed several successful small in-house projects for my employer, a multi-million pound turnover company and I was lined up to develop their next specialised stock control system, a system I also had intimate knowledge of. However, the corporate IT director, based elsewhere in the country, stuck his oar in and insisted that they took charge of the project. They outsourced the project to a business software company. The result was software that was late, over-budget, riddled with bugs, couldn't handle all the different types of stock movement and in short a total disaster. The external company spent months trying to rectify the software but eventually it became clear it was going to be unworkable. It all ended up in court with lots of bad feeling around.
It subsequently came to light that the corporate IT director who insisted on taking charge of the project (only to outsource it) was best buddies (old school tie) and on golfing terms etc with the director of the company the software was outsourced too. They had appointed a trainee programmer to handle the project. When I saw the source code I was shocked at how appallingly bad it was. A complete tangle of spaghetti code with numerous coding errors and design flaws. I got the impression this was the first software this trainee had ever written beyond "Hello World" and they were completely out of their depth.
I ended up writing the new software myself and everyone was happy, maybe with the exception of the corporate director of IT who had lost face over his bungling of the project. He managed to keep his job, but he was always somewhat frosty towards me for the following ten years I worked at the company.
-
Tuesday 4th July 2017 21:03 GMT Anonymous Coward
Agile development, code first, top down by ex fast food chefs with a Prince qualification, and BA's straight out of the typing pool.
They don't even bother to disguise the job creation, the user story is about as blatant as it gets.
"The user says he wants a system to fix his problems. There! We've spent 90% of the budget and done all the hard work, the coding should now be easy."
Oh how I long for the days of yore when software was made by people who knew what they were doing.
-
Wednesday 5th July 2017 10:30 GMT Steve B
Coincidental with Prince.
I used to use proper project management techniques and all of my projects were delivered on time. Not necessarily when the management were expecting them on their plans but always as I promised from day one on mine. Then along came Prince and Agile to formulate the techniques and to make life easier for useless people to get qualifications. So basically the people who could not create a proper project management plan suddenly became qualified to prove that they could! Failure guaranteed!
Biting the hand that feeds IT
