Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The FSOP Cycle (Flying by the Seat of Your Pants)

February 3rd, 2007 · 17 Comments

Here’s a cycle I’ve observed many times in my career. Frankly, I’ve gone round and round this thing many times as I try to apply successful patterns/approaches to broader problems than they were initially used.

FSOP Cycle

Incidentally, there are no arrows on this cycle because Apple’s KeyNotes software can’t draw curved arrows. Aargh. I’m going to have to break down and buy office on the mac, or learn more about OpenOffice. Sigh. At any rate, the cycle moves clockwise.

This cycle is really the application of Virginia Satir’s model for change to the problem of how processes evolve.

I made this up yesterday as I contemplated the usefulness of process in the context of software development. I’ve really lost faith in the idea of the repeatable development process, an idea that seems to be the holy grail of many IT professionals. Is it myth? I think so. I don’t believe process can do much, if anything, to guarantee a development project will be a success. That’s like saying anyone can invent flight by following a certain process, or discover the so-called Northwest Passage using another defined process. It doesn’t make sense. Process can help you keep track of financial expenditures, staff allocation, other peripheral (but important) aspects of a project, but it can’t guarantee success. And heavyweight processes often guarantee failure because they put an unmanageable burden on project participants.

I believe there is an irrational association between project success and process adherence on the part of many IT professionals and pundits. I don’t see a correlation, and I’ve been on lots of projects in the past ten years. In fact, the successful projects I’ve been on were usually not encumbered by stringent processes. Instead, they were comprised of smart, motivated people who were flying by the seat of their pants. I don’t mean they were just making it up as they went along. Quite the opposite. They always had a plan, and they revisited it constantly, sometimes everyday. They were focused on making progress, getting rid of obstacles, and adjusting plans to use resources as effectively as possible. They were planning every day – but not for long. Brief, daily planning coupled with focused activity toward an immediate goal is the only “process” I feel comfortable with today.


Even then, I want to bring up a point. I don’t necessarily believe this process will guarantee project success either – no process could have helped Lewis & Clark find a Northwest Passage, because there isn’t one. Some things are impossible, and process, even lightweight ones, won’t make it possible.

IT is one of the few places where process has such a religious ardor to it. Contrast the way many IT pros feel about process with the way scientists feel about the scientific method, for example. Do researchers believe the scientific method GUARANTEES they will be successful at finding a cure for cancer? Heck no. They believe the scientific method will help ensure that whatever they learn through research and experimentation is credible and authentic. But they can still fail, and usually do.

So, where does process really belong? I think it belongs on the sidelines. It should be tools we use to ensure certain aspects of project management are done properly (like tracking finances, billing customers, and selecting vendors). It doesn’t belong in the driver’s seat. It shouldn’t show up in a project plan template as defined phases or activities. It won’t help you get wherever you are going. Put a smart PERSON in the driver’s seat, and let them find the way from where you are to where you want to be. It’s the only way to get there, because process will never get you there on its own.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

17 responses so far ↓

  • 1 Garrett // Feb 5, 2007 at 8:09 pm

    That’s your best post yet.

  • 2 dave // Feb 5, 2007 at 9:50 pm

    Thanks Garrett!

  • 3 Ben Simo // Feb 6, 2007 at 1:02 am

    Wonderful! Thank you for making this cycle visual!

    No process should be completely repeatable. Even CMM has “Optimizing” as the highest level. The problem is that we seem to get stuck at “Repeatable” and forget that the goal was continuous improvement.

    You got it right. Trouble comes when smart people stop using process as a map and let the process drive.

  • 4 dave // Feb 6, 2007 at 6:50 am

    Thanks Ben. You make a great point about where the trouble comes from. I remember the day when I first looked at the process landscape around me and realized for the first time the processes we were struggling with had not been imposed on us from the outside, but that we had done it to ourselves.

  • 5 Drew Kime // Feb 7, 2007 at 11:15 am

    One change I’d make is in the circle labeled “Process Becomes Painful”. Really what’s happening is that the project runs into some problem that isn’t addressed by the current process.

    Every process you can name was originally designed to solve a specific problem. On very large projects, there’s the potential to encounter lots of problems, so certain processes can prevent those problems from appearing. But attempting to prevent every conceivable problem actually *causes* the problem of too much time spent on the process instead of the project.

    That’s where Agile comes in. It solves the problem of too much process. Do you currently suffer from too much process? Than you could incorporate some ideas from Agile. But make a distinction between using ideas to deal with specific problems, and adopting a whole big-M “Methodology”.

    There’s a line in the movie “Dogma” that I think describes this really well: “You can change an idea. Changing a belief is trickier. Life should malleable and progressive; working from idea to idea permits that. Beliefs anchor you to certain points and limit growth; new ideas can’t generate. Life becomes stagnant.”

  • 6 dave // Feb 7, 2007 at 5:50 pm

    Thanks Drew. You make a great point that processes become inadequate due to misapplication – I am going to incorporate it into my picture. One other way process gets in the way is when really, really creative people are involved. Sometimes they just get bored with doing things the same way over and over, and then become disengaged.

    I’m glad you mentioned Agile – I am finding ideas in Lean Software Development very helpful.

  • 7 My IT News Blog » Blog Archive » Posted on TechDarkSide.com - The FSOP Cycle (Flying by the Seat of Your Pants) // Feb 9, 2007 at 4:18 pm

    […] Here’s a cycle I’ve observed many times in my career. Frankly, I’ve gone round and round this thing many times as I try to apply successful patterns/approaches to broader problems than they were initially used. Incidentally, there are no arrows on this cycle because Apple’s KeyNotes software can’t draw curved arrows. Aargh. I’m going to have […] Read more… […]

  • 8 Mike // Apr 2, 2007 at 6:44 pm

    Developers working on a commercial software product are often able to reach a consensus about which process to implement and are quite successful. The advantage here is a repetitive cycle of adding feature to an existing product where most of the variables are known.

    New product development can also benefit from a formalized process, especially when the team members have worked together for some period of time and have had a chance to exercise their product development methodology of choice.

    Consulting bring a whole different set of challenges as more often than not, people are coming together who have not worked together before and may come from different schools of thought. The greater the number of people involved the more import a formalized development process becomes.

    While I agree that strict adherence to a process does not guarantee success, it does provide the foundation for the team, so everyone knows what to expect. I also agree that the process should not become a religious debate but that everyone on the team should have a say in defining the process. When everyone reaches a consensus on the chosen methodology, adherence to the process will not be an issue.

    As far as Lewis and Clark goes, that was a military operation with strict rules and discipline. Those who chose to leave the group, where never heard from again.

  • 9 dave // Apr 2, 2007 at 8:07 pm

    Process certainly can be a foundation for a team, but it doesn’t have to be. There are plenty of alternative foundations, like a common goal such as building software that works, that can serve equally well as a foundation. Some people mistake process for planning – I believe in planning. I also agree that successful groups tend to develop successful patterns. That’s one of the things the FSOP cycle illustrates. What I don’t believe is that the bottom half of the FSOP cycle adds much value, as a general rule.

  • 10 Jonathan Kohl // Dec 9, 2008 at 12:05 pm

    Well put.

    Codifying an instance of that into a process often ends up as a meme – the parts that are easy to replicate and communicate are only part of what really went on. Memes are easier to sell though, particularly if they either appeal to the fears of management, or the egos of the techies. :-)

  • 11 Simon Godfrey // Dec 9, 2008 at 3:53 pm

    Nice post Dave.

    It worries me that sometimes, when working on projects, the smart people flying by the seat of their pants happens at the expense of a process which enables a whole project team to work effectively.

    It reminds me of recently talk about process v procedure; one should enable smart people to work freely, and creatively, the other results in smart people feeling restricted, and feeling the pain.

  • 12 Pete Dignan // Dec 10, 2008 at 9:50 am

    A couple thoughts.

    First, there’s a tacit assumption behind this whole line of thinking – that we know what we mean by “smart people.” Maybe we can agree it’s everyone who is clever enough to read this blog. :-)

    Second, why to the Smart People need to Reject the Process? Couldn’t they tweak the process to address what they know now that they didn’t know then? Which might include simply taking some stuff out (e.g. vestigial structures) of a process that has become too heavyweight?

  • 13 David Christiansen // Dec 10, 2008 at 10:01 am

    I think it’s important to remember that the FSOP cycle is an OBSERVATION, not a prescription. I’m not proposing it as a process that should be following, I’m proposing it as a model for how people normally behave. It may not be the “right” way per world views such as Pete’s, but it’s still the normal way, at least as I’ve observed it.

  • 14 Peter Burkholder // Aug 6, 2009 at 4:18 pm

    My $WORK is launching a very poorly-implemented ITIL process, and I found this post relevant to how we’ll likely reject the process (not because it’s ITIL, but because it’s HPServiceCenter) and start flying by the seat of our parts again.

    Not surprisingly, your site is blocked by our corporate content filters, flagged as ‘malicious’ in nature.

    Go figure.

    -Peter

  • 15 Get to the point | Drew Kime // Mar 1, 2010 at 4:21 pm

    […] Christiansen over at Information Technology Dark Side has a good graphic representing what he calls the FSOP Cycle (Flying by the Seat of Your Pants). […]

  • 16 Velocity 2010 – Change Management « the agile admin // Jun 23, 2010 at 6:24 pm

    […] Christensen’s FSOP (flying by the seat of your pants) cycle describes the problem – we don’t even know what best practices are yet.  Find some, […]

  • 17 Doing Ops big time « Not Dead Head // Oct 16, 2010 at 2:48 am

    […] http://www.techdarkside.com/the-fsop-cycle-flying-by-the-seat-of-your-pants […]

Leave a Comment