In some cases, that's the most economical or even the only option. But Unknown isn't unknown, and it makes sense to classify the term a little bit further.
The types of Unknown
Folly
Some things are just common knowledge. For example, everyone who has a smartphone knows that you need a secure password for everything that's on the Internet. To claim that "we didn't know that 'root' doesn't make a good root password for our web server." is just plain foolish. It's not Unknown, and there is no sensible reason to treat it as one.Unqualified
If you work in a field, for example, software development, a few things can be assumed as standard knowledge. It doesn't take much except reading a few blog articles, a beginner's book or attending a really basic class to know these things. People who don't put the effort to know the very basics of what they're dealing with are sloppy and therefore unqualified. Absence of basic knowledge means you hired the wrong people, not that people should learn by trial and error.Silly Excuses
Things wouldn't be common knowledge unless they were understood by a majority of the population. Claiming that it's not possible to research what happens when you disconnect a router is just a silly excuse. These also don't qualify as Unknowns for anyone who intends to keep their job - as a company that accepts such unknowns is very unlikely to survive for long.Knowledge gaps
As soon as we get to field specific knowledge, not everyone can know everything. For example, you might have hired a music PhD for your development team who contributes a lot when it comes to synergizing ideas - but they may be unaware of how to write proper tests. That's an acceptable Unknown, which can be readily covered with available information. Throw in a bit of practice and you're set.These Unknowns are fairly predictable and can be planned quite well.
Unfeasible
You may encounter areas where nobody on your team has any knowledge, and only a few people on the planet know what they're talking about. Maybe the thing you need to know hasn't even been explored yet or it's just uneconomical to acquire enough information upfront.Such Unknowns are quite typical when doing innovation work, and are often hard to plan, as nobody knows exactly what the result will be and which steps will lead there.
This is the domain of experimentation, adaptation, trial and error.
Unknowable
The most difficult realm for prediction is knowledge which can't possibly exist, such as information about the future. While we can either research or explore by trial and error how customers use our product, we have no way of knowing whether a policy change in a country somewhere half across the globe will plunge our business into an economic crisis tomorrow.The Unknowable warrants an entirely different approach. Usually, deliberately ignoring unknowable circumstances until they occur is the best strategy (as trying to know the Unknowable can consume an infinite amount of energy with no return on invest). When something Unknowable pops up, we need to deal with it - and that's being agile.
Dealing with Unknowns
If your development team claims that something is Unknown, first classify why the thing is unknown.- Folly, unqualified action and silly excuses should not be tolerated. If it's a people thing, address the behaviour openly.
- Knowledge gaps should be brought up as early as they become known, so they can be filled effectively.
- In software development, - acquiring all the knowledge is unfeasible: either too complex, too slow or too expensive. "Experiment, Inspect and Adapt" is the most economical, pro-active strategy.
- Everything related to the future is unknowable. Accept it. The further you look into the future, the larger the Unknowable becomes. The impact of the Unknowable on your work determines how flexible you'll need to be.
No comments:
Post a Comment