IT Management

There’s an old adage: You can’t manage what you don’t name. Then there’s its corollary: You can’t manage well what you don’t explicitly define. Done right, a well-writt en project or program description will help guide all participants toward your goals. Done wrong, this definition will set false expectations and send participants down the wrong path. As a leader, you should review the official descriptions of efforts for which you’re responsible.

Consider this cautionary tale. Last year, a large bank asked me to assist a pair of its executives— one an IT leader with a major mainframe project, and the other working in risk management.

Together, these two leaders were sponsoring a major program that would touch most functional areas in the bank. For about six months, they had been meeting with leaders and mid-level managers across the bank, asking for their support and participation. They called me in because they had been getting lukewarm response where they had expected overwhelming enthusiasm. They needed to know what was going on, and how to get back on track.

I met with each of them separately. Each conversation began the same way, “OK,” I said, “Tell me about the program.”

Within minutes, it was clear what was wrong. While each executive was enthusiastic about the cause and had a clear vision of his desired end state, neither one could succinctly tell me what the program was. When I pressed them for details—what it did, who was involved, major efforts, key responsibilities—each pulled out a stapled stack of papers about a half-inch thick. “The answers are in this PowerPoint,” they each said.

“I’ll read that later,” was my reply. “Just tell me about the program.”

Neither leader could tell me the basic who, what and when for their program (which they admitted could be important to their careers). They could tell me, however, the name of the resource they had assigned to create the program definition as well as other “details” that were included in the PowerPoint they were using to recruit support. They could recite management specifics about this program—who was in their new organization, how much money they had gone through, how long they had been in business, and how their success was being measured. What they couldn’t give me were those 100 or so words that described the essence of what this was all about.

I understood why. As a manager, you have a lot to do. Most of it you have to delegate; you have only so many hours every week. As a rule, you no doubt delegate low-level or “routine” activities. Some of these routine activities are associated with starting up the many projects and programs for which you’re totally or partially responsible. You have a team of functional and project managers to take care of these for you, and you probably have asked them to bring to you only those issues that need your explicit attention. But there’s one “low-level” activity you should really insist on being involved with—the official definition of your programs and projects.

How your program is defined will influence your ability to manage it—to keep all participants on focus, in sync, and striving toward the same goals.

So, let’s critique the previous scenario. Why were these two execs having trouble engaging stakeholders and keeping program participants on focus, in sync, and striving toward the same goals?

3 Pages