Restraint and Failure

One of the key points to the FIST value concept is the idea of restraint. We believe restraint is absolutely essential for any project leader who values completing an effort quickly with the maximum amount of goodness. Lucky for us, this recent article in WIRED magazine highlights just how important restraint really is.

How Success Killed Duke Nukem

On a related note, it's fantastic to see a major publication acknowledging the value of failure (WIRED's Jan issue is all about failure). We often talk about the importance of failure and how the FIST values increase your chance of an optimal failure - were much is learned and little lost. I highly recommend the issue.

FIST Video!

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.

Cancelling Projects

From a justice perspective, it's important for an accused person to have a good lawyer. Even if the defense attorney thinks the client is guilty, they are still supposed to provide a robust defense and make the strongest case possible.

Unfortunately, program managers often act like defense attorneys for their projects. They sometimes act as if their job is to keep the project alive, and defend it to all comers... even if the project is a dog and needs to be cancelled.

The program manager (arguably) knows the most about the health and viability of the program. If it's heading over a cliff, aiming for irrelevance or otherwise doomed, the PM is usually among the first to know, and should speak up. Sadly, this does not always happen.

PM's are not defense attorneys. Their job is not to keep the program alive and out of jail. It's to guide and shepherd the development. And if the program needs to be cancelled, the PM should lead the charge.

Failure

You might have heard the saying "If you fail to plan, you plan to fail." Here's a different twist on it:

"If you don't plan to fail, you've failed to plan."

As I've said elsewhere, failure is inevitable. It shouldn't be a surprise that things don't work out the way we'd hoped. So, rather than trying to prevent and avoid all failures, we should have a plan to deal with it, learn from it, respond to it.

In The Mythical Man Month, Brooks writes that software programmers should "plan to throw one away." That sounds like planning for failure to me. I think it's a pretty good idea.

Bad Power Point

Holy cow there's a lot of bad PowerPoint out here. In fact, there are almost no good presentations.

It's not a new problem. I found an article from 1985 titled Let There Be Stoning, complaining about boring presentations and suggesting that such people should have rocks thrown at them. I wouldn't go quite that far, and I dislike the part in the article where the guy describes his public criticism of a particularly bad presenter. But seriously, something needs to be done.

Nobody likes to sit through a dense, convoluted presentation, do they? And yet, the standard approach is exactly that. It hit me the other day that we design our presentation slides the same way we design weapon systems - complex, endless and ineffective.

I think a big part of the problem many of us never got any training on how to create good presentations. It just wasn't part of the curriculum when we were in school. And yet, that's a big part of the job. It seems to me that it's incumbent on us as professionals to educate ourselves on how to communicate effectively.

And I nominate Garr Reynolds' Presentation Zen book & blog as a great starting point. If you give presentations, please please please read his blog, get his book, and start doing things differently...

FIST Presentation

Gabe and I recently had an opportunity to do our FIST (Fast, Inexpensive, Simple, Tiny) presentation for the Defense Acquisition University. It was a fun time and a great audience. They even let us take home some of the cool posters they made to advertise the show.

The more time I spend in DC, the more convinced I am that this message needs to get out there. There is such an infatuation with complexity among military technologists, and there's a widespread belief that things would be better if we just had more money, more time, and bigger teams. And don't get me started on the preference for formal processes, control and mandatory activities.

While the FIST ideas generally get a good reception and seem to resonate with our audiences, I'm coming to see exactly how counter-cultural these ideas are. We've got quite a fight ahead of us if we're going to try to get wider acceptance of the FIST approach. Wish us luck!

Contracting Fail

I recently came across this post from Cliff at the Sunlight Labs blog, talking about their failed attempt to bid for a government contract (thanks to Dick for the link!). I say "their failed bid," but in fact I think it's more like the government's failure to get their bid. The current government environment is so insular, jargon-heavy and complex that a new company ends up facing all sorts of unnecessary barriers. Sunlight Labs ended up not even submitting their proposal.

But that's a discussion for another day.

What I want to comment on is their attitude to the whole thing. They looked at it as a learning and growing opportunity. They looked at it as a failure, yes, but a head-held-high kind of failure. Something to reflect on, learn from, and discuss with a wider community. They even acknowledged that, as it turns out, the project they'd planned to bid on was probably too big for their organization to effectively achieve. Now that is clearheaded humility and insightful self-awareness.

Their experience definitely gave me something to think about. I love their story, and I love the way Cliff tells it. And so we award Sunlight Labs the coveted Rogue Medal of Awesomeness.

Colbert Speaks Our Language

To follow up yesterday's post, here's Dr. Stephen Colbert with the best commentary on the F-22 yet!

The Colbert Report	Mon - Thurs 11:30pm / 10:30c
ThreatDown - Henry Louis Gates Jr., Bill Gates & Wilford Brimley
http://www.colbertnation.com/
Colbert Report Full Episodes Political Humor Mark Sanford

Yeah buddy!

F-22 RIP (?)

With the Senate's recent decision to not fund additional F-22's, I'd like to take a moment to say, with as much respect and propriety as possible, WOO-HOO!

Ahem.

And I was also thinking that now might be a good time to highlight some of the reasons it's a good idea to not spend more money on the Raptor.

1) The SECDEF, SECAF and CSAF don't want more. In fact, the Secretary and Chief wrote an OpEd in which they said it's "time to move on."

2) Despite going operational in Dec 2005, the F-22 has yet to fly a single combat mission in either Iraq or Afghanistan. Where is it flying? Alaska - where it (ironically) performs the mission that was envisioned for it back in 1981: keeping the Russians away. Yes, I suppose that's important, but hardly the top priority for today's DoD... or tomorrow's... or the day after that...

3) It's too expensive and has all sorts of maintenance problems (both of which probably contribute to #2).

Ultimately, I think the problem with the F-22 is that we've spent too much time and money on it. We made it too complicated (both operationally & technically). The end result is technically obsolete and operationally irrelevant (for example, it can't share data). Did you know we started the F-22 Upgrade program BEFORE it went operational? Um, shouldn't we at least start flying it before we upgrade it? [note: I can't put my hands on the link to support that statement at the moment, but lemme know if you want it & I'll track it down.]

If we'd focused on simplicity and insisted on budget & schedule restraints, we might have ended up with a system that was Affordable, Available when needed and Effective when used.

Instead, we ended up with one that's hugely expensive, not available on time and not suited to the military's needs. And did I mention it can't share the intel it collects (except with other F-22's)?

The lesson for the rest of the world is pretty clear. A lack of restraint, an infatuation with complexity and a dependence on political support to keep the project alive leads down a dark and ugly road.

Rogue Project Leaders take note. Rogue projects are generally quick, inexpensive, simple and unloved and/or ignored by the Powers That Be... and that's a good thing.

"Process Performance Failure"

I recently came across an article titled "Understanding the Roots of Process Performance Failure." One of the authors is Dr. Bob Charette, the guy who wrote the great article for IEEE Spectum titled "What's Wrong With Weapons Acquisitions?"

The article asks why "there is an increasing gap between program cost, schedule and technical performance requirements and the capabilitiy of program teams to realize them," particularly given the "increased process focus within DoD programs."

The analysis indicates "software, systems engineering and management processes... were primary contributors to poor program performance." [emphasis added]. The authors also observe that "in 80 percent of the assessed programs where no process adherence issues of merit were found, process capability issues were still discovered." In other words, 80 percent of the time the project teams followed the process, but still had performance problems. The processes themseles were causing poor performance.

How could this be? Isn't "Process" supposed to improve things? The authors explain "Process adherence is mistakenly seen by too many program teams to automatically equate to process capability..." Further, "adherence-oriented models... are based on a generalized organizational standard of what most projects require, not on what any specific project requires. While these process models are intended to be tailored for specific program needs, the data suggests that in practice they often are not..." [emphasis in original].

The point is that there's a big difference between compliance & adherance on one hand, and creative, imaginative application on the other. Processes are supposed to be tailored. If we don't tailor them, we miss the whole point, because as Alex said in yesterday's post, "projects are unique."