25 Sep 2008

How To Eat The Elephant: Insight Into How A Complex Problem Can Be Simple.

“How do you eat an elephant,” the joke goes. “Well don’t start in the rear, that’s for sure.”

25 Sep 2008

“How do you eat an elephant?” the joke goes. Well don’t start in the rear, that’s for sure!

All of us have had to deal with what seemed a complex business problem, and have most likely learned more valuable lessons from falling down than from succeeding.

Some time back, I recall struggling with how to break down what seemed to be an extremely complex business process for our sales and contracts teams in order to overlay their process in my company’s EDM and workflow solution. Luckily, the team leaders within the departments had fairly well fine-tuned their process, given leasing company regulations, but it was the different entry points a “sales packet” could enter that was really throwing me for a loop.

A sale could be a ‘dollar out’ or ‘fair market value’ lease, cash purchase or even a rental. The deal may or may not have any number of documents with it, and depending upon the deal, it could vary widely. I was sitting at my desk, attempting to visualize the workflow by scribbling on a notepad, when a colleague walked in. He inquired what I was doing, and I went on to inform him I was trying to figure out how to eat an elephant. He quipped off a pithy remark, “Don’t start in the rear, that’s for sure!”

After seeing me laugh, he sat down and listened a little while to my evident frustration with the process. He sat there in silence for a little bit, and then asked, “Why don’t you treat each entry point into the process as it’s own process? He went on to suggest simply overlaying all of the processes on top of one another to compare and contrast them.

I think chagrin is the correct work to describe what I felt. It was such a simple answer, why didn’t I think of that? For whatever reasons, I couldn’t see the trees because of the forest (yes, reversed). In other words, I got where we were going, but I couldn’t see my way clear of the obstacles. He cleared a path with that simple comment.

When dealing with an elephant you must eat, here are a few helpful hints:

  1. Know your objectives: Once you have a clear understanding of what is to be delivered you can begin to operationalize the details.
  2. Take it apart to fix it: While this seems opposite of common sense, sometimes it’s easier to deconstruct a problem than it is to unravel it piece by piece (think rope or electronic chords).
  3. Don’t get too serious: Remember that misery loves company, and don’t forget to laugh to relieve tension.
  4. Remember the list: While I’m not a list-kind-of-person, I’ve learned that an actionable items list helps you stay focused. It doesn’t have to be high-tech to work, a notepad will do just fine.
  5. Don’t place yourself at the wrong end of the problem: While it is easy to find yourself at the wrong end of a problem, don’t let yourself get caught, because that elephant might just sit on you!


Ken Stewart’s website, ChangeForge, focuses on the collision between the constantly changing worlds of business and technology in an information-centric world. As a senior consultant with the Photizo Group, he comes from and works directly with channel providers in the managed services space, developing educational tools and resources to promote lasting business transformation.

Get the latest industry news, and follow ChangeForge on Twitter or become a fan on Facebook. You might also be interested in reading more from Ken in his weekly column on MPS Insights every Tuesday.


Leave a comment
More Posts
Comments
  • I think the 2nd rule “Maintain an actionable list of to-do’s.” says it all. Just one action list, immediately accessible, and easily updatable.

  • I think the 2nd rule “Maintain an actionable list of to-do’s.” says it all. Just one action list, immediately accessible, and easily updatable.

    • PM Hut, I completely agree. That one rule has made the biggest difference in my life. While you always keep your eye on the horizon, you are effective only when you can execute and avoid walls that prevent you from achieving your goals.

  • PM Hut, I completely agree. That one rule has made the biggest difference in my life. While you always keep your eye on the horizon, you are effective only when you can execute and avoid walls that prevent you from achieving your goals.

  • Actionable list = a list that you actually can complete.
    So many times we make that 'list' and it never gets done due to the overwhelming size of to do's.
    I like the K.I.S.S. method.
    Keep
    It
    Simple
    Stupid.

    :)
    Great post.

  • Actionable list = a list that you actually can complete.
    So many times we make that ‘list’ and it never gets done due to the overwhelming size of to do’s.
    I like the K.I.S.S. method.
    Keep
    It
    Simple
    Stupid.

    :)
    Great post.

  • kallan

    Kia ora Ken!

    I guess it all depends on how your brain works. Now there's a project if ever there was one :-)
    Yes, lists aren't everyone's cup of tea. I'm not a 'list' person either, but in studying Science as a discipline I had to get my head round the 'list culture'. Then, having to teach it, I became quite sold on the idea.

    Your observation is correct. Lists are useful for comparing, if only to compare their lengths! They also permit one to spot patterns and duplicates, particularly duplicates in patterns or process.

    I think this is where many projects can get very complex. Not that they are necessarily as complex as they seem. When loops and duplicate loops and patterns become part of the process or structure of a project, redundancy makes things overly complex.

    Studying complexity systems has taught me that they're recursively elaborate. This is one of the features that make a complexity system complex, compared to a complicated system that is just plain complicated.

    Most projects are complicated. If they get complex, it's a sure sign that there's some redundancy somewhere that's perhaps not needed. Lists used in comparison can help identify the redundancies and unnecessary loops.

    Ka kite
    from Middle-earth

  • Wow, I think all of that talk on complex and complexity have thoroughly perplexed me 😉

  • kallan

    Kia ora Ken!

    I guess it all depends on how your brain works. Now there’s a project if ever there was one :-)
    Yes, lists aren’t everyone’s cup of tea. I’m not a ‘list’ person either, but in studying Science as a discipline I had to get my head round the ‘list culture’. Then, having to teach it, I became quite sold on the idea.

    Your observation is correct. Lists are useful for comparing, if only to compare their lengths! They also permit one to spot patterns and duplicates, particularly duplicates in patterns or process.

    I think this is where many projects can get very complex. Not that they are necessarily as complex as they seem. When loops and duplicate loops and patterns become part of the process or structure of a project, redundancy makes things overly complex.

    Studying complexity systems has taught me that they’re recursively elaborate. This is one of the features that make a complexity system complex, compared to a complicated system that is just plain complicated.

    Most projects are complicated. If they get complex, it’s a sure sign that there’s some redundancy somewhere that’s perhaps not needed. Lists used in comparison can help identify the redundancies and unnecessary loops.

    Ka kite
    from Middle-earth

    • Wow, I think all of that talk on complex and complexity have thoroughly perplexed me 😉

      • kallan

        Oops! Sorry Ken.

        Here’s some input.

        Catchya later

  • kallan

    Oops! Sorry Ken.

    Here's some input.

    Catchya later

  • kallan

    Oops! Sorry Ken.

    Here's some input.

    Catchya later

Comment