6 IT lessons learned the hard way

“Failure is not an option,” the Gene Kranz character tells a roomful of NASA engineers who are trying to come up with solutions to save the crippled space capsule in the movie "Apollo 13." It’s a thrilling, heroic moment in a film full of them.

If only all government technology programs and projects worked that way.

The truth is that many government IT projects don’t succeed, at least not in the way that people initially envisioned they would. And there are often many small failures along the way, even if the eventual implementation is successful.

It’s much the same for the people who are in charge of government IT. It’s rare to find any executive in a government agency who does not have at least one example of a way that a project can fail.

As the following stories show, failure in government IT is definitely an option; it’s almost a requirement. The people spotlighted here are among the best government IT practitioners, and yet it seems they almost had to fail at some point to learn the lessons that propelled them to their eventual successes.

Lesson 1: It’s not about you; it’s about the customer

Kevin Carroll finished his government career in 2007 as the Army’s program executive officer at the Program Executive Office for Enterprise Information Systems (PEO-EIS). But it was years earlier, as a young contracting officer, that Carroll learned the lessons that helped carry him to one of the military’s top IT management jobs.

As Carroll described it, he knew the rules of contracting and was technically competent, but he was also self-centered, controlling and leery of trusting anyone else’s judgment. Carroll expected things to go exactly the way he thought they should go and considered himself the sole guardian of the taxpayers' trust.

“I thought industry was only out for profit and that my government customers only wanted to get promoted,” he said. “I didn’t trust anybody but myself.”

The result was a tendency to restrict communications with both parties, something that came back to bite him in a big way during the Army’s first big PC procurement. Carroll ended up with customers who were unhappy with what the contract offered and vendors who thought they hadn’t been listened to. The procurement was eventually protested.

With the help of a mentor, he came to realize the need to be more open to input from all sides and more trusting that others also had the government's and taxpayers' interests in mind. He internalized those lessons over time, all the way to the program executive officer position.

“It gave me an ability to make sure customers were involved with program managers and to take industry input and utilize that for the betterment of government,” he said. “That really became a part of my personality.”

As president of his own consulting company, the Kevin Carroll Group, Carroll said he sees the same thing happening today. There are a lot of young and inexperienced people in government doing what he did, he said, “and, quite frankly, a lack of the mentorship that I had.”

NEXT--Rethink your management style

Lesson 2: Get out of the way

Linda Cureton, NASA’s CIO, considered herself a good manager during a 16-year stint at a previous government organization. But after she left and looked back, she decided she had not been all that she could have been.

Everything at that organization reverted to the way it had been before she got there, “so while I did a good job of managing, I didn’t really bring people to the point where they could take over and keep the work going,” she said. “I didn’t do any of that stuff.”

Taking that lesson to her next job, the first executive-level position she held in government, Cureton changed her style of managing. It’s now been 10 years since she left, “and I can still see the things I put in place there are still in place, so I feel that I made a real impact with that.”

That first, big mistake was in succumbing to the allure of strength. If you're a good manager and, in particular, have strong technical skills, it's easy to get sucked into a situation of solving all the problems yourself. As Cureton put it, it’s “very seductive to micromanage when you’re a good manager, and you get very comfortable with that."

“I knew the answers to problems, and I could help people with them when they came to me for help,” she said. “But I never would put people in the position where they could help themselves and learn.”

However, as a leader rather than as just a manager, you need to get out of that comfort zone to build the organization. Now, Cureton said, she makes it a point to breed leaders. But she’s the first to admit it’s tough.

“It takes a lot of humility to get yourself and your ego out of the way,” she said.

NEXT--Nurture your learning tree

Lesson 3: Never stop studying

Being an IT professional requires constant study to keep up with the technical demands of your profession, something even those in leadership positions need to admit. Falling behind on that aspect of the job invites trouble.

Steve Boutelle found that out the hard way. He is now CEO of Cisco IRIS and vice president of Cisco Systems’ Global Government Solutions Group. In 1997, the retired lieutenant general and former Army CIO was a colonel in charge of Task Force 21, the Army’s first digitization initiative. For him, that meant more of the databases and Unix systems he was familiar with.

However, the world of Web services was starting to leave that environment behind. Despite the suggestions of some of his people to look in that direction, Boutelle drove the Army down the familiar path. But for one particularly persistent lieutenant colonel who pushed Boutelle hard on the issue, it could have been a much worse scenario than the year or so the Army spent in that outdated environment.

It was, Boutelle said, “like a lightbulb going on” when he finally realized his mistake through reading the periodical and technical journals and on one of his regular trips to Silicon Valley and Microsoft in Redmond, Wash.

That taught him the value of study as an IT professional and the need for leaders in that profession to be able to admit mistakes and change direction.

“It’s not a job or an occupation,” he said. “It’s a profession, and there’s a big difference between them.”

Boutelle said he sees some disturbing signs that the lesson he learned might still be needed in government today, particularly when it comes to virtualization and cloud computing. That’s a huge inflection point in industry today, and he said he feels it should be one in government, too. But the Defense Department and others are reluctant to commit.

To meet evolving demands, IT professionals need continual learning and studying, he said, “and I find that lacking.”

NEXT--The primacy of people

Lesson 4: Put people first

When he was in government, Ira Hobbs was known for his ability to build teams and bring all types of people into the mix on the programs he ran as an IT manager and as CIO of the Treasury Department. As principal officer at his own consulting firm of Hobbs and Hobbs, the primacy of people is something he continues to advocate.

That person wasn’t easy to see in his early days in government. By his own admission, he was a bright-eyed, bushy-tailed intern straight out of graduate school who had come to fix the government.

“I was very aggressive, very straightforward and, I thought, very businesslike,” he said. “But in being that, I was very forgetful of the small things. I had a future, and I was going somewhere, but I was stalling all of the possibilities by putting the focus on me and what I was doing.”

The turnaround came not through any great epiphany but from the intervention of his mentor’s assistant. Perhaps seeing more in Hobbs than he saw in himself at the time, she took him aside and stressed the importance of people in the organization and the value of the roles they play. Hobbs said that one event stuck with him throughout his government career.

“That’s why, in most organizations, the most important people that I got to know first were those who worked in the mail room because if they don’t do their job, then, for the most part, senior management can’t do theirs,” he said.

Hobbs made the importance of valuing everyone in the organization a part of his professional and personal brand, he said, “because the moment you start to forget about the people who make up the organization, you start to forget about the organization itself.”

NEXT--The importance of clear lines of authority

Lesson 5: Governance is crucial

In his new post as deputy mayor for operations in New York City, Stephen Goldsmith said he hopes the lessons he learned implementing IT projects as mayor of Indianapolis translate to the kind of complicated, cross-agency programs he will be in charge of in the Big Apple.

For example, in New York, he has responsibility for a complicated 911 emergency dispatch modernization that involves strong professional organizations, such as the fire and police departments, and many demands from residents.

In this case, there's an overarching technology solution and a need to referee the differing opinions of strong-minded professionals to generate an effective plan.

As the two-term mayor of Indianapolis in the 1990s, Goldsmith faced a similar situation when implementing a new, integrated criminal justice system.

“It took me a half-dozen years to create that system in Indianapolis,” he said, “and when we turned it on, it was the best, most efficient example of a mainframe system on the day that mainframe systems became obsolete.”

It took that long to implement because there were no clear lines of authority, he said. The cross-agency governance process didn't clarify who could make the final decisions.

It was a gradual process. Deliverables started to slip, and each time they did, people had a good excuse. Unresolved issues started to pile up. Eventually, the light bulb went on about the need to change the governance and decision-making process, Goldsmith said.

“That, we discovered, requires the senior leadership to have the person-in-charge under the mayor and deputy mayor to have a combination of true leadership ability, subject-matter knowledge, and to be technically fluent,” he said.

The lesson learned, time and again, is that problems in implementation are never about the technology; they're about people.

“Almost every failure I’ve had has been a failure of governance,” Goldsmith said.

NEXT--Time is of the essence

Lesson 6: Time is money

Karen Evans, who finished her long government career in 2009 as the Office of Management and Budget’s administrator for e-government and IT, learned a couple of lessons the hard way: Government waits for no one, and good enough is often OK.

The first step in Evans' education came at a major department early in her career. Applications were not working properly, and code had to be corrected. As the person in charge, she focused on fixing the code and didn’t keep an eye on other things, she said. In the meantime, pressure was building, and services were affected.

“The usual way to handle that kind of problem was to take time to analyze the code and figure out what was wrong with it,” she said. “But in the age of 24/7, you can’t just take your stuff off-line while figuring it out. I almost got fired for that.”

Later, and particularly as technology got cheaper, Evans found ways of getting around those kinds of problems, such as using hardware to help resolve software issues. The code still had to be fixed, but technology gave her the leeway to make those fixes while maintaining performance.

An extension of that lesson is the realization that it’s often counterproductive to try to be perfect and fix everything, she said. Another agency that Evans worked for didn’t want to implement an inventory control system because it didn’t have a module to deal with classified material, even though that only accounted for 5 percent of the total inventory flow.

“I do see that in government even now,” she said. “They want a 100 percent solution when they could have something that can provide 80 percent, giving them time to work on getting the other 20 percent.”