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.


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

%d bloggers like this: