With maths and syntax like that
Nearly 40? I'm nearly 40. 40 what? Projects, percent, people??
Is it any wonder they're failing?!
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 …
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.
"...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".
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.
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.
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.
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...
>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...
> 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.
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.
"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.
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.
"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.
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.....
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.
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.
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.
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.
"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.
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.
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.
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.
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.
@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 :)
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.
"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.
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.
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).
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.
Biting the hand that feeds IT © 1998–2019