Outcomes-Based Leadership: Not Common Sense

We've often written here on PMThink about the need to focus on outcomes. It occured to me that a lot of people look at Outcomes-Based Leadership as a "given." They say, "Of course leadership should be based on outcomes! What else would it be based on?"

It is surprising then how little focus is really given to outcomes in organizations. They focus on activities, tools, processes, forms, measures, costs, schedules, and so on. Everything except outcomes.

If we really revisited many of the processes and tools in our organizations with a keen eye toward outcomes (i.e. what purpose is it intended to serve, and is that the best and fastest way of serving it), we'd see how far we miss the boat.

I have a model I like to use called SET. It stands for Simplicity, Engagement, and Technology. It's simple, but powerful, and works well with outcomes-based leadership.

When we look at outcomes, we must keep these three factors in mind : Are we taking the simplest effective route (and do we even understand and agree on what the outcomes should be in the first place)? Are we engaging others in the best way to achieve our outcomes? Are we leveraging technology effectively or is it getting in our way?

Most organizations have a Chief Technology Officer. To this, they should add a Chief Simplicity Officer and a Chief Engagement Officer. If all three were focused on outcomes, and geared all people, budgets, departmental structures, processes, and tools toward the outcomes the organization is striving to achieve, strange things would begin to happen. People would become energized, not weighed down by the saddle of overused, misused, and rigid processes. It would become second nature for people to ask, "And just why are we doing this?"

Meanwhile, I'm afraid Outcomes-Based Leadership is not common sense. But I have hopes that one day it will be.

The Enemy of Simplicity: The Thud Factor

We've all heard about the benefits of simplicity, whether in our processes, our communication, or in our objectives. In all its forms, simplicity is a way to reduce confusion, boost morale, and encourage speed and flexibility. In fact, simplicity, speed, and flexibility are three of the "Six Winning Principles" I wrote about in Napoleon on Project Management (the other three being exactitude, character, and moral force).

But there's a lurking enemy of simplicity, and it often goes unnoticed. It can be found in the motives of individuals creating the processes, communications, or objectives. I'm talking about job protection. I don't mean the blatant kind that results from grandiose thinking, egotism or turf wars. It's much more subtle than that.

It can happen if an individual or department is placed in charge of creating a process or devising a plan. Or it can happen if a consulting company is brought in to do a study or offer advice. Common sense says that these people, while not necessarily devious, will hesitate to come up with anything too simple, lest they feel they're not doing their job. The result is often something that is way more detailed, complex, and expensive than it needs to be.

What can we do about it? We need to be very aware of motives and rewards, and make sure we don't consiously or unconciously reward people for complexity. We need to send a message that the shortest, simplest way to meet the goal wins (even offering incentives if possible). This can avoid what many consultants jokingly refer to as "the thud factor"----the customer's perception of the value of the service as judged by how much of a noise the report makes when it's dropped on their desk.

Whether it's a consulting company, a PMO, an internal process center, or a project team, we need to find a way to head off the thud factor and insure simplicity. We can do this by understanding motives; sending the right message; insisting on brief, simple reports; and creating the right reward system.