There was a great article in the NY Times yesterday, titled We Have Met The Enemy, and He Is PowerPoint. It recaps all the familiar criticisms of bad briefing charts - they're too complex, too simplistic, too confusing, too obtuse... Regular readers may recall a little film noir spoof I wrote titled Death By Bullets, which was my own little salvo in the war against bad PowerPoint.
But as they say, it is a poor workman who blames his tools, and I've long believed that Microsoft's presentation software isn't the problem (although the default template settings they use are inexcusable). But the truth is, all those terrible, horrible, no-good, very-bad briefings out there do not represent a software problem. They don't represent a technology problem. For that matter, they don't even represent a communication problem.
Ladies and gentlemen, bad briefings are a leadership problem and a thinking problem.
Senior leaders should never accept an endless parade of dense, impossible-to-read charts. They should refuse to sit through briefings like that. But not only do they receive and accept such briefings, they deliver them too. It makes me crazy to think about it.
Nobody likes that approach. Nobody thinks it's effective. And apparently nobody thinks there's an alternative.
Thank goodness for rare leaders like Brig. Gen. H. R. McMaster, who banned PowerPoint presentations according to the aforementioned article. Now, I think he would have been better off banning BAD PowerPoint, but it's a start.
Look, it's possible to create a clear, coherent, cogent presentation using just about any type of software (Apple's KeyNote can be just as bad as PPT). It just requires a little extra thought, a little creativity and a little practice.
A little study wouldn't hurt either. Do your homework. Learn how to give a good presentation. I recommend starting with Garr Reynolds' Presentation Zen and watching some of the TED presentations.
Good luck, and remember the #1 rule of PowerPoint: First, Do No Harm.
A more-than-slightly-subversive blog,
dedicated to serving project leaders with attitude.
28 April 2010
27 April 2010
Crossing The Unknown Sea
I don't recall how I first came across British marine zoologist and poet David Whyte's name or his fantastic book, Crossing The Unknown Sea. But the book has had a tremendous influence on me. It contains profound insight into the nature and purpose of work, the causes and solutions to exhaustion, and various aspects of life on a frontier.
I recommended it to a friend over the weekend, and thought I'd recommend it here too. I have a strong aversion to trite, six-easy-steps-to-success style books. This is nothing like that. It's simply a deep, gentle, compelling look at life, work, meaning and struggle.
I highly recommend it.
I recommended it to a friend over the weekend, and thought I'd recommend it here too. I have a strong aversion to trite, six-easy-steps-to-success style books. This is nothing like that. It's simply a deep, gentle, compelling look at life, work, meaning and struggle.
I highly recommend it.
26 April 2010
Simplicity Cycle Down Under
The other day I came across a scientific paper titled "Using the Simplicity Cycle in Model Building." It was presented at the 18th World IMACS / MODSIM Congress in Australia this past July. The conference has something to do with "modeling and simulation with mathematical and computer sciences," which frankly is all a bit beyond the scope of my education.
But back to the paper's title. Huh, I thought. Someone else is using the phrase "Simplicity Cycle." I wonder what theirs is like. So I checked it out.
Nope. Turns out, the title of the paper was referring to MY Simplicity Cycle. How cool is that?
All I could get access to was the abstract, which is probably just as well. But from what I can tell, Prof Ted Lefroy from the University of Tasmania and his co-authors C.A. Pollino and A.J. Jakeman from the Australian National University in Canberra are using the Simplicity Cycle concept to "arrive at a state of low complexity and high utility" in their agricultural models, by "progressively discarding drivers, nodes and links to which the system is least sensitive." Which is exactly what the Cycle diagram is for.
I completely love the idea that Australian agricultural scientists are using some ideas from my crazy little book to shape their own model designs. I hope others will do the same - which is why I made it a free download at Lulu and why I released it under a Creative Commons License.
Incidentally, it's now been downloaded over 2,100 times. You've got your free copy, right?
But back to the paper's title. Huh, I thought. Someone else is using the phrase "Simplicity Cycle." I wonder what theirs is like. So I checked it out.
Nope. Turns out, the title of the paper was referring to MY Simplicity Cycle. How cool is that?
All I could get access to was the abstract, which is probably just as well. But from what I can tell, Prof Ted Lefroy from the University of Tasmania and his co-authors C.A. Pollino and A.J. Jakeman from the Australian National University in Canberra are using the Simplicity Cycle concept to "arrive at a state of low complexity and high utility" in their agricultural models, by "progressively discarding drivers, nodes and links to which the system is least sensitive." Which is exactly what the Cycle diagram is for.
I completely love the idea that Australian agricultural scientists are using some ideas from my crazy little book to shape their own model designs. I hope others will do the same - which is why I made it a free download at Lulu and why I released it under a Creative Commons License.
Incidentally, it's now been downloaded over 2,100 times. You've got your free copy, right?
22 April 2010
Superficial Agreements
People often respond to my FIST (Fast, Inexpensive, Simple, Tiny) presentations by saying that “Everyone agrees with this," by which they seem to imply this stuff is almost too obvious to say.
The thing is, that’s not exactly true.
Sure, everyone agrees in principle to the *objectives* of FIST, such as reducing the cost and time involved with developing new systems. But when it comes down to actual *implementation,* we quickly encounter friction. And it’s the implementation that’s at the core of FIST.
Let’s take a look at a few specifics, shall we? In my FIST presentations & articles, I say simplicity is desirable, a sign of sophistication. Adding more features, functions & widgets makes the system worse, not better. But take a look at almost any piece of consumer electronics or any weapon system, and you’ll find it’s chock-full of shiny bits and features, apparently added in the belief that more is better. In fact, when you actually analyze the system, you often find it’s full of extra features, which:
a) are unused / seldom used,
b) increase the cost of the system,
c) increase the complexity of the system,
d) reduce the reliability of the system (by creating more potential failure modes, for example),
e) make the system harder to learn, use & maintain
f) all of the above
I could go on, but you get the picture.
Similarly, FIST argues that constraints foster creativity, and thus small budgets are good. But as soon as a program runs into a technical problem, the same people who supposedly agree with FIST end up asking for more time and money. Or consider the huge pressure on military program managers to “keep your obligations’s & expenditures up,” (i.e. spend all your money) for fear of not getting as much money next year. Clearly, the environment does not reward thrift. Any DoD program manager who turns in money at the end of the year is likely in for some harsh words from the finance folks. Spend, spend, spend! But yes, we agree that FIST is a good idea… as long as we don’t make things simple and as long as we spend a lot of money.
Sheesh.
The thing is, that’s not exactly true.
Sure, everyone agrees in principle to the *objectives* of FIST, such as reducing the cost and time involved with developing new systems. But when it comes down to actual *implementation,* we quickly encounter friction. And it’s the implementation that’s at the core of FIST.
Let’s take a look at a few specifics, shall we? In my FIST presentations & articles, I say simplicity is desirable, a sign of sophistication. Adding more features, functions & widgets makes the system worse, not better. But take a look at almost any piece of consumer electronics or any weapon system, and you’ll find it’s chock-full of shiny bits and features, apparently added in the belief that more is better. In fact, when you actually analyze the system, you often find it’s full of extra features, which:
a) are unused / seldom used,
b) increase the cost of the system,
c) increase the complexity of the system,
d) reduce the reliability of the system (by creating more potential failure modes, for example),
e) make the system harder to learn, use & maintain
f) all of the above
I could go on, but you get the picture.
Similarly, FIST argues that constraints foster creativity, and thus small budgets are good. But as soon as a program runs into a technical problem, the same people who supposedly agree with FIST end up asking for more time and money. Or consider the huge pressure on military program managers to “keep your obligations’s & expenditures up,” (i.e. spend all your money) for fear of not getting as much money next year. Clearly, the environment does not reward thrift. Any DoD program manager who turns in money at the end of the year is likely in for some harsh words from the finance folks. Spend, spend, spend! But yes, we agree that FIST is a good idea… as long as we don’t make things simple and as long as we spend a lot of money.
Sheesh.
21 April 2010
Collapse
I recently got turned on to John Robb's fascinating Global Guerillas blog. As I've perused the site, one line in particular jumped out at me. Commenting on social and economic collapse, John writes about a "system that collapses when it begins to succumb to diseconomies of complexity."
I think the concept of collapse caused by the diseconomics of complexity is brilliant, not just because I'm a word geek and love a well-turned phrase, but also because it perfectly describes an aspect of The Simplicity Cycle which I'd never really considered before. Specifically, it describes a common way for a large entity to leave the upper-left quadrant, aka the Region of the Complicated, where complexity is high and goodness is low (check out the Simplicity Cycle link above if you don't know what I'm talking about).
I generally describe two ways to proceed from this situation (of high complexity & low goodness). One is to simplify, and the other is to scrap the whole thing and start over. From a design perspective, there are many practices and principles for doing the first option. The second option takes guts and is called a smart move when it's deliberate... but it's called collapse when it happens even though nobody really meant for it to happen. And frankly, if we don't do it with purpose, it eventually happens whether we wanted it to or not.
It just makes me wonder whether the defense acquisition business will figure out a way to deliberately simplify before the diseconomies of complexity completely take over and things begin to collapse in a big way.
I think the concept of collapse caused by the diseconomics of complexity is brilliant, not just because I'm a word geek and love a well-turned phrase, but also because it perfectly describes an aspect of The Simplicity Cycle which I'd never really considered before. Specifically, it describes a common way for a large entity to leave the upper-left quadrant, aka the Region of the Complicated, where complexity is high and goodness is low (check out the Simplicity Cycle link above if you don't know what I'm talking about).
I generally describe two ways to proceed from this situation (of high complexity & low goodness). One is to simplify, and the other is to scrap the whole thing and start over. From a design perspective, there are many practices and principles for doing the first option. The second option takes guts and is called a smart move when it's deliberate... but it's called collapse when it happens even though nobody really meant for it to happen. And frankly, if we don't do it with purpose, it eventually happens whether we wanted it to or not.
It just makes me wonder whether the defense acquisition business will figure out a way to deliberately simplify before the diseconomies of complexity completely take over and things begin to collapse in a big way.
20 April 2010
Sparky Baird Award!
Pardon me while I brag for a moment, but I just got a nice surprise in the mail. It turns out the Twitter Is Mission Critical article I co-wrote with some friends was selected as the winner of the Sparky Baird Award "for the best article published in SIGNAL Magazine during 2009."
I didn't even know there was such an award, let alone that our little article was in the running. I'm not sure if I'll make it down to Virginia Beach for the awards luncheon, but it's definitely nice to be selected.
I didn't even know there was such an award, let alone that our little article was in the running. I'm not sure if I'll make it down to Virginia Beach for the awards luncheon, but it's definitely nice to be selected.
19 April 2010
Free Shipping
I love publishing my books at Lulu.com and have always been impressed with their quality, speed and low prices. But I have to admit I think their shipping & handling charge is kinda high - it's $3.99 if you order one book.
The shipping charge is one of the reasons I encourage people to download the free PDF version of The Simplicity Cycle. Sure, you can buy the printed hardcopy for just $7.95, but by the time you add in shipping and handling and taxes, it's upwards of $12. And personally, that feels a bit steep to me. I wish there was a lower-price shipping option for people who just want to order one book.
I'm very happy to report that between now and May 1st, there is! Use the coupon code FREEMAIL305 to get free shipping on one book and skip the $3.99 s&h fee. Usually Lulu coupons are good for 10% off, which equals about 80 cents for the Simplicity Cycle. So the $4 savings is a pretty big deal. If you've already got the eBook version and want a physical copy, this is a great time to get it.
16 April 2010
The Innovator
Check out this little piece I wrote about crowdsourcing & defense acquisitions.It got a nice mention on David Axe's War Is Boring blog. I'd say more but I'll just let you read it...
(NOTE: I fixed the link... try again)
(NOTE: I fixed the link... try again)
FIST Poster
I've been meaning to post this photo for a while (since last month, actually). It's the poster that hung outside the room where I did my FIST presentation a while back. I was so happy they gave me the Wright Flier picture, instead of the oh-so-expensive (& delayed & complex) F-22, which adorned some of the other posters.
I just really like how the poster looked. Thought I'd share.
14 April 2010
Quality
I love Hugh MacLeod - he's got some truly spectacular stuff on his blog, Gaping Void. I'm on his email distro list and get a piece of Hugh's artwork in my inbox every day. It's the only mass email thing that I actually signed up for on purpose and continue to enjoy.
But there is one thing that sometimes stands in the way of my appreciation for his genius, and that's the salty language which often accompanies his art & commentary. Actually, it doesn't stop me from appreciating it... just from sharing it with my friends & neighbors. So imagine my pleasure to discover that he's cleaned up one of my favorite pieces - posted below
I'm also particularly glad that he uses a Creative Commons License for his work. Rock on, Hugh!
But there is one thing that sometimes stands in the way of my appreciation for his genius, and that's the salty language which often accompanies his art & commentary. Actually, it doesn't stop me from appreciating it... just from sharing it with my friends & neighbors. So imagine my pleasure to discover that he's cleaned up one of my favorite pieces - posted below
I'm also particularly glad that he uses a Creative Commons License for his work. Rock on, Hugh!
13 April 2010
Bad Design - Shuttle Bus
After parking in the endless Row D9, I boarded the shuttle bus which takes parkers to the main terminal. Imagine my surprise when the bus pulled up to the next pickup / drop off point and a cheery voice announced that the doors were about to close... as the doors were opening. Sheesh.
That's right. Every time the bus comes to a stop and the driver opened the door, a recorded voice warned the passengers to watch out, because the doors (which were in the process of opening) were about to close. Once all the passengers were loaded, the doors did indeed close... but this action was not accompanied by any recorded messages.
It wasn't a one-time glitch, either. This happens every time I'm on the bus, with one exception. In one instance, the driver began to close the door, then quickly opened it for one last passenger, then closed it again while a recorded voice was saying something about the terminal we were heading to. But apparently the act of opening the door triggered the "Doors closing" message, so as we were driving down the road (with the doors closed), all the passengers were once again warned to look out, because the (closed) doors were... wait for it... about to close.
The lesson here is that a message (recording, warning light, etc) should correlate with the appropriate action. Run some use cases and tests to make sure you're not warning about things that have already happened or won't happen for several minutes... or worse yet, about the opposite of what is actually happening.
That's right. Every time the bus comes to a stop and the driver opened the door, a recorded voice warned the passengers to watch out, because the doors (which were in the process of opening) were about to close. Once all the passengers were loaded, the doors did indeed close... but this action was not accompanied by any recorded messages.
It wasn't a one-time glitch, either. This happens every time I'm on the bus, with one exception. In one instance, the driver began to close the door, then quickly opened it for one last passenger, then closed it again while a recorded voice was saying something about the terminal we were heading to. But apparently the act of opening the door triggered the "Doors closing" message, so as we were driving down the road (with the doors closed), all the passengers were once again warned to look out, because the (closed) doors were... wait for it... about to close.
The lesson here is that a message (recording, warning light, etc) should correlate with the appropriate action. Run some use cases and tests to make sure you're not warning about things that have already happened or won't happen for several minutes... or worse yet, about the opposite of what is actually happening.
12 April 2010
Bad Design - Reagan Parking Lot
One of the items in my long list of Books To Write Some Day is a project I'm calling The Book Of Bad Design. Maybe I'll do it as a blog instead, but the general concept is to present poorly designed objects and examine what went wrong... then propose design solutions.
In anticipation of someday creating such a thing, I've been collecting examples and thought I might share a few of them here on RPL.
The photo to the left is of a parking lot at Reagan National Airport in DC. Notice the sign reading "D9" on the street light. Notice also the long line of street lights stretching off into the distance. Although you can't tell from this photo, I can confirm that every single one of those lights has a sign which reads (wait for it...) "D9." Really? Yes, really.
Running parallel to the long line of D9 parking spots are other rows, with similarly consistent labeling. This means that even if you remember you parked in row D9, your car could be anywhere along a rather lengthy row. The simple solution of course would be to give each light its own unique label, such as D1, D2, etc (for the D-row), and C1, C2, etc for the C row.
I can't imagine why the parking lot designers decided to use this labeling convention. They got so close to a usable design, then completely whiffed it. But it was better than the shuttle bus design... more on that soon.
In anticipation of someday creating such a thing, I've been collecting examples and thought I might share a few of them here on RPL.
The photo to the left is of a parking lot at Reagan National Airport in DC. Notice the sign reading "D9" on the street light. Notice also the long line of street lights stretching off into the distance. Although you can't tell from this photo, I can confirm that every single one of those lights has a sign which reads (wait for it...) "D9." Really? Yes, really.
Running parallel to the long line of D9 parking spots are other rows, with similarly consistent labeling. This means that even if you remember you parked in row D9, your car could be anywhere along a rather lengthy row. The simple solution of course would be to give each light its own unique label, such as D1, D2, etc (for the D-row), and C1, C2, etc for the C row.
I can't imagine why the parking lot designers decided to use this labeling convention. They got so close to a usable design, then completely whiffed it. But it was better than the shuttle bus design... more on that soon.
06 April 2010
GK Chesterton Quote of the Day
Writing about trusts and monopolies, the great G.K. Chesterton had this to say:
"It has not only destroyed the virtues it despises; such as independence, individuality and liberty. It has also destroyed the very virtues that it claims; efficiency and modernity and practical progress. Big Business is not business-like; it is not enterprising; it is not favorable to science and invention. By the very nature of its monopoly of machinery and mass production, it works entirely the other way. Millions are sunk in plants that cannot be changed or brought up to date. Machinery is made so that it must be used, even when it is useless..."
One hundred years later, the principles of brainless bureaucracy persists, where compliance is a virtue and we do things because they're important rather than useful and productive. Thankfully, there is a growing movement of craftsmen and small-batch production.
"It has not only destroyed the virtues it despises; such as independence, individuality and liberty. It has also destroyed the very virtues that it claims; efficiency and modernity and practical progress. Big Business is not business-like; it is not enterprising; it is not favorable to science and invention. By the very nature of its monopoly of machinery and mass production, it works entirely the other way. Millions are sunk in plants that cannot be changed or brought up to date. Machinery is made so that it must be used, even when it is useless..."
One hundred years later, the principles of brainless bureaucracy persists, where compliance is a virtue and we do things because they're important rather than useful and productive. Thankfully, there is a growing movement of craftsmen and small-batch production.
02 April 2010
CubeSail Space Cleaners
The BBC News recently reported on a FISTy approach to cleaning out some of the orbital debris which is currently cluttering the region located a few hundred kilometers above your head.
Dr Vaios Lappas, the lead researcher on the project says "Our system is simple and very low cost..."
Of course, he goes on to say "... but we need to demonstrate that it can be done," so apparently there's some work still to be done. Nonetheless, I do get excited when technologists and researchers brag about systems that are inexpensive, simple and tiny...
Dr Vaios Lappas, the lead researcher on the project says "Our system is simple and very low cost..."
Of course, he goes on to say "... but we need to demonstrate that it can be done," so apparently there's some work still to be done. Nonetheless, I do get excited when technologists and researchers brag about systems that are inexpensive, simple and tiny...
01 April 2010
Reducing Complexity, DARPA-style!
Graham Warwick has a great post over at Aviation Week's Ares blog, talking about the impact of complexity on weapon system development projects. The post looks at the F-35 Joint Strike Fighter in particular, and the way the DoD does systems engineering in general.
It turns out DARPA did a study of the relationship between complexity and project duration, and launched a program called META which is designed "to make a dramatic improvement on the existing systems engineering, integration, and testing process for defense systems." And by "dramatic" they mean reducing timelines by 5X.
As for me, I'm pretty excited to see someone is paying attention to the impact of complexity on system development efforts, and specifically to the relationship between complexity and project duration. One of the central tenants of FIST is that we can't simply reduce one aspect of a project (say, timelines) without simultaneously reducing the other aspects (cost, complexity, team size, etc). In other words, FIST isn't four ideas, it's one.
That means not only do I reject the "faster, better, cheaper - pick two" concept, but I think the only way to improve in two dimension is to also improve the third.
It turns out DARPA did a study of the relationship between complexity and project duration, and launched a program called META which is designed "to make a dramatic improvement on the existing systems engineering, integration, and testing process for defense systems." And by "dramatic" they mean reducing timelines by 5X.
As for me, I'm pretty excited to see someone is paying attention to the impact of complexity on system development efforts, and specifically to the relationship between complexity and project duration. One of the central tenants of FIST is that we can't simply reduce one aspect of a project (say, timelines) without simultaneously reducing the other aspects (cost, complexity, team size, etc). In other words, FIST isn't four ideas, it's one.
That means not only do I reject the "faster, better, cheaper - pick two" concept, but I think the only way to improve in two dimension is to also improve the third.
Subscribe to:
Posts (Atom)