Values

I haven't talked about the topic of values in a while, and after some lively discussions with B. Smitty, I figured I'd spend a little time on the topic again, because assumptions about values are at the heart of most of the problems in project leadership (and a lot of the disagreements too).

The values I have in mind are "the things we think are important." In engineering speak, values are measures of merit. They are the signs of sophistication and other desirable attributes (and the context I have in mind is organizations, technologies and processes). This stuff matters because our values shape our objectives, and at the end of the day, values are the yardstick we use to assess whether good things have happened or not.

In my FIST-related writings, I talk about values as the answer to the question "What is important and good?" and I often describe FIST as a values-based approach. It basically says "It is important and good to be Fast, Inexpensive, Simple and Tiny." There are other value sets out there, and mostly they go unstated, unexamined, unconsidered and untested. That's a HUGE problem.

See, if we value complexity (either explicitly or unconsciously), we'll make the system more complicated and think we've done something good - even if it's not actually any better. You see this a lot in PowerPoint presentations - people who think they are effective communicators because they included every word, every comma, every data point and every possible nuance of every diagram in their 800-chart presentation (for their 15 minute time slot). You also see this in over-engineered systems, chock-full of a million good ideas. I'm going to suggest these are examples of values out of whack. Overvaluing complexity drives unproductive behavior.

Similarly, if we think spending a lot of money guarantees quality, we'll feel reassured by a high price tag, even if a smaller price might have delivered better results, better quality. Same thing with time - if we value the slow-and-steady approach, the fact that it took 20 years to deliver a system gives us a warm feeling, even if such expenditures were unnecessary.

So, the questions are: what values drive your project? What values contribute to positive outcomes, and improved operational effectiveness? And to come full circle to the afore-mentioned discussion, when people praise the F-22 as "the most capable aircraft" in our inventory, what are they really praising? What values are driving that assessment? What basis is there for those values?

Frankly, this question doesn't come up often enough in program management circles, which is a bummer because I think it's at the core of the whole discipline.

The One Thing

If there was one thing I could accomplish professionally, one contribution to the corpus of program management practice and theory, it would be to dispell the Myth of Inevitability.

What is this myth, you ask? It's the idea that high tech system development projects (weapons, spacecraft, commercial products, etc) inevitably take a long time, cost a lot and are complex. The myth is expressed in phrases like "better, faster, cheaper - pick two." A corollary to this myth is the idea that adding time and money to the project improves the outcome, as if the problem with our failed system development efforts was that our schedule was too short and our budget too small.

No kidding -that's what they said when the 18 year, $7B (billion-with-a-b) Comanche helicopter was cancelled. They needed more money. They needed more time. Yeah, that would have helped. Right. A similar chorus rises from any number of failed high tech projects. My assessment is that they had too much time & money, not too little. And at the core, they believed that the costs and delays were inevitable, simply an inherent part of this kind of work. It's a tragic belief and a self-fulfilling prophecy. It's also not grounded in reality.

The truth is, there is nothing inherent in military technology (for example) that requires it to cost so much, take so long or be so complex. Yes, systems like the F-22 took a long time and cost a lot. But there's a difference between "it took a long time" and "it takes a long time." We could have done it better (both programmatically and operationally). If we set up our values correctly, if we cherish our constraints and pursue intelligent simplicity, we don't have to spend billions and decades. We can do it for millions and in years (or thousands in months). The F-117, the SR-71, NASA's Near Earth Asteroid Rendezvous (NEAR) mission and the Pathfinder Mars mission are all examples of high-tech projects built on a FIST (Fast, Inexpensive, Simple, Tiny) foundation.

Despite the evidence of a significant portfolio of FISTy projects (documented in my master's degree thesis), the Myth of Inevitability insists that things like this have to be complicated and expensive. Believers in the myth see no alternative to bureaucracies, technologies and processes that are complex, expensive and slow.

Their failure to see through the myth reflects ignorance of the past and a lack of imagination. There are alternatives. Download a free copy of The FIST Handbook for more details on the principles, activities and examples of how to use constraints to foster creativity and deliver systems that are simultaneously faster, better and cheaper.

FIST Handbook - Updated

Team Rogue and I put together an updated version of the FIST Handbook (pun intended - sorry!), which collects the best of our articles from Defense AT&L.

Unfortunately, the file format has some incompatabilities with Lulu, so the version you can download on RoguePress is out of date. The new version is 12Mb, and rather than try to email it, I stuck it on Rapid Share. You can download your own very version right here.

Enjoy!