Letter from Karachi, 1942

My recent research at the Air Force Institute of Technology brought me to the archives of the USAF Museum at Wright-Patterson AFB. The archive is located in a warehouse, straight out of an Indiana Jones movie.

One of my favorite discoveries during my hours in the archives is a letter from one Col. Homer L. Sanders, Commander of the 51st Fighter Group at Karachi Air Base. It's dated 26 Aug 1942.

The subject of the letter is simply "Fighter Airplanes," and in this letter, Col Sanders asks the Commanding General of US Army Air Forces in India and China to send him a new plane called the P-51 Mustang to replace the P-40's his squadrons are currently flying.

He writes: "It is an extremely simple airplane and has such perfect handling qualities as to put a smile of joy on the face of any fighter pilot." He goes on to write "It is requested that this Group be equipped with P-51 airplanes as expeditiously as possible. The P-51 is requested in preference to P-47 because of its smaller size, ease of maintenance, economy of operation, range, and because many of the accessories for it are already available in this area... engines, guns, radios, instruments, and many other parts are the same as those used on P-40..."

The P-51 is famous for its simplicity, speed of production, low cost and, most importantly, complete dominance of the air. It's a great example of the FIST (Fast, Inexpensive, Simple, Tiny) approach in action. Given the P-51's epic effectiveness, I wonder why we have not insisted that subsequent aircraft be just as simple. Probably because simplicity is hard to do... and complexity looks impressive.

The Col also reported on some impressive production stats, explaining that North American (the aircraft company) was"... building only 3 1/2 per day, but could raise the production rate to 10 per day within three weeks after being given the go ahead signal by the Air Corps." Ten aircraft per day? Gosh, they must have had some really good Total Quality Management systems, and a solid basis in Lean Six-Sigma practices to achieve that kind of efficiency and speed. I bet they were a real Process Enterprise. I wonder where they keep all their detailed and rigorous process diagrams. No doubt they were CMMI Level 5 and relied on the Program Management Deskbook of Knowledge...

Sigh.

Maybe it's not fair to expect today's aircraft developers to be as fast, inexpensive, and efficient as we were during WWII. I mean, those guys got to use notebooks and sliderules and make stuff up as they went along. We have to use computers and follow Best Practices. Plus, things today are so much more complex than they used to be, now that the Complexity Maximization Law got passed, effectively banning simplicity from our organizations and technologies.

And finally, in the Some Things Never Change category, the Col points out "It appeared there was a tendency by the Materiel Division to hinder the development of this airplane, which can only be accounted for by the fact that it was strictly a North American project, and Materiel Division could claim no credit for it."

Exciting Times!

Lots of excitement here in Rogue World. I've now moved to the DC area and am moving into my new office today. Still have some boxes at home, but we've made a lot of progress getting the house settled.

Gabe and I recently did an interview with our new BFF Traci Fenton of WorldBlu. WorldBlu is a fascinating organization that advocates workplace democracy. We'll let you know when the interview is posted. It was so much fun to do!

We also wrote an article on social media for SIGNAL magazine (the magazine of the Armed Forces Communications & Electronics Association). Whoo-hoo!

AND... we're working on a little seminar sponsored by Defense Acquisition University for later in July. Details forthcoming on that as well. If you're in the DC area and available for 90 minutes on 22 July, stop on by!

More to follow...

Radical Elements Redux

The first book I ever wrote was titled The Radical Elements of Radical Success.

As I've mentioned elsewhere, I have mixed feelings about the Radical Elements project. On the one hand, I can't believe I had the audacity to write such a book. I can't imagine I would presume to attempt such a thing today.

And yet... every time I flip through it with a critical eye, looking for an excuse to take it off the Rogue Press website, I come away thinking "Hey, there's some good stuff in there, if I do say so myself." It got some very nice reviews over the years. And for some inexplicable reason, it continues to sell a handful of copies from time to time.

As I flipped through it again the other day, the thing that stood out the most was the bits about cynicism, apathy, fear, timidity and smugness, and how poisonous these attributes are. I can't say I've got the antidote, although the book does offer a few thoughts on preventing them.

You can flip through the whole book for free online (and of course you can buy the eBook or the hard copy).

Process, Scrutiny & Oversight

n a recent briefing someone described their organization’s contribution in these terms:

“[we provide] processes that can stand the scrutiny of unprecedented oversight.”

Are they really saying that the objective of their proposed “methodical, rigorous and standard processes,” which are “demanded by the complexities of 21st century weapon systems,” is to prevent criticism? Yes, they are. I’m not surprised it’s come to this, but it is a little bit funny to see the CYA mentality stated so explicitly and with such boldness.

Withstanding scrutiny & oversight is fine, but it shouldn’t be the bottom line. What happened to delivering capabilities (which the briefing NEVER MENTIONED!)?

In a process-centric environment, compliance is apparently sufficient to shield poor performers from criticism. The team didn't deliver what the end user needed? Well, the boss won't object to the poor performance as long as the team complied with the process. Maybe we need to make the process more rigorous. Let's start a Continuous Process Improvement Initiative.

When an organization is process centric, people know it. So rather than seeking to simplify our excessively complex systems, processes and organizations (and focus on results), they instead develop rigorous and standardized processes, as a talisman against accusations of inadequacy.

If processes are going to be of any value, they should make the product better. They should streamline operations, enable smart decision making, foster better problem solving, encourage innovation, and deliver the required systems faster & cheaper. When we use them primarily as shields against scrutiny, something is horribly wrong.

Which Is Better?

In a meeting recently,* the Big Guy at the Head Of The Table suggested the following "A bad process is better than no process."

Um, I've got to disagree, although sadly I did not have my wits about me with sufficient speed to object during the meeting. So I'll just do it here - and save this answer for the next time I hear such an opinion expressed.

Here's how I see it: A process gone bad is generally one that puts up barriers to smart, effective behavior. It institutes needless delays and complexities. It increases costs. It discourages initiative and accountability.

An absent process, on the other hand, does not provide guidance about what to do, but neither does it introduce artificial friction into the works. So it doesn't help much, but it doesn't hinder either. A bad process hinders. I'd say that's worse.

*By "recently" I mean at some point in the past. No sense in trying to guess where I was or who the offender was.

Gabe's Take on the DAG

The proper name of one of the hundreds of Defense Acquisition Guidebook (DAG) processes:

Technical Planning Technical Management Process

A real term with a unreal meaning. Can somebody help me out here?

People > Process

Another excerpt from the 3 June 09 testimony to the House Armed Services Committee's Defense Acquisition Reform Panel. The speaker is retired AF LtGenl Ron Kadish, who chaired the 2006 Defense Acquisition Performance Assessment. Emphasis is added.

LtGen Kadish: “It's remarkable that the people we have out there doing this every day can make this work still under the systems that we impose on our self. And all for good reason. There are a lot of heroes out therereally making this work and I would almost say in spite of the system

I don't think process is going to fix this problem. When we add process and improvements, we tend to really add things and not take things away. And under that approach, I think we will just increase complexity. So I would advise a lot of caution in adding things without asking the question, "What are you going to take away to make these processes more integrated and less complex?"

And at the end of the day, it's the people doing the job, making more right decisions than wrong decisions that our going to produce the outcome here. And it really does. It might really come down to the fact that we could make an administration system and as good as we can make them in human terms. But its going to come down to people doing the job every day. And we've got to select them right. And we've got to support them and make them perform and hold them accountable.”

There's a lot there I can hang my hat on. It's stuff I've been saying and writing about for several years now, so this is a nice bit of confirmation that I'm on a good track.

I really should have some t-shirts made that say "I don't think process is going to fix this problem." Let me know if you want one too and we can do a bulk order...

Defense Acquisition Reform Panel @ HASC

I've been reading through the transcript of some recent testimony to the House Armed Services Committee's Defense Acquisition Reform Panel (3 June 2009).

I suspect the fact that I rose out of my chair and waved my fist in the air once or twice while reading it means a) I'm a hopeless geek and b) I'm in the right job.

A one-page summary that accompanied the 40+ page transcript offered these observations & themes:
Complexity drives the problems
Stability... counts
People make the difference

I'm encouraged by the recognition that complexity is a problem and people are a solution. Not much mention of the need for more rigorously-defined and vigorously-enforced processes. Whew! I particularly appreciated the comments by DARP Chairman Rep Robert Andrews (D-NJ):

Andrews: “There have been many instances where there has been very effective coordination. I think the bulk of the evidence is that that's more a function of the talents and commitment of the individual that are involved, not necessarily the administrative structure within which they are working.

One of the corollary hypotheses to this is maybe it doesn't matter much what the administrative structure is. It's entirely dependent upon the skills and personalities of the people involved and that there are very finite limits as to what we can do with manipulating an administrative structure. That may well be the case.”

Former SECDEF Gordon England: “The more complex the system, the more flexibility you need -- managers need. The trend is always the other way. That is, it gets more complex. We add layers of bureaucracy and regulation and control and that makes it almost impossible to run very complex programs.”

Now, these gentlemen aren't the first to say all this stuff, but I'm always encouraged to see that someone is saying it out loud. The trick is to make the leap from a House committee down to the actual project leaders who are doing the work... and perhaps more importantly, to the senior executives who provide direction to these project leaders.

More to follow tomorrow.

Bonus Time!

And for an extra treat, check out page 32-33 of the latest issue of Defense AT&L.

It's not in the table of contents. There's no direct link on the website. You gotta dig a bit to find it... but I think you'll find it's worth the effort.

Nightmare!

The latest issue of Defense AT&L is posted online now, and if I wasn't absolutely exhausted after moving out of my house today, I'd be REALLY excited about seeing my latest article hit the internets. It feels like I've been working on this one for a long time, and I really like how it came out.

Honestly, I'm too beat right now to even write anything about it. You'll just have to go read it. I'd love to hear what you think of it (after I get about 15 hours of sleep).

Nite-nite. I wonder what kind of dreams I'll have...

FIST & Failure

As I run around talking with people about the FIST (Fast, Inexpensive, Simple, Tiny) approach to developing new technologies & systems, I continue to learn and discover new aspects of it. My most recent ah-ha moment had to do with the way FIST projects fail.

I'd already written extensively about the fact that FISTy projects fail better (i.e. they cost less and teach more than a big, expensive, complex project). But another benefit is that FIST failures are easier to admit, and that's kind of huge.

Admitting the project failed can be difficult. But, because FIST projects use small budgets, short schedules and small teams, a FIST failure involves a relatively low degree of loss. That makes it less challenging emotionally to say "Hey, that one didn't work out." And when we make it easier for people to admit they discovered a dead-end, we make it easier for them to be honest and report the truth. We take away some of the incentives to dissemble and provide overly optimistic assessments.

I think that's kinda important.

Not Simple

In an attempt to interleave additional material into the blog, I'm beginning a series of posts that deal with Gabe's Take on the Defense Acquisition Guidebook. I recently finished a course on DoD systems engineering which draws heavily from the guidebook and I wanted to share the enlightening experience.

Have you ever planned to plan? If so, then this chart's for you:

Yes, this is a real chart, and there are literally hundreds more like it. Don't tell me this is hard to follow. This is as simple as it gets. It shows you right there in the figure how to verify something. How can it be any more explicit?

Like all institutionalized cogs, instructions are essential. Intuition and intelligence need not apply.

Ze Frank @ TED

I love Ze Frank and everything he does. He's brilliant, fascinating and hilarious. The embedded video is a talk he gave at TED. It doesn't really have anything to do with rogue project leadership... or maybe this is what it's really all about.

I know, it's kind of a long video. I dare you to watch it all the way through without pausing it to look up some of the stuff he talks about.

Rogue University, Reloaded

In the original RPL webzine, we ran a few articles about Rogue University. The basic idea was to encourage people to read a bunch of books that aren't in the current list of Top Ten Must Read Business Books, do something based on what you learned, then write something about what you did (and preferably publish it somewhere). And then we'd send them a certificate.

I still think that's a pretty good approach to adult education. I very much think people don't spend enough time reading books from the interesting end of the Long Tail. This has the unfortunate result of everyone thinking too much alike.

What this means to me is that if a lot of people recommend I read a particular book, I probably won't read it, particularly if they are people I hang out with and work with a lot. I'm not trying to be difficult here. I want to make sure I contribute something unique to the job, not just one more take on why the world is flat, for example (and yes I read it & enjoyed it. I also read all of Galdwell's books, don't worry).

So, I'm wondering what sort of books I would put on the Rogue University Reading Guide if I were to write one today. Orbiting the Giant Hairball would still be at the top of the list. I'd add Demarco's Slack too. And Gawande's Complications. And The Hacker Ethic., by Himanen. Everything by Scott McCloud (yes, the comic guy). Andy Nulman's Pow book. Dee Hock's The Chaordic Age.

How about you? Any recommendations from Rogue Nation on interesting reading material that isn't getting talked about much?

Moving Day

FYI, the nice people from the moving company are coming to my house over the next two days, to put all my worldly possessions into cardboard boxes. On Friday, they'll load the boxes into a truck, and with any luck, on Monday the 22nd will deliver these boxes to my new house in Virginia.

Somewhere in that timeframe, my family and I will also make the long drive from Ohio to Virginia.

I only mention that because I'm not sure how much I'll be able to participate in the comments section of this blog for the next week or so. I've lined up things to automatically post while I'm on the road, but the back & forth in the comments might be a bit light and/or late.

At some point, we'll get things unpacked and I'll have the time & mental bandwidth (and actual bandwidth) necessary to keep up with things here on RPL. And who knows, maybe I'll still pull it off despite the moving. But if not, I wanted you to know I'm not ignoring you. I'm just up to my elbows in cardboard.

Empowerment

Another nugget of insight from Tom Demarco's book, Slack.

Empowerment = the capacity to injure the person above you.

Wow. That makes me think about a lot of things. What does it make you think about?

Process Ownership, according to Demarco

Process should be a team asset (i.e. owned by those who execute it), rather than a corporate asset (i.e. imposed on those who execute it). – Inspired by Tom Demarco’s book Slack

If you've read any of my stuff for any length of time, you probably know I'm not a big fan of the current craze of process-centric management (and frankly, industry seemed to lose interest in it right around the time the DoD decided to drink the koolaid). Which makes my current job title quite ironic (it's something about chief of process improvement, I think).

A few posts back I pointed to the phenomenon of throwing out the process as soon as we have a high-priority project. In these situations, we tend to rely on talented people instead of process. The opposite never happens - a top priority project where we kick out all the talented people and instead institute a rigorous process. Oh, wait, that's basically what we do on the 90% of projects that aren't "top priotity."

Still, if we must have process (and for the forseeable future, it seems we must), it should be created, owned and modified by the people who actually have to use it, not imperiously imposed by those who don't actually do the work.

And frankly, I much prefer freestyling, done by Master Rogue Project Leaders.

CPI & Diminishing Returns?

I have a question for any "continuous process improvement" experts out there: is the CPI approach subject to the law of diminishing returns (each additional improvement yields smaller benefits than previous improvements)? If so, doesn't that sort of undermine the whole CPI mentality? If not, why not?

Here's what I'm thinking: If the law of diminishing returns applies to continuous process improvement efforts, that means CPI provides the biggest benefit during its initial phase, and provides smaller and smaller benefits over time. That might mean it's a good short-term strategy, but somewhat weak over the long-term... so maybe the "continuous" part is of dubious value?

I've only just started thinking about it in these terms. I suspect I'm on the right track, but I might be missing something here. I sincerely want to hear from people with CPI experience & insight - and my first round of google searches turned up precious little on the topic.

Productivity

Came across this great observation in Tom Demarco's book Slack.

The best predictor of how much a knowledge worker will accomplish is not the hours he or she spends, but the days.

The twelve-hour days don’t accomplish any more than the eight-hour days.

I find this to be very true in my own life and career. In fact, I tend to leave the office earlier than anyone else I know... and with all due humility I'll gladly compare my accomplishments and contributions with just about anyone.

Here's the thing - I'm an early bird, and I know my producivity, creativity and overall ability begins to drop off in the late afternoon. If I stick around the office for a few extra hours, the office is getting the least productive part of my day. Plus, it's keeping me from being with my family, which makes me itchy and hurts my morale & motivation. Those extra hours end up being a net loss, not a gain.

So - if you want to get the most out of me, let me leave early. Focus on the days, not the hours. And frankly, I'm writing that as a reminder to myself, as I get ready to head in to a new job in DC. I'm telling myself that not only is it ok to not work long hours... it's better for everyone if I don't.

A Thought on Cybersecurity

We should avoid a dependence on [a particular technology] that is out of proportion to our ability to protect it. – Ben Bova, Peacekeepers

I came across this line in a scifi novel I was reading a while back. It got me thinking about the way we have become so dependent on information systems, even though we haven't entirely wrapped our brain around how to protect them.

People have been defending physical entities for thousands of years. We've got a pretty good idea how to do it (walls, locks, undisclosed locations, etc). But not so much when it comes to IT. Our need for it continues to expand, and our ability to protect it is scrambling to keep up.

Not quite sure what to do about that. Surely the answer is not to avoid being so dependent on IT systems.

Real Acq Reform

The Deputy Secretary of Defense (William Lynn III) wrote an editorial in the Washington Times (June 4, 2009), titled Real Acquisition Reform. I thought you might enjoy reading a few excerpts:

He starts by pointing out this problem is a longstanding issue:

"Problems are deeply entrenched and have developed over several decades," one study noted. "Too many of our weapons systems cost too much, take too long to develop, and, by the time they are fielded, incorporate obsolete technology." That was the troubling diagnosis of a blue-ribbon commission - in 1986. Yet despite repeated attempts at reform, including more than 130 commissions and studies, the core problems persist.

So, why is this latest attempt going to be any different? Well, for starters, he points out the leaders are different:

in Robert M. Gates, we have a defense secretary determined to correct the Pentagon's failure to quickly deliver lifesaving equipment and technologies to our forces in Iraq and Afghanistan - failures that led him to simply bypass the traditional procurement system in order to equip those forces with the unmanned aerial vehicles and explosive-resistant armored vehicles they needed.

I've always thought our tendency to throw out the "traditional procurement system" whenever we have a really important project should tell us something about the value of that system. If the traditional process can't be relied on to deliver the important projects, um, why use it at all? If we don't use it for systems that really matter, does that mean we do use it for systems that don't really matter? What are we doing building stuff that doesn't matter?

The article goes on to talk about "new mechanisms to prevent endless "requirements creep" in which the desire for an ever-elusive perfect system can result in no system being delivered at all."

I'm always encouraged when people acknowledge that the perfectionistic pursuit of a system that delivers everything... doesn't actually deliver. Far better to take the imperfectionist approach, which says "I would rather have something today than everything tomorrow ('cause tomorrow never comes)."

none of these reforms will work unless we are prepared to take a final step - reforming or canceling weapons programs that are not on track to provide our warfighters what they need when they need it. We have started making those hard decisions in our proposed budget for next year.

Rather than take a business-as-usual approach to troubled programs - simply readjusting our expectations for cost, schedule and performance - we've canceled programs like the $19 billion Transformational Satellite program. This was a classic example of a promising but unproven exotic technology.

I admit it - I get a warm feeling every time I see a big failing project get cancelled. It's not that I'm unsympathetic about the jobs that get lost, but the military technology development community isn't a jobs program. It's supposed to be about making stuff that needs to be "available when needed and effective when used." Plus, people love good leaders, and the decision to cancel a failing project is generally a sign of strong leadership.

And can I also point out there's a HUGE difference between developing a new technology and building a new system? Building a new technology involves a large degree of exploration & uncertainty, using immature & unproven stuff. The point is to try to bring something to maturity. Building a new system, on the other hand, is all about putting something in the field. It's got to rely on proven, mature technologies. We get in trouble when we call it a system development project and it's actually a technology development project. That's the kind of stuff that needs to get cancelled.

being tough-minded on acquisition reform is part of being serious about a strong defense

I love that line. Cutting spending on failed projects doesn't mean you're weak on defense. It means you're strong on defense.

What Matters Most?

As part of my recent thesis research, I identified three kinds or success for system development projects. They are:

Programmatic Success: The system came in on time, on budget.

Technical Success: The system advanced the state of the art.

Operational Success: The system was available when needed and effective when used.

Project leaders will make very different decisions depending on which of these three they're aiming for. Of course we could aspire to succeed in all three dimensions, but all too often we settle for just the first two, or (even worse) just the first one. That’s a shame, because I think Operational Success is the most important of the three.

See, Programmatic success is all about the program manager's performance & self-interest. Technical success is all about the technologist's desires. But Operational success is about the end user's needs, and that’s the whole point, isn’t it?

I recently expanded the definition of Operational Success a bit, and now define it this way: affordable systems that are available when needed and effective when used. Note that “available and affordable” is not necessarily the same as “on time, on budget.” It’s a subtle difference, I admit, but I think the fact that the thing is ready for use when we need it, at a price we can afford to pay, is more important than whether or not we met the planned cost and schedule.

How about you? How do you define project success?

RPL Down Under!

Aussie blogger Craig Brown recently posted a little blurb about RPL on his always entertaining and stimulating blog, Better Projects. He's got a lot of good stuff about Agile and project management and other fun stuff.

Check him out!

Rogue Maturity Model

Carnegie Melon’s Software Engineering Institute developed something called the Capability Maturity Model Initiative (CMMI), which is “a process improvement approach that provides organizations with the essential elements of effective processes.” It basically involves assessing an organization on a scale of 1 to 5, blah blah blah. If you want to learn more about CMMI, go to the SEI website.

We here at Rogue University have come up with our very own assessment tool – the Rogue Maturity Model. It’s still a work in progress (and probably always will be), and we’re going to crowd-source it. That means you can contribute to the development of the RMM.

The Rogue Maturity Model assessment tool is a spreadsheet, available via Google Docs. Feel free to click on over, open it up and add your own recommendations.

Please let us know in the comments section when you add something.

Development Timelines

The amount of time you spend developing a system needs to be shorter than the mean time between significant requirements changes. 

In other words, the development time needs to be shorter than the requirement’s shelf life.

Social Media Interview with Dan

I did a little interview with social media blogger (and former Marine) Michael Brito, over on his Britopian blog.

He asked some great questions, and I really like how it came out. You can read the whole thing here. I'm hoping lots of RPL readers will stop by Michael's blog and leave comments!

War Is A Racket

It’s not often that a 2-star Marine Corps General, with a matching pair of Medals of Honor (that’s right, two medals of honor!), takes a stand against war. But Major General Smedley Butler, USMC, wasn’t your average Marine General.

After serving in uniform for 33 years on three continents, he wrote a small book titled War is a Racket (in 1935), in which he denounces the fact that nations go to war to enhance the profits of industrialists, while the costs of war are born by the poor. He offers an isolationist policy, and suggests that the military should focus on defending the shoreline, writing “I wouldn't go to war again as I have done to protect some lousy investment of the bankers. There are only two things we should fight for. One is the defense of our homes and the other is the Bill of Rights. War for any other reason is simply a racket.”

Now, I’m not going to go into a full analysis of Gen Butler’s ideas. I’m not even going to say whether I agree with him or not. However, I will say I agree completely with his denunciation of situations in which profits are privatized while losses are socialized, or where the few collect benefits while the many pay the costs. 

That was one of the main points of my Process Loss Cost article, and it’s one of the main flaws in things like Scientific Management, Business Process Reengineering and CMMI. It seems to me that the distance between payment and consumption should be as short as possible. The person gaining the benefit should also be the one paying the price. For it to be otherwise is indeed a racket.

I get a kick out of MGen Butler’s suggestion that the government be required to “conscript capital and industry and labor before the nation’s manhood can be conscripted.” He writes:

Let the officers and the directors and the high-powered executives of our armament factories and our munitions makers and our shipbuilders and our airplane builders and the manufacturers of all the other things that provide profit in war time as well as the bankers and the speculators, be conscripted -- to get $30 a month, the same wage as the lads in the trenches get.

Let all these kings and tycoons and masters of business and all those workers in industry and all our senators and governors and majors pay half of their monthly $30 wage to their families and pay war risk insurance and buy Liberty Bonds.

Why shouldn't they?

They aren't running any risk of being killed or of having their bodies mangled or their minds shattered. They aren't sleeping in muddy trenches. They aren't hungry. The soldiers are!

Give capital and industry and labor thirty days to think it over and you will find, by that time, there will be no war. That will smash the war racket -- that and nothing else.

MGen Butler was a radical and a rogue thinker. His book is worth reading. We proudly award him the posthumous Rogue Medal of Independent Thinking.

Do -vs- Get

Here’s a question for all the program managers out there. When you’re developing a new system, is the focus on making sure we “do it right” or “get it right”?

 

Doing it right is all about compliance with the proscribed processes and best practices. Getting it right is all about delivering the product.

 

I contend it’s more important to GET it right than to DO it right.

 

(I found the phrases in an article by Roger Atkinson titled Project Management: cost, time and quality, two best guesses and a phenomenon, published in the 1999 International Journal of Project Management, vol 17, No 6)

The Standish Group's Research

For several years now, I’ve been writing about the FIST approach to acquisitions.

For those who don’t already know, FIST stands for Fast, Inexpensive, Simple and Tiny. It’s a set of values that can be applied across the spectrum of decision making (organization, requirements, architecture, design, testing, etc), for all kinds of technology development efforts. Whether you’re building an aircraft carrier or a hand-held radio, there is always an opportunity to chose between fast and slow, inexpensive or pricey, complex or simple, and large or small.

I recently came across some research by The Standish Group that strongly supports the FIST approach. In fact, they make me look downright conservative. They write:

Our research has shown smaller projects are consistently more successful because of reduced confusion, complexity and cost.

… smaller projects experience fewer cost overruns.
… shorter time frames… increase the success rate.
… the more expensive a project becomes, the less likely its chance of success.
Time is the absolute enemy of all projects.
Our newest data suggests that we need to further reduce the amount of resources to increase the success rates even more. … no more than four people, for no longer than four months at a cost of less than $500,000. We find that the less the features, the greater the yield.

All I can say is yes, yes, a thousand times yes!

An Observation

It’s kind of funny that I’m doing this blog.

I’ve been writing four-page articles for several years now, and have sort of been itching to write something longer. Something book-length, with a bit more substance and nuance and completeness than a short article can contain. But instead, I find myself moving in the opposite direction – short blog posts.

And yet, a blog is more than a series of short, isolated posts. A blog is actually a continuing stream, and could end up being longer than a book, not shorter. With the opportunity to have discussions in the comments section – this may indeed be more substantive than a book. It has the potential to be richer, the ideas more fully explored and more dynamically developed. A book is a broadcast monologue – a blog is a conversation.

So, we’ll see how it turns out. I really appreciate all the comments & discussions we’ve had so far. I look forward to seeing how things develop.

If a thing is worth doing...

... it's worth doing badly (G.K. Chesterton).

... it's got to be done right now. (Peter's Laws)

... and it's fun, I'll do it. (Dan)

How about you? How would you finish that sentence?