Laws of Implementation: Tree for the Forest

A tidal wave – that’s what you’re hit with when you first try to introduce yourself to new software. Buttons above, buttons below, buttons everywhere you go. In the right hands, these buttons are the coordinated steps to high velocity tools for your business and your life. Here, they are an embarrassing wall in a very dim maze. You are drowning in the tidal wave of buttons.

In 2013, I was tasked with teaching myself and then training on 22ish different programs. With all of them I was presenting to a large group of individuals in various fields, from basic use to comparison matrices that would be utilized organization-wide. Through my own experiences, there were maybe a handful of the programs I had already gleaned some expertise on.  However the majority of tools were both my first install as well as my first exposure to that organization-of-the-week. Some of the technology I was implementing hadn’t even been released yet.

So how did I do it? I stopped. I took a breath…and I’d have another, keener look after the button shock would wear off.  I knew that if I was going to begin learning an alien-to-me program, I’d have to take apart the forest of tools for the tree of what I wanted. Yes, figuratively getting down to the root of it with a single button or process…BUT, by focusing on one tool or one task, I was Foundation Planning for how I would pursue my learning of the new software.  Here are some major points in Foundation Planning (in sequence):

• Ducks and Redundancies: What have you done in the past? What is something you can draw on for comparison? What walks, talks and sounds like the same job from another piece of software you may be acquainted with? This is the first act – getting curious and reminding yourself that the software has a point to its existence beyond trying to frustrate you.
• Use your “Rosetta Stone:” If you can isolate a tool or process – see how it is incorporated to other tools and/or processes. Let the isolated task influence how you interact with other parts of the software. It should tell you how the overall software operates. What hoops need to be jumped? What is ignorable to precursory process and what must be set?
• Read Backwards: Whenever I educate with books or guidance materials, one of the first tips I offer up is to go straight for the index (normally located at the end, hence “Reading Backwards”), and see where that specific, initial item is spoken of throughout the rest of the manual. This lifts the veil on what shape that will take as you progress with the program. It also may offer the solution you’re currently looking for in a chapter the author didn’t plan on.
• Wax On, Wax Off: Did you do something right once? Do it again, and mix it up. This is similar to “Use your Rosetta Stone” except now we’re getting into use over comprehension of the software. If you can feel comfortable in a process, you are beginning the process of self-discovery and will better command the software. When I was first learning Revit, I built a one hundred story, non-uniform skyscraper that only used four tools: Floor, Beam, Glass & Level. Today, I am a leading Revit user in the western market.

• Round Two: A good plan for a secondary round of goals is using the new software to solve previous challenges you had personally faced and solved. Keep it simple, but see how it compares and let it inform you of its strengths this way…and don’t be afraid to see how others had solved the same task too; strength in numbers. Also, see in there what draws your curiosity. Always go the direction you will find most motivating.