Gov must hire 'thousands' of techies to rescue failing projects The government needs to bring in "thousands" of digital tech folk to lower the high number of failing IT transformation projects, the chief executive of the civil service has said. Addressing the Public Accounts Committee about findings that one-third of big government projects will fail in this Parliament, John Mazoni said …
Good luck. In my department we've struggled to hire anyone over the last four years. The two or three people have come in and then left after two years. Got permission to hire graduates instead of using the usual spec we have to adhere to. In saying that most of the department has been here for over ten years and if more than one or two left the rest of us wouldn’t be able to pick up the extra work. There’s the specialised knowledge required to do their job which we’re all familiar with but haven’t just got on the tip of our tongues and the relationships with the small band of users they would be supporting. I wonder how government IT in general got into the state it’s in…
Ah yes, the stupid Civil Service job hiring requirements. First you had to advertise to those "At risk" (those recently made redundant or those who were so useless they actually somehow managed to get the sack - it does happen, though very rare), next you could only advertise internally (so those we'd dub enthusiastic amateurs and who fancy their chances can trash systems - we had a forced redeployment into a team I worked in - he was useless, managed to delete the website a couple of times and just made everyone else's job harder), then to the wider civil service (more feckless idiots) and finally, when all that was said and done, you could go out externally, But only to guardian jobs (so, more recently jobless civil servents). After that, maybe monster.com (finally, maybe get someone in who we actually need and can do the job).
It is incestuous and fucking stupid as you end up with the dregs. When I worked in gov and went through this tedious process, we were under massive pressure to rehire internally before going externally. "Couldn't they be retrained/are you sure they're not suitable/we'll have to delay going externally a little longer to make sure no one else missed the chance" on and fucking on. Madness
I've worked in four countries in IT, as developer, architect, administrator, applications support, in banks, engineering, computing companies (like the late Digital, HP, IBM and others), software companies, government research (the serious stuff you all use while rubbishing the producers).for oer thirty years.
What have I learnt?
1. Avoid working in informatics as long as you can.
2. Avoid people with IT degrees in every case, not those with training, but certainly those who studied just IT at university. We need breadth, openness and new ideas.
The best people I ever worked with were a quantum chemist, a biologist, an archaeologist, a couple of classics (Oxford) graduates, some arty type and some telecomms engineers who had converted. Mathematicians are not bad. A couple of very good people, as in top of the country-type good, actually had no formal qualifications other than certified eccentricity.
As for the jaundiced view of civil service recruitment claimed in another comment, of course one should scan internal, available talent first. It does not mean one has to accept them, just that one must give them a fair shot. And as for Guardian only advertising, I suggest you widen the scope of newspapers you read and, anyway, for the reasonably literate and interested, the Guardian stands pretty well against Telegraph, what passes for the Times and others. No, your prejudice, ignorance and bitterness are showing. If you are so wonderful, tell us how you fixed the situation and what fantastic post you are blocking now.
I think you've missed the point of the Guardian only bit of my little rant. I have no objection to those who read the Guardian or have any gripes about advertising in it then or now. It was the fact that we had to advertise there exclusively for two to three months before going to any other paper, agency or other job outlet. Guardian Jobs is, or at least was when I worked for Gov, the place you went to for Civil Service jobs - it pretty much was an extension of the "Advertise to wider Civil Service only" part of the recruitment exercise but included the recently left for whatever reason. And quite often the job specs were tweaked by HR to add in comments such as "Civil Service experience required". Recruiting new talent was a teeth grinding exercise that followed the same pattern every time and it felt like they were trying to force you to recruit from the Civil Service. Only after 9 or so months were we finally allowed to recruit a non Civil Service bod.
As for me? I managed to escape after a number of years and am doing fine working as a random SysAdmin for a non-UK company.
Sorry, but you're a tad clueless.
As someone who is paid to go in and fix the problems and turn projects around... I can tell you that you want people who have a very strong technical background. IT degree? Is that an MIS degree? BS/BA CIS degree? Or an engineering degree?
I've been in this industry for 30 years. Yes you can find PhDs in Physics who can do the job. You can find Systems/Control engineers who can do the job. But those who are classically trained software engineers and have worked in the embedded and OS level... they are the ones that you want to solve the problem.
You also want small teams of people. The more people, the harder it is to control the work and keep things moving.
You also want people who understand that IT isn't a democracy where everyone has an equal vote. Sure you may want the input from the team, but the team leaders / architects have the final vote. When you try to make things democratic, you increase the risk and you will end in failure.
"You also want small teams of people. The more people, the harder it is to control the work and keep things moving."
Exactly.
And if you try to save a failing project by throwing more bodies at it, you slow things down as you add people who don't know what is going on in to the mix.
Sometimes the right response is actually to make the team smaller - cull the half-wits and non-producers.
Yes, I concur on the software engineer front.
As far as project failures go, they simply pick the wrong people to do the job. The large consultancies make their money by supplying mediocre but cheap talent at enormous prices.
To actually make a project work you need small hungry firms who are far more likely to have technical talent.
Of course Government IT projects are also notorious for having endlessly changing requirements...
"2. Avoid people with IT degrees in every case, not those with training, but certainly those who studied just IT at university. We need breadth, openness and new ideas."
I recall about 10-15 years ago, that was very definitely the rule. IT degrees prior to the turn of the century had a reputation for being a bad joke that focused on teaching people dead programming languages, largely irrelevant information about processor architectures and obsolete electronic history (oh, you can tell me exactly when the first vacuum tube was developed? Great! Can you reset someone's AD password...?). You were generally better off with a maths grad who had picked up some programming experience on the side, because he'd have genuine problem solving skills; most IT grads were overconfident and utterly clueless about actual business software. They'd have been great if I needed to write an OS from scratch in assembler. They were less useful when I needed to build a network using proprietary software. The programmers we used mostly worked with SAP, which universities regarded as beneath them.
Nowadays, the degree courses are a lot more relevant and the languages used tend to be closer to the kind of thing you'll see in the workplace. You can pick up C or Java at uni and immediately start doing something useful in a business, rather than showing up with a comprehensive knowledge of LISP and discovering that no-one in business has used it since 1988; or you'll learn half the contents of a CCNA and know how actual real-life networks operate, rather than crap about IBM Token Rings.
(as a note, archaeologists actually make great IT support guys. The cognitive skillset required is almost exactly the same. Archaeologists show up at a site covered in broken technology and have to figure out what happened. This is exactly what you want in a DTS engineer, who has absolutely no need to understand the theoretical basis of Boolean algebra but does need methodical deductive problem solving skills).
I got my Computer Systems Engineering BSc almost 30 years ago and my CS PhD 24 years ago (uk uni) and I still program in C and Bourne Shell (still love sed/grep regexes) that I learnt as an undergrad and can still apply them in my job ... Sure I don't still use Pascal, APL, Fortran, COBOL, Lisp, BASIC (except for 8-bit retro work), lex/yacc, LaTeX/TeX, Z80, 6809, 6502 or even 68k much but I remember the syntax, semantic parsing and data-modelling principles and can apply them to xml/soap, REST/json. I don't model circuits with SPICE or use VLSI design tools or dabble in Lambda Calculus anymore but the background is useful for fritz and eagle work on my IoT remote sensing projects.
I stayed on at uni to work in the computing service and back in the 80s/90s the 'customers' were a tricky bunch demanding always-on access (24-hour access to 'terminal rooms' on campus) and money was tight so just very few staff were employed and we therefore had to do DevOps all the time without breaking anything (as academics are very vocal types). Going from working in a uni where 'agile development' (before it had a name) using Unix/netware/NT, email, web serving, proxies and dns were the norm to an 'enterprise' where IP addresses, 64k lines and slow change management processes reigned was something of a culture shock!
I have not seen much in the last 37 years of my computing experience that is genuinely new with most things being incremental improvements. But personally I am happy that Alan Kay's DynaBook from 1972 is now finally embodied in a smartphone/tablet on a 4g 'world wide web'.
"The best people I ever worked with were a quantum chemist, a biologist, an archaeologist, a couple of classics (Oxford) graduates, some arty type and some telecomms engineers who had converted."
I once worked in an IT team which consisted of a botanist, a geologist, a zoologist and a CS graduate. The CS graduate actually wanted to be an astronomer.
I wanted to be an astronomer before I got hooked on programming at school and went on to do a CS degree.
This was so long ago that any old degree would get you a programming job, but CS still gave me an invaluable grip on the essentials.
Except how to debug other people's code...
> "Why on Earth would you let a developer have access to a production system?"
If your team has fewer than five members, everyone has access to the production system. It also means your system isn't that valuable in the first place.
"f your team has fewer than five members, everyone has access to the production system. It also means your system isn't that valuable in the first place."
The first part may well be true. The second, not necessarily.
There's one point to bear in mind - if you're going to have to support it in production you end up writing something you can support.
If you're supporting something in production you might find yourself working more closely with users and gain a better understanding of their jobs which feeds back into the ability to match what you develop with those needs.
A lot of this has been lost with separation of functions. Now it's suddenly so fashionable to get back to doing this sort of thing that it's acquired a name: DevOps.
As a developer... and a consultant... I avoid production systems like the plague.
Too much liability because if something goes wrong. You get the blame. And if you accidentally did something... you have the risk of being sued.
Production systems? Just say no.
This post has been deleted by its author
This post has been deleted by its author
"Good luck. In my department we've struggled to hire anyone over the last four years. The two or three people have come in and then left after two years"
1: Departments refuse to hire people who can actually do the jobs well
2: Departments refuse to pay them at appropriate levels, because they would mean they're earning more than management.
2: Departments refuse to pay them [IT professionals] at appropriate levels, because that would mean they're earning more than management.
Every manager should have subordinates who make more money. It teaches them humility and their proper role in life: they are support systems for the people who do the real work, the difficult work. If you need to hire a manager, the people waiting at the nearest bus stop form a perfectly satisfactory pool of candidates for the job.
Also, internal promotions to management are generally the result of ass kissing.
In my department we've struggled to hire anyone over the last four years
I'll bet you use recruitment agencies. They're the source of most employment problems.
These agencies attempt to reduce the difficult problem of matching people to jobs into a simple word-search; as a result, you get agents with no understanding whatosever of the positions they're trying to fill, and you get CVs massively over-blown to try to get some of the buzzwords du jour. Neither is good for an accurate assessment...
IME, the most effective way to find staff is to offer your current staff a reasonable bounty for finding anyone that stays for more than a year.
Vic.
Remember, the Mythical Man Month (always worth a revisit) is talking about the effect of adding additional warm bodies to an existing project - with all of the communications problems and consequences. Maybe they are
(a) thinking of starting again - with properly resourced projects that do not rely on uncertain consultant based staffing (although I suspect not)
(b) putting some staff in to do the work that has not even started (probably not even specced) because of a lack of competent wetware.
But then again, as they probably won't be doing (a), and (b) will probably trend toward the MMM - maybe even worse if the specs have not been properly defined and the consequences thought through, you are almost certainly correct. I say almost, because despite astonishingly low probabilities, people do win lotteries.
1) Try hiring a rather smaller number of experienced techies who actually understand what they're doing.
2) pay them a decent salary, make them government employees, and offer them a long-term career path, so that their allegiance is to their team and department, and not to the shareholders of a dodgy outsourcing firm. Then recruit your managers from your pool of experienced staff who understand the actual needs of the business.
This post has been deleted by its author
Agreed. I used to work with a small group of very experienced contractors who basically went from company to company to get projects working that one (or more) of the big consultancies had screwed up. In the end there isn't a substitute for experience, the problem is that it costs more.
In the end there isn't a substitute for experience, the problem is that it costs more.
Not over the life of a project, it doesn't.
Paying one man £8000 a month for three months is a cost of £24K.
Paying three men £1500 a month for five years is a cost of £90K.
The former is more likely to get you the product you wanted...
Vic.
Try hiring a rather smaller number of experienced techies who actually understand what they're doing.
How will they keep at bay the demands of technically and managerially illiterate management who keep on changing things, or trying to release dysfunctional specs to bidders?
In the area of shared services, the IT usually only becomes a problem because the business processes (and the policies that back them) are inadequate, undocumented, inconsistent and not understood by the management, who think that if only they automate more stuff, all their troubles will go away.
Take payroll or expenses. In concept, very, very straightforward to autiomate and share as a service. But if you're doing shared services, that means every customer of the shared service centre has to adopt the same policy and process on these (otherwise you're running duplicate systems, and they aren't shared at all). The policies and processes need to be understood by customer-staff and the "doers", and they need to be clearly written down - who does what by when, who is accountable and responsible. And really, the existing processes need to have proper MI so that the current performance is understood, and they need to generally work because automation won't fix a broken process (I think that's the nub of government's, and to an extent wider business's problems).
So yes, more and better techies by all means. But just as important to enable the techies to deliver are more and better process designers, MI specialists, and management who actually have experience of creating and running a successful shared service centre.
I'm not holding my breath.
Pen-y-gors,
Back when I worked in a tech area of the civil service, they got 1 spot on.
2, however...well, I was told for nine months straight that I'd be up for integration/permy (I had repeatedly stated I liked working there, seemed to be helping and really needed some job security as I was having problems with anxiety - not a good mix with contracting). After nine months of will they won't they, I had a nervous breakdown which wasn't entirely caused by the stress of not knowing if I'd have a job at the end of the contract period, but damn it didn't help.
I wasn't the only one who was treated this way - there were plenty of contractors who were quite comfortable with the idea of a pay drop but some security and the concept of making a difference in central government IT. They, however, just left and went onto bigger and better things out of frustration at the carrot being dangled, then constantly snatched away (and seeing their contract positions being filled by CSs with less experience than them - some were kept on permy, but it was a rare thing).
The Civil Service are very, very bad at dealing with people who aren't already in the Civil Service - the whole 'not invented here' thing.
Anon, as overall I quite liked that job and it still opens the odd door for me to jam my foot in.
@A/C
Whether you'd be better off in the CS or not probably depends on a variety of things.
After 14 years I think I avoided a nervous breakdown by getting out. Apart from anything else I spent about half that at the top of my pay scale in a department that quite cynically didn't hand out promotions above that level (cynically? I was offered a promotion, no board or any other formalities as soon as I handed in my resignation). After a few other permie jobs I spent the last 10 years of my working life freelance and found I'd finally got to be where I wanted.
But if it works for you, best of luck.
Dr Syntax,
Yeah, you're probably right.
I get the feeling that even if I had been kept on, I'd eventually have shuffled sideways (where I was working doesn't strictly exist any more) and been bored silly, as there aren't that many interesting jobs in CS IT that aren't managed by outsourced entities.
Since that breakdown I spent nine months recovering (and was nearly sectioned - fun times), then went back to working with normal people in a semi-retail environment, and it was quite refreshing - so refreshing it lasted the better part of five years before I started looking around again.
My most recent employment experience ended with me being given the boot on legally dubious, and morally repugnant grounds. I do rather seem to go from shit job, to good job, to shit job and so on.
By that measure though, I'm due a good one, eh?
I've worked in a UK Government IT department. My experiences with working there and working on these kind of projects, and I've seen some belters, is this:
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
