Strategy(ies)

Some cool things to try:1) Ask employees for initiatives that have worked, that have not worked, what they've tried that they think will work well across the organization. That way, management would get ideas people have tried in their own units that have worked well and that should probably be evangelized across the organization.

2) Prototyping and front-end development responsibilities should be kept in the high cost center arenas. Integration with the back-end should be done in the high cost center. [See my previous posts for this subject beaten to death].

3) There seems to be a running theme in many of these applications we create at the investment bank. Take someone's spreadsheet and turn it into an application. Front-office users are adept at Excel apparently. Here's the progression:

1. They create the spreadsheet, start really using it, and get dependent on it.
   
2. They start mailing the spreadsheets all around.
   
3. They wind up with multiple copies all over the place and they get out of sync.
4. Then they ask IT for help...
   
5. IT comes to the rescue with a solution with 3 tiers and 6-12 months development time.

We should start looking at other solutions. If we keep following this procedure, IT is reduced to not adding any real value; we're placed in the position of playing constant catch-up. And IT is not really innovating or doing anything kewl.

Instead why don't we:
1) Train business users to use IT more wisely. There are a myriad of technologies out there. When I stop by a business user's desk, the same things strike me each time: how few applications they have installed on their box and how non-facile they are at using applications. As part of their on-boarding, they should be indoctrinated into the tech tools that are available to them; for instance, an introduction to using Sharepoint technologies; If they use an online-spreadsheet in the first place, IT might never have to build them an application at all. And even if they needed something extraordinary, we could build them a Sharepoint component to help them, for example vs. building them a whole new app. Hell, even use something like Google docs!

2) IT should get away from the mindset of creating applications from scratch. In this world of plug-n-play, we should be leveraging other solutions. That means hiring people who like to play with new technologies, with vendor products, experiment, attach the output of one product as the input to another product and integrate them, etc. We should be coding only when we HAVE to. Even the idea of taking code from one application and using it in another is often far-fetched. In reality, ripping this stuff out and using it elsewhere doesn't work so well in practice. And you usually need the guy who developed it in the first place to stick around. If he's not, good luck!

Get IT to play with experimental technologies and to prototype with them [I'm thinking of using frameworks to prototype quickly: Rails, django, adobe flex, etc].