Sponsored By

The "Art of the Possible" TrapThe "Art of the Possible" Trap

The "art of the possible" approach can succeed when key team members are quickly able to connect technical possibilities with results that could improve business outcomes.

Kevin Kieller

October 23, 2014

19 Min Read
No Jitter logo in a gray background | No Jitter

The "art of the possible" approach can succeed when key team members are quickly able to connect technical possibilities with results that could improve business outcomes.

Good intentions and hard work alone do not yield valuable technology solutions that provide measurable business benefits. One approach that is well intentioned but nonetheless can lead to activity devoid of results is to focus on the "art of the possible."

For most IT groups, exploring the "art of the possible" is akin to brainstorming. It is embarking on unbounded investigation, ideation based mostly on marketing brochures, demos and often unstructured vendor trials or pilots.

The art of the possible is often explored by IT personnel in absence of any documented or prioritized business requirements. Sometimes phrases such as "the business doesn't know what they don't know" are used to justify this approach. IT people like to play with technology. The art of the possible approach allows them to do just that. IT people are not always versed in soliciting and documenting measurable business objectives; the art of the possible approach delays making this weakness visible. (See "A Proxy for End Users" to better understand the fallacy of thinking your business users can't be trusted to provide input on business requirements.)

In direct contrast, when Otto von Bismarck (who is credited as coining the phrase) said, "Politics is the art of the possible, the attainable -- the art of the next best," he was in fact speaking about the practical. Bismarck was arguing that you must focus on measurable outcomes based on boundaries and limitations.

Documenting Business Requirements is Always a Better First Step
Stephen Covey said it like this, "Begin with the end in mind." He was suggesting that before you start a journey you should know where you want to end up. This is the opposite of traveling using the "the art of the possible" approach, which would have you randomly sample different modes of travel: hop on a bus, drive a car, roller skate, try a plane, swim, crawl. Sampling travel solutions is activity. It might be fun, but you aren't getting anywhere specific; you are not generating any meaningful results.

Documenting and prioritizing business requirements in no way limits creativity or your ability to explore different possible solutions as a second step. Having documented business requirements means you know where you want to go and you will realize when you get to your destination. Having documented business requirements avoids wasting time exploring invalid solutions; swimming is not a realistic transportation solution to get from New York to Los Angeles.

The ability to "prune" possibilities is important. Reducing solution possibilities allows you and your team to focus efforts on viable solutions for your organization. There are more possibilities than practical solutions. The objective should not be to identify the most possible solutions; but rather, to identify the best solution for your specific situation. Only in the context of defined business requirements (success criteria) can the relative merits of various solutions be evaluated. Ratings without requirements is just marketing; it is "fluff," unsubstantiated beliefs and indefensible opinions.

When the Art of the Possible Can Succeed
A while back, two VPs at a large insurance company engaged me to develop and present an "art of the possible" presentation for their teams related to unified communications. This was done as a first step of their UC journey and was valuable. The art of the possible approach can succeed in certain limited circumstances:

  • With executive leadership – Executives in most organizations are "tuned into" the key metrics that improve overall business performance.

  • As a first step in a multi-step process – Knowing we are next going to define, prioritize and document business requirements helps us "keep our eyes on the prize."

  • Where some options are "pruned" based on priorities – Success is more likely if we don't need to explore limitless possibilities.

  • When we have clear documented understanding of what success looks like – The team understands that eventually they will need to create a business case where value exceeds investment.

The "art of the possible" approach can succeed when key team members are quickly able to connect technical possibilities with results that could improve business outcomes. This almost always requires very senior leadership be part of the process.

When the Art of the Possible is Likely to Fail
Sadly, more often than not, an "art of the possible" project is instead a "look busy" activity that fails to provide value in a number of scenarios:

  1. When led by lower-level technical resources – Often these people equate activity with value and can't fully connect technical solutions to key business drivers.

  2. With no defined boundaries – Without business focus areas, timelines or budget parameters, the entire exercise can become a never-ending, "geeky" hobby.

  3. If asking questions is discouraged – If asking "why?", "so what?", "how might this help the business?" or "what are the alternatives?" is frowned upon, then you are likely to fail. Unless you are part of the R&D department at a Fortune 100 company, thinking about how something that is technically possible could help the business should be done every hour on the hour.

  4. When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

  5. No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time.

If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

Art resides in the quality of doing, process is not magic.

-- Charles Eames

The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

Follow Kevin Kieller on Twitter and Google+!
@kkieller
Kevin Kieller on Google+

  • As a first step in a multi-step process – Knowing we are next going to define, prioritize and document business requirements helps us "keep our eyes on the prize."

  • Where some options are "pruned" based on priorities – Success is more likely if we don't need to explore limitless possibilities.

  • When we have clear documented understanding of what success looks like – The team understands that eventually they will need to create a business case where value exceeds investment. The "art of the possible" approach can succeed when key team members are quickly able to connect technical possibilities with results that could improve business outcomes. This almost always requires very senior leadership be part of the process.

    When the Art of the Possible is Likely to Fail
    Sadly, more often than not, an "art of the possible" project is instead a "look busy" activity that fails to provide value in a number of scenarios:

    1. When led by lower-level technical resources – Often these people equate activity with value and can't fully connect technical solutions to key business drivers.

    2. With no defined boundaries – Without business focus areas, timelines or budget parameters, the entire exercise can become a never-ending, "geeky" hobby.

    3. If asking questions is discouraged – If asking "why?", "so what?", "how might this help the business?" or "what are the alternatives?" is frowned upon, then you are likely to fail. Unless you are part of the R&D department at a Fortune 100 company, thinking about how something that is technically possible could help the business should be done every hour on the hour.

    4. When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

    5. No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time.

    If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

  • Where some options are "pruned" based on priorities – Success is more likely if we don't need to explore limitless possibilities.

  • When we have clear documented understanding of what success looks like – The team understands that eventually they will need to create a business case where value exceeds investment. The "art of the possible" approach can succeed when key team members are quickly able to connect technical possibilities with results that could improve business outcomes. This almost always requires very senior leadership be part of the process.

    When the Art of the Possible is Likely to Fail
    Sadly, more often than not, an "art of the possible" project is instead a "look busy" activity that fails to provide value in a number of scenarios:

    1. When led by lower-level technical resources – Often these people equate activity with value and can't fully connect technical solutions to key business drivers.

    2. With no defined boundaries – Without business focus areas, timelines or budget parameters, the entire exercise can become a never-ending, "geeky" hobby.

    3. If asking questions is discouraged – If asking "why?", "so what?", "how might this help the business?" or "what are the alternatives?" is frowned upon, then you are likely to fail. Unless you are part of the R&D department at a Fortune 100 company, thinking about how something that is technically possible could help the business should be done every hour on the hour.

    4. When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

    5. No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time.

    If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

  • When we have clear documented understanding of what success looks like – The team understands that eventually they will need to create a business case where value exceeds investment. The "art of the possible" approach can succeed when key team members are quickly able to connect technical possibilities with results that could improve business outcomes. This almost always requires very senior leadership be part of the process.

    When the Art of the Possible is Likely to Fail
    Sadly, more often than not, an "art of the possible" project is instead a "look busy" activity that fails to provide value in a number of scenarios:

    1. When led by lower-level technical resources – Often these people equate activity with value and can't fully connect technical solutions to key business drivers.

    2. With no defined boundaries – Without business focus areas, timelines or budget parameters, the entire exercise can become a never-ending, "geeky" hobby.

    3. If asking questions is discouraged – If asking "why?", "so what?", "how might this help the business?" or "what are the alternatives?" is frowned upon, then you are likely to fail. Unless you are part of the R&D department at a Fortune 100 company, thinking about how something that is technically possible could help the business should be done every hour on the hour.

    4. When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

    5. No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time.

    If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

  • With no defined boundaries – Without business focus areas, timelines or budget parameters, the entire exercise can become a never-ending, "geeky" hobby.

  • If asking questions is discouraged – If asking "why?", "so what?", "how might this help the business?" or "what are the alternatives?" is frowned upon, then you are likely to fail. Unless you are part of the R&D department at a Fortune 100 company, thinking about how something that is technically possible could help the business should be done every hour on the hour.

  • When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

  • No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time. If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

  • If asking questions is discouraged – If asking "why?", "so what?", "how might this help the business?" or "what are the alternatives?" is frowned upon, then you are likely to fail. Unless you are part of the R&D department at a Fortune 100 company, thinking about how something that is technically possible could help the business should be done every hour on the hour.

  • When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

  • No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time. If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

  • When there is an unwillingness to discuss dollars – If the total cost to implement a solution exceeds the total value the solution provides then it is not worthwhile. If during your "art of the possible" exploration the team is unwilling to discuss "order of magnitude" costs and benefits (i.e. is it hundreds, thousands, millions of dollars?) you will likely not produce anything of value to the business.

  • No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time. If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

  • No consideration given to supportability – Almost all technical solutions are not one-time science experiments. This means a viable solution needs to be able to operate reliably over a period of time and be supportable. In the unified communications realm, CUCI-Lync (the convoluted mashup between Cisco CUCM and Microsoft Lync) is a good example of something that while technically possible is rarely reliable or supportable over any period of time. If you have no documented, prioritized, measurable business requirements but plan to first undertake an "art of the possible" investigation, simply STOP.

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

    Art resides in the quality of doing, process is not magic.

    -- Charles Eames

    -- Charles Eames

    The most common attribute of successful technology projects is having clear, documented, measurable success criteria. This is the process that most often yields a quality result.

    I hope it is "possible" for you to share your thoughts by commenting below or connecting with me via twitter @kkieller.

    Follow Kevin Kieller on Twitter and Google+!
    @kkieller
    Kevin Kieller on Google+

About the Author

Kevin Kieller

Kevin Kieller is a globally recognized Unified Communications, Collaboration and technology analyst, strategist, and implementation leader. He is part analyst and part consultant, which ensures he understands both the "big picture" and the real-world realities.

Kevin and the team he created helps organizations select and successfully implement leading collaboration, communication and cloud technologies, focusing on delivering positive business outcomes. He helps vendors generate awareness and demand, position their products, often leveraging his unique understanding of the Microsoft ecosystem.

Kevin leads the elite BC Strategies Expert group and is part of the No Jitter technical analyst team where he covers Microsoft Teams, Copilot, UC, Collaboration, and AI for productivity. He presents regularly at Enterprise Connect and keynotes many other events focused on technology effectiveness.

He has led the development of many technology strategies for medium and large organizations, served as Bell Canada's lead UC strategist, developed new practice offerings for Softchoice, and advised hardware and software companies interested in expanding within, or competing against, the Microsoft ecosystem.

Kevin is comfortable interfacing at both the most senior (CxO) levels and getting "his hands dirty" helping technical teams.

Kevin has conceived, designed and overseen the development of software products and cloud-based services in the business, educational and recreational areas which have been used by millions of people in over 17 countries worldwide. A long time ago he created an award-winning game for the Commodore 64 and ever since has been committed to delivering business value through technology.