Making change palatable for users at Fannie Mae


Mortgage finance giant Fannie Mae has a workforce made up largely of economists, accountants, auditors and analysts, including credit risk analysts, business analysts, data warehouse analysts, process improvement analysts and data management analysts, to name just a few. These are people who like figuring out how things work, and often times they like building their own tools to help them with the job. This tendency can be a business asset, but it also can introduce unnecessary risk to the organization.

A couple years ago, Fannie Mae decided it was time to find out what kinds of applications were being developed by end users without documentation or controls. For a look at the effort to inventory the applications, apply appropriate control measures and improve both efficiency and security, you can read my interview with Leon Nisenfeld, director of application development for operations and technology risk controls at Fannie Mae. But one of the things I found most interesting about Nisenfeld's story is the way he and his team handled users' reactions to this major change in the way they do their work.

It was to be expected that users would express concern when Nisenfeld first explained that applications could no longer be built without appropriate controls. "The first reaction was, `Oh are you going to take away my tools?'" he told me.

The challenge was to convince them that while it may take a bit longer to get the tools they wanted, there would be benefits not only to the organization's risk profile, but also to their own individual jobs. A key to convincing them was communicating in an open and straightforward manner.

"Walk the talk," Nisenfeld said. "Be totally transparent. Tell them that things aren't going to be quite as easy for them as they were before. You need to show them that you can listen and understand their needs in terms of agility and the ability to get a quick solution."

Great communication won't convince all users that change is good, however, and when new controls were applied, some employees weren't satisfied. Whenever this case arose, Nisenfeld made sure that employees understood that their concerns were heard. He allowed controls to be adjusted based on risk level. Applications that are instrumental in developing financial results, for example, demanded stricter controls than applications used for processing data for internal use.

Trying to force end users to cede all application development initiative to the IT department would only have created an army of rogue developers, Nisenfeld said. By working with them instead, he was able to rein in risk and simultaneously improve the tools at their disposal.

"In the old way of doing things, there was a hard line. End users would just go underground," he said. "Now they see there's a dialogue going on. They see that you're comfortable finding the right balance." - Caron