Coming soon!

Yup, I'm making progress.

A fresh batch of RPL shenanigans is lined up and ready to go. The fun begins again on 3 Jan!

Under Construction

Watch this space - fresh posts coming in the new year!

Upcoming talk

I've been asked to put together a talk based on an article I wrote a while back (Acquisition As Deterrent) - and frankly I'm a bit stumped on how to do it.

The conference coordinators also said I could basically talk about whatever I want... but they'd really like me to do it based on that bit of nightmare fiction I wrote.

So I need to decide - do I do my usual FIST presentation, which I'm constantly updating to keep it fresh, but still, it's the safe presentation... or do I knuckle down and come up with a presentation based on that article... or do I come up with something entirely different?

Watch this space for updates...

New FIST Comic

For those who haven't already heard, the latest issue of Defense AT&L is now available - online and in a mailbox near you (also often found in HQ waiting rooms & base libraries... so, yeah, mostly online).

In this, the July/Aug 2010 issue, we've got our third installment of the FIST Superhero Comic, in which our heroes go after a baddie called The Incredible Inevitable.

So here's my question - did you know that already, either via my facebook post, my direct email or your own access to the magazine? Anyone finding out about new AT&L developments for the first time via this blog?

I'm asking 'cause the value of blogs seems to be decreasing in some circles. I've seen a few friends stop blogging altogether. I've personally taken to reading fewer blogs than I used to. And even this one has scaled back to a weekly post instead of daily.

I still like writing it... but with other social media outlets & opportunities, perhaps my time & energy should go elsewhere.

Book Update

Just a quick update on the latest book news from Rogue Press. I've been playing around with Amazon's new Digital Text Platform, which gives self-published authors like yours truly the ability to quickly & easily publish eBooks for the Kindle.

There's a lot to like about DTP - it's quick, easy & free, for starters. The author has full control over the price, and the royalty structure is a generous 70% for the author. Now, Amazon only sends royalty payments 60 days after the end of the month in which sales occur (as opposed to Lulu, which pays royalties monthly), but that's still faster & more frequent than traditional publishers. And I'm not really doing this 'cause it makes any money anyway - it's mostly 'cause it's fun.

So, if you're so inclined, you can pick up The Radical Elements of Radical Success (Not a Major Motion Picutre), Skyler and the Shadows on the Sun and The Boomer Sisters Meet Champy. Each book is just $2.99, delivered virtually instantaneously through the magic of the interweb. I'll probably add a few more titles in coming days.

Happy reading!

Lean lessons

I've long been a critic of things like six-sigma, business process reengineering and lean. My critiques have ranged from how easy it is to misapply these approaches, flaws in the underlying assumptions & theories, and the well documented lack of results (or the lack of well-documented results). I always tried to be careful not to say these approaches are worthless or never work... just that they're largely oversold, overapplied and overstated.

As previously mentioned, I recently had a chance to attend an in depth 2-week class on Lean (and that other stuff too). I really enjoyed the class and have been pondering the lessons ever since. Here are a few observations:

Business efficiencies allow us to do what we were hired to do in the first place (i.e. be awesome) and not get distracted & dragged down by low-value activities. In a non-efficient place (i.e. just about everywhere) not much happens on any given day even though everyone's busy.

Doing things the right way should be easier than doing them the wrong way.

This stuff has to be strategic if it's going to work. If we get distracted by questions of how many printers to have and where to put them, we might overlook the fundamental question - whether we really need to print things in the first place.

Even when this stuff is taught well, it's still frighteningly easy for a group to wind up labeling all the staplers and cleaning out the supply closet, rather than making truly significant improvements.

More to follow, I'm sure...

Wikileaks

Let me start by saying I don't approve of releasing classified information. Just so we're clear about that. Releasing classified info is a bad idea. People shouldn't do it, unless they're properly authorized to declassify and release it.

But here's the thing: when classified information is released, I'm pretty sure it ceases to be classified (recent objections to the contrary not withstanding). The definition of classified material is information that would cause harm if it were released. As soon as it's released (inadvertently or otherwise) the proverbial genie is out of the bottle and the damage has been done. The released information it can't be re-released any more than it can be un-released (particularly in this digital age), and once it's out, I don't think it can do any further damage by being "more out."

Because of that, I don't understand the recent ban on troops accessing WikiLeaks. Never mind the fact that we're saying the bad guys can look at this stuff but our guys can't, which has its own logical flaws. And it's not as if I really want to go read any of that stuff. I'm just confused because as far as I can tell, the released stuff doesn't qualify as classified anymore - unless I'm missing something. (And just to be clear: I have not personally visited the wikileaks site and have no plans to do so).

The other thing I wanted to point out was that we're talking about digital files. Asking that WikiLeaks return the digital documents sounds kinda funny to me - it's sort of like asking someone to return a fax by faxing it back to you. Yes, the Pentagon also asked that WikiLeaks also delete their files, but the request to "return" them made me laugh a little. Would they like the files to be delivered on a flash drive (which isn't allowed on government computers) or as an email attachment (which would get stripped by the file server because it's too large)? Maybe they could return the stuff by posting it on a website somewhere so the DoD could just retrieve the files... oh, never mind.

As for deleting, the doc's have already been posted online and copied by more than one or two people. So even if WikiLeaks decided to cooperate, that would simply mean they don't have a copy anymore... but it wouldn't exactly take the info out of circulation. Such a move might have merit as a symbolic gesture, but it wouldn't do anything (a-n-y-t-h-i-n-g) to solve the problem.

By all means, let's go after people who break the law. Let's encourage WikiLeaks (and others) to not solicit this sort of thing or repeat this sort of thing. If they've got a stack of unpublished classified stuff, let's encourage them not to expose it. But let's also keep in mind that we're not dealing with paper. Concepts like "return" and "delete" simply don't have the same meaning they used to.

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.

Speeding Dolphins

In a recent visit to the National Aquarium in Baltimore, we saw a dolphin show. I really enjoyed it 'cause dolphins are awesome, but there's one thing the announcer said that really bugged me: "Dolphins swim faster than they should be able to."

It's sort of like the old myth that according to the laws of aerodynamics, bumblebees can't fly. The basic concept here is that people have a complete understanding of laws of motion (flight, swimming, etc), and these doggone animals are violating our laws.

The truth is, the animals have it right and we've got it wrong. When our math indicates one thing and observation reveals something else, um, that means our math is wrong. Rather than saying things like "Bumblebees shouldn't be able to fly" or "dolphins shouldn't be able to swim that fast," we should go with something like "Our understanding of physics is wrong / incomplete / etc." But let's not blame the animals when their behavior doesn't comply with our "laws."

In the case of dolphins' speed, the discrepancy is known as Gray's Paradox, posed in 1936 by biologist James Gray. He basically thought dolphins couldn't be strong enough to overcome the force of drag as they swim through the water. He was wrong, but that wasn't proven until 2008.

So, when there's a mismatch between our model and reality, don't criticize reality. Fix the model. When a theory is "mathematically correct but operationally wrong," it's wrong and needs to be modified... no matter how rigorous the math appears to be.

And yeah, this has something to do with project leadership. It's all well and good to have theories and guesses about how much a project should cost, how long it should take or how people should behave in certain situations. But when reality diverges from expectations, it's time to adjust the expectations.

Special Bonus Post: Beth & Jenna Explain Comedy

As part of my ongoing effort to be a producer and not just a consumer, here's a little comedy video my kids and I did (with some script assistance from my comedian brother-in-law).

Aside from the fact that this was way fun to do and a nice way to spend time with the kiddo's, there's something really cool about making something and sharing it with the world. It's also a nice stretch to go beyond written text and branch out into video.

And if I do say so myself, the result is pretty darn funny. Enjoy!

Bad Design - Hotel Internet Box

As promised, in this edition of Bad Design we're moving out of the bathroom and into... the sleeping area.

Specifically, we're in a hotel room somewhere in Tennessee. The photo below shows a small electronic box mounted on the wall. This box provides internet connectivity to any traveler fortunate enough to get a room at this fine establishment. As an added convenience, the Magic Box Of Wall-Mounted Electronics has a pair of LED which flash in a Very Helpful And Informative manner, providing all sorts of useful information to anyone who speaks LED.

What's wrong with this design, you ask? Well, the soft white object in the lower left corner of the shot is a pillow, resting on the bed. If perchance a weary traveler places their head upon that pillow and attempts to sleep on their left side, they are treated to a magical light show as they drift gently off to sleep... and who doesn't enjoy having blinking lights flashing at them as they try to sleep?

OK, the obvious fix here is to reposition the box - it could have been placed lower on the wall or on some other wall. It could have been reoriented so the LED's were pointing down or away. But mounting it in perfect alignment with the level of the bed is absolutely inexcusable. I can only conclude it was installed by either a blind person, someone who believes that nobody sleeps on their left, or by a misanthropic insomniac.

But issues of location aside, I have to wonder why the blinking LED's are there in the first place. As far as I can tell, they only communicate one thing: your internet is working (or not). And I can tell that by the fact that I'm  online (or not). Those blinking LED's are largely unnecessary and communicate very little 99% of the time. There's no reason for them to blink 100% of the time.

The main point here is that most bad design decisions aren't inevitable. Doing the right thing generally doesn't cost more. In this case they could have mounted the box a-n-y-w-h-e-r-e else in the room for the same cost and got better results. But the more subtle lesson has to do with signals and indicators. If we're going to make a light blink, it should do so for a reason, to indicate something meaningful. As Shakespeare wrote, blinking all the time is just "a sound and fury, signifying nothing."

Bad Design - Bathroom Redux

I know, I know - I said I wasn't going to make a habit of taking photos of bad bathroom-related design, but apparently I just can't help myself. I double-super-promise this is really really really the last one I'll do (maybe).

Today's featured Bad Design is a very common paper towel dispenser which works (I use that word loosely) by exposing a small strip of paper towel which you're supposed to grab and pull to dispense the rest. You've all probably seen them... and probably had the same results I documented below:

I don't need to tell you that a person trying to pull out a towel generally has wet hands. Wet hands make wet paper... and instead of ending up with a full paper towel, we generally end up with two small corners of wet paper. I know I'm not the only one this happens to because the floor beneath these dispensers are always (A-L-W-A-Y-S) littered with scraps of paper towel corners.

From a design perspective, the problem here is that the dispenser's tension exceeds the strength of the wet paper towels. This makes it virtually impossible for a wet-handed person to pull a full sheet of paper towel and leads to litter & gnashing of teeth. But I bet the real problem is that when the designers tested the thing, their hands weren't wet.

So, the design lesson of the day is that when you're testing your design, you should make sure the test accurately represents operational conditions. If your users are going to have wet hands, your testers should too.

Updated Reading List

Lately, I've had several requests for a list of recommended books. I figured posting the list here would probably make it accessible to the most people.

How to describe this list? These books shaped my professional development, captured my imagination and influenced the way I see the world. I've consistently recommended each one to people who are looking to make a difference and do things differently. I hope you find something interesting & helpful - as for where to start, they're all good. Start anywhere. Or drop me an email (or comment) and let me know what you're looking for, and maybe I can make a more personalized recommendation.

Happy Reading!

Alternative approaches to organizational structures & leadership
Orbiting the Giant Hairball, by Gordon MacKenzie
The Birth of the Chaordic Age, by Dee Hock
Losing My Virginity, by Richard Branson
Maverick, by Ricardo Semler
Reimagine, by Tom Peters
The Abilene Paradox, by Jerry Harvey
How Come Every Time I Get Stabbed In The Back, My Fingerprints Are On The Knife, by Jerry Harvey
Love and Profit, by James Autry
Up The Organization, by Robert Townsend

Military / Air Force issues
Boyd, by Coram
Pentagon Wars, by James Burton

Creativity, Marketing & Presentations
Ignore Everybody, by Hugh MacLeod (a book about creativity)
Understanding Comics, by Scott McCloud
Presentation Zen, by Garr Reynolds (want to give better presentations? Start here)
A Whole New Mind, by Dan Pink
Fascinate, by Sally Hogshead

Thoughts on Career Development & Transition
Crossing The Unknown Sea, by David Whyte
Radical Careering, by Sally Hogshead
The Adventures of Johnny Bunko, by Dan Pink

Short Reads
ReWork, by Fried & Hansson
The Peter Principle, by Lawrence Peter
The Simplicity Cycle, by Dan Ward (Download for FREE!)

Long Reads
The Fifth Discipline, by Peter Senge
The Reflective Practitioner, by Donald Schon

Lean Education

I'm in the middle of training to become a certified Black Belt in the AF's version of Lean. I'm actually enjoying the course quite a lot - the instructors are great, the material's interesting and despite the strong flavor of manufacturing, I'm learning stuff I can actually use.

I've got to admit this Lean / Six-Sigma / Theory of Constraints stuff makes a lot of sense - still no fan of the late Dr. Hammer & his Business Process Reengineering though. I'm still figuring out how to use this stuff in my more creative pursuits, but I definitely see a place for it in the contract management part of my life.

I guess that's all I wanted to say - the class is good, I'm learning useful stuff and enjoying it.

Mediocrity

Imagine how awesome you could be if the world didn't insist that you be mediocre.

Seriously, how much of the stuff we spend our time doing is done because someone else thinks it's important? Stuff that, even if it's done well, doesn't really make an impact? Stuff that gets in the way of doing the really high-impact, meaningful, leave-a-dent-in-the-universe stuff we dream of doing? Too much time, I tell you. Too much time.

The thing is, we all spend an awful lot of time doing an awful lot of stuff that doesn't really matter much... and that's awful. Time is precious, life is short and all that...

So, do you want to know a secret? It turns out, the world doesn't really insist on your mediocrity. I bet there's a way to really put your strengths to use, to do the Big Cool Stuff you're supposed to be doing... and a way to dodge the pointless timesucks that get in the way.

Step one is to try. Step two is to not give up. I'm pretty sure there is no step three...

Flawed

My recommendation for the day? Let your self be flawed.

Do some things badly. Fail to do other things entirely. But be absolutely awesome at what matters most.

Play to your strengths and put them to use as fully as you can. Don't worry about filling in every chink in your armor, shoring up every weakness and improving every shortcoming. The days are too short to do all that.

Do what you can do. Be great at what you can be great at. And don't spend too much time on all that other stuff.

Being Busy

In his book The Four Hour Work Week, Tim Ferris writes "being busy is a form of laziness." I couldn't agree more.

The busy-busy-hair-on-fire-ImsoburiedIdon'thavetimetopee style of work which masquerades as meaning in countless offices doesn't impress me at all.The fact that a person has frantically filled up all their time means they're running from thing to thing, and most likely they're not really thinking very much. As Ferris put it, being lazy is a form of mental laziness. It's an excuse to not think.

Personally, I make a point of not filling in every moment of every day. It's important to me to have quiet, unhurried moments to think, to reflect, to poke my head above the cloud of dust and get a little strategic. And when everyone around me complains (i.e. brags) about how busy they are, I don't chime in.

A lack of time isn't a sign that you're doing good things. A lack of time is actually a lack of priorities (that's Ferris again). The point isn't to be super busy - the point is to be productive. So don't tell me how full you schedule is. Show me what you actually accomplished - otherwise it's just brownian motion.

The Fear Question

[NOTE: For the near future I'm aiming to post here once a week, on Tuesdays at 0700, in order to free up some time to write my next book.]

One of the questions that comes up a lot in my FIST presentations goes something like this: “Your ideas sound really different and counter-cultural. My organization simply won't / can't / doesn't reward this sort of thing. Although I agree with your recommendations, I might get criticized / fired / not promoted if I do it. So how can I do FIST in an environment that doesn’t encourage it?”

There are several variations on that question, but they all resolve around a single concept: fear. People are afraid to do something different, afraid to stand out, afraid of criticism, afraid of doing something that isn’t recognized & rewarded…

I’ve tried answering it several different ways, and I’m not quite sure I’ve ever answered it particularly well. My latest attempt goes something like this: “I’m not recommending this FIST approach because it’s easy or because I think it’ll get you promoted. It might even get you into trouble. But the impact on your career and promotability isn’t the point. If you just want to get promoted, then spend billions of dollars and manage a cast of thousands. Smile, nod and be as busy as you possibly can.As a general rule, that's what big organizations value and reward.


“On the other hand, if you want to help the warfighter and look after the interests of the taxpayer, do this FIST thing. Rapidly deliver affordable systems that are available when needed and effective when used. This approach might trigger the Corporate Immune Response… but I bet it won’t. I bet most of our negative fantasies about undesirable consequences won’t come to pass. But even if they do, there’s something profoundly cool about being punished for doing the right thing.”

Bottom line: don't let fear be your primary motivator. Surely you can find a nobler purpose than maintaining your personal safety (and like I said, 99.9% of our negative fantasies wouldn't come true anyway).

Here's a little video my kids did. They're sharing a few thoughts about how to do PowerPoint well. I hope you enjoy it (my wife and I even have brief cameos).

FIST-a-palooza

I was a guest speaker at three different courses over the past three days - each time, talking about the FIST approach to system development and acquisitions. It was an exciting, exhausting experience, and I look forward to continuing the conversation with the students (& professors).

Each class had its own unique flavor - one was almost raucous, asking questions in the middle of the presentation and laughing at all the right places. Another was quiet and reserved, but still full of thoughtful, penetrating questions and observations from the students. I don't know if the difference was the result of the time of day, the professors or the students themselves... or some combination of all three.

At any rate, it was great to have a chance to spend so much time in such different classrooms. I loved it and wish I could have weeks like this more often!

Taking a break

I'm going to take a break from this blog for a little while, in order to focus on writing my next book.

Who knows, I might surprise myself and post things here more often than I think I will... but I wanted to let you all know that the output here is going to be reduced and redirected towards a different project for a while.

cheers!

Defense Budget Trend

Fellow blogger Craig Brown posted this link in a recent comment section, but I had to bring it up to the main level. Check out this graph on USAspending.gov, which shows the size of budgets for various government agencies and departments.

First of all, it's a really well done layout. Very simple, crisp and clear. Switch between the balls, lines and bars - wow, they've got some elegant transitions between graph styles. You don't have to be a data nerd to appreciate what's going on there.

But what's really interesting is to use the slider bar at the bottom of the graph and see the change from 2000 to 2009. And by "interesting" I think I mean "horrifying." I'm going to whip this out the next time I hear someone complain that upcoming budget years are going to be "grim" or "difficult" or "tight." Um, no, they're really not.

The List View is nice if you're a serious data nerd and want to see the actual numbers. As for me, the Graph View captures it perfectly well...

Simon Sinek on "Why"

Do you watch TED Talks? If not, you're really missing out. So much good stuff there, all in short doses (from 3 to 18 minutes, depending).

I recently came across an 18-min talk by a dude named Simon Sinek. Great stuff there, looking at what made MLK, Apple Computer and the Wright Bro's different from their competitors & peers. Check him out.

Pomplamoose Music

I can't get over this video by Jack Conte and Nataly Dawn, aka Pomplamoose. I dig indie music in the first place, and these two film their videos in a smallish apartment. It's a very stripped-down, simple approach, and the resulting product is pretty amazing. Nataly has a great voice and watching Jack play the drums is a thing of beauty. I'm not sure if it's the elbows or the grin that gets me more.

Why mention this here? Just to point out that the relatively simple, inexpensive approach to producing things applies beyond the world of technology. It works for music, just like it works for tech. Enjoy the video.

Microcredit

I just finished reading Muhammad Yunus' amazing book Banker To The Poor. It describes his efforts to set up a microcredit bank called Grameen, and it's a heck of a story. It almost makes me want to become a banker.

He started in 1976 with a $27 loan to a few of the poorest people in Bangladesh. A few decades later he's lent billions and helped millions of people lift themselves out of poverty.

One of the things I love about his story and his approach is the emphasis on speed & simplicity. He is totally focused on delivering credit to the poor and has no time for the complexities, formalities and delays inherent in traditional banking structures. The results (including a Nobel Prize) speak for themselves.

"I'm getting better..."

Here's a headline I didn't expect to see anytime soon: "GAO report finds Pentagon acquisition becoming more efficient."

Wow. How did that happen? Apparently "the Pentagon has "made major revisions" in its weapons-buying practices to put more emphasis on learning more about requirements, technology and weapons design before starting weapons programs," according to an article by William Matthews, which quoted the GAO's Michael Sullivan. Huh. Who knew it was important to understand requirements, technology & designs BEFORE we start? Oh, that's right... JUST ABOUT EVERYBODY! It's been a nearly constant theme of GAO reports in particular over the past several years. Still, it's nice to see some of these changes actually being implemented.

Sadly, Matthews' article goes on to say "The bad news is that they probably aren't improving fast enough to avoid a fiscal crunch caused by the federal budget deficit, the cost of the wars in Iraq and Afghanistan, and rising medical expenses and personnel costs."

So we've still got some work to do... but hey, it's a start.

Brownies, military-style

A buddy recently forwarded me the 26-page recipe for military brownies. Yikes!

To be fair, these are MRE-style brownies, so they need to be able to sit on a shelf for a thousand years and still be moist and delicious. And many of the pages refer to the packaging. But still, it does seem excessive, doesn't it?

Now, I'm no brownie expert. It's entirely possible the 26-page spec is exactly the simplest, shortest and most concise recipe possible, given the rigorous operational demands we place on these combat brownies. We certainly don't want a situation where a dude in combat opens his MRE brownie and discovers it's inedible, moldy, etc. Eating MRE's sucks enough in the first place, and no doubt brownies are the highlight of the meal.

But when the AF built the F-16 Falcon, the Request For Proposal was 25 pages long. Proposals were limited to 50 pages. Should the explanation of how to make and package a brownie really be longer than a statement of need (and more than half as long as the proposals) for an advanced fighter jet?

I bet we could do better than that.

The Scientist's Garden

Just came across another case of The Simplicity Cycle being used in someone's book. How excited am I?!?

On page 175 of Dr. Richard Stirzakar's book Out of The Scientist's Garden, he's got a great little diagram that's derived from my Simplicity Cycle diagram (the acknowledgement shows up on page 193). Amazon says the book won't be released until June, but somehow I was able to read a good chunk of it on Google.

It looks like a pretty fascinating book - I'll have to preorder a copy.

How To Win...

I recently came across a brilliantly simple PowerPoint presentation, titled How To Win the War In Al Anbar. It's by Army Captain Travis Patriquin, who was sadly killed by an IED.

The presentation was actually done in 2006, but it's still worth looking at today, both for its message / strategy and its format.

If you haven't seen it already, check it out.

Stuff I like

I've been thinking a lot about what I want to be when I grow up. Specifically, I'm thinking about what I want to do when I retire from the AF, which will probably be in about 4 years. As someone recently pointed out to me, four years away is "too soon to start worrying about it, but not too soon to start thinking about it."

So I made a little list of things I like to do. The list said I like to write, teach, speak, design and help. I like to do stuff that matters. I like to collaborate with interesting people. I like delivering early, starting new things... and the list goes on.

A few days later I returned to the list and realized I'd left off something significant: I forgot to write that I like leading small groups... even though that's a pretty central, persistent like.

The thing is, between the 18 months I spent in school and the 12 months I've been in DC, I haven't led a small project group for quite a while. I've not only gotten out of practice, I sorta forgot about it.

It's now at the top of the list: leading small teams of talented people... That's the sort of thing I love to do, and it's something I hope to get back to doing again... preferably sooner rather than later.

Bad Design - Bathroom Layout

I don't make a habit of taking photos in bathrooms - honest! But here we are for two days in a row... don't worry, this is the last one, I promise.

This shot is part of the continuing "Bad Design" theme. Anyone want to take a guess what's wrong with the design of the comfort station pictured to the left? Here's a hint - it has something to do with shoulders.

For those who haven't figured it out yet, holy cow those urinals are close to each other! I don't have remarkably large shoulders, but it is downright uncomfortable to make use of these facilities when the other one is occupied. It's not easy to avoid brushing shoulders with the dude next door.

Even an inch or two between facilities would have been much better. There's not a ton of space on the wall, but enough to have done it better. I'm sure there's a lesson here for any design students out there...

Don't Do This

As a general rule, I'm not a big fan of rules. And this set of "Restroom Guidelines" posted on the stall door of the men's room at my office is pretty much a perfect example of how not do do it.

First of all, these aren't guidelines. They're rules. And don't give me this about my assistance being requested and appreciated. This sign is asking for compliance. The attempt to put some humanity into this rule set falls quite flat.

Can anyone tell me why the men's room needs a "Guideline" to not dispose of feminine products? And what about pinecones? The Guidelines doesn't say I can't discard pinecones, which is just about as likely as discarding my "clothing undergarments."

I just have to wonder about the mindset of the person who conceived, wrote and posted these rules. What did they think they accomplished? Maybe one of these things happened once, and now there's a big rule set outlawing things that never happened and never would have, rules or no rules. It's just one more example of universal solutions to isolated problems.

I only mention this because organizations do the exact same thing in all sorts of other contexts. My request? Please don't...

The Discipline of Affordability

On a similar note to yesterday's post, Dr. Ashton Carter (Under-Secretary of Defense for Acquisition, Technology and Logistics) recently said the Pentagon needs to "relearn the discipline of affordability" and "relentlessly pursue affordability."

It sounds to me like he and the SECDEF are both saying it's important and good for programs to be inexpensive. That's the I in FIST, the Inexpensive value. It's a nice change of pace from previous years, when large price tags were seen as both a sign of sophistication and an inevitable attribute of military technology systems.

That's some pretty clear direction from the top leaders. I just hope the DoD's rank and file will read and heed.

Keep going, Mr Secretary!

I've admired Secretary of Defense Gates for quite a while. He's got guts and vision, and I like the way he leads. In recent days, he's been quite blunt about the need for fiscal constraint, a move I heartily applaud. Based on his statements, it looks like the DoD is going to do some belt-tightening in the relatively near future, on everything from weapon system development to organizational structures. That sounds good to me.

In fact, way back in Nov 2004, I said the DoD "has too much money," and that being overfunded is limiting our ability to innovate. But enough about me - let's see what Mr. Gates has been saying:

From NY Times article:
“Military spending on things large and small can and should expect closer, harsher scrutiny. The gusher has been turned off, and will stay off for a good period of time." And this: "“How many of our headquarters and secretariats are primarily in the business of reporting to or supervising other headquarters and secretariats, as opposed to overseeing activity related to real-world needs and missions?” Mr. Gates asked."

An excerpt from the Wall Street Journal article:
We have to accept some hard fiscal realities," Mr. Gates told an audience of naval officers and defense contractors in National Harbor, Md. "We have to ask whether the nation can really afford a Navy that relies on $3 billion to $6 billion destroyers, $7 billion submarines and $11 billion carriers."

No doubt he's going to get some heat for this, but I for one am completely behind him. It's about time for a little restraint.

Policy for Policy's Sake?

I'm taking an online class from Defense Acquisition University, and came across this line:

“As a Business Advisor you should take the lead to ensure that the final requirement documents implement as many government policies as possible.”

Um, I don't think that's quite right. I think I understand what the writer was trying to say, but let me gently suggest that the point isn't to implement as many policies as possible. Maybe something more along the lines of implementing the appropriate policies, or maintaining compliance with all relevant policies...

But as many as possible? I sure hope not.

We don't...

I kinda dig these ads that have popped up in several metro stops around DC. They say things like "We don't build UAV's" or "We don't build ships." It's for a company that provides translation services for the military, and I really appreciate the simplicity and focus of their ads, both in terms of the message and the structure.

Very simple - big letters, white background, and a brief description of what they actually do. The big negative statements ("We don't do X") got my attention and made me curious to find out what they DO do...

Sure, I don't need any translation services myself, but if I did, this ad would definitely get my attention.

Thrift Supervision?

Walking through downtown DC the other day, I came across the Office of Thrift Supervision. I thought this office sounded like a pretty good idea, and I'd like to get one for the DoD.

The DoD office of Thrift Supervision could focus on making sure people exercise some restraint when it comes to spending. It could encourage and reward underruns on development programs. It could provide education on why a tight budget is good for programs, why it's good to not spend all your money by the end of the year, and help program managers understand that constraints foster creativity. Naturally, this new office would work closely with the Office of Speed Supervision, which would encourage programs to establish short timelines. And we could probably use an Office of Simplicity Supervision... heck, let's just put them all together into the Office of FIST Supervision.

Speaking of speed, did you know that in 1943, the XP-80 development team was given 150 days to deliver their aircraft? They did it in 143 days... one week early! Did you know we could do that today if we wanted to? Or we can keep on making 10-year plans that turn into 20-year projects...

Hey, a guy can dream, right?

Defeating The Enemy

There was a great article in the NY Times yesterday, titled We Have Met The Enemy, and He Is PowerPoint. It recaps all the familiar criticisms of bad briefing charts - they're too complex, too simplistic, too confusing, too obtuse... Regular readers may recall a little film noir spoof I wrote titled Death By Bullets, which was my own little salvo in the war against bad PowerPoint.

But as they say, it is a poor workman who blames his tools, and I've long believed that Microsoft's presentation software isn't the problem (although the default template settings they use are inexcusable). But the truth is, all those terrible, horrible, no-good, very-bad briefings out there do not represent a software problem. They don't represent a technology problem. For that matter, they don't even represent a communication problem.

Ladies and gentlemen, bad briefings are a leadership problem and a thinking problem.

Senior leaders should never accept an endless parade of dense, impossible-to-read charts. They should refuse to sit through briefings like that. But not only do they receive and accept such briefings, they deliver them too. It makes me crazy to think about it.

Nobody likes that approach. Nobody thinks it's effective. And apparently nobody thinks there's an alternative.

Thank goodness for rare leaders like Brig. Gen. H. R. McMaster, who banned PowerPoint presentations according to the aforementioned article. Now, I think he would have been better off banning BAD PowerPoint, but it's a start.

Look, it's possible to create a clear, coherent, cogent presentation using just about any type of software (Apple's KeyNote can be just as bad as PPT). It just requires a little extra thought, a little creativity and a little practice.

A little study wouldn't hurt either. Do your homework. Learn how to give a good presentation. I recommend starting with Garr Reynolds' Presentation Zen and watching some of the TED presentations.

Good luck, and remember the #1 rule of PowerPoint: First, Do No Harm.

Crossing The Unknown Sea

I don't recall how I first came across British marine zoologist and poet David Whyte's name or his fantastic book, Crossing The Unknown Sea. But the book has had a tremendous influence on me. It contains profound insight into the nature and purpose of work, the causes and solutions to exhaustion, and various aspects of life on a frontier.

I recommended it to a friend over the weekend, and thought I'd recommend it here too. I have a strong aversion to trite, six-easy-steps-to-success style books. This is nothing like that. It's simply a deep, gentle, compelling look at life, work, meaning and struggle.

I highly recommend it.

Simplicity Cycle Down Under

The other day I came across a scientific paper titled "Using the Simplicity Cycle in Model Building." It was presented at the 18th World IMACS / MODSIM Congress in Australia this past July. The conference has something to do with "modeling and simulation with mathematical and computer sciences," which frankly is all a bit beyond the scope of my education.

But back to the paper's title. Huh, I thought. Someone else is using the phrase "Simplicity Cycle." I wonder what theirs is like. So I checked it out.

Nope. Turns out, the title of the paper was referring to MY Simplicity Cycle. How cool is that?

All I could get access to was the abstract, which is probably just as well. But from what I can tell, Prof Ted Lefroy from the University of Tasmania and his co-authors C.A. Pollino and A.J. Jakeman from the Australian National University in Canberra are using the Simplicity Cycle concept to "arrive at a state of low complexity and high utility" in their agricultural models, by "progressively discarding drivers, nodes and links to which the system is least sensitive." Which is exactly what the Cycle diagram is for.

I completely love the idea that Australian agricultural scientists are using some ideas from my crazy little book to shape their own model designs. I hope others will do the same - which is why I made it a free download at Lulu and why I released it under a Creative Commons License.

Incidentally, it's now been downloaded over 2,100 times. You've got your free copy, right?

Superficial Agreements

People often respond to my FIST (Fast, Inexpensive, Simple, Tiny) presentations by saying that “Everyone agrees with this," by which they seem to imply this stuff is almost too obvious to say.

The thing is, that’s not exactly true.

Sure, everyone agrees in principle to the *objectives* of FIST, such as reducing the cost and time involved with developing new systems. But when it comes down to actual *implementation,* we quickly encounter friction. And it’s the implementation that’s at the core of FIST.

Let’s take a look at a few specifics, shall we? In my FIST presentations & articles, I say simplicity is desirable, a sign of sophistication. Adding more features, functions & widgets makes the system worse, not better. But take a look at almost any piece of consumer electronics or any weapon system, and you’ll find it’s chock-full of shiny bits and features, apparently added in the belief that more is better. In fact, when you actually analyze the system, you often find it’s full of extra features, which:
   a) are unused / seldom used,
   b) increase the cost of the system,
   c) increase the complexity of the system,
   d) reduce the reliability of the system (by creating more potential failure modes, for example),
   e) make the system harder to learn, use & maintain
   f) all of the above

I could go on, but you get the picture.

Similarly, FIST argues that constraints foster creativity, and thus small budgets are good. But as soon as a program runs into a technical problem, the same people who supposedly agree with FIST end up asking for more time and money. Or consider the huge pressure on military program managers to “keep your obligations’s & expenditures up,” (i.e. spend all your money) for fear of not getting as much money next year. Clearly, the environment does not reward thrift. Any DoD program manager who turns in money at the end of the year is likely in for some harsh words from the finance folks. Spend, spend, spend! But yes, we agree that FIST is a good idea… as long as we don’t make things simple and as long as we spend a lot of money.

Sheesh.

Collapse

I recently got turned on to John Robb's fascinating Global Guerillas blog. As I've perused the site, one line in particular jumped out at me. Commenting on social and economic collapse, John writes about a "system that collapses when it begins to succumb to diseconomies of complexity."

I think the concept of collapse caused by the diseconomics of complexity is brilliant, not just because I'm a word geek and love a well-turned phrase, but also because it perfectly describes an aspect of The Simplicity Cycle which I'd never really considered before. Specifically, it describes a common way for a large entity to leave the upper-left quadrant, aka the Region of the Complicated, where complexity is high and goodness is low (check out the Simplicity Cycle link above if you don't know what I'm talking about).

I generally describe two ways to proceed from this situation (of high complexity & low goodness). One is to simplify, and the other is to scrap the whole thing and start over. From a design perspective, there are many practices and principles for doing the first option. The second option takes guts and is called a smart move when it's deliberate... but it's called collapse when it happens even though nobody really meant for it to happen. And frankly, if we don't do it with purpose, it eventually happens whether we wanted it to or not.

It just makes me wonder whether the defense acquisition business will figure out a way to deliberately simplify before the diseconomies of complexity completely take over and things begin to collapse in a big way.

Sparky Baird Award!

Pardon me while I brag for a moment, but I just got a nice surprise in the mail. It turns out the Twitter Is Mission Critical article I co-wrote with some friends was selected as the winner of the Sparky Baird Award "for the best article published in SIGNAL Magazine during 2009."

I didn't even know there was such an award, let alone that our little article was in the running. I'm not sure if I'll make it down to Virginia Beach for the awards luncheon, but it's definitely nice to be selected.

Free Shipping

I love publishing my books at Lulu.com and have always been impressed with their quality, speed and low prices. But I have to admit I think their shipping & handling charge is kinda high - it's $3.99 if you order one book.

The shipping charge is one of the reasons I encourage people to download the free PDF version of The Simplicity Cycle. Sure, you can buy the printed hardcopy for just $7.95, but by the time you add in shipping and handling and taxes, it's upwards of $12. And personally, that feels a bit steep to me. I wish there was a lower-price shipping option for people who just want to order one book.

I'm very happy to report that between now and May 1st, there is! Use the coupon code FREEMAIL305 to get free shipping on one book and skip the $3.99 s&h fee. Usually Lulu coupons are good for 10% off, which equals about 80 cents for the Simplicity Cycle. So the $4 savings is a pretty big deal.  If you've already got the eBook version and want a physical copy, this is a great time to get it.

The Innovator

Check out this little piece I wrote about crowdsourcing & defense acquisitions.It got a nice mention on David Axe's War Is Boring blog. I'd say more but I'll just let you read it...

(NOTE: I fixed the link... try again)

FIST Poster

I've been meaning to post this photo for a while (since last month, actually). It's the poster that hung outside the room where I did my FIST presentation a while back. I was so happy they gave me the Wright Flier picture, instead of the oh-so-expensive (& delayed & complex) F-22, which adorned some of the other posters.

I just really like how the poster looked. Thought I'd share.

Quality

I love Hugh MacLeod - he's got some truly spectacular stuff on his blog, Gaping Void. I'm on his email distro list and get a piece of Hugh's artwork in my inbox every day. It's the only mass email thing that I actually signed up for on purpose and continue to enjoy.

But there is one thing that sometimes stands in the way of my appreciation for his genius, and that's the salty language which often accompanies his art & commentary. Actually, it doesn't stop me from appreciating it... just from sharing it with my friends & neighbors. So imagine my pleasure to discover that he's cleaned up one of my favorite pieces - posted below



I'm also particularly glad that he uses a Creative Commons License for his work. Rock on, Hugh!

Bad Design - Shuttle Bus

After parking in the endless Row D9, I boarded the shuttle bus which takes parkers to the main terminal. Imagine my surprise when the bus pulled up to the next pickup / drop off point and a cheery voice announced that the doors were about to close... as the doors were opening. Sheesh.

That's right. Every time the bus comes to a stop and the driver opened the door, a recorded voice warned the passengers to watch out, because the doors (which were in the process of opening) were about to close. Once all the passengers were loaded, the doors did indeed close... but this action was not accompanied by any recorded messages.

It wasn't a one-time glitch, either. This happens every time I'm on the bus, with one exception. In one instance, the driver began to close the door, then quickly opened it for one last passenger, then closed it again while a recorded voice was saying something about the terminal we were heading to. But apparently the act of opening the door triggered the "Doors closing" message, so as we were driving down the road (with the doors closed), all the passengers were once again warned to look out, because the (closed) doors were... wait for it... about to close.

The lesson here is that a message (recording, warning light, etc) should correlate with the appropriate action. Run some use cases and tests to make sure you're not warning about things that have already happened or won't happen for several minutes... or worse yet, about the opposite of what is actually happening.

Bad Design - Reagan Parking Lot

One of the items in my long list of Books To Write Some Day is a project I'm calling The Book Of Bad Design. Maybe I'll do it as a blog instead, but the general concept is to present poorly designed objects and examine what went wrong... then propose design solutions.

In anticipation of someday creating such a thing, I've been collecting examples and thought I might share a few of them here on RPL.

The photo to the left is of a parking lot at Reagan National Airport in DC. Notice the sign reading "D9" on the street light. Notice also the long line of street lights stretching off into the distance. Although you can't tell from this photo, I can confirm that every single one of those lights has a sign which reads (wait for it...) "D9." Really? Yes, really.

Running parallel to the long line of D9 parking spots are other rows, with similarly consistent labeling. This means that even if you remember you parked in row D9, your car could be anywhere along a rather lengthy row. The simple solution of course would be to give each light its own unique label, such as D1, D2, etc (for the D-row), and C1, C2, etc for the C row.

I can't imagine why the parking lot designers decided to use this labeling convention. They got so close to a usable design, then completely whiffed it. But it was better than the shuttle bus design... more on that soon.

GK Chesterton Quote of the Day

Writing about trusts and monopolies, the great G.K. Chesterton had this to say:
"It has not only destroyed the virtues it despises; such as independence, individuality and liberty. It has also destroyed the very virtues that it claims; efficiency and modernity and practical progress. Big Business is not business-like; it is not enterprising; it is not favorable to science and invention. By the very nature of its monopoly of machinery and mass production, it works entirely the other way. Millions are sunk in plants that cannot be changed or brought up to date. Machinery is made so that it must be used, even when it is useless..."

One hundred years later, the principles of brainless bureaucracy persists, where compliance is a virtue and we do things because they're important rather than useful and productive. Thankfully, there is a growing movement of craftsmen and small-batch production.

CubeSail Space Cleaners

The BBC News recently reported on a FISTy approach to cleaning out some of the orbital debris which is currently cluttering the region located a few hundred kilometers above your head.

Dr Vaios Lappas, the lead researcher on the project says "Our system is simple and very low cost..."

Of course, he goes on to say "... but we need to demonstrate that it can be done," so apparently there's some work still to be done. Nonetheless, I do get excited when technologists and researchers brag about systems that are inexpensive, simple and tiny...

Reducing Complexity, DARPA-style!

Graham Warwick has a great post over at Aviation Week's Ares blog, talking about the impact of complexity on weapon system development projects. The post looks at the F-35 Joint Strike Fighter in particular, and the way the DoD does systems engineering in general.

It turns out DARPA did a study of the relationship between complexity and project duration, and launched a program called META which is designed "to make a dramatic improvement on the existing systems engineering, integration, and testing process for defense systems." And by "dramatic" they mean reducing timelines by 5X.

As for me, I'm pretty excited to see someone is paying attention to the impact of complexity on system development efforts, and specifically to the relationship between complexity and project duration. One of the central tenants of FIST is that we can't simply reduce one aspect of a project (say, timelines) without simultaneously reducing the other aspects (cost, complexity, team size, etc). In other words, FIST isn't four ideas, it's one.

That means not only do I reject the "faster, better, cheaper - pick two" concept, but I think the only way to improve in two dimension is to also improve the third.

Go JOE!

Joint Forces Command recently published their Joint Operating Environment 2010 report (aka the JOE report), and it's got some interesting observations.

As reported by Greg over at Defense Tech, JOE asserts that "the military’s approach to buying new high-tech weaponry has become a strategic liability and is weakening the force."

Yikes! Apparently the amount of time & money we're spending on weapon systems is actually degrading our national defense posture, rather than improving it. According to the report, the failure to reform acquisitions is "no longer a bureaucratic issue: it is having strategic effects."

There is a significant move afoot across the DoD to reduce the cost, duration and complexity of weapon system development projects. In recent months I've seen actual evidence of meaningful reform in certain places - more than just people talking about making improvements, but actual improvements. And at the same time, there's a huge amount of institutional inertia, and the Corporate Immune Response is doing its best to fight off the "reform idea virus." Having JFCOM point to big/expensive/slow/complex acquisitions as a strategic liability is certainly a helpful piece of the overall reform puzzle.

(Thanks to Nick S. for the heads up on this report!)

Reading Policy

It's sometimes amazing what you can find when you read a policy document. I happened to be thumbing through a copy of D0D 5000.02 (aka the Defense Department's policy on acquisitions), and I came across the following.

Evolutionary acquisition is the preferred DoD strategy for rapid acquisition of mature technology for the user. An evolutionary approach delivers capability in increments, recognizing, up front, the need for future capability improvements. The objective is to balance needs and available capability with resources and to put capability into the hands of the user quickly.

Evolutionary acquisition requires collaboration among the user, tester, and developer. In this process, a needed operational capability is met over time by developing several increments, each dependent on available mature technology.

Each increment is a militarily useful and supportable operational capability that can be developed, produced, deployed, and sustained.

Whaaaaaaaaaaaaaaat? Rapid acquisition of mature technology, putting capabilities in the user's hands quickly? Collaboration among users, testers and developers?

Nonsense - this could never work. The policy won't allow such a Fast, Inexpensive, Simple and Tiny approach. Why, just think of all the legislation you'll need to change, all the waivers you'll need to secure, all the... wait, what? That's already IN the policy? There's an approved, documented path for doing precisely this? And it even addresses the need to balance the requested capability with the available resources? So we could just do it? To quote the great American philosophers Bill & Ted, "No way? Way!"

Way indeed, my friends. Way indeed.

Rework

I just finished reading Rework, the new book by the guys at 37Signals. It was fantastic - and you can check out their free online excerpt to get a taste.

I particularly liked the bit titled Planning Is Guessing. Bingo! Their comment about the danger of treating guesses as plans was particularly insightful, and I wholeheartedly agree with the following advice:

"Start referring to your business plans as business guesses, your financial plans as financial guesses, and your strategic plans as strategic guesses."

While you're waiting for your copy to arrive (you are going to buy one, aren't you?), check out this tongue-in-cheek attack ad the 37Signals guys did to counter the #1 selling book on Amazon, Karl Rove's Courage & Consequence.

The Monkeysphere

There's a great sociology article over at the prestigious American journal Cracked.com, ("America's only humor and video site, since 1958") which sheds some light on the importance and value of small teams. This is an important element of the FIST (Fast, Inexpensive, Simple, Tiny) approach to systems development, and I highly recommend reading the article to help understand why it's so important to keep teams small. Plus, it's hilarious.

The author, David Wong, posits that the human brain has a limited capacity for maintaining social connections. He refers to this group size as "the Monkeysphere," based on research on monkesy, and explains:

"The Monkeysphere is the group of people who each of us, using our monkeyish brains, are able to conceptualize as people. If the monkey scientists are monkey right, it's physically impossible for this to be a number much larger than 150."

The implications for large program teams are significant, in terms of the increase in conflict, friction and inefficiency. Plus, like I said, the article is full of references to monkeys, and monkeys always make me laugh.

FIST (near)Space Imaging

You may recall hearing the reports of the two MIT students who built a contraption that rose 17 miles above the earth and took photos from a near-space environment... and did so for less than $150.

Well, they've posted a pretty good description of how they did it, for those of you with the inclination, $150 and time to build your own.

One of these days, I totally want to do this!

Overvaluing Complexity

One of my frequent refrains is that technologists have a tendency to overvalue complexity. Complexity looks like work. Complexity looks like improvement. I wrote The Simplicity Cycle book to help counter that tendency, arguing that simplicity is a sign of design maturity, while complexity is a sign of cluttered thinking and immature design.

This is not just a problem in the military. Industry certainly wrestles with overvaluing complexity, as the following video shows (incidentally, the video was actually produced by Microsoft, as an internal parody intended to highlight their own foibles - and somehow, it got unleashed onto the interweb and we all got to join in the laugh).

DIMHRS - RIP

It cost $1B (that's billion-with-a-B).

It took 12 years.

Over 600 people worked to integrate 90 different systems.

All it delivered was an unpronounceable acronymn, according to the SecDef.

DIMHRS - the Defense Integrated Military Human Resources System was supposed to be an integrated, state-of-the-art payroll and personnel system. The Chariman of the Joint Chiefs of Staff called it a disaster when it was cancelled last month (it was originally supposed to go operational in April 2006).

Gosh, who could have seen that coming?

And the worst part of it is, the DoD saw the problems on the horizon and they had an alternative. According to this article:

"Six years ago, after multiple pay problems surfaced again for mobilized personnel, the Defense Finance and Accounting Service stopped waiting for DIMHRS and announced it would phase in a more reliable, effective interim pay system, the Forward Compatible Payroll. This new system promised far fewer errors, an easy-to-read Leave and Earnings Statement and instantaneous adjustments to pay records. But the Forward Compatible Payroll never started. The rationale seemed to be: Why spend millions more on an interim payroll fix when DIMHRS was so near?"

Apparently, DIMHRS in the mirror wasn't as close as it appeared.

Just one more data point supporting the wisdom of simple, incremental, interim solutions, developed on shorter timelines and smaller budgets. Of course, we don't know for sure that FCP would have worked, because it wasn't tried. But I don't think it could have been much worse than DIMHRS.

Provocative

I bumped into a guy recently who said he'd read some of my articles. He said he liked them because "they're not right or wrong, just thought-provoking pieces, trying to encourage people to think creatively."

Um, ok.

I actually do intend for most of my articles to be right (i.e. correct, reasonable, useful, etc). I try to leave room for nuance and alternative perspectives, and I try to avoid being excessively dogmatic or prescriptive. But I am indeed aiming to be more than provocative.

Still, if that's what some readers get out of my articles, I guess it's better than nothing, right?

FIST & Failure

In a recent briefing, after showing data which supports the idea that small, rapid, inexpensive projects (i.e. FIST projects) have a higher success rate than large, slow, expensive ones... and after describing the difference between optimal failures (cost a little, teach a lot) and epic failures (cost a lot, teach a little) and showing that FIST projects fail optimally, I still got the question about "How can we deal with all the failures?"

Let me just say: Arg!

System of Systems

Whenever I hear someone use the phrase "system of systems" (SoS), I like to ask them to explain the difference between a "system" and a "system of systems." I've been doing this for a pretty long time now, and just this week I finally got a good (albeit paradoxical) answer.

Most attempts to distinguish between a system and a SoS fall into a recursive, almost fractal-esque jumble of un-clarity. For example, is an aircraft a system that is part of a larger SoS (which includes air traffic control, radar sites, communications links, etc), or is the aircraft itself a SoS, made up of the life support system, navigation system, weapon system (if it's a military jet)? Depends on your perspective, right? And if both terms can be applied to the same object, we might ask what the terms really mean.

It seems to me that we could simply describe any given SoS as a system. This lack of clarity in distinguishing between the two labels led me to suspect that SoS don't really exist in a meaningful way. However, after talking with a new BFF from Auburn University, now I'm thinking that SoS do exist, but discrete systems don't (thus the paradox).

Clearly the intent of the term SoS is to highlight the interrelated nature of technology systems. We use that term to remind ourselves that no system is an island. This awareness helps shape our decisions about investments, modifications, operations, etc. And along with the idea that no system is an island, I'm coming to suspect that no system is a system. It's all part of a bigger system of systems.

Or maybe my original opinion was right, and it would be simpler to just use the word "system." Thoughts?

Toyota's Problems

I've been deliberately quiet on the topic of Toyota so far, but I do want to offer a few comments on their recent recalls & troubles.

See, Toyota is the poster child for Lean Six-Sigma, process-centric operations. In fact, before it was called "Lean," it was the Toyota Production System. As I understand it, this approach to manufacturing is designed to prevent the very quality problems we've seen all over the news lately. Clearly, it failed.

Regular readers of this blog know I'm not a big fan of process-centric approaches to work, particularly in non-manufacturing situations. However, I'm not all excited to see Toyota do a public face plant, nor do I see this as proof of some deep-seated flaw in their method. It would be a huge mistake to read recent headlines and conclude that this specific failure means Toyota, Lean or process are universal failures. Yes, it failed. But that doesn't mean it will always fail. There's a big difference between "didn't work" and "can't work," or between "can fail" and "will fail."

So let's not rush to paint this failure as an endemic failure, a fatal flaw in Toyota's overarching philosophy. It would be entirely unjustified to use Toyota's recent problems as an excuse for a wholesale rejection of Toyota's manufacturing approach. Yes, something went wrong. Something big. Something that their method was supposed to prevent. But let's not paint with too broad a brush, shall we?

And I would like to suggest that this perspective on failure applies to just about any approach - Lean, FIST, Faster-Better-Cheaper... when a project or product line produced by the method runs into problems, we should probably avoid the knee-jerk reaction of blaming the method (even if it's the very problem the method is supposed to prevent). My friends from the process world might not agree, but in my experience, most of the time problems like this are caused by the people, not the process. And the solution isn't necessarily to abandon the method or fire the people - maybe what the situation needs is more training, more listening, or something else entirely. One more time: there's a big difference between "can fail" and "will fail."

Bottom line: Toyota's track record is actually pretty good. Their manufacturing approach works well - most of the time. But it's not perfect, and neither are the people involved. And while I'm still not a big advocate of a process-centric worldview, I don't see the current situation as proof that their approach is completely busted.

SECDEF on MC-12 (Project Liberty)

The MC-12 "Project Liberty" project is a remarkable ISR aircraft. A modified C-12 Huron, the MC-12 team just won a pretty big award at the AF Acquisition Leadership Forum this week.

At the presentation ceremony, they played a short video clip, in which the Secretary of Defense said the following:

"Your work proves what industry and the military can accomplish together. And it reminds us that new platforms can be developed, built, and deployed in a short period of time – and the best solution isn’t always the fanciest or the most expensive."

It's from a speech he gave on 31 Aug 09, and it's just about a perfect summary of the FIST concept. The MC-12 came together very quickly, inexpensively - and used proven, mature technologies that were put together in an interesting way to create something that's more than the sum of its parts.

I think it's cool the AF did this. I think it's doubly-cool the AF rewarded the team behind it. Hopefully other projects will take note that, in the words of Sec Gates, "the best solution isn't always the fanciest or the most expensive."

Too Early, Too Late

I recently heard someone explain that project leaders are being held accountable to the cost estimates that are produced at "Milestone A" (i.e. VERY early in the project). This was considered a Bad Thing, because MS A is so very early in the project timeline.

Yes, there's something silly about setting a cost estimate in stone before very much is known about the project. But at the same time, perhaps the problem isn't necessarily that we're doing our cost estimates so early. Maybe the problem is that we're delivering the system so late! Go ahead and do your cost estimate at MS A. If you then deliver the system 1 or 2 years later, you'll probably be fine. A good cost estimate can probably survive the passage of that much time.

Sure, if it's a 10 or 15 or 20 year project, that initial cost estimate is bound to break down. But if the distance between estimate and delivery is too long, delaying the estimate isn't the only way to make things better...