Death Star Acquisitions Follow-up

I just came across a pair of articles responding to my Death Star article. The first one, by a gentleman named Gulliver, called it "easily the best article I've seen in a defense acqusition trade publication in my entire time following the subject" (acknowledging of course that the bar isn't terribly high in the defense acquisition literature genre).

The other piece, posted by "Bucherm," took issue with my "article" (yes, he put quotes around the word article), and speculated that I must have watched some other movie. This post included the following remarkable sentence: "By any stretch, the second DS program was well run with the end product being a good one."

Clearly, the first writer is  well-groomed, intelligent and thoughtful. The second's parents are obviously unmarried first cousins. I bet he even likes Jar Jar Binks.

I kid! The truth is, I'm tremendously glad to see that people are writing about my piece, whether they agreed with it or not. I can't say I followed Bucherm's logic - in what universe were the Death Star programs (I or II) well run? - but I'm glad he cared enough to write a rebuttal. Now, I thought my article was pretty clear about Vader's psychopathic "leadership" style. But hey, the man is entitled to his opinion, right? If he likes that stuff, I'm sure we can find all sorts of Vaderific bosses to work for. Good luck with that.

As for Gulliver's piece over at Ink Spots, all I can say is wow, thank you for the kind words... and may the Force be with you!

Odd Policy

At the local Best Buy, I came across a sign that explains their We Check ID policy.

I whipped out my handy-dandy, oh-so-fuzzy little camera phone and took this shot. Per usual, it's pretty out of focus and hard to read, but maybe you can figure out why I took this picture. If not, I'll explain.

Basically, the policy says they support the software rating system and require a photo ID for anyone who wants to purchase any software rated NC-17, Mature or R. Also, compressed air.

Huh?

Yup, the policy in checking ID's for software based on the ESRB's ratings includes a reference to "compressed air."

Now, I'm sure there's a dozen good reasons to not sell compressed air to minors. Who knows what sort of mischief a 16 year old could get into with such contraband. But mentioning compressed air in a software ratings policy was so jarringly incongruous that I had to read the policy several times. I've got to wonder why they chose this software rating policy, of all policies, to mention the compressed air thing.

And I've got to wonder whether, when selling compressed air, a clerk will remember to check the software ratings policy and thus learn they're supposed to check ID.

If we want policy to be useful, shouldn't it be internally consistent?

DIY

In a public restroom of some restaurant or other, I came across this sign.

I waited and waited, but no staff showed up to wash my hands for me. Eventually I got tired of waiting and washed my own dang hands.

I don't care what the policy is or what the sign says, it's just one of those things I can do all by my self.

For Me? Thanks!

As I was waiting for the Blue Line train in DC's Metro, I noticed a sign that sort of called my name.

Apparently, the DC Metro's website is MetroForWard.com. I thought that was awfully nice of them to do that just for me.

Thoughts On the Death Star Article

All the attention my Death Star article has received got me thinking. Figured I'd share a few observations:

1) If you want something to go viral, mention Star Wars. I've published 55+ articles and even won an award for one of them. None has ever generated as much buzz & attention as Don't Come To The Dark Side. Now, I wrote this one with the same motivation & method as any other piece. I always hope my articles will be popular and well received, but I don't pick a topic or theme just because I want it to go viral - as if that's within my control. Anyway, I never imagined it'd take off like this.

2) If you every mention Star Wars, do your homework 'cause if you get even a tiny detail wrong, the fanboys will Call. You. Out.

3) Commentators who said the article was "brilliant, hilarious and important" have exquisite taste. Those who said "Ward just doesn't get it" just don't get it.

4) I really wish I'd stuck with my first draft of the metal bikini line ("they look awesome") instead of the blander version I ended up with ("they look cool").

5) Some people think we can't learn real life lessons from fiction. I feel bad for them. Some other people think Star Wars is real. I feel bad for them too.

5.b) Actually, nobody thinks Star Wars is real. But some people take the films seriously enough that other people think they think it's real. It's the "other people" who got it wrong... so I guess I'll feel bad for them too.

6) Nerds are awesome... and they're everywhere.

7) Most commentaries on my article focused on the technology issues in the article. Relatively few cued in on the leadership lessons. But really, the article was about identifying Vader's psychopathic leadership style as much as it was a technical commentary on Death Star Systems Engineering.

8) The article was about Death Stars and droids. People who think it was about aircraft carriers, nuclear weapons or the Joint Strike Fighter are revealing their own opinions of those systems. I'm staying mum on whether any contemporary DoD systems fit the Death Star model. I will acknowledge, however, that the Millennium Falcon is a B-52.

9) Despite #8 above, the article wasn't JUST about Death Stars and droids. It was also about good design approaches and the importance of substance over style when assessing the value of a particular system or technology.

The temptation to write a sequel is strong - and several people have already sent suggestions about what the follow-on article should address. Not sure if I'll do that or not. I actually have two other articles in the pipeline already, and there's a 3-month lag between submitting a piece and seeing it published, so it'll be a little while before anything emerges. But I promise, if I do a sequel, I won't wait 20 years...

Free book!

Since I've got a few new readers on this blog now (hello!), I figured I should mention that I've got a few books you might be interested in. One of 'em is even free.

The free one is called The Simplicity Cycle. It's a design book and I primarily wrote it with engineers in mind. But it's also got more pictures than words, it's a quick read, and I've heard from writers, artists, scientists and business consultants who say it's been useful in their work. And hey, you can't beat the price, right?

The other book that seems to be taking off lately is The Radical Elements of Radical Success. It's a crazy little book that was my attempt to stand the success-lit genre on its head. You can also get it for the Kindle. 

Anyway, happy reading!

Internet Famous

My Death Star article has generated a lot of discussion around the interwebs lately, which is awesomely cool and exciting. It's also pushed some new traffic to my blog, which is also cool and exciting, except for the fact that I sort of haven't been writing here lately. Oops!

Ever since I got word about being deployed, I've been blogging less and doing other stuff more. So it's kind of rotten timing that this article would come out now, when I'm not exactly in a position to continue the discussion the way I'd like to.

Nevertheless, I'm going to try to post stuff here more often. We'll see how that goes. I've got a few posts & topics in mind. Just a matter of finding making the time. Wish me luck!

Brilliant

At a Chick-Fil-A a while back, I came across these little bowls, nestled among the napkins & straws. What a cool idea - free cheerios!

This is one of the most sensitive and insightful things I've ever seen a store do. It costs practically nothing, demonstrates a deep understanding of the customers and shows the type of hospitality that should be the hallmark of any restaurant.

My kids are old enough to eat stuff from the menu, but I can still appreciate the gesture that says "We'd like to make your visit here more pleasant - here's something your little ones will enjoy."

This sort of thing is so easy and so obvious, it makes me wonder why everyone doesn't do it.

Ambiguity

Quick, what does that license plate mean? Is the driver an ornithologist who specializes in birds from the genus Sialia of the thrush family (i.e. a Blue Birder)? Or was I following a medical professional who specializes in liposuction and/or obesity (Blubber Dr)?

Sure, it could be a depressed bird watcher (a blue birder), or maybe they meant "blue" in the sense of risque... kinda hard to tell.

And so today's lesson is: when you're picking a name, a brand identity or a vanity license plate, make sure you pay attention to the ways it can be misread.

No Sale

Check out this photo, which I snapped at the local grocery store using my handy-dandy, oh-so-fuzzy, 1.3 Megapixel camera phone.

In case it's not clear, this is a sign for a "SPECIAL!" sale - regular price is $6.99, now on sale for $6.99. Save 0 cents!

It got me thinking about the mental processes involved in placing this sign. I mean, someone decided to print this tag. Someone (probably a different someone?) put it on the shelf. Presumably the person who put it on the shelf looked at it, to make sure the food item it referred to was indeed on that shelf. And at no point did anyone say "I'm not going to do this because it doesn't make sense."

I bet the person who put up this sign (and a bunch of others) got credit for doing good work after all the signs were up.

If this was just about grocery store signage, it would hardly be worth mentioning. But it's actually a small example of a larger phenomenon. How often do we find ourselves doing stupid things for bad reasons? How often do we not read the signs we post on our metaphorical shelves, or (even worse) read them and put them up anyway.

Want to do something about it? Check out the book Hacking Work for a great tutorial on how to bend & break the stupid rules that try to get you to put up a sign like this.

Shortening The Max

Kickstarter is an online fundraising platform that helps connect small investors with creative types. It's a wonderful way for people to quickly raise small amounts of money to help fund interesting projects... to get a kickstart, if you will.

I mention them because of a recent blog post my friend Kelly sent me. The gist of the post is that Kickstarter has shortened the maximum project length, from 90 days to 60.

Why did they do this? Simple - they found an inverse correlation between project length and project success. In plain English, shorter projects succeeded more often (see graph to left). Longer projects succeeded less often.

In the interest of science, I really appreciated their explanation that longer projects don't necessarily fail because they were longer. Remember, correlation doesn't prove causality. There are no doubt several factors leading to project success, and duration may be one of them. But they were careful to avoid proclaiming they'd discovered a direct cause.

I think the data is pretty interesting, and the correlation is indeed tight. While this doesn't prove a long duration directly reduces the success rate, I think there is wisdom in keeping the schedule short. That's a big part of the FIST approach - good projects have short schedules. Let's take a closer look at the interplay of some of these forces.

Maybe part of the dynamic is that when your schedule is tightly constrained, you're more focused on doing the essentials - the stuff that matters most. Longer timelines increase the temptation to overextend the scope. Longer timelines also expose the project to more changes, which tend to be expensive & complexifying, both factors which tend to go along with reduced success rates.

Bottom line: this is one more data point supporting the idea that short timelines go along with higher success rates. When you're designing your project, whether it's a fundraiser for your new album or a developing a new fighter jet, take a close look at how much time you're planning to spend. My recommendation is to shorten the timeline as much as possible... and then cut it a bit more.

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.

FIST Goes To War

Got word last week that I'm being deployed to Afghanistan for 6 months. Not tomorrow, but soon enough.

I'll be in Kabul. Don't have a lot of other info at this point but I'll be sure to share what I can.

Just wanted you all to know.

(in other news, Germany recently announced they're getting out of the nuclear power business. I guess they're reading RPL over there! Sadly I think the plan is to replace it with coal... but I'm hoping they'll have a go at some more renewables.)

TRIZ 40 Principles

If you're not familiar with Genrich Altshuller's Theory of Inventive Problem Solving (aka TRIZ), today might be a good day to check it out.

TRIZ is a fascinating tool set, designed to help people solve a wide range of problems. Initially focused on technical / hardware type challenges, it has since been expanded to apply to everything from software to services.

Of particular interest is the list of 40 Principles, each of which is a known solution to a particular type of problem. The contradiction matrix (pictured) helps you identify which principle is likely to be helpful & relevant to your situation.

For example, Principle 1 is "Segmentation," which involves dividing an object into independent parts. Examples include modular furniture, personal computers (instead of a mainframe) or a Work Breakdown Structure.

The TRIZ40 website has a great little box with dropdown menus to help you navigate the matrix. For example, you may have a situation where you want to increase the strength of a component without increasing the weight. It will automatically pull up the four Principles that typically help in a situation like that.

Like any tool, mastery of TRIZ takes time and effort. But in my opinion, it's well worth examining.

Acquisition Innovation Wiki

The Citizen Apps website is a very cool initiative that provides a wide range of social media tools for federal agencies to use in their outreach efforts. It provides a framework for blogs, wiki's and discussion forums, to name a few. The intention is to make it easier to engage in discussions with the general public, in true Web 2.0 style.


Accordingly, I'd like to direct your attention to the Acquisition Innovation Wiki. It's an interactive forum where you can discover and contribute content related to innovation, technology development and defense acquisitions.

I hope you'll stop on by and take a look around. Even better, create an account and add some content!

GAO on JSF

Tuesday's post looked at the VA Class subs from the GAO's perspective. Today, let's see what my favorite government accountability office has to say about a different project: the Joint Strike Fighter.

I already mentioned that  the Joint Strike Fighter went into production even though "three critical technologies are not mature, manufacturing processes are not proven and testing is not complete." The GAO report doesn't explain why the JSF pressed ahead into production with an immature, untested set of tech. It didn't explain what sort of pressures drove that decision, but I'm pretty sure it wasn't the result of sound engineering practices.

It's a striking contrast to the VA class sub's decision to rewrite requirements that were "unrealistic and would not be worth the cost to achieve them." Apparently unrealistic, excessively expensive requirements are perfectly acceptable and unchangeable on the JSF.

It reminds me of Kevin Kline's line in French Kiss, where he purposely mistranslates the French airline pilot's intercom announcement for Meg Ryan's character: "The pilot says there is a crack in the engine, but not to worry, we take off anyway."

I gladly concede this is an improvement over previous tech maturity issues, because the GAO points out "the JSF program entered system development in 2001 with none of its eight critical technologies fully mature." And now only three are still immature. So they're making progress. I guess. That's probably why Lockheed is asking to increase the production rate.

Unfortunately, it gets worse. The report says "the JSF is tracking well against its new, less aggressive test schedule despite late deliveries of test aircraft and lower than expected availability rates..." Good to know late deliveries and low availability didn't get in the way of the lowered standards, right? Makes me wonder how much "less aggressive" this new schedule is. And despite this "progress," its combat radius still falls short of the requirement, for reasons "that are not yet fully known."

No word yet on whether the JSF is making progress towards its goal of reducing the cost of each aircraft, or towards it goal of a reduced timeline to build each one.

Oh, right, that's because they don't have goals like that.

Nerd Crush

I admit it, I have a major acquisition nerd crush on the GAO. I don't read every report they put out, but their annual Assessment of Selected Weapon Programs is always a big event for me. It's like the Oscars and the Superbowl all in one, except it's not on TV... and the only uniforms involved are military... and it's not really a competition... and there aren't any commercials.

Anyway, I've also got a cross-service fondness going on for the Virginia Class submarine program. Shhh... don't tell the AF. Now, you may wonder how a guy who advocates the fast, inexpensive, simple, tiny approach could have anything nice to say about something as big, expensive and complex as a nuclear sub? Read on...

The 2011 GAO Assessment report had some fascinating things to say about the VA subs. For example, the Navy "expects to realize its goal of reducing cost to $2.0 billion per ship... and hopes to further decrease the time required to build each ship." Of the 71 other programs assessed in that report, only one or two had bothered to set a goal of a reduced cost or time. Imagine what would happen if this was a standard practice? What if every program got a budget and then was expected to set a cost goal that's below that figure? As in, not only will we not tolerate overruns or late deliveries - we expect early delivery, UNDER budget.

The Navy is showing this can be done... and incidentally they delivered the USS New Hampshire 8 months early, $54M under budget. Nice!

It gets better. The report goes on to say "the Navy has decided not to pursue two planned technology insertions," which is an impressive sign of design restraint and gutsy leadership. Why did they abandon plans, for example, to include a "conformal acoustic velocity sensor wide aperture array"? Because "it would significantly increase, not decrease, life-cycle costs and complicate maintenance." Since this array would have increased costs and complexity, they dropped it.

This isn't just the result of good leadership. It's evidence of a pervasive culture of restraint, one that says overreaching is foolishness and complexity is not the same thing as goodness.

In another case, they "determined the original requirements were unrealistic and would not be worth the cost to achieve them." If only every program would do this sort of assessment. And the funny thing is, there's nothing stopping us from taking this approach all the time.

Lessons From Nuclear Power

The nuclear situation in Japan got me thinking once again about nuclear power... and its implications for engineering design.

I really dislike nuclear power. In fact, I think we shouldn't do it. But usually, when people criticize nuclear power they point to two issues: safety and waste disposal. My objection is related to those topics, but I'd like to describe it in more fundamental terms. I object to nuclear power because it's a critically incomplete idea.

Operating a nuclear power plant generates nuclear waste. However, as I wrote in 2008, we don't have a good plan for how to dispose of nuclear waste (and 3 years later, we still don't). Seriously, we're producing highly toxic waste that's going to be around for thousands of years... and our best plan is to put it in "long term storage." This is as foolish as taking off in an airplane with the expectation that we'll figure out how to land it someday. I suppose that's alright if you're a test pilot, but not so much if you're doing it with a fleet jetliners, each full of passengers, flying over major cities.

You might wonder, "How close are we to having a disposal plan?" Well, Newsweek recently did an article about a nuclear power advocate from France, named Anne Lauvergeon. In the article, she pointed out that "the technology exists to destroy it [nuclear waste] in a laboratory setting—a technology she predicts will jump to real life within 20 years."

Um, really? If the technology we're depending on won't be ready for real world use until 2030, shouldn't that give us pause? Isn't there a chance our prediction of what life will be like in 20 years could -just maybe - be a little bit off? Sure, go ahead and produce 20 years worth of nuclear waste. I'm sure we'll figure out what to do about it someday...

The same thing applies to all sorts of other designs. For example, the latest GAO report on selected weapon systems pointed out that the Joint Strike Fighter went into production even though three critical technologies are not mature, the manufacturing process isn't proven yet and the testing is incomplete. Yeah, you guys go on ahead. Don't worry - the technology, manufacturing and testing crew will just catch up later.

I promise you, that approach is not on anyone's list of Best Practices.

OK, back to nuclear power. What are we doing with all that spent fuel while we're waiting 20 years for the big breakthrough? Mostly, we're keeping it on site, in some cases storing five times more waste than the container was designed to handle. And of course we're continuing to produce even more waste... without a good plan on what to do with it all.

On the question of safety, Ms. Lauvergeon's aforementioned interview listed a series of catastrophic scenarios and explained that thanks to our robust designs, "Whatever happens, you will have no leak in the air or the ground.” This was about a week before the earthquake hit Japan. Oopsie!

Yes, most nuclear power plants operate with perfect safety records. But when one fails, it fails hard. We can't prevent it 100% of the time, and we don't really know how to deal with it when the inevitable failures occur. Just one more example of how this is not a complete idea.

Also, Ms. Lauvergeon should find a new job.

I'm all for exploration and experimentation. I'm a lab guy at heart. But when the objective is to develop an operational system, one that'll be built in large quantities and used in the real world, where failure has serious consequences on a major scale, we must make sure we have a complete idea, to include things like safety & disposal. Until then, it's best to use other solutions that are already proven and complete.

RPL, Year 1

Before Rogue Project Leader was a blog, it was a webzine. Every month, several friends and I would publish a new collection of articles and features. There was even a poetry corner and it wasn't half bad.

By the time it was all over, we'd published nine-and-a-half issues, had a lot of fun and learned a lot about DIY webzines... including how much work they are and how to stop doing one when the time is right.

The original RPL is off line now, but it's not out of reach. Whether you missed it or loved it the first time around, you're invited to get your very own copy of Rogue Project Leader, Year 1 at the Rogue Press shop (dead-tree version or eBook).

Whether you buy a copy or not, I hope you'll at least click over to the preview and read "Call Me Crazy," my first editorial for that very special experiment. And check out my riff on imperfectionism... and Quaid's original vision for Rogue University... and Gabe's piece about being "in orbit"... and, well, just read the whole thing, ok? I think you'll dig it.

Help!

I like love to write. It doesn't matter whether it's fiction or non, serious or funny, books or blogs. I truly enjoy the experience of putting words together in interesting ways... with one exception.

I have a hard time writing about my writing.

Writing the back cover blurb or the description on a webpage leaves me pulling my hair out, surrounded by a pile of crumpled notebook pages. Worse yet is my attempts at writing a query letter, introducing my books to a potential agent or publishing company. Writing 30,000 words on a topic is a piece of cake compared to writing 200 words trying to convince someone that my 30,000 words are worth their time. I guess it's the difference between teaching and selling.

Nevertheless, it's got to be done... and I was wondering if I could get a hand from some of my blog readers.

Here's the deal: I'm trying to rewrite the description of The Simplicity Cycle on my Lulu site and it's kicking my butt. The current description is lame. I was wondering if someone out there might be willing to take a shot at rewriting it.

How would you describe The Simplicity Cycle, in a paragraph or two. Brevity is good. You can leave your ideas in the Comments section or send them via email to The . Dan . Ward (at) gmail (dot) com.

Thanks!

70 > 0

Good morning and welcome to Math With Dan, the fun blog where we learn important math facts.

Today's Important Math Fact is this:

70 > 0

Everyone with me so far? Great! Let's say it together: 70 > 0. Very good!

My 2nd grade daughter just came in and read over my shoulder. She laughed and said "Everybody already knows this!" And then she saw me write about her reaction and it got all meta. So I had to go make pancakes for breakfast.

OK, I'm back. Let's talk for a moment about why is it important to understand that 70 > 0.

You see, a lot of times people talk about delivering "the 70% solution," as if it was some poor alternative to the 100% solution. But that's the wrong comparison. When we take time into account (and we should ALWAYS take time into account), what we're really talking about is delivering a 70% solution now instead of a 0% solution now.

The cool thing about a 70% solution is that it delivers far sooner than the hypothetical 100% solution. So when we compare the two approaches, the 70% solution delivers something within a timeframe where the 100% solution delivers nothing. While the 100% solution is still being designed, the 70% solution can actually be fielded and used.

Just something to keep in mind the next time you hear someone talk about the 70% solution. It may not be 100%, but it's certainly better than nothing.

A Behemoth In A Blizzard Of Cash

The Center For Public Integrity recently posted a great article about the Joint Improvised Explosive Device Defeat Organization (JIEDDO). Well, maybe great is the wrong word to describe a story about how we've failed so miserably. I probably meant to say it's an interesting, insightful story.

Here's a short excerpt from the first part of the article:

The launch of JIEDDO eventually turned what had been a 12-person Army anti-homemade bomb task force into a 1,900 person behemoth with nearly $21 billion to spend.

Yet after five years of work, hundreds of projects, and a blizzard of cash paid to some of America’s biggest defense contractors, JIEDDO has not found a high-tech way to detect or defeat these so-called Improvised Explosive Devices (IEDs) from a safe distance.

What's striking to me is the apparent incredulity over JIEDDO's failure, despite being enormous and having "a blizzard of cash" to spend and despite it's focus on "high tech." And I don't mean the author's surprise - I'm talking about the reaction of government people who can't seem to understand why throwing buckets of money at the problem and building a "behemoth" organization didn't work out.

Um, anyone ever look at any data on successful programs? There's a pretty compelling trail of examples showing that simple, low-cost, rapidly-fielded systems tend to outperform the multi-billion-dollar products that take decades to produce.

My point? Nobody should be surprised when a behemoth in a blizzard of cash fails to show results.

Tips On Giving Presentations

Communication skills are a critical part of a project leader's professional competency. Project leaders who fail to hone their ability to give a compelling briefing or write a cogent paper are dropping the ball on one of their key responsibilities and most important skill sets. A project leader who doesn't communicate well is like a vampire who's afraid of the dark.

Look, everyone doesn't have to be a dazzling speaker or writer, but we all must put forth effort to up our game when it comes to giving presentations and writing papers.

Here are a few thoughts towards that end:

Read Garr Reynolds' book Presentation Zen. And his blog. Then read them again.

If your presentation is dull, you're doing it wrong. And I mean that in both senses of the word wrong (incorrect & immoral) 

To be even clearer: being dull is a sin, a crime, a theft and an assault. Don't waste people's most precious irreplaceable resource - time - with droning messages that don't convey anything useful and that beg to be tuned out. 

Prepare. 'Nuff said. 

PowerPoint isn't the problem. PowerPoint's defaults are the problem. Reject them with great enthusiasm. 

You have my permission to be interesting. You do not have my permission to waste my time. 

 When giving a presentation, don't be the only guy in the room who doesn't know how much time you have left. 

Another Objection

OK, it was so much fun to look at objections to the FIST (Fast, Inexpensive, Simple, Tiny) approach, I figured I'd do it again.

Today's objection sounds something like this: "The FIST approach would never deliver a high-tech, complex, expensive system (like the F-22, for example)."

Um, duh!

At the core of most of these objections is a faulty assumption. One of the most common of these assumptions is that the cost, schedule and complexity of technology (particularly military technology) is inevitably high... and that these are not only inevitable attributes of a system but are also desirable attributes. FIST argues that speed, thrift and simplicity are simultaneously possible and operationally desirable.

Now, if we were to sit down and create an air superiority fighter using the FIST principles, we'd end up with something like the F-16 (or the F-5 or the F-20). It would be a low-cost, simple aircraft, requiring a minimal amount of effort to train, maintain, own and operate. It would do one thing extremely well and we'd have a large enough fleet of them to make a significant difference. It would also leave enough money in the treasury to build a second type of system to handle other missions (say, air-to-ground missions).

So, would the FIST approach deliver a high-tech, high-cost system? Um, no. But then, you really don't want one of those...

Two Objections

It's not often I get push-back when I talk about the FIST (Fast, Inexpensive, Simple, Tiny) approach to developing new systems. Most of the time, people tend to agree that it makes sense, etc. But on the rare occasion a skeptic speaks up, the objections tend to come in one of two flavors:

1) We've already tried this and it didn't work.
2) We've never tried this, so how do you know it would work?

What's even funnier is when both objections come out of the same person. Yes, that happens.

Allow me to briefly address these two objections. On the first objection, I'd like to gently point out that's not a very strong or compelling argument. Past failure does not prove future success is impossible. And for that matter, they're trying to prove a negative by asserting the FIST approach has never worked, often based on a single attempt. And even one successful example is sufficient to counter objection #1 - and I have buckets full. What kills me is when I hear this objection immediately following my 45-minute FIST presentation, which includes a half dozen or so.

Often time, people who use Objection #1 are thinking about NASA's Faster, Better, Cheaper initiative from the 90's. I wrote about that a while back, and Howard McCurdy's Faster Better Cheaper book provides an even more comprehensive assessment, concluding that FBC can be done.

The second objection is based on an erroneous assumption. As I already mentioned, I have dozens of examples of situations and programs where we have indeed used the FIST approach to successfully deliver new capabilities.

Most of the time, I think what people mean by this objection is that the FIST term per se wasn't used by the P development team. That's often true. What I try to explain is that FIST is a term I use to describe a particular pattern of decision making. So when I apply FIST to an old story like the P-51 Mustang, I'm being descriptive and saying that project followed the pattern. I then suggest new projects use FIST, in a prescriptive way, to apply this proven pattern. FIST isn't some new idea - it's a consolidation of rather old practices.

There are other objections of course... maybe I'll take a look at some of those in the future.

Go There

My latest addition to the list of Words And Phrases I Don't Like is "Don't go there."

It joins "There's Nothing We Can Do About It," "For The Record" and the words pamphlet, brochure and utilize in the pantheon of linguistics that seriously rub me the wrong way.

Unlike pamphlet and brochure, which I dislike for purely aesthetic reasons, "don't go there" made the list for reasons of ethics and honesty. People seem to use this phrase when someone is in danger of speaking an uncomfortable truth. It's a shorthand that cuts off conversation in a manner that is borderline dishonest... or even blatantly (albeit subtly) dishonest.

Don't Go There means let's pretend something that is true... isn't actually true. Let's ignore the issue. Let's not deal with the core problem. Let's go somewhere else. It's the verbal equivalent of looking for your lost keys at the street corner, because that's where the street light is, instead of the dimly lit area down the block where you actually lost them.

Look, we can't solve problems by avoiding them. Discouraging people from discussing something because it's uncomfortable or impolitic doesn't really help.  Don't Go There really means "if we don't talk about it, I believe it'll go away." And that's not only a silly belief, it's dangerous.

It's still important to exercise discretion of course, but when it comes to going there, I'm thinking we should...

Bonus Monday Post!

I know, I know, I said I'd post on Tuesdays and Thursdays... but I get impatient sometimes and want to say things ahead of schedule, so once again you get a free Monday Bonus Post - no extra charge!

Several recent conversations and experiences have once again confirmed in my mind the primacy of simplicity as a systems engineering / programmatic / technical / leadership principle (pick your genre). Time and again, complexity eats our lunch, wastes our time and generally makes things stink.

The worst part is, so much of the complexity we face is self-inflicted. No, wait, that's not really the worst part. The really worst pat is that it's deliberately self-inflicted. Not only do we do it to ourselves, we do it to ourselves on purpose. And we think it's a good idea... and then we're confused when the yogurt hits the fan, as Tom Peters says.

See, all too often we equate complexity with sophistication. We think adding more features, parts & functions makes the thing better. We miss out on the opportunity to leave something simple... or to make it simple. All too often, simplicity isn't a goal. We aim for complexity... and we hit it.

So once again, I'd like to invite you, my internets friends, to download your FREE copy of The Simplicity Cycle, over on the Rogue Press. And then pass it around to your internets friends, so they too can read it and ponder the cost and the value of complexity.

Actually, strike that. I've never said this before, but here goes : I'd like you to actually buy a copy. 

Yes, yes, I've always discouraged people from paying money for this book. I give it away free because I want to make the idea as accessible as possible. I've poo-poo'd the idea of buying the dead-tree version. But the truth is, I personally love reading books on paper. And when I get an electronic book, I tend to either not read it or I misplace it, accidentally delete it, etc. With a paper copy, you're more likely to keep it, read it, flip through it again at odd times, or share it with a friend. Thus, my decision to encourage you to pick one up.

I hope you'll pardon this shameless commercial plug. And of course, the free PDF version is still available, if you don't have one yet. But I think it would be really great if you'd pick up a hardcopy of The Simplicity Cycle. Your team will thank you.

Rogue Maturity Model

Although I'm very impressed by some of SEI's recent work (on Agile and Acquisition Archetypes) I'm not a big fan of their Capability Maturity Model Integration (CMMI). Rather than spend a lot of time explaining why, let me simply point out that CMMI is solidly the result of Modernist management thinking. As I explained in an article titled Postmodern Program Management, I lean towards a postmodern point of view.

Accordingly, I've put together the first draft of a Rogue Maturity Model. In keeping with the spirit of RPL, you're all invited to contribute your thoughts and expertise to the RMM. Just click that link and type away!

FIST Handbook Update

I've updated and expanded the FIST Handbook - check it out!

Now, along with links to a bunch of FIST-related articles, there's also a section for media & interviews, data and tools. It's a much more complete reference point than before and I hope it'll be useful to you as you move out on applying FIST in your own projects.

Stop on by & tell your friends!

Reality Is Broken

I love-love-love Jane McGonigal's beautiful new book Reality Is Broken. It's a fascinating blend of psychology, philosophy, history and technology. In large part the book is about what it means to be human - how we learn, how we interact with each other, what we want and need and contribute to the world around us.

Her TED talk is a great introduction to Jane and her ideas. But as with most movies, the book is even better. Here are a few excerpts to get you started:

By removing or limiting the obvious ways of getting to the goal, the rules push players to explore previously uncharted possibility spaces. They unleash creativity and foster strategic thinking.

In a good computer or video game, you're always playing on the very edge of your skill level.

Why do unnecessary obstacles make us happy? (read the book to find the answer)

The opposite of play isn't work. It's depression.

Within the limits of our own endurance, we would rather work hard than be entertained.

The game must be carefully designed so that the only way to be rewarded is to participate in good faith... rather than on providing compensation for doing something that would otherwise feel boring, trivial or pointless.

And yes, I'm totally going to play Top Secret Dance Off. I hope you'll come play too.

POGO Interview

The Program On Government Oversight (POGO) blog posted a sweet interview with yours truly. Bryan Rahija and crew came up with some great questions and I'm really psyched with how it all came together. POGO's Watchdog Fu is the stuff of legend and I'm honored they asked me to share some ideas.

I'll spare you the longish story of the effort involved with getting this thing approved - let me just say I'm glad to see it all paid off.

So - stop on by the POGO blog (they've always got interesting stuff) and maybe even click the Share button to pass the link along to your various internets and friends.

Stuff That Matters

The RPL thought for the day comes from the always brilliant Hugh MacLeod. I couldn't agree with him more.

The idea of doing stuff that matters is something I've been thinking about for a long time. In fact, that's what my first book (The Radical Elements of Radical Success) was all about.

See, it's so easy to get caught up in the tyranny of the urgent. To get distracted by artificial emergencies and to waste time on activities that nobody thought of yesterday and nobody will remember tomorrow. There are plenty of things that can be safely left undone, with little to no impact on anything at all.

Someone recently asked how I find the time to write books and magazine articles, on top of my day job, etc. Part of the answer is that writing is recreational for me. It's something I really enjoy doing (and yes, recreational activities matter!). But another part of the answer is that  writing is important to me. It's how I process my experiences. It helps me understand the world around me and has led to all sorts of new relationships with readers around the world. Writing is something that matters, so I make the time to do it.

How about you? Are you doing stuff that matters?

Change The World

It's amazing to me that some people don't want to change the world, at least in some small way. I'm a rather content guy, but I have a hard time fathoming how a person could look at the world around them and be satisfied with the status quo.

And yet, Hugh MacLeod's commentary is right - not everyone wants to make a big difference. I know some people have a hard enough time just surviving, let alone changing the world. I understand that. What I don't understand is the comfortable & competent people who don't make an effort to improve things.

For those of you who want to change the world, the opportunities are endless. The trick is figuring out how to do it.

Lately I've been told, emphatically and with great conviction, that change only happens when it's led by Top Leaders. As in, people who sit at the peak of the org chart, people with corner offices and multiple stars on their shoulders... or better yet, people who tell people with stars on their shoulders what to do. Those are the only people who can institute big, meaningful change.

Other times I've been told the only real change is grassroots driven, that it's all about Power From The People. You need to harness the power of the masses in order to bring about real change.

I'm not sure either opinion is quite correct. Instead, I think Hugh is right - the key to making change is to want to make change. I'm not sure it matters how much formal authority a person has. Ghandi and Jesus seemed to do just fine. Martin Luther King wasn't exactly a Formal Authority Figure either.

Bottom line: I'm not convinced you and I need to become CEO's or Generals or High Ranking Public Officials if we're going to change the world. I'm not even sure we need to get those people on board with our ideas... for that matter, I'm not sure how much their support really helps. I think the key to changing the world is to want to do it... and as Hugh explained, not everybody does.

Free Books! (and Cheap Ones Too!)

Wanted to invite all the new RPL readers to download their very own free copy of The Simplicity Cycle over at the Rogue Press site. It's a quick read and takes a practical look at ways to deal with complexity in your designs. It applies to everything from building a PPT deck to an organization to a technical architecture. I hope you find it interesting & useful... and you can't beat the price.

If you're so inclined, you can also pick up inexpensive eBook versions of several of my books, either from the Rogue Press site or Amazon's Kindle store. If you want to read before you buy, the Rogue Press site lets you "preview" the entire text of each book.

And for old school readers like me, there's a dead tree version of each one.

Happy reading!

Changing The World

This is a brilliant, beautiful TED talk about how to change the world... by giving a good great presentation.

I learned a lot here. I bet you will too (and thanks to Dan Taylor for the link!).


Nancy Duarte's talk at TEDx East from Duarte Design on Vimeo.

Awesome Packaging

As a father of two daughters, I have had frequent opportunities to spend countless quiet hours straining mightily to open the @#$!@!% packages that encase various dolls and small plastic toys. I'd almost come to the conclusion that the Package Engineering profession is wholly populated with misanthropic sadists who are paid by the hour... and when I say hour I mean the amount of time it takes to open the packaging they design.

However, today's post is not a rant about bad design. Quite the opposite. I am writing to report some good news of great joy. After years of suffering through unending inconveniences and unnecessarily difficulties associated with removing Object A from Package B, I am happy to report the discovery of an example of packaging design so simple, so thoughtful and so right that I almost wept.

The picture below, taken as always by my my handy-dandy, oh-so-out-of-focus little camera phone, shows this magnificent piece of customer-loving art:

In case it's difficult to tell, let me explain. This is a photo of a car charger for a cell phone. It is still in the package... except for the part that isn't. On the right side of the picture, you can see that the business end of the charger is actually sticking out of the package. When it's on display, that particular bit is snapped into a snug little concavity... but this thoughtful design allows potential customers to tug the cord free and actually plug it into their phone to make sure it fits, before actually buying it, bringing it home and opening it!

On the side of the package you can see the obligatory list of all the phone models this charger supports. But if you have your phone with you in the store (and you probably do, right?) you don't have to actually look at the list. You can just plug it in. If it fits, you've found the right charger. Buy it! If not, then keep looking.

This is a great example of literally thinking outside the box. I'm sincerely impressed that someone was able to challenge the unstated assumption that a product has to be inside the package... and in doing so, made life much easier for the consumer.

Now if only they'd do the same thing for Barbie...

Development Principles

OK, I've been poking at the still-sidelined F-22 a bit lately. Let's step back a bit and look at some of the principles involved.

For starters, I very much believe in planning ahead.  I think it's a good idea to start cooking dinner before you get hungry. It's a good idea to save up some money before your car breaks down. And yes, we need to build weapon systems before the conflict arises. As my SOCOM friends often point out, "Competent Special Operations Forces cannot be created after emergencies occur."

I also believe the future is going to be surprising. We don't know what demands will arise, what seemingly eternal threats will go away and what new ones will emerge. We can't anticipate Black Swans. The only thing we can do is maximize our flexibility and our ability to respond to the unexpected. Read Taleb's book for more on that.

I'm also quite convinced we cannot build an effective fighter jet in 20 years, but we can do it in 3-5 years (the same holds true for all sorts of other technology genres). If we spend 20 years building something, we're going to end up with something that's technologically obsolete, operationally irrelevant or both. The  basic principle here is it's important to minimize the time between stating the need and addressing the need. Our 1980's era predictions about the 21st century didn't quite pan out. And our current predictions about what we'll need 10 years from now aren't going to be correct either. There are many reasons I don't think we'll have an air war with China... and one of the reasons is that people keep predicting it as a likely future.

I think we need to take a closer look at the stuff Chuck Spinney wrote, about how less expensive systems tend to outperform more expensive systems, and simpler systems tend to out perform complex systems. I believe thrift and speed are not merely fiscal or political values. They are desirable technical attributes for a system. You want to build a really fantastic capability? Do it quickly & inexpensively (and keep it simple). And please keep in mind that the cost, delay and complexity associated with systems like the Raptor are not inevitable. We could rapidly deliver inexpensive air superiority jets if we wanted to, but only if we try. Speed, thrift and simplicity were never objectives on the Raptor.

So let me be really clear: if we want to ensure air superiority (or any other technical advantage), spending billions and decades is the wrong way to go about it.

Finally, I believe our development efforts should be guided by a prioritized set of requirements (as our Agile development friends do). Deliver the most important capabilities first. Deal with less important capabilities later. So, for example, if you're in the middle of two or three wars where air superiority jets aren't relevant, maybe bump that particular capability to a lower position on the stack.

I'm just sayin'...

FIST on FB

Just another reminder / invitation to become a FIST fan on Facebook & link up with other people who are pursuing the Fast, Inexpensive, Simple, Tiny approach to system development & acquisitions.

How To Fix Acquisitions

When it comes to the defense acquisition process, change seems to be the only constant. In fact, we change things often enough that it's pretty difficult to attribute any improved (or degraded) results to a particular change, because by the time the weapon system is delivered, the policies and procesess have changed a five or six times (or more). Hard to get any correlation going with that much flux.

Of course, if we'd just shorten program timelines we'd be able to finish projects before the process changed excessively and thus could measure the impact of our "improvements," but that's a topic for another day.

Here's the thing - all too often the changes are blatantly superficial and have virtually no impact on the actual management or engineering of weapon systems. It's bananas but it's the sort of behavior the system rewards. Anyway, that observation inspired this sketch, originally intended for the 13 Theta series for Defense AT&L magazine. I figured I'd post it here instead.

For those who aren't familiar with the structure of the defense acquisition process, it involves moving through a series of milestones. In 1996, we used Milestones O, I, II and III. In 2000 it changed to Milestones A, B and C. And now here's the gag:

What would I recommend doing instead? Focus on honing decision-making skills and using the FIST approach to rapidly deliver affordable systems.

Spoke Too Soon?

In an earlier post, I mentioned a report that the F-22 Raptor might finally see some action over Libya, after watching Iraq and Afghanistan from the sidelines for five years. Alas, according to the Air Force Times, that seems to not be the case.

One might wonder why we wouldn't use "the most capable air superiority fighter" to accomplish a mission or two over Libya. Say, accompanying B-2's on their bombing runs... which is one of the things the F-22 is supposed to do, right?

Well, the article points to the fact that it can't communicate well with other aircraft as a big reason for not using it. Also, that it can't actually hit ground targets very well. So the Libyan Air Force's strategy of staying on the ground looks like a pretty effective counter-measure against the Raptor.

Other than its inability to communicate with the good guys or to make the bad guys go boom, it's a fine, fine aircraft. Technically, the only thing wrong with it is that it apparently doesn't support any of our actual mission needs.

Now, I'm not an operations guy. I'm not even an airplane guy. I really don't know much about what sort of capabilities this country requires when it comes to jet fighters. But I am an acquisitions guy and a techie. And I know the objective of acquisitions & system development is to deliver affordable systems that support mission needs. From where I sit, it seems like we've spent a whole lot of time & money developing a system that doesn't contribute to any of the various fights we're currently engaged in. Where I come from, that doesn't count as success.

Might the Raptor contribute to some future mission? Of course. And I can't say for sure that these hypothetical future scenarios aren't actually right around the corner. All I know is that given current operational and fiscal realities, the Raptor looks like a strange investment. I might even say an unfortunate investment. This isn't hindsight - I've been saying this sort of thing for a pretty long time now. Frankly, even if we start using it 10 years from now, I'm not sure that would quite make up for the long trail of non-contributions.

Is there a lesson to learn here? Maybe something about the wisdom of shortening our development timelines, using the budget to constrain the design and focusing our requirements on a prioritized set of real-world needs. The opposite of the FIST approach - spending decades and billions to develop a multi-role system that doesn't support any of the three major operations we're currently performing - leads to situations like the Raptor.

Someone once told me that the FIST approach would never have produced a weapon system like the F-22. My answer to that: precisely!

Ask Your Question

Here's a special, exclusive offer just for you, the RogueProjectLeader Reader:

You are personally invited to send me your questions about innovation, technology development, the FIST (Fast, Inexpensive, Simple, Tiny) method, or anything else you may want to ask about.

I'll make up some weird answer and post the whole shebang right here, on RPL!

Submit you question in the Comments section, or drop me an email to my gmail account (The.Dan.Ward).

Leadership

I keep coming back to my post titled The Effectiveness Of Signs. It's one of my favorite posts on this blog. I like the way it blends design principles with an important aspect of leadership - namely, doing stuff.

Now, the topic of Leadership-with-a-capital-L generally turns me off (I blame John Maxwell's horrible books for that - and no I'm not linking to them). But this blog is titled Rogue Project Leader, so I guess I'm not completely against the topic.

Anyway, several years ago I sat in the office of a very high ranking person. In the course of our conversation, he expressed his frustration over his inability to get the people who ostensibly worked for him to do what he asked them to do. I was part of a small  bureaucratic spetsnaz team that he had put together for the purpose of undermining the Defenders Of The Status Quo who were ignoring his direction. That conversation, and his frustration, have haunted the back of my mind ever since.

Now, with the perspective of some years, I wonder if maybe he was a bit like the sign maker in my earlier post. His sign was clear and unambiguous... but still the trashcan was not where it was "supposed to be." It's not a perfect analogy - I'm not saying he posted his sign behind the door or was asking anyone to put the trashcan in an inconvenient place. But clearly there were divergent priorities and interests. And just like with the trashcan story, the power lay in the person who actually moved the can.

F-22 in Libya?

It looks like the F-22 might finally fly its first combat mission, in support of the Libyan No Fly Zone.

The Raptor was declared operational in Dec 2005, but so far it hasn't flown any combat missions. There's talk now about possibly using it to take down radar sites in Libya... that is, if there are any radar sites left after the US Navy's bombardment with their Tomahawk missiles. Also, the French, British and Canadian Air Forces already have fighters in the air over Libya, so if the Raptor is going to see any action it's going to have to move quickly.

One might wonder whether the F-22 is really the best platform for doing this kind of work, or if perhaps Tomahawks and Rafales are sufficient.

On a completely unrelated note, check out Krog's New Weapon, a sci-fi story I published in Defense AT&L magazine in March, 2008. Why? Oh, no reason...