Working closely with IT....

makes you hate them more...

I'm developing an App at work, they do "sprints", even when the task is not complete all they are interested in getting it signed off. They have no concept we've got a customer at the end of this we don't want to roll out a glitch ridden mess to... and then I have the "you now need to do x"... which could have been done two months ago if I'd have known the task existed....

I did a project programme and they checked it, they were told to add in activities and identify those that could be done early or which would go onto the critical path and when...I constantly stressed this and asked the direct question at our meetings.... gggrrrrr

The app is very good, but they are horrible, horrible communicators and contributors.

This is just a rant.... oh, and it is them, not me, before the contrarians start.

Soz they're sh1te.

But if your antepenultimate para is accurate then presumably you can (and should) be getting them hauled over the coals for it from on high and to ensure it never happens again? If not then same sh1te will continue next time and on and on and they'll think they're untouchable - make them accountable for their failures.

TBH lawyers and IT tend not to work well as IT are very process driven and lawyers have a get it done now mentality borne out of their ability to timeshift the majority of their work.

The agile working comes from people historically getting something IT think they wanted and then moaning that it wasn't what they wanted with unpicking it basically meaning doing it all again.

The app is good... it's not a failure. The programme didn't have enough glitch time in it.

We do post project reviews and as I keep a tracker this will go into that. I won't however "haul them over the coals"... that's a sh1t way to manage most issues.

I suspect it's a workload/understanding issue.

The good bit is overshadowed by the bad bit... and that's a shame. It also means the same is happening to me with the client.

If you've been referring to developers as IT to their face that might be why the working relationship is not a positive one.

Your call, obv.

But if this is right: "I did a project programme and they checked it, they were told to add in activities and identify those that could be done early or which would go onto the critical path and when...I constantly stressed this and asked the direct question at our meetings.... gggrrrrr"

and you don't address their failure to work with and to that then you can hardly complain if, as and when it happens again.

I once had to do manual VAT returns for a year because IT refused to add an additional code to their worklist

our IT adopt agile working principles.... that's exactly what their articles say.... they are very proud of it.

We scoped this out very clearly and the scope hasn't changed. This is sprint 1, we'll have sprint 2 where there will be upgrades but basically sprint 1 is replacing a paper/email/spreadsheet chain with an App. The scope was driven by the previous process so easy to do ... We haven't had any scope creep and they knew what was required and why (they don't show any interest in the why)...

when I say do the returns I mean like process from purchase order stage

and the returns were in another country

tldr yes they are bastards

BC... I didn't say I wouldn't address it, obviously I will. I said I wouldn't address it by hauling them over the coals.

Pancakes, our development team, designers and architects sit in IT.

IT and Design & Change (the latter of whom are adept at designing and changing things without consulting anyone, then asking compliance and legal to rubber-stamp their efforts) made my time on secondment at a bank a misery. Like children playing with new toys just for the sake of it.

"We are working at pace in an agile manner."

No. You mean that you're making it up as you go along and trying to run before you can fooking well walk, with no input from the business teams responsible for the products involved and no understanding of the context of, and risks inherent in offering, those products. You fooking dicks.

LOlL. We just do it to fook with you guys.

I have been on both sides of the consultancy/consumer side with software projects and yeah, agile exists to cost software projects - not as a way to manage development but it’s become more the latter. It was introduced to stop the (common) problem of when a client/internal ‘stakeholder’ (Bleurgh) received a project and then started going ‘oh yeah, well this button does some calculations and saves some figures to a database but it it doesn’t, like, give me a blowjob or anything’ ‘er, well you didn’t mention the blowjob requirement when we specced the project’ ‘I know but I just, like, really like blowjobs - you know’ ‘right well yes it’s good that you like blowjobs but that’s extra work so you have to pay for it’ ‘oh come on I just really like blowjobs, please?’

Me [to IT guy]: Right. I want this programme to be able to do X. It needs to produce a loan document which sucks in the data inputted by the customer in the online application form and use those to populate coded fields. It just needs to work, ok?

IT guy: C++ and Javascript. Basic, database migration and data cleanse. Internal budgets and KPIs. Back-office legacy systems."

Me: FFS, can you do it or not?

Feel your pain on all of this. IT can be painful.

Mugen - have you got a nonny email address you could let me have? Just curious about those spreadsheets with the blowjob button. A friend is asking.

I also feel your pain.

Me: Describe to me how we can make this happen? In words that I understand...

Them: well, coding, obfuscation via one way hash, not capable of decryption, well is shouldn't be but you can if you have the key, but then we can use encryption which also needs a key but can be decrypted by us or a third party by running a set of executable bollox, or we can do something else but requires us to do some work and write some code to automate it which could take years. At the end of the day its your decision...

Me: *head explodes*

Have you worked with investment bankers?

There is often a huge divide between users and IT. Both sides are responsible.

The most impressive project I’ve seen was an in-country implementation of a core banking package at Citibank. IT said that they were going to manage the project. The COO said ‘No f*cking way. This is important’. From day one Operations took total control of the project, from training users to define requirements, through negotiating with the package provider, and defining their own test packages for IT’s in-house developed modules. It was awesome: slicker than chocolate

The COO had been around the block a few times, and had seen various IT systems and projects from the sidelines, but had never led an ‘IT’ project, let alone one with multiple systems and real-time interfaces.

But she knew every step of her bank’s operations inside-out. And exactly what she wanted from the technology, not what IT told her she should want.