19 March 2010

FIST & Failure

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

Let me just say: Arg!


Glen B. Alleman said...


Are you suggesting no matter the needed capability for the war fighter, the FIST approach is the solution to acquisition reform?

The Dan Ward said...

@Glen - Not at all. I'm saying that it's a funny question for that particular audience member to ask, after I'd just shared a stack of data showing that FIST projects fail less often and more gracefully.

In my briefing that day I also pointed out that FIST has "no monopoly, no guarantee." It's not the only way to do good work. It doesn't always succeed. But it's an approach to consider for several reasons, including the fact that it increases the likelihood of delivering "affordable systems that are effective when used and available when needed," and when the FIST approach does fail to deliver, this failure still costs less and teaches more than the long, slow, expensive & complex approach.

But is it the only way to go? Should it be used on every project? No, of course not...

Dick Field said...

Well, your retort to the attendee could have been, "Failures are part of life. Deal with THAT!" . . . but that might have been viewed as a tad confrontational, I suppose. :>)

These people need to be freed from the rote-based, insular, mob-think they have been schooled in. They need to think independently for a change.

Don't worry, Dan - it only takes a few initially who have the a-ha moment and "get it". From there, the geometry of social phenomena takes over!

Glen B. Alleman said...

I'd say the Ah Ha moment comes when the "buyer" realizes that over specifying the requirements rather than stating the needed capabilities is the way to success.

I've seen numerous times the ridiculous specification of some feature or function when little or no understanding of the beneficial outcome or the impact on cost and schedule.

Maybe the one benefit of FIST is to start to ask "why do we need this?"