There are some things that are so obvious that everyone knows them. These are the things that people talk about on busses, trains and in cafes. Nobody questions them because they are common sense. Everybody is certain that these “truths” are correct.
The trouble is that people can be wrong.
The “truths” on which people form their strongly held views might be out of date, inaccurate or no longer applicable. The same thing happens in organisations and projects. How many times have you heard someone say “that would just never work here”
Innovation may require the challenging or re-writing of “truths”
Innovation often requires a paradigm shift. It might be uncomfortable, but also necessary for a project to question or even reverse “truths” that have been in place for years.
As Business Analysts, we have a real opportunity to challenge these truths using open questions. Here are a few of my favourites (!):
1. “Are you certain that is true – has it been proved? Or is it an assumption?”
2. “Can you tell me why this solution wouldn’t be appropriate?”
3. “What would have to change for this to work?”
4. “If we were designing this [widget] from scratch, how would it look?”
5. “If we were forming a brand new company, how would we approach this?”
6. “How do our competitors approach this?”
7. “If we were in an ideal world, with no constraints, how would we approach this?”
Ultimately, innovation needs “buy in” from all levels of the organisation. Robust Business Analysis will help organisations to make sure that they challenge the norm and pick the winning projects. However an excellent communication & engagement plan will be needed to ensure that people are on board.
Innovative projects aren’t easy, but they are necessary to survive.
I read your seven questions and I think to myself, “this will only work under some conditions”. Let me tell you why.
You ask a programmer to do something in one way, the programmer says it can’t be done, you’re not a technical person, how can you challenge that?
In case you are a technical person, you are henceforth considered a skeptical from the programmer’s perspective and s/he will deal with you differently (after all, there is something called the programmer’s ego).
IMO, in order to be able to ask these questions, and more, you have to be a technical person, respected by the programmers, and blessed with authority.
Hi PM Hut, Many thanks for your comment.
I think that this really comes down to timing.
Whilst these questions could come in useful throughout the entire project lifecycle, I think they are most useful at the initial phases. They can be used to question any pre-conceived ideas about the business landscape, or even the problem itself that the project is looking to solve.
The solution may or may not involve technical change, it might involve organisational or process change. I believe that by asking these types of question (whilst maintaining ‘open mindedness’) tends to encourage more innovative thinking and will help focus on the requirements rather than the solution.
However, I do accept your point that it may be difficult to challenge programmers on specific technical design issues. However, I believe it isn’t impossible – it’s still possible to build rapport, and ask probing questions to understand any key issues. In addition, a good Solution Architect will be able to provide an objective input.
The most important point, I believe, is that smart organisations constantly challenge “truths” (e.g. “We can’t sell our products in supermarkets, they must be sold in a specialist outlet”, “People will always buy CDs” etc).