Systems: a prescription

March 23, 2011

NOTE: You may only read this if you are trying to understand a current system, design a new system, or implement a system change, or have done so in the past. Because only you will believe this:

Systems thinking is an art, not a science.

But just as Wolfgang Mozart had to start by learning to squeak out a song on his father’s violin, you must learn a few basics.

1) Start with the scope

Success is defined by the beholder [1], not by you. It is critical, then, to identify what constitutes measurable success, and get the stakeholders to agree to it–especially the ones that hold the pursestrings.  The first part of this is identifying the system boundaries.–a surprisingly hard task. Think about what you have the ability to influence or change–those you do not probably belong outside of your system.

2) Model the system

If you can’t explain the system in 5 minutes, either you don’t understand it, or it doesn’t work [2]. Modeling the system, whether using software tools like Microsoft Visio or just a whiteboard and markers, helps you understand the system. Many frameworks are available, each with their list of pros and cons. For sophisticated analysis, use UML or one of its variants; for simple analysis, use a standard workflow. This can seem daunting, but it really isn’t. You’ve already identified what isn’t in the system, so all that’s left is to classify what is in the system. In many business systems, it helps to think about money, as it is a data flow that everybody understands. Where does money come into the system? Where does money leave the system? How are the inflows and outflows triggered?

Often this step is blown out of proportion compared to its usefulness. The main purpose of a model is to provide a layer of abstraction so that you and others have a better understanding of the system. It should not be an end result, but rather a step in a process. Beware of overly complex models–and remember that the complexity of the model should always be less then the complexity of the system. (This is where some of the readers are saying “Duh!” and slapping their foreheads)

3) Simplify the system

The easiest way to get good results is by making things more elegant. Pick areas in your model that look complex or daunting. Make them less so through brainstorming, through conversation, through interviews, or through insight. Beware of second system syndrome, where a successful system designer or leader ends up bloating his second with all the features and do-dads he always wished he had had time to put in the first.

Also trust your gut–if it doesn’t look right, try again.

4) Implement the system

Implementing the system is the best way to get it right. Despite all your best efforts, you will likely screw something up–a button won’t work, a scripted answer will sound corny, a critical component will be installed upside down. The quickest way to find this out is to get it in front of as many eyes as possible as soon as possible. Don’t overdo it by pushing out large failure after large failure,  but neither should you plan for so long that your system is obsolete by the time you’re ready to ship it.

5) Remodel the system

This may sound like unnecessary work, and it is–if you’re perfect. But you aren’t, so do it–now that you’ve spent the time to introduce the system to the critical world around you, map it out again. This time use even less detail–remember, modeling is a tool to help you with your understanding of the system.

6) Tweak and repeat step 4 and 5

Certain situations require more planning than others, but for most a “Ready, Fire, Aim fire aim fireaimfireaim…”  mentality will get you further, faster, and with better quality than spending too much time planning. Unless you are designing a nuclear bomb, or handling the medical records of 300 million people, test your system as publicly as politically possible. You may not be able to rescue your honor, but you will be able to get a better system.

Final note: That which is measured, improves. Be careful what you measure in any system. If you measure how many leads a salesman is gathering, he will gather thousands of garbage leads. If you are measuring how fast a project is finished, you’ll have a non-working project tomorrow.

Notes:

[1] Rechtin, E Systems Architecting: Creating & Building Complex Systems, 1991
[2] Darcy McGinn, 1992 from David Jones

2 Responses to “Systems: a prescription”

  1. Alan Says:

    Certain situations require more planning than others, but for most a “Ready, Fire, Aim fire aim fireaimfireaim…” mentality will get you further, faster, and with better quality than spending too much time planning. Unless you are designing a nuclear bomb, or handling the medical records of 300 million people, test your system as publicly as politically possible. You may not be able to rescue your honor, but you will be able to get a better system.

    Curious about the first firing before aiming. Was that deliberate? What would be the purpose of releasing/installing a system before modeling or designing it fully?

    If I understand the aimfireaimfire correctly, you continually tweak the system in order to fix the bugs and make it work. What happens if the system needs to be “perfect” the first time?

    I am also curious about how to “publicly” test your system, and air the inevitable failures, without alienating your customers. I agree that it can and should happen, but I was wondering what some tips are to ensure that your clients are impressed with your honesty, rather than frustrated with your failures.
    Thanks!


  2. Every system is on a continuum, from critical to not-so-much. A pacemaker, for example, must work the first time, as must an automatic mixing system in a hospital’s pharmacy. In these types of situations, the entire flow must work the first time, in which case a careful, precise “aim” is required before firing.

    Also, parts of every system are critical. In a companies IT department, it is typically unappreciated when the Internet goes down–which might be a consequence of haphazardly moving to managed switches.

    But for the most part, the consequences of a misfire are greatly exaggerated, and in my experience, it comes down to human psychology. People don’t like to look the fool. They want it to go right the first time. And this is particularly true of somebody who released a change into the wild woolly world and got burned.

    But you bring up a good point–a client (internal OR external) has to understand why you’re doing what you’re doing. I have a few guidelines for this:

    1) Identify the critical pieces during the “Ready” stage. Remember that criticality is defined by the users, not by you–which makes it tough.

    2) Clearly state that you fully intend to make immediate changes upon noticing errors.

    3) Engage the users–get them to feel like part of the team.

    4) Plan to work a long day on the day of first release.

    5) Grow thick skin.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: