Boyd on CyberWar

The hacking (cracking) attack on Google et al has caused a phenomenon that actually puts those companies and even countries at risk. Over the last year, the response by companies and countries to these cracking episodes has been to lock down their intranet/internet systems, filtering content and making access more restrictive. As an example, the Air Force Material Command, even after relenting on bans with certain types of social media, still enacts a robust filtering policy that continues to restrict blogs, wikis, and the like. Australia is even considering filtering incoming internet traffic echoing China and other totalitarian countries.

The giant risk of this fortress mentality is that it actually makes the organization less secure because it makes the organization less nimble. By enacting more security, an organization inevitably enacts more bureaucracy which creates friction and slows reaction ability to a grinding halt. This phenomenon is captured well in the Starfish and the Spider (I synopsize it here) and was a central tenet in John Boyd’s discussions on how armies win wars. I propose that rather than locking down access to the internet, organizations relinquish control and let employees, partners, and other supporter’s route crackers and malcontents via an organic set of decentralized tactics (this may already be taking place). Twitter is indeed mission critical. In cyber operations, observing, orienting, and acting faster than the adversary is the only way win.

What Is Good?

Apparently my theme this week has something to do with measuring progress (I didn't plan to have a theme - it just sorta happened). While previous posts have mostly focused on the measurement part, let's take a look at the "progress" part today.

Specifically, I'd like to talk about priorities and values. What attributes do we consider desirable for our projects? What are our measures of merit? What indicators give us reassurance that we've got a good program?

Regular readers of this blog know I think it's "important and good" for a program to be Fast, Inexpensive, Simple and Tiny. I apply these values to every part of the program, from the requirements documents and system architectures to the organizational structure and operational processes. My research indicates that the FIST values not only support programmatic success (i.e. delivering on time), but also operational success (i.e. performing well in the field).

The funny thing about values is they are often assumed, not discussed. I seldom see explicit statements about a project's values, but there are plenty of indicators that show what the project leaders really think are important.

Look at any number of recently cancelled projects, and I think you'll find that nobody thought it was particularly important for the thing to be developed quickly or inexpensively, or for it to be simple. Rather, complexity is often treated as a sign of sophistication. Big budgets are a sign that the system is important. Take a long time to build it? Great! That means you're clearly doing a good job and exercising due diligence.

Here's the thing: when we aren't deliberate with our values, when we don't examine and discuss them, we run the risk of being guided by values that are counterproductive and ineffective. I'm not saying that FIST is the only value set that works - I'm just saying we should be purposeful with our values, and should be aware of the way they shape our decisions and behavior.

Faster, Better, Cheaper?

I've been doing some research into NASA's Faster, Better, Cheaper initiate from the 1990's. It's quite a story, and I must admit I'm stumped as to why FBC got scrubbed.

The results of the FBC missions were fantastic. For less than the price of the Cassini mission, NASA launched 16 mission, including the Pathfinder mission to Mars and the Near Earth Asteroid Rendezvous (NEAR), which no kidding, landed on an asteroid, after collecting 10 times more data than they'd expected. Of those 16 mission, only 10 succeeded, but that's still 10 successful missions for less than the price of a single planetary mission using the "traditional" Slower, Suckier, More Expensive approach (excuse me - I mean, the deliberate, modernist, Scientific Management approach, which never ever fails ever).

The crazy thing is, many people treat FBC as if it was not only a failure, but an embarrassing failure. As if NASA should have known better than to try something so absurd as reducing costs and delays in their pursuit of knowledge and adventure in space. As if 10 successes for the price of 1 is an inadequate track record. As if the data clearly shows we must "pick two," instead of pursuing simultaneous improvements in all three dimensions. I don't get it.

OK, I'm not really stumped. I have my theories about why the approach was rejected. But it's becoming increasingly clear that the rejection and ridicule of the FBC approach has nothing to do with the initiative's actual results, which were admirable and impressive.

How about you? What do you think when you hear the phrase "faster, better, cheaper"?

People & Process

I recently came across this quote by Fujio Cho, Chairman of Toyota Motors:

“We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems.”

Yikes! Anyone else find that somewhat disturbing? I mean, I've known for a long time that the process gurus really believe a good process is a substitute for good employees, and that process can replace talent and ingenuity. But it's not often the process people get so explicit about it.

Interestingly, Dilbert's pointy haired boss made this exact point on Sunday, saying "As you know, a good process is a substitute for good employees." That line made me laugh out loud - because it's one of those truths that isn't usually stated so explicitly. And I think Adams intended that line to be funny - surely, no boss would make a statement like that to his employees. But there we have Chairman Cho basically saying the same thing.

Now, there's probably a cultural element here. Everyone in America thinks they're above average, and to be described as "average" is an insult around here. That may not be the case in Japan.

But cultural differences aside, I'm not sure it's true that process trumps talent. In fact, I think it's the opposite. Talented people can overcome bad processes. Good processes can't overcome a lack of talent, motivation, initiative, etc. But maybe that's just because my perspective is based in an R&D environment, rather than manufacturing.

So, what do you think about the Chairman's statement? Would love to get your two cents...

Values

I haven't talked about the topic of values in a while, and after some lively discussions with B. Smitty, I figured I'd spend a little time on the topic again, because assumptions about values are at the heart of most of the problems in project leadership (and a lot of the disagreements too).

The values I have in mind are "the things we think are important." In engineering speak, values are measures of merit. They are the signs of sophistication and other desirable attributes (and the context I have in mind is organizations, technologies and processes). This stuff matters because our values shape our objectives, and at the end of the day, values are the yardstick we use to assess whether good things have happened or not.

In my FIST-related writings, I talk about values as the answer to the question "What is important and good?" and I often describe FIST as a values-based approach. It basically says "It is important and good to be Fast, Inexpensive, Simple and Tiny." There are other value sets out there, and mostly they go unstated, unexamined, unconsidered and untested. That's a HUGE problem.

See, if we value complexity (either explicitly or unconsciously), we'll make the system more complicated and think we've done something good - even if it's not actually any better. You see this a lot in PowerPoint presentations - people who think they are effective communicators because they included every word, every comma, every data point and every possible nuance of every diagram in their 800-chart presentation (for their 15 minute time slot). You also see this in over-engineered systems, chock-full of a million good ideas. I'm going to suggest these are examples of values out of whack. Overvaluing complexity drives unproductive behavior.

Similarly, if we think spending a lot of money guarantees quality, we'll feel reassured by a high price tag, even if a smaller price might have delivered better results, better quality. Same thing with time - if we value the slow-and-steady approach, the fact that it took 20 years to deliver a system gives us a warm feeling, even if such expenditures were unnecessary.

So, the questions are: what values drive your project? What values contribute to positive outcomes, and improved operational effectiveness? And to come full circle to the afore-mentioned discussion, when people praise the F-22 as "the most capable aircraft" in our inventory, what are they really praising? What values are driving that assessment? What basis is there for those values?

Frankly, this question doesn't come up often enough in program management circles, which is a bummer because I think it's at the core of the whole discipline.

Catching Up With BRITE

One of the first projects I really had an impact on was a little imagery dissemination project for the National Geospatial-Intelligence Agency called BRITE (originally Broadcast-Request Imagery Technology Experiment... I think they changed the E to something else later). It was a small system designed to provide overhead imagery to forward deployed SpecOps guys who had very limited bandwidth and were highly mobile.

The BRITE project was one of the keys to developing my FIST approach to technology development. We had a very small team - in fact, I was the only government guy working on the project (and I was a junior Captain). On the contractor side, we just had a handful of people, and most of them were only assigned to the project part time, as I recall. The budget was quite small, the deployment schedule was short (this was 2001 - 2002). The system was designed to operate in austere conditions and it worked like magic.

That experience had an enormous impact on my thinking and my perspective on what can be done with small teams of talented people, working on tight budgets and tight schedules. It also hammered home the importance of simplicity - organizationally, technically and procedurally.

So, just for fun I googled it and came up with a great story about using BRITE to support the Hurricane Katrina disaster relief effort. It's nice to see that my little project still had legs after I'd moved on to other things.

The Realm of the Possible

In a recent discussion about improving defense acquisitions, someone suggesting things would be better if we could get rid of Congress. Everyone laughed at this humerous suggestion, and one particularly literal-minded person said "Oh, that's too big of a change, it can't be done, let's move on..."

Well, hold on.

Maybe there's a way to "eliminate" Congress from the project without disbanding one third of our constitutionally-established government.

See, the problem isn't Congress' existence. The problem is that sometimes Congress provides, as Shrek so delightfully put it, "the opposite of help." So, what if we could minimize this anti-help?

It turns out, we can. The FIST (Fast, Inexpensive, Simple, Tiny) approach does exactly that.

A FISTy project has a small budget, which attracts less interest and oversight from our congressional leadership. A short schedule provides fewer chronological opportunitites for, let's call it involvement (instead of meddling). A small team and simple organization doesn't get spread across multiple congressional districts and states, and voila, that means fewer legislators with a dog in the fight.

These decreases are all appropriate and above-board. It's not a matter of shutting Congress out, but rather of keeping the project sufficiently small that it doesn't require their, ahem, help.

Process Application

Most of the process advocates I've met recently have come from background like manufacturing and logistics. That makes a lot of sense - these are well-bounded, repeatable, concretely-defined disciplines. The problem is when we try to cut and paste successful manufacturing or logistics approaches onto other areas, like research & development or program management.

R&D is typically - and appropriately - an unbounded, unique, loosely-defined activity. That doesn't mean there are zero processes involved... just that the most significant parts of R&D are beyond the realm of process.

So, when I say that I'm a critic of the process-centric approach, what I'm really objecting to is the misapplication and the overapplication of these approaches.

I also want to point out that I'm not a skeptic of the utility of process-centric approaches in R&D and program management. I'm emphatically a critic. The term skeptic sounds like a person is unsure whether a thing will work or not. Not me - I'm not agnostic about this stuff. I've done my research, taken the classes, got the t-shirt, and came to a conclusion. I'm well beyond skepticism.

Presentation Skills Are Critical

The ability to stand up in front of a group of people and communicate effectively is a critical professional skill for program managers and other project leaders. It's particularly necessary for military engineers, defense contractors, and leaders in general. I can't say strongly enough how important this is as a matter of professional competence.

For better or worse, PowerPoint is the tool of choice for making presentations. When anyone gives a presentation with dense, complicated, unreadable, illegible and otherwise horrible-horrible-horrible presentation charts, they are demonstrating sheer professional incompetence.

In case you can't tell, I get kinda worked up about this.

For all the time we spend giving and receiving briefings, it's inconceivable to me that honing one's presentation technique is not treated as an important discipline and a core element of professional development. I've even seen professional educators, who brag about their ability to facilitate discussions and interact with audiences, use powerpoint charts that are frankly embarrassingly bad.

This stuff isn't hard. Sure, it's a little bit more work than doing it badly, but once you get the hang of it, it's not bad. Go check out Garr Reynold's Presentation Zen blog for some great examples of how to do it right.

Change

I like to say that FIST isn't a new way to do acquisitions. It's just how we do acquisitions when we do it well.

But frankly, I'm not convinced my current attempt to drive FISTy change into the system is going to succeed. I am very aware that the probability of success is low. Five or ten years from now, there's a pretty good chance the defense acquisition community is going to look very much like it does right now.

Having said that, the environment does seem more change-friendly than it ever has before. Our experiences in Iraq and Afghanistan are a big part of that, along with the new administration, changes in the economy and advances in technology - particularly UAV's. This combination of operational, political, economic and technical factors is sort of a perfect storm and gives me hope that significant, meaningful change is possible. If the FIST approach ever had a chance at widespread adoption, it's in the current climate.

Our troops overseas are increasingly emphasizing the importance of rapid access to systems that are simple and effective. They have less tolerance for the complexity and delays of previous years. The president ran on a platform of change, and military leaders from the SECDEF on down are reimagining the way we do business. The economy is forcing people to think really hard before spending money. And along come these UAV's, which offer relatively inexpensive and simple ways to accomplish missions that used to require much more time, money and effort.

So will FIST take off? I don't know. I certainly hope so. All I know is that I've got to try to make a difference, even if the odds are against me, 'cause these are the best odds I'm ever likely to see.

Rogue Netflix!

My brother sent me this link to a Guide to Netflix Culture & Values a while ago, and I'm just now getting around to posting something about it. It's pretty remarkable (get it, re-Mark-able, and it's from my brother Mark, and I'm re-posting it... sorry!)

Anyway, I love this. My favorite bit was the chart about Communication. When they talk about valuing people's communication skills, what's the first line on the chart? "You listen well."

Holy cow, that's fantastic. Good communication skills start with good listening skills. Um, heck yeah.

We hereby award Netflix the Good Rogue-keeping Seal of Approval!

FIST Video!

Yesterday's post was the short version of the FIST (Fast, Inexpensive, Simple, Tiny) approach to system development.

Today, I've got a short post with a link to a long video. Yes, this is the much anticipated Rogue-a-palooza aka Rogue Fest 2009 aka the briefing that Gabe and I did at the Defense Acquisition University back in July.

I confess I haven't actually watched the whole thing yet, but my mom and dad did and they said I did real good. They also said the video includes the Q&A at the end of the presentaiton - I wasn't sure if that part would be included, but it was. That's cool.

So, if you've got an hour or so to kill, and you want to see me and Gabe jump around like monkeys and tell stories about why FIST is so good, click the link.

CogBlog Homerun

Check out this (rather lengthy) post over at the CogBlog. It's an insightful look at the saying-doing gap in defense acquisitions, primarily focused on the IT side of things. A few nuggets to whet your appetite:

DoD acquisition regulations do not actually mandate stupidity … they just encourage it.

...the Joint Capability Integration Development System, or “JCIDS“, mandates a change from “system-based” to “capability-based” requirements... However formal OPTEST evaluates systems, not enterprise capability.

What is the gap between the capability provided by Travelocity vs. Defense Travel System? [Dan here - holy cow DTS is a pain to use!]

We need pre-approved catalog offerings available on GSA schedules and IDIQ vehicles. We need “dating services” to put consumers with like requirements in touch with each other and expert providers. We need “consumer reports”... to provide basis of objective, convenient comparison.

Team Rogue in the Danger Room

For those who haven't heard yet, Wired magazine's Danger Room blog did a very nice post about Team Rogue and our FIST approach to acquisitions.

They even sort of made it sound like the SECDEF is an advocate of the FIST approach. OK, it didn't sort of sound like that... it totally sounded like that. What else does the phrase "high level advocate" mean?

Anyway, it's fun to see our ideas getting this kind of visibility.

Courage!

Hey true believers!

The latest action-packed issue of Defense AT&L is posted online - click on over to read my contribution, The Courage Imperative.

I have to admit, I'm a little nervous to see what sort of reaction this one generates. It's a bit, um, pointed... (yeah, unlike all my others, right?)

A-Team versus MacGyver

Borrowing a theme from Bas de Baar's blog, let's talk about the A-Team and MacGyver.

Both shows were the awesomest shows ever. And please, let's not reignite the ugly A-Mac flamewars from the early 90's. As I said, I think we can all agree both shows were the awesomest. Please, put away your Swiss Army Knives and/or pickup truck with sheets of metal welded onto it.

Instead, the question I'd like to pose is, which show is a better model for project leadership?

No, we're not going to debate the relative merits of swiss army knives versus vehicles with sheetmetal welded onto them. Instead, let's talk about the underlying problem solving approach the two shows used. These approaches can be described as "I love it when a plan comes together" (A-Team) and "I'll figure it out when I get there." (MacGuyver).

Both shows involved resourcefulness. And let me say it again, both were equally awesome. But one clearly relied on planning before execution, while the other was more focused on improvization during execution.

Given the technological, social and economic environment we find ourselves in these days, I'm going to say MacGuyver's approach is probably the most productive model to follow. And I just know Mr. T is going to call me a fool for saying that...

Are You Happy?

I first met Mr. Terry Little several years ago, when he was director of the Air Force's Acquisition Center of Excellence (ACE). He is a legendary project leader, an original Rogue, and a man who not only has an impressive track record, but is also a genuinely warm human being. His smile is kind - almost shy - and he is what I'd call "an insightful listener." I wouldn't mind at all being like Mr. Little when I grow up.

A few weeks ago, I ran into him again. We chatted a little about things (he's retired now), and as I told him about my job, he asked "Are you happy?"

Whoa.

There was something in the way he said it that was completely unobtrusive and yet firm. He wasn't just being polite - he sincerely wanted to know, he sincerely cared, even though it had been years since we'd seen each other. It was clear that this was a priority for him, but not in a checklist sort of way. More like a lifestyle kind of way.

It was a question he wanted an answer to, but it also felt a bit like a challenge, in the best possible sense of that word. There was a subtle, affectionate insistence, somehow, that I should make sure I'm doing things that make me happy. He wasn't challenging me to give a specific answer. He was challenging me to make sure I'm on the right path, for the long haul. When he asked, it felt a little bit like someone had hit a tuning fork at just the right frequency, and the question vibrated through my brain.

Yes, I said, I'm happy. I've got a good job, with a good mission and a good team. I've got a real opportunity to make a difference, and I'm having fun doing it. The house and the neighborhood we're in are very nice. The family's doing well. And I've just been taught a lesson at the foot of a Master... a lesson in humanity, leadership and, well, humanity.

I don't know how long it will take me to learn to ask questions the way Mr. Little does. I suspect it'll take a while. It's been several weeks, and I can still see that scene in my head. I can still hear the question. Here, let me try asking you: Are you happy?

Best Practices - NOT

At the Social Media conference last week, several people mentioned they were looking for "best practices." These were inevitably the same people who also insisted on the importance of "thinking strategically" when it comes to social media.

It seems to me that both sentiments have the same root. Namely, both are expressions of a modernist worldview, in which rationality can supply all our needs and activities can be optimized. I'm just not sure this worldview stands up to reality. It makes sense logically, but experience tends to disprove it. When that happens, we can't blame the world for not living up to our theory (but Strategic Best Practice advocates often seem primed to do just that).

Best practices are someone else's best practices. We should use them for illumination, not imitation. We should reflect on them, not just copy them. And strategic thinking is all fine and good if we mean intentional, thoughtful consideration of our eventual objectives... but not if it means locking down those objectives before we even begin.

Thought of the Day

A failure to tailor the process is a failure to execute the process.