I have seen several different forms of transformation programs and software development programs.  Some have been small, one person (me) writing software and talking to customers.  There was a time when I wrote software in the morning and met with customers in the afternoon.  In the afternoon I would show the advances from the previous day and share some of my ideas of what I could do by the next meeting.  In the end I knew that the customer saw the benefits from the software because their face lit up when they saw it working.

I’ve also seen programs where there are hundreds of people all trying to achieve that same end result.  The majority of the people assigned to the program are trying to create some order in the chaos and provide some structure.  At the core there are people wanting to develop, people trying to figure out what to build, people interpreting what they think the business needs and ultimately a business customer that is hoping that all of this activity is going to yield some results.

These are two extreme examples of a spectrum of approaches to working towards transformation — but they key is to maintain as much of the purity of connection and communication that exists in the first model while harnessing some of the parallel capacity of the second.

I’ve written previously about the galvanizing power of a “big vision” for transformation, but I haven’t written much about what should happen next.  In my opinion financial services transformation programs need to be smaller, faster, lighter, more nimble and more connected to the core business problems.

I try to not be overly annoying in this blog or have a soap box to stand on, instead what I try to do is highlight the problem and articulate a few ideas on steps that can be taken to address the challenges.  So in the spirit of this, here is how financial services transformation programs can become leaner and more business aligned:

• Create small teams with great people who have a broad and deep perspective from the business and technology domain
• Push these small teams to eliminate boundaries between technical and business concepts, all team members should be completely versed in the entire topic
• Empower these teams to find real world business problems where transformation is required
• Have the teams work off site and be able to completely focus on the team work
• Have the small teams iteratively formulate a problem statement and a transformation goal that includes both a business and a technology angle
• Ensure that the goals are specific and articulate both a target end state and the sequence of steps to achieve this;  each of the steps needs to be a package that can be implemented
• Let the teams report to a group of stakeholders to validate the progress and capture new thoughts along the way
• Implement the packages, repeat, profit

I realize that many of these are agile principles and methods, but I have seen too many of these types of discussions become entirely about methodology rather than focusing on how to get results.

Big programs are always a struggle to deliver.  Some of this is just a function of scale and some of it is the dilution of creative inspiration and obscuring the connection to the business stakeholders and challenges.  To many people in large programs are guessing about what they think the problems are instead of checking in with the reality from the field.

Maintaining that solid connection between the business stakeholders and what is being created is essential in transformation.  Small, fast, and light teams that are well versed on the technology and the bank can do this.  Once the big transformation vision is understood and aligned, each work package created by these teams can be held up to the vision and once alignment is confirmed the package can be implemented and real world progress is achieved.