Problems are often opportunities in disguise. Here, is where a high turnover of staff — a continual and often complained about problem — was turned into a force for change. No one lost a job in this use of this project management tool!

We had an annual staff turn-over of about 33%. Every year. The “company” did this on purpose, but every manager hated the problems it caused. It was often the reason given why something went wrong, or why we couldn’t do something as fast or as well as we wanted.

We were the US Air Force. Our strategy was to move people between assignments just about every three years. The reasons for moving are as much legendary as the are practical. We moved often to keep ourselves prepared to move in a real emergency; to round out our skills and capabilities in a variety of jobs; to spread the burden of who gets the bad jobs (3rd world country remote from our family) and who had the good jobs (Hawaii); to generally making us a well rounded and flexible Airmen who are ready to meet the needs of the service and the country.

Great, but every time someone got up to speed in their job, they moved on to something else. Every time I got really cranking at my job, I’m informed I’m getting a new assignment and need to start working on my move.

As an officer and a manager, I kept losing my most experienced people and getting new people in. People who I had to get up to speed, fast. Yes, we generally do the same job that was done at a past assignment. However, especially in the software field, every job practically required a new set of domain knowledge. At one assignment we worked with software embedded in electronics in the aircraft avionics. The next assignment we programmed command and control computer systems that reached around the world. The follow-on assignment, we wrote code for a satellite based early warning system. Finally, we were maintaining code that tracked the flow of bombs and bullets, or that kept organized the personnel records of every Airman in the USAF. Every development environment, the tools and processes we used to do our job, could be significantly different because of the difference in the domain we supported.

It Started With A Bad Situation

We were terrible at making software changes. Our customers literally refused to take any changes from our unit because we had constantly messed up their war-fighting capability. Things that once worked would no longer work and had to be fixed. New capabilities were more difficult to use then the existing, simpler, capabilities. Software maintenance and enhancements at this five nation military unit had all but ceased to happen.

Surprises For The New Guy

I didn’t know this history when I showed up as the new officer in charge of software development. I was just unpacking boxes in my new office when my boss, a German Lieutenant Colonel in the Luftwaffe, came in with an urgent need. He needed me to stop the programmers from reading newspapers at their desks! OK, I guess this isn’t a bad task to start with. I had not met everyone yet, so this was a good way to wander around, see for myself, to learn what everyone was doing and to do a little motivating.

There is a problem it seems. On walking around and talking to everyone, they claim they don’t have any work to do. How is that possible? I’m a bit embarrassed that I am so new that I don’t have a clue at what the work to be done is yet. OK, this is still useful. I head back to my boss to get a briefing on what we are doing, requirements, customers, schedules, deadlines, etc.

My boss’s response to their claim they don’t have any work to do? He doesn’t deny it. He just says that instead of reading newspapers, they should be reading technical manuals. I’m stunned. What are we doing here? With a little deeper probing, I finally hear that we don’t have any work that has been authorized. There is a major project that has just been contracted out to a vendor to give us a new command and control system. We will maintain this new command and control system once it is finished. Finished, I come to understand, in a few years! I can’t believe it.

What do we do over the next few years? It seems we will be learning the new system, but since it is still early in development, it will be some time before there is something to study and learn. In the meantime, we need to be creative and keep everyone busy. OK, time to go find a new assignment. This is completely not what I want to be doing.

What about the system that is currently being used to allow us to fight any war in this region? Is there nothing that needs to be done on it? My boss tells me there is a backlog, accumulated over eight years, of things our customers have requested. However, every time we make changes it seems like it causes more problems than it solves. In one case, our team was told to “just go home” when they were unable to make a new set of changes work at our customer site. The new system will include all these changes the customers have requested — in a few years.

Salvation

This situation went on for a few months. I was depressed. I was a workaholic and this was not where I wanted to be.

One day, I got called into my boss’s office. It seems we had a bit of a problem. There was a bug in the command and control system and we could not wait for the new system before we fixed it. It was a “safety of flight” problem and that without a fix, we could end up sending two aircraft to the same space in a way that could cause a mid-air collision. We practiced and trained with the existing software, so with every exercise we had a chance of causing a mid-air mishap. Apparently the problem was found because that is almost what happened.

Great! Kind of. If we messed this up we could kill people (in the air and on the ground). This had to be done and done well. The notion was that the people we had could not be relied upon to do the job. I was to make the changes and fix the system, personally. Gee, I had seen this kind of thing before but at least we now had something to work on. We got started.

Solution

I was not the hero type. I was not interested in making the change and getting all the recognition and rewards. It would be an easy change I figured out, but I still had a staff that didn’t have work to do. It did give me the opportunity to work through the entire development process. I completed the change, understood the system and architecture a bit now, and demonstrated that it worked. With that success, changing the system successfully, I wanted to get my team going again. My boss had great skepticism, but he allowed me to start working on other needed changes. But, how to do it and avoid the failures of the past?

It was a two phased approach. For the new folks coming in, I brought them up to speed on the process. I did this by pre-analyzing many of the simple changes that were needed and giving these to my new folks to do. It allowed them to learn the system (end to end) and to complete a needed project at the same time. It also allowed me to influence how they did their work. It was important that they had a high degree of success, so that we could continue to work on the system. My boss accepted that I could do the work successfully, but he did not yet believe anyone else could be relied upon.

The second phase was to get the “old timers” up to speed. For the other Air Forces, they didn’t all have the high rotation the US Air Force did. Some of these folks had been here for years and were expected to be here for years longer. One individual, my boss told me, was going to be incapable of doing much of anything, so I would always have to do his work for him (i.e., very close supervision).

New Airmen rotating in had little or no reluctance to getting help with learning the system and getting their first project completed. As I mentioned, every domain was significantly different and had to be learned. Most people expressed that they appreciated such an immediate and well integrated training program. As I got more people going, new people would be assigned a mentor, someone who had gone through the process and would help them learn the system and would look over the initial work they were assigned. The new folks didn’t know the history of us not being allowed to do work. They just came in and got up to speed quickly.

The “old timers” did just as well. They also didn’t like not having work to do, and so were open (well, most of them) to our approach. They also saw new people coming in and successfully changing the system — a system that they supposedly had more expertise in.

We were no longer a collection of programmers all doing our own thing (actually, nothing), but instead a team following some very specific ways of attacking each problem that needed solving. The crowning achievement is when the individual my boss said I would have to do his work for him, my boss now said that he now would like to have a “dozen” like him!

Lessons Learned

We got the unit going again doing software development. In about three years we not only cleaned out the accumulated backlog of eight years, but also handled a huge inflow of new requests received once our customers recognized we were reliably making software changes again.

No one was reading newspapers at their desk any longer. Everyone was motivated and excited. It was hard to hold folks back and not overdo how many changes we were making at any one time.

We leveraged the “terrible” turnover to quickly bring a new team up to speed on how we wanted to change how we did business. It forced us to think out and plan how we brought in new people. In the future, I would never again worry too much about a high turnover. If we were well organized, a high turnover was in fact a huge advantage when improving an organization.

Problems are often opportunities in disguise. We’ve all heard this before. Here, we took a classically bad situation with high turnover and turned it into an opportunity for change which transformed the project performance of an organization.