Mar 1 ’09
The Importance of Your Program Descriptions
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?
First, the positives: The effort these two execs were backing had the support of the company’s board and C-level . leaders. So they had that all important support from the top. This wasn’t a particularly politically charged effort, so they weren’t fighting those battles. The executives themselves had strong reputations. They had funding and a staff in place. So far, so good.
Now, the challenges: This effort was new to their organization. It involved new processes and new accountabilities. It also involved technology changes that were difficult to explain to non-technical colleagues. Moreover, success involved the active support of managers from C-level executives down to mid-level managers. It was this string of managers who would make or break the program as they enforced (or didn’t) the new processes and accountabilities.
To gain that support, these two execs had recruited a half-dozen leads who were requesting one-on-one meetings to explain the importance of the effort and to ask for support. Each meeting followed the same format: the program lead explained what the project was, what it would accomplish, and what would be required from the manager’s group. Then they would ask for support and set next steps.
Now pause. We’ve already established that the program executives couldn’t recite a succinct description of the program itself. Could their program leads? Or were the program leads slapping a PowerPoint on the table with the explanation that, “The answers are in there.”
Now back to you. As an astute leader yourself, you know the importance of first impressions. When you’re pitching a project, program or technology, you know that your colleagues will probably form an opinion in that first minute about whether your effort is going to be successful, how strongly they want to be associated with it, and how they regard you for backing it. So, those words in the program description can be critical.
What’s highlighted in your program definition, and the specific words used, tell the world:
- Who you’re trying to engage
- What you’re trying to change or introduce
- What you expect of participants.
Programs that succeed know exactly who they want to involve, what they want to happen, and what successful engagement and results look like.
Because these few words are so important, you should learn the elevator speech associated with your program and you should vet that speech, especially the portion that describes what the effort is. Examine every word to ensure that it sends exactly the message you think is required to form a positive first impression.
Let’s consider some different definitions for a single discipline or program to see how the wording of these definitions sends different messages to program stakeholders. As an example, we’ll use definitions of data governance. Consider the details they focus on. Do they project a strategic or tactical perspective? Consider the subliminal messages they might send: Will participants need to be tech-savvy? How hard will the work be?
We’ll start with the definition of data governance introduced by the Data Governance Institute:
“Data governance is a system of decision rights and accountabilities for information-related processes, executed according to agreed-upon models that describe who can take what actions with what information, and when, under what circumstances, using what methods.” (Source: www.DataGovernance.com)
This is a general, all-purpose definition of data governance, focused at the mid-level managers who must come together to make cross-functional decisions, set policies, and execute them. Its emphasis is on the idea of governance as setting the rules by which managers manage.
Why did the Data Governance Institute (my organization) highlight “rules of engagement” (a key component of the DGI Data Governance Framework)? When it was written and published, we wanted to provide an alternative to definitions that focused on authority and control structures, since we thought those definitions might not be well-accepted in consensus-based cultures.
Now look at some alternative definitions. Can you see how the way data governance is defined might influence how it’s executed? Can you tell from the definitions whether it’s aimed at executives, middle managers, or individual contributors? Can you guess what types of changes (to the organization, processes, authority structures, technology, and data) are being supported by data governance?
Here’s a definition from IBM: “Data governance is about how an organization uses data to benefit and protect itself.” (Source: www-01.ibm.com/software/tivoli/governance/servicemanagement/ data-governance.html.)
Would you expect an organization that uses this definition to be focusing its data governance efforts on improving the quality of its data or on standardizing definitions or policies for that data? I wouldn’t. I’d expect a focus on security, with the techno-centric approaches that usually go with that. I’m not certain how to interpret the “benefit” part of the definition. What conclusion would you make about what’s expected of participants and stakeholders?
Here’s another definition: “Data governance refers to the overall management of the availability, usability, integrity, and security of the data employed in an enterprise.” (Source: http://searchdatamanagement.techtarget.com/sDefinition/ 0,,sid91_gci1151688,00.html.)
Would you expect a program with this definition to be focused on just security? I wouldn’t. I’d expect a rather broad set of goals. Suppose another executive told you they were introducing a program with this definition. What questions would you have about the number and types of efforts they would undertake to achieve their goals? What assumptions might you make about the level of resources they would need? What would you ask about the who, what and when of managing the availability of data? Usability? Integrity? Security? What’s your first impression about how IT would be involved in such a program? How about how various business teams might be involved? Does this definition give you any impression about how managers will come together to make decisions? Do you think the program is making assumptions about who has the right to introduce policies, standards, and data-related rules?
Consider this definition from Robert S. Seiner, publisher of “The Data Administration Newsletter (TDAN)”: “Data governance: The execution and enforcement of authority over the management of data assets and the performance of data functions.” (Source: www.tdan.com/view-articles/5037.)
I’ve had many debates with the author of this definition. He contends that the purpose of a data governance program is to ensure people do what they’re told by those in charge (my paraphrase). In this vision, you might conclude that what’s needed are data cops—official program representatives who know what leadership wants, and who enforce those rules through the execution of authority.
- When the author and I have debated this definition, we’ve talked about three topics:
- How organizations relate to “cops.” I contend that, yes, some organizations with command-and-control cultures expect a certain amount of policing and “enforcement of authority.” Other cultures, however, are based more on consensus. In those cultures, major changes are expected to come about via persuasion rather than power. Ask yourself this: If you exist in a consensus culture, how would your colleagues react to this definition?
- Our second topic of debate has been around the concept that those in charge are ready to issue data-related mandates that must be obeyed by staff across the organization. In my experience, those who have the highest level of authority in an organization may not be experts on how to manage data. Rather, I’ve found that sometimes an important function of a data governance program is to assemble knowledgeable resources from across the organization that can compile, prioritize, and recommend data policies and practices that meet enterprise needs. In these situations, those in authority are depending on this governance body to issue recommendations that leadership can turn into mandates.
- Our third topic of debate involves the second part of this definition—the “execution and enforcement of authority over the management of data assets and the performance of data functions.” I interpret this to imply that the focus of the program will be on data management departments and resources. What do you think? If this program definition were introduced in your organization, how do you think business-side managers would react? In that critical first minute of hearing about the program, what do you think they would infer about their role?
Here’s yet another definition: “Data governance is the practice of organizing and implementing policies, procedures, and standards for the effective use of an organization’s structured/unstructured information assets.” (Source: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/ library/uuid/60022998-5d17-2b10-dbaa-8e3ab357fa55.)
What do you think your organization’s business-side managers would conclude about this program? What do you think they would conclude about the type of changes the data governance group would be proposing? What does this program definition say about the scope of efforts? Would the program be confined to data in the mainframe?
Now consider this definition: “Data governance is the formal orchestration of people, process, and technology to enable an organization to leverage data as an enterprise asset and mitigate risk.” (Source: http://0036f23.netsolhost.com/ data_governance.htm.)
With this definition’s focus on risk, I would expect the program to support a more formal approach to assessing data-related risks and implementing controls to manage that risk. What do you think? Because of the use of the word “orchestration,” I would infer that the way people, process, and technology will be used will involve careful alignment rather than heavy-handed pronouncements. Because of the goal of enabling an organization to “leverage data as an enterprise asset,” I would assume the program will be inspired by approaches used to manage other types of assets, such as physical and financial assets. What would you assume about such a program? Would you expect it to have a tactical or strategic focus?
Finally, let’s consider one last definition: “Data governance is the decision-making process that prioritizes investments, allocates resources, and measures results to ensure that data is managed and deployed to support business needs.” (Source: www.b-eye-network.mobi/view/8393.)
What would you infer about the focus of this program? Is it tactical or strategic? Is it concerned only with technical issues or also with business issues? Does it imply that someone in the organization already knows everything that must be done, or will participants be involved in making decisions? If so, what type? Would they be driven by ideals or metrics? Would you want to sign on for involvement with this program?
In conclusion, let me again acknowledge that as a member of the management team of an organization large enough to employ mainframes, you’re a busy person. You’re too busy to attend to all the details that cry out for your attention. That’s what you have staff for. Yet, if you’re expecting your staff to meet with other leaders to solicit their support for a program, project, or initiative that’s important to you, you should pay attention to one detail: the description of that effort. Read it carefully, and speak it out loud. Consider every word and what it implies, who would be involved, what they would be focusing on, and the ground rules that apply to their engagement. Carefully consider the implications of the definition.
Don’t be afraid to solicit multiple versions of a program description so you can pick and choose the exact words that will help craft the perfect elevator speech. After all, a great deal rests on that first impression.