Simplicity Friday: Trust

Oops - this was supposed to get posted yesterday, but apparently I failed to click the right button or something. Here it is, a day late.

Leading a system development project is ultimately about people. It's about how you treat people, and we might even say it's about love. And along with loving the people on your team, I suggest that trusting them is pretty important.

For example, despite what we've all heard about assumptions, I contend it's important to make several key assumptions about the people around you. I find great value in assuming they are honest and competent. If you assume the people around you are not honest or not competent, um, you're hanging with the wrong crowd (and frankly, you're probably wrong about their honesty & competence). In fact, I'll even suggest that the ability to make these assumptions about people is a key competency for project leaders. Let me be blunt: if you can't trust people, find a different line of work.

Yes, yes, it's important to test and confirm these assumptions. Sometimes you'll be proven wrong - dishonest & incompetent people exist, and you're bound to run in to a few eventually. Sometimes, you'll get burned. But the going in position in any encounter must (MUST MUST MUST) be to trust the honesty and competence of the human being across the table. Because if you start out distrusting, you're going to burn yourself even worse (and probably won't even recognize you're hoisting yourself on your own petard). For a more rigorous description of this argument, check out a 2004 article I wrote titled The Program Manager's Dilemma. Or read just about anything on the topic of McGregor's Theory X and Theory Y.

Why mention this on Simplicity Friday? Well, it turns out trust is much simpler than the byzantine monitoring structures we establish to determine compliance. So if you want to simplify your organization, your process, your interactions with people and your procedural structures, think trust. It works - trust me. :)

Bragging, Army-style

Had a great time at a recent conference, and was particularly struck by the comments of one of the keynote speakers.

MG Myles, from the Army's Aviation and Missile Command, gave a fantastic speech. What I particularly liked was the stuff he bragged about. He bragged about his organization's commitment to teamwork - frequently using the phrase "working hard to work together." And this wasn't empty boasting either. Everyone I talked with reiterated that teamwork was a top priority.

Note that he wasn't simply bragging about how well everyone worked together. He was emphasizing how much everyone valued working together. It wasn't easy. It wasn't automatic. It wasn't perfect. But it was something they work hard at.

He also talked about delivering systems early & delivering them inexpensively. He consistently described how his command used existing stuff in new and interesting ways, modifying them slightly to create big operational improvements. He never once expressed any infatuation with shiny new objects or high-tech objet du désir. He was clearly only infatuated with delivering meaningful capabilities for his soldiers. The concept of process compliance didn't come up once.

It was refreshing to hear that kind of talk. It was motivating. It was awesome.

Weird Wednesday: Rogue Wallet

I'm sure all the readers of Rogue Project Leader will be excited to hear about this amazing new invention: the Rogue Wallet!

It's a "scientific, stylish solution" designed to fit into your front pocket. As you can see, one of the corners is clipped off into a stylish, scientific curve, thus allowing you to place it comfortably in a front pocket. You can also get an RFID shield for it, to prevent "skimming theft."

I actually think it's kinda cool... and also kinda weird (in a good way, right?).

Don't Do This

Twenty-five minutes after the presentation was supposed to be over, as we finally arrived at the last chart, the briefer said "I don't know how I'm doing on time - over, under...?"

Rule #1 of giving briefings: Know how much time you're supposed to spend.

Rule #2: Know what time it is.

Don't be the only one in the room who doesn't know when you're supposed to be finished. I promise you everyone else is very much aware.

(Hint: all those people who got up and left 15 minutes ago should have been an indication...)

Defaults & Standards

I recently overheard a comment about how to improve the military acquisition business, and I hope I misheard it. What I think this particular person said was "We need to be able to do rapid acquisitions if we have to..."

The implication was that the ability to develop systems quickly was a necessary evil. Sure, if you really MUST deliver a system quickly, I guess we'll need to have that capacity, but really, we'd much prefer to take our time.

That just seems upside down to me.

Shouldn't the fast, inexpensive approach be the default? And sometimes, if we really have to take a long time & spend a lot of money, we should have the capacity for doing so. But shouldn't that be the exception rather than the rule?

Faster, Better, Cheaper- Revisited

The latest issue of Defense AT&L is posted online - my article this time is titled Faster, Better, Cheaper - Revisited.

In this article, I take a look at NASA in the 1990's, during their Faster, Better, Cheaper era. I think you'll be pleasantly surprised by what the data actually reveals about their accomplishments during that time.

Simplicity Friday: Coupling & Cohesion

Today's topic is the systems engineering principle of high cohesion / low coupling.

This principle actually has its roots in computer science & programming. The basic idea is to make each module focused and relatively independent, so that changes to one module don't ripple through the rest of the software. You'd like to have it so you can modify one module without having to go through and modify the rest of the code. This guy did a nice writeup about the concept, if you want more detail.

In a hardware context, this translates to standardized interfaces & outputs - sort of a black-box approach to modular design. In a good design, you should be able to pull out one part and replace it with something else with minimal (note: not necessarily zero) design implications for the rest of the system.

This approach takes effort and planning, but it simplifies the overall design, simplifies testing and simplifies upgrades.

Impossible!

I was recently told the FIST (Fast, Inexpensive, Simple, Tiny) approach to system development "can't be done."

This was expressed quite emphatically, in exactly those terms. Emphatically and, sadly, quite publicly. Not sad for me - sad for the individual raising the objection. I'm afraid he didn't boost his credibility much...

Naturally, this assertion of FIST's impossibility came as a surprise to me, since a) I've done it several times and b) I'd just spent 30 minutes telling stories about other people who have also done it. Undeterred by these stories, testimonies and examples, the gentleman stood his ground. FIST can't be done. Hmmm...

Now, my first impulse was to suggest that "the person who says a thing can't be done should never interrupt the one who's doing it." (not sure on the source of that quote) But that wouldn't have been polite & respectful, so I demurred.

Instead, I said something along the lines of "Well, you're free to not try to do things this way if you don't believe it's effective, but it's something I'm going to continue doing..." And then I continued with my presentation.

In retrospect, that wasn't a great answer. What I should have done was acknowledge that this individual had apparently encountered a situation where the FIST approach did not work (possibly because it wasn't tried?). And then I should have suggested that the existence of a situation where things weren't FISTy doesn't prove there is no situation where FIST can be effective. There's really no reason to globalize failures. Sort of gets back to the whole question of data & how we interpret it.

One data point can disprove a negative (i.e. I propose A doesn't exist. Someone finds one A and my proposition is disproved). But one data point can't disprove everything (i.e. I propose A can be done. Someone finds a situation where A is not done - the proposition is not disproved).

Fortunately, several other audience members chimed in and helped address this gentleman's concerns. I'm not sure he was convinced, but it was good to see that many other audience members understood what I was proposing.

The truth is, I kind of liked the way things worked out. Sure, it would have been better to have someone raise a substantive & thoughtful objection, but even the "this can't be done" comment triggered something in the audience that I, the speaker, couldn't do directly. It engaged them and got them to express their understanding of the concept. Can't really ask for anything more than that.

I think I owe that guy a thank you.

Weird Wednesday: QuickGym

OK, have you ever seen an ad for the QuickGym ROM Machine (ROM = Range Of Motion)? The thing costs $14,615 and offers to get you into shape by doing a 4-minute workout.

The sales pitch involves some mathematical calculations, criticisms of "exercise experts" who don't believe the QuickGym claims, references to a few studies supporting the claims, testimonials, and a 30-day rental offer.

I read through the studies (they were remarkably short), and didn't come away convinced. Apparently high intensity interval training can be a time effective approach... but when the benefits are described as "small but significant" I begin to think I can find better uses for almost $15K. Didn't Carl Sagan say something about extraordinary claims requiring extraordinary evidence? And I'd add that extraordinary costs should deliver extraordinary results.

Does the QuickGym actually work? I don't know - but I do know I'd want a lot more evidence before clunking down almost $15,000. I'm sure there's a project leadership lesson in there somewhere...

Misreading Data

The world is full of data - the trick is to understand what it means.

For example, some people point to the huge DC snowstorm as proof that global warming is a myth. Um, first of all, data isn't proof. It's evidence. And second, the storm might actually be evidence of a warming trend, because warmer air can hold more moisture and thus create larger storms. Or maybe the blizzard is just the result of an El Nino pattern and it might have nothing to do with climate change at all, man-made or otherwise. And please understand - this post is not about global warming. It's about understanding & interpreting data.

Me, I'm convinced data never speaks for itself. It must always be processed and interpreted. That's particularly true on projects where we collect metrics. And there are many kinds of metrics - predictive, descriptive, etc. Sometimes we simply collect the obvious & easy ones, which may or may not tell us anything about the project team's performance. Other times we misread good data. It can be done well - but it takes deliberate effort (and a grain of salt).

I don't have an easy answer - all I'm trying to say here is that we're fooling ourselves if we think the data is self-interpretive. We're taking a dangerous shortcut when we fail to reflect on the data and the many ways it can be shaped (or mis-shaped), interpreted (or mis-interpreted).

Better Than Nothing

In an admirable desire to pursue excellence, system designers and project leaders sometimes end up pursuing "perfection." And by "perfection" they don't mean a system that is available when it's needed and effective when it's used, much less a modestly-effective system that's simply "better than nothing." Instead, perfection is defined solely in technical terms rather than operational terms (or worse yet - technical terms disguised as operational).

Thus, we end up with the dilemma of the oversold consumer, whose computer / camera / kitchen device - when it finally makes it to market - has far more features than they ever needed & costs more than it needed to. The fact that people buy such devices is somewhat of an excuse, but not really.

Because sometimes, when you're buried under more than two feet of snow, when your shovel has been shattered after a week of constant use, and when the delivery trucks haven't been able to keep the hardware stores stocked with shovels, a piece of plywood screwed onto a 2x2 really is "better than nothing."

And at $4, it's a bargain.

Simplicity Friday

I'm having so much fun with Weird Wednesday, I thought I'd start a new string called Simplicity Friday.

I'm also aiming to provide you, dear readers, with concretely useful take-aways. So for the next several Fridays, I'll offer some tools you can use to simplify your systems, organizations and processes (if you're so inclined).

Let's start with TRIZ, aka the theory of inventive problem solving. The name is from a Russian acronym (Теория решения изобретательских задач (Teoriya Resheniya Izobretatelskikh Zadatch), and it was created by Genrich Altshuller.

Altshuller's main insight is to state technical problems in the form of a contradiction. For example, let's say you want your vehicle to go faster. A larger engine would make it go faster. But a larger engine would also be heavier, which makes it go slower. So the larger engine simultaneously increases and decreases the vehicle's speed - thus the contradiction.

Having established your contradiction, you can then consult a matrix of 40 TRIZ principles, which offers suggestions, principles and tools for resolving the contradiction. It's powerful (and simple) stuff!

One of the tools or practices that TRIZ identifies is "trimming," which I wrote about in my Simplicity Cycle book. It basically involves arbitrarily removing one part from the design, then seeing if you can make the system perform its function without that part. You'd be surprised how often that's possible.

OK, there's your simplicity tip for the day. Tune in next week for more!

Measuring Success

At the end of the day / week / year / project, how do you know you did good?

As I wrote previously, delivering useful capabilities is the only measure of success for Rogue Project Leaders.

So if you're primarily measuring progress by whether or not you've complied with the process, or whether you improved the process, or whether the metrics you report are in line with the metrics you were expected to report... I'd like to gently suggest that somewhere in your calculus you address the question of actually delivering the hardware / software / vehicle / system / product.

Even if your job description says your main task is to improve the process, there should still be a link to the actual product. Because frankly, your job is never to simply improve the process. Process is a means, not an end. The point is to make the output better / cheaper / available sooner / etc... so if your process improvements don't make the output better, you haven't really improved the process.

Let me say it again: process (and process improvement) is a means, not an end.

Weird Wednesday: Dupont Underground

In today's episode, we go under DC to a place called Dupont Circle Underground (aka Dupont Down Under).

In Washington DC, underneath Dupont Circle, there is some interesting unused space (approx 26,000 square feet of it). It was originally a trolley subway, but it was closed down in 1962. It briefly reopened in 1995 as a food court, and by "briefly" I mean the food court was open for 6 months.

Apparently there's a move afoot to put the space to use again, this time as an art space. It'll be interesting to see how that works out.

I just think it's fascinating that an unused underground facility exists in downtown DC, neglected but available for development. I hope someone figures out how to take advantage of it and turn it into something productive.

It makes me wonder how many other underutilized resources are out there, waiting for someone to apply creativity, imagination and vision (along with some dollars and elbow-grease). Just a thought...

People -vs- Angels

One of the problems with most approaches to optimizing organizational performance (aside from the horrible phrasing) is that they often rely on optimized people. That's insane.

The thing is, stuff is always (always always always) done by people. Not angels. Not machines. People.

People get tired. We get distracted. We misunderstand. We have a bad day. We have counterproductive motives. We are self-serving. We make mistakes.

People also get inspired. We learn. We adapt. We have a great day. We solve old problems in new ways. We are selfless. We make discoveries.

This isn't a contradiction or a paradox. It's just the reality of how people are. And any approach that fails to take these things into account is overlooking the most important aspect of work. It's always all about people.

I've written about this many times before, but I want to hit the topic again. Let me be very explicit here - the FIST approach does not rely on angels, who are perfectly pure in their motives and are perfectly tuned in their capabilities. In fact, FIST is built on an assumption that even the best, most talented people are going to drop the ball sometimes. It's also built on the explicit assumption that they'll pick up the ball and run with it in directions nobody anticipated. FIST asserts that people are both better and worse than we can imagine.

I love to point out that the FIST approach can fail - in fact, it can directly cause failures. So FIST is not about optimizing anything. It's about providing a set of guidelines to help shape decisions that are made by people. So my advice for rogue project leaders is to get the best people you can get. Give them the training, tools & resources they need (but not too much time or money). Stay out of their way as much as possible. Expect them to fail. Expect them to amaze. Everything else is nonsense.

The FIST Manifesto

As promised on Friday, here for your reading pleasure is the FIST Manifesto. Please feel free to pass it along to your friends and colleagues. Drop me a note if you want me to add your name to the list of signatories. I'd also be glad to send you the little cut-and-fold booklet version - drop me a line and I'll send it right over.

System development projects should be done by the smallest possible team of talented people, using a short schedule, a small budget and mature technologies to deliver innovative solutions to urgent needs. This approach is called FIST: Fast, Inexpensive, Simple, Tiny.

Short timelines increase agility and stabilize requirements, technology, budgets and people. Short timelines also force accountability, ownership and learning. To maintain short timelines, a project must also exercise restraint over budgets, complexity and size. Increases to the project’s budget, complexity or size inevitably reduce its speed.

Accordingly, the FIST approach advocates the following:
Minimize team size, maximize team talent.
Use schedules and budgets to constrain the design.
Insist on simplicity in organizations, processes and technologies.
Incentivize and reward under-runs.
Requirements must be achievable within short time horizons.
Designs must only include mature technologies.
Documents and meetings must be short. Have as many as necessary, as few as possible.
Delivering useful capabilities is the only measure of success.

FIST Principles
A project leader’s influence is inversely proportional to the project’s budget and schedule.
Creative constraints foster creativity. Adding time and/or money generally does not improve outcomes.
Fixed funding and floating requirements are better than fixed requirements and floating funding.
Complexity is a cost.
Complexity reduces reliability.
Simplicity scales. Complexity doesn’t.
An optimal failure costs a little and teaches a lot. When FIST projects fail, they fail optimally.
Iteration drives learning, discovery and efficiency. FIST is iterative.
Talent trumps process.
Teamwork trumps paperwork.
Leadership trumps management.
Trust trumps oversight.

Real Artists Ship

I had the opportunity to sit down with the inimitable Dr. Alex Laufer for lunch yesterday, and while there were many insights & take-aways from our discussion, one in particular sort of jumps out at me:

It's all about delivering the product.

That concept is one of the subtexts & supertexts (is that a word?) of this whole Rogue Project Leader / FIST idea. But perhaps it hasn't been as front-and-center as it should be. I am coming to think that I haven't made this as explicitly prominent in my words as it is in my head. I'm gonna fix that.

See, we do projects in order to deliver operational systems - not just to make a cool design, an interesting briefing or to exhibit process compliance. This is one of the reasons I hate the process-centric mentality. It takes the focus off the product. And the product is the whole point of the work. We get so wrapped up in improving the process, it's easy to forget we're supposed to be improving the outcome. And then we take comfort in compliance, rather than in what actually gets delivered.

Thus, in the FIST Manifesto (which I'll post here on Monday), there's a key line which states "Delivering useful capabilities is the only measure of success." In the booklet form of the Manifesto, that line has its very own page, in large font.

I'm going to try to make sure I say this more frequently on this blog, so before I wrap up for now, let me say it one more time: Delivering useful capabilities is the only measure of success.

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 Supercomputer

The Air Force Research Lab in Rome NY is currently hooking together over 2,000 PlayStation 3's in order to "create a supercomputer nearly 100,000 times faster than high-end computer processors sold today." They're calling it the 500 TeraFLOPS Heterogeneous Cluster

To accomplish this feat, researchers are using off-the-shelf components, including ordinary metal shelving to hold the PS3's (instead of the traditional computer racks, which are much more expensive but would be overkill). The system is running Linux, the free open source OS. And for the environmentalists out there, the cluster will consume about 300 kilowatts. Most supercomputers use 5 megawatts.

It'll operate at a cost of $2-3 per gigaFLOPS, and when it's all done, it'll handle 500 teraFLOPS.

I love it when project leaders brag about how inexpensive and simple their system is, along with explaining how its performance is cutting-edge.

Fordlandia

Welcome to another edition of Weird Wednesday!

Did you know that in 1928, Henry Ford built a utopian industrial town in the middle of the Amazon rainforest? It was called Fordlandia, and the idea was to have it supply Ford Motor Company with its own supply of rubber.

The town was built on strictly scientific, hygienic principles. Brazilian workers were given American style houses, American food (Hamburgers! They're good for you!), American ID badges and, despite the amazonian afternoon heat, American style work hours. Use of alcohol and tobacco were forbidden, even in workers' homes. The only music allowed was polka, square dancing and English-language sing-alongs. The rubber trees were planted following the best practices of rubber plantations in Asia... because Asia and South America are practically the same place, right? What could possibly go wrong?

Ford sold Fordlandia at a loss in 1945, after it had failed to provide any rubber whatsoever. I'm sure there's a lesson in there somewhere.

Day Off

I took the day off yesterday. It was fantastic.

Why did I take the day off?

Not because it's a holiday.

Not because it's a slow period at work.

Not because we had anything particular to do.

It was just because the kids had the day off (actually, they had a 4-day weekend). I decided I'd at least manage a 3-day weekend.

And during this whole 3-day weekend, I didn't blog, I didn't write (much), I just bopped around the house, did some little bits and pieces here and there, caught up on some reading, did some grocery shopping... and basically chilled.

I highly recommend doing this from time to time. It's good for the soul.

Optimism & Estimates

OK, let me start by admitting that I am a dedicated optimist. I've even been known to opine that optimists are the only true realists, but that's a topic for another day. What I want to talk about now is project estimates.

When a project busts its initial cost and schedule estimates, an almost universal conclusion is that the cost and schedule were "too optimistic." Now, I won't deny that blind optimism, in the absence of facts and data, can cause problems down the road. And I agree with the observation that most projects fail at the beginning (tho we don't always know it until later). But let's not be too quick to put the blame on the optimists. Over runs might actually have something to do with project execution, unexpected developments, or several other factors.

When someone says "I can do this project for X dollars and Y days/months/years," they're guessing. This guess is made at a point in the project where we know the least. So please, let's not all be surprised when the guess turns out to be wrong.

But let's also acknowledge that a mismatch between the initial guess and the final outcome doesn't mean the guess was too optimistic. Maybe the problem had something to do with a lack of restraint on the part of the requirements writers. Maybe it had something to do with avoidable changes introduced long after the project launch. Maybe the estimate was perfectly rational given certain conditions, but changes to the conditions rendered certain assumptions moot.

And finally, maybe the problem was a naive belief that a 10-year estimate could have any validity over a 10-year time period. Even a pessimistic estimate is bound to be wrong over such a long timeframe. Bottom line: if you want your estimates to be accurate, make sure you keep the timeline short.