Sitting in a war room for a project already 8X over budget and a year late, they’re massaging a RAG report.  “The Boss doesn’t want our analysis, he just wants the numbers”, was the mantra. And so they presented raw numbers, which going in the wrong direction, begat even more numbers, perhaps because as Alfred Hitchcock said, “there is no terror in the bang, only in the anticipation of it.” It was time to ask hard questions, but no one wanted to.

Asking tough questions is not easy in most of the meetings I’ve attended over the years. Definition of a hard question – everyone else in the room immediately decides to check their smartphones. Between the game playing, desire not to know (for future deniability), or fear of not being a ‘team player’, most meetings are kabuki theater.

Business Analysts are adept at capturing features/functions, but they don’t challenge core hypotheses and so the resulting Business Requirements, technical project sizing and resulting planning is sort of best-case. Agile Scrum Masters are supposed to lead the capture of User Stories, but more often than not end up with a number of identified ‘expected’ situations, again, without much creativity or personal risk.

How can we do better?

Fortunately, there is a structured, politically neutral method to obtain all possible needs and outcomes. Socratic Questioning has survived for over 2500 years because it works by providing a structured deep dive into core practices and underlying assumptions, issues and scenarios.  It beats swarming newbie MBA’s into a situation, filling out data points for later analysis, as the data points themselves may be missing or deficient. Not relying on pure data analysis also requires creativity, experience and personal risk taking, none of which are well documented traits of most current MBA programs.

Disruptive projects require two levels of questioning; we covered one line of questioning, project deliverables focused, in our previous posts.  The second line is less explored and more powerful in determining potential for success – the search for, and critical testing, of all hypotheses around the possible outcomes or issues surrounding executing the initiative. Since the low hanging fruit of innovation was picked a long time ago, and even if the project team has identified all possible Use Cases/Use Stories, integrating multiple services, data feeds, and customer facing back-end systems into an end to end functioning experience is not easy. Besides message formats, data definition inconsistencies, customer experience to customer expectation alignment, and update timing (some companies are end of day and other real-time oriented) are serious complications.  Factor in external providers and services and today’s systems are more about Service Integration than Systems Integration – a whole new level of difficulty needing thorough ‘what-if’ coverage.

Who runs the questioning process? Internal or external, the facilitator is a combination of Socrates and cross-examiner, where each hypothesis is subjected to deep-dive questioning. Culture matters here – if belittling or marginalizing dissenters or questioners are the norm, or if only the senior team is assumed to be insightful, the outcome is pre-ordained.  Nothing replaces speaking truth to power and surviving the encounter.

Below are the 5 questions we ask, based on both project rescue and innovation experiences:

  1. What is the exhaustive list of all known, outlier and “that’s crazy” hypotheses?
  2. What evidence do we have proving these can happen at all? If we don’t have the information or experience to support our opinion is that because we never captured it or is it impossible to happen?
  3. But if any of these hypotheses do happen, especially the ‘impossible’ category (which have a strange habit of occurring anyway), what else would be affected or would be a related upstream or downstream effect?  How does this affect the underlying business logic? If our competitor did this to us, what would be the hit?
  4. How do we ensure the most desired hypotheses happen or fix things if the worst case occurs?
  5. How do we measure the ongoing operational status of each, as well as an early warning requiring action? How much information is required to get an accurate read?

Why avoid using deep questioning before everything blows up? It can be painful until mastered, but as Hitchcock said, “when all these are removed and you can look forward and the road is clear ahead, and now you’re going to create something…”

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe