In yesterday's post, I joked a bit about the term "waste elimination," giggling at the connection between Lean's main focus and a bodily function. But the more I think about it, I wonder if there is indeed a connection?
Sometimes Lean's fixation on waste strikes me as almost pathological. There's a focus on controlling things that borders on being what Herr Freud might call anal retentive. Does anyone else think "perfectionism and a compulsive seeking of order and tidiness..." describes the general zeitgeist of the Lean world? 'Cause that's actually from a definition of what it means to be anal.
I ask these questions with some trepidation, not seeking to malign, make fun or insult anyone... nor to excuse myself from my own psychological fixations and shortcomings. And I'm also not saying I buy into Freud's whole theory of psychosexual development. I'm just wondering if the word choice is more than a coincidence. Might it represent an unconscious aspect of the Lean proponent's psyche? Because if the focus on eliminating waste is indeed connected with a particular stage of psychological development, might that imply that there is a more mature approach further along the spectrum? Perhaps something that accepts messy creation instead of pursuing efficiency and tidy expulsion of waste?
Guys like Gordon MacKenzie and Richard Branson are among the least anal retentive guys I've ever read about... and their approaches to work are worlds away from Lean (as I understand it). They're messy. Wasteful even. And joyful to a degree that is absent in Lean circles. And oh yeah, they're profitable too.
According to this article, Toyota's Chief Engineer Taiichi Ohno "created the seven wastes." Sort of makes him sound like the evil character in a fairy tale. ("And then, the hero had to cross the Seven Wastes."). The writer probably should have gone with "identified" instead of "created," but maybe that's just me. And because I'm still a 12-year-old in my head, I giggle a little bit every time they talk about the importance of "eliminating waste." (he he he).
Ok, I do have a point, so let's get to it. One of the seven deadly wastes is "transporting." Apparently, according to this Lean approach, "moving your product from one location adds no value to your product."
Really? To quote a source of wisdom far more ancient than the Lean Oracles, "a bird in the hand is worth two in the bush." I think this old English proverb means, among other things, that location matters. We might even say that location adds value. Sure, I like to get free shipping when I order stuff, but I am willing to pay for shipping when I need to, because the right thing in the wrong location is of very little value to me.
How about an example? I'd pay more for a pizza that's in front of me than a pizza that's a hundred miles away. And whoever moved that pizza from far away to a location within arm's reach has increased the value of said pizza. Hey, when's lunch?
Am I missing something here? Sure, transportation of materials from point A to B and then back to A might be wasteful, but just because some movements do not add value doesn't mean allmovements add no value. Seems like someone's fallen for a logical fallacy to me. I just don't see the evidence that moving a product never increases the product's value. In fact, I'm pretty sure location is the ultimate value. So transportation not only creates value, it unleashed all other sources of value. We might almost say transportation is the source of all value.
I'm hoping someone (Mark?) will enlighten me as to this particular aspect of waste. Did I misstate the case? Or did the article I referenced miss the boat? I look forward to hearing your thoughts.
I recently had a chance to have a little mentoring session with an old friend. We'd worked together a few assignments back, and he is now at somewhat of a career crossroads. So he stopped by and we spent about an hour talking about his past, his aspirations, his options... and I look forward to seeing what direction he ends up taking.
This meeting was probably the most important thing I did at work all week. Taking time to listen to and consult with a fellow traveler, to be there and help him figure out what he wants & where he's going... man, that's some crucial stuff. Of course, it'll never show up in a weekly status report or a metrics chart. Its impact on operations isn't directly measurable, particularly since this guy isn't part of my current organization. It might even be called "waste" in certain frameworks.
But for any who are tempted to call those 90 minutes "waste," let me respectfully suggest that such a label devalues people AND overlooks the positive contribution made by activities like mentoring. If you really need a term that means "anything that does not add value to the product," fine. But maybe "waste" isn't the right word...
We got some great discussions going on the previous post, and I'd like to continue talking about one particular point. Specifically, the human side of this thing.
When I first read the "Red is good, green is worthless" article, the part that really stuck in my head was the horrifying scene where a group of employees was described as going from "proud and excited" to "devastated," thanks to a brief comment by Mr. Watanabe.
Now, I don't know if that actually happened. With all due respect to my friends in journalism, I am well aware that reports of events aren't always accurate (and as a writer myself, I'm sure I've mis-written a scene or two). But whether it happened quite that way or not, the writer was clearly holding it up as a sign of Mr. W's keen insight and wisdom, his ability to see through the "worthless" status report and identify a hidden problem.
Let me be clear - the scene as written describes a travesty, a failure of leadership that most likely has negative implications for the organization - and certainly had a negative impact on the people involved. A good leader - a real leader - would have recognized his employee's enthusiasm and figured out a way to redirect it as necessary, without emotionally violating the people. They would have walked away with energy, direction and insight. And if he did leave them feeling devastated (deflated, demoralized, disrespected), the real story would have been the way he acknowledged and made amends for his mistake.
See, leadership and management isn't about metrics, stoplight charts, production rates or even profits. It's about people. It's about taking care of them, encouraging, empowering and equipping them. I don't think it's much of a stretch to say it's about loving them. And it really bugs me to see a story about a "leader" who puts people down (aka a tyrant) being used to show how wise and insightful that leader is. It's even worse when the writer glibly glosses over the scene where people get hurt, and instead focuses on which color he likes better.
Bottom line: the real lesson in that story has nothing to do with metrics and everything to do with love.
I recently came across this article about "lean metrics," which basically makes the case that reporting a status of Green ("things are good") is unacceptable, because it gives the lean guys nothing to do. The only good value for a metric is Red ("things are not good"), and if anyone reports a Green status, you should "send them back to the drawing board." Wow, I disagree with it so completely.
Yes, whitewashing (green-washing?) a program is bad. It's not helpful to report that everything is good simply because you haven't dug deep enough to find the actual problems. Deliberately hiding problems is even worse. But this article stinks of a hammer in search of a nail. "If you are green, they don't know where to focus improvement efforts." Um, isn't it possible to be green because you DO know where to focus your improvement efforts? Maybe the status is green because you know what you're doing and things are actually going well. Let's not assume that a set of green metrics can only be produced by dishonest or superficial assessments.
The article also makes Toyota's Mr. Watanabe come across as a monumental jerk. Sure, it's possible he responded to a set of Green metrics by saying "no problems, must need no managers" with an unmentioned twinkle in his eye. Maybe he was trying to be funny. For his sake, I'm going to assume that's the case. I'll just ignore the writer's commentary about how his comment "devastated" the managers who had previously been "excited and proud." There's something to be said for challenging people's assumptions and encouraging them to leave their comfort zones, but there's no excuse for devastating them. I wonder how effective they were after this meeting. I'll bet their metrics turned quite red for some time to come.
Bottom line - red-washing a metrics report is just as bad as green-washing it. Good metrics are accurate, timely and actionable. Green or red isn't the question. The real quality of a status report is based on whether it's honest, not what color it is.
I've been hearing a lot about the proverbial "70% solution" lately. It's usually in the context of having to chose between "a system that delivers a 70% solution and a system that provides a 100% solution." But let's take a look at what we're really talking about here.
It turns out, we're not choosing between a partial and a complete solution. It's actually a choice between a partial solution and no solution at all. And to be even more precise, we're choosing between a series of partial solutions and no solution.
Here's how it works. A developer can't give you everything you need right now. But they might be able to quickly deliver a system that does SOME of what you need... followed by an additional increment / block / spiral / release that does MORE of what you need... followed by another increment, and so on.
So let's keep in mind that the partial, 70% solution isn't the whole story. It's just the first increment. As a dedicated imperfectionist, I'm pretty cool with the 70% solution to start with. And as a guy-in-a-hurry, that's at least partly because the 70% solution is generally available MUCH faster than the 100% solution. It's cheaper too. But if you do it right, it's also not the end of the story.
On Saturday, 5 Dec, DARPA launched a contest in which they placed 10 red weather balloons at locations across the country. If you're the first one to submit the lat & long of all 10, you get $40,000. That's right, 40-grand just for finding 10 red balloons. Dude!
The catch is that submissions are due by 14 Dec - that's a little over a week to criss-cross the whole country and find these balloons. The idea is that you can't do it yourself. DARPA is trying to explore the impact of social networking and cross-country collaboration in the field of information collection. Which means whoever wins will probably have to share that $40K, but it's still a nice chunk of change.
It's always fun and fascinating to see what DARPA is up to.
A British medical researcher (and eventual Nobel Prize winner) named Edgar Douglas Adrian was doing some research involving the toad retinas. Hey, who doesn’t love experiments involving toads, eyeballs and electricity? OK, so having attached electrodes on the poor toad’s optic nerves, Dr. Adrian was surprised to hear repeated noises coming from the loudspeaker attached to an amplifier that was being fed by those electrodes. I don’t know what sort of experiment involves wiring toad eyeballs to loudspeakers, but there you go.
Anyway, the room was dark and the sounds were unexpected. Like a good scientist, Dr. Adrian set about to figure out what was causing these noises. He writes “It was not until I compared the noises with my own movements around the room that I realized I was in the field of vision of the toad’s eye and that it was signaling what I was doing.” The year was 1928, and this experience proved the presence of electricity within nerve cells.
The point of this story is that sometimes the most important discoveries come when we're looking for something else, so it's important not to be so focused on the problem you're trying to solve that you miss the problem you should be solving. As the great American philosopher Ferris Bueller once said, "Life moves pretty fast. You don't stop and look around once in a while, you could miss it."
One of the questions people sometimes ask about the FIST approach to systems development is about procedural waivers.
"What rules, regulations's and processes and procedures do we need waivers for, in order to do this FIST thing?"
I have to admit, I'm always a bit confused by that question.
See, FIST is a set of values that is designed to influence our decision making and organizational behavior. It says "It's important and good to be fast, inexpensive, simple and tiny." There generally aren't any regulations or requirements that forbid such a stance. Sure, some rules and reg's are less than helpful, and some interpretations of rules point us in the opposite direction of FIST... but in the latter case, it's generally because our values are pointing in that opposite direction anyway!
The bottom line is that FIST can be applied under just about any framework or set of guiding policies. Strictly speaking, no waivers are necessary and nothing is really stopping us from opting for the faster, less expensive, simpler and smaller option. Having said that, FIST can also be applied TO just about any framework or set of policies. We could simplify, shrink and accelerate our policies - I think that'd be good for everyone (because I think the FIST values are good).
And yeah, I'm sure just about every technology development environment has some policies, regulations, etc that are un-FISTy. But do you need a waiver or some sort of official permission to make decisions these ways? No - if you're making design decisions (about documents, technologies, organizations, etc), you can make them with FIST.
Had a great time at Disney over Thanksgiving - but instead of getting home at a civilized 3:00 on Sunday afternoon, we pulled into the driveway at 1am Sunday night / Monday morning. Why you ask? Because of a compressor that decided to let all its smoke out (and every engineer knows that computers, cars and other devices run on smoke, so it's important to keep the smoke inside. If the smoke gets out of the computer/car/space telescope, it stops working... and it's very hard to put the smoke back in).
So... less time + more exhaustion = a lack of posts for my friends here at RPL.
But I'm working on it, don't worry. More Rogueishness coming up soon (and for the record, I was using the word Rogue way before Gov. Palin picked it for her book).
This is a reprint from my own blog, but I think it's applicable to the audience here.
I devised a new platitude that I’ve dubbed Gabe’s Axiom:
Engineers make stuff work. Designers make stuff useful.
I did so in response to my overall experience as an engineer to date. This thought coalesced recently while reading the book The Design of Everyday Things. Engineers love making and using gizmos and gadgetry and they love figuring out how to use a new widget. Therefore they find it frustrating when Joe user isn’t as passionate about learning all 15 ways to shut down a Windows based computer. I’ve often seen this frustration manifest as rebuke when a layman has trouble using equipment in the shared workspace (office copier, coffee pot). I’m guilty of it myself. I’d posit that a great many engineers don’t design with elegance or ease of use in mind. Making stuff work is their MO. However, the gizmos that are most useful are ones that are intuitive. It’s not the users fault if a gadgets operation isn’t readily apparent. True engineering involves synthesis and distillation with an eye toward elegance, not tech savvy alone. It’s the simplicity on the other side of complexity. It’s more challenging, but definitely more fun. After all, if it isn’t useful then what’s the point?
And now, a brief commercial message and a peak behind the scenes of the Rogue Project Leader blog.
For those who don't know, in addition to this blog, I write childrens books. I started writing them as Christmas presents for my own two munchkins, but they are available at Amazon and RoguePress if you're interested.
This year's book is Skyler and the Shadows on the Sun. It's a cool little fantasy adventure, and it's been eating up a fair amount of time lately. I just finished it (whew!) and am now waiting to receive my final "author's review copy" before making it available for purchase.
I mention this because, while I have lots of ideas for upcoming blog posts, I'm a little short on words for the next few days. And I'm planning to take next week off because of Thanksgiving. So I'm hoping to post something here again by 30 Nov. In the interim, maybe you could peruse some previous posts.
I don't recall exactly when I started carrying around a little notebook in my pocket, but I know it was a long time ago. I always feel a little bit naked anytime I inadvertently leave the house without one. Brrrr - I hate when that happens.
My first pocket notebooks were green AF-issue Memoranda jobs, that flipped open like a reporter's notebook (Federal Supply Service #7530-00-243-9366 - no kidding). I still have a few blank ones, but have no desire to use them.
At some point, I went with hardcover Moleskine pocket notebooks for a while, then made the leap over to the Moleskine Cahiers (smaller notebooks, with soft covers). It took me a while to get used to the smaller cahiers (and I don't like the word "cahier" - it doesn't exactly trip off the tongue), but eventually I was won over.
Then I heard about FieldNotes brand notebooks on Dan Pink's blog and have been using them for a couple years now. They aren't hugely different than the Moleskine Cahiers, but I like the story & vibe of FieldNotes. Plus, it's a better word.
Despite my history of changing brands, I have to admit I feel a little bit funny about a recent purchase. At the Newseum in DC, I picked up a 3-pack of WritersBlok notebooks. A set of 3 (80 pages each) cost $6. In contrast, a pack of 3 FieldNotes (48 pages each) costs $9,95 and a 3-pack of cahiers from Moleskine, 64 pages each, go for about $7.
I haven't used my new WritersBlok notebooks yet - still have plenty of pages left in my current FieldNotes. But it'll be interesting to see what it feels like to try a new brand.
When I talk with people about using the FIST (Fast, Inexpensive, Simple, Tiny) approach to project leadership, we inevitably arrive at a point where the importance of talent comes up. It's not uncommon for people to experience an epiphany, where they say "Ah ha! The FIST approach means you need to have good people working on the team."
To which I can only respond "Yup." (At this point, the process-oriented types and the misanthropes generally write the FIST concept off as unachievable).
From here, the conversation often heads in the direction of objections like "But talent is rare!" and "Good people are hard to find!"
To which I once again reply, "Yup."
Yes, FIST requires a small team of talented people. Yes, talent is rare, but with FIST, you only need a small number of excellent people. So that's something.
But there's more. The other cool thing is that across a large organization or a large portfolio, FIST actually increases the pool of talent. How does it do this incredible feat, you might ask? Well, let me tell you.
FIST is an iterative approach, best used as part of a portfolio. It's about large numbers of small projects. This means you're creating more opportunities for more people to get relevant experience and to expand their practical, professional education. More opportunities to lead. More opportunities to learn. And, by keeping schedules short, more opportunities to see the end of the story (which is a key element of learning from experience). All of this combines to make your people more talented. And that's pretty cool.
In contrast, if you've only got one or two big projects, you're providing fewer opportunities for your people. Fewer opportunities = less learning = less development = less talent.
Sure, FIST requires talent. But it also helps produce it. I think that's pretty cool.
It struck me the other day that extreme precision is frivolous.
Engineers in particular tend to overvalue precision. I have three engineering degrees, so I think I can speak with some authority here. And I can attest to the fact that when engineers (and others) use extremely precise data, they are often overstating the value of their analysis. Just because they measured the distance between A and B to the micrometer doesn't mean they measured it in a meaningful way.
In mathematics, we talk about "significant figures," but we probably are not sufficiently aware of the presence of "insignificant figures." That is, 3.1415926 is pi to 7 "significant" figures... but depending on the application, those last 5 digits may or may not actually be significant.
So don't tell me it's exactly a 3-minute walk from here to there, when you know full well it takes "approximately 5 minutes." I don't want to hear that the wind is blowing at 42 knots, when clearly it's gusting to roughly 40. And really, finishing 33% of a project isn't any different at all from finishing 30% or 35%.
Don't get me wrong - I like frivolity when it's fun, and I like precision when it's necessary. But I have no interest in the grim frivolity of unnecessary precision.
I admit I'm a wild-eyed optimist - it's probably as much by my emotional / biochemical / psychological predisposition as anything, but the older I get, the more optimism becomes a matter of choice and less of a default position.
My optimism isn't entirely accomplished in the absence of reasons, but it's not solely based on reason either. If that was the case, I'd be a realist, right? Of course, I think optimists are the only true realists, but that's a discussion for another time.
But whatever the origin, I think optimism is important, because it drives change. If you don't think change for the better is possible, you're unlikely to work in that direction, and you end up with a self-limiting, self-fulfilling prophecy.
So from a purely pragmatic perspective, I think optimism works. But I also think optimism is true. We can make things better. We can fix problems. And specifically for the context of this blog, we can improve the way we lead system development projects.
That just might be the whole point of everything I write...
Two of the most exciting new aircraft projects are the MC-12 Liberty and the C-27 Spartan. Notice anything unusual about those designations? Neither one is an F or a B! Maybe this has something to do with the fact that the Chief of Staff of the AF is a C-130 pilot, but whatever the reason, I think it's awesome (and it's about time).
The MC-12 has an ISR mission, and they started development last summer. According to a Global Security article, "SAF/AQ tasked Big Safari to procure and modify aircraft as quickly as possible." They're flying operationally now. Nice!
The C-27 is a "mini-Herc" (a smaller version of the C-130 Hercules). It too is a rapid development effort based on a mature airframe. Very, very FISTy.
Paraphrase of something overheard at a recent conference: "Even though it was complicated, they still had problems."
I believe this particular statement was said tongue-in-cheek, but it points to a belief that is seriously held by many technologists and program managers - namely, that making something more complicated makes it better.
That is precisely the attitude that caused me to write The Simplicity Cycle (incidentally, it has now been downloaded over 1500 times! How cool! You can get your free PDF at www.lulu.com/RoguePress)
There is a related belief, that adding money and extending the program's schedule makes things better. And the truth is, that just isn't the case. I'm quite convinced that 99% of the time, the worst thing you can do to a project is give it more time and money. Far better to scale back the requirements (or push them to a future increment).
The latest issue of everyone's favorite defense technology magazine, Defense AT&L, is now available online for your reading pleasure. My contribution to this issue is titled There Are No Facts About The Future, a fun little piece full of pseudo-faux math and tongue-in-cheek pretend science... but very real ideas and suggestions about how to do this crazy little thing called program management (and there's some real data in there too, just to mix things up a bit).
You might also want to check out Let's Fix It, by Scott Reynolds. A man after my own heart, Prof Reynolds doesn't pull any punches.
As an added bonus, DAU changed the magazine's URL - not just for this issue, but for the whole archive! So, if you've got any old bookmarks or links, you'll get a 404 page-not-found message. But Google has apparently caught up with the change, which is cool and impressive.
Apparently there are some budget cuts looming over the horizon for the DoD. The article excerpt below describes the situation in very gloomy terms, such as "painful adjustments," "pressure" and an absence of "relief." Gosh, sounds like an unsuccessful trip to a chiropractor to me.
I think it's actually good news. Sure, I'm a glass-is-half-full kinda guy to start with. I'm also convinced that constraints foster creativity, and times of financial belt-tightening tend to produce (nay, demand) innovation. Those of us who hold to the FIST value set should be cheered and encouraged by this budgetary development.
So I'm all for reductions in spending on new weapon systems. Not for political reasons, but for reasons that are almost purely technical. Yes, it's possible to cut too deeply into the budget, but as far as I can tell, we're nowhere close to that limit. It'll be interesting to see what kinds of essential innovations will be produced once the budgets get a bit smaller.
TheHill.com October 28, 2009
Reed: Pentagon Should Prep For Cuts
By Roxana Tiron
Sen. Jack Reed (D-R.I.), an Army veteran and senior defense authorizer, on Wednesday said that the Pentagon will have to face "painful adjustments" in its budget.
Reed, the new chairman of the Senate Armed Services Seapower panel, indicated that weapons modernization will suffer in years to come as a result of military operations in Afghanistan, but also because of the economic crisis.
"There is going to be significant pressure on the defense budget going forward. [...] I do not think there is going to be much relief on the personnel front ... so the likely path is to push and delay platforms that you do not think are absolutely essential," he said. Additionally, he said, weapons programs that continue likely will have to be reduced and bought in smaller numbers, in what will be "painful adjustments" for the Department of Defense.
Apparently my theme this week has something to do with measuring progress (I didn't plan to have a theme - it just sorta happened). While previous posts have mostly focused on the measurement part, let's take a look at the "progress" part today.
Specifically, I'd like to talk about priorities and values. What attributes do we consider desirable for our projects? What are our measures of merit? What indicators give us reassurance that we've got a good program?
Regular readers of this blog know I think it's "important and good" for a program to be Fast, Inexpensive, Simple and Tiny. I apply these values to every part of the program, from the requirements documents and system architectures to the organizational structure and operational processes. My research indicates that the FIST values not only support programmatic success (i.e. delivering on time), but also operational success (i.e. performing well in the field).
The funny thing about values is they are often assumed, not discussed. I seldom see explicit statements about a project's values, but there are plenty of indicators that show what the project leaders really think are important.
Look at any number of recently cancelled projects, and I think you'll find that nobody thought it was particularly important for the thing to be developed quickly or inexpensively, or for it to be simple. Rather, complexity is often treated as a sign of sophistication. Big budgets are a sign that the system is important. Take a long time to build it? Great! That means you're clearly doing a good job and exercising due diligence.
Here's the thing: when we aren't deliberate with our values, when we don't examine and discuss them, we run the risk of being guided by values that are counterproductive and ineffective. I'm not saying that FIST is the only value set that works - I'm just saying we should be purposeful with our values, and should be aware of the way they shape our decisions and behavior.
It's a great read. He points out that we come up with budgets and schedules "at a time when least is known about the project," then measure success based on the degree to which we live up to those guesses. Anyone else see something funny about that plan?
I would simply add that the longer the project, the less we know about it on Day 1 (or on Day -100, which is probably when we actually put the budget & schedule together).
Just one more reason to keep our schedules short... along with a compelling argument that the way we measure progress is often misleading, even when it's "accurate."
As a follow-on to yesterday's post, I'd like to say a few words in praise of something called Earned Value Management (aka EVM).
EVM is basically a way of measuring progress in terms of actual work accomplished, not simply in terms of the number of discrete tasks that have been marked Done. It seems to me that EVM is just another word for honest accounting.
It boggles the mind that a project leader would use anything other than EVM to measure, assess and report progress towards their goals.
Some people try to say it's too complicated, too cumbersome and frankly too dang hard to do EVM. I've also heard that EVM isn't well suited for small projects, but in fact there are ways to do simple implementations, without relying on excessive overhead. For that matter, the simple implementations can probably be useful even on big projects.
Now, applying EVM to certain types of research projects, where future work paths are unknown, requires a slightly different tack... but it's possible to use some of the principles even in this area.
EVM - it's not just for breakfast anymore. Check it out!
I recently read a quote that said something along the lines of "95% of acquisitions are done on time, on budget."
My first thought was - huh? What about all the GAO reports that say (over and over and over again) that military acquisition projects take too long, cost too much, and under perform when fielded.
And then I realized that it's entirely possible for both to be true.
When we say a project comes in on time & on budget, it sounds like a good thing. But what if it had too much time & money to start with? It's possible to spent too much money AND be on budget.
And what do we really mean by "on budget." Does that mean we delivered the stated capability using the original amount of funding? Or are we taking credit for staying under a budget line that has increased over the years, as additional funds get added to the baseline (because we've increased the schedule, added requirements, etc)? If we define "on budget" broadly enough, then I'll bet almost everyone is on budget. Maybe even 95% of projects.
But there's more to this story. The idea that 95% of projects are on time & on budget doesn't actually mean as much as it might seem. Imagine a portfolio of 10 projects. Nine of them each cost $100, and each deliver on time, on budget. The 10th project was supposed to cost $100,000, but ended up coming in at $150,000. Do we praise this portfolio for being "90% on budget," or do we acknowledge it spent $50K more than planned? I'm thinking the latter assessment is more accurate.
The flaw in the 95% on budget reasoning is that it is measuring performance on a per-attempt basis, using a straight count of the number of projects. What we should be measuring is the performance of our dollars (i.e. the proverbial bang for the buck).
Similarly, let's say we have a project that has 10 steps. Nine of the steps each take one day to accomplish. The 10th step takes a year. At the end of nine days, if we say we're 90% done with the project, because we have finished nine of the steps, we're seriously misrepresenting how much work has been done (and how much is remaining).
Statistics are funny things. It's entirely possible for a statistic to be true and misleading all at once. It's important to be careful and make sure the things we're measuring and reporting provide an accurate representation of the situation.
In the summer of 1992, when I was still a cadet, I used to go running with an Army Captain whose in-laws live across the street from my parents. We've sort of kept in touch over the years, mostly by bumping into each other each Christmas as we're unloading our respective cars.
When I was stationed in Rome NY, he was at Ft. Drum (also NY), and he brought me up to visit and shoot some artillery (I even got to keep the shell!)
Anyway, I ran into him in the Pentagon today... 17 years after those training runs. He's a Colonel now, and we discussed our various jobs. He mentioned that he's working on acquisitions, which is my specialty. I mentioned that I have this FIST concept I've been working on for a while, and we talked about that a little. I happened to have a print out of a draft of an article I've been working on, and I gave it to him.
It turns out he now works for the Army 3-star general I quoted in the intro to the article. He said it sounds like the kind of thing this general would be interested in. So... he's going to take a closer look and I might get a chance to pitch FIST to the Army acquisition guys.
Little did we know 17 years ago what seeds were being planted, and what future doors were being opened.
One of the nice things about commuting (ok, it's the only nice thing about commuting) is that I get to do a lot of reading these days. Lately, I've been reading novels - I really enjoyed the Psych books by William Rabkin. But I'm thinking I'd like to dive into some meatier fare.
Any recommendations on some good books to read? I'm looking for stuff that's outside the mainstream, not just the books everyone's reading. Any thoughts from the far end of The Long Tail? Here's the challenge - give me something I've never heard of before...
I've been doing some research into NASA's Faster, Better, Cheaper initiate from the 1990's. It's quite a story, and I must admit I'm stumped as to why FBC got scrubbed.
The results of the FBC missions were fantastic. For less than the price of the Cassini mission, NASA launched 16 mission, including the Pathfinder mission to Mars and the Near Earth Asteroid Rendezvous (NEAR), which no kidding, landed on an asteroid, after collecting 10 times more data than they'd expected. Of those 16 mission, only 10 succeeded, but that's still 10 successful missions for less than the price of a single planetary mission using the "traditional" Slower, Suckier, More Expensive approach (excuse me - I mean, the deliberate, modernist, Scientific Management approach, which never ever fails ever).
The crazy thing is, many people treat FBC as if it was not only a failure, but an embarrassing failure. As if NASA should have known better than to try something so absurd as reducing costs and delays in their pursuit of knowledge and adventure in space. As if 10 successes for the price of 1 is an inadequate track record. As if the data clearly shows we must "pick two," instead of pursuing simultaneous improvements in all three dimensions. I don't get it.
OK, I'm not really stumped. I have my theories about why the approach was rejected. But it's becoming increasingly clear that the rejection and ridicule of the FBC approach has nothing to do with the initiative's actual results, which were admirable and impressive.
How about you? What do you think when you hear the phrase "faster, better, cheaper"?
I recently came across this quote by Fujio Cho, Chairman of Toyota Motors:
“We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems.”
Yikes! Anyone else find that somewhat disturbing? I mean, I've known for a long time that the process gurus really believe a good process is a substitute for good employees, and that process can replace talent and ingenuity. But it's not often the process people get so explicit about it.
Interestingly, Dilbert's pointy haired boss made this exact point on Sunday, saying "As you know, a good process is a substitute for good employees." That line made me laugh out loud - because it's one of those truths that isn't usually stated so explicitly. And I think Adams intended that line to be funny - surely, no boss would make a statement like that to his employees. But there we have Chairman Cho basically saying the same thing.
Now, there's probably a cultural element here. Everyone in America thinks they're above average, and to be described as "average" is an insult around here. That may not be the case in Japan.
But cultural differences aside, I'm not sure it's true that process trumps talent. In fact, I think it's the opposite. Talented people can overcome bad processes. Good processes can't overcome a lack of talent, motivation, initiative, etc. But maybe that's just because my perspective is based in an R&D environment, rather than manufacturing.
So, what do you think about the Chairman's statement? Would love to get your two cents...
Two weeks ago, I mentioned having lots of projects in the works. But now I'm getting hit by crazy allergies like nothing I've experienced since I was a kid. It's making it kinda hard to do just about anything. And that got me thinking about work & humanity.
It occurs to me that when a person is tired, they should probably rest (crazy, I know). When you're not feeling well, when your head is cloudy and you can't concentrate, there's not much point to sitting at your desk - you should probably go home.
But often, we're reluctant to do that, for fear of looking like a slacker. Never mind that you're not accomplishing anything by staying at your desk until "quitting time." Appearances must be kept up. In the minds of some, it's more important to maintain the impression of doing work than to actually do the work (or to do the smart thing and go home).
As for me, I try to be the guy who goes home, boldly and unapologetically. That last 30 or 45 minutes wasn't going to be productive anyway - I might as well go get some rest so I can come back tomorrow (hopefully) feeling better.
Steven Metz writes in his article Small Wars: From Low Intensity Conflict to Irregular Challenges (chapter 16 of Rethinking the Principles of War, Naval Institute Press):
"[A]n array of factors has characterized success for counterinsurgents and counterterorists in the modern era [one of which is]: Adapt at least as rapidly as and more effectively than the enemy. "
How is it possible to act this swiftly using the current DoD Weapon System Acquisition process? Maybe it's just me, but the current system seems too cumbersome, with all the processes and procedures and statutory regulations that must be followed, to achieve the speed necessary to rapidly adapt. I have an idea! What if we focused on being Fast, Inexpensive, Simple, and Tiny? I remember seeing that somewhere.....
I don't get over to the Open NASA blog as often as I should. There's no excuse for it - the blog is fascinating on so many levels (technically, organizationally, humanly). I really should make more of an effort to stop by there more often.
And my new fav writer over at Open NASA is Jen, a senior aerospace technician at Kennedy Space Center. She first caught my eye with a post titled When Failure Is Our Best Option. Insightful, thought-provoking stuff. A little further down the list, she's got a post titled Tracing The Why's, that suggests spending less money (gasp!) if we want to do meaningful human exploration of space.
Here at RPL, we're big fans of people who don't stick to their allocated lanes in life. We're in favor of having lots of crazy hobbies and wide-ranging interests. We think it's a good thing when people are not content to just be good at one thing, and instead branch out and make meaningful contributions in several areas.
Personally, I'm a fan of GK Chesterton. The guy wrote mysteries, histories, travel books, theology, fiction, essays - and had something intelligent to say on just about every topic you can imagine. I also really admire Will Smith, and the way he's done music, tv & movies - comedy & drama. Both guys went way outside the narrow bounds of specialization - and I think that's awesome.
And then there are those who go way beyond diverse writing or different forms of entertainment. Consider the beautiful and talented Hedy Lamarr, a film actress in the 30's and 40's (and beyond, actually), who also has a patent for spread-spectrum, frequency-hopping communication system (and it's quite a story how she came up with it, by the way).
And did you know that William Marston, the guy who came up with Wonder Woman, also invented the polygraph machine? How cool is that?
No doubt people asked Ms. Lamarr what business a movie actor has getting involved with communications technology for the Navy. No doubt people told Dr. Marston that serious scientists don't create comic books. And the world is richer for the fact that they did it anyway.
This is not about being a generalist or a specialist. It's about being a multi-specialist, doing a deep dive into several areas of activity.
How about you? Content to stay in your lane? Or ready to branch out...?
I keep coming back to this topic of presentations. I really think that if we could just have the guts, imagination and will to improve the way we give presentations, we'd find that we could fix all sorts of other problems. If we would spend the time necessary to communicate clearly & accurately, and if we valued telling the truth over making sure the charts are consistent with everyone else's format, not only would a lot of problems be easier to solve - I think many wouldn't even occur in the first place.
But it's tricky, isn't it? If your charts don't look as dense, complex and convoluted as everyone else's, it'll look like you didn't really do any work, 'cause everyone knows complexity is a sign of effort, right? Actually, a simple, clear message takes more understanding, more time and more skill than the jumbled messes we call "finished products."
So, to help get things started, here are a few thoughts and guidelines, in case you haven't picked up Garr Reynolds' Presentation Zen yet:
1) You don't need your logo on every chart. Honest!
2) You don't need a redundant title on each chart either. Really, you don't!
3) Use hand-outs to present details. Use PowerPoint charts to present main topics
4) Limit yourself to somewhere between 1/2 an idea and 1 full idea per chart.
5) Time is always (always always always) the limiting factor (the only limiting factor). It's not about how many charts you use.
Some interesting concepts that come out of asymmetrical warfare strategy talk to the importance of taking advantage of opportunity and agility in maneuvering against an enemy. Often, these principles are linked to the conduct of war as an art form. As an art form, principles devised to guide conduct are not considered immutable or inviolable. One author even states,
The crucial element of its artistic application is recognizing unique contexts, the contingent factors, and the opportunities to create advantage purposely by violating principles or rules when needed. [A]rt accepts the existence of principles and rules, but only as guides. Each case has its own features - which modify the application of the rule, and may even make it at times wholly inapplicable.
- Frank Hoffman, Chap 17, Rethinking the principles of War, Naval institute Press, Oct 2005
If this applies to the messy work of warfare, why not program management? Isn't program management as much an art form as warfare? I think so. Yet too often (if not exclusively), the same defense department that conducts war treats the business of weapons technology development as a precise science to be quantified, measured, predicted and proven. This behavior is as if the human factor of "business" doesn't exist. But it does and with it comes the art of business. A craft that can't be accounted for by implementing rigid processes or precise controls. The artistic practice of business allows for unknowns and flexes to let humans use their ingenuity to solve problems rather than forcing them to stick strictly to the script. The artistic practice of business is attuned to serendipity.
Removing an over reliance on process and procedure is one step toward practicing the craft. Increasing tolerance of failure and allowing deviant practices as a matter of course are others. Anything that puts people back into the drivers seat of business - that's how to practice the art of business.
I recently came across the idea of an "acquisition wind tunnel" that would allow us to test our organizations and projects, to see how streamlined and efficient they are.
I like that imagery... I think. At the same time, I wonder if some of the points of friction and resistance might not be some of the more interesting and productive parts of the project. I guess it depends on how we define friction.
It occurs to me that one person's friction is another person's traction. Similarly, one person's momentum is another person's inertia. So, in this hypothetical wind tunnel, we'd have to be specific about how we distinguish between negative friction and positive traction. And the tricky thing is, the line between friction and traction is probably pretty fuzzy (and it probably moves).
This wind tunnel concept no doubt could be implemented under a Theory of Constraints sort of framework. No doubt the Lean crowd would find that this idea resonates with them. And frankly that makes me hesitant about the whole thing.
At the same time, I do like the idea of setting up some well-defined streams of "wind" that we could point at a project, organization, etc, to assess its flight worthiness. A FIST-based wind tunnel could have real value in identifying opportunities to unleash the creative power of constraints and restraint.
I seem to have more projects than usual in various stages of not done. I think it has something to do with autumn. Fall always strikes me as a time of new beginnings, a time of renewed intellectual activity and productivity.
So, in my stack of current works-in-progress, there's my latest children's novel, the cover design for said novel, the outline for next year's novel, a handful of articles (not just for Defense AT&L), a white paper on "how to implement FIST across the Air Force," a grown-up novel (!) about a guy who accidentally deletes the internet, and the third installment of the FIST comic series.
I was on leave last week while my wife was in TN for a conference, but I didn't get as much done while the kids were at school as I'd hoped to. I'll probably have to go away on a trip of my own to really make a dent on the stack.
I haven't talked about the topic of values in a while, and after some lively discussions with B. Smitty, I figured I'd spend a little time on the topic again, because assumptions about values are at the heart of most of the problems in project leadership (and a lot of the disagreements too).
The values I have in mind are "the things we think are important." In engineering speak, values are measures of merit. They are the signs of sophistication and other desirable attributes (and the context I have in mind is organizations, technologies and processes). This stuff matters because our values shape our objectives, and at the end of the day, values are the yardstick we use to assess whether good things have happened or not.
In my FIST-related writings, I talk about values as the answer to the question "What is important and good?" and I often describe FIST as a values-based approach. It basically says "It is important and good to be Fast, Inexpensive, Simple and Tiny." There are other value sets out there, and mostly they go unstated, unexamined, unconsidered and untested. That's a HUGE problem.
See, if we value complexity (either explicitly or unconsciously), we'll make the system more complicated and think we've done something good - even if it's not actually any better. You see this a lot in PowerPoint presentations - people who think they are effective communicators because they included every word, every comma, every data point and every possible nuance of every diagram in their 800-chart presentation (for their 15 minute time slot). You also see this in over-engineered systems, chock-full of a million good ideas. I'm going to suggest these are examples of values out of whack. Overvaluing complexity drives unproductive behavior.
Similarly, if we think spending a lot of money guarantees quality, we'll feel reassured by a high price tag, even if a smaller price might have delivered better results, better quality. Same thing with time - if we value the slow-and-steady approach, the fact that it took 20 years to deliver a system gives us a warm feeling, even if such expenditures were unnecessary.
So, the questions are: what values drive your project? What values contribute to positive outcomes, and improved operational effectiveness? And to come full circle to the afore-mentioned discussion, when people praise the F-22 as "the most capable aircraft" in our inventory, what are they really praising? What values are driving that assessment? What basis is there for those values?
Frankly, this question doesn't come up often enough in program management circles, which is a bummer because I think it's at the core of the whole discipline.
If there was one thing I could accomplish professionally, one contribution to the corpus of program management practice and theory, it would be to dispell the Myth of Inevitability.
What is this myth, you ask? It's the idea that high tech system development projects (weapons, spacecraft, commercial products, etc) inevitably take a long time, cost a lot and are complex. The myth is expressed in phrases like "better, faster, cheaper - pick two." A corollary to this myth is the idea that adding time and money to the project improves the outcome, as if the problem with our failed system development efforts was that our schedule was too short and our budget too small.
No kidding -that's what they said when the 18 year, $7B (billion-with-a-b) Comanche helicopter was cancelled. They needed more money. They needed more time. Yeah, that would have helped. Right. A similar chorus rises from any number of failed high tech projects. My assessment is that they had too much time & money, not too little. And at the core, they believed that the costs and delays were inevitable, simply an inherent part of this kind of work. It's a tragic belief and a self-fulfilling prophecy. It's also not grounded in reality.
The truth is, there is nothing inherent in military technology (for example) that requires it to cost so much, take so long or be so complex. Yes, systems like the F-22 took a long time and cost a lot. But there's a difference between "it took a long time" and "it takes a long time." We could have done it better (both programmatically and operationally). If we set up our values correctly, if we cherish our constraints and pursue intelligent simplicity, we don't have to spend billions and decades. We can do it for millions and in years (or thousands in months). The F-117, the SR-71, NASA's Near Earth Asteroid Rendezvous (NEAR) mission and the Pathfinder Mars mission are all examples of high-tech projects built on a FIST (Fast, Inexpensive, Simple, Tiny) foundation.
Despite the evidence of a significant portfolio of FISTy projects (documented in my master's degree thesis), the Myth of Inevitability insists that things like this have to be complicated and expensive. Believers in the myth see no alternative to bureaucracies, technologies and processes that are complex, expensive and slow.
Their failure to see through the myth reflects ignorance of the past and a lack of imagination. There are alternatives. Download a free copy of The FIST Handbook for more details on the principles, activities and examples of how to use constraints to foster creativity and deliver systems that are simultaneously faster, better and cheaper.
My buddy Rhet passed along this link to an article about the impact of the web on writing. And now I'm passing it along to you, my favorite readers.
Now, this isn't technically a project leadership issue, nor a military technology issue. But it is about several topics that are interesting & (I think) relevant to the wider discussion here on RPL.
The basic idea in the article is that the internet expanded the scope of possible manuscript lengths. No longer are writers limited to books or magazine articles. We can go longer or shorter, thanks to the magic of the series of tubes we call the internets.
It's just one of the many ways the internet is changing how we do business, how we communicate, and ultimately how we think. It affects what ideas we are able to share and discover. And THAT is the secret sauce of the whole thing.
Rocks are not processes (although they can be described as the product of a process). For that matter, I don't think any nouns are processes. I'm going to go out on a limb and say that only a verb has the potential to be described as a process. This means an outcome is not a process. Hold that thought...
While we're talking about words, let's consider semantics. It might be true to say "everything you do can be represented as a process." That's a bit different than "everything IS a process," wouldn't you agree? I suspect that's what people mean when they say "everything is." But why say everything when you mean every activity? And why say is when you mean can be represented as? Those concepts are quite different.
More to the point, even if everything we do can be represented as a process, that doesn't mean everything should. Some activities are best performed with an intuitive, craftsman-like touch. Not because it's easier, but because the end product is better. As my favorite poet ee cummings pointed out:
Process, it seems to me, is all about "the syntax of things." It's not about the outcome. Process may be about kissing, but it's not about The Kiss.
Another observation: some activities are not repeated / repeatable. Some projects are unique, some activities are unique. But repeatable or not, it's important to consider the amount of time, money, effort, etc that goes in to developing, documenting and validating a process. Sometimes, it's just not worth the expense. For example, do we really need to document a process if we're only going to do it once? What's the point of documenting a process if the people doing the activity are already effective and efficient? It's a calculation we should consider.
Sure, if you've got a large number of people doing well-bounded, well-defined, repeatable tasks, in which variations are undesirable and the environment is generally predictable, by all means, document your process and do it that way. But not everything is in that category.
Is everything a process? I'll take "Answers That Begin With No" for 500, Alex. Can everything be represented as a process? Sure. Are there some activities that should not get the process treatment? You bet...
Gabe & I collaborated with our AT&L editor Carol on a fun little article titled Twitter Is Mission Critical. It'll be in the Oct issue of Signal magazine, and you can read a short preview here. We'll let you know when the full version is up.
OK, this is kinda touchy, on a couple levels, but here I go...
I was quoted in a post yesterday by David Axe, over at the War Is Boring blog. The post starts out talking about Sec. Gates and his vision for military technology (AF in particular), then goes on to talk about some of the stuff I've been writing about for a while. It's a cool piece, and I hope it helps generate some thoughtful discussions about ways & means for doing this acquisition thing better. But there are some bits in the post that probably merit a disclaimer / clarification.
I did sit with David for a little interview. He's a cool guy and it was a lot of fun to talk with him. I think his post captured the bulk of what we talked about. However... there are a few lines that come across more pointed and critical (and less nuanced) than they probably should have. That is, they came across more pointed and critical than what I think I said. Not a huge deal - but I don't want readers to think I've gone further off the deep end than I really did.
Don't get me wrong. I like rocking the boat. I'm not shy about offering criticism of the DoD's acquisition community. I've been known to use phrases like "slow-dancing with the 800 lb status quo gorilla" or "the DoD has too much money, which is limiting our ability to be innovative" or "we don’t blame the bureaucracy. We blame the bureaucrats, and you can tell them we said that." And that's in official DoD publications.
Still, when I'm boatrocking, I do have some guidelines. Like, keep it honest, keep it funny, keep it accurate, acknowledge nuances and stick to what I know. So, I avoid phrases like "we don't have the right systems," because I'm not in that business. I'm not involved in determining the portfolio of operational needs, and I can't say for sure whether we've got the right mix. My area of expertise is figuring out ways to develop systems that provide meaningful capabilities, not measuring whether we've got everything we need. If I get anywhere close to the topic of operational needs, I'd go with something more nuanced, like "It seems to me we need more of this and less of that..." Better yet, I'd quote an expert like the SECDEF, and say we need more ISR assets and fewer air superiority jets.
And while I do think the FIST principles can apply to just about everything, I'm sure I'm wrong about that. In fact, I'm very very very sure I'm wrong - just because I can't think of any situations where FIST wouldn't be helpful doesn't mean such a situation doesn't exist. So, I can't and don't say everything should be done the FIST way. Sure, I think that, but I go out of my way not to say it. If I gave the impression in the interview that I meant ALL systems should be FIST systems, that's my bad, but not my intention.
OK, having said all that, I do think it's an interesting and thoughtful blog post. I really like the way he finished the piece. Here's an excerpt (with the caveat that the word "all" in the 3rd sentence should be replaced with "most" or "more):
Ward has a prescription for building a better, cheaper Air Force, faster. It boils down to constraints. All programs should be “fast, inexpensive, simple and tiny,” he said. Budgets, schedules and initial quantities should be deliberately limited, so as to deliver a given capability in years for millions of dollars, instead of decades for billions.
Pointing to aircraft like the F-16, the Predator drone and the World War II P-51, all of which were developed quickly and cheaply, Ward insisted that his so-called “FIST” approach isn’t really new. It just requires today’s Air Force establishment to stop believing in the “inevitability of overruns and delays.”
“We can do better, faster, cheaper,” Ward said.
So, surf on over to WarIsBoring. Check out Dave's stuff and jump into the conversation. Rock on!
A hearty Rogue Welcome to blogger Mike Burlson, who writes the New Wars blog! His blog is, as Gabe would say, awesome. Be sure to check it out.
Burlson's vision for the future Navy lines up very closely with my own imaginings of a future AF. Specifically, he's saying we should move away from small fleets of big, expensive, complex systems, and towards larger fleets of systems that are, to coin a phrase, fast-inexpensive-simple-tiny. Here's a short excerpt:
We contend here at New Wars that modern computer technology added to guided missiles has doomed the heavily armored, over-priced weaponry of the Cold War/WW 2 eras. With this in mind we could safely cut such complicated arms as the manned fighter, the heavy tank, and large surface warships. Their replacements would be unmanned aerial vehicles, light armored cars, plus submarines and light patrol ships.
Let's say I can hold my breath for two minutes. That would be an impressive capability.
However, being able to hold my breath that long would not make me a more capable writer or engineer - the two main areas of professional expression I'm currently engaged in. I would not include "can hold breath for 2 minutes" in a resume looking for an engineering or writing job -it's just not relevant to those tasks.
So, when I hear people say that the F-22 Raptor is "the most capable aircraft ever," I have to object and ask what they mean by "most capable."
When I assess a system's capability, I'm looking at its ability to contribute to the fight. Since 2001, any system that doesn't provide capabilities we need in Iraq or Afghanistan is, by my definition, not very capable. And that's precisely the case with the Raptor. It first went operational in 2005, and it has yet to fly a combat mission in either war. It's not bringing anything (a-n-y-t-h-i-n-g) to the fight. In what sense is it, therefore, the "most capable" jet around?
To put it plainly, the F-22 does things we don't currently need to do. We may need to do them someday, although I think that's not as likely as some people do. But it is a demonstrable fact that we don't need these capabilities today... or any time soon. The SECDEF himself said the Raptor is "irrelevant" to the fights in Iraq and Afghanistan. To my mind, that makes it one of the least capable aircraft in the inventory (and that's not even factoring in its maintenance issues, low availability rates, etc). Combine that with the $65B we've spent on the thing and you can see why we've decided to not buy any more of them.
So yeah, it can hold its breath for a long time, but that capability doesn't line up with the near- or mid-term needs. What we need are aircraft that are capable of accomplishing the mission. The Raptor clearly is not. I'm not saying we should scrap the whole fleet. I'm just saying we should stop trying to paint it as the "most capable" system we've got.
One of the first projects I really had an impact on was a little imagery dissemination project for the National Geospatial-Intelligence Agency called BRITE (originally Broadcast-Request Imagery Technology Experiment... I think they changed the E to something else later). It was a small system designed to provide overhead imagery to forward deployed SpecOps guys who had very limited bandwidth and were highly mobile.
The BRITE project was one of the keys to developing my FIST approach to technology development. We had a very small team - in fact, I was the only government guy working on the project (and I was a junior Captain). On the contractor side, we just had a handful of people, and most of them were only assigned to the project part time, as I recall. The budget was quite small, the deployment schedule was short (this was 2001 - 2002). The system was designed to operate in austere conditions and it worked like magic.
That experience had an enormous impact on my thinking and my perspective on what can be done with small teams of talented people, working on tight budgets and tight schedules. It also hammered home the importance of simplicity - organizationally, technically and procedurally.
So, just for fun I googled it and came up with a great story about using BRITE to support the Hurricane Katrina disaster relief effort. It's nice to see that my little project still had legs after I'd moved on to other things.
One other comment while we're talking about Congress.
Representatives and Senators are elected to represent and protect the interests of their constituencies. That's their job, and we should not complain and object when they do what they were elected to do. The problems in military acquisitions are not Congress' fault.
See, when we deliberately spread out development of a project across 44 states and several hundred congressional districts, we are making a cynical move that's designed to ensure the project can't be cancelled. We can't then turn around and object that those doggone people in Congress are forcing us to do something. If we built smaller, more focused projects, we'd get a lot less Congressional involvement.
Similarly, when we launch a hugely expensive project, it is entirely appropriate for Congress to insist on performing oversight. It's a lot of money, and they owe it to their constituencies to make sure it's spent appropriately. If we spent less money, we'd get less Congressional involvement.
The FIST approach is a good way to reduce intrusive oversight without denying legislators the right and ability to perform their legitimate, constitutionally appointed roles.
In a recent discussion about improving defense acquisitions, someone suggesting things would be better if we could get rid of Congress. Everyone laughed at this humerous suggestion, and one particularly literal-minded person said "Oh, that's too big of a change, it can't be done, let's move on..."
Well, hold on.
Maybe there's a way to "eliminate" Congress from the project without disbanding one third of our constitutionally-established government.
See, the problem isn't Congress' existence. The problem is that sometimes Congress provides, as Shrek so delightfully put it, "the opposite of help." So, what if we could minimize this anti-help?
It turns out, we can. The FIST (Fast, Inexpensive, Simple, Tiny) approach does exactly that.
A FISTy project has a small budget, which attracts less interest and oversight from our congressional leadership. A short schedule provides fewer chronological opportunitites for, let's call it involvement (instead of meddling). A small team and simple organization doesn't get spread across multiple congressional districts and states, and voila, that means fewer legislators with a dog in the fight.
These decreases are all appropriate and above-board. It's not a matter of shutting Congress out, but rather of keeping the project sufficiently small that it doesn't require their, ahem, help.
Most of the process advocates I've met recently have come from background like manufacturing and logistics. That makes a lot of sense - these are well-bounded, repeatable, concretely-defined disciplines. The problem is when we try to cut and paste successful manufacturing or logistics approaches onto other areas, like research & development or program management.
R&D is typically - and appropriately - an unbounded, unique, loosely-defined activity. That doesn't mean there are zero processes involved... just that the most significant parts of R&D are beyond the realm of process.
So, when I say that I'm a critic of the process-centric approach, what I'm really objecting to is the misapplication and the overapplication of these approaches.
I also want to point out that I'm not a skeptic of the utility of process-centric approaches in R&D and program management. I'm emphatically a critic. The term skeptic sounds like a person is unsure whether a thing will work or not. Not me - I'm not agnostic about this stuff. I've done my research, taken the classes, got the t-shirt, and came to a conclusion. I'm well beyond skepticism.
I've been thinking about this whole process-centric approach for a while now, and I think I figured out a way to state my position in words the Lean and Theory Of Constraints crowd can understand:
Process is not the bottleneck. Talent is.
This means process is neither the problem nor the solution. Talent drives action, talent dictates outcomes, and at the risk of sounding like Tom Peters, talent is, well, it's everything. [not that there's anything wrong with sounding like Tom Peters - the guy's amazing].
Process is a poor substitute for talent. You can't make up for a talent shortage by simply instituting more and more (and more and more) processes. If there is indeed a talent shortage, the way to deal with it is by... unleashing more talent! And a compliance-based, process-centric, dictatorial, command & control approach squelches and repels talent.
Now, there's nothing wrong with using and improving our processes. But when our approach to improving performance is process-centric instead of talent-centric, we end up discounting and preventing the very thing that matters most.
The ability to stand up in front of a group of people and communicate effectively is a critical professional skill for program managers and other project leaders. It's particularly necessary for military engineers, defense contractors, and leaders in general. I can't say strongly enough how important this is as a matter of professional competence.
For better or worse, PowerPoint is the tool of choice for making presentations. When anyone gives a presentation with dense, complicated, unreadable, illegible and otherwise horrible-horrible-horrible presentation charts, they are demonstrating sheer professional incompetence.
In case you can't tell, I get kinda worked up about this.
For all the time we spend giving and receiving briefings, it's inconceivable to me that honing one's presentation technique is not treated as an important discipline and a core element of professional development. I've even seen professional educators, who brag about their ability to facilitate discussions and interact with audiences, use powerpoint charts that are frankly embarrassingly bad.
This stuff isn't hard. Sure, it's a little bit more work than doing it badly, but once you get the hang of it, it's not bad. Go check out Garr Reynold's Presentation Zen blog for some great examples of how to do it right.
I like to say that FIST isn't a new way to do acquisitions. It's just how we do acquisitions when we do it well.
But frankly, I'm not convinced my current attempt to drive FISTy change into the system is going to succeed. I am very aware that the probability of success is low. Five or ten years from now, there's a pretty good chance the defense acquisition community is going to look very much like it does right now.
Having said that, the environment does seem more change-friendly than it ever has before. Our experiences in Iraq and Afghanistan are a big part of that, along with the new administration, changes in the economy and advances in technology - particularly UAV's. This combination of operational, political, economic and technical factors is sort of a perfect storm and gives me hope that significant, meaningful change is possible. If the FIST approach ever had a chance at widespread adoption, it's in the current climate.
Our troops overseas are increasingly emphasizing the importance of rapid access to systems that are simple and effective. They have less tolerance for the complexity and delays of previous years. The president ran on a platform of change, and military leaders from the SECDEF on down are reimagining the way we do business. The economy is forcing people to think really hard before spending money. And along come these UAV's, which offer relatively inexpensive and simple ways to accomplish missions that used to require much more time, money and effort.
So will FIST take off? I don't know. I certainly hope so. All I know is that I've got to try to make a difference, even if the odds are against me, 'cause these are the best odds I'm ever likely to see.
My brother sent me this link to a Guide to Netflix Culture & Values a while ago, and I'm just now getting around to posting something about it. It's pretty remarkable (get it, re-Mark-able, and it's from my brother Mark, and I'm re-posting it... sorry!)
Anyway, I love this. My favorite bit was the chart about Communication. When they talk about valuing people's communication skills, what's the first line on the chart? "You listen well."
Holy cow, that's fantastic. Good communication skills start with good listening skills. Um, heck yeah.
We hereby award Netflix the Good Rogue-keeping Seal of Approval!
I'm not going to pretend I understand the Iraqi Air Force's operational needs better than they do, but I have to admit I think they might be heading in the wrong direction when it comes to fighter jets.
A recent Danger Room post says the Iraqi's are not terribly interested in the inexpensive and simple light-weight fighters that have been getting so much buzz in FISTy circles lately. Instead, they want F-16's. I have to wonder whether this preference is based on a solid assessment of their actual operational needs and maintenance capabilities, or whether it's based on a desire to have the same shiney jets that the big boys fly.
Something similar happened in the late 70's & early 80's - ironically, also involving the F-16. Northrop developed the F-20 Tigershark as a low-cost export fighter. It was basically an advanced F-5, and was supposed to be easy to maintain, lower cost, etc. The idea was to sell it to countries who didn't really need or couldn't afford all the capabilities of the F-15 Eagle or F-16 Falcon, but still wanted a solid fighter jet. The F-20 cost $8M, compared to $15M for the F-16 or $30M for the F-15.
Under the Carter administration, foreign sales of Falcons and Eagles were not allowed anyway, so the market for the F-20 looked good. But then President Reagan changed the policy, and suddenly other countries had the option of buying F-15's and -16's. Northrop never sold a single F-20.
Sure, there's a lot more to the story, but the gist is that even though the F-16 cost twice as much, was more expensive & difficult to operate and maintain, and was frankly more aircraft than many of our allies really needed... that's the jet they wanted.
Here we are nearly 30 years later, and when faced with the possibility of buying a FISTy fighter that will do everything they need it to do, we see an ally apparently buying into the idea that complexity is a sign of sophistication, that more expensive equals better, etc. I might be wrong here, but the similarities are striking.
And interestingly, the US Air Force is also looking at using these Light Attack fighters. Maybe that'll help lend some credibility to the thing...
Ever since I wrote the nightmare fiction story Acquisition As Deterrent, I've been a little bit haunted by the thought that it might be true. In fact, when the idea first hit me, it came down on my head like a ton of bricks and sorta bummed me out.
What if the reason for all the complexity, cost and delay in military technology projects is to prevent the rest of the world from imitating us?
Well, that still might be the case, but if so, it's a bad reason. The thing is, the FIST approach is not easily imitated, because the US has such direct access to a wide range of mature, advanced technology, compliments of our various military laboratories, etc.
So, the hostile dude in some other part of the world who wants to use the FIST approach is starting off with a significant disadvantage, in terms of the pieces and parts available to use. Yeah, the barriers to accessing and adopting technology are lowering, but we've still got a significant advantage.
And then there's the whole personnel part, the training, talent, education, courage and creativity of the people who actually develop and use these systems. That's pretty hard to imitate.
Yesterday's post was the short version of the FIST (Fast, Inexpensive, Simple, Tiny) approach to system development.
Today, I've got a short post with a link to a long video. Yes, this is the much anticipated Rogue-a-palooza aka Rogue Fest 2009 aka the briefing that Gabe and I did at the Defense Acquisition University back in July.
I confess I haven't actually watched the whole thing yet, but my mom and dad did and they said I did real good. They also said the video includes the Q&A at the end of the presentaiton - I wasn't sure if that part would be included, but it was. That's cool.
So, if you've got an hour or so to kill, and you want to see me and Gabe jump around like monkeys and tell stories about why FIST is so good, click the link.
One of the main rebuttals to our FIST concept is that it is incapable of producing the kinds of capabilities seen in weapon systems like the F-22 or an aircraft carrier. The argument is that these kinds of capabilities can only be produced by programs that are methodical, deliberate, systematic and massive. We often hear that FIST programs are cute and may be fine to fill stop gaps, but aren't sufficient to do the heavy lifting of developing and fielding "real" weapon systems.
But that's our point exactly. Weapon systems with tons of capabilities and features are overrated, if not useless, in the current state of warfare. We postulate that what the warfighter's really want and need is something that is Good Enough. Turns out defense isn't the only industry where this is true. WIRED just published an amazing article which could easily be our manifesto for FIST, The Good Enough Revolution: When Cheap and Simple is Just Fine. An excerpt:
Military aircraft are experiencing their own version of the MP3 effect.
Why, if manned planes are so superior, is the Predator saturating the combat market? [Their] ability to maintain a constant presence in the air. That's because the drones are relatively cheap to build, can fly for more than 20 hours straight, and don't require pilots who need sleep, food, and bathroom breaks (and who might die if the plane is shot down).
Piloted aircraft are still valuable......but because the Predator can linger, it has enabled a new type of strategy—remotely guided surgical strikes with fewer troops and armaments. It's a lesson that surprised the Air Force and other services, Mathewson says, but one that has been learned definitively.
OK, let me summarize the whole FIST thing as concisely as possible. It really comes down to this:
"There is nothing inherent in military technology that requries it to cost so much, take so long, or be so complex."
There, I wrote it down for everybody on the Interwebs to see, and it feels good.
The more I read, the more I do, the more I hear people's stories, the more convinced I am that complexity is not inevitable. We do it to ourselves, technologically and organizationally and procedurally... but we dont' have to. Similarly, these huge cost overruns and schedule delays are not inevitable. Until we believe that - I mean REALLY believe it - we're going to keep getting the results we've been getting.
Incidentally, this applies to NASA's space projects as much as the DoD's systems... and no doubt to commercial & industrial projects as well.
Take a moment today to drop someone a bit of fan mail, will you?
It could be an email, a blog comment, a Facebook wall post, or (gasp) an actual, physical letter, with a stamp and everything. If you're feeling particularly bold and Rogueish, you could even make a phone call.
If there's someone out there you admire, someone whose work means something and speaks to you, let them know. Sometimes we're just so busy enjoying the articles, songs, books, etc, that we don't take the time to say so out loud.
And along with writing some fanmail, maybe you could find the time to tell a friend about whatever singer, artist, writer or other creative types you're enjoying these days.
Check out this (rather lengthy) post over at the CogBlog. It's an insightful look at the saying-doing gap in defense acquisitions, primarily focused on the IT side of things. A few nuggets to whet your appetite:
DoD acquisition regulations do not actually mandate stupidity … they just encourage it.
...the Joint Capability Integration Development System, or “JCIDS“, mandates a change from “system-based” to “capability-based” requirements... However formal OPTEST evaluates systems, not enterprise capability.
What is the gap between the capability provided by Travelocity vs. Defense Travel System? [Dan here - holy cow DTS is a pain to use!]
We need pre-approved catalog offerings available on GSA schedules and IDIQ vehicles. We need “dating services” to put consumers with like requirements in touch with each other and expert providers. We need “consumer reports”... to provide basis of objective, convenient comparison.
In the late 90's, before I really had any idea what was going on in the world of defense acquisitions, some in the DoD tried an approach called Total System Performance Responsibility (TSPR). It came and went largely unnoticed by little ole me. Now, like Total Quality Management and other past attempts at making things better, TSPR has become a bad word among military technology circles.
Since people are still throwing spears at it, I figured I should know more about it than I do. It turns out, the basic idea was to reduce the government's involvement and allow contractors to do things their own way, as efficiently as possible, without undue influence or involvement by the government.
Unfortunately, many people today seem to have decided that the problem with TSPR was that it involved too much trust. Trust is bad, they conclude. We can't trust those slimy contractors. They're bad, they're bad!
Hold on. Let's not get the wrong conclusion here.
After a bit more investigation and reflection, it seems to me that the problem with TSPR wasn't trust, but rather ignorance. Instead of reasonable delegation, we turned it into abdication. The government wasn't merely hands-off, it was eyes-shut. Anyone surprised that didn't work out very well?
The truth is, I think the government should trust contractors more than we do (as I've written elsewhere). But that doesn't mean we should take the "wake me up when it's ready" approach. We can still be involved and informed, without turning it into excessive meddling.
More to the point, trust isn't weakness, naivete and stupidity. Trust requires strength, judgment and wisdom. A lack of trust indicates, among other things, a lack of trustworthiness and a significant degree of unreflective foolishness. Yeah, I said it - foolishness. Real rogues trust their partners, 'cause that's a smart and strong thing to do.
The TSPR approach may have been fatally flawed from the start, or it may have been a good idea badly executed. I still don't know. But what I do know is that if we think the lesson of TSPR's failure is to not trust people, we've learned a horribly wrong lesson.
For those who haven't heard yet, Wired magazine's Danger Room blog did a very nice post about Team Rogue and our FIST approach to acquisitions.
They even sort of made it sound like the SECDEF is an advocate of the FIST approach. OK, it didn't sort of sound like that... it totally sounded like that. What else does the phrase "high level advocate" mean?
Anyway, it's fun to see our ideas getting this kind of visibility.