Have you ever noticed that many IT professionals seem to leap to a conclusion?jumping-frog

I once attended a training course on how to elicit business requirements using a facilitated discovery session to gather requirements.  By bringing all the stakeholders together to define the project, the shared information and decision-making process was to improve buy-in, reduce risk of scope creep, and increase the speed of delivery.

As the instructor briefed us on the method, she recommended that IT people not be included in the discovery sessions.  Having come up through the ranks of IT, I questioned the reasoning behind such a statement and asked the instructor at the first break.  She cited an example of a recent discovery session her company had facilitated to gather requirements for a large project at a client company.  In attendance at the discovery session were a number of stakeholders from throughout the company – including two IT developers who had been with the company for quite a while.  After the facilitator had laid out the ground rules for the discovery session, she began eliciting business requirements from the attendees.  As requirements were suggested, they were to be discussed and refined as necessary.  However, it happened that as soon as the first business requirement was mentioned, one of the developers said, “We can’t do that.” When the next requirement came up, the other developer remarked, “We’ve tried that before, and it doesn’t work.”  This back-and-forth went on for a while until the facilitator called time out for a short break.  During the break, she asked the developers either to leave the session or to remain silent.  When the session resumed, requirements were quickly gathered, discussed, revised, and prioritized.  When the finished requirements document was reviewed by the two developers the next day, their response was, “Oh, we can do this.  It will be easy!”

So… how did this project magically get from “we can’t do that” to “that will be easy”?  Very simply, all it took was getting the two IT developers to withhold judgment until they had all the requirements together.

IT professionals love to solve problems, and they are often quick thinkers.  As such, it is not at all unusual for an IT professional to solve problems in his head as he hears about them.  This in itself is not an issue.  The difficulty occurs when he states his conclusion before hearing all the requirements.  That’s exactly what the two IT developers had done in the discovery session described above.  They were in a hurry…there were a lot of other things they needed to do.  But by stating their conclusion prematurely, they were shutting off discussion and obviously failing to get a complete picture.  And in doing so, they were frustrating the stakeholders and very likely were becoming frustrated themselves.

Instead of jumping to a firm conclusion too quickly, it is much better to be an interactive listener.  Let others have their say.  Then instead of simply stating your judgment, ask questions to validate your thoughts.  Done properly, this may help in reaching a better conclusion, but it also has the added benefit of improving relationships by bringing everyone forward together.

What do you think?  Have you ever experienced this issue?  What other suggestions do you have to help resolve it?

6 Responses to “The Problem with Jumping to Conclusions”

  • HolmanRW says:

    Everyone needs a reminder to use this habit from Covey – “Listen to Understand, not to Respond”.

    • RW, I agree. Be swift to hear and slow to speak.

      • Brandon Bugher says:

        See this repeatedly, where IT guys go straight into solution mode. It really has a huge impact on the end result.

        • Brandon, good to hear from you! I agree —- this can have a huge effect on the end result. The solution will tend to be incomplete, or worse yet, it will be the wrong solution. And sadly, it doesn’t always seem to dawn on people as to what caused the issue.

  • Heath W. says:

    Great article which really hits home. Do you see one PM methodology helping more or less than another when attempting to properly seek solutions? I.e., Does requirements gathering with waterfall set you up for success regarding problem solving more so or less than Agile/Scrum? Might we be more prone to properly define the problem/opportunity via Story Writing? Thoughts?

    • Heath,

      I appreciate your comment. I honestly believe that this is a problem of attitude and behavior – not one of methodology. It doesn’t just occur in system development. It can happen in any relationship or encounter. We need to seek first to understand.

      That said, one of the advantages of agile (done correctly) is that the IT staff is not segregated from those who need the system. Instead, they are working together every day. Small, incremental results are shared, discussed, & critiqued throughout each day. That seems to provide more opportunity for listening and learning.

      What do you think?


Email Address*
Newsletter Powered By : XYZScripts.com