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.

It Really Is Important

We've been talking a lot about social media here = it's important! If you are leading or directing people in any way, you should definitely understand why the use of social media is important to your team.

In my book, these "social" engines facilitate transparency; a critical attribute for organizations who want to accomplish anything. One of the best descriptions I've come across to explain why this is comes from the Standish group:

...transparency can be painful, but transparency reduces barriers to communication, builds trust, and accelerates consensus building and decision making.

It's important. Yeah Buddy!

A-Team versus MacGyver

Borrowing a theme from Bas de Baar's blog, let's talk about the A-Team and MacGyver.

Both shows were the awesomest shows ever. And please, let's not reignite the ugly A-Mac flamewars from the early 90's. As I said, I think we can all agree both shows were the awesomest. Please, put away your Swiss Army Knives and/or pickup truck with sheets of metal welded onto it.

Instead, the question I'd like to pose is, which show is a better model for project leadership?

No, we're not going to debate the relative merits of swiss army knives versus vehicles with sheetmetal welded onto them. Instead, let's talk about the underlying problem solving approach the two shows used. These approaches can be described as "I love it when a plan comes together" (A-Team) and "I'll figure it out when I get there." (MacGuyver).

Both shows involved resourcefulness. And let me say it again, both were equally awesome. But one clearly relied on planning before execution, while the other was more focused on improvization during execution.

Given the technological, social and economic environment we find ourselves in these days, I'm going to say MacGuyver's approach is probably the most productive model to follow. And I just know Mr. T is going to call me a fool for saying that...

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.

Waste

In a recent briefing, someone explained that a Lean Six Sigma analysis showed that 90% of what an organization does is "waste." Further research showed that the almighty Toyota, Masters of Lean, manage to occasionally reduce their waste to only 70% (on a good day).

Ok, this is me waving the BS flag.

First of all, how do we define "waste"? How do we measure it? Is all inefficiency in that category? And really, how much waste is appropriate? Should we aim to get to 70% like Toyota? Should we be content with 90%? His point seemed to be that there's a lot of improvement to be made. I'm not sure he really understood the implications of what he was saying - isn't it possible that 90% (if that's even the right number) is absolutely the least amount of waste we can reasonably expect to produce?

It really gets back to the question of rational optimization - and regular readers of this blog know I don't believe in optimization, at least not when it comes to human-centric activities like project leadership, technology development, etc. Yes, there's something to be said for streamlining our efforts... but there can also be great value in creative exploration, even if it doesn't lead directly to the outcome we think we want. Sometimes the messy, inelegant preparation phase of the project is the most fruitful (eventually), even though it appears to be "wasteful" at first.

Vote For Dick!

BONUS POST

Our good friend and fellow Rogue Dick Field is, in addition to being a true Rogue Project Leader, an actor. He recently sent me a note informing me about his latest adventure, which I share with you now. I hope you'll click on the link and vote for him to get a walk-on part on Mad Men!

I entered this joint promotional deal between Banana Republic and the the trendy, retro TV series, "Mad Men". (If you have to ask, you must not be trendy and retro. Oh . . . all right -- it's a series about Madison Avenue advertising men in the late 50s and 60s.) Anyway, the store and the TV series are running a casting call for a walk-on part on the series. You can find my entry at: http://madmencastingcall.amctv.com/photos/view/181. -- AND, true to the current preference for popularity over talent (which is decidedly NOT a 50s-60s thing), part of the casting competition is based on votes! So, here's your chance to vote for ME (it's all about ME) by clicking on any of the stars at the bottom of my headshot. --AND you can vote once EACH DAY! So . . . VOTE and VOTE OFTEN. Here's my big chance to see if they love me, they really love me!

RPL on Flickr

Hey everyone, I just created a little RPL group over on Flickr. Here's what I want you to do:

Wrap up your knuckles in tape, write FIST on the tape, take a picture of it, then add it to the RogueProjectLeader group on Flickr (I used masking tape for the picture on this site, btw).

Bonus points if you also submit a photo of yourself wearing a fake mustache. Double bonus points if you're wearing a fake mustache and you're female. Drop a comment here when you've done it. Have fun!

Are You Happy?

I first met Mr. Terry Little several years ago, when he was director of the Air Force's Acquisition Center of Excellence (ACE). He is a legendary project leader, an original Rogue, and a man who not only has an impressive track record, but is also a genuinely warm human being. His smile is kind - almost shy - and he is what I'd call "an insightful listener." I wouldn't mind at all being like Mr. Little when I grow up.

A few weeks ago, I ran into him again. We chatted a little about things (he's retired now), and as I told him about my job, he asked "Are you happy?"

Whoa.

There was something in the way he said it that was completely unobtrusive and yet firm. He wasn't just being polite - he sincerely wanted to know, he sincerely cared, even though it had been years since we'd seen each other. It was clear that this was a priority for him, but not in a checklist sort of way. More like a lifestyle kind of way.

It was a question he wanted an answer to, but it also felt a bit like a challenge, in the best possible sense of that word. There was a subtle, affectionate insistence, somehow, that I should make sure I'm doing things that make me happy. He wasn't challenging me to give a specific answer. He was challenging me to make sure I'm on the right path, for the long haul. When he asked, it felt a little bit like someone had hit a tuning fork at just the right frequency, and the question vibrated through my brain.

Yes, I said, I'm happy. I've got a good job, with a good mission and a good team. I've got a real opportunity to make a difference, and I'm having fun doing it. The house and the neighborhood we're in are very nice. The family's doing well. And I've just been taught a lesson at the foot of a Master... a lesson in humanity, leadership and, well, humanity.

I don't know how long it will take me to learn to ask questions the way Mr. Little does. I suspect it'll take a while. It's been several weeks, and I can still see that scene in my head. I can still hear the question. Here, let me try asking you: Are you happy?

Best Practices - NOT

At the Social Media conference last week, several people mentioned they were looking for "best practices." These were inevitably the same people who also insisted on the importance of "thinking strategically" when it comes to social media.

It seems to me that both sentiments have the same root. Namely, both are expressions of a modernist worldview, in which rationality can supply all our needs and activities can be optimized. I'm just not sure this worldview stands up to reality. It makes sense logically, but experience tends to disprove it. When that happens, we can't blame the world for not living up to our theory (but Strategic Best Practice advocates often seem primed to do just that).

Best practices are someone else's best practices. We should use them for illumination, not imitation. We should reflect on them, not just copy them. And strategic thinking is all fine and good if we mean intentional, thoughtful consideration of our eventual objectives... but not if it means locking down those objectives before we even begin.

Thought of the Day

A failure to tailor the process is a failure to execute the process.

BigDog -vs- Mules

My buddy Rhet sent me a link to a post on the Small Wars Journal about some transportation methods being developed for the US Military. Specifically, a robot named BigDog that can haul 380lbs over some very rough terrain. Check out the video below - it's pretty sweet looking.

HOWEVER (and it's a big however), the every thrifty and innovative Marines have figured out a way to haul heavy loads over rough terrain, using a very mature "technology" that doesn't require batteries, replacement parts or even gasoline. Yup, they use mules.

Which makes me wonder - if mules can effectively accomplish the mission, is the BigDog really necessary? Yes, BigDog is cool. I love it. I've watched this video several times and it gets me all excited. But the real question is, is it better?

Maybe it is. But frankly, that's likely to be a matter of opinion ("better" being a rather subjective word, don't you think?). And clearly, mules are the FISTy option.

Thoughts?

Social Media Conference

I just spent two days at a "Social Media In Government" conference, sponsored by the Advanced Learning Institute. It was definitely an interesting time, but some presenters were much better than others.

Hillary Hartley, of NIC Inc definitely deserves a shout-out. Her presentation was fantastic and a real highlight of the two days. She demonstrated a most profound and comprehensive understanding of Web 2.0, Government 2.0 and social media, and did so in a language that everyone could easily understood. Plus, her slides rocked!

Which makes me wonder - for a group of professional communicators (and most of the presenters fit in that category), why oh why were so many of the slide presentations so crappy? I mean, in more than a few cases the person was a good speaker, the content was top-notch, and the actual slides were h-o-r-r-i-b-l-e (i.e. word-dense, bullet points, bland, etc).

And there was one presentation in particular, who shall remain nameless, who didn't belong at the conference at all. He was a fantastic storyteller with a gripping yarn to spin. I really enjoyed his bit. However, I cringed every time he said "social media" because he clearly doesn't know what that phrase means. What he meant was "online media," which isn't the same thing. Just because you post a podcast doesn't mean you're doing SM.

Getting Started

Let's take a look at two different approaches to starting a new development project:

1) I've got X dollars and Y months - what capabilities can I get?

2) I need to be able to do X - what's it going to cost me and how long will I have to wait?

In both cases, we have constraints. In the first situation, the constraint is resources. In the second, it's the need. I'm going to suggest that in reality, scenario #2 is much rarer than scenario #1. However, we all too often act like #2 is the only way to do business.

Here's the thing - we often don't really know what we need. We generally have some idea, but our understanding of the ultimate objective is going to change over time. The longer the time, the more it'll change.

That's not bad!

We should expect some change, plan for it, and seek it out. Attempting to lock down our requirements on Day 1 (when we know the least about the project) is pretty stupid... unless delivery is scheduled for Day 2. And it's entirely possible to end up with something that is simultaneously different than what we thought we needed and better than what we originally aimed for.

Let me put it bluntly: on a long project (i.e. anything over 6 months), requirements creep is good. It shouldn't be a surprise, and we shouldn't resist it. We should count on it and perhaps even insist on it.

Two additional comments: It's important for the user to be informed, educated and involved. The ultimate customer (warfighter, user, etc) needs to be continually involved in the development effort, communicating truths about the operational environment and learning about the possibilities and limitations of technology. It's also important to foster a trusting relationship between all involved. I refuse to do business with people I can't trust.

Hal Macomber over at the Reforming Project Management blog has some great stuff to say about projects, process and getting stuff done.

I particularly liked this line from a post titled Time to Re-Th!nk Improvement: Don't improve on something that we shouldn't be doing in the first place.

This is a topic that’s come up in the comments section of several recent blog posts here. And indeed, the persistent focus on “process improvement” in so many organizations these days seems to presuppose we’ve established good, meaningful objectives. Similarly, my own rants AGAINST process-centric thinking often make the same presupposition, that we have a decent idea of what we really want/need.

It’s probably time for this blog to take a closer look at the kinds of goals we should be setting, the kinds of projects we should be pursuing, the kinds of requirements we should be writing, etc. In other words, to take a look at ends and not just means.

More soon…

FIST Thesis

My thesis, The Effect of Values on System Development Project Outcomes, is now available online, via the DTIC website.

It examines a couple dozen historical military system development projects, both successes and failures, and looks at the role the FIST values (Fast, Inexpensive, Simple, Tiny) played in the operational effectiveness and program outcomes.

Check out page 2 and see if you can find the slight addition I made to the traditional disclaimer.

It's Not A Machine

One of the common problems we often encounter as "rogue" leaders in today's project management environment is the use of engineering and scientific principles to govern the mechanics of human interaction.

This is specifically seen in the unique way certain entities like the government spin concepts like Systems Engineering, Continuous Process Improvement, etc. The framework of these concepts read like a big computer program with line after line of instruction sets attempting to define every possible action an actor need take with no regard for the actor themselves. "These frameworks are portable and scalable", the propaganda reads, "you can use them at any level for anything." Yet, just like a computer, the actors are reduced to cogs with no self intelligence what so ever. How does this really work when the cogs are human beings who do more than simply follow instructions?

I think these concepts are myths of management. This really excellent article by Christopher Paperone, from Defense AT&L magazine, pokes holes in some of the these myths.

"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."

Unique

One more bit of wisdom from Alex Laufer. The only comment I want to add is an invitation for process-oriented people to reflect on these three words:

Projects are unique.

Procedures Foster Fear

As I mentioned yesterday, Alex Laufer's presentation on project leadership really got me thinking. And there's one comment he made, almost as an aside, that really stuck in my head:

"Procedures foster fear."

That is, formalized procedures create an environment in which under-led and over-managed employees frequently face the fear of noncompliance. As the rule set grows and gets more complex, a person's ability to know and understand the rules decreases. And yet, the rules must be followed... thus the persistent fear of being criticized for non-compliance. [not that every set of formalized procedures leads to under-led / over-managed people... but it doesn't help].

That's why we need more punks in our organizations. Punks don't care about fitting in and following stupid rules. Punks don't mind criticism by The Man. Punks have a certain type of fearlessness. It's something the organization needs, sure, but punks don't do it for the organization. They do it for themselves and their peers... (and yes, this benefits the organization).

And cool things happen when the punks get in charge. For starters, there are fewer stupid rules, less complexity and less confusion. And that helps drive out fear, as Deming recommends.

Dr. Alex Laufer

I've been a fan of Dr. Alex "Call me Alex" Laufer for many years. I've read several of his books, and recently had the opportunity to see him give a presentation and came away with a significant collection of observations and notes.

One of the most significant bits was when he pointed out that the traditional "First, define the problem. Then, solve it" approach is (and I quote) "almost always wrong.

Go ahead, take a minute to let that sink in. It's the way we do things 99% of the time. But when applied to projects, it's "almost always wrong."

The alternative Alex proposes is to focus on discovering goals and requirements as the project progreses. It's sort of a recursive approach to uncovering emerging objectives. Consider: the early days of a project are when we know the least about it. And in this state of maximum ignorance & uncertainty, it is silly to try to nail down requirements and solidify cost & schedule estimates. Thus, the recursive approach, which views requirements and goals as Things To Be Discovered.

More from Alex's presentation coming soon...

Background: Alex was kind enough to contribute a few articles to the original version of RPL, back when it was a webzine.

Process Ownership Redux

As a guy who writes a lot, I have a real fondness for phrases and try to make a note of particularly elegant and insightful combinations of words. I recently came across the phrase "remote from the consequences" in an article in The Week (a magazine I really enjoy and highly recommend, btw), and I quickly developed a word crush.

It's a dangerous thing for decision makers to be "remote from the consequences" of their decisions and actions. I'm thinking about project leaders in particular, but I'm sure it applies to other situations too. Remoteness leads to all sorts of things that sound good on paper but don't work so well in reality (unbeknownst to those who are remote), or situations where benefits convey to one (remote) group while costs are borne by those who are more proximiate to the consequences.

This ties back to an earlier post about how process should be a team asset rather than a corporate asset. We could say it this way: processes should not belong to those who are remote from the consequences. Process belongs in the hands of the proximate.

Gabe's Rant on Terms

Here is the "solution" to the puzzle I posted regarding the term:

Technical Planning Technical Management Process

I attempted to give the answer in the comments of the post, but it was so lengthy that I decided to make it into a post. Unfortunately the description of the above term isn't an easy one, which is the point I was making. In fact, my explanation may be wrong, but again that's the point. The terms and syntax used in the systems engineering course I took are so hard to understand, who really knows what's going on.

There are three types of overarching processes in the systems engineering construct as taught by the DoD. One of these is the Technical Planning Process. The Technical Planning Process is broken into two other processes: Technical Management Process and the Technical Process. The crazy thing about this scheme for describing "systems engineering" concepts is that it uses verbs as proper nouns. This term is qualifying that you are performing the technical management function of the technical planning process.

No, I am not kidding!

A Shameless Plug

While we're talking about simplicity, now is as good a time as any to put in a plug for my book, The Simplicity Cycle. You can download the PDF for free, so there's no reason to not get a copy for your own self (and of course the hardcopy is available for sale as well).

The Simplicity Cycle is built around the idea that complexity and goodness are not always directly proportional. That is, when you're designing something, be it a system, an organization or a process, increases in complexity don't always make it better.

One of the main applications of the Simplicity Cycle is to assess the value of a proposed change to a design. Before instituting the change, we can reflect on whether it increases or decreases complexity, and whether it increases or decreases goodness. Read the book to learn more...

Good Enough

Quick follow-up to the previous post, from an article in the latest issue of Wired. The article takes a look at the Nike+ system (a joint project between Nike and Apple, which allows runners to track their distance & speed).

"Nike+ isn't a perfect tool; it wasn't designed to be. But it's good enough, and more crucially, it's simple... The iPod wasn't a massive hit because it was the most powerful music player on the market but because it offered the easiest, most streamlined user experience."

Just one more example of the way simplicity trumps perfection.

Worse Is Better

I'm a self-described "imperfectionist," much preferring an imperfect-but-feasible approach over a perfect-but-unobtainable one. This preference covers technology design and organizational structures, as well as processes, etc. In practice, imperfectionism is a preference for simplicity over complexity and adequacy over completeness.

A while back, I came across a little paper by Richard Gabriel, titled The Rise of "Worse is Better." The context of this paper is software (Lisp specifically), but I think it applies to all sorts of design work. Gabriel's philosophy is very much in line with my own imperfectionism, and his paper offers the following insights, which I offer for your consideration:

Simplicity is the most important consideration in design.

It is slightly better to be simple than correct.

...it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementation complexity or inconsistency.

Completeness can be sacrified in favor of any other quality. In fact, completeness must be sacrified whenever implementation simplicity is jeopardized.

The worse-is-better philosophy means that implementation simplicity has highest priority...

... worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.

... it is often undesirable to go for the right thing first. It is better to get half ofthe right thing available so that is spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.

Any reaction to these ideas?