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...

Prototyping

In a recent discussion about the FIST (Fast, Inexpensive, Simple, Tiny) approach, someone pointed out that FIST works well if we're developing prototypes.

Yup, it does. But that's not the only thing it can do.

In fact, the US Navy's Virginia class submarines are a great example of an operational system that is, in an absolute sense, kinda big and expensive, while still being quite FISTy. And when I say FIST, I'm talking "delivered 8 months ahead of schedule and $54M under budget."

So yeah, the FIST approach can result in a system that is simple and inexpensive in an absolute sense. It can produce a prototype that isn't supported by any sort of logistics tail, isn't well tested, etc. Sure, we can do that. But FIST can also produce fully-operational nuclear submarines. Want to read more? Check out More For Less, from the Navy's Undersea Warfare magazine.

Rambling Thoughts On Failure

Failure isn't good.

I don't mean nothing good can ever come from a failure. I certainly don't mean all failures are the same. I'm just pointing out that the word "fail" means something, and it's not a positive thing. Redefining failure as something good, no matter how well intentioned, inevitably means we end up talking about something else.

Now, there is real value in recasting a particular situation as something other than a failure. Call it a learning experience, an investment, an education - great! And there's much wisdom in finding goodness in a failure experience. But let's not treat failure itself as something greatly to be desired.

Nobody wants to fail. We want to succeed. Unfortunately, a certain amount of failure is inevitable. But the $1M question is "How much failure is enough?"

NASA's Faster Better Cheaper initiative had a 90% success rate for its first 7 years. Then in 1999, it had a 20% success rate, for a grand total of 62%. For unmanned space missions, the sweet spot is probably somewhere between 90 and 20% (preferably closer to 90, right?). But where? I don't have an answer on that. All I know is that if you can't tolerate failure, then you absolutely deserve every mediocre ounce of "success" you achieve.

Weird Wednesday: The Wright Sister

Did you know the Wright Brothers had a sister? Well, they did - and she apparently played a vital role in their success. She's even been called "the third Wright Brother."

I know! Weird, isn't it? We've all heard of Orville and Wilber - but how many people know about Katherine Wright? My fellow NPR listeners probably know this already, but in case you missed that broadcast, here's some more info:

There's a fair amount of controversy over how influential and involved she was in the airplane business. Some commentators say she was the real brains behind the whole operation, others say she was basically their housekeeper - I'm inclined to guess it was something in between. Apparently Orville & Wilber were introverted (engineers? introverted? No!), and she helped do a lot of the publicity & interpersonal

I did confirm that she received the legion d'honneur from France - one of very few women to ever receive this recognition.

Anyway, I thought that was an interesting tidbit from the history of aviation. Just goes to show that the history books don't always capture the whole story (No! Really?)

Palantir FIST

I saw this ad on the wall at the Pentagon Metro stop and had to snap a photo (even tho I think there's a sign around here somewhere saying no photography - oops!). But such a bold statement - 5% of the cost, 1% of the time - man, it doesn't get much Faster & Cheaper than that. True or not, I find it encouraging that they're appealing to the Fast and Inexpensive values. Definitely a nice change of pace from some of the "look how complex and cutting-edge we are" ads I so often encounter.

I don't know much about Palantir Technologies, but their website makes it sound pretty cool. It's an open platform, which is in itself a great start. I should probably spend a little more time checking it out. For now let me just observe that there's something simultaneously cool and creepy about the a company that names itself after the seeing stones from Lord of the Rings.

The FIST Handbook

Writing magazine articles, as I have done for several years now, requires a significant degree of restraint and summarization, because there’s only so much you can say about a topic in a couple pages. Inevitably an article writer is forced to gloss over certain nuances, omit interesting sidelines and neglect many possible sources. It goes with the territory.

I’m not complaining about this – I chose to write short magazine articles, and I happily accept the restrictions of my chosen medium. But it is something I’m always aware of as I write. It’s an interesting challenge to make sure the article covers the essentials, as honestly and completely as possible, without giving in to distractions or unessentials. And yeah, sometimes I struggle with the necessity of leaving out stuff that I'd like to include, facts I'd like to mention and nuances I'd like to explore.

Over the past few years, I realized that many of these articles, as limited as they are, have become part of a larger story. It occurred to me that I’m not really just writing a series of articles – I’m actually writing a book, but I’m publishing it 2500 words at a time. That doesn’t mean every article I write is part of this "virtual book," but I have come to view many of my articles as chapters in a larger opus.

So, I've collected a bunch of the related articles into The FIST Handbook. When you put them side by side like this, they ARE able to investigate, explore and address many of the nuances and interesting sidebars of the bigger picture. Each article stands alone, but I'd like to think that when you put them all together like this, the result is greater than the sum of its parts.

Hurray For Access!

For those who haven’t heard, apparently the Pentagon is going to let the defense community get access to online social media sites like Twitter, Facebook and YouTube!

Now, I’m not going to claim all the credit here, but I did co-write an article back in October titled Twitter Is Mission Critical which called for precisely this decision. I’d like to think that helped nudge things along at least a little. Even though it probably didn't. But hey, a guy can dream, right?

Actually, the Pentagon did a 7 month study of the issue, and supposedly THAT’s what convinced them to make the change. Whatever the reason, I’m happy to see a more open and thoughtful approach to one of the most important & exciting segments of the IT world.

Now it's just a question of how long before the new policy gets translated into actually allowing access. Standing by...

Weird Wednesday: Flags

Welcome to the Branding Issue of Weird Wednesday!

Did you know that the Netherlands and Luxembourg have the same flag?

Ok, that's not exactly true. The length-to-width ratio is different (Luxembourg's is longer/narrower), and the color is a bit different (Netherlands' blue is one shade darker). But these are only really noticeable if you put the two flags side by side. Show one alone and most people would be hard pressed to tell whether it's from Holland or Luxembourg.

Now, it would be one thing if two countries from the other side of the world had the same flag. That could be because they just didn't know about each other when they designed their flags, but surely Luxembourg had heard of Holland and their red, white and blue striped flag. I think they're not too far from each other, right? I could also understand if the flags were ancient traditional banners - but Luxembourg didn't adopt theirs until 1972! The Netherlands has used theirs since 1572, but didn't make it official until 1937. Still, they seem to have dibs, eh?

My point? Brands & symbols matter. They should probably be distinctive, unless you like being mistaken for someone / something else.

Who To Tell?

There seems to be a divergence of opinions as to how change happens in organizations. Some people are emphatic that it only comes from the top. Senior leaders are essential to driving any meaningful change - you've got to get their buy-in and support or you're finished before you even begin.

Others are even more emphatic that grassroots is the only way to go. The bottleneck is at the top of the bottle, they like to point out. Ignore the generals, ignore the CEO's - talk to the practitioners, the front-line people, the ones who actually do the work. They are the only ones who can make real change happen.

And lately I've been on the receiving end of well-intentioned advice from both ends of the spectrum. Some people want to know what the senior leaders think about my change-oriented ideas. They recommend I get in to see as many top-level types as I can. On the other hand, one person advised I actively avoid the top leaders (and others implied as much). What's a guy to do?

Well, I think I'm going to keep doing what I do. Talking to whoever will listen, and not expecting any one person, group, category or position to be the Magical Key to Successful Change. I should admit I'm more optimistic about grassroots change than top-down, but I've got to acknowledge the importance of both...

Proximity Matters

The aforementioned MG Myles said something that really stuck in my head (well, he actually said several things, but I'll write about this one). He said:

Proximity Matters.

One of the keys to his teams' successes, as part of the whole "we work hard at working together" mantra, was to put people side by side. The user, the contracting officer, the engineer, the money person, the inspector... bring all these people into a common area, let them get to know each other and work together, and you'll find that they can get stuff done faster, cheaper, simpler (hey, where have I heard that before?).

That's one of the real benefits of the FIST approach, is that it makes proximity possible. When you've got a huge team, scattered across the country, it's virtually impossible to get everyone into the same room at the same time. But when you've got a small, co-located team, I've found that communication gets clearer & more reliable. There's more trust and respect. More willingness to help and compromise. There's better understanding and a greater sense of belonging.

These things all matter tremendously for system development projects, even though they're not taught in engineering schools.

One more time: proximity matters.