Showing posts with label Program. Show all posts
Showing posts with label Program. Show all posts

September 2, 2009

Are Organizational Values Valuable?

Many organizations have a value statement that identifies what traits are most important to them.

Organizational values are similar to an enterprise architecture in that the organizational values identify a type of target state for organization members to strive for and adhere to.

The purpose of value statements is to guide people’s behaviors, decisions, and interactions.

For example, one police department that I looked up has value statements around the traits of integrity, pride, service, and fairness. A city that I found had value statements for passion for community, integrity in work, and results through collaboration. A non-profit organization had values of leadership, integrity, excellence, and impact.

As you read the value statements they give you a sense of the organization in terms of who they are, or actually more like what they believe in.

But do they really—i.e. are organizational value statements something that people in the organization are aware of, understand, can locate, recite, or summarize, and moreover, are the values actually used to guide behavior?

Or are these value statements written by leadership, human resources, or some strategic planning function in the organization as an ivory tower effort, and then published in the organization’s glossy annual plan and/or on their website, but never really communicated with or adopted by the people in the rank and file?

The question is not posed in order to be cynical, but to genuinely ask: are organizational value statements “true values” or are they more marketing and branding glitz?

With few exceptions, I would challenge most to identify whether their organization even has a value statement, let alone what it is. Moreover, the last time, they thought of and considered the organizational values in making a decision or taking an action.

Then why do organizations have value statements?

Perhaps, organizations intuitively or through management best practices know that they need to have values, because they are genuinely important. Just like as individuals we have personal values (be they religious or otherwise) that “tell” us who we as human being are and guide our behaviors, so too as organizations, we need to identify the values that will be our “moral compass” and define our organizational identity.

The problem though comes when organizational values are developed as a “project”—a time bound task or “to do” for someone or some committee who researched it, developed it, and got approval on it; but not managed as a “program”—an ongoing endeavor and commitment to create awareness, educate, and even enforce the values through performance rewards and recognition.

Moreover, culture and peer pressure are vey powerful forces that drive employee behavior, whether they consciously are aware of it or not. So many values are indeed employed in day-to-day interactions, but they may not be explicit and they may not be the same values that are actually in the organization’s value statement. That is because the informal network and implicit values may actually be more prominent and powerful in driving people’s behaviors that the formal and documented one in the organization.

The key is for leaders to genuinely commit to the values and their use across the organization. The leaders need to provide for the values to be widely communicated (on wall hangings, pocket cards, employee reference guides, Intranet and so on) and they need to be referred to in periodic communications (speeches, announcements, broadcasts, meetings, etc.). They need to be living, breathing values that touch people daily (and obviate the implicit and unsanctioned ones).

Further, leaders need not only talk about the values, but also they need to exemplify them. In other words, leaders need to practice what they preach and lead by example using the values to drive decisions and actions in a way that is transparent to all.

What I learned when I developed user-centric enterprise architecture is that any ivory-tower exercises or development of organizational shelfware is by definition a failure, and therefore we need to treat all of our strategic planning and management functions as a real-world effort.

If we could do that with both EA and organizational values, it would be great to integrate them and use them to drive an explicit target state for both the performance and the business perspectives, as well as a human capital perspective of the architecture.


Share/Save/Bookmark

August 12, 2007

Enterprise Architecture: Program or Project?

Enterprise Architecture is a program with many phases and projects.

Several times in my career, I have been brought in to develop an enterprise architecture for an organization, and just about every time, the boss has asked how long will it take, when will it be done, or some other similar version to time-bind the effort.

However, for those of us who are practitioners in the field of EA, we know resolutely the answer is that EA is never done.

Legally, EA is mandated by the Information Technology Management Reform Act (a.k.a. the Clinger-Cohen Act). As such, it is not a one-time event, but an ongoing requirement, and thus an established program in every department of the federal government.

But more than that, EA defines the current, target, and transition plans for an organization. And by definition, a current and target are just snapshots in time, which are in essence outdated a moment after you publish (just like when you drive a new car off the dealer lot and it immediately becomes “used.”) That is, an organization, its business and technology, are constantly evolving and in a state of flux, responding to internal and external factors (such as new mission challenges, business opportunities, congressional or executive mandates, changing customer expectations, new technologies, and so on). So in an ever-evolving organization, the “current” state does not stay current, and the “target” does not stay current (up to date). That is, unless you place these under “maintenance,” i.e. you refresh these on a periodic basis, and make course corrections along the way.

Further, developing and maintaining an EA for any organization is a challenging task, especially for a large and complex organization (like many in the federal government). As such, EA efforts need to be broken down into smaller projects to be successful. And these projects need to be clearly defined in terms of scope, schedule, and performance measures and managed for all project knowledge areas (reference: Project Management Book of Knowledge).

So the next time your boss asks you, “When will the EA be done?” I suggest you tell them: “The EA is a program with many phases and projects. Phase (#) is scheduled to roll out (date).”

Has this ever happened to you – that your boss asked you when the EA would be finished? What did you say/do?


Share/Save/Bookmark