We have a large and incredibly significant Flex project taking place at CFI right now: we're rewriting the front end of one of our core applications, which handles sales for the front end of our business in the call center environment. If you'd told me five years ago that this is what we'd be doing in Q3 of 2007, I would have called you crazy.

I can safely say that this project is the culmination of the beginning of everything I have been trying to do with our IT department since I joined it as a lowly junior developer in application support. This application, upon successful delivery, will be the fledgling model around which the next several years of software development at CFI will be based.

In total, getting us to this point took the following:

1) Three years for me to fly in the face of all of our departmental practices, building our web development team to the point where the processes and technologies we were using showed some significant benefits over our traditional methods,

2) another year to convince our Director and CIO that we needed to change direction for the rest of the department,

3) two years of repeating myself to the business and negotiating ad nauseum to focus our efforts on re-engineering our core systems to bring them in line with their needs,

4) the last nine months or so getting all of our software development teams moving toward the new direction (some faster than others), and

5) the tireless work of countless people who have engaged in, supported, and led the transition.

Total Underestimation
Paul, who was our Director when we decided to make the switch, had always been wary of such a large transition in process and technology. He certainly wasn't scared of it, but I think he had a much better sense of just how much work it was going to be and how long it would take (maybe that's why he left right when it started? :) ). Having sat firmly in the driver's seat for all of 2007, I must say that I had absolutely no idea what I was getting myself in to.

Not that I regret it. I do regret the fact that I don't get to mess around with all the cool technologies we're now using as much as the developers do (lucky bastards).

However, I'm somewhat obligated to make the change happen, since I ended up in a unique positon to do so. That's not a statement born of conceit, but the state of affairs due to my 11 year tenure with the organization and my career path through it. The unique blend of positions and experiences I've had at CFI have given me a solid understanding of our business challenges, and my delivery record and the specific mix of relationships that I maintain from prior positions allow me to say and do things that are (usually) diametrically opposed to our prior IT model. People have always joked that I could get away with anything at CFI, and while I think that's a gross exaggeration, I've certainly been able to facilitate some radical changes in direction that nobody else wanted (or were obtuse enough :) ) to champion.

Changing Culture
Prior to this experience, I had no expertise of any sort with changing an organizational culture. My first management role put me in the enviable position of being handed a small department (three people, myself included) and being given cart blanche to build it up from scratch. The fact that we had nothing mission-critical to support at the time made my job all the easier.

Honestly, our first project failed miserably, after which we spent about six months to a year just figuring out what we wanted to do differently to prevent that from happening again. We changed our SDLC, implemented Fusebox and the FLiP process, bought some development tools, and had great success with our next project immediately - a trend which continued for quite some time. We certainly did a lot of things wrong and incrementally improved things over the years, but by the time I left the department we had a pretty good thing going (at least philosophically - I can't defend most of the code we wrote :) ).

After leaving the web team, I had the opportunity to run another development team (one of our Oracle teams), and that gave me a clear perspective on a few things.

1) First, it was obvious that everything I had been told about the business units for our internal apps being harder to manage than the ones I dealt with for web projects was utter nonsense. For some reason, the other department managers seemed to think that the way we did things on the web team would never work with their teams, which was bunk. The same analysis techniques and communication strategies worked just as well with my newly inherited business units as they had with everybody else. As with anything work related, setting the attitude of the team appropriately defined its ability to succeed or fail at its goals.

2) Most of the things I had suspected were challenging with our legacy internal application architecture (technology selection, coupling issues, scalability challenges, etc.) were legitimate concerns. This explained a lot about the pain some of our teams were feeling.

By enabling the resources on my new team and making some changes to our interactions with the business, I was able to facilitate a lot of improvements, which I felt would prove the purpose behind some of the changes we were trying to make department-wide. However, I still found myself dealing with a lot of resistance in mindset and attitude to making the switch to newer technologies and more modern software development processes. The state of affairs and what needed to be done to improve them had become abundantly clear in my mind due to my successes and failures in varying development paradigms; but my audience, having only ever done things one particular way, often lacked this perspective.

As a result, I found myself constantly repeating myself for two years straight. Literally, almost every day, I was having the same conversations with different people about our new direction, answering the same questions, countering the same arguments, so on and so forth, until finally the light would turn on and they would buy in to it. It's been an utterly draining experience that I've felt like giving up on at least once every three months since I started doing it. Thankfully, I'm amazingly stubborn and a glutton for punishment, so I kept at it no matter how painful it became.

Getting Support
If I were to advise somebody on making a similar IT organizational culture change in the future, I would recommend a few things.

Item #1: Fresh Perspective
First, you have to hire people that are of a similar mindset to you. There is a great set of audio books by Jack Welch (called "Winning"), and he has some thoughts on organizational change that are 100% accurate - one of which is identifying who from the "old way" is going to make it, and who isn't. There's simply nothing you can do to change a person's sense of nostalgia for the old ways, and if they can't get on board and change to meet the new ways, they unfortunately become less useful to the organization. Often times, these people have to be let go - something we certainly didn't want to be forced to do with anybody.

Personally, I was completely unsuccessful at showing some of our old resources the benefits of the new practices. However, the great thing about hiring new people from outside the company is that they breathe fresh ideas and attitudes in to the organization. I stepped on a lot of feet during my progression at CFI (often due to a lack of professional maturity), and many times, I believe past grudges got in the way of people hearing (and believing) what I had to say. By putting a few new people in the organization and highlighting their results, I was able to win over some of the doubters.

The first example I'll use was a new project manager I hired shortly after taking over the Oracle team. Before this hire, the business analysts on this team really weren't on board with where I was trying to take them. So, I brought somebody in who had experience with RUP and a contagiously positive attitude. I put him in the same box as the other guys, gave him a project that the team had failed to deliver on for two years, and let things happen. Within four months, the project (the first RUP project for the team) went to production. The combination of this success plus the interactions with the new hire had changed the perspectives of the other business analysts. We were also able to see improvements in the attitude of the business. They were so happy with the quick results, they asked for this new hire to lead all of their future projects.

The second example I'll use was a hire made on another team, in this case a development resource. Typically, when we hired a new development resource in to the old way of doing things, they would take four to six months to become useful since we had no persistent system documentation for them to refer to (we referred to this lull in productivity as "learning the system"). A lot of people fought me on the principle of creating persistent documentation, a key tenant of our new SDLC. When the new development resource was hired, he was productive on a high profile project in about three day's time, having reviewed the system documentation we'd created as part of the project and immediately getting his bearings. This gave me yet another case to point to of the new ways working where the old ways had failed.

A key to hiring effectively is standardizing your hiring practices. We implemented some rules in hiring that allowed us to have some more consistent metrics for bringing people in. It's not perfect, but it's better than the free-for-all we had beforehand.

Item #2: Dedicated Change Management
The second item that is critical to the success of an organizational change is a set of dedicated resources to facilitate and formalize all the changes. This was supposed to be me and my architecture team when I originally left the web team, but since I had to immediately run a troubled development team, and my architectural resources were 100% committed to a high profile project, we didn't get much done. This year, I inherited several newly formed departments as a result of a position change, and had to direct development for our PCI compliance intiatives, so I was no more effective in promoting organizational change in my new role than I had been in my previous one.

So, while we've made a lot of progress on our transition this year, it's only been because of other people taking ownership and making things happen. I've directed and guided a lot of what we've come up with, but the real work was done by developers and project management resources getting their hands dirty. The largest benefit of this state of affairs is that the quality of the solutions has been very high, because they were born of real world challenges, and battle-tested by the internal developer and project manager communities. I always say that design by community is far better than design by committee.

Item #3: Support from the Boss
The third item that you absolutely have to have is support from your superior(s). My boss gave me cart blanche to make changes (this time with the entire department). While she plays devil's advocate often enough, and we butt heads occasionally, it just makes me validate my ideas before executing on them. If I didn't have her supporting me, I would have given up on this initiative a long time ago.

Knowing When It's Working
The last twelve months have been pretty positive. We've hired a lot of really smart people who understand where we're going, and have helped us get to the next level. We've also had a lot of people participate in a new technology/process project, and most of them have really enjoyed what they have gotten to do while adding significantly to their skill sets (some for the first time in years). There's been a lot of challenges and tribulations, but an equal number of successes, and everybody has learned from their experiences.

I've also noticed a distinct attitude shift across the department in the last two months. Pretty much all of the prior naysayers have accepted the change in direction, while others are actively promoting it in everything they do. For many, there's the feeling that the transition can't finish soon enough. There's a hopeful and positive feeling to the new projects that are in progress, and a cohesion forming between our teams as they find themselves getting on the same page with their processes, technologies, and direction. This cohesion has never existed in our department in the six years I have worked there.

Best practices are being shared regularly through natural collaboration, occuring as our expertise with each new technology and tool matures. Small groups of motivated and responsible parties have been forming automatically to solve common problems, after which they are presented to me for blessing and standardization.

The most interesting thing to me is that this cultural attitude shift occurred over a very short period of time. We had years of staunch resistance and disinterest, and then suddenly, things have started to gel as though somebody snapped their fingers. I like to think of this as the "event horizon" of organizational change. I'm not sure if this is a common and/or legitimate perception of events of this nature, but that's the way it has felt to me after almost five years of pushing for it to happen.

In Closing
I've been rambling on for way too long, so I'll wrap this up. I want to make this point clear for anybody else who is trying to change the organizational mindset and culture of their corporate IT department.

The bottom line is this: the entire period of culture shift required a near constant level of effort, during which I found that I had to maintain an unwavering vigil of positive reinforcement for our new direction and technologies. I often felt like giving up on the draining and repetitive process of convincing people to do something that they usually didn't want to do; after all, it would have been far easier to just go and work somewhere where the organizational values I yearned for were already in place (although truth be told, I'm not sure if such a company exists on the East Coast).

But now that the switch seems to have flipped, things have changed so drastically in terms of culture and attitude that I have to remind myself that it used to be the other way around. We've got really interesting work happening in exciting technologies, and the rewards gleaned from watching resources apply their new found skills to a successful project can't be measured in words.

Sure, we have a crapload of work left to do to get it all finished. I'm currently wrapping up the departmental development process changes our web team pioneered, while another pair of resources irons out the kinks in our SDLC and requirement/project management tools. I'm going to spend all of next year getting our QA processes straight, and pushing hard to promote the transition across the teams that are just now getting comfortable with making the jump.

Any change in corporate IT culture is going to fail if you aren't doing it for the benefit of the people that will live with it. My motivation for making things different stemmed entirely from the pain of failure after our first web team project crashed and burned, and the strong desire to make sure that situation never happened again. I can honestly say I've failed more than I've succeeded in my career, but having the opportunity to see things turn around at CFI and play a role in them doing so has been both tiring and thrilling in equal measure.