You MUST!

I came across this old beat up sign on a street corner in DC and had to take a photo with my handy-dandy, fuzzy little camera phone. The sign informs pedestrians that they must ("MUST") push a button to call for the walk signal.

Only problem: no button.

The button isn't broken or non-responsive. It's completely non-present. As in, someone removed it. Probably someone with tools and permission. For some inexplicable reason, however, this tool-and-permission-equipped individual... left the sign (which has clearly seen better days).

Obviously this isn't a  huge deal. The walk signal did indeed show up, even though I didn't press the (non-existent) button, which means not only did someone remove the button, but they reprogrammed the lights. And then left the sign in place. The whole scenario struck me as a handy metaphor for corporate culture, rules and status quo thinking.

How often do we encounter a rusted out, irrelevant piece of guidance, insisting that we must (MUST!) perform some set of actions for which there is no longer a mechanism, a set of actions that once upon a time was relevant and productive but which now a) cannot be performed and b) wouldn't make a difference anyway?

When you encounter such a situation, how do you react? Pantomime the behavior, going through the motions out of obedience and compliance? Run to the nearest Radio Shack to buy a replacement button and install it near the sign? Ignore the sign?

Or do we have the guts to take the sign down?

(I'm thinking I want to go back there with a sticker or some paint or something, to change that sign)

Priorities

Finding out you're going to get deployed does marvelous things to your priorities. Specifically, it clarifies them brilliantly.

I find I've become much more deliberate with my time, now that I suddenly have less of it.There are only a few months left before I head to Kabul and I want to make the most of my time before I go.

For years I've been saying that constraints foster creativity. Now I'm also learning that constraints bring clarity. See, when your time is constrained, you're forced to focus on doing the most important things. And while I'm not crazy about the idea of spending 6 months in Afghanistan, I have to admit there's something cool about a deployment deadline. Everything is more intense & more focused.

The same things happens to a program - when you don't have a lot of time, you focus on doing the essential stuff. One of the best things a project leader can do is set a tight schedule... and stick to it.

For me personally, I expect my blogging schedule is going to change (actually, it already has). I'm not going to stop - but I'm also not going to post as often. I've got other things I need to focus on between now and November. I hope you'll hang in there with me and I appreciate your patience as I direct my energies towards getting ready to go to Kabul.

Self-Inflicted Complexity

One of the major themes of my work is that military technology projects (and tech projects in general) don't have to take so long, cost so much or be so complicated. That is, the cost, delay and complexity we typically encounter on these projects is not inevitable.


So when someone tells me the FIST approach is fine if we want to build a simple system but that it doesn't work if we want to build a complex system, I go into Alice mode from Dilbert (Must... control... FIST... of... Death!).

The word choice is particularly revealing: "when we want to build..." All too often, people view high levels of complexity as not only inevitable but also desirable. The truth is, it's neither.

Yes, there's a certain amount of inevitable complexity for any given system, particularly now that all our systems are supposed to integrate with all other systems. Any system that doesn't play well with others (I'm looking at you, F-22 Raptor) is going to lose points. The trick is to avoid excessive, unnecessary complexity... and that starts by understanding that complexity and goodness are not always directly proportional.

So, when I talk about being rapid, thrifty and simple, it's important to keep context in mind. A 5-year timeline may be blindingly fast, for certain types of technology. A simple nuclear submarine may still be hugely complex, in absolute terms... while also being simple compared to the alternatives.

We just need to understand that extreme complexity is not intrinsically desirable, nor is it inevitable. We always have opportunities to simplify in ways that improve performance, reduce cost, increase reliability, etc. But we'll never find them if we don't look for them in the first place.

Impossible / Impressive

Why doesn't the USAF have a requirement for an invisible jet like the one Wonder Woman flies? Nevermind that any pilot sitting inside the invisible jet was completely visible, it's still an awesome piece of tech, right? It's way beyond stealth - I mean, it's completely transparent!

Well, let me answer my own question. The reason we don't have a requirement for an invisible jet is that such a thing is considerably beyond our technical capabilities. We might almost call it impossible, although I hesitate to use that word. And the thing is, we can't require the impossible.

It's important to include reality in our requirements, and to ensure our requirements are reallistic. Doesn't that go without saying? Sadly, it doesn't.

This doesn't mean we have to aim low. Just because we can't require the impossible doesn't mean we shouldn't require the impressive. But the distinction between impossible and impressive is an important one to consider.

What Is Better?

I am increasingly convinced that one of the main sources of the troubles in the program management arena is bad definitions of goodness.

That's not to downplay the impact of weak relationships, poor communications, and distrust. Those are biggies, to be sure. But it seems to me that the way we define the goal has a big impact on our decision making and our eventual outcomes.

See, even with great trust and communication, if we head in the wrong direction we're going to end up in the wrong place. If we think adding a hundred new features, extending the schedule by 10 years and increasing the budget by billions is going to make the product better, um, we're going to end up with stuff that's bloated, broken, operationally irrelevant and technically obsolete. 

That's why the focus of FIST is on the program's values - the statements of preference and priority, the definitions of goodness which define our objectives. FIST says it's important and good to be fast, inexpensive, simple and tiny. And there's a lot of data that suggests simple, low-cost systems out perform complex, high-cost systems. When you're aiming for a quick, inexpensive solution, you're more likely to build good relationships, communication, etc, because such solutions are more human-scale. You're more connected & invested in them than if you were on a thousand-person team half-way through a 20-year project.

But when we think it's important and good to spend a lot of time and money, developing a hugely complex system, we're going to end up going in the wrong direction. Trust and good communication are important, but they might not help with that sort of problem.

Needs versus Wants

What do we really need systems to do? Is it enough to be good enough, or must each new product be perfect? Is a partial solution acceptable, or should users hold out until they can get everything they want?

I've already posted about the superiority of 70 over 0 (and argued that the 70% solution isn't really an alternative to a 100% solution... it's an alternative to a 0% solution)

In early March, I came across a great quote from SECAF Donley, in which he talked about the importance of intellectual honesty about what we actually need versus what we want. I think that's pretty important. See, it's not just about accepting a 70% solution. It's about how we define the 100% solution in the first place.

This isn't up to the engineers and technologists, although we have a role. It's ultimately the user's responsibility. But it's not something they can or should do in a vacuum. It's something the whole team should work on together, and decisions should be based on a deep understanding of the operational environment, combined with a deep understanding of the technical options. This juxtaposition of operational and technical insight is all too rare, but it's also within the reach of anyone who owns a phone and can set up a meeting or two.

As with most things, it's not terribly hard. It's also not terribly easy. It just needs a little nudge, a little effort, to move the default behavior in the direction of collaboration and conversation.