This talk from Ryan at Unspace is highly relevant to how technology projects ought to proceed. The most telling comment he makes is that most software sucks, even though its on time and budget. Its 38 mins, but the talk is only abut 17 mins. He talks about Rails but the real substance is the process.
http://video.google.com/videoplay?docid=6479473876822587034
He speaks of agile development, and raises some methods that will make Bank technology groups curl up and die.
- no requirements documents
- no contracts
- no detailed estimates
His reasons are valid, when he reflects on old ways
- no-one is happy – not the business use or the technology group
- too many people and layers involved – why cant the developer and business user speak to each other
Hear Hear!
Technorati tags: agile+development, unspace
Bankwatch 
I watched his presentation and in a perfect world would love to see this. And it is totally possible to have developers and business user speak to each other but problem is both sides need to come closer to the middle.
Developers need to be able to speak more on a business strategy/ROI to the biz people and the biz people need to embrace the technology more and not just tact it up as ‘techie’ talk.
Totally agree Brad. It needs shifts on both sides to make this work, but its essential in our technology driven business world to get at this problem.
Another great post, Colin and with a predictable response.
Looking at the previous comment, the question it suggests to me is “OK, who’s going to fix the problem?”
Saying there’s a chasm between the business and the techie staff is a blinding flash of the obvious. It doesn’t address the issue, it merely identifies the two protagonist groups.
The problem is usually caused by the intransigence of the techie teams and their constant insistence on saying why things can’t be done the way the business wants, as opposed to finding a way to make it so.
The business, facing a host of (often fraudulent) reasons why it can’t be done, expressed in a way they can’t understand, simply disengages from the technical team and the project is compromised and ultimately fails.
Imagine a project as a journey. A manager asks his chauffeur to take him to an important client meeting. The driver say he can’t do it because his tyres are bald, he doesn’t have enough fuel for the trip and his injectors have corroded and are spitting back.
Confusing stuff for the manager, who just wants to go to the meeting. So, does he cancel?
No, he does not. He finds a driver who will take him. Then fires the chauffeur for not maintaining a viable transport system. Simple problem, simple solution. So, what’s different in real life, with the techies?
Well, they rack out the excuses. Often because they’re too comfortable with the status quo, haven’t bothered to keep up with training and trends or just know they can get away with doing nothing new.
Even if the boss tried to bring in a new team, then that opens the door to the next villains of the piece, the internal risk and security team.
These guys are a mix of lazy ex-techies with outdated knowledge, but with the power to stop things changing because they can. The classic case of the tail wagging the dog.
The cure is to engage the technical team initially and outline a clear requirement. Give them the chance to accept the challenge. If not, give it to an external strategy team to analyse what needs to be done. This team should not be the ones to implement as that is a clear conflict of interest.
Ensure the risk and security team understands that it WILL go ahead and their role is to accommodate it safely by engaging with the strategists in an open and frank dialogue.
But way above all, remember, a project is all about change. The requirement should not ever be set in stone. If a project takes six mo9nths, the team must recognise that things may change during that time and accommodate that change accordingly, not say “that’s not how you described it, so you can’t have it”
Sounds like the development techies and risk team would really have to work for a living, eh?
You know what, that’s what they’re paid for!