I’m feeling especially blessed as I return to the office after a week in Fairfax, Virginia at the 2015 World Police and Fire Games. A dear friend of mine is a National Park Ranger and came to the Games to compete in the triathlon. I came to the Games to spectate, cheer on my friend, and generally bask in the glow of these men and women who dedicate their lives to the service and safety of our communities.
At the Games there were 60 sports at 53 venues, hosting 12,000 athletes. That sounds like a pretty impressive system! And it truly was.
Every event and venue we visited during the week was well staffed, well organized, and provided a safe environment for the athletes and spectators. As the week wound down and I started to mentally prepare for my return to the office and my upcoming blog post, my mind turned to reflections upon the systems aspect of the event.
I’m relatively new to the discipline of systems thinking. When I came to Vitech and was introduced to it, Jim Long (our late CEO), taught me that there are systems all around us. If you look, you can see the system in anything. Because of that, I often observe the systems around me and discuss them with our team, in order to expand my personal practice of systems thinking.
Upon first reflection of the system at the Games I thought, surely, there must be a hierarchy of requirements. After all, isn’t safety the absolute first concern here? If that’s the case, how do I reconcile all of the other things that “need” to happen in order for the event(s) to be successful?
We’ve all heard talk of “requirements” and “desirements,” but in a true system, only requirements exist. So, how do I reconcile the desirements?
It took me a day to come around to it, but I soon realized that I was going about this the wrong way. I was already mentally writing requirements for the system. The veteran systems thinkers out there probably saw me making this mistake the moment they read the title of my blog post. I walked right into this classic mistake.
I feel blessed to have worked with some world-class systems engineers. Joe Maley, one of our recently retired SE’s, taught me to step back from the solution, then step back from thoughts of requirements, and focus instead on defining the problem. Only once I’ve carefully studied the problem, defined and refined the problem statement, and ensured I fully understand it can I take the next steps.
So, as I was in wonder of the Games, instead of mentally writing requirements, I should have been thinking about the problem. What is the mission? What are the measures of success? Any special considerations?
