3.2 Working assumptions
Main page |
As many companies have discovered, getting new products on the market takes longer and longer time and requires more and more documentation while the product's lifespan continues to decrease. Especially in areas like pharmaceuticals, medical devices and other high-tech products used on humans. At the same time the costumers have less money and want larger discounts.
In the old days you could make a product. Start with developing the technology, make the product and test it, in that order, before product launch. Those days are over. Now the things are done parallel to save time. Technology is developed within the projects instead of before, and a lot of development is based on "working assumptions" rather than facts, leading to a lot of failures, as the assumptions turn out to be wrong.
Nothing wrong with parallel development and the concept of "working assumptions" is valid. Where things go wrong is when a lack of technological understanding turns "working assumptions" into "the documented truth" without being tested.
To put it in simple terms: Assumptions is the mother of all fuck-ups!
It may be something as simple as assuming that when the boss or project manager tells you that something has been documented, it actually has. If it's vital for your part of the project, take the time to read the documentation and make sure it really has been documented. I have seen this one several times at several companies. It may be biological tests, it may be patents, it may be the market size. The possibilities are almost endless, and the cost in time and money can be disastrous.
One company I heard of assumed that the costumer wanted an apparatus that could measure the content of a specific chemical with a four or five decimal accuracy and spent time and money developing the apparatus. The costumer, as it turned out, didn't need more than 2 decimal accuracy, what they needed was a cheap and reliable instrument.
When Coca Cola launched their new taste in the 1990s, it was based on the assumption that the market had peaked and costumers wanted coke to taste differently. No, they did not. Shortly after the introduction of the new Coke they had to reintroduce the old taste as Coca Cola Classic, and discreetly take the new taste off the market after which the "Classic" was removed and Coca Cola was once again Coca Cola.
When the U.S. army invaded Vietnam they assumed that a bunch of uneducated farmers would be no match for a well trained army. As the history books shows, they were wrong.
The U.S. army couldn't have known at the time that the Vietcong would be a formidable enemy, and they had no way to test the assumptions before they deployed the troops. The two other companies have no excuses. They failed to test the working assumption by doing a simple but thorough market research, and it cost them time and money.
When you make assumptions, the first thing you do is to set things in motion to turn the assumptions into documented truth. Do not ever underestimate the impact wrong assumptions have on projects. Many are made in the beginning of projects, so they affect the course of the project from day one.
In the old days you could make a product. Start with developing the technology, make the product and test it, in that order, before product launch. Those days are over. Now the things are done parallel to save time. Technology is developed within the projects instead of before, and a lot of development is based on "working assumptions" rather than facts, leading to a lot of failures, as the assumptions turn out to be wrong.
Nothing wrong with parallel development and the concept of "working assumptions" is valid. Where things go wrong is when a lack of technological understanding turns "working assumptions" into "the documented truth" without being tested.
To put it in simple terms: Assumptions is the mother of all fuck-ups!
It may be something as simple as assuming that when the boss or project manager tells you that something has been documented, it actually has. If it's vital for your part of the project, take the time to read the documentation and make sure it really has been documented. I have seen this one several times at several companies. It may be biological tests, it may be patents, it may be the market size. The possibilities are almost endless, and the cost in time and money can be disastrous.
One company I heard of assumed that the costumer wanted an apparatus that could measure the content of a specific chemical with a four or five decimal accuracy and spent time and money developing the apparatus. The costumer, as it turned out, didn't need more than 2 decimal accuracy, what they needed was a cheap and reliable instrument.
When Coca Cola launched their new taste in the 1990s, it was based on the assumption that the market had peaked and costumers wanted coke to taste differently. No, they did not. Shortly after the introduction of the new Coke they had to reintroduce the old taste as Coca Cola Classic, and discreetly take the new taste off the market after which the "Classic" was removed and Coca Cola was once again Coca Cola.
When the U.S. army invaded Vietnam they assumed that a bunch of uneducated farmers would be no match for a well trained army. As the history books shows, they were wrong.
The U.S. army couldn't have known at the time that the Vietcong would be a formidable enemy, and they had no way to test the assumptions before they deployed the troops. The two other companies have no excuses. They failed to test the working assumption by doing a simple but thorough market research, and it cost them time and money.
When you make assumptions, the first thing you do is to set things in motion to turn the assumptions into documented truth. Do not ever underestimate the impact wrong assumptions have on projects. Many are made in the beginning of projects, so they affect the course of the project from day one.