evolution of music, musical notation, the design of the piano, and methods of teaching piano all have evolved in nonrigorous ways.
Anything explicitly planned must have arisen from a less explicitly planned activity at some point in history. ET is exactly the kind of activity that comes before rigor and makes rigor possible. ET is primarily creative. It has value because it exposes problems, but it also has value because it is a way to create other kinds of tests. It's a great way to learn about a product. And rigorous test plans start with thorough understanding of the product. That gives us an answer to the planning question: an open-ended plan may be all that we have. If you already know for sure what the next test is that would be worth executing, by all means follow that plan. Otherwise, you'll have to figure that out for yourself. And that's an exploratory process.
You get someone to agree to such a process the same way you get someone to agree to allow a house to be built before they try to live in it. If they understand the difference between a house and an empty lot, and they want a house, and they see that there is no house, they may well agree that someone ought to build one.
…and dealing with a complex world requires skill, above all.
Still another way to think about Ms. Sahoo's question is that it's a query about how a relatively lightly planned activity can be organized and managed. This is where the myth of planning really rears its head. The truth is, we organize and manage all kinds of things without detailed plans. In the absence of pre-scripted moves, what do we do? We pay attention. We react to the situation at hand. We anticipate problems. Because we don't always know the right answers in advance, we have developed ways to come up with answers on the fly.
Similarly, we can train testers to excel safely in exploratory testing: start small, provide coaching, learn from failure, and build on successes. I don't send testers on complex exploratory missions until they have gained credibility on the easier missions. Testers must show an ability to design a good test strategy, execute good tests, find important problems, and report them in a compelling way. Furthermore, they must be able to explain their work. Only under those conditions do I come to trust a tester's exploratory work.
Remember it's the skill of the tester, the social system of the project team, and the testing situation at any given moment that enable excellent exploratory testing. Don't dwell too much on planning. If you're challenged to defend exploratory testing on the basis that it's not planned, reply that when the developers let you know where all the bugs are, you will happily write a precise and accurate plan that visits each one. Until then you must spend some of your time exploring in order to find important bugs fast.