All Posts in Process Management and Improvement

|In: Career Management|Last Updated:

Etymology isn’t identity. Where words come from is a matter of historical interest, not proper usage.

So I hope you enjoyed your Memorial Day, even though it’s become little more than a day off and an opportunity for retailers to offer sale prices.

Not that Memorial Day is something to be cynical about. I think about the sacrifices men and women in uniform have made for us and I’m reminded of the Passover tradition, where parents explain to their children that God brought them out of slavery — them personally, not just their ancestors.

Most of those who made the ultimate sacrifice probably weren’t thinking of us at the time. More likely they were thinking of getting the job done, of their buddies, and of their families. And yet, they sacrificed themselves for each of us, personally, and we shouldn’t forget it.

Which has what to do with running an IT department?

Just this: Too often, business leaders cast the need to get the job done in moral terms. There’s a project with milestones and deadlines — employees who don’t meet them are letting the company down, aren’t taking responsibility, won’t “give 200%” (and can we please start respecting the field of mathematics by jettisoning this tired cliché?).

They’re bad people, even though the milestones, and deadlines, and staffing to accomplish them, were adjusted to the point of absurdity through optimism bias and political necessity.

Please remember — the success of a business project lacks the moral imperative of liberating Dachau’s prisoners, not to mention France.

What’s hard is that this isn’t binary. You have more alternatives than just death marches and clock-watching.

In business, a sense of urgency is a valuable dimension of the corporate culture. It’s just that more isn’t better. Even more urgent is equal to frantic — an unproductive state in which employees divert their energy and attention from getting things done to worrying about how they’ll ever manage to get things done, while managers divert their time and energy from making sure things get done to making sure employees look busy every minute of every hour of every day.

There’s a dimension of oddity to this, too. The best executive leaders project an air of relaxed confidence. They’re able to act with urgency without ever looking rushed and harried.

But many of these same leaders interpret an aura of relaxed confidence in their employees as apathy and lack of commitment.

Go figure.

Getting back to deadlines and making them, you want this to matter to everyone. You want this to be a matter of professional pride. You want to make sure “This deadline was never realistic” isn’t the team’s default conclusion when the deadline becomes challenging, even as you conclude it’s time to change the deadline because it was never realistic.

Which brings us to a broader topic.

In some situations, the point of stability is where you want to be. That’s when leadership is easy. None come to mind at the moment, but I’m sure there are situations like this.

Leadership is hard when the stable places are the extremes, because that’s where staying in the healthy middle takes constant attention, a great deal of energy, and constant vigilance.

Maintaining a balance in the healthy middle that bisects the line that has apathy on one end and frantic flailing on the other is just one example. Maintaining a healthy balance between the stable cultural characteristics of chaos and bureaucracy is another.

If you’re a metrics-oriented sort, ask yourself how you’ll measure this sort of thing. Take CMMI (Capability Maturity Model integration), which in many respects is an admirable approach to process maturity. CMMI doesn’t, of course, advocate bureaucracy as it promotes increasing sophistication in process management.

The problem: It doesn’t recognize the near-inevitability of an encroaching culture of bureaucracy as organizations become more process-mature, and incorporate strong management practices to prevent it.

For that matter, and it’s a related matter, CMMI, like most maturity models, has a strong focus on metrics, but tends to hand-wave over the difficulty of making sure the metrics used to measure a process are the right metrics.

Here’s what I’ve never seen: A multidimensional maturity model that makes too much just as immature as too little.

But this is exactly what mature business leaders have to do.

Comments

|In: Organizational Design|Last Updated:

Here’s something to celebrate: Saturday, NASA’s Opportunity rover celebrated the tenth anniversary of it’s landing on Mars and it’s still going strong, even though its planned mission life was only three months.

This isn’t a fluke. Cassini, an international collaboration managed by NASA that originated in 1982, launched in 1997, entered orbit around Saturn in 2004, and completed its planned mission in 2008. It’s still going strong.

Then there are the two Voyager probes, the Curiosity rover, the Chandra orbiting X-ray observatory … what’s interesting about NASA projects is that these sorts of spectacular successes have become ordinary.

Unlike, say, the Department of Health and Human Services (HHS), whose most noteworthy large-scale projects in the same span of years — those would be Medicare Plan D and Healthcare.gov — were, shall we say, challenged.

As pointed out in this space when Healthcare.gov’s problems became newsworthy, using Healthcare.gov, and for that matter challenged state exchanges like Minnesota’s MNSure, as evidence that “government can’t do anything right,” is just plain ridiculous. If that was the case, NASA’s string of successes would have been a string of failures, NASA being a part of the federal government and all.

Were we to conclude that the Department of Health and Human Services should never be entrusted with a large-scale project, we’d at least have a sample size of two on our side. But even then, other than the joy we all experience when we’re able to point our fingers at someone else to say, “Aren’t they just awful?” there’s nothing interesting about a conclusion like this.

It gets interesting when we ask what the difference is between NASA and HHS. There are two. The first is that, following two embarrassing missions to Mars that failed, NASA decided to find out what it was doing wrong, and to fix it. It commissioned an in-depth investigation and took the results seriously.

Following Medicare Plan D and Healthcare.gov, the investigation, if that’s the proper term, came from a Congressional committee. Even if we eschew (gesundheit!) the easy, snide comment, there’s still an obvious contrast to be drawn: NASA’s investigation was led by experts in managing large programs. Congressional investigations are run by elected representatives, whose nearest equivalent of a large program is a re-election campaign.

So that’s the first difference. The second, and more important one, is that NASA is in the big projects business. Big projects … missions … are what NASA does for a living.

HHS is, in contrast, in the operations business, and it’s actually quite good at it. For example, Medicare’s administrative overhead is either one or six percent of total expenditures, depending on whether the metric includes the administrative overhead of the private contractors the Medicare program uses. For comparison, the Affordable Care Act establishes a ceiling of 18% for health insurers, a restriction that created quite a stir in the industry.

The point being that HHS isn’t in the large projects business, so it shouldn’t be all that surprising that it isn’t very good at them.

We can go deeper than that. The leadership, management, and cultural traits that make an organization good at operations are in many respects antithetical to those that make an organization good at project management.

Operations is about keeping things the same. Think of a factory and you get the picture: the job is to do the same thing over and over again, in very much the same way, so as to minimize variation and incremental cost while maximizing throughput.

Operations planning is all about matching capacity and staffing to anticipated demand. It’s a day-to-day thing.

Projects are about making things different. Project planning is all about figuring out what the tasks are to change things or build something new, how they have to be sequenced, who is best equipped to take each one on, and how long they should be expected to take.

Operations tasks, that is, are known because they’re repeated over and over again. Each project task is, in contrast, in some respect unique. They’d better be, because each one would have already been done by someone else. The project should use that result instead of creating an identical copy.

Operations never finishes. No matter what gets done today, we’ll do more of it tomorrow. Projects, by definition, are supposed to end.

I am oversimplifying. NASA is also in the operations business. Otherwise there wouldn’t be anyone around to receive all the data its successful missions keep sending back to Earth.

Interestingly enough, it doesn’t describe things that way. Its operations are considered part of the mission, and while missions may be extended, they’re never considered eternal.

There’s always an end date.

Comments